MCP Extensions 框架：自己写扩展是怎么回事
数据截至 2026-07，价格与限额以各官网为准。
Extensions 框架的意义不是”多了一个插件系统”，而是 MCP 把核心协议主动瘦身了：以前想加一个能力，只能等它进核心规范；现在核心只保留最小共识，剩下的都往扩展里放——连原本用于长时间运行操作的 Tasks，都已经从核心协议移到了扩展。这意味着”自己写扩展”从边角能力变成了官方明确认可的正常做法。
先承认一个常见误解：很多人一听”扩展机制”，默认它是给第三方留的后门，官方功能走核心、自己的私货走扩展，两者地位不平等。这次的设计恰恰相反——官方在说明里明确写了，用户可以自建 extension，并与官方认可的 extension 并存。也就是说，扩展不是二等公民的容身处，而是新能力进入生态的常规通道，Tasks 就是活生生的例子：它没有留在核心里，而是自己搬进了扩展。
先看清背景：这次改的不只是加了个扩展点
2026-07-28 发布的这版规范，官方的定性是自协议发布以来最大的一次修订，之前已经放出过 release candidate。它兑现的是 2026 年的路线图，一共六块：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，以及一套正式的弃用策略。
这六块不是并列的五个新功能，它们内部是有因果关系的。核心协议要瘦身，被拿掉的部分就得有地方去，Extensions 框架就是那个”去处”；核心一旦频繁增删，就必须配一套正式的弃用策略，否则生态会被撕碎。所以理解扩展机制，得先理解核心为什么要瘦。
瘦身最明显的一处是无状态化。MCP 现在在协议层是无状态的，这一步由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同实现，完成了此前”The Future of MCP Transports”里的计划。实际影响很具体：以前需要粘性会话、共享 session 存储、网关做深度包检测才能跑起来的远程 server，现在可以直接放在普通轮询负载均衡后面，按 Mcp-Method 头路由就行。
这里要拧一个特别容易走偏的理解：“无状态”说的是协议层不再要求会话追踪，不是”MCP 不能有状态了”。你的业务照样可以有会话、有上下文、有持久化，那是应用层的事。协议不再强制要求传输层维持会话，只是把这个约束从下面挪走了，不是把状态本身取缔了。这两句话差别很大，看到”MCP 变无状态了”就以为要重写业务逻辑的，多半是把这两层混了。
如果你对 MCP 的基础模型还不熟，建议先看MCP 是什么？为什么说它是 AI 的 USB 接口，再往下读会顺很多。
Tasks 搬家：一个看得见的样本
Extensions 框架讲抽象没意思，好在官方直接给了一个现成样本——Tasks 特性，用于长时间运行的操作，已经从核心协议移到了 extension。
这件事值得多想一层。长时间运行的操作是 agent 场景里几乎必然会碰到的需求：跑一个耗时几分钟的构建、发起一个要等人工确认的审批、调一个异步的批处理接口。按老思路，这么普遍的需求理应留在核心。但它被挪出去了，说明这次划分核心的标准不是”有多常用”，而是”是不是所有实现都必须有”。
对你的实际影响是：如果你在做的 server 依赖长任务语义，它现在是一项需要声明和协商的扩展能力，而不是可以默认假定对端支持的核心能力。对端不支持时会怎样、怎么优雅降级，这些是你要自己想清楚的工程问题，不能再指望”反正协议里有”。
具体的扩展声明格式、协商流程、命名规则这些细节，我不在这里凭印象复述——这版规范刚落地，字段和写法只应该以官方规范文档与官方博客的当前版本为准。写错一个字段名，比不写更浪费你的时间。
自己写扩展之前，先想清楚三件事
即便还没读到具体 API，有三件事是可以先定下来的，而且它们比 API 细节更影响成败。
第一，先判断这件事该不该做成扩展。 扩展的价值是让”核心没有、但你确实需要”的能力有个规范的落脚点。如果你要的能力用现有的工具（tool）调用就能表达清楚，那就别做扩展——多一层协议约定，就多一层要跟所有对端对齐的成本。真正适合做扩展的，通常是那种改变交互形态的能力：需要多轮往返、需要对端理解某种新的生命周期、单靠一次工具调用表达不了的。Tasks 之所以是扩展而不是一个工具，就是这个道理。
第二，先设计降级路径，再设计能力本身。 扩展的默认前提是对端可能不支持。所以在动笔写扩展之前，先回答：对端不支持时，你的 server 是直接报错、退回同步阻塞、还是只暴露一个功能受限的版本？这个决定会反过来影响你的能力怎么切分。经验上，把一个大扩展拆成”必需的小核心 + 可选的增强”，比做一个要么全有要么全无的大扩展，在真实生态里活得久得多。
第三，先想清楚你的扩展给谁用。 只在你公司内部两端之间用的私有扩展，和想让公开 client 都支持的通用扩展，工程标准完全不一样。前者你可以两端一起改、一起发版；后者你要面对的是一个你控制不了的、版本参差不齐的客户端世界。绝大多数人写的扩展属于前者，但很多人是按后者的心态去设计的，结果把简单问题做复杂了。
授权这块单独说：加固意味着更严
六块里的授权加固同样是 6 个 SEP，方向是让授权规范更贴近真实的 OAuth 2.0 / OpenID Connect 部署。其中一条点了名：要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。
“更贴近真实部署”翻译成人话就是更严。以前能糊弄过去的实现，现在可能过不了。校验 iss 这件事本身在标准 OAuth 世界里不是新鲜要求，它防的是授权响应被混淆到错误签发方的那类问题；但如果你的 server 是照着早期 MCP 示例攒出来的、授权那块本来就写得比较随意，那这次很可能要动。
写扩展的人尤其要注意：扩展不是授权的法外之地。你新增的能力如果涉及敏感操作，它照样落在这套加固后的授权模型下面。别把权限判断塞进扩展自己的逻辑里当成”我这层自己管”，那是把安全边界画在了错误的位置。
具体每个 SEP 改了什么、要求实现方做哪些动作，以官方规范文档为准，这里不逐条转述。
最扎心的部分：旧代码可能直接不通
这是全篇最该认真对待的一节，而且跟你写不写扩展没关系。
维护者 David Soria Parra 对这次改动的定性是：自加入授权以来最实质的变更，原话是”A lot of things that made MCP are gone.”——构成 MCP 的很多东西没了。这不是营销话术，配套的事实是：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然。
好消息是官方同时给了缓冲：弃用机制给旧版本 12 个月窗口。这是一个明确的、可以拿去排期的数字，而不是”未来某天会停”。
那这 12 个月该怎么用？给几条可操作的做法：
- 先做一次盘点，再谈升级。 把你手上的 MCP server 和 client 分两栏列出来，标清楚每一个是你能控制的（自己维护、能改能发版），还是你控制不了的（别人的 server、用户装在自己机器上的 client）。真正的风险几乎全在第二栏。
- 别在同一次改动里既升协议又加功能。 升级到新规范本身就是一次有破坏性风险的迁移，跟业务功能混在一起改，出问题时你分不清是协议不兼容还是自己写错了。
- 保留可回退的旧版部署。 在窗口期内，新旧并行跑一段时间比一刀切安全得多，尤其当你的 client 装在别人机器上、你无法强制升级的时候。
- 把 12 个月当排期起点，不是截止线。 窗口的意义是让你有序迁移，不是让你在第 11 个月才开始。
- 升级前后都跑一遍连通性验证。 MCP 配置和连接本身就是常见坑区，排查思路可以参考Claude Code 的 MCP 连不上、配置不生效怎么排查和Claude Code / Cursor 通用 MCP 配置教程，别把协议不兼容和配置写错混为一谈。
写完的扩展怎么被人找到
registry.modelcontextprotocol.io 是官方的 MCP Registry，提供 server 发现、文档与 API 参考，由 modelcontextprotocol 这个 GitHub 组织维护，社区驱动。如果你写的 server 想被别人用到，这是官方的发现入口。
路线图上还有一项相关工作值得留意：MCP Server Cards——一个通过 .well-known URL 暴露 server 元数据的标准，目的是让注册表和爬虫不用真的连上你的 server，就能发现它有什么能力。对写扩展的人来说，这条的潜台词是：你的能力声明将来会被离线读取，所以元数据要当成对外的正式接口来写，而不是随手填的描述文字。
想看看别人的 server 长什么样，可以先从开发者必装的几个 MCP 推荐：装这几个就够里挑几个读源码，比看抽象文档快。
这套东西为什么值得你认真对待
一个协议的扩展机制值不值得学，取决于这个协议会不会活下去。几个背景事实：2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会下的 Agentic AI Foundation，它成为一个厂商中立、社区治理的标准；OpenAI、Google、Microsoft、AWS 都已经把它接进了自家的 agent 栈。
生态规模方面，按官方与行业公开资料的口径，公开在生产中运行的 MCP server 超过 10,000 个，SDK 月下载量超过 9,700 万。这两个数字是汇总口径而不是精确统计，当量级看就好，别拿去做精确论证。
诚实说局限
几点必须讲清楚：
- 这版规范刚落地，中文资料几乎为零。 具体的扩展 API 形态、字段命名、协商流程，请一律以官方博客与规范文档的当前版本为准，本文有意没有复述这些细节。
- 网上的过期信息比你想的多。 有站点到现在还把 2025-11-25 那版列为当前稳定版、把下一版说成”暂定 2026 年 6 月”，这类内容已经过期，看到直接跳过。判断一份 MCP 资料新不新，最快的办法是看它提不提无状态内核和 Extensions 框架。
- 规范文档、注册表和相关代码仓库都托管在境外。 这几家平台官方并未面向中国大陆开放，以各官网当前的地区政策为准；本文不提供也不背书任何第三方中转渠道。
- 本文不替官方对兼容性下承诺。 “可能无法协同”是官方措辞，你的具体组合到底通不通，要自己实测。
小结
Extensions 框架的本质是核心协议主动瘦身：核心只留最小共识，其余能力往扩展里放，Tasks 从核心搬进扩展就是官方给的示范。自建扩展与官方认可的扩展并存，这是被明确写进设计里的，不是权宜之计。写扩展之前，最该先定的三件事是”该不该做成扩展""对端不支持怎么降级""给谁用”，这些比 API 细节更决定成败。最需要立刻排期的其实不是写扩展，而是应对破坏性变更——新旧版本可能互不兼容，弃用窗口是 12 个月，拿这个数字去做迁移计划。至于具体怎么写，等你手边打开官方规范文档时再逐字对照，别信任何凭记忆复述的字段名，包括这篇。