⚡️The new OpenAI Agents Platform
25:38 Share

大家好，欢迎回到另一期Latents-Based Lightning节目。我是Alessio，Decibel的合伙人和CTO，和我一起的是Spix，SmallAI的创始人。嗨，今天我们有一期非常特别的节目，因为我们要和我们老朋友Roman聊聊。嗨，欢迎。嗨。

谢谢。感谢你们的邀请。还有Nikunj，如果有人曾经尝试过访问API上的任何内容，Nikunj就是那个人。所以我了解你的邮件，因为我期待着它们。是的。很高兴见到你们所有人。我认为我们今天基本上是为了讨论新的API而聚集在一起的。所以也许你们想先开始。OpenAI今天发布了什么？是的，我可以开始。我们今天发布了很多新东西。我们将推出三个新的内置工具。

所以我们正在推出网络搜索工具。这基本上是用于搜索的ChatGPD，但在API中可用。我们正在推出改进的文件搜索工具。所以这是你将你的数据带到OpenAI。你上传它。我们负责解析它，将其分割成块，嵌入它，使其可搜索，并为你提供这个可以使用的就绪向量存储。所以这就是文件搜索工具。然后我们还将推出我们的计算机使用工具。所以这是ChatGPD中操作员产品背后的工具。所以今天它将面向开发者。

为了支持所有这些工具，我们将拥有一个新的API。所以，你知道，我们我认为在23年3月左右推出了完成API。已经有一段时间了。所以我们正在寻找一个更新来支持模型可以做的所有新事情。所以我们正在推出这个新的API，叫做Responses API。它是，你知道，

它与工具一起工作。我们认为它将成为我们构建的所有未来代理产品的绝佳选择。所以这也将在今天发布。实际上，我们发布的最后一件事是代理SDK。我们在去年推出了这个叫做Swarm的东西，它是一个实验性的SDK，供人们进行多代理编排之类的事情。它应该像教育性的实验一样，但是人们真的很喜欢它。他们很喜欢它。

所以我们想，好吧，让我们升级这个东西。让我们给它一个新名字。所以我们称之为Agents SDK。它将在OpenAI仪表板中内置跟踪功能。所以有很多很酷的东西要发布。所以是的，对此感到兴奋。很多东西，但是我们说2025年是代理年。所以这就是它，很多用于为开发者构建这些代理的新工具。

好的，我想我们会逐一进行，并将Agents SDK留到最后。所以Responses API，我认为人们的主要担忧，以及我认为我在规划过程中与你们交谈时向你们表达的内容是，聊天完成功能会消失吗？所以我只想让你们回应人们可能有的担忧。

聊天完成功能绝对会保留。它是一个我们已经使用了相当长时间的底层API，围绕它构建了许多工具。所以我们要确保它得到维护，并且人们可以自信地继续在其上构建。与此同时，它针对的是不同的世界进行了优化。它针对的是一个预多模态世界进行了优化。我们还针对单轮进行了优化，

文本提示输入，文本响应输出。现在有了这些代理工作流程，我们注意到开发人员和公司想要构建更长期的任务，这些任务需要多次轮次才能完成。例如，计算机使用就是其中之一。这就是为什么Responses API应运而生，以支持这些新的代理工作流程。但是聊天完成功能绝对会保留。

在Assistance API中，我们的目标日落日期是2026年上半年。所以在我看来，这是一种非常诗意的API与模型的镜像。我认为这就像Assistance API和聊天完成功能的合并，对吧？合并成一个统一的Responses。这就像GPT和旧系列模型也正在统一一样。

是的，这正是正确的框架。我认为我们吸取了从Assistance API中学到的最佳经验，特别是能够非常方便地访问工具。但同时，简化了集成方式——你不再需要考虑六个不同的对象来访问这些工具。

Responses API，你只需要一个API请求，突然之间你就可以整合这些工具了，对吧？是的，绝对的。我认为我们将使Assistance API用户非常轻松直接地迁移到响应式API，而不会丢失任何功能或数据。所以我们的计划绝对是添加，你知道，类似于助手的对象和类似于线程的对象

与响应式API配合得非常好。我们还将添加代码解释器工具，该工具今天不会发布，但很快就会发布。我们将向响应式API添加异步模式，因为这是与Assistance的另一个区别。

它将具有网络钩子之类的东西。但我认为一旦我们准备好所有这些，这将是一个非常平滑的过渡，我们将给用户整整一年的时间来迁移，并帮助他们解决遇到的任何问题。所以我认为用户将从这种更灵活的原语中长期受益。

人们应该如何考虑何时使用每种类型的API？所以我知道过去，Assistance可能更具状态，有点像长时间运行，使用多种工具，有点像基于文件的东西。而聊天完成功能更无状态，你知道，有点像传统的完成API。人们是否仍然应该拥有这种思维模型，或者说默认情况下是否应该始终尝试使用Responses API？Responses API将在发布时支持它支持的所有内容，将支持聊天完成支持的所有内容。

然后随着时间的推移，它将支持Assistance支持的所有内容。所以对于任何开始使用OpenAI的人来说，这将是一个非常合适的工具。他们应该能够访问Responses。顺便说一句，Responses也具有无状态模式。所以你可以传入store false，这将使整个API无状态，就像聊天完成一样。我们真的试图获得这个统一的故事，这样人们就不必同时处理多个端点了。

话虽如此，ChatCompletion是我们采用最广泛的API。它非常流行，所以我们仍然会在未来几年内用新的模型和功能来支持它。但是，如果你是新用户，或者你想利用这些内置工具中的某些工具，你应该完全可以迁移到Responses，并且你将拥有比ChatCompletion更强大的功能和性能。

我认为我同意我认为最能引起共鸣的信息是，它是一个严格的超集，对吧？就像你应该能够做你在聊天委托和助手那里可以做的一切一样。我刚刚假设，因为你现在默认情况下是有状态的，你实际上正在存储聊天日志或聊天状态。我认为你会为此收费。所以，你知道，对我来说，你发现如何免费提供它非常令人惊讶。

是的，它是免费的。我们将你的状态存储30天。你可以关闭它。但是是的，它是免费的。关于状态的有趣之处在于，它只是使，特别是对我来说，它使调试和构建事物变得如此简单，我可以创建一个相当复杂的响应对象，它是我的构建的更复杂应用程序的一部分。我可以直接进入我的仪表板并查看确切发生了什么。我的提示出了问题吗？它没有调用这些工具中的一个吗？我是否错误配置了这些工具中的一个？

你正在做的所有事情的可视化可观察性非常非常有帮助。所以我对人们尝试它并从中受益感到兴奋。是的，我认为这确实非常好。但我要说的是，我的朋友Corey Quinn说，任何可以用作数据库的东西都将用作数据库。所以要做好准备应对一些滥用。是的。

好的。是的，这是一个很好的说法。尝试使用元数据。人们在将数据塞入对象方面非常非常有创意。我们确实有包含元数据的响应。没错。

让我们完成所有这些。所以网络搜索。我认为当我第一次说网络搜索时，我认为你只是会公开一个API，然后返回某种像好的列表一样的东西。但是它的命名方式就像GPT-4.0搜索预览。所以我猜你基本上使用的是与聊天GPT搜索中相同的模型，该模型经过微调用于搜索，我猜。我猜它与基本模型不同。性能的提升令人印象深刻。举个例子，在SimpleQA中，

GPT-4.0的准确率为38%。4.0搜索的准确率为90%。我们总是谈论工具如何像模型一样，模型并不是你需要的全部。工具同样重要。所以是的，也许可以让人们快速预览一下制作这个特殊工具的工作。我应该这样做吗？是的。开始吧。所以，是的，

首先，我们以两种方式推出网络搜索。一种是在Responses API中，它是我们的工具API，它将作为网络搜索工具本身可用。所以你将能够使用工具，打开网络搜索，你就可以开始了。我们仍然希望让聊天完成用户能够访问实时信息。所以在那个聊天完成API中，它不支持内置工具，

我们正在启动对ChatGPT for Search使用的微调模型的直接访问，我们称之为GPT-4.0 Search Preview。这个模型是如何构建的？基本上，我们的搜索研究团队一直在研究这个问题。他们的主要目标是从我们用于收集搜索信息的所有数据源中获取大量信息。

然后选择正确的内容，然后尽可能准确地引用它们。这就是搜索团队真正关注的。他们做了一些非常酷的事情。他们使用合成数据技术。他们已经完成了O系列模型蒸馏，以使这些4.0微调模型真正出色。但是是的，主要问题是，它能否保持事实性？它能否根据它检索到的内容回答问题？它能否准确地引用它？这就是这个微调模型真正擅长的地方。

所以，是的，我很兴奋它将直接在聊天完成中可用，并且作为工具可用。是的，只是为了澄清一下，如果我使用Responses API，这是一个工具。但是如果我使用聊天完成，我必须切换模型。我不能使用01并将搜索作为工具调用。是的，没错。完全正确。我认为真正引人注目的是，至少对我来说，以及我目前为止的个人经验，

使用它的方式是，当你使用网络搜索作为工具时，它与平台上的其他每个工具和其他每个功能完美结合。所以考虑一下这一点。例如，假设你有一个带有网络搜索工具的Responses API调用，但是突然你打开了函数调用。你还打开了，比如说，结构化输出。现在你可以像实时地从网络上构建任何数据一样。

在你需要的应用程序的JSON模式中。所以当你开始组合这些功能和工具时，它非常强大。这几乎就像一个互联网API，你知道，就像你可以访问你的应用程序所需的精确模式一样。是的。然后只是为了总结一下它的基础设施方面，我在……

帖子中读到，人们，发布者可以选择出现在网络搜索中。所以人们默认情况下都在里面吗？我们如何才能在网络搜索API中获得潜在空间？是的。是的。我认为我们有一些关于

网站、发布者如何控制在网络搜索工具中显示的内容的文档。我认为你应该能够阅读它。我认为我们肯定能够获得潜在空间。是的，我认为是这样。我将此与我去年开始报道的在线LLM的更广泛趋势进行比较。实际上，我认为Perplexity是第一个提供连接到搜索的API的公司。

然后Gemini有了某种搜索基础API。我认为你们，实际上我没有，我在最初阅读文档时错过了这一点，但你们甚至提供了带有精确匹配子段落的引用，我认为这是现在的标准。我认为我的问题是，我们如何看待这种东西的知识截止日期，对吧？因为现在基本上没有知识截止日期，它总是实时的。

但是模型在其反向传播中内化了什么以及正在搜索其rag之间存在差异。

我认为这取决于用例，对吧？以及你想展示什么作为来源。例如，你以Hebbia公司为例，它使用了这种网络搜索工具。他们可以结合，例如对于信用公司或律师事务所，他们可以找到来自互联网的公共信息，以及有时你确实想要访问的实时来源和引用，而不是内部知识工具。

但是如果你正在构建不同的东西，例如你只想拥有一个依赖于模型的深层知识的助手，你可能不需要这些直接引用。所以我认为这有点取决于用例。但是有很多像Hebia这样的公司需要访问这些引用，以便精确地知道信息来自哪里。

是的，是的，当然。然后关于广度的一件事，你知道，我认为很多深度研究，开放式深度研究的实现都有这种关于它们搜索深度和搜索广度的超参数。我在文档中没有看到这一点，但这是否是我们可以调整的东西？这是你推荐的吗？

思考。非常有趣。这绝对不是今天的参数，但我们应该探索一下。这非常有趣。我想象一下，你将如何使用网络搜索工具和Responses API来做到这一点，你将拥有某种形式的代理编排，在这里你有一个规划步骤，然后你进行的每次网络搜索调用都明确地深入一层又一层。但这并不是一个开箱即用的参数。但这很酷，这是一个很酷的事情。是的。我将提供的唯一指导是

许多这些实现都提供top K，也就是，你知道，top 10，top 20，但实际上并不真正想要那样。你想要某种相似性截止值，对吧？就像某种匹配分数截止值一样，因为如果只有五件事，五份匹配的文档很好。如果有500个匹配，也许这就是我想要的。对。是的。

但这可能会使我的成本非常不可预测，因为成本大约是每1000次查询30美元，对吧？所以是的。是的。是的。我想你可以拥有某种形式的上下文预算，然后你就像，尽可能深入地挖掘，选择最好的东西，并将其放入X个令牌中。

可能有一些创造性的方法来管理成本。但是是的，这是一个非常有趣的事情。你是否看到人们将文件和搜索API一起使用，你可以搜索然后将所有内容存储在文件中，这样下次我就不用再为搜索付费了？是的，人们应该如何平衡这一点？

这实际上是一个非常有趣的问题。首先让我告诉你我如何看到人们使用文件和搜索一起工作的一个非常酷的方式，他们将他们的用户偏好或记忆放在向量存储中。因此，当查询进来时，你使用文件搜索工具来获取某人的阅读偏好或时尚偏好等信息。然后你搜索网络以查找他们可以购买的与这些偏好相关的产品。

然后你渲染一些漂亮的东西来向他们展示，例如，这里有五件你可能感兴趣的东西。这就是我看到文件搜索、网络搜索如何一起工作的方式。顺便说一句，这就像一个单一的响应式API调用，这真的很酷。所以你只需要配置这些东西，然后砰的一声，所有事情都会发生。但是是的，这就是我看到文件和网络如何一起工作的方式。但我认为你指出的内容很有趣。我相信开发人员将像往常一样，在他们如何组合这些工具以及他们如何使用它们方面给我们带来惊喜。

文件搜索作为拥有记忆和偏好的方式，就像Nikum所说的那样。但我认为从更宏观的角度来看，我在这里发现非常引人注目和强大的地方是，当你拥有这些神经网络时，它们拥有今天拥有的所有知识，加上对互联网的实时访问，

对于你的应用程序和文件搜索可能需要的任何类型的实时信息，你可以在其中拥有许多公司私有文档、私人详细信息。你将这三者结合起来，你将获得非常非常引人注目和精确的答案，以满足你的公司或产品可能想要实现的任何类型的用例。这与内部文档与开放网络之间的区别，对吧？就像你需要两者一样。

没错，没错。我从未想过它也能做记忆。我想，再说一次，你知道，任何东西都是数据库，你可以存储它，我们都会将它用作数据库。这听起来很棒。但我认为你一直在扩展文件搜索。你拥有更多文件类型。你拥有查询优化、自定义重新排序。所以它看起来确实像，你知道，它已经完善了。显然，我没有关注

太多关注文件搜索功能。但听起来你的团队添加了很多功能。是的。元数据过滤是人们一直要求我们提供的主要功能。而这正是我非常兴奋的功能。我的意思是，一旦你的存储大小超过，你知道，超过，你知道，5000、10000条记录，你就需要它了。所以是的，元数据过滤也即将到来。对于大多数公司来说，这也不是你想要内部重建的能力。你知道，像

你知道，考虑嵌入和分块，以及像它听起来对于你的用户来说非常复杂，就像一个非常明显的东西一样，例如Navant这样的公司，例如，他们能够使用文件搜索来构建，例如，获取你拥有的所有常见问题解答和旅行政策，你将它放入文件搜索工具中，然后你就不必考虑任何事情了。现在你的助手自然会更了解来自这些文件的所有这些策略。

问题是，正如你所知，已经存在一个非常非常活跃的RAG行业。所以还有许多其他向量数据库，许多其他框架。如果它是一个开源堆栈，我会说我与之交谈的许多AI工程师都想要拥有这个堆栈的一部分。感觉就像，我们应该何时自己动手，何时应该只使用OpenAI提供的任何东西？

是的。我的意思是，如果你正在从头开始做一些事情，你将拥有更多控制权，对吧？所以非常支持人们尝试卷起袖子，构建他们超级定制的分块策略和超级定制的检索策略以及所有这些。而这些事情对于使用开放式工具来说会更难做到。开放式工具具有，我们有一个开箱即用的解决方案。我们提供一些旋钮来定制事物，但这更像是一种托管的机架服务。

所以我的建议是，从开放式工具开始，看看它是否满足你的需求。随着时间的推移，我们将添加越来越多的旋钮，使其更易于定制。但是，你知道，如果你想要完全定制的东西，你想要控制每一件事，

那么你可能想要使用其他解决方案来手动滚动它。所以我们支持两者，工程师应该选择。然后我们得到了计算机使用，我认为操作员显然是今年最热门的版本之一，而我们只有……

让我们谈谈这个。这似乎也是一个为操作员微调并具有浏览器访问权限的单独模型。是的，绝对的。我的意思是，计算机使用模型令人兴奋。计算机使用的很酷之处在于，我们还处于非常非常早期的阶段。它就像计算机使用的GPT-2，或者可能是计算机使用的GPT-1。但它是一个单独的模型，它已经被开发出来。

你知道，计算机使用团队一直在研究。你向它发送屏幕截图，它会告诉你采取什么操作。所以它的输出几乎总是工具调用，你根据你试图操作的任何计算机输入屏幕截图。也许可以稍微放大一下，因为我相信你的观众非常非常喜欢原生，显然。但是计算机使用作为工具是什么，对吧？操作员是什么？所以计算机使用的想法是，我们如何让开发人员也构建可以为用户完成任务的代理，但使用计算机或浏览器。那么你如何做到这一点呢？这就是为什么我们有这个为计算机使用优化的自定义模型，我们像自己一样使用它来进行操作。但是将它作为API背后的想法是，想象一下，现在你想为你的产品或你自己的客户自动化一些任务，那么现在你可以拥有像启动

其中一个代理，它将查看屏幕并在屏幕上操作。这意味着能够点击，能够滚动，能够键入并报告操作。这就是我们所说的计算机使用，以及将其作为工具包装在Responses API中。所以现在这也在暗示我们之前暗示的多轮次内容。这个想法是，是的，这些操作中的一个可能需要几分钟才能完成，因为可能需要20个步骤才能完成该任务。但是现在你可以。

你认为计算机使用可以玩口袋妖怪吗？这将很有趣。我想我们应该尝试一下。有很多兴趣。老实说，我认为口袋妖怪确实是一个很好的代理基准。似乎克劳德遇到了很多麻烦。

听起来我们应该把它作为一个新的评估，看起来像。是的。哦，然后在我们继续Agents SDK之前还有一件事。我知道你时间紧迫。所有这些，你知道，blah blah dash预览，对吧？像搜索预览，计算机使用预览，对吧？你看到它们都像4.0的微调一样。我认为问题是，它们是否都将合并到主分支中，或者我们基本上是否总是会拥有这些模型的子集？是的。

是的，我认为在早期，OpenAI的研究团队使用微调模型进行操作。然后一旦事情变得更稳定，我们就将其合并到主线中。所以这绝对是预览结束后的愿景，因为我们对

并了解所有开发人员用例，并且我们在这方面做得很好。我们将使它们成为核心模型的一部分，这样你就不必处理这种分叉了。你应该像去年我们引入视觉功能时那样看待它，你知道，视觉功能是在基于GPT-4的视觉预览模型中，然后视觉功能现在显然内置于GPT-4.0中。你可以对其他模态（如音频）以及针对搜索和计算机使用优化的模型进行同样的思考。

Agents SDK，我们还剩下几分钟。所以让我们假设每个人都看过Swarm。当然。我认为Swarm确实普及了交接技术，我认为这对于某种多代理世界来说非常非常有趣。SDK有什么新功能？是的，当然。所以我们基本上添加了对类型的支持。我们使这个更加……

我们添加了对类型的支持。我们添加了对防护栏的支持，这是一个非常常见的模式。在防护栏示例中，你基本上会同时发生两件事。防护栏可以阻止执行。这是一种发生的乐观生成。

我认为我们添加了对跟踪的支持，所以你基本上可以查看Agents SDK在开放式仪表板中创建的跟踪。我们还使它非常灵活，因此你可以从支持聊天完成API格式的任何提供商那里选择任何API。所以它默认支持响应，但你可以轻松地将其插入到使用聊天完成API的任何人中。同样，在跟踪方面，你可以支持多个跟踪提供商。

默认情况下，它指向OpenAI仪表板。但是，你知道，有很多跟踪公司，我们也将在这一方面宣布一些合作伙伴关系。所以就像，你知道，添加许多核心功能并使其更易于使用，但仍然以交接为中心，这是主要的主要概念。顺便说一句，这很有趣，对吧？因为Swarm

只是从直接学习客户的经验中产生的，就像在生产中编排代理非常困难一样。你知道，简单的想法可能会很快变得非常复杂。这些防护栏是什么？这些交接是什么，等等。所以这是从学习客户的经验中产生的，最初发布时是一个低调的实验，我会这么说。

但我们对围绕这个概念的势头之大感到惊讶。所以我们决定从中学习并接受它。就像，好吧，也许我们应该将其作为OpenAI平台的核心原语来接受。这就是导致Agents SDK的原因。我认为现在，正如Nikud提到的那样，它就像向其中添加所有这些新功能一样，例如利用我们拥有的交接，但也包括跟踪。

而且我认为对开发人员来说非常引人注目的是，与其拥有一个统治所有代理的代理，并且你将很多工具调用塞进去，这很难监控，现在你拥有了你需要分离逻辑的工具，对吧？你可以拥有一个根据意图转到不同代理的三级代理。然后在OpenAI仪表板中，我们还发布了许多新的用户界面日志。所以你可以看到所有跟踪UI。本质上，你将能够排除故障，例如在三级代理向辅助代理和第三个代理进行交接时，以及工具调用时到底发生了什么。所以我们认为Agents SDK与跟踪UI相结合，绝对可以帮助用户和开发人员构建更好的代理工作流程。

我认为这对开发者来说非常有吸引力，因为不必再只有一个万能的代理，在其中塞入大量工具调用，而这些调用很难监控。现在，你们有了将逻辑分离所需的工具，对吧？你们可以有一个根据意图转向不同类型代理的分诊代理。

然后在 OpenAI 仪表板中，我们还会发布许多新的用户界面日志。因此，您可以查看所有跟踪 UI。从本质上讲，您将能够对工作流程中发生的情况进行故障排除，例如，当分诊代理将任务移交给次要代理和第三个代理时，并查看工具调用等等。因此，我们认为，代理 SDK 与跟踪 UI 相结合，一定会帮助用户和开发人员构建更好的代理工作流程。

在我们结束之前，您是否考虑将其与 RFT API 连接起来？因为我知道您已经有了，您可以存储我的文本补全，然后我可以对其进行微调。对于代理来说，这是否类似于存储我的跟踪信息，然后帮助我改进代理？是的，绝对可以。就像您必须将跟踪信息与评估产品关联起来，以便您可以生成良好的评估一样。一旦您拥有良好的评估、评分者和任务，您就可以使用它来进行强化微调。

还有很多细节需要在这里确定，但这就是我们的愿景。我认为我们将全力以赴，并希望能够使整个工作流程对开发人员更容易。

太棒了。非常感谢您的时间。我相信明天您会在 Twitter 上忙于处理所有开发人员的反馈。是的，非常感谢您邀请我们。与以往一样，我们迫不及待地想看看开发人员将用这些工具构建什么，以及我们如何才能尽快向他们学习，从而随着时间的推移使这些工具变得更好。太棒了。谢谢你们。谢谢。谢谢你们两位。