模型服务抖动、限流、风控误判、版本下线——业务端最后看到的全是 5xx。多数团队的应对是写一堆 try/catch 串起来，然后祈祷下一次值班的同事知道这段代码在哪。
灵果 把这一切换成一条声明式备援链：秒级切换，每次请求实际命中了谁，看板上一目了然。
每个「提供方 + 模型」每 10 秒做一次探测：时延、错误率、风控触发率。降级在被业务感知前就标记为不健康。
5xx、限流、风控、上下文超限、鉴权失败——每类触发不同的重试策略。429 在同一家继续重试；风控直接跳到下一家。
流式输出中途失败时，只重放断点之后的部分。客户端看到的是一条连续不断的 SSE 流，无可见切换。
备援链遵守预算策略。「成本优先」的路由不会自动跌到更贵的模型；「质量优先」的路由会。
按路由配置数据驻留规则。境内流量只能在境内提供方之间兜底；私有化模型只在 VPC 内调用——即使在全网抖动时也不破例。
每条响应头都带上命中的提供方、重试次数与决策原因。事故可复现，不用翻日志。
一条典型的生产路由：DeepSeek 主选、通义千问中转、VPC 内私有部署的开源模型作为最后兜底。任何不可恢复错误，灵果 都会顺链走下去。
所有路由决策汇总成实时事件流，SRE 与值班同学可以按路由 / 提供方 / 错误类型筛选。点开任一切换事件，可看到当时各提供方的健康快照——不需要事后翻日志拼时间线。
最近的切换事件高亮标出。本分钟内 DeepSeek 返回了两次 overloaded_error；通义千问无缝接管。
