OpenAI 又一次改写了 API 规则！
OpenAI 刚刚推出了全新的 Responses API，这或将彻底重新定义了开发者与AI交互的方式。
Atty Eleti 在推特上将其称为「OpenAI API的新原语」，并表示这是两年API设计经验的集大成者，也是他们构建代理的基础架构的新篇章。
说到这里，你可能会好奇，Responses API 和 OpenAI SDK 之间是什么关系呢？
我来解释下——
OpenAI SDK 是开发者用来与 OpenAI 服务交互的工具包，就像一个完整的工具箱，也几乎成为除固执的Claude 和 Gemini 外所有模型的行业标准。
而 Responses API 是这个工具箱中的一个新工具，是 OpenAI 提供的一种新的交互方式。
具体来说：OpenAI SDK 是整个软件开发工具包，包含了多种 API（接口），它允许开发者在自己的应用程序中使用 OpenAI 的各种功能，包括了所有与 OpenAI 交互的方法，如 Chat Completions API、Assistants API，现在还有新的 Responses API
而 Responses API 是属于 SDK 中的一个新接口，并被设计为融合了 Chat Completions API 的简洁性和 Assistants API 的强大功能，提供了更好的状态管理、多模态支持和工具调用等功能。
在 Responses API 发布后，Atty Eleti 于第一时间发推分享了 OpenAI 如何设计它的故事。
我在这里将其转述分享出来，希望能让你有所了解和参考。
从周末项目到行业标准
故事要从两年前说起。
Atty Eleti 和同事 @_rlys 在一个周末（字面意义上的周末）构建了 Chat Completions API：周五设计，周二就正式发布了。
这个周末项目迅速成为了行业标准，如今已经支撑着数十万应用，并被所有主要模型提供商采用。
当年晚些时候，他们又推出了 Assistants API 测试版，这是他们构建「代理原语」的第一次尝试。后台运行的 Runs 会根据需要调用工具。
许多开发者喜欢它的便捷性（只需使用 OpenAI 作为你的数据库！）以及通过 file_search 工具内置的强大 RAG 功能。
为什么需要重新设计？
但自那以后，情况发生了很大变化：今天的模型已经是多模态的（文本、图像、音频），具有代理能力（可以调用一个或多个工具），并且能够「先思考再说话」。
Chat Completions 不是为此设计的：它是无状态的（迫使开发者反复传递大量图像和音频数据），不支持工具调用，还有许多可用性问题（特别是正确处理流式输出非常困难）。
Assistants API 虽然支持工具调用，但回顾起来过于抽象。你需要了解半打概念才能入门，后台处理意味着它默认速度很慢。
开发者想要的是底层能力，但 API 的形态成了障碍。
Responses API：简单与强大的完美结合
于是，Responses API 诞生了：一个将 Chat Completions 的简洁性与 Assistants 的强大功能相结合的 API。
只需 4 行代码就能开始使用，但同时内置了文件搜索、网络搜索、函数调用和结构化输出等强大功能，只需一个参数就能启用。
（表单编码输入的粉丝们可以欢呼了：OpenAI API 现在支持它了。）
状态与存储：不再重复发送数据
Responses API 在多个方面都是有状态的：
所有 Responses 默认都会被存储，让你可以在控制面板中查看它们以便后期调试。你可以使用 previous_response_id 继续对话，无需反复发送大量数据。
Responses 也是状态机，更好地模拟了不完整、中断和失败的模型输出。
Items：多态对象的新世界
Items 是 Responses 的核心概念：表示用户输入或模型输出的多态对象。Items 可以代表消息、推理过程、函数调用、网络搜索调用等等。
如果说 Chat Completions 是「输入多条消息，输出一条消息」，那么 Responses 就是「输入多个 items，输出多个 items」。
（同时还从外部标记多态转向了内部标记多态，使数据结构扁平化了一半。）
托管工具：一行代码搞定复杂功能
托管工具是 Responses 的杀手级功能：
只需一行代码，你就能在应用中获得一流的网络搜索、文件搜索，以及即将推出的代码解释器。
（此外还发布了独立的 Vector Stores Search 端点，让你可以将 OpenAI 的 RAG 与任何模型或提供商一起使用。）
流式输出：告别复杂的增量模式
Responses 的流式输出也经过了完全重新设计。
以前的 API 遵循「增量」模式：输出 JSON 对象，这些对象是前一个版本和新版本之间的差异。这不是类型安全的，而且集成起来非常困难。
Responses 支持「语义事件」——命名良好的事件，准确地告诉你发生了什么变化，比如 response.output_text.delta。
名称之争
关于名称：Responses 显然与 HTTP Responses 冲突。
但 OpenAI 团队强烈认为这个名称是优雅和描述性的完美平衡。在日常使用中，我们都会说「模型的响应是什么？」。
他们考虑过的其他名称包括：Tasks、Generations、Messages、Interactions、Conversations 等等。
但最终还是选择了 Responses.
更多细节改进
Atty 还提到了许多其他改进：
-
SDK 有 response.output_text可以快速获取文本！ -
n选项消失了；不再需要completion.choices[0].message！ -
finish_reason消失了；status表达能力更强。 -
函数调用和结构化输出默认为 strict。
网友 John(@johngonzalezv) 也对此提出了疑问：
我喜欢 n choices，因为有时模型输出会变化。这是一种获取不同结果的策略，无需增加输入令牌。现在我该如何获得类似的功能？
Chat Completions 的未来
尽管推出了新 API，Chat Completions 并不会消失。它是成千上万企业的主力，OpenAI 承诺将在未来几年继续支持新模型和功能。
他们的首要责任是为客户提供稳定可靠的 API，这一点永远不会改变。
API 设计哲学
OpenAI 的 API 设计哲学值得单独写一篇博客，但他们有一套指导原则：
提供能力，而非抽象。
简单的事情应该简单，复杂的事情应该可能。
他们最喜欢的是来自 @sbensu 的「API 即梯子」理念——
好的 API 就像梯子：付出一点努力，就能获得回报。
链接（非常值得一读）：https://blog.sbensu.com/posts/apis-as-ladders/
Responses 从一开始就秉持这一理念设计。
幕后英雄
Responses 背后的团队成员包括：
@stevendcoffey、@nikunjhanda、Rasmus、@brianyu8、Wei、@zedlander、Gireesh、Bo、Baishen、Prashanth、Erin、@IshaanSingal、@kevinwhinnery、@liodikas
以及整个 OpenAI API 团队。
Atty 表示，在 OpenAI API 团队工作是一种真正的特殊权利，因为他们能够服务于所有开发者——那些构建行业未来的杰出开发者。
最后，Atty 感谢了大家对他们业务的信任和指引。
看完 Atty Eleti 的分享，网友们纷纷点赞，表示「非常棒！」。
zaumai(@z4um41) 提出了思考：
Responses API 看起来很强大，但我很好奇这会如何塑造关于 AI 代理的讨论。当我们将 API 描述为「代理原语」并使用「先思考再说话」这样的语言时，我们是否无意中强化了一种类别错误？复杂的工具编排与人类代理性背后的现象学基础之间存在有意义的区别。我们如何设计技术语言来保持这种区别，同时仍然传达能力？
而Mike(@OneGodel) 点赞并关心起性能问题：
太棒了，整个团队干得好！关于延迟怎么样？Assistants API 引入了大量开销，而 Completions 相比之下很轻量。新 API 在这两者之间处于什么位置？
BadTechBandit(@BadTechBandit) 则期待更多教程：
既然你们没有发布深度研究 API（😡），请做一个教程，介绍如何使用新的 Responses API 来构建它！说笑的，这对所有开发者来说都将非常棒。
EchoZ(@Echoooo0_0_) 对名称的选择表示赞赏：
喜欢「responses」这个名称，很有意义，代理超越了聊天和对话。response 也很通用，适用于各种任务和模态。
同时也提出疑问：
好奇为什么 parallel_tool_calls 默认为 true，人们经常使用并行工具调用吗？
Nick(@gonzaleznick) 则询问：
如果对话历史变长，你们有限制前面消息的方法吗？
想要开始使用 Responses API——
请访问：https://platform.openai.com/docs/quickstart?api-mode=responses
（文：AGI Hunt）