模型路由与故障切换：失败时也要保持原有约束
从候选筛选、重试预算到部分输出恢复，设计可验收的多模型路由方案。
Foxmu · 更新日期: 2026-10-19
先筛选资格，再比较优先级
路由首先要确定哪些目的地有资格处理请求。核对账户与模型权限、所需协议、上下文限制、工具能力和批准的数据处理方式。每一个备用候选都应符合相同要求，不能因为主路由不可用，就自动扩大模型访问或数据发送范围。
建立小型候选矩阵，为每项条件记录证据与负责人。如果没有合格目的地，返回清晰失败，而不是任意寻找可返回文本的服务。跨提供方发送敏感内容前，结合 ZDR 生命周期指南确认内容保留与第三方工具边界。
区分硬性条件和路由偏好
在合格候选中，可以优先考虑任务质量、延迟、成本或固定提供方。说明各目标的优先级，并使用代表性工作负载的测量结果做选择。同一模型切换推理提供方，与更换成另一模型，是两种不同变更，输出质量和行为都需要重新验证。
OpenRouter 官方文档列出了明确的提供方偏好选项，但其参数名与默认值不是 Foxmu 的配置约定。评估 MaaS 或 AI 网关时，应核对实际设置与观察到的路由结果，不直接假设别的平台示例可以照搬。
为整个操作设置重试预算
先定义总截止时间，再给连接、首次响应和生成阶段分配预算。限制客户端、网关和上游 SDK 合计的尝试次数与资源消耗。各层独立重试可能在故障时放大请求量，让原本的单次操作变成多次并发或重复执行。
只对适合该操作的失败进行有限退避重试，并传递取消信号。无效输入与权限拒绝通常需要修正请求，而不是换一个目的地继续试。每次尝试前检查剩余时间和预算，已无法有效完成时及时停止。
处理部分输出与工具副作用
内容已经到达用户后，重新生成是一份新回答，不应作为原回答的延续悄悄拼接。明确标记中断，提供可理解的恢复动作；同时检查响应体中的失败信号，不能只看 HTTP 状态。恢复方案也要保持原来的数据与权限约束。
工具创建或修改业务记录时，超时可能意味着结果尚不确定。使用业务幂等键和执行记录，重试前核对是否已完成，并保留需要的审批。模型生成的调用标识本身并不能保证订单、支付或发布动作不会重复。
保留发布与回滚证据
测试主路由不可用、候选全部耗尽、限流、流式中断、用户取消和权限拒绝。确认实际选择的路径、受限的尝试次数、最终状态和可核对的用量，不必为此保存完整提示词。恢复后的回答还应满足原任务的质量要求。
记录配置与客户端版本、已测边界和未解决情况，与此前可用版本比较，并保留回滚计划。API 兼容性清单和工具调用指南可帮助定义验收条件；仅有路由机制并不构成可用性保证。