LangChain把模型路由放进Agent Harness

一个有边界的成本实验

LangChain在2026年10月1日发布《How to Build a Model Router in the Harness》，披露了Open SWE内部模型路由实验。这个 news peg 是一组可复查的生产数据：总计973个threads，一半进入路由器，一半始终使用最强模型GPT-6 Astra，成本分布和PR结果被放到同一张表里比较。

这组结果最容易被误读的地方，是把成本下降写成质量提升。原文没有给出这样的结论。LangChain的说法是，路由组中位线程成本为$0.94，对照组为$2.61，相对always GPT-6 Astra基线低64%；同时，PR合并率为29.2% vs 27.3%，统计检验为p=0.49，PR打开率为38.9% vs 39.6%，统计检验为p=0.82。这些数字支持“质量没有可测下降”，不支持“质量显著提高”。

样本边界同样需要写清。实验对象是LangChain自己的Open SWE，它是一个开源异步coding agent，用于调查代码库、实现变更、验证结果、打开或更新PR，也能做PR review、CI跟踪和反馈响应。Open SWE README还强调项目处于active development，正确性、稳定性和兼容性并不保证。因此，这篇文章更适合作为agent harness路由设计案例，而不是所有agent系统的通用成本承诺。

对开发者和平台团队来说，重点在路由位置的变化。LangChain把路由从“外部网关按模型价格分流”改成“harness内部按任务上下文决策”。当agent开始承担长线程、多工具、多轮反馈的工程任务，模型选择就不再是一次API参数选择，而是和任务分类、trace、eval、成功指标绑定的运行时策略。

数字怎么读

LangChain的第一轮A/B测试设计很直接：生产线程随机分流，一组走模型路由，一组始终使用GPT-6 Astra。路由器在每个thread开始时只选一次模型，之后整个thread沿用这个选择。换言之，它还不是一个会在执行中途反复切换模型的调度器，也没有解决“问答线程中途变成修bug任务”这类复杂度漂移问题。

指标	路由组	对照组	读法
样本范围	合计973个threads	合计973个threads	第一轮生产A/B测试总样本，不是公开benchmark全集。
中位线程成本	$0.94	$2.61	相对始终使用GPT-6 Astra，路由组低64%。
均值与p90成本	均值降42%，p90降37%	基线为always GPT-6 Astra	节省不是少数便宜任务拉低中位数。
PR合并率	29.2%	27.3%	p=0.49，不能写成质量显著提高。
PR打开率	38.9%	39.6%	p=0.82，说明打开PR的比例基本持平。
路由去向	56% balanced，34% fast，10% performance	全部GPT-6 Astra	大多数线程没有被送到最强档。
分档中位成本	fast $0.097，balanced $1.50，performance $2.88	控制组$2.61	三档之间约30倍价差。

这里有两个关键口径。第一，成本指标写的是LLM cost per thread，而不是完整agent平台总成本。它不包括工程师等待成本、失败返工、沙盒费用、日志存储和后续人工review成本。第二，质量指标主要来自PR结果和稀疏用户反馈。PR是否被合并比点赞踩更稳定，但它仍然只是代理变量：PR能被合并，并不等于更少bug、更短review时间或更高长期可维护性。

原文还提到第二个方向的对照实验：把路由器与始终使用fast模型比较。LangChain说这轮测试在一天内结束，原因是工程师几乎立即反馈fast-only组输出质量有问题，已经干扰生产力；由于提前终止，它没有产生统计意义上的结果。这段不能被写成“fast模型一定不可用”，只能说明在Open SWE当时的真实任务组合里，单一低价模型很快暴露质量风险。

为什么路由要放进harness

LangChain文章反复强调的设计判断，是model router belongs in the agent harness, not a generic gateway。理由并不复杂：通用网关通常看得到模型列表、价格、延迟和调用量，却看不到一个agent正在处理什么任务、带了哪些工具、仓库上下文是什么、用户是要求解释代码还是改代码、历史反馈在哪里出错。对coding agent而言，这些信息恰恰决定了“便宜模型够不够用”。

Open SWE的路由器有三部分：base prompt、每个tier的criteria，以及负责读入用户请求并选择tier的classifier model。LangChain先从LangSmith traces里抽取thread-level数据，观察请求类型、成本和turn count，再用一周交互线程做LLM分类。文章给出的任务分布显示，新功能占22%，bug fix占17%，test或no-op运行占16%。这些分类不是严格标签，而是基于thread title和metadata的启发式结果。

这一步很关键，因为路由不是“便宜模型优先”的同义词。一个release procedure可能很短也很便宜，一个feature investigation可能更长、更贵、调用更多工具。LangChain用成本和invocation count近似任务复杂度，再结合各模型厂商对模型适用场景的说明，为fast、balanced、performance三档写criteria。最终fast档选择GLM-5.3-Flash，balanced档选择GPT-5.6 Sol，performance档选择GPT-6 Astra。

LangGraph和LangSmith提供了这个判断能够落地的背景。LangGraph文档强调，它允许在同一graph里混合确定性步骤和LLM驱动步骤，支持持久执行、人类介入、memory和生产部署。LangSmith Observability文档则把trace定义为agent在生产中做了什么的记录，并用于debug failures、monitor quality和build datasets。放到Open SWE案例里，模型路由不是一个孤立模块，而是靠trace理解任务空间，靠生产结果判断是否退化，靠eval补离线验证缺口。

实验能证明什么，不能证明什么

这篇文章能强证明的，是“在Open SWE这一生产样本上，把所有线程都交给最强模型不是成本最优策略”。路由后只有10%线程进入performance档，说明至少在LangChain自己的任务池中，大量请求可以由balanced或fast模型承担。结合$0.097、$1.50和$2.88的分档中位成本，路由的经济性来自避免把低复杂度任务送进高价模型，而不是压低单个模型价格。

它也能中等强度地支持一个工程判断：路由器需要了解任务，而任务理解通常在harness里完成。Open SWE知道用户消息、仓库、工具、计划、反馈和PR状态；LangSmith能把这些执行痕迹变成可分组、可回放、可评估的数据。网关当然可以做供应商抽象和价格策略，但如果网关不知道“这次是解释一个测试失败，还是要跨仓库改动并等待CI”，它只能做粗粒度分流。

不能从这篇文章推出的结论同样重要。它不能证明路由提高了代码质量，因为PR merged的差异没有统计显著性。它不能证明任意agent都能节省64%，因为Open SWE的任务组合、模型价格、工程师反馈习惯和PR流程都很特殊。它也不能证明一次性线程起点路由已经足够，因为原文明确把mid-thread rerouting放进what’s next，并指出切换模型会丢掉prompt cache，新模型需要以全价重新读thread。

更保守的读法是：LangChain把agent成本优化从“模型价格表”推进到“生产工作负载实验”。这比单纯发布一个路由middleware更有价值，因为它给出了错误可能在哪里出现。若routing criteria写得过于乐观，便宜模型会吞掉复杂任务；若一律偏向最强模型，成本会在规模化后失控；若只看离线benchmark，真实PR流程里的reviewability、CI反馈和用户耐心又可能缺席。

对团队的实际启发

第一类读者是已经有内部agent的工程团队。最直接的行动不是马上接入某个路由middleware，而是先把任务空间量化：过去一周或一个月的请求里，多少是问答、多少是小改动、多少是跨模块实现、多少是release或测试流程；每类任务的turn count、token成本、失败率和人工返工时间分别是多少。没有这张任务地图，路由prompt只能靠想象写criteria。

第二类读者是平台与基础设施团队。LangChain的案例说明，成本优化要绑定结果指标，不能只看调用侧账单。Open SWE用merged PR作为主指标，用user feedback捕捉“路由错了”的主观信号，这已经比单看token账单更接近业务结果。但对企业生产环境来说，还应补上review耗时、CI失败率、rollback率、敏感文件触达和权限升级次数。否则，便宜模型可能把成本从LLM账单转移到人工排障。

第三类读者是模型和网关厂商。通用模型网关可以继续提供价格、配额、fallback和供应商抽象，但如果想介入agent路由，就必须接入更深的上下文：任务类型、工具清单、历史trace、组织政策、沙盒能力和质量门槛。LangChain把路由放进harness，本质上是在说模型选择已经成为agent产品逻辑的一部分，而不是基础设施层可以完全外包的功能。

还有一个容易被忽略的点：路由器本身也需要被评测。原文建议后续用DeepSWE或其他coding benchmark评估routing decisions against a controlled baseline，避免只靠生产A/B。这条路线值得跟进，因为线上A/B更接近真实流量，但代价是用户会暴露在不成熟策略下；离线eval更可复现，但必须代表真实任务。成熟做法大概率是两者结合：离线eval挡住明显退化，线上A/B验证成本与生产指标。

接下来看什么

接下来最应该看的是公开程度。若LangChain后续能公开973个threads的随机分组、任务类别分布、置信区间和失败样本，外部团队就能判断这次实验到底是由大量简单任务带来的自然收益，还是由criteria本身有效识别了复杂度。没有这些细节，案例仍然主要是官方经验分享。

第二个观察点是路由粒度。当前Open SWE只在线程起点选择一次模型，适合异步coding agent的长间隔工作流；但很多agent会在一个会话里从咨询、检索、计划一路走到执行。mid-thread rerouting是否能节省更多，取决于prompt cache损失、上下文重读成本和切换后质量风险。LangChain文章已经把这个问题列为后续方向，说明当前设计并不把一次性选择视为最终形态。

第三个观察点是subagent。如果主agent已经能按任务分流，但subagent仍独立选择模型，长任务里的成本可能还会被子任务放大。对研究、代码迁移和多仓库排障这类工作，subagent往往承担大量探索调用。把subagent纳入统一路由，可能比主线程路由更影响总账单，也更容易引入隐性质量回归。

第四个观察点是供应商无关性。Open SWE这次三档来自不同供应商，fast档还是open model。LangChain强调自己的model interface能跨provider替换模型，这一点会让路由策略更像持续维护的配置和数据资产。随着模型价格和能力频繁变化，真正有价值的不是固定哪三个模型，而是能否快速换掉某一档，并用相同的trace和eval确认结果没有变坏。

最终，这条新闻给出的结论可以很朴素：agent规模化之后，默认最强模型会变成昂贵的保险。路由器要证明自己，不是靠宣称更聪明，而是靠在真实任务里少花钱、少返工、少误判。LangChain这次提供了一个可讨论的样本，下一步要看它能否从公司内部经验变成可迁移的方法论。