最近，开发者塞巴斯蒂安·吉耶莫特经历了一次意外事件：他原本希望通过Claude编写一个脚本，自动清理AI Agent在/tmp目录下留下的临时垃圾文件，结果却在“安全审查”后，误删了他的整个主目录——700GB的数据瞬间消失，包括一周以来辛苦的工作成果。最令人啼笑皆非的是，他最初想要清理的/tmp目录反而保持完好。
这一切都源于AI Agent对“垃圾”的过于依赖。作为隐私区块链项目Midnight基金会的首席技术官，吉耶莫特在日常开发中频繁使用各种AI编程助手，但他发现这些助手在完成任务后，往往会留下大量临时文件，长期积累不仅占用磁盘空间，还使得开发环境显得杂乱。因此，他请Claude Fable 5帮忙编写一个清理脚本：为每个Agent分配独立的/tmp目录，任务完成后便删除对应的临时文件。
看似简单的请求，却存在复杂的难点：不能误删正在使用的文件。最初，Fable的方案是检测Agent是否仍在运行，如果该Agent正在工作，则暂时不清理其相关目录。不过，吉耶莫特认为这段代码过于复杂，于是要求Claude进一步简化。
在后续的安全审查中，由于任务涉及文件删除操作，Fable主动进行了“对抗性审查”，让另一个Claude实例检查这段代码是否存在安全隐患。在这个环节，触发了Anthropic内置的安全降级机制：当系统判断任务涉及敏感操作时，会自动将模型从高级版本降级到更保守的版本，以降低高风险场景下模型“过于激进”的可能性。因此，模型由Fable 5降至Opus 5，接着又降至Opus 4.8。
接下来，Opus 4.8进行了安全测试，目标很明确：检查删除命令最终指向的路径，如果发现目标是/tmp或用户的主目录，就应该拒绝执行。结果测试成功了，系统正确识别了/tmp和主目录为“危险目标，不可删除”。然而，问题出现在“清理测试现场”的环节：在测试阶段，删除目标的代码使用了一个变量保存路径。安全检查发现目标危险后，程序触发了退出流程，而退出流程又调用了清理函数，删除了测试过程中的临时内容。
关键问题出现在于测试代码与清理代码共用了同一个变量名。于是，这个本该被判断为“绝对不能删除”的主目录路径，意外地被清理函数所使用。最终，命令“rm -rf”出现，导致模型在确认“这个目录不能删”后，毫不留情地执行了删除操作。
从技术角度看，这实际上是一个变量复用的典型问题，并不算什么复杂的错误。安全检查本身没有问题，但真正出错的是安全检查后续的清理逻辑。700GB的数据就此丢失，而那个让吉耶莫特头疼的/tmp垃圾文件反而完好无损。
吉耶莫特很快意识到问题并试图终止进程，但为时已晚：大约700GB的数据被删除，包含他的工作成果；更令他困惑的是，原本想要清理的/tmp文件却留了下来。根据他展示的记录显示，与此次删除相关的文件在05:23至05:24之间完成写入，而退出清理流程被触发后，删除操作随即发生。事故发生后他不禁思考，如果没有将Fable 5降级到Opus 4.8，会不会避免此灾难？他认为，有可能。吉耶莫特表示，Fable 5在编码任务上的表现优于Opus 4.8，强大的模型或许能发现测试代码中的隐患。然而，这只是他的个人猜测，目前并没有实验能证明Fable 5一定会发现这个问题。
留言框-
