Agent 互操作协议之战：MCP、A2A、AGNTCY 谁在决定 Agent 世界的边界

一个先放在前面的判断

所有关于 Agent 互操作协议的讨论都被官方叙事带偏了。

官方叙事长这样：MCP 解决工具调用，A2A 解决 Agent 之间通信，AGNTCY 解决企业级编排，三者互补、分层共存、皆大欢喜。这个故事从 2025 年讲到 2026 年，每次三家公司发联合声明都重复一遍。

但只要你真的在生产环境里跑过多 Agent 系统，会发现这是工程师不愿戳破的客气话。真实情况是：MCP 已经从底层往上吃，A2A 的存在感正在被稀释，AGNTCY 大概率会落成企业合规层的一张皮。三个协议不是在分蛋糕，是在抢同一个控制点——谁定义 Agent 调用对端的标准方式，谁就拿到下一代基础设施的入口。

这篇文章要给出的判断是：分层共存只是过渡形态，Agent 互操作协议最终会收敛，而且收敛点不是协议本身，是谁先把规模拉起来。

三个协议的真实定位，不是文档里写的那个

把三家的官方介绍并排放在一起看，会以为他们活在三个不同的星球。但拆开看实际语义和落地形态，差异远没那么干净。

MCP（Model Context Protocol） 是 Anthropic 在 2024 年 11 月扔出来的。表面定位是「让模型连接工具和数据源的标准接口」，本质上是 LSP（Language Server Protocol）那一套思路在 LLM 上的复刻：定义一个通用的 client-server 协议，工具方暴露 server，模型方做 client，中间走 JSON-RPC。

它真正的杀手锏不是技术先进，而是Anthropic 一开始就放弃了协议层的商业化。开源、文档完整、SDK 覆盖 Python/TypeScript/Go/Rust，社区在三个月内做出了几千个 server。到 2025 年下半年 OpenAI、Google、Microsoft 全部宣布兼容 MCP——不是他们想兼容，是开发者不会再为每家平台写一遍 GitHub 集成。

A2A（Agent2Agent） 是 Google 在 2025 年 4 月 Cloud Next 上甩出来的，定位「Agent 之间的通信协议」。技术上基于 HTTP + JSON-RPC + SSE，引入 Agent Card 做能力声明，引入 Task 做异步状态管理。Google 把它捐给 Linux Foundation，签名公司列了五十多家。

A2A 的尴尬之处在于：它要解决的问题，在 2026 年的真实工作负载里没那么突出。绝大多数生产 Agent 系统是「一个 orchestrator 调一堆 tool/sub-agent」的层级结构，不是「多个对等 Agent 互相协商」的网状结构。前者用 MCP 加上一层 sub-agent server 就能做完，没必要再引入 A2A 的 task 状态机。

AGNTCY 是 Cisco 牵头、LangChain/Galileo/Glean/Outshift 等十几家在 2025 年 3 月联合发起的「Internet of Agents」开源项目。它的野心最大：身份（Agent ID）、目录（Agent Directory）、消息层（SLIM）、可观测性、信任评估，全栈都要管。

AGNTCY 的问题反过来——野心太大，垂直整合太重。它实际上是想把 Agent 时代的「DNS + BGP + IAM」一次性发明出来，但 2026 年的开发者大多还在解决「我的 MCP server 怎么不被 prompt injection 打穿」这种基础问题。AGNTCY 的设计文档读起来像 90 年代的 OSI 七层模型：完美、严密、和实际部署没什么关系。

真正的战场在哪：控制点之争

把上面三个协议的位置画出来，会看到一个尴尬的事实：它们的边界都在往外扩，重叠区域在变大。

MCP 1.0 只有 tools/resources/prompts 三类原语。到 2025 年底引入了 sampling（让 server 反向请求 client 调模型）和 elicitation（让 server 向用户索取输入），再到 2026 Q1 草案里加入的 agent primitive——MCP 已经能直接表达「一个 Agent 把任务委托给另一个 Agent」。这个能力的语义和 A2A 的 Task 已经九成重叠。

A2A 也在反向蚕食。2025 年 11 月发布的 A2A 0.3 引入了 Skill 概念，本质上是 MCP 的 tool 加上调用方语义。Google 内部在 Vertex AI 上的实现，是 A2A 包一层 MCP——表面上 Agent 跟 Agent 说话，底下还是 MCP 在搬数据。

AGNTCY 干脆把两个都吃进去。它的 SLIM 消息层默认支持 A2A payload 格式，目录服务里登记的 capability 用 MCP schema 描述。换句话说，AGNTCY 的护城河不是协议，是「我把别人的协议合规化」。

这种局面下，所谓「分层共存」是话术。真实的战场是控制点：

谁定义 Agent 的能力声明格式（MCP 的 tool schema vs A2A 的 Agent Card vs AGNTCY 的 OASF）
谁定义身份和授权语义（MCP 的 OAuth resource indicators vs A2A 的 enterprise auth vs AGNTCY 的 Agent ID）
谁拿到 marketplace 的入口（Claude/ChatGPT 的 connector 商店、Vertex 的 Agent Garden、AGNTCY 的 Directory）

控制了这三个点中任何一个的人，就能把另外两个协议变成自己生态里的「兼容层」。

企业和开发者今年实际遇到的两个痛点

抽象的协议之争对于真正在做事的人没有意义。下面两个是 2026 年我从生产团队听到的最高频抱怨，恰好暴露了 Agent 互操作协议的真问题。

痛点一：MCP server 治理失控。 一家中型 SaaS 公司年初部署了 230 多个内部 MCP server，覆盖 Jira、Salesforce、内部数据仓、CI/CD。半年后做安全审计，发现至少 18 个 server 没有做参数白名单，3 个 server 默认权限是 admin，有 1 个 server 因为开发者复制粘贴示例代码，把生产数据库 URI 直接写在了 metadata 里。MCP 协议本身完全没规定治理——它只管「怎么调」，不管「谁可以调、调了之后怎么审计」。结果就是企业被迫自己造轮子：API gateway、policy engine、audit log 全要自建。这恰好是 AGNTCY 想插入的位置，但 AGNTCY 的方案太重，大多数公司最后选了在 MCP 前加一层 LiteLLM/Pomerium 风格的 proxy。

痛点二：跨厂商 Agent 协作的责任真空。 一家金融客户同时跑 Claude（合规分析）和 Gemini（数据可视化）两套 Agent。需求很简单：合规 Agent 跑完之后，把结果交给可视化 Agent 出图。理论上 A2A 就是为这个设计的。实际部署时：合规 Agent 调用失败，A2A 的 task 状态卡在 working，可视化 Agent 不知道该重试还是放弃；审计日志分裂在 Anthropic 和 Google 两套系统里，合规团队拉不出端到端 trace；OAuth token 在 Agent 间转手时，没人能解释这个 token 在 A2A 协议下的合法 audience 应该是谁。这不是协议技术问题，是责任划分问题——A2A 假设了协作双方有共同的信任根，但跨厂商场景下根本没有。 最后这家客户的解决方案是把两个 Agent 都包进自己的 orchestrator，对外只暴露 MCP，A2A 直接绕开。

这两个痛点指向同一个结论：协议解决的问题是表层的「能不能调通」，真正难的是「调通之后谁负责」。MCP 因为只解决表层，反而活得最好；A2A 想解决深层但拿不到执行权；AGNTCY 想从治理角度打包，但企业不会把整个 Agent 栈托付给一个还没满两岁的开源项目。

反驳与回应：「协议之争是伪问题，最终云厂商会赢」

每次写到这里都会有人留言：「你们这些讨论都是噪音，最终 AWS、Azure、GCP 三家会自己定标准，开发者用谁的云就用谁的协议，开源协议都会被边缘化。」

这个判断在云原生时代成立，在 Agent 时代不成立，原因有三。

第一，集成成本的结构变了。 云原生时代的核心成本是「跑起来」，所以谁的 IaaS 便宜、谁的托管服务全谁就赢。Agent 时代的核心成本是「连起来」——一个 Agent 要连 50 个工具、20 个数据源、5 个其他 Agent。这个时候开发者最痛恨的就是每家云一套接口。MCP 之所以在 12 个月内吃掉所有平台，不是因为技术多优秀，是因为开发者用脚投票：我不会为了 GCP 的 0.5% 折扣再写一遍 N 个集成。

第二，云厂商自己已经放弃了协议层独占。 Google 把 A2A 捐给 Linux Foundation 不是大方，是认输——Vertex AI 团队心里清楚，如果 A2A 不开源，根本没人理。微软在 Build 2025 直接宣布 Copilot Studio 原生支持 MCP，AWS Bedrock 在 2025 Q4 跟进。当三家云都不敢私有化协议层时，协议之争就不再是云厂商之间的事。

第三，控制点上移了。 即使云厂商不在协议层赢，他们仍然可以在 Agent 平台层赢——但那是另一场战争。在协议层，真正的赢家是把规模做起来的开源项目，因为开发者只会接受一套接口。

回到原问题：协议之争不是伪问题，它决定了未来五年开发者把 Agent 接到谁的生态里。云厂商可以输掉协议层，但开源协议绝不可能被云厂商边缘化——逻辑反过来才对。

FAQ

Q1：作为开发者，2026 年新做 Agent 项目应该选哪个协议？

默认 MCP。除非你明确在做对等 Agent 协商（比如多 Agent 拍卖、多 Agent 谈判），否则不要碰 A2A——你绝大多数需求用 MCP 加 sub-agent 模式就能搞定。AGNTCY 现阶段只在你公司本来就用 Cisco/Outshift 全家桶时考虑。

Q2：MCP 的安全问题这么多，为什么大家还在用？

因为别的更糟。MCP 至少有 OAuth 2.1 + resource indicators 的标准化授权流程（2025 年 6 月加进规范），有官方的 prompt injection 防护指南。A2A 的安全模型在跨厂商场景下基本是空白，AGNTCY 的方案还在草案阶段。MCP 不是最安全，是「被打过最多次所以补丁最全」。

Q3：Anthropic 会不会哪天闭源 MCP 拿走控制权？

技术上做不到。MCP 规范在 GitHub 上以 MIT 协议发布，OpenAI、Microsoft、Google 都已经有自己的 fork 和扩展。Anthropic 现在的角色更像是 W3C——主要靠声誉而不是控制权来推进规范。如果 Anthropic 试图私有化，社区当天就能 fork 一个 OpenMCP。

Q4：A2A 还有没有未来？

有，但不是作为「Agent 通信协议」的未来。A2A 真正可能存活下来的是它的 Agent Card 设计——一个标准化的能力声明格式。如果 A2A 团队能放下面子，把 Agent Card 单独标准化、跟 MCP tool schema 对齐，它能作为「Agent 时代的 robots.txt」活下去。

Q5：AGNTCY 会失败吗？

不会失败，但不会是它现在想成为的样子。AGNTCY 最可能的归宿是变成企业合规层的「打包品牌」——给采购部门一个可勾选的标准，给 CISO 一份可签字的报告，但开发者实际上还是在用 MCP。这不是失败，这是一个 B2B 项目最体面的存活方式。