在智能客服问答系统中，如何让一个模型应对千差万别的用户问题？从闲聊问候到复杂多步骤业务查询，单一策略往往顾此失彼。本文深入解析基于多策略路由（Multi-Strategy Routing）的智能客服系统设计，展示如何通过策略路由模块让 LLM 自主选择最优执行路径。

一、为什么需要多策略路由？

传统的智能客服系统通常采用单一的执行模式——要么是简单的检索式回复，要么是固定的 ReAct（Reasoning + Acting）循环。这两种方式在处理某个 FAQ 这样的垂直场景时，存在明显短板：

• 闲聊问题（“你好”、“谢谢”、“再见”）不需要检索知识库，直接回复即可，走完整链路反而浪费 token。
• 简单查询（“如何创建工单”）只需单个步骤就能回答，不需要复杂的规划。
• 多步骤流程（“从创建工单到生成统计报告的完整流程”）需要跨章节、多步骤的推理和执行。
• 对比分析（“系统X和系统B的区别”）需要在执行后自我检查，确保覆盖完整。

于是我们设计了多策略路由系统——用 LLM 自身对问题进行分类和路由，从五种预定义策略中选出最优解。

二、五种策略详解

策略系统共包含五种模式，从 skip 到 D，复杂度逐级递增：

2.1 Skip 策略——闲聊拦截器

适用于：问候、感谢、再见等非业务问题
特点：不检索知识库，直接生成友好回复

设计初衷：通用客服场景中，用户的第一句话往往是"你好"或"在吗"。如果每次问候都触发知识库检索和 ReAct 循环，不仅浪费算力，还会产生延迟。Skip 策略在路由阶段直接识别并拦截，返回一句礼貌的问候即可。

典型触发场景：

• “你好”、“早上好”
• “谢谢”、“辛苦了”
• “再见”、“88”

2.2 策略 A——快速响应通道

适用于：单操作步骤、简单业务问题
流程：ReAct 逐步选工具，单轮或两轮完成

策略 A 是默认的快速通道。当用户问题只涉及单一操作时（例如"查询工单状态"），系统直接进入 ReAct 循环，选择对应工具执行并返回结果。不需要事先规划，执行效率最高。

2.3 策略 B——计划执行模式

适用于：多独立子问题，需要拆解后依次执行
流程：先规划→再按序执行→汇总答案

当问题包含多个独立的子问题时（例如"如何创建工单和如何添加审批人"），策略 B 会先让 LLM 生成执行计划，将问题拆解为多个独立步骤，然后按照计划依次调用工具，最后汇总答案。

2.4 策略 C——灵活调整模式

适用于：跨章节多步骤流程，步骤间存在依赖
流程：规划→逐步执行→每步观察中间结果→动态调整

这是最灵活的策略。当用户问"从创建工单到生成统计报告的完整流程"时，策略 C 会先生成一份粗略计划，然后每执行一步都观察中间结果，根据实际情况动态调整后续步骤。这种"边做边看"的方式特别适合跨章节、步骤间有依赖关系的复杂查询。

2.5 策略 D——自检补漏模式

适用于：对比分析类问题，需要保证覆盖完整
流程：规划→执行→LLM 自检评估→补漏→返回

策略 D 在策略 C 的基础上增加了一个关键环节——自检（Reflexion）。执行完所有计划步骤后，LLM 会对自己生成的答案进行完整性评估。如果发现遗漏，自动补全后再返回给用户。

典型场景：“对比系统X和系统B在业务审批流程上的异同”——系统需要确保两个系统的各个方面都被覆盖到，不能只讲一个。

策略选择对比表

策略	适用场景	规划	执行	自检	响应速度
Skip	闲聊问候	无	直接回复	无	极快
A	单步简单查询	无	ReAct 即时	无	快
B	多独立子问题	先规划	顺序执行	无	中等
C	多步骤有依赖	动态规划	逐步调整	无	较慢
D	对比分析需完整性	先规划	顺序执行	有	最慢

三、路由判断流程

路由判断是整个系统的决策大脑，其流程分为三个阶段：

3.1 问题分析

当用户问题到达路由模块时，首先进入 _route() 方法：

# 伪代码逻辑
def _route(question: str, context: dict):
    # 1. Skip 策略快速筛查（L1 + L2 防护）
    if _should_skip(question):
        return "skip", None
    
    # 2. LLM 分析问题类型
    analysis = _llm_analyze(question)
    
    # 3. 匹配最优策略
    strategy = _match_strategy(analysis)
    
    return strategy, analysis

3.2 _route() → _llm_json() 的协作

路由模块的核心是一个结构化调用链：_route() 负责接收原始问题，调用 _llm_json() 让 LLM 输出结构化的 JSON 结果，包含：

• type: 问题类型（greeting/single/multi/comparison）
• strategy: 推荐策略（A/B/C/D/skip）
• target_systems: 涉及的业务系统归属（如 [“系统X”, “系统B”]）
• sub_questions: 子问题列表（策略 B/C/D 使用）

target_systems 归属判断是路由环节的一个重要特性。系统会自动识别问题涉及哪些业务产品线，这直接影响后续知识库检索的范围。

3.3 策略执行

匹配到策略后，系统进入对应的执行器：

_route() → LLM 分析 → JSON 输出 → 策略匹配 → _execute_strategy_{a|b|c|d}()

四、防护机制——SKIP_PROTECTION 三级防护

在实际生产中，LLM 分类并非 100% 可靠。一个本应 Skip 的业务问题被误判为普通问题，或者反过来，都可能影响用户体验。为此我们设计了 SKIP_PROTECTION 三级防护体系：

L1：Prompt 修复

第一道防线在 Prompt 层面。系统通过精心设计的 System Prompt 和 Skip 检测指令，引导 LLM 优先识别非业务问题。如果用户问题被判断为"可能非业务"，系统会在 Prompt 中强化约束，让 LLM 重新评估。

L2：业务关键词检测

BUSINESS_KEYWORDS = {
    "系统X": ["工单", "供应商", "入库", "业务审批流程"],
    "系统B": ["文档", "产品", "配料", "成本核算"],
    "系统C": ["任务调度", "库存", "统计报告", "门店"],
}

def _has_business_intent(question: str) -> bool:
    """L2 检测：基于业务关键词集合判断是否包含业务意图"""
    for system, keywords in BUSINESS_KEYWORDS.items():
        for keyword in keywords:
            if keyword in question:
                return True
    return False

L2 是一种纯代码级别的硬检测，不依赖 LLM。如果用户问题中包含任何业务关键词，即使 LLM 误判为"闲聊"，L2 也会将其拦截并转入正常的路由流程。

L3：自动降级到策略 A

如果 L1 和 L2 都未能给出明确结论（边缘情况），系统自动降级到策略 A——采用最保守的 ReAct 快速通道执行，宁可多花一点 token，也不错过任何潜在的业务需求。

问题输入 → L1 Prompt 修复 → "是闲聊" → L2 关键词检测
                                   ↓
                             命中关键词？→ 是 → 取消 Skip，进入路由
                                   ↓
                              否 → L3 自动降级到策略 A

五、四种策略执行器的差异

策略路由不仅仅是选择策略标签，每种策略的执行器都有完全不同的实现逻辑：

_execute_strategy_a()——ReAct 快速通道

def _execute_strategy_a(question):
    # 直接进入 ReAct 循环，逐步选择工具
    # 最多 5 轮思考-行动-观察
    # 适合单步骤操作
    while steps < MAX_STEPS:
        action = llm.think(question, history)
        if action.is_final():
            return action.answer
        result = execute_tool(action)
        history.append(result)

_execute_strategy_b()——先规划再执行

def _execute_strategy_b(question, sub_questions):
    # 步骤 1：LLM 生成执行计划
    plan = llm.plan(question, sub_questions)
    # 步骤 2：按计划顺序执行，不回头调整
    for step in plan:
        result = execute_step(step)
        intermediate_results.append(result)
    # 步骤 3：汇总所有中间结果
    return llm.summarize(question, intermediate_results)

策略 B 的特点是按计划线性执行，子问题之间相互独立，前一个步骤的结果不影响后续步骤。

_execute_strategy_c()——灵活调整

def _execute_strategy_c(question, sub_questions):
    plan = llm.plan(question, sub_questions)
    for i, step in enumerate(plan):
        result = execute_step(step)
        # 检查中间结果，决定是否需要调整后续计划
        observation = llm.observe(result, plan[i+1:])
        if observation.needs_adjustment:
            plan[i+1:] = observation.adjusted_plan
    return llm.summarize(question, plan, intermediate_results)

策略 C 的关键差异在于 llm.observe()——每步执行后都会观察结果，判断是否需要调整后续步骤。这种灵活性能有效处理跨章节、步骤间存在数据依赖的复杂场景。

_execute_strategy_d()——自检补漏

REFLEXION_SYSTEM = "你是一个严谨的质检员..."
REFLEXION_PROMPT = "请检查以下答案是否完整覆盖了用户问题..."

def _execute_strategy_d(question, sub_questions):
    # 执行阶段与策略 C 类似
    answer = execute_with_flexibility(question, sub_questions)
    
    # 自检阶段
    reflexion = llm.reflexion(
        question, 
        answer, 
        system=REFLEXION_SYSTEM,
        prompt=REFLEXION_PROMPT
    )
    
    if reflexion.has_gaps:
        # 补漏：补充遗漏的部分
        answer = llm.supplement(answer, reflexion.gaps)
    
    return answer

策略 D 在执行完成后增加了一个 Reflexion（自检）环节。REFLEXION_SYSTEM 和 REFLEXION_PROMPT 定义了质检员的角色和检查标准，LLM 扮演质检员对已生成的答案进行完整性评估。如果发现遗漏（例如对比分析中只覆盖了 A 系统未覆盖 B 系统），自动补充后再返回。

六、质量门控（QUALITY_GATE）

除了策略 D 的自检机制，系统还在最终输出前设置了 QUALITY_GATE（质量门控）。这是一个统一的答案质量检查器，对所有策略的输出进行最终把关：

所有策略的输出 → QUALITY_GATE → 通过 → 返回给用户
                              ↓
                           未通过 → 兜底策略（重新执行或返回默认回复）

质量门控检查的维度包括：

1. 完整性：答案是否覆盖了用户问题的所有方面？
2. 准确性：答案是否与检索到的知识一致，无幻觉？
3. 相关性：答案是否直接回应了用户问题，而非泛泛而谈？
4. 格式规范：对于需要特定格式（表格、列表）的答案，是否符合要求？

七、设计总结与思考

优势

1. 弹性适配：五种策略覆盖从极简单到极复杂的全场景，不再用一把尺子量所有问题。
2. Token 经济性：闲聊问题 0 检索、0 推理；简单问题快速 ReAct；只有复杂问题才走完整规划链路。Token 消耗与问题复杂度正相关，而非固定成本。
3. 鲁棒性：三级防护机制有效缓解了 LLM 分类不稳定的问题，L2 关键词检测提供了确定性的兜底。
4. 可观察性：策略路由的选择和执行路径可以被完整记录，便于调试和优化。

挑战

1. 路由本身的延迟：LLM 分析问题类型需要一次额外的 LLM 调用，在极端低延迟场景下可能成为瓶颈。
2. 策略边界模糊：B 和 C 之间的界限并非绝对清晰，某些问题的策略选择依赖路由 LLM 的判断质量。
3. D 策略的成本：自检环节增加了额外的一次 LLM 调用，对于高频对比分析场景，需要评估成本收益。

适用场景扩展

这套多策略路由设计虽然是针对某个 FAQ 系统的，但其架构思想可以广泛适用于：

• 企业知识库问答：从员工入职指南到复杂的流程查询
• 医疗客服：简单的科室查询到复杂的症状对照
• 金融客服：从账户余额查询到多产品对比分析

---

多策略路由的核心思想是让智能客服系统像人类专家一样思考——先判断问题类型，再选择回答策略，而不是对所有问题都用同一套流程。这种设计既保证了效率和成本，又提供了处理复杂问题的能力，是构建生产级智能客服系统的一个重要架构模式。