理解A2A-Agent协作协议

Agent to Agent 协议(A2A)面向Agent间的通信，通过标准化协议统一实现：

Agent可以动态发现彼此
通过标准化的任务进行协作
传输多模态内容
支持长时间运行任务
保证企业级安全

组件化构建

Agent Card

A2A的发现机制核心是Agent Card，本质上是一个公开且机器可读的JSON元数据文档
Card的核心内容包括：

身份描述：Agent本身的详细信息
服务端点：A2A服务器可以被访问的URL
认证要求：支持多种认证方案
功能：关于Agent操作功能的信息，例如是否支持流式输出、推送通知
技能：Agent主要负责的具体任务和功能

Task

A2A通过Task实现Agent间的协作任务传递，同时Task是有状态的。可以将Task理解成智能工单，它记录某个目标从提出、执行、补充信息到最终交付的全过程。
Task 是 A2A 中可识别、可跟踪、可多轮交互、可暂停补充信息，并能最终交付成果的一张智能工单。
Task的核心特性：（客户端:发起任务的Agent, 服务端:接收任务的Agent）

明确目标：一个 Task 对应一件需要完成的事
唯一ID：每个 Task 都有唯一标识（一般是UUID），之后客户端查询进度、补充信息或取消任务时，都通过这个 ID 指明是哪一张工单

完整生命周期：Task 会随着处理过程改变状态：

状态	通俗含义
`submitted`	工单已经提交
`working`	服务端 Agent 正在处理
`input-required`	缺少信息，需要客户端补充
`completed`	成功完成
`failed`	执行失败
`canceled`	任务被取消

有状态：服务端会记住这个任务之前发生了什么，因此，同一个 Task 可以包含多轮 Message
支持补充信息：服务端支持在缺少信息的时候不直接报错，而是可以把状态改为：input-required，并发送消息要求客户端补充信息。客户端补充信息后，原 Task 继续执行，不需要重新创建整个任务。（相对Agent as tool更贴合Agent的定义）
可以产出多个成果(Artifact)：支持返回多个成果，例如json、png、pdf...
保存客户端与服务端的对话历史，方便追踪审计排查问题
可以与其他Task建立上下文关系：Task可以通过contextID归入同一个上下文

Message

Message表示任务上下文中的单个通信回合。它们包含初始请求、后续输入、状态更新或Agent中间推理步骤等内容。一个关键字段是 role ，它指定发起者为 "user" （客户端Agent）或 "agent" （远程/服务器Agent）。每条消息包含一个或多个包含实际内容的部件。

Part

Part是Message或Artifacts的组成单位。如果把 Task 比作一张工单，Message 比作工单中的一条消息，那么 Part 就是消息里的“文字、附件或结构化数据”。

Task：分析销售数据
 ├─ Message：请分析这份数据
 │   ├─ TextPart：分析最近三个月的销售趋势
 │   └─ FilePart：sales.xlsx
 │
 └─ Artifact：分析结果
     ├─ TextPart：总体销售额增长了 15%
     ├─ DataPart：各地区销售统计 JSON
     └─ FilePart：销售分析报告.pdf

Part的最大作用是区分不同类型的数据：A2A 不把所有东西都塞进一段字符串，而是拆成多个有明确类型的 Part。主要类型有文本、文件、JSON
使用mimeType来说明文件格式。

Artifact

Secure notifications

Secure notifications安全通知主要是面向服务端Agent执行长耗时任务时，为客户端提供一个回调接口，让客户端不需要一直与服务端Agent一直保持连接通过SSE接收进度或者定时轮询就能获取到任务完成通知。
基本流程：

① 客户端提交 Task
   同时登记通知地址 webhook

客户端 ──────────────────────→ A2A 服务端
        callbackUrl + 配置

② 服务端在后台执行

客户端可以暂时断开             服务端继续工作

③ Task 状态变化后，服务端发送通知

A2A 服务端 ── 带签名的 JWT ──→ 通知服务/webhook
                               ↓
                         验证通知真实性
                               ↓
                         转发给客户端系统

另外安全性由JWT保证，因为 webhook 是一个公开网络地址。任何人理论上都可能向它发送 HTTP 请求。同时：接收通知的系统不一定就是最初的客户端 Agent，也可能是企业的统一通知服务，这样，每个 Agent 不需要单独暴露公网 webhook，可以由一个安全、集中管理的通知层统一接收。

A2A 服务端
      ↓ 安全通知
PushNotificationService
      ├─ 验证 JWT
      ├─ 查找对应 Task
      └─ 转发到：
          ├─ 客户端 Agent
          ├─ 消息队列
          ├─ 邮件系统
          └─ 下游 API

JWT的关键信息：

字段	通俗含义
`iss`	谁发出的通知
`aud`	通知发给谁，通常对应 webhook 地址
`iat`	JWT 什么时候签发
`exp`	什么时候失效
`jti`	本次通知的唯一编号
`taskId`	对应哪个 Task
`kid`	使用服务端的哪把密钥签名
`alg`	使用什么签名算法

底层架构

A2A的通信技术栈：

HTTPs：基础传输层。所有生产部署都需要使用现代 TLS 加密的 HTTPS，以确保传输中的隐私和完整性。
JSON-RPC 2.0：一种轻量级的基于 JSON 的远程过程调用格式，用于调用 A2A 方法如 message/send 。它标准化了代理请求和响应操作的方式。
SSE：为了实现实时、服务器到客户端的通信（尤其是在像 message/stream 这样的流式场景中），A2A 选择使用 SSE 而不是 WebSocket。这个决定反映了一个实际的权衡：SSE 是单向的，对防火墙友好，并且对于任务更新等常见用例更容易实现。

基本流程

1. 发现：客户端代理从 /.well-known/agent.json 获取远程代理的代理卡，以了解其功能、端点、认证和通信模式。
2. 启动：客户端生成一个唯一的任务 ID，并通过发送初始消息来启动任务。这使用以下方式之一：
3. message/send ：用于同步交互或当客户端打算使用 tasks/get 对长时间运行的任务进行轮询更新。
4. message/stream : 通过服务器发送事件（SSE）建立流式连接以进行实时更新，适用于长时间运行的任务或当增量结果有益时。
5. 处理： (流式传输)：服务器在任务进行过程中发送 SSE 事件（状态更新、工件）。(非流式传输)：服务器同步处理任务，并在响应中返回最终的 Task 对象，或客户端使用 tasks/get 进行轮询。
6. 交互（可选）：如果远程代理需要更多信息，它会将任务状态转换为 input-required 。然后客户端可以发送后续消息，包含请求的输入。
7. 完成：任务以最终状态结束： completed 、 failed 或 canceled （客户端通过 tasks/cancel 请求或服务器终止）。

支持多种执行方式

Agent执行的任务会有多种类型，主要以执行时长为主要区别
A2A提供2种核心交互模式：

message/send：预期同步响应的任务，或客户端将轮询更新的任务。
message/stream：通过服务器发送事件（SSE）实时获取进度更新的任务。
在流式模式下，Agent可以发送以下事件：
TaskStatusUpdateEvent：信号生命周期变化（working->completed）
TaskArtifactUpdateEvent：分享中间或最终输出

除此之外：

tasks/get：如果客户端不使用流式传输，用于轮询任务状态
tasks/cancel：用于按需终止任务
tasks/pushNotification/set：用于在客户端无法维持持久连接时注册 webhook 以进行异步更新

posted @ 2026-07-14 13:37 Asakeiii 阅读(14) 评论(0) 收藏举报

刷新页面返回顶部

Asakei