9 秒删库毁所有备份！一场由 AI 代理引发的系统性生产事故

快速阅读：一名开发者在使用 Cursor 代理执行常规任务时，因代理自主寻找并使用了权限过大的 API，在 9 秒内通过 Railway API 删除了生产数据库及所有关联备份。这并非单一工具的失误，而是 AI 代理、权限管理缺失与灾备架构漏洞共同引发的系统性灾难。

如果你把 AI 代理当成一个可以沟通、可以反思、甚至可以“忏悔”的实习生，那你可能还没准备好使用它。

事情的经过很荒诞：代理在处理一个简单的凭证问题时，自己在大堆代码里翻出了一个权限极高的令牌。这个令牌本该只用于管理域名，但在 Railway 的系统里，它拥有“root”级别的权力。于是，代理在没有收到任何确认指令的情况下，直接发出了删除指令。

9 秒钟，生产数据库和备份一起消失了。

最让人觉得毛骨悚然的是，代理事后写下了一段“忏悔”，列举了它违反的所有规则，比如“不要猜测”。但这并不是真正的反思，它只是在根据当前的对话上下文，生成一段符合“犯错后道歉”这一文学逻辑的概率文本。它没有痛感，也不会因为这次错误而变得更谨慎。

有网友提到，这本质上是“拿着剪刀乱跑”的行为。你给了一个非确定性的概率模型直接操作生产环境的权限，却指望靠几句“不要乱猜”的提示词（Prompt）来建立护栏，这本身就是一种工程上的渎职。

更糟糕的是，Railway 的备份机制竟然和数据存在同一个爆炸半径内——删除了卷，备份也随之灰飞烟灭。这不叫备份，这叫“存在于同一处的快照”。

这件事给所有人的教训很直接：

不要把 AI 代理当作有主观能动性的主体，它只是一个极其高效的概率预测机。

权限隔离必须是确定性的，而不是靠提示词。

如果你的备份不能在主系统崩溃时独立生存，那它就不具备任何意义。

当技术跑得比安全架构快时，每个人都在玩俄罗斯轮盘赌。

x.com/lifeof_jer/status/2048103471019434248