有人公开说「Computer Use 这两年没什么进步」。结果 OpenAI 的负责人看到后，差不多是这个反应：
> 那是几个月前说的吧？我希望他们现在看法不一样了，因为 Computer Use 跟以前相比，是彻底的 180 度不同。
Latent Space 在 DevDay 之后第一时间拉来了两位 OpenAI 的人——负责 Computer Use 产品与工程的 Ari Weinstein（Sky 创始人，公司被 OpenAI 收购），和负责 API 产品的 Nikunj Handa（前 Stripe）。这期信息量很密，挑几个最值得记的讲。
一、Computer Use 到底哪里不一样了Ari 的「主线」很清晰：他一直在意的，是帮人省时间，而不是「让 agent 像人一样精细地操作电脑」。
但真正让 Computer Use 质变的，是几个具体的技术变化：
第一，模型现在很会 debug 了。 以前（他做 Sky 的时候）agent 能「可靠地开始任务」，但一遇到问题就卡住。现在的 agent 会重试、会自省「刚才哪里出了问题」。
第二，agent 开始写 JavaScript 了。 它会生成一段代码交给电脑执行，一次性做多个动作。你在 Codex 里手动展开 tool call 就能看到。
第三，那个经典的「截图—滚动—截图」死循环被解决了。 过去 agent 要反复截图、滚动、再截图，慢得离谱。现在有了无障碍树（accessibility tree）、直接读 DOM、代码生成，模型能「一眼看到整页、整个应用」，然后写代码一次执行多步。
Ari 有句话挺妙：
> 世界上所有的软件都是为人类设计的，而现在 agent 能用同一批软件。
他还举了自己的例子：用 Computer Use 在一个订餐服务上点餐，手动要 2 小时，agent 15 分钟搞定，快 8 倍，跑在 GPT-6.1 Sol 上。
至于「超人类」的目标，他的判断是：Computer Use 现在在大多数情况下已经比普通人快，下一个前沿是「像专家用户一样快甚至更快」。瓶颈在哪？他说很多其实是操作本身——比如等 doordash.com 加载完，这跟 agent 无关。
二、App Shots：比截图更好的「上下文」DevDay 上发了个功能叫 App Shots：双击 Command，就能把任意 app 的内容抓进 Codex/ChatGPT。附件里有个隐藏按钮，能展开看到原始文本和无障碍表示。
为什么它比截图好？Ari 举了两个例子：截一张链接的图，你看不到链接指向哪；截一张日历的图，事件标题是被截断的。App Shots 拿到的是完整、而且更省 token 的原始表示。
他有一句话值得单独抄下来：
> 那项本来是为有无障碍需求的人发明的技术……对 LLM 用电脑同样极其有用。
三、最实用的转变：你不再是 agent 的 QAAri 说这是他最喜欢的用例之一：
> 传统上，你在 Codex 里造东西，Codex 帮你写出来，然后你得自己测试，你就成了 agent 的 QA。有了 Computer Use，你可以走完整个软件开发生命周期。
目标是「东西到我手里的时候，它已经能跑了」。
swyx 补了一个很实用的玩法：做一个「视觉 play test skill」，专门抓那些在代码里看不见的设计问题；或者让 Computer Use 一个屏幕一个屏幕地克隆某个 SaaS——agent 驱动、截图、记笔记，然后 Codex 来复刻。
四、重头戏：一周复刻 Jev，而且没训新模型这是这期最有意思的一段。Nikunj 先给足了面子：
> 非常致敬 Diogo 和 Jev 团队，真的启发了市场上整个赛道。
然后他讲了一个很「OpenAI」的故事：Jev 出来后，用户和内部团队（需要做快速分类的）都跑来找他们。这东西四周前根本不在 roadmap 上。 结果一个做 inference 的人、一个做 infra 的人跳出来说「这太酷了，我们来 hack 一个」。做了原型，能跑，然后就一直抠延迟。
swyx 的评价是：「你们应该是你们实验室里第一个复刻并采纳它的。」 Nikunj 确认：
> 这整件事，大概是一周前才开始的。
那 Decisions API 到底是什么？Nikunj 说得很直白：
> 我们没有为这个训新模型。我们纯粹是搭在同一套 Luna 权重上的。
「这东西真的就是 Luna」——第一版是零样本（zero-shot）搭在 Luna 上。关键工作在于：约束结构化输出、优化 inference 栈把 TTFD（首个 token 的决策时间）压到极致、以及把多个问题并行/批量跑。
还有几个细节：
Luna 自带视觉能力（Jev 没有视觉）。它是没有 reasoning 的小模型，走并行推理。用的还是 OpenAI 那套「迭代式部署」：先放出去、看反馈、再按需改模型。swyx 总结得挺狠：「API 本身谁都能做，其实很平凡。难的是速度、准确率，还有那些校准（calibration）特性。」
五、被低估的基础设施：缓存和压缩Nikunj 这段讲的是给「长期运行的 personal agent」打的地基，做 agent 产品的人应该重点看。
缓存： 他们现在提供 30 分钟缓存命中保证，而且刚给一个客户上了长达 12 小时的缓存保证（预览中，还没公开）。逻辑是「多付一点缓存写入的钱，换取更长的缓存读取保证」——你 3、4 小时后再回到同一个线程，依然享受缓存性能。新模型的缓存读取还便宜了 25%。建议是：把应用做成「非常缓存感知」的，并用 prompt/cache diagnostics 工具去查缓存在哪里断掉。现在还支持缓存预热（pre-warming）。
压缩（compaction）： OpenAI 有自己专有的压缩方案。在 Agents API 里它内建在 harness 中；在 Responses API 里有两种方式：服务端自动压缩，或者手动 `/compact`。有意思的是「很多大型编码 agent 喜欢手动做」——开源 Codex harness 用的就是 `/compact`。Codex harness 里还在试验一些基于文件系统的压缩技巧。
六、最后：OpenAI 在造一个「AI 云」Nikunj 是从 Stripe 出来的，swyx 一直爱拿 Stripe 类比。Nikunj 的反思是：在 Stripe，重点是在核心支付原语之上，构建更高层的原语。OpenAI 也试过（很早的 Assistants API），但「不太对」。
现在的问题是：Agents API 到底该给多少灵活性？记忆的「墙」怎么设计？哪些高层对象该把存储概念抽象掉？他的原话很诚实：
> 很多 AI 里的东西，都是给一个低层 API 原语、给一个示例 harness，然后让你的 coding agent 自己去实现。但这里面有多少该我们直接做进 API，是个持续存在的问题。
swyx 的收尾类比是：你在造一朵 AI 云，你在做 AWS 当年发明 EC2、S3 的事——只不过是 AI 原生版本。
对你意味着什么一，如果你在做 Computer Use 类产品，别再自己从零搭 harness 了。 Ari 明说了：模型是在 OpenAI 自己的 Computer Use harness 上训练的，「用分布内那套」在速度、成本、准确率上都有优势。自己搭 harness「很难」。
二，Jev 这类「快分类」能力正在被平权。 一周、不改模型、纯靠 inference 工程就能复刻——这意味着单靠「我有个快速分类模型」很难建立护城河，真正的壁垒在速度和校准。
三，缓存和压缩是长期 agent 的命门。 12 小时缓存保证、缓存预热、`/compact`——这些不起眼的基础设施，决定了你的 personal agent 能不能「一直在线」。
四，产品边界在移动。 当「测试」也交给 Computer Use，工程师的角色就从「写 + 测」变成「定义结果 + 判断结果」。这跟 DHH 那句「手写代码已是异常状态」，说的是同一件事。

来源：latent.space/p/devday-2026