Responses API（TypeScript）导读

如果你准备把新接入统一到更稳定的输出契约上，Responses 通常是更合适的起点。

Responses API 是更适合新接入的路径之一。它的重点不是“名字更新了”，而是 输出结构、流式事件、tool calling 和多轮延续都更统一。对 TypeScript 团队来说，先把 client.responses 跑通，后面再接结构化输出、联网搜索和更复杂的多步工作流，会更容易保持一致。

最值得先记住的 3 个方法

Name	Type	Required	Description
client.responses.create	function	Required	非流式请求。适合大多数后台任务、同步生成和结构化输出。
client.responses.stream	function		流式请求。适合 UI 实时显示和逐段消费事件。
client.responses.retrieve	function		按 response ID 取回结果。适合异步工作流和故障追查。

最小请求

create

const response = await client.responses.create({
  model: "openai/gpt-4.1-mini",
  input: "把今天的站点报警总结成 3 条 bullet。",
});

console.log(response.output_text);

先看这几个参数

Name	Type	Required	Description
model	string	Required	目标模型标识。新接入建议先从稳定的默认模型开始。
input	string \| array	Required	输入文本或更细粒度的 item 数组。复杂多模态与多轮延续都走这里。
tools	array		工具定义。你准备接 tool calling 时，Responses 比 chat 更自然。
stream	boolean		是否返回流式事件。UI 或 agent 回路才需要开。
previous_response_id	string		延续上一轮 response，避免你自己拼接越来越长的对话上下文。

什么时候该优先选 Responses

如果这是新系统、你后面会接 tools、structured outputs、联网搜索或者更复杂的多轮状态， Responses 通常值得优先采用。Chat 更适合兼容已有客户端。

最容易犯的错

text

1. 把 Responses 当成只是 "chat 的别名"。
2. 只看 output_text，不理解完整 output / event 结构。
3. 在需要工具和 schema 的场景里，仍然优先走旧 chat 路径。
4. 已经需要多轮延续，却还在客户端手工拼长对话。

下一步

Create Responses 导读

中文导读

如果你想直接看 HTTP 契约、流式事件和 output 结构，这页更直接。

继续阅读

结构化输出导读

中文导读

很多团队选择 Responses，是因为它更适合配合 schema 和 tools 使用。

继续阅读

工具调用导读

中文导读

如果你下一步要在 Responses 里接 tools，这页更值得连着看。

继续阅读

TypeScript SDK 概览