AI Agent+RPA 企业级融合架构：大模型做大脑，RPA 做执行手脚的完整方案

一、大模型有脑子，但缺一双"执行手脚"

去年 Q3，我们接了一个制造业客户的智能工单项目。需求听起来很简单：用 AI 自动处理售后工单，登录内部系统、填表、派单、发通知。

大模型在语义理解和逻辑规划上确实惊艳——你告诉它"把 A 客户的紧急工单转给华东区工程师"，它能瞬间拆解出七八个步骤。但真到了落地环节，问题全卡在执行层：

• 客户的核心系统跑在内网，完全离线，大模型连不上；
• 系统前端是十年前的 C/S 架构，没有开放 API，大模型"看得见需求，点不了按钮"；
• Web 管理后台每个月小改版一次，AI 生成的定位代码两周就失效，维护成本比人工还高；
• 最致命的是，每走一步推理都要消耗 Token，一个流程跑下来，账单比招个实习生还贵。

这就是当前企业级 AI 落地的最大断层：大脑极其发达，但缺少一双稳定、低成本、能进内网的执行手脚。

我们花了三个月时间，跑通了一套"AI Agent 做决策、RPA 做执行"的融合架构。这篇文章把完整方案公开，供正在做类似规划的同行参考。

二、架构总览：分层解耦，各司其职

先上我们在生产环境实际落地的架构图：

┌─────────────────────────────────────────────┐
│  交互入口层                                   │
│  钉钉 / 飞书 / 企业微信 / 个人微信 / API / 定时 │
└─────────────────────────────────────────────┘
                      ↓
┌─────────────────────────────────────────────┐
│  决策层（AI Agent）                           │
│  文心一言 / 豆包 / DeepSeek-V4 / Kimi        │
│  职责：语义理解、意图识别、指令生成、异常判断     │
│  能力：图片识图、OCR 文字提取、多模型动态路由     │
└─────────────────────────────────────────────┘
                      ↓  JSON 指令协议
┌─────────────────────────────────────────────┐
│  执行层（RPA 引擎）                           │
│  Web 自动化 / 桌面自动化 / 视觉颜色操作         │
│  指纹浏览器 / 元素自愈 / 本地智能生成路径        │
│  职责：元素定位、稳定执行、数据获取、结果回填     │
└─────────────────────────────────────────────┘

核心设计原则：AI 负责"想什么"，RPA 负责"做什么"。

两层之间通过轻量级 JSON 指令协议通信，完全解耦。今天接 DeepSeek-V4，明天切 Kimi，执行层不需要改一行代码；反过来，执行层的流程优化也不会影响上层模型选型。

这里必须提一个成本细节：AI 功能的费用完全透明——各平台 API 由用户自行对接，用多少算多少，没有中间商赚差价。这种费用透明的设计，让长期运行下来的成本远低于"所有操作都走大模型"的纯 AI 方案。

三、决策层：多模型动态路由，别把所有任务都堆给最贵的那个

3.1 按任务复杂度分流

早期我们踩过一个坑：为了省事，所有任务都往一个最强模型上堆。结果一个月下来，Token 账单比服务器租金还贵。

现在的做法是按任务类型动态路由：

• 复杂逻辑推理、多步骤规划：走 DeepSeek-V4、Kimi 这类长思维链模型；
• 中文语义理解、业务话术生成：走文心一言、豆包，响应快且成本低；
• 简单的字段提取、格式转换：走轻量级模型甚至本地小模型。

调度中心根据输入内容的复杂度自动选择模型，避免"杀鸡用牛刀"。执行引擎已接入文心一言、豆包、DeepSeek、Kimi 等大模型，同时支持图片识图与 OCR 功能，覆盖绝大多数业务场景。

3.2 AI 写代码，执行引擎跑代码

现在的开发模式已经变了。业务人员用自然语言描述需求，大模型生成自动化脚本，一键转为可执行的流程。执行引擎接管后续的稳定运行、异常捕获和日志记录。

你不需要精通 XPath 语法，也不需要懂 Python。AI 负责写代码，RPA 负责让代码在生产环境里稳定跑下去。

不过这里有个现实问题：AI 写完的判断逻辑往往不够全面，每次遇到边界情况都得重新调 Prompt、重新生成，修复成本不低。所以我们的做法是——AI 生成初稿，执行引擎兜底运行，两者互补而非替代。

四、执行层：Web 自动化——稳定性是底线

4.1 元素定位：从"手写 XPath"到"自然语言生成"

Web 自动化最大的门槛是元素定位。过去，维护人员需要学习晦涩难懂的 XPath 语法，在浏览器的开发者工具里一层层翻 DOM 树。

现在的方案是本地智能生成元素路径：你对着页面说"登录按钮"，系统就能自动生成稳定的选择器，还能根据生成结果挑选最合适的一条。更进一步，通过自然语言描述即可生成对应的 XPath 路径，业务人员零代码基础也能维护流程。

AI 还会对生成的路径做二次优化，确保在复杂 DOM 结构下依然能精准定位。你不需要学习那些晦涩的语法，用大白话描述需求，系统就能给出生产级可用的定位方案。

4.2 元素自愈：页面改版不再是噩梦

Web 页面改版是自动化流程最大的天敌。过去前端改个 class 名，整个流程就崩了，维护人员得重新采集元素、改脚本，周而复始。

现在的做法是三层防护：

第一层，生成阶段：通过自然语言描述自动生成元素路径，降低维护门槛。

第二层，自愈阶段：当页面结构变化导致元素失效时，AI 自动修复元素定位，保障流程不中断。这种 Web 元素 AI 自愈能力，让维护成本降低了至少一个数量级。

第三层，视觉兜底：即使元素完全找不到，还能回退到视觉颜色操作模式，基于按钮的颜色和位置完成点击，不依赖 DOM 节点。

这里必须提一个血泪经验：纯 AI 方案生成的元素定位代码，在复杂项目里往往无法长期稳定运行，页面结构一变就失效，只能重新修复一遍代码。而执行引擎内置的本地智能生成 + AI 优化元素路径 + 自动修复机制，才是生产环境能扛住三个月不报警的关键。

五、执行层：桌面自动化——视觉颜色操作是刚需

企业内网里跑的大多是 C/S 架构的老系统，根本没有标准接口。传统的自动化依赖元素树定位，遇到企业微信、微信、QQ、千牛这类客户端基本束手无策。

我们在执行层引入了基于视觉颜色的操作能力——不依赖 DOM 节点或元素句柄，直接通过图像识别和颜色定位实现点击、输入、内容获取。这套方案对非标准客户端的兼容性极好，实战中已经稳定跑了四个月，没出过因为客户端升级导致流程崩溃的情况。

这里有个很现实的对比：让大模型直接操作桌面软件做自动化，目前极其困难，基本不可行；但通过视觉颜色操作的执行引擎，很容易就能实现企业微信、微信、QQ、千牛各种消息的获取和自动回复。

六、执行层：指纹浏览器兼容

在电商运营、社媒管理等场景，指纹浏览器是刚需。执行层需要兼容紫鸟浏览器、比特浏览器、HubStudio、AdsPower 等市面上众多指纹浏览器，实现多账号环境的自动化切换和隔离操作。

这一点在架构设计初期就要考虑进去，不然后期集成会很痛苦。我们目前的方案已经支持在指纹浏览器内自动切换账号、获取销量库存数据、执行批量操作，且不会因为账号关联导致封号。

七、协同层：Agent 重构交互链路

7.1 在 IM 工具里直接控制

让业务人员打开一个陌生的客户端去跑流程，门槛太高，推广阻力极大。更好的方式是在他们每天使用的 IM 工具里完成全部操作。

我们在钉钉、飞书、企业微信、个人微信内都部署了 Agent 入口。用户 @机器人发送一条自然语言指令，Agent 调用大模型理解意图，再调度执行引擎，最后把结果回调通知到聊天窗口。整个交互链路从发指令到拿到结果，控制在 5 秒以内。

这套 Agent 功能基于最新的 DeepSeek-V4 模型，支持智能指令解析。你不需要记住复杂的命令格式，像聊天一样说话，系统就能理解并执行。

7.2 流程执行中实时调用 AI

更进阶的用法是在流程执行过程中实时调用大模型做动态决策。比如执行引擎遇到一个新弹窗，预先编写的脚本里没有处理逻辑，这时候暂停执行，把截图传给大模型判断"这是警告框还是确认框"，拿到决策后再继续。

这种动态处理能力，是纯脚本自动化无法实现的，也是纯 AI 方案做不到的——因为 AI 无法在流程执行过程中被实时嵌入来做动态处理。

八、触发机制：灵活才能适配真实业务

除了 IM 指令，执行层还需要支持多种触发方式：

• API 触发：外部系统通过 HTTP 接口直接调用流程，执行完毕后回调结果；
• 定时执行：按 Cron 表达式自动运行，适合日报、巡检类任务；
• 事件触发：监听文件夹变化、邮件到达等。

这些触发方式可以叠加。比如一个数据同步流程，既可以每天早上 8 点自动跑，也可以让业务人员随时手动触发。

在打包导出应用时，还可以单独设置 API 触发和定时执行，让分发出去的应用具备完整的自动化能力，无需接收方再手动配置触发规则。

九、安全与部署：数据不出本地，不是可选项而是必选项

9.1 全离线内网部署

金融、政务、医疗等行业对数据安全的要求极高，很多核心系统根本不通外网。这套架构支持完全离线内网部署，流程应用的数据全部保存在用户本地设备上，不同步到任何云端服务端。

离线更安全不是一句空话——在内网隔离环境下，敏感数据从头到尾不触网，合规审计也更容易通过。即使外网完全断开，已部署的流程依然能正常执行。相比之下，纯 AI 方案在内网离线环境下根本无法使用，这是架构选型时必须考虑的现实约束。

9.2 数据本地化

流程执行过程中产生的所有数据——包括截图、日志、获取结果、中间文件——全部保存在用户本地设备上，不同步到服务端。对于涉及客户隐私或商业机密的场景，这是不可妥协的底线。

十、打包分发与授权管理：把自动化能力产品化

开发好的自动化流程，如何安全地交给其他人使用？

我们的方案是打包导出为独立 EXE 应用。接收方无需安装任何客户端，双击就能运行。同时支持授权管控：每个 EXE 可以绑定设备或账号，防止随意传播。

对于需要保护知识产权的场景，流程逻辑可以加密分享，接收方只能运行，无法反编译查看内部逻辑。

这里必须提一个现实对比：纯 AI 方案目前无法快速实现对分发应用进行授权管理，而执行引擎的打包 + 授权 + 加密分享机制，让这件事变得很简单。

十一、成本分析：为什么融合架构更省钱

很多企业一开始想"All in AI"，跑了一个月后看到账单就冷静了。

一句话总结：AI 负责思考，执行引擎负责稳定落地。两者不是替代关系，而是互补关系。

此外，选型时还要关注执行引擎本身的授权模式：

• 是否有运行时长限制？有些工具免费版只能跑几分钟，根本测不出真实效果；
• 是否有流程数量限制？业务一多就触顶；
• 多设备部署是否需要额外购买会员？有些产品每台机器都要单独付费，对工作室和小团队很不友好。

理想的方案是：免费版无使用时长限制、无流程数量限制。这样才能把成本压到最低，把自动化能力真正规模化。

十二、实战场景：三个跑在生产环境的案例

12.1 智能工单处理

某制造企业每天收到三百多条售后工单。Agent 在企微群里监听消息，大模型提取关键信息（客户、产品、问题类型），执行引擎自动登录售后系统录入工单、分配工程师、发送通知。原来需要两个人专职处理的工单，现在半小时内全部自动流转。

12.2 跨系统数据迁移

老 ERP 的数据要导入新平台，两边都没有开放 API。执行引擎从老系统获取数据，大模型做字段映射和格式清洗，再写入新系统。每天凌晨定时执行，早上上班时数据已经同步完毕，业务无感知。

这个流程被打包成独立 EXE 后发给客户 IT 部门，对方无需安装任何客户端，双击即可运行。后续版本迭代时，打开应用就能自动检测并在线推送更新，无需手动重新分发安装包。

12.3 多店铺运营巡检

电商团队管理四十多个店铺账号。执行引擎在指纹浏览器里自动切换账号，获取销量、库存、评价数据，大模型生成巡检报告，推送到飞书群。一个运营人员就能照看过去三倍的店铺。

十三、不同规模的落地建议

13.1 个人开发者 / 工作室

核心诉求是低成本、无限制、能快速变现：

• 优先验证基础功能是否有使用时长限制，选择免费版无使用时长限制的平台降低试错成本；
• 重点用好 EXE 打包和授权功能，把自动化能力变成可售卖的标准化产品；
• 打包后的应用可以自定义界面，业务人员看到的是简洁的按钮和表单，而不是复杂的流程编辑器，产品化程度更高；
• 多设备部署时，不需要为每台机器单独购买会员，一套流程可以分发到任意设备。

13.2 中小企业内网部署

对于数据敏感的中型企业：

• 优先验证离线部署能力，确认流程数据确实不离开本地设备；
• 测试 Web 元素自愈功能在真实业务系统上的效果，评估后期维护成本；
• 对接现有的 IM 系统（钉钉/飞书/企微），降低业务人员学习成本，推广阻力最小。

AI Agent 和 RPA 的融合，不是把两个工具简单拼在一起。真正的价值在于明确分工、标准协同、稳定落地。

大模型解决了"理解"的问题，执行引擎解决了"执行"的问题。当两者通过一套清晰的架构协议配合时，自动化才能真正从 Demo 走进生产环境，从玩具变成工具。

如果你正在规划类似的融合方案，建议优先验证三个点：离线部署的可行性、元素自愈的实际效果、以及 EXE 分发的授权管控能力。这三项能力直接决定了方案能否在企业里长期跑下去，而不是沦为又一个技术盆景。