改个 Skill 还要走审批?OpenClaw 提案机制的内幕

用 OpenClaw 的人多半遇到过这个情况：你让 AI 帮忙调一下某个 skill 的内容，它没有直接去改文件，而是先弄了个叫”提案”的东西出来，非得你点头才生效。这套机制叫 Skill Workshop，乍看多此一举，但它挡住的麻烦比你以为的多。

一、skill_workshop 到底干了什么

整个机制的核心是一个 tool call——skill_workshop。当 agent 需要更新某个 skill 时，它不再直接编辑 SKILL.md，而是通过这个工具把改动内容打包成一份提案暂存起来。你确认过了，提案才会真正写入目标文件。

说白了就是给 AI 的修改权限加了一道审批门。AI 写得不对，你在提案阶段就能拦下来，不用等文件被改坏了再回滚。

二、这道门是纸糊的

别误会，不是说它没用，而是要搞清楚它的约束边界。Skill Workshop 的规则全写在系统提示词里，靠 LLM 自己遵守——没有代码层面的硬拦截。agent”理应”调 skill_workshop 来走提案流程，但这只是 prompt 层面的约定。

模型有时候不听话，直接改了 skill 文件也是有可能的。这不是 bug，是 LLM 对 prompt 指令的遵从度问题。至少在当前 OpenClaw 版本里，这个”漏洞”是一直存在的。

三、提案的存放位置

所有提案都堆在同一个地方，按 id 分目录管理：

~/.openclaw/skill-workshop/proposals/

存储是全局的，不按 agent 划分。查询时会根据路径做过滤，这个下面展开说。

四、apply：让提案变成实际改动

提案创建之后，想让它生效有两条路：

• 在 Web UI 的 Skill Workshop 页面点确认
• 跑一行命令：openclaw skills workshop apply

apply 的动作很干脆：读出提案里的 proposal_content，剥掉 status、version、date 这些元字段，把剩下的内容直接覆盖写入目标 SKILL.md。提案状态从 pending 跳到 applied，完事。

五、list 命令会过滤，但容易踩坑

openclaw skills workshop list 拉取的是全量提案，但返回前会做一道筛选：检查每条提案的 targetPath，只有路径落在当前 workspace 的 skills 目录下才会出现在结果里。

坑在这：如果你不在 workspace 目录下敲命令，agent 会回退到默认的 main workspace（~/.openclaw/workspace），这时候看到的提案列表跟你想的很可能对不上号。

六、Web UI 有一块看不见的地方

Web UI 打开 /skills/workshop 能看到提案列表，但当前版本有个限制——只展示 main workspace 的提案。

问题出在 API 调用上，Web UI 请求时没传 workspace 参数：

fetch(basePath + `/api/agents/skills/proposals`)

CLI 的 list 命令则会带上 workspace 参数去调 listSkillProposals。你用 CLI 给非 main workspace 创建的提案，在 Web UI 里压根看不到——数据还在全局存储里，只是 UI 没传对的参数去取。这块属于 UI 当前版本的短板。

七、走一遍完整流程

实际操作时的步骤大概是这样：

• 你在对话里说要更新某个 skill
• OpenClaw 识别意图后生成提案
• CLI 查看提案详情：openclaw skills workshop --agent <agent> inspect <proposal-id>
• 内容没问题就应用：openclaw skills workshop --agent <agent> apply <proposal-id>
• 提案变 applied，文件更新到位

习惯 Web UI 的话，记住它的限制——CLI 目前是更靠谱的操作方式。

八、要点速览

Skill Workshop 的思路就四个字：先审后改。在 AI 的自主性和你的安全感之间找了个折中点。它不完美——prompt 约束可能被绕过，Web UI 有盲区——但至少给了你一条可控的改 skill 的路径。用 CLI 走完整流程，是目前最稳的做法。

💬 如果觉得有收获，欢迎在评论区留言交流 👇

作者 · VV · AI 工具 & 技术分享