10 月 21 日，API Evangelist 的 Kin Lane 做了一件很多协议工作组不太愿意面对的事：他把自家目录里登记的每一个 MCP 服务器都敲了一遍门，问同一个问题——你支持技能扩展吗？

结果是：9,170 个端点、3,765 家供应商，只有 1,450 个端点（来自 1,003 家供应商）愿意接受匿名握手。在这 1,450 个里，按技能扩展规范正确实现的有 4 家。如果算上他自己建的 APIs.io，是 5 家，而他明确说不算自己。

4 比 1,003。而技能扩展（SEP-2640，Skills Extension）从草案转正式，是 9 月 13 日的事，到现在刚好五周。

这个数字本身不值得恐慌——五周太短了。真正有价值的是调查里另外两组数字：它们揭示的并不是「大家不愿意用技能」，而恰恰相反，是「大家太想用了，所以先自己发明了一遍」。

技能扩展到底规定了什么

先说清楚规范内容，否则后面的对比没有意义。

一个 Agent Skill 就是一个文件夹，根目录放一个 SKILL.md，里面写名字、描述，以及智能体执行某类工作时应该遵循的指令，外加它需要的脚本和参考文件。在此之前，技能主要放在代码仓库里或者本地磁盘上——这对有文件系统的智能体没问题，对跑在浏览器或手机上的智能体就很尴尬。

技能扩展把技能搬到 MCP 服务器上。服务器在 initialize 返回的 capabilities 里声明 io.modelcontextprotocol/skills，就算支持该扩展。每个技能拿到一个 skill:// URI，SKILL.md 是入口，配套文件作为同路径下的 resources 暴露。客户端通过 skills/list 列出技能，技能文件同时也会出现在普通的 resources/list 里。

维护者在评审中敲定的两个细节值得记住：技能的身份是「服务器 + URI」，不是技能名；客户端不应该一上来就把所有技能和文件全量下载，这是对服务器的保护。

这个扩展不属于核心协议，是可选加入、独立版本化的，官方 conformance 仓库里有测试套件，TypeScript、Python、C# 的 SDK 支持还在推进中。

四家做到了规范的样子

Hugging Face（huggingface.co/mcp）是四家里实现最深的。它服务的技能就是自己平台的「工作材料」：hf-cli、hf-mem，以及一组 SageMaker 部署技能，覆盖 AWS 上下文发现、Python 环境配置、IAM 预检、推理镜像选择、部署规划器和生产默认值。它们不止带一个 SKILL.md——环境配置那个技能还带着 requirements.txt 和两个 Python 脚本作为 resources。

值得一提的是，这个服务器协商的协议版本是 2025-11-25，而且执行得很硬。Kin Lane 第一次跟进调用时用了更新的协议头，Hugging Face 直接返回了一个明确指出不匹配的错误——正如一个服务器该做的那样。

Glean（developers.glean.com/mcp）的开发文档服务器提供两个技能：docs-research 用来在它的开发者文档里翻找答案，connect-glean-remote-mcp 用来把智能体接到 Glean 的远程 MCP 服务器上，还附带一份故障排查参考。

这是我认为最值得推广的技能用法：让产品自己教会智能体怎么用这个产品。

Renoolab（mcp.renoolab.fr/mcp）是法国的一家建筑行业平台，四家里打包得最整齐。两个技能，一个教工匠配置和调整自己的档案，一个帮承包商扩客户群、提升曝光，全用法语写，两者之间挂了 50 个 resources：参考文档、平台动作清单，每个技能文件夹里还有一个 agents/openai.yaml。它还同时声明了 MCP Apps 扩展，是少数同时用两个扩展的服务器，并且从 Cloudflare Workers 镜像提供同样的内容。

BestPrice（mcp.bestprice.gr/mcp）是希腊比价服务，只提供一个技能 bestprice-shopping，教智能体如何用它的搜索、优惠和价格历史工具做只读的购物决策。一个技能，干净利落，同时出现在 skills/list 和 resources/list 里，README 也写了。

更值得看的数字：协议版本本身

调查里最能说明问题的一句话是这个：在 1,450 个响应端点中，只有 44 个协商的是当前版本 2026-07-28。多数还停在 2025-11-25（615 个），544 个甚至还在 2024-11-05。

扩展层面，扩散最快的其实是 MCP Apps，有 45 个端点声明；Tasks 只有 2 个。

所以真实图景不是「技能扩展被冷落」，而是整个 MCP 生态的版本迁移速度本来就慢。7 月 28 日那次被称为「史上最大更新」的规范——去会话化、无状态 HTTP 传输、多轮往返请求、基于头的路由、可缓存列表结果、正式的扩展框架——上线快三个月，采用率只有 3%。任何在这个协议上加盖的新扩展，都要先等这一波版本迁移跑完。

十七家的野生版本

比 4 家合规实现更有意思的，是那 17 家已经决定「技能就应该放在我的 MCP 服务器上」、但各自发明了一套办法的公司。

教智能体用产品的：AWS 的 MCP 服务器有个 aws___retrieve_skill 工具，返回某个技能的 SKILL.md 或它里面的某个文件，你需要先搜文档、拿到技能名再传进去，这个服务器在目录里横跨 AWS 的八个服务条目。Timescale（TigerData）有个 view_skill，工具描述里直接把 11 个技能全部列了出来：Postgres/PostGIS 表设计、找 hypertable 候选、迁移到 hypertable、pgvector 语义检索、混合 BM25 检索、零停机 schema 迁移、schema 探索、TimescaleDB hyperfunctions——一个很好的目录，只是用非标准的方式呈现，离规范只差一次改动。Daloopa 用 list_skills / get_skill 提供投资工作流。MyBotsPro 用同一对工具提供 UGC、产品、广告、电影级生成的 Mira playbooks，其中 get_skill 先返回一个 SKILL.md 路由、再按需返回各个章节——手工实现的渐进式披露。Jentic 把智能体指向 skill://onboard-jentic-one 资源，URI scheme 完全正确，但没声明扩展。

会动手的技能：Browser Use 有 list_skills 和 execute_skill。在这里，技能是一段录好的自动化，几毫秒跑完，不用开浏览器；工具描述里告诉智能体「先检查有没有技能，再退回到完整的浏览器任务」。同一个词，完全不同的意思，因为这些技能是用来执行的，不是用来指导的。

客户自带的技能：Anthropic 的 Claude 平台 MCP 接口有 list_skills 和 create_skill，管理工作区的自定义 Agent Skills。Cequence 在它的 AI 网关里做了 Skill Registry，创建、列出、获取技能的工具，旁边就是挂给智能体的 DLP 策略。Fundamental Research Labs 的 list_skills 覆盖默认、个人、团队三层。Jedify 用 load_skill 取账户用户自己写的 markdown playbook。Unisson 用 list_skills 列出可复用技能。

技能本身就是产品：Wato 有最完整的一条生命周期——列出已发布技能、按 Markdown 取回、按路径取打包脚本或参考、存草稿、发布、把一段对话里的连接器动作蒸馏成新技能。Skillsync 做读取、安装、列表、发布。Skills Directory 做搜索、下载 ZIP、读技能的安全评级和发现项、扫描你正在写的技能。Knostic 的技能目录带扫描状态，可以按仓库触发按需安全扫描。TARX 做技能发现和列表，私有的和本地的技能留在本地运行时。lvlltd 是付费技能市场：免费搜索预览，用 x402 报价，付款后拿到密封文件和 SKILL.md 安装路径。

17 比 4。而这一切都发生在规范发布之前或之后不久。

三个判断

第一，需求先于标准存在，标准是来收敛的，不是来创造需求的。

这些公司不是被规范说服才把技能放上 MCP 服务器的，而是早就有这个需求，各自造了一个名字略不一样、形状略不一样的工具。Anthropic 在推动开放标准之前，Claude 生态里已经积累了大量的内部技能实践——标准化做的事是把存量实践格式化，所以标准一落地，仓库数量就出现了陡峭的增长曲线。

但代价也很直接：一个已经学会 skills/list 的智能体，能找到 Glean 的技能、Hugging Face 的技能、BestPrice 的技能，不需要有人告诉它工具叫什么名字。而一个遇到 Timescale、Daloopa 和 AWS 的智能体，得先读三份工具描述，才能学会三套约定。这正是标准存在的意义。

第二，最容易迁移的是「教产品」那一类，最难的是「市场与注册表」那一类。

教产品的那批（Hugging Face、Glean、BestPrice、Timescale、AWS）内容本来就是 SKILL.md，他们只需要改提供方式，基本是一次改造的事。

市场、注册表、扫描、评级、付费这一批（Wato、Skillsync、Skills Directory、Knostic、TARX、lvlltd）难得多，也更有意思：规范只覆盖了「如何提供技能」，没有覆盖「如何买卖、扫描、评级、发布」。这块要么等下一版扩展，要么继续各自为政。

第三，别把采用率低当成判断依据，要把版本分布当成判断依据。

「4/1003」这个数字会被很多人拿去做标题党。但更有决策价值的指标是：44/1450 在跑 2026-07-28，615 个停在 2025-11-25，544 个停在 2024-11-05。

如果你现在要给一个团队做 MCP 技术选型，这三个数字分别对应三件事：你的服务器要不要支持新传输、你的客户端要不要兼容旧握手、你的工具发现逻辑要不要为「渐进式发现」做两套路径。这些比「技能扩展有没有人用」重要得多。

技能扩展现在是一个在 3% 的土壤上刚播种五周的种子。等 2026-07-28 这版规范爬到半数，再回头看它的采用率才有意义。

而那 17 家用野生方式实现的公司提醒了另一件事：在标准追上需求之前，谁先把「技能该长什么样」的形状固定下来，谁就在事实上定义了下一版标准。 渐进式披露、执行型技能、技能市场的定价与扫描——这些现在都还是空白区。

参考来源

• API Evangelist, Kin Lane，《Four Companies Serve Skills Over MCP The Way The Spec Says》，2026 年 10 月 21 日：https://apievangelist.com/2026/10/21/four-companies-serve-skills-over-mcp-the-way-the-spec-says
• MCP SEP-2640 Skills Extension（2026 年 9 月 13 日转 Final）：https://modelcontextprotocol.io/seps/2640-skills-extension
• Skills Extension 规范文档站：https://skills.extensions.modelcontextprotocol.io/
• Hugging Face MCP 服务器：https://huggingface.co/mcp
• Glean 开发者 MCP 服务器：https://developers.glean.com/mcp
• Renoolab MCP 服务器：https://mcp.renoolab.fr/mcp
• BestPrice MCP 服务器：https://mcp.bestprice.gr/mcp
• APIs.io MCP（作者自建，20 个技能）：https://apis.io/mcp