A2A协议推行一年150家企业支持但实际应用不足

近期，AI Agent 协作领域呈现出两种清晰的技术演进路径，引发了业内的广泛关注与讨论。

一方是 MCP 协议，它核心聚焦于解决 Agent 如何调用外部工具的问题，可以形象地理解为为 Agent 安装“手”。该协议发展势头迅猛，社区已贡献超过 18000 项服务，其 SDK 月下载量达到千万级别，已成为 Agent 连接工具的事实标准。

另一方则是 A2A 协议，全称为 Agent-to-Agent Protocol，由 Google 于去年 4 月发布。其目标更为宏大：旨在解决“不同厂商、不同系统的 AI Agent 如何实现互操作与沟通”这一核心挑战。短短一年内，它已获得超过 150 家组织的支持，在 GitHub 上收获超 22000 个 Star，并获得了 Google Cloud、Microsoft Azure 和 AWS 的原生集成支持，发展态势强劲。

然而，一个值得深思的现象随之浮现。观察今年备受瞩目的几款“多 Agent 团队”产品，例如 Claude Code、Cursor 和 Devin，会发现它们内部的 Agent 间通信，无一例外地采用了私有协议，而非 A2A。

这背后的原因是什么？是 A2A 协议“曲高和寡”，还是我们对它的定位与适用场景需要重新审视？

深入解析 A2A 协议

简而言之，A2A 旨在解决一个典型的“巴别塔”困境：当来自不同公司、不同技术栈的 AI Agent 需要协同工作时，它们缺乏一套通用的交互语言。

设想一个典型的企业场景：您的公司使用 Salesforce 的销售 Agent 管理客户关系，而您的供应商则使用 SAP 的库存 Agent 追踪货物。当销售 Agent 接到一笔大额订单时，它需要直接与库存 Agent 沟通，以确认备货周期与发货时间。问题在于，Salesforce 和 SAP 是两个独立的生态系统，它们的 Agent 彼此“互不认识”，无法直接对话。

A2A 协议的目标，正是成为那个通用的“翻译官”与“通信枢纽”。它定义了一套标准化规范，涵盖 Agent 的发现、身份验证、任务委托、结果返回等核心流程，旨在实现跨厂商 Agent 的无缝互操作。

由此可以清晰区分它与 MCP 的分工：MCP 是纵向的，解决 Agent“如何用手”（调用工具）；A2A 是横向的，解决 Agent“如何与同事协作”（跨系统协同）。两者结合，理论上能够构建出一个完整、开放的多 Agent 协作网络。

A2A 协议一年的关键进展

回顾 A2A 过去一年的发展历程，其推进速度在标准推广领域堪称高效。

一个关键转折点发生在去年 6 月，Google 将 A2A 项目捐赠给了 Linux 基金会，使其转变为由社区共同治理的中立开放标准。这一步至关重要，它消除了“这是谷歌私有标准”的疑虑，为广泛的行业采纳奠定了信任基础。

更大的动作出现在去年 12 月。Anthropic、OpenAI 和 Block 三家公司罕见地联合，在 Linux 基金会下共同发起成立了“Agentic AI 基金会”，并将 A2A、MCP 以及 IBM 主导的 ACP 协议全部纳入其统一管理范畴。

这一举措的信号意义非凡。它表明 AI 领域的主要参与者已达成共识，决定避免潜在的“协议战争”，转而共同推动一套统一的底层互操作标准。可以说，在技术治理层面，格局已基本明朗。

今年 3 月，A2A 发布了 1.0 正式版，引入了签名 Agent Card（相当于 Agent 的加密数字身份）、企业级多租户支持、异步 HTTP 传输等关键特性，标志着协议本身在功能上已趋于成熟稳定。

从标准制定与生态建设的角度看，这样的进展确实令人印象深刻。

为何主流产品未采用 A2A？

这就引出了核心问题：既然标准备受推崇，为何那些明星产品却选择“另起炉灶”？

深入观察可以发现，Claude Code 的 16 个 Agent 并行工作，依赖的是 Git 锁机制和自定义的进程间通信；Cursor 的 Background Agents 在各自独立的 Git 工作区运行，彼此间通信需求极低；Devin 的多个子 Agent 则通过 Cognition AI 自家的私有 API 进行协调。

这并非因为这些团队不了解或抵制 A2A，原因其实更为直接：A2A 的设计目标与这些产品内部 Agent 团队的协作场景，存在根本性的定位差异。

A2A 是为“未知、异构环境下的互操作”而设计的，其核心价值在于实现跨厂商、跨系统的无缝连接。这类似于 HTTP 协议，你无需知晓远端服务器使用的是 Java 还是 Go 语言，都能成功发起请求。

反观 Claude Code 或 Cursor，其内部的所有 Agent 都运行在同一个平台、使用同一套技术框架、甚至可能调用同一个底层模型。它们对彼此了如指掌，就像一个紧密团队内的成员，协作时无需“自我介绍”和“身份认证”这类繁琐流程。在这种高度同质化、封闭可控的环境里，强行引入 A2A 的通用协议栈，无异于让一家人开会前先互相查验护照——不仅多此一举，还会引入不必要的开销与延迟。

因此，与其说 A2A“叫好不叫座”，不如说它是一把设计精良的“万能钥匙”，而目前市场上最成功的多 Agent 产品，暂时还处于使用“自家门锁”的阶段。

A2A 的真正战场：企业级与跨系统集成

那么，A2A 的用武之地究竟在哪里？答案潜藏在企业级应用和复杂的跨系统业务流程自动化之中。

目前，A2A 最落地的实践案例可能就在其发起方 Google 自身。Gemini Enterprise 中的 Agent 注册表与网关，可视为 A2A Agent Card 机制的企业级实现。它正在协助 Salesforce、SAP、ServiceNow 等合作伙伴的 Agent 之间进行任务路由与协同工作。

这才是 A2A 的主战场：企业内部跨部门、跨遗留系统的 Agent 互通；供应链上下游企业间的 Agent 协作；以及不同 SaaS 平台之间自动化流程的串联与编排。

举例而言：公司的财务审核 Agent 在处理合同时发现金额超出权限，它需要自动将任务委托给外部的法务合规 Agent 进行审查；法务 Agent 完成审查后，又将结果通知给采购系统的 Agent 以更新合同条款。这三个 Agent 很可能分别来自三家不同的软件供应商，此时，A2A 作为“通用通信语言”的价值就变得无可替代。

对于个人开发者而言，在使用 Claude Code 编写代码时，可能完全感知不到 A2A 的存在。但在企业 IT 架构师和 CIO 的技术选型清单与系统集成蓝图中，A2A 很可能已成为一个关键的评估维度。

两层基础设施：纵向与横向的协同

要理解当前格局，最清晰的视角是将其视为两层正在并行构建的基础设施：

MCP 是纵向基础设施，负责向下连接，为 Agent 赋予使用多样化工具（手）的能力。它已凭借庞大的开发者社区与丰富的工具生态，确立了事实标准的地位。

A2A 是横向基础设施，负责平行连接，为 Agent 提供发现、认证与委托其他 Agent（同事）的能力。它的企业级落地正在悄然推进，只是由于跨系统协作的复杂性天然高于工具集成，其普及与渗透速度会相对更渐进一些。

这两层协议相辅相成，共同勾勒出未来规模化、开放式多 Agent 系统最完整的底层架构蓝图。至于它何时能成为所有 AI 产品的默认配置，可能还需要一至两年的市场培育、技术验证与生态成熟过程。

但可以肯定的是，最大的不确定性已经消除。当 Anthropic、OpenAI 和 Google 能够坐在一起共同维护一套开放标准时，剩下的主要挑战便是时间与工程实践。

AI Agent 的协议战争或许已提前落幕，但协议驱动的跨系统智能协作时代，其实才刚刚拉开序幕。这场由标准引领的变革，其最终可能带来的产业影响，或许会远超我们当前的想象。