OpenAI Ultrafast 在 Codex 中：将事件调查从数小时缩短至数分钟
OpenAI 于 2026 年 10 月 26 日发布了一份内部案例研究，描述了其工程师如何将 Codex 中的高速模式 Ultrafast 作为事件响应的默认工具。其核心主张是操作层面的，而非基于基准测试：过去需要一到两小时整合结构化和非结构化数据的安全调查，现在只需 10 到 15 分钟即可完成，而且单个答案通常能快速返回（约 30 秒内），使工程师在 Codex 工作时无需频繁切换上下文。
摘要
Ultrafast 是 Codex 中的一种高速模式，OpenAI 报告称其技术人员已将其作为事件响应、安全调查、重构和日常规划的默认选择。文中主要的量化结果是，过去需要一两个小时的安全调查现在只需 10 到 15 分钟，有时接近实时。该文章是 OpenAI 系列内容的一部分，分享公司如何使用自身技术和 API 的内部示例，并作为说明性示例而非已发布的基准测试结果。
根据来源，Ultrafast 是什么
Ultrafast 是 OpenAI 编码代理 Codex 中的一种高速模式。文章围绕延迟容忍度来介绍该功能：当生产环境出现故障时，工程师无法等待数分钟才能得到答案，而事件会不断恶化，因此更快的模式让他们能够同时调查多个潜在原因。
来源未发布 Ultrafast 的工程规格。文中未提及令牌吞吐量数据、模型版本标识符、硬件细节或延迟百分位测量。文中所有定量内容均来自 OpenAI 具名员工描述自己的工作流程。
事件响应：同时搜索多个“干草堆”
OpenAI 的事件工作流程以 Slack 频道和指向问题的 Codex 线程为中心。OpenAI 技术团队成员 Aaron Friel 通常负责事件处理：他会创建一个事件响应 Slack 频道，然后指示 Codex 监控、调查并回答问题。
“在任何事件中，通常有许多环节可能出错，在正确的干草堆中找到正确的针是该频道上人员的主要工作。使用 Ultrafast，我基本上可以同时搜索所有这些干草堆，并更快地响应事件。”
这种并行调查模式是文章的核心结构主张：工程师不是串行地提出假设，而是让 Codex 同时追踪多个候选原因，并在事件仍在进行时报告结果。
安全调查：从一到两小时缩短至 10 到 15 分钟
文章中最具体的数字来自 OpenAI 技术团队成员兼数据中心安全架构师 AJ Trbojevic。他描述了过去的安全调查流程需要一两个小时来收集结构化和非结构化数据、规范化数据，并整理出足够的上下文来做出决策。
“现在这只需 10 到 15 分钟。有时接近实时。”
这是文章“从数小时到数分钟”框架背后的数字。这是从业者自我报告的工作流程比较，而非受控基准测试，来源未说明样本量、涉及的事件类型或测量方式。
30 秒阈值
文章中 Ultrafast 的实际价值由人类注意力限制而非机器指标定义。另一位技术团队成员 Jeff Niu 阐述了自己的规则：如果使用 AI 找到答案需要超过 30 秒，他会转而使用 Slack 或询问同事。
使用 Ultrafast，Niu 报告说他的大部分工作现在都在该阈值以下。他描述了过去的模式：向 Codex 提问，在它思考时切换到其他事情，然后回来时已经失去了思路。他强调的变化是对话的连续性：交流现在实时进行，这使他能专注于手头的任务。
30 秒的数字是 Niu 个人的切换阈值，并非 Ultrafast 的文档化性能保证。
重构和技术债务
更快的响应改变了工程师愿意开始的工作。Niu 表示，Ultrafast 使他更愿意承担大型重构，因为修改现有代码所需的时间更少。
“现在偿还技术债务比以往任何时候都容易。代码很便宜，而且现在生成非常快。过去成本高昂的重构现在几乎瞬间完成。”
这里的主张是行为层面的而非财务层面的：更低的交互延迟降低了开始重大变更的感知成本，因此被推迟的清理工作得以完成。
Codex 作为日常持久副驾驶
Adam Perry 和 Sayan Sisodiya 都在核心代理团队工作，该团队构建使 Codex 能够采取行动、运行命令和使用工具的程序，他们描述了两种日常模式。
Perry 保留了一个他称之为“参谋长”的常驻 Codex 线程。每天早上，它会报告他的会议并标记他可能忘记回复的消息。
“它已经查看了所有数据来编写该摘要，所以当我提出后续问题时，它不需要等待获取更多数据。我可以像对待真正的参谋长一样，在同一个对话中继续提问。”
Sisodiya 使用 Codex 进行基于浏览器的手动工作，例如填写表单，这是他以前因太慢而避免的任务。
“它会打开浏览器，思考五秒钟，点击某个东西，然后再思考。”
他将自己改变意愿归因于最新模型中计算机使用能力的改进，以及 Ultrafast 的速度。
“现在我可以完全放心地让它点击浏览器，而且速度足够快，我不会因为不自己做而浪费时间。”
为什么工程师不再与 Codex 并行运行
在 Ultrafast 之前，工程师将 Codex 视为后台任务，不能指望它及时返回。Perry 直接描述了旧行为：
“以前，我会让 Codex 调查某事，然后同时自己去调查，因为我知道它不够快，不能只等它。现在有了 Ultrafast，Codex 足够快，我可以保持专注，而不是分散注意力。”
Sisodiya 描述了在事件期间不仅使用 Codex 分析日志，还搜索 Slack 以查找可疑更改的引用或其他人在工作区其他地方报告类似症状的情况。
“除了在事件中挖掘日志，我还使用 Codex 搜索 Slack，看看是否有可疑更改的引用，或者是否有人在 Slack 的其他地方讨论类似症状。”
所有五位工程师反复出现的主题是，延迟而非能力决定了他们是否委派工作。文章自己的结论是，Ultrafast“让 OpenAI 的技术人员能够以提问的速度与 Codex 协作”，使他们能够跟进答案或尝试其他方法而不会失去思路，并改变了他们愿意承担的工作。
文章声称了什么，没有声称什么
来源中所述：
- Ultrafast 是 Codex 中的一种高速模式。
- OpenAI 工程师将其作为事件响应的默认选择。
- 安全调查从“一两个小时”缩短至“10 到 15 分钟”，有时接近实时，据 AJ Trbojevic 所述。
- 30 秒的答案阈值决定了 Jeff Niu 是继续使用 AI 还是切换到 Slack 或同事。
- 更快的响应增加了承担大型重构的意愿，据 Jeff Niu 所述。
- Codex 用于日常规划摘要和基于浏览器的表单填写，并引用了最新模型中的计算机使用改进作为这一转变的一部分。
来源中未提及：
- 没有基准分数、延迟百分位、吞吐量数字或模型版本标识符。
- 没有描述 Ultrafast 的技术实现方式。
- 没有小时到分钟比较的测量方法。
- 没有 Ultrafast 的定价、可用性或发布信息。
该文章明确作为 OpenAI 系列内容的一部分，分享 OpenAI 如何使用自身技术和 API 的内部示例，作为前沿 AI 支持其团队用例的说明性示例，而非产品公告或评估。