Mcp & A2a

基本信息

mcp 发布时间：2025.11.25 链接：https://github.com/modelcontextprotocol/modelcontextprotocol

A2A 发布时间：2025.4.9 链接：https://a2a-protocol.org/latest/

二者要要解决的问题：

1. 模型与外部世界的割裂：大模型是基于概率计算的新范式，其思维、推理能力类似于人脑。这种新范式虽强大，但仍需要与传统的结构化计算范式相结合，也就是通过工具调用来完成精确任务。
2. Agent 协作的孤岛效应：AI Agent 的兴起让“做事”的智能体成为可能，但不同框架（如 LangGraph、AutoGen、CrewAI）各自为政，缺乏统一的通信标准，跨平台协作如同“鸡同鸭讲”。
3. 复杂场景的工程化瓶颈：RAG（检索增强生成）与多 Agent 系统需要处理多源数据、多模态交互和长时任务，现有工具链难以提供统一的解决方案。

    Agent A  ───── A2A协议 ─────  Agent B
    企业Agent                    第三方Agent

       │                            │
       MCP                          MCP
       │                            │
    API &资源                   API &资源

MCP

MCP 就是一个为大模型更方便的利用外部资源（主要是工具）而设计的标准化接口，旨在打破模型与外部数据、工具之间的壁垒。

RD before MCP

传统上，将 AI 系统连接到外部工具需要集成多个 API。每个 API 集成都意味着单独的代码、文档、身份验证方法、错误处理和维护。

在引入 MCP 之前，如果我要让一个 Agent 同时具备“网络搜索”“数据库查询”“文本翻译”三种能力，通常要写三套适配器：

• 搜索工具：手动拼 HTTP 请求，处理 OAuth 鉴权，解析 HTML 或 JSON，捕获请求超时。
• 数据库查询：配置 JDBC/ODBC 连接，管理连接池，拼装 SQL，逐行读取 ResultSet。
• 翻译服务：对接 Google Translate 或腾讯翻译 API，关注签名算法、流量限速、错误码处理。

RD after MCP

MCP 则把这些繁琐细节都“藏”到服务器端：

1. 服务端只需注册好 Search、QueryDB、Translate 三个工具能力；

2. 然后 Agent 发起同一套 JSON-RPC 调用：

{
  "method": "callTool",
  "params": {
    "tool": "Translate",
    "input": "Hello, world!",
    "target\_lang": "zh"
  }
}

3. MCP 服务器负责底层的 HTTP 请求、鉴权、连接管理和结果解析，最后把翻译结果一并返回给模型。

这样，开发者只需关心“模型想用哪个工具做什么”，再也不用为每个服务写一大堆样板代码，Agent 的功能扩展也瞬间变得“即插即用”。

因此，它是一个客户端 - 服务器的架构。 模型负责推理和决策，客户端则动态提供上下文、工具和资源，而这些工具和资源则由外部服务器来提供。

模型
│
└─ 推理与决策
│
▼
客户端
│
├─ 上下文
│
├─ 工具  ◄──── 外部服务器提供
│
└─ 资源  ◄──── 外部服务器提供

Function Calling 缺点

传统的 OpenAI Function Calling、LangChain 框架中的 Tools 或 JSON-RPC 相比，MCP 到底有何不同？

尽管 OpenAI Function Calling、LangChain 的 Tools 让大模型能够实现工具调用，但它们都没能真正砍掉 Agent 或大模型应用开发的“高墙”。

1. OpenAI Function Calling 只绑在 GPT 系列上，其调用规范、参数定义和返回格式都深度耦合在 OpenAI 的 API 流程中，无法扩展到其他开源或私有模型。

2. LangChain Tools 虽然支持多种模型和工具，但所有能力都要写在 LangChain 的框架里——跨框架、跨语言、跨团队复用时，得重造一套适配逻辑。

3. JSON-RPC 作为通用远程调用协议，轻量却太过底层：它只管“发什么请求、收什么响应”，但显然不包含大模型的上下文管理、并发会话、流式返回、能力发现等核心需求。

它们解决了“怎么调”或“调哪个好”这一维度的问题，却没形成一套“面向大模型 + Agent 协作”的统一、可插拔、开箱即用的接口规范。

MCP 改进

MCP 则在 JSON-RPC 之上，专门为大模型量身定制了：

• 统一工具描述：所有 Search、Translate、QueryDB 等能力用同一份 tool.json 注册，模型只按名字“call”就行。

• 会话与权限：自动管理多轮对话状态、工具访问权限与鉴权流程，模型无需关心鉴权细节。

• 流式与事件：内建流式数据返回、异步回调和事件订阅，让长任务、实时监控、异步通知都能自然融入推理流程。

• 多传输层：既可跑 HTTP/REST，也可挂 WebSocket、RPC 框架或消息队列，灵活适配不同部署场景。

MCP 真正把“模型想用什么工具干啥”这件事变得极其简单——大模型专注决策，开发者专注业务逻辑，Agent 开发门槛被一举摁平。

这样，MCP 的统一接口让开发者无需为每个场景定制协议，显著降低了工程化成本。

A2A

它定义了一套清晰、标准的沟通方式，让所有智能代理可以顺畅地交流彼此的需求、能力、决策和状态。Agent 们通过 A2A 沟通，就像大家都学会了同一种语言，不管来自哪个“国家”，都能顺畅无阻地交流、互相配合完成任务。

示例

用户向旅行规划 Agent 发送“规划北京到上海 3 天行程”的请求，旅行 Agent 通过 A2A 协议依次发出两次标准化能力调用：

1. 调用查询天气agent
2. 调用查询酒店agent
3. 旅游规划agent归纳

              用户
               │
               ▼
        旅游规划 Agent
               │
      ┌────────┴────────┐
      ▼                 ▼
 天气查询 Agent     酒店预订 Agent
      │                 │
 天气信息返回       酒店数据返回
      └────────┬────────┘
               ▼
          旅行规划结果

A2A 能力

A2A 协议在这个过程中所负责的要点在于：

• 统一协议：所有 Agent 均使用同一消息 schema 进行能力发现与调用。
• 异步协作：支持流式与异步返回，可并发处理多任务。
• 灵活扩展：新 Agent 即插即用，无需额外适配器。
• 解耦实现：Agent 专注业务，底层传输、鉴权、错误处理由协议层统一管理。

A2A 在 JSON-RPC、HTTP/SSE 等底层传输之上，定义了能力发现（通过 Agent 卡片以及标准化的能力定义）、会话管理、任务生命周期管理、消息与内容单元（Part）、权限认证、流式与事件等语义，使多智能体系统能够灵活拼接、异步协作，并具备企业级安全与可扩展性。

A2A 支持长时任务、多模态协作，并强调企业级安全性，如 OpenAPI 授权和角色访问控制。 与 MCP 的资源管理结合，A2A 使 Agent 能够动态协商任务分配，实时共享数据洞察。例如，一个基于 CrewAI 的客服 Agent 可以通过 A2A 与 LlamaIndex 驱动的知识检索 Agent 协作，共同完成客户问题的精准解答。

MCP vs A2A

MCP 提供了统一的上下文管理与工具调用接口，整合了大模型驱动的概率计算与传统工具驱动的结构化计算。A2A 则为多 Agent 协同注入了开放标准。

表格一：MCP 与 A2A 相同点

表格二：MCP 与 A2A 不同点