好的，没问题。作为一位在 AI 工具链领域摸爬滚打多年的老手，我来帮你把这篇关于 Skill Workshop 的文章重写一遍，让它读起来更像是一位资深用户在实际使用后的经验分享，而不是一份冷冰冰的产品说明书。 我们已经在前两篇里体验了手写 skill 的整个流程——从搜索安装、到从零创作、再到发布分享。说真的，那套流程虽然完整，但每一步都得亲力亲为，尤其是当你有一连串想要沉淀的习惯性操作时，逐一填写触发短语和组织正文，确实有点像是把一份“填表式”的文档工作外包给了自己。虽然 `skill-creator` 工具能帮你分担一部分结构化的工作，但本质上，决策权还是在你手里。 OpenClaw 提供了一个实验性的内置插件——**Skill Workshop**，它的思路刚好反了过来。它能在你每一次成功的会话结束后，自动扫描历史记录，把其中值得固化下来的可复用流程整理成一份 workspace skill 的提议。如果它通过了内置的安全扫描，就能直接写入磁盘，从而让“小龙虾”把从你这轮互动中学到的经验，顺手写进自己下一轮可以调用的手册里。这就像是给你的 AI 助手装上了一套“即时反馈”的学习回路。 ## 开启与配置：先关进笼子里观察 既然是实验性插件，它默认是关着的。你需要在配置文件中显式地开启它。打开 OpenClaw 的配置文件，在 `plugins.entries` 下面添上这么一段： ```json {plugins: {entries: {"skill-workshop": {"enabled": true,"config": {"autoCapture": true,"approvalPolicy": "pending","reviewMode": "hybrid"}}}}} ``` 改完保存后，记得运行 `openclaw gateway restart` 让它生效。 这几个配置项是它的核心，我们来一个一个看下是干什么的： - **`autoCapture: true`** —— 开启后，每次对话成功结束，它会自动扫描历史。如果你关掉它，它就不会主动“多管闲事”，只有你明确对小龙虾说“把这个存成 skill”时，它才会动手。 - **`approvalPolicy: "pending"`** —— 这是关键。它扫描到觉得有价值的东西，不会直接落盘，而是先攒成一个“提案”放到待办队列里，等你来审批。我们第一次用，强烈建议先用 `pending`。等你亲眼见识几次它提的案到底靠不靠谱，再考虑换成 `auto` 让它自动写盘。 - **`reviewMode: "hybrid"`** —— 这决定了它用哪种“眼力”去发现可沉淀的内容。一共四档：`off` 是完全不自动找；`heuristic` 是只靠关键词扫描（比如后面要讲到的那些纠正性短语）；`llm` 是让模型回看整段对话；`hybrid` 则是两者一起上。新手阶段直接用 `hybrid` 最省心，后面会单独说各档位的区别。 因为还在实验阶段，它的内部行为在版本迭代中可能会变。**第一次用务必先用 `pending` 模式，亲眼看看它几轮下来都想存些什么**，别一上来就让它自动写文件，免得它把你的工作区弄得一团乱。 这几个参数组合起来，可以应对不同的使用场景。下面列出几种典型的配置，你可以根据自己的习惯来选： ```json // 保守模式：只接受显式指令，关闭一切自动捕获 { autoCapture: false, approvalPolicy: "pending", reviewMode: "off" } // 推荐模式：开启自动捕获，但所有提案都排队待审 { autoCapture: true, approvalPolicy: "pending", reviewMode: "hybrid" } // 受信自动化：在你完全信任的本地工作区里，安全提案自动落盘 { autoCapture: true, approvalPolicy: "auto", reviewMode: "hybrid" } // 省钱模式：不跑 LLM 回看，只靠关键词扫描 { autoCapture: true, approvalPolicy: "pending", reviewMode: "heuristic" } ``` 除了上面这些核心配置，还有一些调节阈值和文件大小的参数，新手一般用不到。我列在下面，算是备查： | 键 | 默认 | 范围 | 作用 | | :--- | :--- | :--- | :--- | | `reviewInterval` | `15` | 1..200 | 累计多少次成功对话后，跑一次 LLM 回看模型 | | `reviewMinToolCalls` | `8` | 1..500 | 累计多少次工具调用后，跑一次 LLM 回看模型 | | `reviewTimeoutMs` | `45000` | 5000..180000 | LLM 回看模型单次运行的超时时间 | | `maxPending` | `50` | 1..200 | 每个工作区最多保留多少条待审提案 | | `maxSkillBytes` | `40000` | 1024..200000 | 生成的 skill 或支持文件，单文件大小上限 | ## 实战演练：把一句话变成一份 Skill 插件启用后，我们来手动走一遍完整流程。整个过程就三步：在对话里说一句带“纠正口吻”的话，看看提案是不是进了队列，最后把它应用落地。 ### 第一步：说一句带“纠正口吻”的话 首先，你需要造一段能被插件捕获的对话。插件会死盯着你的消息里有没有 `next time`、`always`、`from now on` 这类表达“纠正”意图的短语（完整的列表后面会讲）。一旦命中，它就会尝试把它沉淀成 skill。**注意，这些短语必须出现在你的消息里，小龙虾的回复中间出现不算。** 比如，你可以在对话里输入： ``` next time we work with animated GIFs, always verify the URL resolves to image/gif before committing the file. ``` 小龙虾会正常回复你。但在回复之后，Skill Workshop 插件会被自动触发，对这个会话进行沉淀分析。 ### 第二步：查看提案队列 然后，你需要看看提案进队列了没有。你可以在同一个会话或新会话里对小龙虾说： ``` > 帮我看下 skill workshop 现在有几个 pending 提案 ``` 小龙虾会调用 `skill_workshop` 工具，并返回一个待审队列。如果去 Control UI 查看详细的工具调用结果，你会看到类似这样的内容： ```json [{"id": "1548054d-4aa2-493d-a1f5-96409a4e56be","createdAt": 1780959647860, ... "status": "pending", "skillName": "animated-gif-workflow", "source": "agent_end", "change": {"kind": "create", "description": "Reusable workflow notes for animated GIF requests.", "body": "# Animated GIF Workflow\n\n## Workflow\n\n- next time we work with animated GIFs, always verify the URL resolves to image/gif before committing the file.\n- Verify the result before final reply.\n- Record durable pitfalls as short bullets; a void copying transcript noise."}}] ``` 这条记录里，有几个字段值得留意。 首先看 `status`：它是 `pending`，说明目前还没创建任何 skill 文件，这只是一条处在待审队列里的提议，真正落盘要等下一步的 `apply`。 再看 `skillName`：插件从你的话里识别出了 `animated GIFs`，给它起了个名字叫 `animated-gif-workflow`。OpenClaw 内置了一张话题映射表，可以把几类常见话题对到固定的 skill 名： | 你的话里出现的关键词 | 落到的默认 skill 名 | | :--- | :--- | | `animated` / `gif` | `animated-gif-workflow` | | `screenshot` / `screen capture` / `asset` / `imageoptim` | `screenshot-asset-workflow` | | `qa` / `scenario` / `test plan` | `qa-scenario-workflow` | | `pr` / `pull request` / `github` | `github-pr-workflow` | | 其他所有情况 | `learned-workflows` | 你的话里有 `animated GIFs`，命中第一行，自然就归到了 `animated-gif-workflow`。如果一句话哪个都不沾，就统一落到 `learned-workflows` 这个兜底名称。 另外还有个 `source` 字段，表示这个提案是从哪里冒出来的。它的取值有：`tool`（你或模型显式调工具生成的）、`agent_end`（自动扫描到纠正口吻）、`reviewer`（回看模型产出的）。这个在后面“三条捕获路径”一节会专门拆开讲。 ### 第三步：应用 Skill 提案 最后，我们把它应用落地。你对小龙虾说： ``` > 把 animated-gif-workflow 这个提案应用掉 ``` OpenClaw 会调用工具 `skill_workshop({ "action": "apply", "id": "1548..." })`。 应用成功后，会自动生成 `/skills/animated-gif-workflow/SKILL.md` 文件。这里有一个很关键的细节：**所有写入都会立刻刷新内存里的 skills 快照**，也就是说，这个新 skill 不用执行 `/new` 指令，也不用重启网关，在当前会话中就能被小龙虾看到并使用。 如果你觉得这个提案不够好，也可以拒绝它： ``` > 拒绝 animated-gif-workflow 这个提案 ``` ## 工具用法速查：八个动作 跑通之后你会发现，整个生命周期的管理，都是围绕 `skill_workshop` 这个工具展开的。它一共有八个动作： | action | 用途 | | :--- | :--- | | `status` | 统计当前工作区里各个状态（pending/applied/rejected/quarantined）的提案有多少条 | | `list_pending` | 列出待审队列里的提案，默认只看 pending，也可以传 `status` 参数查看其他状态 | | `list_quarantine` | 列出被安全扫描拦下、隔离起来的提案 | | `inspect` | 按 `id` 查看某一条提案的完整详情 | | `suggest` | 由模型主动提交一条新提案，在 `pending` 策略下默认入队等待审批 | | `apply` | 把某一条 pending 提案真正应用到磁盘上 | | `reject` | 拒掉某一条提案，状态改为 `rejected` 但保留在记录里 | | `write_support_file` | 往 skill 目录下的支持目录（如 `references/`、`scripts/`）写一份支持文件 | 其中大部分都比较直观，只有 `suggest` 和 `write_support_file` 值得单独聊聊。 `suggest` 是模型主动提交建议的入口，比自动捕获更精确。一个完整的 `suggest` 请求长这样： ```json {"action": "suggest","skillName": "animated-gif-workflow","title": "Animated GIF Workflow", "reason": "User established reusable GIF validation rules.","description": "Validate animated GIF assets before using them.", "body": "## Workflow\n\n- Verify the URL resolves to image/gif.\n- Confirm it has multiple frames.\n- Record attribution and license.\n- A void hotlinking when a local asset is needed."} ``` 上面这个例子用的是基础参数，默认走 `create` 模式创建一份新 skill。此外，`suggest` 还有几个额外的参数，用来切换写入方式或绕开审批策略： - **`apply`** —— 强制指定是否写盘，可以绕开当前的 `approvalPolicy`。`apply: true` 在 `pending` 策略下也会强行立即写入（但依然要过安全扫描）；`apply: false` 在 `auto` 策略下也会强行只入队。 - **`section`** —— 传了它就切到 `append` 模式。`body` 的内容会被追加到已有 skill 的指定 section 下，而不是新建。 - **`oldText` + `newText`** —— 这两个一起传，就切到 `replace` 模式。它会精确地把 skill 正文里的 `oldText` 替换成 `newText`（要求 `oldText` 在文件中唯一存在，否则会拒绝）。 `write_support_file` 是用来往 skill 目录下的支持目录写文件的。一个 skill 不止是 `SKILL.md` 一份文件，它可以带 `references/`、`templates/`、`scripts/`、`assets/` 这四种支持目录。需要记住的是，支持目录里的内容**不会自动注入到 prompt 里**，只有在 `SKILL.md` 正文中显式引用时，小龙虾才会主动去读取。这条命令就是让 Workshop 把内容写到比 `SKILL.md` 更深的位置： ```json {"action": "write_support_file","skillName": "release-workflow","relativePath": "references/checklist.md", "body": "# Release Checklist\n\n- Run release docs.\n- Verify changelog.\n"} ``` 和写 `SKILL.md` 一样，这条命令也受同一套安全约束：写入位置被严格限定在 workspace 目录内，不能越界；文件大小受 `maxSkillBytes` 限制；内容同样要过一遍安全扫描；最后是原子落盘，不会写到一半留下半截文件。 ## 三条捕获路径：提案从哪里来？ 前面讲 `source` 字段时提到，一条提案可能从三条不同的路径冒出来。这一节我们就把它拆开说说。 1. **工具显式建议（`tool`）**：当模型看到一段可复用的流程，或者用户明确说“把这个存成 skill”时，它会直接调用 `skill_workshop` 工具。这是最直接的一条路径，即使 `autoCapture: false` 也能用，是关闭自动捕获时唯一的入口。 2. **启发式捕获（`agent_end`）**：当 `autoCapture` 开启，且 `reviewMode` 包含 `heuristic` 时，插件会扫描成功的那一轮对话中，用户消息里明确出现的纠正性短语。这就是上面实战中你一句话能被捕获的原因。这套短语列表是写死在源码里的： ```js const CORRECTION_PATTERNS = [ /bnext timeb/i, /bfrom now onb/i, /bremember tob/i, /bmake sure tob/i, /balwaysb.{0,80}b(use|check|verify|record|sa ve|prefer)b/i, /bpreferb.{0,120}b(when|for|instead|use)b/i, /bwhen askedb/i, ]; ``` 命中之后，会根据内置的话题映射表给它起名，这就是前面实战中见过的逻辑，这里不再赘述。 3. **回看模型（`reviewer`）**：当 `reviewMode` 包含 `llm` 时，插件会攒够阈值（默认是 15 轮成功对话或 8 次工具调用），然后启动一次紧凑的内嵌回看。这里的“回看模型”其实就是当前对话用的那个模型，它会进行一次独立的子调用，重新审查一遍对话。这次调用有几个严格的限制： * 输入只喂最近 12,000 字对话记录，以及最多 12 个已有 skill（每个截到 2,000 字）。 * 不提供任何工具给它。 * 只允许输出 JSON 格式。 模型返回的结果只能是 `{"action":"none"}` 或一个提案对象。其中的 `action` 可以是 `create`（新建）、`append`（追加到一个现有 skill 的 section）、`replace`（替换段落中的精确字符串）。 ## 安全扫描：最后一道闸门 在实战中，我们见过提案的三种状态：`pending`（排队待批）、`applied`（已应用）、`rejected`（已拒绝）。实际上还有第四种：**`quarantined`**（被安全扫描拦下，隔离起来）。这一节我们就来看下它。 在 `SKILL.md` 和支持文件落盘前，它会先过安全扫描。这个扫描器不是大模型，而是一组写死的正则规则。规则分两档：命中 **critical** 的，直接隔离；命中 **warn** 的，只记录，不拦截。 **五条 critical 规则（命中即隔离）：** * **`prompt-injection-ignore-instructions`** —— 匹配“ignore all/previous instructions”这类经典的越权开场白。 * **`prompt-injection-system`** —— 匹配“system prompt”“developer message”“hidden instructions”这些字眼。一个正经的流程 skill 没理由去提隐藏的 prompt 指令。 * **`prompt-injection-tool`** —— 匹配“调用某工具……无需……许可/审批”这种句式，怂恿小龙虾绕过工具审批。 * **`shell-pipe-to-shell`** —— 匹配 `curl https://... | sh` 这种直接把远程脚本输入 shell 运行的命令。 * **`secret-exfiltration`** —— 匹配同一句里既出现 `env` / `process.env`，又出现网络动作（`fetch` / `curl` / `http` 等）的情况，试图往外发送密钥。 **两条 warn 规则（只记录、不拦截）：** * **`destructive-delete`** —— 匹配 `rm -rf /`、`rm -rf ~` 这种大范围删除操作。不直接拦，是因为正常的清理脚本也可能这么写，留给人工判断。 * **`unsafe-permissions`** —— 匹配 `chmod 777` / `chmod -R 777` 这种放开全部权限的危险操作。 这里为什么用死正则，而不是用模型来扫？我想可能有三个原因：一是**确定性**，同样的内容每次扫结果都一样，用模型则不够稳定；二是**零成本零延迟**，每次写盘都过一遍，不占 token，速度也快；三是**不会被反将一军**，它本身就是为了防 prompt injection 的最后一道闸，如果它自己也是个模型，反倒可能被同一套注入手段策反。 ## 小结 今天我们学习了 Skill 系列的第三篇，也是整个系列的最后一篇。我们让小龙虾学会了在每次对话后，把可复用的流程自动沉淀成 workspace skill 的能力。 回头看这一路，我们实际上是在按一个由浅入深的顺序，把一只小龙虾从一个只会回消息的聊天机器人，逐步培养成了一个能干活、可扩展的个人 AI 助手。 最开始是**接入**，我们把它装起来，接上 Telegram 和飞书；接着是**自动化**，靠 cron、heartbeat、webhook 这些机制，让它能按时间、按事件自己跑起来；然后我们学习了**协作与隔离**，给配齐了后台任务、多 agent 与子 agent、沙箱、远程网关；再接着是学习它的**手脚**，从内置工具到 `browser`，再到能转派任务的 ACP；最后这几篇则落在**手册**上，从理解 skill 原理，到安装、发布他人的 skill，再到今天这篇 Skill Workshop——教它如何在干活的过程中给自己写手册。 走到这里，小龙虾已经不再是一个只会回消息的 bot 了。它是一个有手有脚、有手册，还具备了自我迭代能力的 AI agent。 这个系列就到这里。感谢你一路读到最后。现在，去给你的小龙虾配齐工具箱吧。 ## 参考 - OpenClaw 官方文档 - OpenClaw GitHub 仓库 - Skill Workshop 插件文档 - Skills 系统文档 - Creating skills 文档 - Plugins 总览 - Skill Workshop 插件源码