差不多每隔一次发现会都会被问:“我们应该统一到 A2A 还是 MCP?”
问题的前提就错了。它们不是竞争者。它们在不同的层面解决不同的问题,健康的智能体系统两者都用。
MCP 是用来做什么的
MCP(Model Context Protocol)是 工具表面 的标准。它回答:基于 LLM 的智能体如何发现并调用不属于其训练范围的工具?文档检索、数据库查询、日历 API、内部服务——每个工具发布一个 MCP 服务器,智能体连接、列出能力、调用。
形态是:一个智能体 ↔ 多个工具。工具是被动的;智能体决定何时调用。
MCP 带给你:schema 发现、有类型的参数、结构化返回、认证边界、沙箱化。本质上,它是为智能体客户端调优过的 RPC 标准。
A2A 是用来做什么的
A2A(Agent-to-Agent 协议,有多个——Google 的 A2A、AGNTCY 等等)是 智能体协作 的标准。它回答:多个半自主的智能体如何协调、移交子任务、汇总结果?
形态是:智能体 ↔ 智能体,带状态。双方都有自己的推理循环。交接包含上下文、中间结果,有时还有子任务的所有权。
A2A 带给你:agent cards(能力广告)、任务生命周期、消息传递、可选的流式与人在环节。它不是 RPC——更接近一个有类型的 actor 系统。
困惑从哪来
两者都涉及智能体通过协议、用结构化负载与某物对话。两者都产出 JSON。两者都有客户端与服务端角色。在三万英尺的视角看,它们像是同一件事。
但两侧的自主程度才是真正的区别:
- MCP 服务端:被动。响应调用。自身没有推理循环。
- A2A 智能体:主动。可以拒绝任务、提出替代方案、移交给其他智能体、要求澄清。
如果对面是“从数据库里取这一行”,那是 MCP。如果对面是“调查这个异常并告诉我你发现了什么”,那是 A2A。
真正可行的架构
在我们交付过的每一个多智能体系统里,拆解都是这样:
- stack 顶部:一个编排器(本身往往也是一个智能体)把用户请求路由给专精智能体。
- 专精智能体通过 A2A 通信。 交接保留上下文;监督方追踪任务状态。
- 专精方通过 MCP 使用工具。 检索智能体有一条到向量数据库的 MCP 连接,以及一条到全文搜索服务的 MCP 连接。“运维智能体”有一条到工单系统的 MCP 连接。
A2A 是智能体之间 协调 的方式。MCP 是每个智能体 行动 的方式。
务实的看法
先采用 MCP——它解决最紧迫的问题(与工具对话),它今天的生态更广(大多数 LLM 提供商原生支持 MCP),从“临时工具调用”升级到 MCP 的路径很直接。
当你有 不止一个 需要互相移交工作的智能体时,再采用 A2A。如果你的系统只有一个智能体加上大量工具,A2A 就是过度——根本没人需要协调。一旦你新增第二个专精智能体并需要它与第一个对话,A2A 就开始物有所值。
不要二选一。把它们叠起来。