1. 从账单爆炸说起为什么 Agent 不能永远只用旗舰模型我最早开始认真考虑混合模型路由是因为一张让我肉疼的 API 账单。当时我维护的一个 Agent 服务所有请求都统一接到最贵的旗舰模型上平均一次对话要串三到五轮工具调用遇到复杂的任务甚至要循环十几轮。一个月跑下来整个服务的调用量其实并不大但账单却高得吓人。最讽刺的是我翻日志以后发现真正需要旗舰模型深度思考的请求可能连总量的 20% 都不到。剩下那 80% 的请求有的只是让 Agent 查个天气、转个格式、做个简单的关键词匹配有的只是用户随手发了句“在吗”但每一次都让旗舰模型全功率运转了一遍。那时候我就意识到Agent 应用的成本问题本质上不是“模型贵不贵”的问题而是“该贵的时候贵、该便宜的时候便宜”的分配问题。混合模型路由解决的就是这件事。它的核心思路很朴素在一个 Agent 服务背后接入多个不同能力、不同价格的模型在每次请求进来的时候由一个路由模块自动判断“这单生意该派谁去”。能力要求低的请求送到轻量级模型几毫秒就返回成本几乎可以忽略真正复杂的推理任务再交给旗舰模型保证输出质量。整个过程中用户无感知但你的成本结构会完全不一样。这套机制特别适合两类团队。一类是已经把 Agent 跑起来、开始被成本困扰的工程团队他们需要在不牺牲体验的前提下把账单压下来。另一类是正在做 Agent 选型、还在“一个模型打天下”和“多个模型混着用”之间犹豫的同学。这篇文章我会把我自己实现这套路由机制的全过程包括判断逻辑、工程细节、踩坑记录和上线后的真实数据完整拆开来讲。2. 路由判据设计如何让系统决定“这单该花多少钱”2.1 第一层判断任务意图与类型识别路由要做的第一件事不是选模型而是先搞清楚用户到底想干什么。没有这一层后面所有复杂度判断都是空中楼阁。我见过不少团队做路由第一版就是简单地拿 prompt 长度做判断prompt 短就走便宜模型prompt 长就走贵模型。这个逻辑不能说完全没用但非常容易被击穿。有些推理任务prompt 本身很短比如“帮我证明一下这个数列是发散的”就十几个字但需要很强的推理能力反过来有些任务 prompt 很长比如“把这封 4000 字的中文邮件翻译成英文”字数很多但翻译这种活根本不需要旗舰模型参与。所以我的做法是路由的第一层先做一个意图分类。实现方式有三种我按性价比排序第一种是用一个小模型做分类器。把用户原始输入注意不是整个系统 prompt只是用户这次说的话丢给一个便宜的文本分类模型让它输出预定义的任务类型标签。这个方案的优点是非常便宜而且分类结果稳定可解释后面接规则也好接。第二种是用 embedding 相似度匹配。预先定义好几十个典型任务类型的示例文本生成 embedding 存起来然后每次请求进来计算用户输入和这几个示例的向量相似度取最高的那个作为意图标签。这套方案的好处是没有额外模型调用延迟匹配速度极快。第三种是让大模型自己给任务分类。就是额外加一次轻量模型的调用让它在输出正文之前先输出一个 task_type 字段。优点是灵活缺点是增加了链路延迟而且你要解析模型输出、处理可能不合 JSON 格式的情况。我用的是第二种方案因为当时我们的 Agent 场景任务类型非常集中无非就是“信息查询”“文本处理”“代码生成”“数学推理”“闲聊”这么几种用 embedding 匹配已经足够稳。而且我发现一个技巧不要只用一个示例代表一个类型最好为每个类型准备 5 到 10 个不同的问法变体因为同一类任务的表达差异非常大示例太少了向量匹配会飘。2.2 第二层判断复杂度信号与置信度自评意图分类只能决定候选模型池也就是说“这单可能是哪几类”但它决定不了“这单到底要花多大力气去处理”。同样是代码生成任务让 Agent 写一个“Hello World”和写一个“分布式任务调度器的幂等重试模块”难度差距是天上地下。所以路由必须再做一层复杂度判断。复杂度信号的来源我总结下来有四个第一是用户输入本身的特征。这里我不仅看长度还会看几个额外信号用户段落的标点密度、是否包含数学符号或公式、是否包含“请仔细思考”“逐步推理”这类强推理暗示词、是否包含大段报错日志或堆栈信息。这些信号单独看都不够强但组合起来能很好地表达任务的推理密度。第二是 Agent 内部状态的上下文长度和工具调用期望。有些任务虽然用户只问了一句但 Agent 为了回答这个问题需要先查数据库、再调外部 API、再汇总结果这种多工具链路的请求就应该走强模型。所以路由器不能只看用户输入还要结合 Agent 执行计划里预计必要的工具调用数量来判断。第三是模型置信度自评。这个方案我用得比较谨慎让轻量级模型在处理请求以后额外输出一个 self_eval 字段表示它对这次回答质量的信心。如果信心低于一个阈值就把结果作废重新发给旗舰模型。这个机制很巧妙等于让最便宜的模型当第一道筛子筛不住的才往上送。但这里有个成本陷阱后面我在踩坑部分会专门讲。第四是我后来加上的错误反馈信号。Agent 调用外部工具返回了异常、JSON 解析失败或者用户对上一个回答点了“不喜欢”这些信号一旦出现几乎就意味着“当前模型搞不定这件事”应该立刻升级到更高级的模型。这条反馈链路让我省掉了大量无用的重复调用因为你与其让便宜模型再试一次不如直接升级。2.3 路由表配置质量与成本的显式权衡前面这些判断做完以后最终要落到一张路由表上。我自己的实现里路由表是这样的一个结构任务类型复杂度等级路由目标备注闲聊、问候、情感类低轻量模型几乎免费用最便宜档位信息查询、事实检索低轻量模型如果有引用需求可升一档文本处理、改写摘要中中档模型结构化输出能力要好代码生成、调试解释中高中档或旗舰看是否涉及多文件修正数学推理、逻辑分析高推理特化模型这里有个重点见下文多工具调用、规划类高旗舰模型工具调用稳定性优先任何类型出现错误信号升级当前档上位模型错误信号优先级最高这个表格看着简单但有两个细节值得展开。第一个细节是“推理特化模型”这一行。当时我们对接的模型里有一类模型价格适中但在数学、代码推理上表现特别好另一类通用旗舰模型虽然综合能力强但价格是前者的好几倍。对于纯数学推理、逻辑证明这类任务推理特化模型的效果和旗舰模型几乎打平成本却低一大截。所以我的路由表在“数学推理”这一类上会优先路由给推理特化模型而不是直接丢给最贵的选项。第二个细节是关于“结构化输出稳定性”的。做 Agent 的同学应该深有体会一个模型即使推理能力很强如果它偶尔不按预定义的 JSON 格式输出你的下游工具解析就会崩溃然后整条 Agent 链路就断了。所以配置路由表的时候不能只看模型贵不贵、聪明不聪明还要看它对 JSON 模式和 function calling 的支持是否稳定。我交过学费之后现在的做法是在每个候选模型上都预先跑一份包含 50 个典型请求的回归测试集专门记录格式遵从率再把这数据写进路由的权重因子。3. 路由执行层的工程细节超时、重试与优雅降级3.1 降级链贵的失败后该由谁接管路由不只是“选一个模型”这么简单更关键的是“选了之后出了状况怎么办”。真实生产环境里最贵最聪明的那个模型恰恰可能是延迟最高、最容易超时的那个。所以我在路由层必须设计完整的降级链。降级链的设计原则是这样路由目标优先但任何单独模型失败时请求必须能顺延到下一个模型而不是直接向用户报错。举个例子一次复杂代码生成任务路由决策结果是“旗舰模型”但它超时了。这时候降级链要把请求转给此时仍旧健康的次优模型而不是让用户干等或者说“服务不可用”。我在实现时维护了一个多级候选列表每一级都包含模型名称、调用优先级、健康状态三个字段。请求进来以后从优先级最高且健康状态正常的模型开始尝试失败就自动切换下一级。这里有个经验值得分享降级链不一定非要“高级降中级、中级降低级”这种单向降序。更好的做法是维护一个动态的可用模型池并且考虑模型之间的互补关系。比如当前最快的轻量模型是 A虽然路由目标是 B但如果 A 当时的负载非常低且返回速度特别快完全可以把一部分中低复杂度请求临时切给 A。这在高峰期削峰的时候特别有用能让整个系统的吞吐量更平滑。3.2 超时与重试的平衡避免双重扣费超时和重试是路由层最容易产生隐藏成本的地方也是我自己真正踩过坑之后才彻底想明白的一个机制。第一版实现里我给所有模型设置了同样的超时时间比如 60 秒。结果发现一个尴尬现象轻量模型通常 2 到 3 秒就返回了设置 60 秒的超时根本没用上旗舰模型偶尔会因为推理链路过长而超过 60 秒超时之后我又盲目地重试一次又等 60 秒。最后用户没拿到结果但后端已经因为两次完整调用被扣了两次费。后来我把超时策略改成按模型分级轻量模型超时时间 10 秒中档模型 30 秒旗舰模型 60 秒。同时重试不是简单的“重试一次”而是先把同一请求按降级链切换到另一个健康模型再试只有当降级链全部不可用时才会选择对原模型做一次幂等重试。而且重试之前必须确认这个请求是幂等的——如果是 Agent 内部已经执行过一次写操作的请求盲目重试会造成重复扣费甚至重复执行事故。另一个容易忽视的细节是“流式响应下的超时判断”。如果你使用的是流式接口不能只等首字节而应该监控两个指标首 token 延迟和两次 token 之间的最大间隔。如果一个模型首 token 秒回但之后每个 token 之间间隔超过 20 秒说明它某个环节卡住了这时候也应该触发降级而不是傻等。3.3 上下文与并发路由决策必须以真实输入为准路由决策必须基于真实、完整的当前请求上下文而不是基于某个固定规则硬编码。这句话听起来像废话但我真的见过有团队把路由做成“所有请求默认走便宜模型只有白名单里的用户走贵模型”。这种做法的问题在于它对“当前这条请求的内容”完全无感白名单用户问一句“你好”也会被送到旗舰模型上去成本根本压不住。正确的做法是路由模块应该直接读取本次请求的组装完成之后的消息列表。我在实现里就是这么干的Agent 的入口拿到用户输入以后先拼接历史对话、工具调用结果、当前系统指令形成一个完整的 request_context再把这个 context 送给路由模块做意图和复杂度判断最后才决定目标模型。之所以强调这一点是因为如果不这样做路由永远会短视。比如用户上一轮说“帮我分析这份销售数据的异常”Agent 已经查完数据库这一轮说“继续”如果不结合完整上下文路由器看到的就是一个孤零零的“继续”它不知道该送哪个模型。只有把完整 context 都交给路由判断才能准确知道这一轮任务其实还在上一轮的复杂延续中应走对应等级的模型。并发控制同样不容忽视。我在路由层加了一个简单的信号量机制限制同一时刻对旗舰模型的最大并发调用数。原因很简单旗舰模型虽然贵但不同时间段它也是有小并发配额的。如果某段时间所有复杂请求集中涌进来直接把旗舰模型打满后面的请求全部排队延迟就会飙升。这时候路由可以做一个“降级但要告知”的策略把一部分中等复杂度的请求提前降级到中档模型而不是全部挤在旗舰模型门口排队。这个策略效果很明显我用一个公式来描述决策逻辑估计预计排队时间 当前等待队列长度 × 模型单请求估计耗时。当这个值超过路由目标的延迟预算时就尝试将任务调度给下一个候选模型。从现象看就是高峰期 Agent 的 p95 延迟从原来的 9 秒降到了 5 秒以内而输出质量几乎没变化。4. 上线一周后的真实数据成本降了质量没塌4.1 成本与质量指标怎么统计才可信很多团队做完路由之后跟我说“成本确实降了”但我一问他们怎么统计的就发现统计口径有问题。有的人只看 API 账单总额但没排除业务增长带来的调用量变化有的人只看单次平均成本却没统计因为路由误判导致的“二次补救调用”。我的建议是上线前就把三个指标定死综合成本、关键质量指标、路由命中率。综合成本按每千次有效对话来算而不是看账单总额这样才能排除掉请求量波动的影响。关键质量指标要看两类一类是用户侧的引用比如请求成功率、用户反馈里的不满意率另一类是 Agent 侧的比如任务完成率、工具调用失败率、返工率。路由命中率就是统计路由决策最终执行成功的比例——这个指标能反映出路由模块本身的稳定性。还有一个容易被忽略的坑统计质量指标时一定要把“因为路由升级而成功”的请求单独分桶。否则你会遇到一个诡异的情况便宜模型先答错了路由升级到旗舰模型答对了最后总账上任务成功率是 100%你会以为便宜模型也能 100% 成功。实际上便宜模型的第一轮成功率可能只有 60%只是被升级机制救回来了。这两种数据的含义完全不同前者说明路由兜底有效后者才是模型本身的真实水平。4.2 实测数据三档模型的分配比例我拿自己维护的那个 Agent 服务做了对比测试。基线是全部走最贵的旗舰模型改造成混合路由之后一共跑了七天。分配比例大概是这样的轻量模型承接了约 55% 的请求主要就是闲聊、查天气、格式转换、简单文本处理这类低难度任务单次调用成本几乎可以忽略。推理特化模型承接了约 25% 的请求集中在数学题、逻辑推理、数据分析解释这些场景效果跟旗舰模型几乎打平价格却便宜了一大半。旗舰模型只承接剩下约 20% 的请求全是最复杂的多步骤规划、长代码项目修改、高难度逻辑推理。成本数据上的变化更直观。改造前每千次有效对话的综合成本我记为基准值 1.0。改造后同一业务量的综合成本降到了 0.3 左右也就是省了大约 70%。而关键质量指标里用户不满意率没有明显上升Agent 任务完成率只掉了不到 1 个百分点基本在统计波动的范围内。值得注意的是这个结果不是一次性白捡的。为了达到“质量不掉”我花的代价是成本 0.3 这个数字里其实包含了一部分“升级补救”的调用成本。也就是说便宜模型先答、回答置信度低、再升级到贵模型重答这种情况虽然没有让质量崩掉但也确实多花了冤枉钱。后面的优化重点就是压低这部分的占比。5. 踩过的坑与后续演进5.1 让模型自己判断结果全走贵模型第一个踩的坑就是我前面提到的“置信度自评”机制。一开始我对这个机制寄予厚望觉得让轻量模型给自己打分既省了规则配置又灵活。结果上线以后我发现一个极其讽刺的现象轻量模型的 self_eval 打分普遍偏高很少觉得自己的回答不够好所以升级率并不高任务完成质量却肉眼可见地下降。反过来我把阈值调严一点之后升级率又飙上去了几乎变成了所有请求都走旗舰模型成本比不用路由还高。后来我仔细想了想问题出在“自我评估这件事本身也需要能力”。一个模型如果只能考 60 分它可能完全判断不出自己哪里错了——你让它评估自己的输出质量它永远觉得“尽善尽美”。所以现在的置信度自评机制只保留了一个变体用轻量模型生成但用一个独立的中档模型做答案评估。评估模型的两段式判断先看答案是否回答了用户问题再看答案里是否存在明显的逻辑硬伤。这样引入了一层“外部审核”比自我感觉靠谱得多。这个坑给我的启发是路由机制的决策来源尽量不要用“被评估者自己”做唯一裁判否则系统会趋向于保守最后滑向成本最高的那条默认路线。5.2 路由只在调用入口做拦截了质量救赎的机会第二个坑比较隐蔽我一开始把路由模块放在了 Agent 的最外层也就是所有请求进来先路由路由完直接发给某个模型然后整条链路就固定了。结果遇到一种情况一个请求被路由到了轻量模型轻量模型答着答着我突然发现它已经连续两次工具调用失败。但按当时的架构路由决策已经做完了没有机制能中途把这条请求“再升级”到更高能力模型。这就是我所说的“静态路由”和“动态路由”的差别。静态路由只管入口一次后面就撒手不管。动态路由则会监听 Agent 链路的中间信号某一步解析失败、某次工具返回异常、某轮回答置信度极低。一旦出现这类信号路由模块会重新介入把一个原本正在执行的轻量模型链路升级成中档或旗舰模型链路。加了这个机制之后我服务的整体任务完成率又往上提了两三个百分点。这个提升来自于那些本来会被浪费掉的中途失败请求——它们不再需要用户重新发起一次全新对话而是在同一次对话里完成了模型升级。说实话这个功能做完之后我再看原本那种“入口一次路由定终身”的设计觉得简直是在给质量埋雷。5.3 下一步反馈闭环与动态路由目前这套混合路由机制已经稳定运行了一段时间但我很清楚它还有明显的改进空间。最优先要做的是让路由决策拥有反馈闭环。原理很简单但实现上有点复杂。现在 V1 版的路由表是静态的任务类型分档和模型映射关系都是提前配置好的。某天如果我换了个新的轻量模型或者某个旗舰模型的效果下降了路由表不会自动感知需要人工去调整。我想要的是每次请求结束以后把实际的任务类型、路由到哪个模型、任务完成率、回答质量评分、成本这些数据全部汇总进一个统计池。每周自动跑一次数据回顾对比同一个任务类型下不同模型的综合表现然后自动生成“该在路由表里增删哪些模型”的建议。更进一步说我有考虑把路由策略从一个静态决策函数改造成基于强化学习的调优方案。也就是说路由决策不再是“根据当前输入特征选一个最优点”而是在多个可选模型之间做试探和分配让系统自己学出来“哪些请求该走哪些模型、什么比例最优”。具体的方案还在试。从我个人体会来说混合模型路由这个方向并不是一个做完就一劳永逸的功能而是会随着模型市场变化持续演进的基础设施。模型一直在更新价格一直在变动能力格局也在洗牌。只要这些变量在变路由策略就需要持续优化。真正让它稳定发挥价值的不是某个聪明的算法而是整个机制的设计足够健壮——能观察、能反馈、能调整让“质量”和“成本”这两头始终处在动态平衡的状态。最后再分享一个小技巧如果你也想给自己的 Agent 做路由别急着在一开始就追求复杂模型。先用最朴素的规则表把 80% 的低难度请求分走把成本先降下来再慢慢在剩下的 20% 里打磨判断精度。路由是均衡的艺术没必要一上来就用最重的方案解决一个其实很轻的问题。
