MCP 新规范落地：自发布以来最大的一次破坏性变更
数据截至 2026-07，价格与限额以各官网为准。
这次 MCP 规范更新不是加几个字段的例行版本号推进，而是把协议底座换了一层：协议层不再要求会话追踪、Tasks 从核心搬进 extension、授权向真实世界的 OAuth 部署靠拢。官方自己把它定性为协议发布以来最大的一次修订，并且明说新旧版本之间可能无法协同工作——如果你线上跑着 MCP server，这篇要读的重点不是”有什么新特性”，而是”我什么时候必须动”。
先说一个很常见的误解：不少人看到”MCP 无状态化”，第一反应是”以后 MCP 不能有状态了，我那些需要记住上下文的 server 是不是废了”。这是把两层混在一起了。变的是协议层不再强制要求会话追踪，应用层自己要维护什么状态，仍然是你自己的事。协议不再替你管会话，不等于禁止你有状态——恰恰相反，它把状态管理的自由度还给了应用。
这次到底改了哪几块
按官方博客的归类，新规范主要落在这几处：
- 无状态协议内核——影响面最大的一块，下面单独说。
- Extensions 框架——把非核心能力从主协议里拆出去的机制。
- Tasks——长时间运行操作的支持，现在是一个 extension 而不是核心特性。
- MCP Apps——面向应用形态的一块新内容。
- 授权加固——让授权规范更贴近真实的 OAuth 2.0 / OpenID Connect 部署。
- 正式的弃用策略——第一次把”旧版本怎么退场”写成规则，而不是靠公告临时通知。
这份清单本身就说明了方向：核心协议要瘦，外围能力靠 extension 挂载，同时把工程落地时最容易出事的两块（部署形态、授权）补硬。发布之前官方已经放出过 release candidate，所以这不是突然袭击，只是很多中文圈的资料还停留在更早的版本上。
无状态化：粘性会话终于可以不要了
这是我认为对运维影响最直接的一条。旧的远程 MCP server 部署起来有个绕不开的麻烦：会话是有状态的，于是负载均衡必须做粘性会话（sticky session），把同一个客户端的请求一直钉在同一个实例上；不想粘的话，就得引入共享的 session 存储，让多个实例之间同步会话；再复杂一点的网关，还得对 MCP 流量做深度包检测才知道该往哪儿转。
这一套东西，对做过分布式服务的人来说都不陌生，但它意味着 MCP server 没法当成普通无状态 Web 服务来部署——扩容、滚动发布、跨可用区容灾，全都要多绕几道。
新规范由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同完成了这件事，兑现了官方此前那篇讲 MCP 传输层未来方向的设计。落到实处就是：协议层不再要求会话追踪，远程 server 可以直接跑在普通的轮询负载均衡后面，按 Mcp-Method 头做路由即可。
对不同角色的实际含义：
- 自建远程 server 的团队：可以把粘性会话配置、共享 session 存储这类基础设施债务列进清理计划，但别急着一刀切——先确认你的运行时（SDK 版本）已经支持新规范，再拆旧的兜底。
- 只写 stdio 本地 server 的开发者：日常感知很弱，本地进程本来也没有负载均衡这一层。你受影响的主要是授权和弃用窗口那两块。
- 做网关/中间层的：路由逻辑可以简化成看头字段，不必再解包判断。
再强调一次前面那个误区：这里说的是协议不再强制会话追踪。你的业务如果需要跨请求记住东西，照样自己存，只是别再指望协议帮你保证”同一个会话落在同一个实例”。
Tasks 移出核心：extension 框架的第一个大用户
Tasks（用于长时间运行的操作）从核心协议移到了 extension。这一步单看像是降级，其实是配套无状态化的必然选择：长任务天然是有状态的，如果它留在核心里，协议内核就没法真正瘦下来。
Extensions 框架同时留了一个口子：你可以自建 extension，和官方认可的 extension 并存。这对企业内部场景挺关键——过去想给协议加点私有能力，要么等上游合并，要么魔改 SDK 自己维护分支；现在有了正式的挂载位置，私有扩展和官方扩展是同一套机制下的公民。
代价也要说清楚：能力从核心挪到 extension，意味着能不能用要靠协商而不是默认存在。以前写客户端可以假设对端支持 Tasks，现在这个假设不成立了，得按扩展协商的结果走分支。迁移时这类”隐含假设”往往比编译错误更难查，因为它不报错，只是行为变了。
授权加固：从”能跑”到”经得起真实部署”
授权这块同样由 6 个 SEP 推动，目标是让规范更贴近真实的 OAuth 2.0 / OpenID Connect 部署，而不是一个理想化的简化模型。
其中一条值得单独拎出来：要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。RFC 9207 是 OAuth 授权服务器签发响应时标识自己身份的机制，客户端校验 iss，本质上是防止在多授权服务器场景里被混淆——拿着 A 服务器的响应去 B 的上下文里用。做过多租户或者对接多个 IdP 的人对这类问题不会陌生。
对开发者的动作建议：
- 如果你的客户端实现是自己手搓的授权流程，把
iss校验补上，这是要求不是建议。 - 如果你用的是官方 SDK，优先升级 SDK 而不是自己打补丁——授权这种地方，自己实现出错的概率远高于收益。
- 授权相关的改动一般不会有优雅的降级路径，测试环境先跑通再上生产。
MCP 排障本身就不轻松，配置和连接层的常见坑可以参考Claude Code 的 MCP 连不上、配置不生效怎么排查，那篇讲的定位顺序在新规范下依然适用，只是要多加一层”版本是否匹配”的判断。
破坏性变更：12 个月窗口该怎么用
这是全篇最需要认真对待的一段。维护者 David Soria Parra 把这次修订称为自加入授权以来最实质的变更，原话是：“A lot of things that made MCP are gone.”（很多曾经构成 MCP 的东西已经不在了。）
具体的兼容性风险，官方讲得很直白：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然。 配套的缓冲是弃用机制给旧版本 12 个月窗口。
12 个月听起来宽裕，但如果你的 server 有外部用户，实际可用时间会比想象中短，因为你不控制对方的升级节奏。一个相对稳妥的排法：
- 第一步，先盘点而不是先改代码。 列清楚你有几个 server、几个 client、各自跑在哪个 SDK 版本上、有没有第三方在连你的 server。没有这张表，后面所有决策都是拍脑袋。
- 第二步，分清”我控两端”和”我只控一端”。 内部工具链两端都自己管的，升级窗口自己定，风险可控；对外提供 server 的，要按最慢的那个消费方倒排时间。
- 第三步，双轨期尽量拉长。 在窗口内让新旧并行可用，比在某个时间点硬切安全得多。具体能不能并行、怎么并行，取决于你用的 SDK 提供了什么，以官方规范文档和 SDK 当前版本的说明为准。
- 第四步，把”能力假设”当成测试项。 前面说过 Tasks 这类从核心挪出去的能力不会报编译错，得靠集成测试兜住。
- 第五步，别把窗口用满。 留出至少一个季度处理意料之外的问题——授权和传输层的坑通常不会在开发环境暴露。
如果你是刚接触这个协议、还在判断要不要投入的人，建议先看MCP 是什么？为什么说它是 AI 的 USB 接口把概念打底，再回来看这次的变更表。
官方注册表与 Server Cards
配套的生态基建也在往前走。registry.modelcontextprotocol.io 是官方 MCP Registry，提供 server 的发现、文档与 API 参考，由 modelcontextprotocol 这个 GitHub 组织维护，社区驱动。
路线图上还有一项叫 MCP Server Cards：通过 .well-known URL 暴露 server 元数据的标准，让注册表和爬虫不用真正连接就能发现这个 server 有什么能力。这件事的价值在于，能力发现从”连上去问一遍”变成”读一个静态文件”，对做聚合、做安全审计、做选型比较的场景都省事很多。注意这一项属于路线图工作，具体形态与可用时间以官方规范文档当前版本为准。
生态背景：为什么这次改得动
一个协议敢做破坏性变更，前提是它的治理结构和装机量撑得住。
2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会下的 Agentic AI Foundation，从一家公司的项目变成厂商中立、社区治理的标准。这件事直接决定了 SEP 这套提案机制能不能被各家认真对待——OpenAI、Google、Microsoft、AWS 都已经把 MCP 接进了自家的 agent 栈，规范怎么改，不再是单方面通知。
至于规模，按官方与行业公开资料的口径，目前有超过 10,000 个公开 MCP server 在生产中运行，SDK 月下载量超过 9,700 万。这两个数字是公开资料的汇总口径而非精确统计，看趋势即可，别拿去当报告里的准确引用。
顺带提醒一句信源问题：这次规范时效性极强，中文资料几乎没有跟上，网上不少站点还在把 2025-11-25 那一版列为当前稳定版、甚至说下一版”暂定 2026 年 6 月”——这类内容已经过期，不要拿它做判断依据。一律以官方博客和规范文档的当前版本为准。
常见坑 / 注意
- 别把无状态理解成”不许有状态”：变的是协议层不再要求会话追踪，应用层状态该存还得存。
- 升级前先确认对端：新版本 server 与旧 client 可能互不兼容，两端版本要一起看，只升一边容易在生产暴雷。
- Tasks 不再默认可用：它现在是 extension，客户端要按协商结果走分支，别沿用旧的隐含假设。
iss校验是硬要求：自己实现授权流程的，按 SEP-2468 补齐；用官方 SDK 的优先升级 SDK。- 12 个月不是缓冲，是排期：有外部消费方的 server，按最慢的那个人倒排时间。
- 警惕过期教程：还在写 2025-11-25 是当前稳定版的资料一律不采信。
小结
这次 MCP 规范修订的主线，是把协议内核做薄、把工程落地的硬骨头（部署形态、授权）做硬。无状态化让远程 server 终于可以按普通 Web 服务的方式部署，Tasks 移出核心是这一取向的必然代价，授权加固则是把规范拉回真实的 OAuth 世界。破坏性是真实存在的，官方没有回避，给了 12 个月的弃用窗口作为缓冲。对已经在生产里跑 MCP 的团队，现在最该做的不是研究新特性，而是先盘清自己有几个 server、几个 client、谁在连你。至于具体的字段、接口与迁移细节，以官方博客与规范文档的当前版本为准——这块变化太快，任何二手转述都有过期风险，包括这一篇。