做多模型系统时，我比较反感一种写法：在业务代码里到处判断“这次走 GPT，还是走 Claude”。短期看很快，长期几乎一定失控。Routing 层真正该做的，不是替业务层写一堆 if else，而是把决策边界单独收出来。
我更看重下面四条原则。
1. 先围绕任务，别围绕模型品牌
路由输入应该是任务类型、输入规模、时延预算、风险等级，而不是“某模型最近很火”。模型会换，供应商会变，任务边界才是相对稳定的那部分。
2. 默认路径要简单
很多系统不是死在能力不够，而是死在默认路径太绕。一个请求进来，先走规则路由，再叠加动态评分、灰度条件、供应商权重和兜底重试，最后谁也解释不清为什么它落到了那个模型上。默认路径越简单，排障越快。
3. 把策略层和接入层拆开
这点特别重要。policy_engine 负责回答“该选谁”，provider_adapter 负责回答“怎么调它”。两个问题别混在一起。否则你每接一家新供应商，策略代码都要跟着动一次。
一个比较顺手的分层大概是这样：
route_context：整理任务、预算、时延、风险等级policy_engine：做规则命中或动态选择provider_adapter：处理协议、鉴权、报错和重试差异
也可以直接把职责理解成下面这张表：
| 层 | 负责什么 |
|---|---|
route_context | 把请求上下文整理干净 |
policy_engine | 决定这次该选谁 |
provider_adapter | 负责把调用真正打出去 |
4. 让每次选择都能回放
线上系统不怕规则粗，怕的是规则不可追。至少要能查到这次请求的上下文、命中规则、最终模型、耗时和切换原因。不然所谓优化，最后只会变成猜。
一个常见误区
很多团队太早追求动态路由，觉得这样才“智能”。但只要基础观测没补齐，动态决策只会把问题藏起来。我的经验是，先让 70% 到 80% 的请求走显式规则，剩下小部分再做实验性决策，这样系统稳定得多。
统一接入也是同样的道理。像 147api 这类服务，更适合放在 Routing 前面做标准化网关。它不是替你决定路由，而是先把模型协议、鉴权和错误处理收口，让策略层不用背着供应商兼容包袱往前跑。
最后一句
说到底，Routing 层设计的是边界，不是花样。边界清楚，系统才会稳。
