MCP × A2A：智能体时代为什么需要开放协议

结论

一家企业接入 5 个数据源、10 个智能体框架，如果每一对连接都要单独开发，需要的集成数量是 5×10=50。这是过去两年多数企业智能体项目卡住的真实原因：不是模型不够聪明,是连接方式太昂贵。2024 年底到 2025 年上半年，Anthropic 与 Google 先后发布 MCP 与 A2A 两个开放协议，把这道乘法题改写成了加法题。汉兴的判断是：拒绝开放协议、自建专有连接层的企业，正在为自己搭建下一轮系统孤岛，代价会在两三年后才显现。

发生了什么

2024 年 11 月 25 日，Anthropic 发布《Introducing the Model Context Protocol》，提出 MCP——一套用于连接 AI 助手与数据所在系统的新标准。文章描述的问题很具体：每一个新的数据源都需要一次定制开发，这让真正互联的系统难以规模化。MCP 的解法是用一套通用协议替代碎片化的定制集成——开发者可以把数据通过 MCP 服务器暴露出来，也可以构建连接这些服务器的 AI 应用（MCP 客户端）。发布当天，Block 与 Apollo 已经在内部系统中集成 MCP；Zed、Replit、Codeium、Sourcegraph 等开发工具公司同步宣布支持；协议附带了 Google Drive、Slack、GitHub、Git、Postgres、Puppeteer 等预构建服务器。Block 的首席技术官在文章中评论：像 MCP 这样的开放技术，是把 AI 连接到真实世界应用的桥梁。

MCP 解决的是 agent 与工具、数据之间的连接问题，但没有回答另一个问题：当一家企业里同时存在多个不同厂商、不同框架构建的 agent，它们要怎么互相协作。2025 年 4 月 9 日，Google 发布《Announcing the Agent2Agent Protocol (A2A)》，提出的正是这一层。A2A 被定义为一套开放协议，为 agent 之间的协作提供标准方式，不论底层框架或供应商是谁。文章明确了 A2A 与 MCP 的分工：A2A 是对 MCP 的补充——MCP 负责给 agent 提供有用的工具与上下文，A2A 负责让 agent 与 agent 之间协作。协议设计遵循五条原则：拥抱智能体的自主协作能力，而不是把 agent 局限成一个"工具"；构建在 HTTP、SSE、JSON-RPC 这些已有标准之上，便于集成；默认安全，提供企业级的身份认证与授权，对齐 OpenAPI 的认证方案；支持长时间运行的任务，从几秒钟的快速请求到可能耗时数小时甚至数天的深度研究；模态无关，支持音频、视频等多种交互形式。这套协议从发布起就有超过 50 家技术合作伙伴的支持与贡献，包括 Atlassian、MongoDB、Salesforce、ServiceNow 这类软件厂商，也包括埃森哲、德勤、麦肯锡、普华永道这类咨询公司。

两个协议的发布相隔不到五个月，出自两家在模型层直接竞争的公司,却在架构层达成了互补而不是对抗的关系——这在企业软件的开放协议史上并不常见。

为什么这对企业重要

企业过去十年在系统集成上交过的学费，本质上都是同一道算式：M 个内部系统乘以 N 个外部服务，每一对连接单独开发、单独维护。ERP 连 CRM 是一次开发，CRM 连财务系统又是一次，换一个供应商，之前的开发投入基本作废。企业智能体如果延续这条老路——每接入一个新的 agent 框架就重新开发一次连接层——集成成本会随 agent 数量和数据源数量同步增长，而且是乘法增长,不是加法增长。

MCP 把"agent 连工具和数据"这一层做成了通用协议,A2A 把"agent 连 agent"这一层也做成了通用协议。两层协议叠加起来的效果，是把集成成本从乘法变成加法——这正是十年前 SOA 和后来的 API 经济想解决却没能彻底解决的问题，如今在智能体这一轮技术周期里，由两家头部实验室共同把标准定了下来。对企业而言，选择是否采用开放协议，不只是一个技术选型问题，而是决定了未来三到五年内换供应商、换框架、接入新伙伴的成本是线性的还是指数的。

汉兴的判断

开放协议避免企业进入新一轮系统孤岛。选择自建专有连接层而不是采用 MCP 和 A2A，短期看起来更可控，长期看是在为自己的集成成本埋雷。

这是一个可以被反对的判断。反对的版本是：专有协议能提供更强的性能优化和更严格的安全边界，因为厂商可以针对自己的技术栈做深度定制，而开放协议为了兼容多方，往往在性能和安全颗粒度上做了妥协。这个反对有一定道理,我们承认在单一供应商、单一技术栈的封闭场景里，专有连接层确实可能跑得更快。但企业智能体几乎不可能长期停留在单一供应商场景——业务在变、模型在换代、组织在并购重组，专有连接层每一次这样的变化都要重新开发，而开放协议只需要新的一方接入协议本身。

我们把两个协议的分工画成一张原创框架，用于向客户解释为什么两个协议要一起看，而不是二选一。

```企业智能体的两层连接协议 [上层] A2A —— Agent ↔ Agent 解决：不同厂商、不同框架的智能体如何协作覆盖：任务委派、长任务跟踪、跨组织协作 [下层] MCP —— Agent ↔ 工具 / 数据解决：智能体如何获取企业内部的数据与能力覆盖：数据源接入、工具调用、上下文供给```

配套的原创指标，我们称为集成成本函数,用于向客户量化"要不要用开放协议"这个决策：

```专有连接层的集成成本 ≈ M × N（M 个内部系统 × N 个外部服务/框架）开放协议下的集成成本 ≈ M + N（每一方只需要对接协议本身一次）```

M 和 N 越大，两条曲线之间的差距越大。这不是一个精确的成本模型，是一个用于判断方向的简化公式：企业接入的系统和 agent 越多，选择开放协议节省的边际成本越高。

一个中国企业的情境（示例推演）

以下情境用于说明框架的用法，不对应任何真实客户，数据为示例推演。

一家华南消费品企业同时使用三套系统支持客服、供应链和财务分析,每套系统背后的智能体来自不同厂商。第一版做法是为每一对系统间的数据交换单独写接口，三个部门各自维护自己的连接代码，供应链团队想调用客服系统里的客户投诉数据时，发现接口格式和权限模型完全不兼容，只能重新开发一次。半年后，接口数量涨到十几个，没人能完整说清楚哪个接口还在被用、哪个已经因为上游系统升级而失效。

如果从一开始按两层协议规划：数据侧统一用 MCP 服务器暴露客服、供应链、财务系统的数据与工具，智能体侧的跨部门协作请求走 A2A，新增一个系统只需要为它写一次 MCP 服务器，新增一个智能体只需要让它支持 A2A,不需要重新打通所有已有连接。这不是换了更贵的技术，是把连接方式从"每对系统单独握手"换成了"每一方对协议本身握手"。

反方观点与适用边界

这个判断在两类情况下需要谨慎。

第一类，协议本身仍在快速演进。 A2A 发布于 2025 年 4 月，MCP 发布于 2024 年 11 月，两者都还年轻，规范细节、安全模型和生态成熟度都在持续变化。企业如果现在就把核心业务流程完全绑定在某个协议版本上，需要承担协议本身升级带来的适配成本，这和绑定专有协议的风险性质不同，但同样需要预算和人力去跟踪。

第二类,单一供应商、边界清晰的小规模场景。 如果企业智能体的使用范围明确限定在一个供应商的产品矩阵内，短期内没有跨厂商协作或频繁更换框架的计划，采用开放协议带来的灵活性可能用不上,反而多付出了协议适配的初始成本。这类场景下，先用供应商自带的连接方式起步、把开放协议留给下一阶段扩展时再引入，是更合理的顺序。

企业现在应该做什么

给 CEO：把"是否采用开放协议"写进下一轮智能体项目的技术选型评审清单，而不是留给技术团队私下决定。 这是一个会影响未来三到五年供应商谈判筹码的决策，不应该只由实施细节推动。

给 CAIO：盘点现有系统里有多少条是专有定制连接，评估把它们迁移到 MCP/A2A 的优先级。 优先迁移那些连接数量多、供应商更换概率高的系统，这些地方开放协议的边际收益最大。

给 FDE：新项目的技术方案里，默认把 MCP 作为数据接入层、A2A 作为跨智能体协作层写进架构图,除非有明确理由不这样做。 这能保证交付的系统不会在两三年后成为下一个需要推倒重来的孤岛。

证据、来源与公开边界

• Anthropic，《Introducing the Model Context Protocol》，2024 年 11 月 25 日。https://www.anthropic.com/news/model-context-protocol
• Google Developers Blog，《Announcing the Agent2Agent Protocol (A2A)》，2025 年 4 月 9 日。https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

本文引用的协议描述、合作伙伴名单与设计原则均来自上述两份官方文件原文。文中的中国企业情境为示例推演，不对应任何真实客户。两层连接协议图与集成成本函数为汉兴原创，未经第三方验证。

元信息

栏目 Research　作者 汉兴 AGI 实验室　版本 v1.0　成稿 2026 年 8 月 12 日