MCP（Model Context Protocol）迎来了发布以来最大的一次更新，但方向出乎很多人意料：不是加新功能，而是砍功能——砍掉初始化握手、废除会话粘滞，让协议回到「无状态 HTTP」的原点。
有人调侃这是「刻舟求剑，重回上古时代」，有人却说这是 MCP 从原型走向生产的关键一跃。到底谁说得对？这背后其实藏着一个更本质的问题：AI Agent 协议在生产环境里，究竟该为谁优化？
一、破题：一场「减法」式的最大更新
2026 年 5 月 21 日，MCP 官方冻结了 2026-07-28 版本的候选发布（Release Candidate），并于 7 月 28 日正式发布最终规范。官方措辞罕见地直白：「这是协议发布以来最大的一次修订」。
修订的核心就一句话：MCP 在协议层实现了无状态化。
具体来说，三件大事同时发生：
- 初始化握手被移除（SEP-2575）：以前客户端要先发一条
initialize，和服务端交换协议版本、能力清单；现在这些信息不再连接时交换一次，而是跟随每一次请求的_meta字段走。 - 会话与 Mcp-Session-Id 头被移除（SEP-2567）：以前服务端返回一个会话 ID，客户端每个后续请求都必须携带，把客户端「钉死」在签发它的那个实例上；现在任何请求可以落在任何实例上。
- 新增
server/discover方法：客户端需要服务端能力时，随时可以单独查询，而不是只能在连接建立时一次性拿到。
一句话总结：以前是「先握手、建会话、再干活」，现在是「每个请求自带完整上下文，谁接都能干」。
但砍掉的东西，恰恰是很多人以为 MCP「就该有」的东西。为什么要自断一臂？
二、拆解：为什么必须砍掉会话
要理解这次修订，得回到 MCP 的原始设计假设。
MCP 最早、最广为人知的形态，是桌面应用通过标准输入输出与本地进程通信。本地进程场景下，持久连接 + 握手成本极低——反正就一个进程，不存在「请求落在哪个实例上」的问题。
但随着生态成熟，越来越多服务器转向远程、水平扩展的部署模式，会话就成了原罪，带来两笔沉重的税：
第一笔税：分布式系统的复杂度。服务器签发 Mcp-Session-Id 后，客户端被绑定到签发实例。要做到水平扩展，你就得配会话亲和性（sticky session）、搞可共享的会话存储，或者在网关上做「深度包检测」——解析 JSON 请求体来决定路由。一个本该是普通 HTTP 服务的 MCP 服务器，被迫背上了一套为分布式系统设计的专用复杂装置。负责部署的团队，实际上是在为协议自身造成的分布式问题买单。
第二笔税：能力协商杀死缓存。能力清单在连接建立时一次性交换，意味着列表结果因连接而异。跨会话或共享中间件的缓存变得难以推断——你没法确定「这份 tools/list 结果对下一个客户端还有效吗」。对依赖缓存降低延迟和 Token 成本的生产系统来说，这是致命的。
维护者的目标很清晰，六个规范增强提案（SEP）都指向同一个方向：让每个请求都能独立存在（standalone）。官方称之为「按需付费复杂度」原则：核心保持精简，仅在功能真正需要时才引入有状态逻辑。
三、建框架：无状态协议，有状态应用
最直观的反对意见是：很多服务器确实需要记住东西啊，购物车、任务状态、账号会话，无状态了怎么办？
答案是：协议不管理状态，不代表应用不能有状态。服务端需要跨调用携带状态时，走 HTTP 世界二十年来的成熟模式——显式句柄（explicit handle）：
工具生成一个 basket_id，放进返回结果里，模型在下一次调用时把它当作普通参数传回来。账户状态、资源 URI、任务句柄、数据库标识符，全部可以走这条路。
这不仅是替代方案，官方甚至认为它比会话更强：藏在传输元数据里的会话状态，模型永远无法推断；而工具结果里的句柄，模型可以跨工具组合、在工作流步骤之间传递、对它进行推理。句柄对模型是「可见的」，会话对模型是「黑盒」——这恰恰是 Agent 场景最需要的透明度。
代价也很明确：句柄会出现在提示词、对话记录和日志里，所以必须绑定经过认证的主体、每次使用都要校验权限，绝不能把句柄本身当作授权凭证。
四、推演：无状态化引发的连锁反应
这一刀砍下去，涟漪远不止「部署变简单」，整个生态的运营方式都在变：
1. 部署与网关：普通基础设施即可。远程 MCP 服务器现在可以像传统无状态 HTTP 服务一样，跑在普通轮询调度（round-robin）负载均衡后面，三个副本零配置。滚动部署不再导致会话失效。平台侧新增的 Mcp-Method 和 Mcp-Name 请求头，让网关不用解析请求体就能按操作做限流和授权——除非忽略传输校验规则，否则一个看似无害的标头背后，不可能藏着另一项调用。
2. 缓存：终于可推断、可计费。受影响的列表和读取结果必须携带 ttlMs 和 cacheScope（参考 HTTP Cache-Control 规范），客户端可以在指定时间间隔内保留目录、免于重新获取。规范还要求服务器按确定性顺序返回条目——这直接服务于提示词缓存命中率，大规模场景下意味着更低延迟、更低 Token 成本。
3. 生态分层：核心精简，扩展单飞。这次修订的另一半重量在「扩展」机制：官方扩展位于 io.modelcontextprotocol 命名空间，第三方扩展用作者的反向域名，各自拥有独立的存储库和发布周期。写过 Kubernetes 自定义资源的人一眼就能认出这种模式——功能在核心发布流程之外发育成熟。
典型案例是 Tasks：2025 年 11 月作为实验性核心功能发布，在生产环境暴露设计问题后，被重新设计成一项扩展。把它移出核心是一次破坏性变更，但下一次迭代就不是了——扩展通过功能标志或设置级版本控制演进，只有无法避免破坏性变更时才启用新标识符。核心从此可以轻装前进，复杂功能各自按节奏成熟。
4. 弃用策略：给生态一颗定心丸。新的特性生命周期策略为每项特性定义了「活跃 / 已弃用 / 已移除」三态：从首次标记弃用起至少保留 12 个月过渡期；只有活跃安全风险才能缩短，且 90 天是不可突破的底线。公共注册表公开列出即将淘汰的特性。对开发者这是例行公事，但对要向平台评审委员会证明 MCP 集成合理性的人来说，一份书面弃用保证比任何新特性都值钱。
当然，代价也是真实的：基于实验性 Tasks API 的系统必须迁移；独立请求模式的服务器要转为多轮次请求（MRTR）模式；采样机制的弃用最棘手——以前走客户端中介采样，服务器不需要提供商凭证、不背模型账单，直接调 API 后就成了凭证持有者和账单方。无状态化带来的是可路由性，而非确定性：两个副本接受相同请求，若跑着不同版本或读着不同下游数据，仍可能返回不同响应。
五、落到行动：现在该做什么
候选版已经冻结、最终规范已发布，十周验证期和 Python / TypeScript / Go / C# 测试版 SDK 都已就位。迁移路径也已经定义好：客户端先用 server/discover 探测，遇到只支持旧协议的服务器时回退到 initialize。这是协议层面的不兼容变更，但配套了可协商的过渡路径——不是让整个生态在指定日期强制切换。
三类人现在各有各的功课：
- 服务器开发者：把远程 MCP 服务器当作无状态 HTTP 服务来部署——轮询负载均衡、去掉会话存储、按
Mcp-Method头做网关策略。需要跨调用状态的，用显式句柄模式，并做好句柄的权限校验。 - 平台 / 运维团队：利用请求头做零解析限流与授权；为列表和读取结果补上
ttlMs/cacheScope；趁验证期梳理会话依赖、测试滚动部署，别等生产流量来了再手忙脚乱。 - 架构决策者：把这次修订当成评估 MCP 成熟度的信号——协议开始像 HTTP 一样「无聊」了，而这恰恰是它适合进入企业生产环境的标志。有书面弃用保证、有扩展演进机制、跑在通用基础设施上，正是平台评审委员会想听到的三个词。
回到开头的问题：MCP 为什么「倒退」回上古 HTTP 时代？答案藏在演进的方向里。一个为本地进程设计的协议，在远程、水平扩展、多租户的生产世界里，会话不是特性而是负债。砍掉它，不是刻舟求剑，而是让 MCP 终于长成了它本该长成的样子——像 HTTP 一样简单，像 HTTP 一样能规模化。
两年前 MCP 定义了「AI 如何连接工具」，这一次它定义了「AI 连接工具的基础设施该如何被运维」。前者决定了生态的上限，后者决定了生态能走多远。