Google 的 Agent2Agent 协议 （A2A）：带示例的指南
了解 Google 的 Agent2Agent （A2A），这是一种用于跨不同系统进行 AI 代理协作的开放协议
AI 代理正在重塑任务自动化、决策制定和软件系统协作的方式。但是，随着组织构建更多的自主代理，跨供应商和框架的标准化通信需求变得至关重要。这就是 Agent2Agent （A2A） 的用武之地。
A2A 是由 Google 开发的一种开放的、供应商中立的协议，用于标准化跨不同系统的 AI 代理之间的协作。
在本教程中，我将指导您了解 A2A 的工作原理、其设计原则、它如何为跨域的实际多代理工作流提供支持，以及它与 MCP 有何不同。
Agent 2 Agent （A2A）
Agent2Agent （A2A） 是一种开放协议，可实现不透明（黑盒）代理之间的互作性。它允许 AI 代理：
- 发现彼此
- Exchange 结构化任务
- 流响应
- 处理多轮次对话
- 跨文本、图像、视频和数据等形式进行作。
让我试着通过下图来解释 A2A 的主要思想：
在图像中，表示两个代理：一个 Google 代理（蓝色）和另一个代理（绿色），可能来自第三方服务。两个代理都尝试处理两种类型的文档或任务。绿色代理在这两个方面都成功，如绿色复选标记所示，而 Google 代理在一个方面成功，另一个失败。
这种差异凸显了谈判和信息共享的必要性，这是 A2A 协议的核心组成部分
Agent2Agent 设计原则
A2A 围绕五个核心原则设计，无需共享内存、想法或工具即可为最终用户完成任务。这五项原则包括：
- 采用代理功能：代理在不共享内存、工具或执行计划的情况下进行协作。
- 基于开放标准构建：A2A 使用 HTTP、JSON-RPC 和 SSE 来确保与现有技术堆栈的轻松互作性。
- 默认安全：它遵循 OpenAPI 身份验证方案并提供企业级安全性。
- 支持长时间运行的任务：A2A 旨在处理后台任务、人机协同审批和流式更新。
- 模态不可知：它处理图像、音频、PDF、HTML、JSON 和其他结构化/非结构化格式。
这些设计原则使 A2A 成为可扩展、企业就绪、多代理生态系统的支柱
A2A 如何工作
在本节中，我们将深入探讨 Agent2Agent 协议的内部工作原理，并了解代理通信的架构和生命周期。我们将探讨涉及的主要参与者、传输和身份验证层，以及通过 Agent Cards 进行发现。
参与者和协议
A2A 协议定义了三个核心参与者：
- 用户：启动任务的最终用户。
- 客户端代理：代表用户制定和发送任务的请求者。
- 远程代理：执行任务并发回结果的接收者代理。
回到上面的图表示例，蓝色代理是客户端代理，绿色代理是远程代理
代理卡和发现
代理通过称为代理卡的标准化 JSON 文档发布其元数据和功能，该文档通常托管在
/.well-known/agent.json。此卡内含：
- 名称、版本和托管 URL
- 描述和服务提供商
- 支持的输入/输出模式和内容类型
- 身份验证方法
- 带有标签和示例的代理技能列表
可以通过 DNS、注册表、市场或私有目录处理发现
核心通信对象
A2A 通信的核心是
Task，即表示原子工作单元的结构化对象。任务具有生命周期状态，例如 submitted、working 、input-required 或 completed。每个
任务包括：
- 消息：这些用于客户端和远程代理之间的对话交换
- 构件：这些构件适用于远程代理创建的不可变结果。
- 部分：消息或项目（如纯文本、文件 blob 或 JSON）中的自包含数据块
A2A 工作流程
让我们通过一个示例工作流来了解 A2A 的工作原理：
**用户发起任务：**用户向 Client Agent 发送请求，例如，"安排笔记本电脑更换"。
客户端代理发现远程代理：客户端代理使用托管在公共或私有 URL 上的代理卡查找其他功能强大的代理 。此 JSON 文件包括技能、支持的形式、身份验证和服务 URL。
**客户端代理发送
任务：**客户端代理使用 HTTP上的 JSON-RPC 2.0 向选定的远程代理发送任务/发送请求。有效负载包含：
- 任务 ID
- 会话 ID（可选）
- 具有一个或多个部分（例如，文本、文件、JSON）的消息
**远程代理响应：**远程代理处理任务并响应：
- 即时结果（通过工件）
- 中间消息（通过消息）
- 或请求更多信息（将 state 设置为 input-required）
流式处理和推送更新（如果异步 ）：如果任务长时间运行，则远程代理可能会使用服务器发送的事件 （SSE） 将部分结果流式传输回去。如果客户端断开连接，则可以将推送通知发送到客户端提供的安全 Webhook。
**任务状态转换：**任务在以下状态之间转换：已提交→正在处理→需要输入→已完成。在任何时候，代理都可能为客户端发出更新或新项目。
**构件和消息：**消息用于沟通或澄清（例如，"请上传您的收据"），而构件则用于展示最终输出，如报告 PDF、分析摘要、JSON 列表等。
**客户端代理恢复或完成任务：**如果需要输入，客户端代理会从用户那里收集该输入并发送后续
任务/发送。任务完成后，客户端可以使用task/get获取所有工件
A2A 示例：IT 帮助台票证解析
想象一下，一个企业 IT 帮助台系统使用 AI 代理自主管理和解决支持票证。在此设置中，用户代理会收到如下请求：
bash
"My laptop isn't turning on after the last software update."然后，用户代理通过 A2A 与多个远程代理协作，从而编排解决工作流程
以下是代理在上述场景中通过 A2A 进行交互的方式：
- 客户端代理向硬件诊断代理发送任务，要求进行设备检查。
- 如果硬件正常，它会升级到 Software Rollback Agent，该代理会评估最近的更新。
- 如果回滚失败，则使用 Device Replacement Agent 来启动硬件交换。
每个代理独立运行，公开代理卡及其功能，并通过结构化任务异步通信。代理人可以：
- 将日志或诊断作为项目流式传输
- 如果需要用户输入，则暂停流
- 在他们完成其部分时发送推送更新
这是一个纯粹的 A2A 用例，因为：
- 不涉及 API 或 OCR 引擎等结构化工具
- 所有协调都发生在不透明的协作代理之间
- 代理就像具有单个决策逻辑和本机模态处理的 Peer 节点
结论
Agent2Agent （A2A） 是大规模多代理系统中缺失的一环。凭借清晰的代理边界、基于任务的结构化通信以及对流式传输和推送的内置支持，它支持模块化、可发现和可扩展的代理生态系统。
A2A 专为满足企业的实际需求而设计，具有安全、异步、模态灵活且与供应商无关的特点。无论您使用的是 Google 的 ADK、LangGraph、CrewAI 还是您的框架，A2A 都可以帮助您的代理与代理交谈