工具超时、限流、空结果会诱使 Agent「再试一次」。没有预算就会自旋。重试预算 SOP 规定：什么错误可重试、总共几次、间隔怎么增、何时标记失败并交人。

适用场景

带搜索、浏览器、代码执行或内部 API 的 Agent；尤其是夜间批任务与多人共用配额时。

SOP 概览

  1. 分类错误：瞬时（超时/429）vs 确定性（404/参数非法）
  2. 仅瞬时错误进入重试池
  3. 全局预算：每任务 N 次，每工具 M 次
  4. 退避：线性或指数，带抖动
  5. 耗尽后：写清失败原因 + 已尝试轨迹，升级人工或降级策略

提示词/策略片段

【重试预算】
- 本任务总重试次数 ≤ 3
- 同一工具连续失败 ≤ 2
- 可重试：timeout, rate_limit
- 不可重试：invalid_args, not_found, auth_error
【每次重试前】简述上次错误码与你将改动的参数（若可改）
【预算耗尽】输出 FAILURE_REPORT：目标、尝试列表、最终错误、建议人工下一步
禁止：在不可重试错误上循环；禁止静默吞掉失败。

与记忆交接

失败报告应进入团队可读的交接备忘，避免下一任 Agent 重复撞墙。参见团队 Agent 记忆交接。

技巧与坑

  • 把「空检索结果」与「工具崩溃」分开：空结果常应改查询而非盲重试。
  • 预算要记在编排层，不单写在提示词里。
  • 对写操作（发邮件、下单）默认不可自动重试，除非有幂等键。

小结

重试是成本与风险控件，不是勇气。先分类错误，再花预算，花完就停并说清楚。

幂等与写操作

对创建、支付、发信等写工具，默认关闭自动重试，除非请求带幂等键且服务端保证只生效一次。读工具的重试预算可以更宽松，但仍要有上限。

观测

在编排层打点：重试次数、错误码分布、预算耗尽次数。没有观测，SOP 只是文档。

降级策略举例

预算耗尽后可选：返回缓存旧结果并标记过期；切换只读镜像接口；向用户展示失败说明与人工入口。选择哪一种由产品决定，并写进 SOP。切忌在耗尽后换成另一个更贵的模型无限重试，那只是换了一种烧钱方式。

在多人共用的 Agent 网关里，预算还应有「每用户每小时」上限，防止单个会话耗尽团队配额。把 FAILURE_REPORT 模板固定下来，值班人才能快速接手。定期回顾：哪些错误码其实不该重试、哪些重试几乎从未成功——据此收紧策略。文档与编排代码不一致时，以代码中的强制预算为准，并回写文档。

相关阅读