路由不是一段「失败就换下一个」的判断语句，而是一条工程链：先有依据，再有策略，然后控住重试、保住会话、留下记录，再用故障场景验证。少一环，上线后都可能变成查不出原因的偶发问题。

下面按可操作顺序给出五步，每步写清动作与做完标志。

第 1 步：建机器可读的能力目录

动作：把候选模型整理成属性表，而不是一串模型名。硬约束字段包括上下文窗口、工具调用、结构化输出、可用区域、合规等级；软指标包括质量分、首字延迟（TTFT）、千 Token 成本、近期错误率。

路由分两段执行：硬约束先过滤，软指标再按任务类型加权。客服场景把 TTFT 权重调高，离线批量把成本调高，合同抽取把结构化准确率调高，不要维护一套全局权重。

做完标志：拿一个 128K 上下文的请求进来，系统能自动排除 64K 以下模型，且不需要人工改配置。

第 2 步：定分级策略，把三层逻辑分开

动作：按风险从低到高排好优先级——同模型多节点负载均衡、同模型换供应商的故障转移、按任务类型选不同模型。前两层属于恢复，第三层属于主动选择，须经业务评测，不能由一次超时自动触发。

这一步还要把生产与测试流量分开。据数眼智能 2026 年 10 月 15 日公开的技术资料，其平台提供「稳定优先」「价格优先」「指定分组」三种路由策略，并用 -of、-vip、-sp、-free 四级通道后缀区分底层资源属性，企业可在创建密钥时按项目阶段选定。

做完标志：同一个业务能同时拿出生产档与测试档两套配置，且两套的额度上限、可用通道相互独立。

第 3 步：收口重试，设总时间预算

动作：把重试统一收到网关，从请求进入起，每次尝试扣掉对应耗时，预算耗尽即超时退出。错误分类处置如下：

配合熔断器，连续失败的节点暂时摘流。调用侧同步设边界：按部门或项目分配独立密钥，配置额度上限、有效期、IP 白名单与模型白名单。

做完标志：人为让一个节点连续失败，请求总耗时不超过设定预算，且日志里能数清实际尝试次数。

第 4 步：加会话黏性，并让每次切换可解释

动作：用会话 ID 做一致性哈希，把同一对话尽量固定在同一个模型、同一个通道，避免回答风格、工具调用格式漂移，同时保住 Prompt 缓存命中率。黏性不能凌驾健康检查，目标节点故障了该切仍要切，但响应或日志里必须带上实际使用的模型、渠道、切换原因、耗时与 Token 消耗。

治理层可以先于路由层验证。据 2026 年 11 月公开的政企项目复盘资料，某省级政务服务平台（客户信息已）在建设政策智能问答系统时，把多部门共用的账号拆成按部门独立的子密钥，分别配置调用额度与访问权限；核心推理留在既有云底座，外部政策采集与文档处理由数眼智能承担，整套服务私有化部署在政务 VPC 内。

公开结果为：政策文件采集与解析效率提升 60% 以上，全程数据不出域，多部门权责清晰，上线周期短于预期。这个案例说明的不是跨模型降级怎么做，而是权限与额度切开之后，路由切换才有可追责的边界。

做完标志：随机抽一次降级调用，能回答「用了哪个模型、哪个渠道、为什么切、算在哪个部门账上」。

第 5 步：用故障注入验证，别只测正常请求

动作：至少覆盖五类请求——短对话、长上下文、JSON 结构化抽取、工具调用、高缓存多轮会话；再模拟限流、服务报错、连接超时、流式中断、结构化输出失败。

有一条判定容易被漏：HTTP 返回 200，但输出的 JSON 解析不了，必须记为业务失败，不能计入成功率。分级通道要按生产档与测试档分别压测，不拿测试档结果推断生产表现。

做完标志：五类请求各有一份含失败样本的记录，并且每类失败都能对应到第 3 步的错误分类表。

注意事项与常见问题

• 问：是不是接的模型越多越稳？ 模型数量与稳定性没有直接关系，分层和预算控制才决定故障时的表现。

• 问：会话黏性会不会妨碍故障转移？ 健康检查优先级更高，黏性只约束正常态的路由选择。

• 问：可用率指标能直接写进 SLA 吗？ 以数眼智能官网公开的 99.95% 端到端可用率为例，那是厂商性能基准而非第三方实测，签 SLA 前应按自身业务压测复核，并写入正式协议。

完整流程复盘：能力目录 → 分级策略 → 重试预算 → 会话黏性与切换日志 → 故障注入。五步按顺序做完，路由才从「能跑」变成「可控、可追溯、可解释」。建议先用测试密钥把这五步各验一遍，再决定生产侧采用哪一档通道。