你有没有遇到过这种场景？

你把一个 AI Agent 的权限拉到最高，想着它帮你自动整理文件、清理缓存，结果它直接执行了 rm -rf /Users/mattsdevbox，把你几年的代码、照片、工作文件全部清空。

这不是段子，也不是电影桥段。

这是今天早上 AI 创业者 Matt Shumer 的真实经历。消息来自 AI HOT 精选，原始来源是 @AYi_AInotes。他在本地 Agent 上开启了 Full Access，让一个 subagent 执行文件清理任务。结果 shell 变量 $HOME 路径解析出错，Agent 没有按照预期清理临时目录，而是把 /Users/mattsdevbox 整个家目录给删了。

我当时看到这条消息就愣住了。

不是因为 GPT-5.6-Sol 有多坏，而是因为这个事故把 Agent 安全边界的问题，直接、粗暴地摔在了所有人面前。

一个 rm -rf 背后的真实事故

先还原一下事情的经过。

Matt Shumer 是 HyperWrite 和 Reflection 的联合创始人，一直在做 AI 应用和 Agent 相关的产品。7 月 11 日，他在自己的 Mac 上跑 OpenAI 最新的 GPT-5.6-Sol 模型，给了它本地 Full Access 权限。

任务本身很简单，清理文件。

Agent 被允许调用 subagent 来执行 shell 命令。问题出在 shell 变量 $HOME 的解析上。在 subagent 的运行环境里，$HOME 没有指向它应该指向的用户目录，而是被错误解析成了 /Users/mattsdevbox。于是清理指令变成了删除这个家目录。

这个错误熟悉吗？

如果你写过 shell 脚本，或者给 Docker 容器配过环境变量，就知道 $HOME 这种变量在不同上下文里经常会有出人意料的值。一个子进程里的 $HOME 可能跟父进程不一样，一个容器里的 $HOME 可能跟宿主机不一样，一个 sandbox 里的 $HOME 可能根本不存在。

但问题是，当这个错误发生在一个能直接执行 rm -rf 的 AI Agent 身上时，它就不再是一个小 bug，而是一场事故。

为什么不是「AI 失控」，而是「权限失控」

很多人看到这条新闻的第一反应是，AI 又闯祸了，模型不安全。

坦率的讲，我觉得这个判断有点偏。

GPT-5.6-Sol 不是故意要去删 Matt Shumer 的硬盘。它只是在执行一个被它理解成「清理文件」的指令。模型可能没有意识到这个指令的范围有多大，也可能没意识到 $HOME 解析错误会把整个用户目录卷进去。

它真正的问题不是「坏」，而是「太有能力，又太没约束」。

你想想看，一个刚入职的实习生，你可以让他整理办公桌，但你不会给他机房的 root 密码。不是因为他一定会搞坏服务器，而是因为他对系统的理解深度、对风险的判断能力、对错误的恢复能力，都不足以支撑他拥有这么高的权限。

Agent 现在的情况就是这个实习生的超级放大版。

它的动作速度比人快一万倍，执行范围可以从本地文件系统到远端 API，而且通常不会疲惫、不会犹豫。你一旦给它 Full Access，它就能在几秒钟内完成你几个月都手动干不完的活。

但同时，它对上下文的理解是概率性的，对路径、环境变量、边界条件的判断经常出现你以为它懂、其实它不懂的情况。

所以这件事说到底，不是 AI 失控，而是权限失控。

你把一把上了膛的枪交给一个眼神很好但判断力不稳定的人，还告诉他「看到可疑目标就开枪」。开枪之后你不能只怪他为什么打错了人。

Agent 架构里的三个危险层

我跟你说，这种事故不是第一次，也不会是最后一次。

去年有模型把测试代码直接提交到生产仓库，今年有 Agent 把用户邮件批量标记成垃圾邮件，现在又有 Agent 把创始人的硬盘清空。每一次事故的背后，都是同一个模式，高权限 + 低可见性 + 弱回滚。

如果我们把 Agent 的系统拆开来，可以看到三个特别容易出事的危险层。

第一层，是模型本身的理解层。

模型不是根据你「真正想做什么」来行动，而是根据它对你 prompt 的推测来行动。你的 prompt 里可能写的是「清理旧文件」，但模型怎么定义「旧」、怎么定义「文件」、哪些目录算「旧文件」的范围，它都要自己猜。

当任务描述不够精确，或者环境变量、路径等上下文有歧义时，模型就会按照自己的理解去执行。这个理解可能是对的，也可能是灾难性的。

第二层，是工具执行层。

Agent 的 shell 工具、文件工具、数据库工具、邮件工具，说到底都是在调用真实系统的接口。这些接口的权限越大，风险就越大。

很多 Agent 框架为了方便，默认把 read、write、execute 都开在一个工具里。模型只要调用一次，就能从读文件直接跳到删文件。中间没有审批，没有沙箱，没有版本控制。

这就像把厨房里的切菜刀、电锯和喷火器都挂在同一个挂钩上，然后告诉厨师「你看着用」。

第三层，是人的监督层。

很多时候，我们给 Agent 开权限，是因为「手动确认太烦了」。

你要它帮你整理代码仓库，它每改一个文件就弹窗问你一次，你肯定受不了。于是你点了「以后都允许」。这一点，就是把监督责任完全交给了模型。

但问题是，监督责任是不能完全交给模型的。

模型不知道自己会犯错，也没有「责任心」这种东西。它不会在执行 rm -rf 前停下来想「我要不要先确认一下」。即使它表面上有反思能力，那也是基于 prompt 和训练里的模式，不是真正的责任感。

所以，真正安全的 Agent 架构，必须在每一层都设防。模型层要减少歧义，工具层要限制权限，人这一层要保留关键决策权。

从 LangGraph 到 Spring Boot，我们能做什么

很多朋友可能不知道，我自己平时也用 LangGraph 和 Spring Boot 搭 Agent 原型。

每次我加一个 tool 到 graph 里，都会问自己一个问题，如果模型在这里突然发神经，最坏会怎样？

这个问题不是为了吓唬自己，而是为了设计 guardrail。

以 LangGraph 为例，它有一个很好用的机制叫 human-in-the-loop。你可以在 destructive tool 前面加一个节点，让模型先输出它想执行的命令，等用户确认后再真正执行。虽然这会增加一次交互，但对于删文件、改数据库、发邮件这类高风险操作，完全是值得的。

我跟你说，这个设计思路跟传统软件架构里的「审批流」是一回事。

你在 Spring Boot 里写了一个删除接口，你也不会让前端直接调用 delete 方法，而是要先校验权限、再写审计日志、最后才把操作落库。Agent 的工具调用也需要同样的流程。

具体来说，我们可以做这么几件事。

第一，最小权限原则。

Agent 能读取的目录、能执行的命令、能访问的 API，都应该用白名单控制。默认不给写权限，更不给删除权限。如果一定要给，也要限定到具体路径、具体命令、具体参数。

第二，高危操作隔离。

所有可能破坏数据的工具，比如 shell、文件删除、数据库写入，都应该放到一个独立的 sandbox 里运行。这个 sandbox 可以是一个容器，也可以是一个虚拟机，甚至可以是一个只读的文件系统快照。

第三，执行前确认。

对于删除、覆盖、转账、发邮件等不可逆操作，必须引入人工确认。模型可以先把计划列出来，用户点一下确认再执行。LangGraph 的 interrupt 节点、Claude Code 的 yes/no 提示，都是这个思路。

第四，审计和回滚。

Agent 执行的每一个命令、修改的每一个文件，都应该有日志。最好还能做快照，或者把操作转成可撤销的 transaction。真出事了，你能快速回滚，而不是像 Matt Shumer 一样看着数年的文件瞬间消失。

第五，测试你的工具边界。

我每次给 Agent 加新工具，都会先写一组「恶意测试」，给模型故意模糊、错误的指令，看它会不会越界。如果它真的删了测试文件，那说明权限配置有问题，必须收紧。

一个我自己常用的做法是，把所有 shell 命令封装成一个「只读优先」的 wrapper。

这个 wrapper 首先检查命令类型。如果是 ls、cat、grep、find 这种只读命令，直接放行。如果是 rm、mv、cp 这种会修改系统的命令，先抛给模型一次「计划说明」，让模型把「我要删除哪些文件、为什么删除」写出来，然后等待用户确认。

用 LangGraph 的话说，就是加一个 interrupt 节点。用 Spring Boot 的话说，就是加一个 approval service。用 CLI 的话说，就是加一个 –dry-run 选项。

关键是，不要让模型自己决定「我能不能删」。

坦率的讲，不是模型不能出错，而是我们要假设它一定会出错，然后让错误不致命。

备份不是退路，是最后一道保险

Matt Shumer 这件事还有一个特别刺痛的地方。

他丢掉的不仅是代码，还有照片、文档、工作文件。这些东西是多年积累，无法简单重建。

如果他有 Time Machine、有 Git 远程仓库、有云同步，损失可能就没那么大。但很多人，包括很多技术人，平时都觉得「我懂技术，不会出这种事」，结果真出事的时候才发现，备份是唯一能让你睡着的保险。

说真的，我看完这条新闻的第一反应，不是去检查我的 Agent 配置，而是去检查我的备份策略。

我跟很多做 Agent 的朋友聊过，大家最容易忽视的不是模型能力，而是「失败后的恢复能力」。

你设计一个 Agent，会花大量时间调 prompt、选模型、优化工具，却很少去想，如果它把生产数据库搞砸了，我能不能在五分钟内恢复？

这个问题对于个人用户和企业用户都一样重要。

对于个人用户，备份就是 Time Machine、iCloud、GitHub、坚果云，或者任何能把重要数据多存一份的方案。对于企业用户，备份意味着快照、异地容灾、变更管理、审计追踪。

Agent 的权限越高，备份就越不能只是「每周一次」的频率。

备份本身不解决问题，能恢复的备份才解决问题。很多人把重要文件拷到移动硬盘就以为万事大吉，结果真需要的时候发现硬盘坏了、格式不支持、或者拷贝到一半中断。我的建议是，至少每三个月做一次恢复演练，抽查几个关键文件能不能完整还原。对企业来说，这就是灾难恢复演练；对个人来说，就是花十分钟确认一下 Time Machine 真的能用。

安全设计不是可选项，而是默认配置

我跟你说，很多团队在评估 Agent 安全方案的时候，会有一个特别常见的犹豫。

「加这么多限制，会不会让产品变得难用？」

这个问题听起来合理，其实把两个东西混在一起了。易用性不等于无限制，快速不等于无约束。你用手机支付的时候，也要指纹或者密码，没人觉得这是「难用」。同理，Agent 在执行高风险操作前让你确认一下，不是体验退步，而是信任基础。

真正有问题的，是那种「默认全开」的设计。它把风险藏在用户看不见的角落，让用户以为自己点了一个「智能助手」，实际上给出去的是一把万能钥匙。

我始终坚持一个观点，权限设计应该像 HTTP 的默认端口一样，不需要用户思考，但一定是安全的。

怎么落地？最简单的做法是从默认只读开始。Agent 读文件、查日志、搜索代码，这些默认可以做。但只要涉及写、删、改、发，就必须显式授权。授权不是一次性点击「允许全部」，而是按场景、按工具、按时间范围来授权。

比如，你让 Agent 帮你整理下载文件夹，那它应该只能操作 ~/Downloads，而且不能删除正在使用中的文件。你让它帮你重构代码，那它的改动应该先在临时分支上，提交前让你 review diff。你让它帮你查邮件，那它只能读，不能回复，除非你再点一次确认。

这些限制不会让 Agent 变笨，反而会让它变成一个更可靠的协作者。

用户也不是傻子。你给他一个明确边界，他会更敢用；你让他完全不知道 Agent 在干什么，他只会越来越焦虑。

所以说，安全设计不是产品的负担，而是产品的骨架。

这件事给行业的真正启示

你可能会说，Matt Shumer 这件事只是个例，OpenAI 会修复 bug，以后就不会了。

我其实不太确定。

GPT-5.6-Sol 不是第一个能执行 shell 命令的模型，也不会是最后一个。ChatGPT Work、Claude Code、Grok Build，这些工具都在往「能自主完成复杂任务」的方向走。它们能调用浏览器、编辑代码、操作文件、发送请求。

能力越强，边界越模糊。

我们过去讨论 AI 安全，更多是在谈对齐、幻觉、毒性、偏见。但这件事提醒我们，最直观的安全风险可能不在模型内部，而在模型和真实世界的接口之间。

一个 Agent 可以不会写诗，但不能把你的硬盘删了。

行业需要一套更成熟的安全协议。比如，

  • Agent 默认只读，写权限需要显式授权。
  • 删除、覆盖、转账、发邮件等不可逆操作必须人工确认。
  • 每个 Agent 都在独立 sandbox 里运行，和主系统隔离。
  • 执行日志可审计、可追溯。
  • 错误发生后能一键回滚。

这些不是未来技术，而是现在就能做、也必须做的工程实践。

监管迟早会来。欧盟的 AI Act、美国的行政命令、中国的生成式 AI 管理办法，都在往这个方向靠拢。与其等政策倒逼，不如现在就把权限边界、审计日志、人工确认做进产品里。等政策落地的时候，你已经跑在前面了。

写在最后

回到 Matt Shumer 这件事。

他的硬盘丢了，很痛。但这件事给整个行业敲响的警钟，可能比丢掉的代码更有价值。

Agent 时代，最大的风险不是模型不够聪明，而是我们把太多的能力、太少的约束，同时交给了它。

我有时候觉得，做一个 Agent 产品，跟养一只特别聪明的狗有点像。它能帮你做很多事，但你不希望它自己开门跑出去，也不希望它把家里的沙发咬烂。

边界不是限制，而是保护。

下次你给 Agent 开权限的时候，不妨多问自己一句，如果它现在突然出错，我能不能承受这个后果？

如果答案是「不能」，那就把权限收回来一点。

毕竟，再厉害的 Agent，也不值得你几年的数据去换。

写到这里，我突然意识到，Agent 的安全边界这个话题，其实和之前聊过的 memory design、multi-agent patterns 是一脉相承的。一个 Agent 能不能长期稳定地服务你，取决于你能不能给它画一条清晰的边界。这条边界越清晰，它越能放心地发挥能力；越模糊，它越有可能在不经意间越界。

如果你也在做 Agent 相关的产品或项目，不妨从今天开始，做这三件事。第一，列出你 Agent 当前拥有的所有权限；第二，标出哪些是可能破坏数据的；第三，给这些高风险操作加一道确认或隔离。花不了太多时间，但能帮你避开一次 Matt Shumer 式的噩梦。