前沿 LLM 依然昂贵。随着智能体变得无处不在并大规模运行,这种成本令人望而却步。幸运的是,大多数智能体并不需要每个任务都具备前沿级别的智能。模型实验室甚至也这么说:Anthropic 的选择模型的指南指出,“对于许多应用而言,从 Claude Haiku 4.5 这样更快、更具成本效益的模型入手可能是最优选择。”
超过某个临界点后,你就会遇到收益递减:能力更强的模型带来的质量提升微乎其微,而成本和延迟却持续攀升。一个好的智能体具备模型-框架-任务匹配:为给定任务配备合适的模型和合适的上下文。一个模型路由器会为每个任务挑选那个模型。我们认为这一路由决策应当属于智能体框架,而不是通用网关,因为选择正确的模型需要框架已经组装好的、而网关通常缺乏的相同领域和任务上下文。
我们最近在 LangChain 就感受到了这种痛点,因为我们的月度编码智能体支出开始迅速攀升。在从客户那里听到同样的担忧后,我们着手为Open SWE构建一个有效的模型路由器,这是我们的开源编码智能体。与我们此前始终使用顶级前沿模型的基线相比,它将每个线程的中位成本降低了 64%,且质量没有可测量的变化。本文介绍了我们如何构建这个路由器、我们学到了什么,以及你如何着手将模型路由构建到你的智能体中。
第 1 步:理解任务
我们的测试平台是Open SWE,我们的工程师通过 Slack 和网页 UI 使用它来询问有关我们代码库的问题并请求代码更改。在构建路由器之前,我们需要了解开发者使用 Open SWE 处理的任务类型。我们从线程级数据中提取了LangSmith追踪记录:进来的请求类型,以及每个线程的成本和轮次(作为复杂度的近似度量)。我们在LangSmith Custom Apps中进行了探索,直接基于 Open SWE 追踪记录构建了一个小界面。
我们取了一周的交互式线程,并使用 LLM 分类器按任务类型对每个线程进行了标注。LangSmith Insights也可以为你跨 trace 做这种分组。代码变更占主导:新功能(22%)和 bug 修复(17%)是两个最大的类别,其次是测试或空操作运行(16%)。这些类别是基于每个线程标题和元数据的启发式分类。

我们还研究了智能体 trace 特征如何因任务类型而异。我们发现,与功能开发调查相关的线程往往更长,成本更高,中位轮次也更多。与测试和发布流程相关的线程则往往相对较短且成本较低。
为了判断“复杂度”,我们同时使用总成本和调用次数作为信号:成本相当直接地反映复杂度,因为更大的任务会使用更多 token;而调用次数则更为微妙,因为高次数可能意味着任务更难,或者模型需要多次后续调用来完成任务。

在数据收集时,所有 Open SWE 线程都通过一个顶级前沿模型路由。上述数据表明,鉴于复杂度的范围,Open SWE 处理的许多任务可能并不需要前沿智能。
任务复杂度的这种差异给了我们一个值得检验的假设:路由器可以从初始请求中推断任务类型和难度,并将其发送到更便宜或更快的模型,而不会降低结果质量。
第 2 步:了解模型
TheArtificial Analysis Intelligence Index在一组共同任务上对模型评分,并报告每任务成本,因此你可以将它们全部绘制在一条智能与成本的曲线上。帕累托前沿是那些最便宜且最聪明的模型集合。

我们沿着曲线决定了三个模型,每个模型在成本、速度和智能之间有不同的平衡:
- 快速:GLM-5.3-Flash (xhigh)
- 均衡:GPT-5.6 Sol(中)
- 性能:GPT-6 Astra(低)
我们从不同供应商挑选了模型,而快速层是一个开源模型。GLM-5.3-Flash 位于帕累托前沿,紧邻闭源模型,这再次表明开源模型已经跨过了一道门槛。LangChain 与模型无关,具有一个通用的模型接口,它在各个供应商之间表现一致,因此当有更好的模型出现时,将其替换进路由器只需改一行代码。
第 3 步:在 harness 中构建路由器
在梳理了任务组合并选定了三个层级之后,我们需要通过读取每个传入请求,并将其发送到能够成功处理它的最便宜层级,来把任务与模型匹配起来。在 LangChain 中,这一决策天然适合放在中间件中,它可以在不改变智能体其他任何部分的情况下替换智能体调用的模型(参见动态模型选择)。
Open SWE 中的路由器在该线程的第一条人类消息上运行。它有三个部分:
- 基础提示词:告诉分类器它的职责:选择最有可能完成任务的最便宜模型。
- 每个层级的标准:用简短、平实的语言描述每个层级应承担的工作。
- 一个分类器模型:读取请求,并根据标准和提示词选择一个层级。
通用基准测试只是一个起点。要从两个来源编写每个层级的标准:你自己的任务分析,以及每个供应商对其模型最擅长之处的说明。我们将第 1 步的任务拆解与供应商指南结合起来,用于GPT-5.6 Sol、GPT-6 Astra和GLM-5.3-Flash,以编写基础提示词和每个层级的标准。
这些标准是为 Open SWE 的任务集编写的,因此路由器与 Open SWE 处理的任务深度耦合。这就是它属于 harness 的原因,因为 harness 已经拥有智能体的任务特定上下文(其提示词、工具和领域知识),而通用网关缺乏这些。
我们的第一个版本使用了一个带结构化输出的 LLM,并以用户的请求作为提示词。现在分类器运行在Jev上,这是一个新发布的决策模型,使分类速度提升了近 50 倍。了解我们如何做到这一点,请见用 Jev 构建 Harness。
路由器在每个线程开始时选择一次模型,该模型会用于整个线程。自然的反对意见是:如果线程中途改变主题或复杂度怎么办?虽然这个朴素的路由器设计没有解决这个问题,但我们会在下面的“下一步”部分讨论中途路由。
第 4 步:跟踪任务结果
路由器的价值在于降低成本,但前提是质量不下降。路由器必须做好两件事:所选模型需要能够完成任务,而且它应该是能完成任务的最便宜、最快的模型。这意味着你需要一种方法来跟踪任务结果。有两种方法可以做到这一点:
- 离线评估在固定数据集上运行路由器,这样你就可以安全且可重复地比较不同版本。问题在于数据集:它必须看起来像你的真实流量,并且按照用户关心的标准来评分。对于编码智能体来说,这意味着 PR 质量和可审查性,而这些很难离线评分。
- A/B 测试将实时线程分流到路由器和单一模型基线之间,并按照一个你能为每个线程衡量的成功指标进行比较。实时流量天然就是一个有代表性的数据集,但缺点是用户会被暴露在可能并非最优的路由器之下。
我们运行了 A/B 测试,使用两个结果信号:
- 已合并 PR:Open SWE 现在会记录它打开的每个 PR,以及该 PR 是被合并还是关闭。每个线程的已合并 PR 数量成为我们的主要成功指标。
- 用户反馈:我们为 Open SWE 添加了点赞和点踩,这样用户就可以对任何线程进行评分,包括那些从未产生 PR 的问题。每个评分都会记录为反馈在线程的 LangSmith trace 上。
我们在一个LangSmith Custom App中跟踪了这两者。已合并 PR 是更强的信号。反馈很稀疏,因为只有一小部分线程会被评分,但正是在这里我们听到了路由错误,比如下面第一个测试中引用的那些。
实验
我们的第一个 A/B 测试将路由器与始终使用我们最强模型进行了比较:一半线程经过路由器,一半始终使用 GPT-6 Astra,总共涵盖 973 个线程。

质量没有可测量的变化。29.2% 的路由线程最终产生了已合并 PR,而对照组为 27.3%(p= 0.49)。PR 打开率也持平(38.9% vs. 39.6%,p= 0.82)。
成本大幅下降。路由线程的中位成本为 $0.94,而对照组为 $2.61,降低了 64%。均值下降了 42%,p90 下降了 37%,所以节省的不只是少数便宜的离群值。
大多数请求并不需要最强的模型。在路由线程中,56% 流向 balanced,34% 流向 fast,只有 10% 流向 performance。各层级之间的成本阶梯很陡峭:中位线程在 fast 上花费 $0.097,在 balanced 上花费 $1.50,在 performance 上花费 $2.88,相差 30 倍。

用户反馈也指向同一方向。当一个简单请求运行在 GPT-6 Astra 上时,工程师直接标记了这种过度支出,评论如:“这个查询相当昂贵”和“这个请求本不该被路由到 performance 模型。”
💡 这个结果并不令人意外,因为对照组是我们最昂贵的模型。但这是许多智能体都能受益的改变:很多智能体过度偏向质量,最终导致过度支出。尤其是对于任务种类多样的智能体,路由可以降低成本。
我们还针对相反的对照组测试了路由器:一半线程走路由器,一半始终使用 fast 模型。我们在一天内就结束了这个测试,还没等到它能产生统计上显著的结果。工程师几乎立刻就标记了仅用 fast 那一组的问题,而且由于输出质量低,它正在干扰他们的生产力。
下一步
这个模型路由器的实现是一个概念验证,作为构建最优路由器的基础。以下是一些我们可以探索改进的方向:
- 在DeepSWE或其他编码基准测试上对路由器进行基准测试,这样我们就能评估路由决策与受控基线的对比,而不是仅依赖对生产流量的 A/B 测试。
- 为子智能体选择模型。目前子智能体独立于路由器选择自己的模型。对子智能体也进行路由,尤其是在长时间运行的任务上,可以进一步降低成本。
- 在线程中途重新路由。当新消息与之前的消息差异足够大时,比如一个问题变成了 bug 修复,切换模型可能会带来收益。代价在于提示缓存:切换模型会丢弃它,因此新模型需要以全价重新读取整个线程。对于异步智能体来说,这个代价通常可以忽略不计,因为在人类轮次之间,当 TTL 较短(比如 5 分钟)时,缓存往往已经过期。
- 细化路由标准借助更多信号,比如从追踪记录中挖掘用户情绪:找出用户感到沮丧的线程,这可能意味着任务需要更强的模型。
入门
如果你要为自己的智能体添加路由,我们会从这里开始:
- 理解任务。你的追踪记录保存着你的智能体被要求做什么的真实记录,而LangSmith Insights帮助你从中发现模式,这样你就能在选择层级之前看清任务组合。
- 理解模型。根据现代基准测试,沿着成本-智能曲线挑选几个模型。LangChain 的模型接口可跨提供商使用,因此你可以随时替换模型,而无需重新改造你的应用。
- 在 harness 中构建路由器。把路由视为上下文工程,类似于经典的特征工程:决定路由器应该看到哪些信息,以便在给定你的智能体领域的情况下,对模型适配度做出最佳决策。
- 跟踪任务结果。在路由之前先建立成功度量:评估、在线评估器,或对追踪记录的用户反馈。如果构建评估数据集成本太高或太困难,在实时流量上做 A/B 测试效果也很好。
适合任务的模型会不断变化,因为新模型(包括开源权重模型)不断抵达前沿。由于 LangChain 与模型无关,获取这些收益只需替换一个层级,而无需重建你的智能体。
要为自己的智能体添加路由,你可以加入我们新发布的模型路由中间件。给它你的基础提示、模型层级以及每个层级的标准,它就会在每个线程开始时挑选一个模型。我们很乐意听到你在X或 LangChain GitHubissues上的反馈。
延伸阅读
- GitHub 上的 Open SWE
- 与 Jev 一起构建 Harness
- 模型路由中间件文档
- LangSmith 可观测性文档
- LangSmith 评估文档
- LangSmith 自定义应用
- 在 LangSmith 中记录用户反馈
- Artificial Analysis Intelligence Index
致谢
感谢Mason Daugherty,Kevin Frank,以及Harrison Chase对本文提出的宝贵反馈。同时感谢支持本次实验的 OpenSWE 团队!