Responses API（OpenAI API 新基础组件）的设计故事 by OpenAI 技术团队 Atty Eleti

「两年前，我们与 GPT-3.5 Turbo 一同推出了 Chat Completions。 Rachel Lim 和我仅用一个周末就完成了它的构建（毫不夸张）：它于周五设计完成，周二便正式发布。

如今，它已成为事实上的行业标准，为数以万计的应用程序提供动力，并被所有主要模型提供商所采用。

同年晚些时候，我们发布了 Assistants API 的测试版，这是我们构建代理基础组件的第一版草稿。运行将在后台进行，根据需要调用工具。

许多开发者喜爱它，因为它易于上手（只需将 OpenAI 作为你的数据库！）并通过`file_search`工具内置了强大的 RAG 功能。

但自那时以来，许多事情已经发生了变化：如今的模型是多模态的（文本、图像、音频）、具备代理能力（调用一个或多个工具），并且在发言前会进行思考。

Chat Completions 并非为此设计；它是无状态的（迫使你传递大量的图像和音频数据），不支持工具，并且存在许多可用性问题（特别是流式处理很难正确实现）。

Assistants 支持工具，但回想起来，它过于抽象了。你需要了解半打概念才能上手，而后台处理意味着它默认就很慢。

我们知道大家都想要底层功能，但 API 的形式成了阻碍。

...（注：后面介绍 Responses API 的核心功能，太技术向了，就不搬了）」

OpenAI 的 API 设计理念包括：

- Ship capabilities, not abstractions（
交付能力，而不是抽象）

- 简单的事情应该简单，复杂的事情应该可能。

- 但 Atty Eleti 最喜欢的无疑是 Sebastian Bensusan 提出的“API 即阶梯”理念。优秀的 API 如同阶梯，让你投入些许努力，便能收获相应回报。

链接：http://t.cn/A6BGdGOs