导语
如果你是从工程视角看 Skill，最值得关心的不是“这个概念火不火”，而是两个问题： 第一，为什么不继续用一个大 system prompt 顶着。 第二，运行时到底是怎么发现、选择、加载并执行一个 Skill 的。
这两个问题，OpenAI、Google、Anthropic、Microsoft 其实已经给出了一套越来越接近的答案。
正文
1. 为什么工程上会从长 Prompt 走向 Skill
很多团队最开始做 Agent，都是一个大 prompt 起步。 把角色设定、输出格式、流程约束、调用顺序、失败兜底、示例、注意事项全写进去，能跑就先跑。这个阶段没问题，甚至是最省事的做法。问题出在后面：能力越多，prompt 越像一份项目手册，而且每个请求都得把大段无关信息重新带一遍。Google 官方把这种做法叫 monolithic prompts，OpenAI 也在 Codex 的最佳实践里建议：当工作开始变成可重复流程，就该把它沉淀成 Skill，而不是继续堆上下文。
这背后是一个很现实的工程问题： 上下文窗口不是白给的，注意力也不是白给的。即便模型能塞下很多 token，也不代表这种组织方式是好的。Skill 的价值，在于把“长期有效的经验”从“当前对话上下文”里拆出来。
2. Agent 加载 Skill 的链路，一般分三步
主流实现现在都在做 progressive disclosure。
也就是说，Agent 不会在启动时读完所有 Skill 的全文，而是按相关性逐层展开。OpenAI 的说法最直接：Codex 先看到 metadata，决定使用后才加载完整 SKILL.md；需要时才会读 references 或运行 scripts。Google 的 ADK 文章也明确把这个过程拆成 metadata、instructions、resources 三层。
第一步：发现。
Agent 先看 name、description、路径等元信息，做技能发现和初步匹配。开放规范专门要求 description 不只是解释 Skill 是什么，还要写清楚什么时候该用，因为这直接影响匹配质量。
第二步：展开说明。
当 Agent 判断这个 Skill 相关，才把完整 SKILL.md 加进上下文。这一步相当于把操作准则、约束、示例、边界条件注入进来。
第三步：读取资源或执行脚本。
如果 SKILL.md 里提到需要查某份参考文档、模板或执行某个命令，这时才会去读 references/ 或跑 scripts/。这比把所有附件一开始全塞进模型更省上下文，也更可控。
从运行时角度看，Skill 本质上是一种按需注入机制，不是一段常驻大 Prompt。
3. 一个 Skill 目录为什么会长成这样
现在几家的结构已经相当接近。
OpenAI 把 Skill 定义成一个目录，里面至少有一个 SKILL.md，外加可选的 references/、scripts/、assets/；Anthropic 也要求 Skill 至少要有一个带 YAML frontmatter 的 SKILL.md，字段里最低要求 name 和 description。
这套结构其实很合理。
SKILL.md 解决“模型应该怎么想、怎么做”；references/ 解决“长资料别直接塞上下文”；scripts/ 解决“该交给确定性执行的动作，不要强迫模型去猜”。如果把这三层混成一个大文本文件，Skill 的边界会很差，后面也不好维护。
我自己的理解是： Prompt 更像一次性的调用说明；Skill 更像一个可部署的能力目录。
4. Skill 和 Tool、Workflow 到底怎么区分
这也是开发时最容易混的点。 Microsoft 的官方定义很清楚：tool 是一个动作，skill 是一个领域知识和资源包。前者更像函数调用，后者更像把一类任务的“处理方式”打包出来。
至于 workflow，Microsoft 也专门做了区分： 如果你要的是 AI 自己判断怎么完成任务，Skill 更合适；如果你要的是固定步骤、强控制、可恢复、带明显副作用的流程，workflow 更稳。这个区分对工程落地非常重要，因为很多人会把所有复杂流程都塞进 Skill，最后得到一个又长又难测的东西。
我比较认同的做法是： 知识、规范、经验、风格、任务套路，优先做 Skill； 强顺序、强副作用、强状态管理，优先做 Workflow； 可确定执行的原子动作，交给 Tool。
5. 几个开源项目，能看出 Skill 正在往哪里长
Nuwa Skill 提供的是一种很新鲜的方向：把“人物认知框架”蒸馏成 Skill。
它不是简单复刻语气，而是把研究、验证和产出 SKILL.md 变成一条流水线。这个项目说明 Skill 不一定只服务于业务任务，也可以服务于思维框架的迁移。
PUA Skill 更像行为策略插件。
它的 SKILL.md 里直接写了触发条件，比如用户沮丧、重复失败、被动行为、质量抱怨等场景，目标是让 coding agent 在这些情况下不要轻易停下来。这个例子很适合拿来观察：Skill 也可以是“行为干预层”。
andrej-karpathy-skills 很适合工程团队参考。
它不是一个花哨的 agent framework，而是一套针对 LLM 编码常见坑的行为准则，既可以按项目落到 CLAUDE.md，也可以作为插件使用。
Darwin Skill 则把 Skill 推向了“自优化”阶段。 它的目标不是给 Agent 新任务，而是优化已有 Skill，本质上是把 Skill 当作一个可以持续评估、迭代、改进的对象。这个方向对团队资产化很有启发。
结尾
如果你是从开发和落地的角度看 Skill，我觉得最有价值的判断是这句： Skill 不是“更大的 Prompt”，而是“更好的能力组织方式”。
它解决的是经验如何发现、何时注入、怎么执行、怎样维护。 Agent 只靠 Prompt 能跑起来，但要跑得久、跑得稳、跑得能协作，迟早会走到 Skill 这一步。
