当一个 Agent 会查天气、处理图片或调用命令时，我们容易把能力归因给模型：它“学会了”使用工具。
但模型参数、工具接口和操作说明是三件不同的东西。工具提供真实执行能力，模型负责选择下一步，Skill 则告诉 Agent 某类任务什么时候该走哪条路径、有哪些约束、应该如何调用已有工具。
在 OpenClaw 中，这层说明主要由目录里的 SKILL.md 承担。它看起来只是 Markdown，却会进入运行时上下文，直接影响 Agent 的判断。
Skill 教方法，Tool 才执行动作
一个最小 Skill 包含 YAML frontmatter 和正文：
markdown--- name: image-lab description: Generate or edit images through the configured provider --- When the user asks to edit an image, inspect the source first...
name 与 description 帮助系统和模型识别用途，正文描述工作流。目录中还可以放脚本、模板和参考资料，但 Skill 本身不是新的底层权限。
如果运行时没有浏览器工具，一份“如何控制浏览器”的 Skill 不会凭空创造浏览器。如果 Agent 已经有 shell 权限，Skill 则可能教它执行一串真实命令。能力来自工具和权限，行为路径来自说明。
这一区分是理解 Agent 系统的第一步。
OpenClaw 如何找到 Skill
根据当前官方文档，同名 Skill 会按来源优先级覆盖。由高到低包括：
- 工作区
<workspace>/skills； - 项目 Agent 的
<workspace>/.agents/skills； - 个人
~/.agents/skills； - 共享的
~/.openclaw/skills； - 安装包自带的 bundled skills；
- 额外目录与插件提供的 skills。
优先级的意义很实际：团队可以在项目内覆盖一个通用 Skill，为当前代码库增加更严格的约束，而不用修改全局版本。
它也意味着排查问题不能只问“文件存不存在”，还要问“最终生效的是哪一份”。同名覆盖常常比模型行为更值得先检查。
不是发现了就一定可用
OpenClaw 会在加载时做 eligibility gating。Skill 可以声明所需操作系统、命令、环境变量和配置项；条件不满足时，它不会进入当前可用集合。
例如，一个依赖 ffmpeg 和特定 API key 的视频 Skill，在二进制或环境变量缺失时应被过滤。这样模型不会在一个不可能成功的前提上规划任务。
此外，Agent allowlist 可以进一步限制某个 Agent 看见哪些 Skill。需要注意：allowlist 控制的是能力目录的可见性，不是主机 shell 的安全边界。若同一 Agent 仍有宽泛的 exec 权限，系统还必须用沙箱、OS 用户、命令策略和最小凭证来约束执行。
真正注入 Prompt 的是紧凑目录
符合条件的 Skill 会被编译成紧凑 XML 块，注入 system prompt。这个目录主要包含名称、描述和位置等信息，让模型知道“当前有哪些路径可用”。
模型匹配到相关能力后，可以根据位置读取对应 SKILL.md，再按正文执行。可以把它理解成两层：
textsystem prompt 中的 Skill 目录 -> 选择可能相关的 Skill SKILL.md 详细说明 -> 约束具体执行过程
这种渐进披露避免把所有完整说明一次塞进上下文。官方文档甚至给出了目录的字符开销估算，并建议描述保持简短明确。
Skill 列表通常会在会话开始形成快照；文件变更监视或远程节点变化可以触发刷新。修改 Skill 后行为没有立刻变化时，会话快照也是排查点之一。
Description 是路由规则的一部分
如果 description 只写“helpful utilities”，模型很难知道何时选择它。好的描述应该说明任务类型、典型触发和关键边界，例如“在用户要求生成或编辑图片时使用；编辑前必须检查源图”。
这不是 SEO 文案，而是路由输入。描述过宽会抢走不相关任务，描述过窄则让 Skill 很少被发现。正文写得再好，路由没有命中也不会发挥作用。
因此，评估一个 Skill 不能只看说明是否完整，还要测试：
- 该触发的请求是否触发；
- 不该触发的请求是否保持沉默；
- 依赖缺失时是否被正确过滤；
- 与同名 Skill 冲突时哪一份生效。
Markdown 也是攻击面
Skill 是会影响 Agent 行为的操作文本。第三方 Skill 还可能附带脚本，并在 Agent 的真实权限下运行。OpenClaw 官方文档明确建议把第三方 Skill 当作不可信代码，在启用前阅读，并对高风险工具使用沙箱。
安装来源、版本更新和依赖安装都应该进入供应链审查。至少要检查：
- 它要求哪些环境变量和凭证；
- 正文是否诱导扩大权限或绕过确认；
- 脚本会访问哪些文件和网络地址；
- 更新后
SKILL.md与脚本是否发生实质变化。
“只是 Markdown”不是安全理由。对 Agent 来说，指令本身就可能是执行入口。
我的判断
Skill 最有价值的地方，不是给工具调用换了一个时髦名字，而是把原本散落在 system prompt、团队口头规范和脚本注释里的操作知识，变成可版本化、可覆盖、可测试的运行时资产。
它同时暴露了 Agent 设计的一条底线：说明、能力与权限必须分层。 Skill 可以教模型怎么做，工具决定能不能做，安全策略决定允许做到哪里。把三者混在一起，系统既难排查，也难信任。