私有化部署RPA+AI：实现数据不出域的企业智能自动化

这两年我一直在一线做企业级智能自动化落地，接触最多的不是技术选型难题，而是业务和IT两边的拉锯。业务部门说Excel录入做到吐、跨系统核对天天加班；IT部门则是安全红线一条条摆在桌上：系统不能乱接、数据不能出网、供应商不能碰客户信息。两边目标看似矛盾，最后往往汇成一个明确需求——我要一套私有化部署的 RPA+AI 方案，自动化照跑，数据不出域。

这个需求听起来不复杂，真正落地的时候却涉及选型、架构、模型部署、流程治理一大堆事。很多团队在POC阶段跑得很欢，一到生产环境就开始翻车。今天我想把一套相对完整的落地思路和踩坑经历梳理出来，重点聊三个部分：为什么必须走私有化路线、RPA和AI怎么在内网里配合、以及上线半年里我处理的那些“文档里不会写”的故障。如果你正在评估类似方案，或者已经在私有化自动化的路上煎熬，这篇应该能帮你少走不少弯路。

1. 为什么是私有化部署 + RPA + AI：三个痛点凑一块的必然选择

1.1 数据合规与“不出域”的真实压力

先说数据不出域这五个字。很多非技术人员一听，觉得“不就是把服务器放公司里吗”，实际远没那么简单。企业数据通常分地域、分密级、分归属，业务系统里随便导出一张订单表，可能同时涉及客户个人信息、供应商结算数据、内部成本结构。这类数据一旦进入公有云SaaS工具或者外部API，轻则违反内部数据安全管理办法，重则触碰监管红线，造成合同纠纷甚至行政处罚。

我接触过的客户里，金融、政务、医疗这几个行业对数据出域几乎是零容忍。银行连日志都要分级存储，医院的患者信息绝不能落到第三方平台，政务系统的数据更要留在政务网内。即便是普通制造企业，研发图纸、BOM表、供应商报价这些商业机密，也很难接受放到外部AI平台做处理。所以“私有化部署”在大多数情况下不是技术偏好，而是合规底线。

这也决定了后面所有技术选型的大前提：RPA机器人要跑在内网环境，AI模型也必须部署在内网或专有云，训练和推理全部走内部通道。外部API只做参考，绝不承载核心业务数据。

1.2 RPA 在私有化环境里的定位

RPA，通俗讲就是让软件机器人模拟人在电脑上的操作，自动完成重复性的业务流程。它最大的价值不是“智能”，而是“稳定”和“听话”——按既定规则点击按钮、填表、读取Excel、调用接口，7×24小时不带脾气。传统RPA在私有化环境里已经是很成熟的技术，企业把机器人控制器、执行器装在自己的服务器上，流程脚本也存在本地，天然就是数据不出域。

但纯粹的RPA有几个明显短板：只能处理结构化规则清晰的场景，碰到验证码图片、合同PDF、客服消息这些非结构化内容就抓瞎；流程一变就要改脚本，维护成本高；遇到需要判断语义、做决策的环节，写死的规则根本没法覆盖。这也是为什么现在聊自动化，几乎必然会把AI加进来——RPA解决“手”的问题，AI解决“眼”和“脑”的问题。

1.3 为什么一定要叠上 AI 这一层

我之前做过一个发票自动录入项目，传统RPA能做的只是把发票PDF里的文本提取出来填到系统里。问题是实际发票版式参差不齐，有扫描件、有电子发票、有照片翻拍，传统规则提取每换一种版式就得调一轮正则表达式，噩梦一样。后来把OCR和文档理解模型接进来，机器人先“看”发票，再“读”出关键字段，准确率从70%多直接提到98%以上，整个流程才真正稳定下来。

类似的场景还有客服工单自动分派、合同关键条款比对、财务报表自动复核。这些任务里都有大量的非结构化数据和语义判断，纯靠RPA规则写不现实，必须由AI模型支撑。而且AI模型通过私有化部署和RPA做成一套管道，数据在模型和企业系统之间闭环流动，对外零暴露，这才能完整回应“智能自动化 + 数据不出域”的双重诉求。

2. 方案选型与架构设计：先把地基打对

2.1 私有化 RPA 工具的选型逻辑

市面上RPA工具分几类：商业产品、开源框架、自研平台。我在私有化项目里通常按下面几个维度评估，列个表格方便对比：

我最近两个项目用的一是影刀RPA，一是开源框架。影刀在应用迁移和脚本兼容性上做得不错，方便快速搭建，比较容易在私有化环境里做出效果；开源框架则强在可定制性，团队有Python基础可以深度改造。选型时没有必要盲目追新，关键看团队的技术储备和场景复杂度。

2.2 AI 能力怎么放进内网：模型选型与部署方式

AI部分目前最常见的需求是OCR识别、文档结构化、智能问答和语义分类。部署方式从轻到重有三种：

第一种是CPU推理的小模型，比如针对票据识别的PaddleOCR、针对文本分类的BERT轻量化版本。这类模型对硬件要求低，几个核的CPU就能跑，适合量大但任务简单的场景。

第二种是单机GPU部署的中型模型，例如表格结构识别、文档版面分析、实体抽取这类任务，一般用8GB以上显存的显卡加载一个微调过的模型服务就能处理。

第三种是大语言模型，用于合同问答、报告生成、工单语义理解等复杂任务。这时需要用到量化技术或者分布式推理框架，比如GGUF量化把模型压缩到几GB，单卡就能跑，或者用vLLM做高并发服务。我把LLM做私有化部署时，最常踩的坑是显存预估不足——模型文件大小只是基础，KV Cache、输入输出的临时显存占用经常是模型体积的2到3倍，上线前必须压测。

无论选哪种，模型和数据都要放在企业内网，推理服务只监听内网端口，RPA脚本通过内网HTTP接口调用。这样从物理链路到逻辑链路都做到数据不出域。

2.3 整体架构与数据流向设计

我一般习惯把整套系统拆成四层：

• 流程与自动化层：RPA控制台、机器人执行器、任务调度
• AI服务层：OCR服务、文档理解服务、LLM推理服务，统一封装成RESTful API或gRPC接口
• 集成与中间件层：消息队列、数据库、对象存储，用来解耦各环节
• 业务系统层：ERP、OA、财务系统、门户后台等目标系统

数据流向大概是：RPA先从业务系统采集数据或文件，把文件交给AI服务做解析，AI返回结构化结果，RPA再按规则写入目标系统，全程都在内网走一圈。我在设计阶段会额外画一张“数据流向图”，把每一步数据经过什么服务、落在什么存储、谁有权访问标清楚。这张图既是给技术团队看的，也是给合规团队看的，评审效率能提高不少。

3. 落地实操：从流程盘点、脚本开发到内网模型调用

3.1 流程盘点：什么样的业务适合先上 RPA+AI

我总结了一个“老三样”筛选法：高频、重复、规则相对明确。高频看执行频次，一天几十次以上的录入比对值得做；重复看人工操作步骤，10步以上的流程收益明显；规则明确指的是业务逻辑能写清楚，哪怕中间需要AI做判断，判断的出入口也要清晰。

比如财务发票入账，这是最典型的RPA+AI场景：业务人员收票后由机器人识别发票信息，自动填单、勾稽、推送审批，数据全程内网处理。再比如订单稽核，从多个系统拉数据做交叉比对，AI负责识别异常描述，RPA负责执行处理动作。客服工单分类也一样，AI读懂工单内容，RPA去派发到对应部门并回执。

流程选得好不好，直接决定项目能不能成功。我见过一个团队上来就挑了个特复杂的合同审核流程，流程判断条件七八层，AI模型怎么调都不满意，最后项目拖了半年没上线。选流程的时候一定忍一手，先把最简单、最痛、最独立的场景跑通，有了成功案例再逐步扩展。

3.2 脚本开发中的关键细节：参数、接口与异常处理

RPA脚本写起来不难，难在写“防御性”脚本。我复盘过多次线上事故，发现最大的问题往往是这几个：

• 元素选择器写得太死，页面稍微改个class就挂
• 异常处理只有一层try-catch，网络超时或弹窗变化时直接死掉
• 写库和回写操作没有幂等设计，同一批数据重复运行就产生脏数据
• 日志只有“成功/失败”两级，排查问题时毫无线索

私有化环境里没有外部SaaS那种现成的“监控大屏”，日志和告警要自己做扎实。我的习惯是每个关键步骤都打印结构化日志，记录当前流程名、任务ID、操作对象、结果状态和耗时，统一收集到日志平台。脚本里还要设计“失败重试+人工补录”双通道，重试超过两次就转人工队列，不能无限循环死磕。

参数化设计也很重要。数据库连接串、接口地址、模型服务地址绝不能写死在脚本里，要用配置中心或环境变量维护。我之前吃过一次亏：一个脚本里数据库地址写死成测试库，发布到生产直接连错库，还好发现得早，否则数据污染就是大事故。

3.3 内网模型调用的实现方式与性能调优

RPA脚本调用内网模型，最简单的方式是通过HTTP请求，封装成“传入文件路径或Base64，返回结构化JSON”的标准接口。比如OCR服务接口：

curl -X POST http://10.0.1.30:8010/ocr \ -H "Content-Type: application/json" \ -d '{"file_id": "2024xxxx.pdf", "page": "1"}'

返回结果示例：

{ "code": 0, "data": { "invoice_no": "91410000xxxx", "amount": "12800.00", "seller_name": "某某科技有限公司" }, "cost_ms": 860 }

这里有个容易忽略的点：如果文件在内网对象存储里，接口传文件路径比传Base64更高效，省去大量网络传输和内存开销。文件体积大、数量多时，还需要用消息队列做异步处理，避免同步请求占用太多连接。

性能调优上，我一般分三层。第一层是模型层，优先做输入预处理，比如图片先做方向纠正和裁切，不要整张原图丢给模型；第二层是服务层，设置合理的并发数和超时时间，给模型服务开线程池、调好显存分配；第三层是流程层，RPA侧对可并行任务做并发执行，但要注意流控，别把内网其他系统打崩。

4. 踩坑实录与排查心得：我踩过的几个坑

4.1 数据不出域不等于数据不流动：网络隔离带来的连锁问题

第一个坑来自对“不出域”的机械理解。有客户要求RPA机器人和AI服务完全断网，结果模型授权服务无法访问，OCR组件的证书又过期了，上线当天就瘫痪。困在网络隔离环境里的自动化系统，连基本组件更新、授权校验有时候都过不去。

我的处理方式是做“最小化出域白名单”：允许访问固定的许可服务器域名，其他一律封锁；所有模型文件离线打包安装；证书和内网DNS提前规划。这个白名单要经合规团队审批、有明确记录和时限。数据虽然不出域，但系统总要和外部做必要的通讯，这个平衡要提前设计好，而不是一刀切。

4.2 OCR模型效果在真实业务数据上的坍缩

做发票识别的时候，开发环境测试集准确率能到99%，一到生产环境直接掉到85%以下。原因千奇百怪：扫描件有摩尔纹、盖章压住了文字、发票代码和号码有噪声、打印机字体不够清晰、手机翻拍角度倾斜。这类问题不是靠调模型参数能解决的，必须建真实业务样本集，持续补充hard case做模型微调。

我的做法是上线初期把识别失败的样本自动收集到人工审批队列，每周抽几个批次做错误分析，把代表性样本加入训练集，每两周做一次增量训练。跑了两个月后准确率才稳稳站在98%以上。这个“闭环迭代”的过程必须设计到项目计划里，否则模型越跑越烂。

4.3 任务调度、并发与资源冲突

RPA自动化跑起来会产生一类容易被忽略的冲突：不同任务同时操作同一个系统、同一批Excel文件或同一个数据库表，导致互相覆盖、死锁、重复提交。最典型的是月末财务集中做账，好几个机器人同时在同一个账套里跑，发票单号重复，生成凭证乱掉。

解决方案有两层。第一层是任务编排，把高冲突的流程错峰执行，或按账号、公司、业务段做数据分片隔离；第二层是加分布式锁，操作关键资源前先占锁，处理完再释放。分布式锁可以用数据库实现，也可以用Redis，逻辑不复杂但必须写进标准模板里。还要限制单机机器人的并发数，CPU和内存被打满后会直接影响其他业务系统，这个量要实测出来，不能拍脑袋。

4.4 运维与监控：自动化跑通了，谁来管？

自动化上线后最容易被忽视的就是运维。以前人工流程出了问题，人就在工位上，很快能发现；现在机器人半夜跑挂了，没人知道，第二天业务部门打开系统才发现数据没同步。所以监控和告警体系必须和自动化系统同时上线。

我的实践是：RPA关键任务执行完发结果到企业微信/钉钉/邮件，标记成功或失败；AI服务用Prometheus采集指标，比如每分钟请求数、平均耗时、模型推理失败率；日志收集到统一平台，支持按任务ID检索；告警规则不能太迟钝，也不能太灵敏，我通常先跑两周基线，再设阈值。这里也建议准备一个“值班手册”，把常见故障的排查步骤写清楚，别等出了问题才现想流程。

4.5 大模型推理服务的隐性故障

私有化部署大模型时，我遇到最多的隐性故障是“服务假死”。表面上进程还在，端口也能通，但响应越来越慢直到超时。排查下来往往是显存碎片化、请求过多导致排队积压，或者单条上下文太长把显存打爆。解决方式是通过模型服务框架配置并发限制和最大输入长度，加请求排队机制，并对慢请求做熔断降级。RPA侧也要设计好超时时间，别让脚本傻等一个注定失败的请求。

5. 一点经验总结与后续扩展

5.1 上线半年后的真实体会

做私有化 RPA+AI 这个方向，最考验人的不是技术本身，而是工程化落地的耐心。我在实际操作中最大的体会是：技术方案选型只是开始，后面持续的样本迭代、流程治理、监控优化才是长期工程。数据不出域既是约束也是优势——它逼着团队把系统做扎实，不依赖外部厂商，所有能力都沉淀在自己手里。

工具选型的时候也别迷信某一个厂商的“全家桶”，实际项目里很多团队是“RPA用一套、AI服务自己搭一套、监控再自己接一套”，只要接口标准统一，最后照样能跑得很顺。

5.2 从 RPA+AI 到智能体协作的扩展方向

项目稳定运行之后，我开始往Agent方向琢磨。传统RPA是“指令式”的，每条流程都是人工预先写好的轨道；叠加AI模型之后，机器人可以处理一部分不确定信息，但整体执行路径还是可以预判的。再往前一步，如果让多个智能体通过语义理解自主拆解任务、互相配合完成目标，那自动化的边界会大很多。我现在就在试点把合同审核的RPA流程拆成“信息抽取Agent + 条款比对Agent + 审批推荐Agent”三个协同单元，数据依然全程内网闭环。

最后分享一个小的实操技巧：任何RPA+AI私有化项目，都要准备一套完整的“接口契约文档”，把所有AI服务的输入输出字段、示例、错误码写清楚，RPA团队和模型团队按契约并行开发。我见过太多项目因为没有契约文档，两边联调一周都没法对接，有了它，交付速度能快一倍以上。