MCP 协议移除有状态会话机制，状态管理职责转移至应用层与周边基础设施

一句话结论

最新版模型上下文协议（MCP）规范移除了协议层会话与握手流程，将状态管理职责转移给应用层，简化了远程服务器的水平扩展部署。

关键要点

• 新规范彻底移除了 `initialize` 和 `initialized` 握手流程，以及用于标识会话的 `Mcp-Session-Id` 请求标头。
• 引入可选的 `server/discover` 操作，允许客户端在调用具体工具之前，先查询服务器支持的能力列表。
• `MRTR` 机制取代了此前需要保持流连接的服务器发起型请求，通过 `input_required` 响应支持多步骤交互。
• 新增 `Mcp-Method` 和 `Mcp-Name` 标头以支持网关路由与限流，并采用 `W3C Trace Context` 实现分布式追踪。
• 流恢复能力被移除，要求客户端具备重试机制，并特别强调了对产生副作用的工具调用实施幂等性控制。

背景与事实

亚马逊云科技近日详细阐述了最新版模型上下文协议（MCP）规范对远程服务器部署架构带来的根本性改变。新规范的核心变革在于彻底移除了协议层面的会话状态管理。在传统架构中，MCP 服务器依赖会话亲和性（Sticky Sessions）和共享会话存储来维护连接状态，这增加了部署复杂度并限制了水平扩展能力。随着 `initialize` 和 `initialized` 握手流程以及 `Mcp-Session-Id` 标头的移除，协议本身不再维持会话上下文。这意味着传统负载均衡器可以将每个独立的请求路由到集群中任意可用的服务器实例，无需维护复杂的会话映射表或共享存储系统。

在技术实现细节上，新规范引入了 `MRTR`（Multi-Request-Transfer）机制来替代过去需要保持持久流连接的服务器发起型请求。这一变更允许通过 `input_required` 响应以及后续的客户端请求来完成多步骤的交互过程，使得交互模式更适应无状态环境。此外，为增强基础设施的治理能力，规范新增了 `Mcp-Method` 和 `Mcp-Name` 标头，使得 API 网关能够基于这些标头进行精细化的路由转发和限流控制。在可观测性方面，规范全面支持 `W3C Trace Context`，便于在分布式系统中进行链路追踪。同时，通过引入 `ttlMs`（生存时间毫秒）和 `cacheScope`（缓存范围）参数，新规范提供了更精细的缓存控制能力，帮助应用层更好地管理数据的新鲜度与一致性。

对于部署在亚马逊云科技（AWS）上的开发者而言，这一变更带来了直接的架构简化红利。AWS 架构博客作者 Anand Komandooru、Steven DeVries 和 Haleh Najafzadeh 指出，新规范允许开发者移除仅为保存 MCP 协议状态而存在的会话存储基础设施，转而使用传统的无状态请求路由模型。他们特别推荐将 AWS Lambda 作为部署选项之一，因为无状态协议的特性完美契合 Lambda 的请求-响应模型，避免了因会话持久化带来的冷启动延迟和资源预留成本。亚马逊云科技还更新了其面向智能体 AI 的 Well-Architected 指南，将上述变更映射至监控、追踪、安全以及工具集成等最佳实践中，为开发者提供了明确的架构参考标准。

影响分析

对于中文开发者与从业者而言，MCP 协议无状态化的转变意味着后端架构设计的思路需要从“连接导向”转向“请求导向”。以往在构建 MCP 服务器时，开发者需要花费大量精力处理会话丢失、分布式环境下的会话同步以及负载均衡器的会话亲和性配置。新规范将这些复杂性上移到了应用层，开发者必须自行设计状态持久化策略，例如使用外部数据库或缓存中间件来保存上下文信息。这种变化虽然降低了协议栈的复杂度，但提升了应用开发的门槛，要求开发者对幂等性、重试机制和分布式一致性有更深的理解。对于正在构建企业级智能体应用的团队，需要重新评估现有的会话管理模块，并投入资源开发新的无状态路由网关，以确保系统在高并发场景下的可扩展性与稳定性。

此外，可观测性与安全性的提升要求开发者调整现有的监控体系。由于 `W3C Trace Context` 的引入，跨服务的链路追踪变得更加标准化，但同时也要求内部系统必须具备处理全局追踪 ID 的能力。在网关层面，新增的标头使得细粒度的流量控制成为可能，这有助于企业更精细地管理 API 配额与安全策略。然而，由于流恢复能力的移除，网络不稳定环境下可能导致用户操作中断，因此前端应用必须实现健壮的自动重试逻辑，并在业务逻辑中设计完善的幂等键，以防止因网络抖动导致的重复执行或数据错误。

适用边界

该无状态架构的优势主要适用于请求-响应模式清晰、单次交互逻辑独立的服务场景，如数据查询、工具调用等。对于强依赖长连接、实时流式传输或高频率双向通信的场景，无状态模式可能会增加网络往返次数，导致延迟升高。此外，由于协议不再维持会话状态，对于需要在长生命周期任务中保持上下文连贯性的复杂智能体工作流，应用层必须自行实现健壮的上下文持久化与恢复机制，否则在服务器重启或扩缩容时，任务进度可能会丢失。同时，对于仍需兼容大量旧版 MCP 客户端的企业环境，完全移除会话基础设施存在风险，必须保留过渡期的双栈支持。

孤本观察

MCP 协议向无状态化演进，反映出基础设施层与应用层职责边界的重新划分，即协议负责标准化通信格式，而状态管理、重试逻辑与副作用控制等复杂业务逻辑被强制下沉至应用层，这既简化了协议实现，也提高了应用开发的复杂度。

来源：InfoQ 中文 AI