模型上下文协议（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定义为新鲜度提示，而非数据仍然有效的承诺。服务器还被要求以确定性顺序返回工具列表，这与提升提示词缓存命中率有关——在高并发场景下，这意味着在支持提示词缓存计费的服务商处，可以降低延迟或Token成本。
需要明确的是：协议层的无状态性带来的是可路由性，而非确定性。两个副本可以接受同一请求而无需相互协商协议状态，但如果它们运行的版本不同或读取的下游数据存在差异，仍然可能返回不同的结果。
扩展生态的演进机制
生态系统层面的价值超越任何单项功能。扩展功能现在拥有命名空间标识符：官方扩展使用io.modelcontextprotocol前缀，第三方扩展使用作者持有的反向域名前缀，并拥有独立的扩展仓库和发布节奏。熟悉Kubernetes自定义资源定义的开发者会对这一模式感到亲切——某项能力可以在核心发布周期之外独立交付和演进。
Tasks功能的演变历程正是这一机制重要性的最好证明。它作为实验性核心功能在2025-11-25版本中发布，实际生产使用暴露了设计缺陷，随后被重新设计为扩展功能。将其移出核心本身是一次规范层面的破坏性变更，但后续迭代不会如此，因为扩展通过能力标志或设置级版本控制来演进，只有在不可避免的破坏性变更时才使用新标识符。MCP Apps作为扩展已经上线，现在纳入了正式的能力协商框架管理。
功能生命周期与弃用保障
功能生命周期策略为每个功能定义了活跃、弃用和移除三种状态，从功能首次进入弃用状态的版本起，至少保留十二个月。仅在存在已发布安全公告或有记录的利用行为的主动安全风险时，才可缩短这一窗口期，且即便如此，九十天是最短下限。公开注册表会列出即将弃用的功能及具体时间节点，而标准跟踪提案在对应场景未纳入合规测试套件之前，不得进入最终状态。
对开发者而言，这或许只是日常维护事项。但对于需要向平台评审委员会论证MCP集成可行性的人来说，一份书面的弃用保障，其价值远超任何单项新功能。
迁移成本与注意事项
这一切并非没有代价。基于实验性Tasks API构建的开发者需要迁移至新的生命周期机制；服务器端向客户端发起请求的场景，需要迁移至多轮请求模式——服务器返回所需信息，客户端携带答案重新发起请求。服务器还需对任何可能影响授权或业务逻辑的echoed requestState进行认证，一次性工作流仍需自行追踪重放情况。
各项弃用功能提供的是迁移方向，而非即插即用的替代方案，其中Sampling的影响最为突出。使用客户端中介Sampling的服务器无需持有服务商凭证，通常也不承担模型费用；而直接调用服务商API则使其成为凭证持有方、计费方，以及用户数据的独立处理方。日志机制同理——stderr和OpenTelemetry已能满足运维侧的可观测性需求，但远程客户端无法获得等同于原有结构化日志流的能力。
应用状态同样不会就此消失。句柄、购物车、任务记录和幂等性键仍然需要存储的地方。协议停止管理状态，并不等于状态本身消失了。
展望与建议
在协议发布不到两年的时间内移除一个基础抽象，是一次经过审慎权衡的风险决策。维护者通过十周的验证窗口期以及Python、TypeScript、Go和C#的测试版SDK，对这一风险进行了合理对冲。
他们还定义了一条迁移路径：客户端优先尝试server/discover，仅在遇到仅支持旧版协议的服务器时才回退至initialize。这是一次协议层面的破坏性变更，但提供了有协商机制的过渡路径，而非生态系统层面的一刀切强制升级。
候选版本窗口期是盘点会话依赖并进行测试的最佳时机，生产环境的推广应在规范正式批准和稳定SDK发布后跟进。从服务器开发者、平台团队，到围绕MCP构建网关和注册表的厂商，此次更新带来的回报是一个能够更自然地融入业界熟悉的基础设施的协议层。
Q&A
Q1：MCP协议为什么要移除会话机制？
A：MCP原始设计中的会话机制在本地桌面场景下问题不大，但在远程水平扩展部署中会造成严重问题。服务器生成的Mcp-Session-Id会将客户端绑定到特定实例，导致需要会话亲和性配置或专用网关逻辑，无形中给服务器开发团队增加了分布式系统方面的额外负担。新版本通过让每次请求携带完整的协议版本和能力信息，实现真正的无状态化，使MCP服务器可以像普通HTTP服务一样部署和扩展。
Q2：移除会话机制后，MCP如何处理需要保存状态的场景？
A：新版本引入了显式句柄（handle）机制作为替代方案。工具可以生成一个唯一标识符（如basket_id），在结果中返回给模型，模型在后续调用时将其作为普通参数传回。这种方式的优势在于句柄对模型可见，可以在不同工具间组合使用并在工作流步骤间传递，而不像以前的会话状态被隐藏在传输元数据中模型无法感知。账户状态、资源URI、任务句柄等均可通过这种方式管理。
Q3：MCP新版本的功能弃用保障机制是怎样的？
A：新版本建立了明确的功能生命周期策略，每个功能分为活跃、弃用和移除三种状态。功能从进入弃用状态起，至少保留十二个月才会被移除。只有在存在已发布安全公告或有记录的主动安全风险时，才可将窗口期缩短，但最短不得少于九十天。官方会维护公开注册表，列出所有即将弃用的功能及具体时间节点，方便开发者提前规划迁移工作。
