最近做了个外部群智能助手的项目——客户被拉进企微外部群，群里有个机器人要能自动响应。和单聊机器人完全不同，群里多人说话、消息杂、@触发、上下文混乱。做完踩了一堆坑，记下来。

 Eyun 平台开放的企微 API，承接群消息收发和群管理，本文重点不在调接口，在"外部群消息怎么处理和自动响应"。

外部群和单聊是两个工程问题

最早以为群机器人就是单聊机器人加个 @ 判断，做完发现根本不是：

• 单聊一对一，群一对多，上下文是多人混合的

• 单聊每条都要回，群大部分消息不该回，只在特定时机回

• 单聊消息归属清楚，群消息要识别是谁说的、对谁说的

• 单聊没有刷屏问题，群消息高峰期能一秒几条

群的工程难点不在响应，在"什么时候该响应、响应给谁"。

群消息识别：先判断要不要处理

群消息进来第一步不是理解内容，是判断这条消息该不该进处理流程：

• @机器人：明确触发，必须处理

• 关键词命中：可能触发，看上下文

• 群成员对机器人说话（"机器人帮我查下"）：触发

• 普通群聊：不触发，只做上下文记录

不判断就处理，机器人对每条群消息都分析一遍，高峰期直接卡死。判断逻辑要轻——关键词和 @ 检查是毫秒级，AI 理解是秒级，先轻判断再重处理。

群成员角色识别

同一条消息，群主说的和普通成员说的、客户说的和员工说的，处理方式不同：

def identify_sender(msg, group_info):
    sender = msg.sender_id
    if sender == group_info.owner_id:
        return "owner"
    elif sender in group_info.staff_ids:
        return "staff"
    else:
        return "customer"

客户问"这个产品多少钱"，机器人要响应。员工在群里讨论内部事务，机器人不该插嘴。角色识别让机器人知道"该不该管"。

群上下文管理

单聊上下文就是这段对话历史，群上下文复杂——多人交替发言，话题可能切换。机器人响应时要理解"当前在聊什么"。

上下文管理几条：

• 滑动窗口：取最近 N 条作为当前上下文

• 话题分割：话题切换时清空旧上下文

• @上下文：被 @ 时回溯到上次相关对话

• 指代消解："他说的那个"要能定位到具体人和具体消息

不管理上下文，客户问"那个产品还有吗"，机器人不知道"那个"是哪个，体验极差。关于群消息存储和上下文检索，可以看开发文档。

自动响应策略：该不该回、回给谁

群机器人最易翻车的是响应策略。不该回的时候回了，打扰群；该回的时候没回，客户觉得机器人没用。

响应策略表：

trigger: at_mention
respond: always            # @必回
scope: public              # 回到群里

trigger: keyword_product
respond: if_context_match  # 关键词命中且上下文相关才回
scope: public

trigger: staff_internal
respond: never             # 员工内部讨论不回
scope: none

trigger: customer_question
respond: if_no_staff_reply # 客户提问且5分钟内没人回才回
scope: public

if_no_staff_reply 这条是关键——客户在群里问问题，员工 5 分钟没回，机器人兜底。员工回了，机器人就不插嘴。这套不做，机器人要么抢话要么失职。

群消息防刷屏

群里机器人连续回好几条，客户体验极差。防刷屏几条：

• 单条响应：机器人一次只发一条，多条内容合并

• 响应节流：3 秒内不重复响应

• 批量聚合：短时间内多个触发，聚合响应"收到 N 个问题，依次回复"

• 静默时段：非工作时间减少主动响应

防刷屏的细节决定了机器人被不被嫌弃。我们最早没做，机器人在群里连发 5 条，客户直接把机器人踢了。关于群消息发送和频率控制，在Eyun 企业微信 API 平台开通后可以测试。

写在最后

外部群智能助手这套东西，难点不在 AI 多能聊，在群消息识别、角色判断、上下文管理、响应策略、防刷屏这些工程细节。每一项都不深奥，但少做一项机器人在群里就是个灾难。这套搭扎实，机器人在客户群里该说话时说话、不该说时闭嘴、说一次说清楚——才真是个群助手而不是群噪音。