机器人业务做到一定规模，单账号必然不够：连锁门店一个号、销售团队人手一个号、客服分组轮值。多账号在接口层支持得很直接——一个应用、一份调用凭证、多个 appid 实例，但工程上要把映射、隔离、状态管理设计好，否则一个号掉线全网告警。这篇讲多实例架构的四个设计点。

背景痛点

第一版多账号方案最常见的混乱是：appid 散落在配置文件、数据库、代码常量里，谁也不知道哪个 appid 是哪个门店的号；一个账号掉线，所有定时任务跟着报错重试；给 A 门店客户发的消息出现在 B 门店的账号上——ID 隔离没做好的事故，排查起来都像灵异事件。

原理

接口层的多账号模型很清晰：一个应用可以登录多个企微账号，共用同一把调用凭证，每个账号是一个 appid 实例，登录和掉线状态互不影响。也就是说，平台侧已经做了实例隔离，工程侧要做的是把隔离延续到自己的系统里：账号档案、会话路由、状态机都要按 appid 维度切分。

所谓多实例架构，是指业务系统为每个登录的企微账号维护独立的配置、状态与任务队列，通过 appid 完成从业务事件到具体账号的路由。

核心实现

账号档案表是整个架构的地基（示例代码，需按官方文档校验）：

class Account:
    # 示例代码，需按官方文档校验
    appid: str          # 实例 ID，主键
    biz_key: str        # 业务侧标识：门店号 / 销售组 / 客服分组
    status: str         # online / reconnecting / offline
    last_check: float   # 最近一次探测时间

def pick_account(biz_key: str) -> Account:
    # 业务事件 → appid 的唯一入口，禁止其他地方直接取 appid
    acct = repo_by_biz_key(biz_key)
    assert acct.status == "online", f"{acct.biz_key} 账号离线"
    return acct

所有发送、查询动作都从 pick_account 拿实例，定时任务按账号分组调度，掉线告警带 biz_key 而不是裸 appid。

踩坑

一、appid 与业务标识的映射必须只有一张表、一个入口。映射出现在两处，就一定会在某次变更后不一致，消息发错账号的事故都源于此。

二、状态机按账号独立：一个账号重连期间，其他账号的定时任务照常执行。调度器按 appid 分组，别用全局失败计数把健康账号也停了。

三、单账号的发送限速在多账号下按账号各自计算，不要共享一个全局速率——那是单实例的约束，不是矩阵的约束。

四、扫码登录必须由账号持有人本人完成，批量"接管"账号的操作不存在也不应有；账号档案里记录联系人，掉线时知道找谁。

总结

多账号架构的四件套：唯一的账号档案、按 appid 的路由入口、独立的状态机、按账号的限速与调度。平台侧实例已经隔离，工程侧把隔离做完整，矩阵规模扩大时只是多一行档案。这篇基于 Eyun 平台的企微接口整理，多账号的登录与容量规则以官方开发文档为准，扩容前先核对应用容量限制。