我们为何构建 Responses API

随着 GPT-5 面世，我们希望提供更多关于最佳集成方式的背景信息，即 Responses API，以及为什么 Responses 是为推理模型和智能体未来量身打造的。

每一代 OpenAI API 都围绕同一个问题构建：开发者与模型对话的最简单、最强大的方式是什么？

我们的 API 设计始终以模型本身的工作方式为指导。最初的 /v1/completions 端点简单但功能有限：你给模型一个提示，它就简单地完成你的想法。通过少样本提示（few-shot prompting）等技术，开发者可以尝试引导模型执行诸如输出 JSON 和回答问题等操作，但这些模型的能力远不及我们今天所习惯的水平。

随后迎来了 RLHF、ChatGPT 和后训练时代。突然间，模型不再只是完成你写了一半的散文——它们像对话伙伴一样回应。为了跟上步伐，我们构建了 /v1/chat/completions（仅用一个周末就完成了）。通过赋予 system、user、assistant 等角色，我们提供了脚手架，使开发者能够快速构建带有自定义指令和上下文的聊天界面。

我们的模型不断进步。很快，它们开始能看、能听、能说。2023 年底的函数调用（function-calling）成为我们最受欢迎的功能之一。大约在同一时间，我们以测试版形式推出了 Assistants API：这是我们首次尝试构建完全智能体化的接口，配备代码解释器和文件搜索等托管工具。一些开发者喜欢它，但由于 API 设计相对于 Chat Completions 存在局限且难以采用，它从未获得大规模普及。

到 2024 年底，我们显然需要一种统一方案：像 Chat Completions 一样平易近人，像 Assistants 一样强大，同时专为多模态和推理模型而打造。于是 /v1/responses 应运而生。

`/v1/responses` 是一个智能体循环

Chat Completions 提供了一个简单的轮流对话界面。而 Responses 则为你提供了一个用于推理和行动的结构化循环。可以把它想象成与一名侦探合作：你给他们证据，他们进行调查，可能会咨询专家（工具），最后向你汇报。侦探在各个步骤之间保留他们的私人笔记（推理状态），但绝不会将其交给客户。

而这正是推理模型真正大放异彩的地方：Responses 在这些轮次之间保留了模型的推理状态。在 Chat Completions 中，推理内容会在调用之间被丢弃，就像侦探每次离开房间都会忘记线索一样。Responses 则让笔记本保持打开状态；逐步的思维过程实际上会延续到下一轮。这体现在基准测试中（TAUBench +5%），也体现在更高效的缓存利用率和更低的延迟上。

responses vs chat completions

Responses 还可以输出多个输出项：不仅是模型说了什么，还有它做了什么。你会得到回执——工具调用、结构化输出、中间步骤。这就像既拿到了完成的文章，又拿到了草稿纸上的演算过程。对调试、审计和构建更丰富的 UI 非常有用。

{
  "message": {
    "role": "assistant",
    "content": "I'm going to use the get_weather tool to find the weather.",
    "tool_calls": [
      {
        "id": "call_88O3ElkW2RrSdRTNeeP1PZkm",
        "type": "function",
        "function": {
          "name": "get_weather",
          "arguments": "{\"location\":\"New York, NY\",\"unit\":\"f\"}"
        }
      }
    ],
    "refusal": null,
    "annotations": []
  }
}

Chat completions 每次请求发出一个 message。message 的结构存在局限：是 message 还是函数调用先出现？

{
    "id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",
    "type": "reasoning",
    "summary": [
      {
        "type": "summary_text",
        "text": "**Determining weather response**\n\nI need to answer the user's question about the weather in San Francisco. ...."
      },
  },
  {
    "id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",
    "type": "message",
    "status": "completed",
    "content": [
      {
        "type": "output_text",
        "text": "I\u2019m going to check a live weather service to get the current conditions in San Francisco, providing the temperature in both Fahrenheit and Celsius so it matches your preference."
      }
    ],
    "role": "assistant"
  },
  {
    "id": "fc_6888f6d86e28819aaaa1ba69cca766b70e683233d39188e7",
    "type": "function_call",
    "status": "completed",
    "arguments": "{\"location\":\"San Francisco, CA\",\"unit\":\"f\"}",
    "call_id": "call_XOnF4B9DvB8EJVB3JvWnGg83",
    "name": "get_weather"
  },

Responses 发出一个 polymophic Items 列表。模型采取的操作顺序清晰明了。作为开发者，你可以选择显示、记录或完全忽略其中的哪些内容。

借助托管工具向上层迈进。}]}

在函数调用的早期，我们注意到一个关键模式：开发者既用模型调用 API，也用它搜索文档存储以引入外部数据源——如今这被称为 RAG。但对于刚起步的开发者来说，从零构建检索管道是一项艰巨且昂贵的工作。通过 Assistants，我们推出了首批托管工具：file_search 和 code_interpreter，让模型能够执行 RAG 并编写代码来解决你提出的问题。在 Responses 中，我们更进一步，加入了网络搜索、图像生成和 MCP。而且由于工具执行是通过代码解释器或 MCP 等托管工具在服务端进行的，你无需将每次调用都回传到自己的后端，从而确保更好的延迟和往返成本。

安全地保留推理

那么，为什么要费这么大劲来混淆模型的原始思维链（CoT）呢？直接暴露 CoT 并让客户端像处理其他模型输出一样处理它们，不是更简单吗？简短的回答是，暴露原始 CoT 存在诸多风险：例如幻觉、在最终响应中不会生成的有害内容，以及对 OpenAI 而言，会带来竞争风险。

去年年底我们发布 o1-preview 时，我们的首席科学家 Jakub Pachocki 在博客中写道：

我们相信，隐藏的思维链为监控模型提供了独特的机会。假设它是忠实且可读的，隐藏的思维链使我们能够“读懂”模型的心思并理解其思考过程。例如，未来我们可能希望监控思维链中是否存在操纵用户的迹象。然而，要使其发挥作用，模型必须能够自由地以未经修改的形式表达其想法，因此我们不能将任何策略合规性或用户偏好训练到思维链上。我们也不希望将未对齐的思维链直接展示给用户。

Responses 通过以下方式解决这个问题：

在内部保留推理，加密并隐藏于客户端。
允许通过 previous_response_id 或推理项安全续接，而不暴露原始 CoT。

为什么 `/v1/responses` 是最佳构建方式

我们将 Responses 设计为有状态、多模态且高效的。

智能体工具使用：Responses API 让你能够轻松地利用文件搜索、图像生成、代码解释器和 MCP 等工具来增强智能体工作流。
默认有状态。对话和工具状态会被自动跟踪。这使得推理和多轮工作流变得简单得多。通过 Responses 集成的 GPT-5 在 TAUBench 上的得分比 Chat Completions 高出 5%，这纯粹是得益于保留的推理。
从底层开始的多模态。文本、图像、音频、函数调用——都是一等公民。我们没有将模态生硬地附加到文本 API 上；我们从第一天起就设计了有足够房间的房子。
更低成本，更佳性能。内部基准测试显示，与 Chat Completions 相比，缓存利用率提高了 40–80%。这意味着更低的延迟和更低的成本。
更佳设计：我们从 Chat Completions 和 Assistants API 中学到了很多，并在 ResponsesAPI 和 SDK 中做了一些提升易用性的小改进，包括
- 语义流式事件。
- 内部标记的多态性。
- SDK 中的 output_text 辅助函数（不再需要 choices.[0].message.content）。
- 更好地组织多模态和推理参数。

那 Chat Completions 呢？

Chat Completions 不会消失。如果它对你有用，就继续使用它。但如果你想要持久的推理、原生的多模态交互，以及一个不需要胶带修补的智能体循环——Responses 就是前进的方向。

展望未来

正如 Chat Completions 取代了 Completions，我们期望 Responses 成为开发者使用 OpenAI 模型构建应用的默认方式。它在你需要时足够简单，在你想要时足够强大，并且足够灵活，能够应对下一个范式带来的任何挑战。

这就是我们未来几年将基于其构建的 API。

/v1/responses 是一个智能体循环