摘要

  • 7 月 21 日 13:04:35 至 16:38:26 UTC，Haiku 4.5 发生 major 级故障，并在第一次监控后重新回到“已识别”。
  • 另一条 critical 级多模型记录把实际高错误区间定为 15:28 至 16:26，但事件页直到 18:18 才关闭。
  • 17:40 至 18:03，文档创建、Cowork Remote、Claude Code 等工作流功能另有一条 critical 记录。
  • 7 月 22 日 08:34 至 09:00，Opus 4.1 在 API 和 Claude Code 上发生独立 minor 故障。
  • Anthropic 没有公开共同根因、受影响人数、请求比例、地区或赔付结论。

状态页从“已识别”转向“监控”，通常意味着修复已经部署。但 Haiku 4.5 的时间线又从监控退回已识别。这次反转比一段笼统的“服务异常”更有价值：第一次恢复判断没有持续成立。

同一天其余记录则提醒分析者克制。时间重叠、组件相同和用户体验相近，都不足以证明后台只有一个故障。

Haiku 经过两次稳定化尝试

Haiku 事件覆盖 claude.ai、Console、API、Claude Code 和 Cowork。13:14 进入已识别，13:22 进入监控，14:44 再次进入已识别，15:30 重新监控，16:38 关闭。

Anthropic 没有说明第一次修复为何失效。可能是同一问题未完全消除，也可能是新症状出现；公开资料无法区分。可确认的是，客户不能把第一次监控状态当成稳定恢复。

因此，企业自己的合成请求、队列积压和业务成功率必须独立观测。供应商状态只是一个信号，不是每个客户账户的运行证明。

多模型事件有两种时长

多模型 critical 事件在 15:35 开页，但最终说明用户在 15:28 至 16:26 遭遇高错误。页面直到 18:18 才标记解决。

58 分钟是供应商后来确认的影响窗口，约 2 小时 44 分钟是从开页到关闭的事件管理周期。把后者全部写成持续报错会夸大；只写前者则会抹去识别、修复和监控的不确定期。

它涉及 claude.ai、API、Claude Code 和 Cowork，并与 Haiku 部分重叠。这里能证明风险集中，不能证明共同依赖已经出错。

模型可用不等于工作流可用

17:40，另一条 critical 记录指出文档创建、Cowork Remote、Claude Code、网页版 Claude Code、Claude Tag 和 Claude Design 等功能中断。17:51 进入监控，18:03 解决。

这条短故障有独立意义。模型可能能够返回答案，而远程环境、文档或编排层仍无法完成任务。把“推理接口”和“围绕推理的工具链”作为两个监控对象，才符合实际生产依赖。

次日的 Opus 4.1 事件再增加一只时钟：08:34 识别，08:45 监控，09:00 解决，涉及 API 和 Claude Code。

严重等级不能相加

一个 major、两个 critical 和一个 minor 不是可以求和的风险分数。没有错误率、用户数量、地区和数据丢失信息，也不能推导全球经济损失或 SLA 赔付。

可以确定的影响机制是运营协调：暂停队列、逐步探测、验证恢复、决定是否切换模型或供应商。Haiku 的回退说明，恢复动作需要稳定观察窗，而不是一次成功请求。

未来的根因报告如果把四条事件映射到共同依赖，结论可以改变。在那之前，最可靠的表述仍是：Claude 的模型和工具面连续承压，用户经历可能相连，技术原因尚未被公开连接。

来源