模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第7章 — MCP：AI的USB-C
Token用量: 约 10,000 input + 1,900 output（估算）
7.3 MCP与A2A
MCP 被广泛接受之后，一个新问题马上出现：如果 MCP 正在标准化 agent 对 tools/data 的访问，那么 agent 之间彼此协作，要靠什么协议？这就是 A2A（Agent-to-Agent Protocol） 的问题空间。很多讨论会把 MCP 和 A2A 当成竞争关系，但这种理解并不准确。它们解决的是两种不同的边界问题。
最短的区分方式是：
- MCP = agent ↔ tools/data
- A2A = agent ↔ agent
前者处理的是 vertical integration（纵向集成）：一个 agent 如何连接到底层能力层。后者处理的是 horizontal communication（横向通信）：一个 agent 如何把任务交给另一个 agent，并协同完成工作。
MCP 面向的是什么问题
MCP 的默认假设是：真正的“主 intelligence”主要在 client/host 这一边。Server 虽然可以很复杂，但从协议视角看，它更像一个 capability provider。Host 负责决定什么时候调用 tool、什么时候读取 resource、什么时候拿 prompt；server 负责把能力声明出来并响应请求。
因此，MCP 的核心交互风格通常是 request-response。哪怕它支持流式进度、notification、甚至 richer interaction，它的本质仍然是：client 在 orchestrate，server 在 expose capabilities。
这也是为什么 MCP 非常适合以下对象：
- search service
- docs service
- filesystem bridge
- browser automation
- database access
- design/data/API connectors
这些东西当然重要，但它们本质上是“能力”而不是“同事”。它们不需要有自己的任务计划，也不需要对外暴露完整的工作生命周期。
另外，MCP 往往是 session-scoped 的。Host 在一个会话里连接 server、列出 tools/resources/prompts、持续调用。Server 也许有状态，但这种状态一般是服务于 host 当前 session 的，而不是一个独立 agent 的长期任务状态机。
A2A 面向的是什么问题
A2A 的出发点完全不同。它假定对面不是一个被动的 capability endpoint，而是另一个具有自主性的 agentic actor。也就是说，对面可能有自己的 model、memory、planning loop、permission policy、execution runtime。这样一来，通信就不能仅仅是“method + params”的问题了。
所以 A2A 更强调 task delegation。一个 agent 把工作提交给另一个 agent；另一个 agent 可以接受、拒绝、请求补充信息、开始工作、回报进度、最后完成。于是协议里必须显式表达 task lifecycle（任务生命周期），最典型的形态就是：
submitted → working → completed
在真实系统里还可能扩展出 failed、blocked、canceled、needs-input 等状态，但关键点在于：A2A 不是单次函数调用，而是一个持续存在的工作实体。
A2A 另一个有代表性的概念是 Agent Cards。可以把它理解成 agent 的机器可读名片：它声明这个 agent 是谁、擅长什么、接受什么输入、遵守什么限制、如何联系。这个术语同样不属于传统 CS 教材里的经典概念，更接近 AI multi-agent 系统中新出现的 service discovery 机制。若说 MCP server 暴露的是 capability list，那么 Agent Card 暴露的是“一个自治工作者的服务画像”。
因此，A2A 更适合以下场景：
- 把 research 委托给 specialist agent
- 把 implementation 委托给 coding agent
- 把 verification 委托给 testing/review agent
- 在不同组织或不同 vendor 的 agent 之间建立协作
- 对长任务进行状态跟踪、取消与回收
换句话说，A2A 是为“智能体之间的协同”设计的，而不是为“智能体访问工具”设计的。
最关键的差异：intelligence 在哪里
理解 MCP 与 A2A 的最好方法，是看 intelligence placement。
在 MCP 中，主要 intelligence 在 client。Server 可以内部很复杂，但对协议来说，它仍然是被 host 调度的能力端点。
在 A2A 中，intelligence 在 双方。发起方要决定委托给谁、何时取消、如何处理部分结果；接收方要决定如何分解任务、如何汇报状态、何时视为完成。
这个差异会影响一整套系统设计。MCP 的返回值通常可以被压扁成 tool output；而 A2A 的返回值往往需要被建模成 task object、status transition、partial result、ownership boundary。信任模型、UI 表达、调度策略都不同。
它们并不是竞争关系，而是互补关系
一旦看清“纵向能力访问”和“横向协同委托”的差别，就会发现 MCP 与 A2A 并不存在真正的替代关系。一个成熟的未来 agent system，大概率两者都需要。
例如，设想一个 2026 年的软件工程 Agent workflow：
- 一个 coordinator agent 收到功能需求。
- 它通过 A2A 把架构分析交给 architecture agent，把代码库调研交给 explore agent，把测试策略交给 verification agent。
- 这些子 agent 在各自工作过程中，再通过 MCP 调用外部能力：docs server、GitHub search、browser tools、filesystem tools、memory system 等。
- coordinator 收集各个 A2A task 的结果，再决定后续实施路径。
这个 layered picture 非常自然：
- MCP 负责 tool access
- A2A 负责 agent coordination
一个给 agent “手和外设”，另一个给 agent “同事和协作网络”。
对比表
| 维度 | MCP | A2A |
|---|---|---|
| 主要关系 | Agent 到 tool/data server | Agent 到 agent |
| 集成方向 | 纵向（vertical） | 横向（horizontal） |
| 核心单位 | Tool / Resource / Prompt | Task / Delegate / Status |
| intelligence 主要位置 | 主要在 client | 双方都有 |
| 交互模式 | 请求-响应式能力访问 | 委托-协作式任务流转 |
| 状态模型 | 通常附着于 session | 明确的 task lifecycle |
| 发现机制 | Server capabilities | Agent Cards |
| 最适合场景 | 搜索、文档、数据库、浏览器、文件、API | 研究委托、专家协作、多智能体编排 |
| 常见失败类型 | tool error、auth error、schema mismatch、timeout | task blocked、rejected、canceled、责任边界冲突 |
| 未来角色 | 外部能力的标准底座 | 多智能体协同的标准底座 |
对 coding agent 设计的启示
对于 coding agent 来说，一个非常实际的判断标准是：你现在面对的边界，到底是“能力边界”，还是“自治边界”。
如果你做的是单智能体编码助手，首先应该优先把 MCP 做好。因为一个单 agent 的上限，往往取决于它能否标准化访问搜索、文档、代码库、浏览器、数据源和其他工具。MCP 是最小可行的 extensibility substrate。
但一旦系统进入 multi-agent orchestration，例如 background specialist、review agent、verification agent、planner/worker 分工，仅靠 MCP 就不够了。你当然可以把“委托另一个 agent”勉强建模成 tool call，但这会在语义上越来越别扭：tool call 天然缺少 owner、status、partial completion、cancelation 这些任务语义。此时 A2A 就会变得必要。
更深的一层启示是：行业可能正在走向一种 two-protocol architecture。一个协议负责 agent 连接外部世界的能力层，另一个协议负责 agent 之间的协作层。这其实很像分布式系统发展史：资源访问和工作协同，往往最终会演化成不同的协议层。Agent 世界现在也在走向类似分化。
所以，真正正确的问题并不是“该选 MCP 还是 A2A”。正确的问题是：你试图标准化的是哪一种边界？如果是 agent 与 capability provider 的边界，MCP 是对的；如果是一个自治工作者与另一个自治工作者之间的边界，A2A 才是对的。
未来并不会出现一个协议吃掉一切的局面。更可能出现的是分层互操作：MCP 标准化 agent 可调用的世界，A2A 标准化 agent 可协作的世界。两者合起来，才构成真正完整的 agent software stack 控制平面。