MCP 变成无状态了：粘性会话和共享 session 存储可以撤了
数据截至 2026-07，价格与限额以各官网为准。
2026-07-28 发布的 MCP 新规范，把协议内核改成了无状态——这意味着你为远程 MCP server 搭的那一整套粘性会话、共享 session 存储、网关侧深度包检测，在新版本上可以拆掉，server 直接放在普通轮询负载均衡后面就能跑，按 Mcp-Method 头路由即可。这是官方自己都称为”自协议发布以来最大的一次修订”的改动，代价是新旧版本可能互相不兼容。
先承认一个很容易产生的误解：“无状态”不等于”MCP 以后不能有状态了”。改的是协议层——协议不再要求会话追踪，不再强制每个请求必须落回同一个连接上下文。你的应用层想维护用户偏好、想在数据库里存对话历史、想让某个工具有记忆，这些都还是你自己的事，一点没被限制。混淆这两层，会让人得出”我的业务逻辑要重写”的错误结论，实际上要动的主要是部署架构那一层。
如果你还不清楚 MCP 是干什么的，可以先看 MCP 是什么？为什么说它是 AI 的 USB 接口 打个底，这篇默认你已经在跑 MCP server 了。
新规范一共动了哪几块
按官方博客的说法，这一版覆盖五个方向：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，外加一套正式的弃用策略。前面还发过 release candidate，所以并不是毫无预警地砸下来。
其中影响面最广的就是无状态化，它由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同实现，兑现的是此前 “The Future of MCP Transports” 里定下的计划。也就是说，这不是临时起意的调整，而是传输层路线图落地的那一步。
无状态到底省掉了什么
以前部署一个远程 MCP server，架构上最烦的就是会话粘性。协议要求会话追踪，于是你必须保证同一个客户端的后续请求还能回到同一个进程，或者至少能读到同一份会话状态。为此常见的做法无非三种：
- 在负载均衡上开粘性会话，用 cookie 或者源 IP 做哈希，把同一个客户端钉死在一台后端上；
- 搭共享 session 存储，通常是一套 Redis，所有实例都往里读写会话，代价是多一个有状态组件、多一条故障链路；
- 让网关做深度包检测，解析 MCP 消息体，从里面认出会话标识再决定路由，代价是网关得懂协议、协议一变网关就得跟着改。
新规范之后这三样都不是必需品了。协议层不再要求会话追踪，请求可以按 Mcp-Method 头路由，普通的轮询负载均衡就能满足。对运维的实际含义是：
- 后端实例变成真正的无状态副本，随便扩缩容、随便滚动重启，不用担心”这台一挂，挂在它上面的会话全断”；
- Redis 这类专门为 session 而引入的组件，如果没有别的用途，可以从架构图上划掉；
- 网关回到只做转发和鉴权的角色，不需要理解 MCP 消息体内部结构。
这一段是最值得先动手的部分——收益明确、改动集中在基础设施侧，而不是散落在业务代码里。
Tasks 被移出核心，改成 extension
另一个结构性变化：用于长时间运行操作的 Tasks 特性，已经从核心协议移到 extension。新规范同时引入了 Extensions 框架，允许用户自建 extension，与官方认可的 extension 并存。
这个设计取向是把核心协议做薄。好处是核心实现更容易做对、更容易做完整；代价是”某个能力到底有没有”变成了一个需要协商的问题——你不能再假定对端一定支持 Tasks。如果你的 server 依赖长任务语义，迁移时要专门确认：客户端侧走的是哪个 extension、版本对不对得上、不支持时的降级路径是什么。这类问题在本地 stdio 场景里不明显，一旦上了远程多客户端，就是实打实的兼容性坑。
授权那边也加固了
授权部分同样由 6 个 SEP 推动，方向是让授权规范更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署，而不是停留在协议文档里的理想模型。
一个具体的点：SEP-2468 要求客户端按 RFC 9207 校验 iss 参数。这条对客户端实现方是硬要求——如果你自己写了 MCP 客户端，授权回调那一段需要补上签发方校验，不能只看 code 和 state 就放行。对只写 server 的人来说，影响相对小一些，但你对接的客户端如果开始严格校验，你的授权服务器返回的字段就必须规矩。
其余细节以官方规范文档当前版本为准，授权这块条款多，凭记忆写代码很容易漏项。
最该重视的是：新旧可能互不兼容
维护者 David Soria Parra 把这次改动称为自加入授权以来最实质的变更，原话是：“A lot of things that made MCP are gone.”（很多让 MCP 成为 MCP 的东西已经没了。）
这句话不是修辞。实际后果是：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然。所以升级不是改个依赖版本号那么简单，得当成一次带兼容窗口的迁移来做。
好消息是官方这次配了正式的弃用策略：弃用机制给旧版本 12 个月窗口。这个窗口足够做分阶段迁移，但也别把它当成”一年后再说”的理由——真实项目里，客户端往往不在你手上，你能控制的只有自己这一端。
给几条务实的做法：
- 先盘点你这一侧到底是 server 还是 client，或者两边都是。两边都有的话，先升 server、后升 client，因为 server 通常你自己能控。
- 新旧并存跑一段，用不同的端点或不同的部署分别承载新旧协议版本，而不是原地替换。等观察期过了再收掉旧的。
- 把兼容性问题的表现记下来。协议版本不匹配报出来的错，未必长得像”版本不对”，可能就是一个莫名其妙的连接失败。排查思路可以参考 Claude Code 的 MCP 连不上、配置不生效怎么排查 里那套从配置到路径的分层定位法，只是这次要在最上面加一层”协议版本对不对”。
- 别急着把粘性会话配置删干净。先确认新架构在生产流量下稳定，再回收旧配置——回滚路径留着，比省那点配置行数重要。
顺带值得知道的两件事
官方注册表。 registry.modelcontextprotocol.io 是官方 MCP Registry，提供 server 发现、文档和 API 参考，由 modelcontextprotocol 这个 GitHub 组织维护，社区驱动。路线图上还有 MCP Server Cards——一个通过 .well-known URL 暴露 server 元数据的标准，目的是让注册表和爬虫不用真的连上 server 就能发现它的能力。对做工具分发的人来说，这条值得盯着。
治理背景。 2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会下的 Agentic AI Foundation，让它成为厂商中立、社区治理的标准。OpenAI、Google、Microsoft、AWS 都已经把它接进各自的 agent 栈。按官方与行业公开资料的口径，目前有超过一万个公开 MCP server 在生产中运行，SDK 月下载量超过九千七百万——这类数字是汇总口径，看趋势就好，别当成精确统计往方案里抄。
需要提醒的是，上面这些厂商的服务本身在中国大陆的可用性是另一回事：这几家官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外，具体以各自官网的地区政策页为准。本文不提供也不背书任何第三方中转渠道。MCP 协议本身是开放规范，你完全可以在自己的基础设施上实现它，这跟能不能用某家的模型服务是两个独立问题。
查资料时的一个坑
这次改动时效性太强，中文资料几乎为零，英文二手资料也大量过期。已经能看到有站点仍然把 2025-11-25 那一版列为”当前稳定版”，并说下一版”暂定 2026 年 6 月”——这个说法已经过期了，别照着它做技术决策。
判断信源新旧有个简单办法：看它有没有提到无状态内核和 Extensions 框架。没提的，基本就是新规范之前的内容。一切以官方博客与规范文档的当前版本为准，尤其是 SEP 编号、字段名、头名称这些细节，凭印象写十有八九要返工。配置层面的基础操作变化不大，可以继续参考 Claude Code / Cursor 通用 MCP 配置教程，但涉及远程部署和授权的部分，要以新规范为准重新核一遍。
诚实说局限
这篇能给的是方向和取舍逻辑，不是逐条的迁移清单。几处必须承认的边界：
- 具体的 SEP 内容我没有逐条展开，只点了与客户端实现直接相关的 SEP-2468。其余 SEP 的字段级细节请查规范原文。
- 迁移的工作量因项目而异。如果你只跑本地 stdio server，这次改动对你几乎无感；如果你运营着多租户的远程 server，工作量不小。
- 生态数字和兼容性表现都会变。十二个月的窗口期里，各家 SDK 和客户端的支持进度会陆续跟上，今天不兼容的组合，过几个月可能就好了。
小结
MCP 协议层在 2026-07-28 之后变成无状态，粘性会话、共享 session 存储、网关深度包检测这三样为会话追踪而生的基础设施可以退场，普通轮询负载均衡加 Mcp-Method 头路由就够。Tasks 移出核心变成 extension，能力协商从此不能靠假定。授权侧的 SEP-2468 要求客户端按 RFC 9207 校验 iss，写客户端的要补上。新旧版本可能互不兼容，官方给了 12 个月弃用窗口，用分阶段并存的方式迁移最稳。最后记住”无状态”只针对协议层，你的应用状态该怎么存还怎么存——所有细节以官方博客与规范文档的当前版本为准。