1. 为什么先学路由而不是直接开写Agent循环先说个我在群里看到的高频问题很多人拿到智能体的需求第一反应是赶紧写一个大循环把大模型调用、工具执行、上下文管理全塞进一个类里。跑通是能跑通但改一个功能就得动全身最后代码变成一锅粥。我在带模拟项目X的时候反复跟成员讲智能体真正难的不是那几次大模型调用而是它内部的交通系统——也就是路由。路由决定了用户的一句话进来之后由谁处理、走哪条链路、调用哪些工具、回落到哪一层。路由设计得好后面加工具、加场景、加兜底都是往里贴砖路由设计得烂每加一个功能都是一次重构。这篇就围绕路由的四种实现方式展开。它们不是纯理论我把每种的适用场景、代码骨架、以及我在实际项目中踩过的坑都放进来。2. 从直观到工程化路由的思维演进2.1 路由到底在解决什么问题可以把智能体想象成一个前台客服中心。用户打来电话第一步是话务员判断这个人是来咨询账单还是报修故障还是想转人工。这个判断动作就是路由。放到智能体里路由的核心职责是解析用户意图判断该走哪条处理链路把请求分发到对应的大模型、技能模块或者工具组合在执行异常或意图不明时决定回落到哪一层兜底维持对话的上下文确保分流后还能把结果带回来一句话路由就是智能体的业务入口和调度中枢。它不负责具体干活但决定活怎么分。2.2 四种实现方式的整体对照先把四种方式摆在一个表里后面我再逐个拆实现方式核心机制上手成本扩展性适合场景规则匹配路由用关键词、正则或条件表达式命中分支最低一般指令明确、词表有限的垂直场景分类模型路由先做意图分类再进对应分支中较好意图边界清晰、需要独立分类能力的场景语义路由用向量相似度或大模型判断选哪个分支中高很好分支多、表达灵活、同义说法多的场景动态自决策路由由大模型基于上下文自主决定调用路径高最强工具多、链路复杂、需要临场应变的场景从规则匹配到动态自决策本质上是一条从人写规则到模型自决策的演进路线。它们不是互斥的实际项目里经常混合使用。2.3 选型不是越高级越好我在跟新手讨论时发现一个误区觉得语义路由和动态决策才像智能体规则路由显得太笨。但真实业务里规则路由的稳定性和可解释性恰恰是它最大的优势。我见过某个报表问答助手硬是靠规则路由支撑了大半年所有分支清晰可控后来加功能也都是小修小补。正确的思路是先用简单方案跑通最小闭环在运行过程中记录哪些分支容易出现误判再针对性地引入更强的路由方式。后面我会给出具体的指标判断方法。3. 第一种实现规则匹配路由3.1 它的识别逻辑规则匹配的核心是人在代码里预先定义分类依据。分类依据可以是关键词、正则表达式、情感极性、或者业务字段的组合条件。这种方式最适合意图边界非常清晰、表达方式相对固定的场景。打个比方你要做一个智能体专门帮用户查天气。用户一般会说北京今天天气怎么样上海明天会下雨吗三亚后天温度多少。这些句子虽然格式不同但核心结构都是地点时间天气意图。用规则完全可以覆盖九成以上的输入。3.2 一个极简的规则路由示例代码层面可以这样写function routeByRules(input) { const text input.trim(); // 第一层按主意图分桶 if (/天气|下雨|温度|气温|会不会降水/.test(text)) { return { branch: weather, payload: extractWeatherInfo(text) }; } if (/股票|股价|大盘|行情|涨跌/.test(text)) { return { branch: stock, payload: extractStockInfo(text) }; } if (/翻译/.test(text)) { return { branch: translate, payload: extractTranslateInfo(text) }; } // 第二层都没命中就回落兜底 return { branch: fallback, payload: { text } }; }关键在于构建规则树而非规则平铺。先按主意图分桶再在桶里做细粒度参数抽取。这样新增一个意图时只需要新增一个分支和对应的抽取逻辑不会牵动其他分支。3.3 我想重点强调的坑情绪的优先级常被忽略。用户可能说的是这天气也太热了吧这句并没有明确问天气但如果在规则层不做情感判断它就会被错误地归入天气查询。建议在规则匹配前加一个轻量级的情绪或语气识别把抱怨、调侃、反讽等非请求类输入先拦下来。正则表达式要覆盖变体例如温度多少度和多少度啊诸如此类。至少要抽象出三级变体标准式、口语式、带语气词式。规则命中的顺序会影响结果优先级最高的规则必须放在最前面。一旦命中就提前return不做无谓的后续判断。这条路最大的优点是性能好、可解释、响应稳定适合作为线上第一道防线。它的不足是遇到没见过的说法就失效所以需要搭配兜底逻辑。4. 第二种实现分类模型路由4.1 给意图构建一个轻量分类器分类模型路由的核心是训练一个专门的意图分类器先分类再执行。它和规则匹配最大的区别在于规则匹配是人写死判断条件分类模型是从标注样本里学习模式。它的典型结构是收集历史对话或模拟对话标注出意图标签如weather、stock、greeting、complaint用样本微调一个轻量分类模型例如基于BERT的小模型或直接调用现成的分类服务推理时先把用户输入送入分类器得到意图分布再根据置信度路由到对应分支4.2 置信度门槛是关键设计点分类模型不是输出一个标签就完了工程上要给它加置信度门槛。我以 0.9作为高置信、直接进对应分支低于0.9但高于0.6的进入确认分支由大模型进一步追问用户低于0.6的全部落到兜底。这个策略把很多原本会误判的输入都挡在了错误分支之外。def classify_and_route(user_text): intent, confidence classify(user_text) if intent weather and confidence 0.9: return handle_weather(user_text) if confidence 0.6: return ask_for_clarification(intent, confidence) return handle_fallback(user_text)很多失败的分类路由项目问题不在模型精度本身而在没有设置确认门槛。覆盖率高的代价必然是误判率也高把低置信度样本直接送进业务分支会污染下游上下文。4.3 什么时候值得上分类模型我个人的判断标准是意图种类在4个以上且表达方式有持续变化规则匹配的未命中率超过两成且兜底逻辑吃掉了大量真实请求业务上能够抽出几百条意图样本用于微调且具备持续标注的机制一旦满足这三条分类模型路由就能显著优于纯规则。4.4 我在项目里遇到的覆盖陷阱有一次我们在做模拟项目X的意图分类时训练集里全是标准问法比如今天天气如何明天成都冷不冷。一到线上用户输入变成这鬼天气热死我了开车过去会不会淋雨分类器全乱了。后来我们把线上积累的真实句子定期回流到标注池发现用户问天气的花样比想象中多得多。再后来我们干脆做了一个双通道方案分类模型处理明确意图规则路由处理强指令类请求两条路并行谁置信度高听谁的。这个结构帮我解决了很多模糊表达的问题。5. 第三种实现语义路由5.1 让分布式的语义兜住灵活的提问语义路由的思路是每个分支都有一个代表性的语义描述用户输入进来后计算它们之间的语义相似度选最接近的分支。实现方案主要有三种用通用向量模型如文本嵌入模型对用户输入和分支描述分别编码算余弦相似度用大模型直接判断以下哪个分支更符合这句话适合分支数量少但语义复杂的场景混合法向量召回若干个候选分支再交给大模型做精细挑选在项目里我常常把第三种作为默认方案。向量负责粗筛大模型负责精判既控制成本又保证准确。5.2 分支描述的写法决定了路由质量好的分支描述要能覆盖提问的变体。举个反例如果你把天气分支的描述写成用户问天气情况那实际提问明天出门要带伞吗相似度就会偏低如果你把它扩展到用户询问天气、降水、温度、风力、紫外线、出游是否需要带伞或加衣服覆盖面就大得多。branch_descriptions { weather: 用户询问天气、气温、降水概率、风力、紫外线强度、出行是否需要带伞或增减衣物, stock: 用户询问股票价格、大盘指数、个股涨跌、行情走势、持仓盈亏, translate: 用户请求把某种语言翻译成另一种语言或询问某个词句的外语说法, }分支描述建议每季度做一次回流优化把线上积累的高频说法补充进去。5.3 语义路由的坑别只看余弦相似度我见过不少同学兴致勃勃地搭建了语义路由上线后发现调用大模型的次数反而变多了。原因是相似度是相对接近不是绝对正确。比如今天有什么热门电影这个提问可能在entertainment分支和general分支之间只有微弱差异。如果只看余弦相似度很容易选错。所以语义路由的配套机制是相似度前三名都保留下来如果第一名和第二名的分值差距小于某个阈值比如0.05就交由大模型做二选一判定。这既保留了语义泛化的优势又避免了细边界上的随机选择。另外要注意的是语义路由的稳定性很大程度上依赖向量模型的质量。不要为了省成本选一个明显偏弱的模型它在同义词、否定句、反讽句上都会掉链子最后害得下游排查成本更高。5.4 一个值得尝试的混合判断样例在模拟项目X的某个模块里我做了这样的混合设计候选集从所有分支的语义描述中生成向量索引用户输入向量化后做ANN检索召回Top3若Top1分值与Top2差距小于阈值由大模型根据Top3候选做最终裁决裁决结果落到分支执行器这个方案在离线测试里把路由准确率从单用向量的82%提到了93.5%在线体验也更稳定。关键是第3步只消耗极少的大模型token成本完全可控。6. 第四种实现动态自决策路由6.1 路由权交给大模型但要给它边界动态自决策路由是目前很多新一代智能体采用的方式。它的本质是不在代码里显式写去哪条分支而是由大模型根据用户意图、当前上下文、可用工具列表自己决定调用哪个工具、执行哪条链路。它的核心组件有三个功能清单、决策提示词、执行回退机制。功能清单必须写得足够清晰包含每个功能的名字、用途、参数说明、使用条件。大模型靠这份清单来认识它能做什么。决策提示词则描述决策原则比如必须先明确时间、地点、主体再调用对应工具如果信息不足先追问不要瞎猜。执行回退机制负责兜底——当大模型选不出合适分支时或者执行分支返回异常时要有降级路径。6.2 一份动态路由的最小实现思路functions [ { name: query_weather, description: 查询指定城市在指定日期的天气。适用于用户询问气温、降水、风力、空气质量, parameters: {city: string, date: string} }, { name: query_stock, description: 查询指定股票代码的行情数据。适用于用户询问股价、涨跌幅、成交量, parameters: {code: string} } ] decision_prompt 根据用户需求从可用功能中选出最合适的调用方式。 如果用户没有提供必要参数请用追问的方式补充信息。 如果用户需求无法被任何功能覆盖不要强行调用请输出无法处理并解释原因。 def dynamic_route(user_input, context): response llm.chat_with_tools( promptdecision_prompt, functionsfunctions, user_inputuser_input, contextcontext ) return response.tool_calls这里最关键的是必要参数缺省时先追问否则大模型会拿错误参数去调工具得到一堆无意义的结果。6.3 动态路由的安全护栏设计动态路由看似聪明但如果完全没有护栏它会做出让人匪夷所思的事情。我在实测中发现过大模型把明天上海冷不冷解读成获取上海未来15天温度曲线并调用了一个重量级数据分析工具白白浪费了几分钟的计算资源。所以护栏必须包含三件事功能权重控制默认只开放十个以内的核心功能其余功能需要用户在对话中主动确认才允许启用。这就防止了模型在模糊场景下随意启用重工具。参数泄漏拦截用户输入中与功能参数无关的内容不允许传入工具。例如用户问天气附带了一段无关闲聊动态路由只能提取城市、日期进工具其余内容留在上下文。执行结果校验工具返回异常或空数据时模型必须将该工具执行失败反馈给用户而不是尝试用另一个工具猜测结果。如果让大模型完全自由地选择工具链大概率会出现不可控的联动调用这是动态路由在工程化过程中的第一道大坎。6.4 大模型幻觉引发的路由偏航还有个必须注意的地方动态自决策比前三种方式更容易被大模型的幻觉带偏。模型有时会在工具调用里编造一个并不存在的参数名或者把同一个意图拆成两次调用。要解决这个问题除了在提示词里明确约束任务清单还要在代码层做参数校验——凡是工具定义里不存在的参数一律拒绝调用。我习惯在动态路由目标下游再加一层参数白名单校验哪怕模型多返回了一个多余字段也会拦截。这样既能享受动态路由的灵活性又不会因为幻觉污染了工具执行的质量。7. 四种路由的实战串讲与选型判断7.1 同一句话在四种路由下的不同表现我拿预约下周二下午三点的会议室这句话看看四种方式各自怎么处理路由方式处理表现可能的问题规则路由命中会议室预约下周二等关键词进入预定分支下周二的语义解析需要额外NLP分类路由分类为meeting_booking进入预定流程需要足够的训练样本覆盖这个意图语义路由通过向量匹配找到会议预定分支如果没有描述好容易和日程查询混淆动态自决策模型自动列出预定会议所需的日期、时间、成员并调用预定工具也可能多问一句几个人参加会议增加了一次追问轮次同样一句话四种路由在表达能力、成本和稳定性上的表现完全不同。没有绝对的最好只有和你的业务约束最匹配的那一种。7.2 业务约束与路由选择的匹配矩阵我们可以把业务约束归纳成四个维度意图覆盖率要求、实时性要求、可解释性要求、迭代频率。根据这四个维度的强弱来推导路由选择意图覆盖率高但可解释性要求也高语义路由加大模型裁决适合客服、问答类场景实时性要求极高、意图种类固定规则路由最快毫秒级返回意图种类持续膨胀、边界模糊动态自决策最合适但要做好护栏有大量历史标注数据、线上流量大分类模型路由性价比最高多数真实项目最后会落到混合方案上。例如规则路由做第一道闸门分类模型路由处理高频意图语义路由覆盖长尾说法动态自决策只用在复杂多跳任务里。每加一层系统的鲁棒性都会往上走一点代价是链路易读性略微下降。7.3 如果从零起步我会这么选我的经验是不要一上来就铺大摊子。第一版用规则路由哪怕只有三个分支目的不是智能化而是先把数据打通。第二步等日志累积起来把所有落到兜底分支的请求捞出来人工看一遍挑出高频未覆盖的意图然后引入分类模型或语义路由。第三步再针对那些需要多跳推理、工具链调度的场景引入动态自决策。这个节奏可以帮你避免两个极端一是功力不够硬上动态路由线上错误率失控二是永远停留在规则匹配面对长尾表达手足无措。8. 路由升级过程中的四个典型问题8.1 回退链路设计不当导致死循环动态路由里常见的一个失误是模型执行失败后再次调用同一个工具来回重试三遍用户体验极差。原因很简单回退链路里没有做失败次数限制。我的做法是第一次失败可以重试一次第二次失败必须降级到兜底回复同时把这个失败事件写入日志方便后续排查。8.2 路由逻辑和上下文管理互相纠缠路由不是孤立的一层它需要读取对话历史来判断用户想干什么。比如用户上一轮刚问了成都今天多少度下一轮又追问那明天呢如果没有上下文明天就无处安放。路由层必须能把省略掉的实体从历史对话里补回来否则再好用的路由算法也会因为信息缺失而乱分流。8.3 分支间自然语言表达的重叠在语义路由里两个分支描述如果语义高度重叠就会出现每次都被分到同一个分支另一个分支形同虚设的问题。这时候要做的不是调阈值而是重新整理分支职责边界。例如天气查询和出行建议天然有重叠你得明确一个只回答气象信息一个结合气象给行动建议职责物理上分开路由才不会瞎打架。8.4 路由日志不可读等于埋雷路由跑完之后至少要记录这四个字段输入原文、命中路由方式、置信度或相似度分值、最终处理结果。否则一旦线上出问题你根本不知道它在哪一步分错了。我要求所有路由日志都能回答一个问题这句话为什么进了这个分支拿不出原因就补日志。9. 路由设计的经验心得与建议9.1 用指标而非感觉来判断路由是否需要升级很多人说要升级路由依据是感觉现在不准了。但感觉靠不住要有量化指标。我一般盯三个数落到底层兜底的比例超过两成就说明当前路由覆盖面不足高置信度预测的错误比例高于3%说明分类模型本身有问题动态路由的工具调用失败率高于5%说明功能清单或护栏设计需要调整每两周复盘一次这三个指标结合日志定位异常分支。9.2 路由不要和业务逻辑焊死我见过一个项目把路由和业务代码写在同一个文件里结果想调整一个分支条件连带要把业务执行逻辑一起重构。正确做法是路由只负责出意图标签必要的参数包执行模块根据参数包去找对应的处理器。两者之间只通过定义好的接口通信这样每一层都可以单独替换。9.3 关键参数的选型依据最后说几个我在多次迭代中总结出来的关键参数建议仅代表个人经验分类路由的置信度门槛建议在0.6到0.9之间。太高会让太多请求落到兜底太低会让误判漏过去。具体数值应该根据你业务里误判的代价来调。语义路由的相似度差值阈值建议0.03到0.08太紧会增加大模型的调用量太松会让细边界选择变得随机。动态路由的可用功能个数建议控制在十个以内功能越多模型做选择时越容易挑花眼兜底发生率反而上升。这些参数不是一次性定死的上线后要用真实日志回放来校准。我每次调整参数都会先跑一遍历史日志模拟出调整后路由会怎么分然后再放量上线。9.4 我的实践感受做了这么多路由项目我的总体感受是路由不像模型能力那样有大力出奇迹的路径它更像一个稳扎稳打的工程问题。规则太硬覆盖不全模型太软稳定性不足。真正让人舒服的路由形态往往是多层叠加的规则负责稳语义负责活动态负责智三层各管一段中间日志清晰可查。如果你正在做智能体先把路由这块想清楚再去开写循环。否则等业务场景铺开工具越来越多你一定会回来补齐这一课。但愿那时候你不需要像我一样重构三版才长记性。
1. 为什么先学路由而不是直接开写Agent循环先说个我在群里看到的高频问题很多人拿到智能体的需求第一反应是赶紧写一个大循环把大模型调用、工具执行、上下文管理全塞进一个类里。跑通是能跑通但改一个功能就得动全身最后代码变成一锅粥。我在带模拟项目X的时候反复跟成员讲智能体真正难的不是那几次大模型调用而是它内部的交通系统——也就是路由。路由决定了用户的一句话进来之后由谁处理、走哪条链路、调用哪些工具、回落到哪一层。路由设计得好后面加工具、加场景、加兜底都是往里贴砖路由设计得烂每加一个功能都是一次重构。这篇就围绕路由的四种实现方式展开。它们不是纯理论我把每种的适用场景、代码骨架、以及我在实际项目中踩过的坑都放进来。2. 从直观到工程化路由的思维演进2.1 路由到底在解决什么问题可以把智能体想象成一个前台客服中心。用户打来电话第一步是话务员判断这个人是来咨询账单还是报修故障还是想转人工。这个判断动作就是路由。放到智能体里路由的核心职责是解析用户意图判断该走哪条处理链路把请求分发到对应的大模型、技能模块或者工具组合在执行异常或意图不明时决定回落到哪一层兜底维持对话的上下文确保分流后还能把结果带回来一句话路由就是智能体的业务入口和调度中枢。它不负责具体干活但决定活怎么分。2.2 四种实现方式的整体对照先把四种方式摆在一个表里后面我再逐个拆实现方式核心机制上手成本扩展性适合场景规则匹配路由用关键词、正则或条件表达式命中分支最低一般指令明确、词表有限的垂直场景分类模型路由先做意图分类再进对应分支中较好意图边界清晰、需要独立分类能力的场景语义路由用向量相似度或大模型判断选哪个分支中高很好分支多、表达灵活、同义说法多的场景动态自决策路由由大模型基于上下文自主决定调用路径高最强工具多、链路复杂、需要临场应变的场景从规则匹配到动态自决策本质上是一条从人写规则到模型自决策的演进路线。它们不是互斥的实际项目里经常混合使用。2.3 选型不是越高级越好我在跟新手讨论时发现一个误区觉得语义路由和动态决策才像智能体规则路由显得太笨。但真实业务里规则路由的稳定性和可解释性恰恰是它最大的优势。我见过某个报表问答助手硬是靠规则路由支撑了大半年所有分支清晰可控后来加功能也都是小修小补。正确的思路是先用简单方案跑通最小闭环在运行过程中记录哪些分支容易出现误判再针对性地引入更强的路由方式。后面我会给出具体的指标判断方法。3. 第一种实现规则匹配路由3.1 它的识别逻辑规则匹配的核心是人在代码里预先定义分类依据。分类依据可以是关键词、正则表达式、情感极性、或者业务字段的组合条件。这种方式最适合意图边界非常清晰、表达方式相对固定的场景。打个比方你要做一个智能体专门帮用户查天气。用户一般会说北京今天天气怎么样上海明天会下雨吗三亚后天温度多少。这些句子虽然格式不同但核心结构都是地点时间天气意图。用规则完全可以覆盖九成以上的输入。3.2 一个极简的规则路由示例代码层面可以这样写function routeByRules(input) { const text input.trim(); // 第一层按主意图分桶 if (/天气|下雨|温度|气温|会不会降水/.test(text)) { return { branch: weather, payload: extractWeatherInfo(text) }; } if (/股票|股价|大盘|行情|涨跌/.test(text)) { return { branch: stock, payload: extractStockInfo(text) }; } if (/翻译/.test(text)) { return { branch: translate, payload: extractTranslateInfo(text) }; } // 第二层都没命中就回落兜底 return { branch: fallback, payload: { text } }; }关键在于构建规则树而非规则平铺。先按主意图分桶再在桶里做细粒度参数抽取。这样新增一个意图时只需要新增一个分支和对应的抽取逻辑不会牵动其他分支。3.3 我想重点强调的坑情绪的优先级常被忽略。用户可能说的是这天气也太热了吧这句并没有明确问天气但如果在规则层不做情感判断它就会被错误地归入天气查询。建议在规则匹配前加一个轻量级的情绪或语气识别把抱怨、调侃、反讽等非请求类输入先拦下来。正则表达式要覆盖变体例如温度多少度和多少度啊诸如此类。至少要抽象出三级变体标准式、口语式、带语气词式。规则命中的顺序会影响结果优先级最高的规则必须放在最前面。一旦命中就提前return不做无谓的后续判断。这条路最大的优点是性能好、可解释、响应稳定适合作为线上第一道防线。它的不足是遇到没见过的说法就失效所以需要搭配兜底逻辑。4. 第二种实现分类模型路由4.1 给意图构建一个轻量分类器分类模型路由的核心是训练一个专门的意图分类器先分类再执行。它和规则匹配最大的区别在于规则匹配是人写死判断条件分类模型是从标注样本里学习模式。它的典型结构是收集历史对话或模拟对话标注出意图标签如weather、stock、greeting、complaint用样本微调一个轻量分类模型例如基于BERT的小模型或直接调用现成的分类服务推理时先把用户输入送入分类器得到意图分布再根据置信度路由到对应分支4.2 置信度门槛是关键设计点分类模型不是输出一个标签就完了工程上要给它加置信度门槛。我以 0.9作为高置信、直接进对应分支低于0.9但高于0.6的进入确认分支由大模型进一步追问用户低于0.6的全部落到兜底。这个策略把很多原本会误判的输入都挡在了错误分支之外。def classify_and_route(user_text): intent, confidence classify(user_text) if intent weather and confidence 0.9: return handle_weather(user_text) if confidence 0.6: return ask_for_clarification(intent, confidence) return handle_fallback(user_text)很多失败的分类路由项目问题不在模型精度本身而在没有设置确认门槛。覆盖率高的代价必然是误判率也高把低置信度样本直接送进业务分支会污染下游上下文。4.3 什么时候值得上分类模型我个人的判断标准是意图种类在4个以上且表达方式有持续变化规则匹配的未命中率超过两成且兜底逻辑吃掉了大量真实请求业务上能够抽出几百条意图样本用于微调且具备持续标注的机制一旦满足这三条分类模型路由就能显著优于纯规则。4.4 我在项目里遇到的覆盖陷阱有一次我们在做模拟项目X的意图分类时训练集里全是标准问法比如今天天气如何明天成都冷不冷。一到线上用户输入变成这鬼天气热死我了开车过去会不会淋雨分类器全乱了。后来我们把线上积累的真实句子定期回流到标注池发现用户问天气的花样比想象中多得多。再后来我们干脆做了一个双通道方案分类模型处理明确意图规则路由处理强指令类请求两条路并行谁置信度高听谁的。这个结构帮我解决了很多模糊表达的问题。5. 第三种实现语义路由5.1 让分布式的语义兜住灵活的提问语义路由的思路是每个分支都有一个代表性的语义描述用户输入进来后计算它们之间的语义相似度选最接近的分支。实现方案主要有三种用通用向量模型如文本嵌入模型对用户输入和分支描述分别编码算余弦相似度用大模型直接判断以下哪个分支更符合这句话适合分支数量少但语义复杂的场景混合法向量召回若干个候选分支再交给大模型做精细挑选在项目里我常常把第三种作为默认方案。向量负责粗筛大模型负责精判既控制成本又保证准确。5.2 分支描述的写法决定了路由质量好的分支描述要能覆盖提问的变体。举个反例如果你把天气分支的描述写成用户问天气情况那实际提问明天出门要带伞吗相似度就会偏低如果你把它扩展到用户询问天气、降水、温度、风力、紫外线、出游是否需要带伞或加衣服覆盖面就大得多。branch_descriptions { weather: 用户询问天气、气温、降水概率、风力、紫外线强度、出行是否需要带伞或增减衣物, stock: 用户询问股票价格、大盘指数、个股涨跌、行情走势、持仓盈亏, translate: 用户请求把某种语言翻译成另一种语言或询问某个词句的外语说法, }分支描述建议每季度做一次回流优化把线上积累的高频说法补充进去。5.3 语义路由的坑别只看余弦相似度我见过不少同学兴致勃勃地搭建了语义路由上线后发现调用大模型的次数反而变多了。原因是相似度是相对接近不是绝对正确。比如今天有什么热门电影这个提问可能在entertainment分支和general分支之间只有微弱差异。如果只看余弦相似度很容易选错。所以语义路由的配套机制是相似度前三名都保留下来如果第一名和第二名的分值差距小于某个阈值比如0.05就交由大模型做二选一判定。这既保留了语义泛化的优势又避免了细边界上的随机选择。另外要注意的是语义路由的稳定性很大程度上依赖向量模型的质量。不要为了省成本选一个明显偏弱的模型它在同义词、否定句、反讽句上都会掉链子最后害得下游排查成本更高。5.4 一个值得尝试的混合判断样例在模拟项目X的某个模块里我做了这样的混合设计候选集从所有分支的语义描述中生成向量索引用户输入向量化后做ANN检索召回Top3若Top1分值与Top2差距小于阈值由大模型根据Top3候选做最终裁决裁决结果落到分支执行器这个方案在离线测试里把路由准确率从单用向量的82%提到了93.5%在线体验也更稳定。关键是第3步只消耗极少的大模型token成本完全可控。6. 第四种实现动态自决策路由6.1 路由权交给大模型但要给它边界动态自决策路由是目前很多新一代智能体采用的方式。它的本质是不在代码里显式写去哪条分支而是由大模型根据用户意图、当前上下文、可用工具列表自己决定调用哪个工具、执行哪条链路。它的核心组件有三个功能清单、决策提示词、执行回退机制。功能清单必须写得足够清晰包含每个功能的名字、用途、参数说明、使用条件。大模型靠这份清单来认识它能做什么。决策提示词则描述决策原则比如必须先明确时间、地点、主体再调用对应工具如果信息不足先追问不要瞎猜。执行回退机制负责兜底——当大模型选不出合适分支时或者执行分支返回异常时要有降级路径。6.2 一份动态路由的最小实现思路functions [ { name: query_weather, description: 查询指定城市在指定日期的天气。适用于用户询问气温、降水、风力、空气质量, parameters: {city: string, date: string} }, { name: query_stock, description: 查询指定股票代码的行情数据。适用于用户询问股价、涨跌幅、成交量, parameters: {code: string} } ] decision_prompt 根据用户需求从可用功能中选出最合适的调用方式。 如果用户没有提供必要参数请用追问的方式补充信息。 如果用户需求无法被任何功能覆盖不要强行调用请输出无法处理并解释原因。 def dynamic_route(user_input, context): response llm.chat_with_tools( promptdecision_prompt, functionsfunctions, user_inputuser_input, contextcontext ) return response.tool_calls这里最关键的是必要参数缺省时先追问否则大模型会拿错误参数去调工具得到一堆无意义的结果。6.3 动态路由的安全护栏设计动态路由看似聪明但如果完全没有护栏它会做出让人匪夷所思的事情。我在实测中发现过大模型把明天上海冷不冷解读成获取上海未来15天温度曲线并调用了一个重量级数据分析工具白白浪费了几分钟的计算资源。所以护栏必须包含三件事功能权重控制默认只开放十个以内的核心功能其余功能需要用户在对话中主动确认才允许启用。这就防止了模型在模糊场景下随意启用重工具。参数泄漏拦截用户输入中与功能参数无关的内容不允许传入工具。例如用户问天气附带了一段无关闲聊动态路由只能提取城市、日期进工具其余内容留在上下文。执行结果校验工具返回异常或空数据时模型必须将该工具执行失败反馈给用户而不是尝试用另一个工具猜测结果。如果让大模型完全自由地选择工具链大概率会出现不可控的联动调用这是动态路由在工程化过程中的第一道大坎。6.4 大模型幻觉引发的路由偏航还有个必须注意的地方动态自决策比前三种方式更容易被大模型的幻觉带偏。模型有时会在工具调用里编造一个并不存在的参数名或者把同一个意图拆成两次调用。要解决这个问题除了在提示词里明确约束任务清单还要在代码层做参数校验——凡是工具定义里不存在的参数一律拒绝调用。我习惯在动态路由目标下游再加一层参数白名单校验哪怕模型多返回了一个多余字段也会拦截。这样既能享受动态路由的灵活性又不会因为幻觉污染了工具执行的质量。7. 四种路由的实战串讲与选型判断7.1 同一句话在四种路由下的不同表现我拿预约下周二下午三点的会议室这句话看看四种方式各自怎么处理路由方式处理表现可能的问题规则路由命中会议室预约下周二等关键词进入预定分支下周二的语义解析需要额外NLP分类路由分类为meeting_booking进入预定流程需要足够的训练样本覆盖这个意图语义路由通过向量匹配找到会议预定分支如果没有描述好容易和日程查询混淆动态自决策模型自动列出预定会议所需的日期、时间、成员并调用预定工具也可能多问一句几个人参加会议增加了一次追问轮次同样一句话四种路由在表达能力、成本和稳定性上的表现完全不同。没有绝对的最好只有和你的业务约束最匹配的那一种。7.2 业务约束与路由选择的匹配矩阵我们可以把业务约束归纳成四个维度意图覆盖率要求、实时性要求、可解释性要求、迭代频率。根据这四个维度的强弱来推导路由选择意图覆盖率高但可解释性要求也高语义路由加大模型裁决适合客服、问答类场景实时性要求极高、意图种类固定规则路由最快毫秒级返回意图种类持续膨胀、边界模糊动态自决策最合适但要做好护栏有大量历史标注数据、线上流量大分类模型路由性价比最高多数真实项目最后会落到混合方案上。例如规则路由做第一道闸门分类模型路由处理高频意图语义路由覆盖长尾说法动态自决策只用在复杂多跳任务里。每加一层系统的鲁棒性都会往上走一点代价是链路易读性略微下降。7.3 如果从零起步我会这么选我的经验是不要一上来就铺大摊子。第一版用规则路由哪怕只有三个分支目的不是智能化而是先把数据打通。第二步等日志累积起来把所有落到兜底分支的请求捞出来人工看一遍挑出高频未覆盖的意图然后引入分类模型或语义路由。第三步再针对那些需要多跳推理、工具链调度的场景引入动态自决策。这个节奏可以帮你避免两个极端一是功力不够硬上动态路由线上错误率失控二是永远停留在规则匹配面对长尾表达手足无措。8. 路由升级过程中的四个典型问题8.1 回退链路设计不当导致死循环动态路由里常见的一个失误是模型执行失败后再次调用同一个工具来回重试三遍用户体验极差。原因很简单回退链路里没有做失败次数限制。我的做法是第一次失败可以重试一次第二次失败必须降级到兜底回复同时把这个失败事件写入日志方便后续排查。8.2 路由逻辑和上下文管理互相纠缠路由不是孤立的一层它需要读取对话历史来判断用户想干什么。比如用户上一轮刚问了成都今天多少度下一轮又追问那明天呢如果没有上下文明天就无处安放。路由层必须能把省略掉的实体从历史对话里补回来否则再好用的路由算法也会因为信息缺失而乱分流。8.3 分支间自然语言表达的重叠在语义路由里两个分支描述如果语义高度重叠就会出现每次都被分到同一个分支另一个分支形同虚设的问题。这时候要做的不是调阈值而是重新整理分支职责边界。例如天气查询和出行建议天然有重叠你得明确一个只回答气象信息一个结合气象给行动建议职责物理上分开路由才不会瞎打架。8.4 路由日志不可读等于埋雷路由跑完之后至少要记录这四个字段输入原文、命中路由方式、置信度或相似度分值、最终处理结果。否则一旦线上出问题你根本不知道它在哪一步分错了。我要求所有路由日志都能回答一个问题这句话为什么进了这个分支拿不出原因就补日志。9. 路由设计的经验心得与建议9.1 用指标而非感觉来判断路由是否需要升级很多人说要升级路由依据是感觉现在不准了。但感觉靠不住要有量化指标。我一般盯三个数落到底层兜底的比例超过两成就说明当前路由覆盖面不足高置信度预测的错误比例高于3%说明分类模型本身有问题动态路由的工具调用失败率高于5%说明功能清单或护栏设计需要调整每两周复盘一次这三个指标结合日志定位异常分支。9.2 路由不要和业务逻辑焊死我见过一个项目把路由和业务代码写在同一个文件里结果想调整一个分支条件连带要把业务执行逻辑一起重构。正确做法是路由只负责出意图标签必要的参数包执行模块根据参数包去找对应的处理器。两者之间只通过定义好的接口通信这样每一层都可以单独替换。9.3 关键参数的选型依据最后说几个我在多次迭代中总结出来的关键参数建议仅代表个人经验分类路由的置信度门槛建议在0.6到0.9之间。太高会让太多请求落到兜底太低会让误判漏过去。具体数值应该根据你业务里误判的代价来调。语义路由的相似度差值阈值建议0.03到0.08太紧会增加大模型的调用量太松会让细边界选择变得随机。动态路由的可用功能个数建议控制在十个以内功能越多模型做选择时越容易挑花眼兜底发生率反而上升。这些参数不是一次性定死的上线后要用真实日志回放来校准。我每次调整参数都会先跑一遍历史日志模拟出调整后路由会怎么分然后再放量上线。9.4 我的实践感受做了这么多路由项目我的总体感受是路由不像模型能力那样有大力出奇迹的路径它更像一个稳扎稳打的工程问题。规则太硬覆盖不全模型太软稳定性不足。真正让人舒服的路由形态往往是多层叠加的规则负责稳语义负责活动态负责智三层各管一段中间日志清晰可查。如果你正在做智能体先把路由这块想清楚再去开写循环。否则等业务场景铺开工具越来越多你一定会回来补齐这一课。但愿那时候你不需要像我一样重构三版才长记性。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
