一文搞懂：Anthropic发布MCP重要更新，告别长连接

🎉 1. 介绍

Anthropic近日宣布对Model Context Protocol （MCP）进行重大更新，推出全新的"Streamable HTTP"传输方式，替代现有的HTTP+SSE方案。 Github PR: github.com/modelcontex...

MCP协议最近因为通用智能体，而变得特别的火。近期，Anthropic又发布了对MCP的更新。

这次更新本质上是对MCP数据传输机制的重构，使协议变得更灵活、更易用且更具兼容性。打个比方，原来的MCP传输方式就像与客服通话时必须保持持续在线（SSE需要长连接），而新方案则类似于随时可以发送消息并等待回复(普通HTTP请求，但可选流式传输)。

此次更新主要包括五大核心变更:

移除了专用的/sse端点，服务器不再单独维护SSE（Server-Sent Events）端点
所有客户端到服务器的消息均通过统一的/message端点传输，不再依赖/sse
服务器可根据需要动态将HTTP请求升级为SSE流，用于发送通知或请求
客户端通过Header提供Mcp-Session-Id，服务器可自行决定是否存储会话信息
支持完全无状态的服务器运行，不再需要维持长期连接

As compared with the current HTTP+SSE transport:

We remove the /sse endpoint

All client → server messages go through the /message (or similar) endpoint

All client → server requests could be upgraded by the server to be SSE, and used to send notifications/requests

Servers can choose to establish a session ID to maintain state

Client can initiate an SSE stream with an empty GET to /message

This approach can be implemented backwards compatibly, and allows servers to be fully stateless if desired.

🤖 2. 从"持久电话"到"智能快递"的进化

在AI模型与应用交互的领域，数据传输协议就像神经系统的传导机制。原有MCP采用的HTTP+SSE方案，相当于要求用户和客服必须保持持续通话（SSE长连接）。这种机制存在三个致命缺陷：

通话中断即重置：就像电话掉线后必须从头复述问题，SSE断开后客户端需要重新建立完整会话。这对于需要长时间交互的AI应用（如持续对话模型）是灾难性的。
客服资源被独占：服务器需要为每个客户端维持专用线路，就像客服无法同时处理多个来电。这在Serverless架构中尤为明显，Cloudflare Workers等平台对长连接支持有限。
单向沟通的困境：SSE只允许服务器向客户端发送数据，形成了类似"客服单方面讲话"的模式。当需要双向协商（如动态调整传输格式）时，必须建立额外通道，增加了系统复杂度。

这些缺陷在AI应用规模化部署时愈发突出。以某智能客服系统为例，原有架构在用户量激增时，服务器维持的SSE连接数呈指数级增长，导致如AWS Lambda冷启动等问题，响应延迟从200ms飙升至5秒以上

📦 3. 新的"Streamable HTTP"传输方式（类似快递）

新方案的核心创新在于重新定义了HTTP协议的使用范式，实现了四个关键转变：

1. 连接模式的重构

传统HTTP像一次性快递：发送请求→接收包裹→结束
新方案赋予HTTP"智能快递柜"属性：客户端投递请求（Mcp-Session-Id作为取件码），服务器可选择：
- 立即响应（普通HTTP）
- 开启专用货柜持续投递（升级为SSE流）
- 分批次投递（分块传输编码)

2. 状态管理的革新

通过Mcp-Session-Id头部实现"无状态中的有状态"：

http 复制代码

POST /message HTTP/1.1
Mcp-Session-Id: 7x9b2f8c-动态令牌
Content-Type: application/mcp+json
{"prompt": "解释量子纠缠", "stream": true}

服务器无需维护会话状态，只需在需要时根据Session ID重建上下文。这类似于快递员通过运单号获取配送信息，而不必记住每个客户。

Stateless servers are now possible---eliminating the requirement for high availability long-lived connections

Plain HTTP implementation---MCP can be implemented in a plain HTTP server without requiring SSE

Infrastructure compatibility---it's "just HTTP," ensuring compatibility with middleware and infrastructure

Backwards compatibility---this is an incremental evolution of our current transport

Flexible upgrade path---servers can choose to use SSE for streaming responses when needed

💯 4. 使用例子

4.1 无状态服务

一个仅提供LLM工具且不使用其他功能的服务可以按如下方式实现：

始终确认初始化（但无需持久化任何状态）
对任何传入的ToolListRequest返回一个JSON-RPC响应
处理任何CallToolRequest，通过执行工具，等待其完成，然后发送一个CallToolResponse作为HTTP响应体

4.2 无状态服务与流式传输

一个完全无状态的、不支持长连接的服务器仍然可以利用流式传输。例如，在工具调用期间发出进度通知：

例如，在工具调用期间发出进度通知：

当传入的POST请求是CallToolRequest时，服务指示响应将是SSE
服务开始执行工具
在工具执行期间，服务通过SSE发送任意数量的ProgressNotifications
当工具执行完成时，服务通过SSE发送CallToolResponse
服务关闭SSE流

4.3 有状态服务

MCP服务需要生成一个会话ID（Mcp-Session-Id），而客户端需要在每次请求时传递该ID。然后，服务器可以使用会话ID进行路由匹配或在消息总线上进行路由消息------也就是说，一个POST消息可以到达水平扩展部署中的任何服务节点，但必须通过像Redis这样的代理进行路由。

📖 5. 总结

对开发者而言，这一更新带来诸多便利：

实现MCP服务器变得更加简单，只需普通HTTP服务器即可支持MCP，无需再搭建专门的SSE服务器;
部署到Vercel、Cloudflare、AWS Lambda等不支持长连接的云平台变得更加容易
兼容性大幅提升，新方案作为标准HTTP可与CDN、API网关、负载均衡无缝集成
扩展性显著增强，支持无状态模式运行，且可在需要时动态升级到SSE

在基础设施和服务器架构方面，新方案同样带来了革命性变化

无状态服务器成为可能，服务器不再需要持续存储客户端会话信息
更适合微服务架构，可轻松与REST API、GraphQL、负载均衡、CDN等系统集成
服务器资源利用率更高，处理完请求后即可释放资源，适合高并发场景

总体而言，此次更新使

MCP变得更加轻量级且灵活，服务器可自主决定是否支持流式传输
部署流程显著简化，适用于Serverless架构
兼容性大幅提升，可与各种网络基础设施无缝协作
服务器资源利用率更高，支持更大规模的并发请求

这一创新性变更使MCP服务器变得更简单、更高效、更灵活，能够支持更大规模的分布式部署，彻底摆脱了SSE的限制，为AI模型与应用间的通信开辟了新篇章。