「机器人总开关」关掉之后，客户群里的工单完成通知也会停。值班会按通道故障处理，实际只是把两条无因果关系的出站绑在同一闸门上。调用量变成 0，看起来像接口挂了。通道往往还活着，只是你把通知也关了。

自动回复的输入是对端发言，输出是规则是否开口。业务通知的输入是工单、预约、库存等状态变迁，对端未必先说话。入口不同，时效、幂等键、失败动作也不同。硬揉成一个「机器人」，配置上省事，事故上费事。

控制面按动作拆，不按「机器人」拆

入站链：事件 → 去重 → 状态机 → 规则 → 可选出站。通知链：业务事件 → 合并窗口 → 渲染 → 存活检查 → 投递 → 回执。共用发送开关会让关关键词连带停通知。共用重试器会让登录探测失败去重打欢迎。

开关建议按出站通知、入站欢迎、入站关键词、素材切开。关关键词后欢迎仍应可测。投诉名单可禁止自动开口，经审核的通知是否仍发，属于产品规则，应写在配置而非发送函数里。内部群通报与客户群值班同样分闸。演示用内部群成功，不能记入客户群验收。

开关是配置，不是一个布尔打天下：

SWITCH = {
    "notify": True,    # 工单通知
    "welcome": True,   # 入站欢迎
    "keyword": False,  # 关键词，关掉不应影响 notify
}

def allow(kind, complaint=False):
    if complaint and kind != "notify":
        return False
    return SWITCH.get(kind, False)

keyword=False 时 allow("notify") 仍为 True。写成 if not robot_on: return，关词库会把完成通知一起停掉，调用量变 0，看起来像通道挂了。

会话状态（可自动、转人工、勿扰、投诉）须落库。转人工后自动回复静默。通知是否跟随静默，另开规则，禁止默认绑死。坐席正在处理赔偿，系统还把「已完成」推到群里，两套口径会进同一聊天。词库留在业务配置，发送层只收最终文本。能指出命中哪条规则，值班才接得住。

审核队列要有积压指标。积压无人消费，出站实际全停，调用量却是 0，会被误判为通道挂了。积压和通道不可用要分开报警。配置变更要有审计，换值班人应能只靠配置和看板接手，不靠口头交代哪个开关是真总闸。

关掉自动回复后，测试工单通知仍应进入测试群；打开回复后闲聊仍不应出站。两件事互不扰动，拆分才成立。一个开关能过演示，过不了值班交接。