降级链要有层次：五级递进与每级的四个问题

真实故障是渐进的，降级不该只有开/关两档。本文给出五级降级（重试/换路/缩量/兜底/不可用）、每级要回答的四个问题、对外如实标注的要求与该观测的四个指标。

降级不该只有"开/关"两档

很多系统的降级设计是二元的 ✗：要么正常、要么报错 ✔。

但真实故障是**渐进的** ✔（上游变慢、部分失败、配额快满 ✔），

**降级链要有层次** ✔，逐级退让而不是一步到底 ✔。

```

① 重试（瞬时故障，退避重试，见重试那篇）

② 换路（换模型/换供应商/换区域，见多模型路由那篇）

③ 缩量（少检索几条、缩短输出、关掉思考，见预算那篇）

④ 用缓存/兜底（返回上次结果或规则结果，并明确标注）

⑤ 明确不可用（给替代路径与等待时间，见降级提示那篇）

```

**要点**：**每一级都要有开关与观测** ✗→✔ ——

没有观测，就不知道系统当前在第几级 ✔（这是最常见的问题 ✔）。

```

① 触发条件（什么指标到什么阈值进入这一级）

② 用户可见差异（用户能感知到什么变化，如何标注）

③ 成本与延迟影响（这一级是省钱还是花钱）

④ 退出条件（什么时候回到上一级，是否需要人工）

```

**第 ④ 项最容易漏** ✗：只降不升 ✗ → 系统长期停在降级态 ✔，用户以为这就是正常水平 ✔。

第 ③ 级起**必须告知用户** ✔（"当前为快速模式" ✔）；

第 ④ 级要说明**结果可能不是最新的** ✔；

第 ⑤ 级给**替代路径**（见降级提示那篇 ✔）。

**静默降级是最坏的做法** ✗（用户拿兜底结果当完整结果用 ✔）。

**当前所处级别**（按功能实时可见 ✔）；

**各级触发次数与时长**（哪一级最常触发 → 该优化哪儿 ✔）；

**降级期间的负反馈率**（降级是否被用户察觉并反感 ✔）；

**自动恢复率**（不能自动恢复的，说明退出条件没设计好 ✔）。

> 上游**变慢一半**（不是全挂 ✔）时 ✔，系统会进入哪一级 ✔、用户看到什么 ✔、多久恢复 ✔？

> 答不出，说明降级链还只有"开/关"两档 ✗。