# 你的 AI 供应商总有一天会出问题

这周来了两条提醒。Anthropic 将在 6 月 15 日把 Claude Sonnet 4 和 Opus 4 从 API 下线——如果你把版本钉死在这两个上，那天起你的调用就直接开始返回错误，没有任何自动切换。而今天早上，Gemini 挂了。两件事方向相反，教训却一样：撑起你产品的那个模型，是一个第三方服务，它会按照你无法掌控的时间表，去改变、消失或者崩溃。解决办法不是什么战略，而是大多数 AI 产品都跳过的、枯燥的韧性工程。

- **Author:** Fedor Chishchin
- **Published:** 2026-06-10
- **Tags:** architecture, methodology
- **Source:** https://fedorthinks.com/zh/blog/your-ai-provider-will-have-a-bad-day

---

这周有两条不起眼的新闻，说的其实是同一件事。第一条：Anthropic 将在
[6 月 15 日把 Claude Sonnet 4 和 Opus 4 从 API 下线](https://platform.claude.com/docs/en/about-claude/model-deprecations)。
如果你的代码调用的是这些钉死的版本，那天之后请求就
[直接返回错误——不会自动切换到更新的模型](https://chatforest.com/guides/anthropic-claude-sonnet-4-opus-4-deprecation-june-15-2026/)，
调用就这么失败了。第二条：今天早上，谷歌的 Gemini
[挂了](https://ca.news.yahoo.com/gemini-down-today-latest-updates-142422735.html)，
给所有依赖它的人返回「出错了」。

一个是计划内的下线，一个是计划外的宕机，但它们是同一个教训的两面：**撑起你产品的那个模型是个第三方服务，它会按照你无法掌控的时间表给你掉链子。**
我们谈论 AI 时，总把它当成一个永远清醒、永不改变的魔法神谕。可它现在是基础设施了——
而基础设施也有不顺的日子。问题在于：你的基础设施出问题时，会不会把你的产品一起拖垮。

## AI 是基础设施，而基础设施会宕机

这种事并不罕见。去年年底某个状态监测平台，单单一个月就记录到主流 AI 供应商发生了 47 起事故——
Anthropic 和 OpenAI 各自的
[总影响时长都超过 180 小时](https://www.thoughtworks.com/insights/blog/generative-ai/claude-outage-june-2026)。
OpenAI 在 2025 年有过一次长达 34 小时的宕机。哪怕在 99.76% 这样还算健康的可用率下，那也意味着
[一年里大约有 16 个小时](https://www.thoughtworks.com/insights/blog/generative-ai/claude-outage-june-2026)，
你产品赖以运行的那个东西干脆就不在了。再加上像 6 月 15 日这样的下线——模型不是*宕机*，而是*消失*——
画面就很清楚了：把宝全押在一家供应商上、毫无后备方案，就等于永远赌它天天都是状态最好的那一天。

大多数 AI 产品恰恰就是这么搭的——一家供应商，一个模型字符串，直接调用，再加上一个「它总会回应」的顺风顺水的假设。
这在演示里没问题，可放到生产环境里就是颗定时炸弹。

## 在动手应对之前，先搞清楚你遇到的是哪种故障

韧性工程教会你的第一件事，就是故障并不都一样，而反应错了只会让情况更糟。**瞬时**故障——
一个 429 限流、一次短暂的网络抖动——几秒钟就过去了，重试一下就好。**持续**故障——
一次彻底的供应商宕机、一个二十分钟里一直返回垃圾结果的模型——干等是等不来恢复的，
[重试只是白白烧钱烧时间](https://www.buildmvpfast.com/blog/building-with-unreliable-ai-error-handling-fallback-strategies-2026)。
对每个错误都盲目重试，正是把供应商一个糟糕的小时变成你账单失控的方式。所以这些手段是层层叠加的：
瞬时的就重试，持续的就降级回退，整个系统都在劣化时就触发熔断器。

## 让你在它们宕机时也能站住脚的四招

你不需要什么花哨的东西——这就是把标准的分布式系统卫生习惯，套用到模型调用上：

- **带退避的重试**，应对瞬时错误。限流和网络打嗝很正常；几次逐渐拉长间隔的重试，能在没人察觉的情况下消化掉大部分。
- **一个后备模型或供应商**，应对持续故障。这是最关键的一招，而且数字很惊人：两家各自可用率 99.3% 的独立供应商，
  同时宕机的概率只有
  [0.0049%——相当于约 99.995% 的有效可用率](https://universal.cloud/en/blog/ai-uptime-vergeten-risico/)。
  多一条路，就把一次宕机从「没有答案」变成「答案稍差一点」。
  （这也是为什么把模型藏在一个[可替换的接缝](/blog/three-models-one-line)后面，
  不只是战略上划算，运维上也一样划算。）
- **一个熔断器**，这样当某家供应商明显挂掉时，你就别再死命去捶它，而是快速失败、干净地恢复，而不是堆积一大堆超时。
- **优雅降级**到一条确定性的路径。如果 AI 功能死了，别让用户永远盯着一个转圈——
  退回到某个更笨但仍然能用的东西：用关键词搜索代替语义搜索，用模板化回复代替生成式回复，用一个普通表单代替智能流程。
  告诉用户「高级功能暂时离线」，并让产品继续可用。

最后这一招最重要，却最常被跳过。一个没有非 AI 后备方案的 AI 功能，意味着你整个产品的可用率，
现在被你最不靠谱的那个依赖给封顶了。

## 还有，把下线日期写进日历

6 月 15 日的下线是更安静的那种故障，而且专坑那些自以为很安全的人。把模型版本钉死，感觉很负责任——
你把行为冻结住了。可一个被钉死的版本，就是一个可能被*下线*的版本，而它一旦被下线，
你的调用不是劣化，而是直接死掉。所以要么去追踪你钉死的每一个模型的下线通知，要么干脆别去钉一个你没准备好按供应商时间表迁移走的版本。
迁移通常只是
[改一行代码](https://chatforest.com/guides/anthropic-claude-sonnet-4-opus-4-deprecation-june-15-2026/)——
但前提是你在 6 月 15 日之前就知道，而不是 6 月 16 日从错误日志里才发现。

## 归根结底

关于 AI 的精彩故事，是它能做的一切。而那个不光鲜的故事——这一周悄悄讲了两遍的那个——
是它就是一个远程服务，会在你没挑选的时刻变慢、宕机或消失——一个假设它不会这样的产品，
离一场事故只差一个糟糕的早晨。这些解决办法没一个是聪明的。抖动就重试，宕机就回退，降级到确定性的东西，
盯紧下线日历。这跟我们为任何关键依赖所做的、同样枯燥的可靠性工作没什么两样——而模型现在恰恰就是这样一个依赖。

所以在你上线之前，问一个演示永远不会逼你去问的问题：当我的供应商迎来它糟糕的一天时——它一定会——
我的用户看到的是什么？如果答案是「一个错误加一个转圈」，那你并没有在 AI 之上搭出一个产品。
你搭出来的，是一个把自己的可用率借给别人去决定的产品，而人家可从没向你承诺过他们状态最好的那一天。