北京时间9月3日晚，Claude与Grok先后出现模型错误，约一小时后ChatGPT和Codex也进入异常窗口。三家的公开故障时间至少重叠约1小时33分，Grok持续时间最长，达到3小时37分。到9月4日凌晨，三家均宣布恢复。罕见的并发中断已经确认，但“同时发生”不等于“由同一个云故障触发”。

北京时间线：Claude和Grok先倒下，OpenAI随后加入

Anthropic当天20:37先记录Sonnet 5的一轮短时错误，20:56恢复；更大的多模型事件在21:26开始。四分钟后，xAI的Grok状态页开始记录模型故障。OpenAI将ChatGPT与Codex异常窗口追溯到22:43，并在23:17标记已实施缓解。三家从此进入同时受影响的阶段。

Claude的影响于次日00:16结束，解决更新在00:23发布；OpenAI于00:55宣布恢复；Grok最后在01:07恢复正常流量。按这些窗口计算，三家重叠约1小时33分。用户感受到的是“主流助手一起不可用”，运营团队看到的却是三个开始、缓解和恢复时间并不相同的事件。

这也不是所有用户百分之百同时离线。OpenAI把事件标为性能下降，账户层级、模型和具体功能的可用性可能不同；Anthropic报告的是高错误率并在恢复过程中逐步缩小到少数模型。所谓大范围，指受影响入口、模型和用户报告跨越多个平台，而不是每个请求都失败。

影响不只聊天窗口，Agent工作流更容易被放大

OpenAI状态页列出ChatGPT的15个组件和Codex的4个组件，覆盖对话、工具和远程控制等入口；恢复后，少数Codex远程控制用户还可能需要重新配对移动设备。Anthropic的影响清单包括Mythos与Fable 5.1、对应5系模型，以及Opus 5、4.8和4.6，23:25时仅Opus 4.8与Opus 5仍未回到基线。

对普通聊天，失败可能只是刷新页面；对运行几十分钟的Agent，故障会落在更棘手的位置：工具已经产生外部效果，模型却没有返回下一步；队列重试可能重复发信、下单或写入；切换模型后，工具格式和上下文状态又未必兼容。服务恢复不代表中断中的任务自动恢复到一致状态。

因此企业应把状态页事件与自身任务日志分开看。供应商宣布恢复，只说明总体错误率回到可接受范围；某个长任务是否执行过、执行到哪里、能否安全重放，必须由应用自己的幂等键、检查点和审计记录回答。

三种公开解释，尚拼不成一个共同根因

OpenAI对外将自身故障描述为路由错误，但没有发布完整根因报告；Anthropic称已识别原因，并把问题归为基础设施异常，同样没有展开技术细节；Grok状态页没有解释原因，SpaceX随后把其问题指向孟菲斯计算中心的一次中断。现有线索至少不是一个已经被三家共同确认的故事。

外界提出Azure或其他共享基础设施故障的猜测，但没有得到三家公司与相关云厂商的统一确认。也没有证据表明这是协同攻击。更稳妥的判断是：故障在时间上罕见重叠，可能包含共享网络、需求转移或纯粹巧合，但在正式事后报告出现前，不能把相关性写成因果。

编辑判断：多供应商并不自动等于容灾

这次事故给企业AI实施留下的核心问题，不是谁先恢复，而是“切换方案是否真的独立”。两个模型供应商可能共享云区、身份服务、网络出口、代理网关或同一企业连接器；主服务故障后，集中涌向备份模型还会触发限流。只在配置文件里写第二个模型名，不能证明业务拥有第二条生命线。

ATYUN编辑判断：生产Agent应为每个外部动作设置幂等键与可撤销边界，为长任务保存检查点，并用断路器阻止错误重试风暴。备用模型要定期在真实流量下验证工具协议、权限、质量和容量，关键流程还应准备降级到只读、人工审批或本地小模型。等三家发布更多根因细节后，真正值得追踪的是故障半径为何扩大，以及哪些容灾措施实际生效。