RPA 並行任務踩坑：同時操作淘寶、抖店及拼多多的死鎖與資源管控方案

简介： 本文记录作者管理11家电商店铺（淘宝6、抖店3、拼多多2）时，RPA并发任务遭遇的四大死锁场景：全局锁僵死、浏览器实例假死、共享文件写坏、元素失效雪崩。详解基于资源隔离的三层管控方案——按店分锁、配额限实例、原子化数据操作、AI自愈+熔断调度，并附可落地的Python调度器代码。核心结论：死锁根源不在工具，而在资源边界未厘清。

踩坑背景

我手里一共11家店：淘宝6家、抖店3家、拼多多2家。去年年初开始，我把订单处理、库存同步、客服消息这些重复动作逐步交给RPA，一台Windows工作站一天要跑十几个流程。真正让我栽跟头的不是流程写不出来，而是并发——所有流程一起开跑的日子，死锁和资源争抢三天两头把机器拖死，订单卡单、库存错乱都发生过。这篇RPA并发任务踩坑实录，记录我同时操作淘宝、抖店、拼多多时遇到的四个死锁现场，以及最后落地的死锁与资源管控方案。结论先说：问题不在工具，在资源边界没划清。

一、一把大锁锁全身：全局锁死锁

最早我怕流程互相干扰，给所有流程加同一把全局锁——同一时刻只允许一个流程跑，跑完释放，下一个再抢。听起来稳，实际是灾难源头。

有天下午抖店的一个页面加载特别慢，锁迟迟不释放；拼多多的流程等不及开始重试抢锁，淘宝的流程又排在拼多多后面……三个流程互相等待，CPU占用不高，机器却像死透了一样。这就是典型的死锁：不是资源不够，是锁的粒度错了。

我把这个坑写进RPA并发任务踩坑清单第一条：锁要按资源分，不能按全局分。落到方案上就是——每个店铺一个独立流程，配独立的浏览器实例。我现在用的这款工具支持应用多开运行、同时控制多个浏览器，让我能给11家店各开一个实例，互不挤占。而且无运行时长限制、无流程数量限制，我才敢把一个大流程拆成11个小流程——这是后面所有资源管控方案的前提。

二、浏览器实例池：从开多少算多少到配额制

拆成11个流程后，新问题立刻来了：同时操作淘宝、抖店、拼多多，登录态要保住，每个实例都挂着店铺后台，内存直接见底，页面批量假死。资源管控方案的第一块拼图，是给浏览器实例做配额。我的工作站是32G内存，实测同时挂5个实例就到瓶颈，于是定了三条规矩：

实例池上限4个，超出排队；
每平台最多2个实例并发，淘宝店铺多，再按店铺细分；
每个实例设心跳，连续3次无响应判定假死，强制回收重建。

假死判定我用了一个讨巧的办法——视觉颜色操作。不依赖页面元素，直接看关键区域的颜色状态，灰屏、白屏、登录跳转页都能识别出来，识别到异常就回收实例并通知我处理。这套配额加回收的机制，把实例假死率从每天都要处理，降到了一周一两次。我还给这套机制配了个自定义界面做监控面板，哪个实例在跑、哪家店在排队，一眼能看到。

三、共享数据竞争：小文件也能翻车

第三个死锁现场不在浏览器里，在磁盘上。多流程同时读写同一个库存Excel，你写一半我读一半，表直接损坏；两个流程同时改写JSON配置，文件变半截。有天对账差了47件货，我翻了两个小时记录才发现是并发写入撞了车。

修复思路是三件事：每个店铺独立数据文件，物理隔离；写入加锁，同店铺流程排队；写入用临时文件加原子替换，写一半断电也不会留烂摊子。流程里的变量管理也跟着规范了：变量批量创建、按变量名精准操作，数据提取和JSON字段提取都走标准指令，不再靠流程里随手定义的临时变量。现在回头看，RPA并发任务踩坑里让我肉疼的一课其实是这个——并发写坏的从来不是浏览器，是你的数据。

四、元素失效连锁：一个按钮引发的雪崩

淘宝改版过一次订单列表页，按钮结构变了，三个平台的流程里有好几处定位依赖相似结构，当天集体失灵。更要命的是我早期写的重试逻辑：报错就重试，重试就再开页面，失败流程堆在实例池里出不来，正常的流程拿不到资源——雪崩。

资源管控方案里必须给失败留一条泄洪道：单个流程重试3次封顶，间隔500到800毫秒随机抖动；3次还失败就熔断，释放实例和锁，截图留证；截图自动发到我的企业微信，人工接手。

而大部分失效其实走不到人工这步——我现在用的这款工具自带Web元素AI自愈，页面元素变了会自动修复定位，流程接着跑不中断。平时搭流程，元素路径本地智能生成，选一条稳定的直接用，不用啃xpath语法。这次淘宝改版，11个流程只有2个走了人工兜底，其余全部自愈通过。自愈更稳定这四个字，在并发场景下最能体现价值：失效流程不再堆积，实例池不会被失败流量打满。

五、资源管控方案：三层架构加一个调度器

踩完上面的坑，最后沉淀下来的死锁与资源管控方案是一个三层结构：资源层管浏览器实例池、每平台信号量、数据文件锁；流程层是单个店铺的标准动作，含重试、熔断、留证，公共逻辑自动化创建子流程复用；调度层决定谁先跑、谁排队、谁熔断。调度层是核心，直接上代码，通用实现，业务流程处替换为自己的流程即可：

import time, random, logging, threading

logging.basicConfig(
    filename="quota_scheduler.log",
    filemode="a",  # 追加模式
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(threadName)s %(msg)s",
)

class Quota:
    """每平台一个配额：并发数加单日上限，防止任务堆积"""
    def __init__(self, platform, concurrent=2, daily_limit=200):
        self.platform = platform
        self.sem = threading.Semaphore(concurrent)
        self.daily_limit = daily_limit
        self.count = 0
        self.lock = threading.Lock()
        self.day = time.strftime("%Y-%m-%d")

    def acquire(self):
        with self.lock:
            if self.day != time.strftime("%Y-%m-%d"):
                self.day, self.count = time.strftime("%Y-%m-%d"), 0
            if self.count >= self.daily_limit:
                logging.warning("quota exhausted: %s", self.platform)
                return False
            self.count += 1
        return self.sem.acquire(timeout=300)  # 排队5分钟拿不到就放弃

    def release(self):
        self.sem.release()

def run_task(name, fn, quota, retries=3):
    """随机抖动加指数退避重试加for-else熔断"""
    if not quota.acquire():
        logging.warning("skip: %s (quota exhausted)", name)
        return
    try:
        for attempt in range(retries):
            time.sleep(random.uniform(0.5, 0.8))  # 500~800ms随机抖动
            try:
                fn()  # 替换为你的流程动作
                logging.info("done: %s", name)
                break
            except Exception:
                logging.exception("retry %d failed: %s", attempt + 1, name)
                time.sleep(2 ** attempt)
        else:
            logging.error("circuit broken: %s", name)  # 此处插入截图加通知人工
    finally:
        quota.release()

三个细节说一下：信号量按平台划分，淘宝挂了自己的实例也不会饿死抖店；单日上限是防重试风暴的第二道闸，哪怕代码写崩了也翻不了天；所有日志追加写，跑一个月日志也才几兆。

这段代码的由来也值得说说——它不是我写的。AI写代码，RPA跑代码：调度器从信号量到熔断，是我把需求描述给AI后生成的，再通过自定义Python代码扩展挂进流程里跑。写代码这步AI又快又稳，要长期稳定运行的是RPA这层。和AI无缝配合的分工就是这样：AI负责思考，RPA负责稳定落地。

六、数据安全：多店铺数据必须物理隔开

11家店的数据都在一台机器上流转，安全这关我看得比效率重。全离线内网部署是我的硬要求：工作站接在办公内网里，在物理层面与外网隔离；流程数据不出本地，全部保存在本地设备上，不同步任何服务端。离线更安全，数据边界一目了然。

多店铺运营还有一个绕不开的话题是登录环境隔离。我接了指纹浏览器来做这件事，紫鸟、比特、Hubstudio、AdsPower都支持，主打的是多店铺合规运营：每家店一个干净的浏览器环境，日常操作都在平台规则之内。

七、AI协作与调试

调试报错那阵，我最怕看到满屏红字。看不懂的报错直接丢给AI智能修复，错误原因和修复建议一并给出来，确认后一键修好，不用硬啃日志。有段库存回写的Python脚本，我用AI生成脚本一键转流程转成能调试的流程，哪一步不对劲随时停下来看变量。后来搭新流程也省事，它支持AI自动化搭建流程，我说一句先查库存再回写状态，骨架直接就出来了。

工具接入了文心一言、豆包、DeepSeek、Kimi这些大模型，图片识图和OCR识别也配了——商品图上的活动文字直接读成文本，省得我手敲。需求说不清的时候更方便，丢张截图配几句描述，AI照着图就能把流程搭出来。

我还把工具通过MCP挂到了Workbuddy、codex、Claude、TraeWork、豆包工作上，写代码的智能体直接控制RPA来搭流程。日常用得最多的是Agent功能，底层跑的是最新的DeepSeekV4模型：我在钉钉、飞书、企微、个人微信里发一条指令就能触发执行，跑完结果自动回传。有回在外面吃饭，钉钉弹出11家店的当日任务汇总，那一刻觉得这半年没白折腾。

八、交付与运维：把方案装进EXE

方案跑稳之后，合伙人那边也想要。我直接把整套流程做了EXE加密打包+授权管理发过去，程序带授权码，过期超限都控得住。他那边走API触发，OA系统带参数调接口就能执行库存同步，定时执行随包设好，人到点不用碰电脑。中途我改过两版，走的都是热更新（在线推送更新），他打开应用就自动检测新版本，我不用再手动发安装包。后来他组里有人想试用，整套流程加密分享过去，授权到期自动失效，比挨个装环境省心多了。

九、成本账

我用的这款工具费用结构对个人开发者、个人工作室、中小企业都友好：成本透明，AI功能采用自行对接各平台API的方式，用多少花多少；免费版无使用时长限制，前期我白嫖了很久验证方案可行性；多设备使用无需多开会员，我三台机器共用一个授权，不用重复付费。

回到标题：RPA并发任务踩坑，坑的不是流程写不出来，而是同时操作淘宝、抖店、拼多多时资源边界没划清。死锁与资源管控方案说到底就三句话：锁按资源分、实例按配额管、失败有泄洪道。