模型路由到底在解决什么：从 Agent 成本、延迟到推理控制

如果你写过一个稍微复杂一点的 Agent，很容易经历同一种变化。

一开始，为了让它尽快跑起来，我们会把所有步骤都交给最强模型：理解用户需求、拆任务、写工具参数、读工具结果、总结、反思、再生成最终答案。这样做很直觉，也很适合 demo。模型越强，出错越少，工程心智负担也越低。

但一旦这个 Agent 开始逐渐交付，问题就会出现。很多调用其实很简单，只是在做分类、抽取、改写或格式化；有些调用对质量要求不高，却被送进了昂贵模型；有些调用更看重的不是通用 agentic 能力，而是 JSON schema 遵循、延迟和 provider 稳定性；还有一些步骤明明可以失败后再升级，却一开始就用了最贵路径。

这就是模型路由开始有意义的地方。

对 Agent 开发者来说，模型路由更像是在回答一个朴素问题：

这一步任务，值得花多少推理预算？

这里的预算不只是钱。它还包括延迟、上下文长度、工具调用可靠性、结构化输出稳定性、安全检查、失败重试次数，甚至你愿不愿意把请求交给外部 provider。

为什么 Agent 特别需要路由

普通聊天产品里，一个用户请求通常对应一次主要模型调用。但 Agent 不一样。一个 Agent 任务经常被拆成很多小调用：

判断用户到底想做什么；
决定下一步该调用哪个工具；
生成工具参数；
读工具返回结果；
判断是否需要继续；
把中间结果压缩进上下文；
最后生成给用户看的答案。

这些步骤并不等价。

比如“判断用户是不是要查日程”和“基于一堆材料写最终分析”，显然不该默认使用同一个模型。前者可能小模型足够，后者可能需要强模型。再比如工具调用参数生成，看起来只是生成 JSON，但如果模型经常漏字段、乱填枚举值、破坏 schema，整个 Agent loop 就会被卡住。这时你真正关心的不是通用 benchmark 分数，而是它在工具调用场景下的细分能力。

模型路由带来的第一个收益是成本下降。简单步骤不必总是走最贵模型。

第二个收益是延迟下降。用户等待的不是某一个模型调用，而是整条 Agent 链路。链路里每一步都用慢模型，最终体验会很差。

第三个收益是可靠性提升。有些模型更适合工具调用，有些模型更适合长文本推理，有些 provider 当下更快，有些 provider 便宜但波动更大。路由层可以把这些差异显式利用起来。

第四个收益是系统不必押注单一模型。当你把所有能力都绑在一个模型上时，模型升级、降价、限流、退化都会变成系统风险。路由层让模型池变成一个可以调度的资源，而不是一个写死在配置里的名字。

当 Agent 的调用链越来越长时，模型路由是用来分配每一步推理预算的机制。

先把路由想成分诊，而不是排行榜

很多人第一次听到模型路由，会自然想到模型排行榜：哪个模型更强，就把难题交给它；哪个模型便宜，就把简单题交给它。

这个理解没错，但不够。

更实用的心智模型是分层。一个请求进来后，路由层先判断它属于哪种情况：

用户请求
  -> 是简单分类、抽取、改写，还是复杂推理？
  -> 是否需要工具调用？
  -> 是否需要严格 JSON / schema？
  -> 是否有安全、隐私或权限风险？
  -> 是否可以先走便宜路径，失败后再升级？
  -> 当前哪个 provider 更快、更稳、更符合数据策略？
  -> 最后才是：选哪个模型或哪条链路。

路由不是一上来就问模型 A 还是模型 B，而是先问这个请求到底需要什么样的服务。

对 Agent 来说尤其如此。因为 Agent 的很多失败并不是模型不够聪明，而是某个中间步骤坏掉了：工具参数错了，结构化输出坏了，检索结果没被正确使用，便宜模型误判了任务难度，或者强模型被浪费在不需要它的步骤上。

所以模型路由的目标是让系统把每一步任务放到合适的位置上。

工业界现在怎么做

工业界的模型路由，大致可以分成两种路线。

一种路线是托管网关。你不想自己维护很多 provider，也不想每天追模型变化，于是把路由交给平台。OpenRouter 就是这个方向里很典型的例子。

下面这些例子只用来说明路线差异，具体能力和默认行为应以各项目最新文档为准。

OpenRouter 文档中的 openrouter/auto 是模型级自动选择入口。你把请求发给 openrouter/auto，平台分析 prompt，然后从它维护的模型池里选一个模型。对开发者来说，这解决的是我不想手动选模型的问题。

OpenRouter 还有 provider routing。同一个模型可能有多个 provider，价格、延迟、吞吐、参数支持、数据策略都不同。OpenRouter 允许你设置 provider 顺序、是否允许回退、是否要求支持所有参数、是否过滤会训练数据的 provider、是否按价格/吞吐/延迟排序。这已经不是语义分类了，而是很实际的生产调度。

另一种路线是自托管控制。你有自己的模型池、自己的合规边界、自己的 GPU 或私有云部署，不希望把路由交给托管平台。vLLM Semantic Router 这类本身就位于推理 Infra 的项目更值得关注。

在架构上，你可以把它理解为私有 AI 基础设施的 “API 网关”。当 Agent 发起推理请求时，vLLM-SR 会作为中间件拦截并处理这些请求。它不仅能执行前置的安全脱敏（PII）、防越狱（Jailbreak）和语义缓存命中，还能通过解析请求的特征（Signal），动态决定将任务路由到哪个具体的私有模型，实现算力的高效分配。这是一个本地化的，高度可定制的 OpenRouter。

所以 OpenRouter 和 vLLM-SR 都叫 routing，但气质不同。

OpenRouter 更像帮我托管多模型和多 provider 的选择复杂度。vLLM-SR 更像让我在自己的推理系统里拥有一层可编排控制面。前者适合快速接入；后者适合需要私有部署、强控制、复杂插件链和自定义策略的团队。

如果你现在要给 Agent 加路由

我不建议一上来就训练一个 router，大多数场景压根不需要去训练一个自动化的 router，了解你的 Agent 调用链路并设置一些简单的规则对于 99% 的项目都已经足够。

先把 Agent 里的模型调用拆开看。每一次调用都记录：任务类型是什么，用了哪个模型，耗时多少，花了多少钱，是否调用工具，schema 是否通过，是否重试，最终用户是否满意。

然后先做最简单的分层。

比如：

分类、意图识别、轻量抽取，默认走小模型；
工具参数生成，走工具调用更稳定的模型；
长文本综合、复杂推理、最终回答，走强模型；
低置信度、schema 失败、工具失败时，再升级；
高风险请求，强制加验证器或安全链。

这很简单，但很有用。很多团队并不缺一个复杂 router，缺的是对自己 Agent 调用链路的基本可观测性以及理解。

等你有了日志和失败样本，再考虑训练 router 或者撰写更加复杂的路由规则。那时你会更清楚自己到底要优化什么：省钱、降延迟、减少工具失败、提高长尾任务质量，还是让不同用户偏好得到不同模型服务。router 不是一个 Agent 项目早期要考虑的问题，而是一个成熟项目的成本优化。

结语

模型路由不是一个特别神秘的技术。它的起点很朴素：不是每一步任务都值得调用最昂贵的模型。

但这个朴素问题一旦放进稍微复杂一点的 Agent，就会变得越来越重要。因为 Agent 不是一次模型调用，而是一串模型、工具、检索、记忆、验证和回退组成的链路。链路越长，越需要一个地方决定每一步该花多少预算。

OpenRouter 让我们看到托管平台如何把模型选择、provider 排序和工具调用质量做成服务。vLLM Semantic Router 让我们看到自托管推理系统如何把信号、插件、模型池和资源池放进同一个控制面。FrugalGPT、RouteLLM、Hybrid LLM、LLM-AT、RouterEval 这些研究则说明，学术界已经在从成本、难度、偏好和评估角度拆解这个问题。

如果你是 Agent 开发者，模型路由是工程降本、降延迟、提可靠性的手段。

如果你是入门研究者，模型路由是一个很适合连接算法与系统的问题：它既要理解模型能力，也要理解真实工作流；既要看 benchmark，也要看工具调用、隐私、反馈和失败恢复。

路由将会成为 Agent 基础设施的一部分，所以它一定会变得简单，简单到用户无需思考就可以使用，但它依旧是一个重要的问题，基础设施里的很多重要问题，都从简单的直觉开始，最终回归简单的使用。

学术界在研究什么：参考阅读 Dynamic Model Routing and Cascading survey ，作者并不了解模型路由相关研究。此综述把 query difficulty、preference、uncertainty、reinforcement learning、multimodality、cascading 等方向整理到一起。方便读者理解路由的基本研究脉络。