跨国深谈← 返回←OpenAI DevDay 双专访：计算机使用 180 度大变样

OpenAI DevDay 双专访：计算机使用 180 度大变样

关联

人物 Ari

公司 OpenAI · Codex

概念 计算机使用 · 智能体 · 智能体 API · harness · 无障碍性 · Decisions API · Responses API · 缓存 · 压缩 · 推理

来源 Latent Space

这一集录制于 OpenAI DevDay 现场，两段连访。前半段的主角是 Ari——OpenAI 计算机使用（computer use，让智能体直接操作电脑界面完成任务）智能体的产品和工程负责人；后半段是 Nick Winch，OpenAI API 团队的产品负责人。这轮发布里最值得记住的一点：Ari 说，计算机使用现在的表现和几个月前相比已经「180 度大变样」，而且它的完成速度在大多数场景下已经超过了普通人 。

计算机使用到底哪里变了

Ari 的职业生涯一直做自动化：Apple 的 Shortcuts、创业公司 Sky，再到现在 OpenAI。他总结驱动他的主线很简单：帮人省掉运营性事务的时间，去做更重要的事 。

回头看，他看到的最大变化是模型行为模式的转变：「以前它们可以比较可靠地开始任务，但之后就会遇到问题。而现在它们非常擅长调试——很擅长重试、内省哪里没有在正常工作」。

另一条关键路线是引入更多模态。过去计算机使用产品的典型循环是：截图 → 尝试操作 → 「我得往下滚到下一页」→ 再截图 → 再操作，大量时间耗在翻页上。现在模型可以按任务选择机制：截图、可访问性接口（accessibility，为视障用户提供的界面结构化描述），或者 playwright（一个能直接操作浏览器的自动化工具），不再只靠截图硬滚 。

一个容易被低估的功能是 AppShot：在 Codex 里连按两下 command，把当前应用的内容抓进对话。它看起来像截图，实际不是——截图不包含链接指向哪里、日历里被截断的标题；AppShot 给模型的是完整上下文，包括原始文本和无障碍表示。

Ari 透露有个极客玩法：点开附件右上角的小按钮，就能看到原始的无障碍表示。团队为此投入了大量精力让它既完整又 token 高效，「这里面有点像一门艺术」。有趣的是，这项为有障碍需求的人类发明的技术，成了喂给模型的最佳表示 。

让智能体自己测自己写的软件

Ari 最喜欢、实际中也很常见的用例：让智能体测试它自己构建的软件。传统流程里，Codex 帮你写完代码后，你就成了智能体的 QA；有了计算机使用，智能体可以构建、然后自己操作界面测试，补全整个软件开发生命周期，「等它到我手上的时候，它已经能正常工作了」。

Ari 还自嘲有额外的乐趣：他在开发 computer use 本身，所以现在有「一个 computer use 智能体在用我的 computer use 智能体，而那个又在用别的东西」。主持人的实践是用计算机使用逐屏克隆一个体验很差的 SaaS——截屏、记录、让 Codex 复刻。

瓶颈在哪：等页面加载

关于下一步，Ari 判断下一个前沿是「lowercase」（小写水平的延迟），一旦达到，就能做出真正实时的产品，并大幅降低使用计算机使用的激活能量 。现在的小瓶颈分布在模型、推理、harness（模型外围的执行框架）和表示各层。

一个非常具体的瓶颈：「随着计算机使用变得更快，我们越来越多地被单纯执行一个操作的速度所瓶颈化」——比如写一个 wait 然后执行这个 wait。理想状态是事件驱动（页面加载完成这类信号直接触发下一步），浏览器导航有加载事件，但很多场景做不到，比如和客服聊天：回复可能 30 秒，也可能三分钟 。

给开发者的建议

计算机使用这次进入了智能体 API，开发者可以用 Codex 和 ChatGPT 同款实现来构建。Ari 的核心建议：自己造 harness 有很棒的工作可做但很难，而且「我们是在自己的计算机使用框架上训练我们的模型，所以使用模型分布内的那一套是有优势的」——可能带来速度、成本和准确率上的好处 。信任层面，他的原则是：构建可靠的东西、加上正确的安全检查、在做有重大后果的操作（比如付款）前征得用户同意、按应用场景限制可访问的网站 。

后半场：API 侧的新东西

Nick Winch 领导 API 团队产品，加入 OpenAI 约三年，一直负责模型发布。GPT-6 带来的核心新能力是异步工具调用：「工具调用耗时太长，以至于你不必在工具运行时暂停模型的执行」——可以发起调用、继续推理，再回来查看。配套的 WebSockets（长连接双向通信）则在 Codex Spark 时首次推出，专门用来降低工具来回交互的开销 。

UltraFast（首次进入 API 的极速模式）背后是推理团队的转变：前几个月他们聚焦效率和降本——「这就是我们能把 Luna 的价格砍掉 80% 的原因」，现在换挡到把速度做到极致 。

Decisions API（超快的分类/决策模型 API）的来历颇具 OpenAI 风格：Jev 发布后，一个推理团队的人和一个基础设施团队的人觉得「这太棒了，我们要拿它来捣鼓一下」，做出能用的原型，现在在做延迟爬山优化。Nick 明确说了实现方式：「我们没有为此训练新模型，完全是构建在已有的同一套 Luna 权重之上」——用结构化输出做约束、极致优化推理栈的 TTFT（首 token 延迟）、多问题并行批量运行，第一版就是零样本。相比无视觉能力的竞品，Luna 的视觉能力是免费送的 。

用例上，内部最明显的是用户运营团队给支持工单分类；Nick 最期待的原型是把 Decisions API 接到 GPT Live（双向实时语音 API，采用「思考者-说话者」架构，快的前端模型负责说话、Astra 坐镇后端）上——过去 GPT Live 的工具调用一直感觉慢，接上 Decisions API 后控制电脑「感觉起来快得多、自然得多」。

性能：缓存与压缩

Responses API（主力 API）的两大方向是延迟和缓存。缓存针对个人智能体这类单线程长跑场景：多付一点缓存费，保证更长时段的缓存读取——「你三四个小时后再回来，仍然能拿到缓存性能」；还有预热功能，提前支付缓存写入费，之后 30 分钟内随时可用，还能派生大量线程实例 。

上下文总会撞天花板，压缩（compaction，把长对话历史浓缩以省 token）的最佳实践：智能体 API 里内置于 harness；Responses API 有服务端压缩——设一个 token 阈值，到了自动压缩；而很多大型编码智能体喜欢手动做，开源 Codex harness 用的就是 slash compact 命令。团队还在试验基于文件的新压缩技术，部分已实现在 Codex harness 里 。

最后是 Nick 留给行业的问题。他此前在 Stripe 做产品，Stripe 的玩法是在核心支付原语上构建更高层的产品；AI 里的对应问题是他反复思考的开放题：早期的 Assistants API 是一次不合适的尝试，现在的智能体 API 给了你 Codex harness，但「应该在其中给予多少灵活性才是合适的？

这是个开放性问题」。主持人的收尾类比：OpenAI 在做 AI 原生版的 AWS 发明——这是 EC2、这是 S3，每一个都是 AI 原生版本。

本集带走

• 写完代码让智能体自己测：用计算机使用让智能体操作界面测试它刚构建的软件，把 QA 环节也自动化，等你验收时它已经能跑。
• 优先用官方 harness 而不是自造：模型就是在官方计算机使用框架上训练的，用分布内实现可能同时拿到速度、成本、准确率的好处。
• 给模型「看结构」而非只给截图：AppShot 式的无障碍表示包含链接指向、被截断文本等截图丢失的完整上下文，模型能做的事多得多。
• 长跑智能体的两个工程要点：用长时效缓存（甚至预热线程、多实例派生）保证几小时后回来仍有缓存性能；上下文接近阈值时用服务端自动压缩或手动 compact 控制长度。
• Decisions API 的定位：超快分类/判断，不训练新模型，靠结构化输出约束 + 推理栈优化 + 并行批跑实现；适合工单分类、评测裁判、给实时语音模型补快速工具调用。

我们是在自己的计算机使用框架上训练我们的模型，所以使用模型分布内的那一套是有优势的。
we train our models on our computer use harness, so there is an advantage to using the one that’s in distribution for the model.
—— Ari · [16:31]

我也觉得有一半的时候对面也是个机器人，所以现在就是机器人在互相交谈了。
I also feel like half the time it’s a bot on the other end, so now you’ve got the bots talking to each other.
—— Ari · [15:15]

这些都没法通过 API 实现，因为他们讨厌开发者。
None of this is available by API because they hate developers.
—— 嘉宾 · [04:50]