被Manus惊到了？OpenAI深夜发布Agent开发三剑客！开源一个新的SDK，现场手搓三个Agent！还抖了一个内部的料

出品 | 51CTO技术栈（微信号：blog51cto）

“2025年将是Agent之年，这一年，ChatGPT和我们的开发工具将从仅仅回答问题，转变为真正为你在现实世界中做事。”

上周Manus通用智能体的发布之后带火了Claude的MCP框架之后，OpenAI终于坐不住了，今天凌晨一点通过直播的形式，一口气把自己内部工程人员在用的Agent开发工具发布了出来。

整体直播不长，只有20分钟，但足以让外界从OpenAI的视角来见识一番以全球最先进的基座模型来做出来的Agent的效果。

这次直播发布了三款Agent开发工具：一系列内置工具、一个新的API以及一个开源SDK。

最大的一个感受是：此次OpenAI演示的Agent，不同之处已经突破了文本形式的检索和输出，强大的多模态理解的能力加上computer use工具，可以说打造的Agent的表现体验是超过了Manus的Demo用例的。

话不多说，这就为大家总结一下。

OpenAI Agent开发者：拼凑低级API太难受了

OpenAI工程人员将Agent定义为一个能够独立行动、为您完成任务的系统。2025新年伊始，OpenAI在ChatGPT中发布了两种Agent。第一种是“Operator”，它可以浏览网页并为用户在网络上完成任务。第二种是“Deep Research”，它可以为你生成任何主题的详细报告，你只需要提供一个主题，它就可以在15分钟内完成可能需要一周时间的研究并给出答案。

于此同时，OpenAI也推出一系列新工具，能够让开发者能够轻松构建可靠且有用的Agent。OpenAI希望将这些工具以及更多功能通过API提供给开发者。

不过在刚刚过去的3个月里，OpenAI正在与世界各地的开发者交流，探讨如何让他们更轻松地构建代理。

而据开发者反馈，主要有两点，一是模型已经准备就绪。凭借先进的推理能力和多模态理解能力，我们的模型现在能够完成代理所需的复杂多步骤工作流。但另一方面，开发者们表示，他们不得不拼凑来自不同来源的低级API，这不仅困难、速度慢，而且常常显得脆弱。

因此，OpenAI做了这样一个决定：今天把这些工具整合成一系列工具、新的API以及新的开源SDK，让这一切变得更加容易。

内置工具好用到丝滑：两个search、一个computer use

开发者体验团队的工程师lan、API团队的工程师Steve、API产品团队人员Nick分别介绍了今天OpenAI所推出的所有内容。

图片

先从内置工具说起。正如上面图中所演示的，分别是网络搜索工具Web search和文件搜索工具File search。

其中网络搜索工具可以允许OpenAI的模型访问互联网上的信息，从而确保用户的回答和输出内容是最新的。

据介绍，网络搜索工具是为ChatGPT搜索提供动力的工具，它由一个经过微调的GPT-4o或4o mini模型来驱动。它非常擅长从网络上检索大量数据，找出相关信息，并在回答中清晰地引用这些信息。在衡量这类功能的基准测试中，例如简单问答的测试中，GPT-4o的得分达到了90%的顶尖水平。

图片

而第二个工具，文件搜索工具则是Steve的最爱。去年，OpenAI在辅助API中推出了文件源工具，方便开发者上传、嵌入他们的文档，并轻松地在这些文档上进行RAG操作。而今天，OpenAI则在文件搜索工具中推出两个新功能。

第一个是元数据过滤。通过元数据过滤，用户可以为文件添加属性，以便轻松筛选出与用户查询最相关的文件。第二个是直接搜索端点。即，用户现在可以直接搜索向量存储库，而无需让模型填充用户查询。

这两个工具可为最强搭档，网络搜索工具用于公共数据，文件搜索工具则用于私有数据。

第三个工具是计算机使用（Computer Use）工具。在API中，它被称为operator，它允许用户控制所正在操作的计算机。这可以是一台虚拟机，也可以是一个只有图形用户界面的遗留应用程序，但用户通常没有API访问权限。

如果你想自动化这类任务并在此基础上构建应用程序，就可以使用计算机使用工具，它配备了计算机使用模型。这个模型与ChatGPT中的Operator使用的是同一个模型。它在OS世界网络、网络航海家等基准测试中表现出色，早期用户对该模型的反馈也非常积极。

新的API：足够灵活的响应API

在开发这些工具并考虑如何推出它们时，OpenAI还从第一性原理出发，设计了最适合这些工具的API。

OpenAI在2023年3月与GPT3.5 Turbo一起发布了“聊天实现”功能，当时的每个API交互都只是输入文本和输出文本。

很快，OpenAI就引入了多模态模型，图像、音频也都具备了理解能力。此外，OpenAI也正在引入工具，还有像o1 Pro、Deep Research、Operator这样的产品，它们在幕后进行了多次模型交互和多次工具调用。

因此，OpenAI想要构建一个足够灵活的API原语，它支持多轮交互，支持工具，我们称这个新的API为“响应API”。

Steve在现场手搓了一个新API的Agent演示。操作非常简单，如果你之前使用过“聊天实现”功能，看起来将非常熟悉：选择一些上下文，选择一个模型，然后得到一个回答。只需要在response字段中的补充instruction的内容即可。

为了展示响应API的强大功能，Steve打算构建一个个人时尚助手。

这个例子很有代表性，个人时尚助手首先肯定要了解用户的喜好。

为此，Steve创建了一个向量数据库，为了直播效果，Steve还爆料称其中的一些条目是自己团队成员的穿着记录，他们为此一直在办公室里跟踪人们，了解他们的动态和穿搭。

演示说明：“我们有一个完整的业务团队在研究这个，所以我会添加文件搜索工具，并复制其向量存储ID。在这里，我实际上可以将存储库中的文件筛选到与你想要的风格相关的文件。所以，我们先从ilan开始。我们将筛选到他的名字，然后返回到这里，我们会刷一下并说‘可以’。”

 不过这些数据库里的数据也有可能是陈旧的。这时候浏览器工具是一个很好的方式，可以将用户的最新的信息带入你的应用程序。“所以为了为这个个人时尚助手创建一个真正好的应用程序，我们希望能够从网络上获取最新数据，以便我们既有最新信息，也有与你的用户真正相关的内容。”

为了展示这一点，Steve演示了添加网络搜索工具的过程。“网络搜索工具真的很棒，因为你还可以添加关于你使用地点的信息。”

响应API理解起来非常简单，因为它可以调用文件搜索工具，也可以调用网络搜索工具，并且可以在一次API响应中给出最终答案。为了告诉它我们到底想要什么，让我们给它一些指令。

比如：我们希望模型在被要求推荐产品时，可以使用文件搜索工具了解Kevin的喜好，然后使用网络搜索工具找到他所在位置附近的一家商店，他可能会对那里感兴趣。所以，我们可以回去在对话框中提示：“找一件夹克”。

这样，模型将发出文件搜索调用，以了解Kevin过往喜欢穿什么样的东西。然后，它将发出网络搜索工具调用，以找到基于他所在位置的他可能会喜欢的东西。所以，模型能够在一次API调用的范围内，找到很多Patagonia，这实际上与Kevin的偏好相符。“他一直在办公室里穿很多Patagonia，但一个个人时尚助手如果不为你代购就不算完整。”

接下来就是重头戏，computer use。使用计算机使用预览模型和计算机使用预览工具也非常简单，见下面的现场操作视频。

图片

只需要在resonse字段中生命model为computer-use-preview模型即可。

在直播中的例子，该模型要求计算机提供一个截图，并在这个计算机上运行一个本地Docker容器。在计算机上传完截图后，该API将查看计算机的状态并发出另一个动作：点击、拖动、移动、输入，然后计算机将执行那个动作。再截一个图，把它发回模型，然后它将继续以这种方式进行，直到它认为任务已经完成，然后返回一个最终答案。

开源的代理SDK:更复杂的Agent怎么办？

对于那些构建更复杂应用程序的人来说，比如你正在构建一个客户支持代理，处理退款的代理应用程序，还有另一个处理客户支持常见问题查询的，还有处理订单和账单的等等。考虑到这一类的Agent，OpenAI去年发布了一个名为Swarm的SDK，Swarm使代理编排变得容易。

“这本该是一个实验性和教育性的东西，但企业用户中很多人都将其投入生产了。”

因此，在用户的倒逼之下，OpenAI决定将Swarm打造成一个生产级的产品，增加许多新功能，并且我们将重新将其命名为代理SDK（Agents SDK）。

据开发Swarm的工程师ilan介绍，他花了很多时间与企业和建设者合作，帮助他们构建代理体验，并亲眼看到一些简单的想法在实际实施时会变得多么复杂。

因此，代理SDK的理念是保持简单想法的简单性，同时允许你以一种相当简单的方式构建更复杂、更健壮的想法。

初体验上跟上面的Response API有些类似，需要定义代理，有一些指令，同样需要文件搜索和网络搜索这两个工具。

默认情况下，该SDKh会使用Response API，但OpenAI实际上支持多个供应商，任何真正符合“聊天实现”功能的都可以与代理SDK一起工作。

不过问题在于，比如，你想在个人时尚代理上添加“退货”，“订单”等不同的业务逻辑，就会让代理的测试变得困难。

所以，推荐还是按照“多Agent”的思路来进行设计，这样可以真正分离关注点并分别开发和测试它们。

图片

而在新的SDK中，已经预置了客户支持代理，可以支持获取过往订单并提交退款请求。表面上这些只是普通的Python函数，但实际上都是Swarm中非常受喜欢的功能。

OpenAI将其这些Python函数带到了代理SDK中，并查看其类型推断或类型签名，然后自动生成模型需要使用的JSON模式以执行这些函数调用。然后，一旦完成这些，Agent就可以运行代码并返回结果。

当然，这些Python函数用户也可以自定义。

多个代理之间如何互动通信呢？OpenAI提出了“交接”的概念，即一个代理熟悉后，然后将其传递给另一个代理。在幕后，你保持整个对话的完整性，只是替换指令和工具，这为你提供了一种方式来分流对话并加载正确的上下文。

所以，还需要在原有的代理之上再创建了一个分流代理，它可以将对话传递给时尚助手代理或客户支持代理。

开发者肯定关心系统幕后究竟发生了什么。通常往往需要开发者手动添加一些调试语句，但代理SDK不需要，它的监控和追踪功能是开箱即用的，非常简洁。

通过OpenAI的追踪UI，可以看出刚刚每一步都发生了什么。比如：刷新了页面；从分流代理开始，发送了一个请求，进行了交接，然后切换到客户支持代理，它调用了一个函数；这里值得一说的是，交接在这里是一个一级对象，所以你可以看到我们实际上将它交给了哪个代理，以及它没有选择的其他选项，这实际上是一个非常有用的调试功能。

一旦进入客户支持代理，你就可以看到它调用了“获取过往订单”函数。最后，我们得到了一个回复。

此外，代理SDK还推出了一些其他内置的防护栏，你可以启用它们，我们有生命周期事件，最重要的是，这是一个开源框架，所以我们会继续构建它，你很快就可以安装它。

现在你可以通过pip install OpenAI-middle-dash-agents来安装，据悉，OpenAI很快也会推出JavaScript版本。

One More Thing：旧API计划停用

1.OpenAI此次引入了Response API，但“聊天实现”功能API并不会消失。OpenAI将继续用新模型和能力支持它。不过后续OpenAI发布的一些需要这些功能的模型和产品，将仅在Response API中提供。

2.Response API的功能是聊天实现API支持功能的超集。所以，用户迁移到Response API时的过程将非常简单。

3.Assistance API即将迁移。OpenAI根据所有测试用户提供的反馈构建了Assistance API。“没有在AssistanceAPI阶段学到的经验，我们也不会走到今天。”

OpenAI将为Response API增加更多功能，使其能够支持Assistance API所做的一切。一旦完成，该公司就会发布一个迁移指南，让应用程序无损地从AssistanceAPI迁移到ResponseAPI。

一旦完成，OpenAI计划停用辅助API。

最后，对于今天的深夜发布：两个内置工具web search/file search、一个新API（Response）、一个开源的代理SDK，大家如何看待呢？

会不会跟一些网友一样，觉得有点小遗憾：为什么不是GPT5呢？

不管怎样，从纯对话的Agent到能真正用于生产提效率的高级自主Agent，注定会发生在2025。

直播回放链接：​​https://openai.com/live/​​

本文转载自​​51CTO技术栈​​