MCP 与 A2A：Agent 通信协议深度解析
摘要: 系统对比了 Anthropic 的 MCP（Model Context Protocol）与 Google 的 A2A（Agent-to-Agent Protocol）两大 Agent 协议标准。MCP 采用 Client-Server 架构，通过 Resources、Tools、Prompts 和 Sampling 四大原语实现 LLM 与外部工具及数据源的标准化连接，被喻为 'AI 的 USB-C 接口'。A2A 则聚焦于 Agent 之间的任务协作，通过 Agent Card 实现能力发现，以 Task 为基本交互单元支持完整的生命周期管理，被喻为 'Agent 的 HTTP 协议'。两者分工明确：MCP 解决垂直方向的 LLM 到工具连接，A2A 解决水平方向的 Agent 间通信，共同构成 Agent 生态的协议基础设施。
核心思想
Agent 协议是让不同 AI 系统之间"说同一种语言"的标准化接口。没有协议，每个 Agent 和工具都是孤岛；有了协议，就构建了一个互通的 AI 生态系统。
Agent 通常通过统一的通信协议、消息队列或共享知识库进行交互，实现任务委派与协同。常见的通信方式与协议有如下几类：
- 标准化通信协议： A2A、MCP
- 消息传递与中间件
- 协作与交互策略
1. MCP（Model Context Protocol）
1.1 背景与愿景
2024 年 11 月，Anthropic 发布了 Model Context Protocol (MCP)，并赋予它一个响亮的比喻："AI 的 USB-C 接口"，主要用于 Agent 与外部工具、数据源和上下文建立标准化连接。
MCP 解决的问题：
没有 MCP 的世界：每个 LLM/Agent 都要单独对接每个数据源
┌──────┐ ┌──────┐ ┌──────┐
│Claude│ │ Chat │ │开源 │
│ │ │ GPT │ │模型 │
└──┬───┘ └──┬───┘ └──┬───┘
│ │ │
├────────┼────────┤ 每个模型都写一遍
│ │ │ 对接代码 (M×N 的复杂度)
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│Google│ │GitHub│ │ Slack│ │ 数据库│
│Drive │ │ │ │ │ │ │
└──────┘ └──────┘ └──────┘ └──────┘
有 MCP 的世界：统一接口，即插即用
┌──────┐ ┌──────┐ ┌──────┐
│Claude│ │ Chat │ │开源 │
│ │ │ GPT │ │模型 │ ← MCP Hosts (消费者)
└──┬───┘ └──┬───┘ └──┬───┘
│ │ │
└────────┼────────┘
│ 一次对接，所有模型通用
▼
┌───────────────┐
│ MCP 协议 │ ← 标准接口层
└───────┬───────┘
│
┌────────┼────────┐
▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐
│Google│ │GitHub│ │ Slack│ ← MCP Servers (提供者)
│Drive │ │ │ │ │
└──────┘ └──────┘ └──────┘类比理解：
- USB-C 出现之前，每个设备都有自己的充电线（Micro USB、Lightning、专用充电器）。USB-C 统一了接口——一根线适配所有设备。
- MCP 同理：一套协议，让所有 LLM 都能访问所有工具和数据源。
1.2 MCP 架构：Client / Server / Transport
MCP 采用经典的 Client-Server 架构：
┌──────────────────────────────────────────────────────────┐
│ MCP Host (宿主程序) │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ MCP Client (客户端) │ │
│ │ │ │
│ │ • 管理与 Server 的连接 (1个 Client 可连多个 Server)│ │
│ │ • 协商协议能力和版本 │ │
│ │ • 将 Server 暴露的功能转换为 LLM 可用的 Tools │ │
│ │ • 路由 LLM 的 Tool Call 到对应的 Server │ │
│ └───────────┬──────────────────┬────────────────────┘ │
└──────────────┼──────────────────┼────────────────────────┘
│ │
Transport│ │ Transport
(stdio) │ │ (HTTP/SSE)
▼ ▼
┌─────────────────────┐ ┌─────────────────────┐
│ MCP Server A │ │ MCP Server B │
│ (本地文件系统) │ │ (远程API) │
│ │ │ │
│ Resources: │ │ Resources: │
│ • file://docs/ │ │ • postgres:// │
│ • dir://project/ │ │ • github://repo │
│ │ │ │
│ Tools: │ │ Tools: │
│ • read_file() │ │ • search_code() │
│ • write_file() │ │ • create_issue() │
│ • list_dir() │ │ • get_pr() │
└─────────────────────┘ └─────────────────────┘三个核心角色：
| 角色 | 说明 | 举例 |
|---|---|---|
| MCP Host | 运行 LLM 的应用程序 | Claude Desktop、VS Code、自定义 App |
| MCP Client | Host 中管理 Server 连接的组件 | 内嵌在 Host 中的协议客户端 |
| MCP Server | 提供具体能力的服务端 | 文件系统服务、数据库服务、GitHub 服务 |
Transport（传输层）的两种模式：
stdio 传输 (本地)
═══════════════════════════════════════════════════════════════════
Host ──> 启动 Server 进程 ──> 通过标准输入/输出通信
适用：本地工具（文件系统、命令行、本地数据库）
优点：零网络配置、安全（进程级隔离）
缺点：无法跨机器
HTTP + SSE 传输 (远程)
═══════════════════════════════════════════════════════════════════
Host ──> HTTP 请求 ──> 远程 Server
│
Server-Sent Events (SSE) 推送 <── 用于实时通知
适用：远程服务（GitHub API、企业数据库、第三方工具）
优点：跨网络、可共享
缺点：需要网络安全和认证1.3 MCP 的核心能力（Primitives）
MCP 定义了 Server 可以暴露的四种核心能力：
MCP 四大能力
═══════════════════════════════════════════════════════════════════
┌─────────────────────────────────────────────────────────────┐
│ │
│ ① Resources (资源) │
│ • 暴露数据给 LLM 阅读 │
│ • 类比：文件系统中的"文件" │
│ • URI 标识: file:///docs/report.pdf │
│ • 支持文本和二进制内容 │
│ • 可以有子资源 (Resource Templates) │
│ │
│ ② Tools (工具) │
│ • LLM 可以调用的函数（Function Calling） │
│ • 类比：API 接口 │
│ • 定义：名称、描述、JSON Schema 参数 │
│ • LLM 决定是否调用、传什么参数 │
│ │
│ ③ Prompts (提示模板) │
│ • 预定义的 Prompt 模板 │
│ • 类比：快捷方式 / 宏 │
│ • 可以包含参数，也可引用 Resources │
│ • 例如："code_review" 模板自动引用当前文件 │
│ │
│ ④ Sampling (采样) │
│ • Server 可以请求 Host 进行 LLM 推理 │
│ • 类比：Server 说"这段文本帮我用 LLM 处理一下" │
│ • 实现 Agent-to-Agent 的 LLM 能力共享 │
│ • 注意：Host 可以拒绝（权限控制） │
│ │
└─────────────────────────────────────────────────────────────┘四种能力的使用场景对比：
| 能力 | 谁驱动 | 典型场景 | 类比 |
|---|---|---|---|
| Resources | LLM 读取 | "帮我看看这个PDF讲了什么" | 文件 |
| Tools | LLM 调用 | "帮我把这段代码提交到GitHub" | API |
| Prompts | 用户/LLM 选择 | "用代码审查模板分析这段代码" | 快捷键 |
| Sampling | Server 请求 | Server 内部用 LLM 处理数据 | 委托 |
1.4 MCP 的交互流程
Host Client Server
│ │ │
│ 1. 启动连接 │ │
│────────────────────>│ │
│ │ 2. 初始化握手 │
│ │───────────────────>│
│ │ 3. 能力协商 │
│ │<───────────────────│
│ │ (返回 Resources, │
│ 4. 注册 Tools │ Tools, Prompts) │
│<────────────────────│ │
│ │ │
│ 5. 用户提问 │ │
│ "我的项目用了哪些 │ │
│ 开源库？" │ │
│ │ │
│ 6. LLM 分析 → 决定 │ │
│ 读 package.json │ │
│────────────────────>│ │
│ │ 7. resources/read │
│ │───────────────────>│
│ │ 8. 文件内容 │
│ │<───────────────────│
│ 9. LLM 读取结果 │ │
│<────────────────────│ │
│ │ │
│ 10. LLM 分析 → │ │
│ 需要查每个库 │ │
│────────────────────>│ │
│ │ 11. tools/call │
│ │ search_web("react │
│ │ license") │
│ │───────────────────>│
│ │ 12. 搜索结果 │
│ │<───────────────────│
│ 13. LLM 综合生成 │ │
│<────────────────────│ │
│ │ │
│ 14. 最终回答 │ │
└─────────────────────┴────────────────────┘1.5 MCP 生态与现状
官方 Server (Anthropic 维护):
├─ Filesystem: 文件系统操作
├─ GitHub: GitHub API 集成
├─ Google Drive: Google 云端硬盘
├─ PostgreSQL: 数据库查询
├─ Slack: 团队沟通
├─ Puppeteer: 浏览器自动化
├─ Brave Search: 网络搜索
├─ Memory: 持久化记忆
└─ Git: 版本控制
社区 Server (第三方):
├─ 数百个社区贡献的 Server
├─ Docker 容器化的 MCP Server
├─ 云平台集成 (AWS, GCP, Azure)
└─ 企业内部系统 (SAP, Salesforce)
工具/框架支持:
├─ Claude Desktop (原生支持)
├─ Continue (IDE 插件)
├─ Cursor / Windsurf (AI IDE)
├─ LangChain / LlamaIndex (通过适配器)
└─ OpenClaw, Hermes (Agent 框架)
对比关键竞品:
┌──────────┬──────────┬──────────┬──────────┐
│ │ MCP │ OpenAI │ Google │
│ │(Anthropic│ Function │ A2A │
│ │ 开放) │ Calling │ │
├──────────┼──────────┼──────────┼──────────┤
│ 定位 │ 通用标准 │ 自家API │ Agent间 │
│ 开放性 │ 完全开放 │ OpenAI专属│ 开放标准 │
│ 模型无关 │ ✅ │ ❌ │ ✅ │
│ 社区驱动 │ ✅ │ ❌ │ ✅ │
└──────────┴──────────┴──────────┴──────────┘2. A2A（Agent-to-Agent Protocol）
2.1 背景与定位
2025 年 4 月，Google 发布了 Agent-to-Agent Protocol (A2A)。如果说 MCP 是"AI 的 USB-C"（连接工具与数据），那 A2A 就是"Agent 的 HTTP"——让不同的 Agent 之间互相通信和协作。
由 Google 等主导的开放标准。它允许不同框架（如 CrewAI、LangGraph）开发的 Agent 进行通信和协作。Agent 会发布自己的“名片”（Agent Card）以供其他 Agent 发现，并通过 HTTP/JSON-RPC 发送任务和流式传输结果。
MCP vs A2A：分工明确
MCP (Model Context Protocol) A2A (Agent-to-Agent)
───────────────────────────── ────────────────────
解决：LLM 如何访问工具和数据 解决：Agent 之间如何协作
┌──────────┐ ┌──────────┐
│ LLM │ │ Agent A │────┐
└─────┬────┘ │ (搜索) │ │
│ MCP └────┬─────┘ │ A2A
▼ │ │ (对话协议)
┌──────────────┐ ▼ │
│ 工具/数据源 │ ┌──────────┐ │
│ (Server) │ │ Agent B │<───┘
└──────────────┘ │ (分析) │
└──────────┘
两者不冲突！MCP 让 Agent 有工具可用，
A2A 让 Agent 之间能合作。核心区别总结：
| 维度 | MCP | A2A |
|---|---|---|
| 制定者 | Anthropic (2024.11) | Google (2025.04) |
| 解决的问题 | 模型 ↔ 工具/数据的连接 | Agent ↔ Agent 的协作 |
| 类比 | USB-C（设备接口） | HTTP（服务间通信） |
| 参与方 | LLM + 工具 | 多个 Agent |
| 协议内容 | Resources, Tools, Prompts, Sampling | Agent Card, Task, Message, Artifact |
| 核心操作 | 读取资源、调用工具 | 任务委托、状态查询、结果交换 |
| 传输 | stdio / HTTP+SSE | HTTP + JSON-RPC |
2.2 A2A 核心概念
2.2.1 Agent Card（Agent 名片）
每个 A2A Agent 都有一个公开的"名片"，描述自己能做什么：
json
// Agent Card 示例
{
"name": "Research Agent",
"description": "进行深度网络搜索和学术文献检索的Agent",
"url": "https://agents.company.com/research",
"version": "1.0.0",
"capabilities": {
"streaming": true, // 支持流式返回
"pushNotifications": true, // 支持主动推送通知
"stateTransitionHistory": true // 保留任务状态历史
},
"skills": [
{
"id": "web_search",
"name": "网络搜索",
"description": "搜索互联网上的公开信息，支持中英文",
"examples": ["搜索2025年AI趋势", "查找最新的量子计算论文"],
"inputModes": ["text"],
"outputModes": ["text", "json"]
},
{
"id": "academic_search",
"name": "学术搜索",
"description": "搜索学术数据库（arXiv, PubMed, IEEE等）",
"examples": ["找关于Transformer架构的论文"],
"inputModes": ["text"],
"outputModes": ["text", "json"]
}
],
"defaultInputModes": ["text"],
"defaultOutputModes": ["text"],
"authentication": {
"schemes": ["bearer_token"]
}
}Agent Card 的作用：
- 让其他 Agent 发现和了解这个 Agent 的能力
- 自动生成工具描述（将 Card 信息转化为 Function Calling 的 tool definition）
- 服务发现：构建 Agent 目录/市场的基础
2.2.2 Task（任务）—— A2A 的核心交互单元
A2A 中，Agent 之间的交互以"任务（Task）"为单位，Task 的生命周期如下：
状态转换图:
┌─────────┐
│ pending │ ← 任务已创建，等待处理
└────┬────┘
│
▼
┌──────────┐
│ working │ ← Agent 正在处理任务
└────┬─────┘
│
┌────┴────┐
▼ ▼
┌─────────┐ ┌──────────┐
│completed│ │ failed │ ← 最终状态
└─────────┘ └──────────┘
│ │
└────┬────┘
▼
┌──────────┐
│ cancelled│ ← 用户或发起 Agent 取消
└──────────┘一个完整的 Task 委托流程：
Agent A (编排者) 向 Agent B (研究员) 委托任务
Step 1 — 创建任务 (POST /tasks)
Request:
{
"id": "task-001",
"sessionId": "session-abc",
"message": {
"role": "user",
"parts": [{
"type": "text",
"text": "请调研2025年AI Agent领域最重要的3个技术突破"
}]
}
}
Response:
{
"id": "task-001",
"status": "working",
"sessionId": "session-abc"
}
Step 2 — Agent A 轮询状态 (GET /tasks/task-001)
{
"id": "task-001",
"status": "working",
"sessionId": "session-abc"
}
Step 3 — 任务完成，Agent B 推送结果 (如果支持 pushNotifications)
{
"id": "task-001",
"status": "completed",
"artifacts": [
{
"name": "research_summary",
"parts": [{
"type": "text",
"text": "2025年AI Agent三大突破：\n1. ..."
}]
}
],
"history": [
// 任务执行的历史记录（类似 ReAct trace）
]
}2.3 A2A 与 MCP 的分工协作
MCP + A2A 协同工作全景
┌──────────────────────┐
│ 用户 / Host │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ 编排 Agent │
│ (Orchestrator) │
│ │
│ 通过 MCP 访问: │
│ • 知识库 (Resources) │
│ • 搜索工具 (Tools) │
│ • 通知模板 (Prompts) │
└──┬───────┬───────┬───┘
│ │ │
A2A │ A2A │ A2A │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 搜索Agent │ │ 分析Agent │ │ 写作Agent │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
MCP │ MCP │ MCP │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Web搜索 │ │ 数据库 │ │ 文件系统 │
│ 学术搜索 │ │ 计算工具 │ │ 导出工具 │
└──────────┘ └──────────┘ └──────────┘
总结：
• MCP：垂直连接 — Agent 与其直接依赖的工具/数据之间
• A2A：水平连接 — Agent 与 Agent 之间的任务协作2.4 A2A 的设计特点与现状
核心设计理念是实现智能体之间的点对点通信。 A2A 关注的是智能体之间如何相互协作。这种设计让智能体能够像人类团队一样进行对话、协商和协作。
A2A 的设计哲学是"对等通信"，在 A2A 网络中，每个智能体既是服务提供者，也是服务消费者。智能体可以主动发起请求，也可以响应其他智能体的请求。这种对等的设计避免了中心化协调器的瓶颈，让智能体网络更加灵活和可扩展。
设计哲学：
- Agent 即服务：每个 Agent 像微服务一样对待
- 异步优先：任务可能耗时，支持长轮询和推送通知
- 多模态：输入和输出都支持 text、image、audio 等多种模态
- 安全：认证、授权、速率限制内置
与 MCP 的互补关系：
| 场景 | 用什么协议 |
|---|---|
| Agent 需要读取本地文件 | MCP (Resources) |
| Agent 需要调用外部 API | MCP (Tools) |
| Agent A 把任务派给 Agent B | A2A (Task) |
| Agent A 查询 Agent B 的任务进度 | A2A (Task Status) |
| Agent 需要 LLM 推理能力 | MCP (Sampling) |
| Agent 之间交换分析结果 | A2A (Artifacts) |
3. 总结
| 特性 | MCP | A2A |
|---|---|---|
| 制定方 | Anthropic (2024.11) | Google (2025.04) |
| 核心比喻 | AI 的 USB-C | Agent 的 HTTP |
| 解决的问题 | LLM ↔ 工具/数据 | Agent ↔ Agent |
| 层级 | 工具调用层 | 服务协作层 |
| 核心概念 | Resources, Tools, Prompts, Sampling | Agent Card, Task, Artifact |
| 传输协议 | stdio / HTTP+SSE | HTTP + JSON-RPC |
| 开放性 | 完全开放 | 开放标准 |
关键要点：
- MCP 解决的是"让 LLM 连接万物"——统一工具和数据访问的接口标准。
- A2A 解决的是"让 Agent 互相协作"——Agent 之间任务委托和状态追踪的标准。
- 两者不是竞争关系，而是互补关系——就像 USB-C（连设备）和 HTTP（服务间通信）。
- MCP 的四大原语（Resources/Tools/Prompts/Sampling）覆盖了从读取到执行的全场景。
- A2A 的 Agent Card 让 Agent 能力可发现，Task 让协作可追踪。