"在群里加个机器人"这个说法，在企微里其实有歧义。企微的群没有"机器人"这种对象，你能做的是：把一个实例账号加进群，让它按规则发言。

理解这一点，后面的实现就顺了。

先把账号加进群

已有群拉人用 room/addGroupMember，参数是群 id 和成员 uin 列表：

def join_group(room_id, robot_uins):
    resp = requests.post(
        f"{BASE}/wx-api/api/room/addGroupMember",
        headers=HEADERS,
        json={
            "appid": APPID,
            "roomId": room_id,          # int64，传 number
            "memberUins": robot_uins,
        }
    ).json()
    return resp["code"] == 0

新建群时也可以直接把人带进去，room/createGroup 的 memberUins 里加上实例账号就行。

加进群之后，这个账号发的消息，群成员看到的就是一个普通成员在说话——不是"应用"或者"系统通知"的样式。想要那种带边框的应用消息卡片，得走内部应用那条路，不在群消息的能力范围里。

怎么知道群里有人说话

监听群消息靠 Webhook。message 事件里 messageType=1 就是群聊：

def handle_group_msg(data):
    if data.get("messageType") != 1:
        return
    room_id = data["roomId"]        # int64
    sender = data["senderUin"]
    content = data.get("content", "")
    if content.startswith("@bot"):
        reply(room_id, content.replace("@bot", "").strip())

这里有个细节：群里 @ 某个成员，回调里不会额外标出"被 @ 了"。content 里能看到 @昵称 的文本片段，但判断有没有指到你，只能靠字符串匹配。所以做群助手，用固定前缀比靠 @ 稳。

发言频率得管住

群助手最容易出事的地方不是答错，是刷屏。一个群里连着发五条，第二天就被人踢了。

三条规则基本够用：

规则	建议值	作用
单群每分钟上限	3 条	防突发刷屏
同类消息合并	5 秒窗口	多条事件合成一条摘要
夜间静默	22:00-08:00	非紧急消息次日推

合并的实现很简单，用 Redis 攒一下：

def enqueue_group_msg(room_id, text):
    key = f"gq:{room_id}"
    redis.rpush(key, text)
    redis.expire(key, 30)
    if redis.llen(key) == 1:
        schedule_after(5, flush_group_queue, room_id)

三种典型行为

把群助手的动作分个类，思路会清楚很多：

被动应答：有人发了指定前缀，回一条。适合查询类，比如查库存、查工单。

定时播报：不依赖群成员说话，按点推日报、值班表、活动提醒。

事件触发：外部系统有事件就推到这个群。比如监控告警推运维群，订单异常推售后群。

三种行为共用同一个发送函数，区别只在触发器。

几个坑

• 自己发的消息不会推回调：接口发出去的内容只产生已读回执，别指望靠回调记录发言历史，自己存流水

• 群 id 是 int64：roomId 传 number，写成字符串会报参数错误

• 成员变动有独立事件：group_member_add、group_member_remove，别跟消息事件混在一起处理

• 回调 5 秒内返回：群消息处理可能慢（要查库、要调模型），先返回 ok 再异步跑

落地顺序

我一般这么推：先把账号拉进一个测试群，用前缀触发跑通一次回话；然后加频控和合并；最后接真实事件源。

群助手的价值不在"能自动说话"，在"说得克制"。接口本身只有收发两条，难的是别把群变成通知垃圾场。凭证和回调配置在 Eyun 平台开通实例时拿到，群相关接口路径在开发文档里查得到。