行业动态Latent Space
为什么Dwarkesh对Computer Use的看法是错的 + OpenAI如何在1周内推出其Jev竞品访谈含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 转成正式可用,以及届时是否公布延迟与定价数字。



