TL;DR —— 自动重试只适合短暂、可恢复、再次执行不会扩大损失的失败。账号权限、设备环境、素材版本和任务参数没有变化时，重复三次通常只会制造三次同样的错误。真正聪明的自动化，不是永远继续，而是知道什么时候应该停下来交给人判断。
先区分可恢复故障和必须调查的故障
任务失败后立即重试，看起来像最合理的效率设计，因为短暂超时、服务瞬间不可用或网络抖动确实可能在几秒后自行恢复。但“失败”只是结果，不是原因；如果系统把所有失败都当成网络问题，就会用同一种动作处理完全不同的情况。具体来说，一批 50 个账号中有 12 个失败，其中 2 个是服务超时，间隔 60 秒重试可能成功；4 个是账号权限已经失效，再试 10 次也不会恢复；剩下 6 个集中在同一设备组，说明更可能是共同环境或配置出现变化。假设系统对 12 个任务统一自动重试 3 次，日志会新增 36 条失败，负责人反而更难看清第一次异常发生在哪里，设备组里的任务还可能继续影响同组账号。可恢复故障通常有三个特征：持续时间短、关键条件没有变化、再次执行不会改变账号或内容状态。不可恢复故障则需要新的信息或人工动作，例如重新授权、替换错误素材、确认账号状态或检查批次配置。判断自动重试是否安全，不能只看“以前偶尔能成功”，还要问重复执行会不会产生重复发布、错误覆盖、更多登录尝试或更大的影响范围。系统如果看不见这些差异，自动重试就不是效率功能，而是错误放大器，只是把问题从一次失败变成一串更难解释的记录，也让真正需要人工处理的异常被噪音淹没。
失败的任务不会因为再执行一次，就自动变成正确的任务。
重试策略必须同时写明条件、次数、间隔和停止方式
一个可用的重试规则至少包含四项：哪些错误允许重试、最多重试几次、两次之间等待多久、达到什么条件后必须停止整个批次。比如服务超时可以在 60 秒和 180 秒后各重试一次；素材缺失、账号权限不足和设备不可用则直接暂停，不进入自动重试；同一批次如果 10% 的账号出现相同错误，系统应停止后续任务并通知负责人，而不是继续把问题扩散到剩余账号。具体还要保证每次重试前重新检查关键条件，例如素材版本是否仍然有效、账号是否被人工暂停、代理或设备是否已经更换，不能拿任务创建时的旧状态继续执行。重试成功也不能覆盖第一次失败，两个结果都要保留，否则团队只能看到最终完成，却不知道系统曾经在什么条件下出现风险。管理者每周可以抽查前 20 个重试任务，区分其中多少属于真正的短暂故障，多少其实需要人工判断；如果后者比例持续超过 30%，说明错误分类或任务前检查需要改进，而不是继续提高重试次数。Ainnc 的任务记录可以帮助团队定位失败发生在哪个账号、环境和步骤，但策略本身仍然需要团队根据风险决定。自动化最有价值的地方不是替人不停点“再试一次”，而是把可恢复的小波动自动处理，把需要责任和判断的异常尽早、完整地交给人。
设置重试规则时检查
- 只允许明确的短暂故障进入自动重试。
- 每次重试前重新检查账号、环境、素材和暂停状态。
- 同类错误达到批次的 10% 时自动停止后续任务。
- 第一次失败、每次重试和最终结果必须全部保留。