A2A 协议深度解读：Agent 间通信的通用语言（A2UI 的传输底座）

引子：从 A2UI 的「传输层可插拔」说起

上一篇文章研究 Google 的 A2UI——一种声明式 Agent UI 协议，让远程不可信 Agent 把富交互界面安全地送回客户端。那张端到端时序图里有一个被一笔带过的角色：传输层。A2UI 反复强调「传输可插拔（A2A / AG-UI / SSE / WebSocket）」，它不绑定传输。

这就留下一个更底层的问题：UI 消息（一行行 JSONL）到底是怎么从远程 Agent 流到你客户端的？如果 Agent 在别的公司、别的云、用别的框架，它们之间靠什么对话？

答案之一，就是这篇的主角——A2A（Agent2Agent）协议。它是 A2UI 最重量级的传输底座，但它的意义远不止「传 UI」：这是 Google 主导、Linux Foundation 治理、150+ 组织支持的 Agent 间通信通用语言。

本篇就从 A2UI 的传输层向下深挖，讲透 A2A：为什么需要它、核心机制、与 MCP 的分工，以及它如何承载 A2UI 的流式 UI。

一、第一性原理：为什么需要 A2A

核心矛盾：Agent 的「巴别塔」

过去：单 Agent + 一堆工具，在一个框架内闭环（LangChain / CrewAI / AutoGen 各自繁荣，但各自封闭）。
现在：企业要多 Agent 协作——客服 Agent 要调供应链 Agent，供应链 Agent 要调外部供应商 Agent，跨越组织边界。
问题：不同框架、不同厂商、不同云的 Agent 互不相通，每两个 Agent 协作都要写定制集成代码，陷入 n(n−1)/2 的集成地狱。

破局：给 Agent 一门「通用语」

A2A 不是又一个 Agent 框架，而是 Agent 之间的通信协议。它让任何 Agent 都能用同一套规则发现彼此、委派任务、交换结果。IBM 给了它一个准确比喻：agent 生态的「通用翻译器」。

关键取舍：协作 ≠ 合并

A2A 协调器反复强调一句话——「collaborate as agents, not as tools」（作为 Agent 协作，而不是作为工具被调用）。两个 Agent 各自保持 opaque（不暴露内部逻辑、记忆、实现），只在协议层交互。这正是它和 MCP 的根本分界线，也是后面整篇文章的锚点。

二、三个参与者与拓扑

A2A 只定义三个参与者（注意：没有 MCP 那样的 Host 角色）：

参与者	职责
User	人，提出需求
Client Agent（A2A Client）	面向用户的编排者，接收需求、拆解、委派给合适的 Remote Agent、跟踪状态
Remote Agent（A2A Server）	实际干活的专家 Agent，对外暴露 A2A 服务端

为什么没有 Host？这是设计哲学差异。MCP 围绕 Host（如 Claude Desktop 这类宿主应用）构建工具访问层级；A2A 更开放，用 Agent Card + 标准协议来处理发现与安全，不预设中心化 Host。官方文档明确把它列为「与 MCP 的设计差异」。

拓扑上是多对多 mesh：Client Agent 可同时委派给多个 Remote Agent，而 Remote Agent 也可以是别人的 Client——Agent 们以对等身份组网，没有谁是天然的中央调度器。

flowchart LR
    U["用户 User"] --> CA["Client Agent<br/>(A2A Client, 编排者)"]
    CA -->|发现 + 委派 Task| R1["Remote Agent A<br/>(A2A Server)"]
    CA -->|发现 + 委派 Task| R2["Remote Agent B<br/>(A2A Server)"]
    CA -->|发现 + 委派 Task| R3["Remote Agent C<br/>(A2A Server)"]
    R2 -.对等协作.-> R3
    R1 -.对等协作.-> R2

这张 mesh 图揭示了一个关键事实：A2A 的世界里没有「主从」，只有「委托与协作」。任何一个 Agent 既能干活（作为 Remote），也能调度别人（作为 Client），角色随场景切换。

三、核心概念：Agent Card / Task / Artifact

1. Agent Card —— 能力名片

每个 Agent 在固定路径 /.well-known/agent-card.json（沿用了 RFC 8615 的 well-known URI 约定）发布一张机器可读的「名片」。这张卡片是整个协议的入口：

{
  "name": "HR Agent",
  "description": "处理人力资源相关任务",
  "url": "https://hr.example.com/agent",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "defaultInputModes": ["text"],
  "defaultOutputModes": ["text", "file"],
  "skills": [
    {
      "id": "time_off",
      "name": "请假管理",
      "description": "处理年假、调休申请",
      "tags": ["hr", "time off"],
      "examples": ["下周五我想请假", "我还剩多少年假？"]
    }
  ]
}

Client Agent 通过抓取并比对各 Agent 的卡片来「选专家」——这就是能力发现（Capability Discovery）。卡片里 capabilities.streaming / pushNotifications 这些标志位，直接决定了后续用哪种传输模式（见第四节）。

/.well-known/agent-card.json 这个路径选择很巧妙：它复用了 Web 已有的 well-known 约定（和 HTTPS 的 ACME 证书验证、OIDC 发现同源），Agent 只要有域名就能被标准化发现，零额外基础设施。

2. Task —— 有状态的任务生命周期

A2A 的通信围绕「任务」组织，不是无状态请求。Task 有明确的状态机：

stateDiagram-v2
    [*] --> submitted: Client 发起
    submitted --> working: Remote 开始执行
    working --> input_required: 需要人补充信息
    input_required --> working: 人补充后继续
    working --> completed: 成功
    working --> failed: 出错
    working --> canceled: Client 取消
    submitted --> rejected: Remote 拒绝
    completed --> [*]
    failed --> [*]
    canceled --> [*]
    rejected --> [*]

最值得注意的状态是 input-required：Agent 干到一半需要人补充信息才能继续——这是 HITL（Human-In-The-Loop）的原生支持，和上一篇 A2UI 的 interrupt/resume 是同一个精神。状态持久化则让长任务可以断点续传，关掉客户端再打开，任务还在。

3. Artifact —— 任务产出

Task 的输出叫 Artifact，是带类型的结构化数据（文本 / 文件 / JSON）。大产出可以分块流式追加，配合 SSE 实现渐进式呈现。

4. Message + Part —— 多模态消息

消息由若干 Part 组成，Part 可以是 TextPart / FilePart / DataPart。A2A 设计上模态无关（modality agnostic）——不限于文本，连音频、视频流都在路线图里。这让 A2A 能承载的远不止「文字对话」。

四、传输机制：JSON-RPC + SSE

A2A 的一大工程美学是不发明新协议层，复用团队已经熟悉的 Web 标准：

JSON-RPC 2.0 over HTTP/HTTPS：请求-响应模式
SSE（Server-Sent Events）：实时流式
TLS：标准传输安全

核心方法一族（都以 tasks/ 或 message/ 开头）：

方法	用途
`tasks/send`	发任务，同步等结果
`tasks/sendSubscribe`	发任务 + 订阅流式更新
`tasks/get`	查询任务状态（轮询兜底）
`tasks/cancel`	取消任务
`message/stream`	流式消息
`QuerySkill()`（路线图）	动态检查 Agent 是否支持某技能

三种获取结果的模式

这三种模式体现了 A2A 对「渐进性」的重视，也恰好对应了不同场景：

轮询（Polling）：Client 反复 tasks/get 问「好了没」。简单可靠，但慢、费请求。
流式（SSE Streaming）：连接保持打开，Agent 实时 push 状态更新和产出分块。体验最好——你能看到文档「逐段长出来」。
推送（Push Notification）：Client 离线或断开时，Agent 异步通知任务事件（完成 / 需要输入）。最可靠。

sequenceDiagram
    actor U as 用户
    participant C as Client Agent
    participant R as Remote Agent
    U->>C: 1. 提需求
    C->>R: 2. 读取 /.well-known/agent-card.json
    R-->>C: 3. 返回能力名片
    C->>R: 4. tasks/sendSubscribe (发起任务+订阅)
    R-->>C: 5. SSE: state=working
    R-->>C: 6. SSE: Artifact 分块 1
    R-->>C: 7. SSE: Artifact 分块 2
    R-->>C: 8. SSE: state=completed + final
    C-->>U: 9. 渐进呈现结果

注意第 5-8 步：Agent 不是憋一个大 JSON 一次性吐出，而是边算边推——状态更新和产出分块交错流式到达。这种「渐进」正是 agent-driven 多轮对话保持流畅的关键。

五、A2A vs MCP：互补而非竞争

最常见的误解是「A2A 和 MCP 是竞争关系」。正解是：它们解决正交的问题。

维度	A2A（Google）	MCP（Anthropic）
解决什么	Agent ↔ Agent	Agent ↔ Tool / Data
交互模型	peer-to-peer 协作	client-server 工具访问
角色定义	User / Client / Remote（无 Host）	Host / Client / Server
状态管理	三级（session / agent / task）	协议级无状态
发现机制	Agent Card（well-known URI）	Server 注册到 Host
典型场景	跨组织多 Agent 编排	单 Agent 接外部工具与数据

生产实践：两者叠加

一句话总结它们的配合：

A2A 把任务路由到对的 Agent；MCP 给那个 Agent 执行任务所需的工具和 context。

举个供应链的例子：客服 Agent（用 A2A）把「查库存」委派给库存 Agent；库存 Agent（用 MCP）去连数据库和 ERP 系统取数。A2A 管 Agent 之间怎么对话，MCP 管 Agent 内部怎么拿数据——一层路由，一层接入，各司其职。

治理会合：行业用行动表态

2025 年 12 月，Linux Foundation 成立 Agentic AI Foundation（OpenAI、Anthropic、Google、Microsoft、AWS、Block 共同创建），A2A 和 MCP 都被纳入同一基金会治理。这是行业最明确的信号：这两个协议是互补标准，不是竞争。同月，MCP 也被捐入该基金会——两大协议在同一屋檐下协同演进。

六、A2A 作为 A2UI 的传输底座

回到开篇的那个问题。A2UI 的端到端流程里，Agent 产出的是 A2UI 消息（createSurface / updateComponents / updateDataModel），这些 JSONL 要「流式传输」到客户端。A2A，就是那根管道。

A2A 的能力与 A2UI 的需求几乎完美对齐：

A2A 能力	A2UI 需求	对齐点
Task 生命周期	Surface 生命周期（创建/更新/关闭）	有状态的 UI 会话
SSE streaming	渐进渲染（JSONL 逐条流，UI 逐步长出）	流式 UI 生成
Artifact 增量追加	`updateDataModel` / `updateComponents` 局部更新	只传变化部分
`input-required` 状态	HITL（用户交互 action 回传）	人机中断恢复

flowchart TB
    subgraph A2A["A2A 传输层（通信语义）"]
        T1["Task 状态机"] --- T2["SSE 流式"] --- T3["Artifact 增量"]
    end
    subgraph A2UI["A2UI 表现层（UI 语义）"]
        U1["Surface 生命周期"] --- U2["渐进渲染"] --- U3["局部更新"]
    end
    T1 -.承载.-> U1
    T2 -.承载.-> U2
    T3 -.承载.-> U3

所以 A2UI 文档说「传输可插拔」并非敷衍：A2A 提供的正是「有状态、可流式、可中断恢复」的传输，恰好是 agent-driven UI 在多轮对话里的刚需。换成裸 SSE / WebSocket 也能传 JSONL，但会失去 A2A 的任务管理、能力发现、跨组织认证这些「Agent 间」语义。

一句话收束这两篇研究：

A2UI 定义了「UI 长什么样」，A2A 定义了「UI 怎么传过来、Agent 怎么对话」——一个管表现层，一个管通信层。两者合起来，才是「跨信任边界 agent-driven UI」的完整答案。

七、治理、生态与成熟度

演进时间线

flowchart LR
    A["2025-04<br/>Google Cloud Next 发布<br/>50+ 合作伙伴"] --> B["2025-06<br/>捐入 Linux Foundation<br/>中立治理"]
    B --> C["2025-08<br/>IBM ACP 协议合并入 A2A<br/>标准收敛"]
    C --> D["2025-12<br/>Agentic AI Foundation 成立<br/>A2A+MCP 共治, 150+ 组织"]
    D --> E["2026<br/>企业生产级使用<br/>落地主流云平台"]

几个关键节点值得细看：

ACP 合并（2025-08）：IBM 的 Agent Communication Protocol（2025-03 发布）并入了 A2A。agent-to-agent 通信从此标准收敛而非分裂——这在早期标准竞争里是难得的结局。
Agentic AI Foundation（2025-12）：六大厂商共建，A2A 与 MCP 同框共治。这是协议走向成熟的治理信号。
SDK 全语言覆盖：Python（a2a-sdk）/ Go / JS（@a2a-js/sdk）/ .NET / Rust，pip / go get / npm / dotnet / cargo 一行安装。

生态侧，Google 与 DeepLearning.AI 合出了官方短课程（Google Cloud + IBM Research），从 0 到 1 搭建一个跨框架的多 Agent 医疗系统——说明已具备可教学、可复制的落地路径。

路线图

官方公布的演进方向：Agent Card 授权方案增强、QuerySkill() 动态技能检查、任务内动态 UX 协商（对话中途加入音频 / 视频）、push notification 可靠性提升。从 roadmap 能看出，A2A 在向「更动态、更多模态、更安全」演进。

八、判断与启示

把 A2A 放回更大的图景里，有四点判断：

1. A2A 是多 Agent Mesh 的「TCP」。 它不解决 Agent 怎么思考，只解决 Agent 怎么找到彼此、怎么对话。这层一旦标准化，Agent 才能真正像互联网节点一样组网——而不是被困在各自的框架孤岛里。

2. 与 MCP 的互补是「协议栈」思维。 不要纠结「选 A2A 还是 MCP」，生产系统两者都要：A2A 管 Agent 间路由，MCP 管 Agent 内工具。这和得物「按场景选型」、A2UI「分层解耦」是同一种工程哲学——没有银弹，按层选标准。

3. 对 A2UI 而言，A2A 补上了「传输语义」。 让声明式 UI 不只是静态描述，而是活在有状态、可流式、可中断恢复的对话里。A2UI + A2A 合起来，才是「跨信任边界 agent-driven UI」的完整拼图。

4. 务实判断：方向对，但仍早期。 A2A 还在 v0.x 阶段，渲染器和工具链仍在成熟，但它的方向（开放、互补、LF 中立治理、六大厂商背书）是正确的。对自建多 Agent 系统的团队，值得作为技术雷达跟踪项；对有跨组织互操作需求的场景，它是当前最正经的标准选项。

从 A2UI 的「传输层可插拔」一路深挖到这里，一条脉络清晰起来：Agent 时代正在重走一遍互联网协议分层的路——UI 表现层（A2UI）、Agent 通信层（A2A）、工具接入层（MCP），各有一套开放标准，各司其职，又在同一个基金会下协同演进。理解了这套分层，也就理解了多 Agent 系统未来几年的基础设施骨架。

信息来源

来源	URL
A2A 官方文档	https://agent2agent.info/docs/introduction
Google 官方公告（2025-04-09）	https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability
GitHub 仓库（a2aproject/A2A）	https://github.com/a2aproject/A2A
Linux Foundation 公告（150+ 组织）	https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
DeepLearning.AI 官方课程	https://www.deeplearning.ai/courses/a2a-the-agent2agent-protocol
Galileo 企业指南	https://galileo.ai/blog/google-agent2agent-a2a-protocol-guide
Auth0: MCP vs A2A	https://auth0.com/blog/mcp-vs-a2a
IBM Think: What is A2A	https://www.ibm.com/think/topics/agent2agent-protocol
上一篇：A2UI 协议深度研究	（本博客 Agent UI 系列）