OpenAI连续17天故障

7 月 25 日傍晚，OpenAI 的 API、ChatGPT、Codex 三条产品线同时报错。31 个服务组件性能下降，故障持续 1 小时 51 分钟。但这不是一次孤立事件：侧录数据显示，从 7 月 9 日至今，OpenAI 没有一天处于”完全正常”状态。

三线齐崩的 111 分钟#

北京时间 17 时 17 分，OpenAI 官方状态页挂出”Investigating”。18 时 02 分进入”Monitoring”，19 时 08 分宣布全部恢复。受影响面覆盖 API 12 个组件、ChatGPT 15 个组件、Codex 4 个组件，合计 31 个服务组件性能下降。第三方监测站记录的事故起点与状态页完全吻合。其中 Codex 中招尤为致命：编程 Agent 执行任务动辄卡住几十分钟，服务断在中间，如果在跑大项目，整体进度都可能烂尾。用户侧的感受非常直观：请求失败、响应异常、任务中断，每一次刷新都在赌运气。

连续 17 天带病上岗#

把视角拉长到一个月，这次事故就不能被看作孤例了。第三方监测平台 Bifrost 的记录显示，从 7 月 9 日至今，OpenAI 没有一天处于”完全正常”状态。7 月 12 日和 16 日两次 Major Outage，其余日期在 Degraded Performance 和 Partial Outage 之间来回切换。另一个监测站 incidenthub 的记录同样密集：仅 7 月 23 日一天，OpenAI 就挂出四起独立事故，24 日 Codex Review 报错，25 日轮到三线齐崩。原因层面官方保持沉默，合理推演有两个方向：夏季推理负载持续爬坡，叠加新模型与新功能的发布节奏，基础设施长期处于压线运行状态。

Agent 时代的宕机算法变了#

两年前 ChatGPT 宕机，损失的主要是聊天体验。2026 年的故障性质已经换挡。API 背后是生产系统：客服机器人、代码流水线、自动化审计、Agent 工作流。服务中断 111 分钟，断的是生产线。监测页下方那句广告语本身就是市场信号：“OpenAI 挂了？自动把请求路由到健康的替代模型”，多模型容灾已经做成了一门生意。对企业选型而言，这组 17 天的记录把一项指标推到了台前：SLA。模型能力榜周更易主，可靠性却按天计分。能力差距按百分比算，宕机损失按 100% 算。

这组 17 天的记录把 SLA 推到了台前。能力差距按百分比算，宕机损失按 100% 算。每次海外旗舰故障，都是国产模型承接溢出需求的窗口：前提是自家的稳定性先扛住同样的负载曲线。OpenAI 的工程团队大概率会在几天内给出复盘，但 17 天连续异常这个事实摆在这里，市场要听的解释恐怕比”错误率升高”五个字复杂得多。

来源：36kr