随着 GPT-5 的发布，我们想进一步介绍集成它的最佳方式：Responses API，以及为什么 Responses 是为推理模型和未来的智能体应用量身打造的。
每一代 OpenAI API 的构建都围绕着同一个问题： 怎样才能让开发者以最简单、最强大的方式与模型交互？
我们的 API 设计始终以模型自身的工作方式为依据。最初的 /v1/completions 端点很简单，但也有局限：您给模型一段提示，它只会顺着您的思路续写。通过少样本提示等技术，开发者可以尝试引导模型输出 JSON、回答问题等，但这些模型的能力远不及我们今天习以为常的水平。
随后，RLHF、ChatGPT 和后训练时代到来了。模型突然不再只是续写您写到一半的文字，而是像对话伙伴一样做出 回应 。为了跟上这一变化，我们构建了 /v1/chat/completions（仅用一个周末就完成的故事广为人知）。通过提供 system、user、assistant 等角色，我们搭建了基础框架，让开发者能够快速构建带有自定义指令和上下文的聊天界面。
我们的模型不断进步，很快就开始能看、能听、能说。2023 年末的函数调用功能成为我们最受欢迎的功能之一。同一时期，我们还推出了 Assistants API 测试版，这是我们首次尝试打造一个完整的智能体接口，提供代码解释器和文件搜索等托管工具。一些开发者喜欢它，但相比 Chat Completions，它的 API 设计限制较多，上手也更困难，因此始终未能得到广泛采用。
到了 2024 年末，统一这些能力的必要性已经很明显：我们需要一个像 Chat Completions 一样易于上手、像 Assistants 一样强大，同时又专为多模态模型和推理模型设计的接口。于是，/v1/responses 应运而生。
/v1/responses 是一个智能体循环
Chat Completions 为您提供了一个简单的按轮次交互的聊天接口。Responses 则提供了一个用于推理和行动的结构化循环。可以把它想象成与侦探合作：您提供证据，侦探展开调查，可能会咨询专家（工具），最后向您汇报结果。侦探会在各个步骤之间保留私人笔记（推理状态），但绝不会把笔记交给委托人。
这正是推理模型真正发挥优势的地方：Responses 会在这些轮次之间保留模型的 推理状态 。在 Chat Completions 中，推理会在两次调用之间丢失，就像侦探每次走出房间都会忘记线索。Responses 则让笔记本始终摊开，逐步展开的思考过程得以延续到下一轮。这带来了基准测试成绩的提升（TAUBench +5%）、更高的缓存利用率和更低的延迟。
Responses 还可以返回多个输出条目：不仅包含模型 说了什么，还包含它 做了什么。您可以获得工具调用、结构化输出、中间步骤等记录。这就像既拿到了写好的文章，也拿到了草稿纸上的演算过程，有助于调试、审计和构建更丰富的用户界面。
{
"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": []
}
} {
"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"
},通过托管工具提升抽象层级
在函数调用推出初期，我们注意到一个重要的使用模式：开发者不仅用模型调用 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 为基础持续开发。