先讲一个我真实经历过的情况。某智能客服项目一开始只接了一个高配大模型，所有提问、总结、信息抽取全部走同一个接口。结果月底对账的时候，负责人差点以为计费系统出了问题：光模型调用费一项，就比服务器成本高了将近五倍。更尴尬的是，简单问题回答得又慢又啰嗦，复杂问题反而经常漏关键信息。后来我把这套系统改成“按请求分流”——也就是给不同任务分配不同规格的模型——费用立刻降了一大截，整体回复质量反而更稳定了。这个分流机制，在圈里通常被称为智能体路由（Agent Routing）。这篇内容就是想把这个机制讲透：为什么单体模型撑不住真实业务、路由到底在决策什么、主流的几种路由机制各自适合什么场景、怎么搭一条能落地的路由链路，以及接入之后会遇到哪些坑。适合正在做大模型应用、智能体产品，或者已经在用单一模型但成本和效果双双失控的开发者参考。下面全部是我实际操作中的经验，尽量少讲虚的。1. 单体模型的“大而全”迷思：什么时候你会真正需要路由1.1 请求长尾分布下的成本失控真实业务里的请求分布从来不是均匀的，而是典型的长尾分布。以我接触过的某内容社区项目为例，每天的模型请求里，大约七成是“这篇文章讲了什么”“帮我翻译这句话”这类简单任务，两成是中等复杂度的信息整理任务，真正需要深度推理、多步规划的高难请求可能只占一成左右。如果所有请求都调用同一个高配模型，那七成简单任务就变成了纯浪费：每多一次调用都在烧钱，但产出和轻量模型几乎没差别。这是个非常要命的隐性浪费，因为它不会在功能测试里暴露，只在月底账单里爆发。我在另一个项目里做过一个粗略测算。假设每天有1万次请求：7000次简单请求，若全部走高配模型，每次约消耗3000个token的输入加500个token的输出；若这些请求能被一个成本只有高配模型十分之一的轻量模型接住，光这一层就能砍掉一大半调用费用；省下的预算还可以匀给那10%的高难请求，升级成更强的推理链路。这就是路由机制最直接的价值：把资源花在真正需要的地方。1.2 复杂任务与简单任务混跑时的质量稀释成本只是其中一个问题，另一个更隐蔽的问题是质量稀释。同一个模型面对简单任务和复杂任务时的表现是不一样的，而当混合请求共享同一套上下文、同一个提示词模板时，这种不一致会被放大。举个例子。客服场景里，“订单号是多少，帮我查物流”和“根据这几页退货政策，判断我这种情况能不能全额退款”是完全不同性质的任务。前者只需要关键词抽取和格式化输出，后者需要逻辑推理、条款比对和可能的多轮澄清。如果两者共用一套提示词和模型，要么简单任务响应过于啰嗦，要么复杂任务因为上下文被压缩而表现浮躁。我当时的判断标准很简单：当一个系统里“简单任务的失败率”和“复杂任务的失败率”同时上升，且两者用了同一个模型时，就是该拆的时候。智能体路由的本质，是把不同复杂度的需求从同一根管道里拆开，让每个任务去匹配合适能力的模型。2. 智能体路由决策什么：任务特征、模型能力与约束条件的三方匹配2.1 路由对象是“任务”而不是“用户”很多人容易犯一个直觉错误：按用户来分模型。比如“付费用户走强模型，免费用户走弱模型”。这种策略看起来合理，但真实场景里同一个用户往往是多面的——他可能上午问一个简单天气问题，下午问一个复杂的法律纠纷问题。如果按用户身份一刀切，简单问题被浪费了预算，复杂问题又得不到足够的模型能力。所以路由的对象应该是单个任务（一次请求），而不是一个用户或会话。在我实现的系统里，每个请求进入时都携带一个任务特征向量，路由层根据这个向量的内容来决定去哪个模型，而不是看请求来自谁。这个思想一旦扭转过来，路由设计的思路就清晰了。2.2 我常用的五个路由特征信号在实践里，我主要会抽取以下五类特征作为路由决策的依据：特征信号说明示例意图类别请求属于哪个业务域售后、物流、商品咨询、闲聊输入复杂度文本长度、实体数量、是否包含多步指令一句话提问 vs 长文档分析领域专业性是否涉及专业术语、合规条款、医学金融等“退换货政策” vs “量子计算原理”输出结构要求需要纯文本、JSON、表格还是代码自由回答 vs 结构化接口约束条件延迟上限、成本预算、是否必须可解释实时客服要求2秒内返回这五类特征不用全部参与每次决策，大多数情况只需要两到三个。关键是要先搞清楚：你的系统最在意什么约束？如果是客服，延迟和成本优先；如果是科研分析，准确率和推理深度优先。路由策略不是越复杂越好，而是要贴合业务的最大痛点。2.3 从“选最强”到“选够用但便宜”的思维转换我见过不少团队在设计路由时会把问题想成“哪个模型最强就选哪个”，这其实等于没做路由。真实做法应该是建立一个候选模型池，给每个模型标注能力画像，比如适合处理对话类任务、适合代码生成、适合长文档摘要、响应速度快但复杂推理能力弱等。路由要做的不是选择“最强”，而是选择“最匹配且经济”。这个概念就像一个运输调度中心，不会让所有货物都上飞机，也不会让所有货物都走海运，而是根据时效、体积、成本来安排不同的运输方式。模型选择也是一样，匹配永远比强弱重要。3. 主流路由机制拆解：从规则到强化学习，各自的算盘和天花板3.1 规则路由：白名单式分流的简单与脆弱规则路由是最朴素也最容易落地的一种。它的实现方式就是维护一组关键词、正则表达式或逻辑判断，命中某个规则就将请求分流到对应模型。def rule_based_route(req): text = req["text"] if "退货" in text or "退款" in text: return {"route": "after_sale", "model": "high_domain_model", "reason": "rule_after_sale"} if "物流" in text or "订单号" in text: return {"route": "logistics", "model": "low_cost_fast_model", "reason": "rule_logistics"} return {"route": "unknown", "model": None, "reason": "no_rule_match"}规则路由的优势是可解释性极强，出问题可以直接追到某条规则，线上排查容易，响应时间也几乎没有额外开销。缺点是脆弱，一旦用户换一种说法，或者业务场景引入新词，规则就失效了。我在早期项目里吃过不少亏，靠关键词很难覆盖口语化表达的多样性。所以我的建议是：规则路由适合做第一步粗筛，过滤掉那些意图极其明确、覆盖度极高的任务，而不是指望它解决所有分流问题。3.2 语义路由：用向量相似度做冷启动分类语义路由是我用得最多的一种方式。它的核心思路是把用户请求用嵌入模型转成向量，然后和一批“代表性样本向量”做相似度对比，取最接近的类别作为路由结果。这里有三个关键点：需要有一个嵌入模型，把文本映射成高维向量；需要给每个路由目标准备若干条典型样本，比如“商品咨询”这个类目下准备几十条真实用户怎么问这类问题的例句；相似度计算通常用余弦相似度，阈值需要根据验证集调。这个方案的优点是不需要标注大量数据就能冷启动——准备每个类别二三十条样本即可，并且对用户的自然表达有很好的容忍度。缺点是需要额外部署嵌入模型，而且对阈值很敏感。阈值设得太严，大量请求会落入“unknown”走兜底；阈值设得太松，误分类又会拉低下游质量。我在客户项目里针对“售后咨询”“商品咨询”“闲聊”三类各准备了30条样本，用开源嵌入模型做向量化。实测下来，对于超过0.82相似度的请求，分类准确率大约有九成以上，已经足够支撑生产环境的第一层分流。3.3 分类器路由：小模型的性价比与误判代价如果语义路由满足不了你，可以考虑训练一个轻量级分类器，比如基于几万条已标注历史请求训练一个小型文本分类模型。它的推理开销远低于大模型，且分类精度通常比纯向量相似度更高，因为它是专门针对你业务场景优化过的。不过分类器也需要付出代价：第一，必须积累一定量的历史标注数据，冷启动阶段很难用；第二，分类器只能判断意图类别，对“任务复杂度”“输出格式要求”这类连续特征帮助有限；第三，模型更新和迭代需要一套数据回流流程，维护成本比规则和语义路由都高。我的经验是分类器适合在半稳定业务中使用——业务方向不会频繁变化时，花两周时间训一个专用分类器，性价比是很高的。3.4 LLM自评价路由：让模型给自己的任务“选路”还有一种非常灵活但成本也高的思路：把“该走哪条路由”这个问题本身交给一个高能力模型来判断。你可以把用户请求和所有候选模型的能力描述拼接成一个提示词，让模型输出“该由哪个模型处理”。def llm_judge_route(req, candidate_models): prompt = f""" 这是一个用户请求：{req['text']} 以下是可选模型及擅长能力： - 模型A：快速响应，擅长简单对话，成本低 - 模型B：擅长复杂推理和多步分析，成本高 请选择最合适的模型，只输出模型名。 """ result = call_llm(prompt) return {"route": result.strip(), "model": result.strip()}这种“用模型做路由”的方式非常灵活，对新出现的任务类型适应能力强，而且可以让LLM同时考虑成本、延迟和复杂度。缺点是三个：一是每次路由决策都多一次模型调用，额外的时延和成本不可忽视；二是LLM的决策不够稳定，同一个请求可能被路由到不同模型，线上行为不可预测；三是如果这个LLM自身能力不够，就会成为一个新的瓶颈。所以我通常只把LLM自评价路由用在规则和语义都无法判定的“残余流量”上，而不是让它做全量路由。3.5 分层组合路由：生产环境的常态说完上面四种，你应该能感觉到：没有哪一种机制是万能的。生产环境里真正起作用的，往往是它们的组合。我把这种组合叫做“漏斗式路由”：先走最快的规则层，筛掉明确任务；再走语义层，覆盖大部分模糊表达；最后走LLM裁判层，处理少数疑难请求。分层的好处是每一层只需要承担一小部分流量，整体延迟可控，成本也不会失控。后面我会给出一个完整的三层路由落地案例。下面是五种机制的综合对比，方便你做选型参考：路由机制落地成本路由时延可解释性冷启动能力适合场景规则路由极低极低极强无需数据意图明确的高频任务粗筛语义路由中低低中每类几十条样本即可对话、FAQ、意图漂移明显的场景分类器路由较高低中需要大量标注数据业务稳定、样本充足的场景LLM自评价路由高高弱无需训练数据疑难残余流量的兜底分层组合路由中中中各层互补生产环境推荐4. 一次完整的智能体路由链路：从请求进来到响应回去要经过什么4.1 路由入口：先把所有请求变成同一种“语言”很多路由系统失败，不是因为路由算法不行，而是入口的数据结构太混乱。不同渠道进来的请求，有的是JSON，有的是纯文本，有的带着HTML标签，有的把多个问题塞在同一个字段里。如果不做规范化，路由层根本没法稳定抽取特征。我在项目里会在路由层之前加一道“请求规范化”处理，把所有渠道的请求统一成一个标准结构：@dataclass class NormalizedRequest: request_id: str text: str source: str user_id: str extra_meta: dict = None这一步看似简单，却能规避大量后续问题。请求ID用于全链路追踪，text是路由决策的主输入，source用于分析不同渠道的分流差异。没有这个统一结构，后面什么特征抽取、日志回放都无从谈起。4.2 决策层：特征打分与路径选择的实操计算规范化之后进入决策层。我会基于项目目标构造一个打分函数，把模型选择转化为一个带约束的最优化问题，而不是靠感觉拍板。假设有三个候选模型，分别代表高配、中配、轻量。我给每个模型定义一个能力值（0到1）和成本值（每次调用的相对成本），路由决策就是让“质量收益”和“成本代价”的加权和最大。用一个简化的打分公式来解释，核心思想是：对于高复杂度任务，质量收益的权重调高；对于低复杂度任务，成本代价的权重调高；对于高延迟敏感任务，额外加入延迟惩罚项。这个打分过程在代码层面其实就是一个映射表加加权计算，并不复杂。难的是确定权重：要拿历史数据回归一遍，或者通过AB实验迭代。我之前第一次做的时候把权重拍得太主观，导致路由结果完全偏离预期，后来老老实实抽样标注了几百条历史请求，才把权重调到了一个合理范围。4.3 执行层：并行探测、超时与降级策略路由决策完成后，接下来就是真正的模型调用。执行层有一个常见陷阱：为了“保险”，把所有请求都串行等待主模型返回，一旦主模型超时，整个链路就失败。我认为比较稳的做法是给每个模型调用设置独立的超时时间，并准备降级路径。比如目标是调用高配模型做复杂推理，但高配模型超时，可以降级到中配模型用简化提示词重试一次；如果中配也失败，再走预设的兜底回复模板。降级路径至少要有两条，不然路由系统自己会成为新的单点故障。另外，对某些置信度不高的路由决策，还可以使用一种“并行探测”技巧：同时把请求发给轻量模型和规则处理模块，哪个先返回可靠结果就用哪个。这在大促或高峰期很有用，能有效降低响应延迟，但成本会有所上升，需要根据场景权衡。4.4 观测层：让路由决策随时可回溯我特别想强调观测层的重要性。很多团队把路由搭完就上线，出问题时完全不知道请求当初被路由到了哪里，也不知道是路由错了还是下游模型错了。这会让排错变成灾难。我的做法是路由层必须打印完整的决策日志，至少包含以下字段：请求ID；路由目标模型；命中规则或相似度得分；各候选模型的打分明细；实际调用耗时与返回状态。有了这份日志，当用户反馈某个回答不对时，我可以立刻定位到是路由误判，还是下游模型本身能力不足。没有观测层，你连自己错在哪都不知道，这是做路由系统的大忌。5. 落地到某智能客服项目的全过程复盘5.1 项目现状与路由改造的目标这个项目是典型的电商智能客服场景，日请求量大约两万次，原本所有请求都调用同一套高配模型。改造前的情况几乎可以写进反面教材：预算曲线陡增，简单问题响应慢，复杂问题又处理不好。当时定的改造目标有三个：整体成本下降百分之五十以上；简单问题平均响应时间压到两秒以内；复杂问题的有效解决率不能下降。5.2 三层路由的搭建与参数配置针对这个项目，我采用的就是前面提到的三层漏斗结构。第一层是规则层，拦截那些关键词极其明确的请求，比如包含“订单号”的查单请求、包含规格参数的比价请求。这一层覆盖了约四成流量，路由到轻量快速模型，单次调用成本很低。第二层是语义层，针对售后、商品咨询、物流查询、闲聊四类常见意图各准备了三十条典型样本，用嵌入模型实时计算相似度。相似度超过0.82的请求，按对应意图路由到中配模型。这一层再覆盖接近三成流量。第三层是残余流量处理，用LLM裁判模型做兜底。剩余的未知意图请求进入这层，由高能力模型综合判断该走哪条路径。三层之间的衔接代码大概是这样的：def hybrid_route(req, sample_vectors): first = rule_based_route(req) if first["route"] != "unknown": return first vec = embed(req["text"]) matched = find_best_match(vec, sample_vectors) if matched.similarity >= 0.82: return { "route": matched.route, "model": model_for_route(matched.route), "score": matched.similarity, } judge = llm_judge_route(req, candidate_models) return {"route": judge.route, "model": judge.model, "score": -1}5.3 路由前后的成本与质量对照为了让大家对这个机制的效果有直观感受，我把那个项目改造前后的数据整理成了下表。数据带有一定项目特性，仅供趋势参考，但方向和量级是真实可信的。指标单模型方案三层路由方案变化日均调用成本约3000元约800元下降约73%简单问题平均响应约6秒约1.5秒提升明显复杂问题有效解决率88%92%上升4个百分点路由决策额外时延0ms约80ms可控兜底人工介入率5%3.2%下降有一点要说明：成本下降的最大来源不只是把简单任务切给了轻量模型，还包括“复杂问题路由到高配模型后，一次解决率提高，减少了重复提问次数”。后者常常被忽略，但它很惊人。5.4 第一版路由踩过的两个典型坑第一版上线的时候，我犯了两个典型的错误。第一个错误是规则层做得太激进。当时为了降成本，我把“退”“换”这类单字都定义为售后规则，结果“我想换个说法”这种非售后请求也被拦下来扔进售后模型，导致大量误分类。后来我把规则条件从“是否包含某词”改成了“是否同时包含两个以上强信号词”，误判率才降下来。第二个错误是忽略了语义层的灰度验证。新路由上线后，我没有做小流量对比就直接全量切换，结果某个深夜语义层突然把一批“询问营业时间”的请求判定为“闲聊”，引发的线上投诉花了两天才消化掉。后来所有语义层的阈值调整都必须在测试集上跑一遍，并且按5%、20%、50%的比例灰度放量，再也没出现过类似的事故。6. 路由长期稳定运行的三张“安全网”6.1 回流样本动态更新路由样本库路由系统上线只是开始，真正的挑战是“它会慢慢变钝”。用户语言在不断变化，业务活动会带来新的说法、新的产品名、新的活动词。如果语义层的样本库不更新，三个月后相似度匹配的准确率会肉眼可见地下降。我现在的做法是每天定时拉取路由日志，筛选那些相似度介于0.6到0.82之间、最终被LLM兜底处理的请求，抽样人工标注后补充到对应类别的样本库中。每个类别每周新增五到十条典型样本，持续迭代。这个动作看起来不酷，但它是路由效果能长期保持稳定的核心。6.2 模型能力变化后的路由重新校准还有一个很容易被遗忘的风险：模型本身会更新。很多团队在路由系统里写死了某个模型的能力描述，比如“模型B擅长复杂推理”，但几个月后模型B发布新版本，可能复杂推理能力更强，成本却变了，或者推理风格发生了变化。路由决策依据如果还是老信息，系统就会在不知不觉中降级。我的建议是每季度做一次模型能力复测，拿一组固定的标准问题集重新验证所有候选模型，根据结果更新模型能力画像和路由权重。这个复测可以自动化，并不费多少人力，但能避免很多难以排查的线上劣化。6.3 请求失败的兜底与人工重放机制最后一张安全网是请求失败后的处理。路由系统接的模型越多，可能的失败点就越多。超时、限流、内容格式异常、下游服务不可用，每一种失败都应该有对应的降级动作。我会为每个路由目标预设一个最低可接受模型，比如高配模型挂了可以降级到中配模型，中配模型挂了可以降级到轻量模型加简化提示词。如果所有模型都不可用，还需要一个模板回复兜底，并接入人工坐席。等系统恢复后，再把失败请求按照原路由路径重新处理一遍，避免用户问题被悄悄丢弃。这套兜底机制一度在一个大促场景里救了我：那次高配模型服务短时抖动，外部调用大面积超时，系统自动把高复杂度请求降级到了中配模型，虽然回答深度有所下降，但至少没有中断服务，也没有出现大规模用户投诉。要知道，在那种流量下，哪怕中断十分钟都是事故。我个人在做了几个带路由的智能体项目以后，最大的体会是：路由不是一个“选个模型”的动作，而是一整套围绕任务分配、成本控制、质量保障的工程体系。如果你刚开始接触，不要急着上复杂的分类器或LLM裁判，先把规则层和语义层搭起来，跑两到四周，看看日志里的数据分布，再逐步增加兜底机制和动态更新。先能跑，再跑稳，最后再优化——这个顺序能让你的路由系统越用越顺手，而不是越维护越吃力。
先讲一个我真实经历过的情况。某智能客服项目一开始只接了一个高配大模型，所有提问、总结、信息抽取全部走同一个接口。结果月底对账的时候，负责人差点以为计费系统出了问题：光模型调用费一项，就比服务器成本高了将近五倍。更尴尬的是，简单问题回答得又慢又啰嗦，复杂问题反而经常漏关键信息。后来我把这套系统改成“按请求分流”——也就是给不同任务分配不同规格的模型——费用立刻降了一大截，整体回复质量反而更稳定了。这个分流机制，在圈里通常被称为智能体路由（Agent Routing）。这篇内容就是想把这个机制讲透：为什么单体模型撑不住真实业务、路由到底在决策什么、主流的几种路由机制各自适合什么场景、怎么搭一条能落地的路由链路，以及接入之后会遇到哪些坑。适合正在做大模型应用、智能体产品，或者已经在用单一模型但成本和效果双双失控的开发者参考。下面全部是我实际操作中的经验，尽量少讲虚的。1. 单体模型的“大而全”迷思：什么时候你会真正需要路由1.1 请求长尾分布下的成本失控真实业务里的请求分布从来不是均匀的，而是典型的长尾分布。以我接触过的某内容社区项目为例，每天的模型请求里，大约七成是“这篇文章讲了什么”“帮我翻译这句话”这类简单任务，两成是中等复杂度的信息整理任务，真正需要深度推理、多步规划的高难请求可能只占一成左右。如果所有请求都调用同一个高配模型，那七成简单任务就变成了纯浪费：每多一次调用都在烧钱，但产出和轻量模型几乎没差别。这是个非常要命的隐性浪费，因为它不会在功能测试里暴露，只在月底账单里爆发。我在另一个项目里做过一个粗略测算。假设每天有1万次请求：7000次简单请求，若全部走高配模型，每次约消耗3000个token的输入加500个token的输出；若这些请求能被一个成本只有高配模型十分之一的轻量模型接住，光这一层就能砍掉一大半调用费用；省下的预算还可以匀给那10%的高难请求，升级成更强的推理链路。这就是路由机制最直接的价值：把资源花在真正需要的地方。1.2 复杂任务与简单任务混跑时的质量稀释成本只是其中一个问题，另一个更隐蔽的问题是质量稀释。同一个模型面对简单任务和复杂任务时的表现是不一样的，而当混合请求共享同一套上下文、同一个提示词模板时，这种不一致会被放大。举个例子。客服场景里，“订单号是多少，帮我查物流”和“根据这几页退货政策，判断我这种情况能不能全额退款”是完全不同性质的任务。前者只需要关键词抽取和格式化输出，后者需要逻辑推理、条款比对和可能的多轮澄清。如果两者共用一套提示词和模型，要么简单任务响应过于啰嗦，要么复杂任务因为上下文被压缩而表现浮躁。我当时的判断标准很简单：当一个系统里“简单任务的失败率”和“复杂任务的失败率”同时上升，且两者用了同一个模型时，就是该拆的时候。智能体路由的本质，是把不同复杂度的需求从同一根管道里拆开，让每个任务去匹配合适能力的模型。2. 智能体路由决策什么：任务特征、模型能力与约束条件的三方匹配2.1 路由对象是“任务”而不是“用户”很多人容易犯一个直觉错误：按用户来分模型。比如“付费用户走强模型，免费用户走弱模型”。这种策略看起来合理，但真实场景里同一个用户往往是多面的——他可能上午问一个简单天气问题，下午问一个复杂的法律纠纷问题。如果按用户身份一刀切，简单问题被浪费了预算，复杂问题又得不到足够的模型能力。所以路由的对象应该是单个任务（一次请求），而不是一个用户或会话。在我实现的系统里，每个请求进入时都携带一个任务特征向量，路由层根据这个向量的内容来决定去哪个模型，而不是看请求来自谁。这个思想一旦扭转过来，路由设计的思路就清晰了。2.2 我常用的五个路由特征信号在实践里，我主要会抽取以下五类特征作为路由决策的依据：特征信号说明示例意图类别请求属于哪个业务域售后、物流、商品咨询、闲聊输入复杂度文本长度、实体数量、是否包含多步指令一句话提问 vs 长文档分析领域专业性是否涉及专业术语、合规条款、医学金融等“退换货政策” vs “量子计算原理”输出结构要求需要纯文本、JSON、表格还是代码自由回答 vs 结构化接口约束条件延迟上限、成本预算、是否必须可解释实时客服要求2秒内返回这五类特征不用全部参与每次决策，大多数情况只需要两到三个。关键是要先搞清楚：你的系统最在意什么约束？如果是客服，延迟和成本优先；如果是科研分析，准确率和推理深度优先。路由策略不是越复杂越好，而是要贴合业务的最大痛点。2.3 从“选最强”到“选够用但便宜”的思维转换我见过不少团队在设计路由时会把问题想成“哪个模型最强就选哪个”，这其实等于没做路由。真实做法应该是建立一个候选模型池，给每个模型标注能力画像，比如适合处理对话类任务、适合代码生成、适合长文档摘要、响应速度快但复杂推理能力弱等。路由要做的不是选择“最强”，而是选择“最匹配且经济”。这个概念就像一个运输调度中心，不会让所有货物都上飞机，也不会让所有货物都走海运，而是根据时效、体积、成本来安排不同的运输方式。模型选择也是一样，匹配永远比强弱重要。3. 主流路由机制拆解：从规则到强化学习，各自的算盘和天花板3.1 规则路由：白名单式分流的简单与脆弱规则路由是最朴素也最容易落地的一种。它的实现方式就是维护一组关键词、正则表达式或逻辑判断，命中某个规则就将请求分流到对应模型。def rule_based_route(req): text = req["text"] if "退货" in text or "退款" in text: return {"route": "after_sale", "model": "high_domain_model", "reason": "rule_after_sale"} if "物流" in text or "订单号" in text: return {"route": "logistics", "model": "low_cost_fast_model", "reason": "rule_logistics"} return {"route": "unknown", "model": None, "reason": "no_rule_match"}规则路由的优势是可解释性极强，出问题可以直接追到某条规则，线上排查容易，响应时间也几乎没有额外开销。缺点是脆弱，一旦用户换一种说法，或者业务场景引入新词，规则就失效了。我在早期项目里吃过不少亏，靠关键词很难覆盖口语化表达的多样性。所以我的建议是：规则路由适合做第一步粗筛，过滤掉那些意图极其明确、覆盖度极高的任务，而不是指望它解决所有分流问题。3.2 语义路由：用向量相似度做冷启动分类语义路由是我用得最多的一种方式。它的核心思路是把用户请求用嵌入模型转成向量，然后和一批“代表性样本向量”做相似度对比，取最接近的类别作为路由结果。这里有三个关键点：需要有一个嵌入模型，把文本映射成高维向量；需要给每个路由目标准备若干条典型样本，比如“商品咨询”这个类目下准备几十条真实用户怎么问这类问题的例句；相似度计算通常用余弦相似度，阈值需要根据验证集调。这个方案的优点是不需要标注大量数据就能冷启动——准备每个类别二三十条样本即可，并且对用户的自然表达有很好的容忍度。缺点是需要额外部署嵌入模型，而且对阈值很敏感。阈值设得太严，大量请求会落入“unknown”走兜底；阈值设得太松，误分类又会拉低下游质量。我在客户项目里针对“售后咨询”“商品咨询”“闲聊”三类各准备了30条样本，用开源嵌入模型做向量化。实测下来，对于超过0.82相似度的请求，分类准确率大约有九成以上，已经足够支撑生产环境的第一层分流。3.3 分类器路由：小模型的性价比与误判代价如果语义路由满足不了你，可以考虑训练一个轻量级分类器，比如基于几万条已标注历史请求训练一个小型文本分类模型。它的推理开销远低于大模型，且分类精度通常比纯向量相似度更高，因为它是专门针对你业务场景优化过的。不过分类器也需要付出代价：第一，必须积累一定量的历史标注数据，冷启动阶段很难用；第二，分类器只能判断意图类别，对“任务复杂度”“输出格式要求”这类连续特征帮助有限；第三，模型更新和迭代需要一套数据回流流程，维护成本比规则和语义路由都高。我的经验是分类器适合在半稳定业务中使用——业务方向不会频繁变化时，花两周时间训一个专用分类器，性价比是很高的。3.4 LLM自评价路由：让模型给自己的任务“选路”还有一种非常灵活但成本也高的思路：把“该走哪条路由”这个问题本身交给一个高能力模型来判断。你可以把用户请求和所有候选模型的能力描述拼接成一个提示词，让模型输出“该由哪个模型处理”。def llm_judge_route(req, candidate_models): prompt = f""" 这是一个用户请求：{req['text']} 以下是可选模型及擅长能力： - 模型A：快速响应，擅长简单对话，成本低 - 模型B：擅长复杂推理和多步分析，成本高 请选择最合适的模型，只输出模型名。 """ result = call_llm(prompt) return {"route": result.strip(), "model": result.strip()}这种“用模型做路由”的方式非常灵活，对新出现的任务类型适应能力强，而且可以让LLM同时考虑成本、延迟和复杂度。缺点是三个：一是每次路由决策都多一次模型调用，额外的时延和成本不可忽视；二是LLM的决策不够稳定，同一个请求可能被路由到不同模型，线上行为不可预测；三是如果这个LLM自身能力不够，就会成为一个新的瓶颈。所以我通常只把LLM自评价路由用在规则和语义都无法判定的“残余流量”上，而不是让它做全量路由。3.5 分层组合路由：生产环境的常态说完上面四种，你应该能感觉到：没有哪一种机制是万能的。生产环境里真正起作用的，往往是它们的组合。我把这种组合叫做“漏斗式路由”：先走最快的规则层，筛掉明确任务；再走语义层，覆盖大部分模糊表达；最后走LLM裁判层，处理少数疑难请求。分层的好处是每一层只需要承担一小部分流量，整体延迟可控，成本也不会失控。后面我会给出一个完整的三层路由落地案例。下面是五种机制的综合对比，方便你做选型参考：路由机制落地成本路由时延可解释性冷启动能力适合场景规则路由极低极低极强无需数据意图明确的高频任务粗筛语义路由中低低中每类几十条样本即可对话、FAQ、意图漂移明显的场景分类器路由较高低中需要大量标注数据业务稳定、样本充足的场景LLM自评价路由高高弱无需训练数据疑难残余流量的兜底分层组合路由中中中各层互补生产环境推荐4. 一次完整的智能体路由链路：从请求进来到响应回去要经过什么4.1 路由入口：先把所有请求变成同一种“语言”很多路由系统失败，不是因为路由算法不行，而是入口的数据结构太混乱。不同渠道进来的请求，有的是JSON，有的是纯文本，有的带着HTML标签，有的把多个问题塞在同一个字段里。如果不做规范化，路由层根本没法稳定抽取特征。我在项目里会在路由层之前加一道“请求规范化”处理，把所有渠道的请求统一成一个标准结构：@dataclass class NormalizedRequest: request_id: str text: str source: str user_id: str extra_meta: dict = None这一步看似简单，却能规避大量后续问题。请求ID用于全链路追踪，text是路由决策的主输入，source用于分析不同渠道的分流差异。没有这个统一结构，后面什么特征抽取、日志回放都无从谈起。4.2 决策层：特征打分与路径选择的实操计算规范化之后进入决策层。我会基于项目目标构造一个打分函数，把模型选择转化为一个带约束的最优化问题，而不是靠感觉拍板。假设有三个候选模型，分别代表高配、中配、轻量。我给每个模型定义一个能力值（0到1）和成本值（每次调用的相对成本），路由决策就是让“质量收益”和“成本代价”的加权和最大。用一个简化的打分公式来解释，核心思想是：对于高复杂度任务，质量收益的权重调高；对于低复杂度任务，成本代价的权重调高；对于高延迟敏感任务，额外加入延迟惩罚项。这个打分过程在代码层面其实就是一个映射表加加权计算，并不复杂。难的是确定权重：要拿历史数据回归一遍，或者通过AB实验迭代。我之前第一次做的时候把权重拍得太主观，导致路由结果完全偏离预期，后来老老实实抽样标注了几百条历史请求，才把权重调到了一个合理范围。4.3 执行层：并行探测、超时与降级策略路由决策完成后，接下来就是真正的模型调用。执行层有一个常见陷阱：为了“保险”，把所有请求都串行等待主模型返回，一旦主模型超时，整个链路就失败。我认为比较稳的做法是给每个模型调用设置独立的超时时间，并准备降级路径。比如目标是调用高配模型做复杂推理，但高配模型超时，可以降级到中配模型用简化提示词重试一次；如果中配也失败，再走预设的兜底回复模板。降级路径至少要有两条，不然路由系统自己会成为新的单点故障。另外，对某些置信度不高的路由决策，还可以使用一种“并行探测”技巧：同时把请求发给轻量模型和规则处理模块，哪个先返回可靠结果就用哪个。这在大促或高峰期很有用，能有效降低响应延迟，但成本会有所上升，需要根据场景权衡。4.4 观测层：让路由决策随时可回溯我特别想强调观测层的重要性。很多团队把路由搭完就上线，出问题时完全不知道请求当初被路由到了哪里，也不知道是路由错了还是下游模型错了。这会让排错变成灾难。我的做法是路由层必须打印完整的决策日志，至少包含以下字段：请求ID；路由目标模型；命中规则或相似度得分；各候选模型的打分明细；实际调用耗时与返回状态。有了这份日志，当用户反馈某个回答不对时，我可以立刻定位到是路由误判，还是下游模型本身能力不足。没有观测层，你连自己错在哪都不知道，这是做路由系统的大忌。5. 落地到某智能客服项目的全过程复盘5.1 项目现状与路由改造的目标这个项目是典型的电商智能客服场景，日请求量大约两万次，原本所有请求都调用同一套高配模型。改造前的情况几乎可以写进反面教材：预算曲线陡增，简单问题响应慢，复杂问题又处理不好。当时定的改造目标有三个：整体成本下降百分之五十以上；简单问题平均响应时间压到两秒以内；复杂问题的有效解决率不能下降。5.2 三层路由的搭建与参数配置针对这个项目，我采用的就是前面提到的三层漏斗结构。第一层是规则层，拦截那些关键词极其明确的请求，比如包含“订单号”的查单请求、包含规格参数的比价请求。这一层覆盖了约四成流量，路由到轻量快速模型，单次调用成本很低。第二层是语义层，针对售后、商品咨询、物流查询、闲聊四类常见意图各准备了三十条典型样本，用嵌入模型实时计算相似度。相似度超过0.82的请求，按对应意图路由到中配模型。这一层再覆盖接近三成流量。第三层是残余流量处理，用LLM裁判模型做兜底。剩余的未知意图请求进入这层，由高能力模型综合判断该走哪条路径。三层之间的衔接代码大概是这样的：def hybrid_route(req, sample_vectors): first = rule_based_route(req) if first["route"] != "unknown": return first vec = embed(req["text"]) matched = find_best_match(vec, sample_vectors) if matched.similarity >= 0.82: return { "route": matched.route, "model": model_for_route(matched.route), "score": matched.similarity, } judge = llm_judge_route(req, candidate_models) return {"route": judge.route, "model": judge.model, "score": -1}5.3 路由前后的成本与质量对照为了让大家对这个机制的效果有直观感受，我把那个项目改造前后的数据整理成了下表。数据带有一定项目特性，仅供趋势参考，但方向和量级是真实可信的。指标单模型方案三层路由方案变化日均调用成本约3000元约800元下降约73%简单问题平均响应约6秒约1.5秒提升明显复杂问题有效解决率88%92%上升4个百分点路由决策额外时延0ms约80ms可控兜底人工介入率5%3.2%下降有一点要说明：成本下降的最大来源不只是把简单任务切给了轻量模型，还包括“复杂问题路由到高配模型后，一次解决率提高，减少了重复提问次数”。后者常常被忽略，但它很惊人。5.4 第一版路由踩过的两个典型坑第一版上线的时候，我犯了两个典型的错误。第一个错误是规则层做得太激进。当时为了降成本，我把“退”“换”这类单字都定义为售后规则，结果“我想换个说法”这种非售后请求也被拦下来扔进售后模型，导致大量误分类。后来我把规则条件从“是否包含某词”改成了“是否同时包含两个以上强信号词”，误判率才降下来。第二个错误是忽略了语义层的灰度验证。新路由上线后，我没有做小流量对比就直接全量切换，结果某个深夜语义层突然把一批“询问营业时间”的请求判定为“闲聊”，引发的线上投诉花了两天才消化掉。后来所有语义层的阈值调整都必须在测试集上跑一遍，并且按5%、20%、50%的比例灰度放量，再也没出现过类似的事故。6. 路由长期稳定运行的三张“安全网”6.1 回流样本动态更新路由样本库路由系统上线只是开始，真正的挑战是“它会慢慢变钝”。用户语言在不断变化，业务活动会带来新的说法、新的产品名、新的活动词。如果语义层的样本库不更新，三个月后相似度匹配的准确率会肉眼可见地下降。我现在的做法是每天定时拉取路由日志，筛选那些相似度介于0.6到0.82之间、最终被LLM兜底处理的请求，抽样人工标注后补充到对应类别的样本库中。每个类别每周新增五到十条典型样本，持续迭代。这个动作看起来不酷，但它是路由效果能长期保持稳定的核心。6.2 模型能力变化后的路由重新校准还有一个很容易被遗忘的风险：模型本身会更新。很多团队在路由系统里写死了某个模型的能力描述，比如“模型B擅长复杂推理”，但几个月后模型B发布新版本，可能复杂推理能力更强，成本却变了，或者推理风格发生了变化。路由决策依据如果还是老信息，系统就会在不知不觉中降级。我的建议是每季度做一次模型能力复测，拿一组固定的标准问题集重新验证所有候选模型，根据结果更新模型能力画像和路由权重。这个复测可以自动化，并不费多少人力，但能避免很多难以排查的线上劣化。6.3 请求失败的兜底与人工重放机制最后一张安全网是请求失败后的处理。路由系统接的模型越多，可能的失败点就越多。超时、限流、内容格式异常、下游服务不可用，每一种失败都应该有对应的降级动作。我会为每个路由目标预设一个最低可接受模型，比如高配模型挂了可以降级到中配模型，中配模型挂了可以降级到轻量模型加简化提示词。如果所有模型都不可用，还需要一个模板回复兜底，并接入人工坐席。等系统恢复后，再把失败请求按照原路由路径重新处理一遍，避免用户问题被悄悄丢弃。这套兜底机制一度在一个大促场景里救了我：那次高配模型服务短时抖动，外部调用大面积超时，系统自动把高复杂度请求降级到了中配模型，虽然回答深度有所下降，但至少没有中断服务，也没有出现大规模用户投诉。要知道，在那种流量下，哪怕中断十分钟都是事故。我个人在做了几个带路由的智能体项目以后，最大的体会是：路由不是一个“选个模型”的动作，而是一整套围绕任务分配、成本控制、质量保障的工程体系。如果你刚开始接触，不要急着上复杂的分类器或LLM裁判，先把规则层和语义层搭起来，跑两到四周，看看日志里的数据分布，再逐步增加兜底机制和动态更新。先能跑，再跑稳，最后再优化——这个顺序能让你的路由系统越用越顺手，而不是越维护越吃力。