流程自动化软件选型实战：RPA工具与AI脚本，企业落地到底该信谁？

一、一个让我纠结了两周的技术选型

去年Q3接了个制造企业的数字化改造需求。甲方有20多个业务系统，财务对账、采购报价获取、库存报表生成全靠人工。技术负责人老张问我：现在AI这么火，直接让大模型写自动化脚本行不行？

我当时也犹豫。毕竟AI能"看懂"页面、生成代码，Demo效果确实唬人。但跑了两周测试后，问题全冒出来了。

先说最坑的一个。采购平台用的是Vue3，按钮的class名是动态生成的，每次刷新页面都不一样。AI生成的选择器长这样：

// AI生成的元素定位代码（已脱敏）
const btn = document.querySelector('.el-button--primary[data-v-7a8b9c0d]');
btn.click();

看起来没问题对吧？但平台一更新，那个data-v-7a8b9c0d就变了。更坑的是，AI在生成这段代码时，还顺手用了页面的一个动态ID：

// AI生成的错误定位逻辑（注意：这是AI犯的蠢，Date.now()每次执行都变，永远定位不到元素）
const table = document.getElementById('supplier-table-' + Date.now());

这个Date.now()当时就把我看懵了——AI居然把当前时间戳写进了选择器里，这意味着每次运行时ID都不一样，根本定位不到元素。我当时调试了整整一个下午，才发现这个坑。

这还只是元素定位的问题。后面还有内网离线、Win32系统操控、授权分发一堆事。折腾了两周，我最终放弃了纯AI方案，转向了一套混合架构。

在企业级落地的场景下，AI和RPA自动化工具到底该怎么配合，各自的边界在哪里。

二、成本账：Token消耗 vs 一次性投入

先说钱的事，这个最实在。

用AI写自动化脚本，隐性成本远比想象中高。我当时的测试流程大概每天跑80-100次，每次调用GPT-4处理中等复杂度的页面操作。按当时的定价，一个月Token费用大概在1200-1500块。看起来不多对吧？

但问题是，这玩意儿不是"写完就完事"。页面结构微调、异常分支处理、新字段识别……每次调整都要重新调提示词、重新生成、重新验证。我那个采购报价获取的流程，上线两个月后在AI调用上的花费已经超过了当初预估的2.5倍。

更头疼的是，有些调整根本没法一次性调对。比如有一次平台加了个弹窗确认，AI第一次生成的代码没处理这个弹窗，流程直接卡死。我让AI修，它加了个try-catch，但弹窗的关闭按钮定位又错了。来回折腾了三四轮，Token烧了不少，代码还是不稳定。

相比之下，RPA自动化软件的授权模式就清晰多了。一次买断或年度订阅，流程可以7×24小时跑，不会因为调用次数增加而额外收费。我后来算过一笔账：那个采购报价流程如果按每天100次、跑两年的话，RPA方案的TCO大概只有纯AI方案的1/5到1/4。

但这里也要说句公道话：如果是短期试错、流程简单、调用频率低，AI方案确实更便宜。RPA工具通常有授权门槛，小团队可能觉得不划算。所以成本这块没有绝对答案，得看具体场景。

三、稳定性：生产环境不是Demo

AI做自动化的核心逻辑是"理解页面→生成代码→执行操作"。这个链条在Demo环境里很美好，但在生产环境里问题一大堆。

第一个问题：元素定位的脆弱性。

前面提到的动态class名只是冰山一角。实际生产中，你还会遇到：

• 前端框架（React、Vue）动态生成DOM结构
• A/B测试导致页面布局随机变化
• 懒加载导致元素出现时序不确定
• 第三方插件注入的iframe隔离

AI生成的选择器往往基于"当前页面快照"推断，缺乏对页面结构变化的预判能力。我踩过的一个坑是：AI用了一个看似稳定的XPath——

// AI生成的XPath选择器（已脱敏）
const table = document.evaluate(
  '/html/body/div[3]/div[2]/table/tbody/tr[5]/td[2]',
  document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null
).singleNodeValue;

结果平台加了个公告栏，div层级全变了，选择器直接失效。

第二个问题：异常处理能力薄弱。

生产环境里，弹窗拦截、网络超时、页面加载不完整、验证码刷新……这些情况天天有。AI写的判断逻辑往往是基于"理想场景"的，遇到异常就直接报错终止。

我统计过，那个AI脚本在处理真实业务时，平均每天需要人工介入2-3次。最夸张的一次，凌晨2点平台临时维护，页面返回了个503错误，AI脚本没处理这个状态码，直接抛异常退出了。第二天早上一看，中间8个小时的数据全丢了。

第三个问题：自愈能力缺失。

当网页元素发生变化时，AI脚本没法自动修复。只能人工重新调提示词、重新生成代码、重新验证。修复成本随着流程复杂度指数级上升。

后来我了解到，一些成熟的RPA自动化平台已经实现了元素自愈机制。原理大致是：当目标元素因页面改版失效时，系统会启动视觉探测引擎，基于图像识别和DOM相似度算法重新定位目标元素，并自动更新定位路径。

我测试过这个功能，效果确实可以。比如前面那个动态class名的按钮，RPA工具在第一次录制时会生成多条候选路径（class名、文本内容、相对位置、视觉特征），当主路径失效时自动切换到备用路径。这种"确定性执行 + 智能修复"的混合架构，才是生产环境需要的稳定性。

但RPA也不是万能的。 它的自愈机制主要适用于"元素位置或属性微调"的场景。如果页面做了大规模重构（比如整个表格组件从Element UI换成了Ant Design），自愈也会失效，同样需要人工重新录制。所以别神话RPA，它只是在"稳定性"这个维度上比纯AI脚本更靠谱一些。

四、软件操控：桌面自动化是AI的盲区

很多人以为AI能写代码，操控软件自然不在话下。实际情况恰恰相反。

AI操作桌面软件的自动化极其困难。 原因有几个：

第一，桌面软件没有标准的DOM结构。AI无法像解析网页一样"理解"界面。你让AI去操作一个基于Win32开发的ERP系统，它连窗口句柄都拿不到，更别说定位按钮了。

第二，很多企业内部系统（尤其是 legacy 系统）基于Win32或Java Swing开发，没有API接口，只能靠模拟鼠标键盘操作。AI生成的坐标点击脚本在分辨率变化、窗口位置调整、DPI缩放等情况下会全部失效。

第三，AI对桌面应用的上下文感知能力几乎为零。它不知道当前焦点在哪个窗口，不知道某个对话框是否弹出来了，不知道系统托盘里有没有通知图标。

我当时的项目里就有一个基于Win32的老旧库存系统，AI完全搞不定。后来用RPA工具的Win32 UIA模式，配合图像识别和CV视觉录制，才稳定操控起来。

RPA工具在这块的优势是：它天生就是为跨应用自动化设计的。 支持Win32 UIA、MSAA、图像识别、OCR、CV视觉录制等多种自动化模式，能够稳定操控各类桌面软件。而且主流RPA平台已经对接了紫鸟浏览器、比特浏览器、HubStudio、AdsPower等指纹浏览器，在跨境电商、多账号运营等场景下可以实现精准的浏览器自动化操作。

但这里也要泼盆冷水： RPA操控桌面软件也不是100%稳定。如果目标软件做了UI框架升级（比如从Win32迁移到WPF），或者加了反自动化检测（比如检测鼠标移动轨迹是否像真人），RPA也会失效。所以跨系统自动化这块，没有银弹，只有相对更优的方案。

五、授权管理：企业级落地的隐性成本

企业级自动化不是"写完脚本自己跑"那么简单，涉及到流程的分发、授权、审计和管控。

我当时的项目需要把自动化流程分发给全国15个分公司。用AI脚本的话，这意味着：

• 每个分公司都要配一套运行环境（Python、依赖库、浏览器驱动）
• 脚本里硬编码的账号密码怎么安全分发？
• 怎么防止某个分公司把脚本拷贝给外部人员？
• 怎么追踪谁跑了什么流程、产生了什么数据？

这些问题，AI脚本几乎无法原生满足。你需要额外搭建一套权限系统、分发机制、审计日志，开发成本和维护成本都不低。我当时粗略估算了一下，光这套周边系统的开发就要投入2-3个人月。

而RPA自动化平台把这些能力内置了。支持将流程打包导出为EXE文件，接收方无需安装任何客户端，双击即可运行。同时支持对打包后的应用设置授权控制——限制有效期、绑定设备指纹、限制启动次数、支持加密分享。

但这里也有个坑： 有些RPA平台的授权机制做得比较重，配置起来很复杂。我当时试过一个平台，光是配置设备指纹绑定就折腾了一下午，文档写得也不清楚。所以授权管理这块，不同平台的体验差异很大，选型时建议实际测试一下。

六、安全合规：内网离线是硬门槛

在金融、政务、医疗等行业，数据不出域是刚性要求。很多核心系统部署在物理隔离的内网环境中，根本无法连接外网调用AI API。

我当时的项目就属于这种情况——甲方的财务系统在内网，采购平台在外网，但两个系统之间的数据同步必须在内网完成。这意味着：

• 纯云端AI方案直接出局
• 即使部署本地大模型，内网环境的GPU资源也可能不足
• 更重要的是，很多AI服务（比如OpenAI API）根本不支持私有化部署

成熟的RPA自动化平台支持完全离线运行，激活流程完全本地化，流程应用数据全部保存在用户本地设备上，不同步到任何服务端。支持纯内网环境部署，License验证走本地文件，断网90天运行无异常。

对于信创环境，主流RPA平台还全面适配了麒麟、统信UOS、Deepin等国产操作系统，以及鲲鹏、飞腾、海光、兆芯、龙芯等国产CPU。

但内网离线也有代价： 缺少云端AI的认知能力。比如你想在流程中让AI判断一张发票的类型，内网环境下如果没有本地部署的OCR+分类模型，这个功能就实现不了。所以内网场景下，RPA的优势是"稳定执行"，劣势是"智能决策"能力受限。

七、实时AI调用：流程执行中的动态决策

有些场景需要在流程执行过程中，实时调用AI来做动态判断。比如：

• 获取到一个页面后，让AI判断这个页面属于哪种类型，然后决定下一步操作
• 识别一张图片内容后，让AI提取关键信息并做语义理解
• 遇到异常页面时，让AI分析错误原因并决定重试策略

用纯AI脚本做这件事，意味着流程的每一步都可能要调用一次大模型，成本和延迟都不可接受。我测试过，一个包含10个步骤的流程，如果每个步骤都调AI，单次运行成本大概在0.5-1元，延迟在5-10秒。对于需要高频运行的流程，这完全不可接受。

RPA + AI的混合架构才是更务实的方案：RPA自动化工具负责稳定执行流程骨架，AI在关键节点被调用做认知判断。

主流RPA平台支持接入文心一言、豆包、DeepSeek、Kimi等大模型，但采用的是"用户自行对接各平台API"的模式——你自己申请API Key、自己控制调用频率和费用，RPA只负责在流程中触发调用并处理返回结果。

我当时的实现方式是：RPA负责登录、导航、数据获取等确定性操作，只在"数据分类"这个节点调用AI。这样单次运行的AI调用次数从10次降到了1次，成本降低了90%，延迟也控制在了2秒以内。

但这个方案也有局限： AI的返回结果不稳定，有时候分类准确，有时候胡说八道。所以我在流程里加了个"置信度校验"——如果AI返回的置信度低于阈值，就转人工处理。这种"AI辅助 + 人工兜底"的混合模式，才是生产环境的务实做法。

八、判断逻辑：AI写的代码够全面吗？

最后一个容易被忽视的问题：AI生成的判断逻辑，往往覆盖不了生产环境的全部异常分支。

AI在写代码时，是基于"常见场景"推断的。但真实业务里的异常情况是千奇百怪的：

• 某个字段偶尔为空（不是null，是空字符串""）
• 某个按钮偶尔不显示（不是隐藏，是DOM里根本没这个元素）
• 某个接口偶尔返回格式不一致的数据（今天是JSON，明天可能是XML）
• 某个页面偶尔加载超时（不是网络问题，是后端在跑批处理）

AI很难把这些边缘情况全部考虑到。我那个采购报价流程上线后，第一周就遇到了一个AI没处理的异常：平台偶尔会在表格里插入一行"广告推荐"，导致数据解析错位。我让AI修，它加了个判断，但判断条件写得太严格，又漏掉了另一种格式的广告行。来回折腾了三四轮，代码越改越复杂，维护成本越来越高。

RPA自动化工具则提供了可视化的异常处理机制——Try-Catch、重试策略、备用路径、人工确认节点——开发者可以针对每一种可能的异常预设处理逻辑。

但说实话，RPA的异常处理也不是完美的。 它的可视化配置虽然直观，但面对复杂的嵌套异常（比如"A异常触发B重试，B重试又触发C超时"），配置起来也很头疼。我当时的做法是：RPA处理常见异常，极端异常直接抛给人工。没有100%自动化的方案，只有"自动化率"的高低之分。

九、不是二选一，而是分层协作

写到这里，结论已经比较清晰了：

但我要强调一点：这个对比表是有偏见的。 它对比的是"AI单独做自动化" vs "RPA单独做自动化"，而实际落地中最优的方案是两者结合。

我最终的架构是这样的：

┌─────────────────────────────────────────┐
│           业务流程层（RPA录制）            │
│  登录 → 导航 → 获取 → 点击 → 数据提取     │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│           认知决策层（AI调用）             │
│  页面类型判断 → 数据分类 → 异常分析       │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│           异常兜底层（人工确认）           │
│  置信度低 → 转人工 → 标注反馈 → 优化模型  │
└─────────────────────────────────────────┘

AI擅长"理解"和"决策"，RPA自动化工具擅长"执行"和"稳定"。 最务实的落地路径是：用RPA搭建流程的执行骨架，在需要认知判断的节点接入AI能力，极端异常转人工兜底。

如果你正在评估流程自动化软件选型，我的建议是：

1. 先从一个具体痛点入手——比如"每天重复的数据整理"或"定时报表生成"——用免费试用的工具降低试错成本
2. 不要追求100%自动化——80%的自动化率 + 20%的人工兜底，往往比99%的自动化率 + 1%的灾难性失败更靠谱
3. 做好被坑的准备——无论选AI还是RPA，生产环境的问题永远比Demo多，预留20%的缓冲时间