自动化助手和普通问答机器人的分界不在"用了多强的模型"，在三个环节是否闭环：什么事件触发它行动、它怎么判断该不该做和怎么做、做完之后结果怎么反馈并影响下一次行动。很多项目把全部精力放在中间的对话能力上，触发源单一（只能等用户发消息）、判断方式要么纯规则要么纯模型、结果发出去就石沉大海——这样的助手跑起来既不主动也不会变聪明。

一、三类触发器——助手不应该只在被@时才工作

只靠消息触发的助手本质还是被动应答。完整的触发源有三类。消息触发：客户或同事发来消息，助手实时响应，这是最基础的入口。定时触发：到点执行周期性任务——每天早9点汇总昨晚的售后群消息、每周五给销售推送本周高意向客户清单、每小时检查一次超时工单。事件触发：业务系统状态变化时被动唤起——订单支付成功触发关怀消息、工单状态变更触发客户通知、库存低于阈值触发采购群提醒。

三类触发器对应三种不同的运行模式：消息触发是同步会话（用户在等回复，秒级响应）；定时触发是批量任务（没人等，重点是吞吐和频控）；事件触发是实时联动（业务发生即动作，重点是可靠投递）。触发器统一成内部事件模型进入同一个调度核心，助手逻辑不用关心自己是被谁唤醒的，只处理"事件+上下文"。定时和事件触发必须有死信机制——执行失败的任务进死信队列可重放，不能静默丢失。

二、混合判断层——规则兜底高频确定场景，LLM处理模糊长尾

判断层最容易走两个极端：全靠规则，话术僵化、维护一堆if-else，客户换个说法就识别不了；全靠大模型，每次判断都调模型，延迟高、成本高，而且"查物流"这种高频确定意图根本不需要推理。生产级做法是分层混合：第一层规则和关键词匹配，命中高频意图（订单号格式、明确关键词、固定指令）直接路由，毫秒级零成本；第二层小模型或向量分类，处理规则没命中但属于已知意图的消息；第三层才是大模型，只处理前两层都无法判断的模糊长尾和需要复杂推理的请求。

混合判断还有一个关键设计是"判断置信度决定自动化程度"：高置信只读任务自动执行；中置信任务先生成方案请用户确认；低置信或涉及写操作的直接转人工。判断不是一次性的——执行过程中发现参数不全或前提不成立，要回到判断层重新决策，而不是硬着头皮执行。

三、结果反馈闭环——做完之后要"回话"还要"学习"

助手执行完任务不能沉默。结果反馈分三个层次：对用户的即时反馈（任务完成了告诉用户做了什么、关键结果是什么、有没有需要他注意的异常）；对发起方的异步回执（定时批量任务跑完推送执行报告——成功多少、失败多少、失败明细）；对系统的结果沉淀（每次执行的成功/失败/用户是否满意写回数据，作为下一轮判断的依据）。

反馈中最有价值的是"用户纠正回流"：助手判断错了用户说"不是查这个订单"，这次纠正要被捕获——修正后的意图、正确的参数入库，定期分析纠正样本，高频错误反哺规则层和提示词。助手因此越用越准。失败反馈要带可操作信息：不能只说"操作失败"，要说明原因和建议（"客户已不是好友，建议电话联系"），让反馈本身推动问题解决。

三环节设计对照

环节	常见缺陷	设计要点
触发	只能被动应答	消息/定时/事件三源+死信队列
判断	纯规则僵化或纯模型昂贵	规则→小模型→LLM三层+置信度分级
反馈	石沉大海不迭代	即时/异步/沉淀三层+纠正回流

自动化助手骨架实现

class AssistantCore:
    # 三类触发器统一成内部事件
    def on_message(self, raw):
        self.dispatch(TriggerEvent("message", raw, raw.wxid))

    def on_timer(self, job):
        for target in job.targets:
            self.dispatch(TriggerEvent("timer",
                {"job": job.name}, target))

    def on_biz_event(self, evt):
        self.dispatch(TriggerEvent("biz_event", evt,
            evt.customer_wxid))

    def dispatch(self, event):
        try:
            decision = self.judge(event)
            result = self.execute(decision)
            self.feedback(event, decision, result)
        except Exception as e:
            dead_letter.put(event)   # 死信不丢
            raise

    def judge(self, event):
        # L1 规则：高频确定意图
        hit = rule_engine.match(event)
        if hit and hit.confidence > 0.95:
            return Decision(hit.action, confidence="high")
        # L2 小分类：已知意图
        intent = small_classifier(event.text)
        if intent.confidence > 0.8:
            return Decision(intent.action, confidence="mid")
        # L3 LLM：模糊长尾+复杂推理
        return llm_decide(event, context=load_profile(event.wxid))

    def execute(self, decision):
        if decision.confidence == "low" or decision.is_write:
            return handoff_human(decision)
        if decision.need_confirm:
            return ask_confirmation(decision)
        return tool_registry.run(decision.action, decision.params)

    def feedback(self, event, decision, result):
        # 即时反馈
        sendText(WID, event.wxid, result.user_summary)
        # 结果沉淀
        db.save("action_log", {"event": event.kind,
            "decision": decision.name, "ok": result.ok,
            "corrected": False})

落地建议

建设顺序按三环节推进：先补齐触发源——定时和事件触发比对话能力更容易被忽视，但它们是"自动化"三个字的真正体现；判断层的规则先行，把Top20高频意图用规则覆盖，能省掉80%的模型调用；反馈闭环从第一天就要记录执行结果，纠正样本攒三个月就是最有价值的优化资产。微信侧的消息回调和定时触达能力由Eyun这类个人微信API平台提供，业务事件由各业务系统Webhook汇入，触发调度、混合判断和反馈沉淀在自建助手服务中实现，接口字段和回调结构以Eyun平台的开发文档为准。