A2A —— Agent 到 Agent 协议

问题

一个客服 Agent 需要把报告撰写委托给一个专门的写作 Agent。在 A2A 之前，可选项有：

• 自定义 REST API。可行，但每一对组合都是一次性工程。
• 共享代码库。要求两个 Agent 运行在同一框架上。
• MCP。不合适：MCP 用于调用工具，而不是让两个 Agent 在保持各自不透明内部推理的同时协作。

A2A 填补了这个空白。它把交互建模为一个 Agent 向另一个 Agent 发送 Task，并带有生命周期、消息和制品。被调用 Agent 的内部状态保持不透明——调用方只能看到任务状态转换和最终输出。

A2A 是「让跨框架的 Agent 彼此对话」的协议。它并不取代 MCP；两者是互补关系。

概念

Agent Card

每个兼容 A2A 的 Agent 都在 /.well-known/agent-card.json 发布一份卡文档：

json复制{
  "name": "research-agent",
  "description": "Summarizes academic papers and drafts citations.",
  "version": "1.2.0",
  "supportedInterfaces": [
    {
      "url": "https:TOK0
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {"streaming": true, "pushNotifications": true},
  "securitySchemes": {
    "bearer": {"httpAuthSecurityScheme": {"scheme": "Bearer"}}
  },
  "securityRequirements": [{"schemes": {"bearer": {"list": []}}}],
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/markdown"],
  "skills": [
    {
      "id": "summarize_paper",
      "name": "Summarize a paper",
      "description": "Read a paper PDF and produce a 3-paragraph summary.",
      "tags": ["research", "summarization"],
      "inputModes": ["text/plain", "application/pdf"],
      "outputModes": ["text/markdown"]
    }
  ]
}

发现基于 URL：拉取卡文档，选择 supportedInterfaces 中第一个 protocolBinding 为你的客户端所支持的条目，然后枚举 skills。输入与输出模式都是媒体类型。

签名 Agent Card

卡可以携带 signatures 数组。每个条目是一个 JWS（RFC 7515），基于该卡的 RFC 8785 规范 JSON（不含 signatures 字段）计算。消费方以相同方式对卡做规范化并验证。这可以防止冒充。

Task 生命周期

text复制TASK_STATE_SUBMITTED
  -> TASK_STATE_WORKING
  -> TASK_STATE_COMPLETED | TASK_STATE_FAILED | TASK_STATE_CANCELED | TASK_STATE_REJECTED

TASK_STATE_WORKING
  -> TASK_STATE_INPUT_REQUIRED
  -> TASK_STATE_WORKING (the client sends a message with the same taskId)

客户端用 SendMessage 发起，服务器创建 Task。被调用 Agent 在状态之间转换；客户端用 GetTask 轮询，或通过 SendStreamingMessage 与 SubscribeToTask 以 SSE 流式接收。流携带 statusUpdate 与 artifactUpdate 事件，并在任务进入终态时关闭。没有 final 标志。

Message 与 Part

一条消息包含 messageId、role（ROLE_USER 或 ROLE_AGENT）以及一个或多个 Part。每个 Part 恰好持有一个内容字段，字段名就是类型。没有 kind 字段。

• text：纯文本内容。
• raw：文件字节，在 JSON 中以 base64 表示，通常带有 filename 和 mediaType。
• url：指向文件内容的链接。
• data：结构化 JSON 载荷（给被调用 Agent 的结构化输入）。

示例：

json复制{
  "messageId": "msg-001",
  "role": "ROLE_USER",
  "parts": [
    {"text": "Summarize this paper."},
    {"raw": "...", "filename": "paper.pdf", "mediaType": "application/pdf"},
    {"data": {"targetLength": "3 paragraphs"}, "mediaType": "application/json"}
  ]
}

Artifact

输出是 Artifact，而不是原始字符串。Artifact 是具名、带类型的输出：

json复制{
  "artifactId": "art-001",
  "name": "summary",
  "parts": [{"text": "...", "mediaType": "text/markdown"}]
}

Artifact 可以按块流式传输。每个 artifactUpdate 事件携带 artifact 以及 append 和 lastChunk。调用方负责累积。

三种协议绑定

1. 基于 HTTP 的 JSON-RPC 2.0（JSONRPC）。请求用 POST，流式用 SSE。方法名为 PascalCase：SendMessage、SendStreamingMessage、GetTask、ListTasks、CancelTask、SubscribeToTask、CreateTaskPushNotificationConfig、GetTaskPushNotificationConfig、ListTaskPushNotificationConfigs、DeleteTaskPushNotificationConfig 和 GetExtendedAgentCard。
2. gRPC（GRPC）。适用于 gRPC 为原生协议的企业环境。方法名相同。
3. HTTP+JSON/REST（HTTP+JSON）。使用资源 URL，例如 POST /message:send 和 GET /tasks/{id}。

三种绑定承载相同的数据模型。每个 supportedInterfaces 条目指明一种绑定及其 protocolVersion。客户端在每个请求上都发送 A2A-Version: 1.0 头，因为服务器会把缺少该头的请求当作 0.3 版本读取。

http复制POST /a2a HTTP/1.1
Host: research.example.com
Content-Type: application/json
A2A-Version: 1.0

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-001",
      "role": "ROLE_USER",
      "parts": [{"text": "Summarize this paper."}]
    }
  }
}

不透明性保持

一个关键设计原则：被调用 Agent 的内部状态是不透明的。调用方只能看到任务状态和制品。被调用 Agent 的思维链、tool call、子 Agent 委托——全部不可见。这与 MCP 不同，在 MCP 中 tool call 是透明的。

理由：A2A 让竞争对手在不必暴露内部实现的情况下协作。A2A 可以是「调用这个客服 Agent」，而调用方无需了解该 Agent 如何实现服务。

时间线

• 2025-04-09。 Google 宣布 A2A。
• 2025-06-23。 捐赠给 Linux Foundation。
• 2025-08。 吸收 IBM 的 ACP。
• 2025-09。 AP2 扩展（Agent Payments）发布。
• 2026-04。 v1.0 发布，拥有 150 多个支持组织。

与 MCP 的关系

想调用特定工具时用 MCP。想把整个任务委托给另一个 Agent 时用 A2A。许多生产系统两者并用：Agent 在工具层用 MCP，在协作层用 A2A。

使用它

code/main.py 实现了一个最小 A2A 测试装置：writer Agent 发布它的卡，research Agent 向它发送一个 SendMessage 请求，其中包含一个 PDF part 和一段文本指令，任务依次经过 TASK_STATE_WORKING → TASK_STATE_INPUT_REQUIRED → TASK_STATE_WORKING → TASK_STATE_COMPLETED，最后返回一个文本 artifact。全部使用 stdlib；采用内存传输，以聚焦消息形态。

重点观察：

• Agent Card 的 JSON 结构。
• 服务端任务 id 分配与状态转换。
• Part 以存在哪个内容字段来定类型。
• 任务中途的 TASK_STATE_INPUT_REQUIRED 分支。
• 完成时返回 Artifact。

交付它

本课产出 outputs/skill-a2a-agent-spec.md。给定一个应可被其他 Agent 调用的新 Agent，该技能会生成 Agent Card JSON、skills schema 和端点蓝图。

练习

1. 运行 code/main.py。追踪完整的 Task 生命周期，包括被调用 Agent 请求澄清时的 TASK_STATE_INPUT_REQUIRED 暂停点。

2. 添加签名的 Agent Card。在 signatures 中放入一个 JWS 条目，alg 设为 HS256，对不含 signatures 字段的卡的规范 JSON 签名。编写验证器，并确认它在卡被篡改时失败。

3. 用 SendStreamingMessage 实现任务流式传输：writer Agent 发出 task、三个 artifactUpdate 块，以及一个带 TASK_STATE_COMPLETED 的 statusUpdate，然后关闭流。调用方负责累积这些块。

4. 设计一个封装 MCP 服务器的 A2A Agent。把每个 MCP 工具映射为一个 A2A skill。说明其中的权衡——损失了哪些不透明性？

5. 阅读 A2A v1.0 公告，找出截至 2026 年 4 月尚无任何框架实现的那个特性。（提示：它与多跳任务委托有关。）

关键术语

延伸阅读

• a2a-protocol.org — A2A 规范权威来源
• a2aproject/A2A — GitHub — 参考实现与 SDK
• A2A v1.0.1 发布：本课遵循的带标签 docs/specification.md 与规范性 specification/a2a.proto
• Linux Foundation — A2A 启动新闻稿 — 2025 年 6 月的治理权转移
• Google Cloud — A2A 协议升级 — 路线图与合作伙伴势头
• Google Dev — A2A 1.0 里程碑 — v1.0 发布说明与向后兼容指导

示意图共 1 张