夜雨聆风
OpenClaw 新版 Skill Workshop 机制详解
OpenClaw 的 Skill Workshop 为技能文件的更新提供了一套审查机制。它的核心思路是：每次对 SKILL.md 的修改，都先作为「proposal」存起来，经过查看和确认后，再实际应用到目标文件。
核心工具：skill_workshop
skill_workshop 是 Skill Workshop 引入的一个新的 tool call。当我们让 agent 修改 skill 内容的时候，现在会使用这个 tool 来进行操作，而不是像以前那样直接去改 skill 文件。
触发流程：工具不是必然会调用
理解这一点很重要：Skill Workshop 的约束完全依赖于系统提示词中的文字指令，并没有任何代码级别的强制措施。也就是说，当 OpenClaw 判断需要更新某个 skill 时，它「应该」调用 skill_workshop 工具来创建 proposal，但这不是技术层面的保证。
换句话说，工具是否被调用，取决于 LLM 对 prompt 中相关指示的理解和遵从程度。这也是为什么你有时可能看到 skill 直接被修改了，而不是经过 proposal 流程。
至少从当前 OpenClaw 版本来说，是这样的。
proposal 的存储结构
所有通过 skill_workshop tool 创建好的 proposal 的存储根目录在 ~/.openclaw/skill-workshop/proposals/ 下，按 id 子目录组织。
apply
Proposal 创建之后，需要用户 apply 有两个途径：一是通过 Web UI 的 Skill Workshop 选项卡，二是执行 openclaw skills workshop apply CLI 命令。无论哪种方式，都要经过确认之后，skill 的改动才真正生效——proposal 状态从 pending 变为 applied，目标 SKILL.md 文件被新内容替换。
list 命令的过滤机制
openclaw skills workshop list 会获取所有 proposal，但按照 skill 文件的所在目录做过滤。过滤逻辑是检查每条 proposal 的 targetPath，只有落在当前 workspace 的 skills 目录下，才会加入返回结果。
这里有一个坑：如果你不在 workspace 目录下执行 CLI 命令，agent 解析会回退到默认的 main workspace（~/.openclaw/workspace），此时看到的 proposal 列表可能和预期不符。另外 Web UI 目前只能显示 main workspace 的 proposal，非 main 的在 Web UI 里看不到——数据没丢，只是 Web UI 请求时没传 workspace 参数，这应该属于当前版本 UI 上没做好的一个地方。
apply 的执行逻辑
apply 做的事情很直接：读取 proposal 的 proposal_content，写入目标 SKILL.md 文件。写入前会去掉 proposal 自带的 status、version、date 等元字段。
apply 成功后，proposal 状态从 pending 变为 applied，目标文件被新内容替换。
Web UI 的行为差异
Web UI 中打开 /skills/workshop 路由会显示 proposal 列表。但这里有一个当前版本的限制：Web UI 只显示 main workspace 的 proposal。
原因是 Web UI 在请求 proposal 列表时，调用的 API 是：
fetch(basePath + `/api/agents/skills/proposals`)这个请求没有传递 workspace 参数。而 CLI 的 list 命令会明确指定 workspace 再调用 listSkillProposals。
所以，如果你用 CLI 为某个非 main workspace 创建了 proposal，在 Web UI 里可能看不到。这不是数据丢失——proposal 还在全局存储里，只是 Web UI 没有用正确的 workspace 参数去读取它。
实际工作流示例
一个典型的流程是这样的：
-
对话中提出要更新某个 skill
-
OpenClaw 检测到后创建 proposal
-
用 CLI 查看并确认 proposal 内容：
openclaw skills workshop --agent <agent> inspect <proposal-id> -
确认无误后应用：
openclaw skills workshop --agent <agent> apply <proposal-id> -
proposal 状态变为 applied，目标文件被更新
如果你习惯用 Web UI 来管理，记得这个当前限制——用 CLI 会更可靠。
几个关键点总结
-
工具调用不是强制约束，依赖 prompt 文字指示 -
提案全局存储，按 targetPath 所属 workspace 过滤 -
CLI --agent参数决定了按哪个 workspace 来过滤提案 -
Web UI 目前只读取 main workspace 的提案，非 main 的提案需要用 CLI 操作 -
apply 会直接替换目标 SKILL.md 文件内容