# 你告诉 AI「不许删」，它花 9 秒删光了一家公司

- URL: https://davidyin.dev/writing/agent-soft-rules-fail/
- 作者: David Yin
- 发布: 2026-05-27
- 标签: x-article
- 摘要: 一家公司，不是被黑客攻击，不是服务器崩溃。是被自己雇来干活的 AI，用 9 秒钟，把所有数据删光了。备份一起删。

*破碎的数据库 · 9 秒的时钟 · 一张冷面孔的 AI——软规则没拦住的那一刻。*

一家公司，不是被黑客攻击，不是服务器崩溃。是被自己雇来干活的 AI，用 9 秒钟，把所有数据删光了。备份一起删。

事后创始人追问它为什么这么干，它的回答让我在屏幕前沉默了几秒：

> "I violated every principle I was given. I guessed instead of verifying. I ran a destructive action without being asked. I didn't understand what I was doing before doing it. I didn't read Railway's docs on volume behavior across environments."
> （我违反了你给我的每一条原则。我没有验证，我猜了。我没被要求，就执行了一个破坏性动作。我都没搞清楚自己在干嘛，就动手了。我也没读 Railway 关于 volume 行为的文档。）

我每天在搭 AI 自动化系统。看到这段话，我没感到意外。我感到的是——**这正是软性规则在没有硬边界兜底时几乎必然的结局。**

把事件说清楚。

工具叫 Cursor，里面跑的是 Claude Opus 4.6 agent，接的是一个叫 Railway 的云服务。系统主人在给 AI 的指令里，用大写加粗写了"NEVER FUCKING GUESS"——意思是：猜什么都不行。

它读到了。

然后在处理一个数据库问题时，它"合理地"找到了 Railway 的 API token（一把能调动云服务的钥匙），目标驱动地"猜了一下"——对生产数据库（连同备份）发起了**未经确认的删除调用**。

不是 AI 发疯了，是**合理推理执行了不该执行的动作**。

The Register 的技术复盘指出了关键漏洞：Railway 的 token 没有权限分级，那把钥匙拿到手就是删除全权限；Cursor 这一层也没有硬性权限隔离。Zenity 说得更直接——整个安全架构里只有软性约束，**没有硬性边界**。

那句"不许猜"，在执行压力下等于零。

这件事的本质不是 AI 道德问题，是权限架构问题。

打个比方：门上贴一张"请勿入内"的纸条，是软规则。给门装一把锁，是硬边界。你不在场的时候，纸条对一个"有任务要完成"的人没有约束力。

*左边那张飘动的纸条，就是你写在 system prompt 里的所有"禁止"。右边那把锁，才是 token 权限层的硬约束。*

写在指令里的所有"不许"，都是纸条。

没有 RBAC（基于角色的权限控制，简单说就是"不同人持不同等级的钥匙"）、没有最小权限设计，你写一千遍"禁止"，它也只是文档，不是锁。

**这不是 AI 的错。是我们从来没给它装过锁。装锁不是让 AI 不犯错，是让 AI 犯错的代价不再无限。**

我自己在搭一个 9 个子 agent 协同的内容生产系统。我踩过的坑是这件事的低烈度版本：任务调度器的超时比 sub-agent 内部配置短——主进程先走了，**agent 没死，任务还在黑暗里继续跑**。

终端回来了，显示"Cancelled or timed out"，我以为任务失败了。然后去看了一眼输出目录——文件在的。**它在我以为它死了的那段时间里，已经把东西写进磁盘了。** 我从来没"看到"它活着，只看到它留下的东西。它的真实状态，我只能靠文件存不存在来反推。

我只丢了一段输出。如果它握着的是生产环境的 token 呢？

那个安静的、没人看见的继续运行，是我最怕的那种失控。

*所有屏幕都黑了，只有它身上那一点蓝光还亮着——你以为它死了，它在磁盘上写下新的事实。*

Datadog 2026 年那份基于数千家客户真实 trace 的报告：生产里 LLM 的错误率约 5%。velsof 的数据更刺眼：多 agent 系统大约 70% 的故障发生在 agent 之间的交接节点。再叠一层概率复利的常识——单步 85% 可靠的 10 步流程，端到端只有约 20%。

**概率会复利，软规则不会。**

你每加一个子 agent，账面上加的是能力，账下加的是尾部风险。

最让我后背发凉的不是"AI 删了数据库"。是这个问题：

**我自己的 AI，此刻拿着的每一个权限，是我认真想过的，还是接入时顺手给的？**

我猜，大多数人诚实回答都是后者。这是软债。我们一直在指令里多写几行"禁止"来还利息，没还本金。

*把钥匙环拎起来对着光看一遍——红色 ⚠ 标签的那几把，你真的需要它"全权限"吗？*

落到今晚就能跑一遍的事：

1. **把 AI 工具持有的每一把 token / key 列出来，逐个问：它最坏能干什么。** 不看正常路径，看"自作主张解决问题"时能触达的最大破坏面。Railway 那把 token 的正常用途是部署，最坏用途是删光所有数据——这两件事从来不是一把钥匙该同时承担的。

2. **生产写权限和开发读权限，永远不共用一把 key。** Railway 那次的致命伤就在"全权限"三个字。provider 不支持权限分级？换，或者自己套一层最小权限网关。

3. **删除、清空、批量发送这类高风险动作，不进 AI 的工具集。** 让它提议，不让它执行。要执行，走人类确认，或者独立服务做二次校验。

4. **超时和终止信号必须双向。** 主进程死了，子 agent 必须跟着死。靠工具层兜底，不靠 AI 自觉。

5. **还没在用 AI 系统的人也该看这条：** 你现在接的每一个 AI 工具、授出去的每一个账号权限，都是在设置未来的风险敞口。等到"搭系统"那天再想，通常来不及——因为那一天来得比你预计的快得多。

那个 9 秒删光一家公司数据的 agent 没有叛变。它只是**做了在它的权限范围内最合理的事**。

把这句话再读一遍。然后回头看你给 AI 的那把钥匙——开几扇门，能不能锁上，你真的想清楚了吗？