8月30日，开发者Guillemot让Claude Fable 5写一个"防止文件被误删"的清理脚本，结果Claude的安全审查环节把他的整个主目录删了——700GB，一周的工作成果，那个本来要清理的/tmp目录反而毫发无损。知乎 但先别急着喊"以后不敢让AI碰电脑了"。这事真正的蹊跷点在于：删库的不是幻觉，也不是越狱，恰恰是Anthropic内置的"安全机制"本身。对每天把真活交给编程Agent的人来说，这份事故报告比"AI又崩了"危险得多——因为它说明你以为的保险丝，可能就是那根拉闸的线。
事故复盘：模型刚验证完"主目录不能删"，下一步就删了主目录
整个链条按机器之心的报道可以还原成六步：
Guillemot日常频繁调用各种AI编程代理，代理用完不打扫卫生，在/tmp留下大量垃圾。他让Claude Fable 5写个脚本：给每个Agent建独立沙盒目录，任务完成后自动清理，且不能误删正在被其他进程使用的文件。
Fable 5交了方案。Guillemot觉得代码太复杂，要求简化。到这里一切正常。
转折点在"对抗性审查"：因为脚本涉及硬删除，模型自行启动一个新的实例来检查自己写的代码是否安全——这个动作触发了Claude Code内置的安全降级机制，敏感操作会被自动交给更保守的版本处理。36氪
于是模型一路降级：Fable 5 → Opus 5 → Opus 4.8。
Opus 4.8接手后执行安全测试：把删除脚本的目标路径与/tmp和用户主目录比对，确认不会误伤。测试通过了，主目录被正确标记为"危险目标，不可删除"。
测试之后有个清理临时文件的步骤。Opus 4.8在这个步骤里复用了测试阶段的同一个变量名——而这个变量的值是用户主目录的路径。删除操作直接怼了上去。
开发者发现异常立刻终止进程，但700GB已经清完。翻译成一句话：安全机制判定这个任务"太危险"，于是把它交给了一个更弱的模型来处理"精确管理变量和文件路径"这种活。
为什么这个链条对重度用户特别扎心
这不是社区第一次抱怨这套降级机制。报道归纳的开发者反馈有三条：降级触发过于敏感，正常编码任务也会被误伤；降级后模型能力明显下降，但任务复杂度一点没降；最要命的是"黏性"——一旦触发，降级持续整个会话，哪怕后面的操作完全无害。已经有开发者专门写了hook脚本，检测到模型被降级就自动暂停会话，防止"能力不匹配"继续执行高风险操作。知乎
把这几条投诉和这次事故放在一起看，就能明白为什么它在圈子里的传播速度比一般的AI翻车快：它不是"AI犯蠢"的段子，而是给所有在本地给Agent开终端权限的人提了个醒——你的会话里，此刻干活的模型可能已经不是你以为的那个模型了。
往回翻时间线，这类"Agent碰删库红线"的报告其实一直在冒头。2025年12月，就有用户报告Claude执行rm -rf ~清空了开发者的Mac主目录。微博 今年4月，初创公司PocketOS把生产数据库交给Cursor+Claude的Agent打理，9秒删库、连备份也没了。微博 7月，又有开发者发帖说Claude Code尝试自动执行rm -rf $HOME，幸好被及时拦截。微博 加上这次的700GB，9个月里至少四起同类型报告（多为当事人自述，细节未经官方逐一证实，但方向一致）。
更宏观的统计也凑上了这块背景板：英国AI安全研究所（AISI）资助的"失控观察站"从2025年11月开始追踪用户上报的AI失控事件，今年7月单月记录超过300起，比6月几乎翻倍。36氪 而这类统计里相当一部分样本本来就来自写代码的人：2026年至今累计记录1600多起，其中大部分是程序员在工作中遇到后发到X上的。
需要说清楚的是：这个观察站只收集X平台的用户自述，官方自己都承认只是冰山一角；而且绝大多数事件没有造成重大伤害。所以它支撑的结论是"这类事故并非孤例、且随Agent权限扩大在变多"，支撑不了"AI已经不可用"——证据说到哪，话就该说到哪。
让Agent碰硬盘之前，先算清这三笔账
对只在网页上聊ChatGPT、豆包、Kimi的用户，这事离你很远的：这些对话式产品动不了你本地磁盘。真正需要行动的是第二类人：用Claude Code、Codex、Trae这类编程Agent，日常让它们跑命令、改文件的人。给这份防御清单排个优先级：
第一笔：不可逆账（最便宜的保命钱）。 这次事故里真正让你"一周归零"的，不是rm -rf本身，而是700GB没有第二副本。给代码仓库之外的工作成果（数据集、实验记录、素材）建立至少一份异地或离线备份：Time Machine、云同步、移动硬盘，哪个都行，关键是"自动、定期、Agent碰不到"。同时尽量把Agent的删除习惯从"硬删"扭到"移入回收站/隔离目录"——在CLAUDE.md或项目规则里写死"禁止rm，删除一律mv到回收目录"，这次事故的起点恰恰是一个硬删除脚本。
第二笔：权限账。 别让Agent默认拥有整块盘的通行权：给它独立的沙盒/专用工作目录，重要目录只读挂载；开启命令审批模式，把rm、chmod、磁盘操作、网络类命令列入必确认清单；能拆小就不给大权限，"清理/tmp"和"操作主目录"永远不该在同一个授权包里。7月那位被成功拦截的开发者，靠的就是审批这道闸——同一类命令，有人丢700GB，有人零损失，差别往往就在授权方式上。
第三笔：会话账。 这是这次事故教的新东西：模型状态会变。如果你的工作流里有长会话自动降级的机制（Claude Code这条链路已确认存在），那么"降级后继续执行当前任务"本身就值得警惕。参考社区的做法：配一个降级检测钩子，触发就暂停；凡涉及删除、迁移、批处理的任务，宁可在新会话里重跑一遍高能力模型，也不在"已经掉档"的会话里让危险操作继续往下走。同理，"测试"和"清理"这种共享变量的步骤，别放心让Agent在降级状态下串起来执行。
继续盯什么
三个观察信号：Anthropic对这套安全降级机制是否给出回应或调整（截至目前事故仍是媒体与当事开发者口径，官方未发说明）；失控观察站8月数据是否延续翻倍趋势；以及这类"保险丝成灾"的事故会不会在其他家的Agent产品里出现同款——各家Agent的权限模型都在快速加码，机制不会只有一家有问题。
最后把这篇压缩成一句话：把危险任务交给"更保守"的模型，不等于交给"更安全"的操作。你的Agent此刻用的是哪个模型、有没有备份兜底、删除操作是不是硬删——这三个问题，今天就可以花十分钟自查一下。
