降级是什么
模型超时率升高或整体不可用时，按预设顺序降低能力，而不是直接把错误抛给用户：先切备用模型，再关掉非必需增强功能，接着改为排队缓冲并告知等待，最后才明确报错。关键在于降级要可见、可恢复：响应里带状态标记，监控面板能看到当前处于哪一级，探测通过后渐进切回主链路。
基本信息
| 降级顺序 | 备用模型 → 简化模式 → 排队缓冲 → 明确报错 |
|---|---|
| 触发条件 | 超时率、错误率超过阈值，或处于上游维护窗口 |
| 可见性 | 响应标记与监控面板同时反映当前档位 |
| 恢复 | 拨测通过后渐进切回，避免瞬时回切再次打崩 |
| 记录 | 记录触发原因、切换点与恢复时间 |
典型使用场景
- 主模型超时率短时冲高：先切能力相近的备用模型，保住基本可用
- 上游维护窗口：提前排定降级计划，页面挂公告而不是等报错
- 高峰过载：关闭引用、图表等增强功能，把算力留给核心生成
- 区域故障：切到另一区域的同级模型，用户侧无感
- 恢复验证：用拨测跑通主链路再回切，避免来回抖动
降级决策示例
降级决策示例
触发: 主模型超时率 > 20%（5 分钟窗口）
动作一: 切换备用模型（能力相近，输出契约一致）
动作二: 仍不可用则关闭增强功能（引用、图表、长链推理）
动作三: 持续 10 分钟则改为排队并更新状态页
恢复: 拨测连续通过后 5 分钟内渐进切回，先放 5% 流量信号与动作对照
| 信号 | 动作 | 用户侧表现 |
|---|---|---|
| 超时率短时升高 | 切备用模型 | 基本无感，质量可能略降 |
| 备用模型也超时 | 关闭增强功能 | 功能变少，主回答仍可用 |
| 持续不可用 | 排队缓冲 | 显示排队与预计等待 |
| 全部链路失败 | 明确报错 | 给出稍后重试与状态页入口 |
降级状态必须在响应里可识别。静默降级会让用户以为质量下降是常态，也让事后统计分不清是能力问题还是故障。