A2A 协议精读 — Agent Card、任务委托与长任务生命周期

日期: 2026-08-08 阶段: Phase 2 - AI-native 参考架构 标签: #a2a #agent-card #task-lifecycle #cross-runtime

核心问题

到目前为止 AML Copilot 的多 agent 是进程内的：orchestrator 直接 import 调 runKnowledgeAgent 等子 agent（src/agent/orchestrator/orchestratorAgent.ts），共享内存、共享信任、同生共死。这在单团队单仓库里没问题。但 P4 要对标的「跨云协作」是另一个世界——两个分属不同组织/不同运行时的 agent，互不知道对方内部实现，要安全地委托一个可能跑几分钟的长任务。这正是 A2A（Agent2Agent）协议要解的问题。今天精读三件事：

1. Agent Card / 任务委托 / 长任务生命周期：A2A 的三个核心抽象——「能力广告」「工作单元」「状态机」分别长什么样，为什么长任务必须是状态机而非一次请求-响应。
2. 跨运行时协作语义：两个不透明（opaque）agent 之间，信任、认证、流式更新怎么协商。
3. 为 P4 跨云对标做准备：本项目当前进程内 orchestration 与 A2A 跨进程 orchestration 的边界在哪、哪些抽象可以提前对齐。

对 AML Copilot 的现实意义：合规场景天然是多组织的——银行的 copilot 可能要委托一个外部制裁名单筛查 agent（OFAC/SDN）、一个外部 KYC 验证 agent。这些 agent 不在本仓库、不共享内存，A2A 正是这种「跨信任边界委托」的协议。

关键内容

A. Agent Card：能力广告与信任锚

A2A 的起点是 Agent Card——一份 JSON 元数据文档，是 agent 对外的「名片+能力清单+信任凭证」。它回答「你是谁、你能做什么、怎么安全地连你」。关键字段（A2A 规范，2026）：

{
  "name": "ofac-sanctions-screener",
  "description": "Screens entities against OFAC SDN/consolidated lists",
  "provider": { "organization": "...", "url": "..." },
  "capabilities": {            // 声明支持的传输能力
    "streaming": true,         // 支持 SSE 流式状态更新
    "pushNotifications": true, // 支持 webhook 推送(长任务断连后通知)
    "extendedCard": true       // 支持认证后返回更详细的 card
  },
  "skills": [ { "id": "screen", "description": "...", "inputModes": [...], "outputModes": [...] } ],
  "url": "https://.../a2a",    // service endpoint
  "securitySchemes": { ... },  // API key / OAuth2 / mTLS
  "interfaces": [ ... ]        // 支持的协议绑定(JSON-RPC/gRPC/REST)
}

为什么 Agent Card 是信任锚而非单纯目录：A2A 1.x（2026-04 Cloud Next 生产化，归 Linux Foundation）引入密码学签名的 Agent Card + 域名绑定——这样「Salesforce 的 agent 能认证 Google Vertex 的 agent，而两边无需事先内部互知」。签名解决了跨组织委托的第一性问题：你凭什么相信对面这个 URL 后面真是它声称的那个 agent？没有签名，Agent Card 只是可伪造的自述。

反直觉洞察①（Agent Card 的价值不在「描述能力」而在「让信任可迁移」）：直觉把 Agent Card 当成 OpenAPI 式的接口文档。但跨组织场景里，接口描述是最不值钱的部分——真正难的是信任的传递性：A 信任 B，B 委托给 C，A 如何确信 C 不是冒充的？签名 Agent Card + 域名绑定让信任从「预先配置的白名单」变成「可验证的凭证链」。这也是新攻击面——一个被攻破的、签名合法的 agent 仍能作恶（承 Day 54：信任边界扩大 = 红队须补测被委托 agent 的行为）。

B. 任务委托与长任务生命周期：为什么必须是状态机

A2A 的核心数据流是任务委托。简单情况下，client agent 发一条 Message，remote agent 直接回一条 Message 就结束。但长任务（制裁筛查可能要查多个外部数据源、KYC 可能要等人工复核）不能用一次请求-响应——连接会超时、client 需要中途取消、任务可能需要补充输入。所以 A2A 把长任务建模成一个显式状态机（八态，A2A 规范 2026）：

        SendMessage(委托)
              │
              ▼
        ┌──────────┐
        │ SUBMITTED│ 已受理,未开始
        └────┬─────┘
             ▼
        ┌──────────┐    需补充输入   ┌────────────────┐
        │  WORKING │◄──────────────►│ INPUT_REQUIRED  │(可中断)
        └────┬─────┘                └────────────────┘
             │                       需认证 ┌──────────────┐
             ├──────────────────────────────►│ AUTH_REQUIRED │(可中断)
             │                               └──────────────┘
   ┌─────────┼─────────┬──────────┐
   ▼         ▼         ▼          ▼
┌────────┐┌──────┐┌─────────┐┌──────────┐
│COMPLETED││FAILED││CANCELED ││ REJECTED │  ← 终态
└────────┘└──────┘└─────────┘└──────────┘
   (产出      (出错)  (取消)    (agent 拒接,
   Artifact)                    如越权/不支持)

委托的消息流（client agent ↔ remote agent）：

client                                   remote agent
  │  ── SendMessage{parts, taskId?} ──►   │
  │                                       │ 创建 Task(唯一 id), 状态=SUBMITTED
  │  ◄── Task{id, status:SUBMITTED} ──    │
  │                                       │ 开始处理, 状态=WORKING
  │  ◄── TaskStatusUpdateEvent ───────    │ (SSE 流 / 或轮询 / 或 push webhook)
  │                                       │ 需要更多信息 → INPUT_REQUIRED
  │  ── SendMessage{同 taskId, 补充} ──►   │ 回到 WORKING
  │  ◄── TaskArtifactUpdateEvent ─────    │ 产出 Artifact(parts)
  │  ◄── Task{status:COMPLETED} ──────    │ 终态

三个抽象层次（A2A 规范）：Message（一次通信单元，含 messageId/contextId/taskId/role/parts）、Part（最小内容容器：text/raw base64/url/data JSON 四选一）、Artifact（任务产出，由 Parts 组成，刻意与 Message 分开——把「通信」与「数据产出」解耦）。

反直觉洞察②（长任务的难点不是「等」而是「可中断 + 可恢复」）：把长任务理解成「同步调用但慢」是错的。INPUT_REQUIRED 和 AUTH_REQUIRED 是可中断态而非终态——任务可以停在这里等几分钟甚至几小时（等人工补 KYC 材料）再继续，靠 contextId/taskId 维持会话连续性、靠 push notification 在断连后通知。这意味着 client 端不能持有 in-memory 的任务上下文（进程可能早重启了），必须能凭 taskId 从 remote 拉回状态。本项目现在的进程内 orchestration 把上下文全揣在内存里——这是 A2A 跨进程化时第一个要打破的假设。

C. 跨运行时协作语义与传输绑定

A2A 工作在 Layer 7（应用层），在 service mesh 之上（A2A 1.2 生产口径，2026-04）。它定义四种功能等价的传输绑定（规范要求各绑定提供「functionally equivalent representations」）：

跨运行时的认证协商：Agent Card 的 securitySchemes 声明支持哪些认证（API key / OAuth2 / mTLS）；AUTH_REQUIRED 态允许任务执行中途要求升级认证（如制裁筛查要求 client 出示更高权限凭证才返回命中详情）。这把认证从「连接时一次性」变成「任务生命周期内可分级」——合规场景刚需。

A2A 与 MCP 的分工（规范 Appendix B，2026）——这是本计划最该钉死的一张表，因为两者极易混淆：

关键澄清：A2A 不替代 MCP。一个用 A2A 暴露给外部的「制裁筛查 agent」，其内部很可能用 MCP 去连 OFAC 数据源工具。MCP 是 agent 向下连工具，A2A 是 agent 向外连 agent——正交的两层。

版本诚实标注：本笔记写作时（2026-06-11）存在版本表述差异——官方规范页 a2a-protocol.org/latest/specification 列当前版本为 1.0.0（历经 0.1.0/0.2.6/0.3.0），而行业报道（cloudmagazin / HPCwire AIWire，2026-04）以 「A2A 1.2 生产化」 表述 Cloud Next 2026 发布。二者不矛盾：1.0 是规范文档版本号，「1.2 in production」是产品/部署口径的市场表述。本计划以官方规范版本号为准（1.0.x 系），引用市场口径时显式标注来源，执行 P4 当周须重新核对官方规范页的最新版本号，不沿用本笔记数字。

设计要点/决策表

对本项目的落地

• P4 边界文档先于代码：本项目当前 orchestration（src/agent/orchestrator/orchestratorAgent.ts）是进程内——dispatch* 工具直接 import 子 agent、同步 await、上下文全在内存。A2A 跨进程化的最小改造点（写入 docs/aipa/ 设计笔记，P4 才落代码）：(1) 子 agent 调用结果须能凭 taskId 重新拉取（打破「内存持有上下文」假设）；(2) 子 agent 长任务须暴露状态查询而非只返回最终 text。当前 runKnowledgeAgent 等返回 {text} 一次性结果——对应 A2A 的「simple Message」路径，长任务路径是 P4 增量。
• Agent Card 抽象提前对齐：为三个子 agent（knowledge/research/portfolio）各写一份进程内 Agent Card 形状的能力声明（src/agent/orchestrator/agentCards.ts，仅 name/skills/inputModes），让 orchestrator 的 dispatch 决策从「硬编码三个工具」演进为「按 card 能力路由」——这是把 A2A 的能力广告思想提前内化，即便暂不跨进程。
• 信任闸门复用红队成果：A2A 引入的「被委托 agent 信任边界」正是 Day 54 红队须补测的新攻击面——src/aml/redteam/ 的工具调用层校验闸门（assertToolAllowed）天然可扩展为「跨 agent 委托前的 Agent Card 签名校验」占位（P4 真接外部 agent 时才实现签名验证）。
• MCP/A2A 分工写入架构图：AML Copilot 若 P4 接外部制裁筛查 agent，架构为「本 orchestrator ──A2A──► 外部筛查 agent ──MCP──► OFAC 数据源」，这张正交两层图入 P4 参考架构，避免把 MCP 当 A2A 用的常见误解。
• 诚实标注：agentCards.ts 头注明确 v1 为进程内能力声明，非真实 A2A endpoint；跨进程 A2A server/client、签名 Agent Card、八态状态机均为 P4 计划项，当前不谎称「已支持 A2A」。

参考资料

1. A2A 官方规范 — Agent2Agent (A2A) Protocol Specification（a2a-protocol.org/latest/specification，当前版本 1.0.0，历经 0.1.0/0.2.6/0.3.0）：八态任务生命周期（SUBMITTED/WORKING/INPUT_REQUIRED/AUTH_REQUIRED/COMPLETED/FAILED/CANCELED/REJECTED）；Agent Card 字段（identity/capabilities/skills/endpoint/securitySchemes/interfaces）；Message/Part（text/raw/url/data）/Artifact；四传输绑定（JSON-RPC 2.0 / gRPC / HTTP+JSON REST / SSE）；Appendix B「Relationship to MCP」互补非替代（规范，2026 持续）
2. HPCwire AIWire — Linux Foundation A2A Protocol Marks One Year with Broad Enterprise and Cloud Adoption（2026-04-09）：满一年 150+ 组织生产使用,Google/Microsoft/AWS 深度集成
3. cloudmagazin — A2A Protocol 1.2 in Production（2026-04-25）：A2A 1.2 于 Cloud Next 2026（2026-04-22）生产化;归 Linux Foundation Agentic AI 项目;签名 Agent Card + 域名绑定;Layer 7,在 service mesh 之上;A2A 补充而非替代 MCP
4. atlan — Google A2A Protocol: How Agent-to-Agent Coordination Works（2026）：Agent Card 元数据/能力/endpoint/签名校验语义
5. 本仓库 src/agent/orchestrator/orchestratorAgent.ts（进程内 dispatch,内存上下文假设）、src/agent/orchestrator/budget.ts（工具闸门,A2A 委托校验扩展点）、src/aml/redteam/（Day 54,被委托 agent 信任边界补测）(2026-06)

SOTA 检查 (2026-06-11)

• A2A 在 2026-06 是跨 agent 互操作的事实标准：归 Linux Foundation，满一年 150+ 组织生产使用，Google/Microsoft/AWS 三家深度集成（AIWire 2026-04）——无竞争性协议取代其「跨组织 agent 委托」地位；本笔记 C 节 A2A/MCP 正交分工表为 2026-06 主流共识。
• 版本口径须按官方规范核对：官方规范页（2026-06）当前版本 1.0.0，市场报道用「1.2 in production」（Cloud Next 2026）——二者不同口径，本计划以规范版本号为准；P4 当周（非本日）须重新抓官方规范页确认最新版本，不沿用本笔记 1.0.0/1.2 数字。
• 签名 Agent Card 是 2026 的关键演进：跨组织信任从「预配白名单」转向「可验证凭证链」（域名绑定签名）——但这扩大攻击面（被攻破的合法 agent 仍能作恶），与 Day 54 红队「被委托 agent 行为须补测」直接呼应,是 live 的安全命题。
• 过时认知警示：(1) 不可把 A2A 当 MCP 的替代——两者正交（A2A 横向连 agent，MCP 纵向连工具），规范 Appendix B 明确互补；(2) 不可把长任务当「慢的同步调用」——INPUT/AUTH_REQUIRED 是可中断可恢复态，client 不能揣内存上下文。
• 待跟踪：A2A 八态状态机与 LangGraph 1.0（2025-10）/ Temporal×OpenAI Agents SDK（2026-03 GA）durable execution 的协作边界——分层共识（2026-04）是「Temporal 管宏观工作流、LangGraph 管微观推理循环」，A2A 在哪一层接入（推测在宏观工作流的跨组织边界），P4 跨云对标时核实；MCP 2026-07-28 最终规范落地后 A2A-over-MCP 或 MCP-in-A2A 的组合模式是否标准化。