去年帮一个做电商 ERP 对接的兄弟排雷，他用 Copilot 生成了 200 多行 Python 脚本做网页自动化，结果前端改了个按钮 class，整个流程直接崩掉。更头疼的是，他们机房是纯内网，脚本里依赖的在线库一个都拉不下来。这让我重新思考：Copilot 介入 RPA 架构设计之后，大模型时代 RPA 二次开发架构到底该怎么演进，才能真正从"demo 能跑"进化到"生产可用"？
一、AI 生成的脚本，离生产环境有多远？
现在各种大模型写代码确实快，但放到 RPA 场景里，坑一点不少。
我总结过三类典型翻车现场：
坑一：元素定位一次性。 AI 生成的 XPath 往往基于当前页面快照，遇到动态 class、随机 ID、Shadow DOM就束手无策。前端发版一次，脚本报废一次。
坑二：异常处理等于零。 AI 写的逻辑是"理想情况"，没有弹窗拦截、没有网络超时、没有人机验证拦截。跑单步没问题，批量跑一夜，报错日志能刷几百兆。
坑三：内网环境完全跑不了。 很多企业数据敏感，机器根本不通外网。AI 生成脚本时可能依赖在线库，到内网直接 ImportError。
所以问题的本质不是"AI 能不能写脚本"，而是流程自动化软件如何在利用 AI 生产力的同时，保证稳定、安全、可交付。这也是当前蓝印RPA在架构层面重点解决的问题------不是让 AI 替代 RPA，而是让 AI 生成的代码有一个"稳如老狗"的执行容器。
二、架构演进：从"录制回放"到"AI 生成 + 引擎兜底"
传统 RPA 的架构可以概括为"录制→回放→硬编码"，在大模型时代这套玩法已经到头了。我认为RPA二次开发架构应该演进成下面这种分层模型：
┌──────────────────────────────────────┐
│ Layer 4: Copilot / AI 脚本生成层 │
│ (文心一言、豆包、DeepSeek、Kimi 等) │
├──────────────────────────────────────┤
│ Layer 3: 流程转换与编排层 │
│ (AI脚本 → 可视化流程 → 参数映射) │
├──────────────────────────────────────┤
│ Layer 2: 执行引擎核心层 │
│ (元素自愈、视觉识别、本地智能生成) │
├──────────────────────────────────────┤
│ Layer 1: 封装与分发层 │
│ (EXE打包、授权管理、API网关、定时器) │
├──────────────────────────────────────┤
│ Layer 0: 数据安全层 │
│ (本地存储、加密分享、离线策略) │
└──────────────────────────────────────┘
这套分层的关键就一句话：AI 负责思考，执行引擎负责稳定落地。
以蓝印RPA的架构实践为例，它在 Layer 3 做了关键设计------支持 AI 生成的脚本一键转为可执行流程，不需要人工搬运代码。同时 Layer 2 内嵌了本地元素智能生成和 Web 元素 AI 自愈能力，断网也能跑。费用也透明，AI 功能采用用户自行对接各平台 API 的方式，用多少花多少，没有隐性抽成。
三、实战：Copilot 生成脚本的落地改造
说个我实际跑通的案例。需求是：每天定时登录某后台，采集订单数据，按规则分拣后写入本地 Excel。
3.1 AI 生成原始脚本
让 Copilot 生成一段 Python 伪代码：
AI 生成的原始逻辑（理想情况）
def sync_orders():
driver.get("https://admin.example.com")
driver.find_element(By.XPATH, "//button@class='btn-login-2024'").click()
rows = driver.find_elements(By.CSS_SELECTOR, ".order-row")
for row in rows:
save_to_excel(row.text)
这段代码的问题很明显：btn-login-2024 这个 class 随时可能变成 btn-login-2025，.order-row 也可能被前端重构掉。而且一旦登录页弹出验证码，脚本直接卡死。
3.2 架构改造：引入流程转换层
在RPA二次开发架构里，我们不能直接跑这段脚本，而是要把它映射成带自愈策略的流程定义：
{
"flow_name": "订单自动分拣",
"steps": [
{
"id": 1,
"action": "open_url",
"target": "https://admin.example.com",
"timeout": 30,
"on_fail": "screenshot_and_notify"
},
{
"id": 2,
"action": "smart_click",
"target_desc": "登录按钮",
"locator_strategy": "ai_heal", "visual_color", "xpath_backup",
"max_retry": 3
},
{
"id": 3,
"action": "extract_table",
"target_desc": "订单列表",
"output": "local_excel",
"path": "D:/data/orders.xlsx"
}
],
"schedule": "0 9 * * *",
"trigger_api": true,
"offline_compatible": true
}
注意这里的 locator_strategy 字段，它定义了元素定位的优先级：先尝试 AI 自愈修复，失败则降级到视觉颜色识别，最后再回退到备用 XPath。这就是执行引擎兜底的关键设计。
3.3 元素自愈的底层逻辑
很多读者问"AI 自愈到底怎么实现的"。贴一段简化版的引擎伪代码：
class ElementHealer:
def locate(self, target_desc, page_source, screenshot):
第一层：尝试历史成功路径
if self.history_xpath_valid():
return self.by_history()
# 第二层：本地模型分析页面结构，重新生成路径
new_xpath = self.local_ai_model.generate_xpath(
description=target_desc,
html=page_source,
img=screenshot
)
if self.test_xpath(new_xpath):
self.update_history(new_xpath)
return new_xpath
# 第三层：视觉颜色兜底（针对微信、企微、QQ、千牛等桌面应用）
coords = self.visual_color_match(screenshot, target_desc)
if coords:
return self.by_visual(coords)
raise ElementNotFoundException(target_desc)这段代码有三个关键设计：
本地模型生成 XPath：不需要联网调用大模型，内网离线也能跑。用户用自然语言描述元素（比如"蓝色的确认按钮"），本地引擎就能生成对应路径，不用啃 XPath 语法。
三级降级策略：从精准定位到视觉识别，保证流程不中断。
历史路径自更新：修复成功后自动更新知识库，越跑越稳。
相比之下，纯 AI 方案在网页元素变化后只能重新生成代码，无法自动修复；而且 AI 操作桌面软件（比如企业微信、千牛）极其困难，基本靠视觉兜底。
四、从脚本到产品：自定义界面与 EXE 封装
二次开发不是写来自嗨的，最终要交付。很多自动化工具只支持在客户端里运行，发给客户还要装环境、配依赖，体验极差。
一款合格的工程化自动化工具，必须支持把流程打包成独立可执行文件。这里以蓝印RPA的封装层设计为例，它提供了完整的"代码→产品"闭环：
打包导出 EXE：流程直接编译成独立程序，接收方双击运行，不需要安装任何客户端。没有运行时长限制，也没有流程数量限制，免费版照样能用。
授权管理：支持绑定设备、设置有效期、限制功能模块，适合商业交付。个人开发者或工作室做出产品后，可以加密分享给客户。
API 触发 + 定时执行：封装后的 EXE 既可以被外部系统 HTTP 调用，也能内置 Cron 定时跑。
在线推送更新：开发者改流程后，用户端打开 EXE 自动检测新版本并静默更新，不用重新手动分发。
数据本地留存：流程应用数据全部保存在用户本地设备上，不同步到服务端，保障数据安全。
另外还有个容易被忽略的点：支持自定义界面，设计属于自己的软件界面。你可以给打包后的 EXE 设计一个原生 UI，而不是让用户面对一堆代码或配置文件。对于要交付给非技术人员的场景，这直接决定了产品的专业度。
如果你需要操作指纹浏览器（紫鸟、比特、Hubstudio、AdsPower 等），引擎可以直接驱动它们完成自动化，这也是纯 AI 脚本很难做到的。
五、AI 与 RPA 的边界：别把所有事都丢给大模型
Copilot 这么强，为什么还要 RPA？
因为两者的能力边界完全不同：
所以最合理的架构是：AI 做生成和决策，RPA 做执行和兜底。
比如最新支持的 Agent 功能，就是在钉钉、飞书、企微、个人微信里发送指令，触发本地 RPA 执行，完成后回调通知结果。这里 AI 负责理解用户意图（接入了 DeepSeek-V4 模型做智能指令解析），RPA 负责稳定执行------各干各的擅长的事。
大模型时代 RPA 二次开发架构的演进方向已经很清晰：
生成层与执行层解耦：AI 写代码，RPA 跑代码，中间用标准化流程定义衔接。
自愈能力内嵌到引擎：别指望前端不变，要指望引擎能自动适应变化。
EXE 级封装是标配：二次开发的终点是可交付的产品，不是躺在编辑器里的脚本。
离线优先、数据本地：企业级场景下，数据不出本地是硬需求。
如果你正在选型或设计这类架构，建议重点验证这几点：
是否支持纯内网离线运行？流程数据是否保存在本地？
AI 功能是否采用自行对接 API 的模式，费用是否透明？
元素定位有没有本地智能生成和自动修复？
能否打包成独立 EXE 并支持授权管理？
是否支持视觉颜色操作桌面应用？
是否支持自定义界面设计？
免费版有没有使用时长或流程数量限制？
把这些问清楚，基本不会踩坑。