Google 在 2025 年 4 月 9 日发布了的一个重磅项目——Agent2Agent (A2A) 协议。这个协议旨在解决当前 AI Agent 生态中的一个核心痛点：不同厂商、不同框架下的智能体如何有效沟通与协作？

让我们深入 A2A 的 GitHub 仓库，从代码和文档中一探究竟，并看看它与另一个备受关注的协议 MCP 有何异同。

GitHub 地址： https://github.com/google/A2A

首先，我们看看项目的代码结构（如下图所示）：

项目中有一个值得关注的文件：llms.txt。这是一种新兴的规范，我们先从它说起。

llms.txt - 让大模型读懂你的项目

根据 llmstxt.org 的定义，llms.txt 文件是一种标准化的文本文件，旨在帮助大型语言模型（LLM）在推理时更好地理解和使用网站或项目的信息。它提供了一种机器可读且易于维护的方式，来声明服务的能力、接口规范、元数据等关键信息，有点像专为 LLM 设计的 sitemap.xml，但内容更丰富、更聚焦。

在 Google A2A 项目中，llms.txt 文件扮演了以下角色：

1. 能力声明与接口说明书：详细描述了 A2A 协议的目标、核心功能、支持的接口、数据结构（如 AgentCard, Task, Message, Artifact）和交互方式。为开发者和自动化工具提供了权威、结构化的参考。
2. 示例与文档索引：指向项目中的规范文件（JSON specification）、示例实现、文档和演示应用，帮助开发者快速上手。
3. 元数据与发现：为其他系统或开发者提供关于 A2A 协议的元信息，支持自动发现和能力适配。

主要讲了：

• 项目简介、目标和核心设计理念。
• 支持的协议与接口（如 JSON-RPC 2.0、SSE 等）。
• 关键数据结构（如 AgentCard、Task、Message、Artifact 等）的详细说明。
• 支持的 API 方法及其参数、返回值、错误码。
• 认证与安全机制说明。
• 示例代码、演示应用和相关文档的索引。
• 贡献和社区参与方式。

A2A 协议要解决的核心问题

那么，A2A 协议本身究竟是为了解决什么问题而诞生的呢？核心目标非常明确：让不同厂商、不同框架、不同技术实现的 AI 智能体（Agent）能够互相发现、通信与协作。

具体来说，A2A 旨在解决：

1. 异构智能体互操作难题：不同框架（如 LangGraph, CrewAI, Google ADK, Genkit 等）开发的 Agent 接口各异，难以协作。A2A 提供统一的「语言」，实现互操作。
2. 能力发现与动态适配：如何知道一个 Agent 能做什么、需要什么输入、如何认证？A2A 的 AgentCard 机制标准化了能力描述，支持自动发现。
3. 任务管理与多轮对话标准化：A2A 定义了标准的任务生命周期（submitted, working, input-required, completed 等）和多轮对话交互模式。
4. 多模态内容与产物交换：通过 Part/Artifact 机制，支持文本、文件、结构化数据等多种内容类型的灵活传递。
5. 流式与推送更新机制：对于长任务，支持 SSE 流式更新和 Webhook 推送，提升体验和集成能力。
6. 安全与认证的标准化：统一认证描述，便于安全集成。

总结一下：A2A 协议的本质，是为日益复杂的多智能体系统提供一个开放、标准、可扩展的通信和协作基础，打破技术壁垒，实现真正的「智能体互联互通」。

A2A 的核心技术组件与机制

为了实现上述目标，A2A 协议依赖以下核心技术组件和机制：

• AgentCard (能力发现) ：一个标准的 JSON 文件（通常在 /.well-known/agent.json），描述 Agent 能力、技能、端点、认证等，供客户端发现。
• 标准消息与任务结构 (JSON-RPC 2.0) ：所有通信基于 JSON-RPC 2.0，定义了 Task (核心单元)、Message (交互)、Part (内容单元)、Artifact (产物) 等标准结构。
• 多内容类型支持：通过 TextPart, FilePart, DataPart 支持文本、文件、结构化 JSON 等多种内容。
• 流式通信 (SSE) ：通过 tasks/sendSubscribe 和 tasks/resubscribe 实现 Server-Sent Events，实时推送任务状态和产物。
• 推送通知 (Webhook) ：通过 tasks/pushNotification/set 配置，Agent 可主动将更新推送到客户端指定的 URL。
• 统一的任务管理与生命周期：定义了清晰的任务状态（TaskState）流转。
• 认证与安全机制 ：支持在 AgentCard 和推送配置中声明认证需求。
• 通用库与示例实现 ：提供了 Python 和 JS/TS 的通用库及多种框架（ADK, CrewAI, LangGraph, Genkit, LlamaIndex, Marvin, Semantic Kernel）的集成示例。

这些机制共同保证了协议的互操作性、灵活性和实际落地能力。

示例：common 目录的通用能力 (Python 版)

在 A2A 的 Python 示例代码中，samples/python/common 目录实现了 A2A 协议的通用基础功能，为构建 A2A 客户端和服务端提供了可复用的核心组件：

• types.py ：定义了所有 A2A 核心数据结构。
• server/ ：包含 A2AServer (基于 Starlette 的服务端入口) 和 TaskManager (任务管理抽象)。
• client/ ：包含 A2AClient (客户端调用逻辑封装) 和 A2ACardResolver (AgentCard 发现)。
• utils/ ：提供缓存、推送通知认证等工具。

设计意义：common 目录将通用实现抽象出来，减少重复开发，提升效率和一致性，是构建 A2A 兼容应用的基石。

A2A 的标准工作流程

一个典型的 A2A 交互流程如下：

1. Agent 发现 (Discovery) ：客户端获取目标 Agent 的 AgentCard (/.well-known/agent.json)，了解其能力。
2. 任务发起 (Initiation) ：客户端调用 tasks/send (同步) 或 tasks/sendSubscribe (异步流式) 发起任务。
3. 任务处理与状态流转 (Processing) ：

• Agent 状态从 submitted -> working。
• 若需用户输入，变为 input-required，等待客户端再次调用 tasks/send。
• 通过 SSE (对 sendSubscribe) 推送状态 (TaskStatusUpdateEvent) 和产物 (TaskArtifactUpdateEvent)。
• 任务最终进入终态 (completed, failed, canceled)。

1. 任务查询与管理 (Query & Management) ：客户端可调用 tasks/get 查询状态，tasks/cancel 取消任务，tasks/resubscribe 重新订阅流。
2. 推送通知 (Push Notification, 可选) ：若客户端配置了 Webhook，Agent 可主动推送状态更新。
3. 任务产物 (Artifacts) ：任务完成后返回结果，支持多种内容类型。

流程图如下：

这个标准化的流程确保了不同 Agent 间交互的可预测性和可靠性。

A2A 与 MCP 的关系：互补共赢

根据 A2A 官方文档的说明 (A2A and MCP)，两者是互补的，而非竞争关系。

可以这样理解：

• MCP (模型上下文协议) ：由 Anthropic 于 2024 年 11 月发布，旨在标准化 AI 模型（LLM）与外部数据源和工具（如数据库、API、文件系统）的连接。它统一了不同模型和框架的“函数调用” (Function Calling) 功能，让 AI 能访问和利用上下文数据。MCP 更像是“工具说明书”，告诉 AI 如何使用各种工具和数据。
• A2A (Agent2Agent 协议) ：则专注于智能体之间的协作。它是一个应用层协议，支持智能体以「智能体」或「用户」的身份进行交互，处理更动态、更自然的对话和协作任务，而不仅仅是作为工具被调用。A2A 更像是「智能体通讯录和对话规则」。

它们如何互补？

• MCP 确保智能体能够访问所需的数据和调用必要的工具（比如通过 MCP 连接到 Google Drive API）。
• A2A 则让智能体能够基于这些数据和工具进行协作，共同完成更复杂的任务（比如一个 Agent 通过 MCP 获取了文档，然后通过 A2A 请求另一个擅长分析的 Agent 来解读这份文档）。

官方文档的汽车维修店例子：

• MCP 像是连接智能体与维修工具（千斤顶、扳手 – 结构化调用）。
• A2A 则支持智能体与客户（“我的车有异响”）、其他技工或零件供应商（需要协作和动态对话）进行交互。

集成点：Google 建议可以将 A2A Agent 本身建模为 MCP 资源（通过 AgentCard 描述）。这样，一个智能体框架既可以通过 MCP 调用外部工具和数据，也可以通过 A2A 与用户或其他智能体进行无缝通信。

官方示例图：

A2A 和 MCP 解决了智能体生态中不同层面的互操作性问题。MCP 侧重于模型与工具/数据的连接，而 A2A 侧重于智能体之间的协作与通信。两者结合，将共同推动一个更强大、更灵活、更互联的智能体生态系统的发展。

虽然官方这么说，但是随着 A2A 协议的推行，其可能会「吃掉」MCP (个人猜想 ^_^)

以上。