Opus 5故障87分钟：一个模型，如何拖住五类产品

Opus 5 这次故障，持续了约 87 分钟。

时间不算长，却足够让五个入口同时出现问题：claude.ai、Claude Console、Claude API、Claude Code 和 Claude Cowork。对普通用户，这是回答失败或反复重试；对开发者，是请求报错、任务中断；对企业团队，则可能是生产流程里某个自动化环节突然失去响应。

Anthropic 的公开记录只确认了一件事：Opus 5 的错误率升高。状态页没有披露根因、错误比例、受影响请求量，也没有说明地区分布，更没有把这次修复解释成永久解决。

这份时间线说明了响应速度，却没有说明故障究竟发生在哪里。模型服务本身出了问题，还是某个调用、路由、限流或发布环节放大了错误，目前都不能从状态页得到答案。

87分钟故障，影响了谁

受影响的五类产品，承担的任务并不相同：

这里需要把“模型层故障”和“产品层影响”分开看。

公开信息只能证明，多个产品在同一时间受到影响，并且都与 Opus 5 有关。它不能直接证明 Anthropic 存在一个被单点控制的架构，也不能证明所有请求都经过同一条故障路径。产品共享模型，不等于产品共享全部基础设施。

但共同依赖带来的风险半径，确实已经变大。

一个用户在网页里重新发送一次消息，代价可能只是多等几十秒。一个企业 API 调用却可能触发连锁反应：任务队列堆积，重试请求增加，超时继续向上游传播，后续系统把一次模型错误误判成业务错误。Claude Code 这类工具还多了一层问题，用户往往把模型调用嵌在编辑、测试、提交代码的连续流程里，单次失败会打断整个工作节奏。

模型越强、入口越多，大家越愿意把更多事情交给它。依赖增长带来的收益很直接，故障扩散也会变得直接。

统一底座提高效率，也放大脆弱性

把一个高能力模型接入聊天产品、开发平台和编程工具，产品团队可以减少重复建设，统一能力和体验。模型升级时，多个产品也能更快获得收益。

代价是，产品之间的隔离感会变弱。

电力系统早就说明过这个道理。发电、输电和终端设备可以共享一套网络，效率因此提高；但只要关键节点出现问题，停电范围就可能远大于最初的故障点。AI 服务没有完全复制电网的结构，模型错误也不必然造成全线中断，但“共同依赖扩大故障半径”的逻辑相似。

这也是我不太接受“只是一次短暂波动”这种轻描淡写的原因。87 分钟本身并不构成灾难，关键在于它暴露出用户正在把 Opus 5 当成多种工作流的默认底座。

对使用 Claude API 的企业，现实动作很具体：

• 不要把单一模型当成唯一生产路径，至少为关键请求准备同供应商的备用模型或其他供应商。
• 重试要带退避、上限和幂等控制.涉及扣款、写入、发消息的请求，不能因为模型报错就无条件重放。
• 监控不能只看 HTTP 状态码，还要看模型错误率、延迟、超时、令牌消耗和业务任务完成率。
• 对 Claude Code 一类工具，团队要保留人工接管和替代开发流程，不能让一次模型不可用就卡住发布。

这会增加维护成本，也会让采购和架构决策变得不那么“整齐”。但把所有能力压在一个模型上，本来就不是免费的便利，只是平时没有单独列出这笔风险。

状态页解决了什么，没解决什么

Anthropic 在 09:17 UTC 开始调查，10:34 UTC 部署修复，10:44 UTC 宣布解决。这个响应节奏至少说明，团队能够较快定位并处理一类跨产品影响的问题。

透明度却停在了最小可用水平。

用户不知道错误率升高到什么程度，不知道哪些地区或请求类型受影响，也不知道修复改变了什么。企业用户因此无法判断：这次事件是偶发的模型异常，还是一次发布、路由或容量管理问题；也无法据此调整自己的容灾等级。

状态页的作用，是告诉人们“现在是否恢复”。它不自动等于事故复盘，也不等于可靠性证明。宣布解决，只能证明服务端认为主要症状已经消失，不能证明同类问题不会重现。

接下来真正该看的有三件事：

1. Anthropic 是否发布更完整的事后报告解释触发条件、影响范围和修复措施。
2. Opus 5 是否再次出现跨产品错误率升高尤其是在版本更新或流量变化之后。
3. 企业用户能否获得更清晰的模型级可用性指标、降级路径和事故沟通机制。

如果后续没有补充说明，开发者只能把这次事件当作一次经验样本：模型调用必须具备隔离、降级和观测能力。至于 Anthropic 的系统到底哪里出了问题，仍然只能保持推断，不能拿状态页的几条更新时间线代替技术结论。

Opus 5 的问题已经恢复，依赖它的工作流却不会自动恢复成原来的样子。模型可以被复用，责任也必须被分散；否则每一次“短暂错误”，都会变成用户自己的长时间等待。