智能体从「调一个模型」变成「调一堆模型」，是今年很明显的工程趋势。一个智能体内部可能同时用大模型做规划、小模型做分类、专用模型做摘要。Weave Router 在 9 月 19 日推出 2.0，把多模型路由做成了一个开源组件：按任务类型、成本预算、延迟和供应商健康度，把每次调用分到合适的后端，并在入口统一做限速、熔断和成本护栏。当模型数量上来，路由层就从锦上添花变成了必选项。
为什么智能体需要路由层
没有路由层时，每个智能体自己写死后端、自己处理失败重试，结果是重复造轮子，而且账单和延迟都不透明。一旦模型供应商临时抖动、或者某个任务其实用便宜小模型就够，硬编码的调用就既贵又脆。路由层把「选哪个模型」这件事从业务逻辑里抽出来，变成基础设施的一层。
增量认知：多模型不是炫技，而是成本和可靠性的现实需要。把简单调用从小模型走、难任务才上大模型，整体账单和可用性都会比死磕单一大模型更稳。路由层的价值，正是把这种策略变成默认能力。
2.0 多了什么
相比早先的版本，2.0 把重点放在了「会算账」上。它不再只是按规则转发请求，而是在入口就感知成本预算和延迟目标，并持续探活各家供应商的健康度——某个后端挂了，能自动切到备援，而不是把错误直接甩给智能体。限速和熔断也下沉到路由层统一管，避免下游被突发流量打爆。
对开发者来说，这意味着业务代码里不再散落着一堆「如果 A 失败就试 B」的胶水逻辑，而是把这类韧性策略集中到一处配置。一个智能体今天用三家模型，明天换一家，业务侧几乎无感。
收益与代价
路由层的好处很直白：成本更平滑、峰值延迟可控、可用性靠冗余兜底。但它也引入了一个新组件和一段新增延迟——每次调用都要先过一道路由决策。对延迟极度敏感的场景，这点开销要算进预算；对中小团队，多维护一层服务也是实打实的成本。
架构提醒：路由层是单点。它本身要做得足够轻、足够稳，否则它一挂，后面所有智能体都失联。建议把它和模型后端一样对待：有健康探测、有超时、有降级（比如直连默认模型），别让「智能体的智能」卡在一个没做高可用的中间件上。
横向看，Weave Router 和 litellm、ARBR 这类网关处在同一赛道，区别在开源程度和侧重点：有的偏统一 API，有的偏治理，Weave Router 2.0 这版明显把成本护栏和供应商探活推到了前面。选型时看你的痛点到底是「接入麻烦」还是「账单失控」。
当你的智能体还只调一个模型，路由层是过度设计；但只要你开始按任务挑模型、开始在意月底那张调用账单，它就是绕不开的一层。2.0 把成本视角做进路由决策，算是踩在了正确的时间点上。