OpenAI 三线齐崩 17 天连续异常 Agent 时代的宕机账单怎么算

7 月 25 日傍晚，OpenAI 的 API、ChatGPT、Codex 三条产品线同时报错，合计 31 个服务组件性能下降，1 小时 51 分钟后恢复。这并不是一次孤立的故障——第三方监测数据显示，OpenAI 已经连续 17 天没有出现过「完全正常」的服务状态。在 Agent 逐步嵌入生产线的背景下，每一次宕机的成本计算方式正在被改写。

故障时间线与影响面

北京时间 7 月 25 日 17 时 17 分，OpenAI 官方状态页挂出「Investigating」，提示多项服务错误率升高；18 时 02 分进入「Monitoring」，缓解措施生效；19 时 08 分宣布全部恢复，总历时 1 小时 51 分钟。

受影响组件覆盖三条产品线：

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 日一天就挂出四起独立事故，涉及 ChatGPT 错误率和延迟；7 月 24 日 Codex Review 报错；7 月 25 日则演变为三线齐崩。

关于根因，OpenAI 官方未给出复盘说明。结合时间窗口，一个合理推测是夏季推理负载持续攀升，叠加新模型与新功能的高频发布节奏，基础设施长期处于压线运行状态。不过这一判断仍需等待官方的事后分析。

Agent 时代，宕机的算法变了

两年前 ChatGPT 宕机，损失的主要是聊天体验；2026 年的这次故障，性质已经换挡。API 背后连接的是客服机器人、代码流水线、自动化审计和 Agent 工作流，服务中断 111 分钟相当于生产线停摆。监测页面下方那句「OpenAI 挂了？自动把请求路由到健康的替代模型」本身就是市场信号——多模型容灾正在变成一门生意。

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

由此可以推演出两条趋势：

多云多模型路由将从加分项变成企业 AI 架构的标配，单一供应商依赖的风险敞口会被重新定价。
每次海外旗舰故障，都是国产模型承接溢出需求的窗口——前提是自身的稳定性先扛住同等的负载曲线。

OpenAI 工程团队大概率会在几天内给出技术复盘。但 17 天连续异常这一事实摆在这里，市场需要的解释，远比「错误率升高」这五个字复杂得多。