MCP 2026-07-28 转向无状态：GitHub Server 提前适配了什么

GitHub 在 2026 年 7 月 23 日宣布，GitHub MCP Server 已提前支持即将发布的 MCP 2026-07-28 规范。GitHub Changelog当时使用的是“提前支持”表述；到 7 月 28 日，MCP 官方仓库已将该版本标记为稳定发布，而不是候选版。

这次变化的重要性不在于新增一个工具，而在于 MCP 的协议核心从“先建立并维护会话”转向“每个请求自带完成处理所需的协议上下文”。对构建 Agent 工具连接的团队来说，它会改变服务器扩缩容、代理层观测、旧客户端兼容和协议验收的方式。

无状态移除的是协议会话，不是业务状态

上一版 MCP 需要客户端先发送 initialize，服务器返回能力后再进入 initialized 状态；HTTP 连接还可能使用 Mcp-Session-Id 维持协议会话。新版移除了这套握手和协议级 session，让每个请求通过 _meta 携带协议版本、客户端信息与能力。

MCP 官方技术说明特别区分了协议状态与应用状态：无状态核心不代表购物车、浏览器实例或长任务进度必须消失。应用仍可把 basket_id、browser_id 等显式句柄作为普通工具参数传递。变化在于，这些状态不再暗藏在 MCP 连接生命周期里，而需要成为可见、可管理的业务契约。

这对部署的直接好处是，请求不必固定回到保存某个 MCP 会话的实例。服务可以更自然地横向扩容，故障实例也不会因为丢失协议会话而让后续请求失去上下文。但如果工具本身依赖数据库事务、浏览器进程或异步任务，团队仍要自行设计状态存储、授权、过期和恢复机制。

initialize 消失后，发现与上下文转到每次请求

新版用 server/discover 让客户端预先查询服务器支持的协议版本与能力，并把旧的服务器主动请求重构为 Multi Round-Trip Requests（MRTR）：服务器返回“需要输入”的结果，客户端补齐响应后重试原调用。官方还把部分能力移出核心，转入扩展或新的交互机制，使核心协议更小。

这不是简单删掉一次网络往返。它把“这个请求来自谁、按哪个版本解释、允许哪些能力”放回请求本身，也要求网关、日志和安全检查能够理解新的头部与元数据。2026-07-28 变更说明因此值得作为迁移清单，而不是只改一个版本字符串。

GitHub MCP Server 的三项工程变化

GitHub 公布的实现提供了一个大规模服务样本。

第一，服务移除了用于保存 MCP session 的 Redis 写入，以及每次调用前读取 session 的数据库操作。第二，新规范把 Mcp-Method、Mcp-Name 和 Mcp-Protocol-Version 等关键字段映射到 HTTP 头部，GitHub 的日志与 secret scanning 可以读取这些受规范约束的字段，不再为了识别请求而深度解析消息体。第三，GitHub 升级了 elicitation 处理，并通过官方 Go SDK 的兼容层同时支持新旧交互方式。

这些是 GitHub 对自身 MCP Server 的实现陈述，不等于所有服务器都会得到相同的性能、成本或安全收益。是否减少存储访问、代理层能否利用头部、旧认证链路是否受影响，都取决于各自架构。

兼容性来自版本协商，不是“升级后自动无感”

官方 Go SDK v1.7.0已经完整支持 2026-07-28，并说明了兼容策略：Streamable HTTP 只有在 Stateless=true 时才接受新版协议；如果服务器继续维持有状态 session，客户端会协商降到 2025-11-25。客户端优先协商双方共同支持的最高版本，server/discover 失败时也可回退到旧 initialize。

这说明官方 SDK 提供了迁移缓冲，但不能推出所有第三方客户端、服务器、网关和插件都已经适配。团队至少应验证四件事：双方实际协商到的版本、旧端点是否仍可用、业务状态是否已从隐式 session 中拆出，以及日志、鉴权和限流是否正确处理新头部。不能只看“连接成功”，还要检查实际走的是新版还是降级路径。

Conformance tests 把协议兼容变成可重复门禁

MCP 的官方 conformance framework可以用测试客户端连接待测服务器，或启动测试服务器驱动待测客户端，记录交互并生成 checks.json、标准输出和错误输出。它还支持已知失败基线：新失败会让 CI 失败，已经修复但仍留在基线中的旧失败同样会触发清理提醒。

对 Agent 工具链来说，这比“手工调用一次成功”更有价值。团队可在 SDK 升级、网关调整或服务器发布前重复验证协议行为，并把已知缺口显式记录。不过，本稿没有运行 GitHub MCP Server 或其他实现的 conformance suite，也不能据官方仓库的存在推断某个第三方实现已经合规。

本站判断是，无状态核心让 MCP 更接近可横向扩展、可被基础设施识别的 Web 协议；真正决定迁移是否稳妥的，仍是显式状态设计、双版本协商和可重复的一致性测试。先在测试环境记录新旧客户端的实际协商结果，再把 conformance 纳入 CI，比直接关闭旧版本支持更可靠。