摘要
- 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的模型和工具面连续承压，用户经历可能相连，技术原因尚未被公开连接。
