公开了什么

2026 年 10 月 26 日，OpenAI 发布内部案例《How Ultrafast cut incident investigation from hours to minutes at OpenAI》。这是它「自家怎么用自家产品」系列的一篇，明确说明是示例，不是客户基准测试。

核心事实很具体：Ultrafast 是 Codex 的高速模式，在 OpenAI 内部，它已经是工程师处理线上故障的默认档。出问题时，他们可以同时排查多个可能原因，并在 30 秒内拿到回答。

数字，以及是谁说的

文章用的是具名工程师的复述，而不是汇总统计，这让判断容易一些：

  • AJ Trbojevic（技术人员、数据中心安全架构师）：过去做安全事件排查，要把结构化和非结构化数据拉到一起、归一化、补足上下文才能决策，需要「一到两个小时」。他说现在「10 到 15 分钟就能完成」，「有时接近实时」。
  • Aaron Friel（技术人员）通常在故障中担任主排查人。他开一个 Slack 频道，把 Codex 指向这个问题，让它持续监控、排查、随问随答。他的说法是：任何一次故障都有很多「可能是哪儿坏了」的分叉，在正确的草堆里找到那根针，才是频道里这些人真正的工作；用 Ultrafast，他可以「同时搜所有的草堆」。
  • Adam Perry（核心 agent 团队）描述的是行为变化：「以前我让 Codex 去查一件事，然后自己同时也在查，因为我知道光等它不够快。现在有了 Ultrafast，它快到我可以专心做手上的事，不用分心。」

最后这句是全文最有用的一句，而且它其实不是在讲速度。

真正的杠杆是延迟，不是能力

Perry 的比喻很直白：两个同样聪明的人，一个一分钟回你，一个一小时回你，一分钟那个明显更有用。这是吞吐量的说法，也解释了为什么「高速模式」能改变流程，而「更聪明但更慢」的模型不能。

当一次回答要十分钟，理性选择是对冲——自己也开一条线去查，因为干等不起。这种对冲让工作量翻倍，也把代理的价值抵消一半。当回答在 30 秒内，等待变成更便宜的选项，人才会从「重复劳动」切换到「指挥」。

能力提升通常改变不了这个算式，延迟可以，因为它改变的那个决定是「它跑的时候我要不要自己也上手」。

值得搬到 Windows 桌面上的结构

不需要 Codex，也不需要 OpenAI 的基础设施，这套结构在本地一样成立：

  1. 一次故障一个频道。 提问和答案落在同一个地方，代理的上下文和人的上下文才是同一个。OpenAI 用 Slack 频道；本机上可以是一个固定的笔记文件或一个终端会话。
  2. 先只读。 日志、事件查看器输出、工单、配置文件，代理应该都能查，但没有改的权限。排查和修复是两套权限。
  3. 延迟预算要真的达标。 如果代理每一步要几分钟，没人会等，你又会退回到重复劳动。量端到端的往返时间，不要看模型的跑分。
  4. 并行假设，串行结论。 同时查三个原因很便宜；同时执行三个修复不便宜。扇出只放在「读」这一侧。

还有一条案例也没法替你解决的约束：修复仍然要人。文中所有收益都集中在定位——哪个服务、哪次发布、哪个权限变更。而这恰恰是「答错只损失注意力、不损失可用性」的那一段。

如果你现在的故障处理，开头总是十五分钟在同样五个工具之间点来点去，那这段就最适合先交出去。MOOGH 跑在 Windows 上，直接操作你本来就在用的那些应用——那十五分钟通常就是它们。

相关阅读

常见问题

这是不是说故障可以不要工程师了？

不是。OpenAI 的例子是工程师在原有流程里用更快的工具，决策仍然由人做。收益来自搜索和汇总，不是自动修复。

最小可用的版本长什么样？

给一个代理只读权限去查日志，给它一个固定的汇报渠道，并要求它给出的每个结论都附上读到的日志行。光这一步就能干掉大部分手工收集的工作。