OpenClaw 工作流上线后，失败是迟早会发生的。网页超时、接口限流、文件读取失败、模型输出格式不对，都很常见。真正拉开差距的不是永远不失败，而是失败以后能不能稳稳恢复。
这里最容易被忽略的是幂等设计。简单说，同一步任务即使被触发多次，也不应该造成重复副作用。前面讲 定时任务 和 人工确认节点 时都提到过，高风险动作不能随便自动跑；失败重试就是这条原则的执行层。
先分清哪些步骤能重试
查询资料、读取表格、生成草稿，一般可以自动重试。发送邮件、删除文件、修改权限、写入 CRM、发布文章，就不能简单重试。它们一旦成功执行，再跑一次可能就变成事故。
所以工作流设计时，最好给每个节点标一个风险级别：read、draft、write、external_send、destructive。低风险节点可以自动重试，高风险节点要检查执行标记，必要时进入人工确认。
给关键动作加幂等键
幂等键可以理解成这次动作的身份证。比如给某个客户发送某封跟进邮件，可以用客户 ID、邮件模板 ID、任务日期组成一个 key。执行前先查这个 key 有没有成功记录，有就不再发送。
这个方法特别适合 销售线索整理、会议行动项同步 和内容发布类任务。只要会改变外部状态，就应该考虑幂等键，而不是只靠模型“记得别重复”。
失败日志要记录到步骤级
很多工作流失败后只留一句“执行失败”，这对修复没有帮助。更好的日志应该记录节点名称、输入摘要、工具参数、外部返回、是否可重试、已经重试几次、下一步状态。
这样配合 日志复盘，团队就能判断该改提示词、改工具、改超时时间，还是把某一步改成人工确认。
重试次数不是越多越好
如果接口限流，短时间狂重试只会让问题更严重。可以采用退避策略：第一次等几十秒，第二次等几分钟，第三次进入人工处理。对外发送类动作，默认不要自动重试，除非能确认上一次没有产生副作用。
还有一种情况要特别注意：模型输出格式错误。与其无限让模型重写，不如先做结构化校验，失败后给出明确错误，再让它只修那一段。
总结
OpenClaw 失败重试不是简单地“再跑一次”。真正可靠的设计，要区分可重试和不可重试步骤，给关键动作加幂等键，记录步骤级日志，并把高风险动作交给人工确认。这样自动化工作流才不会在失败恢复时制造新的问题。
