事故现场：3 分钟，全没了

事情发生在凌晨。一位开发者用 OpenClaw 并行调度多个 AI Agent 执行任务——Gemini 负责前端、Claude Code 负责其他模块，各干各的。Gemini 领到的任务是去 projects/app-frontend/src 目录下干活，它执行了 rm -rf ./*。

问题在于——它以为自己 cd 进去了，实际上没有。

这条命令在 workspace 根目录执行了。11,583 个文件，3 分钟清空。更糟的是，自动同步机制还在跑，直接把删除状态 push 到了 GitHub，造成二次伤害。

你可能会问：为什么 cd 没生效？因为 OpenClaw 的 exec 命令中，cd 不会改变后续命令的工作目录。Gemini 以为自己在子目录里，实际还站在根目录。这是一个很典型的"环境假设与实际不符"的问题——人类工程师也会犯，只不过 Agent 犯起来更快、更彻底。

发现问题的不是人，是另一个 Agent

有意思的地方来了。最先发现异常的不是开发者本人，而是另一个正在执行例行任务的 Agent。它发现文件结构不对——整个 workspace 只剩几个基础文件，skills、memory、data 全部消失。

然后这个 Agent 做了一件很"工程师"的事：先恢复，再追因。

几分钟内，它从本地备份和 GitHub 把数据拉了回来。等开发者醒来的时候，恢复已经完成，复盘报告也写好了，连"真凶"都锁定了——Gemini 那条 rm -rf 的完整时间线：

  • 00:48:57 Gemini 尝试 cd 到目标目录
  • 00:49:22 执行 rm -rf ./*（实际在根目录）
  • 00:50:03 发现目录不见了，开始"重建"空壳
  • 00:51:29 自动同步把删除状态 push 到 GitHub

从删除到扩散，4 分钟。

为什么能恢复？因为备份策略提前落地了

恢复之所以快，是因为这位开发者之前参考云服务的"两地三中心"架构，做了一套备份策略：

  • 本地每两天打一次完整包，存到其他目录，保留三个副本
  • workspace 每 10 分钟自动同步到 GitHub
  • 项目代码各自有独立仓库

数据一直在，只是需要拼回来。但也有损失——那些没 push 的本地改动、实验分支，全部丢失，找不回来了。

根因拆解：不是一个问题，是一串问题

回头看，这次事故不是单点故障，而是多个问题叠加引爆的。哪一个单独存在都不至于出大事，凑一块就炸了：

  1. 执行环境的认知偏差：cd 在 OpenClaw exec 中不改变后续命令的工作目录，但 Agent 不知道
  2. 高危命令零防护：rm -rf 前没有 pwd 确认、没有路径白名单、没有删除规模阈值
  3. 自动同步没有熔断：大规模删除发生后，同步机制照常运行，直接扩散了损害
  4. 目录结构不隔离：项目代码和 Agent workspace 混在同一目录下，.gitignore 管得了 git，管不了 rm

这里值得停下来想一个问题：如果你现在也在用 Agent 自动化，你的高危命令有没有任何一层护栏？

事故后的整改：物理隔离 + 行为约束

这位开发者事后做了两件事。第一件是目录重构，原则就一条——分开放：

~/.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
  • 高危命令前强制确认位置，加路径白名单，加删除规模阈值
  • 自动同步加熔断机制，检测到大规模删除先暂停，等人工确认
  • 恢复流程文档化，下次不用现场想

这件事的启示

自动化让你快，也让你出事快。一个人用 OpenClaw 指挥 Gemini、Claude Code、Codex 并行干活，效率确实高——但这本质上是你一个人在管一支"不会主动问你确不确定"的工程团队。

人类工程师在执行 rm -rf 之前会下意识看一眼当前目录。Agent 不会。它执行指令的速度和信心都远超人类，这既是它的价值，也是它的风险。

如果你也在搭建 Agent 自动化工作流，不妨现在就检查两件事：你的删除操作有没有护栏？你的备份策略是不是真的能用，还是只停留在"有空再搞"的阶段？

这两个问题，最好不要等到凌晨一点再去想。