近期MCP协议实现关键无状态化突破，显著简化服务器部署方式。新规范剥离协议层会话需求，允许请求独立路由至任意实例，既消除粘性共享会话的弊端，又将状态管理权移交周边基础设施，助力水平扩展。此变更取消initialize、Mcp-Session-Id等核心握手及会话标识，使负载均衡器可独立路由请求，并新增server/discover操作辅助客户端预判能力。这一演进让MCP协议摆脱会话依赖，改变传统部署逻辑，其本质是协议无状态化，核心目的降低状态维护成本，但应用仍需适配状态交互，以实现高效协同。
--91likeyou---
对于亚马逊云科技上的部署而言，这可以消除专门用于维护 MCP 协议会话的基础设施。AWS Architecture Blog 作者 Anand Komandooru、Steven DeVries 和 Haleh Najafzadeh 介绍了如何用传统请求路由取代具有会话亲和性的路由，并移除仅用于保存 MCP 协议状态的会话存储。他们还将 AWS Lambda 列为一种适合请求—响应模型的部署选项，因为该协议不再要求持久化会话连接。
协议状态与应用状态之间的区别也成为社区讨论的焦点。Michael Madsen 在 LinkedIn 上谈及该规范时，将这项变化总结为：
协议是无状态的，但你的应用不必如此。
MRTR 取代了此前需要保持流连接的服务器发起型请求，允许通过 input_required 响应及后续请求完成多步骤交互。新的 Mcp-Method 和 Mcp-Name 标头支持网关路由和限流，W3C Trace Context 则支持分布式追踪。ttlMs 和 cacheScope 提供缓存控制能力。
亚马逊云科技将这些变更映射至其面向智能体 AI 的 Well-Architected 指南，涵盖监控、追踪、安全和工具集成。流恢复能力也已被移除，因此客户端可能需要重试被中断的操作。对于会产生副作用的工具调用，这进一步凸显了幂等性的重要性。
早期实现工作表明，现有基础设施仍然需要一条过渡路径。Apify 的 MCP 服务器项目正在现有的有会话服务器之外实现无状态支持，并通过路由和一致性测试覆盖两个协议版本。
因此，对于仍需支持旧版 MCP 客户端的部署，迁移仍然十分重要。亚马逊云科技建议在网关处追踪协议版本，并在旧版流量完全消失之前保留会话基础设施。MCP 项目还制定了一项功能生命周期策略，为弃用功能提供明确的迁移期。
：
🔥 热词：#mcp的有状态和无状态是什么 · #mcp发布新协议无状态化支持 · #MCP SSE无状态 · #mcp开发的应用场景 · #MCP协议在AI中的应用场景 · #MCP在AI中的应用场景有哪些 · #MCP应用 · #mcp状态控制