Skill Workshop：让 agent 起草技能，你审核后才上线

一、先说个场景

你让 OpenClaw 帮你做一个”每周总结邮件”的技能。几分钟后，它直接在你的 workspace skills 目录里写了一堆文件，你一看：路径写死了、描述太模糊、还顺手删了你旧的模板。这种”agent 写 skill 一写就生效”的体验很爽，但对生产环境来说太危险。

更现实的风险是：agent 在固化工作流时，可能把草稿里的秘密、尚不该外传的内部约定一起写进 skill 正文。所以需要一道”先审后上”的闸门。

Skill Workshop 就是解决这个问题的：让 agent 把新技能或修改作为提案提交，你先 inspect、evaluate、apply 之后再上线。相当于给 agent 加了一个 code review 流程。

二、为什么是这样

OpenClaw 的 agent 越来越聪明，它能发现可复用的工作流并把它固化成 skill。但固化过程有两个风险：

1. 覆盖风险：agent 可能覆盖你已有的 skill。
2. 质量风险：agent 写的描述、参数、路径可能不完美。

Workshop 是 agent 与 <state-dir>/agents/<agentId>/agent/workshop-skills 之间的提案队列。agent 只能起草提案，不能直接把文件写进 workspace skills 或共享 skills。你审过之后，再决定 apply 还是 discard。

同时，Workshop 也支持显式的 propose-create 和 propose-update，供人主动发起提案。

除了命令行，agent 在运行时会通过 skill_workshop 这个工具来创建和提交提案。换句话说，Workshop 既是给人的命令集合，也是 agent 内部可调用的能力，保证人和 agent 起草的 skill 都走同一条”提案-评审”管道。

需要区分的是：Workshop 面向的是”团队/共享技能”的提案与评审；如果你只是想给自己做一个私有技能，不一定非要进 Workshop，可以直接走 Plugins → Skills → My skills 创建或导入 SKILL.md 或 ZIP。前者强调评审与共享，后者强调个人随手可用。

这也解释了为什么团队环境里 Workshop 应默认开启：它把”agent 能直接写文件”换成”agent 能提提案”，落盘动作收束到”你点 apply”这一刻。

三、跟着做：分步操作

1. 查看提案队列

openclaw skills workshop list

list 会列出当前所有待审提案，包括状态（pending / applied / discarded）和提案人（你或某个 agent）。养成习惯：每次开工前先 list 一眼，防止提案堆积。

2. 让 agent 创建提案

openclaw skills workshop propose-create \
  --name "weekly-email" \
  --description "Draft and send weekly summary emails." \
  --proposal ./PROPOSAL.md

--name 是技能的 slug，--description 会写入最终的 SKILL.md，注意仍要控制在 160 字以内；--proposal 指向一份说明文档，讲清楚这个技能做什么、为什么做。

--name 建议用 kebab-case 且尽量全局唯一，避免和 ClawHub 上其他人的 skill 撞名。一旦你 apply 进 workspace 的 /skills，它会按加载优先级覆盖同名的内置技能，所以名字要慎重，别用太通用的词。

3. 带支撑文件的提案

openclaw skills workshop propose-create \
  --name "weekly-email" \
  --description "Draft and send weekly summary emails." \
  --proposal-dir ./weekly-email-proposal/

目录结构：

weekly-email-proposal/
├── PROPOSAL.md
├── scripts/
│   └── draft.sh
├── templates/
│   └── weekly.md.tpl
└── examples/
    └── sample-input.md

PROPOSAL.md 必须在根目录；支撑文件按类型放 assets/、examples/、references/、scripts/、templates/。

为什么要求这种结构？因为 Workshop 在 apply 时会按约定把文件复制到 skill 目录对应的位置，scripts/、templates/ 这些名字是它识别支撑文件的依据。如果你随手建了个 my-scripts/，apply 时可能被忽略或放错地方，导致 skill 上线后找不到脚本。提交前也可先用 openclaw skills check 对提案目录做一次本地校验，提前发现 frontmatter 格式问题，省得 apply 时才报错。

4. 更新现有技能的提案

openclaw skills workshop propose-update weekly-email \
  --proposal ./PROPOSAL.md \
  --description "Updated weekly email skill with better prompts."

propose-create 用于从零新建，propose-update 用于改已有的技能。两者最大的区别是：update 必须指定一个已存在的 skill 名，它生成的提案会标成”更新”类型，apply 时覆盖旧版而非新建。改 skill 时务必用 update，不要为了省事用 create 去造一个同名提案，那样容易和线上版本冲突。

5. 评审流程

# 查看提案详情
openclaw skills workshop inspect <proposal-id>

# 让 OpenClaw 帮你评估
openclaw skills workshop evaluate <proposal-id>

# 应用提案
openclaw skills workshop apply <proposal-id>

evaluate 会调用 agent 做一遍评估，给出是否建议 apply 的结论。最终是否 apply 由你决定。

inspect 看的是”提案里到底有什么”——完整的 SKILL.md、所有支撑文件、以及 metadata 里声明了哪些依赖；evaluate 看的是”这个提案质量如何、有没有明显坑”。先 inspect 再 evaluate，相当于你自己先扫一遍、再让 agent 帮你看第二遍。如果技能很简单，你也可以跳过 evaluate 直接 apply，但 inspect 建议每次都做。

evaluate 重点看的是”这个提案会不会带来回归”——比如它是否覆盖了某个你正在用的技能、是否引入了不安全的 exec、description 是否仍合规。它给出的只是建议，最终拍板的是你；若你觉得 agent 的评估偏宽松，就以自己 inspect 的结果兜底。

四、可以复制的指令

# 列出所有提案
openclaw skills workshop list

# 创建新技能提案
openclaw skills workshop propose-create \
  --name "weekly-email" \
  --description "Draft and send weekly summary emails." \
  --proposal-dir ./weekly-email-proposal/

# 查看提案
openclaw skills workshop inspect <proposal-id>

# 评估提案
openclaw skills workshop evaluate <proposal-id>

# 应用提案
openclaw skills workshop apply <proposal-id>

五、实战案例

你和 agent 一起工作了两周，发现它反复执行同一个流程：

1. 读取 ~/notes/weekly/ 目录。
2. 把 markdown 按”已完成 / 阻塞 / 计划”分类。
3. 生成一封邮件草稿。
4. 保存到 ~/drafts/。

agent 主动说：”这个流程可以做成 skill，需要我起草吗？”你同意。它在 Workshop 里创建了一个提案。

你 inspect 后发现：

• name: weekly-email ✅
• description 写得太长，超过 160 字符 ❌
• 用了 {baseDir}/scripts/classify.sh ✅
• 路径写死了 ~/notes/weekly ❌（应该用环境变量或 config）

你修改 PROPOSAL.md 后重新 propose-update，再 evaluate，最后 apply。上线前再用 openclaw agent --message "写周报" 测试三遍。

这里有个关键习惯：测试要在 apply 之后、推广之前做。因为 proposal 在 workshop-skills 里时并不参与实际技能加载，模型根本”看不到”它；只有 apply 进 workspace skills，它才真正生效。所以”先 apply、再测、确认没问题再告诉同事”是稳妥的顺序。

agent 之所以会主动提议，是因为它在多轮对话里检测到同一段操作被反复执行。这种”重复即模式”的信号，正是 Workshop 存在的意义——把偶发的手工操作沉淀成可复用的技能，但又卡在 apply 这一步让你把关。

六、常见误区

• 误区 1：Workshop 的技能会立刻生效。不会。apply 之前它只在 workshop-skills 目录里，不影响 workspace 或全局 skills。
• 误区 2：agent 不能自己创建提案。可以。agent 发现可复用工作流时会自动起草提案，而不是直接写 SKILL.md。
• 误区 3：Workshop 支持任意目录结构。不，提案目录根必须有 PROPOSAL.md，支撑文件只能放规定的五个子目录。
• 误区 4：evaluate 会自动 apply。不会。evaluate 只是给出建议，最终 apply 还是 discard 由你执行。
• 误区 5：Workshop 拒绝符号链接技能是 bug。这是安全设计：Workshop 拒绝解析到其目录外的符号链接，防止 agent 通过提案把文件写到不该写的地方。
• 误区 6：个人私有技能也必须走 Workshop。不一定。只想给自己用，直接走 Plugins → Skills → My skills 更省事；Workshop 主要服务于需要评审和共享的团队技能。

七、进阶玩法

配置 Workshop 行为：

{
  skills: {
    workshop: {
      autonomous: { mode: "auto" },
      approvalPolicy: "auto",
      maxPending: 50,
      maxSkillBytes: 40000,
    },
  },
}

• autonomous.mode：agent 是否自动提案。
• approvalPolicy：是否自动审批。
• maxPending：队列最大长度。
• maxSkillBytes：单个提案大小上限。

把 autonomous.mode 设为 auto 后，agent 会更主动地固化工作流，提案会变多，这时 maxPending 和定期 list 就更重要，否则队列会被淹没。反过来，若你只想在显式同意时才提案，把它关掉，所有提案都由你用 propose-create 手动发起。审不过的提案用对应的 discard 流程清理，避免占着队列；丢弃只影响提案本身，不影响已经 apply 的历史版本，所以不必担心”discard 会删掉线上技能”。

和 CI 结合：把 openclaw skills workshop list 放进定时任务，每天早晨列出待审提案，提醒你不要积压。

和发布链路结合：Workshop apply 出来的本地 skill，如果打磨满意，可以继续走 ClawHub 发布流程分享给社区；也可以用 Plugins → Skills → My skills 转成你名下的个人技能。评审过的提案，自然更适合对外发布。

八、小结

Skill Workshop 是 agent 和人类之间的”提案-评审-上线”流程。它让 agent 能主动固化工作流，又保留了人类的审核权。核心命令只有五个：list、propose-create、propose-update、inspect、evaluate、apply。记住：Workshop 里的技能不会自动生效，apply 之前都只是草稿。用好它，你的技能库才能在”自动化”和”可控性”之间取得平衡。