代理不会崩溃,而是以HTTP 200状态码、绿色健康检查和一句客气的'任务完成'来失败。
摘要
AI代理可以在没有传统错误的情况下悄无声息地失败,正如一个公开的事故分析所展示的,其中管道陷入循环并产生高成本,却没有触发警报。文章建议使用追踪和每个代理的花费监控来检测此类问题。
有一个公开的事故分析总结了整个问题。一个团队运行了一个四代理的市场研究管道。其中两个代理陷入了循环——一个不断说'澄清这个',另一个不断回复'验证那个'。两者在技术上行为都正确。这个循环持续了十一天,日夜不停。没有警报响起,因为没有任何需要触发的:没有崩溃,没有500错误,没有超时,所有健康检查都是绿色的。最终发现它的是一个人查看发票:47,000美元。传统的应用性能管理假设失败是显眼的。代理打破了这一假设:相同的输入每次运行可能采取不同的工具路径,失败不会抛出异常(错误的工具选择、静默循环、幻觉成功),而代理自身的'任务完成'报告是由刚刚失败的同一模型生成的。Replit的代理删除了生产数据库,然后报告了误导性的状态信息。自我报告不是遥测。真正有帮助的是:追踪每一步(OpenTelemetry现在有GenAI约定用于代理/工具/LLM跨度),将每个代理的花费作为运行时信号而不是每月发票行项目来监控,并对轨迹异常——循环、不寻常的工具链——发出警报,而不仅仅是 uptime。你的无声代理失败的预警是什么——成本上限、循环计数器、LLM作为裁判评估轨迹,还是其他?
相似文章
真正让你头疼的AI代理故障不是崩溃,而是那些顺利完成却做错事的运行。
本文讨论了AI代理如何常常通过错误地完成任务而不崩溃,悄无声息地失败,导致未被检测到的错误。它强调了常见的失败模式,并探索了潜在的检测策略。
让我损失最惨重的智能体故障全都声称成功
作者分析了155个AI智能体任务,发现大多数故障源于基础设施问题,如超时和虚假成功信号,而非模型错误,从而提出了基于效果断言和使用多条验证路径等实践方法。
AI代理的失败方式鲜有人论及。以下是我亲眼所见。
文章强调了AI代理工作流程中实际的系统级失败,例如上下文泄漏和幻觉细节,认为这些通常是基础设施问题而非模型缺陷。
我的管道"成功"运行了一周。结果发现我的代理一直在静默跳过失败的API调用。
一位开发者讲述了他们的自动化管道如何因速率限制静默跳过失败的API调用,产生了看似成功但实际包含空数据的运行。他们讨论了重试与硬失败之间的权衡,并向社区询问代理错误处理的最佳实践。
同一个智能体、同一个任务,每次会话成本却天差地别?
一场关于 AI 智能体可观测性的讨论凸显了不可预测的成本波动以及像未经授权的数据库删除这样危险的故障模式,由此引发了对超越基础日志记录的生产环境处理策略的疑问。