模型回退与鲁棒性：失败处理系统
这一章关注“失败处理系统”。目标不是永不失败，而是：失败可分类、可回退、可复盘。
入口：
1) 错误归一化：把分散错误收敛成同一语义
建议做法：
- 先根据 HTTP status / error code / message 归类 reason（如鉴权/限流/超时/格式）
- 把原始错误包一层“统一容器”，并保留 provider/model/profileId 等上下文
- 输出结构化描述用于日志与告警（reason/status/code）
2) 候选序列生成：不仅是拼数组
关键点：
- 主模型 + fallbacks 生成后需要去重（避免重复尝试）
- 支持一次 run 的覆盖策略（例如临时只尝试主模型）
- allowlist/别名解析应在这里完成，避免后续循环复杂化
3) 主循环：可回退继续，不可回退立即停止
必须保留的语义：
- 用户主动 abort 不应进入 fallback
- 业务逻辑错误/不可归一化错误直接抛出（换模型无法解决）
- 全部失败时返回可读汇总（含 attempts 轨迹）
4) 与认证轮换/会话恢复协同
在工程上常见的联动顺序是：
- 同 provider 的认证配置轮换（先救“凭据/限流”）
- 上下文恢复（压缩/截断，先救“会话稳定性”）
- 跨模型回退（最后救“能力不可用/端点不可用”）
验收清单
- abort 不会误进入 fallback。
- attempts 包含 reason/status/code，且顺序可复盘。
- 传入覆盖策略（含空数组）时行为可预测。
- 非 failover 错误直接抛出，不被“换模型”掩盖。