7月25日傍晚，OpenAI的API、ChatGPT及Codex全线同时出现故障，31个服务组件性能受损，历经1小时51分才恢复。单次故障虽不罕见，但更令人担忧的是，OpenAI已连续17天未有过全天候的稳定运行。
01、惊险一断
北京时间7月25日17时17分，OpenAI官方状态页显示“Investigating”，多项服务错误率飙升。18时02分转入“Monitoring”，缓解措施生效；19时08分宣布完全恢复。此次故障波及三条产品线，共计12个API组件、15个ChatGPT组件和4个Codex组件，合计31个服务组件性能下降。第三方监测站记录的故障起点UTC时间09时17分，与官方状态页完全吻合。用户端体验极为直观：请求失败、响应异常、任务中断。其中Codex的问题尤为突出，编程Agent执行任务时容易卡住，若正在处理大型项目，可能导致整个任务烂尾。
02、连续17天“带病上岗”
将时间跨度拉长至一个月，此次事故便不再孤立。第三方监测平台Bifrost的数据显示，自7月9日至今，OpenAI未曾有过一天处于“完全正常”状态：7月12日和16日发生两次重大故障，其余日期则在性能降级和部分中断之间反复切换。监测站incidenthub的记录同样密集：仅7月23日一天，OpenAI就报告了四起独立事故，涉及ChatGPT错误率和延迟；24日Codex Review报错；25日则轮到全线崩溃。官方目前对此保持沉默，合理推测原因可能在于夏季推理负载持续攀升，叠加新模型与新功能的发布节奏，导致基础设施长期处于极限运行状态。具体原因尚待官方复盘。
03、Agent时代，宕机的算法变了
两年前的宕机主要影响聊天体验，而2026年这次故障的性质已发生质变。API背后承载的是生产系统：客服机器人、代码流水线、自动化审计及Agent工作流。111分钟的中断，切断了的是生产线。监测页下方的广告语——“OpenAI挂了？自动把请求路由到健康的替代模型”——本身就是市场信号：多模型容灾已演变为一种商业模式。对企业选型而言，这组连续17天的异常记录将“可靠性”这一指标推向前台。相较于按百分比计算的能力差距，宕机造成的损失是100%。因此，合理推演有两个方向：其一，多云多模型路由将从加分项变为企业AI架构的标配，单家依赖的风险将被重新定价；其二，每次海外旗舰故障，都是国产模型承接溢出需求的窗口，前提是自家的稳定性能扛住同样的负载曲线。尽管OpenAI工程团队大概率会在数日内给出复盘，但“连续17天异常”这一事实摆在那里，市场需要的解释恐怕远比“错误率升高”这五个字复杂得多。