跳到主要内容

重试与失败处理

活屏幕上的自动化失败得频繁而正常：动画还在放、网络调用慢、对话框晚到。把每次波动都当崩溃的流程没法用；把一切永远重试的流程更糟。

本页讲处理失败的三件工具，以及——更重要的——每件工具何时是错误选择。

目的​

读完本页，你看着一个失败的步骤就能说出它需要哪个：

  1. 更长的超时——那东西会来，只是晚点。
  2. 失败连线——屏幕处在另一种状态，走另一条路。
  3. 重试策略——操作确实失败了，重复可能成功。

选错就是流程变慢、变飘、或两者兼备的原因。

重试是节点属性，不是节点​

没有"Retry"节点。重试是附在节点上的策略，在 Properties 面板配置。

{
  "maxAttempts": 3,
  "retryOn": ["failure", "timeout"],
  "backoffMs": 500,
  "backoffMultiplier": 1.5,
  "captureScreenshotPerAttempt": true
}

每项设置​

设置类型范围默认含义
maxAttemptsinteger1–20—含首次的总尝试数
retryOnlistfailure、timeout—哪些结果可重试
backoffMsinteger0–60000—下次尝试前的等待
backoffMultipliernumber1–10—每次把等待乘以此数
captureScreenshotPerAttemptboolean—false每次尝试存一张截图

maxAttempts: 3 是总共三次尝试，不是一加三。

backoffMs: 500、backoffMultiplier: 1.5 时，等待依次为 500 ms、750 ms、1125 ms。

永不重试的东西​

retryOn 只能含 failure 与 timeout。schema 拒绝其余，理由充分：

  • fatal 永不重试。 它意味着配置或系统错误——坏表达式、非法区域、设备断连。重复产生一模一样的错误。
  • success 永不重试，包括报告"未找到"的检测（其状态为 success）。
  • cancelled 永不重试。 用户停止了运行。
最常见的重试错误

给 Find Image 加重试策略想"找得更狠"毫无作用。

未找到模板的 Find Image 返回状态 success、路由 failure。重试只在状态 failure 或 timeout 时触发。策略永不点火。

想找得更狠，提高 timeoutMs——节点本来就在每个轮询间隔重新截图重新匹配。那就是检测的重试环。

一次尝试的生命周期​

图中导出的两条规则：

  1. 参数错误发生在重试之前。 坏的 {{变量}} 是 fatal，永不重试。
  2. 输出映射恰好运行一次，作用于最终尝试的结果。重试三次的节点写一次变量。

超时与退避​

  • 节点的 timeoutMs 是每次尝试的超时，不是整个节点的。5 秒超时、3 次尝试的节点可能花 15 秒尝试再加退避。
  • 退避不算进单次尝试的超时。
  • 退避算进流程的 maxRuntimeDurationMs。

三件工具，各自的用武之地​

1. 提高超时​

用于你等的东西终将出现、只是不知何时。

检测节点轮询：截帧、匹配、睡一个间隔、重复直至超时。更长的超时就是更多次尝试。

Claim 按钮在 2 秒动画后出现。 → Find Image，timeoutMs: 4000，pollIntervalMs: 250。

2. 接失败连线​

用于"不在"意味着屏幕处于另一种合法状态、你想做别的事。

有时有每日奖励弹窗，有时没有。 → Find Image 弹窗，Success → 关掉，Failure → 继续。

这是分支，不是错误处理。三件工具里它最常用也最被冷落。

3. 附加重试策略​

用于操作确实失败且重复可能修复：输入被拒、截帧抖动、瞬时设备错误。

UI 未稳时点击偶尔被吞。 → Click，maxAttempts: 3，retryOn: [failure, timeout]，backoffMs: 400。

决策表​

情形工具原因
按钮在动画后出现更长超时它在路上
弹窗可有可无失败连线两种合法状态
屏幕偶尔加载慢更长超时同一状态，更晚
点击偶尔不生效重试策略操作失败
表达式引用缺失变量都不是fatal——修配置
OCR 偶尔读错验证环见下

验证模式​

凡是要紧的事，别假设操作成功——去查。

它比重试更强，因为确认的是结果，不是调用。为本文档研究的参考自动化用的正是这个形状：操作、稳定、验证，验证不过就干净地跳过。

注意操作与验证之间的 Wait。没有它，验证读的是操作前的帧。见流程解剖的 frameSync。

护栏与失败的互动​

运行时在全程追踪连续失败：

  • failure 与 timeout 递增计数。
  • success 清零。
  • 越过 maxConsecutiveFailures 则以 fatal 终止。

由于检测"未找到"带 success 状态，长时间一无所获的轮询环不会引爆这道护栏。只有真正的操作失败会。

设计干净的失败路径​

给每个流程的坏情形一个明确、刻意的收尾。两个终止节点通常够了：

在失败 Stop 上写 message。那串文字就是你凌晨两点读到的运行日志，"Max Slot Troop" 比一个节点 id 有用无穷倍。

流程作为 Sub Flow 时，这些 Stop 就是它的返回值——父流程在子的 Success 与 Failure 端口上分支。

最佳实践​

  • 每个失败 Stop 都写 message。 那是你的日志。
  • 有副作用的事，验证优于重试。
  • maxAttempts 保持小——2 或 3。三次治不了的十次也治不了。
  • 凡涉设备皆配退避。 立即重试通常撞进同一个忙碌状态。
  • 永不重试 fatal。 你做不到，而想做说明配置错了。
  • 接上每个 Failure 端口，哪怕只到一个 Stop。空路由让运行以 TRANSITION_NOT_FOUND 终止。
  • 调试时开 captureScreenshotPerAttempt，完了关掉——它每次尝试写一张图。

性能笔记​

  • 重试把节点最坏耗时乘上 maxAttempts 再加退避级数。5 秒超时、3 次尝试、500 ms ×1.5 退避，一个节点最多约 16 秒。
  • 检测宁可单次更长超时也别多次重试：单次尝试内的轮询没有退避开销、不重复启动成本。
  • captureScreenshotPerAttempt 每次尝试写图——真实 I/O。生产流程关闭。

内存笔记​

  • 每次尝试都被记日志；开 captureScreenshotPerAttempt 时每次尝试都存工件。重试激进的长运行产出大的运行文件夹。
  • 只有最终尝试的结果记入 nodeResults，重试不放大上下文的内存占用。

常见错误​

错误实际发生修复
Find Image 加重试想"找得狠"策略不点火提高 timeoutMs
maxAttempts: 1 以为有一次重试那是零重试一次重试用 2
重试 fatal不可能修配置
操作与验证间无等待验证的是旧帧插 Wait
Failure 端口空着运行以 TRANSITION_NOT_FOUND 终止至少接个 Stop
失败 Stop 无消息日志读不懂写明原因
慢节点配巨大 maxAttempts运行撞时长上限少尝试、真分支

故障排查​

我的重试策略从不运行。 节点在返回 success 状态（检测未找到）或 fatal。只有状态 failure 与 timeout 可重试。

运行死于 MAX_CONSECUTIVE_FAILURES_EXCEEDED。 有东西反复失败、中间没有成功。检测的未找到不会造成——去查操作节点。

节点耗时远超它的超时。 超时按次计。乘上 maxAttempts 再加退避。

被重试节点写的变量看着不对。 它们只来自最终尝试。设计如此。

流程立即失败，报 PARAM_EXPRESSION_INVALID。 参数里的 {{变量}} 解析不了——通常未声明或拼错。这是 fatal，发生在任何重试之前。

FAQ​

能重试一整组节点吗？ 不能直接。放进 Sub Flow 然后在它的 Failure 上分支，或用计数器搭显式循环。

退避算进节点超时吗？ 不算——但算进流程的 maxRuntimeDurationMs。

maxAttempts: 3 是三次重试还是三次尝试？ 三次尝试总计：首次加两次重试。

该给所有东西都配重试吗？ 不。多数飘忽用更长超时或真正的分支解决得更好。

相关页面​