批量任务可靠性：重试、去重、断点续跑

适合谁

• 批量调用 AI 接口时被 429、超时和偶发 5xx 打断过。
• 重跑整批任务时，担心重复扣费或写出重复数据。
• 任务跑到一半进程被杀，不知道哪些完成了、哪些没完成。

做完得到什么

• 一个只对可恢复错误重试、带退避和总时长上限的客户端。
• 一个校验模型输出、失败重试的壳，脏数据不落盘。
• 一张记录任务状态的表，支持去重、失败重试和断点续跑。
• 一套能解释“为什么失败、花了多少、还剩多少”的日志和查询方式。

三篇怎么配合

重试解决的是单次请求的抖动，json-guard 解决的是返回内容不可信，状态表解决的是整批任务的中断。先有重试，失败率会下降；再加校验，脏数据不会写进结果；最后补状态表，重跑才安全。三篇都做完，才算一条完整的可靠批处理链路。

后续可以加什么

• 按批次汇总成本，月底对账。
• 失败任务落盘后单独补跑。
• 多模型路由，主模型限流时自动降级。
• 任务优先级和并发上限，避免一个坏批次拖住所有工作。