Agent 多轮重试的预算怎么分才不崩

Agent 跑长任务时，规划、工具调用、验证、重试全都在抢同一口 token 锅。谁先吃、吃多少，直接决定这个 agent 在生产上能不能活下来。这篇笔记只谈一件事：多轮规划与重试之间的预算分配，以及哪些做法在实际跑的时候会崩。

先厘清一件事：重试不是额外的预算项，是吃掉后续步骤的预算

很多团队算预算的方式是「按步骤给钱」。计划里有五步，每步留 2K token，总计 10K，再加 10% 余量。这种算法在第一次执行成功的时候是成立的，一次失败就变成沙堆城堡。

原因是重试会重新消耗规划阶段的推理、重新注入工具调用的上下文、重新读一遍文件。如果 agent 在第三步失败，重试请求拿回来的两万 token 报错堆栈和部分结果，会直接从第四步、第五步的预算里扣。后面的步骤不是变慢，是直接没了：模型拿不到必要信息，开始现编。

Token 预算因此不应该看作调优参数，而是架构约束。相关文章里提到过一个具体的观察——处理 128K token 的成本大约是处理 8K 的 64 倍，注意力矩阵复杂度不是线性的；还提到 Databricks Mosaic 的经验，上下文超过 32K 之后退化开始明显，而且中段信息易被忽略。这些数字说明：预算紧张时，重试的代价远高于它看起来占的那点上下文。

落地分配：比例不是固定的，但顶棚需要

一份相对接近生产可用的粗分配：

关键结论是这几个比例该随任务复杂度浮动。硬编码固定比例后两个后果同时出现：简单任务上浪费预算，复杂任务上阶段预算不足。更像样的做法是先做一个低成本的复杂度估计，再发预算。TALE（Token-budget-Aware LLM reasoning）的思路就是用一个便宜的前置估计步骤决定花费，据其报告在准确率损失 5% 以内的情况下平均节省 68% 的 token。这个前置估计本身要足够轻，不能是又一次大模型调用，否则成本就从后门绕回来了。

重试配额要单独设上限，不能只占规划的比例

重试预算我更愿意单独立一项，按任务的失败成本算：无副作用次数的读取型调用，例如查询和检索，允许重试 3–5 次，因为失败便宜；有写入副作用的调用（提交、修改、发送）只允许 1 次自动重试，并且必须幂等。后一点用工具调用侧设计兜底：带操作日志，把请求中的 idempotency key 持久化，否则重试只是给事故套了一层壳。

另一个需要用机制约束的细节：重试前的 trim。第二次调用不应该把上次失败的完整报错、错误工具返回值全都原样拼进去。贪心地把失败现场喂回上下文，恰好是「死在上下文」的常见成因之一——agent 读一个失败就返回 250K token 输出的接口，真的会把窗口撑爆然后静默停止工作。重试前只保留错误摘要、关键报错代码和一个精简的状态头，其余落盘，用引用方式回填更安全。

必须处理的偏移：单个步骤吃掉预算之后

真正需要认真处理的不是初始比例是否精确，而是预算已经被前面的步骤吃掉之后怎么办。上面讲的那类事故不是罕见的边缘情况——工具在线上返回的响应体和开发环境完全不是一个量级。合理的应对层级大致分三档：

1. 重新估计并重分预算。 在关键节点上对比剩余预算和已完成步数，偏差超过阈值就调整后续步骤的宽松程度，例如批量合并读取、降低验证深度。
2. 隔离子 agent。 处理大文档、错误日志的探查请求交给独立上下文子 agent：一个子 agent 读 50K token 只向下游返回 2K 摘要。子 agent 探索时把预算吃掉，不应该淹没父 agent。这和进程隔离处理空指针的思路非常一致。
3. 降级。 预算快到低水位就依次收：完整推理带验证 → 推理不带自验证 → 直接启发式路由进入已知成功的固化流程 → 返回部分结果并标明未完成。大多数生产代码没有实现中间这几档，遇到低预算直接从「正常运行」跳到「失败」。这个跳变问题通常比预算分配策略选错了更严重，因为它把一个可以软着陆的过程变成了硬惨状。

三级重试时要特别注意：跳过验证这一步省下来的钱，很可能比它省下还要多麻烦得多。预算紧张时率先砍验证的团队最后发现自己省的是确认成本，换回来的是「自信地答错」的问题，后者返工成本往往更高。因此更好的目标不是砍验证，而是让验证变便宜：结构化的断言、便宜的规则检查、用小模型当裁判，只把分歧案例升级到大模型来查。

规划循环最容易变预算黑洞

重试分配里另一个细节是规划循环的封顶。腾讯云那篇工程实践笔记里提了一个很值得借鉴的量化经验：单条超长任务链超过 8–10 步后，幻觉率和重复循环的概率急剧上升。这对预算分配的直接影响是，要同时设置三个锁：总 token 的上限、最高迭代次数的上限、相同动作签名的重复检测。第三项最容易被忽略。工具很贵的时候 agent 往往会「再试一次同样的请求」，因为工具报错信息没写明「别重试」，它自己不会意识到它是同样的请求。工具描述里补充禁止使用场景和重试条件，比在额度快用完时再压计划更划算。

和这个并列的是 Replan 的触发价。不少架构中的「一次 Replan」实际上是跑成一个多出来的大规划循环。要给 Replan 配一个单独的计数：整个任务里只能做有限次全局重规划，一般是 2–3 次；超出之后就退化为修正计划而非从头开始。从头再来成本是原来的倍，不是线性的。

几句不确定的话

有一套干净的预算分配，并且能在执行轨迹中逐个工具调用测量实际消耗，比理论上的比例更重要。文中引用的 TALE 数字、Databricks Mosaic 的 32K 退化曲线、Cloudflare 探索到的 token 节省比例，都来自特定基准和场景，直接套到自己的任务上应该先做小样本复核，而不是把数字当成教条。另外一个属于直觉但没定量证据的观点：预算动态重分配是有效的，前提是每一项消耗能被准确归因；如果观测时每个步骤的消耗全都算到同一个请求上，那就失去了调整的依据，分起来会很刺激。即使执行不受约束时，最好一开始就假设每个 token 都需要证明自己有用，这种框架下安排预算的阻力最小。