降级不该只有"开/关"两档
很多系统的降级设计是二元的 ✗：要么正常、要么报错 ✔。
但真实故障是渐进的 ✔（上游变慢、部分失败、配额快满 ✔），
降级链要有层次 ✔，逐级退让而不是一步到底 ✔。
一、五级降级（从轻到重）
① 重试（瞬时故障，退避重试，见重试那篇）
② 换路（换模型/换供应商/换区域，见多模型路由那篇）
③ 缩量（少检索几条、缩短输出、关掉思考，见预算那篇）
④ 用缓存/兜底（返回上次结果或规则结果，并明确标注）
⑤ 明确不可用（给替代路径与等待时间，见降级提示那篇）
要点：每一级都要有开关与观测 ✗→✔ ——
没有观测，就不知道系统当前在第几级 ✔（这是最常见的问题 ✔）。
二、每级要回答四个问题
① 触发条件（什么指标到什么阈值进入这一级）
② 用户可见差异（用户能感知到什么变化，如何标注）
③ 成本与延迟影响（这一级是省钱还是花钱）
④ 退出条件（什么时候回到上一级，是否需要人工）
第 ④ 项最容易漏 ✗：只降不升 ✗ → 系统长期停在降级态 ✔，用户以为这就是正常水平 ✔。
三、对外要"如实标注"
- 第 ③ 级起必须告知用户 ✔（"当前为快速模式" ✔）；
- 第 ④ 级要说明结果可能不是最新的 ✔；
- 第 ⑤ 级给替代路径（见降级提示那篇 ✔）。
静默降级是最坏的做法 ✗（用户拿兜底结果当完整结果用 ✔）。
四、该观测什么
- 当前所处级别（按功能实时可见 ✔）；
- 各级触发次数与时长（哪一级最常触发 → 该优化哪儿 ✔）；
- 降级期间的负反馈率（降级是否被用户察觉并反感 ✔）；
- 自动恢复率（不能自动恢复的，说明退出条件没设计好 ✔）。
五、一条判据
上游变慢一半（不是全挂 ✔）时 ✔，系统会进入哪一级 ✔、用户看到什么 ✔、多久恢复 ✔？
答不出，说明降级链还只有"开/关"两档 ✗。