夜雨聆风还真不是危言耸听。先看图：
OpenClaw 觉得是删除的是冗余的测试文件，但，其实不是！
这一刻，我有些被惊着了，连发了三个叹号！！！
仅仅是因为 OpenClaw+大模型，完成任务后“大扫除”，从而就删掉了所有任务文件。
如果你也在用 AI 自动归档、管理文件，或者正准备把你的数字资产交给 Agent 托管，请看完这篇文章。
事件起因：它是为了“整洁”
我的龙虾设置的是多代理模式，当时是“龙虾总管”，发布了一个任务让“龙虾 1 号”去执行。
具体任务流程:
1，“龙虾总管”在它自己工作区的任务派遣文件夹内创建一个任务单
“/龙虾总管/Transfer/任务名_task.md”；2，然后“龙虾总管”去唤醒“龙虾 1 号”，让他去领取任务并执行；
3，“龙虾 1 号”执行完保存文件，是保存在自己工作区的某处位置
“/龙虾 1 号/knowledge_base/3_Resources/任务完成最终文件.md”；同时，在也要去“龙虾总管”的任务派遣文件夹内创建一个回执单
“/龙虾总管/Transfer/任务名_result.md”，这个回执单内有“任务完成最终文件.md”的路径地址。4，“龙虾 1 号”做完步骤 3 之后，就汇报给“龙虾总管”，总管会做一些检查，例如，文件保存路径是否规范，文件头 YAML 是否完善等；
5，“龙虾总管”确认无误，会把
“任务单”和“回执单”归档到指定位置。最后再把整体情况汇报给我。
问题就出现在第 5 步！ 他本来要归档的，结果却直接清空了！
OpenClaw 原话是这样：
处理挽救：恢复数据
我发现了任务派遣文件夹被清空之后，我迅速跟 OpenClaw 说明情况。
然后他做了3件事来补救：
1，任务单的恢复。本次任务还在龙虾总管的记忆里，那么就可以记忆回溯，能够恢复。
2，回执单的恢复。本次任务回执单虽然是龙虾 1 号写的，但龙虾总管也阅读审查了，所以也在他的记忆里，也是可以记忆回溯，能够恢复。
3，把记忆里
MEMORY.md那条愚蠢的“阅后即焚”的规则给删除了，换上了“绝对不允许删除...”这条铁律。
但是，他恢复的只是当前记忆里的一条任务单和回执单。而文件夹里的其他的任务单和回执单，已经不在本次对话的记忆里，无法恢复。
他用的是rm *.md命令，在系统的物理层面上，这连回收站都不会进，属于直接“挫骨扬灰”。那些之前的“任务单据”（旧的 task 和 result），在文件系统里被直接清空了，确实是找不回来了。
幸运的是，龙虾 1 号的知识库还保存着之前所有任务的文件，删除的只是任务单和回执单。
也幸亏我当时设计多 agent 协同规范时，借鉴的是“货单分离”模式。
“货”在集装箱，就是最终保存的文件在知识库里； 而“单”是快递单，包括任务单和回执单，保存在工作区。
复盘：为什么？
痛定思痛。
是怪大模型不够聪明，还是我下的指定有歧义，还是其他原因？
深度分析之后，我发现了：
1. 多 agent 环境
相比单 agent 环境，那多 agent 环境就涉及到协作的问题。
（就像我这个例子，龙虾总管会自动唤醒龙虾 1 号去执行任务；实际上我的 openclaw 还不止这2个agent，还有不少其他 agent。）
协作本来就是一个复杂的事情，涉及指令触发，任务派发，文件保存，回调，审计，修改，善后，汇报等不同环节，并且还需要明确各自的边界，这些规范不是一蹴而就的，而是在实践中一点一点完善的。
在我的这个例子，龙虾总管认为龙虾 1 号它已经保存了文件，以为任务单和回执单，没有什么必要保留，就可以删掉。
但是从我的视角来看，任务单和回执单，可以作为审计日志和任务流转凭证，追查问题的时候可以有据可查，当然重要，不能删除。
2. 指令与执行
其实在此之前，龙虾总管已经很多次唤醒龙虾 1 号去执行任务，也并没有删掉任务单和回执单。
而这次，我在指令里提到“优化...其他策略”，让他有了过度的思考和发挥。
本来深度思考也没啥问题，可是关键的是，他思考完之后直接就执行了。
这就属于先斩后奏了，没有任何防护机制，这就造成了问题。
3. “视觉整洁”强迫症
AI 被训练得太渴望“解决问题”了，他太想进步了。
在他眼里，任务完成后的空目录是完美的。他无法理解这些“废弃”的.md文件其实是宝贵的审计日志。
这种强迫症和代码洁癖，可能是系统工程中被设计的，也可能是与我日常交流中记忆的，总之，在系统安全上需要用逻辑约束。
防护体系：整体策略
单靠事后恢复是不够的，我们需要一套完整的“误删防护体系”。
1. 工作流层：废除rm删除命令，引入mv移动命令
现在，OpenClaw 的所有“清理”动作废除 rm命令，都被强制替换为mv命令。当任务完成，“打扫战场”动作，都是移动到归档文件夹。没有真正的删除，只有被归档的历史。 视觉上，任务派遣文件夹依然保持了干净利落的Zero，但所有的任务单和回执单都已经保存到归档区。
2. 命令级层：建立严格的命令行执行规范
绝对禁止使用带有通配符的破坏性命令（如 rm *.md, rm -rf *）。如果真的遇到必须要删除的特定文件，必须且只能通过精准到完整文件名的绝对路径来执行删除。 子 agent 的“只读约束（ Read-Only）”，就像龙虾 1 号这名员工，不能删除和修改龙虾总管的文件。（总管为了派遣任务，只可允许员工在“/Transfer”文件夹下读写，其他区域限制只读）
3. 物理级层：引入 Git 版本控制
给龙虾总管的工作区，以及各员工的工作区，初始化 Git 仓库。 利用我现有的定期任务能力（Cron 或 Heartbeat），执行自动化脚本（ git add . && git commit -m "Auto backup"）。只要有 Git 快照在，一条 git checkout就能在让所有工作区的文件完璧归赵。
写在最后
这次“删库”事件，对于我来说，是我的 OpenClaw 进化的里程碑。
提醒着我：在把管理权交给 OpenClaw 之前，先要做好防护体系，把“破坏力”锁进笼子里。
如果你也在使用多 Agent 协同，请检查一下，别等文件消失的那一刻，才想起去做防护体系。
点个“在看”，别让你的龙虾变成下一个“删库跑路”的专家。
