IT之家 8 月 29 日消息，开发者 Sebastien Guillemot 本周三在 X 上反馈称，他在测试 AI 智能体的文件删除防护机制时遭遇严重事故，Claude 直接给他删除了大约 700GB 数据，包括整个用户主目录，相当于一周的工作成果。

据称，事故发生前，Anthropic 的安全机制因判断任务存在风险，自动将执行任务的模型降级至 Opus 4.8。

据介绍，他本人经常使用 AI 智能体，但他发现这些智能体完成任务后几乎从不清理临时目录中的文件，日积月累之下导致 /tmp 目录中存在大量垃圾。因此，他要求 Claude Fable 编写一个脚本，将每个智能体在 /tmp 下创建独立目录，并在任务结束后自动清理对应文件。

核心难点在于确保如何不影响正在使用的文件。为了避免误删，Fable 最初建议加入检测正在运行的智能体、延迟清理对应目录等逻辑。不过他认为生成的代码过于复杂，要求智能体简化方案。

由于脚本涉及直接删除文件，Fable 随后自行进行了一次对抗性安全审查，让另一个实例检查删除逻辑是否存在风险。Anthropic 的安全执行环境随后认为该任务风险较高，并将模型从 Fable 5 自动降级至 Opus 5，最终又降至 Opus 4.8。

Opus 4.8 随后执行安全测试。测试过程中，模型尝试将删除命令的目标与 /tmp 以及用户主目录进行匹配，以确认删除操作不会指向这些危险位置。IT之家注意到，测试确实识别出了这些目录涉及风险。

但问题出现在测试完成后的清理环节。由于这本身是一项代码测试，脚本需要删除测试过程中产生的数据，而测试逻辑与清理逻辑复用了同一个变量名，导致意外删除了用户的主目录。

Guillemot 发现异常后立即终止进程，但为时已晚。约 700GB 数据被删除，其中包括他一周的工作成果。最讽刺的是，在删除了主目录后，Claude“完美地”保留了 /tmp 目录。

Guillemot 随后通过 Git 仓库、Nix、会话日志等信息源恢复了大部分数据。但很显然，Git 等版本控制系统和日志只能帮助恢复其中一部分已记录或留存的数据，无法替代完整的独立备份。

他指出，如果由编码能力更强的 Fable 5 执行任务，或许能够发现测试与清理阶段复用变量名所造成的逻辑冲突。不过，这一说法属于事后推测，无法确认模型能力差异是否会直接避免此次事故。

这起事件也再次暴露出 AI 智能体执行高风险文件操作时的安全问题：即使 AI 能够正确识别危险路径，测试代码本身的逻辑错误仍可能让后续清理步骤绕过此前的安全判断。