什么是 Agent2Agent (A2A)？AI 代理如何通信与协作

Agent2Agent (A2A) 是一种开放协议，使 AI 代理能够相互发现、交换消息、委派任务、报告进度并跨系统边界返回结果。 它旨在用于一个代理需要另一个代理帮助的情形，而无需任一方暴露其内部推理、记忆或实现细节。

随着组织部署专用代理，通信变成了基础设施问题。采购代理可能需要从合规代理获取信息；客服代理可能需要物流代理来调查货运。A2A 提供了一种通用方式来协调这些工作，即使代理使用不同的框架、供应商或模型。

为什么代理需要通信标准

传统 API 公开函数和数据，但代理对代理的交互可能更为开放。接收代理可能需要解释目标、决定解决方案、提出后续问题、工作数分钟或数小时、流式更新，并返回多个制品。

如果没有共享协议，每个平台都会为身份、能力发现、任务、消息、状态和错误定义各自的格式。这种碎片化使跨平台委派变得困难，并将有用的代理锁定在单个产品内部。

A2A 标准化了通信层，同时允许每个代理保持为黑箱。当前 A2A 规范 定义了协议的核心对象和交互。

A2A 中的关键角色

这种分离正是 A2A 与普通函数调用不同之处。远程参与者可以管理长期任务、请求额外信息、协商支持的内容类型，并返回一个或多个制品。客户端代理在跟踪该任务的同时，保留发起任务的用户或应用程序的身份和权限。

一次 A2A 交互通常涉及两个逻辑角色：

• 客户端代理： 请求工作 的代理或应用程序。
• 远程代理： 接收请求并执行或协调工作的代理。

“客户端”和“远程”这两个词描述的是当前的交互，而非永久的层级关系。同一代理可以在一种情境下请求工作，在另一种情境下为其他代理提供服务。

代理卡：发现能力

在委派任务之前，客户端需要了解远程代理能做什么以及如何与其通信。A2A 使用代理卡来发布描述性和操作性元数据。

代理卡可以描述代理的名称、端点、支持的协议特性、身份验证要求、技能以及接受的内容类型。技能是声明的能力领域，例如翻译文档、审查合同或进行市场调研。

发现并不证明质量或可信度。代理卡是对能力的声明，而非独立的认证。生产系统仍需进行身份、授权、策略检查、声誉和评估。

消息、任务与制品

A2A 通过多个核心对象来表示协作。

消息

消息在代理之间承载通信。它们可以包含文本和其他结构化部分，使代理能够交换指令、澄清或上下文材料。

任务

任务代表一个工作单元，其状态可能随时间变化。远程代理可以接受工作、继续处理、请求更多输入、完成、失败或取消它。持久的任务标识对长期操作很有用，因为客户端可以在更新之间引用同一任务。

制品

制品是工作产生的输出，例如报告、数据集、图像、代码补丁或结构化建议。将制品与对话消息分离，使客户端更容易识别并使用最终交付物。

A2A 交互的工作原理

假设一个旅行规划代理需要专家来核实入境要求。

1. 客户端发现远程代理并阅读其代理卡。
2. 它检查该代理是否宣传相关能力以及兼容的交互方式。
3. 客户端进行身份验证并发送描述任务、旅行者、日期和所需输出的消息。
4. 远程代理创建或更新任务并开始工作。
5. 远程代理可能会流式传输进度或请求缺失的细节。
6. 客户端在保持任务上下文的同时提供澄清。
7. 远程代理完成任务并返回包含结果的结构化产物。
8. 客户端在将其用于更广泛的旅行计划之前评估该结果。

远程代理决定如何完成其任务。它可能调用自己的工具、查询私有数据或协调其他代理。A2A 并不要求披露这些内部步骤。

A2A 与 MCP 对比

这些协议可以位于同一架构的不同层级。旅行规划代理可能通过 A2A 将签证研究的专业任务委托给专家。该专家代理随后可以使用 MCP 连接搜索已批准的数据库并检索政策文件。A2A 协调代理之间的职责；MCP 标准化 AI 主机与功能之间的访问。

A2A 与模型上下文协议解决不同的集成问题。

• MCP 将 AI 应用程序连接到工具和上下文。 客户端从 MCP 服务器发现诸如函数、资源和提示等能力。
• A2A 将代理连接到代理。 客户端将面向目标的任务委托给能够自行管理流程并返回结果的远程代理。

这种差异类似于使用工具与雇佣专家的区别。计算器只提供运算；分析师接受目标并决定需要哪些运算。在实际系统中，远程 A2A 代理可能内部使用 MCP 来访问其自身的工具和数据。

A2A 与普通 API 对比

当调用方明确知道具体操作和输入格式时（如检索记录、计算报价或更新字段），传统 API 是理想选择。A2A 在请求为对话式、状态化、异步或面向结果时更为有用。

A2A 并不取代所有 API。远程代理常常调用普通 API 来完成工作，而当代理的自主判断没有价值时，组织可以直接提供确定性的服务。

为何互操作性重要

代理生态系统将是异构的。不同团队会针对不同领域、模型、安全边界和部署环境进行优化。共享协议使组织能够保留这些专长，同时实现协作。

互操作性也可以降低集成耦合。客户端可以依赖声明的技能和协议行为，而不是导入远程代理的框架或复制其内部逻辑。A2A 项目概述将此目标描述为让不同技术栈构建的代理能够作为对等方进行通信；该项目 2026 年关于加入 Agentic AI Foundation 的更新体现了向中立、跨行业治理的推进。

安全与信任挑战

委托会产生责任链。客户端必须验证远程代理的身份和其声明的能力，尽量减少共享的上下文，并保留发起用户的授权。远程代理不应仅因为另一个代理请求任务而继承广泛的权限。每一次跳转都需要身份验证、受限凭证、可审计性，以及在需求冲突或置信度低时应采取何种措施的明确规则。

代理之间的委托会形成权力链。客户端可能会意外共享敏感上下文，赋予远程代理超出预期的裁量权，或基于不可靠的产物进行操作。远程代理还可能收到来自不可信客户端的恶意指令或文件。

强大的部署需要在多个层面设置控制：

• 身份和认证： 验证参与的代理和组织。
• 授权： 限制每个调用方可使用的技能、数据、操作和任务范围。
• 数据最小化： 仅共享远程代理所需的上下文。
• 来源追溯： 记录谁请求了工作、哪个代理生成了它以及哪些来源支持它。
• 输出验证： 在远程产物通过相关检查之前，将其视为不可信。
• 委托限制： 控制远程代理是否可以涉及其他代理或服务。
• 人工批准： 在进行金融、法律、外部、破坏性或其他可能产生重要后果的操作前暂停。

协议兼容性并不等同于组织信任。代理即使能够正确使用 A2A，也可能不适合特定任务。

团队何时应使用 A2A？

当独立代理需要跨产品、供应商或组织边界协作；工作是长期运行的；或接收系统应保留对结果生成方式的自由时，A2A 最具吸引力。

对于简单函数、固定的内部工作流或单个应用内部紧密耦合的组件，使用 A2A 可能并非必要。在这些情况下，普通的 API、事件总线或直接的工具调用更易于操作和评估。

关于 Agent2Agent (A2A) 的关键要点

A2A 为代理提供了一种通用语言，使其能够在不共享内部机制的情况下发现能力并协调目标导向的工作。其核心价值并非多个代理自动优于单一代理，而是独立构建的专才能够通过稳定的边界进行协作。

该边界必须承载的不仅是消息。它需要身份、任务状态、产物、权限、溯源以及错误处理。A2A 提供协议基础；组织仍需提供信任模型。