行业动态Latent Space
来源时间 本站刊期
为什么Dwarkesh对Computer Use的看法是错的 + OpenAI如何在1周内推出其Jev竞品
Why Dwarkesh is Wrong about Computer Use + How OpenAI shipped its Jev competitor in 1 Week
访谈含OpenAI团队一线复盘，做Agent的同事看交付节奏即可，结论未必通用
判断
做 Agent 路由与编排的团队这周要拍板：把「下一步动作」的判定留在自家 harness，还是交给仍在 limited preview 的 Decisions API。省下的是缓存预暖与服务端压缩那套自建活，押上的是路由逻辑从此跟着 GPT-6 Luna 的版本走。
依据
OpenAI API 团队的 Nikunj Handa 在 Latent Space 这期复盘里说，Decisions API 的冲刺「异常快」：开发者先定义问题和若干候选答案，由模型给内容分类、路由请求，或挑出 Agent 的下一步动作；眼下它就是一层 GPT-6 Luna 套壳（wrapper，把模型包成固定接口），团队自己承认是照着行业里现成的好模式克隆的。同期的 Ari Weinstein（Sky 创始人，现负责 OpenAI 的 Computer Use）说 CUA 与几个月前「180 度不同」，靠的是把截图、无障碍树、DOM、Playwright 和生成的 JavaScript 叠在一起，并让 Agent 学会自己调试、从失败里恢复。对照数字：DevDay 前后 Decisions API 公告帖 684K Views，Dwarkesh 质疑「computer use 为什么这么慢」的帖子 604K Views，Computer History 公告 107K Views。取舍很清楚：把路由判定挪进 Decisions API，你少养缓存预暖（pre-warming）和服务端上下文压缩（compaction）这套活，代价是把它绑在一个限量预览接口和 Luna 的迭代节奏上；留在自建侧，则要继续自己扛延迟与私有数据的说服成本。
- Decisions API 公告684K Views
- Dwarkesh 提问帖604K Views
- Computer History 公告107K Views
没写清 材料没给 Decisions API 的延迟、定价和失败率，也没有它与自建路由的对照数据，这笔账不能替它算。
下一步 看 OpenAI 是否把 Decisions API 从 limited preview 转成正式可用，以及届时是否公布延迟与定价数字。