影刀RPA工程实战：多店铺环境隔离体系与自动化流程的事务性保障

一个店铺登录态串到另一个店铺，只在一瞬间。
但要真正杜绝它，需要的是一整套工程约束。

上一篇文章聊了浏览器实例池与并发调度，那套东西帮我们扛住了几十个店铺同时跑的稳定性。但很快我们又遇到了一个新问题：店铺之间的环境边界到底怎么守。

听起来像是个运维规范的问题——只要配置对、目录分好，不就没事了？但实际跑起来你会发现，人是会犯错的，配置是会漂移的，流程里一个不小心的“跳转新页面”就可能让当前浏览器实例沾染了另一个店铺的Cookie。

这篇文章专门讲我们怎么在工程层面，给自动化系统做多店铺环境隔离，以及如何让RPA流程具备基本的事务性保障——出了问题能回滚、能重试、不会留下脏数据。

一、为什么环境隔离是店群自动化的地基

做拼多多、TEMU、TikTok Shop这些平台的矩阵运营，一个执行机往往要承载几十个甚至上百个店铺的自动化任务。每个店铺的环境如果做不到物理级别的隔离，就会出现几种典型事故：

Cookie交叉污染：流程A在店铺甲的页面做了操作，切到店铺乙时残留的认证信息被复用
缓存串扰：本地存储、IndexedDB里残留上一个店铺的标识，导致请求带上错误shop_id
指纹特征关联：多个店铺在同一个浏览器内核、同一网络环境下高频访问，风控侧画像关联

picture.image 对于合规运营来说，我们需要做的不是“绕过平台”，而是让每一个店铺的运营环境看起来就像一台独立的办公电脑——这也是平台乐见的正常经营形态。

picture.image 我见过有的团队试图通过频繁清理Cookie和缓存来解决串号问题，这只能说是一个权宜之计。真正的解决方案，必须从环境创建的那一刻就做到完全隔离，并且没有任何“清理”操作的依赖。

二、环境隔离的四层模型

我们把店铺环境拆成四个层面来分别隔离，每一层都有对应的工程手段。

第一层：浏览器用户数据目录隔离

这是最基础的。每个店铺绑定一个独立的 user-data-dir，里面存放所有持久化状态：Cookie、LocalStorage、插件配置、浏览器偏好设置。我们的池管理器在创建实例时强制校验目录绑定关系。

picture.image

第二层：本地网络环境隔离

如果一台机器上跑多个店铺，同一个IP出口本身就构成关联风险。我们的做法是为每个店铺分配独立的代理出口——注意是合规的固定IP代理，而不是黑产用的秒拨。这个IP就相当于这个店铺的“办公网络”。

第三层：浏览器指纹环境隔离

picture.image 这里需要特别说明：我们不会去篡改或伪造指纹，那属于违规操作。我们做的是通过浏览器启动参数和插件配置，让每个实例的指纹特征由独立的用户数据目录和代理IP自然决定，不做额外干涉。唯一做的“工程化处理”，是确保不同实例之间不会意外共享字体缓存、GPU缓存等系统级资源，因为那些东西可能残留跨实例的特征。

picture.image 第四层：执行机物理/虚拟隔离

picture.image 当店铺数量更多时，直接走虚拟机或者容器化Windows环境，让一组店铺跑在独立的OS里。这块我们后面单独开一篇文章细聊，这里先聚焦在同一台Windows执行机上如何做隔离。

三、环境绑定机制的代码实现

为了避免人为配置错误导致两个店铺指向同一个 user-data-dir，我们在调度层强制实施了一套“环境指纹”机制。

每创建一个新的店铺环境时，目录初始化完毕，我们会在目录根下写一个 env.json，里面包含：

shop_id：店铺唯一标识
platform：平台名
created_at：创建时间
fingerprint：基于店铺ID和创建时间的哈希值

这个指纹文件在浏览器实例分配前会被读取并校验，如果请求任务里的 shop_id 与指纹文件里的不一致，直接拒绝分配并告警。

import json
import os
import hashlib

def verify_env_integrity(user_data_dir: str, expected_shop_id: str) -> bool:
    fingerprint_path = os.path.join(user_data_dir, "env.json")
    if not os.path.exists(fingerprint_path):
        raise FileNotFoundError(f"Env fingerprint missing in {user_data_dir}")
    with open(fingerprint_path, "r", encoding="utf-8") as f:
        data = json.load(f)
    actual_shop_id = data.get("shop_id")
    if actual_shop_id != expected_shop_id:
        logger.error(f"Env mismatch: expected {expected_shop_id}, got {actual_shop_id}")
        return False
    # 二次校验指纹哈希
    expected_hash = hashlib.sha256(f"{expected_shop_id}{data.get('created_at')}".encode()).hexdigest()[:16]
    if data.get("fingerprint") != expected_hash:
        logger.error("Fingerprint hash mismatch, data may be tampered")
        return False
    return True

这段代码很小，但在我们线上一度扮演了“最后的守门员”角色。有好几次数据库配置同步出了问题，就靠它拦住了一批即将串号的任务。

四、代理绑定：一个容易疏忽的细节

很多团队在做环境隔离时，代理的配置还停留在“流程里手动设置”的阶段。这非常危险，因为一旦流程中途失败、重试，代理可能没挂上，导致真实IP漏出。

我们的做法是把代理绑定从RPA流程中剥离，提升到浏览器启动参数层面。

启动浏览器时，直接通过命令行参数指定代理：

cmd.extend([
    f"--proxy-server=http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}",
    "--proxy-bypass-list=<-loopback>"  # 不代理本地连接
])

这样一来，无论影刀流程内部执行了什么样的页面跳转、iframe加载，流量路径始终被操作系统级别的Chromium网络栈控制，不会出现“某一步忘了开代理”的低级错误。

每个店铺的代理配置，连同 user-data-dir，都在数据库中做一条环境记录，生命周期一一对应，不可单独修改。 这是用工程手段把正确性固化下来，而不是靠人每次操作时的小心谨慎。

五、自动化流程的事务性：不是数据库才有事务

RPA流程执行到一半失败了，留下半份改过的商品标题、未提交的订单草稿，比什么都没做更糟糕。

传统的影刀流程脚本，执行失败后默认就是“停了就停了”，没有任何回滚、补偿、清理的动作。我们从一开始就意识到，必须给自动化流程定义事务边界，哪怕它只是一个脚本。

我们的做法是，将每个自动化流程拆成三个阶段：

准备阶段：校验前置条件（登录态、页面加载、数据完整性），所有条件不满足直接终止，不进入执行。
执行阶段：核心业务操作，比如修改价格、回复消息、采集数据。这个阶段的操作会被记录在一个“操作日志”序列中。
确认/回滚阶段：如果所有关键操作成功，标记任务完成；如果失败，根据操作日志执行逆向操作（能恢复多少恢复多少），并标记任务需要人工介入。

以改价为例，执行阶段把修改前的价格存入 revert_log，如果后续出现异常，回滚阶段直接利用这个日志把价格改回去。

def execute_with_transaction(task, flow_func):
    revert_actions = []
    try:
        # 准备阶段
        pre_check(task)
        # 执行阶段
        for step in task.steps:
            before_state = capture_state(step)
            flow_func(step)
            revert_actions.append((step, before_state))
        # 确认阶段
        confirm(task)
        return True
    except Exception as e:
        logger.exception(f"Task {task.task_id} failed, start rollback")
        for step, before_state in reversed(revert_actions):
            try:
                restore_state(step, before_state)
            except Exception as rollback_err:
                logger.error(f"Rollback step {step} failed: {rollback_err}")
        task.status = "failed"
        raise

当然不是所有操作都能完美回滚。比如已经提交的订单就很难自动取消。对于这类不可回滚的操作，我们采用先行确认后执行的策略：在真正执行前加一层“安全检查点”，确认条件完全无误再动手。同时，操作日志与业务表联动，一旦出错立刻生成人工工单，把损失控制到最小。

六、流程内的边界守卫：如何防止“串门”

环境隔离解决了静态绑定问题，但动态运行过程中仍然可能出现流程“主动”跳到别的店铺页面。比如流程从订单详情页点击了一个返回按钮，那个返回链接可能指向了主站首页——而主站首页如果没有做好隔离，可能会读取到其他店铺的Cookie残留。

我们做了三件事来杜绝这种情况。

第一，强制绑定流程的域名白名单。 每个店铺环境启动时，通过浏览器扩展注入一个域名检查脚本，任何非白名单域名的请求都会被拦截并报错，流程直接终止。

第二，流程执行中不允许出现“凭空跳转”的操作。 所有URL跳转必须显式声明目标地址，不允许出现 window.location.href 被动态赋值为一个外部变量这类写法。这个靠代码审查和流程设计规范保证。

第三，流程结束后执行“环境净化”。 这个净化不是清Cookie，而是杀掉当前标签页并回到一个空白页，确保下一个任务拿到的浏览器窗口是干净的起始页。这些操作都通过 CDP（Chrome DevTools Protocol）指令精确控制。

七、回收与销毁：一个容易忽略的安全边界

一个浏览器实例被使用过后，什么情况下可以回收复用，什么情况下必须彻底销毁重建？

我们的规则很明确：

正常结束的任务：实例回归空闲池，下个任务会先做环境完整性校验，通过即可复用。
出现过网络异常或代理失效的任务：实例标记为“脏”，立刻销毁。因为代理失效期间可能发生了直接连接，导致IP漏出或Cookie关联。
任何执行过涉及登录态操作的任务（比如扫码登录、手机验证）：实例直接销毁，不允许复用。哪怕登录是同一个店铺，为了绝对安全也走销毁重建。

销毁不是简单的 taskkill。我们会先通过CDP发送关闭指令，等待5秒，如果进程未退出再强制kill，然后递归删除 user-data-dir 的整个目录树，确保磁盘不留痕迹。下次该店铺再需要环境时，由池管理器从环境初始化脚本重新构建。

八、监控与告警：不只盯机器，也要盯环境

我们的监控看板上，有一个单独的板块叫“环境健康度”，包含以下指标：

环境指纹校验失败次数（立即告警）
代理失效次数（按店铺维度统计）
登录态过期次数
浏览器实例因脏数据被强制销毁的比率

特别是环境指纹校验失败，这个指标一旦大于0，说明环境绑定配置肯定出了纰漏，我们会直接挂起所有涉及店铺的任务，防止串号扩散。

九、落地到多节点后的延伸

当执行机数量增多后，环境初始化就成了一个标准化流程。我们写了一个环境工厂脚本，接受 shop_id、platform、代理配置等参数，在目标执行机上自动完成：

建立 user-data-dir 目录
写入 env.json
配置浏览器启动参数模板
首次启动浏览器进行人工扫码登录（这个环节暂时还需要人工介入，但可以远程操作）
校验登录态并拍摄快照（仅用于内部审计，不涉及数据外传）

这样任何一个新店铺从配置到就绪，10分钟之内搞定，而且全程操作留痕。

十、最终的目标：让流程变成“无状态”的服务

这一整套环境隔离和事务性保障做下来，我们想达到的理想状态是：任何一个自动化流程，拿过来一个干净的环境就能跑；跑完之后环境能安全复用或销毁；流程本身不依赖任何上一次执行的残留状态。

换句话说，把RPA流程从“状态相关的脚本”变成“无状态的服务”。

这个目标还没有完全实现，但框架已经基本搭完。后面要做的，是让每一个流程设计都严格遵循状态外部化原则——需要的状态全部从外部传入（比如数据库中任务参数），执行中的临时状态全部写回任务上下文，不留存在浏览器环境里。

隔离不是一个技术点，而是一整套工程原则的落地。
它不炫酷，但它是多店铺自动化能不能长久跑下去的那条生命线。

作者：林焱
持续记录店群自动化工程中的真实实践