从 SSE 到 Streamable HTTP：看懂 MCP 最新传输协议演进

前言

如果你最近在研究 MCP（Model Context Protocol）、AI Agent、Cursor、Claude Desktop 或各种 MCP Server，可能会看到这样一个变化：

复制代码

HTTP + SSE
    ↓
Streamable HTTP

很多人第一次看到会疑惑：

SSE 是什么？
Streamable HTTP 又是什么？
MCP 为什么要从 HTTP+SSE 迁移到 Streamable HTTP？
ChatGPT、Claude、Cursor 是否也在使用类似技术？

本文将结合 MCP 协议演进过程，一次性讲清楚这些问题。

什么是 SSE？

SSE（Server-Sent Events，服务器发送事件）是一种基于 HTTP 的实时推送技术。

传统 HTTP 的工作方式是：

复制代码

Client → Request
Server → Response
连接结束

而 SSE 的工作方式是：

复制代码

Client → 建立连接
Server → 持续推送数据
Server → 持续推送数据
Server → 持续推送数据

服务器保持连接不断开，并不断向客户端发送事件。

例如：

复制代码

Content-Type: text/event-stream

响应内容：

复制代码

data: Hello

data: World

data: ChatGPT

浏览器通过 EventSource API 即可接收：

javascript 复制代码

const source = new EventSource("/events");

source.onmessage = (event) => {
    console.log(event.data);
};

SSE 的核心特性

特性	说明
单向通信	仅服务器→客户端
基于 HTTP	无需特殊协议，兼容性好
自动重连	连接断开后浏览器自动尝试恢复
事件类型	支持自定义 `event:` 字段区分消息类型
轻量级	比 WebSocket 更简单，资源消耗更少

为什么 AI 应用喜欢 SSE？

以 ChatGPT 为例。

如果用户问：

请解释量子力学

模型可能需要几秒钟才能生成完整答案。

传统方式：

复制代码

等待 10 秒
    ↓
一次返回全部内容

用户体验很差。

而 SSE 可以：

复制代码

第一个 Token
第二个 Token
第三个 Token
...

边生成边展示。

于是用户看到：

复制代码
正
在
输
出
...

这种打字机效果本质上就是流式传输。

流式传输对 AI 应用的额外价值

除了用户体验，流式传输还有两个关键价值：

降低首 Token 延迟（TTFT）：用户感知到的响应速度大大提升，首 Token 通常只需要几十到几百毫秒
支持中途打断：用户可以在生成过程中点击"停止生成"，无需等待完整响应

MCP 旧版协议：HTTP + SSE

在 MCP 2024-11-05 版本中，远程通信采用：

javascript 复制代码

Client → HTTP POST
Server → SSE

结构如下：

javascript 复制代码

MCP Client
    │
    │ POST (请求)
    ▼
MCP Server
    │
    │ SSE (推送)
    ▼
MCP Client

客户端负责发起请求，服务器通过 SSE 返回：

工具执行进度
日志信息
流式输出
结果通知

这种设计能够满足 AI 应用需求，但也带来一些问题。

HTTP + SSE 的问题

1. Stateful（有状态）

SSE 本质是长连接。

服务器需要记录：

javascript 复制代码

连接A
连接B
连接C

以及：

javascript 复制代码

Session
Connection
Context

服务器必须维护这些状态。

2. 云原生部署不友好

现代架构通常是：

复制代码

Kubernetes
Load Balancer
Serverless
Cloudflare

这些平台更喜欢：

复制代码

Stateless（无状态请求）

而 SSE 长连接会导致：

负载均衡复杂
连接迁移困难
资源占用增加

3. 并非所有请求都需要流式

例如：

javascript 复制代码

{
  "method": "tools/list"
}

服务器立即返回：

javascript 复制代码

{
  "tools": [...]
}

根本不需要建立 SSE。

4. 双通道协调复杂性

旧版 MCP 需要客户端同时管理：

一个 HTTP POST 通道（发送请求）
一个 SSE 通道（接收推送）

这意味着客户端需要维护两套连接逻辑、两套错误处理、两套重连机制。

5. 代理和网关兼容性

许多企业代理、API 网关对长时间保持的 SSE 连接支持不佳，可能：

强制超时断开
缓冲响应内容
负载均衡导致连接漂移

因此旧方案显得有些笨重。

什么是 Streamable HTTP？

为了解决上述问题，MCP 在 2025-03-05 版本引入：

复制代码

Streamable HTTP

核心思想：

复制代码

统一使用 HTTP
按需启用 Streaming

简单理解：

复制代码
普通 HTTP
+
流式 HTTP

合并成一个统一传输层。

关键设计原则

原则	说明
统一端点	所有操作使用同一个 HTTP 端点
按需流式	仅在需要时使用 SSE
无状态优先	尽量使用无状态请求模式
标准 HTTP	充分利用 HTTP 生态工具

MCP 新版工作流程

第一步：初始化

客户端：

复制代码
POST /mcp

发送：

javascript 复制代码

{
  "method": "initialize"
}

服务器返回：

javascript 复制代码

{
  "protocolVersion": "2025-03-05"
}

完成初始化。

第二步：正常通信

很多请求直接返回：

javascript 复制代码

POST /mcp
    ↓
{
  "result": ...
}

结束，无需流式。

第三步：按需开启 SSE

如果客户端需要实时推送：

javascript 复制代码

GET /mcp
Accept: text/event-stream

服务器即可建立 SSE 通道。

随后持续发送：

javascript 复制代码

event: progress
data: 10%

event: progress
data: 50%

event: done
data: completed

因此：

复制代码

SSE 变成可选能力
而不是协议基础设施

完整通信流程对比

场景	旧版 (HTTP+SSE)	新版 (Streamable HTTP)
初始化	POST + SSE 建立	POST 一次性返回
工具列表	POST 请求，通过 SSE 返回	POST 请求，直接返回
工具调用	POST 请求，通过 SSE 推送进度	POST 请求，需要流式时升级为 SSE
资源读取	POST 请求，通过 SSE 返回	POST 请求，直接返回
多会话	每个会话需维护 SSE 连接	每次请求可独立，按需流式

Stateful 与 Stateless

这是理解 Streamable HTTP 的关键。

Stateful

服务器保存状态：

复制代码

用户A → 连接001
用户B → 连接002

每个连接都需要维护。

典型代表：

SSE
WebSocket

Stateless

每个请求独立：text

复制代码

请求1 → 处理 → 结束
下一次请求 → 重新携带上下文

服务器无需记住客户端。

典型代表：

REST API

Streamable HTTP 优先支持 Stateless 模式，只在必要时启用 Stateful 的 SSE。

这对 MCP Server 开发者意味着什么？

方面	影响
部署	Server 可以更轻松地部署到 Serverless 平台
扩容	水平扩展更简单，无需同步连接状态
监控	标准的 HTTP 日志和指标即可，无需特殊处理
测试	可以使用 curl 等标准工具测试大部分功能

Streamable HTTP 如何解决旧版问题？

旧版问题	Streamable HTTP 解决方案
有状态	默认无状态，按需启用流式
云原生部署不友好	标准 HTTP，完全兼容 K8s、Serverless
非流式请求被迫走 SSE	普通请求直接 HTTP 响应，不建立 SSE
双通道复杂	单一端点，GET 控制流式通道
代理不友好	标准 HTTP/1.1 和 HTTP/2，兼容性好

Streamable HTTP 在哪里被广泛使用？

事实上，AI 行业几乎已经全面采用类似设计。

ChatGPT

流式回答：

复制代码

Token → Token → Token → 持续返回

采用 Server-Sent Events 或类似的流式 HTTP。

Claude API

Anthropic 返回：

复制代码

message_start
content_delta
content_delta
message_stop

本质也是流式 HTTP。

OpenAI API

开启：

javascript 复制代码

{
  "stream": true
}

即可获得流式响应。

Ollama / vLLM / TGI

本地模型服务也普遍采用：HTTP + Streaming返回生成 Token。

跨 AI 平台的流式实现对比

平台	流式协议	控制参数
OpenAI	SSE	`stream: true`
Anthropic	SSE	`stream: true`
Google Gemini	SSE/WebSocket	`streaming` 参数
Cohere	SSE	`stream: true`
Ollama	纯 HTTP 分块传输	`stream: true`
vLLM	SSE	`stream: true`

为什么 MCP 最终选择 Streamable HTTP？

主要有五个原因：

1. 更简单

统一使用 HTTP，开发者不需要同时处理两种不同的通信模式。

2. 更兼容

天然适配：

Nginx
Kubernetes
Cloudflare
AWS
Azure

3. 更灵活

支持：

同步请求
流式请求

按需选择。

4. 更符合 AI Agent 未来趋势

未来 Agent 会频繁执行：

Tool Calling
Resource Access
Sampling
Workflow

很多操作不需要 SSE，统一协议更加合理。

5. 更低的运维成本

标准 HTTP 意味着可以使用：

标准负载均衡
标准健康检查
标准日志格式
标准监控工具

MCP 协议演进路线图

复制代码

2024-10-01    MCP 初始版本发布
      ↓
2024-11-05    HTTP + SSE 成为推荐的远程传输方式
      ↓
2025-01-15    社区反馈 SSE 在云环境中的问题
      ↓
2025-03-05    Streamable HTTP 引入，作为替代方案
      ↓
2025-03-20    Streamable HTTP 成为推荐传输协议
      ↓
2025-04-XX    旧版 HTTP+SSE 标记为 Deprecated
      ↓
2025-06-XX    完全移除旧版支持（计划中）

延伸思考：未来的 Agent Protocol

MCP 的演进实际上反映了整个 AI Agent 行业的发展方向：text

复制代码

REST API（同步）
     ↓
SSE（单向流式）
     ↓
Streamable HTTP（按需混合）
     ↓
Agent Protocol（双向智能交互）

什么是 Agent Protocol？

未来 Agent 之间可能需要：

双向通信（Agent 互相协商）
多轮对话（持续上下文）
任务委托（A Agent 委托 B Agent）
状态同步（实时共享进度）

MCP 在其中的角色

MCP 目前主要解决：

Client ↔ Server 通信
工具调用标准化
资源访问标准化

未来可能演进到：

Server ↔ Server 通信
Agent 集群协作
分布式任务编排

实践建议

何时使用流式？

场景	是否流式	原因
模型文本生成	✅ 是	用户体验，降低 TTFT
工具执行进度	✅ 是	反馈进度，避免超时
工具列表查询	❌ 否	数据量小，立即返回
资源内容读取	视情况	大文件可流式
健康检查	❌ 否	简单响应
日志订阅	✅ 是	实时监控需要

部署架构建议text

复制代码

┌─────────────────────────────────────────┐
│            客户端 (Client)               │
│  - 优先使用无状态请求                    │
│  - 按需启用流式                         │
└─────────────────┬───────────────────────┘
                  │ HTTP
┌─────────────────▼───────────────────────┐
│         负载均衡 (LB)                    │
│  - 标准 HTTP/HTTPS 路由                 │
│  - 无需粘性会话                         │
└─────────────────┬───────────────────────┘
                  │
┌─────────────────▼───────────────────────┐
│        MCP Server (K8s 部署)            │
│  - 水平自动扩缩容                        │
│  - 无状态 (默认)                        │
│  - 按需管理 SSE 连接                    │
└─────────────────────────────────────────┘

总结

MCP 传输协议的演进可以概括为：text

javascript 复制代码

HTTP + SSE
        ↓
Streamable HTTP

旧版：

javascript 复制代码

Client → HTTP (请求)
Server → SSE (推送)

属于固定双通道模式。

新版：

复制代码
Client ↔ HTTP (统一)

根据需要：

普通响应（同步）
SSE 流式响应（按需）

核心变化：

SSE 从"必须"变成"可选"：只在需要流式传输时启用
优先无状态：符合云原生部署要求
统一端点：降低客户端和服务器的复杂性
标准 HTTP：充分利用 HTTP 生态

本质：Streamable HTTP 并不是取代 SSE，而是把 SSE 从"协议基础设施"降级为"按需启用的传输能力"。

这也是整个 AI 行业当前的发展方向：

复制代码

REST API
     ↓
SSE
     ↓
Streamable HTTP
     ↓
Agent Protocol

而 MCP 只是率先将这种趋势标准化了。

从 SSE 到 Streamable HTTP：看懂 MCP 最新传输协议演进

前言

什么是 SSE？

SSE 的核心特性

为什么 AI 应用喜欢 SSE？

流式传输对 AI 应用的额外价值

MCP 旧版协议：HTTP + SSE

HTTP + SSE 的问题

1. Stateful（有状态）

2. 云原生部署不友好

3. 并非所有请求都需要流式

4. 双通道协调复杂性

5. 代理和网关兼容性

什么是 Streamable HTTP？

关键设计原则

MCP 新版工作流程

第一步：初始化

第二步：正常通信

第三步：按需开启 SSE

完整通信流程对比

Stateful 与 Stateless

Stateful

Stateless

这对 MCP Server 开发者意味着什么？

Streamable HTTP 如何解决旧版问题？

Streamable HTTP 在哪里被广泛使用？

ChatGPT

Claude API

OpenAI API

Ollama / vLLM / TGI

跨 AI 平台的流式实现对比

为什么 MCP 最终选择 Streamable HTTP？

1. 更简单

2. 更兼容

3. 更灵活

4. 更符合 AI Agent 未来趋势

5. 更低的运维成本

MCP 协议演进路线图

延伸思考：未来的 Agent Protocol

什么是 Agent Protocol？

MCP 在其中的角色

实践建议

何时使用流式？

部署架构建议text

总结

参考资源