摘要
- Anthropic 把事故
q2kg8n613kr3列为“critical”，claude.ai、Claude API、Claude Code 和 Claude Cowork 起初都从正常运行转为严重中断。 - Anthropic 事后确认，7 月 29 日 19:45 至 21:26 UTC 期间，Claude 全部模型的错误率升高，症状窗口共 101 分钟。
- 公开事故记录从 19:49:45 开启，到 22:36:20 宣布解决，调查、恢复和验证周期约 171 分钟。
- 21:38 的更新称大多数模型正在恢复，但请求量和延迟仍然偏高；22:20 进入监控时，四个产品面才全部转回正常运行。
- Anthropic 没有披露根因、错误代码组合、请求总量和失败率、客户或地区数量、缓解动作、数据完整性结论或复盘。
- GitHub 在相近时段报告了未具名外部模型提供商事故，但没有点名 Anthropic；时间重合不能建立供应商身份或技术因果。
横向覆盖很广，不等于纵向影响很深
这份状态记录最明确的信息是横向范围。事故开始调查时，claude.ai、直接 API、Claude Code 和 Claude Cowork 四个组件一起从正常运行转成严重中断。标题后来把范围概括为“全部模型错误率升高”，影响等级则被标记为最高的“critical”。
这些字段能回答“问题出现在哪些入口”，却不能回答“问题有多深”。记录没有给出总请求量，也没有给出首次失败、重试成功和最终失败分别占多少。它没有说明四个产品面是否影响同一批客户，也没有按模型、组织、地区、交互式任务或批处理任务拆分。
因此，“全部模型”描述的是模型目录的覆盖范围，不代表每一笔调用都失败。“critical”是供应商用于升级响应的类别，也不是一个错误百分比、客户数或经济损失指标。公开更新始终使用“错误率升高”“大多数模型恢复”“全部模型成功率恢复”等措辞，把它写成完全不可用会超过证据。
四个产品面同步变色，只能证明共同故障域
19:49:45 UTC 事故公开后，四个组件同步进入严重中断。20:33，Anthropic 称已经识别出一个导致多个模型错误率升高的问题。21:38，它报告大多数模型正在恢复，但请求量和延迟仍然偏高；这时四个组件都从严重中断转为部分中断。
22:20，四个组件又同时恢复正常，事故进入监控。16 分钟后，Anthropic 宣布问题解决。这条状态迁移链证明，网站、API 和两个工作流产品都处于供应商公开认定的影响面内，企业不能简单地从 Claude Code 切到同一家供应商的 API，就假定已经离开故障域。
但同步变色没有揭示系统架构。共享推理服务、流量路由、共同依赖、一次发布，甚至状态页对组件的归类方式，都可能形成相似轨迹。Anthropic 没有点名任何一层，所以证据只支持“存在共同运营故障域”，不支持选择某个技术根因。
它也不能证明模型参数或输出本身出了问题。请求可能在推理前失败，在流式返回中断，也可能在工具编排、会话或远程环境中失败。Claude Code 和 Cowork 在模型调用之上还有额外状态。记录没有披露数据丢失、回答污染、安全控制失效或模型权重异常。
101 分钟症状与 171 分钟处置是两只钟
Anthropic 在 19:49:45 建立事故记录，但后来的监控更新把异常开始时间追溯到 19:45，并把结束时间定在 21:26。这 101 分钟是供应商最终确认的用户侧异常率升高窗口。
状态页直到 22:36:20 才关闭。从公开建档到解决约 171 分钟，里面包含调查、问题识别、部分恢复、监控和稳定性确认。把整段 171 分钟都写成持续高错误率，会与 Anthropic 自己的最终边界冲突。
只报 101 分钟同样会漏掉企业真正面对的恢复风险。21:26 之后，供应商还没有立即把组件转绿；22:20 之后又保留了 16 分钟监控期。客户要决定何时释放积压任务，需要判断恢复是否稳定，而不是根据事后划定的症状结束时间自动重启。
这两只钟回答不同问题：第一只钟量度已确认的异常，第二只钟量度供应商从发现到确认恢复的公开过程。可靠的事故报道必须同时保留，不能为了一个简短时长把它们合并。
自动重试会改变错误率所对应的业务体验
Anthropic 的一般 API 文档说明，500 代表内部 API 错误，529 代表临时过载；官方 SDK 默认会对连接错误、限流和 5xx 等瞬时故障进行两次指数退避重试。这些是平时的产品规则，不是本次事故的诊断。本次状态页没有披露 HTTP 代码，也没有说原因是过载。
但这些规则解释了分母为什么不能只数供应商收到的请求。如果一次业务操作首次调用失败、自动重试后成功，用户可能只感到延迟，应用记录的是成功，供应商却看到两次技术请求。如果大量客户端同时重试，尝试量又可能高于原始业务需求。
21:38 更新提到请求量和延迟偏高，却没有说明重试是否参与其中。不能据此断言重试造成负载，也不能假定所有请求都是独立业务。完整量化至少要分开原始业务操作、技术尝试总数、重试次数和重试后的最终失败。
Anthropic 文档还要求客户保留 request ID，以便支持团队定位具体调用。对于事故分析，request ID 把供应商总体现象与客户单笔证据连接起来。只有状态页颜色，没有请求级记录，企业无法解释某个队列为什么延迟或失败。
恢复要在真实工作负载边界上验证
供应商页面变绿可以触发验证，但不应直接触发全部流量。企业可先用实际使用的模型、上下文长度、流式方式和工具组合发送少量合成请求，再分阶段恢复生产流量，同时观察最终错误率、延迟、队列年龄和业务完成率。
四个产品面的事故尤其不适合一个全局健康开关。一次简短 API 调用成功，并不证明长时间 Claude Code 任务或 Cowork 工作流已经稳定。反过来，应用界面退化时，直接 API 也可能仍有价值。探针必须模拟企业真正购买的能力。
重启积压队列还要考虑幂等性。请求的响应可能丢失，但外部动作已经执行；盲目重试会重复写入或调用工具。备用模型和第二供应商也不是无成本切换，输出质量、价格、上下文、工具能力、安全行为和数据路径都可能改变。事故预案必须先定义哪些任务可以改道，哪些必须等待。
GitHub 的同时段事故不能替 Anthropic 补上身份
GitHub 在 20:07 UTC 开启了一份 Copilot 模型提供商事故。更新称向特定或外部 AI 模型提供商发出的请求错误率升高，部分用户可能遇到失败或性能下降；21:51，GitHub 称外部提供商已经解决问题，Copilot 流量完全恢复。
它的时间与 Anthropic 的 101 分钟窗口重叠，但 GitHub 没有公布供应商名称、模型列表或根因。一个产品可以同时使用多家模型提供商，同一时段也可能发生两次独立事故。仅凭时间对齐就认定 Anthropic 导致 Copilot 退化，会把相关性写成因果。
这份记录只能作为边界证据：下游平台确实可能把模型供应商故障表现为自己的服务退化，而公开依赖链仍不透明。只有 GitHub 明确点名供应商，或双方提供可关联的技术证据，才可以进一步连接两份事故。
有用的复盘必须补上分母、层次和纠正动作
当前状态页已经给出一条可信运营链：最高影响等级、全模型范围、四个共享产品面、严重中断到部分中断、正常、监控和解决。它让外部观察者看到恢复的顺序，也用两只钟限制了时长夸张。
下一份有价值的复盘应公布峰值与平均最终错误率、请求总量、首次尝试和重试后结果、受影响组织与地区，以及 API、网站、Code 和 Cowork 之间的差异。它还需要指出失败发生在哪一层、采用了什么缓解或回滚、增加了什么控制，以及复发条件如何改变。
在这些证据出现前，结论既不能淡化，也不能臆测。Anthropic 确实经历了一次横跨全部模型和四个产品面的严重事故，已确认异常持续 101 分钟，公开处置接近 171 分钟。我们知道它在哪里显现、何时转绿，却不知道多少业务操作最终失败，也不知道为什么。对于作为他人基础设施的模型服务，缺失的分母本身就是核心新闻。