从 MCP 到 A2A：Agent 项目里“通信协议”到底在解决什么问题？

最近学习 Agent 的时候，我发现一个问题：

以前我以为 Agent 的重点就是：
大模型 + Prompt + Tool + RAG。

但继续往下看会发现，真正做 Agent 项目时，还有一个非常关键的问题：
Agent 到底怎么和外部世界通信？

比如：

Agent 怎么调用工具？
Agent 怎么访问本地文件？
Agent 怎么连接第三方 API？
Agent 和另一个 Agent 怎么协作？
MCP、A2A、SSE、Streamable HTTP 又分别是什么？
大模型网关在这里到底有没有必要？

这些问题看起来分散，但其实都围绕一个核心：

Agent 不是一个孤立的大模型，而是一个需要连接工具、系统、数据和其他 Agent 的执行体。

所以今天这篇文章，我想从通信协议的角度，重新梳理一下 Agent 项目的底层逻辑。

---

一、先说结论：Agent 项目不只是“调大模型接口”

很多刚开始学习 Agent 的同学，容易把 Agent 理解成：

用户输入问题
   ↓
调用大模型
   ↓
大模型返回答案

但这其实更像普通 ChatBot，不是真正意义上的 Agent。

Agent 更完整的流程应该是：

用户输入目标
   ↓
Agent 理解任务
   ↓
判断是否需要工具
   ↓
调用外部工具 / API / 数据源
   ↓
根据工具结果继续推理
   ↓
必要时多轮调用工具
   ↓
最终给出答案或执行结果

也就是说，Agent 和普通 LLM 应用最大的区别在于：

普通 LLM 应用偏“问答”；
Agent 偏“理解目标 + 调用工具 + 执行任务”。

这里就会出现一个很现实的问题：

工具怎么接进来？工具调用怎么规范化？不同 Agent 之间怎么协作？

这就是 MCP 和 A2A 这类协议出现的背景。

---

二、Function Calling 解决的是“模型怎么表达我要调用工具”

在说 MCP 之前，先要理解 Function Calling。

Function Calling 可以理解为：

大模型不只是返回自然语言，还可以返回一个结构化的工具调用意图。

比如用户问：

帮我查一下北京今天的天气。

如果模型判断这个问题需要调用天气工具，它可能不会直接回答，而是返回类似这样的结构：

{
  "name": "getWeather",
  "arguments": {
    "city": "北京"
  }
}

这表示：

模型想调用 getWeather 这个工具，
并且参数是 city = 北京。

然后由框架来真正执行这个方法：

weatherTool.getWeather("北京");

执行完之后，再把工具返回结果交给大模型，让它组织成自然语言回答。

所以 Function Calling 解决的是：

大模型如何表达“我要调用哪个工具”
大模型如何生成工具调用参数
框架如何识别模型返回的 tool_call

但是它没有完全解决另一个问题：

这些工具从哪里来？
不同工具怎么统一暴露？
本地工具、远程工具、第三方服务工具怎么标准化接入？

这就引出了 MCP。

---

三、MCP 解决的是“Agent 怎么标准化连接工具和数据源”

MCP，全称是 Model Context Protocol。

它可以理解为：

给大模型应用连接外部工具、数据源和上下文的一套标准协议。

Anthropic 在介绍 MCP 时，把它定义为一种开放标准，用于在 AI 应用和数据源之间建立安全的双向连接；开发者可以构建 MCP Server 暴露数据，也可以构建 MCP Client 去连接这些 Server。

如果用更项目化的话说：

MCP Client：通常在 Agent 应用这一侧
MCP Server：负责暴露工具、资源、数据源
Tool：具体能被 Agent 调用的能力
Resource：可读取的上下文资源
Prompt：可复用的提示模板

可以画成这样：

用户
 ↓
Agent 应用 / MCP Client
 ↓
连接 MCP Server
 ↓
获取工具列表 / 资源列表
 ↓
大模型决定是否调用工具
 ↓
MCP Server 执行工具
 ↓
返回结果给 Agent
 ↓
Agent 继续推理并回答

所以 MCP 的意义不是“让大模型更聪明”，而是让 Agent 更容易连接外部世界。

---

四、MCP 和普通 API 调用有什么区别？

很多人会问：

MCP Server 最后不也是调用 API 吗？
那我直接在后端写 API 不就行了吗？

这个问题非常关键。

答案是：

底层确实还是 API、数据库、文件系统、脚本、服务调用。

但是 MCP 的价值在于：它把这些能力统一包装成 Agent 可以理解和调用的工具。

普通 API 更像这样：

后端开发者知道接口地址
后端开发者知道请求参数
后端开发者手动写调用逻辑

MCP 更像这样：

MCP Server 暴露工具定义
Agent / MCP Client 获取工具描述
大模型根据工具描述判断是否调用
框架负责发起工具调用

也就是说，MCP 不是替代 API，而是把 API 包装成 Agent 生态里的标准工具。

举个例子。

你原来有一个接口：

GET /api/order/{orderId}

普通后端项目里，需要你手写代码调用它。

但是如果做成 MCP Tool，它可能会变成：

工具名：queryOrder
描述：根据订单 ID 查询订单状态
参数：orderId
返回：订单详情

这样大模型在看到工具描述后，就有可能自己判断：

用户问的是订单状态，需要调用 queryOrder 工具。

这就是 MCP 和普通 API 的区别。

---

五、MCP 的通信方式：stdio、SSE 和 Streamable HTTP

今天聊天里还提到了一个重点：MCP 到底用什么通信方式？

根据 MCP 官方规范，MCP 使用 JSON-RPC 编码消息，并定义了标准传输机制，其中包括 stdio 和 Streamable HTTP。

可以简单理解为：

stdio：适合本地进程通信
Streamable HTTP：适合远程服务通信
SSE：早期常见的流式传输方式，现在更多作为历史方案或兼容方案理解

---

1. stdio：适合本地工具

stdio 就是标准输入输出。

比如 Claude Desktop 调用本地 MCP Server，本质上可以启动一个本地进程，然后通过标准输入输出传 JSON-RPC 消息。

它适合：

本地文件工具
本地脚本工具
本地数据库工具
开发环境工具
IDE 辅助工具

可以理解成：

Agent Client
   ↓ stdio
本地 MCP Server
   ↓
本地文件 / 本地命令 / 本地工具

优点是简单，适合本地环境。

缺点也明显：

不太适合大规模远程部署
权限管理和服务治理能力有限
不太适合企业级多用户场景

---

2. SSE：服务端向客户端持续推送

SSE，全称 Server-Sent Events。

它是基于 HTTP 的一种单向流式推送方式。

你平时看到大模型一个字一个字输出，很大概率就是类似 SSE 的流式效果。

它的特点是：

客户端发起请求
服务端持续返回数据流
适合大模型流式输出

它不像 WebSocket 那样是全双工通信。

WebSocket 更像：

客户端可以随时发
服务端也可以随时发
双方保持一条长连接

SSE 更像：

客户端问一句
服务端沿着这条响应流持续输出

所以你之前提出的疑问很有价值：

为什么大模型输出过程中，我不能随时打断并改变它的回答？

这里不仅是协议问题，还涉及产品设计、服务端中断机制、上下文管理和模型推理状态。

WebSocket 确实更适合双向实时通信，但 SSE 更简单，更适合“服务端持续输出文本”的大模型问答场景。

---

3. Streamable HTTP：MCP 现在更重要的远程通信方式

Streamable HTTP 可以理解为 MCP 更现代的 HTTP 传输方式。

根据 MCP 官方文档，Streamable HTTP 中，服务端可以作为独立进程处理多个客户端连接，并通过 HTTP POST 和 GET 请求通信；服务端也可以选择使用 SSE 来流式发送多条消息。

它比单纯 SSE 更适合 MCP 的原因在于：

可以更自然地支持远程 MCP Server
更适合企业级部署
更容易结合 HTTP 鉴权、网关、审计、负载均衡
可以支持流式能力

所以可以这样理解：

早期理解 MCP：stdio + SSE
现在理解 MCP：stdio + Streamable HTTP

如果是本地开发，stdio 很方便。

如果是企业级 Agent 平台，远程 MCP Server、大模型网关、权限认证、日志审计都要考虑，那么 Streamable HTTP 就更重要。

---

六、那 A2A 又是什么？

MCP 主要解决的是：

Agent 怎么连接工具和数据源。

而 A2A 解决的是另一个问题：

Agent 和 Agent 之间怎么通信、协作和互操作。

A2A，全称是 Agent2Agent Protocol。

Google 在 2025 年发布 A2A 时，将它定位为让 AI Agent 能够相互通信、安全交换信息，并在不同企业平台或应用之上协调行动的协议。

它的重点不是“工具调用”，而是“Agent 协作”。

例如：

一个采购 Agent
一个财务 Agent
一个审批 Agent
一个库存 Agent

它们可能分别属于不同系统、不同团队、不同平台。

如果没有统一协议，就需要大量定制集成。

A2A 想解决的问题就是：

不同框架开发的 Agent 怎么互相发现？
不同平台上的 Agent 怎么交换任务？
一个 Agent 怎么把任务委托给另一个 Agent？
Agent 之间怎么传递状态和结果？

A2A 官方 GitHub 介绍里也强调，它面向的是让不同公司、不同框架、不同服务器上的生成式 AI Agent 能够有效通信和协作，而不只是把对方当工具调用。

---

七、MCP 和 A2A 的区别

这两个很容易混。

可以用一句话区分：

MCP 是 Agent 连接工具。
A2A 是 Agent 连接 Agent。

更具体一点：

对比项	MCP	A2A
核心对象	工具、资源、数据源	另一个 Agent
主要关系	Agent → Tool	Agent → Agent
解决问题	工具标准化接入	Agent 互操作与协作
常见场景	查数据库、读文件、调 API、执行脚本	多 Agent 协作、跨平台任务委托
更像什么	工具协议	Agent 通信协议

举个例子。

如果你的 Agent 要查数据库：

Agent → MCP Server → 数据库

这更适合 MCP。

如果你的 Agent 要把任务交给另一个专门的 Agent：

Planner Agent → Executor Agent

或者：

客服 Agent → 订单 Agent → 售后 Agent

这更接近 A2A 的场景。

---

八、那多 Agent 项目里，一定要用 A2A 吗？

不一定。

如果你的多 Agent 是在同一个项目内部实现的，比如使用 Spring AI Alibaba Graph、LangGraph、AutoGen 这类框架，很多时候不需要上来就用 A2A。

因为框架内部已经可以通过状态对象、节点编排、消息传递来完成协作。

比如：

用户输入
 ↓
Planner Agent 生成计划
 ↓
Executor Agent 执行工具
 ↓
Reviewer Agent 检查结果
 ↓
Supervisor 判断是否结束

在这种项目里，Agent 之间的通信可能只是：

共享状态 State
消息列表 Messages
节点输出 outputKey
框架内部事件流

这时候并不一定需要 A2A。

A2A 更适合的是：

跨系统 Agent 协作
跨公司 Agent 协作
不同框架 Agent 协作
远程 Agent 服务互相调用
Agent 生态互操作

所以不能简单理解成：

只要是多 Agent，就必须用 A2A。

更准确的理解是：

项目内部多 Agent 编排，可以用框架自己的 State / Graph / Message 机制；
跨平台、跨系统、跨组织的 Agent 协作，才更需要 A2A 这类协议。

---

九、大模型网关在 Agent 项目里解决什么？

今天还聊到了“大模型网关”。

这个概念可以类比后端里的 API 网关。

普通后端网关解决的是：

统一入口
鉴权认证
限流
路由
日志
监控
熔断
灰度发布

而大模型网关解决的是 LLM 调用层面的统一治理。

比如：

统一接入 OpenAI、DeepSeek、通义千问、Claude 等模型
统一 API 格式
统一鉴权
统一限流
统一日志审计
统一费用统计
统一模型路由
统一降级策略
统一 Prompt 管理
统一内容安全过滤

在 Agent 项目里，大模型网关不是必须的，但在企业级项目里很有价值。

如果只是个人学习项目：

Spring AI → DeepSeek API

这样就可以跑起来。

但如果是企业级平台，可能就变成：

Agent 应用
   ↓
大模型网关
   ↓
不同模型厂商

这样做的好处是：

模型可以动态切换
调用成本可以统计
异常可以统一监控
不同业务可以配置不同模型
敏感内容可以统一过滤
Token 消耗可以统一管理

所以大模型网关更像是 Agent 平台化之后的基础设施，而不是每个小项目一开始就必须要做的东西。

---

十、把这些概念放到一张图里

可以这样理解整个 Agent 通信体系：

用户
 ↓
Agent 应用
 ↓
┌──────────────────────────────┐
│          Agent 核心层          │
│  任务理解 / 规划 / 记忆 / 工具决策 │
└──────────────────────────────┘
        ↓              ↓
        ↓              ↓
   MCP Client        A2A Client
        ↓              ↓
   MCP Server       其他 Agent
        ↓              ↓
 工具 / API / DB     专业 Agent 服务
        ↓
 外部系统

如果再加上大模型网关：

Agent 应用
   ↓
大模型网关
   ↓
LLM 服务商

如果再加上 RAG：

Agent 应用
   ↓
RAG 检索链路
   ↓
向量库 / ES / 知识库

这里 RAG 只是 Agent 获取知识的一种方式。

MCP 是 Agent 连接工具的方式。

A2A 是 Agent 连接其他 Agent 的方式。

大模型网关是 Agent 调用模型时的治理入口。

---

十三、今天的总结

今天这部分学习让我意识到：

Agent 的核心不只是“会不会调用大模型”，而是它能不能连接外部世界。

Function Calling 解决的是：

大模型如何表达工具调用意图

MCP 解决的是：

Agent 如何标准化连接工具、资源和数据源

A2A 解决的是：

Agent 如何和其他 Agent 通信协作

Streamable HTTP 解决的是：

MCP 在远程服务场景下如何更好地传输消息

SSE 解决的是：

服务端如何向客户端持续流式输出

大模型网关解决的是：

企业级场景下模型调用如何统一治理

RAG 在这里也很重要，但它不是今天的主角。

它更像是 Agent 的一种知识获取能力：

Agent 需要知识 → 调用 RAG 检索工具 → 获取上下文 → 再调用大模型生成答案

而 MCP、A2A、Streamable HTTP、大模型网关这些内容，则是在回答另一个更底层的问题：

当 Agent 不再只是聊天，而是要执行任务、调用工具、连接系统、协作完成复杂目标时，它们之间到底靠什么通信？