如果你自建过远程 MCP server，大概率踩过这个坑：协议假设有状态 session，于是 server 没法摆在普通负载均衡器后面水平扩展，要么上粘性 session，要么把状态外置到 Redis，怎么做都别扭。
这个 MCP 部署最大的运维痛点，要在 7 月底被正式解决。MCP 2026-07-28 版本的 RC 已经发布，现在正处于 10 周验证窗口期，而且这是一个含 breaking changes 的大版本。
这个版本改了什么
核心变化一句话：协议层无状态化，由 6 个 SEP 协同实现。配套的还有 Extensions 框架、Tasks、MCP Apps、authorization 加固和正式的弃用政策。
对工程师来说，落到实处的是这几条：
| 变化 | 工程含义 |
|---|---|
| 协议无状态化 | 远程 server 可跑在普通 round-robin 负载均衡器后，不再需要粘性 session |
Mcp-Method / Mcp-Name HTTP 头 | 网关可以按方法/名称做路由，不用解包 JSON body |
tools/list 可缓存 | server 声明 ttlMs + cacheScope，客户端按策略缓存工具列表 |
| W3C Trace Context | 标准化链路追踪传播，MCP 调用终于能接进现有可观测体系 |
每一条都在把 MCP server 往"普通 HTTP 服务"的方向推。这是协议成熟的标志：基础设施层面的特殊性越少，能复用的现成运维设施就越多。
现行版本 vs 新版本：架构对比
现行（2025-11-25 规范）：客户端和 server 建立 session，后续请求依赖 session 内的状态。部署远程 server 时，要么单实例硬扛，要么负载均衡器配 sticky session，扩容缩容都要小心翼翼。
新版（2026-07-28）：每个请求自带完整路由信息（HTTP 头），server 端不持有跨请求状态。N 个实例摆在 LB 后面随便扩，挂一个实例不影响在途会话。
旧: Client ──(session绑定)──> LB(sticky) ──> Server-1 (有状态)
新: Client ──(Mcp-Method头)──> LB(round-robin) ──> Server-1/2/3 (无状态)
tools/list 缓存是另一个被低估的改进。现在每个客户端连上来都要全量拉一次工具列表，工具多的 server 这是实打实的延迟和流量。声明 ttlMs 之后，客户端可以本地缓存，对工具列表稳定的 server（绝大多数）几乎是免费的性能提升。
现在该做什么
10 周验证窗口是给 SDK 维护者和客户端实现者的，Tier 1 SDK 预期在窗口内完成支持。对不同角色的建议：
- 自建 MCP server 的团队：现在就去读 RC 公告，对照 breaking changes 清单评估迁移量。7 月 28 日正式版发布后，主流客户端会逐步切换，拖到那时候再动就是被动迁移
- 重度 MCP 用户：关注你依赖的 server 是否跟进。正式弃用政策的出台意味着旧版本的兼容窗口从此有了明确期限
- 正在选型 Agent 基础设施的：把"是否支持无状态 MCP"加进评估项。能水平扩展的 MCP 网关和不能的，半年后运维成本不是一个量级
我的判断：这是 MCP 从"Anthropic 的协议"走向"行业基础设施"的关键一版。无状态化、标准追踪、缓存策略，这些都不性感，但 LSP 当年也是靠这种不性感的工程细节赢的。
参考来源：MCP 官方 RC 公告 / MCP 2026 路线图