大多数 Agent 轮次并不需要前沿模型：路由这笔账现在公开了
2026 年 8 月中旬，三个独立发布的成果给 Agent 内部的模型路由拿出了具体数字——结论都指向同一点：前沿模型只该碰其中很小一部分轮次。
摘要
AI Agent 会把很多步骤串起来跑，而过去团队往往从头到尾都用同一个昂贵模型。新的评测基准和工具表明，小模型、便宜的模型足以应付大部分步骤，只有难啃的那些才交给昂贵模型——成本大幅下降，质量损失却不大。
过去一年，生产环境里 Agent 的默认思路是「挑一个强模型，然后为每一轮付费」。到 2026 年 8 月 15 日那一周，另一种做法终于有了数字支撑，而从业者已经围着它讨论了好几个月：逐轮路由，让前沿模型只处理真正需要它的少数步骤。三个独立发布的结果高度一致——大约 90% 以上的轮次，中等规模模型就能处理得很好；成本差距大到不做路由，反而成了昂贵的选择。
那个 7%
LangChain 拿 NVIDIA 的 Switchyard 路由库，在自家的 Deep Agents 评测套件上跑了基准测试——共 145 个多步任务——结果只有 7% 的轮次需要 Claude Opus 4.8，剩下 93% 由一个 30B 模型完成。综合下来：成本降低 74%，准确率大约损失 6 个百分点。
7% 这个数字才是关键。它说的不是 Agent 与 Agent 之间的路由（这个问题本站此前归为推荐问题讨论过），而是单个 Agent 在一次执行循环内部、模型与模型之间的路由。真正需要前沿模型的轮次，是那些规划上的转折点、工具返回结果含义不明的时刻，以及从失败中恢复的节点。其余所有事情——拼参数、校验结果、派发子 Agent、格式化输出——都可以交给更便宜的权重去做。
NVIDIA 亲自发布的 Nemotron 3.5 Lightning，围绕的正是这一判断。它是一个 30B 的混合专家模型（MoE，每次推理只激活一部分参数），实际激活参数 3B，明确瞄准“长时运行智能体的高吞吐执行层”——工具调用、结果校验、子智能体委派。它的卖点不在与前沿模型正面竞争，而在于它是承载那 93% 请求的合适底座。
同样的分布，也出现在生产环境的降本实践中
Connor Heggie 讲过 Unify 如何在两周内把智能体成本砍掉 95%，这相当于从一线从业者视角看到了同一种分布。他列举的几个抓手——提示缓存命中率优化、OpenAI 每秒 15 次请求的缓存上限、把子智能体当作函数调用、带键的记忆——全都是让便宜路径更便宜、让昂贵路径更少出现的技巧。在不牺牲质量的前提下省下 95%，只有一种可能：那个贵模型其实没参与多少真正关键推理。
同一场对话里还有个相关提示：用作裁判的模型（LLM judge）必须与被评判的模型来自不同家族。这是评估上的约束，但它同样影响路由——裁判本身就是路由图里的一个节点，它的成本账也受同一个分布支配。
综合这三方信息，可以提炼出一条从业者的经验法则：设计路由表时，默认前沿模型只该看到一小部分轮次。如果它看到的比这多，要么你的任务确实端到端都很难（这种情况很少），要么你的路由器调得还不够。
为什么成本账终于算得过来了
要让“智能体内部路由”成为默认做法，得先满足两个条件。
第一，30B 级别的开源模型必须好用到能胜任工具调用——在被交办的多数轮次里不能悄悄失败。Nemotron 3.5 Lightning 和 Meta 的 Muse Glimmer 就是这一门槛已被跨过的实证：两者都在截至 2026 年 8 月 15 日那一周发布，都是 30B，都明确面向本地智能体工作流，包括多步工具调用与失败恢复。其中 Muse Glimmer 用 4 位量化就能跑在 20GB 以内，这直接改变了便宜路径的部署形态。
其次，路由决策本身必须变得既便宜又可靠。Switchyard 是这里具体的产物，但更广泛的趋势是：路由器正在成为生产级 Agent 运行时的标准组件，而不再是实验室里的新鲜玩意。Anthropic 的 Managed Agents 博文把会话、执行框架和沙箱设计成可互换的接口——这种设计只有在接口背后的模型也能按轮次替换时才有价值。
这对 Agent 架构意味着什么
实际结果是，Agent 设计现在有两个循环，而不是一个。一个是 Agent 自己跑的语义循环（规划、执行、观察、修正），另一个是底层的路由循环，负责把每一步分配到某个模型层级。过去把模型选择当作部署时常量的开发者，现在开始把它当作每次调用都要做的决策。
有几个影响值得说清楚：
-
提示缓存变成层级专属的。 Unify 的缓存工作只有在同一层级持续命中相同前缀时才有回报。如果路由在对话中途切换模型，缓存局部性就被破坏了。Heggie 提到的每秒 15 次请求的缓存上限，会实际限制你能多激进地拆分流量。
-
评估必须按层级做，不能只看端到端。 如果 Opus 处理 7% 的轮次，一个 30B 模型处理 93%，端到端评估会掩盖任一层的退化。LangSmith 的 Engine 能把生产环境中的失败聚类成问题并提出修复方案，但它的大部分输出会集中在便宜的那一层，因为绝大多数轮次都发生在那里。
-
“不同家族”评审约束会叠加。 如果执行器是一个 30B 模型，规划器是 Opus，而评审必须和前两者都不同家族，那你至少要有三个路由端点，每个都有自己的成本结构。
-
在单一模型上测出的基准不再能描述你的系统。 即便是 Gemini 3.7 Flash 的 AutomationBench 和 AnalystAgent 结果，描述的也是单模型配置；一个路由系统的数字会完全不同。
六点准确率的代价，值得细看
LangChain 的基准测试给出的是：成本降低 74%，准确率损失约 6 个点。这笔交易并不自动划算——它完全取决于失败长什么样。如果这 6 个点随机散落在简单任务上，多半靠改进路由规则就能找回来大半。但如果它们扎堆出现在某种特定的失败模式里（比如过早锚定初始假设），那就干脆把这些轮次直接丢给高端模型。
这 6 个点几乎可以肯定不是均匀的质量下滑。它们是一组具体的、路由器判断出错的轮次，而找出究竟是哪些轮次，才是真正要做的工程活。这正是生产环境链路挖掘（trace mining）与路由的交汇处：失败不是均匀分布的，路由器分档也不应该均匀。
在相信「路由会带来多少准确率损失」这种标题结论之前，先对失败做聚类。6 个点的下降如果集中在少数几种模式上，那是能修的路由 bug；如果均匀铺开，说明便宜模型还撑不起你的任务，再怎么调路由器也救不回来。
不太舒服的地方
Agent 内部路由把有价值的工程活往下压了一层。以前只要争论「选哪个模型」就够了；现在要争论的是：每一轮如何在模型之间取舍的路由策略、分档分别打分的评测机制，以及让这一切在经济上成立的缓存拓扑。由成本驱动的 Agent 架构，已经不再是「优化问题」，而是首要的结构性决策——那个 7% 不是茶余饭后的谈资，而是一条设计约束，反过来决定了 Agent 运行时必须暴露哪些能力。
这个季度还在生产环境的 Agent 里每一轮都跑同一个模型的团队，等于为一模一样的输出多付了大约四倍的钱。这个差距足够大——等这些基准测试传开，财务团队是不会放过它的。