我们部门去年接到一个挺棘手的需求业务方想把合同审核、财务对账、报表生成这套流程做成自动化但IT那边一票否决了所有SaaS方案原因就一句话——“数据不能出域”。客户数据、合同金额、供应商信息这些敏感内容一旦经过第三方云端合规上就说不清楚。最后敲定的路线是RPAAI的私有化部署。RPA负责流程编排和界面操作AI负责文档理解、信息抽取这些需要“动脑子”的环节所有数据和模型全部跑在内网服务器上。折腾了几个月方案总算落地也踩了不少坑。这篇就把整个方案的设计思路、关键技术点的选型、实际部署中遇到的问题都整理出来给同样有“数据不出域”硬性要求的团队一个参考。1. 方案整体设计与技术选型逻辑1.1 核心需求拆解要解决的不只是“自动化”先理清需求。业务方最初提的是“能不能让机器人帮我把合同里的关键信息填到系统里”听起来是个简单的RPA需求但深挖下去问题并不简单合同是PDF扫描件有印章、有手写备注纯RPA只能做界面操作识别内容这一步靠RPA本身搞不定需要OCR和NLP能力。合同模板不统一不同供应商提交的合同格式千差万别字段位置不同、命名不同信息抽取的规则没法写死。数据涉及商业机密合同价格、付款条款这些信息如果走了云端OCR接口合规风险不可控必须本地化处理。业务系统是老的Web端没有对外开放API只能靠界面级自动化也就是RPA的强项。所以这个方案的本质是“RPA做手AI做脑”RPA负责打开系统、上传文件、填写表单、点击按钮这类重复性操作AI负责读文档、抽字段、做判断、比对结果。两者配合才能真正替代人工。1.2 架构设计与“数据不出域”的实现路径整个方案分四层基础设施层内网服务器数据库文件存储全部在公司私有网络内。数据层原始文件、抽取结果、操作日志统一存在私有化部署的对象存储和数据库里。服务层RPA控制台、执行器、AI推理服务OCR、信息抽取模型、业务系统接口服务。应用层业务人员使用的自动化任务触发入口、后台管理界面。“数据不出域”不是一句口号而是通过三个手段保证的一是模型本地化。OCR、文本分类、实体抽取的模型全部部署在内网GPU服务器上推理过程不依赖外网。财务部的扫描件上传后文件流只走内网链路。二是网络隔离。RPA执行器和AI服务之间走内网API调用执行器所在服务器不开公网映射。外网访问只保留一条运维通道且经过堡垒机审计。三是权限与审计。所有自动化任务都记录操作日志谁在什么时间让机器人做了什么全部可追溯。涉及敏感字段的读取在日志里做脱敏处理。2. 核心组件部署与关键配置2.1 RPA运行环境的私有化搭建RPA产品市面上不少国产的有影刀、金智维、实在智能国外的有UiPath、Automation Anywhere。选型上我们综合考虑了信创适配、私有化部署的灵活度、中文场景的兼容性最终选了国产RPA平台。原因也很实际售后响应快定制化需求能沟通私有化部署的授权方式更灵活。RPA的私有化部署一般是分成控制台控制端和执行器机器人端两个部分控制台管理流程、分配任务、查看执行日志一般部署在服务器上通过浏览器访问。执行器真正干活的机器人部署在需要操作的电脑或独立的虚拟机上。我们这里用了“控制台多台独立执行器”的结构控制台部署在一台16核32G的虚拟机里数据库用MySQL执行器单独跑了4台Windows Server 2019的虚拟机每台执行器分配了固定的业务系统账号互不干扰。注意执行器的机器一定要保证桌面环境稳定RPA操作界面是模拟真人点击如果目标系统页面经常弹窗、网络卡顿很容易导致元素找不到、流程中断。建议给执行器机器设置统一的休眠策略关闭系统自动更新。2.2 AI能力的本地化集成AI部分是这次方案里最需要打磨的地方。我们需要的核心能力有三块OCR识别、信息抽取、文档比对。OCR选型扫描版PDF要先转成图片再识别。市面上很多OCR引擎我们测过一圈最终用了PaddleOCR的私有化部署版本。原因很朴素开源、可控、中文识别效果好、支持自定义训练。部署时拉取官方镜像挂载GPU资源对外提供HTTP接口。实测下来印刷体合同文本的识别准确率在98%以上手写备注的识别准确率稍低大概85%左右但结合后处理也能用。信息抽取传统做法是写正则或规则但合同模板一变规则就废。我们用了基于BERT的中文预训练模型做实体抽取用历史合同数据微调了一版可以自动抽取出合同编号、甲方、乙方、签约日期、合同金额、付款条件这些关键字段。文档比对比对电子版合同与扫描版合同是否一致用到了文本相似度计算。这个环节原以为简单实际也踩了坑后面细说。AI服务统一封装成一个推理平台用FastAPI写接口模型用ONNX Runtime加速部署在内网GPU服务器上NVIDIA T416G显存。RPA流程通过HTTP调用这些接口拿到结构化的JSON结果再填到业务系统里。2.3 权限隔离、数据加密与审计机制私有化部署不等于就绝对安全内部权限管控同样重要。我们做了三方面设置数据加密合同扫描件和抽取结果在存储层做了AES-256加密密钥放在独立的密钥管理服务里跟数据库分开防止一锅端。权限隔离RPA执行器用的业务系统账号只开通了自动化任务必需的最小权限。比如合同录入这个机器人只有合同模块的新增权限没有删除和修改权限。审计日志每次自动化任务的执行记录包括开始时间、结束时间、处理文件的数量、抽取结果的置信度分布都单独存一份日志表。遇到数据争议能从日志里追溯完整的处理链路。3. 关键流程的实操落地3.1 流程梳理与自动化可行性评估这一步最容易被忽视但恰恰是最关键的。我们当时跟财务部、法务部开了三轮需求对齐会议把合同处理的完整流程画出来业务人员接收电子版合同PDF或Word检查合同是否签字盖章把合同信息录入ERP系统财务核对金额与条款归档保存评估后确认接收、录入、归档这三步适合自动化但“检查是否签字盖章”这个环节先保留人工原因是盖章检测的误判率会直接影响后续流程需要AI模型进一步优化后再考虑自动化。经验梳理流程时一定要搞清楚每个节点的异常分支。正常流程谁都能写清楚但大量的精力应该花在“客户传错文件怎么办”“系统里查不到对应供应商怎么办”“重复提交怎么办”这些异常场景上。3.2 场景一合同信息抽取与系统录入这个场景是RPAAI配合最典型的例子。流程设计如下步骤1RPA监控文件目录。业务人员把PDF合同放到指定目录后RPA流程被触发。这里我们没有用FileSystemWatcher的实时触发而是用了控制台的定时轮询策略每3分钟检查一次目录避免多台执行器同时抢文件。步骤2调用AI识别服务。RPA把PDF传给OCR服务OCR服务先判断文件是不是扫描版通过检测是否包含文本层如果是扫描版就转图片识别再传给信息抽取模型最终返回JSON{ contract_no: HT-2023-0892, party_a: 某某科技有限公司, party_b: 某某供应链管理有限公司, sign_date: 2023-09-15, amount: 1580000.00, payment_terms: 合同签订后30日内支付30%验收合格后60日内支付70% }步骤3字段校验与录入。RPA拿到JSON后做两件事一是把金额这类关键字段跟合同首页的OCR结果做交叉校验防止抽取错误二是打开ERP系统把字段值填入对应位置。步骤4异常处理。如果抽取模型返回的置信度低于阈值比如0.85RPA不会直接录入而是打上“待人工确认”的标记把文件转移到人工复核目录同时发送通知。这一步非常关键宁可让机器“示弱”也不要让错误数据主动流进ERP。3.3 场景二财务对账与报表生成合同录入之后还有一块自动化需求是财务对账。原来是会计每月从银行系统、ERP系统分别导出流水用Excel手工做匹配每月要花两天时间。自动化方案RPA每月定时从银行系统导出对账单Excel格式RPA从ERP系统导出应收/应付数据用Python脚本做匹配按“金额日期合同编号”三个维度匹配匹配不上的记录单独生成差异表推送给财务人员复核匹配成功的记录生成记账凭证草稿RPA录入到财务系统这里涉及一个技术决策为什么不用RPA自带的Excel操作组件而是用Python脚本因为对账逻辑涉及大量数据清洗和多条件匹配RPA的Excel组件在处理复杂逻辑时表达能力有限调起来也费劲。我们的做法是把对账逻辑写成独立的Python服务RPA只做“导文件、调接口、传结果”这些事。这种“RPAPython脚本”的组合在实际项目中比纯RPA方案要灵活得多。3.4 业务流程的异常处理设计自动化流程的稳定性很大程度上取决于异常处理做得怎么样。我们在每个环节都设计了异常分支文件读取异常文件被占用、密码保护、扫描件质量太差AI服务超时模型推理时间过长RPA设置重试机制三次重试仍失败就转人工系统元素未找到业务系统页面改版、弹窗遮挡数据校验不通过抽取结果为空、金额对不上、日期格式不对每个异常都有预设的处理路径而不是简单地把流程停掉。比如系统元素未找到的情况RPA会截图保存现场把错误信息发到运维群防止问题被静默吞掉。4. 踩坑实录那些文档里不会写的教训4.1 环境依赖与兼容性问题这是整个项目里最折磨人的坑。RPA执行器的Windows虚拟机在一次安全加固后无法正常打开Chrome浏览器。排查了半天发现是安全策略把Chrome的自动化调试端口给禁了。RPA操作浏览器本质上是通过Chrome DevTools Protocol控制的端口被禁之后元素定位全部失效。类似的问题还有国产化电脑上的Edge浏览器版本差异导致RPA组件库不兼容Python服务部署在Linux上RPA执行器在Windows上跨平台文件路径的分隔符处理不一致OCR服务更新了模型版本但旧任务还在用旧的推理逻辑导致抽取字段格式变化解决思路是凡是界面操作、环境依赖相关的变更都要先经过测试环境验证再上生产。我们后来建了一个跟生产环境配置一致的测试虚拟机RPA流程发布前都先在这上面完整跑一遍。4.2 模型推理性能瓶颈合同识别这个场景一天要处理大概150份合同每份合同扫描件平均25页。刚开始上线时发现AI服务经常超时一份合同OCR加信息抽取要跑4分多钟比人工录入还慢自动化就失去了意义。排查后发现两个问题一是GPU资源分配不合理。OCR和BERT模型共用同一张T4显卡OCR推理时显存占用高把信息抽取的推理挤到了CPU上执行。后来分开部署OCR用GPU信息抽取模型用CPU推理加ONNX优化总算分开了。二是大量无效调用。每次RPA请求OCR服务时会把整个PDF所有页都识别一遍但合同首页往往就包含核心字段。优化成“先识别前3页关键字段缺失再全量识别”之后单份合同的处理时间降到40秒左右。实操建议给AI服务加缓存。相同文件的重复请求直接返回历史结果省掉大量重复推理。这个在重试场景下特别有用。4.3 无人值守调度与流程编排“无人值守”这四个字说起来简单做起来坑特别多。第一天晚上跑自动任务早上来一看流程停在“确认是否删除已有合同”的弹窗上——这个弹窗只在当天页面更新后才出现之前测试环境根本没有。所以异常处理设计时不能只看正常页面的元素要多考虑系统升级、提示变化这些动态因素。还有一个问题是调度冲突。4台执行器并行跑任务偶尔会出现两台执行器同时处理同一个文件。后来引入了分布式锁用Redis的SETNX命令保证文件级别的互斥if redis.set(ffile_lock:{file_name}, 1, nxTrue, ex600): process_file(file_name) else: log_and_wait(file_name)4.4 与业务系统的对接细节老业务系统没有提供API这是当初决定用RPA的原因。但用RPA操作老系统也有不少麻烦老系统的前端框架比较陈旧页面元素定位不稳定刷新之后某些按钮的id会变化。文件上传控件是ActiveX的RPA无法直接操作只能模拟键盘输入路径来绕过。系统的超时时间设置很短AI服务处理时间超过系统session时限RPA还在处理AI结果页面已经退出登录了。最后一个问题尤其头疼。解决方案是调整RPA的执行顺序先在空闲时间把文件提前下载并调用AI服务等AI结果保存在本地后再实际操作业务系统上传。相当于把“AI处理”和“系统录入”两个阶段解耦减少在页面上停留的时间。5. 常见问题速查与个人经验5.1 问题速查表问题现象排查方向解决思路元素定位失败流程随机中断提示找不到控件页面是否改版/弹窗遮挡定期做页面巡检改用相对XPath定位OCR识别率低关键字段为空或识别错误扫描件质量、模型精度优化图像预处理、补充训练数据调度重复处理同一文件被多台机器人处理缺少分布式锁引入Redis锁确保文件级互斥AI服务超时单份文件处理时间过长GPU资源、推理策略分开部署模型、增加缓存、优化识别范围页面会话过期长时间自动操作掉线系统超时设置解耦AI处理与系统录入减少页面停留时间文件路径跨平台问题Windows/Linux路径拼接错误代码中硬编码分隔符统一用pathlib或os.path处理5.2 一些个人经验与反思这个项目做完我最大的感受是RPAAI私有化部署难点不在技术而在预期管理。技术层面RPA和AI都是相对成熟的工具踩坑也能解决。但业务方一开始对自动化的预期是“全自动零人工100%准确”实际上这三个目标互相矛盾完全无人值守意味着异常处理极其复杂追求100%准确AI不可能做到。最后我们达成的目标共识是“人工介入率降低80%核心字段抽取准确率≥95%”。这个标准更现实也更容易验收交付。另一个体会是自动化流程是长期维护的项目不是上线就结束。业务系统的页面改版、合同模板的变化、模型的识别效果波动都需要持续的运维投入。我们专门设了一个运维小组的排班制度每周检查RPA任务的执行成功率、AI模型的识别准确率发现下降趋势就及时介入。如果现在让我重做一遍我会在项目初期就建好一套完整的效果监控体系把每个环节的成功率、耗时、异常类型全部可视化出来。数据说话比事后排查高效得多。这个方案跑了一年多现在稳定处理着合同审核、财务对账、报表生成三类业务每月累计自动化执行超过2000个任务。私有化部署这条路前期投入大、见效稍慢但换来的数据安全可控在当前的合规环境下这笔账值得算。
RPA+AI私有化部署：实现数据不出域的合同审核与财务自动化
我们部门去年接到一个挺棘手的需求业务方想把合同审核、财务对账、报表生成这套流程做成自动化但IT那边一票否决了所有SaaS方案原因就一句话——“数据不能出域”。客户数据、合同金额、供应商信息这些敏感内容一旦经过第三方云端合规上就说不清楚。最后敲定的路线是RPAAI的私有化部署。RPA负责流程编排和界面操作AI负责文档理解、信息抽取这些需要“动脑子”的环节所有数据和模型全部跑在内网服务器上。折腾了几个月方案总算落地也踩了不少坑。这篇就把整个方案的设计思路、关键技术点的选型、实际部署中遇到的问题都整理出来给同样有“数据不出域”硬性要求的团队一个参考。1. 方案整体设计与技术选型逻辑1.1 核心需求拆解要解决的不只是“自动化”先理清需求。业务方最初提的是“能不能让机器人帮我把合同里的关键信息填到系统里”听起来是个简单的RPA需求但深挖下去问题并不简单合同是PDF扫描件有印章、有手写备注纯RPA只能做界面操作识别内容这一步靠RPA本身搞不定需要OCR和NLP能力。合同模板不统一不同供应商提交的合同格式千差万别字段位置不同、命名不同信息抽取的规则没法写死。数据涉及商业机密合同价格、付款条款这些信息如果走了云端OCR接口合规风险不可控必须本地化处理。业务系统是老的Web端没有对外开放API只能靠界面级自动化也就是RPA的强项。所以这个方案的本质是“RPA做手AI做脑”RPA负责打开系统、上传文件、填写表单、点击按钮这类重复性操作AI负责读文档、抽字段、做判断、比对结果。两者配合才能真正替代人工。1.2 架构设计与“数据不出域”的实现路径整个方案分四层基础设施层内网服务器数据库文件存储全部在公司私有网络内。数据层原始文件、抽取结果、操作日志统一存在私有化部署的对象存储和数据库里。服务层RPA控制台、执行器、AI推理服务OCR、信息抽取模型、业务系统接口服务。应用层业务人员使用的自动化任务触发入口、后台管理界面。“数据不出域”不是一句口号而是通过三个手段保证的一是模型本地化。OCR、文本分类、实体抽取的模型全部部署在内网GPU服务器上推理过程不依赖外网。财务部的扫描件上传后文件流只走内网链路。二是网络隔离。RPA执行器和AI服务之间走内网API调用执行器所在服务器不开公网映射。外网访问只保留一条运维通道且经过堡垒机审计。三是权限与审计。所有自动化任务都记录操作日志谁在什么时间让机器人做了什么全部可追溯。涉及敏感字段的读取在日志里做脱敏处理。2. 核心组件部署与关键配置2.1 RPA运行环境的私有化搭建RPA产品市面上不少国产的有影刀、金智维、实在智能国外的有UiPath、Automation Anywhere。选型上我们综合考虑了信创适配、私有化部署的灵活度、中文场景的兼容性最终选了国产RPA平台。原因也很实际售后响应快定制化需求能沟通私有化部署的授权方式更灵活。RPA的私有化部署一般是分成控制台控制端和执行器机器人端两个部分控制台管理流程、分配任务、查看执行日志一般部署在服务器上通过浏览器访问。执行器真正干活的机器人部署在需要操作的电脑或独立的虚拟机上。我们这里用了“控制台多台独立执行器”的结构控制台部署在一台16核32G的虚拟机里数据库用MySQL执行器单独跑了4台Windows Server 2019的虚拟机每台执行器分配了固定的业务系统账号互不干扰。注意执行器的机器一定要保证桌面环境稳定RPA操作界面是模拟真人点击如果目标系统页面经常弹窗、网络卡顿很容易导致元素找不到、流程中断。建议给执行器机器设置统一的休眠策略关闭系统自动更新。2.2 AI能力的本地化集成AI部分是这次方案里最需要打磨的地方。我们需要的核心能力有三块OCR识别、信息抽取、文档比对。OCR选型扫描版PDF要先转成图片再识别。市面上很多OCR引擎我们测过一圈最终用了PaddleOCR的私有化部署版本。原因很朴素开源、可控、中文识别效果好、支持自定义训练。部署时拉取官方镜像挂载GPU资源对外提供HTTP接口。实测下来印刷体合同文本的识别准确率在98%以上手写备注的识别准确率稍低大概85%左右但结合后处理也能用。信息抽取传统做法是写正则或规则但合同模板一变规则就废。我们用了基于BERT的中文预训练模型做实体抽取用历史合同数据微调了一版可以自动抽取出合同编号、甲方、乙方、签约日期、合同金额、付款条件这些关键字段。文档比对比对电子版合同与扫描版合同是否一致用到了文本相似度计算。这个环节原以为简单实际也踩了坑后面细说。AI服务统一封装成一个推理平台用FastAPI写接口模型用ONNX Runtime加速部署在内网GPU服务器上NVIDIA T416G显存。RPA流程通过HTTP调用这些接口拿到结构化的JSON结果再填到业务系统里。2.3 权限隔离、数据加密与审计机制私有化部署不等于就绝对安全内部权限管控同样重要。我们做了三方面设置数据加密合同扫描件和抽取结果在存储层做了AES-256加密密钥放在独立的密钥管理服务里跟数据库分开防止一锅端。权限隔离RPA执行器用的业务系统账号只开通了自动化任务必需的最小权限。比如合同录入这个机器人只有合同模块的新增权限没有删除和修改权限。审计日志每次自动化任务的执行记录包括开始时间、结束时间、处理文件的数量、抽取结果的置信度分布都单独存一份日志表。遇到数据争议能从日志里追溯完整的处理链路。3. 关键流程的实操落地3.1 流程梳理与自动化可行性评估这一步最容易被忽视但恰恰是最关键的。我们当时跟财务部、法务部开了三轮需求对齐会议把合同处理的完整流程画出来业务人员接收电子版合同PDF或Word检查合同是否签字盖章把合同信息录入ERP系统财务核对金额与条款归档保存评估后确认接收、录入、归档这三步适合自动化但“检查是否签字盖章”这个环节先保留人工原因是盖章检测的误判率会直接影响后续流程需要AI模型进一步优化后再考虑自动化。经验梳理流程时一定要搞清楚每个节点的异常分支。正常流程谁都能写清楚但大量的精力应该花在“客户传错文件怎么办”“系统里查不到对应供应商怎么办”“重复提交怎么办”这些异常场景上。3.2 场景一合同信息抽取与系统录入这个场景是RPAAI配合最典型的例子。流程设计如下步骤1RPA监控文件目录。业务人员把PDF合同放到指定目录后RPA流程被触发。这里我们没有用FileSystemWatcher的实时触发而是用了控制台的定时轮询策略每3分钟检查一次目录避免多台执行器同时抢文件。步骤2调用AI识别服务。RPA把PDF传给OCR服务OCR服务先判断文件是不是扫描版通过检测是否包含文本层如果是扫描版就转图片识别再传给信息抽取模型最终返回JSON{ contract_no: HT-2023-0892, party_a: 某某科技有限公司, party_b: 某某供应链管理有限公司, sign_date: 2023-09-15, amount: 1580000.00, payment_terms: 合同签订后30日内支付30%验收合格后60日内支付70% }步骤3字段校验与录入。RPA拿到JSON后做两件事一是把金额这类关键字段跟合同首页的OCR结果做交叉校验防止抽取错误二是打开ERP系统把字段值填入对应位置。步骤4异常处理。如果抽取模型返回的置信度低于阈值比如0.85RPA不会直接录入而是打上“待人工确认”的标记把文件转移到人工复核目录同时发送通知。这一步非常关键宁可让机器“示弱”也不要让错误数据主动流进ERP。3.3 场景二财务对账与报表生成合同录入之后还有一块自动化需求是财务对账。原来是会计每月从银行系统、ERP系统分别导出流水用Excel手工做匹配每月要花两天时间。自动化方案RPA每月定时从银行系统导出对账单Excel格式RPA从ERP系统导出应收/应付数据用Python脚本做匹配按“金额日期合同编号”三个维度匹配匹配不上的记录单独生成差异表推送给财务人员复核匹配成功的记录生成记账凭证草稿RPA录入到财务系统这里涉及一个技术决策为什么不用RPA自带的Excel操作组件而是用Python脚本因为对账逻辑涉及大量数据清洗和多条件匹配RPA的Excel组件在处理复杂逻辑时表达能力有限调起来也费劲。我们的做法是把对账逻辑写成独立的Python服务RPA只做“导文件、调接口、传结果”这些事。这种“RPAPython脚本”的组合在实际项目中比纯RPA方案要灵活得多。3.4 业务流程的异常处理设计自动化流程的稳定性很大程度上取决于异常处理做得怎么样。我们在每个环节都设计了异常分支文件读取异常文件被占用、密码保护、扫描件质量太差AI服务超时模型推理时间过长RPA设置重试机制三次重试仍失败就转人工系统元素未找到业务系统页面改版、弹窗遮挡数据校验不通过抽取结果为空、金额对不上、日期格式不对每个异常都有预设的处理路径而不是简单地把流程停掉。比如系统元素未找到的情况RPA会截图保存现场把错误信息发到运维群防止问题被静默吞掉。4. 踩坑实录那些文档里不会写的教训4.1 环境依赖与兼容性问题这是整个项目里最折磨人的坑。RPA执行器的Windows虚拟机在一次安全加固后无法正常打开Chrome浏览器。排查了半天发现是安全策略把Chrome的自动化调试端口给禁了。RPA操作浏览器本质上是通过Chrome DevTools Protocol控制的端口被禁之后元素定位全部失效。类似的问题还有国产化电脑上的Edge浏览器版本差异导致RPA组件库不兼容Python服务部署在Linux上RPA执行器在Windows上跨平台文件路径的分隔符处理不一致OCR服务更新了模型版本但旧任务还在用旧的推理逻辑导致抽取字段格式变化解决思路是凡是界面操作、环境依赖相关的变更都要先经过测试环境验证再上生产。我们后来建了一个跟生产环境配置一致的测试虚拟机RPA流程发布前都先在这上面完整跑一遍。4.2 模型推理性能瓶颈合同识别这个场景一天要处理大概150份合同每份合同扫描件平均25页。刚开始上线时发现AI服务经常超时一份合同OCR加信息抽取要跑4分多钟比人工录入还慢自动化就失去了意义。排查后发现两个问题一是GPU资源分配不合理。OCR和BERT模型共用同一张T4显卡OCR推理时显存占用高把信息抽取的推理挤到了CPU上执行。后来分开部署OCR用GPU信息抽取模型用CPU推理加ONNX优化总算分开了。二是大量无效调用。每次RPA请求OCR服务时会把整个PDF所有页都识别一遍但合同首页往往就包含核心字段。优化成“先识别前3页关键字段缺失再全量识别”之后单份合同的处理时间降到40秒左右。实操建议给AI服务加缓存。相同文件的重复请求直接返回历史结果省掉大量重复推理。这个在重试场景下特别有用。4.3 无人值守调度与流程编排“无人值守”这四个字说起来简单做起来坑特别多。第一天晚上跑自动任务早上来一看流程停在“确认是否删除已有合同”的弹窗上——这个弹窗只在当天页面更新后才出现之前测试环境根本没有。所以异常处理设计时不能只看正常页面的元素要多考虑系统升级、提示变化这些动态因素。还有一个问题是调度冲突。4台执行器并行跑任务偶尔会出现两台执行器同时处理同一个文件。后来引入了分布式锁用Redis的SETNX命令保证文件级别的互斥if redis.set(ffile_lock:{file_name}, 1, nxTrue, ex600): process_file(file_name) else: log_and_wait(file_name)4.4 与业务系统的对接细节老业务系统没有提供API这是当初决定用RPA的原因。但用RPA操作老系统也有不少麻烦老系统的前端框架比较陈旧页面元素定位不稳定刷新之后某些按钮的id会变化。文件上传控件是ActiveX的RPA无法直接操作只能模拟键盘输入路径来绕过。系统的超时时间设置很短AI服务处理时间超过系统session时限RPA还在处理AI结果页面已经退出登录了。最后一个问题尤其头疼。解决方案是调整RPA的执行顺序先在空闲时间把文件提前下载并调用AI服务等AI结果保存在本地后再实际操作业务系统上传。相当于把“AI处理”和“系统录入”两个阶段解耦减少在页面上停留的时间。5. 常见问题速查与个人经验5.1 问题速查表问题现象排查方向解决思路元素定位失败流程随机中断提示找不到控件页面是否改版/弹窗遮挡定期做页面巡检改用相对XPath定位OCR识别率低关键字段为空或识别错误扫描件质量、模型精度优化图像预处理、补充训练数据调度重复处理同一文件被多台机器人处理缺少分布式锁引入Redis锁确保文件级互斥AI服务超时单份文件处理时间过长GPU资源、推理策略分开部署模型、增加缓存、优化识别范围页面会话过期长时间自动操作掉线系统超时设置解耦AI处理与系统录入减少页面停留时间文件路径跨平台问题Windows/Linux路径拼接错误代码中硬编码分隔符统一用pathlib或os.path处理5.2 一些个人经验与反思这个项目做完我最大的感受是RPAAI私有化部署难点不在技术而在预期管理。技术层面RPA和AI都是相对成熟的工具踩坑也能解决。但业务方一开始对自动化的预期是“全自动零人工100%准确”实际上这三个目标互相矛盾完全无人值守意味着异常处理极其复杂追求100%准确AI不可能做到。最后我们达成的目标共识是“人工介入率降低80%核心字段抽取准确率≥95%”。这个标准更现实也更容易验收交付。另一个体会是自动化流程是长期维护的项目不是上线就结束。业务系统的页面改版、合同模板的变化、模型的识别效果波动都需要持续的运维投入。我们专门设了一个运维小组的排班制度每周检查RPA任务的执行成功率、AI模型的识别准确率发现下降趋势就及时介入。如果现在让我重做一遍我会在项目初期就建好一套完整的效果监控体系把每个环节的成功率、耗时、异常类型全部可视化出来。数据说话比事后排查高效得多。这个方案跑了一年多现在稳定处理着合同审核、财务对账、报表生成三类业务每月累计自动化执行超过2000个任务。私有化部署这条路前期投入大、见效稍慢但换来的数据安全可控在当前的合规环境下这笔账值得算。
