静默失败的AI代理比高调失败的更糟糕

在构建或调试的几个不同代理设置中，我注意到一个模式：最耗时的失败不是崩溃或错误，而是那些继续工作、调用工具、产生看似合理输出，却毫无实际进展的代理。一个永不升级的重试循环。一个研究代理，因为之前的获取未满足目标，而用稍作修改的查询重新获取相同来源，但没有任何机制让它意识到这一点并尝试不同的方法，而不是同一方法的不同表述。共同点不是糟糕的模型或工具。而是大多数代理设置定义了代理能做什么，但没有定义什么情况算作“这不起作用，停止并升级”。执行相同任务的人类几乎自动地识别出卡住状态，三次相同的失败尝试被视为改变策略的信号。代理没有等效的信号，除非有东西明确给出。如果不干预，它只是从“合理的下一步行动”分布中持续采样，每次产生略微不同的变体，这在追踪中看起来像进展，即使实际上不是。这似乎正是“有工具的代理”和“生产环境中可靠的代理”之间的真正差距。工具访问解决了能力问题。但它无法帮助知道当前方法何时停止有效。这必须是一个显式检查，更接近断路器而不是提示指令，通过比较当前状态与过去N个状态，一旦重复超过某个阈值，强制改变策略或转交给人类，而不是依赖模型自行注意。很好奇这里的人们在实际中是如何实现这一点的：硬性迭代上限并强制升级，一个单独的模型调用来定期判断最近几个步骤是否取得了真实进展，还是其他什么方法？感觉这在很多代理架构中都被跳过了，直到它导致生产事故。