先说清楚一个概念：本文讲的"群机器人"，不是企微群里添加的那种只能单向推送的 Webhook 机器人，而是一个由 API 驱动的企业微信账号——它能被拉进群、能收消息、能 @ 人回复，行为和正常成员一致。我们内部的告警值班号、客户群接待号都是这么做的。这篇讲讲具体实现。

一、适用场景和前置准备

比较适合用这种方式做的场景：

• 监控告警：业务系统出故障时，自动把告警发到值班群，支持升级 @ 具体的人

• 客户群接待：新成员入群后自动发欢迎语和群规，常见问题自动答

• 群资料维护：定时更新群公告、同步群成员名单到内部系统

前置条件就三样：控制台开通拿到 App Token、账号本人扫码登录拿到 appid、配好消息回调地址。群相关的接口都归在群模块下。

二、先拿到 roomId

所有群操作都要用 roomId 标识目标群，获取它的主入口是 room/getMyCustomerGroupList，分页拉取当前账号名下的客户群列表。拿到之后建议存库并打上业务备注，后续不要每次现查。

如果只需要某个群的资料（群主、成员列表、每个人的入群时间和邀请人），调 room/getInfo 即可，做群成员对账很方便。

三、自动收发消息

群消息和单聊走同一个消息模块，区别只是 conversationId 传 roomId。最简单的发文本：

POST /wx-api/api/message/sendText

{
  "appid": "we_xxx",
  "conversationId": 1234567890123456,
  "content": "新版本已发布，详情见公告"
}

群里要 @ 人，用的是 message/sendRichText（富文本接口）而不是发文本接口，这个设计一开始容易找错。消息类型比想象中全，图片、文件、链接卡片、小程序、名片都支持，完整清单见消息模块文档。

收消息靠回调：群里有人说话时推送 message.received，回调入口判断会话是群聊后，把消息丢给规则引擎或后续处理服务。要做"关键词自动回复"，就在这一层匹配；做告警机器人，就由内部系统直接调发送接口，两条链路互不干扰。

四、自动建群和成员维护

涉及群结构变更的接口是一套固定动作：

动作	接口	说明
建群	room/create	创建空群，返回新群 roomId
拉人	room/addMember	邀请用户进群
踢人	room/delMember	高风险，调用前要有二次确认
改公告	room/setNotice	适合自动化更新值班信息
设管理员	room/setAdmin	设置或取消管理员
入群确认	room/inviteConfirm	开启后入群需群主确认

典型的自动化流程是：业务系统发起建群 → create 拿到 roomId → addMember 把客户和对接同事拉进去 → setNotice 写群公告 → roomId 回写业务系统绑定。整个过程不需要人碰手机。

五、稳定性上的几个红线

文档里把删除、解散、退出这类不可逆操作标成了"高风险"，做自动化时要认真对待：

1. 发送必须串行。同一个 appid 的发送请求进队列，并发直推容易出问题

2. 高风险操作加人工确认。disband（解散群）、quit（退群）、delMember（踢人）不要做成无人值守的自动动作

3. 处理好掉线。收到 -11001 调断线重连；账号在其他设备登录（-11002）不要自动重连，应提示人工处理

4. 频率留余量。接口有调用频率限制，返回 429 时降频重试，告警风暴这种场景要在自己系统侧先做聚合

上线前建议过一遍官方的使用规范与风控说明，哪些动作敏感、频率怎么控制，里面写得比较直白，比自己踩坑成本低。

写在最后

群机器人这套东西，技术上就是"回调收事件 + 接口做动作"的组合，难点不在接口调用，而在流程编排和异常兜底。建议先从只读类需求入手（群消息归档、成员对账），跑稳了再碰写操作，最后才做建群这类结构变更，节奏会比较稳。