OpenAI Responses API 与 Agents SDK 发布演示解读

OpenAI 宣布了一系列面向智能体开发者的工具。它将智能体定义为能独立行动、代人完成任务的系统。我在视频中观看并点评这场发布会，内容包括网页搜索、文件搜索、计算机操作、Responses API 和开源的 Agents SDK。

OpenAI 将 Operator 和 deep research 作为智能体产品的例子。根据我当时的体验，Operator 表现不太稳定，而 deep research 在日常工作中很有价值。这次发布将相关能力通过 API 提供给开发者。

我同意演示者的观点：模型已经能够胜任许多多步骤工作流。缺少的往往是周边基础设施，包括工具、本地环境、代码执行和协调机制。此前，开发者需要从多个底层 API 拼装这些部分。

第一个内置工具是网页搜索，它可以获取实时信息，而不只依赖模型训练数据。演示者介绍了一个经过微调的搜索模型，用来挑选相关材料并引用来源。他们展示的 SimpleQA 图表中，使用搜索的得分高于未使用搜索的对比模型。

文件搜索解决另一类需求：在上传的文档中查找信息。OpenAI 宣布支持元数据过滤以缩小结果范围，还提供直接搜索向量库的端点。网页搜索和文件搜索结合起来，能让应用检索公开信息和自己的相关数据。

第三个工具是计算机操作，它向开发者提供类似 Operator 的模型。应用负责提供计算机环境，可以是虚拟机，也可以是没有 API 的旧式图形界面应用。智能体随后可以请求通过界面执行操作。

我把这套组合与 Manus 相比：智能体可以搜索网页、在专用环境中操作、编写代码并把工作保存在文件里。OpenAI 提供的是供开发者自行组装类似工作流的基础组件，而非单一的成品应用。

演示者介绍 Responses API，称它旨在支持多模态输入、工具和多轮模型交互。Chat Completions 最初是文本输入、文本输出的接口；较新的 API 则希望让工具驱动的工作流更容易表达。

团队用一个私人造型师示例展示功能。最初的请求很熟悉：选择模型、提供指令并询问最新趋势。不同之处在于示例使用 Responses 端点，之后还会在同一工作流中加入工具。

团队已将示例穿衣偏好放入向量库。他们在请求中加入文件搜索，提供向量库 ID，并用元数据过滤器选择某个人的记录。助手随后就能根据相关文件总结这个人的风格。

接下来，演示者加入网页搜索和位置信息。指令要求模型通过文件搜索了解客户偏好，再用网页搜索寻找附近商店。示例中，一次 API 交互结合两种工具，推荐了东京的 Patagonia 商店。

在计算机操作示例中，他们切换到 computer-use preview 模型并指定显示尺寸。模型收到本地 Docker 环境的截图，提出点击等操作；应用执行后，再把新的截图发回。这个循环持续进行，直到任务完成。

更复杂的应用可能需要多个专门智能体，例如分别负责回答问题、退款和订单。OpenAI 表示，实验性的 Swarm 框架启发了面向生产的 Agents SDK，它希望让简单工作流保持简单，同时支持更复杂的编排。

团队用一个智能体、指令以及文件和网页搜索工具重新实现造型师。他们说 SDK 默认使用 Responses API，也能与兼容的其他供应商配合。另一个客服智能体负责退货，使其逻辑可以独立开发和测试。

客服智能体获得查询历史订单和提交退款请求的工具。演示者解释，普通 Python 函数可以成为工具：SDK 从类型签名推导 JSON schema，调用函数，并将结果返回模型。

交接会将对话从一个智能体转给另一个，同时切换使用的指令和工具。分流智能体可以把请求交给造型师或客服。演示中，退货请求被转交给客服智能体，后者查询了历史订单。

SDK 包含追踪和监控功能。演示者在仪表盘中检查一次运行，查看原始输入、可选和实际选择的交接、函数调用、参数及输出。我喜欢这个界面的清晰程度，因为可见性让多智能体行为更容易调试。

他们还提到护栏和生命周期事件，并表示该框架是开源的。我欢迎智能体框架之间的竞争；同时也说明，我投资了 CrewAI，并广泛使用过它。演示者表示，SDK 也可以使用兼容的非 OpenAI 供应商。

OpenAI 表示会继续支持 Chat Completions，而部分内置工具和智能体能力将通过 Responses 提供。发布会当时，团队表示计划补齐 Assistants API 尚缺的功能，并在计划于 2026 年停用之前提供迁移路径。

这次发布将检索、网页搜索、计算机操作和智能体编排整合为开发者基础组件。我认为这体现了 AI 从只回答问题向能够执行任务的系统发展；实际价值仍取决于开发者如何组合这些组件。