智能助手重试不要让一次失败演变成一场风暴调用模型服务遇到超时或限流时重试是合理手段把每次失败都无条件重试则很容易把短暂波动变成积压、账单和更长的恢复时间。尤其在多个 worker 同时工作时每个实例各自做指数退避可能会在同一时刻再次请求上游让原本已经紧张的服务承受更大压力。所谓止损线不是给所有接口写同一个“最多三次”。它应该回答几件事这个任务还剩多少时间和费用预算失败类型是否有机会自行恢复重试会不会重复产生副作用当前上游是否已经处于不适合继续施压的状态。先把失败分成可处理的类别网络中断、连接建立失败、临时服务不可用有时值得重试。前提是请求还在用户可接受的等待时间内并且任务没有执行不可逆动作。限流响应也不能机械处理有明确的等待提示时应遵守提示没有时可有限地退避但不能让每个任务无限排队。参数错误、权限错误、内容被策略拒绝、结构化结果不合法通常不会因为等待而变好。对于这类失败重试只会浪费配额并掩盖真正需要修复的输入或配置。调用方应记录可诊断的错误类别并给出下一步动作例如修正请求、改走人工处理或返回安全的降级结果。模型输出解析失败处在中间地带。若确认是传输中断造成的半截响应可以尝试一次受控重试若模型反复不遵守协议则应停止并触发更严格的格式约束或人工检查。不能把“解析失败”统统当作网络错误。预算要在请求之前就被看见一次任务可同时受到总等待时间、尝试次数、Token 估算和费用上限约束。请求进入队列时先预留一部分预算完成后根据实际用量结算预算不足则不要启动下一次调用。这样系统会在还可控时降级而不是等到供应商拒绝才发现已经超限。预算应有层次。单个请求的上限保护一位用户或一项任务队列或租户级上限避免某一类流量吃掉全部资源全局上限用于应对异常放量。具体数值取决于产品和合同不应写死在业务函数里。将它们集中配置并记录每次拒绝的原因后续才能调整。超时也不是越长越好。用户正在等待的同步交互时间预算通常比后台批处理短后台任务可以等待更久却仍要有最终结束状态。任何重试都应继承剩余 deadline不能每次重新获得一整段超时。幂等决定了能不能安全重试只读查询通常更容易重试写入、发消息、执行工具或修改外部系统则不同。客户端超时并不表示服务端没执行如果重试又提交一次可能产生重复扣款、重复消息或两次状态变更。为有副作用的任务生成稳定的幂等键并让执行端据此识别重复请求。状态记录应能表达“已接受、执行中、成功、失败、未知”等阶段。遇到超时且结果未知时优先查询任务状态而不是立即重新执行。没有幂等语义的工具调用不应因为一次网络错误被自动放大。模型驱动工具时还需要区分“模型重新回答”和“工具重试”。前者可能给出不同计划后者可能重复执行同一动作。两者都应被任务状态机约束不能只依赖聊天记录中的文字判断。退避、熔断和降级要协同工作退避应加入随机抖动避免大量任务在相同间隔后同时苏醒。等待期间必须响应取消信号用户离开页面或上游任务被撤销后继续占着队列毫无意义。重试次数达到上限、deadline 到期或预算耗尽都要结束任务并释放资源。若一段时间内相同上游错误持续增加可以暂时打开熔断。熔断打开时新请求不再盲目进入失败路径而是快速返回可解释的降级结果例如缓存答案、规则提示、稍后处理的队列状态或明确的服务不可用说明。恢复不能只靠计时器也要通过少量受控探测确认上游真的可用。不要把降级理解成掩盖错误。它应该让用户知道当前能力的范围并让系统保留追踪线索。比如只返回检索到的资料而不生成总结往往比返回一个看似完整但来源不明的答案更诚实。用故障注入验证边界上线前可以在测试环境模拟连接超时、限流、响应半截、非法结构和工具执行后断连。关注的不是日志是否“漂亮”而是任务最终是否只有一个清晰状态预算耗尽后是否真的不再发请求取消是否能终止等待熔断是否能阻止队列继续堆积。同时记录尝试次数、累计等待、预估与实际用量、错误类别和最终处理方式。日志中避免保存不必要的用户原文和敏感参数用任务标识关联即可。复盘时这些记录能回答重试到底挽回了多少任务又在什么情况下只是在制造额外压力。重试本身不等于可靠性。可靠性来自对失败的区分、对资源的限制、对副作用的幂等保护以及在不能继续时果断结束。把这些边界写进系统智能助手才不会在服务最脆弱的时候反复给自己和上游加压。