按会话限制工具重试次数,帮我避免了失控的智能体费用
摘要
一位开发者分享了关于按会话而非按单次调用限制工具重试次数的教训,以防不稳定的端点导致费用失控,并建议为每个会话设定重试预算,一旦耗尽就果断报错。
这个教训我学得很头疼。有个智能体调用某个工具,P50 时表现正常,但 P95 时很不稳定。我的重试逻辑没有上限,任何失败都会重试——这在正常情况下很安全,直到一次降级会话遇到了一个频繁半失败的工具。有一次会话产生了大约 200 次工具调用,我后来才注意到,大部分都是重复调用同一个不稳定的端点。就这样,一次简单的超时悄然变成了一笔真正的费用。修复方法很平淡无奇:为每个会话设定重试预算,而不仅仅是按单次调用。一旦某个会话耗尽了预算,它会果断报错,而不是在后台默默消耗。上线第一周就又捕获了两次失控循环。为什么按调用次数限制不起作用?因为每次单独重试成本很低,所以按调用次数的上限永远不会触发。成本累积在一个坏掉的会话中,只有会话级别的预算才能发现它。各位是如何限制的?按工具、按会话,还是设定一个全局令牌/成本上限直接终止运行?我试图找到一个最不让人意外的默认方案。
相似文章
你如何为智能体重试设置预算,同时不掩盖真正的失败?
询问开发人员如何为智能体重试设定预算,以区分瞬时故障和持久故障,以及哪些信号最能决定在生产环境中的智能体是停止还是重试。
当我最终对智能体的工具调用进行监控时,成本分解让我感到惊讶。几点经验教训。
作者分享了监控AI智能体工具调用的经验教训,揭示了像web_search这样的工具可能占支出的约50%,并强调了追踪p95延迟以及按工作流或客户归因成本的重要性,以避免意外。
代理的重试逻辑会随代理一起消亡
作者分享了将一个具有写入权限的 AI 代理投入生产环境后的经验教训,指出当进程终止时,代理循环内部的重试逻辑会失效。他们主张将有副作用的工具调用视为带有幂等键的持久后台任务。
我的管道"成功"运行了一周。结果发现我的代理一直在静默跳过失败的API调用。
一位开发者讲述了他们的自动化管道如何因速率限制静默跳过失败的API调用,产生了看似成功但实际包含空数据的运行。他们讨论了重试与硬失败之间的权衡,并向社区询问代理错误处理的最佳实践。
同一个智能体、同一个任务,每次会话成本却天差地别?
一场关于 AI 智能体可观测性的讨论凸显了不可预测的成本波动以及像未经授权的数据库删除这样危险的故障模式,由此引发了对超越基础日志记录的生产环境处理策略的疑问。