ChatGPT、Claude 与 Grok 接连故障：证据支持“重叠”，不支持“同一场级联事故”

同一时段里，Grok、ChatGPT/Codex 和 Claude 都出现错误，难免让人怀疑是某个底层 AI 基础设施发生了“连环故障”。但从目前公开记录看，能成立的结论更克制：三起事件的影响时间存在重叠，但各家披露的原因不同，尚无证据证实三者由同一次级联故障引发。

分开看：每家实际确认了什么？

Grok：已确认与孟菲斯计算中心故障有关

SpaceXAI 表示，Grok 的问题源于其孟菲斯计算中心当天上午发生故障，并就受影响的“计算合作伙伴”致歉。报道显示，Grok 的服务异常约在太平洋时间上午 6:30 开始，持续超过 3 小时后恢复。3941

这直接证明：孟菲斯设施确实发生了事故，且影响范围不止 Grok。不过，公开信息没有说明受影响合作伙伴是谁、具体技术故障模式为何，也没有确认哪些外部服务部署在该设施。

ChatGPT 与 Codex：已确认是路由错误

OpenAI 将 ChatGPT 和 Codex 的中断归因于一次路由错误。该问题约从 2026 年 9 月 3 日太平洋时间上午 7:43 开始，约在上午 8:17 实施解决方案后进入恢复监控阶段。39

这构成了 OpenAI 侧路由问题的明确证据；但它并不证明孟菲斯事故导致了 OpenAI 的事件。

Claude：确认出现错误并已恢复，但详细根因未公开

Anthropic 的状态页记录了多个 Claude 模型出现较高错误率，并称影响于太平洋时间上午 9:16（UTC 16:16）结束。33 同期报道将其描述为由基础设施问题导致的部分服务中断。28

但就现有公开材料而言，Anthropic 没有披露足够细的根因，也没有建立 Claude 故障与孟菲斯设施之间的联系。因此，严谨的说法应是：Claude 的确发生并解决了一起真实故障，但其底层原因在公开信息层面仍未得到充分解释。

时间重叠，不等于存在因果关系

这些服务并非在某一个已被记录的时刻同时宕机：Grok 的异常报告更早出现；OpenAI 给出了太平洋时间 7:43 至 8:17 的路由错误处置窗口；Claude 的影响则在 9:16 结束。3339

这样的重叠对业务运营当然有意义——依赖多个 AI 服务的用户，确实会在一段时间内发现多个备选方案同时不可用或性能下降。但时间相关性不是技术因果关系。共同依赖、流量外溢，甚至链式反应，都只能算假设；除非服务商进一步公布证据，否则不能将其视为事实。

目前仍不能证明的说法

基于公开证据，以下结论都尚未被证实：

• Grok、ChatGPT/Codex 与 Claude 发生了同一场跨服务商的级联故障；
• OpenAI 或 Anthropic 在受影响的孟菲斯站点运行生产推理工作负载；
• Azure、Cloudflare 或某一家特定云服务、CDN 或网络服务商是共同根因；
• 根据故障报告网站得出的“受影响用户总数”是经过审计的真实用户数量；
• 某一次 Cursor 异常、编程智能体中断或下游工作流失败，必然由其中任一服务商故障引起，而非集成、认证、排队、限流、网络或客户端问题。

Cursor 的状态页确实报告了上游 OpenAI 和 Anthropic 模型的错误率升高，这可以支持“部分 Cursor 异常与上游服务商有关”的解释；但它本身不足以解释每一次失败的智能体调用或客户工作流。30

真正的教训：多模型，不自动等于高韧性

孟菲斯事件中提到未具名“计算合作伙伴”，提醒了一个常被忽视的事实：基础设施依赖往往并不透明。

一个应用即使同时调用多家模型 API，仍可能共享同一身份认证服务、DNS 或 CDN 路径、云区域、GPU 托管方、模型网关、代码托管平台、可观测性服务或工具后端。

换言之，API 层面的供应商多样化，不必然意味着基础设施层面的独立性。 只有当模型之外的关键依赖也能承受故障时，备用模型端点才是真正有用的冗余。

如何为数小时级 AI 服务中断做准备

1. 画出完整依赖链

维护服务依赖图，列出模型 API、网关、云区域、DNS/CDN、身份认证、向量数据库、消息队列、代码托管、工具集成与可观测性平台等关键环节。同时记录已确认的分包服务商，以及尚不清楚的依赖。

2. 在真实负载下测试故障切换

提前接入替代服务商或较小规模、本地部署的模型，并以真实提示词、结构化输出、工具调用、安全要求、吞吐限制和成本控制进行切换演练。一次演示请求成功，不代表备用方案能支撑生产业务。

3. 让智能体能够安全失败、可靠恢复

采用超时控制、带抖动的有限重试、熔断器、幂等键、持久化检查点，以及明确的暂停/恢复语义。不可逆操作应要求人工审批。故障恢复后，智能体应从记录状态继续，而不是重复执行部署、采购、建单或外部 API 操作。

4. 在事故发生前定义降级模式

明确没有模型访问时哪些能力仍可运行，例如搜索、表单、规则路由、排队起草、只读访问、人工升级处理，以及面向客户的清晰提示。还应设定最大排队时长、人工处理能力、客户通知阈值，以及何时必须停止自主操作。

5. 完善供应商沟通与事件取证

订阅供应商状态通知，建立升级渠道，并在合同允许的范围内约定故障通知时限、事故复盘报告要求和数据可迁移条款。事故期间，应保留 UTC 时间戳、请求 ID、响应头、错误内容、链路追踪、路由记录、智能体状态、队列日志及状态页快照。这些证据是区分“上游服务商故障”与“自身集成故障”的关键。

6. 在关键业务上追求真正独立性

对于高后果工作流，备选方案应尽量在模型服务商、区域、云平台、网络路径、认证依赖和运营控制面上都存在差异。两个模型端点若共用同一网关或同一云区域，就不算有意义的冗余。

结论

9 月 3 日的事件不能被当作“全球 AI 统一宕机”的证据，更不能据此认定是由孟菲斯引发的三方级联故障。它确实说明了一点：看似独立的 AI 服务可能在同一窗口内同时受损，企业应当据此设计可安全持续运行的系统；至于具体因果关系，则应严格以服务商后来披露的证据为准。333941