OpenAI DevDay 特别节目：Computer Use、Decisions API 与 UltraFast
点播放，字幕跟着声音走
Subtitles follow the audio
逐句文字稿
点任意一句，从那里开始听
正在加载字幕…
-
现在 computer use 完成任务的速度比普通人还快，大多数情况下大概都是这样。
-
我觉得下一个前沿，是让 computer use 的表现真正超越人类，用软件的速度能赶上甚至超过像我们这样的资深电脑用户。
-
我觉得那一天到来时会非常有影响、非常令人兴奋，因为到那时我们突然就能做出实时体验强得多的产品了。
-
大概四周前，这东西还不在 DevNet 上。对，完全没有。
-
没有，这算是受 Jeff 启发，然后……
-
我觉得你们正式成为第一个克隆并采用我们的前沿实验室了。
-
我感觉 OpenAI 有很强的黑客文化，大家就是那种……
-
他们对新东西特别兴奋，所以 Inference 那边一个人，还有红外团队一个特别棒的人，就说这太厉害了，我们要上手搞一搞。
-
他们做了个原型，居然就跑通了。
-
现在我们就是在延迟上不断爬坡，想办法把它做到尽可能快。
-
我们想在未来几天内发布。
-
所以一旦达到我们的延迟目标，我们就争取把它推出去。
-
好，我们非常高兴能在这里。
-
今天是 OpenAI Dev Day 特别播客。我们是你们直播之后的第一档播客。第一档播客。
-
我们请到了 Ari，他负责 computer use agent 的产品和工程团队。在我们正式开始深入聊 computer use 之前，你先简单回顾一下。今天都发布了什么？
-
你们今天这一连串发布，快速说一下都有啥？
-
对对，今天超级兴奋。我们刚下主题演讲。
-
真的太酷了。有一堆 computer use 相关的发布，我觉得都值得聊一聊。我们有 dots，这是新的那种个人助理产品，而且它有一些非常令人兴奋的 computer use 功能。
-
还有 GPT-6.1 Sol，这是个很棒的新模型，我觉得它特别适合 computer use，因为成本和速度上都有优势。
-
我记得我们分享过，它的成本是 Astra 的五分之一，如果单看 computer use 的话是七分之一，这真的很惊人。
-
抱歉，要梳理的东西太多了。还有那个 API。
-
Agents API，现在里面也集成了 computer use，这真的很酷，因为开发者现在可以直接基于 Codex 和 ChatGPT 里用的同一套 computer use 来开发了。
-
然后还有一些我们现有 computer use 功能的演示，比如 app shots，你可以把电脑上正在做的事情的上下文抓下来，非常快地带进 Codex 和 ChatGPT。
-
还有 Mac 上的原生 computer use，Roman 让它自动给自己的应用截图，而 computer use 在用他的应用的时候，他还能在电脑上干别的事。所以，真的是很激动人心的主题演讲。
-
更别说还有 Decisions API。Decisions API。
-
一上来先问，它们都是同一个模型吗？
-
是同一个数据集蒸馏到不同模型上吗？
-
基本上就是，computer use 用的是 Decisions API 吗？还是说它们算是分开的？
-
Decisions API 很酷的地方在于它有所有这些新能力。
-
它并行做推理。
-
它没有推理过程。
-
它比我们用于 computer use 的模型要小。
-
所以这些能力让它非常快。
-
但它们也让它在做那种长周期、复杂的任务时稍微差一点。
-
所以我觉得，怎么说呢，怎么把这些方法结合起来，仍然是一个开放的研究领域。
-
不过，我真的很期待看到大家用 Decisions API 做出什么东西来。
-
有意思的一点是，dots 现在有挂载的个人电脑了。
-
所以看起来它们持久性要强得多。
-
你已经用了一段时间了。
-
大家应该怎么去突破边界呢？
-
那大家应该朝什么方向去用呢？
-
现在他们自己该动手试些什么？
-
我拿它做了很多客服方面的事，比如这个搞错了。
-
我不想登录，不想做身份验证，随便找找，直接把它修好就行。
-
对，那我们该怎么再往前推一步？
-
大家应该试些什么？
-
这个产品真的很酷，因为每个 dot 都能访问自己在云端的 Linux 虚拟电脑，这跟我们其他产品不一样。嗯，你知道，以前我们是在云端提供一个浏览器，或者让它访问你自己的电脑，但现在你拥有的是云端一整台自己的 Linux 电脑。
-
所以我们可以运行完整的桌面应用，嗯，它也能用网页浏览器。
-
所以，对，你知道，我觉得 Computer Use 强大的地方，也是我觉得它特别令人兴奋的原因，就是它让智能体能够做人能做的任何事，嗯，
-
因为世界上所有软件都是为人类设计的，而现在智能体也能用同样的软件，你可以把任务交给智能体去做。
-
所以，对，你在电脑上会做的任何事，都可以让一个 dot 去做。
-
对，我觉得哪些特别有用，真的取决于最终用户是谁，以及在他们生活里什么是有价值的。
-
不过，对，我会先从想一想你花时间做的某件事开始，然后想怎么把它交给智能体去做。
-
对，很多订机票和购物，说实话，甚至像玩游戏之类的。完全没错。
-
对，我不知道，对我来说，我最近做的一件事，我一直在弄的，我订了一个备餐服务，因为我想吃得健康一点，你知道吧？
-
我特别喜欢我找到的这个备餐服务，因为它让我能高度精细地定制我订的餐。
-
所以我可以指定要多少克鸡肉、多少克米饭，但这太复杂了。
-
我下一单花了两个小时。
-
然后我发现我可以让 Computer Use 帮我做，它15分钟就搞定了。
-
所以我实际上省了两个小时。
-
它做这件事的速度比我快八倍，而且在 GPT 6.1 上帮我省了两个小时。
-
所以这类任务我觉得真的非常强大。
-
作为一个创作者，我可以直接告诉你，我马上就能想到的头号用例就是自动化 YouTube，因为 YouTube 很多东西都不通过 API 开放。
-
你只能把它放进虚拟机里跑，比如他们的 A/B 测试功能，或者发社区帖子。
-
这些都没法通过 API 用，因为他们讨厌开发者。
-
总之，这是我从我们的开发者体验团队那里听来的。
-
他们经常用它来操作 YouTube。对，真的特别棒。
-
那我想来点，怎么说呢，我想稍微来点刺激的。
-
我们有个朋友做的一档头部 AI 播客，以一句话出名，说 Computer Use 过去两年毫无进展，这个说法很有意思。
-
我觉得你是全世界最适合聊这个话题的人之一，聊聊事情到底是怎么进步的。
-
对，他们大概是几个月前说的。
-
我希望他们现在看法不一样了，因为 Computer Use 跟那时候比完全是180度的大转变。他是个硬茬，这挺让人佩服的。好，行。
-
不过你知道，你基本上整个职业生涯都在做某种计算机自动化，对吧，先是在苹果做快捷指令，然后做了 Sky，再后来加入 OpenAI。
-
你能不能讲讲你这条主线是什么，是什么在驱动你，以及当年可能做不到的事情，还有你的一些里程碑？
-
我想接着问一个后续问题，从上周到今天的 Codex Computer Use，最大的变化是什么？是模型吗？是 Dots 吗？还是 harness？
-
所以就是把整个历史，加上今天发布里真正变了的东西都讲讲？
-
说到这条主线，我想我一直都对自动化很兴奋，喜欢帮人们把任务自动化，因为这样你就能省下时间，把精力放在比精细操作电脑更重要的事情上。
-
所以，对，这就是我们做那些产品的原因。
-
我先是在苹果，后来我们做了一家叫 Sky 的公司。
-
最后我们加入了 OpenAI，这真的非常令人兴奋。我觉得其中有件事很特别。
-
你得绕着苹果的各种限制想办法，直到苹果说，行吧，我们干脆把你招进来，你就可以做自己的东西了，对吧？
-
那地方确实挺酷的，能在那里工作。
-
回头看 Sky 那段经历真的很有意思，因为我们当时也在做 computer use。
-
那时候模型的能力差太多了。
-
而现在，就在过去这一年里，模型在 computer use 上的能力已经变得极其强大。
-
我觉得最大的变化是，以前它们能比较可靠地启动任务，但接着就会遇到问题，而现在它们真的很擅长调试。
-
它们很擅长重试，会反思哪里行、哪里不行。
-
而且我觉得我们也把 computer use 往前推了，computer use 这个领域本身也进步了。
-
我觉得我们用上了更多技术。
-
现在 computer use 经常会写代码。
-
所以如果你在 Codex 里实际看一下，手动展开那些工具调用，你会看到它不是一次只做一个动作，它实际上是在写 JavaScript 代码并执行，由电脑执行这些代码，有时一次完成很多个动作，这大大提升了速度，也大大增强了能力。
-
我们用上了更多无障碍之类的多模态接口。
-
所以模型可能会用截图，可能会用无障碍信息，可能会用 Playwright，它可以根据手头的任务使用很多不同的机制。
-
然后，对，模型的加速真的非常惊人。
-
那么，对，今天有什么不一样？
-
我觉得我们一直在让电脑变得更好。
-
所以我觉得只差一天，影响可能比过去一个月甚至两个月还要小一些。
-
不过，对，我觉得 DOT 里的 computer use 真的很令人兴奋，还有我们新推出的那个模型也是。
-
在主题演讲上，Tejal 提到 computer use 的速度提升了 7 倍，在几个基准测试上也好多了。
-
你们是怎么考虑衡量它的？
-
computer use 就是那种，像你说的，是随着时间不断改进的东西。到底是 harness 的功劳？还是模型？还是后训练？
-
你们内部是怎么看待衡量它有多好的，新模型又带来了哪些变化？
-
其实我们有好几种不同的衡量方式。
-
其中一些是基于 harness 的不同排列和配置。
-
这事儿有点复杂，因为我们的生产产品有更多安全检查。
-
而且这些检查会根据手头任务的需要做不同的配置。
-
所以衡量它的方式有很多。
-
但我觉得不管我们怎么衡量，看到的提升都相当一致。
-
这些提升有时候来自 harness，有时候来自模型。
-
而且对，这个结果让我特别兴奋：GPT 6.1 在 computer use 上的性价比提升，甚至超过了它相对 Astra 的基础成本改进。看到这个真的很酷。
-
直播里我特别喜欢的一个画面是，你们在改进曲线的帕累托前沿，而且讲了很多关于你们如何结合 harness 一起改进它的内容。
-
能不能举几个你们灵光一现的例子，不管是模型驱动 harness，还是 harness 驱动模型，随便哪种都行？
-
我不想重复自己，但我觉得引入更多模态真的非常强大。
-
一个更具体的例子是，过去我觉得很多 computer use 产品得花大量时间滚动页面，你知道，就是截个图，试着做点什么，
-
然后发现哎呀我得往下滚到下一页结果，再截个图，再试着做点什么，又得往下滚，所以我觉得有了无障碍接口，还有直接访问 DOM 之类的，
-
现在语言模型真的能看到整个页面或者整个应用，它能写代码一次完成多个步骤。
-
所以我觉得这些大概就是最大的几个灵光一现的时刻。
-
还有很多相比之下没那么激动人心的小突破，但其实我们也发现，很多速度提升是由大量细小的摩擦点驱动的，我们得深入进去一个个排查。对。
-
很多非常硬核的工程工作。对。
-
我是说，app shots 整体来说，对吧？
-
我觉得大家还没太搞明白这中间的区别，因为你在 Codex 里截个 app shot 的时候有个挺直观的界面，但他们可能不知道区别在于你能真正去操作每一个按钮，而且每段文字都是以非常优化的形式呈现的。对对，没错，就是这样。
-
其实还挺好玩的，如果你想较真一点，你可以打开 Codex，按两下 command 键截个 app shot，就能把你正在用的那个应用里的内容抓进来，带进 Codex 或者 ChatDB 里聊。
-
然后你点一下那个附件，再点右上角那个小小的按钮，就能看到原始文本，还能看到原始的无障碍表示。
-
对，我们花了很多功夫去把东西全都倒出来，对。
-
倒出来，同时还要让它 token 高效，做得高效。
-
这里面有点讲究，算是门手艺。
-
而且你知道吗，结果发现，这项技术本来是为人类发明的，就是那些有无障碍需求、想用屏幕阅读器技术的人，这项技术对他们用电脑真的很有帮助。
-
它对 大语言模型 用电脑也同样很有帮助。
-
所以能参与做这个真的挺有意思的。
-
补充一下背景，我觉得很多人不理解 app shots，他们甚至不知道这是个功能。
-
就是你双击 command 键，它拉进来的东西看起来像一张截图。
-
你就会想，哦，我干嘛要打开一张截图扔进去啊？
-
不是的，它其实把所有的元数据、所有代码、所有东西都抓进来了。对，没错。
-
对，所以就像，你截一个网页的图，如果网页上有链接，截图里是不包含链接指向哪儿的。
-
它也不包含，比如你截个日历的图，事件标题是截断的，对吧？
-
但你截 app shot 的时候，它给语言模型的是关于一切东西的完整上下文。
-
这就让它能做多得多的事情。
-
对，想了解更多的话，Jason Liu，我邀请他在 AI engineer 上做了个完整的 workshop 讲这个。太棒了。你做得很好。
-
我有个关于 computer use agent 的更宏观的愿景问题。
-
所以你举的例子，截个图、滚页面、再截个图看看到哪儿了，今天它们已经能自动化很多事了。瓶颈在哪儿？是模型吗？是 harness 吗？
-
你觉得两年后会发展成什么样？
-
你觉得它会连续跑好几个小时吗？我们怎么才能走到那一步？
-
对 computer use 的未来有什么预测吗？
-
有，我觉得真正疯狂的是，团队在过去几个月里做到的事情——现在 computer use 完成任务的速度，大概在大多数情况下都比普通人更快了。
-
我觉得下一个前沿，是让 computer use 的表现真正达到超人水平，就是它用软件的速度能跟我们这些熟练的电脑用户一样快、甚至更快。
-
我觉得那会非常有意义、非常令人兴奋，因为到那时候我们就能一下子做出提供更多实时体验的产品，而且我觉得这也会降低使用 computer use 的门槛和启动成本，会让我们
-
开始默认把某些事情交给 agent 去做，那些我们以前习惯手动做的事，我觉得这也很令人兴奋，因为能帮我们省下大量时间。
-
而且我觉得，你知道，现在还有各种各样的小摩擦和瓶颈挡在这条路上。
-
我觉得，对，模型这边有要解决的，推理这边有，harness 这边有，表示方式上也有。
-
你知道，我们发现随着 computer use 越来越快，我们越来越被单纯执行一个操作的速度卡住。
-
比如说，你知道，在我们 computer use 任务的基准测试里，有相当一部分时间其实是，假设你在 doordash.com 上自动化一个任务，
-
很多时间其实是在等 doordash.com 自己加载出来，你知道吗？
-
对，那你就写一个等待，然后执行这个等待。对，完全是这样。
-
而且你其实很想，真正重要的是你要做到，从它终于加载完到你执行下一个动作之间，延迟要尽可能小，这本身其实也是一门统计学。
-
也许可以用事件驱动的方式来做。
-
只要可能，你就想用事件驱动。
-
JavaScript 有 load 事件，浏览器有网页导航的 load 事件。
-
但还有些类型的事件其实没法用事件驱动。所以这里有很多复杂性。
-
我想到的一个例子是跟客服聊天。对。
-
回复可能要 30 秒，也可能要三分钟。哦，对。
-
我用 Codex 跟好多机器人打过交道了。太棒了。
-
但我也在想，对面知不知道自己在跟一个机器人说话。
-
因为我都是用完整的句子回复，还会大写。太好笑了。
-
比如我会给出完整的号码、完整的参考编号什么的。
-
就是太，明显太好了。我不在乎。
-
我就是想赶紧把客服问题解决掉。
-
我给它提示过，你知道，别假装你是机器人。
-
要表现得非常烦躁、像个真人、只说简短的一句话，就是催它、各种招都使上。
-
我还会跟它说，等回复的时候，用子代理去研究更好的办法，搞清楚我们到底需要什么。不错。
-
就像人类稍微介入一下。太厉害了。
-
我还觉得有一半时间对面也是个机器人。
-
所以现在就是两个老板在互相对话了。
-
我还要说，我们现在达到的一个计算机使用的里程碑是，三四年前，我们还害怕把 大语言模型 接到网上、接到我们的设备上。
-
而现在我让它帮我配置 DNS。
-
我让它帮我付账单，几万美元的东西我就直接交给它，用 computer use 一顿猛操作。
-
那最坏能坏到哪去呢？
-
所以这些都挺好的。
-
我觉得现在你显然也得自己先用自家的产品，诸如此类。
-
现在你把它发布到 API 上了，有什么坑或者建议想告诉开发者吗？因为他们马上大概就要亲身遇到这些了。
-
首先，我真的很兴奋我们把 computer use 带进了 Agents API。
-
我觉得这真的很棒，因为显然很多开发者都在做需要跟第三方网站和服务打交道的应用。
-
而 computer use 有这种通用性，它能跟任何东西配合工作。
-
所以现在开发者突然就能用上跟我们同一套的 computer use 实现来开发了。
-
我觉得如果你想自己搭一套 computer use 的框架，那有很多好活儿可以干，但这事儿很难。
-
而且我们的模型也是在我们自己的 computer use 框架上训练的，所以用跟模型配套发布的这一套是有优势的。
-
实际上可能在速度、成本和准确率上都有优势。
-
所以我觉得大家能在这个基础上开发，真的挺好的。
-
然后，嗯，嗯，对，你知道，我觉得就像你说的那样，我们其实都还在这个过程里，也许我们有些人比世界上很多人更早一步，更习惯这项技术、更信任它。
-
所以我觉得我们有责任，嗯，通过确保我们做的东西是可靠的、通过做对的安全检查、通过在做像付款这种有后果的事情之前先征得用户同意，来慢慢建立起这种信任，通过问，你知道，
-
也许取决于具体应用，确保只让它访问任务真正需要的那些网站或应用。
-
所以我觉得这是值得考虑的重要一点。
-
不过对，我真的很鼓励大家去试试新的 agents API，在上面做各种酷东西。
-
我们很想听听你们的反馈，你知道，看情况怎么样。
-
你们有没有看到它影响开发者工作流的方式有什么变化？
-
关于 dots 有一点，你知道，你在 Slack 里能看到它。
-
你能看到人们用语音，然后照着 Roman 演示的那个例子来做，把这个应用改一改，过程中给我发截图，所有这些，你有没有在采用情况里看到人们怎么用 computer use 来做编码工作流？
-
大家能从中借鉴什么建议吗？
-
其实 computer use 我最喜欢的用例之一，也是我们在实际场景里经常看到的，就是让智能体真正去测试它自己写出来的软件，这比听起来重要得多，因为传统上你在 Codex 里做点东西，然后 Codex 帮你把它写出来，
-
接着你得去测试它，这时候你就成了智能体的 QA，对吧？
-
然后你还得去测试它，这时候你就有点像这个智能体的质检员了，对吧？
-
所以有了 computer use，你就能把整个软件开发流程走完，智能体可以自己写软件，还能自己测试。
-
所以我做东西的时候特别有乐趣，让智能体去测它。
-
等它到我手上的时候，已经能正常跑了。
-
我还有额外的乐趣，因为有时候我自己就在开发 computer use，所以现在我有一个 computer use 智能体，它在用我的 computer use 智能体，那个又在用别的东西。
-
所以没错，我真的觉得这是一类非常强大的用例。
-
我开发了一个可视化的试玩测试技能，它真的能抓出很多设计上的问题。
-
这些问题呢，通常你光看代码是根本发现不了的。
-
它用来克隆应用也特别好使，如果你在用一个很烂的 SaaS，想把它干掉，你就一屏一屏一屏地克隆它。
-
而且很明显，computer use 能完全驱动一切，截图、记录下来，然后用 Codex 把所有东西都克隆出来。真的很酷。
-
不过还是谢谢你们所有的进展。
-
我觉得时间到了。
-
这不会是我们最后一次聊。好，太酷了。这次真的很有意思。谢谢你们邀请我。好的。好的。好，我们严格掐点。
-
我们直接开始吧。来吧。好。
-
好，Nikunj，我们非常高兴你能来。
-
你在 API 这边发布了很多东西，就像我们刚才和 Ari 聊的那样。
-
你现在可以用 computer use 智能体来构建了。
-
你想重点讲讲 API 这边的变化吗，也简单介绍一下你自己是做什么的？好，当然。我叫 Nik Rinch。
-
我负责 API 团队的产品。
-
在这儿大概三年了。
-
一直在做发布和模型相关的工作。
-
我觉得在我待在 OpenAI 的这段时间里，这一直是个常态。
-
每出一个新模型，我们基本上都会跟后训练团队、研究团队紧密合作，搞清楚它里面有什么新东西。
-
然后我们再把这些能力在 API 里开放出来。
-
大概就是这么个流程。
-
你要是看 GPT-6 带来的所有新东西，我们发布的那些很酷的新能力，首先是异步函数调用。
-
所以你在 codecs 和 dots 这些东西里看到的很多情况是，工具调用耗时太长，你不需要在工具运行的时候暂停模型的执行。
-
你可以直接发起一个工具调用，然后继续跑、继续推理，之后再回来查看。
-
所以我们推出了异步工具调用，还推出了类似中途引导的功能。
-
现在你可以在模型推理的过程中往中间注入消息。
-
这样当你的工具调用结束时，你就可以把那些指令放进去。
-
这也算是模型对齐方面的一项能力，对吧？
-
对，它们得把这种能力训练进去。没错。
-
我感觉我们在应用里一直都有这个。
-
模型推理的时候，你一直都可以去引导它。
-
以前效果不是最好的，现在好多了。
-
我很期待看看它表现如何。
-
对，而且我们在 API 这边的主要目标就是，一旦某个能力在 harness 里训练好了，就把它放进 API。
-
所以我们会等那个时机，等到它足够好。
-
这里面很大一部分其实是靠 WebSockets 支撑的，我们大概几个月前发布的。
-
WebSockets 就是打开了跟模型之间这种完整的双向通信。
-
这不是什么 GP life 的事。
-
我说的就是 GPT-6，你可以做所有这些，比如异步工具调用、异步推理、注入消息。
-
所以这是个很好玩的 API，做起来很有意思，我真的很享受。
-
这就是为什么我们是工程播客，因为我们可以聊 WebSockets。对。
-
这跟 ultra fast 也配合得特别好，对吧？
-
就是那个，我觉得是第一次在 API 里开放，基本上就是你能拿到前沿智能的理论最快速度。
-
对，对，做那个项目真的太让人兴奋了。
-
我觉得在说 API 之前，Ultrafast 最有意思的部分就是看着推理团队用 Astra 大展身手。
-
他们一直在跑这些 codecs agent，想榨出更多性能。
-
我得说，至少有好几个月，很多精力都放在效率上、把成本压下来，所以我们才能把 lunar 的价格砍了 80%。
-
因为这里面很大一部分是靠他们落地的那些推理改进推动的。
-
然后现在他们转向了，想的是怎么让它跑得尽可能快。
-
所以 Ultrafast 在 Astra 这样的模型上看到，真的太惊艳了。
-
能跑那么快，真的很酷。
-
然后对，WebSockets 其实，我们第一次上线 WebSockets 是为了 GPD 5.3 Codec Spark，我都不敢相信我们给模型起了这么个名字，但当时就是为它上线的。
-
显然它帮助特别大，因为你得有工具调用。
-
你得真正减少跟工具来回交互的开销。
-
所以 WebSockets 在这方面特别棒。对。
-
每次看到都挺可爱的，我有我的重置用量上限，然后还有我从来没用过的 spark 用量上限。但它就在那儿，我想要就能用。我觉得它没了。终于，它没了。
-
你在慢慢把那些老的都干掉。真是很棒的一周。
-
我是说，那是我们第一次在极快的速度下拥有前沿智能。对。大家真的很喜欢。对。对。对。有些东西回来了。对。
-
而五点三 spark 明确归功于 Cerebris。
-
你们既不确认也不否认，呃，ultrafast 跟这个有关。
-
所以有 Cerebris，但大家，我就直说吧，大家确实很在意，也很好奇，而且你们自己也有芯片。
-
呃，房间里的大象，决策模型，决策 API。
-
我们是最早跟 Diogo 做了一期 Jeff 深度访谈的播客，我也在 AI engineer 上请他做过分享。
-
你们看到 Jeff 之后多快就反应过来说，对。
-
我觉得 Diogo 和 Jeff 团队真的功不可没，他们真的启发了整个市场里的这一块。
-
很明显 Jeff 一出来，大家都疯了。
-
我们的用户来找我们，我们内部的团队也说，我们需要一个快得多的分类系统。
-
我们可以，呃，我不想，呃，抢在 dots 一些还没发布的功能前面说，但你们会看到一些很酷的、非常利落快速的东西建立在 decisions API 之上。
-
呃，但是你知道，对，Jeff 启发了这一整件事，值得点赞，呃，显然 OpenAI 里有一堆人被这个勾起了兴趣。
-
他们就想，我们怎么才能把它做出来？
-
我们不会去训练一个新模型，但四周前，这不是，不不不不。这是受 Jeff 启发，而且——我觉得你们正式成为第一个克隆并采用这个的前沿实验室。
-
我觉得 OpenAI 有很强的黑客文化，大家就是会为一些东西兴奋起来。
-
所以一个来自推理的人，一个来自推理团队的特别棒的人就说，这太厉害了，我们要动手搞它。
-
他们做了个原型，跑通了。
-
现在我们就只是在延迟上不断爬坡，尽量把它做到最快。
-
而且我们想在未来几天内发布。
-
所以一旦达到我们的延迟目标，我们就会试着把它推出去。
-
有意思的是，在黑客文化的同时，就像Sam说的，你们团队直接负责的API大概有99%的可靠性，而且使用量应该也是最大的。
-
大家应该怎么理解Decisions API？
-
我感觉很多人看到了Jeff，听到了那些热议，但还没真正上手用过。
-
你们正在让它变得非常主流。
-
大家应该把它看成什么？该怎么用它？
-
对，我觉得我们看到的主要用例就是非常快的分类。
-
所有computer use的演示都很惊艳，真的很酷。
-
当然我觉得会有局限，比如让Astra写一段JavaScript脚本来控制你的电脑，对比让Luna一次只选一个动作。
-
我觉得智能水平肯定不一样，但也许有些computer use的任务，这样就够用了。
-
所以很期待看到它落地。
-
我在内部看到的另一个很酷的原型，是有人把它和GPT-Live接起来了。
-
GPT-Live就是我们的双向实时API。
-
它建立在前端模型和后端模型这套架构上。
-
所以GPT-Live就是那种超快的、思考和说话分工的东西。
-
GPT-Live是说话的那个，超快，特别擅长分派任务。
-
后面坐着像Astra这样的东西。
-
但在GPT-Live里，工具调用一直感觉特别慢。
-
所以大家一直在拼这些GPT-Live控制电脑的工具调用演示。
-
感觉就流畅自然多了。
-
所以我挺期待看到大家用Live、用Decisions API上的Luna能做出什么来。
-
嗯，那会挺让人兴奋的。对。
-
所以我想帮大家把这件事理清楚，特别是从产品这边来说，因为很多人一直在推出Jeff的克隆版。
-
过去两周大概有一百个了。哦，真的吗？太厉害了。
-
但他们能克隆Jeff API，说白了就是结构化输出，而OpenAI是最早做这个的。
-
所以我觉得咱们帮大家理清楚，决策模型到底是什么、重要的是什么？它不只是延迟。
-
也不只是结构化输出，对吧？
-
因为我完全可以就用Luna。
-
决策模型的定价跟Luna一样，对吧？
-
把推理关掉，然后加上结构化输出。我就有Jeff了吗？没有，对吧？
-
这才是关键。
-
这里面有一种置信度。对，完全没错。
-
我觉得，我们的做法是，我们并没有为此训练一个新模型。
-
我们完全是基于现有的同一套Luna权重来构建的。
-
所以没错，这真的就是Luna。
-
在此基础上，你要做的是施加约束。
-
所以结构化输出是其中很大一部分。
-
你实际上是在优化推理栈，让它变得非常快。而且因为可能有多个问题，你要做的就是基本上并行跑这些。作为一个批次。
-
对，你把它们作为一个批次来跑。
-
大家正在研究各种各样的推理技术，想让它尽可能快。
-
但至少我们第一版里的实现，就是在Luna之上做零样本，看看效果怎么样。
-
而且你显然想把它放出去。
-
就像这是OpenAI经典的迭代部署方式。
-
放出去，看看大家怎么想。
-
然后我们会在需要的时候继续改进模型。
-
嗯，所以对，这就是，呃，这个Decisions API。
-
而且显然有个好处，你有视觉能力。他们没有视觉能力，对吧？确实是这样。
-
显然，呃，我们用Luna就免费得到了这个。
-
对，我确实觉得，你知道，有些创新，听起来，呃，还在后面，如果还是同样的Luna权重的话，比如置信度和校准这些东西，我们在播客里聊过基准测试的校准，因为基本上，
-
重点就是RLHF会把你往你想听的方向拉，而不是实际的置信度水平。对，完全是这样。
-
你会看到它最终怎么发展。
-
这些会是未来模型发布时我们可能得去爬坡的关键领域。
-
然后在架构方面，另一个在争论的点，显然没人知道，因为Jeff不谈这个，但有两种猜测，一是也许模型不再是自回归的，而是你能用自己的方式实现并行生成。
-
另一个是某种机制可解释性的东西，你去分析激活值然后直接输出权重，这个你们大家都做过研究，人们也猜测过。
-
这两个方向都有过演示。
-
我记得Jim和我分享过Gemini diffusion、Gemma diffusion在Jev风格输出上的东西，也有人，你知道，从中间层抽取出东西来，但这都是猜测。
-
就像，你到底想追求什么，对吧？
-
因为你可以实现这个API。
-
每个人都能实现这个API，其实挺简单的。
-
但接下来还有速度，还有准确率，还有其他的校准特性。我不知道还有什么。
-
对，对，没错，完全是这样。
-
现在整个领域都被带动起来了，这太酷了，大家会做出很多很酷的东西，每个人都能互相学习，我对此真的很兴奋。
-
我觉得在平台团队，你的很多工作就是赋能开发者。
-
你觉得大家应该用 Decisions API 和 computer use agent 做些什么呢？
-
你们内部一直在做的、你觉得在新变化之后真正被打开的东西有哪些？
-
好，那我们想想。
-
Decisions API 在内部的用例其实挺明显的。
-
用户运营团队马上就上手了。
-
我们当时想，如果把所有支持工单都分类一下，还能发现什么？
-
当然，还有那些很酷的 GPT 现场演示。
-
我敢说 Codex 应用团队可能会接手这个，试着做点酷东西。
-
所以，这整件事一周前才开始的，所以还非常非常早期。哦，才一周？我很期待，好。
-
在 eval 的 LM as a judge 上有个大推进，就是让那里的延迟非常低。
-
对，对对，那会很有意思，值得看看。
-
然后，有了 agents API，我们基本上就是让一堆第一方产品，比如 OpenAI 内部的，完全建在它上面。
-
我们刚发布的 codec 安全相关的东西就完全建在 agents API 上面。
-
我们还有那种，我们今天要发布一个会议类的东西。我记得好像有个演示。
-
你记得 Sam 展示插件扩展的时候吗，有个演示，比如你在日历里，可以把你的会议笔记
-
直接放进 Zoom 通话里，类似 granola 那种东西。
-
对，所以所有这些都完全建在 agents API 上面。
-
对，我就是很期待看到，我们刚把它放出来，看看大家会在上面做出什么。
-
我觉得你展示得非常好。
-
整个编辑空间、页面、协作、加上你的 dot，这内容可真不少。
-
所以有很多灵感可以让大家去发挥。
-
对，对，用 Astro 全都能实现，你知道，现在事情发展得太快了，人们从有想法到落地执行特别迅速，太惊人了。
-
有没有什么是你希望大家重点关注、给你反馈的？
-
比如说，也许你刚把这个放出来，然后前面有个岔路口，你想让开发者帮你决定方向？
-
我觉得 agents API 和 decisions API，这些是我们的最新产品，非常希望得到各种反馈，好确定接下来往哪走。
-
这边的话，我们非常开放。
-
关于 responses API，它算是我们这边的主力，现在真的非常专注于性能。
-
性能主要体现在两个方面。第一就是延迟。
-
我们一直在重写整个 responses API 的调用栈，从 TTFT 的角度、从 TBT 的角度，让它尽可能快。
-
所以这仍然是我们重点关注的主要方向之一。
-
第二件我们一直在努力做的事，就是深入做缓存，尤其是针对这些个人 agent，它们基本上就是一条线程，一直不停地跑下去。
-
我们现在提供 30 分钟内缓存命中的保证。
-
对我们其中一个用户，我们刚推出了长得多的缓存窗口，所以我们现在提供 12 小时的缓存保证，让你在更长时间内都能确保缓存命中。有公开的 API 吗？
-
还没有，现在还是预览阶段。
-
我们会尽快把它推给所有人，不过缓存这块要多付一点钱，对吧？
-
而且我们保证缓存读取的时间长得多。
-
所以就算你的 instinct 线程，比如你在上面做了点操作，然后三四个小时后再回来，你依然能享受到缓存的性能。
-
而且新模型也把成本降了不少，对吧？哦对，没错。对。
-
我们基本上就是在靠缓存读取跑。对。
-
对开发者来说，应该去实现它，因为便宜太多了。对，对。
-
就像构建你的应用时，要非常注意缓存，用我们的提示诊断或者缓存诊断工具，搞清楚哪里在掉。
-
然后，缓存这块真的很重要。
-
嗯，对，我还想聊聊预热。
-
我们现在 API 里已经有了。
-
所以比如，如果你知道，嘿，我要拿到一个缓存，抱歉，我要拿到这个提示。
-
我就想先预热缓存，现在先付缓存写入的费用，然后让它准备好，接下来 30 分钟内随时可用。
-
而且它可以生成那个线程的很多实例。没错，对。
-
你可以一直跑下去，拥有大量这样的实例。
-
所以，对，我很期待收到关于底层性能的反馈，这样我们就能让 Responses API 一直是基于 大语言模型 构建时性能最好、最可靠的方式。
-
然后你基本上就有了我们的新产品，我就是想收集各种各样的反馈。对，直接用就对了，对吧？对，直接用。
-
请帮我们定义一下路线图吧。对。
-
对我来说，缓存这块，很好，对吧？
-
显然非常需要，但说到底，你还是会撞上百万 token 的上下文上限，而且在可预见的未来这大概不会变。
-
你还是需要好的压缩。
-
那方面最佳实践是什么？对，对，完全同意。
-
首先，OpenAI 有自己的专有压缩。
-
在 compaction 里，在 API 里。你替我们决定，对吧？对，没错。
-
所以在 Agents API 里，它是内置在 harness 里的。
-
如果你用的是 responses API，有两种做法。
-
一种是我们说的服务端压缩，就是你直接告诉 responses API，一旦 token 数到了这个阈值，就自动压缩，然后回退，或者说减少正在使用的上下文。
-
第二种就是 slash compact，如果你想要完全的控制权，就可以随时 slash compact，自己决定什么时候压缩——不是 EGI，是 AGI。对，对。
-
但这是手动控制的方式。
-
对，这是手动的方式，怎么说呢，不过很多大型的编程 agent 都喜欢手动来做。
-
我是说，如果你看开源 codex harness 里 codecs 的实现，就能看到他们用的是 slash compact 来做。
-
而且我们还在研究一些新的压缩技术。
-
其中一些你会在 codex harness 里看到。
-
它已经在 codex harness 里实现了。
-
还有一些基于文件的系统，我们正在试验。
-
所以没错，压缩这块也有很多很酷的东西在做。
-
太好了，我们时间快到了。
-
我觉得你讲了很多关于性能的内容，也讲了很多你们正在发布的新 API。
-
关于平台的未来，你还有什么其他感兴趣的方向可以给我们透露一下吗？
-
我们显然做的是非常底层的东西。
-
我之前在 Stripe 工作过。
-
在 Stripe，很大一部分工作就是在核心支付原语之上构建这些更高层的原语和产品。
-
我一直很好奇，在 AI 里做这件事最好的方式是什么。
-
我觉得我们在这方面尝试过几次。
-
我们很早以前就发布过 assistance API，但那个其实不太合适。
-
我们当时有点像是沿着这个 agents API 的方向走，它给你一套 codex harness，但到底该给多少灵活性才合适呢？
-
这是个还没有定论的问题。
-
我们该怎么设置记忆墙，还有所有这些更高层的、像 API 对象之类的东西，用来把更多的存储概念抽象掉。
-
这整个就像，呃，有一整片空间，我特别好奇该怎么去设计。
-
我觉得 AI 里很多事情就是提供一个底层的 API 原语，给一个示例 harness，然后让你的编码 agent 去实现它。
-
但这里面有多少要直接做进 API 里，是我一直在琢磨的问题。
-
所以我不知道大家有没有想法，如果有人有思路，那会非常有意思，很想听听。
-
对，我一直会拿来做类比的是，你其实是在建一朵 AI 云，对吧？
-
这是 Sam 一年前说过的话。
-
这几乎就像你在做 AWS 那样的发明，你得搞定，好，这是 EC2，这是 S3，这是这个，但你做的是每一个的 AI 原生版本。
-
有很多类比，所以你会为你已经知道的东西预热缓存。
-
而且这些东西全都开放给开发者，这挺好的，因为它直接打开了构建新东西的各种可能。对，完全同意。好，谢谢各位。谢谢。