1. RPA 中断恢复到底在解决什么问题做过 RPA 的人都有一个共识流程跑通不难难的是跑稳。一个自动化流程在开发机上跑一百遍都顺顺利利一上生产环境各种幺蛾子就来了——目标系统响应超时、页面元素加载慢了一拍、弹窗突然冒出来挡住按钮、网络抖了一下、甚至机器被人误碰重启了。这些意外一旦发生传统 RPA 脚本的行为非常脆要么直接抛异常终止要么卡在某个等待条件上死等要么带着错误状态继续往下跑把脏数据写进业务系统。中断恢复要解决的核心问题就一句话当流程因为任何原因偏离了预期执行路径时如何让它以最小的代价回到正轨或者至少干净地停下来而不是留下一地鸡毛。这件事听起来简单做起来极其复杂。因为中断这个词背后藏着至少七八种截然不同的情况进程崩溃、节点宕机、外部系统不可用、业务规则校验失败、人工干预打断、超时、资源竞争、数据不一致。每一种的恢复策略都不一样用一套逻辑去兜底所有场景必然会在某个角落翻车。我在实际项目里踩过最典型的一个坑一个财务对账流程跑到一半目标系统维护重启了脚本重试了三次都失败然后按照失败即终止的配置直接退出。问题是它退出前已经提交了前半部分的对账结果后半部分没跑导致账目对不上财务同事排查了一整天才定位到是自动化流程留下的半成品。这就是典型的缺少事务边界和恢复语义导致的灾难。所以这篇文章我想系统性地聊一聊 RPA 中断恢复这件事。我会给出一个我自己在多个生产项目中沉淀下来的七层框架从最底层的进程守护一直讲到最上层的业务补偿然后重点讲清楚 AI 在这个框架里能增强哪些环节、怎么增强、以及哪些环节 AI 其实帮不上忙。内容会涉及 Saga 补偿模式、租约机制、检查点设计、幂等性保障这些偏工程的东西也会给出可以直接抄的配置和代码片段。适合已经写过一些 RPA 流程、正在被稳定性问题折磨的工程师也适合正在做 RPA 平台架构设计的技术负责人。2. 七层框架的整体设计与分层逻辑2.1 为什么是七层而不是三层很多人第一反应是中断恢复不就是重试 补偿吗搞七层是不是过度设计我一开始也这么想直到在一个跨五个系统的采购流程里被现实教育了。三层模型检测、重试、补偿的问题在于它把不同粒度、不同时间尺度、不同责任主体的恢复动作混在一起。进程崩了和业务校验失败恢复手段完全不同但三层模型里它们都叫异常。结果就是代码里到处是 if-else重试逻辑和业务补偿逻辑纠缠在一起维护成本爆炸。七层框架的本质是按恢复的粒度和责任边界做切分。每一层只关心自己这一层能处理的中断处理不了就往上抛由上层决定是重试、补偿还是终止。这样每一层的逻辑都足够简单组合起来又能覆盖全部场景。2.2 七层框架的分层说明我把这七层从下到上列出来每一层用一个关键词概括它的核心职责层级名称核心职责典型技术手段L1进程守护层保证执行器进程活着守护进程、健康检查、自动拉起L2会话保持层维持与目标系统的连接连接池、心跳、会话重建L3步骤重试层单步操作的瞬时故障恢复指数退避重试、超时控制L4检查点层记录执行进度支持断点续跑状态快照、持久化、幂等键L5事务补偿层跨步骤的业务一致性Saga、补偿事务、回滚脚本L6租约协调层多实例并发下的互斥与接管分布式租约、心跳续约、故障转移L7业务语义层理解业务规则做智能决策规则引擎、AI 辅助判断这七层不是必须全部实现才能用。小项目可能只需要 L1 到 L4跨系统的大流程才需要把 L5 到 L7 补齐。但你要清楚每一层解决的是什么问题缺了哪一层会在什么场景下出问题。2.3 分层之间的协作关系层与层之间是向上抛异常、向下要能力的关系。举个具体例子L3 步骤重试层在重试三次后仍然失败它不会自己去做业务补偿而是把这一步彻底失败了这个事实抛给 L4。L4 检查点层看到这个失败会判断当前检查点是否完整如果不完整就标记流程为需要恢复然后由 L5 事务补偿层决定是回滚已完成的步骤还是从检查点续跑。这里有个关键设计原则下层永远不知道上层的存在上层通过下层的接口来编排。L3 只管重试它不知道什么叫 SagaL5 只管补偿它不关心底层是重试了三次还是三十次。这种解耦让每一层都可以独立测试、独立替换。注意分层不等于分层部署。这七层逻辑上分层物理上完全可以跑在同一个进程里。不要为了架构清晰强行拆成七个微服务那是另一种形式的过度设计。3. 核心层级的实现细节与实操要点3.1 L1 进程守护层让执行器死而复生进程守护层要解决的是最粗暴的中断执行器进程本身挂了。原因可能是内存溢出、未捕获异常、操作系统杀进程、机器重启。实现方式有两种。第一种是用操作系统的守护机制Linux 下用 systemd 的RestartalwaysWindows 下用服务管理器配置自动重启。这种方式简单可靠但粒度粗进程一挂就整个重启正在执行的流程状态全丢。第二种是在 RPA 框架内部实现心跳和自愈。执行器定期往一个共享存储写心跳时间戳守护进程扫描心跳发现超时就拉起新的执行器实例。这种方式可以配合 L4 检查点层实现进程重启后从检查点续跑。我一般两个都用systemd 兜底保证进程一定活着框架内部的心跳机制负责优雅恢复。配置大概长这样# /etc/systemd/system/rpa-worker.service [Unit] DescriptionRPA Worker Afternetwork.target [Service] Typesimple ExecStart/opt/rpa/worker --config /etc/rpa/worker.yaml Restartalways RestartSec5 StartLimitBurst10 StartLimitIntervalSec300 [Install] WantedBymulti-user.targetRestartSec5表示崩溃后等 5 秒再拉起避免疯狂重启打爆日志。StartLimitBurst10配合StartLimitIntervalSec300表示 5 分钟内最多重启 10 次超过就停止防止一个必然崩溃的配置无限循环。3.2 L2 会话保持层连接断了要能自己接回来RPA 经常要跟浏览器、数据库、API 打交道这些连接都可能断。会话保持层要做的是检测连接失效、重建连接、把重建后的会话上下文恢复到可用状态。浏览器自动化的会话恢复最麻烦。比如用 Playwright 或 Selenium 控制浏览器如果浏览器进程崩了重建一个容易但页面状态、登录态、已填表单全没了。这时候要么重新走一遍登录和导航要么用持久化的浏览器上下文storage state来恢复登录态。我的做法是关键登录态定期持久化会话重建时优先加载持久化状态加载失败才走完整登录流程。Playwright 里可以这样操作# 保存登录态 context.storage_state(pathauth_state.json) # 重建时加载 context browser.new_context(storage_stateauth_state.json)数据库连接用连接池 健康检查。连接池配置里有个关键参数叫validationQuery或者连接池对应的健康检查语句每次从池里取连接时先 ping 一下失效的就丢弃重建。这个参数不配的话池里可能全是已经断掉的死连接取出来用就报错。实操心得会话重建一定要有次数上限和退避。我见过一个流程目标系统挂了脚本疯狂重建连接一秒几十次把目标系统的日志刷爆了运维直接找上门。重建间隔至少 1 秒起步失败次数超过阈值就上报别硬刚。3.3 L3 步骤重试层区分值得重试和重试也没用重试是最容易被滥用的恢复手段。很多人一看到异常就加重试结果把本来应该快速失败的问题拖成了长时间挂起。重试的前提是这个故障是瞬时的、可自愈的。网络抖动、目标系统短暂过载、锁竞争这些重试有意义。但如果是参数错误、权限不足、业务规则校验失败重试一万次结果都一样纯属浪费资源。所以 L3 的第一件事是异常分类。我通常把异常分成三类可重试异常超时、连接拒绝、5xx 错误、元素暂时不可见不可重试异常4xx 错误、参数校验失败、权限拒绝未知异常默认按不可重试处理记录详细上下文供人工分析分类之后是重试策略。指数退避是标配但参数要调。我的经验值是初始间隔 1 秒退避倍数 2最大间隔 30 秒最多重试 5 次。这样总耗时大约是 12481631 秒对于大多数瞬时故障足够了。如果 31 秒还恢复不了那大概率不是瞬时问题继续重试也没用。import time import random def retry_with_backoff(func, max_retries5, base_delay1, max_delay30): for attempt in range(max_retries): try: return func() except RetryableError as e: if attempt max_retries - 1: raise delay min(base_delay * (2 ** attempt), max_delay) # 加抖动避免多个实例同时重试造成惊群 delay delay * (0.5 random.random()) time.sleep(delay) except NonRetryableError: raise注意那个抖动jitter。如果多个 RPA 实例同时遇到目标系统过载它们会几乎同时重试形成新的冲击波。加个 0.5 到 1.5 倍的随机因子把重试时间打散能显著降低二次冲击。3.4 L4 检查点层断点续跑的基础设施检查点层是整个恢复框架的地基。没有检查点进程一挂就只能从头再来有了检查点才能实现从上次成功的地方继续。检查点的设计有三个关键决策存什么、存哪里、什么时候存。存什么最小集合是当前执行到哪个步骤、已完成步骤的输出结果、流程级的上下文变量。不要存整个内存快照那样太重而且恢复时很多状态已经失效了。存哪里本地文件最简单但多实例场景下不行。生产环境我一般用 Redis 或者数据库。Redis 快适合高频写入数据库持久适合关键流程。折中方案是 Redis 做热存储、定期落库做冷备份。什么时候存每个业务上有意义的步骤完成后存一次。什么叫有意义就是这一步的结果会影响后续步骤的执行。比如登录成功是个检查点点击了一个按钮可能不是除非这个点击改变了业务状态。检查点还要配合幂等键使用。恢复时从检查点续跑可能会重复执行检查点之后的步骤。如果这些步骤不是幂等的就会产生重复数据。幂等键的作用是让重复执行变成无害操作。# 检查点结构示例 checkpoint { flow_id: purchase_20240115_001, current_step: submit_order, completed_steps: [login, select_product, fill_address], context: { order_id: ORD123456, idempotency_key: purchase_20240115_001_submit }, timestamp: 2024-01-15T10:30:00Z }注意检查点写入必须是原子的。我见过用普通文件写入做检查点的写到一半进程挂了恢复时读到一个损坏的 JSON直接解析失败。用 Redis 的 SET 或者数据库事务或者写临时文件再 rename保证要么完整要么不存在。3.5 L5 事务补偿层Saga 模式在 RPA 里的落地跨多个系统的 RPA 流程本质上就是一个分布式事务。传统两阶段提交在 RPA 场景下不现实因为很多目标系统根本不支持事务接口。这时候就要用Saga 模式。Saga 的核心思想是把一个大事务拆成一串本地事务每个本地事务都有一个对应的补偿操作。如果某一步失败就反向执行前面已成功步骤的补偿操作把系统恢复到一致状态。在 RPA 里Saga 的落地方式是这样的class SagaStep: def __init__(self, name, action, compensation): self.name name self.action action # 正向操作 self.compensation compensation # 补偿操作 class SagaOrchestrator: def __init__(self): self.steps [] self.completed [] def add_step(self, step): self.steps.append(step) def execute(self): for step in self.steps: try: step.action() self.completed.append(step) except Exception as e: self.compensate() raise def compensate(self): # 反向补偿 for step in reversed(self.completed): try: step.compensation() except Exception as e: # 补偿失败要告警人工介入 log_critical(f补偿失败: {step.name}, e)举个实际例子。一个采购流程创建采购单 → 扣减库存 → 生成付款单 → 通知供应商。如果生成付款单失败补偿操作就是恢复库存 → 取消采购单。注意补偿顺序是反的先恢复库存再取消采购单因为采购单取消后可能不允许再操作库存。补偿操作有两个难点。第一是补偿本身也可能失败这时候不能无限重试要记录到待人工处理队列同时告警。第二是有些操作不可补偿比如已经发出去的邮件、已经通知的供应商。对于不可补偿的操作要么把它放到流程最后要么设计成可撤销的形式比如发一封更正邮件。3.6 L6 租约协调层多实例并发下的接管机制当 RPA 流程需要多实例并发执行时中断恢复就多了一个维度一个实例挂了它的任务谁来接管答案是租约Lease。每个实例在执行任务时先申请一个带过期时间的租约。执行过程中定期续约。如果实例挂了租约到期自动释放其他实例可以申请这个租约并接管任务。租约的关键参数是过期时间和续约间隔。过期时间太短实例稍微卡一下租约就丢了导致任务被重复执行过期时间太长实例挂了之后要等很久才能被接管。我的经验值是续约间隔 10 秒过期时间 30 秒也就是允许连续两次续约失败。class LeaseManager: def __init__(self, redis_client, lease_ttl30): self.redis redis_client self.ttl lease_ttl def acquire(self, task_id, worker_id): # SET NX 保证原子性 key flease:{task_id} acquired self.redis.set(key, worker_id, nxTrue, exself.ttl) return bool(acquired) def renew(self, task_id, worker_id): key flease:{task_id} # Lua 脚本保证检查持有者 续约的原子性 lua if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(expire, KEYS[1], ARGV[2]) else return 0 end return self.redis.eval(lua, 1, key, worker_id, self.ttl)续约必须用 Lua 脚本保证原子性否则会出现检查时还是自己持有续约前被别人抢走的竞态。这个坑我在早期项目里踩过表现为任务偶尔被两个实例同时执行排查了很久才发现是续约的竞态问题。接管任务时接管的实例要先读检查点从检查点续跑而不是从头开始。这就是 L4 和 L6 的配合。3.7 L7 业务语义层让恢复决策理解业务前面六层解决的都是技术上的中断恢复。但有些中断技术上流程没断业务上已经错了。比如目标系统返回了一个成功状态但实际业务规则要求这个操作不应该成功或者流程跑完了但结果不符合业务预期。L7 要做的是在恢复决策中引入业务语义。最简单的形式是规则引擎定义一组业务规则流程执行到关键节点时校验规则不满足就触发特定的恢复动作。AI 在这一层能发挥的空间最大。传统规则引擎只能处理预定义的规则遇到没见过的情况就抓瞎。而大模型可以基于流程上下文做推理判断当前这个异常状态最可能的恢复动作是什么。比如一个订单处理流程某一步返回了库存不足。规则引擎只能告诉你库存不足流程终止。但大模型可以结合上下文推理这个订单是 VIP 客户的历史上有过缺货先发后补的记录建议走缺货登记 优先补发的补偿路径。这种判断传统规则很难覆盖。不过 L7 的 AI 增强要非常谨慎。AI 的建议必须经过人工确认或者严格的规则校验才能执行不能让大模型直接决定补偿动作。原因很简单补偿操作往往涉及资金、库存、客户关系错了代价很大。AI 适合做建议者不适合做决策者。4. AI 增强路径哪些环节值得用 AI怎么用4.1 AI 增强的边界先搞清楚 AI 不擅长什么在聊 AI 能做什么之前我想先泼盆冷水。中断恢复的核心是确定性和可靠性而大模型天生是不确定的。同一个输入大模型两次调用可能给出不同答案。这在恢复决策场景里是危险的。所以 AI 增强的第一原则是AI 只用在决策辅助和模式识别环节不用在执行环节。执行环节必须是确定性的代码AI 的输出要经过校验才能转化为执行动作。具体来说AI 不适合做这些事直接执行补偿操作、直接修改检查点、直接决定是否重试。AI 适合做这些事异常根因分析、恢复策略建议、日志模式识别、测试用例生成。4.2 用 AI 做异常根因分析RPA 流程失败时日志里往往有一大堆信息异常堆栈、截图、页面 HTML、网络请求记录。人工分析这些信息很耗时尤其是当失败原因很隐蔽时。大模型可以吃下这些上下文给出根因假设。我实际用下来的效果是对于常见异常元素找不到、超时、登录失效大模型的判断准确率相当高对于复杂的业务逻辑异常大模型能给出一两个有价值的排查方向但需要人工验证。实现方式是把异常上下文组装成 prompt让模型输出结构化的分析结果def analyze_failure(context): prompt f 以下是一个 RPA 流程失败时的上下文信息 异常类型{context[exception_type]} 异常信息{context[exception_message]} 当前步骤{context[current_step]} 页面 URL{context[page_url]} 页面截图描述{context[screenshot_desc]} 最近的操作序列{context[recent_actions]} 请分析 1. 最可能的根因是什么 2. 这个异常是否可重试 3. 建议的恢复动作 以 JSON 格式输出字段为 root_cause, retryable, suggested_action。 response llm_client.chat(prompt) return parse_json(response)关键是输出结构化。不要让模型自由发挥写一大段分析那样没法程序化处理。用 JSON schema 约束输出解析失败就降级到默认策略。4.3 用 AI 做恢复策略推荐比根因分析更进一步的是恢复策略推荐。当流程在某个检查点失败时AI 可以基于历史成功恢复案例推荐最可能有效的恢复路径。这需要先积累一个恢复案例库每次人工处理完一个中断把异常特征 → 采取的恢复动作 → 结果记录下来。积累到一定量之后用这些案例做 few-shot 提示让模型推荐恢复动作。def recommend_recovery(failure_context, case_library): similar_cases retrieve_similar(failure_context, case_library, top_k3) prompt f 当前失败上下文 {failure_context} 历史上相似的失败案例及处理方式 {format_cases(similar_cases)} 请推荐最可能的恢复动作并说明理由。 可选动作retry, skip_step, rollback, restart_from_checkpoint, manual_intervention return llm_client.chat(prompt)这里的retrieve_similar可以用向量检索把异常特征向量化后找最相似的案例。这个方案我在一个电商订单流程里试过恢复动作推荐的命中率大概在 70% 左右剩下 30% 需要人工判断。虽然不完美但已经能显著减少人工介入的频率。4.4 用 AI 做日志模式识别和告警降噪RPA 流程多了之后告警会爆炸。同一个根因可能触发几十条告警运维根本看不过来。AI 可以做告警聚类把语义相似的告警归为一组只推送一条代表性告警。实现思路是把告警文本向量化做聚类每个簇选一条代表。这个用传统 NLP 也能做但大模型对语义的理解更好尤其是当告警文本包含大量业务术语时。另一个用法是异常模式发现。大模型可以分析历史失败日志发现人类没注意到的模式。比如每周一早上 9 点的失败率明显高于其他时段可能指向目标系统周一早上的批处理任务导致的资源竞争。这种洞察对优化流程很有价值。4.5 AI 增强的工程化注意事项把 AI 引入恢复框架有几个工程上的坑必须注意。第一是延迟。大模型调用通常要几百毫秒到几秒如果放在关键路径上会拖慢恢复速度。我的做法是AI 分析异步进行不阻塞主恢复流程。主流程先用默认策略恢复AI 分析结果出来后再决定是否需要调整。第二是成本。每次失败都调大模型token 消耗很快。要设置采样率比如只对未知异常和高频失败调用 AI常见异常直接用规则处理。第三是降级。大模型服务可能不可用必须有降级路径。AI 调用失败时回退到规则引擎或者默认策略不能因为 AI 挂了导致整个恢复流程卡住。第四是审计。AI 给出的每个建议、最终采取的动作、结果都要记录。这既是为了排查问题也是为了积累训练数据。实操心得AI 增强不要一上来就全量铺开。先在一个非关键流程上试点积累案例库验证效果再逐步推广。我见过团队一上来就把 AI 决策接进核心资金流程结果模型幻觉导致一次错误补偿损失不小。AI 是增强不是替代这个定位要摆正。5. 常见问题与排查技巧实录5.1 恢复后重复执行导致数据重复这是最高频的问题。流程从检查点续跑检查点之后的步骤被重复执行如果这些步骤不幂等就会产生重复数据。排查思路先确认检查点记录的位置是否准确。常见错误是检查点记录在步骤开始前而不是步骤完成后导致恢复时这一步被重跑。检查点必须在步骤成功完成后写入。解决方法是给每个写操作加幂等键。幂等键的生成规则要保证同一个业务操作无论执行多少次幂等键都一样。通常用流程ID 步骤名 业务主键组合。5.2 租约续约失败导致任务被重复接管表现是同一个任务被两个实例执行。根因通常是续约的竞态或者续约间隔设置不合理。排查时先看租约的续约日志确认续约是否按时发生。如果续约正常但任务还是被接管检查续约操作是否原子。用 Redis 的话GETEXPIRE两步操作不是原子的必须用 Lua 脚本或者SET XX配合EXPIRE。另一个常见原因是时钟漂移。如果多个实例的时钟不一致租约的过期判断会出错。生产环境要保证所有实例的时钟同步。5.3 补偿操作本身失败补偿失败是最棘手的情况因为系统已经处于不一致状态而自动恢复手段又失效了。处理原则是补偿失败必须告警并且记录到待人工处理队列。不要试图无限重试补偿那只会让情况更糟。同时补偿操作要尽量设计得简单可靠避免补偿逻辑本身很复杂。我的一般做法是给补偿操作也加重试但重试次数比正向操作少比如 2 次失败后立即告警。告警信息要包含流程ID、失败的补偿步骤、当前系统状态、建议的人工处理方式。5.4 检查点数据损坏前面提过检查点写入不是原子的话进程崩溃时可能留下损坏的数据。恢复时读到损坏数据解析失败流程无法续跑。排查方法是检查检查点的写入方式。如果是文件写入确认是否用了写临时文件 rename的原子模式。如果是 Redis确认是否用了单条命令写入SET是原子的HSET多条字段不是。预防措施是给检查点加版本号和校验和。恢复时先校验校验失败就降级到上一个有效检查点或者从头开始。5.5 AI 分析结果不可用AI 返回的结果解析失败、格式不对、或者内容明显不合理这些都会发生。处理方式是永远不要假设 AI 输出一定可用。解析失败就降级到规则策略同时记录这次失败用于后续优化 prompt。内容不合理的话加一层校验比如 AI 建议的恢复动作必须在允许的动作列表里不在列表里就丢弃。下面这张表汇总了常见问题和排查方向可以当作速查表用问题现象可能根因排查方向解决手段恢复后数据重复检查点位置错误或缺少幂等检查检查点写入时机、幂等键生成检查点后移、加幂等键任务被重复执行租约竞态或时钟漂移检查续约原子性、时钟同步Lua 脚本续约、NTP 同步补偿失败补偿逻辑复杂或依赖不可用检查补偿操作依赖简化补偿、告警人工处理检查点损坏非原子写入检查写入方式原子写入、加校验和AI 结果不可用输出格式不稳定检查 prompt 和解析逻辑结构化输出、降级策略恢复后流程卡住恢复状态不完整检查恢复时加载的上下文补全上下文、加恢复校验5.6 几个容易被忽略的细节日志要带流程ID和检查点ID。排查恢复问题时没有这两个 ID 基本没法定位。每条日志都要带上包括 AI 分析的日志。恢复动作要可观测。每次恢复触发了什么动作、结果如何要有独立的指标。这样才能知道恢复框架本身是否健康。我一般会监控恢复触发次数、恢复成功率、补偿失败率、AI 建议采纳率。定期演练恢复流程。恢复逻辑平时不跑真出问题时才发现有 bug那就晚了。我建议每个月做一次故障注入演练手动杀掉执行器进程验证恢复流程是否正常工作。6. 从框架到落地我的实施建议七层框架听起来完整但落地要分阶段。我的建议是先做 L1 到 L4把基础打牢再考虑 L5 到 L7。L1 到 L4 是恢复能力的地基。没有进程守护进程挂了就全完没有检查点恢复就只能从头再来没有重试瞬时故障就会导致流程失败。这四层做完流程的稳定性会有质的提升投入产出比最高。L5 事务补偿层在跨系统流程里是必须的但如果你的流程只操作一个系统而且这个系统本身支持事务那可以先不做。判断标准是流程失败时会不会留下不一致的中间状态。会就需要补偿不会可以先跳过。L6 租约协调层只在多实例并发场景下需要。单实例跑的话用不上。但要注意即使现在单实例如果未来可能扩展租约的接口可以先预留。L7 业务语义层和 AI 增强是锦上添花。先把前六层做扎实再考虑用 AI 优化。AI 能提升恢复的智能化程度但替代不了确定性的恢复机制。最后分享一个我在多个项目里验证过的经验恢复框架的复杂度要和流程的业务价值匹配。一个每天跑一次、失败了人工重跑就行的流程不需要七层框架。一个每分钟跑一次、失败会影响资金安全的流程七层都不一定够。先评估流程的中断代价再决定投入多少做恢复。这个判断做对了后面的技术选型才不会跑偏。