升级到新 MCP 规范前，先过这份检查清单
数据截至 2026-07，价格与限额以各官网为准。
这次 MCP 规范修订不是加几个可选字段那么轻松，它动了协议内核：2026-07-28 发布的版本被官方称为自协议发布以来最大的一次修订，新版本的 server 可能无法与旧 client 协同，反之亦然。所以升级前真正该做的第一件事不是改代码，而是把”谁连着我、我连着谁”这张连接图先画出来。
一个常见的误解是：MCP 现在无状态了，意味着 server 不能再保存任何状态。这个理解偏了。变的是协议层不再要求会话追踪，不是”你的业务不许有状态”。你的 server 照样可以有数据库、有用户上下文、有缓存，只是这些东西不再依赖协议帮你维持一条会话通道。分清这两层，后面很多设计取舍才不会做错。
先搞清楚这次改了哪几块
在动任何配置之前，先知道改动的边界在哪。官方博客把这次修订归纳为五个部分：
- 无状态协议内核：协议层去掉会话追踪要求。
- Extensions 框架：把一部分能力从核心里拆出去，用扩展的方式承载。
- Tasks 与 MCP Apps：Tasks 这类长时间运行操作的特性，随框架调整位置。
- 授权加固：让授权规范更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署。
- 正式的弃用策略：这次开始有明确的版本退场机制。
这六块里，前两块影响架构，第三块影响功能可用性，第四块影响能不能连上，第五块决定你有多少时间做迁移。检查清单也按这个顺序排。
第一项：盘点你的部署形态，判断无状态化影响多大
无状态化这一块由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同实现，落实了此前”MCP 传输层的未来”里规划的方向。
对本地跑的 stdio 型 server，这块影响有限——你本来就是一个进程一个连接。真正受影响的是远程 server。此前为了让远程 MCP 能工作，运维侧常见的做法是：负载均衡开粘性会话、多实例之间共享一份 session 存储、网关做深度包检测来判断该往哪转。新规范之后，这些拐弯抹角的手段可以退场，远程 server 可以直接跑在普通的轮询负载均衡后面，按 Mcp-Method 头做路由。
所以第一项检查是问自己三个问题：
- 我的 server 是本地 stdio 还是远程 HTTP 型？
- 如果是远程的，现在有没有依赖粘性会话或共享 session 存储？
- 网关/入口层有没有为 MCP 写过特殊的转发规则？
第二、三个问题只要答”有”，就说明你的基础设施里存在一层为了迁就旧协议而加的补丁。升级时这层补丁不是必须马上拆，但一定要标记出来——它们迟早会变成没人看得懂的历史包袱。
第二项：确认你在用的功能有没有被移出核心
Tasks 特性——也就是用于长时间运行操作的那套机制——已经从核心协议移到了 extension。这意味着它不再是”你实现了协议就自动有”的东西。
对使用者来说要检查的是：你的 server 或者 client 里，有没有依赖长时间运行操作的场景？比如提交一个耗时任务后轮询结果、跑一个需要几十秒甚至更久的分析。如果有，升级后这部分要按扩展的方式重新对齐，而不是假设它还在核心里。
顺带说一个正面的变化：extension 机制允许用户自建扩展，并且能与官方认可的扩展并存。这对有内部特殊需求的团队是好事——以前想加点自己的东西只能改协议实现或者用歪门邪道传参，现在有了一条正规通路。但要注意，自建扩展是你自己的责任范围，别指望别家 client 能理解它。
第三项：授权链路要按真实 OAuth 部署重新对一遍
授权这块同样由 6 个 SEP 支撑，目标是让规范贴近真实的 OAuth 2.0 / OpenID Connect 部署，而不是停留在纸面上的理想模型。
其中一条具体到可以直接写进代码检查项：要求客户端按 RFC 9207 校验 iss 参数（对应 SEP-2468）。如果你自己写过 MCP client 的授权部分，去翻一下你处理授权响应的那段逻辑——有没有真的校验签发方标识。很多早期实现是”能拿到 token 就往下走”，这在新规范下不达标。
检查动作建议是这样的：先列出你的 MCP 链路里所有涉及授权的环节（谁发起授权、谁颁发 token、谁验证），再逐个对照官方规范文档当前版本的授权章节走一遍。这块不建议凭印象改，因为授权的细节条款更新频率高，以官方最新说明为准。
第四项：把”新旧不互通”这件事当成排期硬约束
这是整份清单里最容易被低估的一项。维护者 David Soria Parra 把这次改动称为自加入授权以来最实质的变更，原话是：“A lot of things that made MCP are gone.”
翻译成工程语言就是：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然。 所以升级不是一个可以”我先把 server 升了，client 慢慢跟上”的操作。
好消息是官方给了缓冲：弃用机制为旧版本留了 12 个月的窗口。这 12 个月怎么用，决定了你是从容迁移还是最后一个月通宵。一个务实的排期思路是：
- 前期只做盘点和验证，不动生产。把连接图画出来，标出每一条链路两端各是谁在维护。
- 中期挑一条内部可控、两端都归自己管的链路先升，拿它趟坑。
- 后期处理跨团队、跨厂商的链路——这些最慢，因为对方的排期不归你管。
- 全程保留回退路径，别把旧版本实现太早删掉。
如果你的链路里有一端是第三方提供的 server 或客户端，越早去问对方的升级计划越好。这类沟通的耗时往往比改代码本身长得多。
第五项：借这次机会理一遍你装了哪些 server
升级是一次天然的清理时机。官方维护了一个 MCP Registry（registry.modelcontextprotocol.io），提供 server 发现、文档和 API 参考，由 modelcontextprotocol 这个 GitHub 组织维护，社区驱动。升级前把你实际在用的 server 对着注册表核一遍，能顺手发现两类问题：已经不维护的、和你其实根本没在用的。
路线图上还有一项值得留意的基础设施：MCP Server Cards——一种通过 .well-known URL 暴露 server 元数据的标准，让注册表和爬虫不必真正建立连接就能发现 server 的能力。这个方向落地后，“这个 server 到底能干什么”会变成可以静态查询的信息，对做选型和做安全审计都有帮助。具体形态和进度以官方仓库与规范文档当前版本为准。
如果你还没系统整理过自己装了哪些 MCP，可以先看开发者必装的几个 MCP 推荐理一遍需求，再决定升级时哪些留、哪些砍。
第六项：升级后的连通性验证怎么做
改完之后别只跑一次”能连上”就宣布完成。建议至少覆盖这几种情况：
- 冷启动连接：client 第一次连 server，握手和能力协商是否正常。
- 多实例场景：如果是远程 server 且跑了多副本，故意让请求落到不同实例，确认不再依赖粘性会话也能工作。
- 授权失败路径：故意给一个不对的签发方或过期 token，看有没有按预期拒绝，而不是放行。
- 降级行为：连到一个还没升级的旧端点时，报错信息是否清晰。这直接决定了迁移期间的排查成本。
排查思路上，MCP 连不上的常见根因这几年变化不大——配置文件位置、传输方式选错、路径与权限问题仍是高频项，这部分可以对照Claude Code 的 MCP 连不上怎么排查里的清单先过一遍，把老问题排除掉，再去怀疑新规范。
诚实说局限
有几件事这篇给不了确定答案，需要你自己去核。
一是各家实现的跟进节奏不同。规范发布是一回事，各语言 SDK、各家 client 产品什么时候支持是另一回事。你能不能升，取决于你依赖的那条链路上最慢的那一环。
二是具体条款细节以官方文档为准。这次涉及十几个 SEP，每个都有自己的适用范围和边界条件，一篇中文文章无法替代规范原文。真要动手改实现，请以官方博客和规范文档的当前版本为准。
三是网上的过期信息很多。这次规范时效性极强，中文资料几乎还没跟上，搜索结果里大量内容还停在更早的版本号，甚至有站点仍把旧版本标为当前稳定版、把下一版发布时间写成一个已经过去的日期。看到任何具体版本号和日期，都建议回官方博客确认一次再采信。
顺便看看生态背景，帮你判断该不该投入
如果你还在犹豫要不要花时间跟这次升级，有两个背景信息可以参考。
其一是治理结构变了：2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会下属的 Agentic AI Foundation，它现在是一个厂商中立、社区治理的标准。OpenAI、Google、Microsoft、AWS 都已经把它接进了各自的 agent 栈。这意味着它不再绑定单一厂商的产品节奏。
其二是使用规模：按官方与行业公开资料的口径，公开的 MCP server 数量已经超过 10,000 个在生产中运行，SDK 月下载量超过 9,700 万。这类数字来自公开资料汇总，不是精确统计，看个量级就好——但量级本身说明这不是一个可以观望到明年再说的协议。
对还不熟悉 MCP 基本概念的读者，建议先补一下MCP 是什么、它解决了什么问题，再回头看这份清单会顺很多。
小结
这次 MCP 规范修订动了协议内核，最实际的影响是新旧版本可能无法互通，升级要当成一次有排期的迁移来做，而不是改个依赖版本号。升级前先画连接图，把远程 server 的粘性会话依赖、Tasks 这类被移出核心的功能、授权环节的 iss 校验三处逐一核对。官方给的 12 个月弃用窗口足够从容，前提是你从现在开始排，而不是等到还剩两个月。最后记住”协议层无状态”说的是协议不再帮你维持会话，不是你的应用不许有状态，这两件事别混在一起做决策。所有具体条款和版本细节，以官方博客与规范文档的当前版本为准。