群里出现「张三加入了群聊」，自动回复回一句「你好需要什么」。张三可能已经在群，这句话是系统事件。机器人把它当客户开口，群会被刷屏。退群通知再回「再见」，更难看。外部群里这类事件密度高于内部通报群，开口规则若不按类型切，值班级会先把机器人静音。

聊天消息和成员变更不是一种回调语义。混进同一个 if text: 就会出站。

事件类型先于词表

入站要先分类。文本聊天才进词表。成员增减、群名变更、撤回、拍一拍，第一期默认只记账。分类字段以回调文档为准，不要用正文是否像系统提示来猜。猜会在不同客户端文案上失效。

群开口还要叠加点名或口令。系统事件没有「@机器人」，默认就不应开口。私聊没有进群事件，规则本来就该按会话类型分发。外部群的 toId 是 roomId，回错成某个成员的私聊，当事人会以为被单独骚扰。

消费端先分流：

CHAT = {"text"}  # 实际枚举以回调文档为准

def on_inbound(event, q_chat, q_member):
    kind = event.get("kind")  # 字段名以文档为准
    if kind in CHAT:
        q_chat.put(event)
        return
    q_member.put(event)
    # 成员队列默认不出站

q_member 可以更新本地成员表，供下次 @ 和拉人用。不要在这个队列里调发送。发送只发生在聊天队列，并且还要过开口函数。

成员表更新失败，不应改去重发欢迎。人已经在群里了，欢迎是私聊阶段的动作。进群再欢迎一次，等于把加好友流程在群里重放。

退群后的任务要停对象，不要停通道

员工还在，客户退了，针对这个人的 @ 任务应取消。整群通知仍可发。反过来员工被移出，整群任务都停，失败域是对象失效。把退群当发送失败去重试，会打到已经不存在的关系上。

验收：构造或等待一条进群系统提示，群内不应出现自动问候；客户文本点名后才允许一条业务回复；成员表在进群事件后能查到该 userId。聊天队列积压时，成员队列仍应能消化，避免资料更新被回复堵住。这就是分队列的现场含义，不是多开几个线程那么简单。

查看企业微信 API 文档：
https://doc.qiweapi.com/