私聊按条评估逻辑上说得通。群里对每条闲聊回「收到」会被静音严重时执行账号被移出。移出之后调用仍可能显示成功观察点却已经空了故障会被登记成通道损坏。开发接着改签名密钥没坏开口规则错了。机器人不是「每条消息调一次模型」。实现上是入站事件 → 状态机 → 规则 → 可选出站。开不开口必须落库不能写在提示词里。官方群机器人 Webhook 是另一条能力客户群常常没有这个席位。这里说的是员工会话值班。开口条件必须按会话类型切开私聊的对话对象就是该员工号规则可以逐条进入。群默认应以点名或口令为触发未命中只记日志。报价、赔偿、到账承诺不应交给自动生成须转人工并关闭该会话自动开口。未命中硬生成一句「我没听懂」闲聊会被聊死群里更糟。开口规则写成函数比写在提示词里好验收TOKEN报价# 配置里的口令不要写死在发送层defshould_reply(session_type,text,mentioned):ifsession_typeroomandnotmentionedandTOKENnotintext:returnFalse# 群闲聊只记账ifany(wintextforwin(赔偿,退款,到账)):returnFalse# 转人工本函数不再出站ifsession_typefriend:returnTruereturnmentionedorTOKENintextFalse不是发送失败是规则未命中。日志要分开记。群里每条都return True跟没写这个函数一样。内部群 Webhook 与员工在客户群值班也不是同一控制面。前者适合通报后者按真人会话约束频率与话术。用内部群的开口密度打客户群移出风险更高。两个入口做成同一个开关关掉内部通报会连带停客户群值班或者反过来。会话状态应持久化可自动、已转人工、勿扰、投诉。转人工后自动回复必须静默。状态若只活在进程内存或提示词里坐席输入时仍会被插入一句机器回复同一会话出现两套口径。结案或超时后才允许重新开口规则写在配置里。入站事件可重放欢迎尤其敏感进群类事件与回调重放叠加同一对象同一日只应处理一次。出站前查幂等键。通道不会判断「这是不是第二遍欢迎」。你让它回两次它就回两次。失败要分层。未命中规则去改词库。投递失败去查节点与回执。不该回却回了关的是该会话自动能力。三种失败若合成一个计数值班只能猜测。日志需保留原文、规则标识、是否出站。只有成功数解释不了为什么闲聊也被回了。词库放业务配置不要编译进发送层。对外只暴露收到一条、是否回复、回复什么。模型只是规则命中后的一种生成器不是入口。价格类命中应转人工而不是「让模型谨慎一点」。测试群上应看到闲聊零出站、口令回配置句、投诉后无自动气泡且有转出记录、同一进群事件一条欢迎。先一个测试群跑稳定再扩。群规则与私聊规则分配置。总闸会把业务通知一并切断。查看企业微信 API 文档https://doc.qiweapi.com/