UiPath 自动化工程化实战：选择器稳定性、事务模型与异常分流的三道防线

不少 UiPath 项目有同一个生命周期：POC 两周跑通，演示会上效果好，上线三个月后运维群里开始天天有人问"机器人怎么又停了"。这时候回头看流程设计，往往挑不出大毛病，问题全散在一些当时不起眼的取舍上。

把自动化做成产品，差的不是建模，是工程。这篇把三件事讲透：选择器怎么做得抗震、REFramework 为什么值得用、异常怎么分流处理。顺带说一下 2026 年平台侧新增的那些能力，哪些是真能省事，哪些只是换个地方维护。

一、机器人为什么会"上线即巅峰"

POC 阶段的数据是 clean subset：样本干净、界面稳定、只跑几十条。上线之后进来的是全量数据、多个业务人员的操作习惯、不定期更新的业务系统版本。故障会长这样：

故障类型	典型表现	根因	该谁处理
界面变了	报 SelectorNotFoundException，元素找不到	业务系统改版、动态属性、分辨率不同	开发侧：选择器策略
数据脏了	某几条数据处理失败，其余正常	必填字段为空、金额超审批阈值、客户不存在	业务侧：规则与数据治理
环境抽了	应用崩溃、登录失败、网络超时	会话过期、并发抢占、服务抖动	运维侧：重试与告警

这三类故障的处理方式完全不同：界面的问题要改选择器或加自愈，数据的问题应该标记后跳过交给业务，环境的问题才需要重开应用再来一次。把它们一律塞进"报错就重试"，是很多项目的通病：一条脏数据被反复重试几十遍，真正的环境故障反而被淹没在日志里。

二、选择器：投入半小时，省掉几百次救火

2.1 录制出来的选择器几乎一定要改

UiPath 录制器的目标是"当下能用"，所以倾向把所有能抓到的属性都塞进去，包括随机数 id、带时间戳的页面标题、以及 idx 序号。这些属性在开发环境稳定，换个账号登录、换个环境部署、甚至业务系统发个小版本，它们就变了。

举个例子。下面是录制出来的样子，改完之后是另一个样子：

# 录制出来的：，id 里带随机数，page title 里含录制时间
<webctrl tag='INPUT' id='txtOrder_1748329155432' parentid='form1' />
<html title='订单查询 - 2026-09-12 14:23:07' />

# 改过之后：改用语义属性，抖动部分用通配符并前后锚定
<webctrl tag='INPUT' aaname='订单编号' parentid='form1' />
<html title='订单查询 - *' />

这个改动花不了几分钟，但它是"这台机器人能不能撑过三个版本更新"的分界线。

2.2 四条改法

• 换稳定属性。优先用 aaname、name、innerText 这类带语义的属性，避开自动生成的 id 和 idx。金融类流程里把 id 换成 aaname 之后，一大半莫名其妙的失败会直接消失。
• 通配符配前后锚定。* 匹配任意长度字符串，? 匹配单个字符。注意别让它太泛：title='*' 这种全通配等于没写，容易匹配到别的窗口。改完之后用 UI Explorer 的 Validate 验一遍。
• idx 只在值很小的时候用。值为 1 或 2 尚可接受，一旦变大就说明该换思路了。确实躲不开 idx 时，把它限制在有稳定属性的容器内，缩小依赖范围。
• 属性值全是通配符的属性，直接删。它不提供任何区分度，只增加出错面。

如果属性值的变化有规律，比如 client-ID-12345 只有末尾数字在变，用正则比堆多个通配符干净，在 selector 里启用 matching:name='regex' 即可。

2.3 锚点与相对定位：表格行的解法

当目标元素本身的属性不可靠，但它在某个稳定元素旁边时，用 Anchor Base 或 Find Relative Element，把它锚定到一个静态标签上，再按相对位置（左/右/上/下、偏移距离）去找。

表格里的"处理"按钮几乎没有稳定的 id，但同一行的"订单号"是稳定的。以订单号为锚点找同行按钮，比试图给按钮本身编选择器可靠得多。位置关系不变、属性变了，选择器依然成立。

2.4 完整选择器还是部分选择器

完整选择器从顶层窗口一路描述到目标元素；部分选择器只在 Attach Browser / Attach Window / Open Application 这样的容器内部生效。推荐用容器加部分选择器，理由有四个：

• 同一个应用开两个实例时，容器是把活动区分开的可靠办法。
• 顶层窗口变了只需改一处。
• 不用每次操作都重新找顶层窗口，速度略好。
• 把同一应用上的活动从视觉上分组，后期维护更容易。

2.5 什么时候该认输

有些场景选择器就是不合适，别硬磕：

• Citrix / VDI 虚拟桌面。机器看到的是像素流而不是 DOM，标准选择器基本失效，改用 Computer Vision 活动（CV Click、CV Type、CV Get Text）或图像自动化。更省事的办法是请 Citrix 管理员把 hosted app 的 accessibility 打开。
• 图像匹配对分辨率敏感。Citrix 环境中的分辨率不应低于录制工作流时的分辨率，否则匹配率会明显下滑。
• 界面本身每周都在改。这种情况下花在维护选择器上的成本，多半高于换成 ScreenPlay 这类自然语言描述的方式。

2.6 先判断再操作，而不是事后重试

用 Element Exists、Wait Element Vanish、Check App State 做前置判断，配合合理的 TimeoutMS 与 DelayBefore，比"点了再说、报错再重试"稳得多。等待元素的状态要比等待固定秒数好：页面慢的时候不会不够用，页面快的时候也不会白白浪费时间。

实在要包 Try Catch 时，别把 Catch 留空。空 Catch 是"机器人停了但没人知道为什么"这类事故的主要来源。

2.7 上线前的自检清单

• 每个 UI 活动的选择器都用 UI Explorer 的 Validate 过一遍，Highlight 确认匹配到的是目标元素。
• 检查有没有残留 id、idx、时间戳类属性。
• 通配符是否足够具体，会不会误匹配到邻近元素。
• 多开一个应用实例，验证容器加部分选择器是否还能区分。
• 用非开发账号、非开发环境跑一遍，这是最容易暴露问题的一步。

三、REFramework：把"能跑"变成"能长期跑"

3.1 为什么 For Each Row 撑不住规模化

小机器人用 Sequence 加 For Each Row 加 Try Catch 完全够用。但流程一旦进入日常生产，三个问题会集中爆发：

• 一处崩，整批瘫。某一行数据处理出错导致异常抛出到外层，后面几百行全都没跑。
• 失败不可逆。没有每个数据的状态记录，跑崩之后只能从头再来，已经处理过的还得担心重复。
• 进度不可见。跑到第几条、成功多少、失败多少，全靠看日志数。

REFramework 就是把这三件事做成默认能力的模板：每条交易独立处理、状态写回、失败可重跑。

3.2 四个状态各自负责什么

状态	职责	说明
Init	读配置与资产、登录应用	系统异常后回到这里重开应用，拿干净状态
Get Transaction	取一条待办数据	取自 Orchestrator 队列或本地 DataTable
Process	处理这一条	业务逻辑几乎都写在这个对应的 workflow 里
End	关闭应用、发送总结	干净退出

这里有个容易被忽略的设计：系统异常之后，REFramework 的默认路径是回到 Init 重开应用，而不是原地重试同一个操作。背后的判断很实在，多数系统异常意味着机器人当前处在一个不干净的状态（浏览器卡了一半、应用处在未知页面），原地重试多半还会失败。

3.3 Config.xlsx 的三张表

表	放什么	举例
Settings	常规配置	OrchestratorQueueName、邮件通知人
Constants	技术常量，很少变	MaxRetryNumber、各类 Timeout、列索引
Assets	Orchestrator 资产名	凭证、URL 等敏感或常变的值

外部化的收益在日常运维里最能体现：改一个超时阈值不需要重新打包发布；Dev、UAT、Prod 用不同的配置；业务同事也能改部分值而不用走开发流程。反过来，把文件路径、超时、邮箱硬编码在 workflow 里，每次调整都要过一遍发布流程，成本会在半年后集中体现出来。

3.4 Orchestrator 队列的价值

同样是把交易一条条跑，队列比本地 DataTable 多出四件事：

• 状态可见：待处理、处理中、成功、业务失败、应用失败，一眼看到分布。
• 可分摊：多个机器人同时消费同一个队列，吞吐量可以横向扩。
• 可重跑：失败的单条单独拎出来重跑，不用整批重来。
• 可携带数据：每条 Item 能挂 Progress、Reference、Output 字段，便于和业务单据对账。

3.5 异常分流：这一步决定维护成本

异常类型	代表含义	正确动作	重试
BusinessRuleException	数据本身有问题	标记 Failed（Business），写清原因，处理下一条	不重试
Application / System Exception	环境或应用出问题	截图记录，回到 Init 重开应用后再试同一条	重试至上限

判断标准很简单：重试一次会改变结果吗？订单编号缺失，重试一百次还是缺失；而应用没起来，重试一次大概率就好了。前者是业务的账，后者才是机器人的账。

业务异常那一支别急着发告警。批量脏数据会瞬间灌满收件箱，正确做法是批次结束时汇总成一份清单发给业务负责人，让它回归数据治理的流程。

3.6 重试的两个坑

坑一：SetTransactionStatus 调得太早。这个活动一旦调用，事务就交还给 Orchestrator，后续重试由队列自己的策略接管。想自己控制重试次数，就应该在重试耗尽之后再调用它，否则框架里的重试计数失去意义。

坑二：双重重试。自己在 Process 里写了重试循环，Orchestrator 队列又设了 max retries，两边叠加，一条坏数据可能被跑很多遍。做法是把重试逻辑收敛在一处：如果由流程控制，队列级的 max retries 就设为 1。

还有个细节：重试前先分辨异常是不是意味着会话已断。如果只是偶发抖动，回到 Process 重试同一条就够；如果异常明确指向会话失效（比如登录态丢失），那就要走 Init 重开应用。

四、可观测性：出事能不能十分钟定位

4.1 日志的粒度

• Trace：关键输入参数与中间结果，排查时靠它还原现场。
• Info：每笔交易的开始与结束，带 REFERENCE 便于与业务单据对应。
• Warn：触发了预期内的兜底逻辑，比如走了备用选择器。
• Error：异常与堆栈，必须带上交易标识。

4.2 失败必带截图

异常处理里加 Take Screenshot 几乎是零成本高回报的习惯。三个月后回头看一条"元素未找到"，一张当时的截图胜过二十行日志。

4.3 Orchestrator 侧的排障路径

出问题时的标准动作：Job 页看这次运行整体状态，机器人日志定位到具体交易，队列页看失败分布。启用了 Healing Agent 的项目里，它尝试自愈失败的原因也可以在机器人日志中查到。

4.4 告警要收敛

分两级：单笔业务异常汇总到批次结束发一次；系统异常达到阈值或整个 Job 失败时立即发。每天都发的邮件，一周之后就没人看了。

五、2026 的新变量：平台开始替你做一部分事

前面的地基打好之后，再看这一年平台侧的更新，会更容易判断哪些真有用。

5.1 Healing Agent：让选择器自己爬起来

界面微调导致元素找不到时，它在运行时尝试重新定位，不必等人改选择器再打包发布。失败原因可以在 Orchestrator 的机器人日志里查看。要说清楚边界：它擅长应对位置或属性的小幅变化，遇到结构性改版（换了控件、重组了页面）同样没辙。

5.2 ScreenPlay：把某些界面活从选择器依赖里摘出来

用自然语言描述任务，把一部分 UI 脆弱性转移到运行时理解上。合适的地方是步骤直白、界面经常变的短流程；核心长流程仍然建议用明确的自动化活动，把确定性握在自己手里。

5.3 Maestro、Agent Builder 与 Coded Agents

Maestro 负责编排多步、长时、需要人机协作的流程；其中的 Case Management 面向理赔、贷款、争议、调查这类有目标、需要判断的工作，AI 与规则先把能推进的部分推完，只在确实需要人工判断时才转到人手上。Agent Builder 给非技术角色一个低代码的构建入口；Coded Agents 面向开发者，支持 MCP 插件接外部服务，并配了供试验的沙箱环境。Context Grounding 用于把企业自己的数据作为推理依据。

2026 年 9 月的版本里，会话式聊天与语音智能体可以用 Maestro Flow 来建模，支持按意图路由、在专家智能体之间转接、确定性回复等能力。这一步的意义在于：对话类自动化从"一个 prompt"变成了"可观测、可干预的流程对象"。

5.4 IXP：把文档这个老麻烦往前推了一步

非结构化文档一直是自动化的硬骨头。现在承担这类工作的部分从规则模板转到了智能体：Autopilot 生成抽取结构，Extraction Agents 处理复杂表格与跨页字段，Validation Agents 做校验环节。合同比对、系统记录核对这类场景收益明显。

5.5 本地化这条路现在走得更通了

以往上云是能力完整的前提，本地部署意味着功能打折。现在 Automation Suite 可以把 Maestro、Agent Builder、GenAI Activities、Context Grounding、ScreenPlay、Healing Agent 等能力部署在企业自己的基础设施上，模型侧可选云端服务，也可以选自托管的开源模型。对数据不能出内网的场景，这比"先上云再说"现实得多。

5.6 一句泼冷水的话

这些能力替代的是重复劳动，不是治理责任。谁对机器人的行为负责、怎么审计它的决策、出错时怎么兜底，仍然是甲方自己的设计任务。用上更好的工具，不代表可以省掉前面四章的那些规范。

六、落地清单与常见误区

6.1 六步上线清单

1. 定规范。命名规则（动词加对象）、变量前缀（str、int、dt）、参数方向（in_、out_、io_），动手前就定好并同步给团队。
2. 搭骨架。用 REFramework 起项目，把 Config.xlsx 三张表填好，队列和资产在 Orchestrator 侧先建出来。
3. 磨选择器。按第二章的清单逐条过，UI Explorer 验证。
4. 写分流。业务判断抛 BusinessRuleException，环境问题留给框架的系统异常处理。
5. 补观测。日志四级、失败截图、告警分两级。
6. 跑非开发环境。用真实账号、真实分辨率、全量数据试跑一轮。

6.2 四个常见误区

• 把配置硬编码。改个超时要重走发布流程，代价在半年后集中爆发。
• Catch 留空。异常被吞掉，机器人停得不明不白，排查时没有任何线索。
• 所有异常都重试。脏数据被反复重试，真正的环境故障反而淹没在日志里。
• 觉得用了自愈就不用管选择器。自愈能救小幅变化，救不了结构性改版，地基还是得自己打。

七、常见问题（FAQ）

Q1：小流程也必须用 REFramework 吗？

不一定。跑一次性的、数据量小的临时脚本，Sequence 足够。判断标准是这条流程要不要长期在生产环境里跑、有没有"跑一半崩了怎么办"的困扰。只要有，就值得用。

Q2：MaxRetryNumber 一般设多少？

多数场景 2 到 3 次。设多了意义不大：真正偶发的问题通常一两次内就自愈，重试三次还失败的，基本属于需要人介入的故障，反复重试只是拖延时间和占用机器人。同时记得把队列级的 max retries 设为 1，避免双重重试。

Q3：业务异常要不要告警？

不建议逐条发。批量脏数据会瞬间灌满收件箱，之后真正重要的告警也没人看了。做法是在批次结束时汇总成清单，发给业务侧的负责人，让它回归数据治理流程。系统异常或 Job 失败才需要立即告警。

Q4：Citrix 里的应用有没有更省事的办法？

有。先请 Citrix 管理员把 hosted app 的 accessibility 打开，能用标准选择器就别上图像识别。确实不行再退到 Computer Vision 活动或图像自动化，并确保运行分辨率不低于录制时的分辨率。

Q5：Healing Agent 能让选择器不用维护吗？

不能。它擅长处理属性或位置的小幅漂移，遇到控件替换、页面重组这类结构性改版同样失效。把它看成一道减速带，而不是免检通道：它能明显减少小改动引发的救火，但第二章那套选择器规范仍然要照做。

八、小结

自动化项目的分水岭，往往出现在"能不能长期跑"而不是"能不能跑通"。把三件事做扎实就够了：选择器做抗震、交易用框架管理、异常按类型分流。这三件事都不难，难在它们不像新功能那样有存在感，容易被跳过。

如果你正在规划 UiPath 的落地路径，可以结合 企业 RPA 与超自动化选型实践 一起看，那篇讲平台选型与建设路径，这篇讲上线之后怎么让它不出事。涉及智能体部分的治理口径，可参考 智能体的可信执行 与 AI 智能体安全风险与治理。