「Agent Tool」MCP 协议通常采用什么通信方式？

0 前言

本文内容整理自公众号「小林面试笔记」的文章 13. MCP 协议通常采用什么通信方式？，用于记录与总结 AI Agent 工具调用相关的核心面试知识点。

「MCP 协议通常采用什么通信方式？」，可以这样作答：

MCP 支持两种主要的传输方式，适用不同场景：本地场景用 stdio——Client 把 Server 作为子进程启动，通过标准输入输出通信，延迟极低、不用开端口、没有网络安全问题，Claude Desktop 接本地工具走的就是这种方式；远程场景用 Streamable HTTP——Server 作为独立的 HTTP 服务部署，多个 Client 可以共享同一个 Server，适合团队统一管理工具服务。

MCP 早期版本（2024-11-05 规范）的远程传输是「HTTP + SSE」双端点方案，在 2025 年 3 月被标记为 deprecated（保留向后兼容、但不推荐新项目使用），Streamable HTTP 成为推荐的远程传输方式。

不管哪种传输方式，底层消息格式都统一用 JSON-RPC 2.0——传输方式只影响「怎么传」，消息协议本身不变。传输方式和消息格式解耦，正是 MCP 灵活性的关键。

如今 Claude Desktop、Cursor 等客户端本地接入文件系统、GitHub 工具走的就是 stdio——配置文件里写几行启动命令即可；而云端部署、团队共享的 MCP 服务（比如一个统一的数据库 Server）普遍用 Streamable HTTP，主流 MCP 客户端和 SDK 都已迁移到这套传输。协议层的大致轮廓我们第 3 篇已经概述过，这篇把通信方式挖到最底层。

1 先破除误区：MCP 不用 WebSocket，也不走 REST

很多人一听到「MCP 需要双向通信」就想到 WebSocket——Client 发请求、Server 推结果，全双工正好合适？答案是不对，MCP 没有用 WebSocket。再猜一个：本地场景走 HTTP，在本机起个服务、通过 localhost 访问？也想复杂了。

MCP 的真实设计是双层结构：

  • 消息格式层：不管本地还是远程，统一用 JSON-RPC 2.0；
  • 传输层：按场景二选一——本地用 stdio（标准输入输出，根本不需要网络），远程用 Streamable HTTP（不是 WebSocket，流式推送内部走 SSE）。

先记住这个结论，下面逐层拆。

2 底层消息格式：JSON-RPC 2.0

在说传输方式之前，先说消息格式——因为不管用哪种传输方式，消息格式都是同一套。

为什么 MCP 选 JSON-RPC 2.0？原因其实很朴素。MCP 需要一种「Client 调用 Server 的方法、Server 返回结果」的通信模式，这本质上就是远程过程调用（RPC）；而 JSON-RPC 2.0 是现成的、足够轻量的 RPC 规范——JSON 格式易读易调试，任何编程语言都能实现，Server 是 Python 写的还是 TypeScript 写的，消息格式都一样，不需要额外的序列化工具。

JSON-RPC 2.0 消息格式：请求与响应成对、以 id 匹配

每条消息就是一个 JSON 对象，格式固定：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 请求消息（Client -> Server）
{
  "jsonrpc": "2.0",
  "id": 1,                        // 请求 ID，用于匹配响应
  "method": "tools/call",         // 调用的方法名
  "params": {
    "name": "take_screenshot",    // 工具名
    "arguments": {"url": "https://example.com"}
  }
}

// 响应消息（Server -> Client）
{
  "jsonrpc": "2.0",
  "id": 1,                        // 对应请求的 ID
  "result": {
    "content": [{"type": "image", "data": "...base64..."}]
  }
}

注意一个关键点：JSON-RPC 本身只定义消息格式，不关心底层怎么传输。MCP 在此基础上定义了两种传输层实现——一个管「说什么」，一个管「怎么送」，互不依赖。

3 本地传输：stdio

stdio 是 MCP 最常用的传输方式，适合本地工具的场景。

工作原理很简单：MCP Client（比如 Claude Desktop）在启动时，把 MCP Server 当作一个子进程启动，然后通过进程的标准输入（stdin）发送请求、从标准输出（stdout）读取响应——两个进程在同一台机器上运行，通过操作系统的管道通信。

stdio 传输：Client 以子进程启动 Server，经操作系统管道通信

这里的「管道」到底是什么？你可以把它理解成操作系统在内存里给这两个进程分配的一段先进先出的小缓冲区：Client 往里塞一行 JSON，Server 从缓冲区的另一头读出来处理；处理完再往另一条管道里塞一行 JSON，Client 从那头读。

整个过程不经过网卡、不经过 TCP/IP 协议栈，数据在 RAM 里走了一趟就到了，延迟天然比网络请求低得多。stdio 方式的优点很实在：

  • 延迟极低：进程间通信比走网络快得多，数据直接在操作系统管道里流转，几乎没有额外开销；
  • 不需要开端口：没有暴露服务的面，也就没有网络安全问题，不用担心外部访问；
  • 生命周期自动管理：Server 随 Client 启动而启动、随 Client 关闭而关闭，不用手动管进程。

实际使用时，你只需要在配置文件里告诉 Client「用什么命令启动 Server」：

1
2
3
4
5
6
7
8
9
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",               // 启动命令
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"],
      "env": {}                       // 环境变量（可选）
    }
  }
}

（这套配置我们在第 4 篇「实际跑一遍 MCP」里已经完整演示过，这里不再展开。）

4 远程传输：Streamable HTTP

远程场景下，Server 作为独立的 HTTP 服务运行，Client 通过网络连接访问。MCP 当前推荐的远程传输方式是 Streamable HTTP。

Streamable HTTP 的核心设计是用单个 HTTP 端点（通常是 /mcp）同时处理请求和响应：Client 通过 POST 请求发送 JSON-RPC 消息，Server 选择两种方式返回——简单的同步操作直接返回一个普通 JSON 响应；需要流式输出的操作则返回一条 SSE 流持续推送数据。这种「按需选择」的设计很灵活，不需要强制建立长连接。

Streamable HTTP：云端部署的 Server 可被多个 Client 共享

Streamable HTTP 的优点很明确：Server 可以部署在云端，多个 Client 共享同一个 Server——比如团队共用一个部署在服务器上的数据库 MCP Server，所有人连同一个服务就行，不用各自在本地跑一份；而且支持跨机器访问，适合需要统一管理工具服务的团队或平台。

当然，代价也存在：相比 stdio 多了网络开销、延迟略高，还要处理认证、网络中断重连这些本地场景完全不用操心的问题。

5 演进：为什么双端点方案被 Streamable HTTP 取代

你可能在一些早期教程里看到过 SSE（Server-Sent Events）传输方式。这里要澄清：HTTP + SSE 双端点方案是 MCP 早期版本（2024-11-05 规范）的远程传输方案，在 2025 年 3 月的规范更新里被标记为 deprecated——仍然保留向后兼容，但新项目应该直接用 Streamable HTTP（这一点第 3 篇概述协议层时提过一句，这里讲清楚来龙去脉）。

为什么要替换？因为架构上有个小尴尬：Client 向 Server 发请求要走 POST 端点，Server 向 Client 推数据要走另一条 SSE 长连接端点——同一个对话被拆成了两条通道。

旧版 HTTP+SSE 双端点：POST 与 SSE 两条通道拆分

这带来的具体问题是状态管理复杂：Client POST 了一条消息后网络突然断了，那条消息到底被处理了没？SSE 流还会不会推回结果？Client 没有一个简单的办法判断，出问题时排查链路很长。

Streamable HTTP 的做法是把两条通道合并成一个端点：Client 照样 POST 发请求，Server 根据情况决定返回「一个普通 JSON」还是「一条 SSE 流」，不需要 Client 提前开另一条连接。

Streamable HTTP 单端点：一个 /mcp 同时处理请求与响应

注意这里的关键：Streamable HTTP 并没有抛弃 SSE——流式推送的部分底层还是 SSE（Content-Type: text/event-stream），只是把端点从两个合成一个。架构更简洁，对负载均衡和 serverless 环境都更友好。目前主流的 MCP 客户端和 SDK 都已经迁移到了 Streamable HTTP。

6 面试总结

回答这道题，最常见的误区就是想当然地以为 MCP 用 WebSocket 或 HTTP REST 接口。先避开几个雷：

误区 正解
MCP 用 WebSocket 做双向通信 MCP 不用 WebSocket：本地走 stdio（子进程 + 管道），远程走 Streamable HTTP（内部流式用 SSE）
本地工具也走 HTTP、localhost 起服务 本地场景直接用 stdio，根本不经过网络
把消息格式和传输方式混为一谈 底层统一 JSON-RPC 2.0，stdio / Streamable HTTP 只是传输层实现，两者解耦
还在教新项目用 HTTP+SSE 双端点 双端点在 2025 年 3 月已 deprecated，新项目用 Streamable HTTP

再按这张框架组织答案：

框架 要点
消息格式 统一 JSON-RPC 2.0：轻量 RPC 规范、易读易调试、语言无关；请求/响应成对、以 id 匹配；格式与传输解耦
本地传输 stdio Client 以子进程启动 Server，经操作系统管道（RAM 里 FIFO 缓冲区）通信；不走网卡与 TCP/IP 栈，延迟极低；不开端口无网络安全面；生命周期自动管理
远程传输 Streamable HTTP 单端点 /mcp：POST 发消息，同步返回 JSON、流式返回 SSE；多 Client 共享、跨机器；代价是网络开销、认证与重连
演进史 早期（2024-11-05 规范）HTTP+SSE 双端点因状态管理复杂 deprecated → Streamable HTTP 合并为单端点，内部流式仍走 SSE

追问预案：

  • 「MCP 用 WebSocket 吗？」——不用。本地场景用 stdio，远程场景用 Streamable HTTP；远程的流式推送内部走 SSE，与 WebSocket 无关。
  • 「stdio 和 Streamable HTTP 怎么选？」——本地工具、低延迟、单机使用选 stdio；云端部署、团队共享 Server、跨机器访问选 Streamable HTTP。
  • 「消息格式和传输方式什么关系？」——解耦。JSON-RPC 2.0 只定义消息长什么样，stdio / Streamable HTTP 只定义怎么传，切换传输方式不影响上层调用逻辑（协议层整体结构见第 3 篇）。
  • 「SSE 是被淘汰了吗？」——被淘汰的是「HTTP + SSE 双端点」这套远程方案（2025 年 3 月 deprecated）；SSE 本身还活着——Streamable HTTP 的流式推送底层依然用 SSE，只是端点合并成一个。
  • 「远程部署 Streamable HTTP 要注意什么？」——认证、网络中断重连、负载均衡；单端点设计对 serverless 环境也更友好。

参考

本文图片均来源于公众号「小林面试笔记」，版权归原作者所有。

追逐繁星 > Agent Tool
#AI #Agent #大模型 #LLM
「Agent Tool」MCP 协议通常采用什么通信方式？
https://marisamagic.github.io/2026/08/19/20260819_MCP通信方式/
作者
MarisaMagic
发布于
2026年8月19日
许可协议