Google推出的A2A真的好过MCP吗？

A2A，即 Agent to Agent 协议，是 Google 在2025年4月9日在Google Cloud Next '25大会上推出的开源协议，旨在实现 AI Agent之间的通信和互操作性。通过为Agent提供标准化的协作方式，无论其底层框架或供应商如何，该协议使 AI Agent能够安全地交换信息、协调行动，并跨各种企业平台和应用程序工作。

超过50家技术巨头和领先服务商宣布支持A2A：

A2A 协议是一项开放标准，它使 AI Agent能够跨不同平台和框架进行通信和协作，而无需考虑其底层技术。该协议旨在通过支持真正的多Agent场景，最大限度地发挥AI Agent的优势。

概述

·Agent Card:：描述Agent能力、技能、URL和认证要求的公共元数据文件（通常位于/.well-known/agent.json）。客户端使用该文件和Agent进行连接。

·A2A Server：提供 HTTP 端点、执行 A2A 协议方法（在 json 规范中定义）的Agent。它接收请求并管理任务执行。

·A2A Client：使用 A2A 服务的应用程序或其他Agent。它向 A2A 服务器的 URL 发送请求（如tasks/send）。

·Task：工作的核心单位。客户端通过发送消息（tasks/send或tasks/sendSubscribe）来启动任务。任务有唯一的ID，并通过状态（submitted，working，input-required，completed，failed，canceled）进行。

·Message：代表客户端 ( role: "user" ) 和Agent ( role: "agent" ) 之间的通信。消息包含Parts。

·Part：Message或Artifact中的基本内容单元。可以是TextPart，FilePart（内嵌字节或URL),或DataPart（结构化JSON，如表单）。

·Artifact：代表Agent在任务期间生成的输出（如生成的文件、最终结构化数据），其中也包含Parts。

·Streaming：对于长期运行的任务，支持streaming功能的服务器可以使用tasks/sendSubscribe。客户端会收到服务器发送的事件（SSE) ，其中包含TaskStatusUpdateEvent 或 TaskArtifactUpdateEvent消息，提供实时进度。

·Push Notifications：支持pushNotifications的服务器可主动向客户端提供的 Webhook URL 发送任务更新，该 URL 通过 tasks/ pushNotification/ set配置。

执行流程

1.Discovery：客户端从服务器提供的 URL 中获取Agent Card。

2.Initiation：客户端发送包含初始用户信息和唯一任务ID的tasks/ send或tasks/sendSubscribe请求。

3.Processing

·(流式输出）：服务器在任务进行过程中发送 SSE 事件（状态更新、工件）。

·(整体输出）：服务器同步处理任务，并在响应中返回最终的Task对象。

1.Interaction (Optional)：如果任务进入input-required，客户端会通过tasks/send或tasks/sendSubscribe使用相同的任务 ID 发送后续信息。

2.Completion：任务最终达到结束状态 （completed，failed，canceled） 。

A2A在BAS的应用场景：

在BAS中，可以分场景正常任务执行的流程为多个步骤，将每一个步骤的实现做为一个Agent，根据A2A协议，每个步骤的Agent包含一个AgentCard用来描述该Agent的功能，由AgentClient负责统筹所有的Agent，和任务执行流程。

在BAS中，以钓鱼邮件场景为例，假设在BAS界面中存在一个AgentClient，类似一个网页AI助手，当我们向其输入需求：

五一假期临近，请根据这个主题对矢安科技所有员工做一次安全意识测试。

Agent Client和各个Agent的交互如下：

·调用模版Agent，用来查询模版库中是否存在配套的五一相关的模版，若有提供名称，没有则生成对应的邮件模版和钓鱼页模版。

·调用评估目标Agent，用来选择要进行评估的部门或公司。

·调用任务参数Agent，用来选择任务执行的参数。

·调用任务状态Agent，查看任务执行情况。

具体效果可参考下方执行流程：

A2A在EASM的应用场景：

EASM可将各个部分的功能，作为一个个Agent，最终在AI助手，即AgentClient中实现单独执行特定功能如域名解析、端口服务识别等等，也可参照钓鱼场景实现整体任务下发，可制作一个任务进度查询Agent，返回任务执行情况。

通过本地部署官方A2A样例，使用Google的Gemini模型进行测试。样例中给出了两个Agent，CurrencyAgent和Image Generator Agent一个是用于汇率转换，一个是用来文生图。

代码中给出了一个UI界面，可以在界面中导入本地部署的上述两个Agent

Agent Card

可以看到，访问本地部署的两个Agent会得到AgentCard信息，以便后续模型理解并使用Agent。使用十分方便，只需要导入Agent的地址即可。

任务执行流程

Q1

Currency Agent执行日志：

Q2

Image Generator Agent执行日志：

Q3

调用的Agent日志：

大致执行流程：

根据流程图可以看出，Gemini先根据我们的问题，调用了CurrencyAgent得到的了汇率结果，再调用了Image Generator Agent来生成图片最后返回结果。

单独调用Agent

可以看到A2A协议调用Agent的一些参数，以及返回的信息。分析CurrencyAgent的代码，可以看到

该Agent也是使用的Gemini的API，并设置提示词调用get_exchange_rate工具，也就是函数，如下所示：

该函数根据接收到的参数调用frankfurter的API来实现汇率转换。

从使用上看，A2A和MCP实现效果类似，MCP在Server中写好实现功能，而A2A在另一个Agent中实现。区别点在于，MCP主要用于增强单个Agent的能力，通过连接外部工具（如数据库、API）来提供上下文和数据支持。例如，一个代理可能通过 MCP 连接到一个天气 API 来获取实时数据。A2A则专注于多个Agent之间的协作，允许它们发现彼此、交换任务或共享信息。例如，在企业入职流程中，HRAgent可能通过 A2A 将任务分配给 IT 和设施管理Agent。

如果你需要一个代理访问外部工具或数据，MCP是合适的选择。如果你需要多个代理协同工作，A2A则是更好的解决方案。

A2A 关注的是另一个问题。A2A是一种应用级协议，可使代理以其自然模式进行协作。它允许代理作为代理（或用户）而不是工具进行通信。我们希望 A2A 作为 MCP 的补充，能够实现代理生态系统，并将与社区一起努力实现这一目标。

虽然 Google 声称 A2A 与 MCP 互补，但业界有声音质疑两者可能存在竞争，尤其是在开发者资源有限的情况下。一些专家认为，两者的功能可能重叠，未来可能引发协议之争。

目前研究结果看来，A2A协议使用更加的方便，且具备认证更加安全，打通了不同Agent之间的联动，但是目前可以用来验证的Agent较少，后续发展仍待考究。

https://github.com/google/A2A/https://google.github.io/A2A/#/https://www.a2aprotocol.net/zhhttps://a2aprotocol.ai/https://www.youtube.com/watch?v=voaKr_JHvF4