一句话看懂：最新版模型上下文协议（MCP）规范移除了协议层会话，让远程 MCP 服务器可以像普通 Web 服务一样横向扩展。但这并非免费午餐——会话状态没有消失，只是从协议层转移到了应用和周边基础设施。
事件核心：发生了什么
亚马逊云科技近期介绍了新版 MCP 规范对远程服务器部署方式的改动。核心变化是移除了 initialize 与 initialized 握手流程以及 Mcp-Session-Id 标头，这意味着负载均衡器可以将每个请求独立路由到任意可用的服务器实例，不再需要粘性会话和共享会话存储。规范同时引入可选的 server/discover 操作，供客户端在调用工具前了解服务器能力；MRTR 机制则通过 input_required 响应加后续请求来完成多步骤交互，取代了此前依赖长连接的服务器发起型请求。此外新增 Mcp-Method、Mcp-Name 标头支持网关路由与限流，W3C Trace Context 支持分布式追踪，ttlMs 和 cacheScope 提供缓存控制。
为什么重要
此前 MCP 的会话绑定特性，使得部署时不得不维护会话亲和路由和专门的会话存储，Lambda 这类请求—响应模型也不太适配。新规范把这些协议层负担剥离，让 MCP 服务器更接近标准无状态服务。Michael Madsen 在 LinkedIn 上的总结被广泛引用：“协议是无状态的，但你的应用不必如此。”这句话点出了关键：状态管理职责被下放给了应用侧，协议简化不等于系统复杂度降低。对亚马逊云科技而言，这些变更也被映射进其面向智能体 AI 的 Well-Architected 指南。
对用户/开发者/创作者的影响
开发者受益于部署选项变多：传统请求路由可以替代会话亲和路由，专用会话存储层可以移除，MCP 服务器更容易跑在 Lambda 等无服务器架构上。但代价同样明确——流恢复能力已被移除，客户端可能需要重试被中断的操作，这对会产生副作用的工具调用提出了更高的幂等性要求。目前公开信息显示，迁移并非一刀切：Apify 的 MCP 服务器项目仍在旧版有会话服务器之外并行实现无状态支持，并通过路由和一致性测试覆盖两个协议版本。亚马逊云科技建议在网关处追踪协议版本，在旧版流量消失前保留会话基础设施。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是无状态 MCP 在真实生产环境的落地情况，尤其是重试与幂等性模式能否形成通用实践；二是各网关和 AI 应用框架是否会跟进支持 Mcp-Method、Mcp-Name 等新标头；三是 MCP 项目已制定的功能生命周期策略，旧版客户端与迁移期的实际时长将直接影响存量部署的改造成本。
来源：InfoQ CN
