王中阳

主题

Tool Calling、MCP 与 Agent 的关系：能力、协议与运行时分层 ​

Tool Calling 是模型表达“要调用哪个工具及参数”的能力，MCP 是应用与外部能力提供方之间发现和交换工具、资源、提示等上下文的协议，Agent 则是围绕目标反复感知、决策、执行与停止的运行系统。三者可以组合，但不存在“用了 MCP 就自动成为 Agent”或“Agent 必须通过 MCP 调工具”的必然关系。

先说结论 ​

可以把三者放在不同层次理解：

text
Agent：目标、状态、循环、策略、预算与停止
  ↓ 决定何时需要外部能力
Tool Calling：模型用结构化方式提出工具调用意图
  ↓ 由宿主程序校验与路由
MCP：宿主程序与能力提供方之间的标准化连接
  ↓
本地函数 / 内部 API / SaaS / 数据库 / 文件系统

这是一张职责分层图，不是一条强制依赖链。Tool Calling 可以直接调用本地注册函数而不使用 MCP；MCP Client 也可以在固定 Workflow 中读取资源而不使用 Agent；Agent 还可以通过普通 SDK、HTTP API 或消息队列执行工具。

本文只解释协议和调用关系。Agent 每轮如何维护状态见Agent 运行机制总览，是否需要 Agent 则见Workflow、Agent 与多 Agent 怎么选。

适合谁，不适合谁 ​

本文适合：

  • 被 Tool Calling、Function Calling、MCP、Agent 等术语混淆的开发者；
  • 正在设计模型、Agent Runtime 与工具服务边界的架构师；
  • 需要判断现有函数是否值得封装为 MCP Server 的团队。

已有经验同样可以迁移：前端与客户端开发者可把 MCP 理解为能力接入边界，后端开发者关注服务端授权和幂等，测试开发者关注参数 Schema 与失败观察，运维开发者关注凭证、审计、超时和恢复。

本文不适合：

  • 只想复制某个 MCP SDK 快速开始代码的人；
  • 只想比较单 Agent 与多 Agent 的架构选型者；
  • 需要学习某个模型供应商具体 API 字段的人。

三个概念分别解决什么问题 ​

Tool Calling：模型如何表达调用意图 ​

应用向模型提供工具名称、说明和参数 Schema。模型根据当前上下文返回结构化调用请求，例如：

json
{
  "name": "get_order",
  "arguments": {
    "order_id": "A1024"
  }
}

这一步只表示模型建议调用 get_order，并不表示工具已经执行。宿主程序仍需：

  1. 检查工具是否在当前会话白名单；
  2. 校验参数格式与业务约束；
  3. 以当前用户身份鉴权；
  4. 执行本地函数或远程服务；
  5. 把结果作为观察返回给模型。

因此，Tool Calling 的边界是“结构化决策接口”，不是远程调用协议，也不是权限系统。

MCP：应用如何标准化接入能力 ​

MCP 将能力提供方封装为 Server，由 Client 连接并发现可用能力。它减少了每个 AI 应用为不同工具重复设计描述、传输和结果格式的成本。

从职责上看，MCP 关心的是：

  • Client 与 Server 如何建立会话；
  • Server 暴露哪些工具、资源或提示；
  • 参数与结果如何交换；
  • 能力列表如何发现和更新；
  • 协议级错误如何表达。

但 MCP 不替业务系统自动解决：

  • 当前用户是否有权执行某个动作；
  • 工具结果是否可信；
  • 写操作是否需要审批；
  • 调用是否满足幂等和事务要求；
  • Agent 何时停止。

这些仍属于宿主应用、业务服务和 Agent 运行时的责任。

Agent：围绕目标组织多轮行动 ​

Agent 管理目标、状态、上下文、模型决策、工具执行、观察、预算和停止。Tool Calling 是它可采用的一种决策输出形式；MCP 是它可采用的一种能力接入方式。

一个 Agent 可以在首轮查询订单，观察到“已发货”后再查询物流，在物流异常时创建工单。关键不在调用了三个工具，而在每次结果都会改变下一步决策，并且整个过程受成功标准和停止条件约束。

四种常见组合 ​

组合是否成立示例
Tool Calling，无 MCP，无 Agent成立单次模型选择本地天气函数，程序返回结果
MCP，无 Agent成立固定 Workflow 通过 MCP 读取代码仓库资源后生成报告
Agent + Tool Calling，无 MCP成立Agent 调用应用内注册的搜索与工单函数
Agent + Tool Calling + MCP成立Agent 动态选择多个 MCP Server 暴露的受控工具

还有一种情况是 Agent 不依赖模型原生 Tool Calling：运行时可以要求模型输出自定义 JSON，再由程序解析动作。不过原生 Tool Calling 通常能减少格式解析工作；是否采用取决于模型能力、协议稳定性和可测试性。

一次调用如何穿过三层 ​

以“查询客户订单异常并创建工单”为例：

  1. Agent Runtime 保存用户目标、身份和成功条件。
  2. Runtime 将允许使用的工具描述交给模型。
  3. 模型通过 Tool Calling 提出 query_orders(customer_id)。
  4. Runtime 校验参数、用户权限和调用预算。
  5. MCP Client 将请求发送给订单 MCP Server。
  6. Server 调用订单系统，并返回结构化结果。
  7. Runtime 过滤敏感字段，将结果写入 Agent 状态。
  8. 模型观察到异常订单，提出 create_ticket(...)。
  9. Runtime 发现这是写操作，先请求用户确认。
  10. 确认后执行并以工单号验证成功条件，随后停止。

在这条链路里：

  • 模型不持有订单系统凭证；
  • Tool Calling 不直接执行 API；
  • MCP Server 不决定业务任务是否完成；
  • Agent Runtime 不应绕过订单系统自身的授权。

工具应该直接注册还是封装为 MCP ​

判断直接注册本地工具封装为 MCP Server
使用范围单个应用内部多个 Client 或团队复用
部署关系与宿主同进程或同仓库独立维护和版本演进
能力发现静态注册即可需要标准化发现
权限模型宿主统一控制需要 Client、Server 双层控制
运维成本较低需要连接、版本、监控与兼容治理
适用起点快速验证、内部函数稳定能力平台或跨应用集成

反例：只有一个 Agent 使用两个简单函数，却为了“技术栈完整”分别建立两个 MCP Server。这样引入的部署、鉴权和故障面可能超过复用收益。先直接注册工具，等能力边界稳定且出现第二个消费者，再协议化通常更合理。

安全与可靠性边界 ​

工具描述不是授权 ​

从模型上下文中隐藏一个工具，只能减少被选择的概率，不等于禁止访问。Runtime 和 Server 都应按真实身份鉴权，并对租户、资源和动作做限制。

MCP Server 返回的是外部输入 ​

资源内容、工具结果甚至工具说明都可能包含错误或恶意指令。Runtime 应把它们标记为数据，而不是高优先级系统指令；敏感操作不能因为结果文本写着“请立即删除”就自动执行。

能力发现需要快照 ​

Server 的工具列表可能变化。一次长任务应记录使用的 Server、工具 Schema 和版本快照。否则恢复任务时，同名工具参数已变化，旧动作可能无法重放。

错误必须逐层归因 ​

至少区分：

  • 模型没有生成合法 Tool Call；
  • Runtime 参数或策略校验拒绝；
  • MCP 连接或协议失败；
  • Server 执行失败；
  • 下游业务系统失败；
  • 工具成功但 Agent 验收未通过。

把所有错误都返回“工具调用失败”，会让模型盲目重试，也让工程人员无法定位故障。

常见误区与失败边界 ​

误区一：MCP 是更高级的 Tool Calling ​

两者不在同一层。Tool Calling 连接模型决策与宿主程序；MCP 连接宿主程序与能力提供方。使用 MCP 后，模型仍需要某种方式表达动作，程序仍需要执行和观察循环。

误区二：接入 MCP 后自动获得统一权限 ​

协议统一不等于权限统一。每个 Server 的数据敏感度、身份传递和写操作风险不同。Client 白名单、用户授权、Server 鉴权和业务系统校验缺一不可。

误区三：工具越多，Agent 越强 ​

工具描述会占用上下文，相似工具会增加误选概率，权限面也随之扩大。Runtime 应按任务、身份和阶段只暴露最小工具集合。

失败边界 ​

以下情况不适合立刻引入 MCP：

  • 能力仍频繁变化，连输入输出边界都未稳定；
  • 只有单一调用方，直接 SDK 已足够且没有复用计划；
  • 无法定义身份如何从 Client 传递到 Server；
  • 团队没有能力监控连接、版本兼容与 Server 可用性。

以下情况即使接入 MCP，也不应开放给自主 Agent：

  • 写操作不可回滚且没有人工确认；
  • 工具无法做到资源级鉴权；
  • 返回内容无法隔离提示注入；
  • 调用成功与业务成功没有可验证的对应关系。

可执行检查清单 ​

Tool Calling 层 ​

  • [ ] 工具名称、用途和参数 Schema 清晰且互斥
  • [ ] 模型输出只被视为候选动作
  • [ ] 参数还会经过业务校验与身份鉴权
  • [ ] 工具结果带调用 ID、状态和可追踪错误

MCP 接入层 ​

  • [ ] 只有稳定、可复用的能力才被协议化
  • [ ] Client 与 Server 的信任边界已记录
  • [ ] 身份、租户和最小权限可端到端传递
  • [ ] 工具列表与 Schema 变化有兼容策略
  • [ ] 连接失败、Server 失败和下游失败可区分

Agent 运行层 ​

  • [ ] 只暴露当前任务必要的工具
  • [ ] 每轮调用受时间、次数和费用预算限制
  • [ ] 外部结果按不可信数据处理
  • [ ] 写操作具备确认、幂等、审计与恢复机制
  • [ ] 停止条件由实际工具证据验证

下一步 ​

先回到 Agent 专题 Hub 对照完整知识结构。理解分层后，下一步阅读 MCP 基础：外部数据与工具接入，把一个边界稳定、低风险的只读能力接入现有 Workflow，再决定是否交给 Agent 动态调用。

AI 应用开发训练营 · 现在开始

别只收藏 AI 文章，今天就做出第一个能上线的项目

文章解决认知，项目才证明能力。把 Agent、RAG、MCP 变成可运行、可展示、可面试表达的成果，现在就从一次岗位准备度自测开始。

立即开始 AI 岗位准备度自测 查看训练营路线
真实学员成果先看成果，再决定是否开始 →
  1. 01选方向
  2. 02做项目
  3. 03出成果
  4. 04拿面试