写 MCP 插件的朋友，最近大概都有点分裂：一边是社区天天有人喊「MCP 已死，Skills 才是未来」，连 Perplexity 的 CTO 都公开表态说可能转向 CLI；另一边，7 月 28 日 Anthropic 悄悄推了 MCP 发布以来最大的一次修订，规范版本直接叫 2026-07-28，协议核心从有状态改成了无状态。MCP官方博客
一个协议要是真快死了，不会有人花这么大力气给它动这么大的手术。我把这次的完整 changelog、官方披露的生态数据和社区几篇硬核分析都翻了一遍，今天就讲清楚三件事：这次修订对写插件的人到底意味着什么、哪些代码必须改哪些可以先不动、以及吵了半个月的「MCP/Skills/CLI 之争」到底该怎么站队。
一句话总结这次修订：MCP 把「会话」拆了
如果你只有一分钟，记住这句话就够了。
之前的 MCP 是这么连上的：客户端先发 initialize，服务端返回能力清单，客户端再回一个 initialized 通知，两边握手成功才算建立连接。整个生命周期里服务端维护着一个会话，HTTP 请求还得带着 Mcp-Session-Id 这个头。
2026-07-28 版把这套全拆了。现在每个请求自己带上协议版本和客户端能力（塞在 _meta 字段里），服务端不保存任何会话状态。知乎握手没了，Session-Id 没了，连 SSE 断线续传也一并砍了——断了？整个请求重发就行。
对写插件的人来说，这不是纸面上的架构变化，它直接改变三件事：
第一，MCP Server 可以跑在 Serverless 上了。 Lambda、Cloudflare Workers、Vercel 这些按请求计费的平台，以前因为有状态连接根本带不动，现在没了会话负担，部署成本直接砍掉一个常驻进程的钱。MCP官方博客
第二，水平扩展变得极其简单。 不用做会话绑定，随便挂在哪个负载均衡器后面，请求打到哪台机器都能处理。
第三，如果你的 Server 依赖会话状态，得重写。 比如那种「先调 login 工具、后续调用默认带着登录态」的写法。官方给的替代思路很明确：别把状态藏在传输层，让工具生成一个显式的 Handle（比如一个会话 ID），模型把它当参数在后续调用里传回来。状态摆在明面上，反而更符合大模型的工作方式。
还有个连带改动：以前服务端想向用户要信息（比如「确认要执行删除吗？」），可以主动给客户端发请求；无状态之后服务端没法主动开口了，新做法是返回 resultType: “input_required”，客户端拿到后带上用户输入重新发起同一个调用。这个机制叫 MRTR（多往返请求），之前用过 Sampling 或 Elicitation 的，这块逻辑要跟着改。知乎
三样东西被废弃，但有 12 个月缓冲期
好消息是这次修订不是一刀切。这版规范引入了正式的 Feature 生命周期管理：Active → Deprecated → Removed，中间给至少 12 个月的废弃窗口。MCP官方博客
首批进入废弃名单的是 Roots、Sampling、Logging 三个能力，旧的 HTTP+SSE 传输也在逐步退场。知乎四大 Tier 1 SDK——TypeScript、Python、Go、C#——已经全部同步支持新规范，Rust 版也在 Beta 里了。
所以节奏很清楚：今天不用慌，但如果你的插件打算长期维护，明年这个时候还没动手，就真的连不上了。
对号入座：三类人的迁移优先级
我把受影响的人分成三档，你找到自己的位置就行。
第一类：本地 stdio 小工具玩家。 你的 MCP Server 只在自己机器上跑、用 stdio 拉起、只伺候自己一个客户端——这次修订对你的冲击最小。SDK 升级基本无感，可以先不动，盯着社区把坑踩完再跟。
第二类：已经上线了远程 Server 的开发者。 这次修订就是冲着你来的，清单在这：
拆会话：去掉 initialize 握手和 Mcp-Session-Id 相关逻辑，让每个请求自描述；
需要跨调用保留状态的，改显式 Handle 模式；
用到 Sampling / Elicitation 的，迁移到 MRTR（input_required）；
顺手给 tools/list 的结果做确定性排序——新规范的要求，好处是客户端的 prompt cache 命中率更高，调用方省 token 就是省钱；
做了 OAuth 的，检查 RFC 9207 发行者校验；动态客户端注册（DCR）已被废弃，换成客户端元数据文档（CIMD）的，顺便治一治当年 redirect_uri 报错的老毛病。
动手之前还有一个参考坐标：GitHub 在 7 月 23 日就宣布 GitHub MCP Server 提前支持新规范，官方的口径是——只用现成 MCP Server 的人不需要任何操作，真正要提前准备的是自建服务和定制客户端。微博自检时也别忘了最后一步：别只满足于「能连上」，拿官方 conformance tests 跑一遍协议行为，再补自己的权限和故障测试。
第三类：还没入坑、正在观望的。 现在反而是入场的好时机。直接从新规范起步，无状态 + Serverless，部署和运维成本比一年前低一个量级。生态数据也过了「冷启动」阶段：官方披露 MCP SDK 月下载量已突破 4 亿、今年翻了 4 倍，TypeScript 和 Python 两个 SDK 累计下载均破 10 亿，Claude 应用商店里的 MCP 服务器超过 950 个。36氪蛋糕开始变大了，你要想的是自己切哪一块缝。
「MCP 已死」到底是不是真的
这半个月知乎、小红书上「Skills 和 MCP 谁取代谁」吵得很凶。我的判断是：这三个东西不是替代关系，是分工关系，争错了问题。
拿大家都在用的官方 GitHub 插件拆开看：它由 4 个 Skill 加 1 个 MCP 组成。知乎Skill 管「怎么干」——PR 流程、Debug 流程、Commit 规范，本质是工作流手册；MCP 管「怎么连」——跟你的 GitHub 账户做认证和通信。API 密钥总不能写进 Skill 文件里公开展示吧？连接和鉴权这一层，天然就是 MCP 的位置。
CLI 之所以给人「要取代 MCP」的错觉，是因为大模型天生擅长执行命令行，而像 GitHub CLI 这类工具又足够成熟，个人小项目里确实更省事。但只要场景涉及权限控制、企业级认证、跨客户端复用，MCP 的位置短期内没人动得了——这次 v5 专门加了企业级托管认证（EMA），能直接对接 Entra、Okta 这类身份系统，摆明了是冲着企业预算去的。Figma、Intuit、Netlify、Zoom 的高管也在官方发布后集体站台，无状态架构对 Netlify 这种 Serverless 基因的公司尤其对味。MCP官方博客
所以站队问题可以这么解：你的插件教 AI「怎么做事」，写 Skill；你的插件要替 AI「连上一个需要鉴权的外部系统」，写 MCP；你的目标用户全是终端老手，优先考虑 CLI。先回答「我的插件干什么」，再选形态。
顺手提两个值得留意的变化
一是 MCP Apps 扩展。新版允许服务端直接在对话框里渲染交互式 UI——图表、表单、控制面板，套在安全沙盒里。知乎如果你的插件有「返回一张报表」这类需求，这是明显的体验升级点。
二是多客户端重复配置的老痛点。MCP 协议只管「怎么对话」，不管「配置放哪」，结果是同一个服务器要在 Claude Desktop、Cursor、Claude Code、Codex 里各配一遍：4 个客户端 × 3 个服务器 = 12 份格式各异的配置条目，散落在 4 个不同位置。知乎专栏现在社区已经出现集中网关类工具来收拢这份清单，重度用户（有人单机挂着 45 个 Skill 加 5 个 MCP）可以关注这个方向。
最后说句实在的。这次修订透露的信号很清楚：MCP 想当 AI 时代的 HTTP——基础、无聊、没人天天夸它，但谁都离不开。对写插件的人来说，真正的问题从来不是「协议会不会死」，而是你的插件有没有在解决某个具体的真问题。会话都拆了，架子也搭好了，接下来拼的是内容。
