智能体路由（Agent Routing）实战：从单模型困境到低成本高质量的任务分流机制

先讲一个我真实经历过的情况。某智能客服项目一开始只接了一个高配大模型所有提问、总结、信息抽取全部走同一个接口。结果月底对账的时候负责人差点以为计费系统出了问题光模型调用费一项就比服务器成本高了将近五倍。更尴尬的是简单问题回答得又慢又啰嗦复杂问题反而经常漏关键信息。后来我把这套系统改成“按请求分流”——也就是给不同任务分配不同规格的模型——费用立刻降了一大截整体回复质量反而更稳定了。这个分流机制在圈里通常被称为智能体路由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裁判先把规则层和语义层搭起来跑两到四周看看日志里的数据分布再逐步增加兜底机制和动态更新。先能跑再跑稳最后再优化——这个顺序能让你的路由系统越用越顺手而不是越维护越吃力。