考察点
这道题出自快手和阿里的 Agent 方向面试，承接「什么是 A2A」往下问。面试官想淘汰的是把两个协议当成二选一背名词解释的人——MCP 和 A2A 解决的压根不是同一个问题。得分关键在于讲清「垂直 vs 水平」的层级差异，以及「只选一个」在什么架构下成立。追问会往 A2A 的任务生命周期、push notification、两者在一个系统里怎么共存走。
参考答案
一句话定位：MCP 连工具，A2A 连同事
MCP 解决的是一个 Agent 怎么用工具：把数据库、API、文件系统这些能力标准化地暴露给模型，本质是 Agent 与工具之间的垂直连接——工具是透明的、无自主性的，你给它参数它给你结果。
A2A（Google 主导的 Agent2Agent 协议）解决的是Agent 与 Agent 怎么协作：一个客服 Agent 要把「查物流」委托给另一个团队维护的物流 Agent，双方是平等的、各自有自主决策能力的同事关系，这是水平连接。
这个差别决定了协议设计的一切：
- 能力描述不同。MCP 的 Server 暴露的是确定性工具列表，参数 schema 清清楚楚。A2A 里对方 Agent 是个黑盒，你只能通过 Agent Card（一张描述「我会做什么、我在哪、怎么鉴权」的名片）了解它的技能边界，具体怎么实现你不用知道也不该知道。
- 交互粒度不同。MCP 是一次函数调用，同步、短平快。A2A 的核心抽象是 Task：有完整的生命周期（submitted → working → completed/failed），因为对方 Agent 干活可能要几分钟甚至几小时，中间还会反问你问题（input-required 状态）。
- 通信模式不同。A2A 原生支持流式更新（SSE）和 push notification——长任务不可能让调用方挂在那等，对方完成了主动推回调给你。MCP 没有这种需求。
是竞品吗？不是，是两层
把 MCP 和 A2A 当竞品，就像问「USB 接口和钉钉是竞品吗」。一个真实的多 Agent 系统里两者是嵌套关系：
用户 → 主 Agent ──A2A──→ 物流 Agent ──MCP──→ 运单查询工具、短信工具
└─A2A──→ 售后 Agent ──MCP──→ 工单系统、退款 API
每个 Agent 对外用 A2A 暴露「业务能力」，对内用 MCP 接自己的工具。A2A 协议的设计文档里也明确写了与 MCP 互补。
能不能只选一个？看架构形态
- 只有一个 Agent + 一堆工具：只用 MCP，A2A 完全用不上。这也是目前绝大多数落地的形态。
- 多个 Agent 但都是你自己团队写的：可以只用一个共享的编排框架（Agent 作为内部模块互相调用），不一定需要 A2A 这种跨组织协议。
- Agent 跨团队、跨公司、跨厂商：A2A 的价值才真正出现——你不可能去接别人内部的 MCP Server，那是他的实现细节；你需要的是一个稳定的、面向「业务委托」的边界协议。
所以答案是：协议选型跟着系统边界走。工具是内部实现，Agent 是外部协作者，两条边界用两个协议，谁也不是谁的替代品。
可能的追问
1. A2A 的 push notification 具体解决什么问题？
长任务异步回调：调用方提交任务后不用保持连接，被调 Agent 完成或状态变化时主动推送。没有它，跨 Agent 的分钟级任务只能靠轮询或长连接硬等，资源和可靠性都撑不住。
2. A2A 里怎么处理任务中需要用户补充信息的情况？
Task 状态机里有 input-required 状态：被调 Agent 把任务挂起并返回需要补充的内容，调用方（或终端用户）补全后任务继续，Task id 不变。
3. MCP Server 能不能包装成一个 A2A Agent 对外提供？
技术上可以套一层壳，但要想清楚边界：纯确定性工具直接给 MCP 更合适；只有当调用方需要「委托一件有自主性的事」时，包装成 Agent 才有意义，否则徒增一层抽象。