A2A 协议解决什么问题？和 MCP 是竞争还是互补？
谁在问：头部 AI 公司与平台团队二面；用来看你是否跟得上 2026 协议层演进，以及会不会过度设计
口语化问法
- A2A 你了解吗？它跟 MCP 是不是打架的？
- Agent 之间通信，为什么不能直接把对方包成一个 MCP 工具？
- 你们内部有多个 Agent，会考虑上 A2A 吗？
考察意图
这题有两个坎，一个向上一个向下：
- 向上：能不能说清 A2A 与 MCP 的分工，并且答到 v1.0 的关键设计（Agent Card 的发现与签名、任务状态机、opaque）。只会说"一个管工具一个管 Agent"是及格，说不出为什么必须分开是没读过。
- 向下：会不会过度设计。第三个口语化问法是陷阱——公司内部几个 Agent 之间用不上跨组织协议，直接进程内调用或共享编排框架更简单也更可观测。上来就说"内部也该用 A2A 统一起来"的人，面试官会怀疑你的工程判断。
参考答案
60 分答案（及格线）
互补，不竞争。 分工很清楚：
- MCP 管 Agent → 工具：我怎么拿到并调用一个能力。工具是我知道内部行为的、确定性的东西。
- A2A 管 Agent → Agent：我怎么把一个任务委托给另一个 Agent。对方是个自治黑盒——用什么模型、调几个工具、跑几步，我不知道也不需要知道。
A2A 的核心设计词就是 opaque（不透明）：双方不暴露内部实现。这既是商业上的必要（对方的编排就是它的核心资产），也是工程上的解耦（对方换实现不该打崩我）。
截至 2026-08，A2A 已在 2026-04-09 发布 v1.0，由 Linux Foundation 中立托管，150 多家组织参与。技术上是 HTTP + JSON-RPC 2.0，配合 SSE 推送任务进展；能力发现靠 Agent Card（放在 /.well-known/agent-card.json）。一个系统里两者常常同时存在：我的 Agent 用 MCP 接工具，同时通过 A2A 对外提供服务或委托任务。
90 分答案（有生产经验的回答）
补三层。
1. 为什么不能"把对方 Agent 包成一个工具"就完事？ 技术上能凑合，但三处语义对不上：
- 耗时：工具调用的心智模型是"调了就返回"，跨 Agent 的任务可能跑几分钟到几天。所以 A2A 把任务（Task）做成一等公民，有完整的状态机——v1.0 定义九个状态，归成 Running / Paused / Finished 三组，配 SSE 推送进展。
- 中断与人工介入：委托出去的任务可能需要等待补充信息或对方的人工审批，这是 Paused 组存在的意义；工具调用没有这个语义。
- 信任边界：对方是另一个组织，需要身份验证与能力声明的可信性——这是 Agent Card 要签名的原因。
2. Agent Card 的签名细节值得说。 Card 用 JWS（RFC 7515） 签名，并且要求先按 RFC 8785（JCS）做 JSON 规范化再签。为什么需要规范化：同一份 JSON 用不同库序列化，键顺序和空白可能不同，字节流一变签名就验不过；先规范化才能让签名稳定可验。不签名的后果很直接——攻击者伪造一份能力更强的 Card，把你的任务骗过去，而你连数据发给谁了都不知道。
3. 配套的 AP2（Agent Payments Protocol）也要知道。 跨组织委托一旦涉及付费（对方的服务是收费的、或者任务本身就是采买），就需要标准化的授权与支付语义——额度、授权凭据、可核验的交易记录。这也解释了 A2A 生态的野心：它想支撑的是跨组织的 Agent 市场，不只是消息传递。
4. 三段式看 A2A。
- 解决什么：跨信任边界的任务委托、长任务的状态跟踪与恢复、能力发现与身份验证、标准化的失败与授权语义。
- 代价是什么：多一层协议与运维；opaque 带来调试困难与责任界定难（对方失败你只拿到一个状态码）；失败模式复杂（超时、部分完成、需要补偿）；生态尚在早期，实现质量参差。
- 什么时候不该用：自家内部的多 Agent 编排——同一个团队、同一套可观测体系，直接进程内调用或用编排框架更简单、trace 更完整、调试更容易；确定性的短耗时能力——做成工具或普通 API 就够了；不需要跨组织信任验证的场景，签名和 Card 那套纯属负担。
截至 2026-08 的一句现实判断：规范已经 1.0 且治理中立，但真正跨组织的生产部署仍在早期，大多数团队的"多 Agent"其实还是内部编排。所以面试里最稳的表达是：知道它解决什么，也知道自己现在还用不上它。
追问链
什么时候把对方做成 MCP 工具，什么时候做成 A2A 的 Agent？
期望四条判据：① 自治判断（自己决定步骤 → Agent，输入输出确定 → 工具）；② 耗时（秒级 → 工具，分钟到天级 → Agent）；③ 信任边界（跨组织要身份与能力验证 → A2A）；④ 实现该不该暴露 → opaque 正为此而设。四条都不成立还上，是为协议而协议信号给多维判据还主动补反向判断 → 有工程判断；答「A2A 更先进所以优先用」→ 跟风opaque 是设计目标，那出了问题怎么调试、怎么定责？
期望不透明的是实现，状态必须透明：① 关联 id 跨边界透传让双方 trace 对上；② 契约化——「失败了」没法定责，「因缺字段 X 失败」才行；③ 存档 + Card 版本签名留痕当证据；再加 SLA 与降级路径。能容忍多不透明，取决于这次委托可不可逆信号区分「实现不透明 / 状态必须透明」并挂钩动作可逆性 → 想清楚了；答「黑盒没法调试」→ 不知道契约才是解法Agent Card 为什么必须签名？为什么还要先做 JSON 规范化？
期望签名防冒充与篡改——/.well-known/agent-card.json是发现入口，入口可伪造后面全白搭。先按RFC 8785规范化是因为 JSON 序列化不唯一：键顺序、空白、Unicode 转义一变，JWS验签就挂。签名不等于可信，信任根与吊销另管信号能解释「序列化不唯一导致验签失败」并指出签名不等于可信 → 读过规范；只答「签名保证安全」→ 套话委托的任务跑到一半要等人工审批，或者对方挂了，客户端怎么办？
期望九态三组（Running/Paused/Finished）的用途：Paused = 任务还活着但在等审批。客户端要能长期挂起、被 SSE 唤醒，也要能主动查询（SSE 断线是常态）；再处理超时、断线重建、重试幂等（重发不能变两个任务）、部分完成的补偿；涉费走 AP2 控额度信号主动提「SSE 会断、必须能主动查询」和「部分完成要补偿」→ 做过长任务；只答「等它返回」→ 没考虑跨进程失败模式委托出去的外部 Agent 替你给客户发了一封错误的邮件，怎么止血、定责、防复发？
期望止血：预置开关关掉委托链路，切回本方或人工 → 排影响面（几封、给了谁、错在哪）→ 主动致歉纠正。定责靠留痕：我方任务定义、对方状态与原因码、当时的 Card 版本与签名——多数事故真相是授权太宽而非对方恶意。防复发：不可逆动作不外包，委托对方生成、执行留在本方，中间加策略校验；配套 AP2 额度与可撤销窗口、影子模式、SLA 写进合同、case 进回归集信号根因归到授权边界而不是对方水平、并给出「生成外包、执行自留」→ 设计过跨组织协作；只答「找对方赔偿」→ 没抓住本质
JWS + RFC 8785、九态三组），第 1、5 层验你会不会过度设计、会不会乱授权 —— 后者才是淘汰位。评分要点
- 明确 A2A 与 MCP 互补：Agent→工具 vs Agent→Agent
- 说得出核心设计词 opaque 及其双重动机（商业保护 + 工程解耦）
- 知道任务是一等公民：九态分 Running / Paused / Finished，SSE 推进展
- 知道 Agent Card 位于
/.well-known/agent-card.json，用于能力发现 - 知道 Card 需 JWS 签名 + RFC 8785 规范化，并能解释规范化的必要性
- 说得出代价：调试与定责困难、失败模式复杂、生态早期
- 能说出什么时候不该用（内部编排、确定性短任务）
- 加分：知道配套的 AP2 支付授权语义
- 加分：知道 v1.0 于 2026-04-09 发布、Linux Foundation 中立托管（截至 2026-08）