消息分流最容易被简化成"看这一句话说了什么就分给谁"。但真实场景里客户发"在吗"可能是想问售后、可能是续费咨询、也可能是投诉先确认有人在。只看当前消息的分流必然误判，真正智能的分流要拉通上下文、预测复杂度、并形成效果闭环。

一、上下文感知——不只看当前消息看最近7天

上下文感知分流的核心是"当前消息+会话历史+客户标签"三要素联合判断。当前消息做意图识别拿到候选意图，会话历史做主题延续判断——客户连续3条都在问物流，第4条"还有别的问题吗"显然是物流主题延续而不是新话题。客户标签做画像修正——VIP客户的"在吗"优先走专属客服，普通客户的"在吗"先进通用池。

上下文窗口要动态调整：新客户没有历史数据时窗口缩小到当前消息，老客户可以拉到7天对话。窗口太短会丢主题，太长会引入噪音——30天前的对话基本和今天的咨询无关。上下文还要识别"会话断点"——客户隔了3天再来不是延续上次对话，应该作为新会话处理。

二、复杂度预测——提前知道这次会话会持续多久

不同咨询复杂度差异巨大："查个订单号"2分钟结束，"投诉商品质量问题"可能要拉扯半小时。分流时如果只看意图不看复杂度，简单问题分给了能解决但慢的客服、复杂问题分给了快但浅的客服，效率都低。

复杂度预测靠历史模式：同一意图的历史会话平均时长、消息轮次、是否升级为主管。预测模型可以简单到查表——"物流查询"历史平均3轮、"售后投诉"历史平均12轮。预测结果反向影响分配：高复杂度咨询优先分给解决能力强、当前负载低的客服，即使他们排队更长也值得等。预测不准时允许中途换客服，但要有"会话交接包"——前一个客服的进展摘要+已确认信息+未解决问题，避免客户重复讲述。

三、效果闭环——每个分配决策都被结果打分

分流策略上线后没人能一眼看出好不好。必须建立效果闭环：每次分配记录"为什么这么分"（意图、复杂度、选择的客服），会话结束后收集三个结果指标——是否首次解决（FCR）、客户满意度（CSAT）、会话时长。结果反向打分分配决策，形成"哪些维度影响哪些结果"的权重学习。

闭环数据要每周复盘一次：某类意图持续低满意度，可能是分错了技能组；某个客服接的复杂单子满意度高但时长长，可能应该调高他的复杂单上限。复盘结果沉淀成分配规则调整，而不是手工个案处理。效果闭环最忌"只看平均分"——某个策略平均满意度4.2，但可能VIP客户满意度只有3.0，被平均掩盖了。

三个能力对照

上下文感知分流实现

class ContextAwareDispatcher:
    def route(self, wxid, msg):
        # 三要素：当前消息+历史+标签
        intent = self.classify(msg)
        history = db.recent_dialog(wxid, days=7) or []
        tags = db.get_tags(wxid)

        # 主题延续判断
        if history and self.is_continuation(history[-1], msg):
            topic = history[-1]["topic"]
            return self.dispatch_to_topic_owner(wxid, topic, msg)

        # 复杂度预测
        complexity = self.predict_complexity(intent, tags)
        candidate_groups = self.skill_groups(intent)

        # VIP修正
        if "vip" in tags:
            candidate_groups = ["vip"] + candidate_groups

        # 复杂度高的优先能力强客服
        if complexity > COMPLEX_THRESHOLD:
            chosen = self.pick_strong_low_load(candidate_groups)
        else:
            chosen = self.pick_least_load(candidate_groups)

        # 记录决策理由供效果闭环
        decision_id = db.log_decision(
            wxid=wxid, intent=intent, complexity=complexity,
            chosen=chosen, history_len=len(history), tags=tags)
        self.bind_session(wxid, chosen, decision_id)
        return chosen

    def predict_complexity(self, intent, tags):
        """查表式预测：意图×标签的历史均值"""
        baseline = COMPLEXITY_TABLE.get(intent, 5)
        if "vip" in tags or "complaint" in tags:
            baseline *= 1.5
        return baseline

    def on_session_end(self, wxid, decision_id, outcome):
        """效果闭环：用结果给决策打分"""
        fcr = outcome["first_call_resolution"]
        csat = outcome["csat"]
        duration = outcome["duration"]
        db.log_outcome(decision_id, fcr, csat, duration)
        # 每周聚合分析触发权重调整
        if self.should_recalibrate():
            self.recalibrate_weights()

落地建议

上下文感知先做"会话断点识别"这一项——客户隔几天再来不要当成延续，光这一条就能消除大量误判。复杂度预测从最简单的查表做起，别一上来就训练模型，历史数据量不够模型也学不动。效果闭环最容易偷懒的是"决策留痕"——分配时不记录理由，事后没法复盘。三个能力都依赖完整的对话和会话数据，微信侧的消息收发和会话状态由 Eyun 这类个人微信API接口提供，分流引擎独立部署对接客服工单系统，详细回调字段和消息接口参数参考 Eyun 开发文档。