RPA 机器人卡死通常不是单一故障，而是元素定位不稳、等待策略缺失、异常无人接管三件事叠加。要解决它，先要区分：是页面结构变了、是加载时序没处理好，还是流程本身没有失败的出口。选方案前把失败点定位清楚，比直接加长等待时间更有效。
下面按「场景 → 候选方案 → 代价与边界 → 决策建议」组织。需要结合自有系统改造时，可以参考软件定制开发与系统集成服务的做法。
RPA 页面元素变化导致定位失败，先选哪条路
常见现象是按钮位置挪动、弹窗文案改动、列表多了一列，脚本仍在找同一个元素。候选大致有三类。
方案一：强化选择器与稳定属性定位
用文本、XPath、稳定属性组合，减少对坐标与索引的依赖，优先锚定业务含义明确的容器。
- 优点：改动小，不依赖外部配合，能在短时间内降低偶发失败。
- 代价：选择器越绕越脆，跨版本升级后仍需人工重跑维护。
- 边界：适合页面迭代节奏较慢、内部可控的系统；对前后端偶发重构的页面只能缓解。
方案二：推动系统提供稳定标识或测试钩子
和业务系统团队约定固定的元素标识，或在页面上预留可供自动化识别的稳定属性。这是最根治的做法，但需要跨团队排期。
- 优点：定位长期稳定，脚本生命周期明显拉长。
- 代价：需要研发配合与版本发布；对外部购买的 SaaS 系统一般难以推动。
- 边界：适合自有 B/S 管理系统，改造前需要通过需求评审并落进版本计划。
方案三：视觉识别或图像匹配兜底
在 DOM 定位之外补充图像比对，作为最后兜底。
- 优点：对部分渲染差异不敏感，可覆盖跨端场景。
- 代价：受分辨率、缩放比例、字体与主题色影响，稳定性依环境而定，误判时需要人工判断。
- 边界：适合同一固定终端运行，不建议用于多变分辨率或多浏览器环境。
决策建议：自有系统优先走方案二，外部系统以方案一为主，视觉识别只作为兜底且需要配合人工核对。相似场景在同类项目案例中有过处理。
什么情况下不要选择重试机制来救场
重试很容易被当成万能药，但有几种情况加强重试只会掩盖问题、拖长单笔处理时间，甚至把一次差错放大成批量差错。
- 该步骤本身具有写操作且结果不确定：重复点击提交、重复扣款、重复下单，重试前必须先确认幂等或做状态查询。
- 错误原因属于权限、账号锁定、审批状态未流转：这类是业务态问题，重试一万次也过不去。
- 失败原因属于流程前置数据缺失：如主数据没同步、编码不存在，应该在流程入口做校验而不是循环重试。
- 异常原因不明且无法断点续跑：手工重试容易从头跑一遍，产生重复数据。
判断标准很朴素：先问这一步重新执行一次会不会产生第二个结果。若答案是会，就先设计前置查重与状态核对，再谈重试策略。
异常捕获与重试机制怎么设计
一套能跑的 RPA 流程，设计重点在异常分级与人工兜底，而不是把所有异常都当成可重试。
先做异常分级
- 可瞬时自愈型：网络抖动、加载慢、页面偶发空列表。适合短间隔有限次重试。
- 可恢复但需重跑步骤型：登录态失效、页面结构变化后元素定位方式失效。建议重新登录取页面快照，并对元素重新定位。
- 不可自愈型：权限不足、审批未通过、数据不合规。直接转人工处理并记录原因。
- 需终止整条流程型：连续失败、关键数据缺失。应将任务挂起，保留上下文与截图，通知责任人。
分级之后，重试策略才有依据：重试次数、间隔要按业务容忍度来定，退避策略比固定间隔更能对抗瞬时拥塞，但要设总时长上限，避免任务长期占住机器。
设计几个固定动作
- 每一步开始记录上下文：流程名、步骤、关键入参、页面截图或结构化日志。
- 异常发生先做状态核对，再决定重试或人员介入。
- 断点续跑以「任务状态 + 处理结果」为准，不以「步骤序号」为准。
- 为流程加上运行中的心跳或超时监控，任务似乎无异常但长时间无输出时自动上报。
这些动作同样适用于系统集成场景，具体做法见服务范围与交付流程。
常见卡死位置与对应处理
- 等待某个元素出现，实际上页面已加载但文案变了：定位改为文本模糊匹配或改用作业务含义明确的稳定属性。
- 依赖固定时长的等待：替换为显式等待页面状态或元素可见。
- 弹窗、遮罩没被处理：让流程在到达主流程前统一做一次页面状态检查。
- 权限被其他机器人抢占或账号互踢：接入统一的账号资源管理。
自查清单与上线前检查项
- 是否列出流程中最容易变化的页面元素清单，并明确了各自的定位策略。
- 写操作步骤是否做过重试安全评估，重复执行会不会二次入账。
- 每次重试是否带上下文证据，失败后能否在不看录屏的情况下定位。
- 是否配置了总超时与无输出告警，避免静默等待。
- 人工介入的任务是否有清楚通知与恢复说明。
- 页面改版后，从上线到发现异常的时间是否明确可控，例如加上每日冒烟任务。
- 登录态、权限变更是否纳入运行监控，不仅依赖测试环境验证。
文字版方案对比清单
- 稳定选择器 + 文本 XPath → 适合外部系统与自有系统并行维护期 → 主要代价是脚本易变、需重跑维护。
- 系统侧提供稳定标识或测试钩子 → 适合自有 B/S 管理系统 → 主要代价是跨团队排期与版本配合。
- 视觉识别兜底 → 适合固定终端、渲染差异场景 → 主要代价是环境依赖强、需人工核对误判。
- 有限次退避重试 + 人工兜底 → 适合健壮的业务自动化流程 → 主要代价是设计复杂度上升与任务挂起处理成本。
- 只加长等待时间 → 适合临时排查 → 主要代价是拖慢整体任务、掩盖真实问题，不建议长期用。
流程能否稳定，本质取决于元素定位的基础是否可靠、异常出口是否设计完整。业务涉及 OA 或其他管理系统、需要改造页面或补齐状态接口时，可先看更多项目案例了解落地经验，或直接联系我们梳理具体步骤。
