MCP 最大更新落地：砍掉握手与会话，回归无状态 HTTP 时代
MCP 发布近两年后迎来官方口中“最大的一次更新”：移除初始化握手与会话粘滞，让每个请求独立携带完整上下文。远程 MCP 服务器从此可以像传统无状态 HTTP 服务一样部署和运维。但这意味着，跨会话的上下文管理将重新交给开发者。
MCP 折腾了近两年，终于迎来了官方口中“发布以来最大的一次更新”，只不过方向有点出人意料——重回上古 HTTP 时代。
这次更新动的是 MCP 的根基：砍掉初始化握手，废除会话粘滞，每个请求必须独立携带完整的上下文信息。这意味着，远程 MCP 服务器从此可以像传统的无状态 HTTP 服务那样进行操作，采用轮询调度即可，无需配置会话亲和性。但有开发者毫不客气地评价：MCP 好不容易从蹩脚的 SSE 迈向成熟的 WebSocket，结果又被刻舟求剑的程序员拽回了上古世界观。
新旧协议共存，注定不会太平。AgentStatus 创始人 Román Moskalenko 在推文中直言：
“看到 MCP 这次更新了吗？MCP 刚刚实现了无状态化，这是发布以来最大的一次变动。不再需要握手，不再需要粘性会话，每个请求都携带自己的上下文。现代协议和旧版协议共存的阶段会非常混乱，故障率可能比现在还要高——我们已经做好了准备。”
那么，砍掉会话和握手，到底是为了解决什么问题？为此又牺牲了什么？
MCP 带来的开销
Model Context Protocol（MCP）迎来自发布以来的最大一次更新。主要维护者于 5 月 21 日冻结了候选发布版本，并于 7 月 28 日发布了最终版的规范。
乍一看，这份更新日志的改动幅度相当大：会话和初始化握手将被移除，三个核心功能将被弃用。但仔细一看，这次修订实际上是将熟悉的工作交还给已经建立起来的专用基础设施，从而简化 MCP 本身。对于运维人员来说，这解决了一个长期存在的痛点：运行一个远程 MCP 服务器，本就不应该需要一个普通无状态服务不需要的专用复杂装置。
要理解这些特性移除，必须分析 MCP 的原始设计与其实际部署之间的差距。它最早也是最广为人知的形式是一款桌面应用程序，通过标准输入和输出与本地进程进行通信。在这种情况下，通过持久连接启动握手操作的成本很低。
随着越来越多的服务器转向远程、水平扩展的部署模式，这些会话便成了问题。服务器会生成一个 Mcp-Session-Id，将客户端与生成该标识的实例绑定在一起。为了实现水平扩展，这通常需要会话亲和性、可与外部共享的会话存储，或者具备 MCP 感知能力的网关逻辑（通过解析 JSON 正文来确定调用路由）。一个负责发布 MCP 服务器的团队，实际上是在为解决该协议所带来的分布式系统问题而付出代价。
能力协商带来了第二项开销。由于能力是在连接建立时一次性完成交换，所以列表结果可能会因连接而异，这使得跨会话或共享中间件的缓存变得难以推断。
维护者的优化目标
六项规范增强提案都围绕着一个共同的目标：让每个请求都能独立存在。现在，协议版本和客户端能力信息会在每次调用中通过 _meta 传递。客户端也应在其中包含身份信息，而且新的 server/discover 方法使得服务器能力既可以在初始阶段查询，也可以在需要时单独查询。该发布公告将此称之为“按需付费复杂度”的基本原则：核心保持精简，仅在功能真正需要时才引入有状态逻辑。
最直观的反对意见是，许多服务器确实需要记住某些信息。主要解决方案之一是显式句柄。这是过去二十年来所有基于 HTTP 构建的购物车所采用的模式：工具生成一个 basket_id，将其包含在返回结果中，而模型在下次调用时将其作为普通参数传递回去。账户状态、资源 URI、任务句柄以及普通数据库标识符，仍然可以用于所有不走该路径的场景。
该句柄不限于只是一种变通方法，因为它对模型是可见的。隐藏在传输元数据中的会话状态，模型永远无法推断出来，而工具结果中的句柄则可以在不同工具之间组合使用，并在工作流步骤之间传递。对应的权衡点在于，这类句柄同样会出现在提示词、对话记录和日志中，因此应将其绑定到经过身份验证的主体，并在每次使用时验证权限，绝不能直接将句柄本身视作授权凭证。
开发人员具体会得到什么
对于服务器开发者而言，远程 MCP 服务器现在可以像传统的无状态 HTTP 服务那样进行操作了。采用轮询调度机制的三个副本，无需亲和性配置，也无需运行或恢复协议会话存储。滚动部署不会再导致会话失效，也不会使客户端滞留在已被移除的实例上，尽管它仍然可能中断正在处理的请求和订阅流；由于不再支持可恢复性，客户端会使用新的请求 ID 重新发送这些请求。
对于平台团队而言，所需的 Mcp-Method 标头，加上针对命名工具、资源和提示操作的 Mcp-Name 标头，意味着网关无需检查请求正文即可按操作进行速率限制或授权。这仅在传输验证规则下成立，后端会拒绝任何与正文不符的标头，并且执行策略的中间节点会拒绝无法保证该检查的协议版本。若忽略这一限制，一个看似无害的标头就可能掩盖其下实际执行的另一项调用。
关键要点
- MCP 最大一次更新核心是无状态化：移除初始化握手与会话粘滞，每个请求自带完整上下文，远程服务器可按普通 HTTP 服务运维。
- 会话状态不会消失，只是从传输层移到了应用层：通过显式句柄（如
basket_id）在请求间传递上下文，模型可见、可组合，但需注意权限校验。 - 平台团队获得更简单的网关控制：
Mcp-Method与Mcp-Name标头允许按操作限流/授权，但前提是后端必须严格校验标头与请求体的一致性。 - 新旧协议共存期会有阵痛：故障率可能短期上升，客户端需处理请求重发，服务器需明确升级策略。
- 对 AI 编程工具链而言，MCP 无状态化意味着远程工具服务的接入门槛更低，也更贴近现代云原生基础设施的运维习惯。
本文是 MCP 协议重大更新解读的第二部分。前文讨论了核心传输层向 HTTP 的迁移，这一部分我们聚焦配套的机制变化：缓存语义、扩展机制、弃用策略，以及这些改动对开发者的实际影响。总的来说，这是一次"协议瘦身"，把状态管理从协议层剥离出去，同时用更规范的扩展和弃用流程来保障生态的平稳演进。
缓存语义：把 HTTP 的成熟经验搬进来
缓存变更值得更多关注。按新草案，受影响的列表和读取结果必须携带 ttlMs（有效期时长，毫秒）和 cacheScope（缓存作用域）两个字段，参考的就是 HTTP 的 Cache-Control 规范。客户端拿到这些信息后，可以在指定时间间隔内直接复用目录结果，无需反复请求服务器。
这里有一个关键细节：草案把 ttlMs 定位为"新鲜度提示"（freshness hint），而不是对数据仍然有效的硬承诺。换句话说，缓存可能在到期前就被上层业务逻辑主动失效，客户端不能把它当成数据未变的保证。
此外，草案还要求服务器按确定性顺序返回条目。之所以强调顺序，是因为稳定的返回顺序能显著提高提示词缓存的命中率。在大规模场景下，这意味着更低的响应延迟；如果云厂商按提示词缓存计费，也能帮开发者省下可观的 Token 成本。
但有一点要拎清楚：无状态带来的是可路由性，而非确定性。两个服务器副本在协议层面不保留会话状态，因此能接受完全相同的请求；但如果它们各自运行在不同版本、或读取了不一致的下游数据，返回的响应仍然可能是不同的。无状态解决的是一致性架构的基础问题，而不是数据一致性本身。
扩展机制：把功能移出核心
这次的生态变化比任何一个单一功能都更有说服力。扩展机制引入了命名空间标识符：官方扩展统一放在 io.modelcontextprotocol 命名空间下，第三方扩展则使用作者反向域名（如 com.example.packagename）。每个扩展都有独立的 ext- 存储库和发布周期。写过 Kubernetes 自定义资源定义（CRD）的开发者，很容易认出这套模式——功能在核心发布流程之外演进成熟，再按需被吸纳回核心。
任务是扩展机制价值的最佳案例。该功能于 2025 年 11 月 25 日作为实验性核心功能发布，但在真实的生产环境中暴露了设计问题，最终被重设计为一项扩展。将其移出核心是一次破坏性规范变更，但下一次迭代就不再是了：扩展通过功能标志或设置层面的版本控制来演进，只有在无法避免破坏性变更时，才会引入新的标识符。而 MCP 应用层（现在以扩展形式提供）也终于纳入了一个正式的管理协商框架，而不是此前并不存在的临时流程。
弃用策略：给开发者一张安全网
新的特性生命周期策略为每项特性划定了三种状态：活跃（Active）、已弃用（Deprecated） 和 已移除（Removed）。核心承诺是：从该功能首次被标记为"已弃用"的规范修订版本起，至少保留 十二个月 的过渡期。
只有一种情况可以缩短这个期限：存在已发布的安全公告，或有记录在案的活跃利用行为。即便如此，90 天 仍是不可突破的最低时限。公共注册表会列出所有即将淘汰的特性及具体时间线。
另一个值得注意的约束是：在对应的测试用例被纳入符合性测试套件之前，任何标准跟踪提案都无法达到"最终版"状态。换句话说，一个特性说"已废弃"之前，必须有可执行的标准来验证新老实现的兼容行为。
对普通开发者来说，这些约束可能只是"例行公事"。但对那些需要向平台评审委员会证明 MCP 集成合理性的团队来说，一份书面弃用保证比这个版本里的任何单一功能都更有分量——它意味着你不会在某个早晨醒来后发现依赖的接口悄悄消失了。
代价：这些变化不是免费的
任何基于实验性 Tasks API 构建的系统，都必须迁移到新生命周期。凡是通过独立请求向客户端要数据的服务器，也都要转为多轮请求模式：服务器返回它仍然需要的内容，客户端依据这些响应自行重试或补全，而不是一次请求就把事情做完。
服务器还必须验证任何可能影响授权或业务逻辑的 requestState 回显字段，并且一次性工作流仍然需要独立的幂等重放跟踪机制。
采样机制是典型的"结构变化大于表面变化"案例。此前采用客户端中介式采样的服务器，不需要持有模型提供商的凭证，通常也不承担模型账单。迁移到直接调用提供商 API 的模式后，服务器摇身一变成了凭证持有者、账单方，甚至用户数据的独立处理者。这三者背后的合规责任差异，远比迁移本身的工作量大。
日志记录面临同样的问题。stderr 和 OpenTelemetry 能解决运维人员的可观测性问题，但对远程客户端来说，它们无法替代旧版提供的结构化日志流。协议层不再管理应用状态，但句柄、购物车、任务记录和幂等性密钥依然需要存放的地方——状态不会消失，只是换了主人。
未来展望：稳妥的演进节奏
在协议推出不到两年就移除一项基础抽象，称得上一次深思熟虑的冒险。维护者们为此设置了 十周验证期，并同步提供了 Python、TypeScript、Go 和 C# 四个语言的测试版 SDK，为生态预留了充分的技术评估窗口。
迁移路径也已经定义：客户端先通过 server/discover 探测，遇到仅支持旧协议的服务器时，回退到 initialize 完成握手。这是一次协议层的破坏性变更，但配套了可协商的过渡路径，而非整个生态在某个指定日期同步强制切换。这种"能协商就不强切"的思路，是这次更新在治理层面最值得借鉴的地方。
对开发者而言，发布候选窗口（RC）是梳理会话依赖、跑迁移测试的最佳时机；待方案正式批准、SDK 稳定后，再安排生产环境部署。
最终，从独立服务器开发者到平台团队，再到围绕 MCP 构建网关和注册中心的提供商，获得的是一个可以自然兼容行业主流运维体系的协议底层——HTTP 的路由、缓存、鉴权、可观测性设施，全部都能直接复用。这才是这次更新更深层的价值：它让 MCP 不再是一个自成一体的野协议，而是长在了基础设施行业的既有土壤上。