Codex也断了：OpenAI三线齐崩，Agent时代的宕机账单怎么算

7月25日傍晚，OpenAI 的 API、ChatGPT 和 Codex 三条产品线几乎是同时亮起了红灯。31个服务组件性能下降，这场故障持续了1小时51分钟才完全恢复。

单次故障倒不算什么，真正让人警觉的是，这已经是 OpenAI 连续第17天没能过上一天完全正常的日子了。

惊险一断

北京时间7月25日17时17分，OpenAI 官方状态页挂出“Investigating”信号：多项服务错误率突然飙升。18时02分，状态更新为“Monitoring”，表示缓解措施已经生效；到了19时08分，才正式宣布全部恢复。

第三方监测站记录的事故起点是UTC时间09时17分，与官方状态页的时间线完全吻合。

用户端的感受非常直接：请求失败、响应异常、任务中断。其中 Codex 的“中招”尤其值得单独拿出来说——编程 Agent 执行任务时，动不动就卡住几十分钟。服务中断在中间，如果正好在跑一个大项目，那后果可能就是整体烂尾。

连续17天“带病上岗”

拉长到一个月的时间维度来看，这次故障就不能再被当作孤例了。

第三方状态监测平台 Bifrost 的记录显示，从7月9日至今，OpenAI 没有一天处于“完全正常”状态：7月12日和16日出现了两次 Major Outage，其余时间则在 Degraded Performance 和 Partial Outage 之间来回切换。

另一个监测站 incidenthub 的记录同样密集：仅7月23日一天，OpenAI 就挂出了四起独立事故，涉及 ChatGPT 的错误率和延迟问题；24日 Codex Review 报错；25日则轮到三线齐崩。

原因层面，官方目前保持沉默。合理推演有两个方向：一是夏季推理负载持续爬坡，二是新模型与新功能的发布节奏过快，导致基础设施长期处于压线运行状态。这些当然都是推测，最终还是要等官方复盘。

Agent时代，宕机的算法变了

两年前 ChatGPT 宕机，损失的主要是聊天体验。但到了2026年，这次故障的性质已经完全不同了。

API 背后连接的是生产系统：客服机器人、代码流水线、自动化审计、Agent 工作流。服务中断111分钟，断的是什么？生产线。监测页下方那句广告语本身就是一个市场信号——“OpenAI 挂了？自动把请求路由到健康的替代模型”——多模型容灾已经做成了一门独立的生意。

对企业选型而言，这组17天的记录会把一个关键指标推到台前：SLA。模型能力榜周更易主，但可靠性是按天计分的。能力差距可以按百分比算，但宕机损失是按100%算的。

合理的推演路径有两条。

OpenAI 的工程团队大概率会在几天内给出复盘。但17天连续异常这个事实摆在这里，市场要听的解释，恐怕比“错误率升高”这五个字复杂得多。