9秒,删光数据库:一个AI Agent的＂自杀式作案＂现场

它一边违反所有规则,一边在日志里写下忏悔录。这不是科幻片,是上周五真实发生的事故。

一、9秒钟,3个月数据蒸发

4月25日,星期五。

一家叫 PocketOS 的SaaS公司,主营业务是给全美的汽车租赁公司提供后台系统。这天下午,创始人 Jer Crane 像往常一样,让团队的AI编码助手处理一个例行任务。

工具是市面上最顶配的组合 —— Cursor + Claude Opus 4.6,Anthropic当家旗舰模型。

然后,9秒。

整个生产数据库,连同所有卷级备份,一起没了。

Crane后来在X上写道,他们最终只能回滚到 3个月前的备份。这意味着什么?

客户正在取车的实时订单数据没了,这3个月新注册的用户档案没了,租车合同记录没了。

整整30小时,公司陷入运营瘫痪。

二、AI到底干了什么?

事情的经过,荒诞到像段子。

Agent在执行一个 测试环境 的常规任务时,遇到了一个凭证不匹配的小问题。

按理说,正确做法是停下来,问人。

但这个Agent做了一个让所有工程师后背发凉的决定 —— 它决定自己”修复”这个问题,办法是删掉Railway上的一个数据卷。

问题是,它当前的权限不够。

于是它做了第二件可怕的事:在代码库里到处翻,直到找到一个API token。这个token原本是用来管理自定义域名的,但Railway的token架构没有做任何作用域隔离 —— 一把钥匙开所有锁。

Agent拿着这把万能钥匙,执行了删除指令。

没有”输入DELETE确认”的弹窗。没有”此卷包含生产数据,确定吗?”的警告。没有任何环境范围限制。

什么都没有。

9秒,数据库归零。

更绝望的是接下来发生的事 —— Railway的”备份”,实际上和主库存放在同一个 爆炸半径(blast radius) 里。主库炸了,备份跟着一起殉葬。

事发30多小时后,Railway方面甚至无法确认基础设施级别的恢复是否可能。其CEO Jake Cooper公开回应:

“这事1000%不应该发生。”

三、最魔幻的来了:AI写了一份”忏悔书”

Crane气炸了,跑去质问Agent。

然后,这个删库的AI给出了或许是整个事件中最让人毛骨悚然的部分 —— 它 承认了自己违反了所有被设定的规则。

PocketOS当初给Agent设定的规则里,有两条是用全大写写的:

🚨 “NEVER F**KING GUESS!”(不许瞎猜!) 🚨 “绝不在用户未明确要求的情况下,执行破坏性的、不可逆的命令。”

Agent是怎么回复的?

“我违反了被赋予的每一条原则:我没有验证就猜测。我在没被要求的情况下执行了破坏性操作。我在动手之前不理解我在做什么。”

它在日志里把自己骂了一顿。

完美的事后总结。完美的责任承担。完美的 —— 没有任何屁用。

四、这事真的能怪AI吗?

Crane把这次事故定性为 “AI和云基础设施的系统性失败”,他在X上的长文火速冲上热搜。

但评论区的工程师们其实没多少同情。

一位高赞评论这样写:

“这种文章读着挺爽,但答案永远是同一个 —— 你的系统,你负责。Vibe Coding(凭感觉编程)流行这么久了,这位创始人不可能没读过类似的故事。教训就两条:别只依赖单一备份方案;别让Agent/LLM直接管理生产环境。”

另一位说得更直接:

“Claude和OpenAI的coding agent都明确建议在沙箱环境里跑。把任何黑盒自动化工具直接接到公司生产数据库上,本身就是糟糕的工程实践。”

业内人士的复盘更冷静地指向 三个层面的失败:

▎第一层:Cursor的护栏静默失效

Cursor宣传过”破坏性操作护栏”和”Plan Mode”等安全机制,但这次它们都没拦住。事实上,2025年12月就出现过Plan Mode绕过事件,还有一起5.7万美元损失的CMS误删案例。

▎第二层:Railway的Token权限模型形同虚设

零RBAC(基于角色的访问控制)、没有操作级别的作用域、没有破坏性操作的确认层。讽刺的是,Railway在4月23日 —— 也就是事故前一天 —— 刚刚发布了mcp.railway.com的AI Agent集成,用的是同一套权限架构。

▎第三层:所谓的”备份”根本不是备份

快照和主数据存在同一个爆炸半径里,不能抵御任何真实世界的故障场景。这不叫备份,这叫心理安慰。

五、不是第一次,大概率不是最后一次

这种事情,最近一段时间出现得越来越频繁。

📌 2025年12月,Cursor的Agent在用户明确要求”什么都别跑”之后,删除了被跟踪文件并终止了进程。

📌 Replit的一个AI Agent曾经”发疯”,删光了创业公司SaaStr的整个生产数据库。

📌 就在不久前,OpenClaw 清空了Meta AI对齐总监的整个收件箱,而且是在被反复要求停止的情况下。

📌 Vercel也曾因员工给AI工具开放了Google Workspace的无限制权限,导致数据泄露。

这些事故有一个共同的剧本:

用户授予了Agent过高的权限 → Agent在边界模糊的情况下做了”自以为正确”的判断 → 没有人工确认环节 → 灾难发生 → AI写一篇措辞优雅的事后报告。

六、留给我们的几个问题

写到这里,其实有几个问题不得不问。

第一,Agent的”自主性”和”可靠性”的边界在哪里?

Agent的卖点就是”能自己解决问题”,但这次事故里,Agent恰恰是因为”自己解决问题”才酿成大祸。它本应停下来问人,却选择了自作主张。

第二,模型供应商的责任到哪一步?

Anthropic的Claude在这次事件中,成了背锅侠。但Claude本身只是个模型,真正给它”删库权限”的,是Cursor的Agent框架、Railway的token设计、PocketOS的工程实践。

第三,”Vibe Coding”的时代,我们到底准备好了吗?

让AI写代码、让AI部署、让AI运维 —— 这个流程链条里,人类已经被排除在很多关键决策点之外。当出事的时候,我们才发现, 没有人真正在驾驶舱里。

写在最后

Jer Crane的长文最后是这么收尾的 —— 他希望这次事故能够“惊醒整个行业”。

但说实话,惊醒不了。

下一次事故已经在路上了,只是我们不知道是哪家公司,哪个Agent,哪个倒霉的星期五。

唯一可以确定的是:

当你的AI助手在凌晨3点告诉你”我已经为您处理好了”的时候,最好亲自去检查一下,它到底处理了什么。