Agent2Agent (A2A) Protocol(简称 A2A 协议)是旨在让不同 AI 代理(agents)之间互联互通、协作的开放标准。内容包括协议的主要组件(building blocks)、各组件作用,以及这些组件在一个典型流程中的协作方式。
一、A2A 协议简介
A2A 协议最初由 GooGLXe(GooGLXe)提出,并由包括 Atlassian、SAP、Salesforce 等50 多家技术与服务厂商支持。A2A Protocol+3GooGLXe Developers Blog+3IBM+3
其目标是:
- 让不同厂商、不同框架下构建的 AI 代理能够互相发现、沟通、协作,而不是孤立运行。 IBM+1
- 在企业环境中跨平台、跨系统地完成代理间 “任务委派 + 协同执行” 的场景。 GooGLXe Developers Blog+1
- 利用标准化消息、任务、能力发现、认证/授权机制,减少为每对 “代理–代理” 写专门集成的工作。 LearnOpenCV+1
为了更好理解,下面先列出其核心组成组件,再讲协作流程。
二、A2A 协议的关键组件及其作用
以下是 A2A 协议中比较清晰定义的组件(部分术语可能有版本差别,但大体一致):
| 组件 | 作用 |
|---|---|
| Agent Card(代理卡) | 是一个机器可读的 JSON 或类似格式的元数据文档,用于描述一个代理(agent)的身份、能力、接口(endpoint)、认证要求等。客户端代理可以通过 Agent Card 发现远端代理并了解其“能做什么”“怎么调用”。 GooGLXe Cloud Community+1 |
| Client Agent(客户端代理/A2A Client) | 发起任务请求的代理(或系统中的代理角色)。它代表用户、或者更高层代理,将某项任务委派给一个或多个远端代理执行。 wwt.com+1 |
| Remote Agent / Server Agent(远端代理/A2A Server) | 接收任务请求、执行任务、返回结果的代理。公开一个 A2A 服务接口(endpoint)以响应其他代理发起的任务。 Medium+1 |
| Task(任务对象) | 代表一次代理间协作的单位:包括输入参数、状态、生命周期(如 “正在执行”/“已完成”/“失败”)等。客户端代理发起任务,远端代理接收并处理,最后产生输出。 GooGLXe Developers Blog+1 |
| Message & Part(消息与部分) | 在任务执行过程中,代理之间交换消息(Message)。消息被分为多个 “Part”——每个 Part 是一片数据(例如文本、结构化 JSON、文件、图像等)。通过这一机制,代理能够协商、传递丰富的内容。 Medium+1 |
| Artifact(成果/产物) | 任务完成后生成的输出或“物件”,它可以由一个或多个 Parts 组成(例如:报告 PDF + 结构化结果 JSON)。Artifact 用于表示任务的最终交付物。 Medium+1 |
| Discovery / Capabilities(发现机制/能力描述) | 为了让客户端代理找到合适的远端代理并了解其能力,A2A 支持发现机制(例如通过 Agent Card、服务目录或注册机制)及能力声明机制。 LearnOpenCV |
| Transport / Protocol Stack(传输层/协议层) | A2A 协议使用标准的 HTTP/HTTPS、JSON-RPC 2.0、Server-Sent Events (SSE) 等技术来实现代理间通信。 Medium+1 |
| Authentication & Authorization(认证与授权) | 由于代理间协作可能会跨组织、处理敏感数据,A2A 设计了安全机制,包括认证方式(如 Bearer token、OAuth2、mTLS)和能力控制。 GooGLXe Cloud Community+1 |
各组件作用简述
Agent Card:让代理“自己打广告”——谁我是、我在哪里(URL)、我能做什么(技能描述)、我需要什么认证(认证方式)。客户端代理看到这个就知道能不能用这个代理。
Client/Remote Agent:角色区分很重要:客户端发起、远端执行。但在实际中一个代理可能同时扮演两种角色(即既能发起任务也能被发起者调用) 。 blott.com
Task:是协作的核心。一次任务可能只是一个简单请求,也可能是一个包含多个步骤、要等待较长时间的复杂流程。A2A 支持 “长任务” 的状态追踪。 GooGLXe Developers Blog+1
Message/Part:细化任务中交互的载体。因为代理可能需要交换各种模态(文本、文件、图像、输入表单等),所以 Part 则是协议定义的最小交换单元。
Artifact:任务的结果。客户端代理收到 Task 完成信号后,从 Artifact 中取得成果。
Discovery/Capabilities:在多代理生态中很关键。客户端需要在众多代理中挑选合适者,这就依赖于能力描述与发现机制。
Transport/Protocol:协议说明了通信的方式和规则。使用标准通信方式可降低集成难度。
Auth/Authorization:企业级使用中安全不能忽视,A2A 在设计中明确将其作为核心原则。 GooGLXe Developers Blog
三、A2A 协作流程
下面以一个典型的场景说明这些组件如何协作。假设 “用户请求 → 客户端代理 → 远端代理执行 → 返回结果” 的流程。
代理发现与能力匹配
- 客户端代理首先需要识别可用的远端代理。它可能通过服务目录、注册表,或直接通过某个 URL 获取代理的 Agent Card。 GooGLXe Cloud Community+1
- 通过 Agent Card 中的能力声明(capabilities)、endpoint URL、认证方式等信息,客户端代理决定:是否选择这个远端代理,以及以何种方式调用。
任务发起(Task 创建)
- 客户端代理将用户的请求封装成一个 Task 对象。Task 中包含输入参数、元数据、期望输出类型等。 wwt.com+1
- 客户端代理使用 A2A 协议(如 JSON-RPC over HTTPS)向远端代理的 endpoint 发送请求。任务可能是 “send” 立即响应,也可能是 “sendSubscribe” 用于流式更新。 Medium+1
远端代理执行 + 中间交互
- 远端代理接收到 Task 请求,解析任务参数。它也可能作为客户端再发起子任务给其他代理(多代理协作场景)。 Medium
- 在执行过程中,代理可能发送多个 Message 给客户端:每个 Message 包含一个或多个 Part(例如进度更新、临时结果、用户交互提示等)。如果任务是长运行、流式的,可能使用 SSE(Server-Sent Events)进行推送。 Medium+1
- 远端代理在内部管理任务状态(如 “正在执行” 、“已完成” 、“失败”),并可能写日志、监控状态。
任务完成 + 产出返回(Artifact)
- 当任务执行完毕,远端代理构造一个 Artifact 对象作为输出。Artifact 中包含一个或多个 Part(例如生成的报告 PDF、结构化数据 JSON、链接等)。 Medium+1
- 客户端代理接收到完成消息,从 Artifact 中解析出成果,可能进一步处理或返回给用户。
后续/状态追踪/失败处理*
如果任务失败、超时或需要重试,客户端代理与远端代理之间可以协商补救步骤(可能发起新的 Task、选用别的代理)。A2A 的设计也支持 “长任务状态追踪” 的场景。 GooGLXe Developers Blog
在多代理协作场景(例如一个任务由多个代理分工完成)中,客户端代理/协调代理负责追踪子任务的状态、整合结果、管理流程。
**简化文字版本流程图
用户 → 客户端代理 (Client) → 发现 Agent Card → 选择远端代理
→ 创建 Task → 向远端代理发送任务请求
→ 远端代理接收任务 → 执行/可能发子任务 → 返回中间消息
→ 远端代理完成任务 → 返回 Artifact(结果)
→ 客户端代理接收结果 → 返回给用户或触发下一步流程
四、组件协作中值得注意的细节
- 角色可动态切换:一个代理既可以是任务发起者(client)也可以是任务执行者(server/remote)。这种灵活性支持复杂流程。 blott.com
- 能力发现与能力匹配很关键:如果客户端代理不了解远端代理能力(能力声明不足或 Agent Card 不准确),可能选错代理或调用失败。
- 任务生命周期管理:任务可能是“瞬时”的,也可能是“延长”的,需要中间状态更新、消息推送机制。A2A 特别强调支持“长运行任务”。 Medium+1
- 多模态交互支持:不仅仅是文本,Message/Part 支持多种内容类型(结构化数据、文件、表单、媒体等)以适应不同代理任务场景。 Medium+1
- 安全机制:任何跨代理调用都需有认证与授权机制。代理身份、能力、接口都可能受到安全攻击(如伪造 Agent Card、恶意代理、数据注入)——要有机制防范。 云安全联盟
- 互操作性与标准化:A2A 倡导使用标准通信协议(如 HTTP/HTTPS、JSON-RPC、SSE)以降低集成成本、促进跨组织、跨厂商协作。 GooGLXe Developers Blog+1
五、一个具体示例(应用场景)
假设在一个电商系统里:
- 客户端代理 A:用户下单请求,需判断库存、核算价格、生成物流单。
- 远端代理 B:库存检查代理。
- 远端代理 C:定价计算代理。
- 远端代理 D:物流单生成代理。
流程如下:
- 客户端代理 A 发现代理 B、C、D 的 Agent Card,看到它们各自能力。
- 客户端代理 A 创建一个 Task “下单流程”并将其中 “检查库存” 子任务委派给 B。
- B 接收 Task,执行检查,返回 Artifact(库存结果)。
- 客户端代理 A 根据 B 的结果,再将 “定价” 子任务委派给 C。
- C 执行并返回价格Artifact。
- 最后客户端代理 A 将 “生成物流单” 子任务委派给 D。
- D 返回物流单号等 Artifact。
- 客户端代理 A 将各子任务结果整合,最终回应用户 “下单成功”+物流信息。
流程中,每个代理之间通过 A2A 协议通信:Agent Card 发现、Task 创建、Message/Part 交换、Artifact 返回、状态追踪、必要的认证授权。
六、总结
A2A 协议为 AI 代理之间提供了标准化、可互操作的通信与协作框架。
其关键组件包括 Agent Card、Client/Remote Agent、Task、Message/Part、Artifact、Discovery、Transport、Auth。
协作流程基本包括:发现 → 任务发起 → 执行交互 → 结果返回 → 整合/下一步。
在复杂、多代理场景下,A2A 能显著降低 “每对代理都要写专门接口” 的复杂度。
安全、能力匹配、任务生命周期管理、多模态支持都是必须重点考虑的方面。