Responses

OpenAI Responses API，用于创建模型响应。与对话补全相比，它支持通过 previous_response_id 串联有状态多轮对话、更细粒度的推理控制，并采用不同的输出与计量结构。

这个接口是做什么的：和 Chat Completions 的核心区别是「谁来记住对话历史」。Chat Completions 要求你每次把完整对话原样发一遍；Responses 允许你只传 previous_response_id（上一轮响应的 ID），服务端会记住上下文并自动接续，不需要你自己攒历史消息数组。适合需要多轮持续对话、或者要用到 Responses 独有工具生态（如内置的网页搜索、代码执行等）的场景；如果只是简单问答或已经有一套基于 messages 的成熟代码，用 Chat Completions 通常更省心。

鉴权：在请求头携带 Authorization: Bearer <令牌>，详见鉴权与令牌。

与 Chat Completions 的差异

适用场景：需要服务端串联对话状态、使用 Responses 原生工具生态，或对接只支持 Responses 协议的模型。其余场景用 Chat Completions 即可。两个端点的字段不可混用（如 messages 不能发给本端点）。

请求参数

思考档位说明

reasoning.effort 的档位、默认值与支持范围因模型供应商而异。本文档所列的档位语义来源于 OpenAI 官方协议规范，并非适配所有供应商；不同供应商对同一档位名的解释或支持的档位子集可能不同。本端点对思考参数做透传，原样发给上游模型——请以你实际调用的模型的官方参考文档为准，不要跨供应商照抄档位设置。各档含义与选择建议见对话补全的 reasoning_effort 参数说明。

请求示例

curl https://api.jimu.chat/v1/responses \
  -H "Authorization: Bearer $JIMU_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "input": "你好",
    "instructions": "你是一个简洁的助手",
    "max_output_tokens": 1024
  }'

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["JIMU_API_KEY"],
    base_url="https://api.jimu.chat/v1",
)

resp = client.responses.create(
    model="gpt-5.5",
    input="你好",
    instructions="你是一个简洁的助手",
    max_output_tokens=1024,
)
print(resp.output_text)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.JIMU_API_KEY,
  baseURL: "https://api.jimu.chat/v1",
});

const resp = await client.responses.create({
  model: "gpt-5.5",
  input: "你好",
  instructions: "你是一个简洁的助手",
  max_output_tokens: 1024,
});
console.log(resp.output_text);

响应结构

{
  "id": "resp_0f9583835d5e5762016a68bef03a1c8199a90d35cdc6336b8a",
  "object": "response",
  "created_at": 1785249520,
  "status": "completed",
  "model": "gpt-5.5",
  "output": [
    {
      "id": "msg_0f9583835d5e5762016a68bef137ec81998de27f2fbe177b2a",
      "type": "message",
      "status": "completed",
      "role": "assistant",
      "content": [
        { "type": "output_text", "text": "Hi! How can I help you today?", "annotations": [] }
      ]
    }
  ],
  "reasoning": { "effort": "medium", "summary": null },
  "tool_choice": "auto",
  "tools": [],
  "usage": {
    "input_tokens": 7,
    "input_tokens_details": { "cache_write_tokens": 0, "cached_tokens": 0 },
    "output_tokens": 13,
    "output_tokens_details": { "reasoning_tokens": 0 },
    "total_tokens": 20
  }
}

关键字段说明：

• status：响应状态，如 completed、incomplete、failed。incomplete 时 incomplete_details 给出原因（如达到 max_output_tokens）。
• output：输出项数组。文本回复是 type: "message" 的项，其 content 内含 output_text 片段；工具调用等其他 item 类型（如 function_call）也会出现在此数组中。
• usage：token 计量。权威字段为 input_tokens / output_tokens / total_tokens。

流式事件

设置 "stream": true 后，响应为 SSE 事件流。与 Chat 的 chunk 模式不同，本端点每个事件带 event: 行标明语义类型，典型序列（实测）：

event: response.created
event: response.in_progress
event: response.output_item.added
event: response.content_part.added
event: response.output_text.delta      ← 增量文本，可能多次
event: response.output_text.done
event: response.content_part.done
event: response.output_item.done
event: response.completed

以上是纯文本生成的典型序列。平台透传全部事件流，工具调用、联网搜索等场景还会出现相应的其他事件类型；客户端应忽略未识别的事件类型，不要当作错误处理。

• 增量文本在 response.output_text.delta 事件中：解析事件 data JSON 后读取顶层 .delta 字段，拼接即为完整输出。
• response.completed 是终态事件，其 data 是一个信封对象：{"type":"response.completed","response":{完整响应对象},"sequence_number":N}——完整响应（含 output、usage）位于 data.response 下，不是 data 顶层，注意解析路径。
• 本端点的流不以 data: [DONE] 收尾——收到 response.completed 即表示结束。这与 Chat Completions 流式末尾的 [DONE] 标志不同，复用同一套 SSE 解析代码时不要依赖 [DONE] 作为唯一结束条件。

压缩长对话

对话变长后，可用 POST /v1/responses/compact 对历史做压缩（compaction），降低后续请求的上下文占用。