编码代理真正昂贵的地方，不是某一次模型调用，而是它为了完成一项任务究竟要调用多少次模型。
当开发者让 Claude Code 或 OpenAI Codex CLI 修改一个函数时，代理不会只生成一段代码就结束。它可能读取文件、理解项目结构、调用工具、运行测试、分析报错，再次修改，直到任务完成。简单任务需要少数几轮，复杂任务则可能持续更多轮次。开发者购买的是“完成一次任务”的结果，模型平台却通常仍按输入和输出 token 计费。
这产生了一个容易被忽略的成本错觉。模型的单 token 价格很直观，但整项任务的账单还取决于代理需要多少轮、每一轮要重放多少历史上下文，以及失败后需要重试多少次。便宜模型如果频繁返工，未必便宜；昂贵模型如果能减少无效轮次，也未必是更差的选择。
模型路由从“选一个”变成“每一轮都要选”
AWS 与 NVIDIA NeMo Switchyard 给出的方案，试图解决的不是如何再造一个编码代理，而是如何在代理运行过程中决定“这一轮该由哪个模型接手”。AWS 官方博客展示的架构中，编码代理的请求先抵达 Application Load Balancer，再进入运行于 Amazon ECS on AWS Fargate 私有子网中的 LiteLLM 与 Switchyard 插件，最后通过 Amazon Bedrock 调用后端模型。
在这条链路里，LiteLLM 负责网关密钥校验，并调用插件选择模型。上层代理可以继续使用相对稳定的接口，后端则根据路由决策切换候选模型。AWS 文章展示的并不是一个固定的单模型部署，而是把单模型基线与多模型路由放在同一套部署中进行比较。
这里的关键变化，是路由对象不再只是一个静态请求。编码代理会连续发起模型调用，路由系统可以在每次调用时重新判断当前阶段需要什么能力。规划、理解陌生代码和处理复杂报错，可能更适合能力更强的模型；已经明确定位问题后的局部修改，可能适合效率更高的模型。是否真的节省成本，则必须由完整任务的调用轮数、通过率和重试情况来验证，不能只看单次 token 价格。
为什么工具活动比提示词更能说明任务难度
Switchyard 的 Stage 路由策略依据请求历史中的工具活动和工具结果选择模型层级。它不只看开发者最初写下的那句话，也看代理已经走到了哪一步。AWS 官方方案明确说明，Stage 需要读取完整对话历史中的工具活动与结果，因此代理必须发送完整历史。
这点很关键。对人来说，“修复这个测试”可能只是一个短句；对路由器来说，任务难度往往要在执行过程中才逐渐显现。代理如果连续搜索多个目录，或者多次运行测试仍然得到失败结果，说明当前阶段可能需要更强的推理能力。反过来，如果问题已经定位，后续只是根据清晰的测试反馈做局部修改，继续使用高能力模型的必要性可能下降。
这使动态路由区别于任务开始时的一次性分类。静态路由在开头给出模型选择，默认任务全过程保持不变；Stage 路由则把代理执行过程中的信号纳入决策。它更接近软件工程中的动态资源调度，而不是简单的请求分流。
代价同样明确。完整历史意味着更多输入上下文，长任务的 token 成本和延迟都可能随之增长。Switchyard 解决的是“调用哪个模型”的问题，并没有消除代理系统自身的上下文经济学。企业评估方案时，必须把历史长度、路由开销与后端模型调用一起计算。
路由的价值不在“便宜”，而在减少无效工作
如果只看单次调用价格，模型路由很容易被简化成“把请求尽量发给便宜模型”。但编码代理的现实更复杂。一个低价模型如果不能稳定理解工具结果，可能导致额外测试、重复编辑和失败重试，表面上的价格优势会被返工重新吃掉。
因此，路由系统真正应该优化的指标，不是某一轮调用多少钱，而是单位完成任务的成本。一次修改是否便宜，不取决于第一次写入文件用了多少 token，而取决于最终完成任务前，系统付出了多少轮沟通、执行与修复。
AWS 方案中的示例配置使用 claude-opus-5-5 和 nemotron-super-3-120b 作为单模型基线组。每个基线组始终由对应模型回答，便于与多模型路由组比较成本和任务通过率。AWS 原文展示了这种实验设计，但在可核验内容中没有给出可普遍外推的节省比例或通过率提升，因此不能把路由天然等同于确定的成本下降。
这个比较框架本身比宣传某个模型更有意义。它把问题从“哪个模型更强”改成了“在一项完整任务中，怎样组合不同能力层级的模型”。最强模型可能提高单轮成功概率，但所有请求都交给它，会让低难度调用承担不必要的成本；低价模型可以压低单次价格，却可能让复杂阶段支付更多返工代价。
架构上的克制，决定了它能否进入生产环境
模型路由只有嵌入真实基础设施，才会从概念变成生产能力。AWS 给出的组合没有要求上层编码代理重写自己的执行逻辑。LiteLLM 提供网关入口，Switchyard 负责路由决策，Amazon Bedrock 负责模型调用，Amazon ECS、Fargate、负载均衡与 VPC 接口端点承接部署和网络边界。
模型调用通过 Amazon Bedrock 的 Converse 或 ConverseStream API 完成，凭证使用任务的 IAM 角色。推理流量通过 Amazon VPC 中的 Amazon Bedrock Runtime 接口端点，保持在 AWS 网络内。对企业而言，这些细节接近真实上线门槛。代码仓库、工具调用记录、测试输出和模型响应，都可能包含敏感信息，路由层不能成为新的数据外泄入口。
协议兼容性也决定迁移成本。NVIDIA 官方项目将 Switchyard描述为能够在模型和提供商之间路由流量，同时保持 OpenAI 与 Anthropic API 兼容性。对上层应用保持接口稳定，对下层模型保留替换空间，是路由层最现实的价值。
但兼容不等于治理成本消失。企业仍需要记录每次路由决策，知道哪一个模型处理了哪一轮、路由依据是什么、任务是否因此重试。否则，路由器会成为一层难以审计的黑箱，账单分析和故障定位都会变得更复杂。
它与 Bedrock 原生路由不是一回事
AWS Bedrock 还提供 Intelligent Prompt Routing，可以在同一模型家族内，根据对响应质量和成本的预测动态选择模型。NeMo Switchyard 的 Stage 策略则把代理工具活动与执行阶段纳入路由。两者都涉及动态选择，但服务边界不同。前者更接近托管模型服务中的请求级能力，后者更接近可嵌入代理网关或执行框架的路由决策层。
这一区分很重要。把所有“模型自动选择”都称为同一种路由，会掩盖代理任务的特殊性。普通问答往往可以在请求级别完成判断；编码代理的难度则会随文件读取、工具调用和测试结果变化。它需要的不只是提示词分类器，还需要理解任务轨迹的执行层。
模型竞争也会因此从排行榜延伸到中间层。模型供应商争夺默认入口，云厂商争夺调用与治理层，路由基础设施争夺的则是每个任务的模型组合。模型越多，企业越不可能为每一个代理手工写死规则，越需要一个能够观察任务状态、记录决策并允许调整的中间层。
NVIDIA 通过 NeMo Switchyard 进入这一层，价值不只是帮助客户少调用某个模型，而是试图把模型选择从应用代码中抽出来，变成可配置、可观测、可替换的基础设施。AWS 提供身份、网络和托管模型入口，Switchyard 则提供跨候选模型的决策能力，二者的组合更像云上代理系统的交通控制层。
交通控制也会带来新的风险。路由策略误判，可能把复杂任务交给能力不足的模型；策略过于保守，又会退化为始终调用高价模型。随着模型版本、任务类型和工具生态变化，路由策略还需要持续校准。它不是部署一次就结束的组件。
编码代理的账单，将从 token 计价走向任务计价
NeMo Switchyard 所揭示的趋势，比某一款插件更重要。随着编码代理进入软件开发流程，企业关心的计量单位会从“生成了多少 token”逐步转向“完成了多少任务”。模型调用只是过程，代码是否通过测试、任务是否按时结束、是否需要人工接管，才是结果。
这会改变采购和评估方式。企业不应只比较模型的输入输出价格，也要比较单项任务的平均调用轮数、历史上下文规模、失败重试率和最终通过率。对于路由系统，则要观察它是否在降低调用成本的同时引入更多返工，是否让延迟变得不可预测，是否能够解释每次模型选择。
真正成熟的路由，不是把所有请求平均分给不同模型，也不是简单地让便宜模型承担大多数流量。它应该理解任务处于什么阶段，知道哪些错误可以低成本修复，哪些信号意味着必须升级模型，并在任务结束后用结果验证自己的判断。
编码代理正在把模型调用变成一条生产流水线。流水线的效率，从来不由最便宜的零件决定，而由整条链路的返工率决定。谁能把正确的模型放在正确的步骤上，谁就更有机会把“能写代码的模型”变成“能稳定交付软件的系统”。
快报