Why Dwarkesh is Wrong about Computer Use + How OpenAI shipped its Jev competitor in 1 Week｜深度中文详解

播出信息

• 日期：2026-09-30
• 时长：2352 秒（39 分 12 秒）
• 音频：收听节目
• YouTube：无
• Episode：节目页面
• 英文转写来源：latent.space_vtt

背景

这期 Dev Day 特别节目分为两段访谈。前半段，主持人与负责电脑操作智能体产品和工程的 Ari 讨论 Dots、Codex 中的电脑操作能力，以及模型如何借助截图、无障碍信息和网页结构完成任务。后半段，负责 API 产品的 Nikunj 介绍异步工具调用、WebSockets、Decisions API，以及缓存、上下文压缩等平台问题。

标题中的两条线索分别是：主持人转述 Dwarkesh 对“电脑操作近两年进步不大”的判断，并请 Ari 回应；以及 OpenAI 受到 Jev 启发，迅速做出决策类 API 原型。节目并未提供一场严格的能力对比测试，也没有完整披露 Decisions API 的上线时间表。

总结分析

本集最有价值的区分，是把“电脑操作进步了”拆成模型、工具表示和运行环境三个层面。Ari 认为，早期智能体往往能可靠地开始任务，却容易在出错后停住；现在的模型更会检查失败原因、重试，必要时还会写代码。与此同时，智能体也不再只能反复截图和滚动：AppShots 提供应用的无障碍结构，网页任务可以利用 DOM，具体任务还可选择 Playwright 等机制。这解释了为什么能力提升不能简单归功于某一次模型发布。

但更快并不等于可以无条件放手。Ari 说，任务执行加速后，等待页面加载、判断客服何时回复等操作本身开始成为瓶颈；而支付、访问外部服务等行为，又要求产品建立授权和边界。后半段把同一问题带到 API 层：异步调用与 WebSockets 试图减少模型等待工具的时间；Decisions API 则用现有 Luna 权重、结构化输出和并行推理，切入快速分类等场景。它令人关注的地方是产品化速度，而不是节目已经证明它在准确率、置信度校准上胜过 Jev。贯穿两段访谈的主线因此是：智能体的竞争越来越取决于模型之外的系统工程——如何给模型合适的观察方式、减少等待、复用上下文，并在高风险动作前保留人的控制权。

节目结构 / 议程

1. Dev Day 新品与电脑操作入口 — 00:04 🎧
2. 回应“电脑操作没有进步”：模型与运行框架的变化 — 05:14 🎧
3. AppShots：从截图走向结构化观察 — 09:28 🎧
4. 速度瓶颈、安全边界与智能体自测 — 12:12 🎧
5. API 如何支持异步工具调用与高速交互 — 19:33 🎧
6. Decisions API：受 Jev 启发的快速决策接口 — 23:25 🎧
7. 应用场景、缓存、压缩与平台抽象 — 30:28 🎧

分节详解

1) Dev Day 新品与电脑操作入口 — 00:04 🎧

💬 他们说了什么：Ari 概述了 Dots 个人助理、GPT 6.1 Sol、加入电脑操作能力的 Agents API，以及把当前应用上下文送入 Codex 或 ChatGPT 的 AppShots。她特别指出，每个 dot 可以访问云端独立的 Linux 虚拟电脑；这与只给智能体一个云浏览器不同。主持人举例说，YouTube 有些创作者操作没有相应 API，因此让智能体直接操作界面很有吸引力。Ari 也谈到自己订餐时，精细配置一笔订单曾花去约两小时。

💡 为什么重要：电脑操作补的是传统 API 的覆盖缺口。它让开发者有机会处理那些必须经过图形界面、配置步骤繁琐，或需要跨应用完成的任务；独立虚拟环境则为较长的个人助理工作流提供了运行场所。

⚡ 争议点：“能操作任何界面”不等于稳定完成任何任务。涉及登录、网站规则、付款和任务中途状态变化时，通用性需要与可靠性、权限管理一起评估。本段提到的 Decisions API 也不是电脑操作模型本身：Ari 说明它更小、更快，但不以长程任务推理见长。

2) 回应“电脑操作没有进步”：模型与运行框架的变化 — 05:14 🎧

💬 主持人请 Ari 回应 Dwarkesh 关于电脑操作进展的说法。Ari 以自己从 Apple Shortcuts、Sky 到 OpenAI 的经历作对照：过去模型常能开始任务，却在遇到问题后卡住；现在更擅长调试、重试和判断哪里出了错。她说，智能体有时会写代码，并根据任务选用截图、无障碍接口或 Playwright。她认为，若要解释当天演示的变化，观察过去一两个月的累积进步比只比较前后一天更有意义。节目也提到主题演讲宣称电脑操作速度提升约 7 倍。

💡 能力变化既来自模型，也来自让模型行动的运行框架（harness）。Ari 说内部会在不同框架配置下测量表现，生产环境还需加入因任务而异的安全检查。因此，单看模型名称或一次演示，都不足以解释实际体验。

⚡ Ari 认为“几乎没有进步”的判断已经过时，但节目没有给出 Dwarkesh 原话的完整语境，也未展示可复核的逐项基准结果。“7 倍”应视为节目转述的发布会指标，而非所有任务都能获得的速度提升。

3) AppShots：从截图走向结构化观察 — 09:28 🎧

💬 Ari 举出旧式工作流的低效之处：智能体截一张图、尝试操作，再为寻找下一项结果不断滚动并截图。通过无障碍信息、DOM 等结构化入口，模型可以获得不局限于当前画面的内容。她还介绍 AppShots：在 Mac 上连按两个 Command 键，可将应用上下文带入 Codex 或 ChatGPT；用户能在附件中查看其原始文本和无障碍表示。与普通截图不同，AppShot 可以保留链接目的地、被界面截断的日历标题等信息。

💡 给智能体什么样的“观察结果”，直接影响它能否理解页面、定位控件，以及要花多少步骤寻找信息。把界面内容整理成较省 token 的表示，也关系到长任务的成本和速度。

⚡ 结构化表示并非总能代替视觉检查，且不同应用所能提供的无障碍信息可能不同。Ari 强调的是多种观察方式按任务搭配，而不是宣称 AppShots 可无损读取所有应用数据。

4) 速度瓶颈、安全边界与智能体自测 — 12:12 🎧

💬 Ari 判断，经过近几个月改进，电脑操作完成不少任务已可能快于普通人；下一步的障碍却未必只在模型。页面加载、操作生效、客服回复都需要等待，其中客服消息可能隔 30 秒，也可能隔 3 分钟。她希望在可行时使用事件驱动机制，并尽量缩短“加载完成”到模型下一步行动之间的延迟。谈到开放给开发者的 Agents API，她提醒：OpenAI 的模型在自家电脑操作框架上训练，直接使用该实现可能在速度、成本或准确性上占优，但产品仍须建立可靠性检查，并在付款等重要动作前征得同意。她尤其看好让智能体测试自己写出的软件：由智能体完成构建、运行和检查，而不是把全部 QA 留给用户。

💡 智能体开始覆盖软件开发的完整反馈循环，也让“工具完成后何时唤醒模型”成为性能问题。与此同时，能力越强，越需要明确哪些网站可访问、哪些动作须由人确认。

⚡ 主持人分享了让智能体处理 DNS、账单等高风险事务的个人经验，不应被当作通用安全建议。Ari 关于“多数情况下快于普通人”的表述，也缺少本集可核对的任务范围和测试方法。

5) API 如何支持异步工具调用与高速交互 — 19:33 🎧

💬 第二段访谈中，API 产品负责人 Nikunj 介绍 GPT-6 的异步函数调用：模型发出工具调用后，不必一直暂停，可以继续推理，再回来查看结果。他也谈到通过 WebSockets 进行双向通信、注入消息和降低工具往返开销，以及 API 中的 UltraFast。按他的说法，推理团队先着力提高效率与降低成本；节目提到 Luna 价格降低 80%，随后团队进一步追求运行速度。

💡 当智能体频繁调用工具，等待与通信开销会累积成显著延迟。异步执行和持久在线连接，针对的正是模型能力之外的交互瓶颈。

⚡ 主持人问及 UltraFast 与 Cerebras 的关系，并提到 OpenAI 自有芯片；嘉宾没有确认其具体硬件来源。节目也未给出不同任务、不同 API 配置下的统一速度比较。

6) Decisions API：受 Jev 启发的快速决策接口 — 23:25 🎧

💬 Nikunj 明确称赞 Jev 团队开拓了这一市场方向。OpenAI 的用户与内部团队都希望获得更快的分类能力，于是工程人员用现有 Luna 权重搭建原型，而非为首版重新训练模型。他描述的办法包括约束结构化输出、优化首 token 延迟，以及将多个问题并行、批量执行；Luna 原有的视觉能力也随之可用。他称这项工作“一周前才开始”，当时仍在继续压低延迟，希望达到目标后于未来几天推出。讨论中还提到，四周前并没有这个既定项目。

💡 这是一则产品与推理工程快速组合的案例：同一基础模型可以通过输出约束和服务栈优化，变成面向分类、判断等短任务的接口。Nikunj 也提到客服工单分类，以及与实时语音产品结合、降低工具调用等待感的可能性。

⚡ 主持人追问置信度校准，以及 Jev 可能采用的其他架构；Nikunj 没有声称首版解决了校准问题，也未证实关于 Jev 架构的猜测。标题里的“一周”对应其口述的原型工作起点，不等于一个经过长期验证的竞品已全面上线。

7) 应用场景、缓存、压缩与平台抽象 — 30:28 🎧

💬 Nikunj 说，内部考虑用 Decisions API 分类支持工单，也讨论将低延迟判断用于评测中的“语言模型裁判”；Agents API 则正被第一方产品采用。对于较成熟的 Responses API，团队重点改进延迟和缓存：他描述一种尚未公开的较长时间缓存能力，让持续运行的个人智能体即使隔 3 至 4 小时再回到同一线程，仍有机会利用缓存性能；另提到可预热缓存，为接下来约 30 分钟的请求做准备。面对主持人提出的约 100 万 token 上下文限制，他说明 API 提供上下文压缩方式，Agents API 的运行框架也内建相关机制。最后，他把问题提升到平台设计：应向开发者提供多少现成的智能体框架、记忆或存储抽象，又该保留多少灵活性？

💡 智能体若持续工作，成本不只来自单次推理，还来自重复读取历史上下文、等待首 token、压缩长线程和恢复任务。缓存及压缩策略会影响产品的实际响应速度与价格；平台抽象的取舍，则决定开发者是在调用现成能力，还是自行维护复杂运行框架。

⚡ 较长时间缓存被明确说成当时尚未公开，不能当作所有开发者已可使用的功能。预热、缓存命中和压缩收益也依赖具体应用设计；“平台应该封装到哪一层”，Nikunj 本人仍将其视为开放问题。

人物与机构

• Ari：节目介绍为 OpenAI 电脑操作智能体产品与工程团队负责人；分享了从自动化工具到电脑操作智能体的工作脉络。
• Nikunj：OpenAI API 产品负责人；讨论模型能力如何进入 API，以及延迟、缓存和平台抽象。
• OpenAI：本期 Dev Day 发布与 API 讨论的主体。
• Dwarkesh：主持人借其关于电脑操作进展的说法提出挑战；本期没有播放或完整引用其原论述。
• Jev：节目中被称为启发 Decisions API 方向的产品及团队；转写对其名称的呈现不完全一致。
• Latent Space / Aftercasting：本期访谈的节目与本文的深度笔记语境。

金句

“以前它们能可靠地开始任务，然后就会遇到问题；现在它们很擅长调试、重试，审视哪里出了错。”——Ari（意译）

“我们在自己的电脑操作运行框架上训练模型。”——Ari（意译）

“我们没有为此训练一个新模型；它建立在同一套 Luna 权重之上。”——Nikunj（意译）

“应该把多少东西内建进 API，是我一直在想的问题。”——Nikunj（意译）

洞见与延伸背景

• 观察界面也是系统设计：普通截图只呈现像素；无障碍树、DOM 或应用元数据还可能呈现控件与文字的结构。节目中的 AppShots 例子说明，改进输入表示有时比单纯增加点击速度更有效。
• 智能体性能需要端到端衡量：模型推理快，不代表整个任务快。工具启动、页面响应、等待事件和重复传送上下文，都会影响用户感知到的总耗时。
• “使用同款框架”有潜在分布优势：若模型训练时见过特定工具格式与调用方式，开发者采用相近框架可能更易获得稳定表现；但这仍应在自己的任务上测试，而不能替代评测。
• 快速产品化不等于新模型突破：Decisions API 的首版思路提示，结构化输出、并行处理和服务优化也能创造新产品形态。其价值最终仍取决于真实场景里的速度、质量和成本平衡。

争议与需核实

• Dwarkesh 究竟说了什么：本期只有主持人的概述和 Ari 的回应。评价双方分歧，应回看原始论述及其所指的时间段、任务类型和指标。
• 电脑操作的“7 倍”提升：需核对发布会使用的基准、对照版本和计时口径；不宜外推至所有网站或应用。
• Decisions API 的发布时间与效果：录制时 Nikunj 表示仍在优化延迟，并期待未来几天推出；是否按期开放、实际表现如何，需以后续官方资料和独立测试为准。
• 名称与转写缺口：英文转写在若干处有句子中断，并交替出现 Jev、Jeff 等写法。本文沿用标题的“Jev”，不据缺失内容补写技术细节。
• 高风险任务的安全性：主持人的付款、DNS 等例子是个人使用经验；不能证明智能体已适合在缺少审批、日志和限权措施时自主执行此类操作。

行动建议

1. 选一个真实的界面任务做端到端测试：记录完成率、人工接管次数和总耗时，而不只看模型响应速度。
2. 同时检查视觉与结构化信息：对支持 AppShots 或类似机制的应用，比较智能体仅看截图与获得界面结构时的差异。
3. 把高风险动作设为确认点：支付、修改账户或基础设施配置前，要求明确授权，并保留操作记录。
4. 为智能体加入自测环节：让它运行并检查自己生成的软件，再由人进行最终验收。
5. 评估新 API 时分开测量指标：对决策类任务分别考察延迟、分类准确率和置信度校准；对长程智能体另外衡量缓存命中与压缩后的任务连续性。

来源

• Latent Space 节目页面：Why Dwarkesh is Wrong about Computer Use + How OpenAI shipped its Jev competitor in 1 Week
• 本期音频
• 英文转写：latent.space_vtt；本文时间戳依据所提供转写标记整理。