OpenAI 高管亲述：我们是怎么在一周内做出 Jev 竞品的
计算机操作（Computer use）的结果明明很容易验证，为什么这一技术的进展如此缓慢？AI 什么时候才能真的学会操作电脑？
今年 6 月，知名播客主持人 Dwarkesh Patel 提出的这个质疑，在行业内引发了不少争议。
三个月后，OpenAI 在 9 月 29 日的开发者日展示了 Dot、计算机操作和一系列新的开发者接口。每个 Dot 都可以使用一台独立的云端 Linux 电脑，既能打开浏览器，也能运行桌面应用；用户可以把原本需要自己在网页或软件里逐步完成的任务交给它处理。产品演示之后，这个问题反而更值得进一步细问：计算机操作现在究竟能做到哪一步，支撑智能体完成任务的能力又发生了什么变化？
开发者日结束后，Latent Space 的《The AI Engineer Podcast》与 OpenAI 的 CUA 团队和 API 平台负责人进行了深入探讨。播客首先采访了 Sky 联合创始人、现 OpenAI 计算机操作产品与工程负责人 Ari Weinstein。Ari 认为，过去一年最关键的进步，是智能体遇到障碍后更会排错和重试。它也不再只能看着截图逐步点击：页面结构、无障碍信息和自己编写的代码，都可以成为它操作软件的方式。但当智能体能够访问网站、处理付款，人该在哪些环节把关，仍是产品必须回答的问题。
OpenAI API 产品负责人 Nikunj Handa 在访谈中分享了为智能体开发在 API 层做的各种实践：从让模型在工具执行时继续推理，到快速决策、性能优化和上下文管理。当谈论到 Decisions API 时 ，Nikunj Handa 承认，这是受到了 Jev 启发而启动的，起初并不在研发计划之中。项目启动约一周，团队就已完成可运行的原型。他们没有重新训练模型，而是沿用 Luna 的权重，把输出约束成结构化结果，并专门优化推理系统，让首次决策返回时间尽可能短，多个问题还能并行批量处理；它更像一个极快的分类和决策层，能用于客服工单分类、评估打分和计算机操作，也能和 GPT Live 配合，让智能体在需要快速判断时更灵敏。
从“AI 为什么还不擅长操作电脑”的质疑出发，两场访谈逐渐把镜头拉近：智能体怎样发现自己做错了，怎样决定下一步，又怎样在漫长而琐碎的实际任务中持续工作。开发者日的演示给出的是结果，此次访谈则从产品和平台的不同视角出发，分享了他们在计算机操作方面的实践。
主持人 Vibhu： Dot 为每个智能体提供独立的云端电脑。用户应该如何探索它的能力？
Ari Weinstein： Dot 可以在云端 Linux 电脑上使用浏览器和桌面应用。一个实用的起点是梳理自己日常耗时的电脑任务，尝试将其中适合的任务委托给智能体。
主持人 Swyx： 有观点认为，计算机操作在过去两年几乎没有进步。实际情况如何？
Ari Weinstein： 过去，智能体通常能够启动任务，却容易在遇到问题后停滞。如今，它更善于排查错误、调整方法并重新尝试。这是近一年最显著的变化之一。
Ari Weinstein： 两者都在发挥作用。智能体现在可以结合截图、无障碍信息、页面结构和 Playwright 操作软件，也可以编写代码，一次执行多个步骤；模型本身的能力和速度同样在提高。
Ari Weinstein： 瓶颈分布在模型、推理、运行框架和信息呈现等多个环节。随着智能体执行速度提高，等待网站加载等操作本身的耗时，也变得越来越明显。
主持人 Swyx： 开发者通过 Agents API 使用计算机操作能力时，需要注意什么？
Ari Weinstein： 应根据任务限制智能体可访问的网站和应用，并在付款等可能产生重要后果的操作前征求用户同意。可靠性和恰当的安全检查，是建立用户信任的基础。
Ari Weinstein： 智能体可以实际打开并测试自己开发的软件。这样，编写代码与验证结果能够形成闭环，减少开发完成后完全由人接手测试的情况。
Nikunj Handa： 异步函数调用允许模型在工具运行期间继续执行，之后再获取结果；中途引导则允许开发者在模型运行过程中加入消息。这些能力有助于处理工具调用频繁、执行时间较长的任务。
主持人 Swyx： OpenAI 是如何开始开发 Decisions API 的？
Nikunj Handa： Jev 的推出引起了用户和内部团队的关注，此前 Decisions API 并不在开发计划中。团队先验证原型是否可行，再着手优化决策返回的速度。
Nikunj Handa： 目前明确的用途是快速分类，例如处理客服工单。它也可能用于某些需要迅速选择下一步动作的任务，但快速决策与完成复杂、长周期任务所需的能力不同。
主持人 Swyx： 如果同样使用 Luna，Decisions API 与普通的结构化输出有何区别？
Nikunj Handa： 首个版本没有重新训练模型，而是基于现有的 Luna 权重，对输出施加约束、并行处理多个问题，并专门优化首次决策返回的时间。
Nikunj Handa： 开发者可以设置阈值，让 Responses API 自动压缩上下文；也可以调用 /compact ，自行控制压缩时机。
主持人 Vibhu： 今天是 OpenAI DevDay，我们在现场录这期特别访谈。
主持人 Vibhu： 今天请到的是 Ari，他负责计算机操作（Computer Use）智能体的产品和工程团队。在深入聊这项技术之前，能不能先回顾一下今天发布了哪些东西？
Ari Weinstein： 我们刚从主题演讲现场出来，今天有几项计算机操作方面的发布值得关注。
首先是 Dot，这是一个新的个人助理产品，里面有一些很令人期待的计算机操作功能。
还有 GPT-6.1 Sol，这是一个非常出色的新模型，我认为它尤其适合计算机操作，因为它在成本和速度上都有优势。我们好像公布过它的成本是 Astra 的五分之一；如果专门看计算机操作，成本只有七分之一，真的很了不起。
Agents API 现在也加入了计算机操作能力，开发者可以使用与 Codex、ChatGPT 中相同的实现来构建产品。现场还演示了现有功能，比如应用快照（app shots），可以把你正在电脑上处理的内容迅速带入 Codex 和 ChatGPT。
还有 Mac 上的原生计算机操作：Roman 让它自动给自己的应用截图，而它操作应用时，他仍然可以在电脑上做其他事情。所以，这场主题演讲确实很精彩。
主持人 Swyx： 更不用说还有 Decisions API。我先直接问一下：这些背后都是同一个模型，还是用同一套数据集蒸馏出来的不同模型？具体来说，计算机操作用的是 Decisions API，还是两者相对独立？
Ari Weinstein： Decisions API 很有意思，它有几项新能力：可以并行推断，不进行思考推理，用的模型也比我们用于计算机操作的模型更小。这让它速度很快，但处理执行周期较长、比较复杂的任务时，能力也稍弱一些。怎样把这些方法结合起来，仍然是一个有待研究的问题。我很期待看到大家用 Decisions API 做出什么。
主持人 Vibhu： 所以它们似乎能更持久地保留工作环境了。你已经用了一段时间，大家应该怎样探索它的能力边界？应该朝什么方向尝试？我自己现在经常让它处理客服问题。 比如，“这个东西出错了，我不想登录，也不想做身份验证”，你去找到相关信息，把问题解决就行。再往前一步，大家还应该尝试什么？
Ari Weinstein： Dot 是一个很有意思的产品，因为每个 Dot 都可以使用自己在云端的一台 Linux 虚拟电脑，这与我们的其他产品不同。过去，我们提供的通常是云端浏览器，或者让智能体访问你自己的电脑；现在，你有的是云端一整台属于自己的 Linux 电脑。它既能运行完整的桌面应用，也能使用浏览器。我认为计算机操作如此强大、如此令人期待，就是因为它让智能体能够做任何一个人可以做的事。世界上所有软件原本都是为人设计的，如今智能体也能使用这些软件，你就可以把工作委托给它。所以，凡是你会在电脑上做的事情，都可以让 Dot 去做。具体哪些最有用，确实取决于最终用户是谁，以及什么事情对他的生活有价值。
我会建议，先想想你平时把时间花在哪些事情上，再想想能不能把这些事情交给智能体。凡是你会在电脑上做的事情，都可以让 Dot 去做。具体哪些最有用，取决于最终用户是谁，以及什么事情对他的生活有价值。我建议先想想，自己平时把时间花在哪些事情上，再看看能不能把这些事情交给智能体。
主持人 Swyx： 对，比如订机票、购物，说实话，甚至玩个游戏之类的事情也可以，对吧？
Ari Weinstein： 完全可以。我最近为了吃得健康一些，订了一项配餐服务。我很喜欢这家服务，因为它允许我非常细致地定制每一餐，比如“我要多少克鸡肉、多少克米饭”。但操作实在太复杂，我下一次订单就花了两个小时。后来发现，可以让计算机操作帮我下单，它十五分钟就完成了。用 GPT-6.1 Sol，它完成这件事的速度是我的八倍，同时替我省下了两个小时。我觉得这类任务特别能体现它的价值。
主持人 Swyx： 作为创作者，我马上就能说出自己的首要用途：把 YouTube 上的操作自动化。YouTube 很多功能都不开放 API，你只能把它放进虚拟机里，让智能体自己跑。比如 A/B 测试，或者发社区帖子，这些都没有 API，因为他们讨厌开发者。
Ari Weinstein： 我也听开发者体验团队的人这么说过。他们经常用它处理 YouTube 上的事情，确实非常好用。
主持人 Swyx： 我想稍微问得尖锐一点。我们有朋友做一档很有影响力的 AI 播客，他们有一个出名的观点： 计算机操作在过去两年里毫无进步 。这个说法很有意思，而你应该是全世界最有资格谈这个话题的人之一。究竟发生了哪些进展？
Ari Weinstein： 我记得他们是几个月前这么说的，希望他们现在已经改变看法，因为计算机操作与以前相比，已经有了一百八十度的变化。
主持人 Swyx： 你几乎整个职业生涯都在做某种形式的计算机自动化，从在 Apple 做快捷指令（Shortcuts），到 Sky，再到加入 OpenAI。能不能讲讲贯穿这段经历的主线？是什么在驱动你？以前有哪些事情做不到，又有哪些里程碑？
主持人 Vibhu： 我再补充一个问题：从上周的 Codex 计算机操作到今天，最主要的变化是什么？是模型，是 Dots，还是智能体运行框架（harness）？除了整段历史，也想请你讲清楚，今天的发布究竟改变了什么。
Ari Weinstein： 我一直对自动化、对帮助人们把任务自动化很有热情，因为这样能节省生活中的时间，把精力放在对自己更重要的事情上，而不必细致地操作电脑。这也是我们做那些产品的原因。我之前在 Apple 工作，后来创办了 Sky，最终加入 OpenAI，这段经历让我很兴奋。
主持人 Swyx： 感觉就像你一直在想办法绕过 Apple 的限制，直到 Apple 说：“好吧，我们干脆把你招进来，让你从内部做这些事。”是这样吧？
Ari Weinstein： 能在那里工作，确实是一段很棒的经历。回头看 Sky，很有意思的是，我们当时也在做计算机操作，但那时模型的能力弱得多。仅仅过去一年，模型的计算机操作能力就已经变得非常强。我看到最大的变化是，以前它们可以比较可靠地开始一项任务，但做着做着就会遇到问题；现在， 它们非常擅长排查错误、重新尝试，审视哪些方法有效、哪些无效。
计算机操作这个领域本身也在发展，我们采用了更多技术。现在的计算机操作经常会写代码。如果你在 Codex 里手动展开工具调用，就会看到，它并不只是一次执行一个动作，而是在编写 JavaScript 代码，交给电脑执行，有时一次就能完成很多动作，速度和能力都有了提升。我们更多地采用无障碍接口等多模态交互方式，模型可能使用截图，也可能使用无障碍接口，或者 Playwright。它可以根据手头的任务，选择许多不同的机制。模型自身的加速也非常惊人。
至于今天有什么不同，我觉得我们一直在改进计算机操作，因此单独看一天的变化，可能还不如看过去一个月或两个月那么有意义。不过，Dot 中的计算机操作，以及今天发布的新模型，我都认为非常值得期待。
主持人 Vibhu： 主题演讲里，Tejal 提到计算机操作的速度提升了七倍，在几个基准测试上也好了很多。你们是怎么衡量的？就像你说的，计算机操作是在不断进步的。这些进步来自智能体运行框架、模型，还是后训练？新模型又带来了哪些变化？
Ari Weinstein： 我们实际上有很多种衡量方式，其中一些会测试智能体运行框架的不同组合和配置。这里的情况有点复杂，因为正式上线的产品会有更多安全检查，而且会根据当前任务的需要采用不同配置。所以，衡量的方法有很多，但无论采用哪种方式，我们看到的提升都相当一致。这些提升有时来自运行框架，有时来自模型。有一个结果让我印象很深：与 Astra 相比，GPT-6.1 在计算机操作上的成本效益提升，甚至超过它本身基础成本的降幅。看到这一点真的很棒。
主持人 Swyx： 直播中有张图我特别喜欢，展示了你们不断改善这条曲线的帕累托前沿。你们也谈了不少如何配合运行框架一起改进。能不能举几个让你们恍然大悟的例子？无论是模型推动框架改进，还是框架推动模型改进，都可以。
Ari Weinstein： 引入更多模态确实很有效。具体来说，过去很多计算机操作产品必须花大量时间滚动页面：先截一张图，试着操作一下，再发现“得往下滚，看看下一页结果”，于是再截图、再尝试操作，然后又往下滚。如今借助无障碍接口、直接访问文档对象模型（DOM）等方式，语言模型可以看到整个页面，或者整个应用，还可以写出一次完成多个步骤的代码。这些大概是最明显的突破。此外还有很多小发现，没那么引人注目，但我们确实发现，不少速度提升来自一个个细小问题，需要深入检查、逐一解决。
主持人 Swyx： 背后是大量艰苦的工程工作。比如应用快照，很多人还不太理解它的区别。截取应用快照时，Codex 会显示一个很好看的画面，但他们未必知道，你实际上可以操作其中每个按钮，每一处文字也都已经以很合适的形式呈现给模型了。
Ari Weinstein： 没错。其实挺有意思。如果你想深入研究，可以打开 Codex，按下两个 Command 键截取应用快照。这样就能把你正在使用的应用内容带入 Codex 或 ChatGPT 的聊天里。然后点击附件，再点右上角那个很小的按钮，就能看到原始文本和原始的无障碍结构表示。我们为这件事投入了很多工作。
Ari Weinstein： 不仅要导出来，还要高效、节省词元（token），这里面有不少技巧。原本为有无障碍需求、需要使用屏幕阅读器的人发明的技术，既能帮助他们使用电脑，也非常有助于大语言模型使用电脑。能参与这样的工作，很有意思。
主持人 Vibhu： 补充一点背景：很多人不了解应用快照，甚至不知道有这个功能。按两下 Command，会引入一个看起来像截图的东西。你可能会想：“为什么只是打开一张截图，把它丢进来？”其实它会把所有元数据、所有代码以及其他内容一起带进来。
Ari Weinstein： 没错。比如你给一个包含链接的网页截屏，截图里不会包含链接的目标地址。或者你给日历截屏，日程标题可能被截断了。但应用快照会把完整的上下文交给语言模型，让它能够做更多事情。
主持人 Vibhu： 关于计算机操作智能体，我想问一个更宏观的问题。你刚才说的截图、滚动页面、再截图，是过去的状态。今天它们已经可以自动完成很多事情了，瓶颈在哪里？是模型还是运行框架？你觉得两年后会发展成什么样？它能连续运行几个小时吗？我们怎样才能走到那一步？你对计算机操作的未来有什么预测？
Ari Weinstein： 我觉得团队过去几个月做到的一件很不可思议的事情是，现在计算机操作在大多数情况下，完成任务的速度可能已经超过普通人了。接下来要突破的，是让它的表现真正超越人类：使用软件的速度达到，甚至超过像我们这样熟练的电脑用户。那会带来很大的影响，因为我们能做出体验更加实时的产品。同时，使用计算机操作的门槛，或者说开始使用它所需要克服的阻力，也会降低。对于某些我们习惯亲手做的事情，大家会开始默认交给智能体，从而节省大量时间。
要实现这一点，还有许多小问题和瓶颈需要解决。有些在模型端，有些在推理端，有些在智能体运行框架里，还有些涉及信息的表示方式。随着计算机操作越来越快，我们越来越容易受到操作本身速度的限制。比如在计算机操作任务的基准测试中，有一部分不可忽视的耗时，是在等待网站加载。假设你在 doordash.com 上自动完成一项任务，其中很大一部分时间其实是在等 doordash.com 自己加载。
Ari Weinstein： 页面终于加载完成，到触发大语言模型执行下一个动作，这之间的延迟要尽可能短。这非常重要，本身实际上就涉及一套统计方法。
Ari Weinstein： JavaScript，或者说浏览器，针对网页导航有加载事件，但有些其他类型的事件确实没办法用事件驱动处理。所以这里面非常复杂。
主持人 Vibhu： 我想到的一个例子就是跟客服聊天。对方可能三十秒回复，也可能三分钟才回复。
主持人 Swyx： 我已经用 Codex 跟很多 机器人 打过交道了，挺好用。但我有时也会想，对面知不知道自己是在跟机器人聊天？因为我回复的句子太完整了，连大小写都很规范，编号、参考编号之类的信息也都给得完整，明显表现得太好了。不过我不在乎，我只是想解决自己的客服问题。
主持人 Vibhu： 我会在提示里告诉它：“别表现得像机器人，要像一个已经很不耐烦的人。”我还会告诉它：“等回复的时候，调用子智能体，研究一下有没有更好的办法找到我们需要的信息。” 就是稍微加一点人的干预。
Ari Weinstein： 太好了。而且我觉得，多半对面本来也是机器人，现在就成了机器人互相聊天。
主持人 Swyx： 是的。我们现在已经走到了计算机操作的一个里程碑：三四年前，我们还害怕把大语言模型连到互联网、连到自己的设备上，现在我已经让它帮我配置域名系统（DNS）、替我付账单了。真的是几万美元的事情，我就直接交给计算机操作，放手让它去做，心想最坏能发生什么呢？你们自己也要使用自己的产品。
现在既然已经通过 API 发布了这项能力，有没有什么陷阱或者建议想告诉开发者？因为他们马上就要亲身经历这些事情了。
Ari Weinstein： 首先，我真的很高兴我们把计算机操作带进了 Agents API。很多开发者开发的应用，都希望能够与第三方网站和服务交互，而计算机操作具有这种通用性，什么都能操作。现在，开发者一下子就能使用与我们自己相同的计算机操作实现来构建产品。如果你想自己做计算机操作的智能体运行框架，这方面当然还有很多值得做的工作，但难度很大。而且我们的模型是在自己的计算机操作框架上训练的，所以使用处于模型训练分布内的这套框架，可能在速度、成本和准确性上都有优势。
回应你刚才的话，我认为大家都还在逐渐适应这项技术、建立对它的信任，只不过我们当中有些人可能比世界上很多人走得更快一些。因此，我们有责任通过时间慢慢建立这种信任：确保做出的东西可靠，设置恰当的安全检查，在付款等可能产生重要后果的操作之前征求用户同意；或者根据具体应用的情况，确保它只能访问完成任务真正需要的网站和应用。这些都值得认真考虑。我非常鼓励大家试试新的 Agents API，在上面做出各种有意思的东西，也欢迎大家把使用后的反馈告诉我们。
主持人 Vibhu： 你有没有看到它对开发工作流程带来的变化？比如现在可以在 Slack 里使用 Dots，也有人用语音来构建东西。Roman 演示的例子是让它修改应用，并在过程中不断发来截图。大家实际怎样把计算机操作用在编程流程里？有没有值得借鉴的做法？
Ari Weinstein： 我最喜欢的用途之一，也是我们在实际使用中经常看到的，就是让智能体通过计算机操作，真正测试自己开发出来的软件。这件事的影响比听起来大得多。过去，你让 Codex 做点东西，它做好以后还得由你测试，于是你就成了智能体的质量保证人员。有了计算机操作，软件开发的整个流程就能贯通：智能体既能开发软件，也能测试软件。我很喜欢这样做东西，让智能体自己测试，到交给我时，软件已经能正常工作了。
对我来说还有额外的乐趣，因为有时我开发的就是计算机操作本身，于是就出现了一个计算机操作智能体，操作着我开发的另一个计算机操作智能体，再由后者去操作别的东西。我认为这是一类非常有价值的用途。
主持人 Swyx： 我做了一个视觉交互测试技能，能发现很多只看代码发现不了的设计问题。它也特别适合复刻应用：如果你正在用一个很烂的软件即服务（SaaS）产品，想把它替换掉，就一屏一屏地照着做。计算机操作可以把整个应用都操作一遍，截图、记录，再让 Codex 把一切复刻出来。总之，谢谢你们做出的这些进展，我们的时间到了，不过这肯定不会是最后一次对话。
主持人 Vibhu： Nikunj，很高兴请到你。你们在 API 方面发布了很多东西，刚才和 Ari 也谈到了，现在已经可以用计算机操作智能体来开发了。你想重点介绍哪些 API 变化？也请简单介绍一下自己和负责的工作。
Nikunj Handa： 我叫 Nikunj，负责 API 团队的产品工作，在这里大约三年了，一直参与模型发布。感觉在 OpenAI 的这段时间里，这件事就没停过。每推出一个新模型，我们都会与后训练团队、研究团队紧密合作，弄清楚它有哪些新能力，再通过 API 开放出来。
GPT-6 这次发布的新能力，首先是异步函数调用。Codex、Dots 等产品中的很多工具调用都很耗时，现在工具运行的时候，不必暂停模型的执行。你可以先发起工具调用，让模型继续运行、继续推理，过一会儿再回来查看结果。我们还推出了轮次中途引导，可以在模型推理的过程中注入消息，这样工具调用一结束，就能把相关指令放进去。
主持人 Swyx： 这也有一部分属于模型对齐能力，对吧？这种能力本身也得通过训练获得。
主持人 Vibhu： 我感觉应用里以前就有了：模型推理时，你可以中途引导它。以前效果不算最好，现在已经好多了，很期待看看这个版本的表现。
Nikunj Handa： 是的。我们在 API 方面的主要目标，就是等这些能力已经在智能体运行框架中训练到位，再放进 API，所以会等到它足够好。很多能力由 WebSockets 支撑，我们应该是在几个月前发布的。WebSockets 让应用能够与模型进行双向通信。我这里说的不是 GPT Live，而是 GPT-6。异步工具调用、异步推理、注入消息，这些都能做。开发这个 API 很有意思，我很享受这个过程。
主持人 Swyx： 这就是我们为什么是一档工程播客，因为我们会聊 WebSockets。它和 UltraFast 也很搭，对吧？我记得这也是 UltraFast 第一次通过 API 提供。也就是说，前沿水平的模型可以以理论上最快的速度运行。
Nikunj Handa： 在谈 API 之前，我觉得 UltraFast 最有意思的部分，是看推理团队围绕 Astra 不断拿出成果。他们一直运行着 Codex 智能体，试着再多挤出一点性能。至少有几个月，大量工作都集中在提高效率、降低成本上，我们因此能把 Luna 的价格降低大约 80%。其中很大一部分，就是他们落地的这些推理优化带来的。后来他们换了方向，开始研究怎样让它跑得尽可能快。看到 UltraFast 能把 Astra 这样的模型加速到这个程度，很让人振奋。
我们最初推出 WebSockets，是为了 GPT-5.3 Codex Spark。显然，工具调用必不可少，而 WebSockets 能大幅减少与工具来回通信的开销，所以特别有帮助。
主持人 Swyx： 每次看到用量额度的界面都挺好玩：一边是我的常规额度重置，另一边是那个我从来没用过的 Spark 额度，反正我想用的时候，它就在那儿。
受 Jev 启发？却不止于结构化输出：OpenAI 的 Decisions API 如何追求更快决策
主持人 Swyx： 5.3 Spark 明确说过用了 Cerebras。你们现在既不确认，也不否认 UltraFast 是否与 Cerebras 有关，但大家确实在讨论，也很在意、很好奇这件事。而且你们也有自己的芯片。还有一个绕不开的话题：决策模型，也就是 Decisions API。我们是第一档请 Diogo 来深入聊 Jev 的播客，我也邀请他上过 AI Engineer。你们看到 Jev 后，多快就决定跟进了？
Nikunj Handa： 首先要感谢 Diogo 和 Jev 团队，他们启发了整个细分市场。Jev 一出来，大家都激动得不行，用户不断来找我们，我们内部团队也说：“我们需要一个快得多的分类系统。”有些即将推出的 Dot 功能，我不想提前透露太多，但大家会看到一些基于 Decisions API 做出来、反应非常迅速的功能。OpenAI 很多人一下就被这个技术问题吸引住了，开始琢磨：“怎么把它做出来？我们不会去重新训练一个模型，但是……”
Nikunj Handa： 我觉得 OpenAI 有很强的黑客文化，大家看到有意思的东西就会兴奋起来。推理团队的一位同事，还有基础设施团队的一位很厉害的同事说：“我们来动手试试。”他们做了个原型，发现确实能跑起来。现在我们就在不断优化延迟，尽可能把它做快，希望未来几天就能推出。一旦达到延迟目标，我们就会争取发布。
主持人 Vibhu： 有意思的是，一方面有这种黑客文化，另一方面，正如 Sam 所说，99%……你们也是最可靠的 API 之一，使用量可能也是最大的，而这正是你团队直接负责的部分。大家应该怎样看待 Decisions API？很多人见过 Jev、听过讨论，但还没实际用它开发，你们正在把它带给更广泛的人群。应该把它看成什么，又该怎么用？
Nikunj Handa： 我们看到的主要用途是快速分类。计算机操作的演示很精彩，但不同模型各有适用范围：让 Astra 编写 JavaScript 脚本来控制电脑，与让 Luna 每次选择一个动作，所需的能力并不一样。不过，对某些计算机操作任务来说，这已经够用了，我很期待看到这方面的成果。我在内部还看到一个有意思的原型：把 Decisions API 与 GPT Live 结合。GPT Live 是我们的双向实时语音 API，采用前端模型与后端模型协作的架构。GPT Live 负责快速对话和分派任务，后端则可以使用 Astra 这样的模型。过去，GPT Live 的工具调用一直让人感觉比较慢。现在有人做了一些演示，让 GPT Live 通过工具调用控制电脑，整个体验变得灵敏、自然得多。我很期待看到大家把 Live 和 Decisions API 上的 Luna 结合起来，看看能做出什么，想必会很有意思。
主持人 Swyx： 我想把这里面的事情给大家讲清楚，尤其是从产品角度，因为最近很多人在做 Jev 的仿制品，过去两周大概已经有一百个了。
主持人 Swyx： 大家可以复刻一个 Jev API，说实话，那就是结构化输出，而 OpenAI 是最早做这个的。所以我想讲清楚，什么是决策模型，真正重要的是什么。它不只是延迟，也不只是结构化输出，对吧？决策模型的价格和 Luna 一样，那我直接用 Luna，把推理关掉，再加上结构化输出，就等于有了 Jev 吗？并不是，这才是真正的区别。
Nikunj Handa： 我们没有为这件事训练一个新模型，而是完全基于现有的同一套 Luna 权重来做，所以它真的就是 Luna。在此基础上，我们对输出加以约束，结构化输出是很重要的一部分，同时专门优化推理系统，让首次决策返回时间（TTFD）尽可能短。因为你可以有多个问题，我们基本上就是把这些问题并行运行。
Nikunj Handa： 对，批量运行。大家正在尝试各种推理技术，让它尽可能快。但至少我们最初的实现，也就是第一个版本，是直接在 Luna 上采用零样本方式来做，看看效果如何。当然，我们希望先把它推出去。这就是 OpenAI 一贯的迭代部署方式：先发布，看看大家怎么想，再根据需要进一步改进模型。这就是 Decisions API。
主持人 Swyx： 听起来，如果仍然是同一套 Luna 权重，那么有些创新还在后面，比如置信度。我们在播客里谈过校准，也谈过校准的基准测试。关键在于，基于人类反馈的强化学习（RLHF）会让模型的输出趋向于你想听到的内容。但那不一定反映它实际上有多大把握。
Nikunj Handa： 完全同意。我也很想看看实际结果如何。也许置信度和校准会成为后续模型发布时需要重点改进的关键方向。
主持人 Swyx： 架构方面也有争论。Jev 没有公开说明具体做法，所以没人知道答案。目前主要有两种猜测：一种认为它可能使用扩散模型，而不是自回归模型。不过，你们用自己的方法也实现了并行生成。另一种猜测与机制可解释性有关：也许它分析模型的激活，然后直接输出权重。你们也做过这方面的研究，所以大家会有这样的猜测。
主持人 Vibhu： 这两种思路都有人做过演示。我记得 Gemini 分享过 Gemini Diffusion，或者是 Gemma Diffusion，用来生成 Jev 风格的输出。可解释性研究者也尝试从模型的中间层提取信息。不过，这些都只是猜测。
主持人 Swyx： 关键是，你到底想达到什么目标？因为做出类似的 API 形式并不难；难的是之后的速度、准确性和置信度校准等能力，以及其他校准方面的能力。
Nikunj Handa： 整个领域现在被带动起来了，大家会做出很多有意思的东西，也会互相学习，这让我很期待。
主持人 Vibhu： 作为平台团队，你的工作很大一部分是帮助开发者做出东西。你觉得大家应该用 Decisions API 和计算机操作智能体开发什么？你们内部有没有正在做的东西，是这次变化之后才真正变得可行的？
Nikunj Handa： Decisions API 在内部的用途其实很明确，比如用户运营团队马上就开始用了，说：“我们得把所有客服工单都分类。”此外还有 GPT Live 的一些演示也很精彩。我想 Codex 应用团队或许也会用它做些尝试。不过，整个项目大约一周前才启动，现在还处于很早期的阶段。
主持人 Vibhu： 评估方面也有很大的需求，尤其是让大语言模型充当评判者时，延迟能非常低。
Nikunj Handa： 这方面的发展会很值得看。至于 Agents API，OpenAI 内部已经有一批第一方产品完全建立在它之上。刚刚发布的 Codex 安全相关功能，就是完全基于 Agents API 构建的。今天还会推出一个与会议有关的功能。你们记得 Sam 展示插件扩展的那个演示吗？你在日历里，可以把会议记录汇入自己的空间。
Nikunj Handa： 这些全部都是基于 Agents API 构建的。现在我们刚把它推出去，我很想看看大家会在上面做出什么。
主持人 Vibhu： 我觉得你们展示得很好，编辑空间、页面、协作，再把自己的 Dot 加进来，内容相当多，大家能从中得到很多启发。
Nikunj Handa： 是的，这些有了 Astra 都能实现。现在一切发展得实在太快了，人们从想法走到实现的速度快得惊人。
主持人 Swyx： 有没有什么方面是你特别希望大家重点反馈的？也许你们先把东西推出去，前面有几个不同方向，希望开发者帮你们决定走哪条路。
Nikunj Handa： Agents API 和 Decisions API 是我们最新的产品，我们欢迎关于它们的各种反馈，帮助我们确定接下来的方向。Responses API 则是我们的主力，目前非常关注性能，主要分成两个方面。首先是延迟。我们一直在重写整个 Responses API 技术栈，从首个 token 的返回时间（TTFT）以及后续 token 之间的延迟（TBT） 这些指标入手，尽可能降低延迟，这些仍然是我们工作的重点。
其次是深入改进缓存，尤其是个人智能体这类应用，基本上就是一条永远不断延续的会话。我们一直在努力把缓存做得更好，现在可以保证三十分钟内的缓存命中。实际上，我们刚为一位用户推出了长得多的缓存窗口，提供十二小时的缓存命中保证。
Nikunj Handa： 还不是，目前处于预览阶段。我们会争取尽快向所有人开放。只要为缓存写入多付一点费用，我们就能保证在更长时间内读取缓存。比如，你正在使用一个智能体会话，完成了一些操作后离开，等到三四个小时后再回来继续使用，仍然能够享受到缓存带来的性能优势。
主持人 Vibhu： 用了新模型以后，你们也把这部分成本降了不少，对吧？便宜了 25%。
Nikunj Handa： 是的。开发应用时，要充分考虑缓存，使用我们的提示词诊断或缓存诊断工具，找出哪些地方没能有效利用缓存。这部分很重要。我还想谈谈预热，我们现在已经在 API 里提供了这个功能。如果你知道某个提示词将会用到，就可以提前预热缓存：现在先支付缓存写入费用，让它在接下来三十分钟里随时准备好。
Nikunj Handa： 可以一直继续，创建很多个。我特别希望收到关于底层性能的反馈，让我们能继续把 Responses API 做成基于大语言模型开发时性能最好、最可靠的方式。对于那些新产品，则欢迎任何方面的反馈。
主持人 Swyx： 对我来说，缓存显然很必要，但到头来，你还是会碰到一百万 token 的上下文上限，在可预见的未来，这个上限大概也不会改变。所以仍然需要好的压缩方法，这方面的最佳实践是什么？
Nikunj Handa： 完全正确。首先，OpenAI 有自己专有的压缩，也就是上下文压缩（compaction）。
Nikunj Handa： 没错。在 Agents API 中，上下文压缩功能已经内置在 Agent 的运行框架 (Harness）里。如果使用 Responses API，则有两种方式：一种叫服务端上下文压缩，告诉 Responses API，一旦达到某个 token 阈值，就自动压缩，减少正在占用的上下文。另一种是 /compact ，适合希望完全自己控制的人，你可以随时调用 /compact ，用自己的逻辑决定何时压缩。
主持人 Swyx： 它不是通用人工智能（AGI），不过，它确实是手动接管的方式。
Nikunj Handa： 很多大型编程智能体都喜欢手动控制。如果去看开源 Codex 运行框架里的实现，就能看到他们用 /compact 处理这件事。我们也在研究新的上下文压缩技术，其中一些已经在 Codex 运行框架里实现了，可以看到。我们还在试验一些基于文件的系统，所以在上下文压缩方面，也有不少工作正在进行。
主持人 Swyx： 时间快到了。你讲了很多性能方面的事情，也介绍了正在发布的新 API。关于平台的未来，还有哪些感兴趣的方向，可以再透露一点吗？
Nikunj Handa： 我们现在提供的还是比较底层的东西。我之前在 Stripe 工作，当时很重要的一部分工作，是在核心支付基础能力之上，构建更高层的基础组件和产品。我一直在想，在 AI 里怎样做才最好。我们已经尝试过几次，比如很早以前推出的 Assistants API，但它并不是一个特别合适的答案。现在我们沿着 Agents API 这个方向走，它提供 Codex 运行框架，但究竟应该在里面给用户多大的灵活性？这还是个开放问题。
比如，我们应该如何设计内存墙（Memory Walls），以及各种更高层级的 API 对象，进一步抽象和封装底层的存储概念，让用户少操心这些细节？这一整片领域，我都很想弄清楚该怎么设计。在 AI 里，很多事情现在的做法是，提供一个底层 API 基础能力，再给一个示例运行框架，然后让编程智能体去实现。但其中究竟有多少应该直接内置到 API 里，是我一直在想的问题。如果大家对此有想法，我很愿意听。
主持人 Swyx： 我经常想到一个类比，我们就用它来收尾：你们正在构建一个 AI 云平台，Sam 一年前就说过这个。你们有点像在重新经历 AWS 的发明过程，需要逐个确定：这个是 EC2，那个是 S3，等等。但你们做的是这些东西各自的 AI 原生版本。
主持人 Vibhu： 确实有很多可以类比的地方，比如对那些知道将会用到的内容，提前预热缓存。很好的一点是，这些能力都开放给了开发者，让大家有了更多构建新东西的方法。
声明：本文为 InfoQ 编译， 不代表平台观点，也不构成投资建议，未经许可禁止转载。
VIP课程推荐
APP专享直播
热门推荐
24小时滚动播报最新的财经资讯和视频，更多粉丝福利扫描二维码关注（sinafinance）
股市直播
02 / 美军奉命准备重启对伊朗重大行动：特朗普权衡时机，行动或赶在美以选举前
03 / 今天，“存储”的悲喜并不相通：长鑫科技大跌，三星电子赚翻
05 / 董事长被指系“东航空姐下跪事件”当事人，广东一上市公司回应
07 / 10月8日收盘：三大指数收跌 10年期美债收益率创20年新高 银行与科技股承压
10 / 美公司指控中国个人和机构用AI工具攻击韩国金融机构，外交部回应
01 / 又“热”起来了！探访国庆假期北京楼市：售楼处、样板间，都要排号
04 / 操盘必读：影响股市利好或利空消息_2026年10月8日_财经新闻
09 / SpaceX拟举债400亿美元采购英伟达芯片，其股价应声下跌
10 / 热搜爆了！尊界刹车踏板支架被踩断了3次！某车帝专栏报道！江淮汽车跌停！
01 / 美好“浦”面而来｜烟火正浓 佳节有味 周二超惠吃伴您悦享假期
7X24小时
用户7763476192 ： 再玩下去6000亿都守不住了，没人玩了
新浪简介 | 广告服务 | About Sina 联系我们 | 招聘信息 | 通行证注册 产品答疑 | 网站律师 | SINA English