三家最常用的 AI 服务在同一时段一起失去了响应。日本时间 2026 年 9 月 3 日深夜至 4 日凌晨，OpenAI 的 ChatGPT、Anthropic 的 Claude 以及 Grok 相继出现故障，三者都在各自的状态页面上确认了异常。从最初的异常到最后一条恢复通知，整个过程持续了约四个小时。三家同时中断并不常见，但原因似乎并不能归结为同一个。
三项服务相隔数十分钟先后停摆
最先出问题的是 Claude 和 Grok，日本时间 3 日 22 时 30 分前后开始出现连接困难的报告。ChatGPT 稍晚一些，在 4 日零时前后浮现异常。
从用户的体感来说，这次不是「变慢」，而是接近「连不上」。故障报告网站 Downdetector 收到了超过 3 万 5000 条报告，其中绝大多数与 ChatGPT 有关。虽然在日本正值深夜，但在美国是工作日的上午，因此不少人的工作被迫中断。
Anthropic 在日本时间 4 日 1 时 16 分宣布问题已解决并将状态恢复正常，OpenAI 在 1 时 55 分、Grok 一侧在 2 时 7 分先后报告恢复。三家基本在一个小时之内相继收敛。
影响范围不只是聊天界面
这次故障值得注意的一点，是影响远远超出了对话界面。
OpenAI 在状态页面上列出了 ChatGPT 侧 15 个组件与面向开发者的 Codex 侧 4 个组件受到影响。对话、登录、搜索、文件上传、语音模式、图像生成、Deep Research 以及智能体功能几乎同时劣化。官方还提示，恢复之后部分 Codex 用户可能需要重新与移动设备配对。
Anthropic 的情况类似。最初报告 Mythos 5.1、Fable 5.1 和 Opus 5 的错误率上升，随后范围扩大到包含 Opus 4.8 与 4.6 在内的多个版本。受影响的不只是 Claude 应用，还包括 API、Claude Code 和 Claude Cowork，也就是说基于 Claude 构建的内部工具与自动化流程同时停摆。
连锁反应还向外扩散。AI 编程助手 Cursor 公告称，自家服务的故障源于 Grok 与 Claude 的中断。依赖特定模型供应商的服务，上游一停就跟着停。道理并不复杂，只是这一天同时发生在两家供应商身上。
是共同原因，还是巧合
三家在同一时段停摆，很容易让人怀疑底层存在共同因素。不过就目前公开的说明来看，还无法收敛到单一原因。
OpenAI 方面被描述为太平洋时间 3 日 7 时 43 分前后开始的路由故障。这属于该公司自身的流量控制层面，并非与其他公司直接共用的部分。而 Anthropic 与 Grok 一侧尚未公布详细的技术拆解。
故障期间，某大型云平台的异常报告也在相近时段增加，因此出现了共用基础设施可能牵涉其中的推测。但这并未得到各家确认，仅停留在从状况推导出的推测层面。
更耐人寻味的是，Google 的 Gemini 始终没有官方承认故障。Downdetector 上同一时段 Gemini 的报告确实增多，但这也可能是其他服务中断后用户涌入所导致的拥堵与误报。自建数据中心与芯片的 Google 得以幸免，在思考基础设施归属方式时颇具启发性。
以「会停」为前提来设计
这次事件说明，AI 服务的可用性已不再是单一公司的问题。当开发现场把 Claude Code 或 Codex 这类智能体当作日常工具时，它们一停，工作本身就推进不下去。与表格软件或邮件不同，本地并没有可替代的手段。
现实的应对包括：保留在多家供应商的模型之间切换的能力；把重要处理放进队列以便重试；以及把各家的状态页面加入通知渠道。最该避免的，是通过用户的询问才第一次得知故障。
话虽如此，这次是三家同时停摆。即便准备了切换目标，该目标在同一时段也停摆的可能性并不为零。冗余本身并非万能——这一点同样值得记住。
总结
日本时间 2026 年 9 月 3 日深夜至 4 日凌晨，ChatGPT、Claude、Grok 三项服务在同一时段发生故障，并在约一小时之内先后恢复。影响不止于聊天界面，还波及 API、智能体功能，以及 Cursor 这类外部服务。OpenAI 提到了路由故障，但三家共同的原因并未公布，Gemini 也没有承认故障。AI 越是被放在业务的中心，停摆时的代价就越大。以多重化与重试为前提的设计，正在逐渐成为常识。
