2026 年 9 月 24 日，几篇技术分析几乎同时给 MCP 2026-07-28 规范下了同一个结论：这是 Model Context Protocol 自 2024 年 11 月 Anthropic 开源以来最大的一次修订。 VentureBeat 把这次更新定位成「面向大规模企业生产部署」，而 bex.co 的文章标题更直接——《MCP Just Got Its Biggest Update Ever: What Stateless Servers Mean for Self-Hosting Deploy-from-Chat》。有意思的是，这个被包装成「企业版」的更新，本质上让自托管开发者也能把 MCP 服务器当成一个普通 HTTP 服务来运维。

规范本身是 7 月 28 日定稿的，距今已接近两个月。真正值得在 9 月底再写一笔的，不是它「改了什么」，而是生态开始把它当成生产部署的默认假设。这个信号比任何一条单独的新规范都重要。

协议线上发生了什么

MCP 2026-07-28 的核心动作可以概括为：把协议核心从「有状态」改成「无状态」。

在此之前，每个 MCP 客户端都要先走 initialize 握手，拿到一个 Mcp-Session-Id，之后同一会话的所有请求都必须落到持有该会话状态的那个服务器实例上。这意味着生产环境里必须做粘性路由、共享会话存储，或者让网关去解析 JSON body 做转发。对很多团队来说，MCP 服务器是他们基础设施里唯一一个有状态的东西。

新规范直接取消了握手和会话 ID。每个请求自己携带协议版本、客户端能力和目标工具名，服务器不再需要记住客户端。AgentPatterns.ai 的总结很精炼：any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage。

具体变化包括：

• 路由信息移到 HTTP 头：Mcp-Method 对应 JSON-RPC 方法，Mcp-Name 对应工具/资源/提示名；网关、WAF、限流器可以在不解析 body 的情况下做路由和计量。
• 协议版本和客户端信息放进请求 _meta；服务器通过 server/discover 在响应 _meta 中自我标识。
• tools/list、resources/list 等列表响应支持显式 ttlMs 和 cacheScope，工具目录终于可以缓存，不再每会话重新协商。
• 认证被重写为正式 OAuth 2.1 资源服务器：强制 issuer 验证（RFC 9207）、protected-resource 元数据（RFC 9728）、resource indicators（RFC 8707），并用 Client ID Metadata Documents 取代 Dynamic Client Registration。
• Tasks 扩展和 MCP Apps 扩展毕业，进入正式扩展框架。
• 工具定义迁移到 JSON Schema 2020-12。
• Roots、Sampling、Logging 和传统 HTTP+SSE 进入十二个月弃用窗口。

这些改动里最被低估的，可能是「列表可缓存」和「请求头路由」。前者把 Agent 启动时最常见的 tools/list 调用从服务器压力变成 CDN 边缘可命中；后者让网关层第一次可以像处理普通 REST API 一样处理 MCP，而不必拆开 JSON-RPC body。

企业需求与自托管需求殊途同归

bex.co 的文章里有句话值得单独摘出来："the enterprise release is secretly a self-hosting release"。

企业需要 MCP 像他们已有的云原生服务一样可观测、可伸缩、可复用现有运维流程；自托管者则希望 MCP 服务器不要成为一个需要单独写一份 runbook 的异类。无状态化同时满足了两边：

• 不再需要 Redis 会话存储或粘性负载均衡；
• 一个二进制或容器加上普通反向代理就能跑；
• 重启对客户端不可见；
• HPA 自动扩缩、Gateway API 路由、标准 HTTP 监控都可以直接套用。

换句话说，MCP 服务器现在终于可以像其他微服务一样被部署了。

bex.co 针对自托管部署服务器给出了一个务实的迁移顺序：

1. 先升级 SDK，把传输层切到无状态；
2. 删掉会话存储，在现有网关后面验证请求头与 body 是否一致；
3. 把 OAuth 2.1/CIMD/issuer 验证作为第二步单独排期，而不是一次性全做。

这个顺序很实在。很多团队会被「企业级治理」吓到，但实际上大部分自托管场景只需要核心传输+认证升级即可，正式的审计追踪、多厂商合规认证可以以后再说。

无状态不等于无状态管理

新规范最容易被误解的地方，是把「协议无状态」和「应用无状态」混为一谈。

协议层面的无状态只是说：传输层不再替应用保存会话。真正需要持续的工作——一次长时间的部署、一次多步骤的数据迁移、一个跨轮次的用户访谈——仍然需要状态。只是这些状态不再藏在 Mcp-Session-Id 后面，而应该显式地由工具返回一个 handle，让模型在后续调用里传回来。

这也是为什么 Tasks 扩展如此重要。它给了长时运行操作一个协议级的形状：启动任务、轮询或订阅、收集结果，不需要一个长连接来 babysit。

另一个隐性账单是工具目录的上下文成本。AgentPatterns.ai 提醒，Anthropic 内部测过一个五服务器场景：58 个工具定义大约 55,000 token，优化前甚至到 134,000 token。无状态化并不减少这些 token，只是让传递它们变得更便宜。 deferred tool loading 仍然是独立问题。

我的判断：MCP 正在从「开发者玩具」变成「基础设施默认」

2025 年大家都在讨论 MCP 能不能成为 Agent 工具调用的「USB-C」；2026 年讨论的问题已经变成：它能不能被当作生产基础设施来运维。2026-07-28 规范给出的答案是：可以，但前提是接受一次破坏性迁移。

这次迁移的代价是真实的。任何依赖旧握手、旧会话 ID、旧 HTTP+SSE 传输、Roots/Sampling 的代码都必须在十二个月内升级。对已经跑在生产环境里的 MCP 服务器来说，这不是小修小补。

但收益也是真实的。无状态化让 MCP 服务器可以复用现有的云原生运维体系，OAuth 2.1 资源服务器化让它在大企业里有合规立足点，Tasks 扩展让长时 Agent 工作不再靠长连接 hack。这些加在一起，意味着 MCP 正在从「Agent 客户端的一个插件」变成「企业应用层的一部分」。

对普通开发者来说，最务实的做法不是追逐企业治理套件，而是先把核心迁移做了：升级 SDK、删掉会话存储、把认证迁到 issuer 验证。等你的 MCP 服务器数量多到「数不过来」的时候，再回头补审计和多厂商合规也不迟。

参考来源

• bex.co: MCP Just Got Its Biggest Update Ever: What Stateless Servers Mean for Self-Hosting Deploy-from-Chat (2026-09-24) — https://bex.co/blog/2026/09/24/mcp-biggest-spec-update-self-host-deploy-chat
• VentureBeat: MCP just got its biggest update ever: Here’s what changes for AI agents (2026-09-24) — https://venturebeat.com/infrastructure/mcp-just-got-its-biggest-update-ever-heres-what-changes-for-ai-agents
• Agentic AI Foundation: MCP Graduates to Enterprise Infrastructure: Stateless Architecture, Formal Governance, and Security — https://aaif.io/blog/mcp-graduates-to-enterprise-infrastructure-stateless-architecture-formal-governance-and-security
• AgentPatterns.ai: Stateless MCP: One Request per Tool Call — https://agentpatterns.ai/standards/stateless-mcp
• Kuadrant MCP Gateway scaling guide — https://github.com/kuadrant/mcp-gateway/blob/HEAD/docs/guides/scaling.md