路由模式省60%token成本：智能选择Agent模型

我曾经亲眼看着一条研究 pipeline 在一个下午烧掉了 340 美元。不是因为它失败了，而是因为它成功了。整个流程有 23 个步骤，每一步都被路由到前沿模型，而其中 19 步只是格式化 JSON、提取日期，以及给客服工单分类。我花着买凯迪拉克的钱，干的却是骑辆自行车就能完成的活。

从那天起，我不再怪模型，而是开始审视 router。

模型还没开始思考，账单就已经来了

Agent 成本爆炸背后的数学关系简单得让人容易忽视。像 Claude Opus 这样的前沿模型，每个 token 的成本是 Claude Haiku 这类小模型的 5 到 25 倍。只看一次调用，这点差额几乎可以忽略。但在一个七步工作流中，如果串联了五次前沿模型调用，成本就会比同等的小模型 pipeline 高出一个数量级。

研究结果证实了我的账单早已揭示的问题。在一次生产环境的多 Agent 运行中，团队手工为每个 Agent 绑定模型：planner 用小模型，reviewer 用前沿模型，writer 用小模型。这样一来，一个 Agent 发出的所有调用都会交给同一个模型，不管实际调用有多难。reviewer 每个任务会调用六次，难度从“总结一个模块”到“找出一个并发 bug”不等，但由于它绑定了前沿模型，这些调用全部都交给了前沿模型。

真正关键的是，哪些调用在花你的钱。按调用路由只把 16 次调用中的 2 次交给前沿模型，每 1,000 次审查的成本为 1.37 美元，只有全部使用前沿模型时的五分之一，也不到按 Agent 绑定模型方案的一半。它还找出了 6 个预先植入的 bug 中的 4 个，与全部使用前沿模型的实验组持平，并超过了只找到 3 个 bug 的按 Agent 绑定模型方案。

我一直在解决错误的问题。我不断优化 prompt，却没意识到那个模型从一开始就不该接手这个任务。

改变架构的那个认识

一位同事看了我的 trace，问了一个让我重新审视整个问题的问题：“为什么你的总结步骤，调用的模型和规划步骤一样？”

答案让我有些难堪。我给每个 Agent 配置了一个模型。每个步骤都用它，因为默认就是这样。我从来没问过，每个步骤是否真的需要这个模型。

这时我才明白，模型选择应该是每次调用都要做的决策，而不是每个 Agent 只做一次的决策。规划步骤确实需要前沿模型级别的推理能力。但紧随其后的格式化步骤，只需要一个 7B 模型就够了。把它们一视同仁，在架构上就相当于雇一位资深架构师来整理文件。

vLLM 团队的这句话，我一直贴在显示器上：把模型绑定到 Agent，是“对尚未有人见过的工作，提前做出一次预测”。任务会以一连串调用的形式到来，而按 Agent 绑定模型，会对每次调用给出同一个选择，不管它有多难，还是多简单。

基于能力的路由：匹配调用，而不是 Agent

解决这个问题的模式叫作基于能力的路由，也叫 semantic routing。它简单得让人有些不好意思：根据每次调用的需求进行分类，把它路由到足以胜任的最便宜模型，只有当 gate 拒绝输出时，才升级到更强的模型。

Federation of Agents 论文对这一机制做了形式化描述：Versioned Capability Vectors（VCVs）是机器可读的能力档案，可以通过 semantic embeddings 检索 Agent 的能力，让 Agent 能够公开自身的能力、成本和限制。路由层通过分片 HNSW 索引为任务匹配 Agent，同时通过偏向低成本的优化来落实运行约束。

Equinix 的 LatentGate 论文则从企业应用的角度描述了这个问题。当系统拥有 100 个专用 Agent 时，router 必须把自然语言输入映射到正确的 Agent，同时满足三个约束：延迟低于 100ms、精度足够高，因为路由错误会触发错误的 API 调用，以及新 Agent 的接入成本足够低。基于 prompt 的 LLM 路由具备很强的语义推理能力，但延迟高得难以接受，大约为 1500–2000ms；当 Agent 数量达到 100 个时，准确率还会下降到 70–77%。解决办法不是换一个更大的 router，而是使用一种表示方式，避免把语义相近但功能不同的 Agent 挤进同一个 embedding 锥形区域。

朴素的级联方案有一个陷阱。决定是否升级模型的 gate，才是整个机制的关键支撑。如果 gate 只检查输出格式，就会直接放行错误答案：格式错误的 JSON 很容易被发现，但一个自信满满、实际却错误的提取结果，看起来和正确结果完全一样。

研究究竟量化了什么

2026 年的研究已经不再停留于理论。数字很具体。

MTRouter 把交互历史和候选模型编码为联合的历史与模型 embeddings，并从记录下来的执行轨迹中学习一个结果估计器，预测每一轮调用中模型的效用。在 ScienceWorld 上，它超过了 GPT-5，同时将总成本降低了 58.7%。在 Humanity's Last Exam 上，它取得了有竞争力的准确率，同时相比 GPT-5 将总成本降低了 43.4%。与此前的多轮 router 相比，它切换模型的次数更少，对暂时性错误的容忍度也更高。

Planner-as-Router 把模型档位选择融入规划过程。planner 将查询拆成子任务时，会为每个子任务分配一个模型规模档位：small、mid 或 frontier。这样，在任何专用 Agent 开始运行之前，依赖关系就已经清晰可见。在覆盖 54 项企业 Agent 任务的 1,157 次评估中，相比全部使用前沿模型的路由方案，它降低了 44% 的成本，准确率只损失了 2.9 个百分点。

RouterHGC 将路由形式化为异构图上的节点选择问题，节点类型包括用户查询、协作模式、Agent 角色和 LLM。它在 MATH 和 HotpotQA 上取得了 0.80%–6.17% 的准确率提升，同时将推理成本降低了 27.40%。

L7 是一个 Bayesian 路由框架，它针对每个模型的 Beta 分布使用 Thompson Sampling。在 10,000 个异构 benchmark 任务上，相比静态 round-robin 基线，它将总推理成本降低了 68.5%。它不需要任何训练数据，从均匀先验出发，通过在线更新即可工作。

这些研究得出的结论一致：按步骤路由优于按 Agent 路由，因为同一个 Agent 的工作负载中，各次调用的复杂度差异很大。

没人提醒你的成本悖论

接下来这个问题，我花了三周才理解，又花了两个月才修好。

如果你在多轮 Agent 中错误地实现路由，最后花的钱可能比完全不做路由还多。

原因是 prompt caching。到一次 Agent 会话的第 3 轮时，缓存 token 已经占据了你所发送 token 的绝大部分。你需要保护的，正是这部分效率。

在会话中途切换模型，会彻底破坏这层保护。每家提供商的缓存都与具体模型绑定。新模型无法访问旧模型存储的历史，只能从头重新读取整段对话，并按完整的输入 token 价格计费。

这就是 vLLM Semantic Router 团队构建 Session-Aware Agentic Routing（SAAR）的原因。其核心认识是：router 不仅要知道哪个模型最适合当前请求，还要知道什么时候切换模型会破坏会话。SAAR 增加了由 router 管理的会话记忆、针对 tool loops 和不可迁移的提供商状态的强制锁定、安全重置边界，以及将 prefix cache 纳入考虑的模型切换成本计算。在 21,600 个确定性轮次中，SAAR 将模型切换次数减少了 79.29%，消除了 3,836 次不安全切换，并将估算的实际底层模型成本降低了 78.71%。

我犯的错误，是在整个会话过程中切换模型来做路由。解决办法是在单个步骤内路由：为每次生成选择模型，完成生成后，再回到会话使用的模型。更好的办法是，在切换前先总结上下文，让新模型从压缩后的历史开始，而不是面对一个冷缓存。

谁已经把它用到了生产中

Barclays 对一个由四个 Agent 组成的 pull-request 审查团队开展了对照实验。全部使用前沿模型时，每 1,000 次审查的成本约为 7 美元。按 Agent 绑定模型时，成本约为 3 美元。使用 vLLM Semantic Router 按调用路由时，成本为 1.37 美元：只有全前沿模型实验组的五分之一，不到按 Agent 绑定模型实验组的一半，而且 bug 检出率与前沿模型基线相同。router 为每次决策增加的 p50 延迟为 1.86ms。

Equinix 在 5 个 SLM backbone 和 100 个企业 Agent 上部署了 LatentGate。在自然语言查询上，它取得了 98.8% 的域内准确率和 80.0% 的域外准确率，比 embedding 基线高出 13 到 22 个百分点。在 T4 GPU 上，延迟约为 28ms，而且 SLM 前向传播的计算不随 Agent 数量变化。

Microsoft Foundry 提供了可以直接接入的 Model Router 部署，为 Agent 发出的每个请求选择最合适的 LLM。简单的问候会被路由到快速、便宜的模型，复杂的 tool-calling 链则会被路由到前沿模型。你可以给不同 Agent 分配不同的 router，每个 router 都有自己的路由模式和模型子集，让部署方案与各个 Agent 的成本特征相匹配。

Red Hat 的 vLLM Semantic Router benchmark 结果是最具体的一组数据之一：通过自动调整 reasoning mode，准确率提升了 10.2%，延迟降低了 47.1%，token 用量减少了 48.5%。在商业和经济领域，准确率提升超过了 20%。

它应该放在架构的什么位置

分层路由不应该是默认配置。它是针对特定问题的解决方案。

当你的 Agent 工作负载中，各次调用的复杂度存在差异时，才使用它。规划和综合分析调用需要前沿模型的推理能力，提取、格式化和分类调用则不需要。如果每次调用确实都需要前沿模型的能力，路由就帮不上忙。

当你的 token 用量足够大，节省下来的成本能够抵消基础设施投入时，才使用它。如果每月账单是 50 美元，一个能省 40% 的 router 不值得专门去构建。如果每月账单是 50,000 美元，一个能省 40% 的 router 就值得。

使用步骤级特征，而不是查询级特征。研究已经明确表明，单轮 router 会错误地路由 Agent 步骤，因为它们缺少执行轨迹的上下文。TwinRouterBench 的存在，正是因为现有 benchmark 只用一次性的 prompt 评估 router，从不提供 Agent 中间步骤上 router 能看到的前缀。真正重要的特征，是当前步骤能够获得的信息：指令、累积的上下文长度、上一步的模型档位，以及依赖结构。

没有先做总结，就不要在会话过程中切换模型来做路由。缓存损失会吃掉你省下来的成本。要么在单个步骤内路由，要么在切换前先做总结。SAAR 的会话锁，就是这一原则在生产环境中的实现。

你需要接受的取舍

基于能力的路由能降低成本，而且通常也能降低延迟。代价是确定性降低，以及技术栈里多了一个 classifier。

每次路由决策都有可能选错。复杂调用被交给便宜模型后失败，你就得支付便宜模型的尝试成本、升级模型的成本，以及两次调用的延迟。决定级联方案是否划算的是 gate 的误接受率，而不是模型档位阶梯。如果你的 gate 放行了错误答案，你只是以折扣价把错误交付了出去，所谓节省成本也就成了假象。

你还得接受更多需要维护的组件：router、gate、档位配置，以及各档位的成本追踪。每一个都可能独立出故障。vLLM Semantic Router 的故障处理方式很有参考价值：低置信度答案会自动升级；提供商服务中断会触发 circuit breaker；预算耗尽后会停止升级，并返回当前能获得的最佳回答。这些机制都需要付出成本。

但看着账单下降了 68%，而质量没有出现可测量的退步，我学到了一件事：那些把 Agent 用出成效的团队，并没有把最好的模型用在所有事情上。他们为每次调用选择合适的模型，也接受了这样一个事实：“合适”值得作为一项明确的决策来做。

所以，我想问你：如果按调用查看你的 Agent 成本明细，其中有多少次调用，在你认真选择模型的情况下，仍然值得支付前沿模型的价格？

我很想听听你最后采用了什么方案：在 Agent 团队前面放一个 semantic router，坚持你认为合理的按 Agent 绑定模型方案，使用能在线学习的 Bayesian 策略，还是直到一张账单让你终于开始审视这个问题？又是什么最终促使你做出改变？

部分评论可能仅对已登录的访客可见。登录后即可查看全部评论。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。