MCP新规范移除会话机制简化扩展

最新版模型上下文协议（MCP）对远程服务器部署方式作出重要调整：协议层不再维护会话，请求可以被分发到任意可用的服务器实例。这样一来，系统不再因协议本身依赖粘性会话或共享会话存储，水平扩展和基础设施设计都更接近普通无状态服务。不过，这并不意味着状态完全消失，而是需要由应用、网关、缓存或其他外围组件承担。

在具体变更上，新规范删除了 initialize、initialized 握手流程，也取消了 Mcp-Session-Id 标头。传统负载均衡器因此可以按请求独立转发流量，无需确保同一客户端持续命中同一实例。同时，规范新增可选的 server/discover 操作，方便客户端在调用工具前查询服务器能力。

对于部署在亚马逊云科技上的 MCP 服务，这类变化意味着可移除一部分只为维持协议会话而存在的组件。相关架构说明提出，可用常规请求路由替代会话亲和路由，并删去仅保存 MCP 协议状态的会话存储。AWS Lambda 也被视为更自然的部署选择，因为新版协议更契合请求—响应模型，不再要求长期保持会话连接。

社区讨论的重点之一，是区分“协议状态”和“应用状态”。有开发者概括称，协议可以是无状态的，但应用并不必然无状态。新版中的 MRTR 取代了过去依赖持续流连接的服务器发起请求，多步骤交互可通过 input_required 响应与后续请求完成。新增的 Mcp-Method、Mcp-Name 标头可用于网关路由和限流，W3C Trace Context 支持分布式追踪，ttlMs 与 cacheScope 则提供缓存控制能力。

这些调整也被映射到面向智能体 AI 的架构实践中，涉及监控、追踪、安全和工具集成等方面。与此同时，流恢复能力已被移除，客户端在操作中断时可能需要自行重试。对于会改变外部状态的工具调用，幂等性因此变得更加关键，否则重试可能带来重复执行等风险。

早期实现显示，现有系统仍需要过渡方案。例如 Apify 的 MCP 服务器项目正在既有有会话服务器之外加入无状态支持，并通过路由与一致性测试同时覆盖新旧协议版本。对于仍需兼容旧版 MCP 客户端的部署，建议在网关侧识别并跟踪协议版本，在旧流量完全退出前保留会话基础设施。MCP 项目也制定了功能生命周期策略，为弃用能力提供明确迁移窗口。