从兴趣小组到官方工作组：ext-skills决策日志背后的5大关键设计取舍

ext-skills是 MCP（Model Context Protocol，模型上下文协议）官方Skills 扩展（io.modelcontextprotocol/skills）的官方仓库，由 Skills Over MCP 工作组维护。如果你想理解 MCP Skills 的发现、分发与消费机制是如何设计出来的，这份仓库里的决策日志就是最好的"第一手史料"——它用 ADR（架构决策记录）格式，完整记录了工作组从兴趣小组成长为官方工作组路上的每一次关键取舍。本文带你读懂其中 5 个最能代表项目设计哲学的重要决策。

📖 背景速览：ext-skills 与 MCP Skills 扩展工作组

ext-skills 仓库承载了 MCP 生态中"技能（Skills）"这条线的官方工作，核心资料如下：

一句话概括工作组的起点：MCP 生态原本高度"工具（Tools）中心化"，缺少一套标准方式来分发更丰富的上下文——尤其是以 Markdown 形式编写的"技能"。这份问题陈述列出了四个痛点：服务器指令只能在初始化时加载、复杂工作流超出指令大小限制、没有发现机制、多服务器编排困难。

🔀 取舍一：Instructor 还是 Helper？——Skill 的内容形态之争

这是工作组在 2026 年 2 月 14 日首会就拍板的第一条决策（决策日志 2026-02-14 条目）：

MCP 分发的 Skill 采用instructor 格式（结构化 Markdown 内容），helper 模型（执行本地脚本/代码）明确排除在外。

三个理由都很务实：

1. 已有替代方案：需要本地执行代码的 helper 类技能，本来就有仓库、npx 等分发渠道，不需要 MCP 来"运输"代码
2. 安全性更好审计：静态的教学内容远比"任意可执行代码"容易做安全审查
3. 更贴合 MCP 定位：MCP 是上下文协议（context protocol），instructor 格式在远程和本地服务器间都更便携

对新手来说，这条决策划定了理解 MCP Skills 的第一条边界：它是"教 Agent 怎么做"的说明书，不是"替 Agent 执行"的代码包。

🧩 取舍二：Skills as Resources——不造新原语的复用之道

MCP 已有 Tools、Resources、Prompts 等原语，Skill 到底用哪个装？

社区在早期就提出：既然 Skill 本质是文件，而 MCP Resources 天生就是"带 URI 的可寻址文件"，那就应该直接复用（决策日志 2026-02-21 条目）。工作组最终采纳Skills as Resources路线，其设计理由是：

• 免费继承 URI 寻址、resources/read读取、资源订阅（变更通知）和现成客户端工具
• 新增原语会复制大部分现有能力，还给生态增加复杂度
• 符合 MCP "可组合性优于特异性（Composability over specificity）"的社区设计原则

被放弃的替代方案（SEP-2076 提议的新原语）虽然能力协商更干净，但代价是把 Skill "拍平"成只有名字的地址化数据块，丢失了 Agent Skills 规范定义的目录模型——而支持文件正是依赖这个目录模型的。

💡 一句话总结：能用原语解决的，绝不发明新机制。

🔗 取舍三：skill:// URI 规范——"末段即 name"的金发姑娘折中

多个独立实现（FastMCP、NimbleBrain、skilljack-mcp 等）不约而同收敛到skill://这个 URI scheme，但结构五花八门。工作组最终敲定的推荐格式是：

skill://<skill-path>/SKILL.md

其中最有意思的是<skill-path>的约束（决策日志 2026-04-16 条目），它经历了两个失败草案才找到"金发姑娘"式的中庸：

配套规则还包括：SKILL.md必须在 URI 中显式出现（镜像 Agent Skills 的目录模型）、支持文件按相对路径寻址（如skill://<skill-path>/references/GUIDE.md）、服务器也可使用自有域名 scheme，但需满足同样的结构约束。

⚖️ 取舍四：从兴趣小组到官方工作组——形式与职能对齐

MCP 社区治理中有两种组织形态（决策日志 2026-04-16 条目）：

• 兴趣小组（IG）：聚焦"识别值得解决的问题"，产出非约束性建议
• 工作组（WG）：协作产出 SEP（标准扩展提案），做出约束性决策

Skills Over MCP 于 2026 年 2 月 1 日以兴趣小组身份成立，但几周后产出已经"越界"：不仅在做问题定义，还在推进 Skills Extension SEP、搭参考实现、跨工作组协调。继续用 IG 的形式，就出现了权责不匹配的尴尬——干着 WG 的活，却没有对应的决策权。

2026 年 4 月 16 日，工作组正式升级。升级后的决策链是：懒惰共识（lazy consensus）→ 正式投票 → 升级仲裁，规范变更还需 WG 共识 + 核心维护者批准；同时确认了双人 Lead 模型，赋予其在会议安排、提案优先级和范围内 SEP 分诊上的自主权。

这条决策的启示：当产出已经越过组织形式的边界时，宁可改形式、也别改职责。

✂️ 取舍五：v1 范围大瘦身——为什么砍掉 archives 和 index.json

这是决策日志中最"痛"也最精彩的一条（2026-07-16 条目）。2026 年 6 月底，核心维护者会议将 SEP-2640 的投票暂缓，提出多个结构性顾虑，其中最大障碍是archives（压缩包分发）：解压本身是攻击面（解压炸弹、路径穿越、符号链接逃逸），两种分发方式并存还破坏兼容性底线。

工作组听取"先做小、先落地、再叠复杂度"的指引，在 7 月一次性完成 v1 瘦身：

另有两条常被忽略的补充：skill://被明确为非特权scheme（宿主判断某资源是不是技能，靠skills/list/skills/get的答案，而不是看 URI 前缀）；同名 Skill 的冲突处理被写成规范级要求（name只是标签，uri才是身份）。

最终 v1 的协议面非常克制：两个必选方法（skills/list、skills/get）+ 一个可选方法（resources/directory/read），没有其他任何新方法、新消息类型。

🧭 延伸阅读：如何继续深入 ext-skills

• 想了解"为什么复用 Resources"等 8 组设计问答：docs/rationale.md
• 想查看各 SDK / 服务器 / 客户端的实现进度：docs/implementations.md
• 想给规范提变更建议？流程写在 AGENTS.md 与 CONTRIBUTING.md：在决策日志新增一条Status: Proposed的 ADR 条目，PR 本身就是提案
• 想回顾 SEP 定稿前的完整设计史：docs/archive/ 保存了问题陈述、URI 调研、威胁模型等全部冻结文档

写在最后

从 2026 年 2 月的兴趣小组，到 9 月 SEP-2640 标记 Final，ext-skills 的决策日志展示了一条教科书式的路径：先对齐内容形态（instructor），再对齐承载原语（Resources），再对齐寻址规范（skill://），最后用"先落地再迭代"的 v1 瘦身换取规范的可接受性。如果你正在做 MCP 相关工作，或者只是好奇"一个开放标准是怎么一点点谈出来的"，这份决策日志都值得完整读一遍。