A2A 与 MCP：两种 AI Agent 互联协议解析与选型
A2A 与 MCP：两种 AI Agent 互联协议解析与选型
引言
做 AI 应用的人这两年绕不开两个缩写：MCP（Model Context Protocol）和 A2A（Agent2Agent Protocol）。它们都由头部厂商提出，都被冠以”开放标准”，却常常被混为一谈。很多人以为它们是同类竞品，其实两者解决的是完全不同的问题。
读完本文你会明白：
- MCP 解决的是「模型如何调用外部工具和数据」，管的是单体 Agent 的能力接入；
- A2A 解决的是「一个 Agent 如何找到并协作另一个 Agent」，管的是多 Agent 之间的互联；
- 两者不是二选一，而是经常叠加使用，各自负责协议栈的不同层次。
本文面向已经了解 LLM 基本概念、准备搭建 Agent 系统的开发者。文中事实以官方文档与规范为准，个人理解处会明确标注。
背景：为什么 Agent 需要协议
先看一个演进过程。最早的 LLM 应用是”问答机”：模型吃 prompt，输出文本。很快大家发现模型不会查数据库、不会调 API，于是有了 Function Calling——模型按 JSON Schema 声明”我要调什么函数、传什么参数”，应用去执行。这解决了单机场景下模型与代码的连接，但每接一个工具都要写一遍适配。
更复杂的诉求随之而来：一个”订机票的 Agent”需要去读日历、查航班、走支付；一个”招聘 Agent”需要和”简历解析 Agent”、”背景调查 Agent”协作。前者要的是把各种数据源和工具统一接进来，后者要的是让多个独立 Agent 互相发消息、接力完成任务。
于是出现了两条互补的技术路线：一条向下接入能力（MCP），一条横向连接 Agent（A2A）。
MCP：模型与工具、数据的标准化连接
MCP 由 Anthropic 于 2024 年 11 月发布，核心目标是消除”每个 AI 应用都要为每个数据源写一遍自定义集成”的重复劳动。它把”模型需要的外部能力”抽象成三类原语：
| 原语 | 含义 | 典型例子 |
|---|---|---|
| Tools（工具） | 可执行的函数，模型决定何时调用 | 查数据库、发消息、调支付 API |
| Resources（资源） | 供模型读取的上下文数据 | 文件内容、数据库记录、API 返回 |
| Prompts（提示词模板） | 可复用的交互模板 | system prompt、few-shot 示例 |
每种原语都配套发现（*/list）与获取（*/get、*/call）的方法，协议统一约定 JSON-RPC 格式的消息。这意味着一个”文件系统 MCP Server”写一次，Claude、Cursor、任意支持 MCP 的应用都能复用，不需要为每家平台重写适配层。
MCP 的三层角色
MCP 架构里三方各司其职，可以类比为插排、插头、电器：
- Host（主机）：用户直接交互的 AI 应用，内含 LLM，如 Claude Desktop、Cursor。相当于插排本身——提供电源接口。
- Client（客户端）：Host 内部的翻译器，负责把 Host 的语言翻译成 MCP 协议消息。相当于插排上的每个插孔。
- Server（服务端）：承载并执行工具的程序，如文件系统、数据库 Server。相当于电器——它自己不知道插排是谁，只遵守统一的插头规格。
用一个生活化比喻帮助记忆：MCP 相当于”统一的电源插头标准”。过去每个家电（数据库、GitHub、日历）都要造自己形状的插孔，AI 应用接起来头疼；MCP 规定大家用同一个插头和插孔，于是任何”电器”（Server）都能插进任何”插排”（Host）。
比喻的边界：插头接上就通电，但 MCP Server 并不会”主动来找你”——它只是被动等待 Host 的 Client 来连接和调用，连接的建立仍需要配置。
flowchart LR
subgraph Host["Host（AI 应用，含 LLM）"]
C1["Client 1"]
C2["Client 2"]
end
C1 -->|JSON-RPC| S1["MCP Server（工具/资源）"]
C2 -->|JSON-RPC| S2["MCP Server（数据库）"]图 1：MCP 架构中一个 Host 通过多个 Client 连接多个 Server，通信基于 JSON-RPC。
A2A：Agent 与 Agent 的对等协作
A2A 由 Google 于 2025 年 4 月提出，定位是企业级场景下多 Agent 协作的开放协议。它回答的问题不是”模型怎么调工具”，而是”一个 Agent 怎么发现另一个 Agent、把任务交过去、再拿回结果”。
A2A 的几个核心概念：
- Agent Card（代理名片）：每个 Agent 对外发布的一份 JSON 元数据，描述自己的身份、能力、技能、接口地址和认证要求，通常放在
/.well-known/agent-card.json。Client 通过读它来发现合适的 Agent 并决定如何通信。这是 A2A 的”发现”机制。 - Task（任务）：一个有状态的进程，Client 和远端 Agent 围绕一个目标协作，有明确的生命周期（如
submitted → working → completed）。长任务可以持续同步进度，而不是一问一答就结束。 - Message（消息）：Client 与 Agent 之间的一轮通信，承载指令、上下文或结果。
- Artifact（产物）：任务产生的文件、报告等输出物。
A2A 的重点在于任务管理（Task Management）：任务可以有状态、可追踪、可跨长时间运行，Agent 之间能对”某件事做到哪一步”保持一致。
生活化比喻：A2A 像企业里的”跨部门工单系统”。部门 A 需要成果，但不关心部门 B 内部怎么干活——它只需要提交一张工单（Task）、说明需求（Message）、跟踪状态（Task 生命周期），最后接收交付物（Artifact）。部门 B 通过”部门简介”（Agent Card）被找到，并对外承诺”这类活我能接”。
比喻的边界：工单系统通常有中心调度，而 A2A 协议本身不强制中心节点——它是点对点的，只要双方都遵守协议即可通信。
sequenceDiagram
participant C as Client Agent
participant S as Remote Agent
C->>S: 读取 Agent Card（发现能力）
C->>S: 发起 Task（携带 Message 指令）
S-->>C: 返回 Task 状态（working / 进度）
S-->>C: Task 完成，返回 Artifact 产物图 2：A2A 的一次典型协作流程——先通过 Agent Card 发现，再以有状态的 Task 接力并回收产物。
对比：MCP 与 A2A 的差异点
| 对比维度 | MCP | A2A |
|---|---|---|
| 提出方 / 时间 | Anthropic，2024 年 11 月 | Google，2025 年 4 月 |
| 解决的核心问题 | 模型如何调用外部工具与数据 | 一个 Agent 如何发现并协作另一个 Agent |
| 通信双方 | 应用/Host ↔ 工具 Server（不对等，有主从） | Agent ↔ Agent（对等，双向协作） |
| 关注对象 | Tools / Resources / Prompts 三类原语 | Task / Message / Artifact，以及 Agent Card 发现 |
| 有无状态 | 以工具调用为主，偏”一问一答”式 | 任务有状态、有生命周期，支持长时间运行 |
| 发现机制 | 靠 Client 端配置接入 Server | Agent Card 公开元数据，供对端发现 |
| 传输 / 协议 | 基于 JSON-RPC，典型走 HTTP/Streamable HTTP | 基于 JSON，走 HTTP（也有 v1.0 的演进） |
| 生态现状 | 工具接入侧渗透广，AI IDE、Agent 框架普遍支持 | 多 Agent 协作场景，厂商与框架逐步接入 |
一句话概括差异：
MCP 管”能力接入”（纵向，模型↔工具），A2A 管”Agent 互联”（横向，Agent↔Agent）。
这决定了它们在技术栈中的位置完全不同。MCP 解决的是”一个 Agent 的工具从哪里来”，A2A 解决的是”多个 Agent 怎么把任务传下去”。
适用场景
适合用 MCP 的场景：
- 给一个 LLM 应用接数据库、文件系统、GitHub、Slack、日历等具体数据源和工具；
- 想做一个”工具丰富”的单一 Agent，并希望这些集成可复用、跨平台；
- 接入方是 Host（应用）与服务方（工具 Server）的关系，模型直接驱动工具调用。
典型例子：一个客服 Agent 通过 MCP 连接 CRM、订单库和退换货接口，在一个 Host 内部完成查询与处理。
适合用 A2A 的场景：
- 多个独立部署、由不同团队维护的 Agent 需要协作完成端到端流程；
- 任务周期长、需要持续跟踪状态、中间可能有人工介入或跨系统接力；
- 你需要”一个 Agent 根据 Agent Card 自动发现并调用另一个 Agent”。
典型例子：招聘 Agent 把”简历解析”交给 A2A 对端的专业 Agent，再把自己不擅长的”背调”接力给第三个 Agent，每个 Agent 独立演进、互不侵入内部实现。
个人理解（推测，非官方表述）：粗看可把 MCP 类比为”协议栈的下层——能力面”，A2A 类比为”上层——协同面”。一个 Agent 先用 MCP 接好它的工具，再用 A2A 去和其他 Agent 协作。
组合使用：MCP + A2A
实践中两者往往同时出现，而不是互斥。一个常见的架构是：
- 每个 Agent 内部用 MCP 接入自己的工具与数据，保证”单兵作战”能力；
- 每个 Agent 对外发布 Agent Card，通过 A2A 与其他 Agent 协作，保证”团队作战”能力；
- 上层一个编排 Agent 用 A2A 发起 Task，把工作分发下去，再汇总各 Agent 的 Artifact。
也就是说：MCP 让 Agent 变得”有用”（有工具可调），A2A 让 Agent 变得”合群”（能被找到、能接力）。两者解决的是不同层面的问题，因此被越来越多框架视为互补的成对标准。
总结
- MCP（Anthropic，2024）标准化了「模型 → 工具/数据」的连接，核心是 Tools / Resources / Prompts 三类原语，偏 Host↔Server 的接入关系。
- A2A（Google，2025）标准化了「Agent → Agent」的协作，核心是 Agent Card 发现 + 有状态的 Task / Message / Artifact，偏对等的多 Agent 协作。
- 选择建议：单 Agent 要接工具和数据，选 MCP；多 Agent 要互联协作、接力长任务，选 A2A；完整体系往往两者并用。