OpenAI全新智能体API：新手乐开花，老手没波澜

12 日凌晨，OpenAI 对最基础的 API 产品 Chat Completion API 进行了升级，为其添加智能体功能后命名为 Response API。

调用 Chat Completion API 时，借助 Response API 便可使用联网搜索、文件搜索和 Computer Use 功能。想想近期爆火的 Manus 应用的功能，其中的意味颇为微妙。

与 Response API 同时发布的还有此前发布的 Agent 框架 Swarm 的升级版——OpenAI Agents SDK，其主要功能是编排智能体工作流，涵盖单智能体和多智能体。

Response API 可视为 Chat Completion API 与 Assistant API 的结合体。从 Agent 构建角度看，它使用更为简便，宣称“只需一次 Response API，就能运用多个工具和模型论次解决复杂任务”。
Response API 能作为统一接口，将 OpenAI 的模型和内置工具集成到应用中，还能轻松实现数据存储以及智能体的性能跟踪、评估。OpenAI 承诺：“不会默认使用用户的业务数据来训练我们的模型。”
原来的 Chat Completion API 仍可继续使用，后续更新的新模型也会支持它。这对仅需支持简单聊天应用的开发者而言是个好消息，无需耗费大量精力迁移至 Response API。当然，Response API 已完全涵盖 Chat Completion API 的所有功能，若从头开始开发，可直接使用 Response API。
对于 Assistant API，OpenAI 将在 Response API 完成对其功能的继承（如本次遗憾未添加的 Code Interpreter，以及 Assistant、Thread 等）后，于 2026 年中期将其完全弃用，开发者可着手准备迁移。
网络搜索工具基于 GPT – 4o 和 GPT – 4o – mini，在基准测试 SimpleQA 上，GPT – 4o search preview 和 GPT – 4o mini search preview 分别获得 90% 和 88% 的分数，远超 OpenAI 其他未调用搜索的基础模型。

费用方面，GPT – 4o search preview 和 GPT – 4o mini search preview 定价分别为 30 美元每千次查询和 25 美元每千次查询。

文件搜索工具与 Assistant API 中的类似，但相较于后者，增加了元数据过滤、直接搜索端点（可直接搜索向量存储）等新功能。其费用为每千次查询 2.50 美元，文件存储是 0.10 美元/GB/天，首 GB 免费。

Computer Use 工具和之前发布的 Operator 一样使用了 Computer – Using Agent（CUA）模型。在基准测试中，该模型在 OSWorld 的全 Computer Use 任务上成功率达 38.1%，在 WebArena 上达 58.1%，在 WebVoyager 的基于 Web 的交互任务上达 87%，创下新的 SOTA 记录。

OpenAI 表示，此次通过 API 使用 Computer Use，相当于将 Operator 的功能扩展到本地操作系统，会带来新风险。尽管进行了额外的安全评估和红队测试，但结合其在 OSWorld 上仍欠佳的表现，官方建议使用时进行人工监督。费用方面，Computer Use 每百万 token 输入花费 3 美元，每百万 token 输出花费 12 美元。

按照 OpenAI 的说法，Response API 代表了他们未来构建智能体的路线选择。
OpenAI Agents SDK 基于 Swarm 构建，而 Swarm 基于 Chat Completion API。与 Assistant API 相比，它有更好的透明度，能对上下文、执行步骤和工具调用进行细粒度控制。具体改进如下：
– 智能体：易于配置的 LLM，具有清晰的指令和内置工具；
– 交接：智能体之间的智能控制转移；
– 防护机制：可配置的输入输出验证的安全检查；
– 追踪和可视化：通过可视化智能体执行轨迹来调试和优化性能。

未来，OpenAI 可能将 Agents SDK 开源。
据 OpenAI 的 Atty Eleti（Response API 开发者之一）透露，Response API 的开发初衷是鉴于当下多模态输入输出、思维链推理以及智能体工作流的发展趋势，Chat Complete API 逐渐难以适应，而 Assistant API 使用过于复杂，其后台处理方式导致速度较慢。

与 Chat Completion API 相比，Response API 会存储所有 Response，无需重复输入上下文，使用“previous_response_id”即可继续对话。其响应结构更复杂，用概念 item 表示，代表用户输入或模型输出的多态对象，可包含消息、推理、函数调用、web 搜索调用等。
尽管 Response API 有诸多改进和便捷设计，但它真的那么好吗？过去因 Chat Completion API 受限，开发者只能用 Assistant API 实现文件搜索等功能，然而 Assistant API 使用中存在诸多问题，如使用复杂、响应速度慢、缺少 Webhook 设置、上下文编辑困难、token 数易暴涨（添加的文档会在多轮聊天中重复调用并消耗 token）、RAG 文件存储成本高等。此次 Response API 能在多大程度上改善 Assistant API 糟糕的用户体验仍是未知数。
从 Reddit、Hacker News 上用户的反馈来看，OpenAI 此次发布并未带来太大惊喜，反而吐槽居多。例如网络搜索费用，有网友称比自己配置 Google search api（可能只需 1 – 1.5 美元）贵很多。
OpenAI 旨在用一套工具整合过往成果，提高产品易用性，提供全套监控和衡量工具，让开发者更依赖其生态，尤其是数据存储功能的支持，开发者一旦使用，对生态的依赖会更强。但这终究是一款适合初级开发者的“傻瓜式”产品，对于需要更多自定义和复杂功能的开发者来说，吸引力不大。
特别是在智能体开发方面，目前智能体发展尚处早期，可标准化的内容不多，社区探索也未出现大量重复造轮子的情况，因此对智能体进行抽象的必要性较小。将语言模型作为黑盒，构建面向场景的工具和软件才是最佳方式，而非在其上嵌套过多的 LLM 抽象。正如所说“LLM 应该是一个应用中最无聊的存在”。
简言之：小白狂喜，老手无感——鸡肋。在设计能征服开发老手的产品方面，OpenAI 还需向 Anthropic 学习。