如果你或你的团队正在跑 MCP Server，或者正准备把 MCP 接进生产环境，7 月 28 日那条消息你可能错过了，也可能误读了。那天 MCP 发布了第五版规范，官方一句话定调：这是自协议发布以来最大的一次修订。哔哩哔哩改动的力度，看被删掉的东西就知道：官方明确，MCP 不再依赖 Session。知乎initialize 握手、Mcp-Session-Id 会话头、保活的 ping，全没了。哔哩哔哩也就是说，「会话」这个概念，从 MCP 的协议层被拿掉了。
社区很快分成两派。恐慌派的口号很唬人：全球一万多个已上线的 MCP 服务，要么重写，要么被淘汰。哔哩哔哩
观望派的反问也很实在：光 TypeScript 旧版 SDK 一周下载就超四千万的协议，把协议层的会话删了，你慌不慌？哔哩哔哩
我把官方博客、SEP 提案、SDK 迁移指南和社区一手反馈都翻了一遍，结论有点不一样：九成的 MCP 服务其实不用动；但剩下那一成，问题不是「要不要迁」，而是「多快能迁」。
到底改了什么：不是加功能，是换底座
这次改版不是小打小闹：官方一口气发了六个提案，五条是破坏性变更。哔哩哔哩规范本身的变化，可以压缩成六条：
无状态化。 握手和会话头被移除，每个请求自带身份和协议版本，客户端不再需要和某一个服务器实例「保持联系」。最直接的好处：任何请求可以打到任何实例，最朴素的轮询负载均衡就够用，AWS Lambda、Cloudflare Workers 这类无服务器环境第一次能原生跑 MCP。
MRTR（多轮往返请求）。 以前服务器执行工具中途要问用户，得维持长连接等着；现在返回一个「需要输入」的结果，客户端收集完输入再发一个新请求回来，全程不用挂任何连接。
授权重写。 对齐 OAuth 2.1，弃用动态客户端注册（DCR），换成 CIMD。
路由头 + 缓存。 网关不用解析请求体就能知道这个请求调的是哪个方法、哪个工具；JSON 响应可以用 ttlMs 和 cacheScope 两个字段显式缓存。
Tasks 正式走出实验，进入扩展框架；还有 MCP Apps——服务器可以返回交互界面。
弃用清单。 Roots、Sampling、Logging 三项弃用，但至少保留 12 个月缓冲。
规范、SDK、生态是这次一起动的：MCP 2026-07-28 规格发布的同时，TypeScript、Python、Go、C# 四个 SDK 同步更新。知乎TypeScript 和 Python 两个 SDK 各自累计下载已超过十亿次。哔哩哔哩发布当天 Claude 全线产品支持，AWS、Cloudflare、微软、Google、Figma 全部首日落地。
为什么要无状态：不是倒退，是协议长大了
看到「删 Session」，有人第一反应是：这不是开倒车吗？
看看历史。HTTP 天生无状态，整个现代 Web 基建——负载均衡、缓存、CDN、网关、水平扩展——恰恰是建立在这种无状态之上。MCP 头一年半走的是反方向：有状态长连接让实现门槛足够低，协议「对演示友好」，生态才爆起来，从 Anthropic 一家推，变成全行业跟的事实标准。
但有状态是「对演示友好」，无状态才是「对生产友好」。一个合格的 MCP 服务器，需要管理请求到粘性会话的路由、保持流开启、处理消息重放，比传统 Web 服务器多出一大堆开销和复杂度。知乎你想水平扩容，负载均衡器一放上去，第二个请求就找不到第一个请求的会话——「Server B 不认识 session 123」——只能上粘性路由或共享会话存储，基础设施复杂度直线上升。有状态假设撞上实例随时销毁的无服务器环境，更是直接的事故。
所以这次改版，官方把 MCP 的方向重新定了调：从「有状态、长连接的 Agent 协议」，转向无状态、可负载均衡、可缓存、可路由、可扩展的生产级基础设施。知乎落到部署上，MCP 服务器现在可以只跑在一个 Worker 上，不再需要任何有状态的基础设施，组件更少，运维更简单，成本也更低。知乎翻译成人话：从今往后，部署一个 MCP Server，就像写一个普通的 Web API。
新规范还要求 Streamable HTTP 请求携带 Mcp-Method、Mcp-Name 这类头，网关、限流器或 Web 应用防火墙现在可以直接根据头信息做决策，不用解析任意 JSON。知乎tools/list 这类目录接口的结果，也带上了 ttlMs 和 cacheScope 缓存提示。部署一个 MCP 服务，能直接复用现有 HTTP 生态的全部家当——这就是「换底座」的具体含义。
但要记住一句澄清：「无状态」不等于 MCP Server 不能保存状态。知乎以前状态藏在传输层的会话里，现在要求它变成显式句柄：由工具返回、客户端回传、应用层自己管理。协议层无状态不等于应用层无状态。知乎这是这次改版里最重要的设计思想变化。
自查：九成不用慌
社区流传最广的迁移指南给了一套十分钟自查法，判断你在九成不用动的那批，还是要动架构的少数派。哔哩哔哩翻译一下，再补上我的账：
这两类，不用动：
本地 stdio 工具（和 Claude Code、Cursor 一对一跑的那种）：Session 移除对你基本无感，等客户端和 SDK 升级完，跑一遍回归就行；
只读或轻状态的远程服务（暴露 tools/list、调了就返回结果的）：把官方 SDK 升级到对应新规范的版本即可，业务代码基本不用改。
这三类，本月就要开始迁：
依赖粘性路由、共享会话的服务。 你为了把同一个客户端钉在同一个实例上，搭过粘性会话、Redis 共享会话——这一层现在可以整个拿掉了。但「拿掉」本身就是一轮架构改造，还得在负载均衡下验证非粘性链路。
用了 Sampling、Roots 或推送式交互的服务。 这三项能力在弃用清单上，推送式交互在新规范下会直接硬失败——这不是警告，是故障。
把状态藏在会话里的服务。 比如「数据库连接建在会话里」「上一次工具调用的结果还在内存中」。新规范要求这些状态全部改成显式句柄。这是改动最大的一类，也是安全责任发生转移的一类：句柄到了模型手里，防伪造、防重放就是你的事了，不再是协议的事。
哪些标识符扛哪些状态，边界也要划清：协议核心变薄后，身份、业务对象、长任务、幂等对账、多轮交互和审计状态，必须分别拥有显式标识、所有者、生命周期、授权规则与恢复语义。知乎社区已经有人把地图画出来了：request ID 管单次请求幂等，operation_id 标记同一次业务副作用尝试，taskId 让异步任务可持久寻址，requestState 承载 MRTR 中途交互，subscription ID 承载订阅——各有各的生命周期，别混着用。
还有一个容易漏的隐藏项：授权。以前靠 DCR 动态注册的服务要切到 CIMD，社区已经有人踩坑——精确匹配逻辑下，有的授权服务器会直接拒登，先在测试环境量一遍。
避坑清单：先动手的人已经替你踩了四个坑
先动手的人已经替你把坑踩出来了：Lambda 二次调用就崩、MRTR 毁掉延迟统计、TS codemod 静默失效、CIMD 精确匹配拒登。哔哩哔哩展开说：
无服务器 + 旧协议 = 直接跑不通。 Lambda 二次调用崩溃是反馈最多的，本质是有状态假设撞上实例随时销毁的环境。
MRTR 会打乱延迟统计。 一次逻辑调用可能跨多个 HTTP 往返，监控还按老口径算 P99，数字会骗人。
TS codemod 会静默失败。 部分代码模式不会被改写，跑完之后编译照过、行为是错的，稳妥做法是手动 grep 一遍 Mcp-Session-Id 交叉核对。
CIMD 拒登。 客户端元数据的精确匹配问题，务必回归一遍令牌签发链路。
接下来怎么办
不用动的：把「12 个月弃用缓冲」记进你的技术雷达——Roots、Sampling、Logging 三项被弃用，但至少保留十二个月。哔哩哔哩下次升级 SDK 时，再核对一遍兼容矩阵。
要动的，建议按三步走：先用 Inspector 做只读预检，MCP 2026-07-28 已经把核心改成 stateless request/response，并提供 server/discover，先把协议层验活。知乎第二步把有状态逻辑迁到显式句柄；第三步在负载均衡下验证非粘性链路。如果第一步就不对，先修协议层，别拿业务调试去掩盖。
值得继续盯的信号：官方 SDK 版本号与兼容矩阵、客户端支持进度、认证服务器里有多少已经切到新规范——这是生态迁移速度的风向标。协议平时没人关心，它一开始被关心，就是生态重新洗牌的时候。这次 MCP 改版的真正意义，是 Agent 的工具层第一次完成了「HTTP 化」。对做架构的人来说，记住一句话就够：无状态不是没有状态，而是把状态从传输层搬进业务层。 谁先想明白这一点，下一轮扩容时就从容得多。
