top of page

LangChain 模型路由器在未出现可测质量损失的情况下削减 Agent 成本

7天前
讀畢需時 14 分鐘

LangChain 表示,其 LangChain 模型路由器在 973 个真实线程中将编程 Agent 的成本中位数降低了 64%,同时拉取请求的结果没有出现可测量的下滑。这一结果挑战了 Agent 设计中的一种常见选择:为每项任务都分配当前最强的模型。

该公司在 Open SWE 中测试了这一路由器。Open SWE 是其通过 Slack 和网页界面使用的开源编程 Agent。经路由的线程中,拉取请求的合并率为 29.2%。始终使用 GPT-6 Astra 的对照组则为 27.3%。

这一差异在统计上并不显著。因此,该实验并不能证明路由能够提升代码质量。它提供的是一个更有限的结论:Open SWE 大幅减少了模型资源消耗,同时未检测到相应的质量损失。

这一区别很重要,因为编程 Agent 要处理混合型工作负载。一项功能调查可能需要长时间推理,而一次测试运行或代码仓库提问则未必如此。LangChain 的观点是,在 Agent 开始工作之前,模型选择应反映这些差异。

973 个 Open SWE 线程中发生了什么变化

LangChain 用任务级路由取代了固定的前沿模型默认配置,随后在真实的内部流量中对这一改变进行了测试。

该公司在其 10 月 1 日发布的模型路由分析中介绍了结果。测试将 973 个 Open SWE 线程分为路由组和对照组。

每个对照组线程都以低推理强度使用 GPT-6 Astra。路由组线程则可根据第一条人工消息使用三个层级中的一个。

性能层使用 GPT-6 Astra。平衡层使用 GPT-5.6 Sol,快速层则使用 GLM-5.3-Flash。每个层级代表模型能力、延迟和运营成本的不同组合。

根据 LangChain 发布图表中的日期,该实验于 9 月 16 日至 9 月 22 日期间进行。与仅使用前沿模型的对照组相比,经路由线程的单线程成本中位数下降了 64%。

降幅并不只体现在中位数上。LangChain 报告称,平均成本下降了 42%,第 90 百分位成本下降了 37%。这些数字表明,结果并非仅由少量极其简单的请求推动。

大多数经路由的工作都避开了性能层。平衡模型接收了 56% 的路由线程,快速模型处理了 34%。只有 10% 被分配给最强模型。

这一分布是核心事件。它表明,路由器将十个传入请求中的九个归类为适合使用低于最高层级的模型。

Open SWE 覆盖的不只是自主代码生成。工程师使用它来提出代码仓库问题、调查行为、运行测试、修复缺陷和请求新功能。底层的 Open SWE repository还支持集成、隔离的编程环境和拉取请求工作流。

LangChain 首先研究了一周的交互追踪记录,以了解这类工作负载。在已分类线程中,新功能占 22%,错误修复占 17%。测试或无操作运行又占 16%。

这些标签来自一个使用线程标题和元数据的 LLM 分类器。LangChain 明确将其称为启发式方法,因此不应将其视为经过人工验证的事实依据。

不过,这些类别揭示了具有实际意义的差异。功能调查通常需要更多轮次,并消耗更多资源。测试和发布任务一般更短、成本也更低。

这种差异为路由创造了空间。固定模型策略假定每项请求都值得投入相同的推理预算。生产数据则表明并非如此。

为什么 LangChain 模型路由器部署在 Harness 内部

LangChain 更大的主张关乎部署位置:模型路由应位于 Agent harness 内部,因为任务上下文已在那里可用。

Agent harness 是围绕模型运行的运行时系统。它提供提示词、工具、记忆、执行限制、权限以及应用专属上下文。

网关通常位于技术栈更底层。它可以集中管理供应商访问、执行预算、分配流量,或依据通用规则选择端点。

LangChain 认为,这些通用信号不足以支持对任务敏感的路由。成本最低且足够胜任的模型,取决于 Agent 必须完成什么、可以使用哪些工具,以及成功意味着什么。

一项编程请求就能说明这种差异。“解释这个配置文件”和“追踪一个间歇性并发缺陷”可能通过同一个界面进入系统,但二者所需的推理深度不太可能相同。

Harness 能看到代码仓库上下文、可用工具、系统提示词以及用户明确的目标。通用流量层可能只能看到请求封装和宽泛的模型元数据。

这就是为什么 Open SWE 的模型路由从第一条人工消息开始。分类器会将该请求与三个层级的自然语言标准进行比较。

其基础指令要求选择最有可能完成任务的最低成本模型。路由器不会自动选择最快的选项,而是试图识别仍然足够胜任的最低层级。

LangChain 通过 Agent 中间件实现这一决策。中间件是能够检查或修改 Agent 操作、而无需重写整个 Agent 循环的代码。

该公司的动态模型选择方法允许中间件替换模型,同时保持工具和更广泛的工作流不变。随着供应商发布新选项,这种分离使模型替换变得更容易。

这种部署位置也使路由成为上下文工程的一种形式。开发者不再只改进 Agent 的回答提示词,而是设计用于选择回答模型的信息。

这一决策可以纳入请求类型、预期工具使用、代码仓库敏感性、延迟要求或既往失败模式。支持 Agent 和编程 Agent 所需的层级定义会有所不同。

这一架构对仅依赖网关的路由策略提出了挑战。集中式网关对于身份验证、限制、日志记录和供应商故障转移依然很有用。然而,这些功能并不会自动揭示一项任务在语义上是否困难。

这两个层级可以共存。Harness 可以进行应用级选择,而网关则在其下方执行组织层面的控制。

因此,这项实验不应被解读为网关已经过时的证据。它说明,具备领域认知的 harness 可能拥有单靠基础设施无法获得的路由信息。

对于工程团队而言,这也带来了可观测性要求。路由器需要记录实际工作、结果和失败模式。没有这些记录,层级标准就会沦为猜测。

Open SWE 使用 LangSmith 追踪记录来检查请求类型、成本和模型调用。构建类似系统的团队需要等效的反馈闭环,无论他们使用 LangSmith 还是其他追踪平台。

可搜索的设计决策记录也有助于团队解读这些追踪信息。开发者可以通过工程知识库将路由失败与代码仓库细节联系起来,而不是孤立地评估提示词。

Open SWE 模型路由如何做出选择

路由器结合观察到的任务模式和模型专属标准,然后将每个线程固定分配到一个层级。

LangChain 从工作负载分析开始,而非通用排行榜。这个顺序很重要,因为一个模型可能在公开基准上表现良好,却不适合某个组织的实际任务。

团队将线程成本和调用次数作为复杂度的近似信号。两者都不是完美标签。

更高的成本可能反映请求更长或更困难,也可能反映低效行为。更多调用可能代表真实复杂性、反复修正,或不必要的工具调用。

随后,LangChain 使用智能水平与成本曲线比较候选模型。最终选定的三款模型分别覆盖快速、平衡和性能位置,而不是选择三款能力几乎相同的前沿模型。

路由器的标准结合了两类输入:一类是 Open SWE 观察到的任务分布,另一类是有关模型预期优势的指导信息。

在运行时,分类器会读取开场请求,返回一个层级,而 Open SWE 会在整个线程中使用对应模型。

第一版使用具备结构化输出能力的通用 LLM,这意味着模型必须返回预定义的分类格式。LangChain 后来将分类任务迁移至专门的决策模型 Jev。

该公司表示,Jev 将分类速度提升了近 50 倍。这是供应商报告的结果,已发布的路由实验并未提供独立的延迟复现验证。

更快的分类仍然解决了一个实际问题。如果路由器节省了模型成本,却为每个请求增加明显延迟,用户体验就可能受到影响。

一次性决策也有助于保护提示词缓存。持续使用同一模型,可让供应商复用符合条件的提示词内容,而不必再次处理整个对话。

不过,在线程开始时作出固定选择也带来了一个重大限制:初始提示词并不总能预测后续工作。

用户可能先提出代码仓库问题,随后再要求修复错误。一个看似很小的改动,也可能在 Agent 运行测试后暴露依赖问题。

当前路由器不会自动响应这种演变。一旦选择了层级,同一选择会在整个线程中保持有效。

这使开场分类比表面上看起来更关键。路由不足可能让困难任务受困于较弱模型;路由过度则可能抹去预期节省。

LangChain 发布的设计包含三个易于理解的组成部分:基础指令、层级标准和分类器。这种简单性有利于审计,但无法捕捉所有复杂性来源。

代码仓库规模、编程语言、失败测试输出和所需工具权限,可能只有在执行开始后才会显现。分类器无法利用尚不存在的证据。

当初始请求包含足够信息、能够区分常规工作与高要求工作时,这种方法最有效。模糊的提示词则更难可靠分类。

这一限制并未否定 Agent harness 的模型选择方式。它界定了下一个工程问题:Agent 在收集到新证据后,应在何时重新考虑模型选择?

成本结果比质量主张更有力

该实验支持一个明确的成本结论,但其质量证据仍有参考价值,同时并不完整。

LangChain 将已合并的拉取请求作为主要成功指标。当 Open SWE 创建的拉取请求后来被用户合并时,该线程被计为正向结果。

路由组的合并率为 29.2%,对照组为 27.3%。报告的 p 值为 0.49。

这一水平的 p 值并不支持路由系统表现更好的主张。它同样无法证明两个系统在所有质量维度上等效。

更稳妥的结论是 LangChain 所采用的表述:在这项测试中,没有发现可测量的质量变化。这一措辞承认了实验的检测能力限制。

拉取请求的创建率也同样接近。经路由的线程创建拉取请求的比例为 38.9%,而对照组为 39.6%。报告的 p 值为 0.82。

这些数字降低了人们对任务完成情况明显下滑的担忧。但它们并不能说明,经路由的拉取请求是否需要更多人工修改,或是否引入了更隐蔽的缺陷。

合并是一个具有意义的生产信号,因为它反映了用户的接受程度。但它同样受到模型质量以外因素的影响。

审查资源是否可用、任务紧急程度、代码仓库惯例以及用户行为变化,都会影响拉取请求能否被合并。一些有价值的线程根本不需要拉取请求。

LangChain 增加了点赞和点踩反馈,以覆盖这些非 PR 交互。该公司表示,参与度较低,限制了这一指标的统计价值。

评论确实暴露了明显的路由错误。当简单任务被分配至性能档位时,工程师会提出抱怨,因为这些资源显得没有必要。

反向失败的测试时间更短。LangChain 将路由方案与仅使用快速模型的对照组进行比较,但在一天内便结束了实验。

据该公司称,仅快速模型组的工程师立即反馈输出质量较低、生产效率受到干扰。测试在能够产生具有统计意义的结果前便告终。

这一事件有助于界定主要的对立选项。问题并不是路由与始终选择最便宜模型之间的对比。

而是在不同极端下,情境化分配与固定策略之间的对比。仅使用前沿模型会将能力浪费在常规工作上,而仅使用快速模型则可能在任务变得复杂时失效。

生产测试在成本方面支持情境化分配。但它尚未确定最佳路由标准、最优档位数量,或对其他 Agent 普遍适用的节省幅度。

这些流量来自使用 Open SWE 的 LangChain 自身工程师。该群体了解公司的代码库、Agent 行为和内部工作流程。

外部用户可能会提出结构更不清晰的请求。其他编程环境的任务分布或审查标准也可能不同。

对照模型同样重要。LangChain 选择了最强、最昂贵的档位作为主要对照。已经使用均衡默认模型的团队,应预期可挖掘的空间会更小。

随着模型能力和供应商条款演变,档位分配可能发生变化。路由器并不是对模型品牌的永久排名。

相反,它是一项需要反复评估的运营策略。模型会进步,任务组合会变化,昨天的均衡选项可能成为明天的快速档位。

这也是为什么所报告的 64% 降幅不应被视为通用预测。它是针对一个 Agent、一种工作负载、一周时间和一项对照策略的实测结果。

这项实验仍然有价值,因为它使用的是实时工作,而非合成提示词集合。生产流量能够捕捉到静态基准测试经常遗漏的模糊性、后续互动行为和任务差异。

更有力的后续研究应将实时结果与受控的离线评估结合。LangChain 已将 DeepSWE 等基准测试视为实现可重复比较的潜在路径。

离线测试可以让不同路由器版本在一组固定且具有代表性的任务上重放运行。随后,人工审查可评估正确性、可维护性和所需修改量。

实时测试仍然必不可少,因为用户会围绕 Agent 改变行为。两种方法结合起来,将提供比单独使用任一方法更有力的证据。

固定前沿模型默认设置如今面临更多审视

这一结果给那些将最强模型视为自动生产默认选项的团队带来了压力。

在早期开发阶段,这种默认设置可以理解。使用单一模型能够减少一个变量,让团队专注于工具、提示词、权限和执行可靠性。

但随着流量增长,这一做法越来越难以辩护。异构工作负载迫使组织即使面对需求低得多的请求,也要为最高能力付费。

随着每月编程 Agent 支出的增加,LangChain 感受到了这种压力。据报道,客户也提出了类似担忧,从而促成了 Open SWE 实验。

更广泛的转变,是从模型基准测试转向系统基准测试。顶级模型的得分并不能揭示,Agent 中的每一项任务是否都能从这种能力中获益。

Agent 的结果取决于完整系统。工具质量、检索、权限、状态管理、提示词和人工审查,可能比模型之间的微小差异更重要。

路由增加了另一个系统变量。问题变成:对于每类任务,模型、上下文和运行框架的哪种组合能够产生可接受的结果。

模型供应商已经鼓励按工作负载匹配模型。Anthropic 的模型选择指南建议,在选择时考虑智能水平、速度和成本,而非仅按能力作决定。

LangChain 将这一原则从应用设计延伸到单个 Agent 线程。运行框架不再为整个产品选择一个折中模型,而是按任务作出选择。

这也可能拓宽开放模型的角色。Open SWE 的快速档位采用 GLM-5.3-Flash,LangChain 将其描述为一款开放模型,在其选定曲线上定位接近闭源替代方案。

该实验并未单独测量 GLM 的贡献。报告的是整个路由系统的结果,而不是各个档位之间的随机对比。

不过,路由可以为原本不会成为组织范围默认选项的模型创造实际切入点。更窄的档位可在产生真实结果数据的同时限制风险暴露。

供应商多样性也能降低对单一模型产品线的依赖。LangChain 的通用接口让团队无需重建 Agent 架构,便可替换某个档位。

这种灵活性也引入了运营复杂性。不同供应商在工具调用行为、上下文限制、缓存规则和安全控制方面可能有所不同。

纸面上看似高效的路由,可能会因模型以不同方式格式化工具参数而失效。因此,跨供应商测试应成为评估流程的一部分。

安全策略也必须随所选路由执行。敏感的代码仓库数据不应仅因某个模型适合较低成本档位,就被发送给该供应商。

团队在比较模型能力前,需要明确的资格规则。合规性、部署区域、数据保留和工具支持,可能会直接排除一些候选方案。

路由只能在已获准处理该任务数据和执行相关操作的模型之间进行。成本优化不能替代访问控制。

分类器本身也形成了另一道信任边界。被操纵或含糊的请求,可能以非预期方式影响档位选择。

对于编程 Agent,这种影响可能超出答案质量。所选模型可能获得 Shell 访问权限、代码仓库凭据,或提出修改建议的能力。

Open SWE 的架构采用隔离、线程范围内的环境,但其文档也警告称,编程沙箱仍需遵循最小权限凭据原则,并设置经过细致定制的审批机制。

模型路由应在每个档位中保留这些控制措施。较弱模型不应为了弥补推理能力不足而获得更广泛的权限。

对于评估这类系统的用户而言,可追溯性与标题所强调的节省同样重要。运营人员应能够解释由哪个模型处理了某项任务,以及原因何在。

这些记录可支持调试、审计审查和后续重放。它也能让团队拥有调整档位标准的证据,而非依赖轶事。

一套实用的AI 工作流可以帮助团队向利益相关方汇总路由变更、结果指标和反复出现的失败情况。

LangChain 模型路由器测试后值得关注的事项

三个信号将显示,运行框架层面的路由是否会成为持久的 Agent 模式,还是仅停留在有前景的内部实验。

第一个信号是受控基准测试表现。LangChain 表示,希望针对 DeepSWE 或其他编程基准测试路由方案。

可重复的评估能够检验分类器是否持续将困难任务分配给有能力的模型。它还可以衡量拉取请求合并以外的质量表现。

关注通过率、人工审查评分、回归问题数量和所需纠正工作量。如果经路由的结果仍保持可比,这些指标将强化相关论据。

如果较低档位生成的修改能通过表面检查,却需要更多维护工作,则会削弱这一论据。稳定的数据集也能使路由器修订更易于比较。

第二个信号是线程中途重新路由。Open SWE 目前根据最初的人类请求作出一次决策,并在整个线程中保持使用同一模型。

LangChain 已将重新路由确定为未来方向。触发因素可能包括用户请求变更、反复的工具失败、负面情绪,或意料之外的任务复杂度。

成功的重新路由将解决该系统最明显的局限。它可以挽救分类不足的工作,而无需从一开始就分配前沿模型能力。

其中的权衡涉及上下文复用。切换模型可能失去提示词缓存收益,并迫使新模型重新处理对话。

团队应关注 LangChain 是否发布明确的升级规则。有用的实现方式应解释,何时切换的成本低于继续使用能力不足的模型。

第三个信号是跨子 Agent 的表现。Open SWE 的子 Agent 目前独立于线程级路由器选择模型。

较长的 Agent 运行过程可将研究、测试分析或代码仓库探索委派给专门的工作单元。这些任务可能需要不同的能力水平。

协调子 Agent 路由可能提高节省幅度,因为单个线程可能包含许多模型调用。但它也可能放大分类错误。

因此,证据应覆盖整体任务结果,而非孤立的调用成本。若廉价子 Agent 向主 Agent 提供不完整证据,可能使整个运行变得更加昂贵。

更广泛的采用将取决于其他团队是否能在不同工作负载下复现 LangChain 的结果。客户支持、研究和数据 Agent 并不具备 Open SWE 的任务结构。

每种类型都需要自己的成功定义。支持 Agent 可能优化问题解决率和升级率,而研究 Agent 则可能优先关注来源准确性和覆盖范围。

这正是该实验带来的持久教训。路由不是粘贴在模型目录前的通用提示词。

它是由轨迹、任务类别、模型证据和可衡量结果构成的领域特定控制系统。运行框架是它的天然归宿,因为框架本来就在协调这些要素。

LangChain 的数据为测试这种设计提供了可信理由。但它们不足以证明应在未进行本地评估的情况下照搬其三档设置。

团队应先梳理真实流量,并在启用自动路由前定义失败标准。他们还应保留固定模型的后备方案,以应对分类器错误或不确定请求。

下一个问题不再是每个 Agent 是否都应使用最强模型,而是团队能否识别前沿推理在哪些地方会改变结果,并将其留给这些时刻。

如果受控基准测试、线程中途升级和子 Agent 路由都支持初步结果,LangChain 模型路由器将不只是一次成本实验。它将提供一种根据实际工作分配模型智能的实用架构。

 
 

免费开始使用

一款本地优先的AI助手

为了获得更好的人工智能体验,

remio 目前仅支持Windows 10+ (x64)和M-Chip Mac 。

你的 AI 工作伙伴

和 remio 一起高效工作

规划、创作、交付

一站式完成

bottom of page