开发者记录五个月 AI Agent 失败：仅 6/48 被自动捕获

一位运营小型电商业务的开发者在 Hacker News 上分享了自己五个月内记录到的 48 起 AI Agent 故障，并按「如何被发现」而非「故障类型」做分类。统计显示，仅 6 起（约 12.5%）被任何自动化机制捕获，29 起（超六成）是数周乃至数月后在无关排查中偶然发现的。文章的核心观察是：随着 Agent 能力提升，代码层面的错误减少，取而代之的是「基于正确数据得出错误结论」，而这类问题没有堆栈可供测试抓取。

五个月、48 起故障的发现方式

作者将每一起故障按被发现的方式归入五类：

GATE：确定性校验在执行前拦截
THREW：运行时实际抛出错误
HUMAN：人员对某个数字产生怀疑
OPERATOR：操作员反馈「数据似乎缺失」
LATER：在无关排查中偶然发现

48 起故障在这五类中的分布为：GATE 1 起、THREW 5 起、HUMAN 12 起、OPERATOR 1 起、LATER 29 起。亦即仅 6 起被任何自动化手段捕获，超过六成被偶然发现。

自动化捕获占比为何停在 9%–15%

作者原本预期，随着针对已知故障不断补齐防御措施，被自动捕获的比例会逐步上升。但实际数据显示，在五个月内事件总量增长 2.7 倍的背景下，自动化捕获占比始终在 9%–15% 之间徘徊（11% → 9% → 15% → 13%），没有呈现上升趋势。

期间确实补齐过针对性修复：

为已上线的失效链接加 CI 校验
为一个定价 bug 加回归测试
为被静默吞掉的邮件投递错误加计数器

这些修复每一条都按预期工作，但它们无一捕获到新的故障。文中作者写道，每条防御措施都是为单一故障而事后补齐的，而当前占主导地位的故障形态并不属于它们能识别的类型。

从代码错误到「正确数据的错误推论」

文中损失最大的几起故障都呈现同一形态：Agent 读取正确的表、执行正确的查询，却得出错误的结论。

一份报告将广告平台的归因转化数当作真实销量，断言九天内销量归零并提交到主分支。该窗口内实际卖出 14 张票——广告平台仅能看见其中约 11% 的真实销售，而数据库中已经存在花费与营收的完整连接表，无人去读。
一次跨性别广告支出泄漏测算结果为 241.81 美元，方法是把各广告组的终生花费与「当前定向」比对；该方法对任何被编辑过的广告组都不成立。按每次编辑的时间戳重测，其中 180.56 美元的「泄漏」发生在定向锁定之前；真实数字约为初值的四分之一。
一次渠道分析称某平台广告从未在该账户投放，实际该平台四个月内为每个活动都投了广告；按其自身归因，其带来的票数是被建议保留渠道的 60% 花费下的 3 倍以上。

作者形容这类输出「语法完美、内部一致、措辞自信、完全错误」，而仓库里没有任何检查会问「结论是否成立」。

一手观察而非行业基准

需要指出，本文来自一位个体经营者在 Hacker News 上发布的个人经验贴，其业务体量很小（Stripe 收单、Firestore 后端、真实广告账户与实际客户），并非行业基准测试或同行评审研究。文章正文在「I wrote that a s…」处被截断，后半部分结论未能完整呈现。读者宜将其视为一名一线从业者对 Agent 可靠性的质性记录，而非可推广的统计数据——但它指向的问题，即「语义层面的错误没有测试抓手」，在当前 Agent 工程实践中具有相当的代表性。