批量任务特别容易出事的地方不是跑不动，是跑了一半。中断之后重跑，要么把已经做完的又做一遍，要么卡在某个中间态出不来。

一、先给结论

结论是：批量任务的稳定性靠三件事——分片、幂等、断点记录。把一批数据切成固定的片，每片只做一次并且做之前先落一条状态，中断后从状态点继续，而不是从头再来。企业级智能体自动化的批量场景大多日结或月结，跑一次要好几个小时，中断成本很高。

二、分片粒度：按业务主键切，不按数量均分

按数量均分看似公平，实际会出问题：某一片里集中了一个大客户的所有单据，这一片就是超长片。我们按业务主键切，同一主体的数据落在同一片，片内再按上限拆。单片大小设成 500 到 2000 条的区间，整批的总片数不宜超过 200 片，片数过多会让状态记录本身成为负担。并把超长片单独标记出来跟踪。分片表本身要落一份快照，中断后按快照重建切片，避免重跑时切法发生变化。

三、幂等：先落状态再干活

每片开始前先写一条状态记录，写成功才继续，处理完成后把状态改成完成。整个过程中，同一片重复执行不会产生额外的业务结果。这条约束看着简单，但它决定了中断之后能不能安全地重跑。顺序反过来，程序异常退出时状态没来得及写，重跑就会重复处理。

四、失败重试要分三级

其一，瞬时失败，网络抖动导致的，等待后重试，间隔从 10 秒起按退避增加，上限 5 分钟，次数上限 3 次。其二，数据失败，字段缺失或格式错误，重试没有意义，直接进异常队列。其三，业务失败，调用方明确返回拒绝，需要人判断，转人工队列。只有瞬时失败才自动重试。把三级混在一起自动重试，会把需要人介入的问题一直压在队列里，队列也难以出清。

五、我们踩过的三个具体坑

用"是否处理过"做去重判断。程序异常退出时状态没来得及落，重跑造成重复入账。改成先写状态再干活才解决。

重试不加分级。数据错误也重试，把队列堵到无法消费。分级之后队列积压明显下降。

只有全局开关。停了就不能再细化，某一片要单独重跑只能整批停。加上单片重跑之后，影响面收窄很多。

六、行业里已经跑到什么规模

日结量级的任务在一些集团里已经是可观测的常规动作。某能源化工集团公开的凭证文本日处理量在 1 万条量级；某大型产业集团公开的纳税计算从 30 分钟压到 3 分钟，涉及 500 个以上单位。这类任务一旦中断，业务侧当天就可能受影响。

七、怎么验证这套机制真的生效

单片平均耗时：反映分片是否均衡。

重试占比：瞬时失败占总片数的比例，长期偏高说明上下游不够稳定。

异常队列积压量：需要人工处理的片数，应当趋于收敛。

断点恢复成功率：中断后从状态点继续成功的比例。- 状态记录滞后时长：状态写入与实际的间隔，长期偏大会放大重复处理窗口。

这四项里，断点恢复成功率是硬指标，它直接决定中断会不会演变成事故。

检查清单
分片是否按业务主键切，而不是按数量均分。

每片是否先落状态再执行。

失败是否分瞬时、数据、业务三级处置。

是否支持单片重跑，而不只有全局开关。

是否跟踪超长片并单独处理。