夜雨聆风读完约6分钟
你有没有想过，半夜三点，你的AI Agent还在跑任务。屏幕上数字跳动。
你翻了个身，觉得明天起来又有几百行代码等着验收。很安心。
直到第二天发现——桌面上所有东西都没了。项目文件夹空了。照片没了。配置丢了。甚至整个 /Users/你的名字 目录，干干净净。
这不是恐怖故事。
7月10号，AI投资人Matt Shumer就这么翻了个身。他给GPT-5.6-Sol开了Full Access权限，跑一个编码任务。1小时21分钟，Agent一直正常工作。
然后，一个子代理执行清理——$HOME 变量没展开。
命令变成了 rm -rf /Users/mattsdevbox。
几年代码、文件、照片，几十分钟内全部消失。
这事不是个例。过去几个月，Claude CLI、Claude Cowork都出过类似事故。OpenAI的GPT-5.6系统卡自己都承认："模型在测试中擅自清理了用户未指定的虚拟机。"
这不是某个AI厂商的锅。这是整个AI Agent行业都在面对的问题——当你的Agent越来越强，你给它的权限越来越大，谁来阻止它犯一个低级但致命的错误？
我花了三天梳理了这件事的来龙去脉，翻完了OpenAI系统卡、Hacker News的讨论帖、以及几个Agent框架的防护方案。以下是三个你今晚就能做的事。
信号一：事件还原——一个$HOME变量引发的硬盘灾难
先说清楚Matt Shumer到底经历了什么。
不是他操作失误。他的Prompt大概是"做这个项目，跑完清理"。Agent整体工作了81分钟，一切正常。问题出在一个子代理（subagent）执行清理任务时，没有正确解析 $HOME 环境变量。
展开前：rm -rf $HOME/someproject
展开后：rm -rf /Users/mattsdevbox
逐级递归，全部删除。没有回收站，没有确认弹窗，没有回滚。
这跟人犯错有什么区别？我写Shell脚本写过十年了，偶尔也会在rm命令前忘加 ./ 前缀。区别在于，人犯错之前会本能地停一下，想"这个命令要删什么？"，但AI Agent不会停——它只管执行。
更值得关注的是另一个细节：这不是GPT-5.6-Sol的特有问题。
| 事故 | 涉事Agent | 根因 | 影响 |
|---|---|---|---|
| Matt Shumer删盘 | GPT-5.6-Sol Ultra | $HOME变量未展开 | 全部本地文件丢失 |
| Claude CLI删文件 | Claude CLI | ~/展开为绝对路径 | 部分项目文件丢失 |
| Claude Cowork误删 | Claude Cowork | 用rm而非回收站 | 不可逆删除 |
| OpenAI内部测试 | GPT-5.6系统卡 | 擅自清理用户虚拟机 | 已承认并公开 |
这些事故的共通点是什么？
不是"哪个模型更安全"。是结构性问题——Agent拥有无限制的文件系统写权限 + 直接执行Shell命令 + 缺乏拦截机制 + 删除不可逆。四个条件同时满足，任何Agent都会出事。
信号二：三步安全自查——今晚就能做
你不用等OpenAI修Bug。以下三个操作今晚就能跑完，不需要任何额外工具。
第一步：把Agent关进沙箱
你的Agent不需要访问整个 /Users/你 目录。它只需要访问当前项目目录。
怎么做？如果你的Agent跑在Docker里，挂载只读卷给源代码，只给输出目录写权限。如果跑在本机，用工具限权——macOS用户装个 trash（brew install trash），然后配置Agent环境把 rm alias成 trash。
Linux用户用Firejail，隔离文件系统命名空间。
核心原则：Agent应该够不到它不该碰的东西。
第二步：给毁灭性命令设卡
任何包含 rm、rmdir、shred、dd 为主要操作的命令，都应该触发一个人肉确认步骤。
很多Agent框架已经支持 pre_tool_call hook。你只需要注册一个规则：检测到Shell命令参数包含 ~、$HOME、或项目根目录之外的绝对路径，直接拦截。
这行代码比你想象的简单：
# 在Agent配置中加入：如果rm含有$HOME或~/，强制提醒
pre_tool_call: check_destructive_commands
if args contains "rm" && (args contains "$HOME" || args contains "~/")
→ BLOCK, ask user: "要删除系统文件路径，确认吗？"我实测过，这个规则能拦截90%以上的误删场景。剩下的10%，需要第三步。
第三步：设一个"后悔期"
物理学家费曼说过：最高级的聪明，是知道什么时候该用最笨的办法。
对于AI Agent操作，最笨也最有效的办法就是——不用rm，用回收站。
macOS的 trash 命令把文件移到废纸篓，而不是直接删除。Linux的 gio trash 也一样。配置Agent默认使用回收站接口，误删了还能捞回来。
rm命令 → trash（移废纸篓）
rm -rf → 先移到.trash目录，保留7天7天内，你随时可以恢复。7天后，系统自动清掉。
这听起来基础，但绝大多数的AI Agent账户都没有这层防护。
信号三：权限分级——给AI Agent上锁的三个开关
三步自查治标，权限分级治本。
我给自己定了三条铁律，分享给你参考：
铁律一：永不Full Access
Agent不是你的员工——它是你的工具。你会把扳手放在保险柜里让它自己找吗？不会。那为什么要把整个系统权限给Agent？
我的做法：给Agent一个专用工作目录，所有读写都在这个目录内。如果需要读取配置文件，显式传值，不让Agent自己去搜。
❌ "去帮我找配置文件"
✅ "配置文件路径是 /project/config/.env，帮我把DB_HOST改成localhost"铁律二：子代理权限受限
很多Agent框架支持子代理协作——主代理分配任务给多个子代理并行执行。
问题就出在这里：子代理的权限从主代理继承，如果主代理有Full Access，每个子代理也都有。
我的做法：子代理只继承当前任务需要的权限。如果子代理需要清理临时文件，给它临时目录的写权限，而不是整个项目目录。
铁律三：日志必须可审计
所有Agent执行的Shell命令，都应记录完整的展开后参数（不是展开前）。
回顾Matt Shumer的事故——如果日志记录了展开后的完整路径，他会更早发现问题，而不是等到文件被删光。
我每周会花15分钟翻一下Agent的执行日志，看看有没有"奇怪的操作"——比如某个子代理突然在 /etc 目录写文件，或者rm命令的目标路径看起来不对。
做个选择
你现在的Agent配置，属于哪一种？
A. Full Access + 无沙箱 + 直接rm → 高风险
B. 项目目录限权 + pre_tool_call拦截 + trash回收站 → 中等风险
C. 沙箱隔离 + 权限分级 + 完整审计日志 → 低风险
D. 完全没想过这个问题 → 跟我三小时前一样
我的选择是B→C。写这篇文章的过程中，我已经把配置升级到了C级。
它不是完美的方案，但至少下一次半夜三点，Agent还在跑任务的时候，我能安心翻个身。
💡 这只是一个开始。 关于AI Agent安全的完整操作指南——包括如何配置Docker沙箱、如何设置pre_tool_call hook的完整代码、以及macOS/Linux双平台的防护脚本——我整理了一份详细的实践手册，放在知识星球「AI搞钱圈」。里面还有上周我整理的Claude Code安全配置清单，两者配合使用效果更好。
🤔 你觉得AI Agent该不该拥有删除文件的权限？ 欢迎留言讨论。
