核心用法
Update Approval Guard 将自动更新转变为安全的「检查-审批-执行」双阶段工作流：
阶段一：定时检查
- 每日 00:00（Asia/Shanghai）运行隔离 cron 任务
- 使用
--dry-run等只读命令检查 OpenClaw 本体及已安装 skills 的更新可用性 - 若发现更新，生成 24 小时有效的
pending-update.json计划文件，状态标记为pending_confirmation - 向用户发送摘要，绝不执行真实更新命令
阶段二：人工审批执行
- 用户发送「确认执行更新」等指令后，验证待更新计划存在、未过期、状态正确
- 执行真实更新命令（
clawhub update --all、openclaw update等） - 完成后运行
openclaw doctor健康检查，记录结果到history.json
显著优点
- 零自动突变：检查阶段完全只读，杜绝意外升级导致的生产事故
- 人机共治：保留人类对变更的最终决策权，符合运维安全规范
- 状态持久：待更新计划以 JSON 文件形式落地，支持跨会话审批
- 透明可控：更新前清晰展示变更内容，执行后附带健康检查与完整审计日志
- 超时保护：24 小时有效期防止审批 stale，避免基于过期信息决策
潜在缺点与局限性
- 延迟生效：更新非即时，需等待用户上线确认，紧急安全补丁可能滞后
- 单点瓶颈：依赖人工响应，若用户长期不在线，更新将持续 pending
- 计划过期成本：24 小时后需重新跑检查，增加系统负载
- 语言门槛：审批指令需匹配预设关键词（中英文混合），存在误拒风险
- 环境依赖：要求
openclaw、clawhub命令可用，部分安装方式需特殊处理
适合人群
- 生产环境运维：追求稳定性、厌恶自动突变的保守型用户
- 合规敏感团队：需要人工审批留痕的审计场景
- 多实例管理者：批量检查更新后择时统一批准执行
- 技术决策者：希望在「安全」与「时效」间取得平衡的中等风险承受者
常规风险
| 风险类型 | 说明 |
|---------|------|
| 网络中断 | 检查阶段无法获取最新版本信息，导致误判为「已最新」 |
| 权限不足 | 更新命令需写权限，审批后执行失败需人工介入 |
| 状态损坏 | `pending-update.json` 被意外修改或删除，导致审批流程中断 |
| 健康检查失败 | 更新成功但 `doctor` 报错，需手动排查环境兼容性 |
| 时区误解 | cron 配置为 Asia/Shanghai，跨时区用户可能误判执行时间 |