MCP协议有望迎来重大更新 引入可流式HTTP传输方式

最近，MCP协议迎来了一次重大升级——全新的Streamable HTTP传输机制正式引入。没错，这次改动可不是小打小闹，它直接化解了当前HTTP+SSE传输方式的诸多限制，同时完整保留了原有的优势。那么，这项改进具体带来了哪些变化？背后又蕴含着怎样的设计考量？

先简单回顾一下这张图，帮助你快速了解MCP协议的基本框架。

值得一提的是，这次更新离不开Shopify、Pydantic、Cloudflare、LangChain、Vercel、Anthropic团队以及MCP社区众多成员的热心反馈。可以说，这是一场真正的“集体共创”式演进。

主要变更：从端点设计到会话管理

与现有的HTTP+SSE传输相比，新版Streamable HTTP做出了几个关键调整：

• 移除了`/sse`端点：这个旧的路径标识直接被取消了。
• 所有客户端到服务器的消息，现在统一通过`/message`（或类似端点）来传输。
• 所有客户端到服务器的请求，都可以由服务器主动升级为SSE，用于发送通知或发起请求——控制权交回给服务器。
• 会话ID由客户端在请求头中提供，服务器可以根据自身需求决定是否关注这个ID。
• 客户端还可以通过向`/message`端点发送一个空GET请求，来初始化SSE流。

这样一来，新方案既实现了向后兼容，也让服务器能够根据需要灵活地保持无状态运行——这才是真正意义上的弹性设计。

更新动机：旧的HTTP+SSE到底卡在哪？

我们先来看看原来的远程MCP通过HTTP+SSE传输时，存在哪些令人困扰的问题：

• 不支持断线恢复：一旦连接中断，整个会话就必须重新开始。
• 要求服务器维护高可用的长连接：这对服务器的硬件资源和网络环境造成了不小的压力。
• 服务器消息只能通过SSE传递：消息传输的通道被锁定，缺乏灵活性。

换个角度来看，正是这些痛点，才催生了本次更新。

主要优势：Streamable HTTP的新意在哪？

1. 无状态服务器成为可能：不再需要费力维持高可用的长连接，服务器可以变得更“轻量”。
2. 纯HTTP实现：MCP可以在纯HTTP服务器中正常运行，完全不需要依赖SSE支持。
3. 基础设施兼容性：它本质上就是“普通HTTP”，所有中间件和基础架构都能无缝集成。
4. 向后兼容：不是推倒重来，而是对现有传输机制的渐进式升级。
5. 灵活的升级路径：服务器可以根据实际需求，随时启用SSE进行流式响应。

应用场景：不同服务器类型下的玩法

无状态服务器

一个完全无状态的服务器，甚至可以完全不支持长连接：初始化时，它只需要一次性确认（无需保存任何状态）；需要列出工具时，直接通过单个JSON-RPC响应处理；执行工具调用时，完成后便将结果作为HTTP响应体返回。整个流程干净利落。

带流式处理的无状态服务器

即使是无状态服务器，依然可以实现流式处理：当接收到一个工具调用请求时，服务器先主动提示响应将采用SSE；在执行工具的过程中，可以发送进度通知；一旦执行完毕，再发送最终响应，然后关闭SSE流。这相当于一边干活一边向你实时汇报进度。

有状态服务器

有状态服务器类似于当前实现，但需要额外处理会话ID头，确保在水平扩展部署时，消息能够准确路由到对应的会话。

为何不选择WebSocket？

团队在讨论中详细评估了将WebSocket作为主要远程传输方案的可行性，但最终暂时不予采用。原因非常实际：

• 在“RPC式”使用场景下，WebSocket会带来不必要的运营和网络开销。
• 浏览器环境无法为WebSocket附加授权等头部信息。
• 只有GET请求能透明升级为WebSocket连接，这需要复杂的两次握手升级步骤。

说白了，现阶段WebSocket对MCP的使用场景而言，有些“杀鸡用牛刀”的味道。

总结

这次更新让MCP协议的灵活性和稳健性迈上了一个新台阶，能够更从容地应对更广泛的应用场景。尽管当前选择了基于HTTP的方案，但未来依然保留了对WebSocket等其他传输方式探索的可能性。通过这次技术升级，MCP协议将更好地契合现代应用架构的要求，为开发者提供更强大、更可靠的消息通信能力。一句话：更简单、更灵活、更稳定。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：MCP协议有望迎来重大更新 引入可流式HTTP传输方式要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题