MCP 协议 2026-07-28 无状态架构升级，这件事把生产部署的坑全平了

MCP 协议 7 月 28 日那版更新，有个变化当时没引起太多注意，但对正在把 MCP 推到生产环境的人影响很大——无状态架构。

旧架构的坑

之前的 MCP 有状态设计是这样的：客户端先发一个 initialize 请求，服务器返回一个 Mcp-Session-Id，后续所有请求必须带着这个 ID 打到同一个服务器实例。

这在本地跑没问题。一旦你要水平扩展——加机器、配负载均衡——就必须用 sticky session，把同一个客户端的请求固定路由到同一个实例。同时还要搭一个共享 Session Store，所有实例都要能访问这个状态。

结果就是：明明是个协议层面的问题，却需要一堆基础设施来兜。

新架构怎么解决

新版 MCP 彻底移除了 Mcp-Session-Id，每个请求自带所有必要信息（版本、客户端信息都放到 _meta 字段里），任意服务器实例都能正确处理。负载均衡直接用 Round-robin，不需要 sticky session，不需要共享 Session Store。

这对部署的影响

如果你现在正在评估或已经在用 MCP，有几个具体的变化：

部署层面，Nginx/HAProxy 这类标准负载均衡器可以直接用，不需要插件或特殊配置。之前为 sticky session 配的规则全部可以删掉。

多实例部署的复杂度降了一个量级。原来需要 Session Store（Redis/Memcached）+ sticky 路由，现在这两层都不需要了。

但有一点要注意：无状态不等于应用无状态。如果你的 MCP Server 需要跨请求维护状态（比如用户会话上下文），现在需要自己在应用层实现，比如生成一个 handle_id 让模型在后续请求里传回来。这是显式状态 vs 协议隐式状态的区别，不是无状态 vs 有状态的区别。

值不值得升级

如果你现在还在 PoC 阶段，直接上新版本，没有历史包袱。

如果已经在跑有状态版本的生产环境，需要评估迁移成本——主要是客户端请求格式变化和 Session Store 的依赖移除。有正式弃用策略兜底，可以分步走，不用担心下次更新又 breaking。