MCP 与 A2A：两个 AI Agent 协议的关系和区别是什么？

作为一个在前端领域摸爬滚打了十年的老兵，最近一年我几乎把所有业余时间都投入到了 AI Agent 的学习中。当我第一次听到 MCP 和 A2A 这两个协议时，我的第一反应是：“又来两个新协议？它们到底是干什么的？是竞争关系还是互补关系？”

这篇文章就是我深入研究这两个协议后的学习笔记。我会用前端开发者熟悉的视角，来解析这两个协议的本质、设计哲学、以及它们在 AI Agent 生态系统中的定位。

为什么我们需要了解这两个协议？

2025年被很多人称为"AI Agent 元年"。如果说 2023-2024 年是大模型能力爆发的时代，那么 2025 年就是 Agent 落地应用的时代。

作为前端开发者，我们已经习惯了各种协议和标准：HTTP、WebSocket、GraphQL、REST API… 这些协议定义了前端与后端、服务与服务之间的通信规范。

现在，AI Agent 领域也面临着同样的问题：

  • Agent 如何连接外部工具和服务？
  • 多个 Agent 之间如何协作？
  • 不同厂商的 Agent 如何互通？

MCP (Model Context Protocol) 和 A2A (Agent-to-Agent Protocol) 就是为了解决这些问题而诞生的两个重要协议。

一句话理解两者的区别

在深入细节之前，让我先用一个简单的类比来说明两者的区别：

MCP 就像 USB-C 接口：它定义了 AI Agent 如何"插入"和使用外部工具、数据源和服务。

A2A 就像 HTTP 协议：它定义了多个 AI Agent 之间如何发现彼此、建立连接、分配任务和协作完成工作。

用前端的话来说：

  • MCP 解决的是"Agent 如何调用 API"的问题（类似 Axios 或 Fetch）
  • A2A 解决的是"多个微服务如何协作"的问题（类似微服务架构中的服务发现和通信）

MCP：让 Agent 连接万物的"USB-C"

背景与起源

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年 11 月推出的开放标准。它的目标很明确：标准化 AI 系统与外部工具、数据源的集成方式。

在 MCP 出现之前，每个 AI 应用想要集成外部工具，都需要写一套定制的集成代码。这就像早期每个手机厂商都有自己的充电接口一样混乱。MCP 的出现，就是要成为 AI 领域的"USB-C"。

核心概念

MCP 的架构非常简洁，主要包含三个核心角色：

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   MCP Client    │────▶│   MCP Server    │────▶│  External Tool  │
│  (AI 应用/Agent) │     │  (中间适配层)    │     │  (数据库/API等)  │
└─────────────────┘     └─────────────────┘     └─────────────────┘

MCP Client：发起请求的一方，通常是 AI 应用或 Agent。比如 Claude Desktop、Cursor、各种 AI IDE 插件等。

MCP Server：提供工具和资源的一方。它将外部系统的能力封装成标准化的接口暴露给 Client。

三大核心能力：

  • Tools（工具）：可执行的操作，如"发送邮件"、“查询数据库”、“创建文件”
  • Resources（资源）：可读取的数据源，如文件内容、数据库记录
  • Prompts（提示模板）：预定义的 prompt 模板，帮助 AI 更好地使用工具

实际代码示例

作为前端开发者，让我用代码来说明 MCP 的工作方式。假设我们要创建一个天气查询的 MCP Server：

// weather-mcp-server.ts
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server(
  {
    name: "weather-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
    },
  },
);

// 定义一个工具：获取天气
server.setRequestHandler("tools/list", async () => ({
  tools: [
    {
      name: "get_weather",
      description: "获取指定城市的天气信息",
      inputSchema: {
        type: "object",
        properties: {
          city: {
            type: "string",
            description: "城市名称，如：北京、上海",
          },
        },
        required: ["city"],
      },
    },
  ],
}));

// 处理工具调用
server.setRequestHandler("tools/call", async (request) => {
  if (request.params.name === "get_weather") {
    const city = request.params.arguments.city;
    // 这里调用实际的天气 API
    const weather = await fetchWeatherAPI(city);
    return {
      content: [
        {
          type: "text",
          text: `${city}的天气：${weather.condition}，温度：${weather.temperature}°C`,
        },
      ],
    };
  }
});

// 启动服务
const transport = new StdioServerTransport();
await server.connect(transport);

这段代码对前端开发者来说应该很熟悉：

  • 定义接口规范（inputSchema 类似 TypeScript 的 interface）
  • 注册请求处理器（类似 Express 的路由）
  • 返回标准化的响应格式

MCP 的生态发展

MCP 的发展速度令人惊叹。根据我收集的数据：

时间节点 里程碑
2024年11月 Anthropic 发布 MCP，提供 Python 和 TypeScript SDK
2025年3月 OpenAI 宣布支持 MCP
2025年4月 Google DeepMind 确认 Gemini 将支持 MCP
2025年5月 Microsoft 和 GitHub 加入 MCP 指导委员会
2025年11月 规范重大更新：异步操作、无状态设计、官方注册表
2025年12月 Anthropic 将 MCP 捐赠给 Linux Foundation 下的 AAIF 基金会

到 2025 年底，MCP 生态已经有超过 5800+ MCP Server 和 300+ MCP Client，SDK 月下载量超过 9700 万次。

A2A：让 Agent 相互对话的"HTTP"

背景与起源

A2A（Agent-to-Agent Protocol，代理到代理协议）是 Google 在 2025 年 4 月的 Cloud Next 大会上发布的开放协议。

如果说 MCP 解决的是"Agent 如何使用工具"的问题，A2A 解决的则是一个更高层次的问题：不同的 AI Agent 之间如何发现、认证、协作？

想象一个场景：你有一个"客服 Agent"、一个"订单处理 Agent"、一个"物流查询 Agent"。当用户问"我的订单到哪了"时，客服 Agent 需要：

  1. 发现有哪些 Agent 可以帮忙
  2. 找到合适的 Agent（订单处理 → 物流查询）
  3. 把任务分配给对应的 Agent
  4. 收集结果并整合返回给用户

这就是 A2A 要解决的问题。

核心概念

A2A 采用客户端-服务器模型，通信流程分为三个阶段：

┌─────────────────────────────────────────────────────────────────┐
│                        A2A 通信流程                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. Discovery (发现)                                            │
│     ┌──────────┐    GET /.well-known/agent.json    ┌──────────┐│
│     │ Client   │ ─────────────────────────────────▶│  Server  ││
│     │ Agent    │ ◀───────────────────────────────── │  Agent   ││
│     └──────────┘         返回 Agent Card            └──────────┘│
│                                                                 │
│  2. Authentication (认证)                                       │
│     根据 Agent Card 中的认证要求进行身份验证                       │
│     支持：API Key、OAuth 2.0、OpenID Connect                     │
│                                                                 │
│  3. Communication (通信)                                        │
│     使用 JSON-RPC 2.0 格式通过 HTTPS 进行通信                     │
│     支持：Webhooks 回调、SSE 实时流                               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Agent Card：Agent 的"身份证"

A2A 中最核心的概念是 Agent Card。它是一个 JSON 文件，托管在 /.well-known/agent.json 路径下，描述了 Agent 的身份、能力和如何与其交互。

{
  "name": "OrderProcessingAgent",
  "description": "处理电商订单的 AI Agent，可以查询订单状态、修改订单、处理退款",
  "url": "https://orders.example.com/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "query_order",
      "name": "查询订单",
      "description": "根据订单号查询订单详情和状态",
      "inputSchema": {
        "type": "object",
        "properties": {
          "orderId": { "type": "string" }
        },
        "required": ["orderId"]
      }
    },
    {
      "id": "cancel_order",
      "name": "取消订单",
      "description": "取消指定的订单",
      "inputSchema": {
        "type": "object",
        "properties": {
          "orderId": { "type": "string" },
          "reason": { "type": "string" }
        },
        "required": ["orderId"]
      }
    }
  ],
  "authentication": {
    "schemes": ["oauth2"],
    "oauth2": {
      "authorizationUrl": "https://auth.example.com/oauth/authorize",
      "tokenUrl": "https://auth.example.com/oauth/token",
      "scopes": ["orders:read", "orders:write"]
    }
  }
}

这个设计让我想到了前端微服务架构中的服务注册与发现。Agent Card 就像是每个微服务在 Consul 或 Eureka 中注册的元数据。

Task：A2A 中的工作单元

在 A2A 协议中，Agent 之间的协作是以 Task（任务） 为单位的。每个 Task 有明确的生命周期：

interface Task {
  id: string; // 任务唯一标识
  status: TaskStatus; // 任务状态
  messages: Message[]; // 对话历史
  artifacts: Artifact[]; // 产出物
}

type TaskStatus =
  | "submitted" // 已提交
  | "working" // 处理中
  | "input-required" // 需要更多输入
  | "completed" // 已完成
  | "failed" // 失败
  | "canceled"; // 已取消

这种设计支持长时间运行的任务。比如一个"深度研究"任务可能需要几小时甚至几天，中间可能需要人工介入确认。A2A 协议原生支持这种场景。

A2A 的发展现状

A2A 在发布时获得了 超过 50 家技术合作伙伴 的支持，包括 Atlassian、Salesforce、SAP、ServiceNow 等企业软件巨头。

时间节点 里程碑
2025年4月 Google 在 Cloud Next 发布 A2A
2025年6月 Linux Foundation 宣布托管 A2A 项目
2025年7月 A2A 0.3 版本发布，新增 gRPC 支持
2025年9月 生态扩展至 150+ 组织支持

不过，根据我的观察，A2A 的实际采用速度不如 MCP。这可能是因为 MCP 先发优势明显，而且解决的问题更加普遍。

MCP vs A2A：核心区别深度对比

现在让我们来做一个系统性的对比：

1. 解决的问题域不同

维度 MCP A2A
核心问题 Agent 如何使用外部工具和数据 多个 Agent 如何协作
通信方向 Agent → 工具/服务 Agent ↔ Agent
类比 人使用工具（锤子、电脑） 人与人协作（团队合作）

2. 架构设计不同

MCP 的架构更像是传统的 RPC 或 REST API：

Client (Agent) ──请求──▶ Server (工具提供方)
              ◀──响应──

A2A 的架构更像是对等网络或微服务架构：

Agent A ──发现──▶ Agent B
       ◀──Agent Card──
Agent A ──创建任务──▶ Agent B
       ◀──任务状态更新──
       ◀──最终结果──

3. 适用场景不同

MCP 更适合的场景：

  • 让 Agent 访问数据库、文件系统
  • 让 Agent 调用外部 API（天气、股票、搜索等）
  • 让 Agent 操作本地工具（IDE、浏览器等）
  • 统一多种工具的接入标准

A2A 更适合的场景：

  • 构建多 Agent 协作系统
  • 跨组织、跨平台的 Agent 互操作
  • 复杂任务的分解和分配
  • 需要长时间运行的任务管理

4. 技术栈对比

特性 MCP A2A
传输协议 stdio、HTTP/SSE HTTP/SSE、WebSocket、gRPC
消息格式 JSON-RPC 2.0 JSON-RPC 2.0
认证方式 自定义 OAuth 2.0、API Key、OpenID Connect
服务发现 配置文件/手动 Agent Card (/.well-known/agent.json)
状态管理 无状态 有状态（Task 生命周期）
异步支持 SSE Webhook、SSE

5. 代码示例对比

让我用一个实际的例子来说明两者的使用方式差异。

场景：开发一个能够查询天气并发送通知的系统。

使用 MCP 的方式（单个 Agent 使用多个工具）：

// Agent 通过 MCP 调用天气工具
const weatherResult = await mcpClient.callTool("weather-server", {
  name: "get_weather",
  arguments: { city: "北京" },
});

// Agent 通过 MCP 调用通知工具
await mcpClient.callTool("notification-server", {
  name: "send_notification",
  arguments: {
    message: `北京天气：${weatherResult.temperature}°C`,
    channel: "wechat",
  },
});

使用 A2A 的方式（多个专业 Agent 协作）：

// 1. 发现天气 Agent
const weatherAgent = await a2aClient.discover(
  "https://weather-agent.example.com",
);

// 2. 创建天气查询任务
const weatherTask = await a2aClient.createTask(weatherAgent, {
  messages: [
    {
      role: "user",
      parts: [{ type: "text", text: "查询北京的天气" }],
    },
  ],
});

// 3. 等待任务完成
const weatherResult = await a2aClient.waitForCompletion(weatherTask.id);

// 4. 发现通知 Agent
const notifyAgent = await a2aClient.discover(
  "https://notify-agent.example.com",
);

// 5. 创建通知任务
const notifyTask = await a2aClient.createTask(notifyAgent, {
  messages: [
    {
      role: "user",
      parts: [
        {
          type: "text",
          text: `发送天气通知：${weatherResult.artifacts[0].content}`,
        },
      ],
    },
  ],
});

可以看到，MCP 更直接、更轻量，适合简单的工具调用。A2A 则更复杂，但提供了完整的任务管理和状态追踪能力。

它们是竞争还是互补？

这是我研究这两个协议时最想弄清楚的问题。答案是：它们是互补关系，解决的是不同层次的问题。

层次模型

┌─────────────────────────────────────────────────┐
│                  应用层                          │
│    (用户界面、业务逻辑、Agent 编排)               │
├─────────────────────────────────────────────────┤
│               A2A 协议层                         │
│    (Agent 发现、认证、任务分配、协作)             │
├─────────────────────────────────────────────────┤
│               MCP 协议层                         │
│    (工具调用、资源访问、上下文提供)               │
├─────────────────────────────────────────────────┤
│               基础设施层                         │
│    (网络、存储、计算资源)                        │
└─────────────────────────────────────────────────┘

用一个更生动的比喻：

  • MCP 就像每个员工手中的工具（电脑、电话、打印机）
  • A2A 就像公司的组织架构和协作流程（谁负责什么、怎么交接工作）

一个完整的多 Agent 系统可能同时使用两个协议：

  • 每个 Agent 通过 MCP 连接其需要的工具和数据源
  • Agent 之间通过 A2A 进行发现、通信和协作

实际架构示例

                    ┌──────────────────────────────────┐
                    │         用户请求                  │
                    │    "帮我订一张明天去上海的机票"     │
                    └─────────────┬────────────────────┘
                                  │
                                  ▼
                    ┌──────────────────────────────────┐
                    │        协调者 Agent               │
                    │   (理解意图、分解任务、整合结果)    │
                    └─────────────┬────────────────────┘
                                  │ A2A
                    ┌─────────────┼─────────────┐
                    │             │             │
                    ▼             ▼             ▼
         ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
         │ 航班查询Agent │ │ 支付处理Agent │ │ 行程管理Agent │
         └──────┬───────┘ └──────┬───────┘ └──────┬───────┘
                │ MCP            │ MCP            │ MCP
         ┌──────┴───────┐ ┌──────┴───────┐ ┌──────┴───────┐
         │ 航班API Server│ │ 支付API Server│ │ 日历API Server│
         │ 价格比较Server│ │ 风控Server    │ │ 通知Server   │
         └──────────────┘ └──────────────┘ └──────────────┘

我的实战经验与踩坑分享

踩坑1：MCP Server 的调试困境

刚开始写 MCP Server 时，我遇到最大的问题是调试困难。因为 MCP 使用 stdio 通信，很难用常规的 HTTP 调试工具。

解决方案：

  1. 使用 MCP Inspector 工具进行可视化调试
  2. 在 Server 中添加详细的日志输出到文件
  3. 先用 HTTP 模式开发测试，再切换到 stdio
// 开发时使用 HTTP 模式，便于调试
const transport =
  process.env.NODE_ENV === "development"
    ? new HttpServerTransport({ port: 3000 })
    : new StdioServerTransport();

踩坑2：A2A 的服务发现在内网不太好用

A2A 的 Agent Card 设计假设了 Agent 可以通过公网 URL 访问。但在企业内网环境，这个假设不一定成立。

我的解决方案：搭建了一个内部的 Agent 注册中心，Agent Card 统一托管在这里，通过内部 DNS 进行服务发现。

踩坑3：两个协议的版本兼容问题

2025 年这两个协议都在快速迭代。我曾经遇到过 SDK 版本升级导致 API 不兼容的问题。

建议：

  • 锁定 SDK 版本
  • 关注官方 changelog
  • 生产环境升级前充分测试

踩坑4：在英博云上部署 MCP Server 的网络配置

我在英博云平台上部署 MCP Server 时遇到了一个有趣的问题。MCP 的 stdio 模式适合本地运行，但在云环境中我需要 HTTP 模式。

问题：英博云的容器默认只开放特定端口，而我的 MCP Server 启动时没有正确绑定到 0.0.0.0，导致外部无法访问。

解决方案：

// 云环境部署时，需要绑定到 0.0.0.0
const transport = new HttpServerTransport({
  host: "0.0.0.0", // 关键：不要用 localhost
  port: parseInt(process.env.PORT || "3000"),
});

另外，英博云提供了 GPU 实例，如果你的 Agent 需要本地运行模型推理，记得选择带 GPU 的实例类型。我在测试一个需要本地 embedding 的 MCP Server 时，一开始用 CPU 实例，结果响应时间长达数秒，换成 GPU 实例后降到了几十毫秒。

未来展望：2026 年及以后

根据目前的发展趋势，我对这两个协议的未来有以下判断：

MCP 的方向

  • 将成为 AI Agent 领域的事实标准（类似 HTTP 之于 Web）
  • 生态会继续爆发，预计 2026 年底会有上万个 MCP Server
  • 安全性会是重点关注方向（prompt injection 等问题）

A2A 的方向

  • 在企业级多 Agent 场景会逐渐获得采用
  • 可能会与 MCP 有更深度的集成
  • 复杂 Agent 编排场景会是主要应用方向

可能的融合

我个人的预测是，未来可能会出现一个更高层次的标准，将 MCP 和 A2A 的能力统一起来。毕竟，用户不关心底层用的是什么协议，他们只关心 Agent 能不能完成任务。

给前端开发者的建议

如果你也是从前端转型学习 AI Agent 的开发者，这是我的建议：

  1. 先学 MCP：它更简单、更实用，能快速上手
  2. 理解协议设计思想：这和我们熟悉的 REST API、GraphQL 有很多相通之处
  3. 动手实践：写几个 MCP Server，比看十篇文章更有效
  4. 关注生态：加入 MCP 和 A2A 的社区，了解最新动态
  5. 安全意识：Agent 有执行能力，安全问题比传统 API 更严重

总结

对比维度 MCP A2A
发布方 Anthropic (2024.11) Google (2025.04)
核心目标 Agent 连接工具/数据 Agent 之间协作
类比 USB-C 接口 HTTP 协议
复杂度 较低 较高
成熟度 高（已成为事实标准） 中（仍在发展）
适用场景 工具集成、数据访问 多 Agent 系统、企业协作
关系 两者互补，可同时使用 两者互补，可同时使用

MCP 和 A2A 不是二选一的关系，而是解决不同问题的互补方案。

一个成熟的 AI Agent 系统很可能同时使用这两个协议：用 MCP 让每个 Agent 获得使用工具的能力，用 A2A 让多个 Agent 能够协调工作。

这就像我们做前端开发时，同时需要 HTTP（通信协议）和 REST/GraphQL（API 规范）一样——它们在不同的层次解决不同的问题，共同构成完整的技术栈。

参考资源

# 人工智能 # 状态模式
Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

AI 龙虾 | 对学习工作的影响和未来前瞻

AI 龙虾（OpenClaw）是能自主操控设备、完成全流程任务的 AI 智能体，核心是 “动口即执行”，正从工具升级为数字生产力单元，深刻重塑学习与工作模式。

avatar 龙虾开发者社区
cover

OpenClaw部署和使用心得

avatar 龙虾开发者社区
cover

动手写个agent（四）：实现接入MCP 协议

avatar 龙虾开发者社区