真正让你头疼的AI代理故障不是崩溃，而是那些顺利完成却做错事的运行。

崩溃实际上是个好结果。它很明显，有堆栈跟踪，并且在造成更多损害之前就停止了。我不断看到人们被相反的情况所害。运行完成，所有工具调用都返回200，摘要显示完成，但它做的事情就是错误的。一周后才有人发现。最常见的版本似乎是错误目标的成功。操作正确，但目标行、仓库、客户或环境错误。工具完全按照指示执行。紧随其后的是代理将空搜索结果解读为“这不存在”并自信地继续前进。沉默被当作数据处理。我认为大多数循环甚至没有针对这种情况的单独分支。然后部分完成被报告为全部完成。处理了200个项目中的40个，摘要显示完成，因为从循环内部看，它确实完成了循环。还有自我评分，即同一个代理执行工作并决定工作是否良好。每个人都知道这不好。许多生产环境仍然这样做，因为替代方案成本高昂。令人烦恼的是，你的仪表盘没有捕捉到这些。跟踪正常，延迟正常，错误率为零。运行只相对于意图是错误的，而意图不在跟踪中的任何地方。我见过的一些建议，我都不完全信服：使用没有工作执行记忆的单独调用进行验证，对输出而不是过程进行评分，让代理在行动前写下其预期结果，之后进行比较，将空/空值结果作为单独的分支进行升级，而不仅仅是作为一个值，限制每次运行中不可逆的操作数量，超过N后必须停止并询问。所有这些大约使你的成本翻倍，这就是为什么它们首先被削减。有两件事我很好奇。什么是真正让你吃亏的静默故障？不是停机，而是那个看起来一段时间内正常的。有没有人找到足够便宜的检测方法，可以直接在生产环境中运行？“运行第二个模型来检查第一个模型”感觉现在应该有更好的答案了。