上周末，如果你是一名 Codex 重度用户，你可能会经历这样一个魔幻时刻：明明没怎么用，上午刚充值的额度到下午就见底了。类似上周还能轻松跑一整周的工作量，现在两三天就烧光了。

这不是你的错觉。OpenAI 的 Codex 确实出了大问题。

6 月 28 日到 29 日那个周末，X（原 Twitter）上开始出现大量 Codex 用户的抱怨。有人发现自己的 Pro 套餐（月付 200 美元）在 2 到 3 天内就用光了整周的额度，而之前同样的使用习惯从没遇到过这种情况。软件工程师 Adam 在 X 上写道：「我之前一整周都用不完 7 天的额度，结果最近两天每天就烧掉整整一周的量，我不得不第一次使用重置功能。」

面对汹涌而来的用户投诉，OpenAI 做了一件不寻常的事：在周日拉起了一个「作战室」（War Room）。

Codex 工程负责人 Thibault Sottiaux 周一在 X 上发帖解释说，经过紧急排查，团队发现了几个关键问题：

AI Agent 在「偷偷加班」#

第一个也是最核心的问题：Codex 的自动化功能在后台运行得比预期更多。

具体来说，Codex 内置的自动审查（auto-review）功能本应在不需要人工干预的情况下检查代码行，但它有时会重复运行甚至跑两次。辅助子 Agent（sub-agent）也存在类似问题，出错后重试得过于激进。这些后台进程像是一群不会喊累的实习生，默默地在后台燃烧着用户的额度。

Sottiaux 的原话是：「auto-review 和 helper subagents 有时候运行得比预期更频繁，要么跑两次，要么在出错后重试过于激进。」

仪表盘也在「说谎」#

第二个问题是并发的：Codex 的使用量仪表盘也在显示错误的数据。有些被记录为已消耗的额度实际上并没有真正被扣费，仪表盘把不该算的也算进去了。这导致用户看到的额度消耗比实际情况更糟糕，形成了「后台在偷偷烧额度，前台在虚报消耗」的双重打击。

用 Sottiaux 的话说，仪表盘「错误地显示了实际上并未向用户收费的活动」。

怎么修的？#

OpenAI 的应对相当迅速。周末作战室查明原因后，工程团队立即部署了修复方案，同时采取了两项果断措施：

  1. 全量重置所有用户的使用额度上限，给所有人一个干净的起点
  2. 新增了更详细的监控机制，用于更快地发现后台用量异常

Sottiaux 表示：「所有修复已部署，我们增加了更详细的监控，以便更快发现后台用量回退。我们会继续密切关注结果。」随后，OpenAI 再次对所有用户进行了全额度的重置。

这件事为什么重要？#

表面上看，这只是一次技术故障。但如果深挖下去，这次事件揭示了 AI 编程工具一个至关重要的挑战：隐性成本。

AI 编程和传统工具不同。你用 VS Code 打字的时候，计算机消耗的资源是透明且可控的。但当你给 Codex 下达一个模糊的指令（「帮我审查一下这个 PR 的安全性」），AI Agent 在后台可能执行了几十步操作：读取文件、分析代码结构、调用多个子 Agent 并行检查、在遇到歧义时反复重试。每一步都在消耗计算资源，而用户对此几乎完全无感。

这种「无感」在 AI Agent 变得日益复杂之后，正在变成一个双刃剑。一方面，用户享受到了强大的自动化能力，不需要关心底层做了什么。另一方面，当后台逻辑出问题时，用户看到的只是「我的额度怎么用完了」，而不清楚问题出在哪里。

更关键的是，AI 编程工具正处在一个激烈竞争的阶段。OpenAI 的 Codex、Anthropic 的 Claude Code、谷歌的 Gemini Code Assist 都在争夺开发者用户，而代码生成恰好是 AI 变现最清晰的场景之一。在这种背景下，任何涉及计费和可用性的问题都会变得格外敏感，因为它可能直接导致用户流失。

从「作战室」看 OpenAI 的工程文化#

抛开故障本身不谈，OpenAI 这次的响应方式也有一些值得注意的细节。

首先，周日拉起作战室这件事本身就说明问题的严重性。通常来说，如果只是一个少数用户遇到的边缘 bug，研发团队不会在休息日全员集结。这意味着 Codex 的用量异常影响面相当大，可能涉及相当比例的付费用户。

其次，工程负责人在 X 上公开发帖解释，把技术细节摊开来给用户看，这种透明沟通在 SaaS 行业并不多见。很多公司遇到类似问题会选择静默修复，然后发一封模糊的「服务已恢复」邮件。Sottiaux 的公开说明虽然不一定让所有用户满意，但至少建立了一种「我们看到了问题，我们正在解决」的信任。

最后，两次全量额度重置也展示了一种实用的用户补偿策略。虽然不是直接退款，但在用户最关心的「能不能继续用」这个问题上，重置额度是最直接的解决方案。

对我们有什么启示？#

对于 Codex 这类 AI Agent 工具的日常用户来说，这次事件有几个值得记住的点：

第一，后台自动化是一把双刃剑。 自动审查、子 Agent、后台重试这些功能确实能提升效率，但它们的资源消耗模式和你手动交互完全不同。如果工具允许，关注一下后台运行的活动数量和频率设置。

第二，定期检查使用量仪表盘。 即使在这次修复之后，养成每周看一眼额度消耗进度的习惯也是好的。用量异常往往是问题的最早信号。

第三，AI Agent 的「可控性」将成为下一阶段的竞争焦点。 当各家 AI 编程工具的功能趋于同质化之后，谁能给用户提供更透明的资源消耗视图、更精细的后台行为控制，谁就能在体验上拉开差距。这次事件实际上暴露了 Codex 在「可观测性」方面的一个短板。

Codex 的作战室事件已经落幕，但它留下的问题远没有结束。随着 AI Agent 变得越来越自主，它会替你做的决策越来越多，同时消耗的资源也越来越难以追踪。如何在「自动化便利」和「资源透明可控」之间找到平衡，将是所有 AI 工具开发者需要面对的下一个重大课题。

参考资料：