告别永不落幕的守夜：MCP Streamable HTTP 的轻盈革命

我这些天把 MCP 规范又翻了几遍。2025 年 3 月 26 日前后，官方悄然把旧 HTTP + SSE 标为 deprecated，转而把 Streamable HTTP 推上前台做默认。这事儿说大不大，说小不小——它直接改写了 AI agent 跟工具、上下文打交道的节奏。旧方式像个粘人守夜人，必须 24 小时盯着那条专线；新方式则像个懂分寸的助手，要用的时候来，用完就走。差别一目了然，却藏着对整个生态的深远影响。

🌐 MCP 传输的旧梦：双端点持久战的隐痛

旧 HTTP + SSE 时代，端点一分为二。客户端得同时管 POST 发令的口子，和 SSE 收讯的专线。两条线并行，却像两条永远不能关的水龙头。尤其是 SSE 那条，必须时刻在线，服务器也得常备不懈。网络稍有波动，连接一断，上下文就可能全丢。开发者得额外写恢复逻辑，服务器资源却一直在烧。说白了，这套设计在早期流式需求刚冒头时勉强能用，可一旦 agent 并发起来，问题就全暴露了。

再看连接模型。旧制要求 dedicated SSE channel 始终在线，哪怕半夜没人调用，也得挂着。服务器因此背着沉重负担，高可用长连接池随时待命。扩展性自然受限——想多加几台机器，负载均衡和 proxy 还得专门为这条“永动机”开绿灯。兼容性更别提，CORS、auth、现代网关设施经常跟它过不去。架构别扭，单向推送为主，服务器想主动说句话都费劲。

⚡ Streamable HTTP 的魔法：一个端点里的按需流转

新协议把这一切翻篇了。客户端只往一个统一端点发 POST。服务器收到后，若是短交互，立刻返回普通 application/json 响应；若是需要流式——比如 LLM token 逐个吐出、长任务进度推送——就直接把这个响应动态升级成 text/event-stream。格式还是 SSE 那套，可全在同一个请求、同一个端点里完成。办完事，服务器 SHOULD close the stream，不用一直挂着。还支持 standalone GET 单独拉 SSE 流，加上 session 管理。

这设计妙就妙在“按需”。普通请求走常规生命周期，需要流式时才把连接打开，用完即关。官方文档反复强调：Does not require long-lived HTTP connection。服务器终于能喘口气，不用再为“可能随时推送”而常备资源。stateless 变体甚至让 ephemeral server 也能轻松上阵。客户端也省心了，只管一个端点，不用协调两条连接。

会话恢复的实用设计：断线后，客户端带上 Mcp-Session-Id 和 Last-Event-ID 重新发起请求，服务器就能从上次事件继续推送，而非让整个流从头再来。这在 agent 多步工具调用、长上下文推理时尤其要命。想想看，报告写到一半网络抖一下就全丢，那体验得多糟。新机制像给对话装了自动存档点，续传自然流畅，上下文不丢。

🔄 长连还是短连？Streamable 的灵活哲学

它不算传统短连接——传统短连接是请求响应完立刻 close TCP。但它也远不是旧 SSE 那种强制持久长连。Streamable 是“需要时才长”，普通请求可以短、中生命周期，流式响应才保持打开直到结束或服务器主动关闭。还支持 streamable_stateless 模式，更接近短连接友好。服务器负担因此大幅减轻。高并发场景下，资源分配更弹性，不会因为“必须一直在线”而轻易耗尽连接池。

这才是关键。旧方式下，服务器像个永不休息的守夜人，资源永远被占着；新方式则让它成了随叫随到的快递员，送完就撤。部署复杂度直线下降，跟现有 proxy、负载均衡、auth 设施也天然亲和。CORS 不再是拦路虎，stateless 架构更易云原生扩展。

💥 旧痛新解：MCP 为何痛下决心换道

旧 HTTP + SSE 的痛点真实存在。连接不可恢复，断线丢上下文；服务器必须维持高可用长连接，扩展性差；只能单向推，架构别扭；跟现代 web 基础设施冲突大。这些问题在 agent 规模起来后，成了实打实的瓶颈。开发者花在连接管理、恢复逻辑上的精力，常常超过业务本身。

Streamable HTTP 一招解多痛。它保留了流式能力，还加了双向支持（同一流里 server 可先发 request/notification 再 response）、session 管理、resumability。架构干净了，部署简单了，兼容性也上来了。服务器不再被持久连接绑架，客户端代码也更简洁。高并发、生产环境下的稳定性明显更好。

🚀 船长拍板：新项目直奔 Streamable，老系统平稳过渡

新项目、新 MCP server，直接上 Streamable HTTP 就行，别再碰旧 SSE 了。好处摆在那儿：端点少一半，连接按需，扩展性强，部署友好。老系统迁移也不用慌，官方保留 backward compatibility，可以先双端点并行过渡，逐步切。尤其是做 Agent / LLM 工具链的——正如 KLIP 系列那类实践，在高并发、生产部署、连接稳定性上，新方式胜出明显，值得优先采用。

当然，如果不是 MCP，而是泛指一般 Web 开发里的 SSE vs HTTP chunked streaming，那结论会略有不同：两者连接都是 long-lived，区别主要在格式标准化和使用便利性（SSE 有固定 data:/event: 格式 + EventSource API + 自动重连）。但从用词精确度看，99% 指向 MCP 语境。

这场传输方式的转变，看似只是协议小修，实则是 AI agent 基础设施走向成熟的标志。我翻完规范后只有一个感觉：旧梦结束了，新路更轻盈。开发者终于能把更多精力放回真正该关心的东西——让模型跟工具、上下文的对话，变得更自然、更可靠。

参考文献

1. MCP 官方规范更新说明（2025 年 3 月 26 日弃用旧 HTTP + SSE，转向 Streamable HTTP 作为默认）
2. Model Context Protocol 传输机制对比：单端点 Streamable HTTP 工作原理详解
3. MCP 会话恢复与 Last-Event-ID resumability 技术解读
4. 从持久长连接到按需流式：MCP 架构演进与迁移指南
5. Agent 工具链集成 MCP 的最佳实践——Streamable HTTP 在高并发场景下的优势验证