Agent to Agent（A2A）

什么是 Agent to Agent？

Agent to Agent（A2A）是 Google 近期推出的一种开放协议，旨在让不同框架和供应商的 AI Agents 能够互相通信和协作。AI Agents 是能够自主执行任务的系统，比如搜索信息或处理客服查询。A2A 让这些 Agents 能够发现彼此、分享能力，并在安全的环境中协同工作，类似于 USB 或蓝牙让不同品牌的设备互联。

例如，一个擅长搜索的 Agents 可以与擅长总结的 Agents 合作，完成从信息收集到摘要生成的全过程。这种协作对用户透明，提升了任务效率。

Agent to Agent 要解决什么问题？

在人工智能领域，AI Agents 的快速发展带来了新的可能性。这些 Agents 能够自主执行任务、做出决策，并与环境互动，通常依赖大型语言模型（LLMs）等技术。然而，随着 Agents 数量和种类的增加，一个显著问题浮现：不同供应商或框架构建的 AI Agents 之间缺乏有效的通信和协作方式。这限制了它们在复杂、多步骤任务中的应用潜力。

为了解决这一问题，Google 于 2025 年 4 月 9 日推出了 Agent2Agent（A2A）协议，这一开放标准旨在让 AI Agents 实现跨框架和供应商的互操作性。A2A 的目标是建立一个通用的通信语言，让 Agents 能够发现彼此、展示能力、协调任务，并在安全的环境中合作。

使用A2A，Agents 能够在不共享记忆、思维或工具的情况下完成终端用户的任务。取而代之的是，智能体通过各自原生的方式交换上下文、状态、指令和数据。

简洁：复用现有标准
面向企业：支持身份认证、安全性、隐私保护、链路追踪与监控
优先异步：支持（非常）长时间运行的任务和人类参与的流程
模态无关：支持文本、音视频、表单、iframe 等多种交互形式
黑盒执行：智能体无需共享思考过程、计划或工具

A2A 的工作原理

A2A 协议的核心是通过以下步骤实现 Agents 间的通信：

发现机制 ：允许 Agents 通过标准化的方式发现其他 Agents 的存在，类似于网络中的 DNS 发现设备。每个 Agents 有一个公开的 Agent Card 文件（位于 /.well-known/agent.json），包含能力、技能和通信端点，每个 Agent 可以公布自己的技能，例如"搜索信息"、"总结文本"或"处理图像"，便于其他 Agents 根据任务需求选择合作伙伴。。
任务管理：任务是工作的核心单元，有唯一 ID，状态包括提交、处理中、需要输入、完成、失败或取消。确保协作流程顺畅。
消息和内容：通信通过消息进行，消息包含文本、文件或结构化数据（Parts），角色标记为"用户"或"Agents"。
流式传输和推送：支持长时间任务的流式更新（通过 Server-Sent Events）和推送通知（通过 Webhook URL）。

参与者（Actors）

A2A 协议包含三个核心参与者：

用户（User）： 使用智能体系统完成任务的终端用户（可以是人类，也可以是服务）。
客户端（Client）： 代表用户向一个"黑盒"智能体发起任务请求的实体（可以是服务、Agents 或应用）。
远程 智能体 / 服务器（Remote Agent / Server）： 黑盒智能体，即 A2A 协议的服务端。

传输方式（Transport）

A2A 协议使用 HTTP 作为客户端与远程智能体之间的传输协议。根据客户端和远程智能体的能力，它们还可以使用 SSE （Server-Sent Events） 以支持服务器向客户端推送实时更新的流式通信。

在客户端与远程智能体之间的数据交换格式，A2A 协议采用的是 JSON-RPC 2.0。

异步通信（Async）

A2A 客户端与服务端可以使用标准的请求/响应模式，并通过轮询获取更新。然而，A2A 也支持更高效的异步通信方式：

当客户端处于连接状态时，可通过 SSE （Server-Sent Events） 接收实时流式更新；
当客户端处于断开状态时，也可通过 推送通知 接收异步更新。

这使得 A2A 能够灵活适配各种任务持续时间和网络状态下的通信需求。

身份验证与授权（Authentication and Authorization）

A2A 将 Agents 建模为企业级应用（由于 A2A 智能体是"黑盒"的，不共享工具和资源，因此可行），这使得 Agents 间互操作迅速具备企业级能力。

身份验证 规范： A2A 遵循 OpenAPI 的身份验证规范进行认证。值得注意的是，A2A 协议中不会在协议中交换身份信息 。 Agents 应通过带外（out-of-band）方式 获取认证信息（如 Token），并通过 HTTP Header 传递这些信息，而不是在 A2A Payload 中传输。
服务器身份要求声明 ：尽管 A2A 不在协议内直接传输身份信息，但服务端会在 A2A Payload 中声明其认证要求。至少，服务端应在其 Agent Card 中公开其身份认证要求。
客户端认证流程 ：客户端应选择服务端公布的一种认证协议完成身份认证，并获取认证材料。服务端应对每个请求进行身份验证，并使用标准 HTTP 状态码（如 401 Unauthorized、403 Forbidden）以及认证协议特定的 Header 与响应体进行响应（例如通过 WWW-Authenticate Header 提示所需认证方案，或在某个 well-known 路径下提供 OIDC 发现文档）。更多细节可参考 Enterprise Ready 章节。
运行中追加认证 ：若智能体在任务执行过程中需要客户端/用户提供额外的认证信息（例如访问某个工具所需权限），则应返回一个任务状态为 Input-Required 的响应，并在 Payload 中携带一个 Authentication 结构。此时客户端也应通过带外方式获取新的认证材料。

这套机制确保了 A2A 在不暴露身份信息的前提下，仍可安全、标准地支持企业级身份验证与权限管理。

Agent Card

支持 A2A 协议的远程智能体必须以 JSON 格式 发布一份 Agent Card（智能体卡片） ，用于描述该智能体的能力（capabilities/skills）以及身份认证机制。

客户端会使用 Agent Card 中的信息来：

判断该智能体是否具备完成某项任务的能力；
获取所需的身份认证方式；
并基于 A2A 协议与该远程智能体建立通信。

发现机制（Discovery）

A2A 协议让 Agent 能够互相发现，是整个 A2A 协议中最基础也是最关键的环节。每个 Agent 公开一个 JSON 文件，称为 Agent Card，位于https://<base-url>/.well-known/agent.json，包含能力、技能和通信端点。客户端通过 HTTP 请求获取此文件，了解 Agent 功能并选择合适的合作伙伴。

一个 Agent 需要找到另一个它想要与之通信的 Agent。
发现机制不是 A2A 协议本身强制规定的，可以有多种实现方式，例如：
- 通过用户手动操作（如扫描二维码、点击链接）。
- 通过共享的发现服务（类似通讯录）。
- 通过物理邻近（如使用蓝牙、Wi-Fi Direct 等底层技术，虽然 A2A 主要面向 Web）。
发现过程的目标是让两个 Agent 能够交换初始的连接信息（比如对方的公钥或一个临时的连接标识符）。

Agent-to-Agent 通信（智能体间通信）

客户端与远程智能体之间的通信是围绕任务完成 而展开的，多个智能体可以协同合作，以满足最终用户的请求。在 A2A 协议中，Task（任务）对象是客户端与远程智能体协同完成任务的核心载体。

任务执行模型

即时完成：某些任务由远程智能体接收后可以立即完成并返回结果。
长时间运行：对于耗时较长的任务，客户端可以通过轮询（polling）方式，周期性地向智能体请求任务最新状态。
推送更新 ：如果客户端与远程智能体保持连接，智能体也可以通过 SSE （Server-Sent Events） 向客户端实时推送任务状态更新。若客户端处于离线状态，也可以通过外部通知服务向其推送更新。

核心对象（Core Objects）

任务（Task）

任务是一个有状态的实体，允许客户端和远程 Agent 达成特定结果并生成结果。客户端和远程 Agent 在任务中交换消息。远程 Agent 生成结果作为制品。

任务总是由客户端创建，状态总是由远程 Agent 确定。如果客户端需要，多个任务可以作为一个共同会话的一部分（通过可选的 sessionId 标识）。为此，客户端在创建任务时设置可选的 sessionId。

Agent 可以：

立即完成请求
将工作安排到后续时间
拒绝请求
协商不同的方式
向客户端请求更多信息
委托给其他 Agent 和系统即使目标已经完成，客户端仍然可以请求更多信息或在同一任务的上下文中进行更改。（例如，客户端："画一只兔子的画"，Agent："<画>"，客户端："把它弄成红色"）。

任务用于传输制品（结果）和消息（思想、指令、其他内容）。任务维护一个状态和可选的状态及消息历史记录。

消息（Message）

消息包含任何不是制品的内容。它可以包括 Agent 的思维、用户上下文、指令、错误、状态或元数据等内容。

所有来自客户端的内容都是以消息的形式发送的。Agent 发送消息以传达状态或提供指令（而生成的结果作为制品发送）。

消息可以有多个部分，以表示不同的内容。例如，用户请求可能包括用户的文本描述，然后是多个文件，作为客户端的上下文。