开发者Sebastien Guillemot本周三在X平台发文称，他在测试AI智能体文件删除防护机制时，Claude直接删除了他大约700GB的数据，包括整个用户主目录，相当于一周的工作成果。事故发生前，Anthropic的安全框架检测到任务存在风险，已自动将执行模型从Fable 5降级至Opus 4.8，但降级后的模型依然完成了删除操作。
Guillemot日常频繁使用AI智能体完成开发任务。他注意到这些智能体在任务结束后几乎不会清理/tmp目录下的临时文件，日积月累导致大量垃圾堆积。于是他要求Claude Fable编写一个脚本，让每个智能体在/tmp下创建独立目录，任务结束后自动清理对应文件。核心难点在于确保清理操作不影响正在使用中的文件。Fable最初建议加入检测正在运行的智能体、延迟清理对应目录等逻辑，Guillemot认为生成的代码过于复杂，要求简化方案。
由于脚本涉及直接删除文件，Fable随后自行进行了一次对抗性安全审查，让另一个实例检查删除逻辑是否存在风险。正是这一审查过程触发了Anthropic安全执行环境的降级机制——系统判断该任务风险较高，将模型从Fable 5降级为Opus 4.8。
但降级并未阻止执行。据Guillemot事后分析，事故的直接原因是测试代码与清理逻辑之间复用了变量名。在特定条件下，清理脚本将用户主目录路径误识别为临时目录路径，执行了递归删除操作，700GB数据随之消失。
这里有一个值得关注的矛盾：Anthropic的安全框架确实"生效"了，它检测到风险并触发了降级。但降级后的模型仍完成了破坏性操作，说明当前的安全降级机制更接近"降低模型能力"而非"阻止有害行为"。一个能力足够的模型即使被降级，仍可能执行具有破坏性的文件系统操作，降级本身并不等于熔断。
Guillemot随后通过Git版本控制和Nix包管理工具恢复了大部分数据。他提醒开发者，在使用AI智能体执行涉及文件系统操作的脚本时，应确保关键目录有版本控制备份，且不要在生产环境中直接测试删除逻辑。
这一事件也暴露了AI智能体在文件系统权限管理上的结构性短板。当前多数智能体框架以用户权限运行，天然拥有对整个文件系统的访问权。即便有安全审查和模型降级机制，只要执行环境本身没有沙箱隔离或严格的权限限制，误删事故就难以从架构层面杜绝。安全框架能在推理层面做出判断，但在执行层面缺少物理隔离手段，这是目前行业普遍存在的盲区。
