A2A 为什么补不上 MCP？多 Agent 协作和工具接入根本不是一回事

qq_41678239

831人浏览 · 2026-04-17 13:56:15

qq_41678239 · 2026-04-17 13:56:15 发布

这半年，很多人一看到 A2A 和 MCP，第一反应就是：

它们是不是在做同一件事？

然后讨论很快就会滑向两个方向：

有人说，既然 A2A 能让 Agent 和 Agent 通信，那还要 MCP 干什么？
也有人说，既然 MCP 已经能接工具和上下文了，为什么还要 A2A？

我先给结论：

A2A 和 MCP 解决的根本不是一类问题。

如果硬要压缩成一句话：

A2A 主要解决 Agent 与 Agent 之间怎么发现、协作、委托
MCP 主要解决 Agent 与工具、资源、上下文之间怎么连接

所以你问“A2A 能不能替代 MCP”，就像在问：

部门之间能不能开会，能不能替代员工访问公司内部系统？

完全不是一个层次。

一、为什么这个问题最近更容易被问出来

原因其实很简单：Agent 系统开始从“单智能体 + 几个工具”进入到更复杂的阶段了。

过去很多应用其实只有一个主 Agent：

它接用户请求
它自己调工具
它自己给答案

这时大家最关心的是工具接入，所以 MCP 很容易成为焦点。

但当系统开始变复杂，新的问题就来了：

规划 Agent 要不要把任务分给执行 Agent
不同团队的 Agent 怎么跨系统协作
供应商 A 的 Agent 怎么调用供应商 B 的 Agent
企业内多个 Agent mesh 怎么互通

这时，A2A 的价值才开始被看见。

也正因为两个协议都在 Agent 时代爆红，很多人就误以为它们是互相替代关系。

实际上并不是。

二、A2A 到底在解决什么

Google 在 2025 年发布 A2A 时，对它的定位非常明确：

让 Agent 可以彼此发现能力
让 Agent 能安全交换信息
让 Agent 能跨平台协调复杂任务

到了 2025-06-23，Google 又把 A2A 捐给 Linux Foundation，进一步强调它要做的是：

一个中立、开放、跨供应商的 Agent-to-Agent 协作标准
让企业里的多 Agent 生态不再各自为政

所以 A2A 的重点从来不是“接工具”，而是：

让多个独立 Agent 可以互相对话、互相委托、互相协作。

它更像什么？

它更像：

组织之间的协作协议
不同服务之间的任务委托协议
多 Agent 世界里的“共同语言”

三、MCP 到底在解决什么

再看 MCP。

MCP 官方架构文档里写得很清楚，它是一个：

Host / Client / Server 架构
基于 JSON-RPC
带状态会话
聚焦上下文交换和采样协调

这套设计的重点，不是“Agent 彼此如何协作”，而是：

Host 里的 Agent，如何安全地接入外部能力。

典型场景包括：

访问文件系统
查询数据库
调浏览器
读企业知识库
访问内部 API
提供 prompt、resource、tool

所以从工程视角看，MCP 更像一层 能力接入总线。

它决定的是：

Agent 能接什么
接入过程怎么做权限和边界控制
宿主如何管理不同 server 的连接

四、最容易看懂的区别：A2A 连的是 Agent，MCP 连的是能力

这是我觉得最值得记住的一句话：

A2A 连接 Agent，MCP 连接能力。

为了更直观一点，可以看下面这张图。

这张图说明了两件事：

A2A 管的是 Planner Agent 和 Specialist Agent 之间怎么协作
MCP 管的是 Specialist Agent 怎么拿到完成任务所需的工具和资源

如果没有 A2A，会怎样？

多 Agent 协作不顺
远程委托缺少统一语言
跨团队 Agent 很难互通

如果没有 MCP，会怎样？

Agent 之间也许能说话
但真正干活时，拿不到文件、数据库、浏览器和企业系统

所以一个负责“沟通协作”，一个负责“实际接能力”。

五、为什么说 A2A 补不上 MCP

这是本文最核心的部分。

很多人觉得，既然 A2A 已经能把任务发给另一个 Agent，那被委托的 Agent 自己去处理不就好了？

问题就在这里：

被委托的 Agent 仍然需要能力接入层。

它收到任务之后，通常还要做这些事：

读企业文档
查数据库
调内部 API
操作浏览器
获取用户授权后的资源

而这些事情，不会因为有了 A2A 就自动消失。

换句话说，A2A 只是把任务传过去了，但：

工具怎么接
权限怎么控
资源怎么暴露
宿主怎么管理 server

这些问题仍然是 MCP 这一类协议在处理。

所以：

A2A 解决“找谁干”，MCP 解决“怎么干”。

六、反过来也一样：MCP 也补不上 A2A

同样地，MCP 也不等于多 Agent 协作协议。

MCP 再强，它也更偏：

本地或宿主内连接
工具和上下文暴露
单 Agent 工作面的能力增强

但一旦进入下面这种场景，MCP 就不是主角了：

销售 Agent 把线索交给法务 Agent
支持 Agent 把复杂工单转给分析 Agent
一个企业系统里的 Agent 调另一个供应商平台里的 Agent
规划 Agent 把任务拆给多个领域 Agent 再汇总

这里的核心问题是：

如何描述 Agent 的能力
如何发现可调用的 Agent
如何发起委托
如何拿回任务结果

这类问题显然更属于 A2A 的范畴。

七、用一个完整例子看，就不会混了

假设你在做一个“企业采购助手”。

用户输入：

帮我对比三家供应商的报价，并给我生成审批建议。

一个更真实的执行流程通常会像这样：

在这个流程里：

Planner -> Vendor / Risk 是 A2A
Vendor / Risk -> MCP Servers 是 MCP

如果你把其中任意一个拿掉，系统都会残掉。

八、加一段代码，更容易看出分工

下面是一段示意代码，不是某个具体 SDK 的精确实现，而是为了帮助你看清两层职责。

def handle_purchase_request(user_request):
    # A2A：把子任务委托给不同的远程 Agent
    vendor_result = send_a2a_task(
        agent="supplier-agent",
        task="获取三家供应商报价与交付周期"
    )

    risk_result = send_a2a_task(
        agent="risk-agent",
        task="检查合同风险和历史履约问题"
    )

    # MCP：本地规划 Agent 再读取内部审批模板和知识库
    approval_rules = mcp.read_resource("kb://procurement/approval-rules")
    template = mcp.read_resource("fs://templates/purchase-review.md")

    return synthesize_report(
        user_request=user_request,
        vendor_result=vendor_result,
        risk_result=risk_result,
        approval_rules=approval_rules,
        template=template,
    )

这段代码里，两层边界非常清晰：

send_a2a_task(...) 是把任务交给别的 Agent
mcp.read_resource(...) 是把能力和上下文接给当前 Agent

所以你很难说哪个替代哪个，因为它们压根不是一回事。

九、为什么企业里这两个协议大概率会一起出现

我越来越倾向于认为，未来真正复杂的企业 Agent 系统，通常会同时出现这两层：

第一层：A2A

负责：

多 Agent 发现
多 Agent 协作
跨系统任务委托
结果回传

第二层：MCP

负责：

工具接入
企业上下文暴露
权限边界
host 对 server 的生命周期管理

一层偏“组织协作”，一层偏“能力接入”。

这就像一个公司既需要：

跨团队协作机制
也需要员工访问内网、数据库和业务系统的权限体系

两者缺一不可。

十、还有一个经常被忽视的问题：信任边界不同

这也是 A2A 和 MCP 不适合互相替代的重要原因。

Google 在 A2UI 那篇文章里其实也顺带说清楚了多 Agent world 的一个现实：

远程 Agent 往往在不同服务器
可能属于不同组织
可能根本不能直接碰你的前端或本地环境

这意味着多 Agent 协作天然更容易跨信任边界。

而 MCP 的典型问题更像是：

当前 host 如何安全接入能力
当前用户授权给哪些 server
当前会话里上下文怎么传

所以它们面对的安全和架构问题，本来就不同。

十一、截至 `2026-04-17`，我认为可以下的判断

基于 Google 和 MCP 官方公开材料，我觉得下面几条已经很稳：

1. A2A 的核心目标是多 Agent 协作，不是工具接入

Google 官方一直在强调的是：

discover capabilities
exchange information
coordinate tasks

2. MCP 的核心目标是上下文与能力接入，不是跨组织 Agent 委托

MCP 官方架构文档强调的是：

host / client / server
stateful session
context exchange
sampling coordination

3. 未来复杂系统里，两者很可能一起出现

因为企业真实需求同时包含：

多 Agent 协作
工具和资源接入

4. 真正错误的问题，不是“谁替代谁”，而是“哪一层缺了”

如果系统协作混乱，可能缺的是 A2A。

如果 Agent 拿不到工具、上下文和资源，缺的就是 MCP。

十二、我的结论

所以，回到文章标题：

A2A 为什么补不上 MCP？

因为 A2A 解决的是多 Agent 之间的协作语言，而 MCP 解决的是 Agent 和工具、资源、上下文之间的连接方式。

两者的本质区别可以压缩成最后一句：

A2A 决定 任务怎么在 Agent 之间流动
MCP 决定 能力怎么流进 Agent

理解了这一点，你就不会再把“多 Agent 协议”和“工具接入协议”混成一个东西。

未来真正成熟的 Agent 系统，大概率不是二选一，而是：

上面用 A2A 做协作，下面用 MCP 接能力。

参考资料

Google Developers Blog, Announcing the Agent2Agent Protocol (A2A)
https://developers.googleblog.com/a2a-a-new-era-of-agent-interoperability/
Google Developers Blog, Google Cloud donates A2A to Linux Foundation, 2025-06-23
https://developers.googleblog.com/google-cloud-donates-a2a-to-linux-foundation/
Model Context Protocol, Architecture
https://modelcontextprotocol.io/specification/2024-11-05/architecture/index
Model Context Protocol, Roadmap, last updated 2026-03-05
https://modelcontextprotocol.io/development/roadmap