做企微自动化机器人的时候，最容易引发“车祸”的场景是什么？ 那就是把单聊的自动回复逻辑，原封不动地搬到了客户群里。客户在群里随便聊句天，机器人就疯狂搭茬，瞬间把原本活跃的客户群变成了毫无体验的“轰炸区”。

想要机器人聪明地做到“单聊秒回，群聊按需回复（比如只回复被 @ 的消息）”，系统就必须在接收到回调的那一瞬间，精准判断出这条消息的来源。

今天不绕弯子，直接从星云企业微信开放平台（Google搜索）的底层报文入手，教你用一个 roomType 字段搞定消息来源的路由分发。

撕开回调报文看本质

当有人给你的机器人发消息（不论是私聊还是在群里），企微网关都会向你的 Webhook 地址推送一段加密的 JSON 报文。

在完成解密后，很多开发者习惯性地眼睛只盯着 Content（文本内容）或者 MsgType（消息类型）看，却忽略了决定业务走向的来源标识字段。

你可以翻开官方的 API文档，找到接收消息的基础结构说明：

在这个明文 JSON 里，藏着一个专门用来区分场景的字段：roomType（部分接口体系下也可能用 ConversationType 命名，逻辑互通）。

单聊与群聊的 JSON 对比

我们直接看两段真实解密后的报文数据。

场景一：客户私聊机器人

JSON

{
    "MsgType": "text",
    "roomType": 1, 
    "FromUserName": "wm_xxxxxxxxxxxxxxxxxxxx",
    "Content": "你们这个API接口怎么收费？",
    "CreateTime": 1698765432
}

当 roomType 的值为 1 时，代表这是一对一的私聊。报文里只有发件人（FromUserName），没有群组概念。这种场景下，你可以大胆地让大模型或关键词词库接管，直接调用发消息接口把答案怼回去。

场景二：客户在群里发消息

JSON

{
    "MsgType": "text",
    "roomType": 2,
    "ChatId": "wr_xxxxxxxxxxxxxxxxxxxx",
    "FromUserName": "wm_xxxxxxxxxxxxxxxxxxxx",
    "Content": "刚才那个问题谁能解答下？",
    "CreateTime": 1698765432
}

当 roomType 的值为 2 时，代表这条消息来自一个群聊。 注意到了吗？一旦变成了群聊，报文里会多出一个极其关键的字段——ChatId（群聊的唯一标识）。

拿到 roomType 后，业务代码怎么写？

在你的路由分发模块里，拿到解密数据后的第一件事，就是写一个 if-else 分支。

如果是单聊 (roomType == 1)： 顺理成章，提取 FromUserName，去数据库查客户标签，走标准客服回复流程。

如果是群聊 (roomType == 2)： 千万别直接把回复丢出去！群聊的业务逻辑要复杂得多，通常需要配合以下两步防雷操作：

1. 提取 ChatId 落库：必须把发消息的目标改成这个 ChatId，而不是客户个人的 ID，否则你的回复会发到私聊里，群里根本看不见。

2. 拦截非 @ 消息（高亮重点）：在群聊报文里，通常还会带有一个表示“是否被 @”的字段，或者 Content 里会包含机器人的名字。代码里必须加一层校验：如果客户没有明确 @ 机器人，直接 return 丢弃这条消息。 只有这样，机器人才能安静地潜伏在群里，召之即来，挥之即去。

随手总结

做企微接口对接，看懂数据结构比盲目敲代码重要一百倍。 用 MsgType 区分图片还是文本，用 roomType 区分群聊还是单聊。把这两个路由阀门焊死，你的机器人架构就搭起了一半。

如果你的业务涉及到多群管理，或者是根据不同群聊（如 VIP群、售后群）回复不同的话术，只要紧紧抓牢 ChatId 去做映射配置就够了。开发调试时多用 Apifox 模拟这两类 JSON 发包，能帮你避开绝大多数的路由 Bug。