谷歌将 A2A 捐赠给 Linux 基金会，但代码实现还得靠开发者自己？！

A2A 协议是谷歌在今年 4 月份推出的一项开放标准，支持不同 AI 智能体之间的通信与协作，打破目前限制人工智能潜力的“孤岛化”问题。谷歌联合 Salesforce、Atlassian、LangChain 等共同开发了该协议，目标是为不同厂商、不同框架的智能体建立一个通用的互操作标准。目前已有超过 100 家企业支持该协议。

谷歌方面表示，A2A 项目将在 Linux 基金会中立治理模式下进行，这将确保该关键组件始终保持厂商中立、社区驱动。此举旨在通过一个强大开放的协作框架、知识产权管理机制与长期托管体系，加速 A2A 协议的开发与普及。

捐赠给基金会其实也是谷歌的“基本操作”，比如其在 2015 年将最初开发的 Kubernetes 捐赠给了 CNCF，该组织由 Linux 基金会托管，从此 Kubernetes 的基础设施都转由 CNCF 社区运营。2018 年，谷歌云向 CNCF 提供总值 900 万美元的云资源，用于支持 Kubernetes 及相关组件的持续集成、交付流水线与镜像仓库运营等。

AI 智能体技术仍处于早期阶段，但各公司正热情探索其潜力，并渴望抢占先发优势。虽然不确定这些协议能存续多长时间，但 Anthropic 的 MCP（模型上下文协议）采用速度非常快，包括谷歌、OpenAI 都已采用。同时，微软最近宣布将采用谷歌的 A2A 来满足其智能体间通信需求。

其中，MCP 规模扩张十分迅猛。根据网站 PulseMCP 统计，MCP 其已经从 2 月份的 500 台 MCP 服务器增长到如今已超过 4000 台。

MCP 标准化了大模型与外部工具、数据库和 API 的通信方式，主要解决将 M 个不同的大模型与 N 个不同的工具集成在一起的组合爆炸问题。它为大模型提供了关于外部服务能做什么以及需要什么数据的清晰上下文。MCP 提出了一个标准的客户端 – 服务器架构，供大模型厂商和工具构建者采用。

谷歌的 A2A 则运作在更高层面，实现了多个智能体之间的顺畅交互。它确保通信安全、管理交互的状态和上下文、帮助智能体之间协商任务，并方便智能体间相互发现。本质上，A2A 是协调多个专业智能体，以便它们高效行动、完成复杂任务。

A2A 定义了一种基于 HTTP 的通信模型，其中代理被视为可互操作的服务。每个代理都公开一个“代理卡（Agent Cards）”——一个机器可读的 JSON 描述符，详细说明了其身份、功能、端点和身份验证要求。

对此，有开发者认为，A2A 非常符合谷歌的战略需求。“其核心在于：通过为所有代理建立索引，并利用代理卡解构它们所能提供的服务，这一做法最终可能将代理本身解构为可直接通过服务调用的标准化工具。若谷歌成功实现此目标，从长远看，可能会削弱 MCP 的地位。从架构角度看，A2A 确实处于比 MCP 更高的层级。”

该开发者补充道，索引是谷歌的秘密武器，它决定了当一个代理请求服务时，哪些索引代理会被优先推荐。这实质上是在代理生态中引入了类似谷歌广告的竞价机制，影响巨大。然而，核心问题在于其宣称的“开放性”。 如果协议的核心是代理索引，却只有谷歌的算法或其协调器能够访问和决定排名，那么这种“开放”就名不副实，本质上是在重新实现算法广告竞价模式——价高者得。

不过，谷歌官方将 A2A 定义为 MCP 的“补充”。简单来说，MCP 将 AI 连接到工具，而 A2A 将 AI 连接到其他 AI。它们共同构成了构建智能体系统的强大模块化基础。

虽然两者有差异，但如今仍有一些开发者表示，“还是不清楚这两个主要协议将如何共存。”对此，有开发者指出，造成混淆的原因在于 A2A 可以完成 MCP 所能做的一切。“MCP 已经起飞，A2A 现在需要参与其中。A2A 能够脱颖而出的方式是，做一件 MCP 做不到的事情，并且做得非常好。如果能做到这一点，我认为它们就能很好地共存。”

MCP 的优势在于其已适配了多个实用客户端，如 Cursor、Claude。 然而，有人认为 A2A 在集成不同客户端方面可能更具优势。这主要是因为 A2A 基于 HTTP 协议，对客户端的集成要求相对较低。相比之下，MCP 的集成难度似乎更高，一个明显的例证是：同出自 Anthropic 开发的 Claude 桌面端，在 MCP 发布四个月后仍未完全支持其全部功能。这或许进一步佐证了 MCP 集成的复杂性，也表明 A2A 可能是一个更容易集成的方案。

另外，值得注意的是最初由 IBM 提出的 ACP（代理通信协议）。它采用了完全不同的方法：完全基于本地优先的代理协调，不需要云；不使用 HTTP 和基于 Web 的发现，而是允许智能体在共享运行时内直接查找并相互通信。它非常适合以下情况：

• 带宽有限或需要低延迟（例如机器人或设备助手）；

• 注重隐私，想让一切都保持离线状态；

• 部署在与互联网隔绝的环境（如工厂车间、边缘节点）。

ACP 并非试图与 A2A 竞争，它只是填补了不同的市场空白。但在某些情况下，尤其是在严格控制的环境中，ACP 可能会完全取代 A2A，因为它跳过了 Web 原生协议的开销，只需在本地完成工作。

采用协议应当是因为我们需要它们，而非仅为采用而采用。

近期，Y Combinator 的普通合伙人 Pete Koomen 指出，虽然他们构建了许多 AI 智能体来帮助运营公司，但这些智能体都不依赖 MCP 或 A2A。

Andreessen Horowitz 的合伙人 Yoko Li 则认为，AI 模型前景光明，最终将通过代替我们做很多事情来重塑行业。但就目前而言，这个技术尚未完全成熟。大模型会遗忘信息，对可用的工具及其使用方法感到困惑，这就是为什么我们需要“程序层（procedure layers）”来帮助它们达到目标。像 MCP 和 A2A 这样的协议，目前就扮演着“手把手指导（hand-holding）”工具的关键角色，协助智能体及其背后的大模型处理它们各自无法独立完成的任务。

简单的智能体工作流可能不需要它们，但复杂的工作流，尤其是涉及多个 AI 智能体的工作流则需要。

谷歌云的应用总监兼 A2A 的共同创造者 Miku Jha 强调，企业只有在相信代理技术像现有企业工具一样可靠时，才会采用智能体驱动的工作流。尽管生成式 AI 在很多方面令人印象深刻，但可靠性并不是它的强项之一。这就是 A2A 的初衷。

另外，智能体应用的 ROI 衡量目前是较为困难的。

企业通常通过两种主要方式利用代理：一是对现有工作流进行现代化改造，二是为产品启用新的用户交互方式。一旦确定了使用方式，企业就必须评估智能体生成的输出内容是否符合其质量标准，以及是否能转化为切实的成本节约或收入增长。

Jha 强调，企业常常犯这样的错误：在探索代理技术时，先选择特定的工具，比如 MCP 或 A2A，而不是先清晰地定义用例和成功标准。她建议反过来做：企业在对智能体技术进行大量投资之前，应该先确定自己的用例，以及从业务价值意义上的成功标准。

然而，针对智能体驱动系统的监控和衡量机制仍不完善。即使是基本的可靠性概念，如衡量 AI 系统提供的正常运行时间达到 “几个九”，或者定义服务级别协议（SLAs），都仍处于早期阶段，而评估生成式 AI 的输出则更为棘手。在上一届 SRECon Americas 会议上，当听众得知微软正在使用 NPS（净推荐值）来衡量 AI 模型的性能时，都感到十分震惊。

MCP 和 A2A 两种协议在安全性和复杂性方面也带来了新的担忧。MCP 的开放工具调用必须经过仔细的沙盒处理，A2A 在智能体之间开放了许多端点，因此身份验证（OAuth、API 密钥等）和授权（RBAC、令牌）至关重要。

因此，在实际应用中，开发者需要考虑的真正问题是：

• 如何在自己的系统中结合这些框架？

• 下一个智能体能否要使用 MCP 链接工具，然后使用 A2A 跨服务进行协作？

• 自己的大模型是否已为这个新的、更加开放的智能体生态系统做好准备？

Li 还指出，在一些场景中，传统 ROI 衡量可能失效或根本不适用。她提到 AI 伴侣是一个巨大的市场，并且消费者可能处于一种“他们以前不知道自己需要 AI 伴侣，但现在却离不开它”的境地。在这种情况下，如何衡量 ROI 呢？

这些协议将帮助智能体达到更高的可靠性，这可能给公司项目带来有价值的改变。但目前，只有约 5% 的生成式 AI 项目转化为盈利产品，可见前路依然漫长。