OpenAI Dev Day 现场：computer use 已经比普通人快，以及"四周前这东西还不存在"的 Decisions API（Latent Space，2026-09-30）¶

嘉宾（两段，各自独立）:
第一段（[00:01:00]–[00:20:18]）Ari Weinstein——OpenAI computer use agents 的产品与工程负责人，前 Apple（Shortcuts）、Sky 创始人
第二段（[00:20:18]–[00:39:37]）Nikunj Handa——OpenAI API 团队产品负责人，入职约三年，前 Stripe
主持: Latent Space 主播（⚠️ 现场至少两位，转录稿无姓名标签；有一位自称"as a creator"并提到"我请他来 AI engineer 做 workshop"，按本库此前材料判断是 swyx，另一位未能确定）
来源: YouTube · 40 分钟
转录稿: sources/latent-space/20260930-z9OkBD2-MDU

这期是什么：OpenAI Dev Day 当天、keynote 结束后的现场加场（"我们刚从 keynote 出来"，[00:01:00]）。所以它的性质是发布日的一手技术注解——价值在机制与取舍，而不在独立评估。⚠️ 全部产品性能数字都来自 OpenAI 一方，本库未核实。

⚠️ 本页的术语警告（必读）：转录稿是自动字幕，产品与模型名被大面积拼错。本页统一按以下还原，并在首次出现处标注：Codex（字幕作 "codeex / codecs"）、ChatGPT（"chatbt / chatgbt / JBT"）、Jev（"Jeff / Jeb / Jev"，指 TypeSafe 的 Jev）、Diogo（"Dogo / do"）、GPT Live（"GPD live / GBY live / Jubilee live"）、GPT-6.1 Soul（"GPD 6.1 Soul"）。模型代号 Astra / Luna / Soul / Spark 按字幕原样保留。⚠️ 凡本库无法确定还原的（如 keynote 上被称作 "Tijall" 的人），一律标注存疑、不猜。

概要¶

⚠️ 本期最该被记住的一句："现在 computer use 在完成任务上大概在多数情况下已经比普通人快了"，而"下一个前沿是让它真正超人——像我们这种专家级电脑用户一样快或者更快"（[00:00:00]、[00:13:13]）。
⚠️ 本库第一次拿到"前沿实验室照着一家创业公司的产品形态抄了一遍"的当事方自述：Decisions API 是 Jev 启发的，"四周前这东西完全不存在"，而主持人当面说"你们正式成为第一家克隆并采用这个的前沿实验室"，Nikunj 没有否认（[00:24:20]–[00:25:20]）。
⚠️ 而它的实现方式比"抄"更值得记：没有训新模型——"纯粹建在同一批 Luna 权重之上"，靠结构化输出约束 + 推理栈优化 + 多问题并行批处理做出来（[00:28:25]）。
computer use 的技术路线已经不是"一次一个动作"：模型会写 JavaScript 交给电脑执行、一次做很多个动作，并在截图 / 无障碍树（accessibility）/ Playwright 之间按任务切换（[00:08:08]）。
⚠️ 瓶颈已经从模型转移到网页："我们 benchmark 里有不小比例的时间其实是在等 doordash.com 自己加载"（[00:14:14]）。
⚠️ 一条产品论证本库认为最有结构价值：computer use 让 agent 能测试自己写的软件，从而闭合 SDLC——否则"你现在就是 agent 的 QA"（[00:18:18]–[00:19:18]）。
API 侧的新原语：async 工具调用、mid-turn steering（推理中途插话）、websockets、UltraFast，以及 ⚠️ 12 小时缓存命中保证与缓存预热（pre-warming）（[00:21:19]–[00:35:33]）。
⚠️ 一处被主持人逼出来的坦白：决策模型真正的差异不是延迟也不是结构化输出，而是 confidence / calibration——而这部分 "还没做，可能要靠未来的模型版本去爬坡"（[00:29:26]–[00:30:27]）。

第一段：computer use（Ari Weinstein）¶

当天发布了什么（供日后对账的一份清单）¶

（[00:01:00]–[00:02:02]）⚠️ 全部为嘉宾口述、本库未核实：

发布	他的描述
dots	新的个人助理产品，每个 dot 有自己的一台云上 Linux 虚拟电脑（⚠️ 他强调这与以往不同：以前是云上浏览器、或者你自己的电脑）
GPT-6.1 Soul	⚠️ "成本是 Astra 的五分之一；如果只看 computer use，是七分之一"
Agents API 加入 computer use	开发者可以用上和 Codex、ChatGPT 同一套 computer use
app shot	把你当前在用的东西的上下文"非常快地"带进 Codex / ChatGPT
Mac 上的原生 computer use	keynote 演示里它自动截图，"而他可以同时在电脑上做别的事"
Decisions API	见下文第二段

Decisions API 与 computer use 是不是同一个模型（[00:02:02]–[00:03:02]）：不是。Decisions API"并行做推断、没有 reasoning、模型比我们 computer use 用的那些更小"，所以非常快，但也"在长时程、复杂任务上差一些"。⚠️ 他明确说"怎么把这两套路子合起来，仍然是一个开放的研究方向"。

⚠️ 这一节是本页的核心：computer use 的技术路线怎么变的¶

他的来路（[00:06:06]–[00:07:08]）：一直在做自动化——Apple（Shortcuts）→ 创办 Sky → 加入 OpenAI。主持人的玩笑话顺带记录了一段行业史："几乎就是你得绕着 Apple 黑，直到 Apple 说'行吧，我们把你招进来，你在里面做'。"
⚠️ 他指认的最大变化不是能力，是调试（[00:07:08]–[00:08:08]）：在 Sky 时期模型差得多；"我看到的最大 delta 是，以前它们能可靠地开始任务，然后就会撞上问题；现在它们非常擅长调试，非常擅长重试、反思什么有用什么没用。"
⚠️ 三条技术变化，本库认为这是全期最该长期引用的一段（[00:08:08]）：
computer use 现在经常写代码："如果你在 Codex 里手动展开它的工具调用，你会看到它不是一次做一个动作——它实际上在写 JavaScript，交给电脑执行，有时一次执行很多个动作。"
多模态界面并用：模型可能用截图、可能用 accessibility、可能用 Playwright，"基于手头的任务"选机制。
模型本身的加速。
⚠️ "为盲人做的技术，拿给 LLM 用"——本页认为这是全期最漂亮的一条（[00:12:12]）："当年为有无障碍需求、要用读屏软件的人发明的那套技术，对 LLM 用电脑也非常有帮助。" 而工程上的难点是同时要 token 高效——"把所有东西 dump 出来，但也要高效地 dump，这里头有点手艺（a bit of an art）。"
app shot 到底是什么（他说很多人不知道这个功能）（[00:11:12]–[00:13:13]）：双击两个 command 键抓取当前 app 的内容带进 Codex / ChatGPT；点附件再点右上角那个小按钮可以看到原始文本与原始 accessibility 表示。他给的对照很清楚："你截一张有链接的网页图，截图里不包含链接指向哪里；你截日历的图，事件标题是被截断的——但 app shot 给语言模型关于一切的完整上下文。"
⚠️ "scrolling 地狱"的消失，被他列为最大的 aha moment（[00:10:11]–[00:11:12]）：过去 computer use 产品"要花大量时间滚动"——截图、尝试、发现得往下滚、再截图、再尝试、再滚；而有了 accessibility、直接访问 DOM 之类的东西，语言模型可以一次看到整页或整个应用，并写出一次做多步的代码。
他同时给了一条很不性感但很真实的补注："很多速度提升其实是由大量小的 paper cut 驱动的，我们得一个个进去排查。"

⚠️ 他对"computer use 两年没进步"的正面反驳¶

（[00:06:06]）主持人说"我们的朋友、一家头部 AI 播客以'computer use 在过去两年没有进展'这句话出名"（⚠️ 转录稿没有点名，本库不猜是谁；主持人补了一句"他是个很难被打动的人"）。

Ari 的回答："他们是几个月前说的，我希望他们现在的看法不一样了，因为 computer use 已经是 180 度不同了。"
⚠️ 本页标注这条争议的真正分歧点：Ari 给的全部证据都是harness 与工程层的（写代码、accessibility、多模态、paper cut），而他自己也承认"收益有时在 harness、有时在模型"（[00:09:10]）。所以"进步了多少"这个问题高度依赖你把 harness 算进"computer use 进步"里还是不算——而这正是本库 LLM 操作系统里 Thariq 讲的"harness 的苦涩教训" 那条线的同一个口径问题。两期相隔一天，没人把口径对齐过。

怎么度量，以及度量为什么复杂¶

（[00:09:10]–[00:10:11]）

他们有多套度量方式，其中一些跑在harness 的不同排列与配置上。⚠️ 他主动说出了一条重要的限定："这故事有点复杂，因为我们的生产产品有更多安全检查，而那些检查是按手头任务的需要分别配置的。"
结论："不管怎么度量，我们发现收益相当一致"，而"那些收益有时在 harness、有时在模型"。
keynote 上提到的 7 倍 computer use 速度提升（[00:09:10]）由主持人引用；Ari 自己特别兴奋的是 ⚠️ "GPT-6.1 对 computer use 的性价比提升，比它相对 Astra 的基线成本改善还要更大"。
⚠️ 本页标注："harness 的不同排列与配置"+"生产环境有额外安全检查"这两句合起来，意味着对外公布的 computer use 数字与用户实际体验之间存在一个未被量化的差距——他说得很诚实，但没有给这个差距的大小。本库把这条记到评估与基准。

⚠️ 瓶颈转移：现在卡在网页加载，而不是模型¶

（[00:14:14]–[00:15:14]）这是本页认为最有预测价值的一段。

他的原话："我们发现随着 computer use 变快，我们越来越被单纯的操作速度卡住。比如你在 doordash.com 上自动化一个任务，很多时间其实是在等 doordash.com 自己加载。"
⚠️ 而这推出了一个真正的工程难题："你希望在它终于加载完、和你去触发 LLM 做下一个动作之间，延迟越小越好——而这件事本身是一门统计科学。"
事件驱动只能解决一部分："能做的时候你希望它是事件驱动的——JavaScript 有 load 事件，浏览器导航有 load 事件；但还有一些类型的事件实在没法事件驱动，所以这里有很多复杂性。" 主持人给的例子是和客服聊天，回复可能 30 秒、也可能 3 分钟。
⚠️ 本库记这条为一条结构性判断：computer use 的下一阶段提速，收益会越来越多地落在"等待的统计学"而不是模型能力上——这也解释了为什么他把"超人速度"而不是"更强能力"当作下一个前沿。

⚠️ 闭合 SDLC：agent 测试自己写的软件¶

（[00:18:18]–[00:19:18]）本页认为这是全期最有结构价值的一条产品论证。

他的原话："computer use 让 agent 真的能测试它自己造出来的软件，而这件事比听起来重要得多——因为传统上你在 Codex 里造一个东西，Codex 给你造好了，然后你得去测它，于是你现在就是 agent 的 QA。"
有了 computer use，"软件开发生命周期可以闭环：agent 能造软件，也能测软件"——"我有很多乐子就是造东西、让 agent 去测，等它到我手上的时候已经是能用的了。**"
他顺带给了一个很有意思的递归："我有时在开发 computer use 本身，所以我有一个 computer use agent 在用我的 computer use agent 在用别的东西。"
主持人补了两个一手用法：① 自己做了一个视觉 play test skill，"能抓到很多你只看代码根本看不出来的设计问题"；② ⚠️ "克隆应用非常好用——如果你在用一个很烂的 SaaS 想把它干掉，就一屏一屏地克隆"（computer use 全程驱动、截图、记录，再让 Codex 克隆全部）。
⚠️ 本库交叉标注：主持人这条用法是 DHH 的"各自造自己的 5%" 那条论证在工具层的实现；而它与本库 AI 的商业与价值捕获里"SaaS 之死"那条线直接相关——这是本库第一次看到"克隆掉一个 SaaS"被描述成一条具体的操作流程，而不是一个论点。

信任曲线与给开发者的建议¶

⚠️ 他对信任变化的描述，本库照录（[00:16:16]）："三四年前我们还害怕把 LLM 接到网上、接到我们的设备上；而现在我在让它替我配 DNS、替我付账单，真的是几万美元的东西我就直接丢给 computer use 梭哈（yoloing）了——还能出什么最坏的事呢。"（原话带笑声。）
⚠️ 他给开发者最实质的一条建议，是一个本库此前没有的机制论证（[00:17:17]）："如果你想自己造 computer use harness，有很多好活可以干，但它很难；而且我们是在我们自己的 computer use harness 上训模型的。所以用模型分布内（in distribution）的那一套是有优势的——速度、成本、准确率上都可能有优势。"
⚠️ 本库标注这条的双重性：这既是一条真实的技术事实，也是一条平台锁定论证。它与 Thariq 讲的"harness 的苦涩教训" 指向同一件事的两侧：模型与 harness 共同训练会让"自带 harness"系统性吃亏。详见 LLM 操作系统。
安全侧他自己列的三条（[00:17:17]–[00:18:18]）：① 确保造出来的东西可靠；② 在做有后果的事（比如付款）之前征求用户同意；③ 按应用需要，只让它访问任务真正需要的网站或应用。 他把这归到一句话上："我们这些人在适应与信任这项技术上也许走在世界上很多人前面，所以建立信任这件事落在我们身上。"

第二段：API 与 Decisions API（Nikunj Handa）¶

新原语：async 工具调用、mid-turn steering、websockets¶

（[00:21:19]–[00:22:19]）

async function calling：⚠️ 动因很具体——"在 Codex、dots 这些东西里，工具调用耗时太长，以至于你不该在工具运行的时候把模型的执行暂停掉"；于是"你可以踢出一个工具调用，继续跑、继续推理，然后再回来查"。
mid-turn steering：模型在推理中途可以被插入消息——"你的工具调用一结束就可以把指令塞进去"。
⚠️ 主持人指出这同时是一个对齐能力（"他们得把这个能力训进去"），Nikunj 的回答把"早就有"和"现在才够好"分开了："我感觉我们在 app 里一直有，它在推理时你总是可以 steer，只是以前不够好，现在好多了。"
⚠️ 他说出了 API 团队的一条工作原则，本库认为值得单记（[00:21:19]–[00:22:19]）："我们在 API 的主要目标是：等某个东西被训进 harness 之后，再把它放进 API——所以我们会等那个时刻，等它足够好。"
底座是 websockets（[00:22:19]–[00:23:20]）："websockets 打开了与模型的整个双向通信"，async 工具调用、async 推理、插入消息都靠它。⚠️ 他说第一次上 websockets 是为了 "5.3 codex spark"——"不敢相信我们给一个模型起了这个名字"。
UltraFast 首次进 API（[00:22:19]–[00:24:20]）：主持人称之为"理论上你能拿到的最快速度 + 前沿智能"。Nikunj 给的幕后是一条顺序：⚠️ "至少有几个月，重点都放在效率和把成本压下来——这就是我们能把 Luna 价格砍 80% 的来路，很多是推理团队落地的改进；然后他们现在换挡到了'怎么让它跑得尽可能快'。"
⚠️ 一个被明确拒答的问题（[00:24:20]）：主持人说 5.3 spark 是明确归功于 Cerebras 的，而 UltraFast 与 Cerebras 的关系"你们不确认也不否认"，并补了"而你们自己也有硅"。Nikunj 没有回应这一段。 ⚠️ 本库记为"公开未确认"，相关背景见 Cerebras 一侧的材料与 AI 基础设施。

⚠️ Decisions API：本库第一份"前沿实验室照抄创业公司"的当事方自述¶

时间线（[00:24:20]–[00:25:20]）：主持人先交代自己的位置（"我们是第一个和 Diogo 做 Jev 深度访谈的播客"，即 09-21 那期），然后问"你多快看到 Jev 然后就……"
Nikunj 的回答："首先，巨大的致意给 Diogo 和 Jev 团队，他们真的启发了市场上一整个板块。Jev 一出来，所有人都疯了。我们的用户在找我们，但我们内部团队也在说：我们需要一个快得多的分类系统。"
⚠️ "四周前这东西完全不存在。"——主持人说，Nikunj确认："完全没有。对，这是 Jev 启发的。"
⚠️ 主持人当面下的判断，而他没有否认："我认为你们正式成为第一家克隆并采用这个的前沿实验室。" 他的回应是把它归给文化："OpenAI 有非常强的 hacker 文化，大家就是会对东西兴奋。推理团队的一个人、基建团队的一个很厉害的人说'这太棒了，我们要去黑一下'，他们做了个原型，它能跑，现在我们就在延迟上爬坡，想尽量快，希望接下来几天就上线——一旦打到延迟目标就发。"
⚠️ 实现方式（本页认为这比"抄"这件事本身重要得多）（[00:28:25]）："我们没有为这个训新模型。我们纯粹建在我们已有的同一批 Luna 权重之上。" 具体做法是：
约束——结构化输出是很大一块；
推理栈优化——"把 TTFT 做得非常快"；
⚠️ 并行——"因为你可以有多个问题，你就把它们并行跑，当成一个 batch 跑"。
白送的一项优势（[00:29:26]）：⚠️ "我们从 Luna 免费拿到了视觉；他们没有视觉。"
⚠️ 本页认为全期最该记的一处交锋：主持人逼出了"什么才算决策模型"（[00:28:25]–[00:30:27]）。
主持人的设问："决策模型重要的不只是延迟，也不只是结构化输出。我可以拿 Luna、关掉 reasoning、加上结构化输出——我就有 Jev 了吗？不，对吧。" 他自己给出答案："那里头有一个 confidence。"
他把这条接到了本库已有的一条线上："我们在播客上谈过 benchmark 的校准（calibration）——因为 RLHF 基本上会把你坍缩到你想听的答案那边，而不是真实的置信度。"
⚠️ Nikunj 的回答是一次坦白："我很想看它怎么发展。也许这些就会是我们要靠未来某个模型版本去爬坡的关键领域。"
⚠️ 本库的记法：Decisions API 的第一版复制了 Jev 的接口与速度，但没有复制它的校准——而按主持人的论证，校准才是这类模型的实质。这是一条可以在下一个版本上被直接检验的判断，已记入评估与基准。
架构猜测被问到但没被回答（[00:30:27]–[00:31:28]）：主持人列了外界对 Jev 的两种猜测——⚠️ ① 扩散模型而非自回归；② 某种 mech interp 式做法（分析激活、从中间层直接输出）。Nikunj 既不确认也不反驳，只指出两种都有过公开 demo（Gemini / Gemma diffusion 做过 Jev 风格的输出；也有人从中间层拉过 interp），并说"这全是猜测"。
⚠️ 主持人给了一条很有用的区分："API 谁都能做出来，其实挺 trivial 的。难的是速度，然后是准确率，然后是其它校准特性。" 他还提到 ⚠️ "过去两周大概出了 100 个 Jev 克隆"（本库未核实）。
他给的用例（[00:26:22]–[00:27:23]、[00:31:28]）：最主要是非常快的分类（内部 user ops 团队"马上扑上来，说我们得把所有支持工单分类"）；computer use 的一个可能方向——"让 Astra 写一段 JavaScript 来控制你的电脑，和让 Luna 一次挑一个动作，是不一样的；智能水平不会相同，但也许有些 computer use 任务这就够好了"；以及 ⚠️ 与 GPT Live 配合：GPT Live 是"前端模型 + 后端模型"结构（"talker 超快、很擅长委派，后面坐着 Astra 之类的"），而"工具调用在 GPT Live 里一直感觉很慢"，于是有人做了 GPT Live 控制电脑的 demo，"感觉顺滑自然得多"。主持人补了一条：eval 里 LLM-as-a-judge 对低延迟有很大需求。

⚠️ 缓存、预热与压缩：本页最可操作的一节¶

（[00:33:30]–[00:37:35]）他说 Responses API 现在的重点就是性能，而性能分两块：延迟（"我们在重写整条 Responses API 链路，把 TTFT、TBT 做到最快"）和缓存。

缓存的动因是个人 agent 的形状：⚠️ "特别是这些个人 agent，基本上是一条单线程一直一直往下走。"
⚠️ 具体承诺（本库认为这是本页最该被别人引用的几个数）：
30 分钟内的缓存命中保证（现有）；
⚠️ 12 小时缓存窗口保证——"我们刚为其中一个用户上了一个长得多的缓存窗口"，目前是 preview，还没有公开 API，"就是缓存多付一点钱"；动因很具体："即使你的 Instinct 线程做完一件事、三四个小时后再回来，你仍然拿得到缓存的性能。"
缓存读取的价格在被压低，"对开发者来说应该去实现，因为显著更便宜"。
缓存预热（pre-warming），已在 API 里：⚠️ "如果你知道自己接下来会用到这个 prompt，你可以先预热缓存、现在就付缓存写入的费用，然后它在接下来 30 分钟就是现成的"——主持人立刻接出用法："而我可以 spawn 很多个那条线程的实例。" 他的回答："正是。"
工具：用prompt / cache diagnostics 工具去查"哪里掉链子了"。
⚠️ 压缩（compaction）：三种做法被一次讲清，这是本库目前最完整的一份（[00:36:35]–[00:37:35]）。主持人先把问题立住："缓存当然很需要，但归根结底你还是会撞上一百万 token 的上下文，而这在可预见的未来大概不会变——你仍然需要好的压缩。"
① Agents API 里内建在 harness 中（OpenAI 自有的专有压缩）——"你们替我们决定"。
② Responses API 的服务端压缩："你告诉 Responses API，一旦撞到这个 token 阈值就自动压缩、把用到的上下文减下去。"
③ /compact 手动覆盖："如果你要完全控制，你可以在任何时候 /compact，用你自己的逻辑决定什么时候压。"
⚠️ 他给了一条本库此前没有的实践观察："我不知道为什么，但很多大的 coding agent 喜欢手动做。如果你看开源 Codex harness 里的实现，你会看到他们用的就是 /compact。"
⚠️ 以及一条前瞻："我们在做一些新的压缩技术，有些你已经能在 Codex harness 里看到——是一些基于文件的系统，我们在实验。" ⚠️ 本库交叉标注：这与 Thariq 讲 Claude Code 把上下文往文件里卸载是两家实验室在同一周给出的同方向答案，详见实践中使用 LLM。

⚠️ 他自己提出的开放问题：抽象层该放在哪¶

（[00:37:35]–[00:39:37]）本页认为这是全期最诚实、也最值得长期回看的一段。他的框架来自 Stripe：

类比："我之前在 Stripe，在 Stripe 很大一部分活就是在核心支付原语之上造更高层的原语与产品。我一直很好奇在 AI 里做这件事的最好方式是什么。"
⚠️ 他主动承认了一次失败："我们试过几次。我们很早上过 Assistants API，那个其实不太合适。"
现在的尝试与它的未决问题："我们现在是在走 Agents API 这条路，它给你 Codex harness——但在那里面该给多少灵活性？这是个开放问题。" 他举的具体对象是 ⚠️ "memory vaults 这类更高层的 API 对象，用来把存储这类概念抽象掉"。
⚠️ 他把这个困境讲成了一句很一般的话，本库认为值得当作一条通用观察引用："AI 里很多东西就是：有一个低层 API 原语，看一个示例 harness，然后让你的 coding agent 去实现它。但其中多少应该被内建进 API 里，是我一直在想的问题。" 他随后直接向听众求助："如果有人有想法，我很想听。"
主持人的收束框架（[00:39:37]）："你们在造一个 AI 云——这是 Sam 一年前说的话。这几乎就是在重做 AWS 的那次发明：这是 EC2、这是 S3，但你在做每一个的 AI 原生版本。"
他对反馈的具体要求（[00:33:30]–[00:35:33]）：Agents API 与 Decisions API 是最新产品，"任何反馈都要"；Responses API 是"我们的主力"，要的是底层性能反馈。原话收尾："就用起来，然后告诉我们——请替我们定义路线图。"

⚠️ 本页的四条限定¶

这是发布日的当事方叙述：所有性能、成本、速度数字都来自 OpenAI，没有第三方验证，而"比普通人快"这类表述没有给出任务集与测量方法。
⚠️ 两段都存在一处没有被追问的问题：Ari 说生产环境有"按任务需要分别配置的安全检查"（[00:09:10]），Nikunj 说长缓存窗口"是为其中一个用户上的"（[00:34:32]）——两处都暗示对外数字与一般开发者可得的东西之间有差距，主持人都没有追。
⚠️ "第一家克隆并采用的前沿实验室"这句评价出自主持人，不出自 OpenAI。Nikunj 做的是致意 + 把动因归给 hacker 文化，他没有说"我们抄了"。本页保留这个区分。
产品名在转录稿中被大面积拼错，还原规则见本页开头；凡本库无法确定的一律没有还原。