云端部署 AI+RPA 服务：从零搭建智能自动化环境完整实操

去年Q3，我们团队接了一个制造业客户的财务自动化需求：每天凌晨从三套内网系统取数，按固定格式汇总成Excel，早上八点前推送给风控部门。三个系统分别是两套B/S网页端和一套C/S客户端，登录方式各异，表单字段经常微调。

客户提了三个硬约束：

• 生产网物理隔离，无公网出口，数据不出本地；
• 服务器禁止安装Python运行环境，业务部门要求"双击运行"；
• 脚本需要分发给三个分支机构使用，必须可控，不能明文裸奔。

这三个条件一叠加，市面上大部分自动化方案直接被筛掉。折腾了半个月，我们最终跑通了一套云端部署 AI+RPA 服务的完整方案：在CVM上搭建开发环境，利用支持脚本打包导出EXE的能力，流程调试通过后打包为独立可执行文件，分发到内网执行机内网离线使用，数据不出本地。

整个过程中，AI负责思考 RPA负责稳定落地——AI写代码 RPA跑代码，各司其职。开发阶段在云上完成，打包后在内网跑，离线更安全，自愈更稳定。

这篇文章把服务器搭建智能自动化环境完整实操过程记录下来，涵盖全离线内网部署、EXE加密打包、授权管理等核心能力，包括选型思路、架构设计、部署命令、配置截图和踩坑记录。

一、为什么选AI+RPA，而不是纯AI或纯脚本

一开始我们走了两条弯路。

弯路一：纯AI写代码。 用AI编程工具生成Python脚本，本地测试跑得挺顺，一到客户现场直接趴窝。pip装不了依赖，Selenium找不到ChromeDriver，更致命的是内网根本连不上AI。折腾了三天，我意识到：内网离线环境下根本无法使用AI持续生成代码，脚本基本就是一堆废代码。而且AI消耗的token费用不低，复杂项目需要持续消耗，长期跑下来成本吃不消。更麻烦的是，AI生成的元素定位在复杂项目里极不稳定，网页改版一次就崩，每次出问题都得重新改提示词让AI修，修复成本高得离谱。AI操作软件自动化也极其困难，遇到没有开放接口的国产软件直接束手无策。

弯路二：纯RPA手动拖拽。 传统RPA工具确实能离线跑，但遇到复杂业务逻辑，可视化拖拽效率太低。而且很多工具强制联网验证License，断网后流程直接停止；数据还默认同步云端，流程应用数据全部保存在用户本地设备上这个基本要求都做不到。

最后我们确定的思路是：AI写代码，RPA跑代码。AI在外网把逻辑想清楚，生成脚本后一键转为可视化流程，交给一个能离线跑、能自愈、能打包分发的自动化引擎去执行。说白了，AI负责思考，RPA负责稳定落地。

这种组合在四个维度都优于单一方案：

二、整体架构设计：三层隔离模型

我们的架构分三层，确保"开发可联网、生产严格离线、数据全程可控"：

企业内网环境（物理隔离）
├── 核心生产区：RPA执行节点（业务系统操作）
│   └── 完全断网，只操作内部ERP/OA
├── 流程开发区：腾讯云CVM设计器（流程编写调试）
│   └── 开发阶段联网，打包后切换离线模式
└── 管理控制区：License本地验证 + 日志审计
    └── 独立部署，不依赖外部服务

关键设计原则：

• 核心生产区彻底断网，执行节点只操作内部业务系统；
• 流程开发区用腾讯云CVM，开发阶段允许联网调用AI生成脚本，调试完成后打包分发；
• 管理控制区独立部署本地License验证和日志存储，全程零外网依赖。

这种设计的好处是：既利用了云计算的灵活性做流程开发，又守住了数据安全的底线。开发阶段在云上完成，打包后在内网跑，离线更安全。

三、腾讯云CVM环境准备：选型与初始化

3.1 CVM选型配置

我们的方案是"CVM作为开发环境，打包后分发到内网执行机"。这样既利用云资源做流程开发，又保证生产环境完全离线。部署完成后，流程应用数据全部保存在用户本地设备上，不同步到服务端，保障数据安全。

关键操作：创建CVM时选择"自定义镜像"，后续所有环境配置完成后直接打成镜像。内网部署时用这个镜像启动新实例，省去重复安装。

3.2 初始化CVM：第一步实操命令

登录CVM后，先完成基础环境初始化：

# 1. 关闭Windows防火墙（内网环境通常有硬件防火墙）
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

# 2. 安装Chrome浏览器（指定114版本，避免驱动不匹配）
# 下载离线安装包后执行
ChromeSetup_114.exe /silent /install

# 3. 验证浏览器版本
& "C:\Program Files\Google\Chrome\Application\chrome.exe" --version
# 输出：Google Chrome 114.0.5735.199

# 4. 下载对应版本的chromedriver
# chromedriver 114.0.5735.90 必须与Chrome版本匹配
# 将chromedriver.exe放到C:\Tools\目录下

# 5. 验证驱动
C:\Tools\chromedriver.exe --version
# 输出：ChromeDriver 114.0.5735.90

# 6. 安装运行时库（.NET Framework 4.7.2 Server 2019已内置）
# 安装VC++ 2015-2022 Redistributable
vc_redist.x64.exe /install /quiet /norestart

注意：浏览器版本和驱动版本必须严格匹配。建议在内网环境统一使用固定版本，避免自动更新导致驱动失效。我们在客户现场就遇到过Chrome自动更新到115版，驱动还是114版，脚本直接崩溃的情况。

3.3 离线依赖包清单

内网部署前，需要提前准备好以下资源，通过加密U盘或专用摆渡机传入内网：

• 主程序离线安装包（内置完整运行时，断网状态直接激活）
• 浏览器离线安装包（Chrome 114指定版本）
• 浏览器驱动（chromedriver.exe 114.0.5735.90）
• 本地AI模型包（DeepSeek、Kimi、文心一言、豆包等本地部署包）
• 指纹浏览器安装包（紫鸟浏览器、比特浏览器、HubStudio、AdsPower等）
• 运行时库（VC++ 2015-2022 Redistributable）

四、核心部署：十步搭建完整环境

Step 1：操作系统与基础环境

在CVM上完成上述3.2节的初始化后，创建系统镜像。这个智能自动化环境需要确保元素获取支持本地智能生成、AI智能优化元素路径，为后续流程开发打好基础：

# 在腾讯云控制台创建自定义镜像
# 登录腾讯云控制台 → 云服务器 → 实例 → 更多 → 创建自定义镜像
# 镜像名称：Win2019-RPA-Base-v1.0

这个镜像包含了Chrome、驱动、运行时库，后续所有部署都基于这个镜像，省去重复安装时间。

Step 2：本地AI模型部署（DeepSeek/Kimi/文心/豆包）

这是整个方案的智能核心。我们选择在CVM上本地部署轻量级AI模型，供流程调用实现智能交互。

以DeepSeek为例，在CVM上执行：

# 1. 上传离线安装包至CVM D盘，解压
Expand-Archive -Path "D:\DeepSeek-Local-v4.zip" -DestinationPath "D:\AI-Models\"

# 2. 进入模型目录
cd D:\AI-Models\DeepSeek-Local-v4

# 3. 执行离线安装脚本（无需联网）
.\install.ps1 -OfflineMode

# 4. 验证模型加载
.\deepseek-cli.exe --version
# 输出：DeepSeek-Local v4.0.1

# 5. 启动本地API服务
.\deepseek-server.exe --model deepseek-v4 --port 8000 --host 0.0.0.0

# 6. 测试本地API（新开PowerShell窗口）
Invoke-RestMethod -Uri "http://localhost:8000/v1/chat/completions" `
  -Method POST `
  -ContentType "application/json" `
  -Body '{"model":"deepseek-v4","messages":[{"role":"user","content":"测试"}]}'

避坑要点：

• 选择本地文件授权方案，避免部署后强制联网激活；
• 内存不足会导致推理卡顿，建议预留≥10GB内存给AI进程；
• 模型切换后避免中途更换，防止输出不稳定。

部署完成后，CVM上的AI模型可提供本地API接口，供流程在运行时调用。这种设计让AI功能采用用户自行对接各平台API的方式，费用更可控，按实际用量计费，成本透明。你可以根据业务场景选择性价比最高的模型，接入文心一言、豆包、DeepSeek、Kimi等主流大模型：日常文本处理用豆包，复杂推理用DeepSeek，通用对话用Kimi，中文语义理解用文心一言。

Step 3：流程自动化工具安装与离线激活

这是私有化部署的灵魂。没有真正的离线授权，所谓"私有化"只是伪命题。

安装过程：

# 1. 以管理员身份运行离线安装包
Setup.exe /S /D=C:\Automation

# 2. 验证安装目录
Get-ChildItem C:\Automation
# 应包含：Designer.exe、Runtime.exe、LicenseManager.exe等

# 3. 断网测试：禁用网卡后启动设计器
Disable-NetAdapter -Name "以太网" -Confirm:$false
& "C:\Automation\Designer.exe"
# 如果正常启动且无弹窗要求联网，说明安装包内置完整运行时

离线激活流程：

1. 硬件指纹采集：安装完成后，软件自动采集设备指纹（主板序列号、CPU ID、硬盘序列号、网卡MAC地址），生成专属的Machine ID。在CVM上执行： powershell & "C:\Automation\LicenseManager.exe" --export-fingerprint # 生成 fingerprint_20260811.json
2. 申领授权文件：管理员将Machine ID通过摆渡机带出内网，在授权管理系统中绑定许可证数量、有效期、功能模块权限，使用私钥签名生成.lic文件；
3. 本地激活：将授权文件拷贝回内网机器，软件用公钥验证签名合法性，解密后写入本地授权存储。激活完成后，软件定期在本地验证授权有效性，全程无需连接外网。

核心判断标准：一次激活，永久离线运行，除非企业主动更新授权。那种每隔90天要联网"续命"的方案，在严格隔离环境中不可接受。

我们实测过几款工具，发现"离线"这件事水很深。有些工具宣传的"本地部署"其实是伪本地——界面装在你本地，License还是要联网校验，日志还是要上传云端做"分析"。在等保2.0和数据安全法的背景下，这种方案过不了一点。真正可用的方案必须满足：安装包内置完整运行时，断网状态直接激活；License本地文件校验，不依赖中央服务器；流程数据纯本地存储，不同步到云端。

Step 4：AI生成脚本一键转为可视化流程

这是整个方案最省心的一步。AI生成的脚本不用改，直接转成可视化流程节点。

示例：用AI生成一段OA系统自动填单的Python脚本：

# AI生成的脚本
from selenium import webdriver
from selenium.webdriver.common.by import By

driver = webdriver.Chrome()
driver.get("http://10.0.1.100/oa")

# 登录
driver.find_element(By.XPATH, "//input[@id='username']").send_keys("admin")
driver.find_element(By.XPATH, "//input[@id='password']").send_keys("******")
driver.find_element(By.XPATH, "//button[@type='submit']").click()

# 填单
driver.find_element(By.XPATH, "//a[text()='新建申请']").click()
driver.find_element(By.XPATH, "//input[@name='title']").send_keys("服务器采购申请")

将这段脚本导入可视化流程设计器，系统会自动识别代码结构：

• driver.get() → "打开网页"节点
• find_element().click() → "点击元素"节点
• send_keys() → "输入文本"节点

不需要手动重写一遍。AI写的是代码，流程里跑的也是这段代码，只是被可视化节点封装了。后续如果要改逻辑，既可以回到AI工具里改脚本重新导入，也可以直接在流程里微调参数。

这种支持所有AI生成脚本一键转流程的设计，让个人开发者和小团队不用在"写代码"和"画流程"之间二选一，哪个顺手用哪个。AI写代码，RPA跑代码，两边都不耽误。

Step 5：Web元素智能定位与AI自愈

传统自动化最大的痛点是元素定位。网页改版、前端重构、动态加载，都会导致脚本失效。

我们采用的方案支持三层定位机制：

第一层：本地智能生成元素路径

支持本地智能生成元素定位路径，无需学习晦涩难懂的XPath语法。通过自然语言描述目标元素，系统自动生成对应的定位路径。比如描述"登录按钮"，系统会分析页面结构，生成最稳定的XPath或CSS Selector。这种元素获取支持本地智能生成的能力，让获取元素更加简单稳定。

第二层：AI智能优化元素路径

系统内置AI优化引擎，会根据页面结构自动选择最稳定的定位策略。比如首先尝试id，其次name，最后才是相对路径。这种AI智能优化元素路径的能力，让元素定位的稳定性大幅提升。更关键的是，自然语言描述即生成对应的xpath路径——你不需要背XPath语法，用大白话描述元素位置和特征，AI自动翻译成准确的定位表达式。

第三层：Web元素失效自动修复

当页面发生变更，原有元素路径失效时，系统会自动启动修复机制。通过分析页面DOM树的变化，结合历史操作记录，重新计算最优定位路径。Web元素失效时AI自动修复元素定位，实现元素自愈，保障流程不中断。

实测下来，这套Web元素AI自愈机制能应对90%以上的页面微调场景。以前网页改版一次，脚本就得重写；现在系统自己就把路径修好了，自愈更稳定。离线更安全 自愈更稳定，这是内网部署的核心优势。

Step 6：指纹浏览器对接与多账号隔离

很多自动化场景需要操作多个账号，比如电商运营、社媒管理。普通浏览器多开容易被平台检测封号，必须借助指纹浏览器实现环境隔离。

我们测试的自动化引擎已兼容市面上主流指纹浏览器，对接紫鸟浏览器、比特浏览器、hubstudio浏览器、adspowser浏览器等市面上众多指纹浏览器。对接方式很简单：

# 连接指纹浏览器的远程调试端口
rpa.browser.connect(
    browser_type="chrome",
    debugger_address="127.0.0.1:9222",  # 指纹浏览器开放的调试端口
    profile="profile_001"  # 指定指纹环境
)

# 后续操作与普通浏览器一致
rpa.browser.open("https://shop.example.com")
rpa.browser.click("xpath://button[@id='login']")

每个指纹环境有独立的Cookie、缓存、Canvas指纹、WebGL指纹，平台无法识别是同一台机器在操作。这种实现自动化操作的多账号隔离能力，对电商和社媒运营团队是刚需。

Step 7：打包为独立EXE并配置授权

这是整个方案里最香的一环。支持脚本打包导出EXE，把流程变成独立可执行文件。传统交付模式是：在客户服务器装设计器→导入流程文件→配置运行环境→调试→培训客户IT人员维护。打包EXE的交付模式是：把EXE拷过去→双击运行→完事。

打包配置示例：

# 调用打包API生成独立EXE
pkg = Packager()
pkg.set_source(r"D:\Flows\OA_Auto_Fill.flow")
pkg.set_output(r"D:\Deploy\OA智能填单助手.exe")

# 加密与授权配置
pkg.set_encryption(
    password="user_defined",      # 自定义密码
    machine_bind=True,              # 绑定设备
    expire_date="2027-08-11"        # 有效期
)

# 运行时约束
pkg.set_runtime(
    network_required=False,         # 运行时无需联网
    local_logs=True,                # 日志本地留存
    screenshot_local_only=True      # 截图仅本地
)

pkg.build()

打包后的EXE可在未安装任何环境的机器上直接运行。业务部门根本不知道底层是自动化引擎，体验接近正经软件。

授权控制维度：

验收实测：我们将打包的EXE拷到个人笔记本运行，提示"未授权设备，拒绝执行"。安全部同事难得说了句："这个可以写进材料。"

相比之下，AI生成的脚本完全不具备授权管理能力，发给客户就是裸奔。而打包导出应用EXE支持授权的设计，让自动化流程可以当成正经软件产品去交付。应用支持加密分享、分享授权，你可以把打包好的应用加密后发给合作伙伴，对方输入授权码才能运行，既保护了知识产权，又实现了可控分发。

Step 8：API触发与定时任务调度

流程不是只能手动点。支持API触发，可以通过HTTP接口被其他系统调用。同时打包导出应用EXE支持单独设置api触发、定时执行，这意味着分发出去的EXE不只是个手动工具，它可以被其他系统调度，也可以自己按时运行。

HTTP接口触发配置：

# 1. 在流程中启用API服务
rpa.api.start(host="0.0.0.0", port=8080)

# 2. 其他系统通过HTTP请求调用
# POST 请求示例（使用curl测试）
# curl -X POST http://10.0.1.50:8080/trigger \
#   -H "Content-Type: application/json" \
#   -d '{"flow_id":"oa_auto_fill","params":{"title":"服务器采购申请","amount":50000}}'

定时执行配置：按Cron表达式设置，每天凌晨2点自动跑。在打包配置中单独设置：

pkg.set_schedule(
    cron="0 2 * * *",  # 每天凌晨2点
    enabled=True
)

这种设计让自动化流程可以无缝接入现有IT系统，不需要人工干预就能按时执行。

Step 9：IM工具远程控制与Agent模式

这一步让流程真正"无人值守"，而且对非技术人员极其友好。

钉钉、飞书、企微、个人微信内控制流程执行，支持发送指令远程触发流程，执行结果自动回调通知响应执行结果到聊天窗口。这就是Agent功能在实际业务中的落地——使用最新的DeepseekV4模型，支持智能指令解析，能识别自然语言意图并映射到对应流程。

比如你在群里发一条消息："跑一下昨日报表"。家里的服务器就开始执行，做完后企业微信收到一条"已完成，共处理1532条订单"的推送。

这种交互方式对业务部门根本不需要打开设计器，手机上发句话就能搞定。对于适合个人开发者、个人工作室、中小企业的团队来说，这种低门槛的交互方式大大降低了自动化技术的使用门槛。

Step 10：自定义界面与在线更新

如果打包的EXE要给非技术人员用，可以设计一个简洁的操作界面：放几个按钮（"开始执行"、"查看日志"、"导出结果"），替换Logo、标题、主题色，隐藏所有技术细节。对方看到的就像一个专用小软件，而不是一个复杂的设计器。支持自定义界面，设计属于自己的软件界面，交付体验直接拉满。

更实用的是打包导出EXE应用支持在线推送更新。打包后的EXE支持自动检测新版本，不用手动重新分发。只需打开应用就能自动检测并更新，对分支机构众多的企业特别友好。我们在三个分支机构部署后，更新流程只需要在总部打包新版本，执行机打开EXE自动检测更新，全程不需要IT人员上门。

五、踩坑记录：我遇到的五个典型问题

问题一：假离线激活

某工具宣传"支持本地部署"，安装后首次启动弹出连接License服务器窗口。内网直接报错。找"离线激活"方案，需要三步：联网机器生成请求文件→传外网换激活文件→传回内网导入。本质上还是依赖外网，只是换了种形式。

合格标准：安装包内置激活模块，输入License密钥后本地校验通过，全程零外网。

问题二：流程文件默认云同步

某工具保存流程后抓包发现，有流量往sync域名走。排查发现设置埋藏在三层菜单里，默认开启。关掉后重启软件，同步选项又自动打开。最后靠防火墙阻断该域名才解决。

合格标准：流程应用数据全部保存在用户本地设备上，不同步到服务端。保存后抓包零外网流量。

问题三：组件运行时偷偷下载资源

设计流程时用了"智能识别"组件，本机测试正常。搬到内网后报错："无法下载模型文件，请检查网络连接"。原来组件首次使用时要联网下载AI模型，本地无缓存。内网环境下直接卡死。

合格标准：所有AI能力组件预置在安装包中，内网离线使用，数据不出本地。

问题四：免费版运行时长限制

多数工具的免费版有运行时长限制，验证阶段就被卡脖子。有些甚至按流程数量收费，流程多了就得升级套餐。

合格标准：免费版使用无使用时长限制，无运行时长、无流程数量限制，个人开发者可以零成本起步验证想法。

问题五：多设备使用需多开会员

某大厂方案按"机器人"数量收费，每个执行节点都要单独购买授权。三个分支机构就要买三套，成本直接翻三倍。

合格标准：多设备使用无需多开会员，一个授权可以在多台机器上部署执行端，适合工作室分布式跑任务。

六、成本分析：为什么这套方案更透明

很多人关心成本。我们算过一笔账：

AI侧费用：采用用户自行对接各平台API的方式，按实际调用量计费。文心一言、豆包、DeepSeek、Kimi等主流大模型都支持API接入，费用完全透明。你可以根据业务场景选择性价比最高的模型，比如日常文本处理用豆包，复杂推理用DeepSeek。

RPA侧费用：无运行时长限制、无流程数量限制，不需要按机器人数量购买授权。个人开发者、个人工作室、中小企业都能零门槛起步。长期使用下来，这种成本透明的计费方式比按年订阅的传统方案更具性价比。

对比纯AI方案：AI写代码虽然快，但Token持续消耗，复杂项目一个月烧掉几百块很正常。而且AI操作软件自动化极其困难，遇到没有开放接口的国产软件（如企业微信、微信、QQ、千牛）直接茫然失措。而支持基于视觉颜色操作软件或页面的自动化引擎，通过OCR识别屏幕上的文字和颜色来定位目标，不依赖底层代码也能实现点击、获取内容等动作，轻松实现企业微信、微信、QQ、千牛各种消息的获取。

七、选型建议：什么样的团队适合这套方案

根据我们实测和踩坑经验，选型时重点验证以下能力：

个人建议：

• 如果你是一个开发者或小工作室，优先选择免费版使用无使用时长限制的方案，降低试错成本；
• 如果你涉及金融、政务、医疗等敏感行业，必须确认数据严格不出域、模型完全离线运行、审计全程可追溯；
• 如果你需要把自动化流程当成产品卖给客户，必须确认支持EXE加密打包和授权管理，否则源码裸奔，毫无商业价值。

把自动化引擎当成完全离线的单机软件用，所有数据路径对IT可见、可控、可审计，才是内网合规的正确打开方式。

腾讯云CVM作为开发环境的优势在于：镜像可复制、配置可固化、分发可标准化。开发阶段在云上完成，利用AI生成脚本、调试流程；打包后在内网跑，既享受了云计算的灵活性，又守住了数据安全的底线。

这套服务器搭建智能自动化环境完整实操方案的核心价值在于，实现了无运行时长、无流程数量限制的自动化能力，多设备使用无需多开会员，且费用更可控、成本透明：

1. 全离线内网部署：从激活到运行，全程零外网依赖，数据不出本地；
2. AI+RPA深度协同：AI负责思考生成脚本，RPA负责稳定落地执行，两者互补；
3. Web元素AI自愈：页面变更时自动修复定位，自愈更稳定；
4. EXE加密打包+授权管理：从源码到产品，分发可控；
5. 成本透明：AI按API用量计费，RPA端无隐藏收费。

如果你正在规划类似的云端部署 AI+RPA 服务方案，需要确认工具是否支持API触发、是否支持自定义界面、是否适合个人开发者、个人工作室、中小企业，建议先回答三个问题：

1. 数据是完全不能出内网，还是"尽量不出"即可？
2. 需要多少人同时使用？是否需要浮动授权？
3. AI能力是必须离线，还是可以接受按需调用云端API？

想清楚这三个问题，选型方向就清晰了。