先说结论：Skills 是真的范式变化，但生态成熟度大约相当于 2014 年的 npm——能用，而且已经能闻到供应链事故的味道了。
截至 2026 年 9 月 2 日，anthropics/skills 仓库 173,071 Stars。
比 Star 数更能说明问题的是另一个数据：2026 年 8 月的 GitSkills 研究在公开 GitHub 里扫出了 3,797,117 个 SKILL.md 文件，覆盖 282,200 个仓库，内容去重后还有 1,877,981 份。
一个九个月大的文本格式，靠复制粘贴长出了近 400 万份实例。这篇回答分四部分：
它到底解决了什么、
官方源码里暴露的早期问题、
我们的跨 Agent 复现实验、
以及为什么我认为它真正的故事是"软件供应链"
一、Skills 解决了什么：给"经验"一个可安装的载体
传统的 Agent 提示词散落在聊天记录、团队 wiki 和个人习惯里，难复用、难版本化、出了问题追不回是哪版规则在起作用。
Agent Skills 的方案朴素到不像创新：用一个文件夹封装一项能力。
机制上有两个设计值得单独说：
1. 渐进加载。 Agent 启动时只读 name + description
两行元数据，命中任务后才加载正文，再按需读 references。这解决了系统提示词长期霸占上下文的老毛病。
2. 接口的双重读者。 这是行客认为最深刻、也最容易被忽略的变化。传统函数靠稳定名称和参数调用；Skill 的"接口"是一段自然语言，路由决策者是模型的概率判断。官方 skill-creator 甚至专门提醒：Claude 目前存在低触发倾向，作者要把触发条件写得更主动。
换句话说，你写的 README 同时是给人看的文档和给概率路由器看的路由表。软件史上头一回。
3. 不绑定 Claude。 2025 年 12 月 18 日 Anthropic 把格式作为开放标准发布（agentskills.io），48 小时内微软（VS Code/Copilot）和 OpenAI（Codex CLI）跟进，到 2026 年 7 月支持工具超过 40 款。这基本是 MCP 路径的复刻：先做、再开放、让生态替它修路。
二、拆开官方源码：
成熟度没有 Star 数那么好看
在 2026 年 9 月 1 日的官方提交上做了本地审计，19 个 Skill 目录。skill-creator 已经配了验证脚本、触发评测、A/B 对照工具——说明官方确实是当"可测试的软件工件"在经营。但两个具体问题很说明早期状态：
问题一：Windows 编码。
官方 quick_validate.py 用Path.read_text() 读文件，没显式指定 UTF-8。在中文 Windows 的 GBK 默认环境下，校验官方的 discernment-nudge 直接抛
UnicodeDecodeError；设 PYTHONUTF8=1 后通过。故障很小，但它能直接阻断本地验证流程。
问题二：规则和实现打架。
官方校验器规定 description 上限 1,024 字符。我们批量验证 19 个官方 Skill，18 个通过——唯独官方自己最新的 claude-api 是 1,068 字符，严格校验失败。而客户端接入指南又建议对这类问题"警告并继续加载"。同一个 Skill，可能在严格流水线被拒，在宽容客户端照常运行。
这就是软件供应链早期的经典症状：规范版本、作者工具、包内容、运行时，四者对不齐。
另外提醒一个法律细节：19 个目录里 14 个是 Apache-2.0，但 docx/pdf/pptx/xlsx 四个文档 Skill 用的是 source-available 许可。仓库公开可读 ≠ 每个目录都给你商用和再分发权利，用之前逐目录看 LICENSE。
三、跨 Agent 实验：
格式是开放的，行为不是自动跟着走的
既然微软和 OpenAI 都接入了这个标准，那"同一个 Skill 文件在别的 Agent 上表现一致吗"？我们做了个对照实验。
测试对象：官方
discernment-nudge（无脚本、无网络依赖），规则是"给出有决策后果的建议后，追加 2-3 个核验问题"。
题目：为一家 20 人 AI 软件团队选单/双供应商方案，含三个月计划、80 万预算和风险。
条件：实验组与空白组用同一 Codex 版本、同一模型、同一推理档位、同一道题。
结果：
但这个实验回答不了的东西更多：
单次 token 差值混合了文件发现、内部规划和运行波动，40% 的差值不能全算在 Skill 头上；
客户端同时会扫描用户目录里的其他 Skills，存在干扰；
一次命中 ≠ 长期触发率，而触发率恰恰是自然语言路由最不稳定的部分；
Claude Code CLI（已核验到 2.1.252）本机未登录，行为测试没跑成；OpenCode 1.18.25 完成了客户端发现测试（成功列出项目级 Skill，元数据与官方快照一致），但没配模型供应商，路由 A/B 留待下轮。
所以行客对此的建议是：目录兼容、成功路由、输出一致，当成三项独立指标分别验收。正式评测至少需要 20 正例 + 20 反例、每题重复三次、固定模型和 Skill 提交版本，再统计命中/漏触发/误触发。
四、真正的故事：
一门没有包管理器的供应链生意
前面都是铺垫，这部分最值得从业者警惕的。
生态缺基础设施。 近 400 万份 SKILL.md 在流动，但没有统一包管理器、没有编译器、没有类型检查器。作为对照研究：一项针对 138,133 份 Skill 的静态分析显示，91.8% 的样本至少存在一项复用缺陷（路由描述、正文可执行性、资源组织）。另一项维护研究发现，在其识别的复用关系中，53% 的 Skill 被采纳后就没再改过。
这两个数字要谨慎读：静态缺陷率 ≠ 生产故障率，复制后不改也可能只是内容稳定。
复制即分叉。 传统依赖通过版本范围和锁文件接收上游修复；复制进项目的 Skill 断开了这条线。上游出漏洞、改流程、换许可，你甚至不知道自己手里有多少份旧副本。
安全扫描只覆盖一段。 Anthropic 今年 8 月上线了第三方 Skill/插件安全扫描（pass/warn/fail，多数任务一两分钟），这很好。但仍需要注意空档：既有 Skill、Claude 创建的 Skill、经 MCP 提供的 Skill、MCP 服务器与 hooks，都可能落在扫描之外。pass 也不保证业务逻辑正确。别忘了这个接口的执行面能摸到文件、命令、网络和凭证——恶意指令、凭证窃取、数据外传都是现实威胁模型。
企业真正需要的是一条完整风险链：来源 → 许可 → 路由 → 权限 → 数据 → 审计 → 回滚。 扫描只是其中一环。
五、给开发者的五条落地纪律
从高频、低权限、结果可验证的任务起步（格式检查、测试生成、发布说明）；直连生产库、支付、删除命令的 Skill 先过沙箱和人工审批；
概率流程与确定性动作分层：判断逻辑写 SKILL.md，可复现动作进脚本，脚本做单元测试，整体做有/无 Skill 的行为 A/B；
当内部依赖管：每个 Skill 记录来源、版本、许可证、责任人、权限、数据范围、评测集和回滚方法；项目级进 code review，组织级进变更审批；
"应该触发"和"应该沉默"分开测，只测成功案例会掩盖误触发；记得在上下文压缩后复测是否重复激活；
提前设计出口：固定版本、保存基准输出、保留替代实现——比指望作者长期在线可靠。
写在最后：
Skills 的本质，是把"团队经验"从聊天记录里捞出来，变成可发现、可分发、可评测的软件工件。当经验可以像依赖一样安装，治理就必须跟上——这是 npm 生态当年用无数次事故换来的教训，Skills 生态大概率要重走一遍，但愿走得快一点。
模型差距在缩小，未来企业真正的资产会落在：领域流程、可执行工具、评测数据、治理记录。 Skill 决定 Agent 能复用什么经验，治理系统决定这些经验能不能长期可信地运行。
如果你正在建设 Agent 工作流或 AI Coding 团队，可以关注「行客科技」并星标。
回复关键词【技能治理】，获取《Agent Skill 生产治理检查清单》，覆盖来源、版本、路由评测、权限、数据、许可证、安全扫描与回滚。
团队已经出现规则散、评测缺失、结构退化或 Agent 反复改坏，也可以在后台留言【DARWIN】，进一步了解 AI Coding 的修复与治理闭环。
