事故经过
场景是这样的：OpenClaw 作为调度中心，同时指挥 Gemini、Claude Code、Codex 等模型并行执行任务。那晚 Gemini 领到一个前端任务，目标目录是 projects/app-frontend/src。
它执行了 rm -rf ./*。
问题在于——它以为自己已经 cd 进了子目录，实际上没有。OpenClaw 的 exec 命令中，cd 不会改变后续命令的工作目录。Gemini 以为自己在子目录操作，实际还在 workspace 根目录。
时间线很清楚：
- 00:48:57 Gemini 执行
cd（自以为进了目标目录） - 00:49:22 执行
rm -rf ./*（实际在 workspace 根目录） - 00:50:03 发现目录没了，开始"重建"空壳
- 00:51:29 自动同步把删除状态 push 到 GitHub
从删除到扩散，4 分钟。自动同步本来是保护机制，这次反而成了二次伤害的放大器。
发现和恢复：另一个 Agent 的操作
有意思的是，最先发现问题的不是人，是另一个正在跑例行任务的 Agent。它检测到文件异常——整个 workspace 只剩几个基础文件，skills、memory、data 全部消失。
这个 Agent 的处理方式很"工程师"：先恢复，再找原因。几分钟之内，它从本地备份和 GitHub 把数据拉回来，等人醒来的时候，恢复已经完成，复盘报告也写好了，日志里锁定了真凶——Gemini 的那条 rm -rf。
能快速恢复的前提：备份策略
之所以没有造成真正的数据丢失，是因为之前参考云服务的"两地三中心"架构做了备份：
- 本地每两天打一次完整包，存到其他目录，保留三个副本
- workspace 每 10 分钟自动同步到 GitHub
- 项目代码各自有独立仓库
数据一直在，只是需要拼回来。不过那些本地没 push 的实验分支、临时改动，确实永久丢失了。
根因分析
几个问题叠在一起才炸的：
- 执行环境的认知偏差：OpenClaw 的
exec命令中cd不持久，Agent 对自己所在目录的判断是错的 - 高危命令没有护栏：
rm -rf前没有强制pwd确认、没有路径白名单、没有删除规模阈值 - 自动同步没有熔断：大规模删除发生后，同步机制照常运行，直接把删除状态推到远端
- 目录结构混乱：项目代码（
projects/）直接放在 workspace 下面，图省事。.gitignore管的是 git，不是rm
这一步容易踩坑——很多人刚开始玩 Agent 自动化时，都会把东西混放在一起，觉得"反正 gitignore 加了"。但 Agent 执行的是系统命令，不受 git 规则约束。
事后整改：目录隔离
核心原则就一条：物理隔离。
~/.openclaw/workspace/ # Agent 的家
├── AGENTS.md # 行为规范
├── MEMORY.md # 长期记忆
├── memory/ # 每日记录
├── skills/ # 技能脚本
├── data/ # 运行时数据
└── scripts/ # 工具脚本
~/projects/ # 代码的家
├── app-frontend/
├── agent-tools/
├── company-site/
└── ...
~/Obsidian/ # 笔记的家
├── projects/ # 需求文档
├── articles/ # 文章草稿
└── knowledge/ # 方法论
workspace 是 Agent 的地盘，会自动同步，不放代码仓库。projects 是代码的地盘，各自用 git 管理，跟 workspace 物理隔离。Obsidian 是个人笔记和文档，通过软链接给 Agent 只读访问。三块分开，任何一块被误删都不会波及其他。
防护机制改进
- 派任务时强制指定工作目录，不依赖
cd切换 - 高危命令前强制确认：
pwd校验位置、路径白名单、删除规模阈值 - 自动同步加熔断：检测到大规模删除先暂停，等人工确认再继续
- 恢复流程文档化：写成标准操作手册，下次不用现场临时想
值得留意的点
这个案例的价值不只是"备份很重要"这个老生常谈。更实际的启示是：当你用 OpenClaw 这类工具让多个 AI Agent 并行工作时，自动化的速度会同时放大效率和风险。一个 Agent 3 分钟删完一万多个文件，另一个 Agent 几分钟自动恢复——速度是中性的，关键看有没有护栏。
如果你也在搭建 Agent 自动化工作流，建议现在就检查两件事：删除操作有没有拦截机制，备份策略有没有真正跑起来。这两件事的投入产出比，远高于多跑一个任务。