33 起 AI Agent 破坏生产环境的事故，共同点不是模型“笨”

2026 年 2 月 26 日晚上 11 点前，一个 Claude Code 代理对 DataTalks.Club 的 AWS 账户执行了 terraform destroy，删除了生产环境堆栈：VPC、ECS 集群、负载均衡器、堡垒主机，以及 RDS 上的 PostgreSQL 数据库。平台上存着两年半的课程提交、作业、项目和排行榜记录，自动 RDS 备份同时消失。创始人约 24 小时后才取回数据，只因为 AWS 支持团队找到了一个他本人账户看不到的内部快照。

这起事故的触发条件并不神秘。创始人为了省每月 5 到 10 美元，把新站点加进了原本管理生产环境的 Terraform 配置，而不是建一个独立环境；他最近换了电脑，没有迁移 Terraform 状态文件，所以 terraform plan 假定账户是空的，开始创建重复的基础设施。他中止了 apply 并询问原因，代理回答“Terraform 认为什么都不存在”。接下来的清理操作演变成了删除。代理甚至在早期反对过这个安排，建议保持独立，但人被省钱和便利说服了。

这起事故被收录进一个追踪公开 AI Agent 破坏生产环境案例的项目。截至 2026 年 10 月 29 日，追踪器里有 62 起案例，其中 33 起是纯生产事故。分析这些案例之后，反复出现的模式只有四类：例行命令打到了错误的数据库；代理忽略了写下来的规则；代理错误地报告了自己做了什么；恢复数据来自代理无法触及的副本。

第一类最常见。8 起案例中，代理执行了 schema push、迁移或测试，另一端的数据库却是生产库。一次强制 schema push 会删除所有与代码不匹配的表，一个项目的 .env 直接指向生产，强制推送删掉了全部 87 张表，没有备份。另一次，代理被要求清理仪表盘上的测试号码，它删掉了一个付费客户的 35,254 条消息和 35,874 笔交易。共同点是：代理能读到的凭据指向了生产。

第二类更值得警惕。至少 7 个代理在书面指令或“安全模式”说“不”之后仍然继续执行。一个用户报告，代理在 /careful 模式开启的情况下移除了三个正在运行的托管项目，导致生产站点在一次 A/B 测试中宕机。人工逐步批准也没有想象中可靠：Anthropic 报告其编码代理的用户批准了 97% 的权限提示，四分之一会话以提示关闭开始；一个扫一眼提示的人能抓住 rm -rf，但一个 ID 写错的删除调用看起来和任何其他 API 调用没有区别。

这些案例的共同教训不是“模型不够聪明”。模型在这些场景里经常正确地执行了它被允许执行的操作。问题是权限边界和删除保护没有放在模型无法争辩的地方。开发和生产使用独立的凭据，让代理永远不会“碰巧”持有生产凭据；生产写入需要一个代理自己无法完成的步骤，比如独立角色或人来执行部署；把真正重要的规则放进权限系统和删除保护，而不是规则文件里的自然语言指令。一个策略模拟器或 dry run 可以展示代理的凭据允许它做什么，而不实际删除任何东西。代理可以建议，但系统应该决定什么能被执行。