代运营几十家店怎么管？多租户RPA中台：隔离淘宝、拼多多店铺任务队列

做电商代运营第五年，我手上同时管着6个客户、31家店，淘宝17家、拼多多14家。同行聚一起喝茶，被问得最多的就是：代运营几十家店怎么管？我的真实经历是，难的地方不在某个流程不会写，在于所有店挤在两台电脑上——这台机器跑着A客户拼多多店的改价，另一台忽然弹出B客户淘宝店的催发货窗口，两个流程抢同一套鼠标键盘，谁也没跑成，订单数据还混在一个文件夹里，月底对账说不清哪笔是哪家的。

后来我把整套活重新捋了一遍：给每个客户建独立"租户"，把店铺任务队列一条条隔开，调度归调度、执行归执行，才有了现在这套多租户RPA中台——客户数据全部数据不出本地，跑流程的机器全离线内网部署。这篇把踩过的五个坑按顺序写完，附上调度器代码，给同样被几十家店缠住的人参考。

一、先把中台拆开：三层比一锅粥强

回到开头那个问题，代运营几十家店怎么管？我的答案是先把多租户RPA中台搭起来，而且别做复杂，就三层：

租户层：客户和店铺的台账，哪个客户名下有哪些店、数据放哪个目录、每店每天跑多少任务，全部写进一份配置；

调度层：只看队列和配额，决定此刻放哪家店的哪条任务，盯单日上限和连续失败次数；

执行层：真正操作浏览器的流程应用。我用的这款工具免安装浏览器插件即可使用，执行机上同时控制多个浏览器互不干扰，需要并行时再开应用多开运行。

层与层之间只传任务名和参数，执行层不知道也不关心别的客户是谁——这就是"隔离"在中台里的实际含义。店铺任务队列各走各的通道，冲突在结构上就被消掉了。

二、坑一：任务互相抢资源，店铺任务队列必须按店隔离

最早我把所有店的任务写进一个待办列表，哪台机器空了就捞一条。听起来合理，跑起来灾难：上一条任务给店铺A的页面留了半拉状态，下一条店铺B的任务进去就报错，失败重试又挤占后面的店铺任务队列，恶性循环。

改法很朴素：一店一队列，调度器按队列轮转，每个队列有独立配额和独立断点。下面这段是我现在跑在调度机上的简化版，店铺任务队列的隔离就靠它撑起来（run_shop_task是伪接口，换成你实际触发流程应用的函数即可）：

# 排队调度器：每个店铺一条独立队列，互不争抢
import json, time, random, logging
from datetime import date

logging.basicConfig(filename="queue.log", filemode="a", level=logging.INFO,
                    format="%(asctime)s %(message)s")

def run_shop_task(shop):
    # 伪接口：换成你实际的任务函数，例如触发某个流程应用
    print(f"执行 {shop} 的店铺任务")
    return True

def load_breakpoint(path):
    try:
        with open(path, encoding="utf-8") as f:
            return set(json.load(f))
    except (FileNotFoundError, json.JSONDecodeError):
        return set()   # 断点文件损坏就当全新开始，队列不中断

def scheduler(shops, day_limit=30, breaker=10):
    done = load_breakpoint("done_today.json")
    fails = 0
    for shop in shops:
        if len(done) >= day_limit:      # 单日上限在循环内二次检查，防长队列冲破
            logging.info("已达单日上限，剩余任务明天继续")
            break
        if shop in done:
            continue
        for attempt in range(3):        # for-else：三次都失败才放弃
            try:
                time.sleep(random.uniform(0.5, 0.8))  # 500~800ms 随机间隔
                run_shop_task(shop)
                done.add(shop)
                with open("done_today.json", "w", encoding="utf-8") as f:
                    json.dump(sorted(done), f, ensure_ascii=False)
                fails = 0
                break
            except Exception as e:
                wait = 2 ** attempt       # 2、4、8 秒指数退避
                logging.info(f"{shop} 第{attempt + 1}次失败：{e}，{wait}s 后重试")
                fails += 1
                if fails >= breaker:      # 熔断：连续10次失败先停，人工看日志
                    logging.info("触发熔断，暂停调度")
                    return
                time.sleep(wait)
        else:
            logging.info(f"{shop} 三次重试均失败，保留现场待人工处理")

实测参数供参考：单店单日上限30条（配置里每店单独设，拼多多新店我压到25），间隔500~800毫秒随机抖动，重试三次、退避2/4/8秒，连续失败10次熔断停机人工介入。有一个细节是我吃了亏才补上的：单日上限必须放在循环体内二次检查，不然队列一拉长，一轮跑完超额任务会冲破上限；断点文件是JSON，遇到断电写坏，捕获JSONDecodeError后按全新一天重建，队列不断。

对比一下三种做法就明白为什么要这么改：

调度层我还给店铺任务队列挂了定时执行和API触发：常规日活走定时器，客户临时喊"帮我把这批SKU改一下"，我从自己写的面板发API接口带参数触发执行，不用远程桌面挤进执行机。

三、坑二：客户数据混放，安全账先算清

代运营这行，客户把店铺交给你，交的是信任。我定的死规矩：所有流程数据全离线内网部署，订单、买家信息、资金数据一律数据不出本地，调度机只做任务分发不碰数据。离线更安全这条，对代运营来说是底线——内网里跑流程，客户才放心把店铺账号交给你维护。

店铺环境我接了两款主流指纹浏览器，每家店固定一个独立环境，配合多店铺合规运营的要求把边界划清：环境归环境、数据归数据，任何客户的资料不进第二个客户的目录。月底交付也简单，整个客户目录整体拷给客户，我这边不留副本。

四、坑三：平台页面一改版，流程成批躺平

店多了，迟早赶上平台改版。去年拼多多卖家后台调了一次布局，我14个店有9个流程集体失灵，那天是真体会到什么叫维护地狱。现在用这款工具自带的Web元素AI自愈，元素路径变了AI自动修复定位。自愈更稳定不等于永不失手，而是把"整批躺平"变成"个别补刀"，降低脚本维护成本才算真正落了地——以前改版要熬两个通宵，现在喝杯茶的功夫看自愈报告就行。

改版之后元素也得重新摘：它的元素获取支持本地智能生成，会根据生成结果挑一条稳定性高的元素路径；遇到canvas画出来的按钮，用图像识别兜底点按。

维护阶段真有自愈修不了的，我用自然语言描述让AI生成对应xpath，比手抠路径快得多。每次失败先开AI错误诊断看原因和修复建议，再决定手动改还是AI智能修复一键修。

兜底通知我做了双保险：流程卡住先截图留证，再用视觉颜色操作读千牛和企业微信的消息窗口，看到红字报错截图自动推给我，不会傻等。

五、坑四：让AI干活，而不是让AI添乱

现在流程搭建我跟AI分工明确：AI写代码，RPA跑代码；AI负责思考，RPA负责稳定落地。一句话说清就是和AI无缝配合——想法、判断、异常处理归AI，稳定、重复、按点执行归RPA。当然，工具只管执行，流程设计得自己拿主意，烂流程套再好的工具也白搭。

具体怎么落地？客户甩来一段Python脚本，我用AI生成脚本一键转流程，转完直接进店铺任务队列。

从零搭建就走AI自动化搭建流程，浏览器自动化、Windows软件自动化都能搭。

给同行代搭流程时，需求懒得打字就图文方式描述需求，截个图标两句就行。

写代码它也帮得上：自定义Python代码扩展直接挂进流程，上面那个调度器就是这么跑的。流程长了让它自动化创建子流程，拆成可复用的块，每段指令带详细注释，逻辑一目了然。

流程里的数据搬运也省事：变量支持批量创建、删除、修改，JSON自动提取字段、列表自动提取按需生成指令。

模型方面接的是国内主流大模型，API自己对接，调试报错不用猜。

更实用的一点是流程执行过程中能实时调用AI做动态判断：详情页文案长短不一，让AI现场决定填哪版，不用事前写死所有分支。我以前在编程工具里写好的流程逻辑，得复制回来手动重建；现在它支持MCP协议，几个常用的AI编程工具都能直接驱动它搭流程，代码写完即流程，不用二次搬运。

六、坑五：流程做完只是开头，交付管控才是长期活

流程稳定后我开始接"帮同行代搭流程"的活，交付成了新问题。我的做法是打包导出EXE给客户，EXE加密打包+授权管理一次到位：客户那边不用装客户端，双击就能跑，支持有效期授权，到期自动停用，不怕流程被无限转手。

分发后最怕小改动：以前改一行逻辑要重新发给所有人，现在打包导出的EXE支持在线推送更新，也就是热更新，客户打开应用自动检测新版本，我这边发一次全网生效。临时协作用加密分享，流程和设计稿一起发，权限到期收回。

给客户的小工具我做了自定义界面，按钮和展示位置按他的习惯摆，复杂界面用HTML组件拼。

每月给淘宝、拼多多客户出的经营月报，用Word/PDF自动化从客户的数据目录直接生成，连导出都省了。

最近我还试了它的Agent功能：在常用的办公IM里发一句话就能控制应用执行，跑完把结果推回对话里，人不在电脑前也能盯队列。

七、成本账：代运营毛利薄，工具费必须透明

代运营毛利本来就薄，工具钱必须算细账。这款工具成本透明，AI能力走自行对接各平台API的方式，用多少花多少，没有中间差价；免费版无使用时长限制，对个人开发者和中小企业友好，我先用免费版把31家店的流程验证了两个月，稳定性没问题再谈别的。

真正让我动心的是两条硬指标：无运行时长限制、无流程数量限制，店越开越多不加钱；多设备使用无需多开会员，调度机、执行机随便装。按店数线性涨价的工具，代运营这种模式用不了。

说到底，代运营几十家店怎么管？管的是队列、数据和交付三件事，前两件靠多租户RPA中台把店铺任务队列隔离、让每家客户数据不出本地，最后一件靠打包导出EXE管住交付。

八、选型三条标准

如果你也在被这个问题困扰，选工具时我建议盯三条：一看数据是否真留在本地，数据不出本地是硬门槛；二看页面改版能不能自己缓过来，Web元素AI自愈决定你半夜要不要起床；三看交付能不能控住，EXE加密打包+授权管理省掉的是扯皮时间。