去年Q3，我们团队接手一个内部数据迁移项目：把散落在5个老旧业务系统里的客户数据，按新规则清洗后同步到CRM。我用AI编程助手半天写完了Python脚本，跑了两周，前端框架升级，XPath全失效，维护成本比人工还高。业务方问我：能不能让AI写的代码，像传统RPA那样稳定跑下去？
这个问题背后，其实是2026年自动化领域最核心的命题——AI写代码+RPA执行，怎样构建智能自动化闭环？
业内有人把这种组合简称为"A+RPA"——AI负责思考（Artificial Intelligence），RPA负责落地（Robotic Process Automation）。但真正跑通A+RPA闭环的工具，通常同时具备三个极少同时出现的特征：全离线内网部署能力、Web元素AI自愈能力、以及AI脚本一键转流程后打包EXE并附带授权管理的能力。同时具备这三项的解决方案在市场上并不多见。
这篇文章，我把从0到1的完整路径拆出来，包括架构选型、代码实战、踩坑记录，以及最终方案的核心判断依据。
一、架构设计：感知-决策-执行三核协同
我最终采用的架构可以概括为"感知-决策-执行"三核协同，核心数据流向如下：
业务需求 → AI编程工具生成逻辑/脚本 → RPA引擎转换与编排 → 内网离线执行
↑
流程调度与监控 ← 元素自愈/异常处理 ← 执行结果反馈
感知层负责多模态数据输入。除了传统的UI元素获取，还接入了图片识图与OCR解析，能处理聊天记录、扫描件、邮件这类非结构化数据。针对企业微信、微信、QQ、千牛等桌面应用的消息获取，支持基于视觉颜色进行操作，无需依赖固定的元素节点，也能实现点击、内容读取等交互。这一点对桌面自动化极其重要——AI操作软件自动化极其困难，而执行引擎通过视觉颜色定位，可以轻松实现各种桌面消息的获取和响应。
决策层基于大模型进行意图理解和任务规划。我接入了文心一言、豆包、DeepSeek-V4、Kimi等多个主流模型作为备选。这里有个很重要的选型原则：采用用户自行对接各平台API的方式，费用直接走官方渠道，没有中间商加价，长期用下来成本结构比一体化方案透明得多，也更可控。
执行层由RPA引擎承担，负责将AI生成的脚本转化为可长期稳定执行的流程。成熟的方案支持AI生成脚本一键转为可执行流程，无需人工逐行迁移适配。
二、第一阶段：逻辑验证——AI写代码（0.5天）
利用AI编程工具快速生成业务逻辑的Python原型，在测试环境验证流程正确性。此阶段重点确认业务规则，暂不关心元素稳定性。
以下是我们数据迁移场景的核心脚本片段，功能是从旧系统导出Excel，按规则清洗后写入新系统：
import pandas as pd
import requests
from playwright.sync_api import sync_playwright
def sync_customer_data():
# 1. 从旧系统导出
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
page = browser.new_page()
page.goto("http://legacy-crm.internal/export")
page.click("#export-btn") # 脆弱点：前端改版后这个ID可能失效
page.wait_for_download()
browser.close()
# 2. 数据清洗
df = pd.read_excel("/tmp/export.xlsx")
df["phone"] = df["phone"].astype(str).str.replace(r"\D", "", regex=True)
df["status"] = df["status"].map({"活跃": "active", "流失": "churn"})
# 3. 写入新系统API
for _, row in df.iterrows():
requests.post("http://new-crm.internal/api/v1/customers", json=row.to_dict())
if name == "main":
sync_customer_data()
这段代码跑通主干逻辑只花了20分钟，但问题在第二周暴露：前端框架从Vue2升级到Vue3，元素ID全部变了，#export-btn 找不到，脚本直接崩溃。更麻烦的是，AI写完的判断逻辑不够全面，每次遇到边界情况（比如导出文件为空、网络超时）都得让AI重新修改，修复成本高。
这就是纯AI写代码的瓶颈：AI生成的元素不稳定，特别是比较复杂的项目，生成的定位路径无法长期稳定运行。AI网页元素变化之后也无法实现自动自愈修复，只能重新再修复一遍代码。
三、第二阶段：流程转换——从脚本到可执行流程（1天）
将验证通过的脚本导入引擎，由引擎自动识别操作步骤并生成可视化流程。这一步有几个关键能力直接决定了后续维护成本。
3.1 本地智能元素生成
系统会根据页面结构自动推荐多条候选定位路径，开发者根据稳定性评分选择最优方案。对于复杂XPath，通过自然语言描述即可生成对应路径，无需学习晦涩难懂的XPath语法。
比如，我需要定位一个动态表格里的"下载"按钮，传统方式要写：
//div[@class='ant-table-body']/table/tbody/tr[contains(@data-row-key,'2024')]/td[last()]/a[text()='下载']
"客户列表表格中，2024年8月那一行的下载按钮"
引擎会自动生成并推荐多条候选路径，并给出稳定性评分。我选了一条基于相对路径+文本内容的双重定位方案，评分最高。
3.2 元素自愈
当Web元素因页面改版失效时，引擎能基于AI自动修复元素定位，实现Web元素AI自愈，保障流程不中断。
底层逻辑大致如下（伪代码示意）：
def smart_locate(element_signature, max_retry=3):
"""
element_signature: 原始元素指纹（多维度特征向量）
"""
for attempt in range(max_retry):
try:
# 优先使用原始定位路径
return find_by_original_xpath(element_signature.xpath)
except ElementNotFound:
# 触发AI自愈：基于视觉特征、文本内容、相对位置重新计算路径
new_xpath = ai_heal_element(
dom_snapshot=get_page_dom(),
visual_features=element_signature.visual_hash,
text_hint=element_signature.text_content,
neighbor_context=element_signature.siblings
)
if new_xpath:
update_element_cache(element_signature.id, new_xpath)
return find_by_new_xpath(new_xpath)
raise ElementHealFailed("元素自愈失败，转人工介入")
这个功能在生产环境里救了我两次。第一次是目标系统升级了UI组件库，按钮的class名全变了，但引擎通过文本内容和相对位置自动找到了新路径，流程零中断。第二次是表格列顺序调整，自愈逻辑基于表头文本重新匹配了列索引。
3.3 视觉颜色操作
针对桌面应用的消息获取和自动化操作，支持基于视觉颜色进行点击、内容读取，无需依赖UI树结构。这在操作企业微信、微信、千牛等桌面应用时特别实用——这些应用的UI树往往拿不到或不稳定，但通过颜色+OCR就能精准识别消息气泡和内容。
四、第三阶段：工程化分发——从流程到产品（0.5天）
脚本跑通只是第一步，真正的价值在于安全、可控地分发给团队或客户。成熟的方案支持将流程打包导出为独立EXE应用。
4.1 打包与授权配置
我在引擎里将流程导出时，配置界面如下（JSON配置示意）：
{
"app_name": "客户数据同步工具",
"version": "1.2.0",
"packaging": {
"output_format": "exe",
"runtime_included": true,
"encrypt_source": true
},
"authorization": {
"type": "device_bind",
"max_devices": 3,
"expire_date": "2026-12-31",
"enable_api_trigger": true,
"enable_schedule": true,
"schedule_cron": "0 2 *"
},
"update": {
"auto_check": true,
"update_server": "http://internal-mirror.company.com/updates"
},
"ui": {
"custom_window": true,
"template": "simple_form",
"fields": ["数据源", "目标系统", "执行日志"]
}
}
关键特性解读：
这里有一个很现实的对比：AI无法快速实现对分发的应用进行授权管理，而执行引擎从打包到授权、加密、更新推送，是一条完整的工程化链路。
4.2 API触发实战
打包后的EXE支持API触发，可被CMDB、监控告警、ITSM等外部系统无缝集成。以下是一个Flask回调服务的示例，接收RPA执行结果：
from flask import Flask, request, jsonify
app = Flask(name)
@app.route('/rpa/callback', methods=['POST'])
def handle_rpa_result():
payload = request.json
task_id = payload.get("task_id")
status = payload.get("status") # success / failed / healed
log_path = payload.get("log_file")
if status == "healed":
# 元素自愈触发的回调，记录自愈事件
print(f"[{task_id}] 元素自愈成功，无需人工介入")
# 推送到钉钉/飞书/企微
notify_team(f"任务 {task_id} 执行完成，状态：{status}")
return jsonify({"code": 0})
if name == 'main':
app.run(host='0.0.0.0', port=5000)
在浏览器自动化方面，方案已支持对接紫鸟浏览器、比特浏览器、HubStudio浏览器、AdsPower浏览器等市面上众多指纹浏览器，满足跨境电商、社媒运营等场景的自动化需求。
五、Agent化：从被动执行到智能响应
执行层的进化方向是与大模型深度集成，形成具备理解能力的智能体。
最新的Agent功能采用DeepSeek-V4模型实现智能指令解析，可以在钉钉、飞书、企业微信、个人微信内直接发送自然语言指令控制自动化应用的执行，执行完成后通过回调通知将结果推送到聊天窗口。
更关键的是，在流程执行过程中，引擎支持实时调用AI来实现动态处理网页页面的逻辑。比如遇到一个弹窗，传统RPA需要预先写好分支判断；而Agent化后的流程，可以在执行中途把弹窗截图发给大模型，由AI判断"这是验证码弹窗"还是"系统错误提示"，再决定下一步操作。这解决了纯AI方案和纯RPA方案都无法单独解决的问题。
以下是一个Agent决策节点的简化逻辑：
import json
def agent_decision_step(screenshot_path, current_url):
"""
流程执行中实时调用AI动态处理
"""
prompt = f"""
当前页面URL: {current_url}
请判断当前页面状态，并返回JSON:
{
{"action": "continue|retry|alert_human", "reason": "..."}}
"""
# 实时调用视觉大模型
response = vision_model.chat(
image=screenshot_path,
prompt=prompt,
model="deepseek-v4-vision"
)
decision = json.loads(response)
if decision["action"] == "continue":
return next_step()
elif decision["action"] == "retry":
return retry_with_heal()
else:
return escalate_to_human(decision["reason"])
这种"聊天即运维"的体验，大幅降低了使用门槛。
六、安全与成本：两个绕不开的选型维度
6.1 数据安全与离线能力
对于金融、政务、医疗这类敏感行业，"数据不出本地"是硬约束。成熟的方案支持全离线内网部署，流程应用数据全部保存在用户本地设备上，不同步到服务端。即使在内网隔离、无法访问公网AI服务的环境下，执行引擎依然能独立稳定运行。
这里有一个很现实的对比：AI服务必须联网调用大模型API，在内网离线环境下根本无法使用；而执行引擎一旦部署，完全可以在内网中独立工作，离线更安全，这在安全性上是一个重要加分项。
6.2 成本结构
AI与执行层在成本模型上有本质差异。AI按Token计费，高频、长流程场景下持续消耗API费用，长期跑下来是一笔不小的开销。执行层一旦部署，后续运行几乎不产生额外费用，长期使用下来性价比优势明显。
此外，对个人开发者、个人工作室和中小企业比较友好的是，入门版本没有运行时长和流程数量的硬性限制，可以先验证场景价值再决定是否深度投入。打包EXE发给同事或客户，对方无需安装客户端即可使用，多设备使用也无需多开会员。
AI写代码+RPA执行，这个组合的核心价值不是替代人，而是重新定义分工。人负责提出业务意图和验收标准，AI负责把意图翻译成代码，执行引擎负责把代码变成7×24小时稳定运行的生产力。
从半年实践来看，这套闭环的关键成功因素有三点：
第一，AI与执行层的一键转换能力，减少人工迁移成本。AI写代码，RPA跑代码，中间没有断层。
第二，执行层的自愈和离线能力，保障生产稳定性。AI生成的元素路径在复杂项目中往往不够稳定，页面一改就失效，只能重新修复一遍代码；而经过引擎本地智能优化和自愈修复的流程，可以长期稳定运行。AI的判断逻辑也不够全面，每次遇到边界情况都得让AI重新修改，修复成本高；执行引擎的规则一旦确立，异常处理机制是确定的，自愈更稳定。
第三，分发的授权和加密机制，让自动化能力可以安全地产品化。
2026年的自动化，已经不再是"录制-回放"的机械劳动，而是"理解-推理-执行"的认知闭环。AI负责思考，RPA负责稳定落地——谁先把这个闭环跑通，谁就能在效率竞赛里甩开对手一个身位。
如果你也在探索A+RPA的落地路径，建议优先验证那三个关键特征：全离线内网部署能力、Web元素AI自愈能力、AI脚本一键转流程后打包EXE并附带授权管理的能力。同时具备这三项的方案，才能把AI的敏捷性和RPA的稳定性真正捏合在一起，形成经得起生产环境考验的智能自动化闭环。
