🔶 Google 将 A2A 交由 Agentic AI Foundation 托管

不过，并非所有人都对这一举动感到高兴。

Google 已将 Agent2Agent Protocol（A2A）贡献给 Agentic AI Foundation（AAIF）。对于不了解它的人来说，A2A 是 AI Agent 互操作性领域正在涌现的标准之一，另一个是 Model Context Protocol（MCP）。

A2A 定义了一种通用方式，使 AI Agent 能够相互发现、委派工作，并跨越框架和厂商边界交换任务。Google 于 2025 年 4 月推出该协议，随后又将其捐赠给 Linux Foundation；AAIF 表示，该项目目前已获得超过 150 家组织支持，并在供应链、金融服务和移动平台等生产环境中部署。对于一个仅有一年多历史的协议而言，这相当令人印象深刻。

据 AAIF 介绍，A2A 的目标是让开发者和工程师无需经历重重困难，就能部署多 Agent 系统。在 A2A 出现之前，他们不得不应对 Agent 之间反复无法通信的问题。“基于不同框架构建的 Agent，无法在不为每种配对专门编写定制集成代码的情况下相互移交工作。每增加一种新的厂商合作关系，都需要从头重复同样的集成工作。成本不在 Agent 本身，而在它们之间的集成。”为每个 Agent 构建专用连接，既麻烦又昂贵。

A2A 正是为解决这一问题而构建的。它通过定义“Agent 如何跨越框架和厂商边界进行通信”来实现这一目标。一个 Agent 会发布一张 Agent 卡，其中包含对其能力以及访问方式的结构化描述。其他 Agent 读取该卡片，发现其能力，并在无需人工居中协调交接的情况下委派任务。整个交换过程具有结构化、可观测且框架无关的特性。

此外，AAIF 表示，今年 3 月发布的 A2A 1.0 版本引入了多租户、版本协商、多协议绑定以及签名 Agent 卡，后者旨在支持加密身份验证。

这一切听起来都很不错，但让 Agent 更容易彼此传递工作，也会带来新的安全、身份与访问管理（IAM）问题。Mahesh Shanmugasundaram 是 Seekr 的首席 AI 解决方案架构师，他认为 A2A 存在一种风险：未经验证的主张可能沿着 Agent 链条传播，并逐渐获得表面上的权威性。

当然，Shanmugasundaram 表示：“像 A2A 这样的开放协议，是让 Agentic AI 更具互操作性和灵活性的重要一步。但事实是，互操作性只会扩大原本就存在的信任鸿沟。协议将管道标准化，而组织决定通过管道传递什么。”

他警告称，A2A 可能会制造一场“AI 传话游戏”：每个参与者都会放大前一个 Agent 的置信度。因此，链条开端处的一个小型幻觉，可能在经过数个步骤后演变成一个看似极具权威性的答案。嗯……AI 非常自信地给出完全错误的答案。我们以前见过这种情况，不是吗？

他说：“在 A2A 链条中，每个 Agent 都将上一个 Agent 的输出视为 100% 可信的输入，而不是一个需要验证的主张。一旦这种假设被内置，级联故障在结构上就会比团队预期的更加严重。”Shanmugasundaram 表示：“因此，基于证据的评估和可解释输出不能只是事后考虑的事项。相反，它需要成为 Agent 之间交换的默认单元。整个 A2A 系统的成功都取决于此。”

尽管如此，A2A 已经投入生产使用。例如，华为已将 A2A 标准化，用于连接其操作系统级 AI 助手 Celia，以及 HarmonyOS 开发者平台上的应用内 Agent；腾讯微信则使用该协议与华为及其他 Android OEM 厂商的助手进行集成。

A2A 并不只是移动端的玩法。正如你所预期，Google Cloud 支持通过其云服务和 Kubernetes 产品开发及部署 A2A Agent。Microsoft Azure AI Foundry 允许 Agent 暴露 A2A 端点，并通过标准发现机制查找外部 Agent。此外，AWS Bedrock AgentCore 可以托管和运行 A2A 服务器，使 Agent 能够跨不同框架和云环境协作。最后，Google Cloud 和 PayPal 正通过 Agent Payments Protocol（AP2） 将 A2A 扩展至 Agentic Commerce。

那么，接下来会怎样？AAIF 对 A2A 的托管，可能有助于整合日益碎片化的 Agent 互操作性格局。该基金会表示，A2A 的目标是实现框架和厂商中立的通信，并指出 IBM 的 Agent Communication Protocol 已于 2025 年 8 月并入 A2A。到目前为止，一切顺利。

不过，Shanmugasundaram 的批评凸显了互操作性与可信赖性之间的区别：标准化的传输和发现机制，并不能证明一个 Agent 的输出是准确的、来源可靠的，或适合用于触发其后续行动。随着组织开始采用 Agent 对 Agent 工作流，它们需要决定：证据、置信度元数据、可追溯性和验证究竟只是可选的应用功能，还是每一次交接都必须具备的属性。就我而言，我认为这些都应当是强制性的。

But not everyone is happy about this move.

Google has contributed the Agent2Agent Protocol (A2A) to the Agentic AI Foundation (AAIF). For those who don’t know it, it is one of the emerging standards for AI-agent interoperability along with the Model Context Protocol (MCP).

A2A defines a common way for AI agents to discover one another, delegate work, and exchange tasks across framework and vendor boundaries. Google launched the protocol in April 2025, and later donated it to the Linux Foundation; AAIF said the project now has backing from more than 150 organizations and is deployed in production settings spanning supply chains, financial services, and mobile platforms. Pretty impressive for a protocol that’s just over a year old.

The purpose of A2A, according to the AAIF, is to enable developers and engineers to deploy multi-agent systems without blood, sweat, and tears. Before A2A came along, they had to deal with agents repeatedly not being able to talk with each other. “Agents built on different frameworks couldn’t hand off work to each other without custom integration code written specifically for each pairing. Every new vendor relationship required the same integration work from scratch. The cost wasn’t in the agents themselves but in the integrations between them.” Building bespoke links for each agent is both annoying and expensive.

A2A was built to solve that problem. It does this by defining “how agents communicate across framework and vendor boundaries. An agent publishes an agent card containing a structured description of what it can do and how to reach it. Other agents read that card, discover capabilities, and delegate tasks without a human brokering the handoff. The exchange is structured, observable, and framework agnostic.”

In addition, AAIF said A2A version 1.0, released in March, introduced multitenancy, version negotiation, multi-protocol bindings, and signed agent cards intended to support cryptographic identity verification.

That all sounds pretty spiffy, but making it easier for agents to pass work among themselves creates its own security and identity and access (IAM) problems. Mahesh Shanmugasundaram, Seekr‘s lead AI solutions architect, believes A2A brings with it the risk that unverified claims will travel and gain apparent authority through an agent chain.

Sure, Shanmugasundaram said, “Open protocols like A2A are an important step toward making agentic AI more interoperable and flexible. But the truth is, interoperability only expands that already existing trust gap. While the protocol standardizes the pipe, organizations decide what travels through it.”

He warned that A2A could create an “AI game of telephone,” in which each participant amplifies the previous agent’s confidence. A small hallucination at the beginning of a chain could therefore emerge several steps later as a highly authoritative-looking answer. Hmmm… AI giving very confident and very wrong answers. We’ve seen this before, haven’t we?

“In an A2A chain, each agent treats the prior agent’s output as 100% trusted input vs. a claim to be verified,” he said. “Once that assumption has been baked in, cascading failure becomes structurally worse than teams expect. Therefore, evidence-based evaluations and explainable output cannot be an afterthought,” Shanmugasundaram said. “Instead, it needs to be the default unit of exchange between agents. The success of the whole A2A system depends on it.”

Be that as it may, A2A is already being used in production. For example, Huawei has standardized A2A to link Celia, its OS-level AI assistant, and in-app agents across the HarmonyOS developer platform, while Tencent’s WeChat uses it to integrate with Huawei and other Android OEM assistants.

A2A isn’t just a mobile play. Google Cloud, as you’d expect, supports developing and deploying A2A agents through its cloud and Kubernetes offering. Microsoft Azure AI Foundry lets agents expose A2A endpoints and find external agents through standard discovery. In addition, AWS Bedrock AgentCore can host and operate A2A servers, so agents can collaborate across different frameworks and clouds. Finally, Google Cloud and PayPal are extending A2A into agentic commerce through the Agent Payments Protocol (AP2).

So, where do we go from here? AAIF’s hosting of A2A could help consolidate an increasingly fragmented agent interoperability landscape. The foundation said A2A’s goal is framework- and vendor-neutral communication, and noted that IBM’s Agent Communication Protocol merged into A2A in August 2025. So far, so good.

However, Shanmugasundaram’s critique underscores a distinction between interoperability and trustworthiness: standardized transport and discovery mechanisms do not establish that an agent’s output is accurate, well-sourced, or appropriate for the downstream action it may trigger. As organizations embrace agent-to-agent workflows, they will need to decide whether evidence, confidence metadata, traceability, and verification are merely optional application features, or mandatory properties of every handoff. Me? I see these as mandatory.