问题:微信渠道只能绑一个号,企业/团队多成员场景无法落地
hermes gateway setup 配置微信后,再次扫码会覆盖 前一个绑定。团队负责人用自己的微信号连上 Hermes 后,团队其他成员无法用自己的微信号接入同一个 agent。这在企业微信协作场景下是硬阻塞。
这在其他渠道(Telegram/Discord/QQ)不是问题,但那些渠道和微信有根本性的产品模型差异 。
为什么 Telegram/QQ 不需要多账号,微信需要?
Telegram / Discord / QQ
WeChat / Weixin
Bot 模型
平台 Bot :一个 bot token = 一个 bot 身份
个人账号 Bot :一个 iLink bot token = 一个具体微信号
多用户
天然支持——bot 在群聊/DM 中服务多人,通过 chat_id/user_id 隔离
不存在"一个 bot 服务多人"——一个 token 就是一个人的微信号
需要多 token?
不需要。一个 token 管所有用户。
必须 。N 个成员 = N 个微信号 = N 个 bot token。
结论:微信的多账号支持不是"nice to have"——是企业微信场景下 agent 能用的前提条件。
根因:self.adapters 按 Platform 枚举做 key
# gateway/run.py:1426
self .adapters : Dict [Platform , BasePlatformAdapter ] = {}
Platform.WEIXIN 只能有一个 adapter 实例。一个 WeixinAdapter = 一个 _account_id + 一个 token + 一条 poll loop。第二次扫码只能覆盖第一个。
不是 iLink API 的限制。 iLink 确实是 1 bot = 1 微信号,但这和 OpenClaw 面临的是同一个限制——OpenClaw 通过并行跑多个独立 bot 绕过了它。
OpenClaw 怎么解决的——一个 agent 管所有号
accounts: Record<string, Account> // 不是 Record<Platform, Account>
~/.openclaw/.../openclaw-weixin/
├── accounts.json ← ["id1-im-bot", "id2-im-bot", "id3-im-bot"]
├── accounts/
│ ├── id1-im-bot.json ← {token, baseUrl, userId}
│ ├── id2-im-bot.json
│ └── id3-im-bot.json
每次扫码 registerWeixinAccountId() 往数组里 push ,不覆盖
每个 account 独立的 monitorWeixinProvider(独立 long-poll)
发消息时 resolveOutboundAccountId() 按 context_token 匹配正确账号
同一微信号重复绑定自动清理 stale account
Hermes 的 weixin.py 存储层已经支持多账号文件 (weixin/accounts/<id>.json),但运行时只加载一个。
为什么多 profile 在企业场景下不是合理方案
官方方向可能是"用多个 profiles"——但在企业部署下这个方案不成立:
管理开销非线性增长 :N 个成员 = N 个 profile = N 个独立 Gateway 进程 = N 套 config/skill/memory/session。运维不可持续。
生态必然分裂 :企业需要统一的 agent 能力池(skill 库、知识库、记忆系统),profiles 强制隔离一切,变成 N 个完全独立的 agent 孤岛。
资源浪费 :N 个 Gateway 进程 + N 套内存开销,对中小企业部署不现实。
产品定位错位 :这不是"N 个独立 bot",这是"一个企业 agent,N 个成员以个人微信为入口接入"。
企业需要的不是 N 个 Hermes——是一个 Hermes,N 个微信入口。
实际影响:从 OpenClaw 迁移的用户被硬堵在微信入口
微信是中国市场企业协作的核心通讯工具。Hermes 已经有 QQ、飞书、企业微信等渠道——但个人微信 是最大的存量用户池和私域入口。
OpenClaw 上一个 agent 管多个微信号是已验证的企业部署模型。迁移到 Hermes 后这个能力缺失,意味着整个基于个人微信的 agent 协作场景在 Hermes 上不可用 。
这不是 P3 Low。这是平台能力缺口——直接决定企业用户能否从 OpenClaw 或自建方案迁移过来。
解决方向(不写具体代码,给架构方向)
参考 OpenClaw 的 accounts: Record<string, Account> 模型:
Adapter 注册改键 :从 Dict[Platform, adapter] 演进为 Dict[str, adapter](按 token/account_id 做 key),或二级结构 Dict[Platform, Dict[str, adapter]]
存储层已就绪 :weixin/accounts/<id>.json 已经支持多账号文件存储,缺的是运行时多实例加载
每个 account 独立 poll loop + 独立 session ——和 OpenClaw 的 monitorWeixinProvider 模式一致
用户隔离走 account_id ,不走 profile
Telegram 有同类的 Support multi Telegram bots for gateway routing and send_message #10452 ——建议统一考虑,本质上是 gateway adapter 从"单实例"到"多实例"的架构演进
关联
环境
Hermes 版本:最新 main(2026-05-20)
平台:Weixin (iLink Bot API)
迁移来源:OpenClaw(多微信账号可用)
问题:微信渠道只能绑一个号,企业/团队多成员场景无法落地
hermes gateway setup配置微信后,再次扫码会覆盖前一个绑定。团队负责人用自己的微信号连上 Hermes 后,团队其他成员无法用自己的微信号接入同一个 agent。这在企业微信协作场景下是硬阻塞。这在其他渠道(Telegram/Discord/QQ)不是问题,但那些渠道和微信有根本性的产品模型差异。
为什么 Telegram/QQ 不需要多账号,微信需要?
结论:微信的多账号支持不是"nice to have"——是企业微信场景下 agent 能用的前提条件。
根因:
self.adapters按 Platform 枚举做 keyPlatform.WEIXIN只能有一个 adapter 实例。一个 WeixinAdapter = 一个_account_id+ 一个 token + 一条 poll loop。第二次扫码只能覆盖第一个。不是 iLink API 的限制。 iLink 确实是 1 bot = 1 微信号,但这和 OpenClaw 面临的是同一个限制——OpenClaw 通过并行跑多个独立 bot 绕过了它。
OpenClaw 怎么解决的——一个 agent 管所有号
registerWeixinAccountId()往数组里 push,不覆盖monitorWeixinProvider(独立 long-poll)resolveOutboundAccountId()按context_token匹配正确账号Hermes 的 weixin.py 存储层已经支持多账号文件(
weixin/accounts/<id>.json),但运行时只加载一个。为什么多 profile 在企业场景下不是合理方案
官方方向可能是"用多个 profiles"——但在企业部署下这个方案不成立:
企业需要的不是 N 个 Hermes——是一个 Hermes,N 个微信入口。
实际影响:从 OpenClaw 迁移的用户被硬堵在微信入口
微信是中国市场企业协作的核心通讯工具。Hermes 已经有 QQ、飞书、企业微信等渠道——但个人微信是最大的存量用户池和私域入口。
OpenClaw 上一个 agent 管多个微信号是已验证的企业部署模型。迁移到 Hermes 后这个能力缺失,意味着整个基于个人微信的 agent 协作场景在 Hermes 上不可用。
这不是 P3 Low。这是平台能力缺口——直接决定企业用户能否从 OpenClaw 或自建方案迁移过来。
解决方向(不写具体代码,给架构方向)
参考 OpenClaw 的
accounts: Record<string, Account>模型:Dict[Platform, adapter]演进为Dict[str, adapter](按 token/account_id 做 key),或二级结构Dict[Platform, Dict[str, adapter]]weixin/accounts/<id>.json已经支持多账号文件存储,缺的是运行时多实例加载monitorWeixinProvider模式一致关联
环境