A2A vs MCP：区别、适用场景与如何配合使用

MCP（Model Context Protocol，模型上下文协议） 把一个 AI 应用连接到工具、数据和提示词：模型调用 search_issues 这样的函数，拿回结构化结果。A2A（Agent2Agent） 把一个 Agent 连接到另一个独立的 Agent：你把一整件任务交给一个你看不到内部的对等方，由它回报进度和结果。两者并不竞争。绝大多数使用 A2A 的真实系统也在用 MCP——MCP 在每个 Agent 内部，A2A 在 Agent 之间。

A2A 项目自己的文档用一句话概括：MCP 是纵向的，A2A 是横向的。MCP 让单个 Agent 更能干；A2A 让这个 Agent 能够触达其他团队、其他厂商、其他公司的 Agent。如果你还不了解 MCP 本身，先读 什么是 MCP？ 再回来。

A2A vs MCP 速览

最关键的一行是"对方是什么"。MCP 服务器暴露的是带输入 Schema 的函数，模型清楚地知道自己在调用什么。A2A Agent 暴露的是用自然语言描述的 技能（skills），并把内部细节保密：它的提示词、工具、记忆，甚至用的是哪个模型。

MCP 做什么

MCP 规范了 AI 应用（宿主，例如 Claude Code、Cursor 或 ChatGPT）如何与提供上下文和操作的服务器通信。服务器暴露三类原语：模型可以调用的 tools（工具）、应用可以读取为上下文的 resources（资源）、用户可以触发的 prompts（提示词）。服务器端的介绍见 什么是 MCP 服务器？，逐条消息的生命周期见 MCP 是如何工作的？。

2026 年有两点值得知道：

• 当前规范 2026-07-28 修订版 让 MCP 变成了无状态协议。initialize 握手被移除，每个请求都在 _meta 中携带协议版本和客户端能力，服务器通过 server/discover 声明自身信息。
• Anthropic 于 2025 年 12 月 9 日 把 MCP 捐赠给了 Agentic AI Foundation，这是 Linux 基金会旗下的一个定向基金。

一次工具调用长这样（来自 官方架构指南）：

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "San Francisco", "units": "imperial" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

返回结果是一个 content 数组（可选 structuredContent），并带有 "resultType": "complete"。模型选择了工具，按 JSON Schema 填好参数，拿回数据。服务器端没有任何"Agent 式"的行为。

A2A 做什么

A2A 规范了一个 Agent 如何请另一个 Agent 干活。Google 于 2025 年 4 月在 Cloud Next 大会上 发布了它，首批有 50 多家合作伙伴；2025 年 6 月捐赠给 Linux 基金会；首个稳定版 1.0.0 于 2026 年 3 月 12 日发布。2025 年 8 月，IBM 的 Agent Communication Protocol（ACP）并入了 A2A，所以现在 Linux 基金会只有一个 Agent 间通信标准，而不是两个。在一周年时，Linux 基金会公布已有 超过 150 家支持组织。

A2A 规范 的核心对象有：

• Agent Card：一份 JSON 文档，描述 Agent 的名称、技能、支持的接口、能力（流式、推送通知）以及安全方案。公开的 Agent Card 放在 https://{domain}/.well-known/agent-card.json。1.0 版本还支持签名的 Agent Card。
• Task（任务）：工作单元，状态包括 TASK_STATE_SUBMITTED、TASK_STATE_WORKING、TASK_STATE_INPUT_REQUIRED、TASK_STATE_AUTH_REQUIRED、TASK_STATE_COMPLETED、TASK_STATE_FAILED、TASK_STATE_CANCELED 和 TASK_STATE_REJECTED。
• Message（消息） 和 Part（片段）：由文本、文件或数据片段组成的对话轮次。
• Artifact（产物）：远程 Agent 产出的结果，例如一份报告或一个文件。

操作包括 SendMessage、SendStreamingMessage、GetTask、ListTasks、CancelTask、SubscribeToTask、推送通知配置相关方法以及 GetExtendedAgentCard。客户端在每个请求上发送 A2A-Version 头（例如 1.0）。

下面是规范自带的 HTTP+JSON 绑定示例：客户端提出一个问题，拿回一个已完成的任务。

POST /message:send HTTP/1.1
Host: agent.example.com
Content-Type: application/a2a+json
Authorization: Bearer token

{
  "message": {
    "role": "ROLE_USER",
    "parts": [{"text": "What is the weather today?"}],
    "messageId": "msg-uuid"
  }
}

{
  "task": {
    "id": "task-uuid",
    "contextId": "context-uuid",
    "status": { "state": "TASK_STATE_COMPLETED" },
    "artifacts": [
      {
        "artifactId": "artifact-uuid",
        "name": "Weather Report",
        "parts": [{ "text": "Today will be sunny with a high of 75°F" }]
      }
    ]
  }
}

对比两段报文。MCP 发送的是函数名加类型化参数；A2A 发送的是一条 自然语言消息，拿回的是一个带 ID、上下文和产物的 任务。怎么得到答案由远程 Agent 自己决定。

什么时候用 MCP，什么时候用 A2A

以下情况用 MCP：

• 你希望助手或 Agent 读取或修改某样东西：代码仓库、数据库、工单系统、浏览器。常见例子有 GitHub MCP 服务器、Postgres MCP 和 Playwright MCP。
• 这个能力的输入输出清晰，自身不需要推理。
• 你希望它能在大家已经在用的客户端里工作。Claude、ChatGPT、Cursor、VS Code 和 Codex 都支持 MCP，见 客户端列表。

以下情况用 A2A：

• 你调用的对象本身就是一个 Agent，有自己的模型、工具和判断力，你想委派的是一个目标，而不是一次函数调用。
• 对方 Agent 属于另一个团队、厂商或公司，他们不会（也不应该）暴露内部实现。
• 工作耗时长或需要多轮：远程 Agent 可能需要更多输入（TASK_STATE_INPUT_REQUIRED）、额外认证，或需要数小时才能完成，进度通过流式返回或推送到 Webhook。

一个快速判断法： 如果你能把这个能力写成一个函数签名，它就是 MCP 工具；如果你会把它描述成"让财务团队的 Agent 处理一下"，那就是 A2A 调用。

A2A 和 MCP 如何配合

A2A 规范中 关于 MCP 的附录 描述了标准模式：A2A 客户端 Agent 请 A2A 服务端 Agent 完成一个复杂任务，服务端 Agent 再通过 MCP 访问完成任务所需的工具、API 和数据。

举一个具体例子，旅行预订流程：

1. 用户请一个旅行 Agent（用任意框架构建）规划行程。
2. 旅行 Agent 读取合作方运营的机票 Agent 和酒店 Agent 的 Agent Card，并通过 A2A 各发一个任务。
3. 在内部，机票 Agent 通过 MCP 服务器访问航司库存 API 和支付服务；酒店 Agent 也用自己的 MCP 服务器做同样的事。
4. 酒店 Agent 进入 TASK_STATE_INPUT_REQUIRED（"需要含早餐吗？"），旅行 Agent 在同一个 contextId 里作答。
5. 两个任务都带着产物（行程单）完成，旅行 Agent 把它们合并后交给用户。

旅行 Agent 从未看到航司 API，机票 Agent 也从未看到用户的对话。MCP 给每个 Agent 深度，A2A 给整个系统广度。

反过来也可以：把一个远程 Agent 包装成 MCP 工具，让 IDE 这类只支持 MCP 的客户端也能调用它。这对快速的一次性请求可行，但你会失去 A2A 的任务生命周期、多轮输入和推送通知。所以真正的任务委派，还是直接用 A2A。

常见误解

• "A2A 会取代 MCP。" 不会。Google 发布 A2A 时就把它定位为 MCP 的补充，如今两者都是 Linux 基金会旗下的项目，范围几乎不重叠。
• "MCP 做不了 Agent 对 Agent。" MCP 服务器背后 可以 有一个 LLM，MCP 也有 elicitation（信息征询）和用于长任务的可选 Tasks 扩展。但 MCP 没有 Agent Card，没有对等方之间的任务生命周期，也没有"带技能的不透明 Agent"这个概念。它是为工具和上下文设计的。
• "一开始就得两个都上。" 大多数团队只需要 MCP。当你有多个分属不同方、必须协作的 Agent 时，A2A 才变得重要。
• "两者都是 JSON-RPC，所以是一回事。" 共用传输格式说明不了什么。MCP 围绕 Schema 和模型控制的调用构建；A2A 围绕对等方之间的任务、消息和产物构建。
• "ACP 是我必须支持的第三个标准。" IBM 的 ACP 已于 2025 年并入 A2A。另一个无关的 Agent Client Protocol（编辑器对接编码 Agent）也缩写为 ACP，注意分清对方说的是哪个。

下一步

如果你要构建的是一个能干的 Agent，从 MCP 开始：在 MCP.so 服务器目录 里挑选现成的集成，在 MCP vs RAG 中对比 MCP 与检索增强，再读 MCP 是如何工作的？ 了解底层协议。当你的 Agent 需要把整件任务交给别人运营的 Agent 时，再加上 A2A。