MCP 协议将在 7 月 28 日转向无状态核心，sessions 和 initialize 会从核心流程中移除。但这不等于所有 MCP 项目都要连夜迁移：GitHub 已明确，一级 SDK 已保留向后兼容。真正要排查的是自建客户端或服务端里，是否把协议会话当成了业务状态、鉴权状态或路由状态。本文给出三类判断和一份最小回归清单。

如果你今天看到“7 月 28 日 MCP 要变无状态”，第一反应是去改 Redis、补 Session、给反向代理加粘性会话，先停一下。

这次变化的重点，不是让所有人紧急重写 MCP；而是把协议核心从“先建会话、再持续交互”，改成“每次请求都能独立处理”。

GitHub 在 7 月 23 日的公告里同时说明：一级 SDK 已保留向后兼容，并且已经发布 beta 支持。对只使用标准客户端、标准 SDK 或 GitHub MCP Server 的多数项目而言，通常不需要为了兼容性临时改造。

真正值得今天排查的，是：你是否自己实现过 MCP 客户端、服务端或中间层，并且把协议会话当成了业务依赖。

先把变化说清楚：少的是协议会话，不是业务状态

7 月 28 日后，MCP 核心走向无状态：sessions 和 initialize 都会从核心流程移除。这样做的直接好处是，请求更容易横向扩展，客户端也可以并行完成握手。

这里最容易误解的一点是：无状态协议，并不要求你的业务没有状态。

• 用户登录态、OAuth Token、任务进度、长任务结果，仍然可以存在；
• 只是不能再默认依赖“这一次请求一定会落到上一次那台机器、带着同一个协议 Session”；
• 需要长期保存的内容，应由业务自己的数据库、缓存、任务队列或显式标识来管理。

你属于哪一类？

第一类：只在用现成客户端、插件或一级 SDK

通常不用为兼容性改代码。

例如你只是把 MCP Server 配进编辑器、桌面客户端或已有框架；或者服务端直接使用一级 SDK，没有自己维护协议握手和 Session。

今天应该做的是：确认依赖版本、观察上游发布说明，并在测试环境跑一次工具发现和工具调用。

不要为了“无状态”凭空增加 Redis、Cookie 或粘性会话。它们不仅解决不了协议兼容问题，反而会给排障增加变量。

第二类：自建了客户端或服务端，但没有依赖协议会话

这类项目建议做一次升级和集成测试，但通常是低风险工作。

重点确认三件事：

1. SDK 是否已升级到支持新规范的版本；
2. 连续两次独立请求能否正常完成工具发现和工具调用；
3. 服务重启、实例扩缩容后，是否仍能正常鉴权和记录日志。

如果这些都通过，通常没有必要为了这次变化重构架构。

第三类：自建实现，并依赖 Session、initialize 或连接粘性

这一类才是需要认真排查的对象。常见信号包括：

• initialize 之后才创建用户上下文、权限上下文或临时资源；
• 将协议 Session ID 写入 Redis、数据库或进程内 Map；
• Nginx、网关或负载均衡依赖 sticky session 才能让后续调用成功；
• 多轮交互、URL 登录、回调确认等流程，默认依赖同一条连接或同一实例；
• 日志只能通过 Session ID 串起来，换实例就丢失关联。

这不表示项目必须推倒重来。更稳妥的做法是把“协议会话”与“业务状态”拆开：业务用自己的用户 ID、任务 ID、授权 ID 和 Trace ID 关联；协议层只负责当前请求的解析、鉴权和响应。

5 分钟先搜这几个词

在项目根目录执行：

rg -n "session|initialize|sticky|redis|Set-Cookie" .

搜到不代表一定有问题，但能快速定位是否存在以下耦合：

搜到的实现	要问的问题
Session ID	它只用于日志，还是承载用户、权限或任务状态？
initialize 回调	初始化失败后，后续请求是否还能独立完成？
Redis/内存 Map	存的是业务状态，还是协议层临时会话？
sticky session	去掉粘性路由后，工具调用是否会失败？
多轮回调	每轮请求能否靠显式 ID 找回正确上下文？

先把这些问题答清楚，再决定是否需要改代码，效率会比“看到协议更新就全局替换”高得多。

最小回归清单：不要只测一次成功

建议至少做下面 5 个测试：

1. **冷启动测试：**服务重启后，首次工具发现和调用是否正常。
2. **独立请求测试：**不复用旧连接，连续调用工具列表和一个真实工具。
3. **多实例测试：**让相邻请求落到不同实例，确认不会因连接粘性失败。
4. **授权测试：**重新授权、授权超时和登录回调能否正确关联到用户。
5. **可观测性测试：**日志里是否能用 request ID、Trace ID、任务 ID 还原完整调用，而不是只能找 Session ID。

特别是第 3 项。很多服务在单机调试时没有问题，一上负载均衡才暴露“状态藏在进程内”的问题。无状态切换的真正价值，也正是提前把这类隐性依赖找出来。

不要把公告读成“所有人必须迁移”

GitHub 的公告给出的边界很明确：一级 SDK 已保留向后兼容，GitHub MCP Server 已提前支持新规范。

对标准使用者，优先更新依赖并跑回归；对自建协议层的人，才需要检查 Session、握手、代理和多轮请求。

把协议升级当成一次依赖审计，而不是一次恐慌式重构，通常是成本最低、风险也最低的做法。

官方资料：GitHub MCP Server supports the next MCP specification。实际升级前仍以所用 SDK、客户端与服务端的发布说明为准。