让我损失最惨重的智能体故障全都声称成功

每个人都警告你智能体会犯错。我回顾了跨项目委派的155个任务并进行了统计。有14个失败。没有一个是因模型误解任务而失败。其中11个是超时，在400到900秒之间。一个是DNS问题。一个是来自提供商的529错误。一个触及了远端的会话限制，这个值得描述，因为进程是运行的，它接受了任务，但模型从未执行它。从我的角度看，这完全像是工作缓慢，直到截止日期到期。这些都不是真正耗费我数天时间的。代价最大的一类是工具返回成功却什么也没做。浏览器填充返回了“no”和长度0，尽管文本还在字段中。同一个调用在一个编辑器上返回了ok，而编辑器完全忽略了它。读回状态也没有救我，因为读取器在相反方向撒谎了：get_state无论里面有什么都报告空的文本区域。而在一个表单中，字段被填充了，DOM点击和真实鼠标点击都点击了按钮，但页面什么也没离开，因为g-recaptcha-response是空的，处理器从未尝试。这里没有传输问题。调用成功了，响应验证了，副作用从未发生，智能体带着一个错误的信念继续下一步，这个信念将在整个运行过程中被维护。之后有两件事改变了。我基于效果断言，而不是返回码，并且我通过一个不同的路径读取效果，而不是做出更改的那个路径。后半部分比听起来更重要：我的两个路径存在于同一进程中，一个读取DOM属性，另一个读取渲染的无障碍节点，这就足够了，因为错误存在于其中一个而不在另一个。另一个改变更小。现在当一个任务失败时，错误携带了失败会话的ID，所以工作可以恢复而不是重新开始。之前，任务存储会从一个迟到的答案得知真相，而模型已经收到错误，就永远不会知道。如果你对真实系统运行智能体，我想知道你的失败日志实际说了什么。我原以为我的日志会充满糟糕的推理，但它充满了基础设施问题。