MCP 最大更新：移除众多服务器围绕构建的机制

模型上下文协议（MCP）自发布以来最大的一次更新即将到来。主要维护者已于5月21日冻结了候选版本，最终规范定于7月28日发布。

乍看之下，变更日志颇为剧烈：会话和初始化握手将被移除，三项核心功能被弃用。但细看之下，此次修订实质上是将 MCP 简化，把熟悉的任务交回已有的基础设施处理。对运维人员而言，这解决了长期以来的痛点：运行远程 MCP 服务器不应需要普通无状态服务所不需要的专用机制。

MCP 对其用户征收的“税”

要理解这些移除，需审视 MCP 原始设计与实际部署之间的差距。其最早且最广为人知的形式是通过标准输入输出与本地进程通信的桌面应用，启动握手在持久连接上开销低廉。

随着更多服务器迁移到远程水平扩展部署，会话成为问题。服务器生成 Mcp-Session-Id，将客户端绑定到特定实例。扩展时通常需要会话亲和性、外部共享会话存储或解析 JSON 体以确定路由的 MCP 感知网关逻辑。一个团队运行 MCP 服务器，却要解决协议自身创造的分布式系统问题。

能力协商增加了第二重成本。能力仅在连接时交换一次，导致不同连接的结果可能不同，使得会话间缓存或共享中介难以处理。

维护者的优化目标

六项规范增强提案汇聚于一个目标：让每个请求独立。协议版本和客户端能力现通过 _meta 在每次调用中传递。客户端应在此包含其身份，新的 server/discover 方法使服务器能力可独立查询。发布文章将此称为“按需付费复杂度”原则：核心保持精简，状态仅当功能真正需要时才出现。

明显的异议是许多服务器确实需要记住事物。主要答案是显式句柄（handle），这是二十年来每个 HTTP 购物车使用的模式。工具创建 basket_id，返回结果，模型在下次调用中作为普通参数传回。账户状态、资源 URI、任务句柄和普通数据库标识符仍可用于不应走此路径的任何内容。

句柄不仅仅是权宜之计，因为它对模型可见。隐藏在传输元数据中的会话状态是模型无法推理的，而工具结果中的句柄可跨工具组合并在工作流步骤间传递。代价是它也会出现在提示、转录和日志中，因此应绑定到已验证主体并在每次使用时检查权限。

开发者实际获得的好处

对服务器作者而言，远程 MCP 服务器现在可以像传统无状态 HTTP 服务一样运行。三副本轮询，无需亲和性配置，无需运行或恢复协议会话存储。滚动部署不再使会话失效或让客户端滞留于移除的实例，但可能中断正在进行的请求和订阅流，由于恢复功能已移除，客户端以新请求 ID 重新发出。

对平台团队，必需的 Mcp-Method 头部加上 Mcp-Name 表示工具、资源或提示操作，使网关可按操作限流或授权，无需检查请求体。这仅在传输验证规则下成立，后端拒绝头部与体不一致的请求，策略强制中介拒绝不保证检查的协议版本。

缓存变更值得更多关注。受影响的列表和读取结果现在必须包含 ttlMs 和 cacheScope，模仿 HTTP Cache-Control，使客户端可以在声明的时间间隔内持有目录而不是重新获取。草案将 ttlMs 视为新鲜度提示而非数据仍然有效的承诺。服务器还要求以确定性顺序返回工具，草案表示这有助于提高提示缓存命中率，在大量使用时可能降低延迟或代币成本。

一个警告属于此处而非脚注：协议层的无状态买来的是可路由性而非确定性。两个副本接受相同请求而无需协商协议状态，但如果它们运行不同版本或读取不同下游数据，仍会返回不同答案。

为何关心扩展

生态系统的论证强于任何单个功能。扩展现在获得命名空间标识符：官方扩展前缀 io.modelcontextprotocol，第三方扩展使用作者拥有的反向域名，外加独立的 ext- 仓库和发布节奏。任何编写过 Kubernetes 自定义资源定义的人都会认出这种模式：一个功能在核心发布周期之外孵化并成熟。

Tasks 是这一点的证明。它作为实验性核心功能于 2025-11-25 发布，实际生产使用暴露了设计问题，现已被重新设计为扩展。将其移出核心本身是一次破坏性规范变更，但下一次迭代不会如此，因为扩展通过能力标志或设置级版本控制演进，仅在无法避免时才使用新标识符。MCP Apps 作为扩展已经可用，现在位于正式管控的协商框架内，而非之前不存在的流程。

弃用策略带来的好处

功能生命周期策略为每个功能定义了活跃、弃用和移除状态，从功能首次被标记为弃用的修订版起至少 12 个月的窗口。窗口只能因已发布公告或已记录利用的活跃安全风险而缩短，即使如此，90 天是硬性下限。公共注册表列出已弃用及何时移除。标准跟踪提案在相应场景落地到符合性套件之前不能达到最终状态。

对开发者而言，这看起来像内务管理。但对需要向平台审查委员会证明 MCP 集成合理性的人来说，书面弃用保证比此次发布中的任何功能都更有价值。

代价

这一切并非免费。任何基于实验性 Tasks API 构建的人必须迁移到新生命周期；任何向客户端发出自身请求的服务器必须转移到多轮次请求模式，服务器返回仍需的信息，客户端携带答案重试。该服务器还必须验证任何可能影响授权或业务逻辑的回显 requestState。一次性工作流仍需自身重放跟踪。

弃用是迁移方向而非替代品，Sampling 是最尖锐的案例。使用客户端中介的 Sampling 的服务器无需提供商凭证，通常不承担模型账单；而直接调用提供商 API 则使其成为凭证持有者、账单方和用户数据的独立处理器。Logging 也类似：stderr 和 OpenTelemetry 回答运维可观察性问题，而不给远程客户端与之前接收的结构化日志流等同的功能。

协议不再管理状态，这并不意味着状态消失。句柄、购物车、任务记录和幂等键仍需驻留某处。协议不再管理状态，但状态并未消失。

前路

在协议诞生不到两年内移除基础抽象是有计算的风险，维护者明智地设置了 10 周验证窗口，并提供 Python、TypeScript、Go 和 C# 的 Beta SDK。

他们还定义了迁移路径：客户端先使用 server/discover 探测，仅在遇到仅支持旧版本的服务器时回退到初始化。这是一个有线层面的断点，但通过协商路径跨越，而非生态系统的“旗帜日”。

发布候选窗口是盘点会话依赖并测试的正确时机，生产部署应等待审批完成和稳定 SDK。从个人服务器作者到平台团队再到围绕它构建网关和注册表的供应商，其回报是协议层更自然地契合业界已熟悉的运维基础设施。