当我们朝着构建能够推理、计划和自主行动的智能系统前进时，模型上下文协议 (MCP) 在构建 AI 模型如何与外部工具和数据交互方面扮演着关键角色。在采用 MCP 时，一个容易混淆的常见问题是——什么时候使用资源，什么时候使用工具。
在这里，老码农尝试对这些概念进行区分，提供一些实际的示例，并总结要点，以便有效地应用它们。
1. 示例场景
假设我们正在开发一个自动化业务工作流的数字助手。例如，当一个新客户签订合同时，助手应该：
- 将客户添加到 CRM 系统。
- 发一封欢迎电子邮件。
- 通过 Slack 通知销售团队。
- 指定一名专门的客户经理。
我们希望 AI 以最少的人工干预来处理这个端到端的过程。
2.MCP中的工具
MCP 中的工具是模型可以调用的操作ーー执行任务的操作。
例如：
复制MCP工具的主要特点：
・模型控制： 人工智能模型决定何时调用它们。
・自动列出： 它们出现在 /tools 端点中。
・自主调用： 模型可以确定使用哪种工具，并在必要时请求缺少的参数。
在我们的业务工作流示例中，像add_client_to_crm、send_email 和 notify_sales_team 这样的操作应该作为工具实现，因为它们需要执行操作，而且模型必须自主决定调用它们。
3. MCP 资源
一般地，资源是由后端公开的只读数据。可以把它们想象成：
- 现有数据清单。
- 静态的参考资料或动态数据集。
- 具有结构化标识符 (uri) 的数据项。
例如：
复制MCP资源的主要特点：
- 客户端控制： AI 模型不会自动调用资源, 客户端应用程序必须对访问进行管理。
- 结构化数据： 它们提供结构化信息，可用于为模型的决策提供信息。
- 上下文管理： 它们通过仅提供相关数据来帮助管理上下文窗口。
在我们的工作流中，使用list_clients, get_client_details和 list_account_managers这样的资源是合适的。
4.为什么不是全部使用MCP工具？
假设公开了 5000 个操作作为MCP工具 (例如，不同的 CRM 系统，api 等等) ，如果这些都是工具：
- 它们在 /tools 中作为 JSON 返回。
- 人工智能模型试图解析所有 5000 个数据，以决定该做什么。
- 这会使上下文窗口膨胀，降低推理速度，甚至可能失败。
相反，可以将 list_crm_systems,list_available_actions或者 list_departments公开为资源。这有助于客户端根据用户输入或身份验证获取相关的上下文片段，从而优化性能和可伸缩性。
5. 何时使用MCP工具？又何时使用资源？
MCP工具和MCP资源的选择依据：
- 是否触发操作？
- 返回结构化数据是否可选
- AI 模型是否 可以自主调用还是客户端必须控制访问
- 是否应用于规划和链接行动，还是只支持上下文抓取
- 是否需要实时的上下文范围
资源有助于管理身份验证和授权：
- 特定于用户的资源列表： 用户请求资源列表时，服务器只能过滤并返回用户可以访问的资源。
- 工具访问控制： 在列出工具时，确保只返回授权用户使用的工具。
此策略确保用户只能看到他们拥有权限的资源和工具，并且可以与它们进行交互，从而增强安全性和用户体验。
如果希望 AI 模型自主地识别有缺失的输入并请求它们，那么必须使用工具。工具是模型控制的，允许模型：
- 读取工具的描述说明。
- 根据提示词选择适当的工具。
- 检测遗漏的输入。
- 自动提示用户输入所需信息。
资源将不会触发此行为，除非客户端应用程序添加了相关逻辑。将数据拉入并将其注入上下文。
虽然 AI 模型本身并不将 tool:// 或 resource:// 解析为协议，但是采用这样的命名约定可以增强可读性和结构。一致的 URI 模式 (如 tool://crm/add-client 或 resource://clients/{ id}) 使生态系统可预测，并且在一些工具框架中能够得到支持。
6.小结
当构建自动化工作流程的智能助手时，在 MCP 工具和资源之间进行选择至关重要：
- 当模型需要自主行动或推理时，使用工具。
- 利用资源提供有范围的、结构化的数据，并减少上下文过载。
对于动态且自动化的Agentic系统，工具是动力，对于管理广泛的参考数据，资源可以帮助我们安全地扩展。
