考察点
快手、阿里都问过，是 MCP/A2A 题的进阶版。面试官想听的不是两个定义并列背诵，而是「为什么一个协议搞不定两件事」的底层论证。追问方向：能不能只选一个、生产上怎么共存。
参考答案
一张表看清分工
| 维度 | MCP | A2A |
|---|---|---|
| 交互双方 | Agent ↔ 工具/数据源 | Agent ↔ Agent |
| 方向 | 垂直（能力下沉） | 水平（对等协作） |
| 核心抽象 | Tool / Resource / Prompt | Agent Card / Task / Artifact |
| 交互模式 | 请求-响应，同步为主 | 任务制，异步、多轮、长耗时 |
| 对端的假设 | 无智能，确定性执行 | 有智能，自己规划和决策 |
| 发起方 | 模型决策（经 Host） | Agent 的规划层 |
为什么 MCP 解决不了 A2A 的问题
关键在「对端的假设」这一行。MCP 的世界观里，Server 是没有智能的能力提供方：你传确定的参数，它执行确定的逻辑，返回确定的结果，一次请求-响应闭环。这套抽象套在「调另一个 Agent」头上会立刻崩掉：
- 输入装不下：给另一个 Agent 派活，输入往往不是结构化参数而是一句模糊的话——「帮我盯一下这个竞品的动态」。硬塞进 Tool 的 JSON Schema，等于逼调用方替对方做规划，Agent 的智能被削成了函数。
- 时间装不下：工具调用假设秒级返回，Agent 干活是分钟到小时级。MCP 没有任务对象、没有状态机、没有「先挂起回头再问」的语义，长任务只能挂着连接干等。
- 交互装不下：协作中对方可能反问（「预算上限是多少」），这在 MCP 里没有对应原语——Tool 要么成功要么报错，没有「做到一半需要补充输入」这个状态。A2A 的 input-required 状态和多轮 Message 就是干这个的。
- 发现装不下：工具发现是列函数清单，Agent 发现要知道对方「会干哪类活、输出什么形态、怎么鉴权」，信息量和语义层级不同，所以 A2A 有 Agent Card 而不是复用 tools/list。
反过来 A2A 也替代不了 MCP：用它调一个查汇率的函数，等于为一次确定性调用维护任务状态机，杀鸡用牛刀还更慢。
生产上怎么共存
标准的多 Agent 系统里两者是嵌套关系：主 Agent 通过 A2A 把子任务委托给远程的专业 Agent；每个专业 Agent 内部再通过 MCP 接自己的数据库、API、文件系统。A2A 是组织对组织的接口，MCP 是组织内部对工具的接口，边界清晰。判断一个新接入方该用哪个，就问一句：对面是会自己动脑的 Agent，还是等参数执行的函数？前者 A2A，后者 MCP。
可能的追问
- 能只用 MCP 模拟 Agent 间协作吗？ 技术上可以把「调某 Agent」包成一个 Tool，但这只是把 A2A 的问题（长任务、多轮、发现）推回给自己造轮子，协议的意义就是不用每家公司各造一遍。
- 两个协议会融合吗？ 短期内更可能是边界磨合而非融合，比如远程 MCP Server 和轻量 Agent 的界限会模糊。但「函数语义」和「任务语义」的差异是本质的，两套抽象大概率都会留着。
- A2A 里的 Remote Agent 自己不接工具行不行？ 完全可以，它可能纯靠模型能力干活（比如翻译 Agent）。MCP 是 Agent 增强能力的手段，不是 Agent 的必备组件。