Agent 里怎么做多模型路由？四种分流策略与兜底设计

Agent 的一次任务里，各个步骤对模型能力的要求差别很大：意图识别、参数抽取、格式化这些用轻量档就够，只有规划和复杂推理才需要旗舰。全程用同一个强模型，等于用跑车送快递。

这篇讲四种路由策略和兜底设计。多家封装的基础做法见多家 API 统一封装。

策略一：按步骤路由（最容易落地）

把 Agent 的流程拆开，给每一步指定模型档位。

轻量档就够的步骤：意图分类、槽位抽取、query 改写、结果格式化、简单的是非判断。这些任务输入短、输出短、逻辑简单。

需要强模型的步骤：任务规划与拆解、多步推理、代码生成、需要权衡多个因素的决策。

中间档：摘要、翻译、内容改写。

这个策略的好处是确定性高：每一步用什么模型是写死的，行为可预测，出问题好定位。缺点是不够灵活——同一步骤里简单和复杂的请求也用同一档。

落地时的关键是在业务代码里用语义别名（「快模型」「强模型」），映射关系放配置。这样调整档位不用改代码。

策略二：按难度动态路由

先用一个轻量模型做难度判断，或者用轻量模型直接尝试，不行再升级。

做法 A：前置判断。 用小模型判断「这个请求需要强模型吗」，再分发。多一次调用，但小模型的调用成本很低。

做法 B：先试后升。 直接用轻量档跑，附带一个校验（置信度、格式校验、规则检查），不通过再用强模型重跑。

做法 B 更常用，因为它不需要额外的判断步骤，而且实际能被轻量档消化的请求比例往往比预期高。代价是失败的那部分要付两次钱——所以要监控「升级率」，升级率太高的话这个策略就不划算了。

策略三：按成本上限路由

给每个任务（或每个用户、每个会话）设一个成本预算，接近上限时自动降档。

适合的场景：面向大量用户的产品，需要防止个别重度用户拖垮成本；或者内部工具，要给每个团队设配额。

实现上需要一个实时的用量累计，按 token 数换算成本。这一层做出来之后，顺带就有了成本归因的能力，见团队 API 预算怎么排。

策略四：按可用性路由（故障切换）

主用一家，健康检查失败或连续报错时自动切到备用。

触发条件建议是复合的：连续 N 次失败、或错误率超过阈值、或延迟 P95 超过阈值。单次失败就切换会导致抖动。

切回策略要有冷却期，别刚切走就切回来。

这一层的价值不只是容灾，还有议价能力——没有哪家能锁死你。相关的迁移准备见模型下线、改名、涨价了怎么办。

路由层必须有的三样东西

一、统一的错误归一。 各家的错误响应结构不同，路由层要把它们映射成统一类型（限流 / 鉴权 / 参数 / 服务端错误），上层逻辑只认这四类。否则每加一家就要改一遍重试逻辑。

二、按模型维度的用量记录。 每次调用记下模型、输入输出 token、耗时、是否命中缓存、是否是升级重跑。没有这些数据，你无法判断路由策略是不是真的省钱了。

三、兜底路径。 所有候选都失败时怎么办：返回友好错误、降级到规则处理、还是排队重试。这一条经常被忘记，然后在第一次全线故障时才想起来。

常见的三个坑

坑一：轻量档的输出格式更容易飘。 分流之后解析失败率上升，重试成本吃掉省下的钱。对策是给轻量档加更严格的 schema 约束，见结构化输出解析失败怎么办。

坑二：不同模型的提示不通用。 同一个 prompt 在 A 家好用，换到 B 家可能要调。多模型路由意味着你要维护多套提示，这是实打实的工程成本。缓解办法是把提示写得尽量朴素、少依赖某家的特殊习惯。

坑三：缓存被路由打散。 请求分散到多家，每家的缓存都难以积累命中。如果你的场景高度依赖提示缓存，路由策略要考虑「同类请求尽量走同一家」，别为了省一点单价把缓存收益丢了。缓存原理见提示缓存是怎么计费的。

怎么验证路由策略真的有效

上了路由之后，要能回答一个问题：它到底省了多少钱、代价是什么。没有这个答案，路由就变成了一个凭感觉维护的复杂度。

需要看的四个数：

一、各档模型的调用占比。 轻量档承担了多少比例？这个数低于预期，说明分流条件设得太保守。

二、升级率（先试后升策略）。 轻量档失败后升级到强模型的比例。这个数高的话，两次调用的成本可能超过直接用强模型，策略反而是负收益。

三、单位任务成本的变化。 上路由前后对比，同样完成一次任务花多少钱。这是最终结论。

四、质量指标的变化。 结构化输出的一次成功率、人工抽检的合格率。省钱不能以质量下滑为代价，尤其要看最差的那部分有没有变差。

四个数一起看才有结论。只看成本降了就宣布成功，很可能是把质量损失转移到了用户那边。

路由层最容易被忽略的成本

一、提示维护成本翻倍。 每多支持一家/一档模型，就多一套需要维护的提示。改一次需求要改多处，而且要多处回归。

二、调试复杂度上升。 出问题时要先确定「这次走的是哪个模型」。所以日志里必须记录实际使用的模型，这一条不能省。

三、缓存收益被稀释。 请求分散后，各家的缓存都难以积累。如果你的场景高度依赖缓存，这笔损失要算清楚。

四、故障面变大。 接的家数越多，任何一家出问题都可能影响你。所以每加一家都要配健康检查和降级路径，不是接上就完事。

这些成本不意味着不该做路由，而是意味着别过早做。量小的时候，一个模型跑到底反而是最优解。

从哪一步开始做

不建议一上来就上四种策略。实用的推进顺序是：

第一步，把模型名从代码里挪到配置，用语义别名。这一步几乎没有风险，但为后面所有事情打了底。

第二步，按步骤路由，把明显简单的步骤降到轻量档。观察一到两周的成本和质量指标。

第三步，加故障切换。这是可用性收益，和成本无关但同样重要。

第四步，视情况上难度路由和成本上限。这两个复杂度较高，量不大时不值得。