新旧 MCP 版本不兼容怎么办：12 个月弃用窗口怎么用
数据截至 2026-07，价格与限额以各官网为准。
面对这次 MCP 规范的破坏性变更，最稳妥的做法不是立刻全量升级，而是先把「谁连谁」这张图画出来，再利用官方给旧版本留的 12 个月弃用窗口做分批迁移——协议层允许你新旧并行一整年，真正会咬人的是你自己没数清楚有多少地方在用它。
先承认一个很常见的误解：不少人以为协议升级跟依赖包升个小版本差不多，改个版本号、跑一遍 CI 通过就算完事。这次不是。官方把 2026-07-28 这一版称为自协议发布以来最大的一次修订，维护者 David Soria Parra 的原话是 “A lot of things that made MCP are gone.”（很多曾经构成 MCP 的东西已经没了）。文档里也写得很直白：新版本的 server 可能无法与旧 client 协同，反之亦然。这不是”可能有小概率不兼容”，是双向的、结构性的。
如果你还不清楚 MCP 到底是什么、在整条链路里扮演什么角色，可以先看 MCP 是什么 补一下背景，再回来读这篇。
这次到底改了什么，先分清哪些跟你有关
新规范大致可以分成这么几块：无状态的协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，以及一套正式的弃用策略。听起来一大坨，但对不同角色影响完全不一样，别一上来就以为每条都要处理。
协议层无状态化，是这次改动最大的一处，由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同实现，兑现了此前 “The Future of MCP Transports” 里的计划。要点是：协议层不再要求会话追踪。带来的实际好处很具体——以前部署远程 server 需要粘性会话（sticky session）、共享 session 存储、甚至让网关做深度包检测，现在可以直接跑在普通轮询负载均衡后面，按 Mcp-Method 头做路由。
这里要提醒一句，别把”无状态”理解成”MCP 不能有状态了”。变的是协议层不再强制要求维护会话，你的应用层想怎么存状态还是怎么存，这是两件事。
Tasks 移出核心。原本用于长时间运行操作的 Tasks 特性，从核心协议挪到了 extension 里。同时用户可以自建 extension，与官方认可的 extension 并存。如果你的 server 依赖长任务语义，这块要单独确认迁移路径。
授权加固，同样由 6 个 SEP 组成，目标是让授权规范更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署。其中一条很具体：要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。做企业内网 SSO 对接的团队，这条是必看项。
对照一下你自己的情况：只是在编辑器里挂几个本地 stdio server 的个人用户，受冲击最小；自己写了远程 server 对外提供服务的，无状态化和授权这两块都躲不掉。
12 个月弃用窗口，该怎么排这一年
官方的弃用机制给旧版本留了 12 个月窗口。这一年不是让你拖到最后一个月再动，而是给你分阶段验证的余地。一个可操作的切法是这样：
第一段（拿到消息后的头一两个月）：只做盘点，不改代码。 列出三类东西——你在用的 client（编辑器、agent 框架、自研应用）、你在用的第三方 server、你自己维护并对外提供的 server。第三类是重点，因为你一改，下游所有人都会受影响。盘点时顺手记下每个东西当前跑的协议版本、谁在维护、有没有活跃更新。这一步听着枯燥，但绝大多数迁移事故都是因为漏了某个”没人记得还在跑”的服务。
第二段（第 3 到第 6 个月）：在隔离环境里跑双版本。 先挑一个非关键的 server 升到新规范，用新旧两种 client 分别连一遍，把报错记下来。这个阶段的目标不是修好，是摸清楚”到底哪里会断”。
第三段（第 6 到第 10 个月）：分批切生产。 从依赖最少的开始，最后才动核心链路。每切一个观察一段时间，别一个发布窗口全推。
第四段（最后两个月）：清尾巴。 处理那些拖着没升的、以及外部依赖方还没跟上的情况，留出缓冲。
把最后两个月当缓冲而不是当工期，是这套排期里唯一需要死守的纪律。
双版本并行的几个实操要点
窗口期内你大概率会处于新旧共存的状态，有几件事值得先想好。
协议版本协商要看清楚握手结果。 排查连接问题时，第一件事是确认双方实际协商到了哪个版本，而不是凭配置文件里写了什么去猜。很多”连不上”的表象背后是版本不匹配，跟配置写没写对无关。
server 侧建议先支持旧版一段时间再摘。 如果你的 server 有外部使用者，直接切到只支持新版等于替对方做了决定。反过来，如果只是团队内部自用、client 你自己也能控，那快速切干净反而更省事。
client 侧升级前先看第三方 server 的进度。 你把编辑器或 agent 框架升到新版，结果一半 server 连不上，体感会比不升级更差。装 server 之前确认一下维护状态，具体挑选思路可以参考 MCP 服务器推荐与安装。
报错先按老套路排一遍再怀疑版本。 配置路径、启动命令、Node 环境、权限这几个老问题，出现频率远高于协议不兼容。Claude Code 的 MCP 连不上怎么排查 那套清单仍然适用，走完一遍还是连不上，再往版本方向查。配置字段本身的写法可以对照 通用 MCP 配置教程。
怎么找到可信的当前信息
这次改动时效性很强，中文资料几乎是空白，这就带来一个很实际的风险：你搜到的东西可能已经过期，而它看起来一点也不像过期的。
已经能观察到的情况是，有的站点仍然把 2025 年 11 月那一版列为当前稳定版，还写着下一版”暂定 2026 年 6 月”。这类内容不是恶意的，只是没跟上，但你照着它做技术决策就会跑偏。
判断信息新旧，有几个笨但有效的动作：一是看它有没有提到无状态内核、Extensions、弃用策略这几个关键词，没提到基本可以判定是旧内容；二是一切以官方博客和规范文档的当前版本为准，二手教程只当参考；三是查 server 时用官方注册表 registry.modelcontextprotocol.io，它提供 server 发现、文档和 API 参考，由 modelcontextprotocol 这个 GitHub 组织社区驱动维护。路线图里还有一项叫 MCP Server Cards，思路是通过 .well-known URL 暴露 server 元数据，让注册表和爬虫不用真的连上去就能发现能力——这项落地后，判断一个 server 支持什么会比现在省事很多。
为什么这次值得认真对待
看背景会更容易理解为什么规范会做这么大的动作。2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会下的 Agentic AI Foundation，它从此是一个厂商中立、社区治理的标准。OpenAI、Google、Microsoft、AWS 也都已经把它接进各自的 agent 栈。
按官方与行业公开资料的口径，目前有超过 10,000 个公开 MCP server 在生产中运行，SDK 月下载量超过 9,700 万。这类生态数字是汇总口径而不是精确统计，不必当成决策依据，但它说明一件事：这已经不是一个小圈子里的实验协议，一次破坏性变更牵动的面很宽。反过来说，正因为面宽，官方才给了 12 个月这么长的窗口——这个长度本身就是一种信号，说明它预期迁移是需要时间的。
诚实说局限
这篇能给的是排期方法和思路，给不了逐条的 API 差异对照表。原因很简单：规范刚发布，各家 SDK 和 client 的跟进节奏不一样，任何具体的”改哪一行”的建议都可能几周内就不准。SEP 编号、字段名、协商细节，请一律以官方博客和规范文档的当前版本为准。
另外，本文提到的窗口期切法是通用工程经验，不是官方的迁移指引。你的实际排期该多快多慢，取决于你有多少存量、下游有多少使用者、能承受多长时间的双版本维护成本，这个只能自己判断。
小结
MCP 在 2026-07-28 发布的新规范是协议发布以来最大的一次修订，新旧版本双向可能不兼容，不是小版本升级。官方给了旧版本 12 个月弃用窗口，把它当成”盘点—隔离验证—分批切换—清尾巴”四段来用，别拖到最后两个月才动手。协议层无状态化和授权加固对自建远程 server 的团队影响最大，只挂本地 server 的个人用户冲击有限。信息源要盯官方博客、规范文档和官方注册表，警惕那些仍把旧版本写成”当前稳定版”的过期教程。具体改哪一行，以官方最新说明为准。