这篇学完你能回答什么
- A2A 协议解决什么问题？它和 MCP 是竞争还是互补？
- Agent Card、Task 状态机、Artifact 分别在解决什么工程问题？
- 什么情况下不该上 A2A？
从一个真实故障讲起
一家公司里有两个独立团队各自做了 Agent：差旅团队做了「行程助手」，财务团队做了「报销助手」。业务上很自然的需求是：订完机票能直接把行程转给报销侧生成预支申请。
第一版集成方案是最直觉的那种——把报销侧的工具全部挂到行程助手上。财务团队导出了 20 个工具的 schema，行程助手把它们和自己的 12 个工具一起塞进模型的 tools 参数里。
三周后这个集成成了两个团队共同的痛点：
- 上下文被撑爆：32 个工具的定义每轮常驻约 5000 token，行程助手的工具选择准确率从 91% 掉到 74%，开始把「查报销标准」和「查差旅标准」搞混；
- 发版互相阻塞：财务团队改一个工具的参数，行程助手不同步更新 schema 就直接调用失败。两边被迫开始对齐发版窗口；
- 凭证要不来：报销工具需要财务系统的写权限。财务团队不愿意把服务账号交给另一个团队的进程——这个顾虑完全合理，但技术方案没给出第二条路；
- 业务逻辑泄漏：报销的审批规则（什么金额需要总监批、什么科目不能报）本来封装在财务 Agent 内部，现在为了让行程助手"用对工具"，这些规则被抄进了行程助手的 system prompt。同一套业务规则出现在两个代码库里，且注定会不同步。
问题的根源是一个建模错误：他们把另一个 Agent 当成了一堆工具，而不是当成一个能接活的对等实体。
正确的建模是：行程助手不需要知道报销怎么做，它只需要说"这是行程单，请生成预支申请"，然后等对方交付结果。对方内部用什么模型、挂了几个工具、审批规则怎么写，都不关它的事，也不该关它的事。
这就是 A2A 协议的全部出发点。
订完机票转报销
两个团队各自做了 Agent，业务上要打通
把 20 个工具全挂过来断点
和自己的 12 个一起塞进 tools 参数
32 个工具常驻上下文
每轮约 5000 token 只用来放定义
工具选错了
把「查报销标准」和「查差旅标准」搞混
审批规则被抄走
同一套规则出现在两个代码库，注定不同步
核心概念：先打比方，再给定义
比喻：MCP 是给自己配工具，A2A 是给外部发外包合同。
你买一把电钻（MCP 接工具），你要懂怎么用它、什么时候用它、它的每个档位是干嘛的。你委托一家装修公司做吊顶（A2A 委派任务），你只需要说清楚要什么、什么时候要、验收标准是什么——你不需要知道他们用哪个牌子的电钻，也不该拿到他们的工具箱钥匙。
定义：A2A（Agent2Agent Protocol，智能体间协议） 是一个开放协议，规定不同厂商、不同框架、不同组织构建的 AI Agent 之间如何互相发现、委派任务、协调工作。它由 Google 在 2025 年 4 月发布，同年 6 月捐赠给 Linux Foundation；v1.0 稳定版于 2026 年 4 月 9 日发布（截至 2026-08）。
协议规范里有个反复出现的关键词值得记住：opaque（不透明）。A2A 明确把对端 Agent 建模为不透明的智能体应用——你看不见也不需要看见它的内部状态、工具、提示词。这个设计取舍决定了它的一切：
| MCP | A2A | |
|---|---|---|
| 方向 | 纵向：Agent → 工具/数据 | 横向：Agent ↔ Agent |
| 对端是什么 | 一组可调用的能力（透明） | 一个能接活的实体（不透明） |
| 交互单元 | 一次工具调用（tool call） | 一个任务（Task，可长时、可多轮） |
| 谁做决策 | 调用方决定每一步怎么做 | 受托方自己决定怎么做 |
| 典型边界 | 同一信任域内 | 跨团队、跨厂商、跨组织 |
所以 Q3-11 的标准答案很明确：互补，不是竞争。 一纵一横，共同构成 Agent 的连接层。两者现在都在 Linux Foundation 治理之下，这一点本身就说明生态没打算让它们二选一。
你得懂怎么用、什么时候用、每个档位干嘛
钻头在你手里，转速开错、墙钻穿了都算你的
一次工具调用，调用方决定每一步
对端是一组可调用的能力，透明；典型边界在同一信任域内
说清要什么、什么时候要、怎么验收
不需要知道他们用哪个牌子的电钻，也不该拿到他们的工具箱钥匙
一个 Task，受托方自己决定怎么做
规范反复出现的关键词是 opaque（不透明）；典型边界跨团队、跨厂商、跨组织
原理拆解
| 组 | 状态 | 语义 |
|---|---|---|
| Running | SUBMITTED WORKING | 已受理 / 正在做 |
| Paused | INPUT_REQUIRED AUTH_REQUIRED | 我缺信息 / 你得补授权 |
| Finished | COMPLETED FAILED CANCELED REJECTED | 终态，返回 Artifact（另有 UNSPECIFIED 占位） |
Paused 这一组是设计意图，不是异常。协议在状态机层面给「人在环中」和「二次授权」留了一等公民的位置，动机和 MCP 2026-07-28 引入 MRTR 是同一件事：真实业务里，长任务执行到一半需要问一句，是常态。
签名是 v1.0 的关键升级：Agent Card 支持 JWS 签名（RFC 7515），对卡片的规范化形式（JSON Canonicalization Scheme, RFC 8785）计算。跨组织时你和对方根本没有预先建立集成关系，验签是刚需。
三个核心对象
① Agent Card（能力名片）—— 放在 /.well-known/agent-card.json
{
"name": "ExpenseAgent",
"description": "根据行程与票据生成预支/报销申请",
"url": "https://expense.corp.internal/a2a",
"version": "1.0.0",
"capabilities": { "streaming": true, "pushNotifications": true },
"securitySchemes": { ... }, ← 声明怎么鉴权（OAuth / API Key / OIDC）
"skills": [ { "id": "create-advance", "name": "生成预支申请", ... } ],
"signature": { ... } ← v1.0 的签名字段
}
② Task（任务）—— 委派的基本单元，有唯一 ID，状态机驱动
③ Artifact（产出物）—— 任务的交付结果，由若干 Part（文本/文件/结构化数据）组成Agent Card 的定位相当于 Agent 版的 OpenAPI 描述：调用方先读卡片，判断"这个 Agent 能不能干这活、我该怎么向它鉴权"，再决定要不要派任务。
签名是 v1.0 的关键升级（截至 2026-08）：Agent Card 支持 JWS 签名（RFC 7515），对卡片的规范化形式（JSON Canonicalization Scheme, RFC 8785）计算。调用方在信任任何一条声明的能力或鉴权方式之前先验签，防的是发现层的卡片伪造——这在跨组织场景里是刚需，因为你根本没有和对方预先建立集成关系。
Task 状态机：九个状态，三组语义
┌── Running ──┐ ┌──── Paused ─────┐ ┌──── Finished ─────┐
│ SUBMITTED │ │ INPUT_REQUIRED │ │ COMPLETED │
│ WORKING │ │ AUTH_REQUIRED │ │ FAILED │
└─────────────┘ └─────────────────┘ │ CANCELED │
│ │ │ REJECTED │
└────────────────────────┴────────────────┴───────────────────┘
（UNSPECIFIED 为未定义占位）这张图里最值得讲的是 Paused 这一组。INPUT_REQUIRED 表示"我需要更多信息才能继续"，AUTH_REQUIRED 表示"我需要你补授权"。协议在状态机层面为「人在环中」和「二次授权」留了一等公民的位置，而不是把它当成异常。这和 MCP 2026-07-28 引入 MRTR 的动机是同一件事：真实业务里，长任务执行到一半需要问一句，是常态。
面试里能把这一点说出来，比背九个状态名有价值得多。
传输与交付
- 传输：HTTP(S) + JSON-RPC 2.0；实时进度用 SSE 流式推送；长任务/断连场景用 push notification（服务端 POST 到客户端提供的 webhook）。
- 版本与扩展：请求头
A2A-Version声明协议版本，A2A-Extensions声明要启用的扩展 URI——扩展机制让能力可以增长而不破坏兼容。 - 交付：任务进入终态时返回一个或多个 Artifact，内容按 Part 类型化（文本 / 文件 / 结构化数据），而不是让调用方去解析一段自由文本。
"返回 Artifact 而不是聊天记录"是 A2A 一个容易被忽略的工程价值：它逼你把 Agent 之间的交付定义成契约。这和多 Agent 编排里"子 Agent 必须返回结构化摘要而非完整 transcript"（T3-8）是同一条工程纪律。
回到开篇的故障
用 A2A 重做那个集成：
行程助手 报销助手（不透明）
│ │
│ ① GET /.well-known/agent-card.json ────────→│
│←──── 卡片（含 skills、鉴权方式、签名）─────────│
│ ② 验签 + 按声明的方式取令牌 │
│ ③ 派任务：{行程单, 期望产出:"预支申请"} ──────→│ 内部爱怎么做怎么做：
│←──── SSE: WORKING ───────────────────────────│ 挂几个工具、什么审批规则、
│←──── INPUT_REQUIRED: "缺成本中心" ────────────│ 用什么模型，调用方一概不知
│ ④ 补充信息 ─────────────────────────────────→│
│←──── COMPLETED + Artifact(预支申请单) ────────│四个原问题一次性解决：工具不再进对方上下文（准确率回来了）；schema 不再耦合（只依赖卡片声明的 skill）；凭证留在财务侧（跨信任边界鉴权）；审批规则只存在于一处。
工程实践（截至 2026-08）
生态现状
- v1.0 于 2026-04-09 在 Linux Foundation 下发布，150+ 组织参与，主流云平台均已集成（Microsoft 侧 Azure AI Foundry / Copilot Studio，AWS 侧 Bedrock AgentCore Runtime，Google Cloud 提供 A2A 编排 + MCP 工具执行的参考架构）。
- 同期还有 AP2（Agent Payments Protocol，智能体支付协议），处理 Agent 驱动的交易场景，与 A2A 配套。
- 生态里还存在 ACP（IBM/AGNTCY 系，REST 原生）等替代方案。2026 年最值得讲的结构性变化不是"又出了个协议"，而是MCP 与 A2A 都进了 Linux Foundation，治理层面开始收敛。
进阶技术三段式：A2A
- 解决什么：跨团队/跨组织的 Agent 协作。把"能力不透明的对端"变成可发现、可委派、可验收的合同关系；避免把对方的工具、凭证和业务规则搬进自己的上下文。
- 代价是什么：① 多一层协议与网络跳数，延迟增加；② 需要维护 Agent Card、签名与密钥轮换；③ 分布式故障模型——对端超时、任务卡在 WORKING、webhook 丢失，都要有超时与补偿策略；④ 端到端可观测性变难，跨组织的 trace 需要显式传递关联 ID；⑤ 责任边界模糊：对端把事办砸了，你的用户只会找你。
- 什么时候不该用：同一进程 / 同一代码库里的"子 Agent"根本不需要 A2A——那是框架内的 handoff 或函数调用，套协议纯属自找麻烦；只有一个 Agent 的系统更不需要；对延迟极敏感的同步链路；以及——你其实需要的只是一个工具而不是一个 Agent 时，用 MCP。
判据：什么时候对端应该是 Agent 而不是工具
| 信号 | 建议 |
|---|---|
| 对端逻辑固定、输入输出确定 | 做成 工具（MCP） |
| 对端有自己的判断、可能反问、可能耗时很久 | 做成 Agent（A2A） |
| 对端归属另一个团队/公司，凭证不能外泄 | A2A（信任边界） |
| 对端的业务规则会独立演进 | A2A（避免规则复制） |
| 你和对端在同一个进程里 | 都不用，直接函数调用 |
避坑清单
- 别把 A2A 当成"多 Agent 架构"的通行证。协议解决的是跨边界通信，不解决"你到底该不该拆成多个 Agent"（那是 T3-8 的问题，答案通常是"不该"）。
- 务必验签。不验签的 Agent Card 等同于把发现层暴露给中间人。
- 给每个派出去的 Task 设超时与终态兜底，别指望对端一定会把状态推到终态。
- INPUT_REQUIRED 要有人或有策略去响应，否则任务会永久悬挂。
- 跨边界传的数据要做最小化：别把整个用户上下文当作任务输入甩过去。
| 对端的样子 | 做成什么 | 为什么 |
|---|---|---|
| 逻辑固定、输入输出确定 | 做成工具（MCP） | 你其实需要的只是一个工具，而不是一个 Agent |
| 有自己的判断、可能反问、可能耗时很久A2A 的正位 | 做成 Agent（A2A） | 状态机里的 INPUT_REQUIRED 就是给反问留的位置 |
| 归属另一个团队或公司，凭证不能外泄 | A2A（信任边界） | 凭证留在对方侧 —— 开篇那个「要不来」的顾虑，技术上终于有第二条路 |
| 业务规则会独立演进 | A2A（避免规则复制） | 审批规则只存在于一处，不会被抄进两个代码库 |
| 你和对端在同一个进程里 | 都不用，直接函数调用 | 那是框架内的 handoff，套协议纯属自找麻烦 |
- 版本与治理
- v1.0 于 2026-04-09 在 Linux Foundation 下发布，150+ 组织参与，主流云平台均已集成
- 传输与推送
- HTTP(S) + JSON-RPC 2.0；进度用 SSE，长任务与断连用 push notification 打 webhook
- 版本与扩展头
- 请求头
A2A-Version声明协议版本，A2A-Extensions声明要启用的扩展 URI - 务必验签
- 不验签的 Agent Card 等同于把发现层暴露给中间人
- 别让任务悬挂
- 每个派出去的 Task 设超时与终态兜底；
INPUT_REQUIRED要有人或有策略去响应 - 跨边界最小化
- 别把整个用户上下文当任务输入甩过去；也别把 A2A 当成「多 Agent 架构」的通行证
面试视角
- 一句话定位MCP 纵向连工具，A2A 横向连 Agent，互补
- 讲 opaque 这个设计建模成不透明实体，所以适合跨信任边界
- 举反例故事把 Agent 当工具挂 → 上下文膨胀 + 规则复制
- 主动给反向判断「同一个服务里，我走的是框架内 handoff」
- 说 A2A 和 MCP 是竞品、二选一
- 只会背 Agent Card、Task、Artifact 三个名词，说不出各自解决什么
- 认为 A2A 是「多 Agent 架构」的必需品
- 不知道 v1.0 已经发布，还停留在「Google 出了个新协议」的印象
- 谈安全只说「要鉴权」，不知道卡片签名这一层
- 一纵一横讲清互补，并点出两者同在 Linux Foundation 治理下
- 卡片管发现与鉴权、Task 管长时委派、Artifact 管类型化交付
- 给得出「我们在同一进程里，所以没上」这类反向判断
- 知道 v1.0 在 2026-04-09 发布，也知道 AP2 这类配套协议
- 提到 Agent Card 验签（JWS + 规范化）防的是发现层伪造
INPUT_REQUIRED / AUTH_REQUIRED 是给人机协同留的位置，并和 MCP 的 MRTR 对照着讲。面试官怎么问
Q3-11 常见于头部 AI 公司和有多团队 Agent 落地的公司的二面。问法通常是「A2A 解决什么问题？和 MCP 是竞争还是互补？」——这题的隐藏考点是"你有没有跨团队集成的真实经验"，因为没踩过"把对方工具搬过来"这个坑的人，答案会停留在名词层面。
追问方向：你们用了吗？没用为什么？（说"没用"并给出理由是加分的）Agent Card 怎么防伪？任务卡住怎么办？
答题结构建议
- 一句话定位：MCP 纵向连工具，A2A 横向连 Agent，互补关系，现在都在 Linux Foundation 下。
- 讲 opaque 这个关键设计：A2A 把对端建模成不透明实体，这决定了它适合跨信任边界。
- 举反例故事：讲你（或你见过的团队）把 Agent 当工具挂导致的上下文膨胀 + 规则复制。
- 主动给反向判断："我们内部两个 Agent 在同一个服务里，我没上 A2A，直接走的框架内 handoff——协议是给跨边界准备的。"
分水岭信号
只读过资料的回答：
- 说 A2A 和 MCP 是竞品、二选一。
- 只会背"Agent Card、Task、Artifact"三个名词，说不出各自解决什么。
- 认为 A2A 是"多 Agent 架构"的必需品。
- 不知道 v1.0 已经发布，还停留在"Google 出了个新协议"的印象。
- 谈安全只说"要鉴权"，不知道卡片签名这一层。
真做过的回答：
- 说得出 opaque / 信任边界是 A2A 的设计核心，并能对比"把工具搬过来"的失败模式。
- 提到 Agent Card 验签（JWS + 规范化）防发现层伪造。
- 注意到状态机里 INPUT_REQUIRED / AUTH_REQUIRED 是给人机协同留的位置，并能和 MCP 的 MRTR 对照。
- 提到 返回 Artifact 而非自由文本是一条工程纪律。
- 能给出"我们没上，因为在同一进程里"这类反向判断。
- 知道 AP2 之类的配套协议，或知道 MCP/A2A 同在 Linux Foundation 治理下的生态收敛趋势。
小结与延伸
继续深入
本篇归属第 3 章「Agent 开发」，去做这一章的题。