警惕！AI服务大面积中断，稳定性成最大隐患
[ AI 基础设施 · 实地考察 ]
三年来，我们一直忧虑 AI 是否会失去控制。
北京时间 9 月 3 日深夜，现实给出了一个更具冲击力的答案：
AI 并未失控，反倒先陷入了“断网”的尴尬境地。
许多用户遭遇了令人哭笑不得的循环：ChatGPT 报错，切换到 Claude；Claude 也不稳，再开 Grok；结果第三个也提示过载。
对于偶尔尝鲜的用户，这只是几十分钟的烦恼；但一旦 AI 深入代码编写、客服、报价、数据分析、内容创作，乃至订单和审批流程，问题性质就截然不同了：
若多家主流模型同时出现异常，企业的业务还能维持多少？
网络上最流行的说法是：GPT、Claude、Grok，甚至 Gemini，都在同一时刻全面宕机。
更准确的描述是：三家主流 AI 服务商在约 77 分钟的时间窗内，先后出现了不同程度的服务故障。
21:26，Anthropic 开始调查 Claude 多个模型请求错误率升高的问题；21:30，xAI 的 Grok 出现模型中断；到 22:43，OpenAI 也开始调查 ChatGPT 与 Codex 的错误率升高。[1][2][3]
核心边界：时间重叠仅能证明“同期异常”，不能直接推导“同一根因”。截至发稿，三家公司尚未公布能将三起事故串联起来的统一原因。
Claude 更像是模型层故障。最初受影响的型号覆盖 Mythos/Fable 5.1、Mythos/Fable 5、Opus 5、Opus 4.8 和 Opus 4.6；随后大部分模型恢复，故障范围逐步收窄。Claude 网页、API、Claude Code 和 Cowork 被标记为部分中断。[2]
Grok 表现出明显的产品端与区域差异。网页端、iOS、Android、X 内置 Grok、Build、办公插件，以及美国东部和西部 API 区域均出现异常；但欧洲 API、单点登录、API 控制台与官方文档仍然可用。[3]
OpenAI 则更接近平台级异常。官方状态页列出 15 个 ChatGPT 组件和 4 个 Codex 组件受到影响，并已应用缓解措施、监控恢复。用户端可能波及登录、文件上传、语音、搜索、深度研究和图片生成等功能。[1][4]
若三家真的因为同一个全球网络节点、同一台服务器或同一家基础设施供应商而集体中断，通常会出现更一致的地域和组件特征。但这次看到的是三组不同的故障指纹。
因此，现在断言“某一家云厂商崩了”“遭遇统一攻击”或“三家公司共享同一套服务器”，都还为时过早。
三家巨头未必共享服务器，却正在共享同一批用户、同一批开发者，以及越来越相似的自动回退逻辑。
当 ChatGPT 出现问题时，用户会立刻打开 Claude 和 Grok；企业的模型路由器也会把失败请求切换到备用供应商；随后客户端超时、自动重试，Agent 工作流重新执行，队列中的任务再次提交。
这就是分布式系统里常见的重试风暴与流量踩踏。AWS 的可靠性指南明确提醒：当失败由资源过载引起时，重试可能让情况更糟；Google SRE 也把服务器过载视为级联故障最常见的起点。[5][6]
这并非对本次事故根因的官方结论。
它是一种值得企业提前防范的架构风险：一家服务商的故障，可能通过用户迁徙、自动切换和同步重试，把容量压力传播到原本健康的服务。
传统网页请求往往几十毫秒就结束；一次深度研究、代码生成或 Agent 任务，却可能持续数分钟，背后包含规划、搜索、网页读取、模型推理、工具调用、代码执行、事实核对和最终汇总。
用户看到的是一个任务，服务器收到的可能是几十次调用。
更麻烦的是：任务执行到第八步失败，如果系统没有检查点和状态恢复能力，所谓“重试”不是重发一次请求，而是整条调用链从头再跑。于是，服务异常期间的实际计算压力，可能被工作流成倍放大。
很多系统表面上同时接入 OpenAI、Claude、Grok 和 Gemini，看起来已经完成多供应商容灾。但继续往下看，所有模型可能仍然共用同一个聚合网关、同一个云区域、同一个身份认证、同一个任务队列，甚至同一条代理线路。
这就像在同一个插线板上，插了三台不同品牌的电脑。
电脑确实来自三家公司，但插线板一断电，品牌多样性没有任何意义。
真正多模型容灾，不只是供应商名字不同，还要尽可能做到：调用路径独立、区域独立、认证独立、业务状态独立保存，并拥有经过演练的切换机制。微软的可靠性框架同样强调，冗余设计需要隔离单个资源故障，并为失效期间准备足够备用容量。[7]
服务彻底打不开，反而容易处理：系统立即报错，用户知道任务没有完成。
更危险的状态是：请求偶尔成功、偶尔失败；延迟从 10 秒变成 3 分钟；系统悄悄切换到能力更弱的模型；工具动作已经执行，但最终结果没有返回；Agent 误以为失败，再次重复操作。
当 AI 连接真实业务，重复执行可能意味着：
同一笔退款发起两次；同一封邮件发送两遍；数据写入一半后中断；内容已经发布，系统却再次发布；代码已部署，Agent 仍继续修改。
这就是为什么，所有会产生真实副作用的操作都必须具备幂等性。Stripe 的 API 设计使用幂等键，让连接错误后的重复请求不会意外执行两次同一操作。[8]
第一层：业务状态必须掌握在自己手里。聊天记录、任务进度、客户数据和中间产物不能只存在某一家模型的线程里。模型应该是可替换执行器，而不是企业唯一的记忆体。
第二层：切换必须基于实时健康度。不能设置成“GPT 失败一次，就把所有流量打给 Claude”。系统要根据成功率、延迟、错误类型逐步切流，并加入熔断、最大重试次数、指数退避和随机抖动。
第三层：所有业务动作必须幂等。退款、发信、发布、创建订单、写数据库，都应绑定唯一任务编号与执行记录；不能因为模型说“刚才好像失败了”，就无条件再做一遍。
第四层：为关键流程准备降级模式。分类、抽取、模板回复、敏感词检查可以由小模型或本地模型临时接管；高风险决策进入队列或转人工，不要为了保持“AI 在线”而盲目降质。
第五层：监控端到端业务成功率。厂商状态页显示绿色，不等于你的系统真的可用。OpenAI 也明确说明，其可用性指标是跨套餐、模型和错误类型的聚合数据，具体用户体验可能不同。企业真正应监控的是：报告是否完整生成、订单是否闭环、代码是否通过测试。[1]
今天的大模型行业已经解决了大量“发电”的问题：模型更强、Token 更便宜、推理更快。
但“电网”还远远没有成熟。大家仍然把注意力集中在跑分、参数量和榜单，却很少追问：它一个月中断多少次？任务能否从检查点恢复？模型切换后质量是否可控？已经执行的动作能否追踪、去重和撤销？
下一阶段的竞争，不只是哪个模型聪明 5%。 而是谁能把智能做成一种 稳定、可切换、可恢复、可审计的能力。
我们担心了三年 AI 会不会失控。
现在更紧迫的问题可能是：AI 还没失控，先失联了。
而对于已经把 AI 接入生产系统的人来说，这不是一个小故障，而是一场提前到来的基础设施考试。
—— AI约翰
事实边界说明
本文以北京时间 2026 年 9 月 4 日凌晨前后的公开状态为截面。三家厂商尚未公布能够相互印证的统一根因。文中关于用户迁徙、自动切换、重试风暴与单点依赖的部分，是基于厂商状态、分布式系统可靠性原理和历史故障模式作出的架构分析，不代表厂商官方事故结论。
资料