失败重试并不等于把同一个动作重复执行几次。若工作流已经成功创建联系人，只是在返回结果时网络中断，系统再次提交请求，就可能产生重复联系人、重复通知，甚至重复扣款。真正可靠的设计目标，是让同一条业务事件被重复处理时，最终结果仍然保持一致。

先区分“失败”发生在哪里

一次自动化执行通常包含读取线索、判断条件、写入客户管理系统和发送提醒等步骤。重试前必须确认失败类型：连接暂时不可用，通常适合重试；字段格式不匹配、权限不足或业务规则拒绝，则应停止并进入失败处理。对已经产生外部副作用的步骤，不能仅凭“请求超时”判断执行失败，因为服务端可能已经完成操作，只是响应没有返回。

因此，重试策略应与执行状态绑定，而不是简单重复整条流程。每一步至少要记录执行时间、状态、错误详情和流程标识。日志显示某一步已成功时，恢复流程应从后续步骤继续，而不是从触发器重新开始。

用幂等性控制重复动作

避免重复执行的核心是幂等性：同一业务事件无论提交一次还是多次，都不会产生多份结果。线索建档可以使用稳定的业务标识作为去重依据，例如表单提交对应的流程标识，或由来源和提交记录组成的唯一键。写入客户管理系统前，先检查该标识是否已经处理；已处理则跳过创建，未处理才执行写入。

发送提醒也应单独记录发送状态。不能因为建档步骤成功，就默认提醒步骤也成功；同样，提醒失败重试时，也不应重新创建联系人。将“建档”和“通知”拆成可独立恢复的步骤，比整条工作流反复执行更安全。

让重试有边界

对于暂时性接口故障，可以采用有限次数和间隔重试，例如资料中提到的重试三次、每次间隔五分钟。重试耗尽后，应把线索移入待处理列表并发送错误通知，而不是无限循环。上线前还要用空字段、特殊字符和字段超长等边界数据测试，确认重复提交、超时响应和部分成功都能被日志准确识别。

可靠的自动化不是“失败后多试几次”，而是具备唯一标识、分步状态、幂等写入和人工兜底。只有先判断动作是否已经发生，再决定是否重试，自动化才不会把一次故障放大成多次业务操作。