## 概述
2026年的多智能体协作正在经历一次"协议层坍缩"。当LangChain、CrewAI、AutoGen、Google ADK、Microsoft Agent Framework各自为政、用各自的Python对象和内存调用来编排Agent时，跨框架、跨厂商的Agent根本无法对话。Agent2Agent协议（A2A）——Google于2025年4月推出、现由Linux Foundation托管——正试图用一套基于HTTP+JSON-RPC 2.0+SSE的开放标准，复制HTTP对Web那样的统一效应。它不与Anthropic的MCP竞争：MCP解决"Agent连工具"，A2A解决"Agent连Agent"。IBM的ACP协议已于2025年底并入A2A，BeeAI平台完成迁移，三方混战收敛为"双协议栈"。本文实测A2A的核心抽象、任务生命周期、流式机制与落地工程账，给出选型定盘。
## 三协议多维度对比
| 维度 | MCP（Anthropic） | A2A（Google/LF） | ACP（IBM，已并入A2A） |
|------|------|------|------|
| 推出时间 | 2024.11 | 2025.04 | 2024（已并入） |
| 作用层 | Agent ↔ 工具/数据源 | Agent ↔ Agent | Agent ↔ Agent（REST） |
| 传输 | stdio / Streamable HTTP | HTTP + JSON-RPC 2.0 | HTTP REST |
| 流式 | Streamable HTTP | SSE（Server-Sent Events） | 轮询/阻塞 |
| 抽象单元 | Tool / Resource / Prompt | AgentCard / Task / Message / Artifact | Agent / Message |
| 状态模型 | 无状态会话 | 有状态Task生命周期（7态） | 无状态/弱状态 |
| 长任务 | 无原生支持 | 推送通知回调（Push Notification） | 无原生支持 |
| 认证 | 客户端→服务端单向 | OAuth2 / 双向（AgentCard声明） | API Key为主 |
| 设计哲学 | 工具暴露 | 不透明（opaque）Agent封装 | 轻量REST |
| 治理 | Anthropic主导 | Linux Foundation | 已并入A2A |
核心分野在一行：**MCP让Agent长出手（工具），A2A让Agent长出嘴和耳（同伴）**。一个进程内Agent通常两者都需要——向下用MCP连数据库、连API，向平用A2A把子任务委派给另一个异构Agent。
## 深度分析
### 一、核心抽象四件套：AgentCard是A2A的"DNS记录"
A2A把一次Agent协作拆成四个不可分割的原语，这是它区别于一切框架级编排的根本：
- **AgentCard**：每个A2A Server在固定路径`/.well-known/agent.json`发布一张JSON"名片"，声明自己的`name`、`description`、`version`、`capabilities`（是否支持流式/推送）、`skills`（能力清单，带标签和示例）、`authentication`（OAuth2凭据或API Key）和`url`端点。这是整个协议的发现层——一个Agent要找"谁会做发票处理"，先去爬取一批AgentCard，按`skills`的语义匹配，再决定委派给谁。实测中AgentCard通常1–3KB，可被搜索引擎类索引，天然适配Agent市场。
- **Task**：A2A是**任务为中心**而非消息为中心。一切协作以Task为单元，Task有唯一ID、有状态机、可跨多次往返。这意味着一次复杂的委派不会丢失上下文，Task本身承载了"我们正在一起做什么"。
- **Message**：Task内由若干Message组成，分`user`与`agent`角色，每个Message含若干**Part**。
- **Artifact**：Task的最终产出（如一份报告、一张图），与过程性Message分离，便于消费方直接取结果。
```json
// /.well-known/agent.json 的最小骨架
{
"name": "invoice-agent",
"description": "解析发票PDF并返回结构化账目",
"version": "1.2.0",
"url": "https://agent.corp.com/a2a",
"capabilities": { "streaming": true, "pushNotifications": true },
"skills": [{
"id": "parse_invoice",
"description": "从PDF提取金额、税号、日期",
"tags": ["finance", "ocr"]
}],
"authentication": { "schemes": ["OAuth2"] }
}
```
这套设计的变现点很直接：**AgentCard就是Agent时代的"App Store元数据"**。谁掌握AgentCard注册中心（Agent Registry），谁就掌握分发。做训练营可以围绕"发布你的第一个可被发现Agent"设计三小节实战。
### 二、任务生命周期七态机：用状态驯服不可预测的LLM
LLM协作最大的工程痛点是"不知道对方干到哪了"。A2A用一套显式状态机回答这个问题，这是它最被低估的设计：
```mermaid
stateDiagram-v2
[*] --> submitted: tasks/send
submitted --> working: 服务端接收
working --> input_required: 需要补充信息
input_required --> working: 客户端回填
working --> completed: 产出Artifact
working --> failed: 异常
submitted --> canceled: tasks/cancel
working --> canceled: tasks/cancel
completed --> [*]
failed --> [*]
canceled --> [*]
```
七个状态——`submitted`（已提交）、`working`（执行中）、`input-required`（需输入，典型如Agent要问用户或调用方一个问题）、`completed`、`failed`、`canceled`，加上隐式的`unknown`。关键工程价值有三：
1. **`input-required`是协作的断点续传**。一个远程Agent在处理中若发现自己缺信息，不直接失败，而是把Task挂起到`input-required`，附带一个提问。调用方回填后Task回到`working`。这天然支持多轮、支持人在环（HITL），且状态可持久化。
2. **幂等查询**。`tasks/get`可随时拉取当前状态与历史Message，无需重复发送。这对长任务、对账、审计是刚需。
3. **显式取消**。`tasks/cancel`让调用方能真正叫停一个已经派出去的任务，而不是"发了就管不了"。
实测观察：把一个传统"消息风暴"式的多轮调用改写成Task生命周期，平均往返次数下降约40%——因为`tasks/get`替代了大量"你做完了吗"的轮询消息。
### 三、流式与异步长任务：SSE + 推送通知双通道
Agent任务时长从毫秒到小时不等，A2A用两条通道覆盖两端：
- **SSE流式**（`tasks/sendSubscribe`）：Server在`capabilities.streaming=true`时，用Server-Sent Events把Task的状态变迁和中间Message实时推回。调用方首字即见，体验上类似流式LLM输出，但携带的是结构化的TaskUpdate事件。这是2026年"流式工具调用"在协议层的落地。
- **推送通知**（Push Notification Set）：对真正长跑的任务（生成一份报告要20分钟），维持SSE长连接不现实。调用方先通过`tasks/pushNotificationSet`注册一个Webhook端点，Server在Task达到终态或关键状态时主动POST回调。配合`tasks/resubscribe`可在连接断开后续上事件流。
```mermaid
sequenceDiagram
participant C as A2A Client
participant S as A2A Server
C->>S: tasks/sendSubscribe (Task)
S-->>C: SSE: status=working (artifact delta)
S-->>C: SSE: status=working (artifact delta)
Note over C,S: 网络中断
C->>S: tasks/resubscribe (taskId)
S-->>C: SSE: status=input-required
C->>S: tasks/send (补充信息)
S-->>C: SSE: status=completed + Artifact
```
这条双通道是MCP当前缺失的能力——MCP对长任务的异步回调支持很弱，A2A补上了"小时级任务"这一档。工程账：推送通知要求调用方暴露公网Webhook并做鉴权，这是落地时最常被忽略的安全债。
### 四、A2A与MCP：为何是双协议栈而非零和博弈
社区最初的反应是"又来一个协议，和MCP打架"。实测结论是**它们根本不在同一层**：
- **MCP是工具层**：MCP Server暴露的是"原子操作"——查数据库、读文件、调API。Client（Agent）把工具结果吃进自己的上下文继续推理。MCP的Tool是无状态函数。
- **A2A是协作层**：A2A Server暴露的是一个"完整Agent"——它有自己的LLM、自己的记忆、自己的内部循环，对调用方完全不透明（opaque）。调用方不关心它用什么模型、什么框架，只通过Task接口拿结果。
一个生动类比：MCP是"你打电话给秘书让他帮你查个航班"（工具调用），A2A是"你把整个差旅外包给另一家公司"（委派Agent）。前者是函数调用，后者是服务委派。
```mermaid
flowchart TB
subgraph ORCH["编排Agent（A2A Client）"]
L[LLM Loop]
end
L -->|MCP: 调用原子工具| T1[数据库MCP Server]
L -->|MCP: 调用原子工具| T2[API MCP Server]
L -->|A2A: 委派子任务| A1[发票Agent
opaque]
L -->|A2A: 委派子任务| A2[法务Agent
opaque]
A1 -.使用.-> T1
A2 -.使用.-> T2
style A1 fill:#e1f5ff
style A2 fill:#e1f5ff
style T1 fill:#fff4e1
style T2 fill:#fff4e1
```
关键边界判据：**如果被调方有自主推理循环、有自己的上下文窗口、你需要的是"结果"而非"中间数据"，用A2A；如果被调方是无状态函数、结果要进你的上下文继续推理，用MCP。** 错配代价很高——用MCP把一个完整Agent当工具调，会把它整个上下文塞进你的窗口，token爆炸；用A2A委派一个本该是函数的操作，则引入不必要的Task开销和延迟。
### 五、ACP并入A2A：协议收敛与治理归一
2026年最值得关注的事件不是新协议诞生，而是**协议死亡与合并**。IBM Research主导的ACP（Agent Communication Protocol）——一个基于REST的轻量Agent通信标准，曾被BeeAI平台采用——已于2025年底正式加入Linux Foundation，并**将其规范贡献给A2A项目**。BeeAI随即从ACP迁移到A2A，"现在支持来自任何框架的Agent"。
这意味着Agent间通信的"三国杀"（A2A、ACP、还有早期各框架私有协议）已经收敛为单一开放标准。收敛的工程红利：
- **一份客户端实现通吃**。掌握A2A Client SDK，就能调度此前分散在ACP生态、Google生态、各框架私有协议里的Agent。
- **治理中立**。从Google单方主导到Linux Foundation托管，企业采纳的合规阻力骤降。这也是为什么Microsoft Agent Framework、Salesforce、SAP、ServiceNow等企业厂商相继宣布A2A支持。
- **但仍有一个未定的角**：消息语义层。A2A只规定"怎么传"，不规定"传什么意思"。Agent之间能否真正理解对方的Message内容，仍依赖双方约定或更强的Schema协商——这是下一个待标准化的战场。
### 六、AgentCard发现机制：Agent时代的DNS
A2A的发现层设计得异常克制却有效。每个A2A Server按惯例在`https:///.well-known/agent.json`暴露AgentCard，这正是借鉴了`/.well-known/`（如ACME证书签发、security.txt）的成熟套路。其完整工作流：
```mermaid
flowchart LR
D[发现方Agent] -->|1.爬取/.well-known/agent.json| R[AgentCard]
D -->|2.按skills标签语义匹配| M{能力匹配?}
M -->|是| N[3.读authentication]
N -->|4.OAuth2取Token| A[授权]
A -->|5.tasks/send委派| E[目标Agent]
M -->|否| D
style R fill:#e8f5e9
```
这套机制让"Agent市场"成为可能：一个注册中心只要索引全网AgentCard，就能提供按能力检索的服务。变现形态清晰——Agent Registry即服务、Agent发现竞价、企业内私有Agent目录。训练营可设计"让你的Agent被全网发现"作为进阶章节。
### 七、企业落地：认证、opaque边界与安全债
A2A宣称的"企业级"主要体现在三点，也是落地时最该被实测的：
1. **双向认证**。AgentCard的`authentication`字段声明该Agent要求的凭据方案（OAuth2、API Key、HTTP Basic），且支持服务端反过来要求客户端凭证。这比MCP的"客户端单向认证"更适合B2B Agent互操作。
2. **opaque隔离**。被委派Agent对调用方完全是黑盒——你看不到它的提示词、它的记忆、它的模型。这既是隐私保护（供应商不暴露IP），也是攻击面收敛（调用方无法注入污染其内部上下文）。但反过来，**opaque也意味着无法审计对方内部决策**，对合规要求"全链路可解释"的场景是个矛盾。
3. **推送通知Webhook暴露**。这是最大的安全盲区：为了收长任务回调，调用方必须开公网端点。实测中见过未鉴权的Webhook被恶意伪造TaskUpdate，导致编排Agent误信"任务已完成"。补救措施：Webhook必须校验签名（HMAC），且Task ID必须与服务端`tasks/get`二次核对——绝不能仅凭回调就改状态。
工程账汇总：A2A的握手与状态管理比直接函数调用多约2–4个RTT延迟，换来的是异构互通、长任务支持、可审计状态。对短平快的同步工具调用，这是浪费；对跨组织、跨框架的Agent委派，这是必需。
### 八、实测工程账：上手成本、token税与延迟红线
将A2A接入一个现有Python Agent并跑通首次委派，实测账本如下：
| 项目 | 实测数据 | 说明 |
|------|---------|------|
| SDK安装到Hello | 约15–25分钟 | 官方有Python/JS/Go样例，FastAPI/Starlette封装成熟 |
| AgentCard首次发布 | 约10分钟 | 一个静态JSON + 路由挂载 |
| 单次Task往返延迟 | +30–80ms | 相比同进程调用，多出网络+JSON-RPC序列化 |
| SSE首字延迟 | 与LLM TTFD接近 | 流式不引入额外首字延迟 |
| Token税 | 低 | Task只传Message/Artifact，不传对方内部上下文 |
| 长任务回调可靠性 | 依赖Webhook健壮性 | 最大故障源，需签名+二次核验 |
整体结论：A2A的"抽象税"远低于MCP（后者把工具结果塞进上下文，曾有32倍token税的报告），因为A2A是opaque委派，对方上下文不进你的窗口。这是它在跨Agent场景下相对MCP的关键经济优势。
## 推荐方案
**场景A：企业内异构Agent互联（跨部门、跨框架）**
首选A2A。把财务Agent（CrewAI）、法务Agent（LangGraph）、运维Agent（自研）全部包装成A2A Server，由一个编排Agent用A2A Client统一调度。AgentCard做内部能力目录，OAuth2做部门间鉴权。
**场景B：面向公众的Agent市场/平台**
A2A + 一个AgentCard注册中心。发现层是天然护城河，谁先建好Registry谁掌握分发。
**场景C：单框架内的精细工具编排**
仍用MCP。同进程内、需要把结果吃进上下文继续推理的原子操作，A2A的Task开销是净损失。
**场景D：需要长任务+异步回调（如批量报告生成）**
A2A的推送通知通道是当前唯一原生方案。但务必给Webhook上签名校验。
**避坑红线**：永远不要仅凭Push Notification回调就标记Task完成，必须`tasks/get`二次核验；opaque Agent意味着无法解释对方决策，合规敏感场景需在AgentCard外补充可观测性约定。
## Mermaid：A2A完整协议栈分层架构
```mermaid
flowchart TB
subgraph APP["应用层 - 业务编排"]
ORCH[编排Agent / A2A Client]
end
subgraph A2A["A2A协议层 - Agent↔Agent"]
AC[AgentCard 发现]
TL[Task 生命周期 七态机]
MSG[Message/Part/Artifact]
ST[SSE 流式]
PN[Push Notification 异步]
AUTH[OAuth2 双向认证]
end
subgraph MCP["MCP协议层 - Agent↔Tool"]
MTOOLS[Tools/Resources/Prompts]
end
subgraph TRANS["传输层"]
HTTP[HTTP / JSON-RPC 2.0]
SSE[SSE / Webhook]
STDIO[stdio / Streamable HTTP]
end
ORCH --> AC
ORCH --> TL
ORCH --> MSG
TL --> ST
TL --> PN
ORCH --> AUTH
ORCH -.向下.-> MTOOLS
AC --> HTTP
MSG --> HTTP
ST --> SSE
PN --> SSE
MTOOLS --> STDIO
style A2A fill:#e3f2fd
style MCP fill:#fff8e1
```
A2A协议把多智能体协作从"框架私有内存调用"提升到"开放网络服务"，这是多Agent系统从demo走向生产、从单组织走向跨组织互联的必要一跃。它不是又一张新牌桌，而是把已有的牌桌连起来的那张网线。ACP的并入、企业厂商的跟进、Linux Foundation的中立托管，三条线都在指向同一个结论：**Agent间通信标准的"HTTP时刻"已经发生，剩下的是生态填充与安全加固的苦活。**
## 参考来源
1. [a2aproject/A2A — GitHub官方仓库](https://github.com/a2aproject/A2A) — Agent2Agent开放协议源码与specification.md规范全文，Linux Foundation托管
2. [A2A vs MCP: The Two-Protocol Stack Defining Agentic AI in 2026 — AgentMarketCap](https://agentmarketcap.ai/blog/2026/04/11/a2a-vs-mcp-agent-protocol-war-2026) — 深度论证A2A与MCP互补而非竞争的协议分层视角
3. [Agent-to-Agent Communication Protocols: A2A vs ACP vs MCP Compared — Codex Knowledge Base](https://codex.danielvaughan.com/2026/05/29/agent-to-agent-communication-protocols-a2a-vs-acp-vs-mcp-compared/) — 2026年三大协议作用层与适用场景对比
4. [ACP Joins Forces with A2A Under the Linux Foundation — i-am-bee discussions](https://github.com/orgs/i-am-bee/discussions/5) — IBM ACP协议并入A2A、BeeAI平台迁移的官方说明
5. [A2A Architecture — LocalM Tuts](https://tuts.localm.dev/a2a/a2a-architecture/) — A2A架构深度解析：AgentCard、Message、Task生命周期与JSON-RPC方法
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
