MCP 与 A2A：朋友还是敌人？

从长远来看，MCP 会变得不再重要吗？

Anthropic 的 MCP（模型上下文协议）的成功显然激励了人工智能行业的其他参与者加入竞争，成为定义用于 Agentic Systems 集成的开放协议的参与者。

本周，谷歌公开发布了名为 A2A（Agent2Agent）的开放协议，旨在规范多智能体系统通信的实现方式。许多人认为（或许是误解了？）这两个协议是竞争关系，而非互补关系。

谷歌的公开立场是，A2A 与 MCP 互补。这说法合理。然而，这其中是否隐藏着长期竞争目标？我们很快就会看到协议之战吗？

我曾多次被问到，我认为这两种协议未来如何才能形成竞争力。请读到最后，了解我的想法。

在本期新闻通讯中：

• 什么是 A2A？
• 什么是 MCP？
• A2A 与 MCP 有何互补之处？反之亦然。
• A2A 能长期吞噬 MCP 吗？

A2A 解释。

让我们首先定义一下 A2A，因为它是新兴事物（MCP 已经成为人们关注的焦点）。

越来越明显的是，未来的代理系统将是多代理系统。甚至，代理之间将进行远程协作，每个代理都可能使用不同的代理框架（例如 LangGraph、CrewAI、代理开发工具包等）实现。

这其中存在一些固有的问题：

• 不支持不同框架实现的系统之间的系统状态传输和交换。
• 远程代理之间系统状态的传输也是不可能的。
• 断开连接的代理不共享工具、上下文和内存（包括系统状态）。

解决方案。

A2A 是一种开放协议，它为代理相互协作提供了一种标准方式，而不受底层框架或供应商的限制。

根据 Google 官方文档：

A2A 协议促进“客户端”和“远程”代理之间的通信。

简单来说，“客户端”代理创建任务并将其传达给“远程”代理，以期望执行某些工作或返回数据。

实现这一目标的主要 A2A 功能：

• 能力发现 - 所有实现 A2A 的代理都会通过“代理卡”公开其能力目录。这有助于其他代理发现特定代理所实现的潜在有用功能。
• 任务管理——一种用于处理短期和长期任务的通信协议。它帮助通信代理保持同步，直到请求的任务完成并返回结果。这一点非常重要，因为有些代理可能需要很长时间才能执行其工作，而且目前还没有关于如何等待这一过程的标准。
• 协作——代理可以互相发送消息来传达上下文、回复、工件或用户指令。
• 用户体验协商——这一点相当有趣。它允许协商返回数据的格式，以符合用户的 UI 期望（例如图像、视频、文本等）。

发现通过 A2A 暴露的代理是一个热门话题。谷歌建议将组织的“代理卡”统一存储在一个地方。例如：

https://<DOMAIN>/<agreed-path>/agent.json

这并不出人意料，因为 Google 将处于最佳位置，可以索引全球所有可用的代理商，从而有可能创建类似于当前搜索索引的全球代理商目录。

关于无头浏览器以及未来代理互联网的实现方式，已经有很多讨论。以上只是利用现有技术实现这一目标的方法之一。

我喜欢 A2A 强调不需要重新发明轮子并在现有标准的基础上进行构建的方式：

• 该协议建立在现有的流行标准之上，包括 HTTP、SSE、JSON-RPC，这意味着它更容易与企业日常使用的现有 IT 堆栈集成。
• 默认安全 - A2A 旨在支持企业级身份验证和授权，与 OpenAPI 的身份验证方案相当。

MCP 解释。

Anthropic 定义的 MCP（模型上下文协议）是：

一种开放协议，用于标准化应用程序如何提供上下文。

更准确地说，它尝试标准化基于应用程序如何与其他环境集成的协议。

在代理系统中，可以通过多种方式提供上下文：

• 外部数据——这是长期记忆的一部分。
• 工具——系统与环境交互的能力。
• 动态提示 - 可以作为系统提示的一部分注入。

为什么需要标准化？

Agentic 应用程序的当前开发流程比较混乱：

• 代理框架有很多，但略有不同。虽然看到生态系统蓬勃发展令人欣喜，但这些细微的差异很少能带来足够的价值，反而可能会显著改变你的代码编写方式。
• 与外部数据源的集成通常是临时实施的，即使在组织内部也使用不同的协议。对于不同的公司来说，情况显然也是如此。
• 代码库中工具的定义方式略有不同。将工具附加到增强型代码库的方式也有所不同。

目标是提高我们利用 Agentic 应用程序进行创新的速度、提高它们的安全性以及提高将相关数据带入上下文的难易程度。
下面是 MCP 的高层架构。

1. MCP 主机 - 以 MCP 为核心并希望通过 MCP 访问数据的程序。
2. MCP 客户端 - 与服务器保持 1:1 连接的客户端。
3. MCP 服务器 - 轻量级程序，每个程序都通过标准化模型上下文协议公开特定功能。
4. 本地数据源 - MCP 服务器可以安全访问的您的计算机的文件、数据库和服务。
5. 远程数据源 - MCP 服务器可以通过互联网（例如通过 API）连接的外部系统。

通过 MCP 划分控制责任

MCP 服务器公开了三个主要元素，这些元素的构建方式旨在帮助实现特定的控制隔离。

• 提示旨在由用户控制。
  • 服务器的程序员可以公开特定的提示（适合与服务器公开的数据进行交互），这些提示可以使用 LLMs 注入到应用程序中，并公开给给定应用程序的用户
• 资源被设计为由应用程序控制。
  • 资源是指任何类型的数据（文本或二进制），可供旨在利用资源的应用程序使用。应用程序的程序员（通常是 AI 工程师）负责规范应用程序如何使用这些信息。通常，这其中没有自动化，因此他们不参与这一选择。
• 工具被设计为模型控制的。
  • 如果我们授权应用程序与环境交互，我们会使用工具来实现这一点。MCP 服务器公开了一个端点，该端点可以列出所有可用的工具及其描述和所需参数，应用程序可以将此列表传递给应用程序，以便它决定当前任务需要哪些工具以及如何调用它们。

A2A + MCP。

根据谷歌官方立场：

Agentic 应用需要 A2A 和 MCP。我们建议工具应用使用 MCP，代理应用使用 A2A。

这是什么意思呢？让我们来看一下涉及多个代理的代理系统架构。

在 MCP 中移动部件：

1. MCP 主机 - 这就是有趣的地方，当与 A2A 结合时，MCP 主机就是代理。
2. MCP 客户端。
3. MCP 服务器。
4. 本地数据源。
5. 远程数据源。

A2A：
6. 代理（MCP 主机）将通过 A2A 协议实现和通信，从而实现：
a. 安全协作 - MCP 缺乏身份验证。[** 更新：** 最近，MCP 的身份验证功能已得到许多改进：链接]
b. 任务和状态管理。
c. 用户体验谈判。
d. 能力发现——类似于 MCP 工具。

建议 MCP 主要用于将遗留数据系统（MCP 资源）和 API（MCP 工具）与基于应用程序的集成，而 A2A 则负责代理间通信。

我确实相信，随着我们不断前进，将您的平台作为代理而不是 MCP 服务器公开将变得更加普遍，因此第 5 点中 MCP 的重要性将逐渐降低。

通过 MCP 发现代理。

Google 甚至建议通过 MCP 服务器资源公开 A2A 代理。

1. 网格中的每个代理都可以通过 MCP 客户端连接到专用的 MCP 服务器并浏览资源目录来发现其他可用的代理。建议通过这些 MCP 资源公开代理卡。
2. 一旦被发现，代理将利用 A2A 协议继续相互通信。

话虽如此，如果我们通过全局索引来实现代理发现，MCP 的重要性也会降低，甚至消失。

A2A 能长期吞噬 MCP 吗？

那么 MCP 是否有逐渐失去意义的风险呢？
很长一段时间以来，人们显然需要一种媒介，将大量释放到世界中的 Agent 彼此连接，并连接到其他遗留系统。虽然也曾讨论过无头浏览器，但这些开放的通信协议似乎才是真正的发展方向。我相信，MCP 将成为新的 http 时代（是不是有点夸张了？）的讨论也源于此。

以下想法基于一些假设：

• 开放的通信协议将整合新世界的代理。
• 落后于领先协议是有好处的。
• 这两种协议都将继续发展，并可能扩大责任的界限。

MCP 和 A2A 的相似之处。

机器人协议有一些明显的相似之处，用户可以选择如何建模他们的 Agentic 应用程序并以多种方式向世界展示它们。

随着 MCP 人气的飙升，公司将 MCP 服务器作为其产品的一部分提供已成为一种常态，以便开发者可以将这些平台的上下文无缝集成到他们自己的应用程序中。

然而，MCP 在采用过程中面临一些问题。

• 该协议最大的缺点之一是缺乏安全性和身份验证。您需要修改基本实现才能安全地公开远程 MCP 服务器。
• 工具可以描述任何事物，包括其他代理。遗憾的是，MCP 并未实现任何能够通过工具促进代理之间正常通信的原语（例如状态/上下文交换、长时间运行任务支持等）。

通过修复上述问题，谷歌可能找到了一个契机，加入与 A2A 的协议之战。

我一直觉得 Anthropic 对 MCP 的计划比现在更宏大，包括多个 Agent 之间的互联互通。现在，由于 A2A 的出现，向这个领域扩张的大门可能已经关闭。

从长远来看什么才是真正重要的？

如果我们从长远考虑，代理世界将如何真正建模？

• 公司公开其数据资产以供代理商使用。
• 公司公开可以返回数据或执行操作的代理。
• 公司是其他代理可以与之互动的代理。

我押注的是最后一个选项。

如果假设成立，那么真正的权力就掌握在控制远程代理间通信协议的协议手中。

即使从短期来看，假设第二点是新兴公司的默认选项，如果选择通过代理公开其数据，A2A 显然是赢家。

上图：通过 A2A 连接的代理网络

话虽如此，MCP 是否会继续作为连接新型应用程序与遗留系统的协议，并在 Agent 接管后逐渐失去意义？谁知道呢，让我们拭目以待。

但如果发生这种情况，猜猜我会押注哪个行业参与者:)

总结。

我们生活在一个激动人心的时代。新型 Agentic 应用的大规模连接方式正在我们眼前被定义。

A2A 或许是该领域的新手，但它正在迅速成长为代理间通信领域的领导者。MCP 为上下文集成提供了结构，而 A2A 则解决了 MCP 所缺乏的：安全性、状态管理和实时协作。A2A 会吞噬 MCP 吗？谁知道呢。

虽然官方立场是这两个协议解决的是完全不同的问题，但它们之间存在潜在的重叠，人们可以预期这两个协议的范围也会扩大。

如果未来是 Agentic 的天下，企业开始对外开放 Agent，而不仅仅是工具或数据，那么能够实现 Agent 之间无缝交互的协议或许才是最终的赢家。目前看来，A2A 或许做出了正确的选择。

今天就到这里，希望下期再见！

转载说明：

本文翻译转载自 Swirl AI Newsletter 发布的文章。

• 原文标题： 《MCP vs A2A: Friends or Foes?》
• 原文作者： Aurimas Griciūnas

译文仅供学习交流，版权归原作者所有。