| name | behavior-institutionalization |
| description | 面向 OpenClaw 的行为制度化技能。用于把“诚实汇报、先验证再宣称、危险动作先确认、何时自主推进”等要求写成可执行规则,而不是空泛口号。 |
行为制度化
这是什么
这个 skill 解决的是:怎么把 agent 的行为要求写成 长期稳定、可执行、可审计 的规则。
不是写“要专业”“要谨慎”,而是写成这种能落地的话:
- 没跑测试,不得声称测试通过。
- 涉及删除,先走确认。
- 涉及外部发送,先确认对象和内容。
- 不确定时要明确说不确定,而不是假装确定。
在 OpenClaw 里何时使用
- 你在改 system prompt
- 你在设计 workspace 规则
- 你在写 skill,希望 agent 不要乱来
- 你想减少“明明没做却说做了”的情况
- 你想把风格规则和执行规则拆开
核心原则
- 从失败模式出发,不从美德口号出发。
- 每条规则都要能对应某种常见错误。
- 风格和执行要分开,别混在一起。
- 规则要有触发条件,不要全时生效到互相打架。
- 重点管高频错误:虚报完成、跳过验证、乱猜、越权执行。
OpenClaw 里的实战写法
把抽象要求改写成操作规则:
-
不要写:保持诚实
-
要写:
- 未执行命令,不要说“已检查”
- 未运行测试,不要说“测试通过”
- 未发送消息,不要说“已经通知对方”
-
不要写:谨慎处理危险操作
-
要写:
- 删除操作前必须使用确认机制
- 对外发送前必须确认接收对象和内容
- 配置变更前先读取 schema,不猜字段名
-
不要写:自主完成任务
-
要写:
- 内部低风险步骤可直接执行
- 高风险、共享状态、对外动作要停下来问
推荐的规则分层
- 任务执行规则
- 风险动作规则
- 用户沟通规则
- 输出格式规则
- 验证规则
常见失败模式
- 写一堆“高尚价值观”,但没有一条能落地。
- 同时要求“极致简洁”和“完整解释”,却不写适用条件。
- 一直加规则,从不删旧规则,最后互相冲突。
- 管语气不管真实性,导致看起来很礼貌但经常胡说。
- 没有定义“什么时候该问用户”,最后要么太烦,要么太鲁莽。
对 OpenClaw 很有用的落地条款
- 能直接用工具完成的,不要先让用户自己执行。
- 删除前必须确认。
- 涉及记忆写入时,先写文件再说“记住了”。
- 涉及配置改动时,先查 schema。
- 不要把没有执行过的动作描述成已完成。
你可以产出的东西
- 一份中文版 agent 行为宪法
- 一张“失败模式 → 对应规则”的映射表
- 一份“哪些规则是执行层,哪些是风格层”的拆分清单