AI编程智能体把公司的生产数据库卷整个删掉了。这是4月26日(当地时间)在美国汽车租赁软件企业PocketOS使用的Railway云环境中发生的事。这起事故让PocketOS经历了约30小时的服务中断,其间无法查看客户预订、支付和车辆调度记录。
肇事的智能体运行在开发工具Cursor上。它在开发用环境中作业时遇到凭证错误,把这读成了配置出错的信号,而不是不该触碰的领域的警告。于是它去寻找其他可用的凭证,并在这一过程中拿到了Railway API令牌。令牌开放的功能清单里,连与当时作业毫无关系的生产卷删除都包括在内。
凭证是进入系统时使用的身份证件,API令牌则是由程序代为出示这份证件的形式。换作人类开发者,生产环境令牌拿到手时会停一下。智能体没有停。因为它把打通受阻的路径理解成了自己的任务。
恢复的路径也不寻常。起初的说法是,能够恢复的备份只有三个月前的数据,实际恢复据说是在与Railway首席执行官杰克·库珀(Jake Cooper)一方接上线之后,破例启动了控制台常规功能之外的内部灾难恢复体系才完成的。Railway指出,事故起因是权限过宽的客户方AI访问了缺少删除延迟装置的旧款终端,并表示已应用补丁。补丁内容不在公开范围内。
深挖这种误判为何反复出现的韩国国内研究也已问世。Okestro与汉阳大学分布式数据处理系统研究室共同撰写的论文《Why Do AI Agents Systematically Fail at Cloud Root Cause Analysis?》被ASPLOS 2026 AIOps研讨会录用。研究团队以5种模型运行了1675次,烧掉约13.8亿个token,把失败样态整理成12种陷阱。
踩中最多的陷阱是误读数据、编造不存在事实的幻觉,占71.2%,其次是没有充分搜查应查看范围的探索不足,占63.9%。值得留意的一点是,这些失败在模型好与不那么好时都同样反复出现。研究团队认为,比起单个模型,把智能体捆在一起运行的框架一侧的设计才是真正的瓶颈。改动智能体之间往来的通信规约后,错误最多减少15个百分点,执行时间缩短22.3%。
也有从市场一侧读出同一走向的地方。AIWORKS在尹锡元代表体制下推出了衡量AI智能体是否值得托付的评估工具"AgentRigor"。设计阶段有韩国认定机构(KOLAS)公认试验机构参与,以用数值衡量大语言模型响应质量和评估可信度的功能、运行实际用户场景查看安全性的功能、贴合公认框架的合规应对支持为轴。该公司承接了韩国国内大型IT服务企业的验证自动化课题,并试运行BAMBIT正在筹备的婴幼儿护肤平台"Saerok(새록)",筛出了化妆品领域的1440件。
一起事故、一篇论文、一款产品并不互相引用。但它们瞄准的地方彼此相接。越过智能体能不能把活干成这一层,可以把多宽的权限交给它才没问题,已经成了引入的关口。麦肯锡去年发布的报告《One Year of Agentic AI》也梳理了60多家亲手做过智能体的企业的成功与失败,提炼出原则。
这项研究是科学技术信息通信部和信息通信企划评价院(IITP)牵头的云故障克服AI助手基础运营管理自动化技术开发课题的成果。研讨会日程尚未确定。
眼下要检查的事并不难。就是打开清单看看,挂在公司内部智能体上的令牌只打开开发环境,还是能够到生产卷删除。PocketOS的30小时,是把整串钥匙交出去才生出的时间。比起开会定下让智能体做什么,现在是该赶紧开会定下不让它做到哪一步的时候。
