摘要
2026 年 8 月 28 日，Anthropic 的 Claude Code（web 端）与 Claude Cowork 出现约 3 小时的 Major 级中断，部分会话无法启动或任务中途断开。Anthropic 在官方状态页将根因归于「上游云厂商（upstream cloud provider）」问题，但未点名具体厂商、未披露故障落在计算/网络/存储哪一层。Claude.ai 聊天与核心 API 全程未受影响，故障局限于上述两个 surface，属依赖类（dependency）外部依赖失效，严重度 p1。
时间线
2026-08-28 17:22 UTCAnthropic 识别到上游云厂商问题，影响 Claude Cowork 与 web 端 Claude Code，部分会话无法启动或中途断开
2026-08-28 18:21 UTC应用缓解措施，进入恢复监控；早前断开的会话可重试
2026-08-28 20:21 UTC问题完全解决，事件关闭
根因
Anthropic 官方状态页归因「上游云厂商（upstream cloud provider）」。即 Anthropic 所依赖的某云基础设施提供商发生故障，波及 Claude Cowork 与 web 端 Claude Code 的会话生命周期（启动与保持）。Anthropic 未公开该上游厂商名称，也未披露具体是计算、网络还是存储层故障。需注意：这是厂商披露的归因（dependency），但具体根因未深挖，上游厂商亦未单独发布 RCA；外界仅能从状态页记录确认「依赖类上游故障」这一性质。
放大因素
- 故障局限于 Claude Cowork 与 web 端 Claude Code，核心聊天与 API 存活，但 agentic 工作流（多步自动化任务）最敏感——会话中途死亡会留下半成品状态与不确定性。
- 单 surface / 单供应商依赖使上游厂商的坏日子直接转化为用户坏日子，本事件凸显「你的供应商还有供应商」这一传导链。
- 上游厂商未点名，外界无法独立验证根因，归因透明度有限，下游用户难以做针对性冗余决策。
缓解措施
- 17:22 UTC 识别 → 18:21 UTC 缓解 → 20:21 UTC 解决，端到端约 3 小时。
- 官方建议断开的会话可重试恢复。
经验教训
- 把 agentic 会话状态外置且可恢复，避免上游断开导致半成品与重复执行副作用。
- 关键路径须对上游云依赖做健康探测与多可用区/多供应商冗余，而非只盯模型层 failover。
- 上游厂商事故须纳入自身 SLO 与事件响应流程，即便根因不在己方。
- 对外承诺的归因应尽量点名上游与故障层，提升生态透明度与下游冗余决策效率。
检查清单
- 上游云依赖是否配置健康探测与多可用区/多供应商冗余
- agentic 会话状态是否可恢复、断开可重试、无重复副作用
- 是否将上游厂商事故纳入自身 SLO 与事件响应流程
- 对外归因是否尽量点名上游与故障层（计算/网络/存储）
- 是否对 Claude Code/Cowork 类长会话配置断点续跑
- 是否订阅 status.claude.com 并配置租户级告警