AI 代理正在重塑任务自动化、决策制定和软件系统协作方式。随着组织构建更多自主代理，跨厂商与框架的标准化通信变得至关重要。这正是 Agent2Agent（A2A） 大显身手之处。
A2A 是由 Google 开发的开放、与厂商无关的协议，旨在标准化不同系统中 AI 代理之间的协作。
在本教程中，我将带您理解 A2A 的工作机制、设计原则，以及它如何为跨领域的真实多代理工作流提供支持，并与 MCP 有何不同。
什么是 Agent2Agent（A2A）？
Agent2Agent（A2A）是一种开放协议，使得不透明（黑盒）代理之间能够互操作。它使 AI 代理可以：
- 彼此发现
- 交换结构化任务
- 流式传输响应
- 处理多轮对话
- 跨文本、图像、视频与数据等多模态运行。
让我通过下图来解释 A2A 的核心思想：
图中展示了两个代理：一个 Google 代理（蓝色）和另一个代理（绿色），可能来自第三方服务。两者尝试处理两类文档或任务。绿色代理两个都成功（绿勾），而 Google 代理一个成功、一个失败。
这种差异凸显了协商与信息共享的必要性，而这正是 A2A 协议的核心组成部分。
Agent2Agent 的设计原则
A2A 围绕五项核心原则设计，以便在不共享记忆、想法或工具的前提下为终端用户完成任务。这五项原则包括：
- 拥抱代理能力：代理在不共享记忆、工具或执行计划的情况下协作。
- 基于开放标准：A2A 使用 HTTP、JSON-RPC 和 SSE，便于与现有技术栈互操作。
- 默认安全：遵循 OpenAPI 认证方案，具备企业级安全性。
- 支持长时任务：A2A 可处理后台任务、人工参与审批与流式更新。
- 模态无关：可处理图像、音频、PDF、HTML、JSON 等结构化/非结构化格式。
这些设计原则使 A2A 成为可扩展、面向企业的多代理生态系统的中枢。
A2A 如何工作？
本节将深入探讨 Agent2Agent 协议的内部机制，了解代理通信的架构与生命周期。我们将探索涉及的主要参与者、传输与认证层，以及通过 Agent Card 的发现机制。
参与者与协议
A2A 协议定义了三类核心参与者：
- 用户（User）：发起任务的终端用户。
- 客户端代理（Client agent）：代表用户构建并发送任务的请求方。
- 远程代理（Remote agent）：接收任务、执行并返回结果的代理。
回到上面的示意图，蓝色代理是客户端代理，绿色代理是远程代理。
Agent Card 与发现机制
代理通过名为 Agent Card 的标准化 JSON 文档发布其元数据与能力，通常托管在 /.well-known/agent.json。该卡片包含：
- 名称、版本与托管 URL
- 描述与服务提供方
- 支持的输入/输出模态与内容类型
- 认证方式
- 带标签与示例的代理技能列表
发现机制可以通过 DNS、注册表、市场或私有目录来实现。
核心通信对象
A2A 通信的核心是 Task，即表示原子工作单元的结构化对象。任务具有提交（submitted）、处理中（working）、需要输入（input-required）或完成（completed）等生命周期状态。
每个 Task 包含：
- Messages（消息）：用于客户端与远程代理之间的对话式交互。
- Artifacts（制品）：由远程代理创建的不可变结果。
- Parts（部件）：消息或制品中的自包含数据块，如纯文本、文件二进制或 JSON。
A2A 工作流示例
下面通过一个工作流示例来理解 A2A 的运作方式：
- 用户发起任务：用户向客户端代理发送请求，例如：“安排更换笔记本电脑”。
- 客户端代理发现远程代理：客户端代理通过托管在公开或私有 URL 上的 Agent Card 查找其他能力匹配的代理。该 JSON 文件包含技能、支持的模态、认证方式与服务 URL。
- 客户端代理发送
Task：客户端代理通过 HTTP 上的 JSON-RPC 2.0 向选定的远程代理发送 task/send 请求。负载包含：
- 任务 ID
- 会话 ID（可选）
- 包含一个或多个部件（如文本、文件、JSON）的消息
- 远程代理响应：远程代理处理任务并返回：
- 即时结果（通过制品）
- 中间消息（通过消息）
- 或请求更多信息（将状态设为 input-required）
- 流式与推送更新（如为异步）：若任务为长时运行，远程代理可使用 Server-Sent Events（SSE） 向后流式传输部分结果。若客户端断开连接，可向客户端提供的安全 webhook 发送推送通知。
- 任务状态转换：任务在以下状态间转换：submitted → working → input-required → completed。期间代理可随时向客户端发送更新或新的制品。
- 制品与消息：消息用于沟通或澄清（例如：“请上传您的收据。”），而制品用于呈现最终输出，如报告 PDF、分析摘要、JSON 列表等。
- 客户端代理继续或完成任务：若需要输入，客户端代理向用户收集并再次发送
task/send。任务完成后，客户端可使用 task/get 获取所有制品。
A2A 示例：IT 服务台工单解决
设想一个企业 IT 服务台系统，使用 AI 代理自主管理并解决支持工单。在该场景中，用户代理接收到如下请求：
“My laptop isn’t turning on after the last software update.”技术支持
随后，用户代理通过 A2A 与多个远程代理协作，编排一条解决流程。
上述场景中，代理通过 A2A 的交互如下：
- 客户端代理向硬件诊断代理发送任务，请求进行设备检查。
- 若硬件正常，则升级至软件回滚代理，评估最近的更新。
- 若回滚失败，则调用设备更换代理，启动硬件更换流程。
每个代理独立运行，公开其能力的 Agent Card，并通过结构化任务进行异步通信。代理可能会：
- 以制品的形式流式传输日志或诊断信息
- 在需要用户输入时暂停流程
- 在完成自身环节后发送推送更新
这是一种纯粹的 A2A 用例，因为：
- 未涉及 API 或 OCR 引擎等结构化工具
- 所有协调均发生在不透明、相互协作的代理之间
- 代理作为对等体行事，拥有各自的决策逻辑与原生模态处理能力
A2A 与 MCP：何时用哪一个？
A2A 与 MCP 在代理系统中解决的是不同但互补的挑战。A2A 专注于让代理以自治对等体的方式协作，而 模型上下文协议（MCP） 旨在将代理与结构化工具和外部资源连接起来。
为什么需要同时使用 A2A 与 MCP？
协议为互操作性建立标准。在代理世界中，两个层面的互操作至关重要：
- 工具互操作性（MCP）：代理调用结构化函数、API 或工具。
- 代理互操作性（A2A）：代理以自然语言或混合模态进行协作。
示例：贷款审批工作流
设想一个为金融机构自动化贷款审批的多代理系统。
在该场景中，A2A 与 MCP 的协同方式如下：
步骤 1：通过工具与 API 进行预处理（MCP）
LoanProcessor 代理接收用户提交的贷款申请。它使用 MCP 来：
- 调用征信评分 API
- 随后从安全数据源检索银行交易历史
- 最后使用 OCR 校验上传的文件
步骤 2：为最终决策进行多代理协同（A2A）
基于步骤 1 的结构化数据，代理使用 A2A 来：
-
与 RiskAssessmentAgent 协作评估借款人风险
-
随后咨询 ComplianceAgent，确保贷款符合法律与监管要求
-
若获批，则交由 DisbursementAgent 安排资金划拨。
结语
Agent2Agent（A2A）是大规模多代理系统中缺失的关键环节。借助清晰的代理边界、基于结构化任务的通信，以及对流式与推送的内置支持，它能够构建模块化、可发现且可扩展的代理生态。
A2A 针对企业的真实需求而设计，具备安全、异步、多模态灵活与厂商无关等特性。无论您使用 Google 的 ADK、LangGraph、CrewAI，或您自己的框架，A2A 都能让您的代理与代理高效对话。
如需进一步了解 AI 代理，推荐阅读以下博文：
AI 代理正在重塑任务自动化、决策制定和软件系统协作方式。随着组织构建更多自主代理，跨厂商与框架的标准化通信变得至关重要。这正是 Agent2Agent（A2A） 大显身手之处。
A2A 是由 Google 开发的开放、与厂商无关的协议，旨在标准化不同系统中 AI 代理之间的协作。
在本教程中，我将带您理解 A2A 的工作机制、设计原则，以及它如何为跨领域的真实多代理工作流提供支持，并与 MCP 有何不同。
什么是 Agent2Agent（A2A）？
Agent2Agent（A2A）是一种开放协议，使得不透明（黑盒）代理之间能够互操作。它使 AI 代理可以：
让我通过下图来解释 A2A 的核心思想：
图中展示了两个代理：一个 Google 代理（蓝色）和另一个代理（绿色），可能来自第三方服务。两者尝试处理两类文档或任务。绿色代理两个都成功（绿勾），而 Google 代理一个成功、一个失败。
这种差异凸显了协商与信息共享的必要性，而这正是 A2A 协议的核心组成部分。
Agent2Agent 的设计原则
A2A 围绕五项核心原则设计，以便在不共享记忆、想法或工具的前提下为终端用户完成任务。这五项原则包括：
这些设计原则使 A2A 成为可扩展、面向企业的多代理生态系统的中枢。
A2A 如何工作？
本节将深入探讨 Agent2Agent 协议的内部机制，了解代理通信的架构与生命周期。我们将探索涉及的主要参与者、传输与认证层，以及通过 Agent Card 的发现机制。
参与者与协议
A2A 协议定义了三类核心参与者：
回到上面的示意图，蓝色代理是客户端代理，绿色代理是远程代理。
Agent Card 与发现机制
代理通过名为 Agent Card 的标准化 JSON 文档发布其元数据与能力，通常托管在
/.well-known/agent.json。该卡片包含：发现机制可以通过 DNS、注册表、市场或私有目录来实现。
核心通信对象
A2A 通信的核心是
Task，即表示原子工作单元的结构化对象。任务具有提交（submitted）、处理中（working）、需要输入（input-required）或完成（completed）等生命周期状态。每个
Task包含：A2A 工作流示例
下面通过一个工作流示例来理解 A2A 的运作方式：
Task：客户端代理通过 HTTP 上的 JSON-RPC 2.0 向选定的远程代理发送task/send请求。负载包含：task/send。任务完成后，客户端可使用task/get获取所有制品。A2A 示例：IT 服务台工单解决
设想一个企业 IT 服务台系统，使用 AI 代理自主管理并解决支持工单。在该场景中，用户代理接收到如下请求：
随后，用户代理通过 A2A 与多个远程代理协作，编排一条解决流程。
上述场景中，代理通过 A2A 的交互如下：
每个代理独立运行，公开其能力的 Agent Card，并通过结构化任务进行异步通信。代理可能会：
这是一种纯粹的 A2A 用例，因为：
A2A 与 MCP：何时用哪一个？
A2A 与 MCP 在代理系统中解决的是不同但互补的挑战。A2A 专注于让代理以自治对等体的方式协作，而 模型上下文协议（MCP） 旨在将代理与结构化工具和外部资源连接起来。
为什么需要同时使用 A2A 与 MCP？
协议为互操作性建立标准。在代理世界中，两个层面的互操作至关重要：
示例：贷款审批工作流
设想一个为金融机构自动化贷款审批的多代理系统。
在该场景中，A2A 与 MCP 的协同方式如下：
步骤 1：通过工具与 API 进行预处理（MCP）
LoanProcessor代理接收用户提交的贷款申请。它使用 MCP 来：步骤 2：为最终决策进行多代理协同（A2A）
基于步骤 1 的结构化数据，代理使用 A2A 来：
与
RiskAssessmentAgent协作评估借款人风险随后咨询
ComplianceAgent，确保贷款符合法律与监管要求若获批，则交由
DisbursementAgent安排资金划拨。结语
Agent2Agent（A2A）是大规模多代理系统中缺失的关键环节。借助清晰的代理边界、基于结构化任务的通信，以及对流式与推送的内置支持，它能够构建模块化、可发现且可扩展的代理生态。
A2A 针对企业的真实需求而设计，具备安全、异步、多模态灵活与厂商无关等特性。无论您使用 Google 的 ADK、LangGraph、CrewAI，或您自己的框架，A2A 都能让您的代理与代理高效对话。
如需进一步了解 AI 代理，推荐阅读以下博文：