A2A（Agent2Agent）详解：Agent 之间如何发现、接力与协作
A2A（Agent2Agent）详解
引言
Agent2Agent 协议（简称 A2A）由 Google 于 2025 年 4 月提出，是面向多 Agent 协作的开放协议。如果说 MCP 解决的是”一个 Agent 怎么调用工具”，那么 A2A 解决的是”一个 Agent 怎么发现另一个 Agent、把任务交过去、再拿回结果”。
本文是 A2A 的专题详解，读完你会掌握：
- 多 Agent 协作到底难在哪里；
- Agent Card 如何让 Agent 互相”被找到”；
- Task 的完整生命周期与状态机；
- Message 与 Artifact 在协作中扮演什么角色；
- 一次完整的 A2A 协作流程如何走通；
- 它适合解决哪些问题。
前置知识：了解 Agent 和 LLM 基本概念即可。文中事实以官方规范为准，个人理解处会明确标注。
要解决的问题：让 Agent 能”找到彼此并接力”
当一个系统里只有一个 Agent 时，事情很简单——它只管自己干活。但当系统里有多个独立部署、由不同团队维护的 Agent 时，问题就来了：
- 一个”招聘 Agent”想调用”简历解析 Agent”，它怎么知道对方存在、有什么能力、怎么对接？
- 任务可能横跨多个 Agent、持续很久、中途要人补充输入——这种”长链路”如何追踪进度？
- 每个 Agent 内部实现各不相同，怎么做到不侵入对方实现就能协作？
A2A 的答案是：把”发现”和”协作”标准化。它不规定 Agent 内部怎么思考、用什么模型，只约定 Agent 对外如何描述自己、如何收发任务、如何回报状态。就像企业里不同部门之间，不需要知道对方内部怎么运作，只需要一张”部门简介”和一个”工单流程”。
一个生活化比喻：A2A 像企业里的跨部门工单系统。部门 A 要成果但不关心部门 B 内部怎么干活——它提交工单（Task）、说明需求（Message）、跟踪状态、接收交付物（Artifact）。部门 B 靠”部门简介”（Agent Card）被找到，并对外承诺”这类活我能接”。
比喻的边界：工单系统通常有中心调度，而 A2A 协议本身是点对点的，不强制中心节点——只要双方都遵守协议，谁发起都可以。
核心概念：Card / Task / Message / Artifact
A2A 围绕四个核心概念展开：
| 概念 | 作用 |
|---|---|
| Agent Card | Agent 对外发布的 JSON 元数据，让其他 Agent 发现它、判断它是否适合当前任务、知道如何接入 |
| Task | 一个有状态、有生命周期的协作单元，Client 与远端 Agent 围绕它协同 |
| Message | 一轮通信，承载指令、上下文或结果 |
| Artifact | 任务产生的交付物，如文件、报告 |
其中 Task 是 A2A 最核心的设计——它把”一问一答”升级为”可追踪、可接力、可长时运行”的任务模型。
Agent Card：Agent 的”数字名片”
Agent Card 是 A2A 的发现机制。它是一个 JSON 文档，描述 Agent 的身份、能力、技能、接口地址和认证要求，通常发布在 /.well-known/agent-card.json。
其他 Agent 通过读取它来回答三个问题：
- 你是谁——名称、描述、版本；
- 你能做什么——能力列表、技能、接受的输入输出格式；
- 怎么安全地调用你——端点 URL、认证方式。
一份简化的 Agent Card 示例：
1 | { |
Agent Card 的价值在于把”能力发现”从人工配置变成自动化：客户端扫到一份 Card，就知道该不该用、怎么连，从而在运行时动态选择最合适的 Agent。
Task 生命周期：一个有状态的任务模型
A2A 的 Task 有明确的状态机（v1.0 起状态名统一为 TASK_STATE_ 前缀的大写下划线形式）。核心状态包括：
| 状态 | 类型 | 含义 |
|---|---|---|
TASK_STATE_SUBMITTED | 活跃 | 任务已提交并被服务端确认 |
TASK_STATE_WORKING | 活跃 | Agent 正在处理任务 |
TASK_STATE_INPUT_REQUIRED | 中断 | 需要客户端补充更多输入才能继续 |
TASK_STATE_AUTH_REQUIRED | 中断 | 需要额外认证才能继续 |
TASK_STATE_COMPLETED | 终态 | 任务成功完成 |
TASK_STATE_FAILED | 终态 | 任务失败 |
TASK_STATE_CANCELED | 终态 | 任务被取消 |
stateDiagram-v2
[*] --> TASK_STATE_SUBMITTED: 客户端提交任务
TASK_STATE_SUBMITTED --> TASK_STATE_WORKING: 开始处理
TASK_STATE_WORKING --> TASK_STATE_INPUT_REQUIRED: 需要补充输入
TASK_STATE_INPUT_REQUIRED --> TASK_STATE_WORKING: 客户端补齐输入
TASK_STATE_WORKING --> TASK_STATE_COMPLETED: 处理成功
TASK_STATE_WORKING --> TASK_STATE_FAILED: 处理失败
TASK_STATE_WORKING --> TASK_STATE_CANCELED: 客户端取消图 1：A2A 中 Task 的状态机——活跃态、中断态与终态的流转。
这个状态机的意义在于：长任务可以暂停、可被中断、可持续跟踪。比如一个任务需要用户先确认支付，它会进入 INPUT_REQUIRED 停下等待，而不是超时失败——这让跨 Agent、跨人机的复杂流程变得可靠。
Message 与 Artifact：通信与交付
- Message：Client 与 Agent 之间的一轮通信。首次发起 Task 时携带用户指令与上下文，后续可以用来补充信息、回复 Agent 的追问。
- Artifact：任务过程中或完成后产生的产物。Agent 完成任务后，把文件、报告等通过 Artifact 交还给发起方。
两者的分工很清晰：Message 管”怎么说”，Artifact 管”交出什么”。长任务里，Agent 可以在 WORKING 阶段边产出 Artifact 边推送进度，发起方不必干等最后一步。
一次完整的 A2A 协作流程
把以上概念串起来，一次典型协作如下：
sequenceDiagram
participant C as Client Agent（发起方）
participant R as Remote Agent（服务方）
C->>R: 读取 /.well-known/agent-card.json（发现与能力判断）
C->>R: 发起 Task，携带 Message 指令
R-->>C: 确认提交，返回 TASK_STATE_SUBMITTED
R-->>C: 开始处理，状态变为 TASK_STATE_WORKING
R-->>C: 需要补充信息 → TASK_STATE_INPUT_REQUIRED
C->>R: 补充 Message（补齐输入）
R-->>C: 恢复 WORKING
R-->>C: 任务完成，状态 COMPLETED，返回 Artifact 产物图 2：一次 A2A 协作流程——发现 → 提交 → 跟踪 → 中断恢复 → 回收产物。
发起方全程只依赖协议定义的状态与消息，不关心远端 Agent 用什么模型、内部怎么实现。这就是 A2A 让”异构多 Agent”能协作的关键。
版本演进
A2A 规范迭代较快：
- v0.1.0（2025-04）：首个公开版本，确立 Agent Card 与 Task 模型；
- v0.2.0：细化任务管理与交互规范；
- v0.3.0：继续完善状态与发现机制；
- v1.0（及 v1.0.1）：正式化状态枚举（
TASK_STATE_前缀 + 大写下划线命名），任务模型趋于稳定。
从 v0.x 到 v1.0 有一处破坏性变更：状态枚举由小写单词（如 submitted）改为 SCREAMING_SNAKE_CASE（如 TASK_STATE_SUBMITTED）。集成时需注意按目标版本匹配字段写法。
适用场景
A2A 最适合以下情况：
- 多个独立部署、可能由不同团队维护的 Agent 需要协作完成端到端流程；
- 任务周期长、需要持续跟踪状态、可能有人工介入或跨系统接力；
- 需要”Agent 在运行时根据 Agent Card 自动发现并调用另一个 Agent”，而不是写死对接。
典型例子：招聘 Agent 把”简历解析”交给 A2A 对端的专业 Agent，再把”背景调查”接力给第三个 Agent——每个 Agent 独立演进，互不侵入内部实现。
总结
- A2A 由 Google 于 2025 年 4 月提出，目标是标准化多 Agent 之间的发现与协作。
- 四个核心概念：Agent Card（发现与能力描述）、Task（有状态的生命周期）、Message（通信）、Artifact（交付物）。
- 与 MCP 的分工：MCP 管”模型 ↔ 工具”的能力接入（纵向），A2A 管”Agent ↔ Agent”的横向协作。两者常组合使用——Agent 用 MCP 接好工具，用 A2A 去和其他 Agent 协作。