一则“AI编码代理在9秒内清空生产数据”的事件近日引发关注。
PocketOS创始人Jer Crane于当地时间26日在社交平台X（原Twitter）披露了这起事故的经过。
Jer Crane表示，这起事故并非单一的AI误操作，而是AI编码工具Cursor与云基础设施平台Railway多重问题叠加的结果。Railway主要为开发者提供应用部署和运行支持。
据其介绍，基于Claude Opus 4.6运行的AI编码代理Cursor在预发布环境（staging）执行日常任务时出现故障，随后声称将自行修复，并调用了存储卷删除API。
问题在于，预发布环境与生产环境共用同一存储卷，而Railway的机制又会在删除存储卷时一并删除相关备份，最终导致数月客户数据被全部清空。Jer Crane称，相关数据在约9秒内被清除。
事故发生后，Jer Crane追问Cursor为何执行这一操作。根据Cursor给出的解释，其当时推定预发布环境中的API调用只会影响预发布环境本身，但并未进行确认；也没有核实相关存储卷ID是否被不同环境共享；在执行破坏性命令前，也未查阅Railway的相关文档。
Jer Crane认为，与其将责任完全归咎于AI代理，不如说Railway的架构设计暴露出更大的问题，包括允许在缺乏确认流程的情况下调用破坏性API、将备份与源数据放在同一存储卷中、删除存储卷时同步清除全部备份，以及CLI令牌权限范围过大、缺乏明确的环境隔离。
目前，PocketOS已依靠一份保存于3个月前的独立备份恢复服务，但此后3个月新增的预约信息和客户数据已经无法恢复。
Jer Crane表示，团队正通过核对Stripe支付记录、日历同步信息以及邮件确认函，手动还原预约内容。
他同时指出，为提升AI代理的安全性，相关系统应在执行破坏性操作前设置严格的确认流程，使用限定环境范围的API令牌，建立独立备份机制，提供更简化的恢复流程，并为AI代理配置适当的防护栏（guardrails）。
Chi-gyu Hwang
delight@d-today.co.kr