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分宣布全部恢复。受影响面覆盖三条产品线：API 12个组件、ChatGPT 15个组件、Codex 4个组件，合计31个服务组件性能下降。第三方监测站记录的事故起点为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%算。合理推演是两条。其一，多云多模型路由将从加分项变成企业AI架构的标配，单家依赖的风险敞口会被重新定价。其二，每次海外旗舰故障，都是国产模型承接溢出需求的窗口——前提是自家的稳定性先扛住同样的负载曲线。

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