OpenClaw 的 Skill 系统:怎么让 AI 真正学会新能力

上次写了 Memory ，有读者问： OpenClaw 怎么扩展能力？光靠对话能做的事太有限了。

这就要说到 Skill 系统。

Skill 是 OpenClaw 的能力扩展机制。它不是插件，不是 API ，而是——一套告诉 AI"怎么做某件事"的文档。

听起来很简单。但它的设计，远比你想的精巧。

先说清楚 Skill 不是什么

很多人以为 Skill 是一种代码注入——像装插件一样，给 AI 装上新能力。

不是的。

Skill 是一段 Markdown 文档，核心文件叫 SKILL.md。里面写的是：这个能力怎么用，什么时候用，用的时候注意什么。

AI 自己读文档，自己理解，自己执行。没有魔法。

这种设计的好处是什么？

解耦。 Skill 的作者不需要懂 AI 底层。写 Skill 就是写文档。文档写得好， AI 就能用。文档写得烂， AI 就拉胯。

SKILL.md 到底长什么样

先看结构。每个 Skill 是一个文件夹，里面只有一个必需文件 SKILL.md。

skill-name/ └── SKILL.md 

就这么简单。没有代码，没有配置，没有额外的目录结构。

SKILL.md 里面分两部分：YAML 头 + Markdown 正文。

YAML 头是这样的：

---name:image-labdescription:Generate or edit images via a provider-backed image workflowmetadata:openclaw:requires:bins:["uv"]env:["GEMINI_API_KEY"]config:["browser.enabled"]primaryEnv:"GEMINI_API_KEY"---

name 是 Skill 的名字，description 是它的简介——这个会被压缩后注入到 AI 的系统提示里，所以描述要精准。

metadata 里定义的是触发条件。你可能在某台机器上，这个 Skill 才有意义。 OpenClaw 用这个来判断：要不要把这个 Skill 给当前的 AI 用。

这就是接下来要说的——Gating 机制。

条件触发： Gating 机制

Gating 是我认为 Skill 系统设计得最聪明的地方。

大部分 AI 工具的插件/技能是无条件加载的——装了就一直存在，不管你用不用，不管环境能不能支持。

OpenClaw 不是。它会检查环境，满足条件才加载。

看 YAML 里的 requires 字段：

bins——检查 PATH 里有没有这个二进制文件。

requires:bins:["ffmpeg","curl"]

如果系统里没有 ffmpeg，这个 Skill 就不会被加载。 AI 根本不知道有这个能力存在。

env——检查环境变量。

requires:env:["OPENAI_API_KEY"]

没有设置这个环境变量， Skill 不会加载。

config——检查 OpenClaw 配置文件里的开关。

requires:config:["browser.enabled"]

os——操作系统过滤。

os:darwin# 只有 macOS 加载os:linux# 只有 Linux 加载

always——强制加载，不管其他条件。

always:true

这个设计解决了一个很烦的问题：同一个 Skill 描述，在不同机器上可能完全不可用——比如 Windows 用户根本跑不了 ffmpeg 命令。但 AI 不知道，它只会照着描述执行，然后报错。

Gating 把这个判断提前了。 AI 拿到手里的 Skill ，是确认能用的。

Skill 加载顺序：谁优先生效

OpenClaw 支持同时从多个目录加载 Skill 。问题来了——同一个 Skill 名字，如果多个目录都有，以哪个为准？

优先级从高到低：

这意味着什么？

项目可以覆盖全局的 Skill 。你本地改的东西，不会影响别人的项目。反过来也成立——你在项目里写的 Skill ，不会污染全局。

Token 优化：别让 Skill 把上下文撑爆

你可能会想： Skill 这么多，都加载进来，系统提示得有多长？

好问题。

OpenClaw 的处理方式是：压缩注入。每个 Skill 的描述会被压缩成大约 97 个字符，塞进系统提示。 AI 知道有这个 Skill ，但不知道具体内容。

具体内容是什么时候加载的？

用的时候。

当你触发了一个 Skill 的描述关键词， OpenClaw 才会把完整的 SKILL.md 内容拿出来，给 AI 读。

这就像图书馆和图书管理员的关系。图书馆的书很多，但管理员不会把所有书都背在身上——他只在你问的时候去查。

按需加载。这是 OpenClaw 能支持大量 Skill 而不爆炸的关键。

ClawHub ： Skill 的市场

Skill 写好了，怎么分享给别人？

OpenClaw 配套了一个公开的 Skill 市场，叫 ClawHub^[1]。

你可以：

安装命令大概长这样：

clawhubinstallskill-creator clawhubsync 

ClawHub 上的 Skill 有安全扫描——安装前会跑一个 dangerous-code scanner ，检查有没有恶意代码。毕竟 Skill 是纯文档，但文档里可能嵌入恶意指令。

这不算完美，但比"随便装什么都行"强多了。

怎么写一个自己的 Skill

说了这么多设计细节，来点实操的。

写 Skill 的核心就一件事：把你的知识变成文档。

假设你想写一个"帮我查天气的 Skill"。你需要告诉 AI ：

一个最简单的例子：

---name:weatherdescription:Get current weather and forecasts for any locationmetadata:openclaw:always:true---Use when:user asks about weather, temperature, or forecasts.## ToolsUse the `weather` tool.## UsageCall weather(tool) with:-location:City name or coordinates## ResponseThe tool returns:temperature, conditions, humidity, forecast.## Error handlingIf location not found, ask user to be more specific.

这就是全部。

Skill 作者不需要写代码，不需要调试 API ，只需要——把一件事的正确做法写清楚。

AI 会照着做。

为什么这个设计值得研究

很多 AI Agent 框架的能力扩展，走的是"插件市场"路线——开发者写 SDK ，平台审核，上架。

好处是质量可控。坏处是门槛高，迭代慢，生态封闭。

OpenClaw 的 Skill 设计，把能力扩展变成了文档写作。

门槛低到任何人都可以写。迭代只需要更新 Markdown 文件。生态是开放的——你写的 Skill 可以发布到 ClawHub ，也可以只在本地用。

当然，这不是完美的。文档式的 Skill 有个天然缺陷：没法描述复杂的状态机逻辑。

如果你要写一个"先登录，再查询，再登出"的三步流程， SKILL.md 很难表达清楚。这时候还是得靠代码。

但对于 80% 的"查个东西"、"做个操作"类需求， Skill 已经够用了。

这就是工程取舍——用文档的灵活性，换代码的能力上限。

最后

Skill 系统让我重新思考了一个问题： AI 到底需要什么形式的"指导"？

不是代码。代码是给机器的指令。 不是提示词。提示词是给 AI 自己的模糊指引。

是结构化的文档——人能写， AI 能读，机器能解析、能版本控制、能安全扫描。

这个思路，放到其他场景也一样适用。

你有没有想过，把你团队的操作规范，也写成 Skill 的格式？

参考链接

[1] ClawHub: https://clawhub.com