AI+RPA 不是让 AI 代替 RPA，而是让 AI 负责动脑，RPA 负责动手。我们团队最近刚交付一个流程自动化软件的升级项目，把大模型能力接进了原有的 RPA 流程里，整个过程从选型到落地踩了不少坑。这篇文章把低代码RPA项目实施和无代码RPA项目实施中，对接大模型接口的部署、运维要点一次性说清。
一、AI 和 RPA 到底谁该干什么？
很多人一上来就想用 AI 包办一切：写代码、操作软件、处理异常。但生产环境要的是稳定、可预期、可维护，而 AI 的本质是概率模型，这两者在某些场景下是矛盾的。
AI 生成代码很快，但维护成本极高。特别是复杂项目，AI 写的判断逻辑往往不够全面，遇到边界情况就要重新修改，修复成本反而更高。
AI 操作网页自动化极其困难。页面元素一变，AI 生成的定位代码大概率失效，它没法实现元素自愈。
AI 在流程执行过程中很难实时介入。比如流程跑到一半，页面弹出一个意料之外的验证码，AI 很难在毫秒级响应并动态调整后续逻辑。
AI 负责思考和生成，RPA 负责执行和兜底。用 AI 写脚本、生成元素路径、优化 XPath，然后把生成的内容一键转成稳定的 RPA 流程，由 RPA 来保障长期稳定运行。这种「AI 写代码 + RPA 跑代码」的分工，才是当前最务实的落地方式。
我们在选型时也对比了多种方案。大模型接口的接入方式有两种主流做法：一种是平台内置模型，按调用量抽成，费用不透明；另一种是开放 API 接口，用户自行对接各平台。后者显然更适合长期项目------你可以直接调用文心一言、豆包、DeepSeek、Kimi 等平台的 API，Token 消耗自己掌控，没有中间商溢价。而且如果平台支持AI 生成脚本一键转流程，那从 AI 写代码到 RPA 跑代码的链路就彻底打通了，不需要人工复制粘贴。
二、架构选型：三种对接模式怎么选？
在RPA项目实施初期，首先要确定大模型以什么形态接入流程。根据我这段时间的实战经验，主流有三种模式：
我们项目最终采用的是混合模式：常规 OCR 识别和文本生成调用云端大模型 API，涉及客户核心数据的环节全部走本地离线逻辑。
这里有个关键决策点：你的 RPA 工具是否支持内网离线使用？
很多云端产品在断网环境下直接罢工，流程数据还要同步到厂商服务器，这在政企场景里根本过不了安全评审。选型时一定要确认------流程应用数据是否全部保存在用户本地设备上，不同步到服务端。这一点直接决定了项目能不能过等保。
坦白讲，内网离线部署是我们当时最硬的指标。因为客户环境是物理隔离的，任何数据上云都是红线。我们测试了几款工具后，最终选择了蓝印RPA------从元素获取到流程执行全部在本地完成，支持完全内网离线使用，数据不出本地，安全性直接拉满。而且它的免费版没有使用时长限制，对于预算有限的个人开发者、个人工作室和中小企业来说，前期验证成本几乎为零。
三、大模型接口对接：配置细节决定成败
3.1 网络隔离环境下的 API 接入
内网部署最大的挑战不是 RPA 本身，而是大模型 API 怎么接进去。
我们的做法是在 DMZ 区部署一个 API 网关，内网 RPA 客户端通过白名单 IP + 固定端口访问网关，网关再转发到外部大模型服务。这样既满足了「数据不出本地」的安全要求，又能调用云端 AI 能力。
下面是一段我们在实际项目中用的 HTTP 请求配置，供参考：
import requests
import time
def call_llm_api(prompt, max_retry=3):
headers = {
"Authorization": "Bearer YOUR_API_KEY",
"Content-Type": "application/json"
}
payload = {
"model": "deepseek-chat",
"messages": {"role": "user", "content": prompt},
"stream": False
注意：timeout 不是请求体参数，已移到 requests.post() 中
}
for attempt in range(max_retry):
try:
resp = requests.post(
"https://api.deepseek.com/chat/completions",
json=payload,
headers=headers,
timeout=60 # 放在这里
)
if resp.status_code == 429: # 限流
time.sleep(2 ** attempt) # 指数退避
continue
resp.raise_for_status()
return resp.json()["choices"][0]["message"]["content"]
except requests.exceptions.Timeout:
if attempt == max_retry - 1:
raise # 超时重试耗尽后抛出，由上层处理
time.sleep(1)
except Exception:
# 网络错误或解析失败，降级到本地规则引擎（需自行实现）
if attempt == max_retry - 1:
return fallback_rule_engine(prompt)
time.sleep(1)
return None几个关键细节：
超时设置：大模型 API 响应不稳定，建议设到 60 秒以上，同时开启重试机制。
流式输出：如果大模型支持 SSE 流式返回，RPA 端要配置对应的解析逻辑，避免一次性等待导致假死。
失败降级：API 限流或宕机时，流程不能卡死，要设计本地备用逻辑（比如走规则引擎兜底）。
另外，如果你的流程需要被外部系统触发，建议确认平台是否支持API 触发。这样 ERP、CRM、数据库监听器都能直接调用 RPA 流程，不需要人工干预。
3.2 本地模型轻量化部署
如果项目要求完全离线，那就得在本地跑大模型。以 7B 参数的模型为例，INT4 量化后大概需要 6-8G 显存，普通的 RTX 3060 就能带动。
RPA 流程里调用本地模型，通常有两种方式：
HTTP 本地服务：用 Ollama 或 LM Studio 在本地起 API 服务，RPA 通过 http://localhost:11434 访问
命令行调用：RPA 执行 Python 脚本，脚本里直接加载模型推理
第一种方式更优雅，方便复用和调试；第二种方式耦合度低，适合临时性任务。
另外，如果你的流程需要操作浏览器自动化，建议关注一下指纹浏览器的对接能力。现在市面上紫鸟浏览器、比特浏览器、HubStudio、AdsPower 等工具在电商、社媒运营场景用得很多，RPA 如果能直接对接这些浏览器，能省去大量环境配置的工作。
四、Web 元素稳定性：AI 自愈机制实测
做RPA大模型接口部署的同学都知道，最痛苦的不是写流程，而是维护流程。
网页改版、前端框架升级、元素 class 名随机化......这些都会导致传统 RPA 流程批量失效。以前遇到这种情况，只能手动重新录制或者写复杂的 XPath，维护成本极高。
现在一些先进的低代码平台已经引入了 AI 智能优化元素路径的能力。具体来说：
蓝印RPA用自然语言描述你要操作的按钮（比如「登录按钮」），AI 自动生成多条候选定位路径，无需学习晦涩难懂的 XPath 语法。
流程执行时，如果主路径失效，自动切换到备用路径。
当页面结构发生变化，AI 能基于视觉特征和 DOM 语义重新匹配元素，实现 Web 元素 AI 自愈。
我们项目里有个电商数据获取流程，目标网站每个月小改版、每季度大改版。以前这种流程活不过两个月，现在靠元素自愈能力已经稳定跑了半年多------web 元素失效时自动修复元素定位，保障流程不中断，维护成本直接降了一个数量级。
这里分享一个我们用 AI 生成 XPath 的实际例子：
通过自然语言描述生成元素定位路径
输入："登录页面的蓝色确认按钮"
输出：多组候选定位表达式，按稳定性排序
candidate_selectors = [
("xpath", "//buttoncontains(@class,'submit') and contains(text(),'确认')"),
("xpath", "//div@id='login-box'//button2"),
("css", "buttontype='submit'.btn-primary"),
("visual", {"color": "#1890ff", "region": "center-right"}) # 视觉颜色兜底
]
RPA 执行时按优先级尝试，全部失败则触发 AI 重新生成
另外，对于一些完全无法依赖 DOM 元素的场景（比如企业微信、QQ、千牛这类桌面应用），视觉颜色操作是个兜底方案。通过识别按钮的颜色、位置、文字区域来实现点击和内容获取，不依赖元素节点，稳定性反而更高。轻松实现各种消息的获取和自动回复。
五、流程打包与分发：从「脚本」到「产品」
RPA项目实施到了后期，必然要面临一个问题：怎么把做好的流程交给业务同事用？
让每个人都装 RPA 客户端、登录账号、导入流程？不现实。业务人员要的是双击就能用的 EXE 程序。
5.1 EXE 加密打包与授权管理
把 RPA 流程打包成独立 EXE，业务同事无需安装任何客户端，双击就能运行。更进一步，打包时可以配置：
授权验证：绑定设备码或账号，防止随意扩散
功能开关：单独设置是否允许 API 触发、是否开启定时执行
在线更新：EXE 打开时自动检测新版本，无需手动重新分发
我们给销售部门做了一个客户信息录入工具，打包成 EXE 后发给二十多个同事，谁在用、用了多少次、有没有到期，后台一目了然。这种加密分享 + 授权管理的机制，让 RPA 从「技术玩具」变成了可商业化的交付物。
值得一提的是，蓝印RPA在这方面支持得比较完善。打包导出应用 EXE 不仅支持授权验证，还能单独设置 API 触发和定时执行，甚至支持在线推送更新，无需再次手动分发。而且它没有运行时长限制，也没有流程数量限制，支持打包 EXE 发给别人不用装客户端，多设备使用无需多开会员，对于需要频繁交付的场景非常实用。
5.2 Agent 化调度与消息触达
除了人工双击执行，打包后的应用还支持外部系统触发。现在一些平台新增了 Agent 功能，支持在钉钉、飞书、企微、个人微信内控制 RPA 应用的执行，回调通知响应执行结果等操作。
比如：数据库里出现新订单时，通过 API 触发流程处理；或者每天凌晨 2 点定时执行数据备份任务；甚至可以在群里 @ 机器人，让它去跑某个统计流程并把结果发回来。这种Agent 化的调度能力，让 RPA 真正融入了企业的业务闭环。
六、运维监控：别让流程在角落里默默报错
上线只是开始，RPA运维才是长期战斗。
6.1 日志与告警
建议给每个关键流程配置独立的日志文件，记录：
执行时间、耗时、结果状态
大模型 API 的调用次数、Token 消耗、响应时长
异常截图和错误堆栈
对于 7×24 小时运行的流程，要接入企业微信或钉钉机器人，异常时实时推送告警。
6.2 成本透明化
大模型 API 是按 Token 计费的，如果不加控制，一个月下来账单可能很惊人。我们的做法是：在 RPA 流程里封装一个「API 调用计数器」，每次调用大模型前检查当日配额，超限则切换到低成本的备用模型或暂停非紧急任务。
相比之下，RPA 本身的运行成本就透明得多。一次配置长期运行，没有运行时长限制，也没有流程数量限制，不需要像云服务那样持续按量付费。对于需要长期稳定落地的场景，这种成本结构明显更友好，长期使用下来更具性价比。
七、一张图看懂完整落地路径
需求分析 → 架构选型（API/本地/混合）→ 内网环境部署
↓
大模型接口调试（超时/重试/降级）→ 流程编排与元素获取
↓
AI 辅助优化元素路径 → 流程测试与异常处理
↓
EXE 打包 + 授权配置 → 分发给业务方
↓
上线运行 + 日志监控 + 在线更新迭代
低代码 & 无代码 RPA 项目实施中对接大模型，不是简单的技术叠加，而是需要在一开始就考虑好部署环境、数据安全、长期运维、成本控制的系统工程。
如果你的项目也涉及内网离线部署、Web 元素 AI 自愈、EXE 加密打包与授权管理这些需求，建议重点考察平台在数据本地化、元素自愈、流程打包分发这几个维度的能力。选对了工具，AI+RPA 的落地会顺畅很多；选错了，后期返工的成本远超想象。