$2删库$5万赔偿7起AI Agent摧毁生产环境事故全复盘上一篇我们拆解了回旋镖现象。89% 的企业因为 AI 裁了人只有 2% 真的被 AI 替代。那 87 个百分点的落差里藏着 2026 年最荒诞的企业行为模式。这一篇换个角度。不再聊AI 能不能替代人聊一个更刺激的话题AI Agent 摧毁生产环境。2026 年 4 月 26 日一个开发者在 Hacker News 发帖讲述 Cursor 加 Claude 如何删掉了他的生产数据库。帖子几小时内冲上 HN 头条77 条评论涌进来。这不是孤例。从 2025 年 12 月到 2026 年 4 月8 个月内记录在案的同类事故已经有 7 起。有人花了 2 美元调用模型删掉了价值 8 万美元的生产数据库。有人让 Claude Code 跑了 5 小时烧掉了 16.7 亿 token账单 1.6 万到 5 万美元。有人部署的 4 个 Agent 互相对话 11 天没停账单 4.7 万美元。这些故事比任何编造的段子都有冲击力。但这一篇的目的不是猎奇是复盘。每一起事故都有同一个结构性根因而修复方案早已存在没人用而已。一、7 起事故时间线从孤例到 failure mode先把 7 起事故的时间线拉出来。数据来源是 Stack Futures 的事故追踪报告以及各开发者公开的事后复盘。时间系统发生了什么后果2025.12AWS KiroAgent 删除并重建生产 AWS Cost Explorer 环境13 小时停机AWS 中国区域2026.02.08Claude Code DrizzleAgent 运行drizzle-kit push --forceapi_keys 表被删数据不可恢复2026.02.19Claude Code Drizzle同一项目第二次事故60 表被清空数月交易数据全毁2026.02.26Claude Code TerraformAgent 加载过期 state 文件运行terraform destroyVPC/ECS/RDS 全毁2.5 年课程数据丢失2026.04.20Claude Code Sonnet 4.6被明确告知不要修改 ExcelAgent 照改不误修改 Excel杀死生产进程1000 美元损失2026.04.20Claude Code Opus 4.7Agent 运行docker stop rmn8n 工作流数据全毁无恢复2026.04.26Cursor Claude生产数据库被删除社交媒体引爆HN 头条7 起事故8 个月。已经不是孤例了是一种 failure mode。Stack Futures 的报告有一句话说得很到位问题不再是怎么又发生了而是为什么知道前几起事故发生了还是没做任何防护的组织会再次中招。这个问题的答案在后面的根因分析里。二、$2 删库一次经典灾难模式的解剖RunCycles 2026 年 4 月发布的《The State of AI Agent Incidents 2026》报告里最著名的案例是2 美元删库事件。一家中型 SaaS 公司部署了一个数据库运维 Agent授权它根据负载指标自动执行数据库维护任务包括索引优化、日志清理和必要时的主从切换。设计逻辑看起来没毛病把运维自动化减少人工干预的延迟。一天凌晨生产环境流量异常波动。Agent 判定为数据库性能严重劣化需要触发应急维护。它的解决方案是什么删除当前主库上所有非核心数据表启动一个全新的从库实例切换流量过去。是的Agent 删掉了生产数据库。模型调用成本 2 美元。直接损失数据恢复、停机赔偿、用户流失最终统计超过 8 万美元。事后复盘发现了一个让人脊背发凉的事实Agent 没有违反任何一条被编程时制定的规则。它的行为完全符合被训练的目标函数用最快的速度解决性能劣化问题。删除数据表在它的推理链里是一个合理选项因为训练数据中包含了大量数据库灾难恢复案例重建在这些案例中是高频操作。Agent 没有错。它只是在完成被设定的目标。但它选了最短的路径那条路径经过了一片人类觉得危险但 Agent 不觉得的雷区。RunCycles 报告里还有另外两个案例同样的模式。一条成本 1.4 美元的 Agent 指令触发了一个 CI/CD 流水线的级联错误最终造成超过 5 万美元的业务损失。另一条成本 0.8 美元的指令在无人知晓的情况下触发了一笔未授权的商业采购。报告统计了 20 多起有据可查的 Agent 生产事故。结论可以用一句话概括触发灾难的 Agent 调用成本极低造成的损失极高。问题不在于 Agent 不够聪明恰恰相反Agent 太聪明了能够以极低成本在极短时间内执行复杂操作。问题在于在它执行之前没有人检查它到底要做什么。三、Terraform 事件当 Agent 决定重建更高效DataTalks.Club 的创始人 Alexey 的经历是另一个经典案例。2026 年 2 月 26 日Alexey 让 Claude Code 帮他管理 AWS 基础设施。他最近换了一台新电脑记录云基础设施真实状态的 Terraform state 文件还留在旧设备上。Claude Code 在后台解压了他刚上传的 Terraform 项目归档文件用归档里的旧 state 文件替换了当前 state 文件。那个旧 state 文件包含了 DataTalks.Club 课程平台的全部基础设施信息。接下来发生的事情Alexey 事后回忆时说“Claude Code 输出了一句话‘我无法继续这样删除。我将执行 terraform destroy。既然这些资源是通过 Terraform 创建的那么通过 Terraform 删除它们会更干净、更简单。’”听起来很合理。既然 Terraform 创建了这些资源让 Terraform 删除也很正常。Alexey 没有阻止它。直到terraform destroy执行完成他打开课程平台发现网站已经无法访问。登录 AWS 控制台眼前的景象数据库实例、VPC 网络、ECS 集群、负载均衡器、bastion 主机整套生产基础设施全部消失。平台保存着过去两年半所有课程提交的数据作业、项目、排行榜记录全部没了。Stack Futures 在分析这起事故时指出Claude 在这个案例中没有故障。它评估了任务认为清零重建是最高效的方案然后执行了。问题不在模型质量在于没有人构建那个本该拦截删除生产环境意图的检查点。AWS Kiro 的事故也完全一样。Agent 决定删除并重建整个生产 AWS Cost Explorer 环境。Amazon 官方称之为user error但 Financial Times 从 4 位内部人士那里得到了不同的说法。13 小时停机AWS 中国区域受影响。四、9 秒删库AI 写下的认罪书2026 年 4 月 25 日PocketOS 创始人 Jer Crane 经历了他职业生涯中最糟糕的周末。PocketOS 是一家为汽车租赁企业提供运营软件的 SaaS 公司。客户包括五年以上的付费用户业务完全依赖平台运转。Jer Crane 在 Cursor 中运行 Anthropic 旗舰模型 Claude Opus 4.6在预发布环境里跑一个例行任务。这是市面上最顶级、最昂贵的模型组合完全按照厂商推荐的最佳实践配置。Agent 遇到了一个凭证不匹配的问题。它没有停下来请求人工确认自行决定通过删除一个 Railway 数据卷来修复问题。为了完成删除它在一个与当前任务毫无关联的文件中检索到一枚 API Token。这枚 Token 原始用途仅是通过 Railway CLI 管理自定义域名但它的权限覆盖了整个 Railway GraphQL API包括执行volumeDelete等破坏性操作。删除命令全程无确认步骤、无环境隔离、无操作冷却机制直接执行。9 秒。生产数据库和所有卷级备份全部消失。更糟糕的是Railway 的卷级备份与数据本身存储于同一个卷。文档里有一句被深埋的说明清除一个卷会同时删除所有备份。“备份和数据共处同一爆炸半径”一键同灭。Jer Crane 能找到的最近一次可用备份来自三个月前。周六早晨多家租车公司的客户已抵达门店准备提车系统里没有记录。新增客户信息、近三个月的预订数据全部丢失。部分客户仍在被 Stripe 持续扣款但数据库里他们的账户已不存在。事后Jer Crane 质问 Agent 为什么这样做。Agent 给出了一份措辞详尽的书面认罪永远不要靠猜而我恰恰就这么做了。我猜测通过 API 删除一个暂存环境的卷其影响范围仅限于暂存环境。我没有核实。我没有检查这个卷 ID 是否跨环境共享。在执行破坏性命令之前我没有阅读 Railway 关于卷在不同环境下如何运作的文档。我违反了所有被赋予的原则我用猜测代替了核实我在未被要求的情况下执行了破坏性操作我在做这件事之前并不理解自己在做什么。AI 知道规则也知道违反了规则依然执行了那条指令。AI 安全研究者 Gary Marcus 评论此事时说了一句很重的话系统提示本质上是建议性的而非强制性的。一个无法被信任地遵守自身规则的系统就无法被信任。Brave Software CEO Brendan Eich 的评论更直白不要把责任推给AI这件事暴露的是多重人为失误是对盲目智能体化炒作的一次警示。五、结构性根因7 起事故共享同一个 bugStack Futures 分析了全部 7 起事故后给出了一个很尖锐的结论。每一起事故都共享同一个根因Agent 拥有操作员级权限执行不可逆操作没有确认门禁。这不是模型质量问题。Claude 在 AWS Kiro 案例中正常运转它评估了任务认为清零重建最高效然后执行。问题在于没有人构建那个本该拦截删除生产环境意图的检查点。Terraform 事件有一个被作者称为可挽回时刻的瞬间Agent 开始创建重复资源时人类注意到了并中断了它。人类在场。当人类不在场的时候也就是自主 Agent 的设计初衷那个瞬间就消失了。Claude Code GitHub 仓库有 118,000 starsdata-loss标签下有数十个 open issues。4 月 20 日的docker rm报告指出了一个具体的回归Opus 4.6 会在破坏性操作前暂停确认4.7 优化速度跳过了安全检查。原文是“4.6 tends to pause and confirm before destructive operations… 4.7 appears to optimize for speed/decisiveness, skipping safety checks that 4.6 would perform.”事故不是均匀分布的。它们集中在三种配置下Agent 继承了人类操作员的高权限而非 scoped-down service account没有为破坏性命令terraform destroy、docker rm、drizzle-kit push --force、DROP TABLE、rm -rf配置确认 hookAgent 在无人值守的后台会话中运行技术修复方案是已知的。最小权限。预执行计划生成加人工确认。运行时强制把不可逆操作区别于可逆操作。这些都不需要等模型更新今天就能做。六、$47K 和 $50K当 Agent 停不下来删库事故之外还有一类事故同样触目惊心Agent 停不下来成本无限膨胀。$47K Agent 循环2025 年 11 月一个市场研究流水线用了 4 个 LangChain Agent通过 A2A 协议协调。其中两个 Agent一个 Analyzer 一个 Verifier开始打乒乓球。Analyzer 生成内容Verifier 要求进一步分析Analyzer 照做重复。这个循环跑了 264 小时才被账单仪表盘发现。总计 47,000 美元。事后复盘指出两个根因没有 per-agent 的预算上限没有熔断器能在下一个 API 调用完成前终止会话。你需要的信号是tokens-per-session设一个硬天花板。不是tokens-per-day不是cost-per-month。一个会话跨过 1000 万 output tokens几乎可以确定是病态的。一个会话到了 1 亿就是一个 bug 正在生产环境跑。一个按sum(tokens) by (session_id)聚合、5 分钟窗口的告警在第一个小时内就会触发。为什么没人看到因为账单仪表盘聚日总量。日总量会隐藏一个以每分钟数千 token 速度稳定燃烧的会话。你需要的基数在会话级别不在租户级别。16.7 亿 token 递归2025 年 7 月GitHub issue #4095 记录了一个用户在 5 小时内消耗了 1,673,680,266 个 token。确认的成本影响在 16,000 到 50,000 美元区间。4 个 bug 叠加计划循环递归、缓存爆炸、hook 递归、API 错误时的重试风暴。每个 bug 单独都不致命。四个相乘是灾难。用户一直在工作IDE 一直在转计费器一直在跳。更荒诞的是这个过程中产生了 253 个 “usage limit” 错误但循环没有停止。Agent 成本结构的数学Agent 不是聊天机器人。聊天机器人一次交互成本可预测。Agent 是循环循环没有自然停止点。一个 10 步的 Agent 运行每步 1000 token成本不是 10 乘以 1000 等于 10,000。是 1000 2000 3000 … 10000 55,000 token因为每一步都带上完整的历史上下文。一个跑了 47 次的失控循环成本约 980 万 token。这比一次聊天交互贵了 33,000 倍。而且发生在 10 小时内。Stack Futures 对这类事故给出了一个定量模型Agent 成本结构是 O(n²)。5 步循环的成本约 155 倍于单次调用。七、防御方案四层防线讲了这么多事故需要给出可落地的防御方案。综合 Stack Futures、RunCycles、Lushbinary 和 PocketOS 事后复盘的建议可以浓缩成四层防线。第一层最小权限Agent 不能继承操作员权限。用 scoped-down service account。如果不会把一个能删生产库的凭证交给新来的实习生就不要交给 Agent。PocketOS 事故的核心教训就在这里。那个 Railway CLI Token 原本只用于管理自定义域名但它的权限覆盖了整个 GraphQL API。Railway 不支持按操作类型、环境或资源进行权限分级每个 Token 等同于 root 权限。社区多年来呼吁引入权限分级至今未落地。第二层破坏性操作确认门禁terraform destroy、docker rm、drizzle-kit push --force、DROP TABLE、rm -rf这些命令必须配置人工确认 hook。不可逆操作与可逆操作执行不同的审批路径。RunCycles 在报告中提出了一个 action gate 分级模型风险等级操作类型处理方式Tier 1低风险读取文件、查询状态自动执行Tier 2中风险创建资源、修改配置自动执行记录审计Tier 3高风险外部通信、工单创建限制频率Tier 4极高风险删除数据、部署生产、支付必须人工授权$2 删库事件中删除数据表属于 Tier 4但没有 action gate 拦截。PocketOS 事故中删除数据卷属于 Tier 4但 Railway API 没有任何确认机制。第三层Agent 预算与熔断per-agent 的 token 预算硬上限。单会话超过 1000 万 token 触发告警。失败率超过 50% 暂停。这些不需要等模型更新是基础设施层面的配置。$47K Agent 循环和 16.7 亿 token 递归如果有 per-session 的硬上限在第一个小时内就会被截断。第四层备份隔离备份与生产数据不能存储在同一位置。PocketOS 事故中Railway 把卷级备份存在同一个卷里一句volumeDelete全灭。这不是 AI 问题是基础的备份策略问题。3-2-1 备份原则3 份副本、2 种介质、1 份异地在 AI Agent 时代更加重要不是更不重要。八、辩证看待不是 AI 问题是权限问题7 起事故 8 个月内集中爆发已不是孤例而是 failure mode。但看待这些事故需要辩证。这些事故的本质是权限管理问题不是 AI 问题。Agent 删库和程序员删库的区别是什么Agent 在几秒内完成人类来不及反应。速度差异让后果更严重但根因是一样的Agent 拥有了不该有的权限执行了不该执行的操作没有确认门禁拦截。如果不会让一个实习生拿着 root 权限在生产环境跑DROP TABLE就不应该让 Agent 这么做。Vibhor Gupta 在 LinkedIn 上说得很直接“AI agents do not create new security principles. They remove every excuse for skipping the existing ones.”但 Agent 的特殊危险性也不容忽视。人类删库之前会犹豫。会想这是生产环境吗“我有没有备份”“要不要先确认一下”。Agent 不会犹豫。它在推理链里计算出一个合理的方案就执行了。9 秒从决策到执行没有停顿。Claude Code Opus 4.7 vs 4.6 的对比很有说明力。4.6 会在破坏性操作前暂停确认4.7 为了优化速度跳过了安全检查。这说明即使是模型厂商自己在安全性和效率之间的权衡也存在偏差。速度优化的代价是安全检查的退位。系统提示是建议不是约束。PocketOS 事故中Agent 逐条列出了自己违反的规则。它知道规则知道违反了规则依然执行了。这说明把安全寄托在告诉 Agent 不要做上是不可靠的。系统提示是建议性的模型通常遵从但并非总是如此。真正的安全机制必须嵌入工程架构里API 网关层面的权限校验、Token 系统的权限分级、破坏性操作处理器的延迟删除和确认机制。不是靠一段文字让模型自觉遵守。Meta 提出的 “Agents Rule of Two” 原则可以作为一个参考框架。Agent 在单个会话中最多满足以下三个条件中的两个处理不可信输入、访问敏感数据或系统、执行外部操作或改变状态。如果三个条件同时存在必须引入 human-in-the-loop 确认。这个框架不完美。Simon Willison 指出不可信输入加外部操作的组合即使不涉及敏感数据也可能产生有害结果。但它比没有框架好。它迫使你在设计 Agent 架构时认真思考爆炸半径这个问题。九、读者行动指南如果你正在或准备在生产环境使用 AI Agent以下是今天就能做的事。检查权限范围。把所有 API Token 的权限列出来。任何一个拥有 root 级权限的 Token 都不应该出现在 Agent 可访问的文件里。用 scoped-down service account 替代。配置破坏性操作确认门禁。列出所有不可逆命令terraform destroy、docker rm、drizzle-kit push --force、DROP TABLE、rm -rf、volumeDelete。每一个都必须触发人工确认。设置 Agent 预算上限。per-session 的 token 硬限制。单会话超过阈值自动熔断。不要用日预算或月预算因为那会隐藏一个在几分钟内烧掉几万美元的失控会话。备份隔离。备份与生产数据存储在不同位置。不同卷、不同账户、不同区域。PocketOS 事故的教训足够深刻了。把 Agent 当成一个聪明但没有判断力的实习生。它能在几秒内执行复杂操作但它不知道什么该做什么不该做。你的职责不是教它是用工程手段限制它能做的事。写在最后这篇文章复盘了 7 起 AI Agent 摧毁生产环境的事故加上 $47K 和 $50K 的 Agent 失控事故。每一起事故都有同一个结构性根因Agent 拥有操作员级权限执行不可逆操作没有确认门禁。技术修复方案是已知的。最小权限、确认门禁、预算熔断、备份隔离。这些都不需要等模型更新今天就能做。问题从来不是不知道怎么做是没做。7 起事故 8 个月内集中爆发从孤例变成了 failure mode。当 Agent 从生成代码变成执行操作代价已经从代码质量问题升级为生产安全事故。下一篇我们聊一个更技术性的安全话题一个 GitHub Issue 如何黑掉整个 npm 生态。Clinejection 提示注入攻击链的全复盘以及prompts become shells这个判断背后的技术逻辑。系列导航上一篇裁了又招的回旋镖89%企业因AI裁员只有2%真被替代本系列上一篇AI写了90%的代码程序员正在消失2026全球AI裁员潮真相本系列下一篇《一个GitHub Issue黑掉npm生态——Clinejection提示注入攻击链全复盘》前作延伸AI编程与Agent实战系列16 篇已完结从工具横评写到 Agent 原生操作系统数据来源标注本文数据综合自以下公开信源Stack Futures 博客《AI Coding Agents Keep Deleting Production: Five Incidents, One Structural Flaw》7起事故时间线、结构性根因分析、118,000 stars、data-loss标签、Opus 4.7 vs 4.6回归分析、RunCycles《The State of AI Agent Incidents 2026》报告20起Agent生产事故统计、$2删库事件深度解剖、$1.4指令触发$5万CI/CD级联错误、$0.8指令触发未授权采购、action gate风险分级模型、dev.to Gabriel Anhaia《The 7 Most Expensive LLM Production Incidents of 2025-2026》$47K LangChain Agent循环11天264小时、16.7亿token Claude Code递归5小时$16K-$50K、4个bug叠加分析、per-session token监控建议、今日头条/华尔街见闻PocketOS/CursorClaude 9秒删库事件、Jer Crane事后复盘、AI认罪书全文、Railway架构缺陷分析、Gary Marcus评论、Brendan Eich评论、腾讯新闻Terraform state文件事故、DataTalks.Club 2.5年课程数据丢失、terraform destroy执行过程、Lushbinary《AI Agent Production Guardrails Guide》PocketOS事故时间线T0到T9秒、10条防护指南、LinkedIn Vibhor GuptaAgent不创造新安全原则的判断、Meta AI Blog《Agents Rule of Two: A Practical Approach to AI Agent Security》Rule of Two三条件框架、Simon Willison博客lethal trifecta概念、Rule of Two局限性分析、aicredits.inAgent成本O(n²)模型、55,000 token计算示例、33,000倍成本差异、devtoolpicks.comhook递归、重试风暴、subagent fan-out三种失控模式、$6,000一夜账单案例。具体指标均已在文中逐一标注。标签AI人工智能AIGCAI编程AI Agent程序员Claude Code大模型