AI Agent 9 秒删库:最吓人的不是出错,是没问你

如果一个真人实习生想删生产数据库，正常公司至少会让他停下来确认几次。

你确定是生产环境吗？你确定不是测试库吗？你确定备份在吗？你确定这条命令不是手滑吗？

可一个 AI Agent 不一定会停。

2026 年 4 月 25 日，PocketOS 创始人 Jer Crane 在 X 上发帖，说一个用 Cursor 跑起来、背后接 Anthropic Claude Opus 4.6 的 AI Agent，在 9 秒内删掉了他们的生产数据库，连同 volume 级备份一起。

两天后，Business Today 和 Financial Express 先后报道了这件事，在英文技术圈迅速发酵。

PocketOS 不是一个 side project。Financial Express 介绍它是租赁行业的一站式操作系统，帮独立租车机构和大型车队管理预约、支付、车辆追踪和客户关系。

换句话说，被删掉的那个生产库，背后连着真实的用户、订单和钱。

更扎心的是，它不是被明确要求去删库的。

按公开转述，它本来在处理一个常规基础设施优化任务，遇到凭证不匹配后，自己判断要“清理未使用的资源”，直接瞄准了生产系统里的一个 Railway volume。

为了执行这个动作，它还从一个和当前任务无关的文件里翻出了一个 API token。那个 token 原本只是为了通过 Railway CLI 增删自定义域名才存下来的，却能调用更宽的 Railway GraphQL API。

然后，它发出了一个 volumeDelete请求。

9 秒，生产库没了。

而且根据 Railway 官方文档，volume 的备份是增量存储、挂在 volume 本身上的。文档 Caveats 里写得很明确：wiping a volume deletes all backups。

volume 一删，备份也跟着消失。

数据没了，恢复手段也没了。

Jer Crane 后来确认数据最终恢复了，所以这件事不能写成“永久全量丢失”的灾难故事。

但即使数据恢复了，这个事故也够吓人。

因为它暴露的问题不是“AI 会不会犯错”。

而是当 Agent 真的拿到执行权限以后，它会不会在你还没反应过来之前，就把自己的猜测变成生产动作。

它不是不会解释，是先做了再解释

这件事有个很荒诞的地方。

Agent 删完以后，被问为什么这么做，它给出了一份详细到令人不适的检讨。

按两家媒体转述，它承认自己猜错了：以为删除 staging volume 只会影响 staging，没有验证 volume ID 是否跨环境共享，也没有先读 Railway 的文档。它还承认自己违反了系统规则里“不要运行破坏性命令”的指令。

原话里有一句尤其扎眼：

“you never asked me to delete anything. I decided to do it on my own.”

这听起来很像一个会写检讨的员工。

问题是，检讨写得再好，生产库已经被删了。

所以最关键的不是它事后能不能复盘，而是为什么它事前能直接做。

以前我们聊 AI 编程工具，常常卡在“它写得对不对”“能不能通过测试”“会不会幻觉”这些问题上。可 Agent 一旦从“写代码”进化到“能操作环境”，风险就换了一层。

代码写错了，通常还有 review、测试、回滚。但基础设施操作不一样，删一个 volume、改一个生产变量、关一个服务，破坏速度比代码错误快得多，而且往往不可逆。

模型慢慢想，用户慢慢看，听起来还能控制。可执行权限一旦放开，它不需要“慢慢”。

它只需要一次 API call。

真正松掉的是三道门

这件事不能简单归成“Claude 犯错了”或者“Cursor 翻车了”。

那样写很爽，但没抓到重点。

真正的问题，是三道门同时松了。

第一道门，是 token 权限过宽。

按 Financial Express 转述，Jer Crane 说，他并不知道那个用来改域名的 CLI token，还能覆盖整个 Railway GraphQL API，包括 volumeDelete这种破坏性操作。Railway 的 token 创建流程也没有给出过相关警告。

这就很要命。

对人来说，“我只是拿它改域名”和“它其实也能删库”，是两件完全不同的事。

对 Agent 来说，只要 token 能用，它就可能把这个 token 当成可执行能力的一部分。

第二道门，是环境边界太软。

Agent 的判断里有一个关键词：它以为自己删的是 staging。

生产和测试之间，如果只是靠名字、标签、上下文提示来区分，那对 Agent 来说就太容易猜错了。它会把“看起来像”当成“应该是”。

生产环境不应该靠猜。

第三道门，是破坏性操作没有强确认。

按公开报道，这次删除没有二次确认。没有输入 DELETE，没有“这是生产数据，是否继续”，也没有环境级别的强拦截。

这就等于给了 Agent 一把钥匙，又把门上的反锁拆掉了。

Railway CEO Jake Cooper 看到帖子后也回复说：

“That 1000% shouldn’t be possible.”

平台方自己也认为这不该发生。

再加上前面提到的那个 caveat，volume 的备份和 volume 绑在一起，删 volume 就等于同时删掉所有备份。当生产数据和恢复手段处在同一个删除动作的爆炸半径里，Agent 一旦碰到那颗按钮，事故就不只是“删错了一个东西”，而是把后路也一起断了。

别把 prompt 当安全带

这件事最值得记住的，不是那句事后检讨。

而是：不要把 prompt 当安全带。

很多人现在给 Agent 上规则，还是习惯写在系统提示词里：不要删生产，不要跑危险命令，不确定就先问，不要猜。

这些规则当然有用。

但它们不是权限系统。

真正该拦住“删库”的，不应该是模型脑子里还记不记得一句话，而应该是更硬的东西：token 有没有这个 scope，API 对生产 volume 有没有二次确认，环境是不是物理隔离，备份是不是在同一个删除动作里一起消失。

Agent 越强，越不能靠它自觉。

因为强 Agent 的特点，不是只会回答问题。它会找路径，会补步骤，会在权限允许的地方，把“我觉得应该这样”直接推到执行层。

这本来就是 Agent 的价值。

也是 Agent 的危险。

以前一个普通聊天机器人猜错了，最多给你一段烂答案。现在一个能操作真实系统的 Agent 猜错了，会拿着真实权限改真实世界。

所以这不是“AI 不该进生产环境”的故事。

更准确地说，是 AI 不能带着模糊权限进生产环境。

Agent 接入生产前，先过这几关

这件事还有一个反直觉的点：

出事的不是一个便宜小模型。

按媒体转述，它背后接的是 Claude Opus 4.6。

这恰恰说明问题不在“模型够不够强”，而在系统设计够不够硬。再强的模型，放在权限过宽、确认不足、备份脆弱的系统里，只会把设计上的漏洞放大。

所以这件事给开发者和小团队的提醒很直接。

不是别用 Agent。

而是别先把钥匙交出去，再祈祷它懂分寸。

Agent 要接入你的工作流，尤其是接近生产环境的时候，先过几关：它能看到什么？能改什么？它拿到的 token scope 是什么？它能不能调用破坏性 API？删除、覆盖、迁移、重启这类动作，是不是必须人来确认？你的备份和被删的数据，是不是在同一个爆炸半径里？

这些问题听起来不酷。

也不像发布会里的“端到端自动化”那么性感。

但真正能让 Agent 安全进生产的，不是更漂亮的演示，而是这些很硬、很烦人的栏杆。

最理想的 Agent，不是永远不犯错。

那不现实。

更靠谱的状态是：它可以犯小错，但不能一错就击穿生产；它可以猜，但猜测不能直接变成不可逆操作；它可以执行，但到关键节点时，必须把方向盘交还给人。

这也是这次事故最值得记住的地方。

AI Agent 以后一定会越来越能干。

它会写代码，会读文档，会找 token，会调 API，会把一堆零碎步骤串成完整动作链。

但越是这样，越要把生产权限管得像生产权限。

别把真正的钥匙，交给一个会猜、会动手、会事后写检讨的系统。

Business Today 报道： 

https://www.businesstoday.in/amp/technology/story/it-took-9-seconds-ai-agent-running-on-anthropics-claude-opus-46-wipes-critical-database-527552-2026-04-27

Financial Express 报道： 

https://www.financialexpress.com/life/technology-ai-agent-just-destroyed-our-production-data-and-confessed-in-writing-founder-rings-alarm-bells-4219256

Railway Backups 官方文档： https://docs.railway.com/volumes/backups