LLM Agent 的重试预算：为什么 20% 的单步失败率会让你的 Token 账单翻倍

大多数团队只有在账单出现时才会发现重试问题。智能体（Agent）“运行正常”；延迟仪表盘保持绿色；错误率看起来也没问题。然后财务部门询问为什么本月的推理支出翻了一番，这时才有人终于去翻看日志。结果发现，一个 3 步操作的智能体中，20% 的工具调用在静默重试，每次重试都重放了完整的提示词（prompt）历史记录，而账单已经连续几周在攀升。

这背后的数学逻辑并不神秘，但极其反直觉。20% 的单步重试率听起来还可以接受 —— 大多数工程师看一眼就会忽略它。但一旦考虑到现代智能体框架的重试方式，实际的 Token 成本会更接近 2 倍而非 1.2 倍。而且，这种失败模式对于团队通常关注的每一项指标都是不可见的。

重试预算（Retry budgets）—— 这是一个源自 Google SRE 工作的旧概念 —— 是最简洁的解决方案。但该模式的 LLM 版本需要调整，因为 Token 的行为方式与 RPC 不同。

复利效应比看起来更糟

天真的模型：一个 3 步智能体，每步 20% 的失败率，失败后重试一次。每步的预期调用次数是 1/(1-0.2) = 1.25。三步意味着 3 × 1.25 = 3.75 次调用，而基准值为 3 次 —— 也就是 25% 的开销。这虽然令人烦恼，但并不算警报。

这种模型对几乎所有生产环境中的智能体来说都是错误的。原因如下。

大多数智能体框架 —— LangChain、LlamaIndex、OpenAI 和 Anthropic 的工具使用 SDK —— 都是通过重放对话历史来进行重试的，而不是孤立地重试单个失败的步骤。当第 3 步失败并重试时，你会重新发送系统提示词，加上第 1 步和第 2 步的输出，以及失败尝试的错误信息。该重试的 Token 成本不是单步的 Token 量；而是截止目前累计的上下文窗口（context window）。

在上下文重放的情况下重新计算。在一个重试率为 20% 的 3 步智能体上，预期 Token 消耗会攀升至约 基准值的 1.7–1.9 倍。在同样重试率的 5 步智能体上，Token 开销会攀升至 2.2–2.5 倍。这种复利效应在上下文大小上是平方级的（quadratic），而不是在步骤数上线性增长的，而这正是从业者所忽略的部分。

再加上多层重试 —— 工具内部的 SDK 重试、包装工具的中间件重试、包装整个循环的智能体级重试 —— 你就会遇到 Google SRE 手册在十年前就警告过的乘法链条。跨五个服务的每层三次重试是典型的“重试风暴（retry storm）”案例：在最坏的情况下，单个用户请求会产生 3^5 = 243 次后端调用。LLM 流水线也不能幸免；而且情况更糟，因为每次调用的成本都更高。

来自真实事件的真实账单

重试风暴并非理论。Anthropic 自家的 claude-code 仓库在 2025 年 7 月记录了一个问题，描述了单个用户会话在 5 小时内消耗了 16.7 亿个 Token，峰值达到每秒 224 次请求，估计账单在 16,000 美元到 50,000 美元之间。事后分析确定了四个重叠的根本原因，其中一个是明确的：253 个 "usage limit" 错误未能停止循环。在供应商提示停止后，重试逻辑仍在继续运行。

同一仓库中 2025 年 10 月的另一个问题记录了单日消耗 1.088 亿个 Token —— 按 Sonnet 价格计算约为 64 美元 —— 原因是自动压缩（autocompaction）漏洞导致同一个文件被循环重复读取。根本原因不同，但形式相同：没有预算限制的重试。

在个人开发者层面，一篇流传甚广的 Substack 帖子记录了 8 个月的 Claude Code 使用量累计达到 100 亿个 Token，按目前的 Sonnet 价格计算约为 15,000 美元，这主要源于用户从未直接观察到的链式调用模式。

更小、更隐蔽的失败更为常见。最近一项针对 ReAct 风格智能体的基准测试发现，在 200 个任务中，90.8% 的重试 —— 513 次尝试中的 466 次 —— 被浪费在了幻觉产生的或不存在的工具名称上。智能体虚构了一个不存在的工具，工具调用失败，智能体带着稍微不同的幻觉进行重试，以此类推。重试并不是解决方案；它们是披着“乐于助人”外皮的失败模式。

适配于 LLM 的 Google SRE 重试预算

SRE 手册针对重试风暴的解决方案优雅而简单。首先在单个请求级别限制重试（尝试次数绝不超过 N 次）。然后，在客户端级别，在一个滚动窗口内跟踪 重试次数 / 总请求数，一旦该比例超过 10%，就拒绝进一步重试。如果没有第二个限制，在部分停机期间，负载会增长到基准值的 3 倍。有了它，负载只会增长到 1.1 倍。该预算将重试视为一种有限资源，系统通过成功的基准请求来“赚取”重试机会。

将此方案转化为 LLM 智能体需要进行两项调整。

第一，将单位从“请求次数”改为“Token 数量”。 LLM 领域的重试成本不只是一个容量单位；其成本与提示词大小成正比。预算应以每个用户每个滚动窗口内的“重试 Token 数”为单位，而不是“重试次数”。一个在 2,000 Token 上下文中重试两次的会话，不等同于一个在 50,000 Token 上下文中重试两次的会话。

第二，在循环内部强制执行预算，而不是在外部。 大多数重试中间件位于 HTTP 层，远低于智能体逻辑所在的层级。智能体循环本身 —— 工具调用重试、JSON 解析重试、验证重试 —— 才是需要检查预算的地方，因为那是发生重放的地方。通用的 HTTP 重试策略看不到带有历史重放的 5 步重试所产生的累积上下文成本。

## 重试预算账本模式

智能体系统的一个行之有效的模式是：维护一个针对每次会话的账本，实时跟踪该会话中每次重试尝试的累计 Token 成本。该账本公开了三个指标——重试 Token、剩余预算和重试原因——并且每个具备重试能力的代码路径在触发前都必须咨询它。

生产团队达成共识的规范准则：

- **单次会话上限**：总重试 Token 不得超过会话基础 Token 预算的固定百分比（实践中 10–15% 比较有效）
- **单步上限**：无论会话预算如何，单个步骤的尝试次数不得超过 N 次
- **单租户上限**：独立于会话计算，设置每个租户每天的硬性美元封顶金额，并在达到 80% 时发出警报
- **不可重试错误列表**：内容过滤拒绝、授权无效和硬性 Schema 违规应直接短路而不是重试，因为重试注定会失败

一个清晰的退出策略与预算本身同样重要。当预算耗尽时，智能体需要一条优雅降级路径：回退到较小的模型、返回带有置信度标志的部分答案、移交给人工审核，或者返回一个受限的“我不知道”。它绝对不能做的一件事是在账本被忽略的情况下继续默默重试。

## 在 CI 中捕获重试爆炸

重试很难测试，因为它们只在正常路径评估（happy-path eval）中不存在的条件下触发。答案是刻意的故障注入：丢弃工具调用、返回格式错误的 JSON、模拟 429 错误，并在这种混沌基座上运行智能体。然后对预算进行断言。

在 CI 中用于门禁的实用评估断言：

- `tokens_per_task < p95_budget` —— 标记重试驱动的成本飙升
- `retries_per_session < N` —— 标记重试循环
- `steps_before_first_tool_call < M` —— 标记虚构工具的重试
- `variance(steps_per_task) < σ_max` —— 重试健康的智能体步骤分布方差较低，重试病态的智能体具有长尾效应

方差断言是最重要且最不直观的。健康的智能体在解决类似任务时，其步骤分布是紧密的。容易发生重试的智能体具有肥尾——大多数任务完成很快，但少数任务花费了 5 倍的步骤，而平均值看起来还不错。捕捉重试病态需要查看第 95 百分位或分布情况，而不是均值。

像 `agent-chaos` 这样的故障注入框架使这变得切实可行。这种模式与微服务的混沌工程相同：刻意注入生产环境最终会给你的故障，并根据系统降级的优雅程度来决定是否通过 PR 门禁。

## 周一该改什么

如果你的智能体已上线生产环境但尚未审计过重试，操作顺序大致如下：

1. **先测量。** 将重试作为一等公民指标——按会话、按工具、按步骤，并附加 Token 消耗。如果你无法通过一次查询回答“我每月的支出中有多少比例是重试？”，你就无法管理这个问题。
2. **找出虚构工具率。** 大部分重试预算泄漏不是因为限流，而是智能体在凭空捏造工具名称。严谨的工具描述和硬编码的小型工具白名单可以立即解决大部分此类问题。
3. **加入预算。** 即使是粗略的带有硬停止的单次会话 Token 上限也能防止失控的会话。后续可以再进行细化。
4. **在评估中接入故障注入。** 两三个覆盖工具故障、格式错误 JSON 和 429 错误的混沌案例，足以在发布前捕获大多数重试爆炸导致的回归。
5. **清理冗余的重试层。** 嵌套在重试中的重试几乎总是错误的。选择一层来承担重试逻辑，并在其他所有地方禁用它。

令人不安的事实是，大多数运行 LLM 智能体的团队在运行时根本没有任何显式的重试预算——一年前的 SDK 默认值原封未动，又在无人负责的三个抽象层中成倍放大。那不是配置，那是承诺支付供应商本月收取的任何费用。重试预算是让这一开放式承诺重新变为受控成本的基础设施。