大多数团队在选择智能体协议时，实际上同时做了三个不同的决策——把它们混为一谈，正是为什么许多集成一旦引入第二个框架就会崩溃的原因。
这三个决策分别是：智能体如何与工具和数据交互（纵向集成）、智能体如何与其他智能体协作（横向协调），以及智能体如何向人机界面暴露状态（交互层）。Google 的 A2A、Anthropic 的 MCP 和基于 OpenAPI 的 REST 解决的是这个栈的不同层次。当工程师混淆它们时，要么用多智能体机制过度设计单智能体场景，要么用单智能体工具欠设计多智能体工作流。两种失败在生产环境中重构代价都极高。
协议实际解决的三个层次
在比较协议之前，你需要对智能体接口栈有一个清晰的认知模型。
工具集成层是智能体向外连接数据库、API 和外部服务的地方。这是 MCP 的领域。智能体需要读取向量存储、调用天气 API 或调用代码解释器——MCP 定义了这种客户端-服务器契约。其架构本质上是纵向的：一个智能体，多个工具。
智能体协调层是智能体横向连接其他智能体的地方。这是 A2A 的领域。一个规划智能体将任务分派给专门的代码编写智能体或文档摘要智能体，跟踪任务生命周期并收集结果。其架构本质上是横向的：多个智能体，对等关系。
交互层是智能体向用户界面暴露状态的地方——流式传输中间结果、渲染结构化组件、处理来回澄清。这是 AG-UI 等新兴项目的领域，标准化工作仍处于早期阶段。
对正在解决的问题产生混淆，会让你走上错误的协议路径。把 A2A 当作 MCP 替代品的工程师，最终会为本质上是单智能体工具调用的问题编写智能体协调代码。
MCP 真正优化的是什么
MCP 由 Anthropic 于 2024 年 11 月发布，到 2026 年初月 SDK 下载量达到 9700 万——这个数字说明了生态系统多么需要一个工具集成标准。
MCP 的核心赌注是：工具访问控制比智能体身份更重要。其信任模型是集中式的：宿主应用（运行 LLM 的东西）是权威。当智能体要调用工具时，宿主负责中介该调用、执行用户同意并控制服务器可访问的数据。服务器只在宿主授权的范围内被信任。
这种设计对单智能体场景非常有效——读取文件并执行 shell 命令的编码助手、查询 CRM 的客服机器人。当多个智能体需要共享工具服务器时效果较差，因为信任模型无法干净地处理"哪个智能体的权限适用"这个问题。一些团队通过每个智能体独立的服务器实例来绕过这个问题，功能上可行但运营成本较高。
MCP 的传输栈（JSON-RPC 2.0 over stdio、HTTP 或 SSE）有意保持简单。2025 年 11 月的规范更新增加了异步操作和无状态服务器支持，将其触达范围扩展到更高延迟的工具后端。权衡是 MCP 没有任务生命周期的概念——它处理离散调用，而非长时间运行的委托工作。
A2A 真正优化的是什么
Google 于 2025 年 4 月发布 A2A，拥有 50 多家合作伙伴组织，并于 2026 年初发布 v1.0，现在由 Linux 基金会旗下的 Agentic AI Foundation 与 MCP 共同治理。
A2A 的核心赌注是：智能体身份比工具访问控制更重要。其信任模型是分布式的：智能体通过基于 JSON 的"智能体卡"公告其能力，协商支持的协议，并在无需依赖中央宿主的情况下相互认证。这是点对点身份，而非客户端-服务器授权。
A2A 专为无法查看对方内部的场景设计。当你的规划智能体向另一家公司的第三方智能体分派任务时，你不知道该智能体运行在什么框架上、有哪些工具或如何在内部处理错误。A2A 专门处理这种不透明性——它规定任务生命周期状态（已提交、处理中、已完成、失败）、能力发现和用户体验协商，所有这些都不需要远程智能体暴露内部实现。
IBM 于 2025 年 3 月发布了一个名为 ACP 的竞争性 REST 协议，并于 2025 年 8 月在 Linux 基金会下合并入 A2A。这次合并值得关注，因为它表明行业正在向 A2A 作为横向协调层的标准答案收敛——2025 年初看似不可避免的协议层碎片化并没有在规范层面出现。
OpenAPI：早于两者的通用语言
OpenAPI（现已更新至 v3.2.0）并非为智能体设计，但它以 A2A 和 MCP 都未曾预料到的方式成为协议栈的重要基础设施。
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- 完整文章，包含未公开存档的部分
- 可落地的工作框架，附带权衡与决策依据
- 新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部