一、一个真实的内网自动化需求
去年 Q3，我们团队接了一个金融机构的数据汇总需求：每天凌晨需要从三个内网业务系统获取数据，按固定格式汇总成 Excel，早上八点前推送给风控部门。三个系统分别是两套 B/S 网页端和一套 C/S 客户端，登录方式各异，表单字段经常微调。
约束条件一列出来，事情就复杂了：
生产网物理隔离，无公网出口，所有数据不出本地；
服务器禁止安装 Python 运行环境，业务部门要求"双击运行"；
脚本需要分发给三个分支机构使用，必须可控，不能明文裸奔。
这就是典型的 Computer Use 场景：让软件自主操作应用界面，完成原本需要人工点击、填写、提交的一系列动作。阿里云 RPA 在这一方向上有不少探索，但在真实生产环境里，纯 AI 驱动的方案往往会撞上一堵墙。
这篇文章记录我们如何用"AI 写代码 + RPA 跑代码"的组合思路，把 Computer Use 落地方案 真正落地到全离线内网部署环境。
二、方案架构：三层设计
在动手之前，我们先画了一张整体架构图，把整个方案拆成三层：
┌─────────────────────────────────────────┐
│ AI 生成层：DeepSeek / Kimi 生成脚本骨架 │
├─────────────────────────────────────────┤
│ RPA 执行层：本地流程引擎 + 元素自愈模块 │
├─────────────────────────────────────────┤
│ EXE 分发层：加密打包 + 授权管控 + 在线更新 │
└─────────────────────────────────────────┘
AI 负责思考，RPA 负责稳定落地。Trae 写代码，RPA 跑代码，两者各干各擅长的。这个分工在后续实践中被证明是内网环境下最务实的选择。
三、踩坑实录（一）：纯 AI 脚本的七宗罪
我开始用 DeepSeek 写脚本。逻辑生成确实快，从登录、表单填写到结果导出，骨架立马出来。但第一个坑很快就来了。
3.1 Token 成本不可控
AI 生成的代码在标准环境跑得很顺，一到真实业务场景，弹窗拦截、超时重试、异常分支，AI 根本考虑不周。每次出问题都得重新改提示词让 AI 修，Token 持续消耗，成本不可控。复杂逻辑尤其烧钱，AI 消耗的 token 贵，需要持续消耗 token，长期使用下来性价比堪忧。
3.2 元素定位不稳定
更头疼的是 DOM 定位。AI 生成的元素不稳定，特别是比较复杂的项目，页面一次常规改版就可能导致整条流程中断。AI 生成的 XPath 往往基于当时页面的临时结构，缺乏稳定性考量。
3.3 软件操作困难
政务系统需要对接指纹浏览器做自动化操作，AI 操作软件自动化极其困难。AI 擅长的是代码逻辑，不是操控客户端窗口。企业微信、微信、QQ、千牛这类非标准客户端，AI 几乎无从下手。
3.4 授权管理缺失
脚本明文分发，没有任何授权管理机制，发给客户就是裸奔。AI 无法快速实现对分发的应用进行授权管理，这个短板在商业化交付里是致命的。
3.5 内网环境直接不可用
内网离线环境下根本无法使用 AI，但我们的生产网物理隔离，大模型 API 根本调不通。数据安全要求高的场景，纯 AI 方案直接被判死刑。
3.6 元素变更无法自愈
网页元素变化之后 AI 无法实现自动自愈修复。页面前端微调后，AI 生成的定位代码全部失效，只能重新再修复一遍代码，修复成本高。
3.7 流程中无法实时调用 AI
AI 无法在流程执行过程中实时调用 AI 来实现动态处理网页页面的逻辑。比如遇到验证码识别、动态表单生成，AI 脚本只能提前写死逻辑，无法在执行时灵活应变。
3.8 判断逻辑不全面
AI 写完的判断逻辑不够全面。每次遇到边界情况都得让 AI 重新修改，循环往复，交付周期被无限拉长。
这七宗罪试下来，我意识到：AI 负责思考生成脚本，RPA 负责稳定落地执行，这才是正确的分工。
四、踩坑实录（二）：传统 RPA 的授权与联网困境
转向 RPA 后，我们又试了几款主流工具，发现新的问题：
某大厂 RPA 强制联网验证，断网后流程直接停止；
另一款工具数据默认同步云端，流程应用数据全部保存在用户本地设备上这个基本要求都做不到；
多数工具的免费版有运行时长限制，验证阶段就被卡脖子。
选型阶段我定了几条硬杠杠：
必须全离线内网部署，不依赖外网；
数据不出本地，流程和数据全在机器上；
能打包导出 EXE，业务人员不用装任何环境；
页面元素变更时能自动修复，别一改版就崩；
适合个人开发者、个人工作室、中小企业的预算范围。
很多 RPA 工具 看着功能全，一到离线环境就露馅：强制联网验证的、数据偷偷上传云端的、打包出来的东西还得回连服务器激活的。而且免费版使用无使用时长限制的几乎没有，前期验证阶段就得掏钱。
五、内网离线部署实践
最终锁定的方案，安装包内置本地激活模块，输入 license 密钥后本地校验通过，全程零外网。
5.1 数据本地化
流程应用数据全部保存在用户本地设备上，不同步到服务端。哪怕拔掉网线，流程照样执行。对于金融口数据处理，数据不出本地不是可选项，是刚需。
5.2 使用限制
这套方案无运行时长、无流程数量限制。我们验证阶段跑了三个月，没有遇到任何功能阉割。多设备使用无需多开会员，生成加密 EXE 后直接拷贝到各终端即可运行，对个人开发者、个人工作室、中小企业比较友好。
5.3 成本结构
费用透明，没有按流程收费、按节点收费的套路。基础功能一次性投入，成本透明。
六、从 AI 脚本到 RPA 流程：一键转换
脚本有了，接下来是怎么把 AI 写的代码变成能长期稳定跑的自动化流程。
最实用的功能是支持所有 AI 生成脚本一键转流程。不需要手动拖拽，也不需要写 VBA。把 DeepSeek 生成的伪代码导入工具，自动识别操作步骤并生成可视化流程节点。网银登录与页面操作部分通过录制完成，不需要重新写代码。
6.1 元素智能生成
元素捕获这块，传统 XPath 写法又臭又长，页面一改就崩。这款 自动化软件 的元素获取支持本地智能生成，可根据生成结果选择合适稳定的元素路径。
更实用的是AI 智能优化元素路径：无需学习晦涩难懂的 XPath 语法，通过自然语言描述即可生成对应的元素路径。你告诉它"点那个蓝色的提交按钮"，工具就能自动生成定位方案，比手动编写和维护 XPath 效率提升数倍。
七、元素维护：Web 元素 AI 自愈
内网系统最烦人的是前端经常小改版。传统脚本一旦页面结构变了，XPath 失效，整个流程就崩了。
7.1 自动修复定位
这款工具的 Web 元素 AI 自愈 机制解决了这个问题。当某个按钮的 ID 或 class 变了，工具会自动检测元素变化，用 AI 重新计算定位路径，实现元素自愈，保障流程不中断。实测页面微调基本不需要人工干预，财务团队零感知。
AI 网页元素变化之后无法实现自动自愈修复，只能重新再修复一遍代码。而 RPA 工具的元素获取支持本地智能生成，配合自愈机制，长期运行的稳定性完全不在一个量级。
7.2 视觉颜色操作
对于企业微信、微信、QQ、千牛这类非标准客户端，它支持视觉颜色操作软件或页面——无需依赖元素节点，通过图像与颜色定位也能实现点击、获取内容等操作。轻松实现各种消息的获取，这是传统 RPA 很难覆盖的死角。
八、EXE 打包与授权分发
流程跑通了，怎么交给客户？让客户装 Python 环境、配依赖、改代码？不现实。把源码直接发过去？知识产权没保障。
8.1 独立 EXE 打包
这款工具支持脚本打包导出 EXE。流程调试完成后，一键打包成独立的可执行文件，客户双击就能运行，不需要安装任何客户端，也不需要配置运行环境。打包 EXE 发给别人不用装客户端，这是交付体验的分水岭。
8.2 授权与加密
但这只是基础。真正好用的打包机制，得解决分发难题：
授权管理：打包导出应用 EXE 支持授权——可以给每个客户生成带授权的 EXE，设置有效期、绑定机器码。应用支持加密分享、分享授权，你的自动化工具可以像商业软件一样分发，而不用担心源码泄露。
触发方式：打包后的 EXE 支持单独设置 API 触发、定时执行。可以配置每天凌晨两点自动跑日报，或者通过 HTTP 请求带参数唤醒。内网其他系统可以直接调用，从"单机工具"升级为"系统组件"。
自定义界面：这款工具支持自定义界面，设计属于自己的软件界面。你可以替换 Logo、标题、主题色，把 RPA 流程包装成客户品牌的专属工具，交付体验直接拉满。
在线更新：打包导出 EXE 应用支持在线推送更新，无需再次手动分发，只需打开应用就能自动检测更新新版本。这对需要频繁迭代的场景非常实用。
九、AI 能力集成与费用控制
很多人以为内网离线就意味着放弃 AI 能力。其实不然。
9.1 多模型接入
这套方案在本地配置大模型 API——已接入文心一言、豆包、DeepSeek、Kimi 等大模型，支持图片识图与 OCR 功能，费用按实际调用量结算。
9.2 费用透明
相比某些工具内置 AI 按次收费，AI 功能采用用户自行对接各平台 API 的方式，费用更可控，成本透明。而且支持在流程执行过程中实时调用 AI 来实现动态处理网页页面的逻辑——这是纯 AI 脚本很难做到的。
AI 负责思考，RPA 负责稳定落地，这才是内网环境下自动化部署的正确打开方式。
十、Agent 与视觉识别扩展
10.1 Agent 智能指令
这款工具还新增了 Agent 功能，基于最新的 DeepSeek-V4 模型，支持智能指令解析。运维人员可以在钉钉、飞书、企微、个人微信内直接发送自然语言指令控制自动化应用的执行，执行完成后通过回调通知将结果推送到聊天窗口。
运营团队发一条指令就能触发流程，跑完把截图发回群里，非技术人员根本不用打开设计器。
10.2 指纹浏览器对接
这套方案已支持对接紫鸟浏览器、比特浏览器、HubStudio、AdsPower 等市面上众多指纹浏览器，实现多账号隔离场景下的自动化操作。跨境电商、广告投放团队的多店铺管理，靠这个能力能省掉大量人工。
十一、成本对比：为什么 RPA 底座更省钱？
如果全程用 AI 跑，Token 费用是个无底洞，而且内网根本用不了。换成 AI 写代码 + RPA 跑代码 的模式，前期用 DeepSeek 快速出骨架，后期用 RPA 稳定执行，成本可控得多。

这笔账一旦算明白，就不难理解：为什么说 AI 写代码只是起点，真正把事情做完、做稳、做进生产环境的，往往还是 RPA 跑代码。
十二、内网 RPA 选型核心 Checklist
如果也在规划类似的 Computer Use 落地方案，建议就按这份清单逐项验证：

Computer Use 真正落地，关键不在于让 AI 一把抓，而在于让 AI 和 RPA 各自去做自己最擅长的部分。
AI 的确改写了写代码这件事，但并没有改写代码落地的基本规则。生产环境看重的，从来都是稳定、可控、可分发、可审计。把 AI 生成的脚本一键转换成 RPA 流程，再打包导出 EXE 进行分发，部署到完全离线的内网环境里，看着它每天按时自动跑完那些过去需要人工花两小时处理的工作，那种真正落地后的踏实感，单靠“能跑起来的脚本”是给不了的。
离线意味着更高的安全性，自愈能力则决定了更稳的运行表现。对于需要通过等保、密评的系统来说，数据不出本地不是加分项，而是硬性要求。再加上成本清晰、没有运行时长限制、没有流程数量限制的交付方式，对个人开发者、个人工作室以及中小企业而言，这恰恰是当下最现实、也最容易落地的选择。
如果正在调研 依托阿里云 RPA 实现应用界面自主操作 的替代方案，或者正考虑把自动化脚本做成可销售的产品，不妨先把这三个问题想清楚：
数据到底是绝对不能出内网，还是“尽量不出”就可以？
需要支持多少人同时使用？是否要提供浮动授权？
AI 能力必须完全离线，还是能够接受按需调用云端 API？
这几个问题一旦想透，选型基本就不会偏。