AGI｜详解Google A2A协议，谁才是Agent的未来标准？

A2A（Agent to Agent）是一种开放协议，支持 Agent 到 Agent 的互操作性，弥合不透明代理系统之间的差距。

主要成员

🔷 User：使用 Agent 系统完成任务的最终用户

🔷Client：代表用户向不透明 Agent 请求操作的实体

🔷Remote Agent（Server）：不透明（“黑匣子”）Agent，即 A2A 服务器。

传输协议

利用 HTTP 在 Client 和远程 Agent 之间进行传输，根据客户端和远程代理的功能，可以利用 SSE 支持流式传输以从服务器接收更新（例如文档、媒体文件等）。且以 JSON-RPC2.0 作为 Client 和远程代理之前通信的数据交换格式。

工作原理

关键功能

🔷 能力发现：代理可以使用 JSON 格式的“代理卡”来宣传其能力，从而允许客户端代理识别能够执行任务的最佳代理并利用 A2A 与远程代理进行通信。

🔷 任务管理：客户端与远程代理之间的通信以任务完成为导向，代理负责执行最终用户的请求。此“任务”对象由协议定义，并具有生命周期。它可以立即完成，或者，对于长时间运行的任务，每个代理可以进行通信，以彼此保持同步，了解任务的最新完成状态。任务的输出称为“工件”。

🔷 协作：代理可以互相发送消息来传达上下文、回复、工件或用户指令。

🔷 用户体验协商：每条消息包含“part”，即完整形成的内容片段，例如生成的图像。每个部分都有指定的内容类型，允许客户端和远程代理协商所需的正确格式，并明确包含对用户 UI 功能（例如 iframe、视频、Web 表单等）的协商。

核心概念

🔷 代理卡（Agent Card）：一个公开的元数据文件（通常位于/.well-known/agent.json），描述代理的功能、技能、端点 URL 和身份验证要求。客户端使用它进行发现。

🔷 A2A Server：一个代理，暴露一个实现了 A2A 协议方法（在JSON 规范中定义）的 HTTP 端点。它接收请求并管理任务的执行。

*JSON 规范：https://github.com/google/A2A/blob/main/specification

🔷  A2A Client：使用 A2A 服务的应用程序或其他代理。它将请求（例如tasks/send）发送到 A2A 服务器的 URL。

🔷 任务（task）：核心工作单元。客户端通过发送消息（tasks/send或）来启动任务。任务具有唯一 ID ，tasks/sendSubscribe并会经历不同的状态（submitted、working、input-required、completed、）。failedcanceled

🔷 消息（message）：表示客户端（role: "user"）和代理（role: "agent"）之间的通信轮次。消息包含Parts。

🔷 单元（Part）：Message或中的基本内容单元Artifact。可以是TextPart、FilePart（包含内联字节或 URI）或DataPart（用于结构化 JSON，例如表单）。

🔷 工件（Artifact）：表示代理在任务期间生成的输出（例如，生成的文件、最终的结构化数据）。工件还包含Parts。

🔵 MCP：主要是不同系统之间通LLM进行函数调用的标准化，降低了LLM与外部系统的数据和能力进行对接的复杂度

🔵 A2A：主要是解决不同AI Agent之间的通信标准化

MCP协议缺陷

🔷 无安全隔离机制：安装MCP Server时，通常会通过代码直接进行依赖，如果存在恶意代码，会对当前运行的系统造成一定的负面影响。

🔷 无任何授权认证机制：MCP需要自己定义权限控制机制，才能确保一些敏感数据的安全。

🔷 大模型本身存在的安全漏洞问题：大模型理解prompt能力有限，无法完全区分恶意的prompt，而MCP协议本身依赖于大模型，一些恶意指令的植入也会造成一定的影响。

A2A协议的核心特性

🔷 具备企业级的安全策略，包含监控、追踪、认证等等

🔷 具备异步的特性、支持长时间的任务运行且语序随时进行人工干预

🔷 支持多模态的处理能力

🔷 多个代理无需共享状态

技术适用场景

🔷 A2A: 

• 跨不同AI系统的多代理协作环境；

• 需要整合来自不同代理专业知识的复杂工作流程；

• 涉及不同供应商AI的跨平台集成场景；

• 以及任务分解型问题解决方案，其中专业代理各自处理任务的不同方面。（即而A2A则实现了能力的水平扩展，使多个专业AI能够协同处理超出单个AI处理能力的复杂问题。）

🔷 MCP:

• 需要访问外部资源的单一代理任务；

• 要求与数据库、API或专业软件进行工具集成的应用场景；

• 基于外部数据进行事实依据的内容生成；

• 以及需要连接到后端系统的面向用户的应用程序。（即MCP实现了AI能力的垂直扩展，通过连接到专业工具和数据源增强单个AI的功能范围。）

实施案例

🔷 A2A: 患者服务AI与专业诊断AI和预约调度AI通过A2A协议协作，帮助患者理解其医疗状况并安排适当的后续诊疗，形成完整的患者服务链条。

🔷 MCP: 临床诊断辅助AI通过MCP协议访问电子病历系统、实验室检测结果数据库和医学知识库，为临床医生提供基于循证医学的决策支持。

Thinking：竞争或合作？

A2A协议（Agent-to-Agent Protocol）本质上是一套开放标准，定义了智能体（Agent）之间相互操作的一致通信接口。

它规定了

🔷 接口规范（例如：/tasks/send 、/tasks/sendSubscribe、/tasks/get等）

🔷 数据交互格式（基于JSON-RPC 2.0+标准化的Tasks/Message/Artifact结构）

🔷 交互模式（支持同步调用和异步流式SSE推送）

🔷 发现机制（通过标准路径/.well-konw/agent.json获取agent能力描述）

🔷 认证和错误处理（接口可以要求认证、错误统一返回JSON-RPC error 格式）

调用流程

A2A 与 MCP

🔷 总结：A2A 与 MCP 协议各有侧重

MCP 专注于 AI 模型与运行环境工具、数据及系统的连接，而 A2A 致力于解决跨平台、跨供应商 AI 代理的协同标准化问题。

二者目前呈现互补关系，但未来发展存在变数。

基于 MCP 现有的生态系统规模，其完全具备能力解决当前存在的技术缺陷。例如在认证机制方面，MCP 厂商正在进行针对性优化开发。待 MCP 补齐其在认证机制等方面相对 A2A 的短板后，A2A 是否还能保持竞争优势值得商榷。不过考虑到A2A作为 Google 推出的解决方案，依托 Google 强大的生态体系，其技术演进路线和发展前景同样具备显著优势。

🔷 展望：但在探索互联 AI 技术的新时代过程中，关键问题不在于是选择 MCP 还是 A2A ，而是如何有效地整合两者，构建具有协同效应的 AI 系统架构，使整体性能超越各组件简单叠加的水平。

参考文献：

1. A2A技术文档（https://google.github.io/A2A/#/）

2. A2AGitHub（https://github.com/google/A2A/tree/main）

3. JSON-RPC 2.0（https://wiki.geekdream.com/Specification/json-rpc_2.0.html）

4. uv-python环境管理（https://docs.astral.sh/uv/）

5. A2A官方演示视频（https://storage.googleapis.com/gweb-developer-goog-blog-assets/original_videos/A2A_demo_v4.mp4）

6.MCP与A2A协议比较（https://avoid.overfit.cn/post/c7755f9f3fde49de99dcb60be3a7ea23）