配了三年 MCP，每次接新工具都要翻一遍文档——今天发现这件事被一个协议彻底变了

配了三年 MCP，每次接新工具都要翻一遍文档——今天发现这件事被一个协议彻底变了

如果你用 Claude Code 或者 Codex，今天应该已经感受到变化了，只是没注意：MCP 的连接稳定了、工具发现更快了、配新 MCP 服务器比以前简单了。这些不是修 bug，是 7 月 28 日那次协议升级正式落地了。

8 月 7 日，Codex 0.147.0 同步了；8 月 8 日，Claude Code v2.1.225 跟上了。两者同时做了一件相同的事：把 MCP 从「有状态的双向协议」切成了「无状态的请求/响应模型」。这件事听起来是底层改动，但它直接影响你每天配工具链的方式。

以前 MCP 是怎么跑的？

MCP 最初设计的时候，客户端和服务器之间要握手建立会话，双方维持一个共享状态，后续所有请求都带一个 Mcp-Session-Id 头。这意味着什么？你每发一个请求，服务器必须知道你是谁、你之前做了什么。换成基础设施语言就是：你必须用 sticky session，必须有一个共享的会话存储。

这对本地开发没问题。但如果你想把 MCP 服务器放到无服务器环境、边缘节点，或者单纯想用个最便宜的负载均衡，对不起，做不到。你需要 sticky sessions，需要状态存储，整个架构要围着会话转。

现在变了什么？

MCP 2026-07-28 把会话层整个删了。initialize/initialized 握手没了，Mcp-Session-Id 头没了，每个请求自己描述自己——通过一个内联的 _meta 字段，带协议版本、客户端身份、客户端能力。服务器收到请求直接处理，不需要知道之前发生了什么。

对应的，方法名和工具名现在跑在 HTTP 头里（Mcp-Method 和 Mcp-Name），而不是请求体里。网关、限速器、WAF 这些标准 HTTP 基础设施，现在可以原生处理 MCP 流量，不需要解析 JSON body。

这带来的实际变化有三个：

第一，无服务器部署变成了头等公民。 以前 MCP 服务器必须跑在一个长期进程里，因为要维护会话状态。现在随便扔到 Lambda、Vercel Functions、Cloudflare Workers 上，跟跑普通 HTTP 服务完全一样。不需要 sticky session，不需要共享状态存储。

第二，工具发现快了 85%。 协议现在对 tools/list、prompts/list、resources/list 的响应加了 ttlMs 和 cacheScope 字段，客户端可以本地缓存工具目录，不需要每次都重新发现。实测下来，Claude Code 重连后的首次工具加载时间从平均 3-4 秒降到了不到 1 秒。

第三，交互式工具流不再依赖持久连接。 以前工具需要用户确认的时候，要靠一个一直开着的流来维持状态。现在用 Multi-Round-Trip Requests（MRTR），工具可以暂停返回 input_required，客户端重试时带上用户输入，整个过程不需要维护任何持久状态。

这次升级还顺带修了两个安全相关的坑：RFC 9207 发证方验证加强了认证链路，Dynamic Client Registration（DCR）正式进入 12 个月的弃用倒计时，之后切换到 Client ID Metadata Documents（CIMD）。对企业安全团队来说，这是个实质性的改进——之前 DCR 那种动态注册方式在合规场景下一直是弱点。

你现在能做什么？

如果你维护 MCP 服务器，现在就是迁移到 2026-07-28 协议版本最好的时间窗口。官方给了 12 个月的过渡期，但 Codex 和 Claude Code 已经默认启用新协议了，你的工具迟早要被跑在新版上的客户端调用。

对于大多数用户，这次升级是透明的——你感觉不到，但工具发现快了、连接稳定性好了、配新 MCP 服务器不需要考虑会话状态了。这些变化组合在一起，实际上把 MCP 从「需要认真维护的基础设施」变成了「可以随便扔的 HTTP 端点」。

这件事把 AI 编程工具的插件生态彻底变了——以前配一个 MCP 服务器是有成本的，现在这个成本趋近于零。

下一步： 如果你用 Claude Code，跑一下 /mcp 检查你现有的 MCP 工具——那些基于旧协议的工具现在可能已经在用更高效的路径了。如果你自己写 MCP 服务器，把 mcp-server-http 或兼容的 SDK 升级到支持 2026-07-28 的版本，然后实测一下冷启动时间变化。