MCP 的新版 2026-07-28 规范移除了所有会话状态 (session-state) 要求，允许每个请求携带其所需的所有数据。向无状态协议的转变意味着开发者可以为每次调用启动单个实例，在无服务器 (serverless) 或边缘节点上运行，并淘汰以往一直困扰部署的旧有粘性路由 (sticky-routing) 和共享存储架构。

从握手转向自包含调用

在此之前，模型上下文协议 (MCP) 强制要求进行握手并颁发会话 ID。服务器必须在连接的整个生命周期内记住该 ID，这在实践中意味着必须保持进程存活、在 Redis 集群中复制状态，或者为“粘性”路由配置负载均衡器。其结果是产生了一个复杂且耗费资源的架构，这会阻碍扩展并增加水平增长的成本。

新规范使每个请求都变为自包含的。每个有效载荷 (payload) 都包含了协议版本和调用者的身份信息，因此服务器可以将该请求视为一次性事务。无需会话存储，无需长连接进程，也无需特殊的路由规则。

为什么无状态对部署至关重要

  • 适配无服务器和边缘计算 – 请求携带了其所需的一切，因此函数可以启动、响应并关闭，而无需预热状态。对于按调用次数计费的供应商来说，MCP 工作负载变得更具可行性。
  • 简化负载均衡 – 标准的 L4/L7 负载均衡器可以均匀地分配流量；不再需要将客户端固定在特定的后端。
  • 降低运维开销 – 团队可以停用 Redis 集群或自定义的会话复制代码，从而降低成本并减少故障面。

对于已经在负载均衡器后运行 MCP 的组织来说，这一变化消除了对“粘性”规则的需求，而这些规则往往会导致流量分配不均。对于每天处理数百万次调用的高吞吐量服务，节省的成本尤为显著。

性能与安全升级

该规范增加了具体的增强功能，在实现无状态化的基础上进一步强化了协议：

  • 基于 TTL 的缓存 – 工具和提示词 (prompt) 列表现在包含一个生存时间 (TTL) 字段，允许客户端在本地缓存结果，从而避免不必要的往返请求。
  • 头部驱动路由 – 新的 HTTP 头部可以尽早暴露路由信息，使网关无需解析完整的 JSON 正文即可转发流量，从而减少毫秒级的延迟。
  • OAuth/OIDC 加固 – 身份令牌经过更严格的 OAuth 和 OpenID Connect 检查，降低了遭受重放攻击和令牌窃取攻击的风险。
  • 正式的扩展框架 – 任务 (Tasks) 和应用 (Apps) 现在属于定义的扩展模型，这使得 SDK 维护者在未来推出新功能时更加顺畅。

对开发者的影响

SDK 生态系统已经反映了这一变化：TypeScript、Python、Go 和 C# 库均已支持输出新的请求格式。这些 SDK 的总下载量每月已接近 5 亿次，是年初的四倍，这表明 MCP 的采用范围正在广泛扩大。

开发者必须调整任何假设存在持久会话的代码。通常这意味着将特定于会话的数据移至请求有效载荷中，或者移至每次调用时查询的外部存储中。迁移窗口期为 12 个月，为团队提供了重构、测试并推出新模式的时间。

对立观点：迁移复杂度

无状态化并非没有代价。此前依赖服务器端状态来实现渐进式对话历史等功能的应用程序，现在必须在客户端或通过独立的持久化层来管理这些状态。

值得关注的动向

  • 采用指标 – 监控 SDK 版本的更新情况；增速放缓可能预示着迁移存在阻力。
  • 边缘平台支持 – 随着更多供应商宣布支持兼容 MCP 的运行时，无服务器带来的实际成本效益将变得更加清晰。
  • 安全事件报告 – 加固后的 OAuth/OIDC 流程应当能减少身份攻击，但任何违规事件都将考验新的防护机制。

核心结论： 通过使 MCP 实现无状态化，该规范使协议与现代云原生模式保持了一致，在大幅减少会话管理带来的运维负担的同时，也为更廉价、更具弹性的部署模式打开了大门。虽然代价是需要经历一段代码重构期且请求数据包会变大，但长期的回报是获得了一个能够像其运行的基础设施一样轻松扩展的协议。