Agent2Agent (A2A) Protocol（ A2A 协议）简介、组件-平芜编程栈

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 能显著降低 “每对代理都要写专门接口” 的复杂度。
安全、能力匹配、任务生命周期管理、多模态支持都是必须重点考虑的方面。