Agent 一直重试怎么办：给任务、工具和异步作业设置截止条件

任务截止限制用户愿意等待的总过程；工具超时限制某次调用的等待。检索、模型、多个工具和重试都会消耗总预算，不能让每一步都独立使用完整任务时间。

例如教学任务总预算为 60 秒，前面已用 45 秒，就不应再开始一个可能等 30 秒的调用。实际时间按业务需求和依赖性能制定，保留收尾记录与状态返回的余量。

超时只说明调用方没有及时获得结果。外部服务可能已经执行，也可能继续运行；尤其是业务写入，要按标识查询当前状态，不把 timeout 转换成确定失败。

AWS 的重试指导指出多层重试会放大请求，并建议限制次数或总时间、采用退避与抖动。先查 SDK、HTTP 客户端、工作流引擎和 Agent 各自是否重试，明确哪些错误由哪层处理。

可以让工具封装层处理符合合同的短暂网络故障，Agent 收到明确结果后再决定任务下一步。不要让模型重复调用同一错误工具，同时底层继续自动重试。

优先理解现成客户端的重试能力与默认行为，再增加必要逻辑。重复包裹“更可靠”的重试器，可能增加负载与恢复时间。

服务返回的 HTTP 状态只是线索，还要看平台合同。某些错误的可恢复性与最终一致性有关，不能只按所有 5xx 重试、所有 4xx 不重试写成通用规则。

退避让连续尝试之间等待更久，减轻持续压力；抖动避免大量任务在同一时间再次请求；次数与总预算防止无限积压。三者应一起受任务剩余预算约束。

等待期间任务可被取消或授权条件可能改变，下一次调用前检查当前状态。重试间隔不是“越长越安全”，过长可能拖过业务处理窗口，过短又可能加剧负载。

记录每次尝试原因和累计耗时。用户看到“处理中”时，维护者应能判断是在等待队列、等待外部作业还是重试工具，避免所有状态都变成不可解释的转圈。

长时间分析、批量处理或外部任务可以先返回作业标识，再提供查询当前阶段与结果的入口。受理不等于完成，轮询也要设置间隔、次数与截止条件。

定义 pending、running、completed、failed 和 cancel_requested 等状态的含义，具体命名由系统决定。取消请求发出后，只有外部服务确认停止，才能声称已取消；已经发生的动作仍要核对。

作业标识要与身份绑定，不能让知道标识的人读取别人的内容。重复回调或状态查询使用幂等处理，终态不应被迟到的旧事件随意覆盖。

说明已经完成的部分、仍未确认的部分和下一步。只完成资料检索，就不要显示“业务处理完成”；已受理写请求但状态未知，返回可查询标识并进入接管或后台核对。

对于没有副作用的研究任务，可以返回部分结果与来源覆盖限制；对于写任务，优先说明业务状态和是否允许继续操作。不要用一段流畅总结掩盖未完成步骤。

保存必要检查点，但不能假设进程恢复会自动处理外部状态。恢复前再次检查权限、版本、预算和作业结果，过期任务可以停止，而不是重新从头执行。

测试取消时同时观察等待连接、内部队列和外部作业。取消本地等待后，队列中尚未开始的动作应按约定阻止；已经提交给外部平台的动作需要查询确认。若平台不支持取消，明确说明本地已停止等待，外部作业仍可能继续；只有确已提交取消请求时，才显示“已请求停止，结果待确认”。不能仅因为前端按钮变灰就宣称业务已经停止。

本文适合带多步工具调用的 Agent 和工作流。预算设计不能消除底层故障，但能限制等待、费用和负载扩散。生产参数应依据实际时延与任务价值制定，并持续观察。