目录一、从“为任务选模型”到“为执行时刻选能力”一传统路由为什么在 Agent 场景中不够用二Switchyard 改变的是路由粒度三它更接近运行时控制面而不是提示词技巧二、Stage Router从工具轨迹识别执行阶段一不用另一个 LLM 猜难度而是读取已经发生的事实二偏向 capable tier 的三类信号1、severity错误严重度不是简单的错误计数1.1 信息性错误与能力性错误1.2 Hard override 的治理边界2、spinning动作很多不等于进展很多3、exploring开放式探索何时变成拖延三偏向 efficient tier 的生产信号四信号如何合并为决策1、方向、强度与阈值2、低置信度时的三条路径3、切换模型还需要交接语义三、Escalation Router把“先尝试、后救场”制度化一它判断的是结果而不是请求外观二两次确认的意义在误报与救援速度之间取舍1、Session identity 是状态路由的基础设施2、Judge 失败为何选择 fail open三它的成本不是两层而是三层四、两种 Router 不是替代关系而是两种控制哲学一逐 Turn 双向调节与 Session 单向保险二为什么不应把两者简单叠加五、基准结果应如何解读先看三角比较再看统计边界一Cognition / Devin Desktop真实环境信号强公开证据仍有限二LangChain74% 节省背后的完整账本三真正重要的是三角比较四平均数会掩盖预算尾部六、Router 的核心风险不是选错模型而是看错状态一可观测性缺口会制造虚假的“进展”二模型切换可能破坏隐性状态三安全与权限不能跟随能力层级随意变化四Router 自身也会成为新的故障域七、如何建立一套可信的评测与上线方法一第一步不是选 Router而是画出 Turn 分布二必须保留三条单模型基线和一个 Oracle 上界1、三条可执行基线2、Oracle 不是可部署方案但能判断上限三用 RESCUE、LOSS、SAFE、HARD 看待误路由四影子路由、回放与小流量顺序上线五一个可执行的指标面板八、工程落地把路由当作策略产品而非一次配置一先选择模型对再选择算法二为 Stage Router 设计可解释信号三为 Escalation Router 控制 Judge 税四协议兼容要以语义回归测试为准五预设退出机制九、进一步推演Agent Routing 会走向何处一从二元 tier 走向能力组合二从启发式信号走向可学习策略三路由目标会从“单次成本”转向“成功任务总成本”四路由将迫使 Agent 显式表达进度十、结论真正值得关注的是“状态感知的模型调度”可参考文章与资料干货分享感谢您的阅读大模型路由过去常被理解为一次性的“Prompt 难度分类”请求到达后系统判断它应交给便宜模型还是强模型。但 Agent 不是一次问答而是一条不断变化的执行轨迹。同一任务会在探索、规划、修改、验证、失败恢复之间往返真正需要判断的不是“这个任务难不难”而是“此刻这个 Turn 需要多强的模型”。NVIDIA 于 2026 年 8 月发布并开源的 NeMo Switchyard把路由依据推进到 Tool Result、错误、写入、测试与会话状态。本文在梳理 Stage Router 与 Escalation Router 的基础上进一步分析它作为 Agent 运行时控制面的价值、成本边界、失效模式、评测方法与工程落地路径。需要特别强调截至本文资料核验时项目仍明确标注为 pre-alpha、experimental、not for production use所有结论都应被视为设计启发与实验结果而非成熟产品承诺。一、从“为任务选模型”到“为执行时刻选能力”一传统路由为什么在 Agent 场景中不够用传统 Model Router 的基本单位通常是一条请求。它查看 Prompt 的主题、长度、关键词、复杂度或分类器分数然后在若干模型之间做一次选择。这种方法适合相对独立、输入已经完整的问答翻译可以交给专用模型简单抽取可以交给小模型复杂数学推理则交给强模型。路由判断发生在执行之前默认请求的难度在一次调用内大致稳定。Agent 改变了这个前提。一个“修复陌生仓库中的并发 Bug”任务可能持续几十个 Turn起初需要理解目录结构和调用关系随后要形成假设、定位竞争条件当方案明确后大量工作只是按计划编辑文件测试失败又会迫使系统回到诊断测试通过后还可能进入整理、补注释和生成摘要。任务的名义标签始终是“修 Bug”但每一步所需的推理强度、上下文敏感度与容错能力并不相同。如果只在会话开始时选一次模型会出现两个对称问题全程使用最强模型探索阶段可能稳健却也让文件读取、格式调整、机械编辑等低难 Turn 承担同样昂贵的推理单价全程使用便宜模型常规步骤成本很低却可能在错误恢复、跨文件推理或长链规划处失速。静态路由把一条动态轨迹压缩成一个标签因此天然损失了可优化空间。二Switchyard 改变的是路由粒度Switchyard 的关键变化不是简单增加另一种分类算法而是把决策粒度从“任务级”或“请求级”推进到“Agent Turn 级”。它试图回答最近发生了什么Agent 是否在产生可验证的进展是否反复执行无效动作是否进入错误恢复当前更像开放式探索还是已经收敛为机械执行这种变化可以用一个状态循环表示同一 Agent 任务中的能力需求并非单调变化。在这个框架里强模型与高效模型不再是两个固定的“Agent 人格”而是两个可按 Turn 调度的能力层级。Switchyard 文档使用 capable tier 与 efficient tier前者适合复杂推理、探索和恢复后者适合方案已经收敛后的稳定执行。值得注意的是“capable”与“efficient”是语义角色不绑定某个厂商或参数规模模型更新、供应商迁移或自托管端点替换不应迫使上层 Agent 改写路由逻辑。三它更接近运行时控制面而不是提示词技巧Switchyard 既可作为 Rust 代理服务器也可作为 switchyard-libsy 嵌入宿主程序。服务器接受 OpenAI Chat Completions、OpenAI Responses 和 Anthropic Messages 等接口并把请求翻译到 vLLM、NVIDIA NIM、Ollama 或其他 OpenAI-compatible endpoint。库侧的 Algorithm 抽象决定调用哪个语义目标、以什么顺序调用以及如何组合结果但不强占 HTTP 栈模型调用可以交还给宿主执行。这意味着路由、协议转换、模型传输与 Agent 本身可以解耦。从系统设计看它处在三个平面之间上接 Claude Code、Codex 或其他 Agent 客户端中间保存路由策略、会话状态和观测数据下接不同协议、成本与上下文窗口的模型后端。它处理的不只是“选谁”还包括跨协议翻译、会话亲和、上下文窗口溢出恢复、指标与决策记录。因此更准确的定位是 Agent 模型调用的运行时控制面。二、Stage Router从工具轨迹识别执行阶段一不用另一个 LLM 猜难度而是读取已经发生的事实Stage Router 最有启发性的设计是优先使用 Tool-result History而不是默认再调用一个 Judge LLM。Coding Agent 每次读取文件、搜索符号、执行命令、修改代码和运行测试都会留下结构化痕迹。这些痕迹比 Prompt 的表面难度更接近真实执行状态一个看似简单的修改可能连续报错一个措辞复杂的任务也可能已经形成确定方案只剩批量替换。在每次 LLM Call 之前Stage Router 检查最近若干 Turn 的工具结果并沿两个相反方向累计证据。官方把偏向强模型的一侧称为 WRONG把偏向高效模型的一侧称为 PROGRESS。命名虽然略显绝对但实际含义是“当前轨迹是否显示未解决状态”与“当前轨迹是否显示稳定产出”。二偏向 capable tier 的三类信号1、severity错误严重度不是简单的错误计数1.1 信息性错误与能力性错误severity 关注窗口内错误的性质与强度。并非任何错误都意味着必须升级一次拼写错误、可预期的文件不存在或测试中的已知失败可能只是正常探索成本关键编译失败、权限/上下文问题、反复出现且未被消除的核心错误则更可能说明当前模型无法有效恢复。官方实现还为 critical error 保留 hard override使其无需等待多个弱信号相互印证即可转向 capable tier。1.2 Hard override 的治理边界这体现了一个重要原则路由信号必须区分“信息性失败”和“能力性失败”。前者帮助 Agent 缩小搜索空间后者才表明继续使用当前能力层级的边际收益正在下降。若部署方把所有非零退出码都视为严重错误Router 会频繁误升级若工具适配器吞掉错误语义Router 又会对真正的困境视而不见。2、spinning动作很多不等于进展很多spinning 指深度操作持续发生却缺乏有效 read 或 write 进展的“原地打转”。Agent 可能不断重复相似命令、在同一错误上改写提示、来回切换假设表面 token 与 tool call 都很活跃实际上没有增加新信息也没有形成产出。这类信号比单纯统计调用次数更有价值。高调用量可能来自正常的大仓库检索也可能来自失控循环关键是动作是否带来状态变化。生产系统若要可靠识别 spinning应记录工具类别、目标对象、结果摘要、错误指纹和前后差异而不能只保存“调用过 shell”这样的粗粒度事件。3、exploring开放式探索何时变成拖延exploring 关注持续 read、search、planning却迟迟没有实际修改的状态。探索并非坏事复杂任务通常必须先建立心智模型问题在于探索是否已经超过合理窗口且没有收敛。此时 capable 模型的价值不只是“更聪明”还可能体现在更好的信息压缩、假设排序和停止条件判断。因此exploring 信号不能脱离任务类型解释。代码审计、研究综述和只读诊断本来就可能不产生 write将“无写入”机械等同于“无进展”会让只读型 Agent 被永久送往强模型。工程上应把用户意图、允许的工具集合和任务终态纳入信号语义。三偏向 efficient tier 的生产信号Stage Router 的 PROGRESS 侧核心是 recent_production_intensity最近窗口内是否持续出现 write、edit 等实际产出。其逻辑是当 Agent 已经从“还在决定怎么做”进入“按明确方案稳定执行”高效模型往往足以承担后续工作。但写入不是质量的同义词。一个模型也可能高速地产生错误修改。官方观测来源还区分 tests_passed近期测试通过、存在近期写入且窗口内没有错误时可把运行视为更稳定。部署者可以进一步把代码审查结果、静态分析、格式化、差异规模与回滚事件纳入“有效产出”的定义。真正有价值的不是 write 数量而是被验证的状态推进。四信号如何合并为决策1、方向、强度与阈值Stage Router 将相反方向的信号合并为 signed score再用 tanh 压缩得到 0 到 1 的 confidence。分数符号表示倾向 capable 还是 efficient绝对强度表示证据是否足够。官方设计强调 corroboration一个完整普通信号约得到 0.46略低于推荐起点 confidence_threshold 0.5通常需要第二个方向一致的证据才能跨过阈值critical error 则可直接覆盖。Stage Router 的信号聚合、阈值与回退逻辑。阈值并不是越高越安全。efficient_first 以高效层为默认阈值升高会减少信号触发的升级可能省钱但增加漏救风险capable_first 以强模型为默认阈值升高会减少降级更偏质量但成本更高。官方明确指出已发布阈值与结果来自 efficient_firstcapable_first 仍属实验且没有校准结果因此不应把两个 picker 的同一阈值理解为同一种风险偏好。2、低置信度时的三条路径当信号没有跨过阈值系统可以采取三种行为使用 picker 的默认 tier配置可选 LLM classifier 进行补判若 classifier 失败则 fall open 回到默认 tier。默认推荐配置是 picker efficient_first、confidence_threshold 0.5、recent_turn_window 3且不配置 classifier让多数 Turn 只依靠工具信号完成路由。这个设计把 Judge 从“每次必交的税”降为“证据模糊时的保险”。不过 classifier 仍可能与高效模型共享限流额度额外请求在规模化后放大 429 风险部署时最好给 Judge 独立客户端或配额池并单独统计其 token、延迟与失败率。3、切换模型还需要交接语义模型切换并非只改一个 endpoint。不同模型对历史的关注点、系统提示词和已形成计划的理解可能不同。Stage Router 支持 handoff notes 与 per-tier system prompts升级时可提示“前一模型停滞请接管诊断”降级时可告诉高效模型“方案已收敛请按计划执行”。这类交接信息能降低状态断裂但也可能污染上下文或过度锚定新模型因此应简短、结构化且可审计。三、Escalation Router把“先尝试、后救场”制度化一它判断的是结果而不是请求外观Escalation Router 从弱模型开始。未锁定的每个 Turn系统先调用 weak target 并缓存回复再把该回复追加到轨迹中让 Judge 评估弱模型已经完成的工作。若 Judge 认为无需升级缓存回复直接返回若给出升级票系统累计连续票数。达到 confirmations 后当前弱模型回复被丢弃强模型重新处理该 Turn并将整个 Session 锁定到 strong target。这与前置能力分类器有本质区别。前置分类器预测“这件事看起来难不难”Escalation Router 观察“便宜模型实际做得怎么样”。后验判断可以发现 Prompt 难度无法透露的困境例如工具调用循环、计划漂移、错误反复或回答与执行结果矛盾。Escalation Router 的两次确认、弱回复缓存与单向锁定。二两次确认的意义在误报与救援速度之间取舍官方默认 confirmations 2。一个升级票不会立刻触发强模型下一次若 Judge 拒绝连续计数归零。这样可以过滤偶发误判避免一次不顺就支付长期强模型成本。代价是救援至少晚一个 Turn用户可能先收到一次已被判定为困难但尚未达到确认数的弱回复。当确认数降为 1系统反应更快但更容易误升级提高到 3 或更多则更省强模型调用却可能让弱模型在错误路径上停留过久。这个参数不是纯粹的成本旋钮它同时改变用户体验、错误累积和上下文污染。若错误修改已经写入外部系统晚一个 Turn 的代价可能远高于一次额外模型调用。1、Session identity 是状态路由的基础设施当 confirmations 1 时连续票数必须跨 Turn 保留。官方要求客户端通过 x-switchyard-session-id 提供会话身份没有它每个请求都从零开始路由永远无法锁定。这揭示了状态型 Router 的基本工程要求会话标识必须稳定、隔离且可追踪还要处理超时、并发、分支 Agent 与重试的语义。2、Judge 失败为何选择 fail openJudge 超时、报错或返回不可解析结果时Escalation Router 返回已缓存的弱模型回复并保持原有连续票数不会因 Judge 故障创建强模型锁定。这样可以避免路由组件故障放大为服务不可用也避免异常误触发昂贵路径。但“fail open”意味着质量保障在 Judge 故障期间下降生产环境必须对失败率设告警并根据业务风险考虑更保守的自定义策略。三它的成本不是两层而是三层未升级 Turn 的成本是弱模型调用加 Judge 调用触发升级的那个 Turn 同时支付弱模型、Judge 和强模型三次调用锁定之后才变成直接强模型且跳过 Judge。端到端延迟同样如此未锁定 Turn 必须等待弱模型完成再等待 Judge而触发 Turn 还要等待强模型重做。因此Escalation Router 的经济性取决于三件事弱模型与强模型的价格差有多少 Turn 能留在弱模型Judge 的固定税。LangChain 给出一个实用的排除公式最低卸载比例 Judge 成本 ÷强模型成本 - 弱模型成本这个公式只回答“即使路由判断正确经济上是否可能划算”不能证明 Router 会做出正确判断。如果两模型价差很小所需卸载比例可能超过 100%此时无论如何调 Judge 都不可能省钱如果弱模型是近零边际成本的本地推理价差扩大路由才更可能成立。四、两种 Router 不是替代关系而是两种控制哲学一逐 Turn 双向调节与 Session 单向保险比较维度Stage RouterEscalation Router主要证据Tool result、错误、探索、写入与测试弱模型完成后的轨迹 LLM Judge决策问题当前处于哪种执行阶段弱模型是否持续遇到困难切换方向capable 与 efficient 之间可逐 Turn 升降weak → strong 单向锁定额外模型调用默认无低置信度 classifier 可选未锁定期间 Judge 为核心调用延迟特征接近规则计算开销串行增加弱调用后 Judge 延迟状态要求最近工具轨迹稳定 Session ID 与连续票数典型负载工具密集型 Coding Agent多轮、允许先试后救的 AgentStage Router 像一个连续变速器根据近期轨迹逐 Turn 升降能力适合任务阶段频繁变化。Escalation Router 像保险丝先让便宜模型承担大部分工作持续异常时熔断并永久切换到强模型。前者强调“阶段适配”后者强调“失败救援”。二为什么不应把两者简单叠加直觉上可以先用 Stage Router再用 Escalation Judge 兜底但这会迅速增加状态空间一个 Turn 由哪些信号触发、Judge 看到的是哪个模型的回复、升级是否覆盖 Stage 的降级、Session 锁定后是否仍允许回落都需要明确定义。若解释链不完整出现质量问题时很难判断是模型失败、信号误判、Judge 偏差还是策略冲突。更稳妥的做法是先明确业务风险和瓶颈若主要问题是工具阶段明显、额外延迟不可接受优先验证 Stage Router若工具信号贫乏但多轮轨迹可读、且允许串行 Judge 延迟验证 Escalation只有单一策略证明确有盲区后再设计组合策略并为每条决策路径建立可观察的来源标签。五、基准结果应如何解读先看三角比较再看统计边界一Cognition / Devin Desktop真实环境信号强公开证据仍有限NVIDIA 官方博客披露Cognition 在 Devin Desktop 中实现 staged-routing methodology并向 NVIDIA 内部用户部署真实环境测试。在 FrontierCode Main 上Opus 5 与 Kimi K2.7 动态路由达到 50.6% 准确率平均每任务 3.11 美元与全程 Opus 5 相比准确率低约 2.8 个百分点平均成本低约 28%。这个案例的主要价值不是“28%”本身而是说明同一 Coding Agent Session 内按执行阶段切换模型已经走出纯模拟实验进入真实用户环境验证。但公开材料没有完整披露任务分布、方差、路由比例、Judge/信号配置、延迟变化以及失败类型因此不能外推为任意 Coding Agent 的通用节省率。它更像一条可行性证据而不是可直接套用的商业预测。二LangChain74% 节省背后的完整账本LangChain 在 145 个多步 Agent 任务上测试 Escalation Router任务平均包含 6.3 次模型调用覆盖受政策约束的客服对话、值班事故调查、跨消息/工单/邮件的多步自动化并包含工具使用、多步检索、文件系统操作和长上下文总结。结果如下方案AccuracyCost / runCost / completed taskClaude Opus 4.8 only86.0%$11.45$0.092Opus 4.8 Nemotron 3.5 Lightning routed80.0%$3.00$0.026Nemotron 3.5 Lightning only77.7%$0.72$0.006路由方案把 93% 的模型调用留给 Nemotron仅 7% 交给 Opus但这 7% 的前沿调用占路由总支出的 68.4%Judge 又占 21.2%便宜模型的 93% 调用只占 10.4%。因此“调用比例”与“成本比例”不能混为一谈。少量前沿调用仍可能主导账单Judge 也不是可忽略的附属成本。LangChain 145 个多步任务实验。柱长仅作相对比较精确值见表。三真正重要的是三角比较路由方案相对 Opus-only 节省约 74%准确率下降 6 个百分点且该差距高于单次运行约 2.7 点的波动质量代价是真实的。更值得警惕的是另一条比较路由只比 Nemotron-only 高 2.3 个百分点却把成本从 0.72 美元提高到 3.00 美元约为 4.2 倍2.3 点的提升又小于运行波动LangChain 因此明确表示不能断言该实验中路由战胜了便宜模型。这说明 Router 评估必须同时比较三条基线强模型全程、便宜模型全程、动态路由。只与强模型比较容易把“采用便宜模型的收益”误记为“Router 的收益”只与便宜模型比较又可能忽视生产环境无法预先知道哪些任务困难的现实。Router 的真正价值是以可控的额外成本降低困难任务无人救援的风险而不是自动保证成本与质量同时最优。四平均数会掩盖预算尾部LangChain 五次路由运行中前沿流量比例从 4.1% 到 9.1%平均 6.9%成本从 2.16 美元到 3.61 美元波动 67%。虽然最差路由成本仍约为 Opus-only 的三分之一但这提醒预算制定不能只用平均值。路由器会降低期望成本却可能扩大成本分布上线前应报告 P50、P90、P95、最大值和任务类别分层而非只展示一个均值。六、Router 的核心风险不是选错模型而是看错状态一可观测性缺口会制造虚假的“进展”如果工具只返回自然语言摘要Router 可能无法区分“文件已修改”与“模型声称文件已修改”如果测试工具没有结构化退出码tests_passed 可能被误判如果多个子 Agent 共用会话某个子任务的错误可能污染另一个任务的阶段。路由质量上限受执行轨迹质量限制信号工程往往比调阈值更重要。建议把每次 Tool Result 规范化为最少字段工具类型、目标资源、成功状态、错误类别、状态变化摘要、产出哈希或差异规模、耗时、重试关联和子 Agent 标识。敏感内容可以只保留类别与指纹但不能只留一段不可计算的日志。二模型切换可能破坏隐性状态不同模型对计划、工具 schema、缓存、reasoning item 和消息角色的处理并不完全一致。协议翻译可以保持字段形状却不能保证语义等价。例如一个模型在先前隐藏推理中形成但未显式写出的约束切换后不会自动传递某些供应商的提示缓存边界和 thinking block 规则也不同。因此动态路由要求 Agent 把关键状态外显当前目标、已验证事实、待执行步骤、禁止事项、最近错误与恢复假设应进入可移植的会话内容或结构化 state而不是依赖单一模型的隐性记忆。handoff note 只能补充不应替代状态建模。三安全与权限不能跟随能力层级随意变化更强模型并不等于可以获得更高权限便宜模型也不等于应被限制到无法完成任务。权限决策必须独立于模型路由同一个工具调用应经过统一的身份、授权、参数校验与审计。尤其是写数据库、发布代码、发送消息和执行不可逆操作时Router 只能选择推理资源不能绕过人类确认和策略门禁。四Router 自身也会成为新的故障域代理层增加配置、网络、状态存储、协议翻译与指标采集任何一层出错都可能影响全部模型调用。Switchyard v0.2.0 的发布说明仍列出若干已知问题例如客户端断开后缓存的上游工作可能继续产生费用、部分回退与升级决策在统计中缺少目标归因等。再结合项目明确的 pre-alpha 状态当前更适合沙箱、离线评测和受控流量实验而不是直接置于关键生产路径。七、如何建立一套可信的评测与上线方法一第一步不是选 Router而是画出 Turn 分布从真实 Agent trace 中抽样给每个 Turn 标注任务阶段、工具类型、是否产生有效状态变化、是否需要复杂推理、最终是否成功。至少区分探索、计划、生产、验证、恢复、总结。然后统计各阶段的调用占比、token 占比、延迟与失败率。只有低难 Turn 占比足够高动态路由才有节省空间。二必须保留三条单模型基线和一个 Oracle 上界1、三条可执行基线最低限度应运行 capable-only、efficient-only 与 routed 三组保持 Agent 版本、工具环境、缓存计价、超时和随机性配置一致。对每组至少报告任务成功率、每成功任务成本、端到端延迟、工具调用数、重试数和不可逆错误数。2、Oracle 不是可部署方案但能判断上限离线获得两模型结果后可以构造“每任务选择成功且更便宜结果”的 Oracle估计模型组合的理论上限。若 Oracle 相对最佳单模型几乎没有提升说明模型能力高度重叠再复杂的 Router 也难创造价值若 Oracle 提升显著问题才真正转化为如何从轨迹中预测正确选择。三用 RESCUE、LOSS、SAFE、HARD 看待误路由Stage Router 官方校准思路将重叠任务分成四象限RESCUE 是 capable 失败而 efficient 成功升级反而不利或降级可救LOSS 是 capable 成功而 efficient 失败错误降级会损失质量SAFE 是两者都成功HARD 是两者都失败。名称提示我们模型层级不是严格支配关系强模型并非在每个任务上都更好。阈值选择应优先控制 LOSS再观察 RESCUE 与成本变化。对高风险业务可以给 LOSS 更高权重对批量低风险任务可以容忍少量 LOSS 换取更大卸载。不能仅优化平均准确率因为一次发布错误或错误外发消息的损失可能远超数千次 token 节省。四影子路由、回放与小流量顺序上线建议采用四阶段路径先在历史轨迹上离线回放信号再让 Router 影子决策但不改变实际模型比较其选择与结果随后对可回滚、低风险流量开启 1%—5% 灰度最后才逐步扩大。每阶段都要设置自动停止条件例如任务成功率下降超过阈值、Judge 故障率异常、P95 延迟增加过大或成本尾部超过预算。五一个可执行的指标面板指标组关键指标用途质量成功率、严重失败率、回滚率、人工接管率判断路由是否伤害终态成本每任务、每成功任务、Judge 占比、P95 成本防止均值掩盖尾部延迟首 token、Turn、任务端到端 P50/P95识别串行 Judge 税路由tier 占比、决策来源、升级/降级率、锁定时点解释策略行为信号error、spinning、exploring、production 命中率发现工具语义偏差稳定性429、超时、解析失败、上下文溢出与回退衡量新增故障域八、工程落地把路由当作策略产品而非一次配置一先选择模型对再选择算法Router 的收益来自模型之间互补且存在足够价格差。如果 efficient 模型已经接近 capable 模型可能直接用 efficient-only 更划算如果 efficient 几乎无法完成任何关键 Turn路由只会制造失败与重做。理想模型对应在常规阶段足够可靠、在困难阶段差距明显并且协议、工具调用与上下文能力兼容。评估模型对时不要只看公开榜单。要在自己的 Agent、自己的工具 schema 和自己的上下文长度下测量。模型的“便宜”还包括 token verbosity、工具调用次数、缓存命中、失败重试和推理时延单 token 价格低但输出冗长、频繁误用工具的模型任务级成本可能并不低。二为 Stage Router 设计可解释信号每条信号应有明确定义、时间窗口、权重、例外和样例。比如“探索”应排除只读审计任务“写入”应结合 diff 与验证“错误”应按可恢复性分级“打转”应识别重复目标和错误指纹。记录 decision_source使每个 Turn 能回答“为何选择此模型”。阈值调整应版本化。修改 confidence_threshold、窗口长度或信号权重后必须绑定评测数据、发布日期和回滚条件。把路由配置当成与模型提示词同等重要的产品逻辑而不是随手改动的基础设施参数。三为 Escalation Router 控制 Judge 税Judge 应尽可能短上下文、结构化输出并独立限流。官方默认 trailing window 为 28 条消息、每条截断 500 字符部署者需验证这是否覆盖关键轨迹又不过度消费。还应测量 Judge 的校准升级票的 precision、recall、连续两票的触发分布以及 Judge 对不同任务类别和弱模型表达风格的偏差。当 Judge 成本占比较高可以尝试只在异常信号出现后调用 Judge或使用本地小模型但这已经改变算法应重新评测不能继续引用原始 benchmark。任何“省掉 Judge 调用”的优化都可能降低困难识别率必须用任务终态验证。四协议兼容要以语义回归测试为准Switchyard 能在 OpenAI 与 Anthropic 协议间转换但生产接入仍应准备回归集覆盖工具定义、并行 tool calls、流式事件、结构化输出、reasoning/final item、token 统计、缓存字段、错误 envelope 和 max token 截断。字段被成功序列化不代表 Agent 行为不变最终要比较工具调用序列与任务结果。五预设退出机制路由不一定长期优于单模型。模型价格、能力、上下文窗口和缓存策略都会变化当 efficient 模型迭代到足够强Router 的边际收益可能消失当 capable 降价Judge 税可能不再合理。建议按月或模型版本重跑三角基线并设置“退回单模型”的明确条件。九、进一步推演Agent Routing 会走向何处一从二元 tier 走向能力组合capable/efficient 是易于解释的起点但真实任务可能需要代码专长、视觉理解、超长上下文、低延迟、数据驻留或特定工具可靠性。未来 Router 更可能在多个语义目标间做约束优化而不仅是强弱二选一。选择函数可同时考虑成功概率、边际成本、延迟、容量、隐私区域与当前工具阶段。二从启发式信号走向可学习策略NVIDIA 博客还介绍了 Prefill Router从模型预填充阶段的 residual stream 提取特征用共享 MLP 预测候选模型成功概率再与成本或延迟策略结合。这代表另一条路线不完全依赖人工规则而从工作负载数据学习。它可能提高细粒度预测能力但要求访问模型内部状态、准备可靠标签并应对分布漂移且目前仍属研究方向。可预见的实践不是启发式立刻被学习模型取代而是分层组合安全与权限使用确定性规则明显错误和测试通过使用高精度执行信号模糊区域再由分类器或学习策略判断。这样可以把可解释性留在高风险路径把统计模型用于边界区域。三路由目标会从“单次成本”转向“成功任务总成本”最便宜的 Turn 不一定带来最便宜的任务。弱模型若造成错误修改、重复工具调用或上下文膨胀会把节省转化为后续恢复成本。合理目标函数应优化期望总成本 模型调用 Judge 工具/基础设施 重试恢复 人工接管 失败损失同时约束成功率、尾部延迟和安全事件。只有在任务级目标下Router 才不会为了局部 token 节省而牺牲全局效率。四路由将迫使 Agent 显式表达进度当系统要根据执行阶段换模型Agent 必须更明确地记录计划、证据、修改与验证。这会反过来推动 Agent 架构从“长对话即状态”走向结构化执行账本。即使最终不用 Switchyard这种可观测状态也能改善调试、恢复、评测和人机协作。十、结论真正值得关注的是“状态感知的模型调度”Switchyard 的意义不在于提供了又一个“便宜模型/强模型”开关而在于把 Model Routing 嵌入 Agent 的执行循环。Stage Router 读取工具轨迹用错误、打转、探索、生产与测试信号判断当前 Turn 是需要诊断还是适合机械执行Escalation Router 则让弱模型先做再由 Judge 依据真实结果识别持续困难并以单向锁定提供救援。公开案例同时给出乐观与克制的证据。Cognition 的 Devin Desktop 说明 staged routing 已进入真实用户环境测试LangChain 证明少量前沿调用可以显著降低相对强模型基线的成本却也证明 Router 未必优于便宜模型全程Judge 可能成为第二大支出准确率代价与成本尾部不能被平均节省掩盖。因此专业的结论不是“所有 Agent 都应该路由”而是三条更严格的判断第一只有当任务内部存在明显阶段差异、模型对具有互补性和足够价格差时路由才有经济空间第二路由质量取决于执行轨迹的可观测性与状态语义而不仅是算法名称第三任何收益都必须在 capable-only、efficient-only、routed 三角基线中用每成功任务成本、尾部延迟和风险加权失败来验证。截至 2026 年 8 月Switchyard 仍是快速演化的 pre-alpha 实验软件。适当的使用方式是把它当作一个值得研究的控制面原型在离线回放、影子决策和受控灰度中验证信号建立可解释账本再决定是否进入更关键的执行路径。真正长远的变化是 Agent 系统开始承认能力不是会话开始时一次性选定的资源而应随着执行状态被动态调度。可参考文章与资料NVIDIA NeMo Switchyard GitHub 仓库与 READMENVIDIA 官方博客Route AI Agent Workloads Across Models with NVIDIA NeMo SwitchyardStage Router 官方文档Escalation Router 官方文档LangChainHow many of your agents calls actually need a frontier model?Switchyard v0.2.0 Release NotesNVIDIA 博客引用的 Prefill Router 研究论文 NVIDIA NeMo Switchyard：把模型路由推进到 Agent 执行过程
目录一、从“为任务选模型”到“为执行时刻选能力”一传统路由为什么在 Agent 场景中不够用二Switchyard 改变的是路由粒度三它更接近运行时控制面而不是提示词技巧二、Stage Router从工具轨迹识别执行阶段一不用另一个 LLM 猜难度而是读取已经发生的事实二偏向 capable tier 的三类信号1、severity错误严重度不是简单的错误计数1.1 信息性错误与能力性错误1.2 Hard override 的治理边界2、spinning动作很多不等于进展很多3、exploring开放式探索何时变成拖延三偏向 efficient tier 的生产信号四信号如何合并为决策1、方向、强度与阈值2、低置信度时的三条路径3、切换模型还需要交接语义三、Escalation Router把“先尝试、后救场”制度化一它判断的是结果而不是请求外观二两次确认的意义在误报与救援速度之间取舍1、Session identity 是状态路由的基础设施2、Judge 失败为何选择 fail open三它的成本不是两层而是三层四、两种 Router 不是替代关系而是两种控制哲学一逐 Turn 双向调节与 Session 单向保险二为什么不应把两者简单叠加五、基准结果应如何解读先看三角比较再看统计边界一Cognition / Devin Desktop真实环境信号强公开证据仍有限二LangChain74% 节省背后的完整账本三真正重要的是三角比较四平均数会掩盖预算尾部六、Router 的核心风险不是选错模型而是看错状态一可观测性缺口会制造虚假的“进展”二模型切换可能破坏隐性状态三安全与权限不能跟随能力层级随意变化四Router 自身也会成为新的故障域七、如何建立一套可信的评测与上线方法一第一步不是选 Router而是画出 Turn 分布二必须保留三条单模型基线和一个 Oracle 上界1、三条可执行基线2、Oracle 不是可部署方案但能判断上限三用 RESCUE、LOSS、SAFE、HARD 看待误路由四影子路由、回放与小流量顺序上线五一个可执行的指标面板八、工程落地把路由当作策略产品而非一次配置一先选择模型对再选择算法二为 Stage Router 设计可解释信号三为 Escalation Router 控制 Judge 税四协议兼容要以语义回归测试为准五预设退出机制九、进一步推演Agent Routing 会走向何处一从二元 tier 走向能力组合二从启发式信号走向可学习策略三路由目标会从“单次成本”转向“成功任务总成本”四路由将迫使 Agent 显式表达进度十、结论真正值得关注的是“状态感知的模型调度”可参考文章与资料干货分享感谢您的阅读大模型路由过去常被理解为一次性的“Prompt 难度分类”请求到达后系统判断它应交给便宜模型还是强模型。但 Agent 不是一次问答而是一条不断变化的执行轨迹。同一任务会在探索、规划、修改、验证、失败恢复之间往返真正需要判断的不是“这个任务难不难”而是“此刻这个 Turn 需要多强的模型”。NVIDIA 于 2026 年 8 月发布并开源的 NeMo Switchyard把路由依据推进到 Tool Result、错误、写入、测试与会话状态。本文在梳理 Stage Router 与 Escalation Router 的基础上进一步分析它作为 Agent 运行时控制面的价值、成本边界、失效模式、评测方法与工程落地路径。需要特别强调截至本文资料核验时项目仍明确标注为 pre-alpha、experimental、not for production use所有结论都应被视为设计启发与实验结果而非成熟产品承诺。一、从“为任务选模型”到“为执行时刻选能力”一传统路由为什么在 Agent 场景中不够用传统 Model Router 的基本单位通常是一条请求。它查看 Prompt 的主题、长度、关键词、复杂度或分类器分数然后在若干模型之间做一次选择。这种方法适合相对独立、输入已经完整的问答翻译可以交给专用模型简单抽取可以交给小模型复杂数学推理则交给强模型。路由判断发生在执行之前默认请求的难度在一次调用内大致稳定。Agent 改变了这个前提。一个“修复陌生仓库中的并发 Bug”任务可能持续几十个 Turn起初需要理解目录结构和调用关系随后要形成假设、定位竞争条件当方案明确后大量工作只是按计划编辑文件测试失败又会迫使系统回到诊断测试通过后还可能进入整理、补注释和生成摘要。任务的名义标签始终是“修 Bug”但每一步所需的推理强度、上下文敏感度与容错能力并不相同。如果只在会话开始时选一次模型会出现两个对称问题全程使用最强模型探索阶段可能稳健却也让文件读取、格式调整、机械编辑等低难 Turn 承担同样昂贵的推理单价全程使用便宜模型常规步骤成本很低却可能在错误恢复、跨文件推理或长链规划处失速。静态路由把一条动态轨迹压缩成一个标签因此天然损失了可优化空间。二Switchyard 改变的是路由粒度Switchyard 的关键变化不是简单增加另一种分类算法而是把决策粒度从“任务级”或“请求级”推进到“Agent Turn 级”。它试图回答最近发生了什么Agent 是否在产生可验证的进展是否反复执行无效动作是否进入错误恢复当前更像开放式探索还是已经收敛为机械执行这种变化可以用一个状态循环表示同一 Agent 任务中的能力需求并非单调变化。在这个框架里强模型与高效模型不再是两个固定的“Agent 人格”而是两个可按 Turn 调度的能力层级。Switchyard 文档使用 capable tier 与 efficient tier前者适合复杂推理、探索和恢复后者适合方案已经收敛后的稳定执行。值得注意的是“capable”与“efficient”是语义角色不绑定某个厂商或参数规模模型更新、供应商迁移或自托管端点替换不应迫使上层 Agent 改写路由逻辑。三它更接近运行时控制面而不是提示词技巧Switchyard 既可作为 Rust 代理服务器也可作为 switchyard-libsy 嵌入宿主程序。服务器接受 OpenAI Chat Completions、OpenAI Responses 和 Anthropic Messages 等接口并把请求翻译到 vLLM、NVIDIA NIM、Ollama 或其他 OpenAI-compatible endpoint。库侧的 Algorithm 抽象决定调用哪个语义目标、以什么顺序调用以及如何组合结果但不强占 HTTP 栈模型调用可以交还给宿主执行。这意味着路由、协议转换、模型传输与 Agent 本身可以解耦。从系统设计看它处在三个平面之间上接 Claude Code、Codex 或其他 Agent 客户端中间保存路由策略、会话状态和观测数据下接不同协议、成本与上下文窗口的模型后端。它处理的不只是“选谁”还包括跨协议翻译、会话亲和、上下文窗口溢出恢复、指标与决策记录。因此更准确的定位是 Agent 模型调用的运行时控制面。二、Stage Router从工具轨迹识别执行阶段一不用另一个 LLM 猜难度而是读取已经发生的事实Stage Router 最有启发性的设计是优先使用 Tool-result History而不是默认再调用一个 Judge LLM。Coding Agent 每次读取文件、搜索符号、执行命令、修改代码和运行测试都会留下结构化痕迹。这些痕迹比 Prompt 的表面难度更接近真实执行状态一个看似简单的修改可能连续报错一个措辞复杂的任务也可能已经形成确定方案只剩批量替换。在每次 LLM Call 之前Stage Router 检查最近若干 Turn 的工具结果并沿两个相反方向累计证据。官方把偏向强模型的一侧称为 WRONG把偏向高效模型的一侧称为 PROGRESS。命名虽然略显绝对但实际含义是“当前轨迹是否显示未解决状态”与“当前轨迹是否显示稳定产出”。二偏向 capable tier 的三类信号1、severity错误严重度不是简单的错误计数1.1 信息性错误与能力性错误severity 关注窗口内错误的性质与强度。并非任何错误都意味着必须升级一次拼写错误、可预期的文件不存在或测试中的已知失败可能只是正常探索成本关键编译失败、权限/上下文问题、反复出现且未被消除的核心错误则更可能说明当前模型无法有效恢复。官方实现还为 critical error 保留 hard override使其无需等待多个弱信号相互印证即可转向 capable tier。1.2 Hard override 的治理边界这体现了一个重要原则路由信号必须区分“信息性失败”和“能力性失败”。前者帮助 Agent 缩小搜索空间后者才表明继续使用当前能力层级的边际收益正在下降。若部署方把所有非零退出码都视为严重错误Router 会频繁误升级若工具适配器吞掉错误语义Router 又会对真正的困境视而不见。2、spinning动作很多不等于进展很多spinning 指深度操作持续发生却缺乏有效 read 或 write 进展的“原地打转”。Agent 可能不断重复相似命令、在同一错误上改写提示、来回切换假设表面 token 与 tool call 都很活跃实际上没有增加新信息也没有形成产出。这类信号比单纯统计调用次数更有价值。高调用量可能来自正常的大仓库检索也可能来自失控循环关键是动作是否带来状态变化。生产系统若要可靠识别 spinning应记录工具类别、目标对象、结果摘要、错误指纹和前后差异而不能只保存“调用过 shell”这样的粗粒度事件。3、exploring开放式探索何时变成拖延exploring 关注持续 read、search、planning却迟迟没有实际修改的状态。探索并非坏事复杂任务通常必须先建立心智模型问题在于探索是否已经超过合理窗口且没有收敛。此时 capable 模型的价值不只是“更聪明”还可能体现在更好的信息压缩、假设排序和停止条件判断。因此exploring 信号不能脱离任务类型解释。代码审计、研究综述和只读诊断本来就可能不产生 write将“无写入”机械等同于“无进展”会让只读型 Agent 被永久送往强模型。工程上应把用户意图、允许的工具集合和任务终态纳入信号语义。三偏向 efficient tier 的生产信号Stage Router 的 PROGRESS 侧核心是 recent_production_intensity最近窗口内是否持续出现 write、edit 等实际产出。其逻辑是当 Agent 已经从“还在决定怎么做”进入“按明确方案稳定执行”高效模型往往足以承担后续工作。但写入不是质量的同义词。一个模型也可能高速地产生错误修改。官方观测来源还区分 tests_passed近期测试通过、存在近期写入且窗口内没有错误时可把运行视为更稳定。部署者可以进一步把代码审查结果、静态分析、格式化、差异规模与回滚事件纳入“有效产出”的定义。真正有价值的不是 write 数量而是被验证的状态推进。四信号如何合并为决策1、方向、强度与阈值Stage Router 将相反方向的信号合并为 signed score再用 tanh 压缩得到 0 到 1 的 confidence。分数符号表示倾向 capable 还是 efficient绝对强度表示证据是否足够。官方设计强调 corroboration一个完整普通信号约得到 0.46略低于推荐起点 confidence_threshold 0.5通常需要第二个方向一致的证据才能跨过阈值critical error 则可直接覆盖。Stage Router 的信号聚合、阈值与回退逻辑。阈值并不是越高越安全。efficient_first 以高效层为默认阈值升高会减少信号触发的升级可能省钱但增加漏救风险capable_first 以强模型为默认阈值升高会减少降级更偏质量但成本更高。官方明确指出已发布阈值与结果来自 efficient_firstcapable_first 仍属实验且没有校准结果因此不应把两个 picker 的同一阈值理解为同一种风险偏好。2、低置信度时的三条路径当信号没有跨过阈值系统可以采取三种行为使用 picker 的默认 tier配置可选 LLM classifier 进行补判若 classifier 失败则 fall open 回到默认 tier。默认推荐配置是 picker efficient_first、confidence_threshold 0.5、recent_turn_window 3且不配置 classifier让多数 Turn 只依靠工具信号完成路由。这个设计把 Judge 从“每次必交的税”降为“证据模糊时的保险”。不过 classifier 仍可能与高效模型共享限流额度额外请求在规模化后放大 429 风险部署时最好给 Judge 独立客户端或配额池并单独统计其 token、延迟与失败率。3、切换模型还需要交接语义模型切换并非只改一个 endpoint。不同模型对历史的关注点、系统提示词和已形成计划的理解可能不同。Stage Router 支持 handoff notes 与 per-tier system prompts升级时可提示“前一模型停滞请接管诊断”降级时可告诉高效模型“方案已收敛请按计划执行”。这类交接信息能降低状态断裂但也可能污染上下文或过度锚定新模型因此应简短、结构化且可审计。三、Escalation Router把“先尝试、后救场”制度化一它判断的是结果而不是请求外观Escalation Router 从弱模型开始。未锁定的每个 Turn系统先调用 weak target 并缓存回复再把该回复追加到轨迹中让 Judge 评估弱模型已经完成的工作。若 Judge 认为无需升级缓存回复直接返回若给出升级票系统累计连续票数。达到 confirmations 后当前弱模型回复被丢弃强模型重新处理该 Turn并将整个 Session 锁定到 strong target。这与前置能力分类器有本质区别。前置分类器预测“这件事看起来难不难”Escalation Router 观察“便宜模型实际做得怎么样”。后验判断可以发现 Prompt 难度无法透露的困境例如工具调用循环、计划漂移、错误反复或回答与执行结果矛盾。Escalation Router 的两次确认、弱回复缓存与单向锁定。二两次确认的意义在误报与救援速度之间取舍官方默认 confirmations 2。一个升级票不会立刻触发强模型下一次若 Judge 拒绝连续计数归零。这样可以过滤偶发误判避免一次不顺就支付长期强模型成本。代价是救援至少晚一个 Turn用户可能先收到一次已被判定为困难但尚未达到确认数的弱回复。当确认数降为 1系统反应更快但更容易误升级提高到 3 或更多则更省强模型调用却可能让弱模型在错误路径上停留过久。这个参数不是纯粹的成本旋钮它同时改变用户体验、错误累积和上下文污染。若错误修改已经写入外部系统晚一个 Turn 的代价可能远高于一次额外模型调用。1、Session identity 是状态路由的基础设施当 confirmations 1 时连续票数必须跨 Turn 保留。官方要求客户端通过 x-switchyard-session-id 提供会话身份没有它每个请求都从零开始路由永远无法锁定。这揭示了状态型 Router 的基本工程要求会话标识必须稳定、隔离且可追踪还要处理超时、并发、分支 Agent 与重试的语义。2、Judge 失败为何选择 fail openJudge 超时、报错或返回不可解析结果时Escalation Router 返回已缓存的弱模型回复并保持原有连续票数不会因 Judge 故障创建强模型锁定。这样可以避免路由组件故障放大为服务不可用也避免异常误触发昂贵路径。但“fail open”意味着质量保障在 Judge 故障期间下降生产环境必须对失败率设告警并根据业务风险考虑更保守的自定义策略。三它的成本不是两层而是三层未升级 Turn 的成本是弱模型调用加 Judge 调用触发升级的那个 Turn 同时支付弱模型、Judge 和强模型三次调用锁定之后才变成直接强模型且跳过 Judge。端到端延迟同样如此未锁定 Turn 必须等待弱模型完成再等待 Judge而触发 Turn 还要等待强模型重做。因此Escalation Router 的经济性取决于三件事弱模型与强模型的价格差有多少 Turn 能留在弱模型Judge 的固定税。LangChain 给出一个实用的排除公式最低卸载比例 Judge 成本 ÷强模型成本 - 弱模型成本这个公式只回答“即使路由判断正确经济上是否可能划算”不能证明 Router 会做出正确判断。如果两模型价差很小所需卸载比例可能超过 100%此时无论如何调 Judge 都不可能省钱如果弱模型是近零边际成本的本地推理价差扩大路由才更可能成立。四、两种 Router 不是替代关系而是两种控制哲学一逐 Turn 双向调节与 Session 单向保险比较维度Stage RouterEscalation Router主要证据Tool result、错误、探索、写入与测试弱模型完成后的轨迹 LLM Judge决策问题当前处于哪种执行阶段弱模型是否持续遇到困难切换方向capable 与 efficient 之间可逐 Turn 升降weak → strong 单向锁定额外模型调用默认无低置信度 classifier 可选未锁定期间 Judge 为核心调用延迟特征接近规则计算开销串行增加弱调用后 Judge 延迟状态要求最近工具轨迹稳定 Session ID 与连续票数典型负载工具密集型 Coding Agent多轮、允许先试后救的 AgentStage Router 像一个连续变速器根据近期轨迹逐 Turn 升降能力适合任务阶段频繁变化。Escalation Router 像保险丝先让便宜模型承担大部分工作持续异常时熔断并永久切换到强模型。前者强调“阶段适配”后者强调“失败救援”。二为什么不应把两者简单叠加直觉上可以先用 Stage Router再用 Escalation Judge 兜底但这会迅速增加状态空间一个 Turn 由哪些信号触发、Judge 看到的是哪个模型的回复、升级是否覆盖 Stage 的降级、Session 锁定后是否仍允许回落都需要明确定义。若解释链不完整出现质量问题时很难判断是模型失败、信号误判、Judge 偏差还是策略冲突。更稳妥的做法是先明确业务风险和瓶颈若主要问题是工具阶段明显、额外延迟不可接受优先验证 Stage Router若工具信号贫乏但多轮轨迹可读、且允许串行 Judge 延迟验证 Escalation只有单一策略证明确有盲区后再设计组合策略并为每条决策路径建立可观察的来源标签。五、基准结果应如何解读先看三角比较再看统计边界一Cognition / Devin Desktop真实环境信号强公开证据仍有限NVIDIA 官方博客披露Cognition 在 Devin Desktop 中实现 staged-routing methodology并向 NVIDIA 内部用户部署真实环境测试。在 FrontierCode Main 上Opus 5 与 Kimi K2.7 动态路由达到 50.6% 准确率平均每任务 3.11 美元与全程 Opus 5 相比准确率低约 2.8 个百分点平均成本低约 28%。这个案例的主要价值不是“28%”本身而是说明同一 Coding Agent Session 内按执行阶段切换模型已经走出纯模拟实验进入真实用户环境验证。但公开材料没有完整披露任务分布、方差、路由比例、Judge/信号配置、延迟变化以及失败类型因此不能外推为任意 Coding Agent 的通用节省率。它更像一条可行性证据而不是可直接套用的商业预测。二LangChain74% 节省背后的完整账本LangChain 在 145 个多步 Agent 任务上测试 Escalation Router任务平均包含 6.3 次模型调用覆盖受政策约束的客服对话、值班事故调查、跨消息/工单/邮件的多步自动化并包含工具使用、多步检索、文件系统操作和长上下文总结。结果如下方案AccuracyCost / runCost / completed taskClaude Opus 4.8 only86.0%$11.45$0.092Opus 4.8 Nemotron 3.5 Lightning routed80.0%$3.00$0.026Nemotron 3.5 Lightning only77.7%$0.72$0.006路由方案把 93% 的模型调用留给 Nemotron仅 7% 交给 Opus但这 7% 的前沿调用占路由总支出的 68.4%Judge 又占 21.2%便宜模型的 93% 调用只占 10.4%。因此“调用比例”与“成本比例”不能混为一谈。少量前沿调用仍可能主导账单Judge 也不是可忽略的附属成本。LangChain 145 个多步任务实验。柱长仅作相对比较精确值见表。三真正重要的是三角比较路由方案相对 Opus-only 节省约 74%准确率下降 6 个百分点且该差距高于单次运行约 2.7 点的波动质量代价是真实的。更值得警惕的是另一条比较路由只比 Nemotron-only 高 2.3 个百分点却把成本从 0.72 美元提高到 3.00 美元约为 4.2 倍2.3 点的提升又小于运行波动LangChain 因此明确表示不能断言该实验中路由战胜了便宜模型。这说明 Router 评估必须同时比较三条基线强模型全程、便宜模型全程、动态路由。只与强模型比较容易把“采用便宜模型的收益”误记为“Router 的收益”只与便宜模型比较又可能忽视生产环境无法预先知道哪些任务困难的现实。Router 的真正价值是以可控的额外成本降低困难任务无人救援的风险而不是自动保证成本与质量同时最优。四平均数会掩盖预算尾部LangChain 五次路由运行中前沿流量比例从 4.1% 到 9.1%平均 6.9%成本从 2.16 美元到 3.61 美元波动 67%。虽然最差路由成本仍约为 Opus-only 的三分之一但这提醒预算制定不能只用平均值。路由器会降低期望成本却可能扩大成本分布上线前应报告 P50、P90、P95、最大值和任务类别分层而非只展示一个均值。六、Router 的核心风险不是选错模型而是看错状态一可观测性缺口会制造虚假的“进展”如果工具只返回自然语言摘要Router 可能无法区分“文件已修改”与“模型声称文件已修改”如果测试工具没有结构化退出码tests_passed 可能被误判如果多个子 Agent 共用会话某个子任务的错误可能污染另一个任务的阶段。路由质量上限受执行轨迹质量限制信号工程往往比调阈值更重要。建议把每次 Tool Result 规范化为最少字段工具类型、目标资源、成功状态、错误类别、状态变化摘要、产出哈希或差异规模、耗时、重试关联和子 Agent 标识。敏感内容可以只保留类别与指纹但不能只留一段不可计算的日志。二模型切换可能破坏隐性状态不同模型对计划、工具 schema、缓存、reasoning item 和消息角色的处理并不完全一致。协议翻译可以保持字段形状却不能保证语义等价。例如一个模型在先前隐藏推理中形成但未显式写出的约束切换后不会自动传递某些供应商的提示缓存边界和 thinking block 规则也不同。因此动态路由要求 Agent 把关键状态外显当前目标、已验证事实、待执行步骤、禁止事项、最近错误与恢复假设应进入可移植的会话内容或结构化 state而不是依赖单一模型的隐性记忆。handoff note 只能补充不应替代状态建模。三安全与权限不能跟随能力层级随意变化更强模型并不等于可以获得更高权限便宜模型也不等于应被限制到无法完成任务。权限决策必须独立于模型路由同一个工具调用应经过统一的身份、授权、参数校验与审计。尤其是写数据库、发布代码、发送消息和执行不可逆操作时Router 只能选择推理资源不能绕过人类确认和策略门禁。四Router 自身也会成为新的故障域代理层增加配置、网络、状态存储、协议翻译与指标采集任何一层出错都可能影响全部模型调用。Switchyard v0.2.0 的发布说明仍列出若干已知问题例如客户端断开后缓存的上游工作可能继续产生费用、部分回退与升级决策在统计中缺少目标归因等。再结合项目明确的 pre-alpha 状态当前更适合沙箱、离线评测和受控流量实验而不是直接置于关键生产路径。七、如何建立一套可信的评测与上线方法一第一步不是选 Router而是画出 Turn 分布从真实 Agent trace 中抽样给每个 Turn 标注任务阶段、工具类型、是否产生有效状态变化、是否需要复杂推理、最终是否成功。至少区分探索、计划、生产、验证、恢复、总结。然后统计各阶段的调用占比、token 占比、延迟与失败率。只有低难 Turn 占比足够高动态路由才有节省空间。二必须保留三条单模型基线和一个 Oracle 上界1、三条可执行基线最低限度应运行 capable-only、efficient-only 与 routed 三组保持 Agent 版本、工具环境、缓存计价、超时和随机性配置一致。对每组至少报告任务成功率、每成功任务成本、端到端延迟、工具调用数、重试数和不可逆错误数。2、Oracle 不是可部署方案但能判断上限离线获得两模型结果后可以构造“每任务选择成功且更便宜结果”的 Oracle估计模型组合的理论上限。若 Oracle 相对最佳单模型几乎没有提升说明模型能力高度重叠再复杂的 Router 也难创造价值若 Oracle 提升显著问题才真正转化为如何从轨迹中预测正确选择。三用 RESCUE、LOSS、SAFE、HARD 看待误路由Stage Router 官方校准思路将重叠任务分成四象限RESCUE 是 capable 失败而 efficient 成功升级反而不利或降级可救LOSS 是 capable 成功而 efficient 失败错误降级会损失质量SAFE 是两者都成功HARD 是两者都失败。名称提示我们模型层级不是严格支配关系强模型并非在每个任务上都更好。阈值选择应优先控制 LOSS再观察 RESCUE 与成本变化。对高风险业务可以给 LOSS 更高权重对批量低风险任务可以容忍少量 LOSS 换取更大卸载。不能仅优化平均准确率因为一次发布错误或错误外发消息的损失可能远超数千次 token 节省。四影子路由、回放与小流量顺序上线建议采用四阶段路径先在历史轨迹上离线回放信号再让 Router 影子决策但不改变实际模型比较其选择与结果随后对可回滚、低风险流量开启 1%—5% 灰度最后才逐步扩大。每阶段都要设置自动停止条件例如任务成功率下降超过阈值、Judge 故障率异常、P95 延迟增加过大或成本尾部超过预算。五一个可执行的指标面板指标组关键指标用途质量成功率、严重失败率、回滚率、人工接管率判断路由是否伤害终态成本每任务、每成功任务、Judge 占比、P95 成本防止均值掩盖尾部延迟首 token、Turn、任务端到端 P50/P95识别串行 Judge 税路由tier 占比、决策来源、升级/降级率、锁定时点解释策略行为信号error、spinning、exploring、production 命中率发现工具语义偏差稳定性429、超时、解析失败、上下文溢出与回退衡量新增故障域八、工程落地把路由当作策略产品而非一次配置一先选择模型对再选择算法Router 的收益来自模型之间互补且存在足够价格差。如果 efficient 模型已经接近 capable 模型可能直接用 efficient-only 更划算如果 efficient 几乎无法完成任何关键 Turn路由只会制造失败与重做。理想模型对应在常规阶段足够可靠、在困难阶段差距明显并且协议、工具调用与上下文能力兼容。评估模型对时不要只看公开榜单。要在自己的 Agent、自己的工具 schema 和自己的上下文长度下测量。模型的“便宜”还包括 token verbosity、工具调用次数、缓存命中、失败重试和推理时延单 token 价格低但输出冗长、频繁误用工具的模型任务级成本可能并不低。二为 Stage Router 设计可解释信号每条信号应有明确定义、时间窗口、权重、例外和样例。比如“探索”应排除只读审计任务“写入”应结合 diff 与验证“错误”应按可恢复性分级“打转”应识别重复目标和错误指纹。记录 decision_source使每个 Turn 能回答“为何选择此模型”。阈值调整应版本化。修改 confidence_threshold、窗口长度或信号权重后必须绑定评测数据、发布日期和回滚条件。把路由配置当成与模型提示词同等重要的产品逻辑而不是随手改动的基础设施参数。三为 Escalation Router 控制 Judge 税Judge 应尽可能短上下文、结构化输出并独立限流。官方默认 trailing window 为 28 条消息、每条截断 500 字符部署者需验证这是否覆盖关键轨迹又不过度消费。还应测量 Judge 的校准升级票的 precision、recall、连续两票的触发分布以及 Judge 对不同任务类别和弱模型表达风格的偏差。当 Judge 成本占比较高可以尝试只在异常信号出现后调用 Judge或使用本地小模型但这已经改变算法应重新评测不能继续引用原始 benchmark。任何“省掉 Judge 调用”的优化都可能降低困难识别率必须用任务终态验证。四协议兼容要以语义回归测试为准Switchyard 能在 OpenAI 与 Anthropic 协议间转换但生产接入仍应准备回归集覆盖工具定义、并行 tool calls、流式事件、结构化输出、reasoning/final item、token 统计、缓存字段、错误 envelope 和 max token 截断。字段被成功序列化不代表 Agent 行为不变最终要比较工具调用序列与任务结果。五预设退出机制路由不一定长期优于单模型。模型价格、能力、上下文窗口和缓存策略都会变化当 efficient 模型迭代到足够强Router 的边际收益可能消失当 capable 降价Judge 税可能不再合理。建议按月或模型版本重跑三角基线并设置“退回单模型”的明确条件。九、进一步推演Agent Routing 会走向何处一从二元 tier 走向能力组合capable/efficient 是易于解释的起点但真实任务可能需要代码专长、视觉理解、超长上下文、低延迟、数据驻留或特定工具可靠性。未来 Router 更可能在多个语义目标间做约束优化而不仅是强弱二选一。选择函数可同时考虑成功概率、边际成本、延迟、容量、隐私区域与当前工具阶段。二从启发式信号走向可学习策略NVIDIA 博客还介绍了 Prefill Router从模型预填充阶段的 residual stream 提取特征用共享 MLP 预测候选模型成功概率再与成本或延迟策略结合。这代表另一条路线不完全依赖人工规则而从工作负载数据学习。它可能提高细粒度预测能力但要求访问模型内部状态、准备可靠标签并应对分布漂移且目前仍属研究方向。可预见的实践不是启发式立刻被学习模型取代而是分层组合安全与权限使用确定性规则明显错误和测试通过使用高精度执行信号模糊区域再由分类器或学习策略判断。这样可以把可解释性留在高风险路径把统计模型用于边界区域。三路由目标会从“单次成本”转向“成功任务总成本”最便宜的 Turn 不一定带来最便宜的任务。弱模型若造成错误修改、重复工具调用或上下文膨胀会把节省转化为后续恢复成本。合理目标函数应优化期望总成本 模型调用 Judge 工具/基础设施 重试恢复 人工接管 失败损失同时约束成功率、尾部延迟和安全事件。只有在任务级目标下Router 才不会为了局部 token 节省而牺牲全局效率。四路由将迫使 Agent 显式表达进度当系统要根据执行阶段换模型Agent 必须更明确地记录计划、证据、修改与验证。这会反过来推动 Agent 架构从“长对话即状态”走向结构化执行账本。即使最终不用 Switchyard这种可观测状态也能改善调试、恢复、评测和人机协作。十、结论真正值得关注的是“状态感知的模型调度”Switchyard 的意义不在于提供了又一个“便宜模型/强模型”开关而在于把 Model Routing 嵌入 Agent 的执行循环。Stage Router 读取工具轨迹用错误、打转、探索、生产与测试信号判断当前 Turn 是需要诊断还是适合机械执行Escalation Router 则让弱模型先做再由 Judge 依据真实结果识别持续困难并以单向锁定提供救援。公开案例同时给出乐观与克制的证据。Cognition 的 Devin Desktop 说明 staged routing 已进入真实用户环境测试LangChain 证明少量前沿调用可以显著降低相对强模型基线的成本却也证明 Router 未必优于便宜模型全程Judge 可能成为第二大支出准确率代价与成本尾部不能被平均节省掩盖。因此专业的结论不是“所有 Agent 都应该路由”而是三条更严格的判断第一只有当任务内部存在明显阶段差异、模型对具有互补性和足够价格差时路由才有经济空间第二路由质量取决于执行轨迹的可观测性与状态语义而不仅是算法名称第三任何收益都必须在 capable-only、efficient-only、routed 三角基线中用每成功任务成本、尾部延迟和风险加权失败来验证。截至 2026 年 8 月Switchyard 仍是快速演化的 pre-alpha 实验软件。适当的使用方式是把它当作一个值得研究的控制面原型在离线回放、影子决策和受控灰度中验证信号建立可解释账本再决定是否进入更关键的执行路径。真正长远的变化是 Agent 系统开始承认能力不是会话开始时一次性选定的资源而应随着执行状态被动态调度。可参考文章与资料NVIDIA NeMo Switchyard GitHub 仓库与 READMENVIDIA 官方博客Route AI Agent Workloads Across Models with NVIDIA NeMo SwitchyardStage Router 官方文档Escalation Router 官方文档LangChainHow many of your agents calls actually need a frontier model?Switchyard v0.2.0 Release NotesNVIDIA 博客引用的 Prefill Router 研究论文