模型路由很简单，直到它不再简单-未完纪

给智能体加一个路由器，听起来很容易见效：把简单请求交给便宜模型，把昂贵模型留给困难任务；或者按专长分配——Claude 负责代码，Gemini 负责多模态，依此类推。由分类器或启发式规则作决定，成本下降，性能维持。完成。

事情并非如此。多数路由系统假设模型选择是分类问题。根据我们把路由集成进智能体系统的经验，看起来像模型选择的问题，很快就变成了系统优化问题。三个方面让这件事比预期困难得多。

1. 成本不只是模型定价

我们原以为 GPT-4.1 会比 Claude Sonnet 4.6 便宜，结果并不是。

在 AppWorld Test Challenge 的417个任务中，使用同一个 CodeAct 智能体，Sonnet 总成本为79美元，每任务0.19美元；GPT-4.1 则为155美元，每任务0.37美元，几乎是两倍。只看账面，这说不通：GPT-4.1 的输入和输出令牌价格都更低，而 Sonnet 完成同样任务所需的推理步骤约为三倍。如果只按标价，GPT-4.1 本应轻松胜出。

原因在于缓存，而多数路由讨论完全忽略了它。智能体工作负载常常在多个步骤间复用大量上下文。缓存命中率高时，实际输入成本会显著下降。Sonnet 更低的缓存读取价格，让它从这一模式中获得了更大的收益，足以抵消更高的基础价格和更长的执行轨迹。

实际成本取决于模型、工作负载和服务基础设施之间的相互作用。 只看价目表的路由器，优化的是错误的数字。

2. 复杂度不只是任务难度

常见策略是估算任务有多难，再把较难任务交给更强的模型。这个想法直观，但在两方面会失效。

首先，路由时往往看不见真正的难度。“总结这份合同”看起来简单，完成前却可能触发检索、合规检查、工具调用，以及多轮修改。反过来，技术性很强的提示可能由较小的专用模型高效处理。很多时候，执行开始后你才知道任务到底有多难。

其次，即便你能完美估计难度，它也只是多个信号之一。生产环境中的路由器必须同时平衡成本、延迟、模型专长和可靠性。企业部署还会增加合规要求、数据驻留规则、隐私约束、获准模型名单等限制。理想情况下应交给某个模型的任务，可能因治理要求被迫交给别的模型，而路由器必须妥善处理。

路由器不是只解决一个问题，而是始终同时权衡成本、质量、延迟、合规与可靠性。

3. 延迟不只是模型速度

很容易只按模型规模理解延迟：大模型慢，小模型快。但用户实际感受到的延迟，取决于更多因素。

路由本身就有开销。模型运行在哪种硬件上、缓存是否已预热、端点有多忙等基础设施因素，常常主导端到端响应时间。理论上更快的模型，如果服务条件不合适，仍可能带来更慢的体验。

路由粒度也是问题。每个任务只路由一次，增加的开销很小；但每一步都进行路由，虽让你能在执行中更灵活地调整，却意味着每个新增决策点都会增加延迟和运行复杂度。

忽略服务系统的路由器，优化的是错误的现实。

我们如何处理这些问题

这些经验影响了我们构建路由器的方式。关键变化是：不再把路由视为分类问题，而是优化问题。算法不再只问“哪个模型最适合这个任务”，而是同时优化成本、质量和延迟，并且保持足够轻量，以免自身成为瓶颈。

下图展示了使用 CodeAct 智能体在 AppWorld Test Challenge 上的结果。每个蓝色方块对应路由器的一种配置，形成成本—准确率前沿。重点不是某一个点，而是路由器提供了一组运行点，让你根据成本、延迟或准确率的优先级选择。配置1针对延迟优化，准确率为84%，成本93美元，耗时83秒；相较于只运行 Opus，成本降低21%，延迟降低9%，准确率仅下降4%。配置2进一步压低成本。