973 个真实编码 Agent 线程，一半永远调用最强模型，另一半交给路由器挑模型。

结果有点反直觉。路由组的中位成本从 2.61 美元降到 0.94 美元，少了 64%。PR 合并率没有掉，反而是 29.2%，对照组是 27.3%。统计上没有显著差异，但至少没有出现质量塌陷。

更有意思的是另一组实验。LangChain 让一半线程永远走最快、最便宜的模型，试验不到一天就停了。工程师几乎立刻反馈产出质量不够，工作被打断了。

这两件事放在一起，才是模型路由最该被理解的样子。

它不是把贵模型换成便宜模型的开关。它是在每个任务开始前，替团队判断一件不舒服但躲不开的事，什么质量算够，谁来为不够负责。

一张榜单，解决不了一张账单

最近看 Coding Agent 的榜单，很容易被一种叙事带着走。谁分数最高，谁就是默认答案。

但实际做 Agent 的人都知道，默认答案往往最贵。Artificial Analysis 的数据里，Claude Sonnet 5.5 max 在 Claude Code 的测试中位列前列，单任务成本最高可以到 14.19 美元。这个数字并不荒唐。遇到复杂重构、跨仓库排查、浏览器操作或连续修复时，强模型确实会省掉很多人肉接力。

问题出在另一头。

你的 Agent 不会每天都在做复杂重构。它还会跑测试、整理日志、定位一个明确报错、补一条边界用例、回答代码库里已有答案的问题。拿最强模型处理这些活，就像让资深架构师去逐条改格式。结果不是质量更好，而是账单更胖，队列更长。

很多团队已经意识到这个问题，于是开始做一个朴素版本的路由，低价模型优先，不行再升级。听着很对，可一上线就会发现事情没那么简单。

因为「不行」到底指什么，通常没有人写清楚。

是模型没产出代码？测试挂了？PR 没被合并？用户连续追问两次？还是它把一个本可十分钟完成的问题，拖成了两小时的来回？不同任务的失败形态完全不同。只看 token 单价的路由，最后常常会变成一种很精致的自欺欺人，调用费用少了，返工费用却悄悄转给了研发团队。

模型路由要算的从来不是模型价格，而是完成一个有效任务的总成本。

先把三层东西拆开，不然系统会越做越别扭

我见过不少 Agent 架构图，把 LangGraph、模型选择、供应商故障转移全画成一块「智能编排」。图很漂亮，代码通常很难改。

这几个概念应该分层。

工作流编排管的是任务怎么走。比如用户提交一个 Jira 链接，Agent 拉取上下文，派一个子 Agent 查代码，派另一个子 Agent 找测试，汇总后创建 PR。LangGraph 这类框架最擅长处理状态、分支、重试和人工审批。它回答的是下一步做什么。

模型路由管的是这一步由哪个模型做。它接到的不是抽象的「用户问题」，而是已经被 harness 组装过的上下文，包括任务类型、仓库语言、工具权限、历史消息、预计时长，甚至当前的预算余量。它回答的是谁来做更合适。

提供商路由则是更底的一层。某个模型在 A 厂商超时，是否切去 B 厂商的同名模型。某个区域限流，是否换 endpoint。它关心可用性、延迟和价格，不该替你理解业务意图。

把这三层混在一起，早期很省代码，后期每一次改价和换模型都会牵动图状态。尤其是 Java 或 Spring 团队，常会把模型调用封成一个万能 Service，再在里面塞满 if else。半年之后，没人敢动。

比较稳妥的做法是让工作流节点表达业务动作，让 Router 只输出一个清晰的决策对象，比如 tier、model、原因、预算和回退条件。底层 Gateway 负责把这个决策可靠地送出去。这样你要从 GPT 换到开源模型，或者给某条链路加供应商容灾，不需要改动整个图。

分层不炫技。它是在给未来的变化留位置。

LangChain 的实验，真正值得抄的是验证方法

LangChain 这次的样本是 Open SWE，一个从 Slack 和 Web UI 接收编码请求的开源 Agent。他们没有先写一篇「智能路由架构设计」，而是先翻了一周的 trace。

这一步看起来笨，实际上最重要。

团队把线程按任务类型标注。新功能占 22%，bug 修复占 17%，测试或无操作请求占 16%。再把线程成本和 Agent 调用轮数放进来，他们看到一个很直观的分布，功能调查更长、更贵，测试和发布操作大多短而便宜。

如果没有这张任务分布图，所谓分层只是在猜。你以为便宜模型适合简单任务，可你的「简单任务」也许需要读一堆内部约定。你以为复杂任务一定要上前沿模型，实际上它可能只是一个有明确断言的单文件修复。

接着，他们选了三档模型。快速档使用 GLM-5.3-Flash，平衡档使用 GPT-5.6 Sol，性能档使用 GPT-6 Astra。这里没什么神秘算法，路由器读第一条用户消息，根据每档的自然语言规则选择一个模型，并且一个线程从头到尾固定使用这个选择。

这甚至算不上很复杂的 Router。

但它有一个经常被忽略的优点，决策规则和 Open SWE 的真实任务绑在一起。比如测试和发布程序偏向快速档，复杂的功能调查更可能走高档。通用网关拿不到这些上下文，harness 拿得到。所以路由应该靠近 Agent，而不是躲在一个只看请求体的公共 API 后面。

很多朋友一上来就想训练一个分类器，或者让模型给自己打 0 到 1 的置信度。我不反对，但那是第二步。没有真实任务分类、没有 outcome 指标时，你只是把一个不透明的猜测，升级成了一个更昂贵的不透明猜测。

质量门槛，要在路由上线前写下来

Open SWE 的 A/B 测试没有只看调用成功率。他们抓了两个 outcome。

第一是 PR 是否合并。这是主指标。它不完美，PR 是否合并会受 reviewer、排期和需求变化影响，但对一个编码 Agent 来说，它至少比「模型回答了」更接近交付结果。

第二是用户的点赞和点踩。它很稀疏，却能抓到纯数值看不见的东西。比如有工程师直接抱怨，一个很简单的问题不该被送到高性能档，太浪费钱。也有人在快速档的实验里很快指出，产出没法用。

两类信号要一起看。PR 合并率像仪表盘，用户反馈更像发动机异响。

在 973 个线程的主实验中，路由组和总是使用 GPT-6 Astra 的对照组相比，合并 PR 比例是 29.2% 对 27.3%，p 值是 0.49。PR 打开率是 38.9% 对 39.6%，p 值是 0.82。数据不能证明路由更好，但没有显示出质量退化。

成本的变化则非常明显。路由后的中位线程成本为 0.94 美元，对照组是 2.61 美元。平均成本低了 42%，p90 低了 37%。这很关键，因为它说明节省不是靠几个特别便宜的离群任务堆出来的。

路由组内部，56% 的线程走平衡档，34% 走快速档，只有 10% 走性能档。三档中位成本分别是 0.097 美元、1.50 美元和 2.88 美元，最便宜和最贵相差接近 30 倍。

这个分布给了我们一个很现实的提醒。大多数 Agent 请求并不需要最强模型，但那 10% 往往决定了用户是否还敢把关键任务交给你。

因此质量门槛不能只写「成功率不下降」。应该按任务拆开。

对于代码修改，可以看测试是否通过、PR 是否被合并、人工 review 的修改次数。对于问答，可以看一次解决率、追问率、人工转接率。对于自动化流程，可以看完成率、人工接管率、越权调用和恢复时间。每一项都要有可接受区间，路由上线后再按周对比。

没有这条线，路由就是在拿用户体验赌成本。

规则路由并不土，前提是你愿意维护它

很多工程师对规则有天然戒心。规则多了会腐化，这话没错。但在模型路由这个问题上，一个可审计的规则集，通常比一个黑箱评分器更适合第一版。

原因很简单，模型能力和业务任务都在变。

今天你可能规定，带有「只跑测试」「解释报错」「生成 release note」的任务进快速档。明天团队引入一个新的 monorepo，测试命令本身就需要跨服务推理，这条规则就得撤。把每一次改动放进 eval 集和变更记录里，规则就不是僵硬的配置，而是一组可以回归测试的产品假设。

这里可以借一点传统后端的直觉。Spring 里的限流、熔断、灰度，从来不是因为系统「不智能」，才写成明确策略。恰恰是因为它们影响真实用户，所以必须能解释、能回放、能回滚。模型路由也一样。

一套够用的第一版，不需要花哨。

你可以先给每个请求打四个标签，任务类型、风险等级、预计上下文规模、是否要求产出可执行变更。再用这些标签决定默认档位。对低风险且有明确验收条件的任务，下探一档。对涉及生产权限、跨模块设计、模糊需求或用户已表达不满意的任务，直接上调。

每一次路由都记录下来，包括输入摘要、选中的 tier、模型、耗时、成本、最终 outcome 和是否人工升级。没有 trace 的 Router 不是系统，只是一段看不见的随机行为。

别把升级机制做成置信度数字游戏

不少路由方案会让廉价模型自报一个置信度，低于阈值就升级。这个思路可用，但很容易被误解。

模型说自己有 0.91 的把握，不等于它真的有 91% 的正确率。不同任务、不同提示词、不同模型版本的分数根本不可直接比较。更麻烦的是，模型通常不知道自己遗漏了哪些代码库上下文。

所以置信度只能是一个信号，不能当裁判。

更可靠的升级条件，应该尽量来自可观察的事件。比如工具连续两次失败、检索没有命中关键文件、测试第一次修复后仍然失败、计划超出预计轮数、用户补充了新目标、生成的 diff 超过风险阈值。它们不一定比置信度更优雅，但它们更接近工程事实。

还有一个常被忽视的成本，跨模型切换会丢掉 prompt cache。LangChain 也提到，如果一个线程中途升级，新模型可能要把对话重新读一遍。同步交互里这笔钱不小。异步 Agent 则不同，用户两次输入之间 cache 常常已经过期，改档未必比硬扛更贵。

所以中途路由不是必选项。第一版把模型固定到线程结束，反而更容易测清楚。等你确认哪些线程确实会在中途变质，再加重路由。工程上最危险的不是少一个功能，而是先引入一个无法归因的变量。

我会怎么给一个 Java 团队落第一版

如果 Channing 的团队要把 Router 放进一个 Spring Boot 加 LangGraph 的 Agent 平台，我不会从模型列表开始。我会先挑一个边界清楚的场景，例如内部代码问答和低风险修复建议，避开直接执行生产操作。

第一周只做观测。把现有单模型请求按任务标签、上下文长度、工具轮次、成本、延迟、是否解决记录下来。样本不必追求大而全，关键是覆盖团队最常见的请求。此时不要改用户路径。

第二周做离线回放。抽一批已经结束的任务，用两到三档候选模型复跑，人工或用明确规则评分。把「性能档必须赢」的任务找出来，也把「快速档完全够用」的任务找出来。你会发现任务边界比模型名更有价值。

第三周小流量 A/B。把 Router 接在 Agent harness 的模型选择 Middleware 上，工作流图保持不变。设一个硬回退，任何失败、超时、关键工具权限不足，都回到稳定档或转人工。此时把成本看板和 outcome 看板放在一起，不要分开。

第四周才讨论自动升级。根据前三周真实的失败样本，增加极少数升级条件。每加一条，补一条回归用例。你不需要证明路由器聪明，只需要证明它没有把不该省的钱省掉。

这条路看起来慢，实际会比一口气做全自动分诊快得多。因为每一周都能得到一组能推翻自己假设的数据。

省下来的钱，不该成为质量债

LangChain 的 64% 很诱人，但它不是一个可复制的常数。它依赖 Open SWE 的任务结构、三档模型、提示词、工具集，以及用合并 PR 衡量成果的方式。换一个团队，这些数字大概率会变。

真正可以带走的是他们的姿势，先看真实请求，再定义质量，再让成本去竞争。

模型越来越多，模型价格也会继续下探。以后 Router 的工作可能不只是挑一个 LLM，还会挑检索策略、Sandbox 规格、是否启用浏览器、子 Agent 数量。到那时，harness 其实更像一个调度系统。

可再复杂的调度，第一责任仍然不变。

用户把任务交给 Agent 时，买的不是一次便宜调用，而是一个能被交付、能被解释、出问题有人接住的结果。路由器如果能守住这条线，才配得上它省下来的每一分钱。

参考资料