一个店铺账号从入驻到正常经营，从临时停用到安全注销，中间要经历十几个状态流转。
如果没有一套自动化的治理体系，靠人脑和Excel去追，早晚会出合规事故。
前面的文章我们把店群自动化的执行、调度、数据都聊透了，但还有一个基础能力一直没展开——店铺账号本身的生命周期管理。
拼多多、TEMU、TikTok Shop，每个平台的账号都有独立的入驻流程、资质维护要求、登录态有效期、异常风控规则。一个中等规模的店群矩阵可能有上百个店铺账号，每天都有新账号入驻、有老账号需要续期验证、有账号因为各种原因被临时限制。
这些操作如果依赖人工逐个处理，不仅效率低下，更容易因为遗漏而导致账号被平台收回或处罚。而一旦因为自动化流程的误操作触发了平台的安全红线，后果是批量性的。
这篇文章还原我们是怎么在工程层面，给多平台店铺账号建立一套自动化生命周期治理体系，并内嵌合规审计能力，让账号管理不再是定时炸弹。
一、账号状态的数字化建模
要自动化管理，第一步是把“账号现在处于什么状态”这件事从人的经验里抽出来，变成可被程序处理的状态机。
我们抽象了一个跨平台的店铺账号生命周期模型，包含以下核心状态：
- 待激活：账号已注册但未完成资质提交或首次登录验证
- 正常：状态良好，可执行全量自动化任务
- 观察期：平台对新账号的风控重点关注阶段，限制部分自动操作
- 受限：平台下发临时限制（如需要补充资料、验证手机），但仍可执行部分只读操作
- 冻结：已被平台冻结或内部主动冻结，禁止一切自动化操作
- 维护中：内部主动停止自动化，用于环境迁移或数据清理
- 已注销：账号已永久关闭
状态流转由特定事件触发，每次流转都记录在审计日志里。
from enum import Enum
class AccountState(Enum):
PENDING_ACTIVATION = "pending_activation"
NORMAL = "normal"
OBSERVATION = "observation"
RESTRICTED = "restricted"
FROZEN = "frozen"
MAINTENANCE = "maintenance"
TERMINATED = "terminated"
VALID_TRANSITIONS = {
AccountState.PENDING_ACTIVATION: [AccountState.NORMAL, AccountState.FROZEN],
AccountState.NORMAL: [AccountState.OBSERVATION, AccountState.RESTRICTED, AccountState.FROZEN, AccountState.MAINTENANCE, AccountState.TERMINATED],
AccountState.OBSERVATION: [AccountState.NORMAL, AccountState.RESTRICTED, AccountState.FROZEN],
AccountState.RESTRICTED: [AccountState.NORMAL, AccountState.FROZEN, AccountState.MAINTENANCE],
AccountState.FROZEN: [AccountState.NORMAL, AccountState.TERMINATED],
AccountState.MAINTENANCE: [AccountState.NORMAL, AccountState.FROZEN],
AccountState.TERMINATED: []
}
所有状态变更都必须通过一个统一的
AccountStateManager来执行，不允许任何流程直接修改数据库里的状态字段。每次变更前做合法性和权限校验，变更后写入审计日志并触发对应的自动化动作（例如进入冻结状态后自动回收浏览器环境、清理任务队列中该账号的所有待处理任务）。
二、账号环境与状态的生命周期绑定
在第一篇环境隔离文章里，我们讲到每个店铺有独立的user-data-dir和代理配置。这些环境资源不是免费的，每个账号占用的磁盘空间、代理IP、浏览器池槽位都是成本。
当账号进入冻结或已注销状态时，其绑定的环境资源必须被及时回收。我们的做法是：
- 冻结：将
user-data-dir打包压缩后转移到冷存储（NAS归档目录），释放执行机磁盘空间。代理IP解绑并标记为可重用。浏览器池中该账号的预留槽位释放。 - 已注销：归档保留30天后，彻底删除
user-data-dir和相关配置，代理IP退订。
环境回收不是手动的，而是由状态流转自动触发。AccountStateManager在完成状态更新后，向调度中心发布一个AccountStateChanged事件，调度中心的路由器监听到事件后，调用环境工厂执行对应的回收或部署动作。
def handle_account_state_change(event):
if event.new_state == AccountState.FROZEN:
archive_env_data(event.shop_id)
release_proxy(event.shop_id)
remove_from_pool(event.shop_id)
elif event.new_state == AccountState.TERMINATED:
schedule_env_deletion(event.shop_id, delay_days=30)
elif event.new_state == AccountState.NORMAL and event.old_state == AccountState.FROZEN:
restore_env_from_archive(event.shop_id)
reallocate_proxy(event.shop_id)
这套机制让资源生命周期和账号生命周期完全咬合，不存在“账号注销了但代理还在扣费”的浪费。
三、登录态维护与合规续期
保持登录态是自动化跑起来的前提，但平台对登录态有自己的有效期，到期后需要重新验证。这不是要突破安全机制，而是要在合规框架内，用自动检测和人工辅助相结合的方式，降低登录态过期带来的任务中断。
我们做了一个独立的登录态巡检服务，每30分钟对所有“正常”和“观察期”账号做一次有效性探测。
探测方式极其轻量：通过CDP向浏览器实例发送一个导航到店铺后台首页的指令，检查页面标题是否包含预期的店铺名称，以及HTTP状态码是否为200。如果探测失败，说明登录态可能失效。
探测失败后，服务会：
- 将该账号标记为
pending_reauth - 暂停该账号的所有自动化任务
- 生成一条人工扫码登录工单，推送到运营的移动端
运营在手机上收到工单后，可以远程打开该账号的浏览器窗口（通过我们的内部远程控制工具），用平台官方App扫码完成登录。登录完成后，巡检服务再次探测确认有效，自动解除 pending_reauth 状态，恢复任务。
自动化不做“自动登录”这件事。
登录必须经过真实人工扫码，这是不可逾越的合规底线。
四、操作权限分级与最小权限原则
自动化流程不能想做什么就做什么。我们按照业务影响程度，把所有自动操作划分了三个权限等级，并和账号状态做交叉控制。
只读操作（权限等级L1）：采集商品、拉取订单、读取消息列表。任何状态的账号（除冻结和已注销）都可执行。
非破坏性写操作（权限等级L2）：回复消息、修改商品标题、调整库存。需要账号状态为“正常”且在非风控重点时段。
破坏性操作（权限等级L3）：确认发货、报名活动、调整价格、提交资质材料。需要账号状态为“正常”、人工审批、操作后强制留痕。
调度中心在分发任务时会校验这个权限矩阵。如果一个L3任务被提交，而对应的审批还未完成，任务会停留在 pending_approval 状态，直到审批通过才进入执行队列。
审批流程走内部工单系统，审批人在工单里看到：操作类型、店铺ID、变更前后的值、预计影响，一键通过或拒绝。这个审批记录同样进入审计日志，和自动化操作日志形成完整的证据链。
五、全量审计日志：让每一件事都有据可查
在真实的企业环境里，自动化系统如果出了事，第一个被追问的就是“谁干的、什么时候干的、干了什么”。审计日志不是一个可选项，它是合规的最后一道防线。
我们定义了一套标准的审计事件模型：
{
"event_id": "uuid",
"timestamp": "2026-05-19T14:30:22Z",
"event_type": "account.state.changed",
"operator": "system:scheduler",
"target": {
"shop_id": "temu_045",
"platform": "temu"
},
"detail": {
"old_state": "normal",
"new_state": "restricted",
"reason": "platform_enforced_restriction_detected",
"related_task_ids": []
},
"trace_id": "abc-123"
}
所有关键事件——账号状态变更、任务执行、人工审批、环境操作、登录态过期、异常告警——都必须生成这样一条审计记录，写入不可篡改的日志存储（我们用的是Elasticsearch加一份离线归档到对象存储）。
审计日志还支持按店铺、按时间段、按事件类型检索和导出，用于内部定期审查或应对可能的平台质询。
更重要的是，我们把审计日志的完整性校验也做了。每日凌晨，一个离线脚本会对比调度中心的数据库、Redis里的状态快照和ES中的审计事件，如果发现不一致——比如数据库里账号状态是冻结，但审计日志里没有对应的状态变更事件——就立刻告警并生成异常工单。这是一个自检闭环。
六、异常行为检测与自动熔断
账号治理不能只靠静态的权限控制，运行时的异常行为同样需要检测。
我们在调度层和浏览器交互层埋设了异常行为检测规则，例如：
- 同一账号在5分钟内操作了远超正常频次的页面（可能是流程死循环或被人为篡改）
- 账号出现了从未执行过的敏感操作类型（比如一个只做采集的账号突然执行了发货操作）
- 平台返回了安全验证页面或验证码（说明操作触发了风控）
当触发这些规则时，调度中心会立即启动熔断：
- 暂停该账号的所有进行中任务
- 将账号状态临时置为
observation或直接frozen（视规则严重程度） - 快照保存当前页面和操作日志
- 生成一条P0级别的告警工单，要求人工排查
这个熔断机制在最危险的一次事件中，帮我们挡住了批量误操作。当时一个测试流程因为配置错误，把TEMU某个店铺的商品价格全部设成了0.01元。异常行为检测在操作执行到第三个商品时就识别出了价格修改频次异常，触发熔断，避免了全店价格灾难。
自动化的底线，不是不犯错，而是犯错后能多快停下来。
七、平台合规差异的抽象处理
三个平台对账号的管理规则各不相同。拼多多要求主账号和子账号体系、TEMU有跨境资质审核、TikTok Shop有内容创作者和卖家账号的区分。
我们不在代码里写死任何平台的规则，而是用规则配置表来驱动行为。每个平台有一套Profile，定义：
- 支持哪些自动操作类型及对应权限等级
- 哪些时段是风控敏感期（如平台大促前后）
- 登录态有效期大致范围
- 需要定期维护的事项（如资质年检提醒）
这些Profile由运营和工程师共同维护，版本化管理，修改需要双人复核。调度中心和巡检服务在运行时会加载对应的平台Profile，动态调整行为。
这样，当某个平台更新了规则时，我们只需要修改一个配置项，而不用改代码重新发布。这在平台规则频繁变动的跨境电商领域，省下了大量维护成本。
八、日常巡检与健康度评分
除了登录态巡检，我们还对每个账号做综合性的健康度评分，并在看板上展示。
评分维度包括：
- 登录态稳定性（近期登录失效次数）
- 操作成功率（最近24小时任务成功率）
- 平台限制状态（是否被平台打过标）
- 资质有效期（营业执照、品牌授权等）
- 代理质量（IP是否被标记、响应延迟）
每个维度打分，加权得到一个总分。低于阈值的账号自动进入 关注列表，限制新建任务，运营需要定期查看和处理。
这个评分系统让账号治理从“被动等出问题”变成了“主动发现隐患”。曾经有一个TEMU店铺连续三天登录态刚续上就掉，健康度评分骤降，自动限制了它的任务执行。后来人工排查发现是代理IP被TEMU标记了，换了一个IP后恢复正常。如果没有这个机制，可能等到运营发现店铺很久没更新商品时，已经丢了一周的销量。
九、账号治理与业务节奏的协同
账号的入驻、激活、注销，这些操作不是孤立的，它们和业务节奏紧密绑定。比如大促前一周，通常需要批量激活一批备用店铺；大促结束后，一些临时店铺需要注销。
我们在调度中心加了一个账号生命周期计划模块，运营可以提前配置计划：某批次店铺在5月25日激活，6月10日冻结。计划到期时，自动化系统触发对应的状态变更，无需人工操作。
这种计划执行同样需要审批，但审批在计划创建时一次性完成，后续自动化照章执行，效率大幅提升。
十、最后想说的
账号生命周期治理，在RPA工程化里属于那种“平时不起眼，出事就是大事”的基础能力。它不是最有趣的部分，也不是最能展示技术深度的部分，但它是整个自动化系统能否通过合规审查、能否被企业信任的关键。
我们花了整整三个月，才把账号状态机、环境绑定回收、登录态巡检、操作权限分级、审计日志和熔断这套体系打磨到能覆盖所有平台和所有流程。中间被内部安全审计挑战过两次，每次都在修补漏洞后变得更强。
自动化的信任，不是靠技术炫技赢来的。
是靠着每一条不可篡改的审计日志、每一个守住的合规底线，一点一点积累出来的。
作者：林焱
一个把“合规”刻进自动化系统骨髓里的工程师