当前位置：首页 > ai >正文

Google Agent space时代，浅谈Agent2Agent (A2A) 协议和挑战！

ai 2025/5/13 23:41:38

如果说去年Google Cloud大会大家还在数“AI”这个词被提了多少次，那么今年，绝对是“Agent”的主场！开发者主题演讲几乎被它“刷屏”，展区的许多 Demo 也都号称是 Agent 应用。

但我得诚实地说，大会现场关于 Agents 的 Demo普遍有点… 低于预期。许多被冠以“Agent”之名的展示，在我看来更像是精心编排的 LLM 工作流（Workflow）或者实用小脚本，却不如国内一些自媒体做的扣子空间工作流。虽然说它们确实有用，也很酷，但似乎离我们想象中那种具备自主决策、能与其他 Agents 复杂交互的“完全体”Agent，还有相当远的距离。现场的 Demo 并没有让我看到 AI 近在眼前。

不过，在这些略显朴实的 Demo 背后，Google 在基础设施层面的一个重磅发布引起了我极大的兴趣，我认为它才是真正可能推动 Agent 时代到来的关键——那就是 Agent2Agent (A2A) 协议。

一、Google 重磅发布：Agent2Agent (A2A) 协议是什么？

在本次大会的早期Keynote中，A2A 协议就已经被提及，并在开发者主题演讲中得到了进一步阐述。那么，这个 A2A 协议到底是什么？

简单来说，A2A 协议是 Google 提出的一个让 AI Agent 之间能够互相通信、协作、甚至进行协商的新协议。

它不是为了取代现有的 Agent 与工具（Tool）之间的协议（比如大家熟悉的 MCP，Model-Client-Protocol）。MCP 解决的是 Agent 如何调用外部工具或服务来扩展自身能力的问题。而 A2A 协议要解决的，是 Agent 如何与另一个 Agent 进行交互的问题。

核心目标：

Agent 发现： Agents 如何找到能帮助自己完成特定任务的“同行”Agent。
Agent 协作： Agents 之间如何协同工作，共同解决复杂问题。
Agent 协商： Agents 如何就任务分派、数据格式、输出要求等进行沟通和约定。

按照 Google 官方的介绍，A2A 协议构建在标准的网络技术之上，例如 HTTP、SSE (Server-Sent Events)、JSON-RPC 等，这有助于它的互操作性。并且，Google 特别强调了 A2A 协议在设计之初就考虑了安全性（不像 MCP 这个名字里没有 S😂，虽然这只是个玩笑，但背后是对安全性的重视）。

Google 也提供了相关的资源供开发者学习：包括官方博客文章、专门网站、GitHub 仓库以及示例 Agent。

二、A2A 协议的背后愿景：一个“Agent应用商店”的时代？

在我与一些行业内的朋友交流时，以及过去一年多关于 Agent 框架的讨论中，一个“公开的秘密”或者说愿景一直在被提及：未来的 AI Agent 世界可能会像今天的智能手机应用商店一样。

在这个“Agent 应用商店”里，你的主 Agent 可以根据任务需求，去“发现”并调用其他专业的 Agents 来完成子任务。比如，一个旅行规划 Agent 需要订机票，它不会自己从头写订票逻辑，而是去调用一个“机票预订 Agent”；需要推荐餐厅，就调用一个“餐厅推荐 Agent”。主 Agent 可能甚至需要为调用的服务付费（每次调用支付少量金额）。

这种“Agent 之间按需调用、付费服务”的模式，听起来是不是很像微服务架构，但又多了一层基于 AI 能力的自主性和协作性，就像是我们今天常见的额，做养生赛道视频的Agents。

而 Google 推出的 A2A 协议，正是支持这种愿景的底层基础设施！

为了实现 Agent 发现，Google 提出了 Agent Card 的概念。每个 Agent 都可以发布一个 Agent Card，用标准化的格式描述自己的能力、接口、使用方式等信息，方便其他 Agents“阅读”和理解。Agent 可以通过注册中心（Registry）或者直接通过私有 API等方式来发现和查找其他 Agent，开发这种Card，只要有人调用，也是可以赚大钱的哦。

我认为，“Agent 应用商店”的愿景和 A2A 协议提供的 Agent 发现与协作能力，是这个协议最令人兴奋的部分。它为构建更复杂、更强大、可组合的 Agent 系统奠定了基础。

三、深入 A2A：核心概念与工作流程

想了解 A2A 协议的技术细节，Google 的 GitHub 仓库是一个不错的起点。仓库中的概念概览（Conceptual Overview）部分详细介绍了 A2A 的一些关键概念和典型工作流程。

一些核心概念包括：

Agent Card： Agent 的能力描述，方便其他 Agent 发现和理解。
A2A Server： 托管 Agents，并处理 A2A 通信请求的服务端。
Client： 发起 A2A 请求的 Agent 或应用。
Task： Client 发送给另一个 Agent 要完成的具体任务。
Messages： Agents 之间在沟通任务和进展时传递的信息。
Artifacts： Agent 完成任务后返回的结果或输出（这是协议中的一个重要概念，代表最终交付物）。

一个典型的 A2A 工作流程可能是这样的：

一个 Client Agent 接收到用户请求，需要完成一个复杂任务。
Client Agent 根据任务需求，向一个 Agent 注册中心查询（或通过其他发现机制），找到能完成部分子任务的相关 Agents。
Client Agent 选择一个或多个合适的 Agent，并向它们发送包含具体需求的 Task 消息。
接收 Task 的 Agent 处理任务，过程中可能与其他 Agent 交互，并通过 Messages 更新状态。
任务完成后，接收 Task 的 Agent 将结果封装成 Artifacts 返回给 Client Agent。
Client Agent 接收 Artifacts，进行整合，最终完成用户请求。

值得一提的是，A2A 协议的设计也考虑到了跨语言的互操作性。这意味着你可以用 JavaScript 编写一个主 Agent，然后调用一个 Python 编写的 Agent 来执行特定的数据处理任务，再调用一个 Java 编写的 Agent 去访问企业内部系统。Google 在示例代码中也展示了如何结合他们的 Agent Development Kit (ADK)、以及 LangChain、CrewAI、GenKit 等流行 Agent 框架来使用 A2A。

四、隐藏的“雷”？A2A 协议的合作伙伴与一个关键的问题

Google 在大会上展示了超过 50 家支持 A2A 协议的技术合作伙伴，其中包括 Cohere (模型公司)、LangChain (Agent 框架公司) 以及许多咨询和服务公司。这表明 A2A 协议已经获得了一定程度的行业关注和支持。

这个合作伙伴列表看起来很强大，似乎预示着 A2A 协议有潜力成为 Agent 交互的标准。然而，仔细观察这个列表，我发现了一个非常关键的缺失——Anthropic！

要知道，Anthropic 是当前市场上与 Google、OpenAI 并列的顶级大模型提供商，并且在 Agent 和 AI 方面有深入研究和独特视角。如果 Anthropic 不加入 A2A 协议生态，那可能会带来一个潜在的巨大问题：

Agent 协议的碎片化。

历史上，技术领域不乏协议之战。如果 Anthropic 选择自行扩展现有的 MCP 协议，或者推出自己的 Agent 间通信协议，那么开发者可能将面临选择困难：是基于 Google 的 A2A 构建，还是基于 Anthropic 的协议？这最终可能导致 Agent 生态被割裂成不同的阵营，不利于整个 Agent 技术的普及和发展。

虽然 Google 在 gRPC 等协议上有着不错的开放和推广记录，甚至会将协议贡献给第三方基金会，但 A2A 协议的未来，尤其是能否成为一个广泛接受的行业标准，在Anthropic 明确表态之前，仍存在不确定性。

除了 Anthropic，列表中暂时也还没看到 LlamaIndex、Pydantic AI 等其他一些知名的 Agent 框架。虽然这些不像 Anthropic 那样具有决定性影响，但更广泛的框架支持对于协议的普及也非常重要。

我非常希望看到 Anthropic 能尽快加入 A2A 协议的阵营，或者 Google 能与其达成某种互通的共识，避免一场潜在的“Agent 协议标准战”。

结论：A2A 是未来 Agent 协作的关键拼图，但普及之路仍需努力

从 Google Cloud Next 2025 大会现场的观察来看，“Agent”无疑是下一个 AI 的重要发展方向。虽然目前的 Agent 应用 Demo 可能还处于早期阶段，但 Google 推出的 Agent2Agent (A2A) 协议，无疑是为实现更宏大的 Agent 协作、互联互通的未来，打下了一个至关重要的基础。Agent 发现、Agent Card、Agent 间通信这些概念，正在一步步将“Agent 应用商店”的愿景变为可能。