2 篇博文 含有标签「retry」

我在上季度接触的一个团队在他们的推理账单上发现了一笔 4200 美元的条目，没人能解释其来源。控制面板显示的流量正常，延迟图表也很平稳。原因最终被发现是一个 Agent 陷入了长达 6 小时的“礼貌”重试循环中，它不断地通过指数退避（最高限制为 30 秒后重启）来重放一个包含 4 万个 Token 的工具链。这套重试策略是直接从 2019 年为基于 HTTP 的 JSON 服务编写的内部 SRE 手册中照搬过来的。它运行得非常完美——只是用错了系统。

这就是那种不会出现在容量规划表中的账单。行业标准化的无状态 REST API 重试策略模式默认了三个前提，而 LLM 工作负载在悄无声息中违背了这些前提：故障是瞬时的、单次额外尝试的成本是有限的，以及重试有合理的成功机会。每一个前提曾是关键的支撑，而现在每一个都是错的。这种成本模型从未捕获的偏差，正潜伏在每一份月度账单的底部。

那些还没有根据 Token 经济学重建重试策略的团队，正在缴纳一种隐形税。这种税收随着你本就最担心的查询难度而增加——那些长文本、Agent 类以及带有深层工具链的查询。在 LLM 技术栈中，经典韧性工程提供给你的安全网，反而成了勒紧脖子的绞索。

在值班文档的表格上，搜索工具的错误率为 2%。事故审查报告称，在三个小时的时间窗口内，Agent 平台的故障率为 20%。没人对这两个数字有异议。搜索团队没有过错。平台团队也没有发布 Bug。这两个数字之间的差距就是故事的全部，而这是一个关于算术的故事，而不是工程能力的平庸。

重试逻辑是 Agent 系统中最常被借用且最少针对性调整的模式之一。团队从他们的 REST 客户端复制 tenacity 装饰器，将它们堆叠在 SDK、网关和 Agent 循环中，然后直接上线。每一层单独看都是合理的。但这种组合就像是一件指向集群中最不稳定依赖项的攻城武器，而且它恰恰在那个依赖项最需要降低负载的时刻开火最猛烈。

本篇文章将探讨这种数学逻辑是如何运作的，为什么 Agent 循环比请求-响应系统更剧烈地放大错误，以及如何通过重试规范防止瞬时波动演变成印着你自己公司 Logo 的关联性宕机事故。