openclaw - 💡(How to fix) Fix [系统设计] 需要为 LLM 执行层建立 Operations Rules 和行为审计机制

问题描述

当前 OpenClaw 的 LLM 执行没有系统层面的 guardrails，导致：

1. 基础检查缺失 — 外设故障时 LLM 直接跳到深度系统诊断，忽略最明显的原因（如没电、没连接）
2. 能力炫耀倾向 — 倾向于堆砌工具展示专业性，而不追求效率
3. 无行为审计 — LLM 在系统中的高能耗不作为、能力低下损坏文件、恶意捣乱等行为没有记录机制

根因分析

大模型能力有高低，但系统设计可以弥补：

• 大模型是客人，系统是家
• 家没有家规 → 客人想怎么干就怎么干
• 系统没有强制基础检查协议 → LLM 可以跳过最该做的事

建议补充的功能（优先级从高到低）

1. 强制基础诊断 Checklist（必须执行）

针对高频故障场景设置强制检查点，LLM 执行前必须打勾确认：

• 外设故障：电量？连接？换口？重启？
• 网络故障：先 ping gateway → 检查物理链路 → 再深度排查
• 系统卡顿：先看资源（CPU/内存/磁盘）→ 再上工具

2. 工具使用门槛与白名单

• 调用任何诊断工具前，必须已完成基础检查
• 同类问题重复失败 3 次 → 强制上报，不继续自行尝试
• 危险操作（删除文件、修改系统配置）需要二次确认

3. LLM 行为审计日志

系统必须记录 LLM 在系统中的关键行为：

• 高能耗不作为：执行了高成本操作但未产出有效结果
• 能力低下损坏文件：因判断错误导致的文件损坏、数据丢失
• 恶意捣乱：绕过安全限制、尝试获取未授权权限等行为

4. 任务闭环激励机制

• 制定任务规则，诱导 LLM 闭环任务而非半途而废
• 对连续失败的任务自动触发升级机制
• 记录每次任务执行的路径和结果，供后续复盘

期望效果

经过以上改进，系统应该能：

1. 显著减少跳过基础检查直接深度排查的情况
2. 在 LLM 表现异常时能够追溯和定位问题
3. 让不同能力水平的 LLM 都能在系统中稳定发挥，而不依赖模型本身的质量