MCP 迎来最大更新：重回上古时代HTTP

MCP 于 2026 年 7 月 28 日发布最终版规范，这是官方口中“发布以来最大的一次更新”。核心变化是移除会话和初始化握手，每个请求必须独立携带完整上下文，使远程服务器可像传统无状态 HTTP 服务一样运行，采用轮询调度即可，无需配置会话亲和性。

这一改动源于原始设计与实际部署的差距：MCP 最初是桌面应用通过 stdio 通信，握手成本低；但远程水平扩展时，会话需要亲和性、共享存储或 MCP 感知网关，成为运维负担。能力协商在连接时一次性交换，导致缓存难以推断。

维护者通过六项规范增强提案实现“按需付费复杂度”：协议版本和客户端能力通过 _meta 传递，新增 server/discover 方法支持按需查询。但开发者 Román Moskalenko 警告，新旧协议共存阶段会非常混乱，故障率可能更高。

无状态化后，需要记住信息的服务器采用显式句柄模式，如购物车的 basket_id：工具生成句柄包含在结果中，模型下次调用时作为参数传回。句柄对模型可见，可跨工具组合，但会出现在提示词和日志中，因此必须绑定认证主体并每次验证权限，不能视为授权凭证。

缓存方面，列表和读取结果需包含 ttlMs 和 cacheScope（参考 HTTP Cache-Control），作为新鲜度提示而非承诺。服务器需按确定性顺序返回条目，以提高提示词缓存命中率，可能降低延迟或 Token 成本。

协议无状态性只保证可路由性，不保证确定性：不同版本或下游数据的副本可能返回不同响应。应用状态（如购物车、任务记录）仍需外部存储，协议不再管理状态，但状态并未消失。

扩展获得命名空间标识符：官方扩展位于 io.modelcontextprotocol，第三方使用作者反向域名，并有独立存储库和发布周期。Tasks 功能于 2025 年 11 月 25 日作为实验性核心功能发布，因设计问题被重新设计为扩展，移出核心是破坏性变更，但后续演进通过功能标志或版本控制，避免再次破坏。

特性生命周期策略规定“活跃”“已弃用”“已移除”三态，从弃用起至少保留 12 个月过渡期；仅当存在活跃安全风险时可缩短，但 90 天是最低时限。公共注册表列出淘汰特性，标准跟踪提案需通过符合性测试才能达到“最终版”。

对于需要向平台评审委员会证明集成合理性的开发者，书面弃用保证比任何特性更有价值。

基于实验性 Tasks API 的系统必须迁移到新生命周期；曾向客户端发请求的服务器需转为多轮次请求模式，服务器返回所需内容，客户端重试。服务器必须验证回显的 requestState 以防影响授权，一次性工作流需独立重放跟踪。

弃用项是迁移指引而非无缝替代：客户端中介式采样不需要提供商凭证，而直接调用提供商 API 会使服务器成为凭证持有者和账单方；stderr 和 OpenTelemetry 无法为远程客户端提供结构化日志流替代。

安全方面，Mcp-Method 和 Mcp-Name 标头允许网关无需检查正文即可限流或授权，但仅在传输验证规则下成立，后端会拒绝不匹配的标头，中间节点需确保协议版本支持检查，否则标头可能掩盖实际调用。

维护者设置十周验证期，并提供 Python、TypeScript、Go、C# 测试版 SDK。迁移路径为：客户端先用 server/discover 探测，遇到旧版服务器时回退到 initialize，实现可协商过渡，而非强制同步切换。

发布候选窗口是梳理会话依赖和测试的最佳时机，待批准和 SDK 稳定后可生产部署。最终，协议层将自然兼容行业成熟的运营体系，从服务器开发者到平台团队和网关提供商都将受益。

但无状态化并非免费：状态管理外移、迁移混乱和安全新挑战并存。开发者需权衡利弊，谨慎规划迁移。