「微信机器人系统」不是一个会回消息的脚本，而是 多账号、多角色、可观测 的通道平台。客服、营销、触达都挂在这套系统上，而不是各写各的发送。这篇讲系统怎么搭。

系统要具备的五层

实例层：微信号在线、隔离、重登
通道层：登录、回调、发送、通讯录
网关层：鉴权、队列、频控、错误码翻译
应用层：接待 / 触达 / 营销（可插拔）
观测层：在线率、回调延迟、失败、抢话

应用层可以多个，通道只能一套。谁都能调发送，系统一定会打成一团。

多账号模型

每个微信号一个实例 ID。所有回调、发送、日志必须带这个 ID。
账号绑定技能组或用途：接待号、交付号、导购号。生产号不用老板号。

权限建议：

• 运营可改词库和任务，不能直接调裸发送

• 坐席只能在接管的会话里发言

• 开发看原始回调，不在生产号上试规则

测试实例和生产实例物理隔离，规则环境分开。

统一出站

所有应用写出站命令：accountId + to + payload + requestId + 优先级。
网关负责：

• 在线才放行

• 接待优先于触达，触达优先于营销

• 同一好友串行、留间隔

• 失败分类回写

应用层禁止自己 sleep 做频控，也禁止绕过网关打通道。

个人号通道用 GeWe API 承接实例和 HTTP 能力，系统自己做网关和应用。多开是否串号，在这一层验收。

统一入站

一个 webhook 收多实例，按实例 ID 分流。先幂等和落库，再路由到接待或仅存档。群和私聊在入站就分开。掉线事件当成一等事件，切断该实例出站。

回调与发送字段以文档为准：API文档

必须上的观测

• 每实例在线、最后心跳

• 回调到达量（突然为 0 先查实例）

• 出站失败率按错误码拆

• 机器人与坐席双发次数

没有观测，系统只是“看起来在跑”。

落地顺序

先单号打通入站出站和日志，再加第二个号验证隔离，再挂接待应用，最后才挂触达和营销。一开始就上三个应用，排障分不清是通道问题还是策略问题。

小结

微信机器人系统的核心是：多实例隔离、统一网关、应用可插拔、全程可观测。通道用 GeWe API 把个人号收发接口化，系统负责谁能发、何时发、发失败怎么办。先把网关立住，客服和营销都是上面的插件，而不是再买一套会聊天的盒子。