大模型调用的超时重试与成本控制

智能体任务通常包含多次模型调用和工具操作。当其中一步超时时，自动重试可以帮助恢复，但也可能增加调用消耗，或重新执行已经完成的业务动作。

治理这类问题，需要区分任务结果、请求状态和用量记录。一次任务最终成功，不代表它只执行过一次请求；客户端显示失败，也不能证明服务端没有处理。

一、把执行状态未知作为独立情况处理

超时可能发生在建立连接、等待处理或接收响应的过程中。对于请求已发出但结果未收到的情况，应保留“执行状态未知”，避免直接归入“未执行”。

如果前一次请求已经产生可计费用量，重试又形成新的处理，总费用可能增加。具体收费应以所用模型服务的计费规则和实际用量为准，不能仅根据超时异常判断。

当接口提供任务查询、结果获取或取消能力时，可以按接口规则确认状态。客户端停止等待不等于取消已经生效；即使取消成功，也不能直接认定此前消耗被撤销。

二、从任务级别约束分层重试

应用、SDK 与代理层可能分别配置重试。若这些层级各自耗尽次数，底层尝试就可能超过业务开发者的预期。

例如，在一个简化配置中，业务层最多尝试两轮，每轮底层客户端最多尝试三次，持续遇到可重试错误时最多可能产生六次请求尝试。这只是次数上限的示例，不代表请求全部到达服务端，也不代表费用固定增加六倍。

应明确重试策略的负责层级，将次数上限、总耗时与预算共同纳入任务约束。重试前检查剩余资源，超过边界时保留已有结果，并明确告知未完成部分。

三、区分可恢复错误与配置问题

短时限流和部分临时服务故障，可以在有限条件下考虑重试。按服务端提示退避，并适当分散尝试时间，有助于避免集中重发。

参数不合法、凭证失效和权限不足，应先修正原因。额度耗尽或账户受限，也不能仅依赖等待恢复。错误分类需要结合具体接口语义，不能仅凭一个状态码套用统一规则。

对于耗时较长的模型任务，应结合实际延迟设置超时。过短的等待时间可能让尚在正常处理的请求反复被中断。采用流式响应可以改善部分场景的等待体验，但不保证消除费用，也不保证中断后能够续传。

四、恢复模型调用时保留业务进度

智能体可能已经完成查询、生成和写入等多个步骤。如果后续某一步失败后从头开始，前面成功的调用也会被再次执行。

因此，应识别已完成步骤与待恢复步骤，并核对重复执行的影响。写入记录、发送通知等操作，需要接口支持的幂等机制或业务状态检查。自行增加一个请求标识，并不能自动保证远端去重。

模型调用的费用控制与业务操作的幂等性也应分别评估：业务动作只执行一次，不代表此前多次推理不会产生费用。

五、用可追溯记录支持成本判断

建议将业务任务标识与各次尝试关联，记录重试原因、发起层级、耗时、模型、可获取的服务端请求标识，以及已知用量和费用。密钥与敏感业务内容应脱敏。

没有收到用量记录时，应标为待核实。后续能够获取明细时再做匹配；只有汇总统计时，应保留无法精确归因的部分。

预算控制需要考虑输出长度变化、并发消耗和用量回传延迟。可以在下一次请求前估算费用并留出余量，但不能把预算阈值视为对最终账单的绝对保证。

最终应同时评估任务成功率、完成耗时和每项成功任务的成本。对重试设定合理边界，才能让可靠性提升与资源消耗保持可解释的关系。