简介RPARobotic Process Automation常被误解为简单的按键录制与回放但实际上它是一套完整的企业级自动化工程体系。从更基础的软件自动化概念出发RPA通过模拟人类操作将重复性业务规则转化为可执行流程其核心价值在于稳定、可审计、可调度。在技术实现上一套成熟的RPA平台通常由设计器Designer、控制器Center和执行机器人Robot三大组件构成分别承担流程编排、任务调度与运行执行的角色。理解这一架构是评估任何RPA工具和落地项目的关键。实际应用中RPA与Python扩展、OCR识别、数据处理等技术结合能够覆盖财务对账、报表拉取、跨系统录入等高频场景。本文围绕RPA组件分工、流程发布策略、并发控制以及日志留痕等工程实践梳理一套从设计到上线的完整方法论帮助自动化负责人和RPA工程师避开常见陷阱真正将自动化项目落地为可维护的系统能力。1. 别把RPA当成按键精灵它是一套完整的工程体系财务月末对账、ERP主数据录入、跨系统报表拉取这类工作规则明确、重复度高一天可能执行几百次但完全靠人盯着屏幕点鼠标。RPARobotic Process Automation解决的就是这个问题一个软件机器人运行在你的桌面上识别UI、模拟鼠标键盘操作把整条流程自动跑完。强调一点RPA不是按键精灵或简单的录制回放。可落地的RPA项目至少包含设计器、控制器、执行机器人三层还要有异常处理、日志留痕和审计机制。无论你是想推自动化的业务负责人还是准备入行RPA工程师先拆解这套架构比直接看哪个流程能录更重要。2. RPA三个核心组件Designer、Center、Robot如何分工2.1 设计器、控制器、执行机器人各管哪一段一套完整的RPA平台常见的是三角色拆开Designer是流程设计器负责把业务动作编排成可执行的指令Center是控制中心负责发布流程、分配任务、监控机器人运行Robot是执行终端部署在工作PC或虚拟化环境里7x24小时跑流程。三者关系可以理解成开发环境、调度平台和运行环境的分工。很多项目失败就是因为把Designer当成“录脚本的工具”忽略了Center的调度能力机器人多了之后任务撞车、权限混乱最后又回到纯手工。下面表格给出了每个组件的关键能力组件主要职责关键能力典型部署位置Designer流程录制、编排、调试录制转脚本、拖拽组件、Python扩展开发人员工作机Center流程发布、任务分配、状态监控队列、并发控制、权限审计独立服务器Robot执行既定流程返回结果鼠标键盘操作、数据读写、OCR识别工作PC或虚拟桌面实际选型时RPA工程师要关心的不是哪个组件功能多而是三个组件之间的接口是否开放。比如Center是否提供API给内部系统调用Robot是否支持无人值守模式和有人值守模式切换。艺赛旗这套方案的框架正是这个结构Center负责把Designer做好的指令包发布给Robot并全程记录行为数据。如果你用过影刀这类国产RPA会发现虽然命名不同但设计器、控制台、机器人三件套的逻辑是一致的。2.2 流程包发布把设计器做的流程变成可调度的任务Designer里完成流程后不会直接扔给Robot执行。常见做法是先导出一个流程包zip格式里面包含流程定义、依赖的脚本和资源文件再传到Center上发布。这样做的原因是可以做版本管理业务改了报销规则重新导出一个v1.1包不需要动Robot上的环境。我一般会在发布环节写一个小脚本同步到Center API。import requests center_endpoint http://center.example.com:8080/api/v1/processes headers {Authorization: Bearer ${CENTER_TOKEN}} with open(reimburse_v1.1.zip, rb) as fp: resp requests.post( center_endpoint, headersheaders, files{file: fp}, data{ name: reimburse_process, version: 1.1.0, robot_group: finance, trigger_type: schedule } ) if resp.status_code 201: print(发布成功流程ID:, resp.json()[id]) else: print(发布失败:, resp.status_code, resp.text)这段脚本把流程包上传到Center并指定了robot_group和trigger_type。robot_group用来限制哪些Robot可以接收这个任务避免测试环境的机器人把生产数据改了trigger_type表示是定时触发还是事件触发财务场景一般用schedule。注意Bearer Token不要硬编码在脚本里建议从环境变量读取这个习惯能避免流程包泄露后连中心都被接管。2.3 任务分配与并发让机器人不空转也不超载Center的核心价值是任务调度。同一个流程可能同时分给多个Robot比如月末有1000张报销单要审核一个机器人跑一天跑不完这时可以开3个机器人并行。但并发不是越大越好下游系统可能扛不住所以要控制队列的最大并发数。下面是我常用的一组队列参数参数示例值说明queueNamefinance_reimburse队列名maxConcurrent3同一队列同时运行的机器人数量retryCount2单次任务失败后自动重试次数runAsrobot_finance机器人运行身份timeout3600单个任务超时时间秒这里的关键是retryCount和timeout要一起看。有些流程一失败就重试但如果是下游系统卡死重试只会加重拥堵。实际我会把timeout设成略高于正常执行时间的1.5倍retryCount先设2再根据日志定位失败原因决定要不要改参数。这一步就是RPA运维和单纯写脚本的分水岭。3. 从录制到Python可视化流程编排与脚本扩展3.1 录屏转脚本操作轨迹为什么不能直接用艺赛旗这类RPA的设计器都支持录制点“开始录制”后你操作什么它就记录什么最后生成一套流程指令。原理上它是在操作系统层面捕获鼠标键盘事件、窗口属性、控件树和图像快照再把这些信息转成脚本。但录制产生的脚本有一个通病大量坐标是硬编码的。窗口稍微移动几个像素录出来的点击就会点错位置。所以RPA实战中录制只能作为起点后面一定要把坐标定位改成控件定位或图像定位。常见做法是打开Designer的“侦测”功能重新选取被操作的元素生成带语义的选择器。比如点击ERP里的“保存”按钮选择器会记录窗口标题、控件类型、名称而不是屏幕坐标。这样流程包迁移到别的机器上只要操作系统和界面版本一致基本不用改。3.2 可视化组件的边界哪些逻辑不用写代码在Designer里你看到的是一个个可拖拽的组件这类“rpa组件”通常包括鼠标操作、键盘输入、图像检测、OCR文本识别、条件判断、循环、异常容错、数据表格处理等。对简单线性流程确实可以做到“无需编程”打开Excel、读取单元格、填入网页表单、点击提交。但一旦业务有分支判断、数据清洗或调试需求纯拖拽就会变得非常笨重。下面是我常用的组件分类表类别常用组件适用场景桌面操作鼠标点击、键盘输入、热键UI交互识别技术控件选择器、图像识别、OCR定位元素数据处理读取Excel、表格过滤、行列合并数据清洗流程控制条件分支、循环、延时复杂流程编排异常处理Try-Catch、超时重试、截图稳定性保障扩展能力Python代码、调用WebService、执行命令行系统集成从这张表能看出RPA组件不是按“功能丰富”来选而是按“场景是否规则明确”来选。图像识别适合验证码和自定义控件但效率低控件选择器效率高但要求能拿到底层UI属性。如果拿到的表格数据需要复杂计算用“Python代码”组件比拖二十个表格组件清爽得多。3.3 Python扩展把可视化流程导出为可维护的代码艺赛旗的Designer支持把可视化流程输出为Python3脚本也可以在流程里插入“Python代码”组件。这意味着你可以先用拖拽搭出主流程再在关键节点写Python处理复杂逻辑。比如从Excel里读取报销明细后需要对金额做二次计算并组装成JSON发给财务系统我会在流程中插入一段类似下面的代码import pandas as pd df pd.read_excel(reimburse.xlsx, sheet_name明细) df df[df[审批状态] 已通过] summary ( df.groupby([部门, 费用类型]) .agg(amount(金额, sum), count(单据号, count)) .reset_index() ) payload summary.to_dict(orientrecords) print(payload)这段代码先从Excel读取数据过滤已审批的行再按部门和费用类型汇总。groupby后的agg里amount和count分别是新列名括号里第一个参数是数据来源列第二个参数是聚合函数。注意read_excel依赖openpyxl或xlrdRobot执行机上必须装对应的Python包否则会报ModuleNotFoundError。输出payload后后续组件可以用它调用财务接口或写入数据库。这种“可视化编排主流程 Python处理数据”的方式比纯录制脚本好维护得多也方便测试数据清洗逻辑。4. 桌面操作、表格处理与OCRRPA的三大实战能力4.1 控件识别选择器优先图像识别兜底RPA最强的能力是模拟人操作桌面应用但“模拟得像”不等于“定位得准”。在Windows上通常优先用UIA、Java Access Bridge等控件树来定位元素速度快、抗干扰强。和坐标不同控件选择器记录的是窗口标题、控件类型、所属窗口、属性名等结构化信息。我见过一个反例某IT运维系统是Java桌面前端用图像识别点击“确认”按钮测试环境正常生产环境分辨率不同每次点偏。后来改成Java Accessibility属性定位问题才解决。一个典型的控件选择器配置如下{ window: { title: ERP - 固定资产, class: SunAwtFrame }, control: { type: Edit, name: assetCode, automationId: 1002 }, action: setText, params: { text: AS-2024-001 } }window字段定位父窗口control字段定位具体控件action是执行动作params是参数。automationId属于较稳定的属性优先使用name可能会随界面语言变化作为第二匹配条件。如果拿不到automationId再降级用图像识别。这里的原则是能用属性定位就不用图片能用图片就不用坐标这样流程才能扛住环境差异。4.2 亿级数据表格处理不要用Excel COM用内存计算Excel COM在数据量变大后会非常慢一个10万行的表逐个单元格读写能跑几个小时。艺赛旗RPA在表格组件上做了底层优化可以直接读取Excel、CSV到内存以表格形式处理亿级数据支持条件过滤、多表合并、排序、列重命名和统计。如果你在写RPA脚本时遇到性能瓶颈可以绕开Excel组件直接在Python代码块里做分块聚合。import pandas as pd file_path billing_data.csv chunk_size 500_000 result_parts [] for chunk in pd.read_csv(file_path, chunksizechunk_size): part chunk[chunk[amount] 1000] part[month] pd.to_datetime(part[bill_date]).dt.month result_parts.append(part) final pd.concat(result_parts, ignore_indexTrue) final.to_csv(filtered_result.csv, indexFalse)read_csv的chunksize参数让文件分批进入内存避免一次性把几个G的文件全部加载。每个分片先过滤出金额大于1000的账单再提取月份。concat合并后的final再写回CSV。使用RPA内置表格组件时建议先确认它是否支持流式读取否则内存会爆。实际项目中我会把这种Python处理放在一个独立的步骤里与UI操作分开万一内存不足重跑时直接从这一步骤恢复。4.3 OCR集成本地、云端和已有OCR系统怎么选OCR解决的是图片中的文字提取比如扫描发票、截图里的订单号。艺赛旗的集成方式有三种内置OCR模块、对接客户已有OCR系统、调用云端OCR接口。选型时看数据敏感度和网络环境。数据不能出内网就用本地OCR引擎内网没有GPU图片格式五花八门就用云端通用OCR。下面是三种方案的对比方案数据安全部署成本准确率适用场景本地OCR引擎高中中内网环境云端OCR接口低低高图片复杂、网络可达客户自有OCR按客户环境低取决于系统已有OCR资产复用调用云端OCR的一个示例import requests ocr_url https://example-ocr.com/v1/general token YOUR_ACCESS_TOKEN image_base64 open(invoice_screenshot.png, rb).read() image_b64_str __import__(base64).b64encode(image_base64).decode() resp requests.post( ocr_url, params{access_token: token}, json{ image: image_b64_str, language: zh-cn, detect_direction: True }, timeout10 ) for item in resp.json()[words_result]: print(item[text])这里把截图文件转成base64字符串通过POST传给OCR接口。detect_directionTrue会在识别前自动判断图片方向适合手机拍照的歪斜单据但会多消耗一点处理时间。timeout设为10秒避免接口无响应时RPA流程卡死。注意OCR接口返回的words_result一般带置信度对关键字段要加一个阈值判断比如低于0.85的文本打到人工队列而不是直接写入业务系统。5. 上线前把这三步做扎实日志留痕、异常回放与自动化断言5.1 用行为留痕和断言验证RPA流程的稳定性RPA流程上线前最容易被忽略的是运行验证。录一遍能过不代表跑一百遍都能过。艺赛旗的完整方案里有录屏、操作日志、行为分析这些不只是审计用的更是排错的关键。我会在流程每个关键步骤前后写日志配上截图并且记录当时的窗口标题、控件状态。下面是一个典型的异常处理框架try: # 操作前断言目标窗口存在且可交互 if not robot.window(ERP).exists(timeout5): raise RuntimeError(ERP窗口未打开) robot.window(ERP).find_control(保存).click() # 操作后断言保存成功提示出现 if not robot.window(ERP).find_control(保存成功).exists(timeout10): raise RuntimeError(保存失败未出现成功提示) except RuntimeError as e: robot.log.error(f{e} at step 12) robot.screenshot(failure_step12.png) raise这段代码演示了“操作前检查、操作后验证”的做法。exists(timeout5)会在5秒内等待窗口出现超时则报错点击保存后再次等待成功提示。failure时截图并记录日志。这样在线上一旦出错打开截图和日志就能判断是环境问题还是流程问题。注意不要在每次点击后都加长等待否则运行时间会翻倍建议只在状态转换的关键节点加断言。把断言粒度控制在“操作前检查、操作后验证”比事后翻日志省力得多。尤其当多个机器人并行跑的时候行为留痕能帮你快速定位是哪个机器人、哪一步、哪个数据出了问题而不是靠猜。本文还有配套的精品资源点击获取 RPA不是按键精灵：设计器、控制器与执行机器人的工程体系拆解
简介RPARobotic Process Automation常被误解为简单的按键录制与回放但实际上它是一套完整的企业级自动化工程体系。从更基础的软件自动化概念出发RPA通过模拟人类操作将重复性业务规则转化为可执行流程其核心价值在于稳定、可审计、可调度。在技术实现上一套成熟的RPA平台通常由设计器Designer、控制器Center和执行机器人Robot三大组件构成分别承担流程编排、任务调度与运行执行的角色。理解这一架构是评估任何RPA工具和落地项目的关键。实际应用中RPA与Python扩展、OCR识别、数据处理等技术结合能够覆盖财务对账、报表拉取、跨系统录入等高频场景。本文围绕RPA组件分工、流程发布策略、并发控制以及日志留痕等工程实践梳理一套从设计到上线的完整方法论帮助自动化负责人和RPA工程师避开常见陷阱真正将自动化项目落地为可维护的系统能力。1. 别把RPA当成按键精灵它是一套完整的工程体系财务月末对账、ERP主数据录入、跨系统报表拉取这类工作规则明确、重复度高一天可能执行几百次但完全靠人盯着屏幕点鼠标。RPARobotic Process Automation解决的就是这个问题一个软件机器人运行在你的桌面上识别UI、模拟鼠标键盘操作把整条流程自动跑完。强调一点RPA不是按键精灵或简单的录制回放。可落地的RPA项目至少包含设计器、控制器、执行机器人三层还要有异常处理、日志留痕和审计机制。无论你是想推自动化的业务负责人还是准备入行RPA工程师先拆解这套架构比直接看哪个流程能录更重要。2. RPA三个核心组件Designer、Center、Robot如何分工2.1 设计器、控制器、执行机器人各管哪一段一套完整的RPA平台常见的是三角色拆开Designer是流程设计器负责把业务动作编排成可执行的指令Center是控制中心负责发布流程、分配任务、监控机器人运行Robot是执行终端部署在工作PC或虚拟化环境里7x24小时跑流程。三者关系可以理解成开发环境、调度平台和运行环境的分工。很多项目失败就是因为把Designer当成“录脚本的工具”忽略了Center的调度能力机器人多了之后任务撞车、权限混乱最后又回到纯手工。下面表格给出了每个组件的关键能力组件主要职责关键能力典型部署位置Designer流程录制、编排、调试录制转脚本、拖拽组件、Python扩展开发人员工作机Center流程发布、任务分配、状态监控队列、并发控制、权限审计独立服务器Robot执行既定流程返回结果鼠标键盘操作、数据读写、OCR识别工作PC或虚拟桌面实际选型时RPA工程师要关心的不是哪个组件功能多而是三个组件之间的接口是否开放。比如Center是否提供API给内部系统调用Robot是否支持无人值守模式和有人值守模式切换。艺赛旗这套方案的框架正是这个结构Center负责把Designer做好的指令包发布给Robot并全程记录行为数据。如果你用过影刀这类国产RPA会发现虽然命名不同但设计器、控制台、机器人三件套的逻辑是一致的。2.2 流程包发布把设计器做的流程变成可调度的任务Designer里完成流程后不会直接扔给Robot执行。常见做法是先导出一个流程包zip格式里面包含流程定义、依赖的脚本和资源文件再传到Center上发布。这样做的原因是可以做版本管理业务改了报销规则重新导出一个v1.1包不需要动Robot上的环境。我一般会在发布环节写一个小脚本同步到Center API。import requests center_endpoint http://center.example.com:8080/api/v1/processes headers {Authorization: Bearer ${CENTER_TOKEN}} with open(reimburse_v1.1.zip, rb) as fp: resp requests.post( center_endpoint, headersheaders, files{file: fp}, data{ name: reimburse_process, version: 1.1.0, robot_group: finance, trigger_type: schedule } ) if resp.status_code 201: print(发布成功流程ID:, resp.json()[id]) else: print(发布失败:, resp.status_code, resp.text)这段脚本把流程包上传到Center并指定了robot_group和trigger_type。robot_group用来限制哪些Robot可以接收这个任务避免测试环境的机器人把生产数据改了trigger_type表示是定时触发还是事件触发财务场景一般用schedule。注意Bearer Token不要硬编码在脚本里建议从环境变量读取这个习惯能避免流程包泄露后连中心都被接管。2.3 任务分配与并发让机器人不空转也不超载Center的核心价值是任务调度。同一个流程可能同时分给多个Robot比如月末有1000张报销单要审核一个机器人跑一天跑不完这时可以开3个机器人并行。但并发不是越大越好下游系统可能扛不住所以要控制队列的最大并发数。下面是我常用的一组队列参数参数示例值说明queueNamefinance_reimburse队列名maxConcurrent3同一队列同时运行的机器人数量retryCount2单次任务失败后自动重试次数runAsrobot_finance机器人运行身份timeout3600单个任务超时时间秒这里的关键是retryCount和timeout要一起看。有些流程一失败就重试但如果是下游系统卡死重试只会加重拥堵。实际我会把timeout设成略高于正常执行时间的1.5倍retryCount先设2再根据日志定位失败原因决定要不要改参数。这一步就是RPA运维和单纯写脚本的分水岭。3. 从录制到Python可视化流程编排与脚本扩展3.1 录屏转脚本操作轨迹为什么不能直接用艺赛旗这类RPA的设计器都支持录制点“开始录制”后你操作什么它就记录什么最后生成一套流程指令。原理上它是在操作系统层面捕获鼠标键盘事件、窗口属性、控件树和图像快照再把这些信息转成脚本。但录制产生的脚本有一个通病大量坐标是硬编码的。窗口稍微移动几个像素录出来的点击就会点错位置。所以RPA实战中录制只能作为起点后面一定要把坐标定位改成控件定位或图像定位。常见做法是打开Designer的“侦测”功能重新选取被操作的元素生成带语义的选择器。比如点击ERP里的“保存”按钮选择器会记录窗口标题、控件类型、名称而不是屏幕坐标。这样流程包迁移到别的机器上只要操作系统和界面版本一致基本不用改。3.2 可视化组件的边界哪些逻辑不用写代码在Designer里你看到的是一个个可拖拽的组件这类“rpa组件”通常包括鼠标操作、键盘输入、图像检测、OCR文本识别、条件判断、循环、异常容错、数据表格处理等。对简单线性流程确实可以做到“无需编程”打开Excel、读取单元格、填入网页表单、点击提交。但一旦业务有分支判断、数据清洗或调试需求纯拖拽就会变得非常笨重。下面是我常用的组件分类表类别常用组件适用场景桌面操作鼠标点击、键盘输入、热键UI交互识别技术控件选择器、图像识别、OCR定位元素数据处理读取Excel、表格过滤、行列合并数据清洗流程控制条件分支、循环、延时复杂流程编排异常处理Try-Catch、超时重试、截图稳定性保障扩展能力Python代码、调用WebService、执行命令行系统集成从这张表能看出RPA组件不是按“功能丰富”来选而是按“场景是否规则明确”来选。图像识别适合验证码和自定义控件但效率低控件选择器效率高但要求能拿到底层UI属性。如果拿到的表格数据需要复杂计算用“Python代码”组件比拖二十个表格组件清爽得多。3.3 Python扩展把可视化流程导出为可维护的代码艺赛旗的Designer支持把可视化流程输出为Python3脚本也可以在流程里插入“Python代码”组件。这意味着你可以先用拖拽搭出主流程再在关键节点写Python处理复杂逻辑。比如从Excel里读取报销明细后需要对金额做二次计算并组装成JSON发给财务系统我会在流程中插入一段类似下面的代码import pandas as pd df pd.read_excel(reimburse.xlsx, sheet_name明细) df df[df[审批状态] 已通过] summary ( df.groupby([部门, 费用类型]) .agg(amount(金额, sum), count(单据号, count)) .reset_index() ) payload summary.to_dict(orientrecords) print(payload)这段代码先从Excel读取数据过滤已审批的行再按部门和费用类型汇总。groupby后的agg里amount和count分别是新列名括号里第一个参数是数据来源列第二个参数是聚合函数。注意read_excel依赖openpyxl或xlrdRobot执行机上必须装对应的Python包否则会报ModuleNotFoundError。输出payload后后续组件可以用它调用财务接口或写入数据库。这种“可视化编排主流程 Python处理数据”的方式比纯录制脚本好维护得多也方便测试数据清洗逻辑。4. 桌面操作、表格处理与OCRRPA的三大实战能力4.1 控件识别选择器优先图像识别兜底RPA最强的能力是模拟人操作桌面应用但“模拟得像”不等于“定位得准”。在Windows上通常优先用UIA、Java Access Bridge等控件树来定位元素速度快、抗干扰强。和坐标不同控件选择器记录的是窗口标题、控件类型、所属窗口、属性名等结构化信息。我见过一个反例某IT运维系统是Java桌面前端用图像识别点击“确认”按钮测试环境正常生产环境分辨率不同每次点偏。后来改成Java Accessibility属性定位问题才解决。一个典型的控件选择器配置如下{ window: { title: ERP - 固定资产, class: SunAwtFrame }, control: { type: Edit, name: assetCode, automationId: 1002 }, action: setText, params: { text: AS-2024-001 } }window字段定位父窗口control字段定位具体控件action是执行动作params是参数。automationId属于较稳定的属性优先使用name可能会随界面语言变化作为第二匹配条件。如果拿不到automationId再降级用图像识别。这里的原则是能用属性定位就不用图片能用图片就不用坐标这样流程才能扛住环境差异。4.2 亿级数据表格处理不要用Excel COM用内存计算Excel COM在数据量变大后会非常慢一个10万行的表逐个单元格读写能跑几个小时。艺赛旗RPA在表格组件上做了底层优化可以直接读取Excel、CSV到内存以表格形式处理亿级数据支持条件过滤、多表合并、排序、列重命名和统计。如果你在写RPA脚本时遇到性能瓶颈可以绕开Excel组件直接在Python代码块里做分块聚合。import pandas as pd file_path billing_data.csv chunk_size 500_000 result_parts [] for chunk in pd.read_csv(file_path, chunksizechunk_size): part chunk[chunk[amount] 1000] part[month] pd.to_datetime(part[bill_date]).dt.month result_parts.append(part) final pd.concat(result_parts, ignore_indexTrue) final.to_csv(filtered_result.csv, indexFalse)read_csv的chunksize参数让文件分批进入内存避免一次性把几个G的文件全部加载。每个分片先过滤出金额大于1000的账单再提取月份。concat合并后的final再写回CSV。使用RPA内置表格组件时建议先确认它是否支持流式读取否则内存会爆。实际项目中我会把这种Python处理放在一个独立的步骤里与UI操作分开万一内存不足重跑时直接从这一步骤恢复。4.3 OCR集成本地、云端和已有OCR系统怎么选OCR解决的是图片中的文字提取比如扫描发票、截图里的订单号。艺赛旗的集成方式有三种内置OCR模块、对接客户已有OCR系统、调用云端OCR接口。选型时看数据敏感度和网络环境。数据不能出内网就用本地OCR引擎内网没有GPU图片格式五花八门就用云端通用OCR。下面是三种方案的对比方案数据安全部署成本准确率适用场景本地OCR引擎高中中内网环境云端OCR接口低低高图片复杂、网络可达客户自有OCR按客户环境低取决于系统已有OCR资产复用调用云端OCR的一个示例import requests ocr_url https://example-ocr.com/v1/general token YOUR_ACCESS_TOKEN image_base64 open(invoice_screenshot.png, rb).read() image_b64_str __import__(base64).b64encode(image_base64).decode() resp requests.post( ocr_url, params{access_token: token}, json{ image: image_b64_str, language: zh-cn, detect_direction: True }, timeout10 ) for item in resp.json()[words_result]: print(item[text])这里把截图文件转成base64字符串通过POST传给OCR接口。detect_directionTrue会在识别前自动判断图片方向适合手机拍照的歪斜单据但会多消耗一点处理时间。timeout设为10秒避免接口无响应时RPA流程卡死。注意OCR接口返回的words_result一般带置信度对关键字段要加一个阈值判断比如低于0.85的文本打到人工队列而不是直接写入业务系统。5. 上线前把这三步做扎实日志留痕、异常回放与自动化断言5.1 用行为留痕和断言验证RPA流程的稳定性RPA流程上线前最容易被忽略的是运行验证。录一遍能过不代表跑一百遍都能过。艺赛旗的完整方案里有录屏、操作日志、行为分析这些不只是审计用的更是排错的关键。我会在流程每个关键步骤前后写日志配上截图并且记录当时的窗口标题、控件状态。下面是一个典型的异常处理框架try: # 操作前断言目标窗口存在且可交互 if not robot.window(ERP).exists(timeout5): raise RuntimeError(ERP窗口未打开) robot.window(ERP).find_control(保存).click() # 操作后断言保存成功提示出现 if not robot.window(ERP).find_control(保存成功).exists(timeout10): raise RuntimeError(保存失败未出现成功提示) except RuntimeError as e: robot.log.error(f{e} at step 12) robot.screenshot(failure_step12.png) raise这段代码演示了“操作前检查、操作后验证”的做法。exists(timeout5)会在5秒内等待窗口出现超时则报错点击保存后再次等待成功提示。failure时截图并记录日志。这样在线上一旦出错打开截图和日志就能判断是环境问题还是流程问题。注意不要在每次点击后都加长等待否则运行时间会翻倍建议只在状态转换的关键节点加断言。把断言粒度控制在“操作前检查、操作后验证”比事后翻日志省力得多。尤其当多个机器人并行跑的时候行为留痕能帮你快速定位是哪个机器人、哪一步、哪个数据出了问题而不是靠猜。本文还有配套的精品资源点击获取