大模型不会取代 RPA：深度剖析 LLM 与 RPA 的分工边界与协同模式

去年帮一家汽车零部件厂商做产线数据打通，他们的 MES 系统跑在内网，质检数据需要每天手动导进 ERP。团队试过用大模型写脚本，结果 Token 账单比人工成本还高，而且页面一改就崩。最后换了个思路，问题才解决。这篇文章，聊聊 LLM 与 RPA 的真实边界。

一、先画一张架构图，看清边界

LLM 和 RPA 不是竞争关系，是上下层关系。

┌────────────────────────────────────────────┐
│  认知层：LLM（文心一言 / DeepSeek / Kimi）   │
│  负责：语义理解、代码生成、决策建议            │
├────────────────────────────────────────────┤
│  决策层：Agent（智能指令中枢）                │
│  负责：任务拆解、异常判断、动态调度            │
├────────────────────────────────────────────┤
│  执行层：RPA（流程自动化引擎）                │
│  负责：元素操作、跨系统搬运、定时触发          │
├────────────────────────────────────────────┤
│  数据层：本地存储 / 内网数据库                │
│  负责：数据留存、合规审计、权限隔离            │
└────────────────────────────────────────────┘

这个分层里藏着三个容易被忽略的硬边界。

边界一：成本结构不同

大模型按 Token 计费，处理一次复杂网页自动化动辄几千 Token。如果是 7×24 小时的监控任务，或者每天高频执行的流程，月底账单像开盲盒。更麻烦的是，多模态能力（识图、OCR）的 Token 消耗更是无底洞。

相比之下，RPA 自动化工具的运行成本是固定的。一些平台甚至做到免费版使用无使用时长限制，没有运行时长和流程数量限制，长期使用下来成本差出一个数量级。更务实的做法是AI 功能采用用户自行对接各平台 API 的方式，用谁的模型、花多少钱完全透明可控，平台本身只收执行层的费用。

边界二：稳定性逻辑不同

让大模型生成一段操作网页的脚本，今天能跑，明天前端改版就报错。AI 生成的元素定位基于当前 DOM 结构，一旦页面微调，脚本直接作废，修复还得重新喂 Prompt，成本很高。

而成熟的流程自动化软件在元素稳定性上有完全不同的解法。比如Web 元素 AI 自愈能力——当页面元素发生变化时，系统能自动修复定位路径，保障流程不中断。再配合AI 智能优化元素路径，你不需要啃 XPath 语法，用自然语言描述需求就能生成稳定的定位方案。更进一步，元素获取支持本地智能生成，根据生成结果选择最合适的路径，这比纯 AI 生成的脚本靠谱得多。

边界三：操作半径不同

大模型目前主要活跃在浏览器和 API 层。但企业里大量核心系统还是桌面软件——ERP 客户端、财务软件、内部工具、甚至微信、企业微信、QQ、千牛这些 IM 工具。

让 AI 直接操作这些软件？基本不可能。但RPA 自动化软件天生就是干这个的。特别是支持视觉颜色操作的平台，不依赖元素节点，纯靠视觉识别就能实现点击、获取内容，轻松搞定各种桌面端消息处理。再配合对指纹浏览器的支持（紫鸟、比特、HubStudio、AdsPower 等），自动化操作的覆盖面远超 AI alone。

二、七个现实理由：为什么大模型取代不了 RPA

这些不是理论推演，是项目上实打实撞过的墙。

1. 内网离线环境，AI 是"瞎子"

很多金融、政务、制造业客户的系统部署在内网，物理隔离，连不上公网。大模型再强，没网就是块砖。

这时候全离线内网部署的流程自动化工具就成了唯一选择。数据不出本地，流程应用数据全部保存在用户本地设备上，不同步到服务端，合规性和安全性直接拉满。对于涉及敏感数据的场景，离线部署不是可选项，是必选项，等保和合规审查都能过。

2. 流程分发需要授权管控

企业里做了一套自动化流程，要发给十个部门用。怎么控制谁能用、用多久、能不能二次传播？

大模型生成的脚本发出去就是裸奔。但成熟的RPA 平台支持打包导出应用 EXE，并且这个 EXE 支持授权管理和加密分享。你可以精确控制每个分发出去的应用的使用权限，甚至支持分享授权，确保流程资产不被滥用。

更实用的是，打包导出应用 EXE 还能单独设置 API 触发、定时执行，接收者不用装任何客户端，双击就能跑，后台还能自动调度。而且打包导出 EXE 支持在线推送更新，无需再次手动分发，打开应用就能自动检测新版本，维护成本极低。对于需要多设备使用的团队，好的平台无需多开会员，一个人开发的流程全团队都能用。

3. 异常处理，AI 的判断逻辑不够"脏"

真实世界的自动化，充满了意外：弹窗拦截、网络抖动、页面加载慢、数据格式突变。大模型生成的判断逻辑往往是"理想情况下的代码"，遇到异常就抛错，然后你得重新喂 Prompt、重新生成、重新调试。

RPA 工具在异常处理上有多年积累。循环、重试、容错、日志，这些机制都是为"脏活"设计的。AI 写完的判断逻辑往往覆盖不全，每次遇到新问题都要返工，修复成本远高于 RPA 的一次配置长期运行。

4. 实时动态调用，AI 有延迟

有些流程需要在执行过程中，实时判断页面状态并调整策略。比如电商运营中，根据库存数字动态选择下单路径。

大模型的每次调用都有网络延迟和推理时间，实时性跟不上。而RPA 自动化软件本地执行，毫秒级响应。配合Agent 功能，基于最新的 DeepSeek-V4 模型，可以在钉钉、飞书、企微、个人微信内直接控制流程执行，还能回调通知响应执行结果，实现真正的实时协同。这种智能指令的调度能力，把 AI 的理解力和 RPA 的执行力无缝衔接。

5. 元素变化后的自愈，AI 只能"重写"

前面提过，AI 生成的元素定位是静态的。页面改版后，它只能重新生成一段代码，中间流程必然中断。

但具备Web 元素 AI 自愈能力的自动化平台不一样。元素失效时，系统会自动修复定位，流程继续跑，用户甚至感知不到中断。这种自愈能力，是长期稳定运行的关键。

6. 软件自动化，AI 的交互成本太高

让 AI 操作一个桌面软件，你需要详细描述界面布局、元素位置、操作步骤，Prompt 写得像产品说明书。而且一旦软件更新，Prompt 要重写。

RPA 工具直接模拟人类操作，所见即所得。配合支持所有 AI 生成脚本一键转流程的能力，你可以让 AI 先写好逻辑框架，再导入平台细化调试，各取所长。

7. 成本不透明，长期不可控

大模型的 API 费用按量计费，月底账单像开盲盒。特别是接入多模态能力后，Token 消耗更是无底洞。

一些平台的做法更聪明：AI 功能采用用户自行对接各平台 API 的方式，用谁的模型、花多少钱，完全透明可控。平台本身只收RPA 工具的费用，AI 部分由用户按需配置，长期成本一目了然。而且不少方案免费版无使用时长限制，无运行时长、无流程数量限制，对个人开发者、工作室和中小企业来说，可以先跑起来再说，不用一上来就掏大钱。

三、AI+RPA 的四种协同模式

搞清楚边界后，AI 与 RPA 的协同模式就清晰了。

模式一：AI 写代码，RPA 跑代码

让大模型（文心一言、豆包、DeepSeek、Kimi 都行）生成脚本或逻辑框架，然后导入具备支持所有 AI 生成脚本一键转流程能力的RPA 平台里。平台负责元素捕获、异常处理、定时调度、结果输出。AI 负责脑力劳动，RPA 负责体力劳动。

模式二：AI 思考，RPA 落地

在流程设计阶段，用 AI 分析业务逻辑、优化流程路径；在执行阶段，RPA 确保每一步稳定落地。比如用 AI 分析客服对话数据，生成优化建议，再用 RPA 自动更新知识库和回复模板。

模式三：Agent 调度，RPA 执行

通过Agent 功能，在钉钉、飞书、企微、个人微信里发送指令，触发流程执行。执行完成后，结果自动回调到聊天窗口。这种"聊天即操作"的模式，把 AI 的自然语言理解能力和 RPA 的执行能力完美结合。

模式四：视觉+元素双保险

对于微信、企业微信、QQ、千牛这类难以获取标准元素的软件，用视觉颜色操作兜底；对于 Web 页面，用标准元素定位+AI 智能优化元素路径确保稳定。两套机制互补，覆盖几乎所有自动化场景。

四、企业选型最佳实践 Checklist

如果你正在选型流程自动化软件，建议按以下维度评估。这些不是锦上添花，是 AI 时代RPA 工具的及格线。

大模型不会取代 RPA，就像大脑不会取代手脚。LLM 让自动化更聪明，RPA 让自动化更可靠。AI+RPA 的未来，不是谁消灭谁，而是想清楚谁该动脑、谁该动手，然后让两者无缝配合。

对于那些需要离线更安全、自愈更稳定、成本透明的场景，选对流程自动化工具比盲目追 AI 风口更务实。让 AI 负责思考，让 RPA 负责稳定落地——这才是当下最靠谱的流程自动化实践路径。