9.0
重磅
AI SCORE
技术实践2026-08-12 20:56
MCP vs A2A协议解析：Agent连接协议选型指南
dev.to · AI#MCP#A2A#Agent
Editor brief · 编辑速览
MCP和A2A解决不同互操作问题：MCP是Agent→能力（工具/资源），A2A是Agent→Agent（跨服务协作）。Google Cloud已演示两者协同运行的架构。
AI 智能体越来越强大，但把它们连接起来却越来越让人困惑。
在这场讨论中，有两个协议反复出现：MCP（Model Context Protocol，模型上下文协议）和 A2A（Agent2Agent Protocol，智能体间协议）。
初看之下，它们听起来像是相互竞争的标准。事实上并非如此。
MCP 标准化的是 AI 应用如何访问工具、资源和外部能力。A2A 标准化的是独立智能体如何发现彼此并进行通信。
一个简单的心智模型是：
MCP: Agent → Capability
A2A: Agent → Agent
如果你的编码智能体需要查询代码库、读取数据库或调用内部服务，MCP 可能是相关的边界。
如果你的旅行智能体需要把酒店搜索委托给另一个服务拥有的专门酒店智能体，A2A 更接近这个问题。
是的，一个系统可以同时使用两者。Google Cloud 已经展示了这样的智能体架构：MCP 和 A2A 协同工作，而非相互排斥的标准。
这个区别很重要，因为当开发者把 MCP 和 A2A 视为堆栈中只能存在一个时，架构决策就会出错。
核心要点：MCP 和 A2A 解决的是不同的互操作性问题。MCP 将 AI 应用连接到各种能力。A2A 将自主智能体连接到其他自主智能体。
上面那张表就是简短答案。
本文余下部分将解释为什么这个区别在真实系统中很重要。
第一代 LLM 应用通常长这样：
User → Prompt → LLM → Response
现代智能体系统看起来就没那么规整了。
User
↓
Agent
├── Database
├── Search
├── Internal API
├── Payment service
└── Another agent
这些连接并不都是相同的。
数据库查询是一次能力调用。
而远程智能体则可以自主决定如何完成委托的目标。它可能使用自己的模型、工具、记忆、策略和工作流。
这就产生了两个独立的互操作边界：
Agent ↔ Capability
Agent ↔ Agent
MCP 主要解决第一个问题。A2A 解决第二个问题。Google 的开发者指南同样将 MCP 定位在工具和数据周围，而 A2A 处理智能体之间的通信。
这也涉及现代 AI 系统中的上下文工程：可靠的智能体不仅依赖提示词，还依赖工具、数据、状态以及其他参与者如何暴露给模型。
模型上下文协议是一个开放协议，用于将 AI 应用与外部上下文和能力连接起来。
它的架构遵循主机/客户端/服务器模型。AI 应用充当主机，创建 MCP 客户端，并将这些客户端连接到 MCP 服务器。然后服务器暴露应用可以发现和使用的能力。
官方模型上下文协议架构文档定义了核心服务器原语，包括：
[来源：Model Context Protocol Documentation, 2026]
一个基本架构如下：
AI Application
↓
MCP Client
↓
MCP Server
↓
Tool / Data / Service
假设你正在构建一个客服智能体。
它需要访问订单数据。与其将自定义集成逻辑硬编码到每个 AI 应用中，不如让一个 MCP 服务器暴露如下能力：
get_order
get_customer
lookup_shipment
issue_refund
应用可以发现这些能力并调用相应的一个。
想象一个需要代码库信息的编码助手：
Coding Agent
↓
MCP
↓
Repository Server
↓
Git Repository
重要的一点是，代码库服务器不一定是另一个自主智能体。
它暴露的是能力。
编码智能体仍然掌控推理循环：决定需要什么信息、调用相关能力、检查结果、然后选择下一步做什么。
要注意旧的 MCP 图表。
MCP 2026-07-28 规范更新将 MCP 协议核心从有状态的会话模型迁移到了无状态的请求/响应模型。该修订移除了旧的协议层握手和会话要求，同时增加了旨在使 MCP 工作负载更容易路由、缓存、安全防护和扩展的变更。
[来源：Model Context Protocol, 2026]
你的应用仍然可以维护状态。
关键变化是核心协议本身不再需要隐藏的传输层会话状态。
对于初学者来说，你不需要记住迁移细节。只要避免假设每个当前的 MCP 交互都依赖于旧的会话模型即可。
A2A，即 Agent2Agent 协议，是为独立智能体之间的通信而设计的。
当前的 Agent2Agent 协议规范定义了发送消息、处理任务、流式更新和发现智能体的操作。
[来源：A2A Protocol Specification, 2026]
最简单的架构是：
Agent A
↓
A2A
↓
Agent B
但这里重要的词是 agent（智能体）。
Agent B 不只是一个如下所示的函数：
get_weather("Boston")
它可能拥有一个完整的工作流。
你可以向它发送一个目标，比如：
Find a hotel near the conference venue
for under $250 per night, with Wi-Fi,
for September 10–12.
远程酒店智能体可以自行决定：
调用方智能体委托的是目标，而非每一个内部步骤。
A2A 需要一种方式让智能体描述自己。
这就是 Agent Card 的用武之地。
A2A 规范将 Agent Card 描述为一个自描述清单，携带诸如智能体的身份、能力、技能、支持接口、版本和安全需求等信息。
[来源：A2A Protocol Specification, 2026]
Hotel Agent
├── capability: hotel_search
├── capability: availability_check
├── interface: A2A
└── authentication: ...
客户端可以在决定远程智能体是否适合某个任务之前检查这些信息。
这与仅仅知道一个 HTTP 端点存在是不同的。
这是值得记住的部分。
Agent → tool
调用方智能体通常仍负责决定该能力如何融入更大的任务。
calculate_shipping(order_id)
该工具执行一个定义好的操作并返回结果。
Agent → Agent
远程智能体拥有更多的问题解决过程。
Plan the lowest-cost shipping strategy
for these 200 orders while meeting
our delivery SLAs.
那个智能体可能会调用多个服务、评估约束、重试失败的操作，或请求更多信息。
所以这里有一个有用的边界：
工具暴露的是能力。智能体拥有目标如何被解决的方式。
这不是对 AI 智能体完美的哲学定义。
然而，这是一个非常有用的架构测试。
核心要点：如果远程系统暴露的是一种能力，考虑 MCP。如果它拥有推理能力并接受委托的目标，A2A 就更加相关。
现在我们可以把两个概念结合起来。
考虑一个旅行平台：
User
↓
Travel Agent
│
├── MCP → Calendar
│
├── MCP → Customer Database
│
└── A2A → Hotel Agent
│
├── MCP → Hotel Inventory
└── MCP → Maps Service
旅行智能体使用 MCP 来访问它直接需要的能力。
但它不是自己实现酒店搜索推理，而是通过 A2A 将这个目标委托给专门的酒店智能体。
酒店智能体随后可以使用它自己的 MCP 连接的能力。
Google Cloud 发布了关于使用 MCP 和 A2A 构建连接型智能体的实践材料，展示了两个标准在同一智能体堆栈中的协作。
[来源：Google Cloud, 2025]
这是许多浅层比较所忽视的架构。
更好的问题是：
我在标准化的边界是什么？
当 AI 应用需要标准化访问工具、资源或服务时，MCP 很有意义。
不要仅仅因为你的智能体调用了一个函数就添加 MCP。
如果一个应用拥有两端，而你需要的只是：
result = calculate_tax(order)
一个普通的函数调用可能更简单。
协议在边界处增加价值。
但它们也增加了架构复杂度。
只有当互操作性、复用性或独立所有权真正需要时，才使用这种架构。
当远程参与者本身是一个独立智能体时，A2A 就更加有意思了。
A2A 规范支持直接响应以及可能异步继续的面向任务的交互，使其适合不能总是表示为单个即时函数响应的工作。
[来源：A2A Protocol Specification, 2026]
假设你在同一个 Python 进程中有两个智能体：
PlannerAgent → WriterAgent
两者使用相同的框架。
都不需要被独立发现。
你可能不需要仅仅为了让他们通信而引入网络互操作协议。
你的框架的原生智能体组合机制可能就够了。
随着边界变得真实——不同的服务、不同的运行时、不同的框架、不同的供应商或不同的所有者——A2A 变得更有价值。
当你犹豫不决时，按这四个步骤来。
远程一方主要是工具、数据源还是能力？
它是一个能够拥有委托目标的独立智能体吗？
如果你的智能体决定每个步骤，而远程一方执行一个定义好的操作，那么 MCP 或普通工具调用可能更接近问题。
如果远程一方决定如何完成请求的目标，A2A 就更相关。
相同的进程和相同的代码库？
协议可能是不必要的。
跨服务、跨框架、跨组织或跨供应商？
标准化协议就变得更有价值。
许多真实系统同时拥有两者：
Agent → Agent → Tools
A2A MCP
在这种情况下，同时使用 MCP 和 A2A 是完全合理的。
它们主要针对的是不同的关系。
"MCP 只是用于工具调用。"
MCP 服务器可以暴露工具、资源和提示，所以它的范围远超函数调用本身。
"每个多智能体应用都需要 A2A。"
当没有有意义的互操作边界时，内部智能体可以通过框架原生机制通信。
"如果我使用 A2A，远程智能体就不能使用 MCP。"
通过 A2A 连接的的智能体可以在内部使用 MCP 服务器来访问它自己的能力。
如果你不熟悉智能体协议，我建议按这个顺序学习：
1. LLM tool calling
↓
2. MCP basics
↓
3. Single-agent workflows
↓
4. Multi-agent architecture
↓
5. A2A
一旦你已经理解为什么 LLM 调用工具，MCP 就更容易理解了。
一旦你构建了一个拥有推理循环的智能体，并且能清楚地将该智能体与普通工具区分开来，A2A 就更容易理解了。
不要从记住协议负载开始。
从学习架构边界开始。
使用 MCP：Agent → Tool / Resource / Capability
使用 A2A：Agent → Agent
同时使用：Agent → Agent → Tools
这就是核心思想。
MCP 给 AI 应用提供了一种与外部能力交互的标准方式。A2A 给独立构建的智能体提供了一种发现彼此、交换消息和委托工作的标准方式。
两个协议都不会自动让智能体变得智能。
两个协议都不能消除对良好架构的需求。
而且两者都不需要「打败」对方。
当你在设计一个智能体系统时，不要再问：
「MCP 和 A2A 哪个更好？」
而是问：
「我是在将智能体连接到一种能力，还是将智能体连接到另一个自主系统？」
一旦你回答了这个问题，协议选择通常就变得容易多了。
核心要点：真正的决策不是 MCP vs A2A，而是能力集成 vs 智能体协作。