先记住这个答案
Routing 工作流先识别输入属于哪类任务，再把它交给适合的处理分支。设计时应让类别边界清楚，给出少量代表性示例，并让模型返回可校验的标签或结构化决策。对混合意图、无法判断或条件不足的输入，应有明确兜底策略，而不是强行分到某一类。路由质量要结合各分支最终结果和错误成本评估，不能只看分类准确率。
- 分支应有不同处理能力，类别定义尽量可区分
- 结构化标签便于校验，但不能保证意图判断正确
- 模糊输入需要可解释的兜底，多意图不一定只选一条路
先设计分支而不是先写分类提示
例如项目助手可以分成解释代码、查询运行状态和修改代码三条路径。它们的输入需求与外部效果不同，分类必须围绕用户真正要完成的操作。若解释代码与分析代码只是两套近似提示，边界难以说明，路由器也很难稳定选择。
对明确规则优先使用确定性判断，例如已有表单字段声明任务类型时，不必再次让模型猜测。模型更适合处理自然语言含义和上下文变化。路由输出仍要验证是否属于允许集合，并记录判断依据供诊断，不能直接执行任意生成的函数名。
处理多意图与不确定条件
用户说先解释这个错误再帮我修复，可能需要一个有先后关系的组合流程，而不是在解释与修改中二选一。可以由上层明确拆分子目标，再分别进入适合的分支；若分支互斥且对象不清楚，则先获取会改变执行路径的关键信息。
模型自报的置信度不能自动当作校准过的概率。可以结合规则冲突、候选差异和验证集表现设计兜底阈值，但应通过实际数据检验。兜底可以是补充检索、更明确的分类检查或向用户澄清，具体选择取决于误分会造成什么后果。
从最终任务效果检查路由质量
分类标签正确但分支无法处理输入，整体任务仍然失败。评估应记录路由决策、分支结果和失败原因，区分分错路与选对路但实现能力不足。类别数量不均衡时，还要按类别查看召回和误分情况，避免大量简单请求掩盖少数重要分支的问题。
错误成本也不对称：把查询误判为修改，比把复杂请求交给稍慢的通用处理器更值得关注。可以为关键边界设置专门样本，包括否定表达、引用他人的指令以及多轮指代。修改类别定义后重新跑历史样本，确认旧输入没有被悄悄改道。
容易答错的地方
- 所有输入必须选一个现有类别
- 类别集不完整或输入混合时，强制分类会制造错误确定性，应支持明确的未决或组合处理。排查“LLM Routing 工作流分支选择与兜底设计”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
- 合法 JSON 就代表路由正确
- 结构验证只证明标签格式符合约定，仍需要检查其是否匹配用户意图和当前上下文。排查“LLM Routing 工作流分支选择与兜底设计”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
面试官还会怎么问？
分支越细效果越好吗？
更细分支可能提供更专门的处理，也会增加类别重叠和样本需求，只有能力差异足够明确时才值得拆分。
路由可以在任务中途改变吗？
可以，工具反馈可能改变对任务的理解。应保存已完成状态并说明切换依据，避免重复执行外部动作。
兜底到通用分支有什么风险？
通用分支可能变成错误分类的隐藏出口，需要统计进入比例与实际完成结果，不能让它掩盖类别设计问题。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。