在智能客服问答系统中如何让一个模型应对千差万别的用户问题从闲聊问候到复杂多步骤业务查询单一策略往往顾此失彼。本文深入解析基于多策略路由Multi-Strategy Routing的智能客服系统设计展示如何通过策略路由模块让 LLM 自主选择最优执行路径。一、为什么需要多策略路由传统的智能客服系统通常采用单一的执行模式——要么是简单的检索式回复要么是固定的 ReActReasoning 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):returnskip,None# 2. LLM 分析问题类型analysis_llm_analyze(question)# 3. 匹配最优策略strategy_match_strategy(analysis)returnstrategy,analysis3.2_route()→_llm_json()的协作路由模块的核心是一个结构化调用链_route()负责接收原始问题调用_llm_json()让 LLM 输出结构化的 JSON 结果包含type: 问题类型greeting/single/multi/comparisonstrategy: 推荐策略A/B/C/D/skiptarget_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 三级防护体系L1Prompt 修复第一道防线在 Prompt 层面。系统通过精心设计的 System Prompt 和 Skip 检测指令引导 LLM 优先识别非业务问题。如果用户问题被判断为可能非业务系统会在 Prompt 中强化约束让 LLM 重新评估。L2业务关键词检测BUSINESS_KEYWORDS{系统X:[工单,供应商,入库,业务审批流程],系统B:[文档,产品,配料,成本核算],系统C:[任务调度,库存,统计报告,门店],}def_has_business_intent(question:str)-bool:L2 检测基于业务关键词集合判断是否包含业务意图forsystem,keywordsinBUSINESS_KEYWORDS.items():forkeywordinkeywords:ifkeywordinquestion:returnTruereturnFalseL2 是一种纯代码级别的硬检测不依赖 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 轮思考-行动-观察# 适合单步骤操作whilestepsMAX_STEPS:actionllm.think(question,history)ifaction.is_final():returnaction.answer resultexecute_tool(action)history.append(result)_execute_strategy_b()——先规划再执行def_execute_strategy_b(question,sub_questions):# 步骤 1LLM 生成执行计划planllm.plan(question,sub_questions)# 步骤 2按计划顺序执行不回头调整forstepinplan:resultexecute_step(step)intermediate_results.append(result)# 步骤 3汇总所有中间结果returnllm.summarize(question,intermediate_results)策略 B 的特点是按计划线性执行子问题之间相互独立前一个步骤的结果不影响后续步骤。_execute_strategy_c()——灵活调整def_execute_strategy_c(question,sub_questions):planllm.plan(question,sub_questions)fori,stepinenumerate(plan):resultexecute_step(step)# 检查中间结果决定是否需要调整后续计划observationllm.observe(result,plan[i1:])ifobservation.needs_adjustment:plan[i1:]observation.adjusted_planreturnllm.summarize(question,plan,intermediate_results)策略 C 的关键差异在于llm.observe()——每步执行后都会观察结果判断是否需要调整后续步骤。这种灵活性能有效处理跨章节、步骤间存在数据依赖的复杂场景。_execute_strategy_d()——自检补漏REFLEXION_SYSTEM你是一个严谨的质检员...REFLEXION_PROMPT请检查以下答案是否完整覆盖了用户问题...def_execute_strategy_d(question,sub_questions):# 执行阶段与策略 C 类似answerexecute_with_flexibility(question,sub_questions)# 自检阶段reflexionllm.reflexion(question,answer,systemREFLEXION_SYSTEM,promptREFLEXION_PROMPT)ifreflexion.has_gaps:# 补漏补充遗漏的部分answerllm.supplement(answer,reflexion.gaps)returnanswer策略 D 在执行完成后增加了一个Reflexion自检环节。REFLEXION_SYSTEM和REFLEXION_PROMPT定义了质检员的角色和检查标准LLM 扮演质检员对已生成的答案进行完整性评估。如果发现遗漏例如对比分析中只覆盖了 A 系统未覆盖 B 系统自动补充后再返回。六、质量门控QUALITY_GATE除了策略 D 的自检机制系统还在最终输出前设置了QUALITY_GATE质量门控。这是一个统一的答案质量检查器对所有策略的输出进行最终把关所有策略的输出 → QUALITY_GATE → 通过 → 返回给用户 ↓ 未通过 → 兜底策略重新执行或返回默认回复质量门控检查的维度包括完整性答案是否覆盖了用户问题的所有方面准确性答案是否与检索到的知识一致无幻觉相关性答案是否直接回应了用户问题而非泛泛而谈格式规范对于需要特定格式表格、列表的答案是否符合要求七、设计总结与思考优势弹性适配五种策略覆盖从极简单到极复杂的全场景不再用一把尺子量所有问题。Token 经济性闲聊问题 0 检索、0 推理简单问题快速 ReAct只有复杂问题才走完整规划链路。Token 消耗与问题复杂度正相关而非固定成本。鲁棒性三级防护机制有效缓解了 LLM 分类不稳定的问题L2 关键词检测提供了确定性的兜底。可观察性策略路由的选择和执行路径可以被完整记录便于调试和优化。挑战路由本身的延迟LLM 分析问题类型需要一次额外的 LLM 调用在极端低延迟场景下可能成为瓶颈。策略边界模糊B 和 C 之间的界限并非绝对清晰某些问题的策略选择依赖路由 LLM 的判断质量。D 策略的成本自检环节增加了额外的一次 LLM 调用对于高频对比分析场景需要评估成本收益。适用场景扩展这套多策略路由设计虽然是针对某个 FAQ 系统的但其架构思想可以广泛适用于企业知识库问答从员工入职指南到复杂的流程查询医疗客服简单的科室查询到复杂的症状对照金融客服从账户余额查询到多产品对比分析多策略路由的核心思想是让智能客服系统像人类专家一样思考——先判断问题类型再选择回答策略而不是对所有问题都用同一套流程。这种设计既保证了效率和成本又提供了处理复杂问题的能力是构建生产级智能客服系统的一个重要架构模式。