A2A vs MCP vs ACP：协议之争已结束，团队仍在买单

一场已经结束的协议战争

2026年了，仍有开发团队在为一场早已分出胜负的协议战争付出代价。

有人花了三周时间重构一套多智能体系统——原因仅仅是同事读到一篇「ACP才是未来」的文章，就把整个集成层押在了这个协议上。事后复盘里有一句话值得所有技术决策者警醒：「我们没有选错协议。我们选了一个已经被废弃的协议，只是当时不知道。」

重构本身的成本还不是最贵的。真正的代价在于：团队已经向利益相关方承诺「我们已就绪ACP」，结果标准在项目启动前两个月就已经并入另一个标准。

这场协议战争已经结束了。问题在于，很多团队还在打。

三个协议，一个已经出局

MCP、A2A、ACP出现在同一个十八个月的窗口里，名字里都带着「协议」，都承诺解决智能体互操作性问题。很多团队把它们当成竞争关系，或者更糟——当成可以互换的东西。

它们既不是竞争关系，也不能互换。而且其中一个已经不再是一个选项。

MCP（Model Context Protocol）是垂直集成层。 它规范的是单个智能体如何向下触达世界：调用工具、读取数据、调用API。智能体保持主导权，它触碰的东西是被动的。一个封装数据库查询的MCP服务器不会思考、不会协商、不会反驳——它暴露能力，然后等待。据公开数据，MCP的月下载量已达9700万次，十八个月内增长了970倍。

A2A（Agent2Agent Protocol）是水平协调层。 它规范的是一个智能体如何将工作委派给另一个拥有独立推理能力、独立工具集、独立行动权限的智能体。接收方可以接受任务、提出澄清问题、运行六分钟，或者直接拒绝。A2A在2026年3月发布v1.0，到4月已有超过150家支持组织，并在Google、Microsoft、AWS平台上深度集成。

ACP（Agent Communication Protocol）是IBM的入场作品，2025年3月发布，为BeeAI平台提供动力。2025年8月，IBM Research和Google宣布ACP将与A2A合并，归入Linux Foundation的LF AI & Data旗下。ACP的开发正在收尾，其资产和专业知识直接贡献给A2A。主导ACP的Kate Blair已加入A2A技术指导委员会。ACP原始仓库已归档，其README明确写道：ACP现在是Linux Foundation治理下A2A的一部分。

对开发者而言，这次整合划出了清晰的分工：MCP是模型到工具通信的标准，A2A是智能体到智能体通信的标准，ACP是一份带迁移指南的历史脚注。

MCP、A2A、ACP的底层传输机制都建立在JSON-RPC 2.0之上，这一点常被忽略。JSON-RPC是一种轻量级远程过程调用协议，用JSON格式编码请求和响应，请求包含method、params、id三个字段，响应则返回result或error。选择它意味着协议本身只定义「消息长什么样」，而不绑定具体传输通道——可以跑在HTTP、WebSocket或stdio上。MCP早期主要用stdio本地通信，后来扩展到HTTP+SSE；A2A则直接基于HTTP。理解这层共性有助于看清：三个协议的差异不在「怎么传」，而在「传什么语义」——工具调用、任务委派还是代理协商。也正因如此，ACP并入A2A在工程上才可行：底层消息格式一致，迁移主要涉及的是语义层和状态模型的重新对齐，而非传输管道的推倒重来。

选错协议的真实代价

ACP到A2A的迁移路径确实存在。BeeAI用户可以通过A2AServer适配器让智能体符合A2A规范，外部A2A智能体也可以通过A2AAgent集成到BeeAI应用中。

但适配器无法撤销建立在ACP假设之上的架构决策。如果你的系统围绕ACP的代理通信模型构建，迁移到A2A的点对点任务委派不是查找替换操作——它是协调层的重新架构。

整合本身是正确的决定。智能体间通信只有一个标准，比两个竞争标准更好。Linux Foundation的说法是将ACP的资产和专业知识引入A2A，加速走向「一个单一的、更强大的AI智能体通信与协作标准」。代价由那些已经交付上线的团队承担。

垂直与水平的双层栈

在生产环境中经受住考验的心智模型是一个双层栈：MCP处理垂直方向，A2A处理水平方向。它们不是竞争关系，而是互补关系。

2026年6月的统一互操作性框架论文明确描绘了这一点：MCP和A2A是互补而非竞争的，采用统一方法可将集成复杂度相比临时方案降低约60%–70%。另一项智能体互操作性协议综述得出了相同结论：MCP提供JSON-RPC客户端-服务器接口用于安全工具调用，A2A则通过基于能力的Agent Cards实现点对点任务委派。

经得起检验的实践决策框架是：

当智能体需要向下触达世界时，用MCP。 快速、结构化、请求-响应式操作——数据库查询、文件读取、API调用。智能体保持主导，被触碰的对象保持被动。

当独立智能体需要跨出你不完全控制的边界委派工作时，用A2A。 远端确实是具备推理能力的自主智能体，而非被动工具。任务可能运行数分钟甚至数小时，接收方可能提出澄清问题或拒绝。

当系统同时有垂直和水平需求时，两个都用。 大多数生产系统都是如此。A2A智能体调用MCP获取上下文，MCP托管的工具触发A2A委派。两层可以自由组合。

Agent Card是A2A的「能力名片」，通常以/.well-known/agent.json路径暴露，内容包括智能体的名称、描述、支持的技能、输入输出模态、认证方式以及服务端点。它解决的问题是「发现」：调用方在委派任务前，先拉取对方的Agent Card，据此判断该智能体能否处理当前任务、需要何种认证。这与MCP的tools/list机制形成对照——MCP列出的是被动工具的能力清单，A2A的Agent Card描述的则是主动智能体的服务契约。从v0.3起Agent Card可携带JWS签名，验证方通过公钥验证卡片未被篡改。但要注意，Agent Card是自我声明的：智能体说自己能做什么，协议并不强制第三方背书，这正是「合规不等于可信」的技术根源。

「企业级就绪」到底意味着什么

A2A v1.0的发布是它从「有前途的标准」变成「生产级开放标准」的里程碑。对企业部署有意义的功能很具体：

签名Agent Cards提供密码学身份验证。 从v0.3起，Agent Cards可以携带JWS密码学签名，接收方能够验证卡片未被篡改，且确实来自所声称的提供方。

企业级多租户和现代化安全流程。 v1.0规范引入了多协议支持、多租户，以及面向早期采用者的明确迁移路径。

面向规模的Web对齐架构。 协议支持熟悉的安全和负载均衡模式，以实现高规模可靠性。

但企业级就绪不等于生产安全。A2A规范本身对其保证和不保证的内容非常谨慎。协议解决的是「如何传输」，而非「如何信任」。任务状态由执行方自行报告。签名Agent Card证明的是身份，不是履约质量。验证环节——验收测试、日志记录、人工审批——必须由采用方自行构建。

Salesforce的发布是A2A进入产品化打包的最清晰信号。Agentforce的原生第三方编排「将Agentforce扩展到任何A2A兼容生态」，允许系统编排来自AWS、Azure、Google的智能体，或作为子智能体参与外部架构。

但「A2A兼容」这个标签所认证的内容比营销暗示的要少。对方身份完全自行声明——Agent Card签名是可选的，不是强制的。没有正式的发现注册表；注册表规范从未发布，维护者将这一需求重定向到相邻规范。协议是为不透明执行设计的，这意味着合规认证的是对话，不是智能体的行为或操守。

JWS（JSON Web Signature）是Agent Card签名所依赖的密码学标准，属于JOSE（JSON Object Signing and Encryption）家族，与JWT同源。其工作方式是：签发方用私钥对卡片内容的规范化JSON进行签名，生成三段式字符串（头部、载荷、签名），验证方用签发方公钥验签。JWS保证的是完整性和来源真实性——卡片没被改动，且确实由持私钥的一方签发。但它不保证内容为真：一个恶意智能体完全可以如实签署一张「我能力超强、绝对可靠」的卡片。此外，JWS验签的前提是验证方已经以可信方式获得了公钥，这又把问题推回到密钥分发和信任锚——协议层再次把难题留给了采用方。这也是为什么文章反复强调：签名解决身份，不解决履约。

用数据量化协议选择

对比文献已经超越了定性评估阶段，数字已经具体到可以据此规划。

集成复杂度降低。 统一TLAS框架估计，同时使用MCP和A2A的分层方法可将集成复杂度相比临时方案降低60%–70%。

采用速度。 MCP SDK月下载量达到9700万次，注册表收录42,753个服务器。A2A在第一年内就达到150+支持组织，并嵌入Azure AI Foundry、Amazon Bedrock AgentCore和Google Cloud。

生产部署。 一项针对100名高级软件工程师的调查显示，41%的软件组织报告MCP已进入生产环境。Gartner预测，到2026年底，40%的企业应用将包含任务特定AI智能体，75%的API网关厂商将具备MCP功能。

正在成形的协议栈

更广泛的格局已经整合为一个分层栈。理解每个协议所处的位置，才是避免重蹈覆辙的关键。

身份与信任层。 签名Agent Cards为A2A提供可验证身份。Web Bot Auth为Web指向同一方向。支付授权携带密码学问责。目前尚不存在的是一种统一方式，让智能体在所有层同时携带「它是谁、它代表谁、它可以做什么」。这仍是下一阶段的标准之争。

智能体间协调层。 A2A是标准。ACP的合并巩固了这一格局。

工具访问层。 MCP是标准。注册表靠自下而上的动力扩张，而A2A注册表仍是开放RFC。

人机界面层。 AG-UI及相关努力将智能体输出流式传输到应用中。这一层尚早，由框架主导而非基金会治理。

支付层。 AP2、Agentic Commerce Protocol、x402等正在竞争。实践者的建议很坦率：把智能体支付当作在抽象层后面试点的能力，而不是托付终身的基础。

你正在接受的权衡

选择A2A和MCP意味着接受这个栈仍在演进。ACP的合并证明了生态可以很好地整合。支付层是下一个检验这种能力的地方。

你也需要接受，「合规」是采购问题，不是技术保证。因为大型企业套件现在把「跨任何A2A兼容生态的编排」作为正式产品出售，验证的负担落到了买方身上。标签提供了连接所需的共同语言，但不提供安全或身份的保证。组织必须验证它们连接到内部系统的智能体，因为协议对参与者的底层意图或可靠性保持不可知。

同时，MCP有一个协议尚未完全解决的扩展问题。每个工具定义都会消耗智能体上下文窗口中的Token。当MCP服务器达到几十个时，仅工具描述就可能消耗上下文窗口的大部分，模型还没来得及读用户消息。MCP规范的渐进式发现建议缓解了这个问题，但它是缓解措施，不是解决方案。

做对了的团队不是在已经结束的战争中选边站。他们在仔细划定边界：把MCP当作工具访问层，把A2A当作协调层，并构建两个协议都不提供的验证层。

所以问题回到你身上：如果你今天正在基于某个协议构建系统，你能说清楚它保证了什么、又把什么留给了你吗？还是你仍然把「合规」当作「安全」的同义词？