近期，谷歌高调发布了名为 A2A（Agent-to-Agent）的开放协议，旨在为多 Agent 系统（Multi-Agent Systems）的通信制定规范。它与Anthropic 发布的模型上下文协议（MCP）有什么不同？一时间，业界纷纷议论——这两种协议究竟是针锋相对的竞争者，还是可以相辅相成的伙伴？
谷歌官方声称 A2A 是对 MCP 的补充，下面让我们了解这两种协议之间的核心概念以及联系。
以下是本文的内容概览：
- 什么是 A2A？
- 什么是 MCP？
- A2A 与 MCP 如何互补？
- 长期来看，A2A 是否会取代 MCP？
A2A 协议：连接未来 Agent 的桥梁
未来的智能体系统（Agentic Systems，指由多个智能体协作完成任务的系统）将以多智能体形式为主。这些系统可能涉及远程协作。智能体可能基于不同的框架开发，如 LangGraph、CrewAI 或 Agent Development Kit。这带来了几个核心问题：
- 不同框架实现的系统之间，无法有效传递和交换系统状态（System State）。
- 远程智能体之间也无法实现系统状态的传输。
- 相互独立的智能体无法共享工具、上下文和记忆（包括系统状态）。
为了解决这些问题，A2A 协议应运而生：
> A2A 是一个开放协议，旨在为 Agent 之间的协作提供标准化的方式，无论其底层的实现框架或供应商如何。
根据谷歌的官方文档，A2A 协议主要促进“客户端”（Client）Agent 与“远程”（Remote）Agent 之间的通信。简而言之，“客户端”Agent 发起任务并将其传递给“远程”Agent，期望后者执行特定工作或返回所需数据。
为实现这一目标，A2A 提供了几项核心能力：
* 能力发现 (Capability Discovery) ：所有实现 A2A 的 Agent 通过“Agent 名片 (Agent Card)”公开其能力清单。这使得其他 Agent 能够发现特定 Agent 所具备的潜在有用功能。
* 任务管理 (Task Management) ：为短期和长期运行的任务提供通信协议支持，确保通信双方的 Agent 能够保持同步，直至任务完成并返回结果。这对于处理耗时较长的 Agent 任务至关重要，因为目前尚无标准来规范等待机制。
* 协作 (Collaboration) ：允许 Agent 之间互相发送消息，以传递上下文、回复、工件（Artifacts）或用户指令。
* 用户体验协商 (User Experience Negotiation) ：这是一个颇具特色的功能，允许 Agent 协商数据返回的格式（如图像、视频、文本等），以更好地适应用户的界面（UI）需求。
Agent 发现机制与谷歌的布局
如何发现这些通过 A2A 暴露的 Agent 是一个关键问题。谷歌建议设立一个统一的地址来存储“Agent 名片”，例如：
https:////agent.json
不难预见，凭借其强大的索引能力，谷歌极有可能处在索引全球可用 Agent 的最佳位置，未来或许会构建一个类似于现有搜索引擎索引的“全局 Agent 目录 (Global Agent Catalogue)”。这与业界关于“无头浏览器 (headless browsers)”和未来 Agent 互联网形态的讨论不谋而合，A2A 提供了一条利用现有技术实现该愿景的可能路径。
A2A 强调不重复造轮子，并基于现有成熟标准构建：
* 协议建立在 HTTP、SSE、JSON-RPC 等广泛使用的标准之上，更易于与企业现有的 IT 技术栈集成。
* 默认安全 (Secure by Default) ：A2A 的设计支持企业级的认证和授权（Authentication and Authorization），其标准与 OpenAPI 的认证方案相当。
关于MCP 协议的详细内容可以查看我发布的上一篇文章：MCP（模型上下文协议）全面解析：塑造 AI 智能体系统的未来
A2A + MCP：协同还是竞争？
根据谷歌的官方说法：Agent 应用程序同时需要 A2A 和 MCP。我们建议将 MCP 用于工具集成，将 A2A 用于 Agent 间通信。
这具体意味着什么？让我们设想一个包含多个 Agent 的系统架构：
* MCP 的角色：
* Agent (即 MCP 主机) (1)：作为使用 MCP 获取上下文的主体。
* MCP 客户端 (2) & MCP 服务器 (3)：负责连接和暴露资源/工具。
* 本地/远程数据源 (4, 5)：通过 MCP 资源（Resources）和工具（Tools）暴露给 Agent。
* A2A 的角色 (6)：
* Agent 间通信：Agent (1) 之间将通过 A2A 协议进行通信，实现：
* 安全协作 (Secure Collaboration)：弥补 MCP 在早期版本中认证能力的不足（更新：近期 MCP 在认证方面已有显著改进：链接(https://github.com/modelcontextprotocol/modelcontextprotocol/pull/284)。
* 任务与状态管理 (Task and State Management) 。
* 用户体验协商 (User Experience Negotiation) 。
* 能力发现 (Capability Discovery) ：发现其他 Agent 的能力。
按照这种设想，MCP 主要负责将遗留数据系统（通过 MCP 资源）和API（通过 MCP 工具）集成到基于 LLM 的应用中，而 A2A 则专注于处理Agent 之间的通信。
随着技术发展，将平台或服务直接暴露为 Agent（而非仅仅是 MCP 服务器）会变得越来越普遍，MCP 在暴露远程数据源（上图第 5 点）方面的重要性可能会逐渐降低。
#### 通过 MCP 进行 Agent 发现？
谷歌甚至提出了一种利用 MCP 服务器资源来发现 A2A Agent 的方式：
1. 网络中的 Agent 可以通过 MCP 客户端连接到 MCP 服务器，浏览其资源目录，从而发现其他可用的 A2A Agent（建议通过 MCP 资源暴露 Agent 名片）。
2. 一旦发现目标 Agent，后续的通信则切换到 A2A 协议进行。
A2A 会取代 MCP 吗？
那么，MCP 是否面临着最终被边缘化的风险？
业界早已明确需要一种机制来连接日益增多的 Agent 群体，并将它们与现有的遗留系统（Legacy Systems）打通。开放通信协议似乎正成为实现这一目标的主流方向，这也是之前关于“MCP 是否是下一个 HTTP 时刻”讨论的根源（或许有些夸大其词？）。
以下推测基于几个假设：
* 开放通信协议将是整合未来 Agent 世界的关键。
* 支持领先的协议将带来显著优势。
* A2A 和 MCP 都将持续演进，并可能扩展其功能边界。
#### MCP 与 A2A 的重叠与差异
两种协议存在一定的相似性，开发者可以有多种方式来构建和暴露他们的 Agent 应用。随着 MCP 的普及，许多公司开始将 MCP 服务器作为其产品的一部分提供，以便开发者能无缝集成来自这些平台的上下文。
然而，MCP 在推广过程中也暴露出一些问题：
* 安全性：早期版本缺乏完善的安全和认证机制是其主要短板之一，安全地暴露远程 MCP 服务器需要额外的定制开发（尽管近期有所改善）。
* Agent 间通信支持不足：虽然 MCP 工具可以描述任何事物（包括其他 Agent），但它并未内置促进 Agent 间复杂通信（如状态/上下文交换、长时任务支持等）的原语。
这或许正是谷歌看到的机会——通过 A2A 协议来解决 MCP 的上述痛点，从而切入这场协议标准的竞争。
Anthropic 对 MCP 的愿景远不止于当前状态，或许本就包含连接多个 Agent 的蓝图。但现在，随着 A2A 的出现，MCP 向该领域扩展的空间可能受到了限制。
#### 长远来看，什么才是关键？
从长远视角审视，未来的 Agent 世界将如何构建？可能的模式包括：
1. 公司将其数据资产暴露出来供 Agent 使用。
2. 公司暴露能够返回数据或执行操作的独立 Agent。
3. 公司本身就表现为一个 Agent，供其他 Agent 交互。
一个合理的推测是，趋势将逐渐向第三种模式演进。
如果这个假设成立，那么真正掌握未来话语权的，将是那个控制远程 Agent 间通信的协议。
即使在短期内，假设第二种模式（暴露独立 Agent）成为新兴公司的默认选择，那么 A2A 显然是更合适的协议，因为它专为此类交互设计。
在这种背景下，MCP 是否会继续扮演连接新型应用与遗留系统的桥梁角色，然后在 Agent 全面接管后逐渐淡出舞台？最终结果尚难定论。
但如果未来真的如此演进，谷歌凭借 A2A 协议所占据的位置无疑是值得关注的。
写在最后
我们正处在一个激动人心的技术变革时期。新型 Agent 应用如何大规模互联互通的标准，正在我们眼前被塑造。
A2A 虽然是后来者，但它正迅速成为 Agent 间通信领域的有力竞争者。MCP 为 LLM 集成上下文提供了结构化方案，而 A2A 则着力解决 MCP 尚有不足的领域：安全性、状态管理和实时协作。
如果未来属于 Agent，如果企业和平台最终选择以 Agent 的形式对外提供服务，那么能够实现无缝 Agent 间交互的协议，很可能成为最终的标准。从目前的布局来看，A2A 似乎正在朝着这个方向迈出关键步伐。Agent 协议的演进之路，值得我们持续关注。