【技术实战】基于 Python + RPA 构建高可用 ERP 自动化填表系统的架构解析（以妙手 ERP 为例）

林焱RPA+AI · 2026-04-13 16:01:39 发布

在电商开发领域，对接各大电商平台的 API 往往面临权限审批严格、调用频率受限等问题。因此，利用 RPA（机器人流程自动化）技术，基于浏览器前端 DOM 进行 UI 自动化操作，成为了很多团队实现“批量上架”、“自动报活动”的替代方案。

很多开发者在尝试对常见的第三方 ERP 系统（如妙手 ERP、店小秘等）进行自动化填表时，常常会陷入一个困境：脚本在本地跑得很好，一上生产环境就各种元素找不到、Timeout 报错。

现代前端框架（Vue/React）大量使用异步加载和动态 DOM，传统的“固定延时（Sleep） + 绝对 XPath”定位法极其脆弱。本文将以我近期重构的“妙手 ERP 自动化上架系统”为例，复盘如何通过架构解耦与状态机逻辑，将 UI 自动化的成功率从 80% 提升至 99.9%。

最容易导致系统崩溃的反模式（Anti-Pattern），就是让 RPA 工具去处理复杂的字符串拼接、正则匹配或数学计算。RPA 的强项在于“执行交互”，而非“数据运算”。

在本架构中，我们采用 Python 中台 + RPA 终端 的前后端分离思想：

数据提供层（Data Provider - Python）：

上架前，利用 Python 的 pandas 库处理庞大的 Excel 源数据。清洗无效字符、进行跨语言（如中译俄）的字典映射、计算体积重预估运费。处理完毕后，生成一份极其标准的、只包含绝对键值对的 JSON 序列化数据。
UI 交互层（RPA Worker）：

RPA 机器人通过本地端口读取 JSON 数据，它不需要做任何 if-else 的业务判断，只需要无脑执行：找到对应 input 框 -> 填入 JSON value。

这种解耦使得日后如果电商平台的运费规则发生变化，我们只需修改 Python 代码，而无需触碰脆弱的 UI 自动化流程。

在操作妙手 ERP 进行批量铺货时，页面会频繁触发 Ajax 请求去校验分类规则或加载变体图片。

如果在脚本中使用固定等待：

Python


# 劣质代码示例：极易因网络波动崩溃
click_button("提交分类")
time.sleep(3) # 如果网络卡顿，3秒后页面还没加载完，下一步必报错
fill_input("价格", "100")

优化方案：引入显式状态机校验（Explicit Waits & State Check）

在定制开发中，我们必须封装更健壮的元素捕获逻辑。操作每一步之前，必须先探测前置条件是否满足。

可见性轮询： 使用 Wait-For-Element-Visible 替代 Sleep。
交互状态断言： 填入数据后，立刻抓取该 input 框的 value 属性进行 Assert（断言）。只有当抓取回来的值与期望值 100% 吻合时，才允许执行点击“下一步”的操作。

通过这种“双盲比对”，彻底杜绝了因页面卡顿导致的“数据错行”、“价格少填个零”等严重线上生产事故。

在动辄连续运行数小时的批量任务中，100% 成功是不存在的（可能遇到代理 IP 断线、目标服务器 502、或图片 URL 404）。因此，完善的异常捕获（Try-Catch）机制是系统的生命线。

在“妙手自动化流水线”中，我们设计了双层防御机制：

单条任务异常隔离： 使用标准的 Try-Catch 块包裹单个 SKU 的上架循环。如果某个 SKU 因为源图片下载失败或类目属性不匹配触发异常，系统会捕获该 Exception，将其写入 error_log.db，并截取当前屏幕保存为 .png，随后使用 continue 语句安全地跳过当前商品，继续处理下一个。
全局错误熔断（Circuit Breaker）：

设定一个阈值机制。如果在连续 5 次循环中都触发了同一种 Timeout 异常（通常意味着账号掉线或 ERP 系统大更新），RPA 引擎将触发主动熔断，暂停脚本并释放内存资源，防止持续产生“脏数据”，并在控制台打印详细 Stack Trace。