OpenClaw 深度解析（八）：Skill 系统——让 LLM 按需学习工作流

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

你问 OpenClaw：「帮我查一下上海今天的天气。」

AI 回复了一段的命令，执行后准确拿到了天气数据。

但这里有个问题值得深究——LLM 是一个语言模型，它并不天然知道"查天气要用 "，也不知道"管理 GitHub PR 用 CLI"，更不知道"控制 Spotify 用 "。

显然有什么东西在"教"它这些。但如果把 50 个工具的完整文档全部塞进系统提示里，光文档本身就会把上下文窗口撑满。

这就是 Skill 系统要解决的问题：

文档规模问题：50+ 个工具，每个都有详细文档——全部预加载会把 LLM 的上下文撑爆。
工具可用性问题： CLI 没装、没配置环境变量——向 LLM 暴露不可用的工具毫无意义还会引发错误。
工作流标准化问题：工具的用法需要让 LLM 精确理解和遵循，不能靠 LLM “猜”。
用户体验问题：用户想通过直接触发，而不是每次都打一段自然语言。

为什么是 Markdown 而不是代码？

Skill 不是一段程序——它是"给 LLM 看的操作手册"。LLM 理解自然语言和 Markdown，所以最合理的格式就是带 YAML frontmatter 的 Markdown 文件。

每个 skill 是一个目录，里面放一个：

frontmatter 中的两个关键字段：

：一行摘要，是系统提示里的唯一"代言人"，LLM 靠这一行决定是否使用这个 skill
：声明依赖哪些可执行文件，运行时若不存在则整个 skill 从系统提示中消失

正文（LLM 读）：详细的"何时用"、“何时不用”、命令模板、注意事项——这部分不会出现在系统提示里，只有 LLM 主动读取时才加载到上下文。

这种分离是整个系统设计的核心：元数据给机器，正文给 LLM，摘要在中间传递决策信号。

问题：skill 来自哪里？

一个用户可能同时有系统内置 skill、自己安装的 skill、项目级别的 skill。这些都要能被发现，而且同名时要有明确的覆盖规则。

扫描六个来源，优先级从低到高：

优先级用一个实现——后赋值的覆盖先赋值的：

这意味着：项目里的会完全覆盖系统内置的 skill，而不是合并。用户可以为特定项目定制任何 skill 的行为。

嵌套目录探测

有一个启发式逻辑：如果存在，则把视为真正的 skills 根目录。这样目录下既可以直接放，也可以放一整个包含子目录的工具包——两种结构都能被正确识别。

问题： CLI 没装，还要把 GitHub skill 展示给 LLM 吗？

在加载后做运行时资格检查：

没装时，检查失败，GitHub skill 被从列表中移除——LLM 的系统提示里不会出现任何关于它的信息。

过滤后还有第二步：剔除的 skill。这类 skill 只能通过显式触发，LLM 自主决策时看不到它们。

资格上下文：远端信息

支持注入远端节点的状态：

当 Agent 在远端 Node Host 上执行时（参见第六篇），资格检查针对的是目标节点的环境，而不是 Gateway 所在机器——所以如果远端 Linux 服务器有但本地 Mac 没有，GitHub skill 依然会显示给 LLM。

问题：150 个 skill 的完整文档有多大？

以每个 SKILL.md 平均 2000 字节计算，150 个 skill 就是 300KB 纯文本——远超大多数模型的上下文窗口。

解决方案是渐进式披露：系统提示里只放每个 skill 的三个字段（name、description、location），正文留到 LLM 决定使用时才读取。

（来自 SDK）把过滤后的 skill 列表格式化成：

注意字段中的路径：被压缩为 ——这个细节在里实现，每个路径节省约 5-6 个 token，150 个 skill 合计节省约 600-900 token。

Token 预算控制

问题：LLM 看到 skill 列表后，知道该怎么做吗？

光有列表还不够——LLM 需要明确的行为规则。把列表和指令一起注入系统提示：

这段指令的设计有几个关键点：

：标记为强制——LLM 每次回复前都要扫描，而不是"偶尔参考"。
“read its SKILL.md at ”：明确指定用工具加载，位置就在字段——LLM 不需要猜路径。
“never read more than one skill up front”：防止 LLM 一次性读取所有可能相关的 skill（会浪费 token）。
“then follow it”：读取后要遵循，而不只是参考。

最终效果：用户问「查一下上海天气」→ LLM 扫描摘要 → 匹配 weather skill 的 description → 调用 → 读取完整工作流 → 执行。

整个过程 LLM 是主动参与者，而不是被动执行脚本——Skill 系统通过"摘要 + 路径"给了 LLM 恰好足够的信息来作出决策，完整内容只在真正需要时才加载。

问题：用户想打而不是自然语言

扫描所有的 skill（默认为 true），为消息平台注册斜杠命令：

命令名做规范化处理：

两种触发模式

用户发送后，系统查找对应的：

模式一：经过 LLM（默认）

模式二：确定性工具分发（）

如果 SKILL.md 的 frontmatter 中声明了：

则触发完全绕过 LLM：

这对"输入明确、工具已知、无需推理"的场景非常有价值——执行速度更快，且行为完全可预期。

当 Agent 在 Docker 沙盒中运行时（参见第七篇），skill 文件需要从宿主机同步进容器：

同步完成后，容器内的工具读取的是容器内的 SKILL.md 副本，而不是宿主机路径。确保每个 skill 目录名都是安全的，不会通过这类名称逃逸到容器外。

Skill 系统的核心是一个简洁的设计哲学：不把文档变成代码，而是把文档教给 LLM，让 LLM 按文档行动。

阶段机制目的发现六来源扫描 + Map 优先级覆盖让用户/项目可以覆盖系统内置 skill 过滤 bins/env/os 资格检查只向 LLM 暴露当前环境真正可用的 skill 摘要注入 ，字符预算控制最小 token 开销让 LLM 能决策 元指令 + read 工具路径告诉 LLM 如何用这些信息 渐进式披露 LLM 决策后主动调用完整文档只在真正需要时才进入上下文 /命令 注册斜杠命令用户显式触发，绕过自然语言推理 确定性分发 执行路径完全不经过 LLM

这个设计让 skill 作者只需写 Markdown，而不需要了解 LLM 推理、工具注册或消息平台——一个 SKILL.md 文件，就能让 AI 按照作者的意图行动。