OpenAI Responses API 怎样保留多轮对话上下文

如果第二次请求只发送“继续刚才的话题”，模型却像第一次见面，通常不是 Responses API 不能做多轮对话，而是请求没有沿着同一个状态入口继续。实际开发中可以选两条路径：需要跨会话、设备或任务复用时使用 conversation；只是把相邻两次响应串起来时使用 previous_response_id。

官方地址：https://developers.openai.com/api/docs/guides/conversation-state

先按会话生命周期选择入口

把上下文保存看成“谁负责记住前文”会更容易。conversation 由服务端维护一个可复用的会话对象，后续请求只要继续传同一个 ID，就能在不同会话、设备或任务之间共享其中的 items。一个 item 可以是消息，也可以是工具调用或工具输出。

previous_response_id 则是响应链：第二个响应指向第一个响应，第三个响应再指向第二个响应。它适合聊天页面中紧挨着发生的上下文续接，代码更短，但应用仍需要保存最新的响应 ID，并决定链条何时切换。

用 conversation 保存跨会话上下文

下面的 Node.js 示例先创建会话，再把会话 ID 交给两次 Responses 请求。真实项目应把会话 ID 持久化到自己的用户或业务记录中；示例中的 ID 只演示数据关系。

import OpenAI from "openai";

const openai = new OpenAI();

// 创建一个可复用的会话对象，实际项目要保存 conversation.id
const conversation = await openai.conversations.create();

// 第一轮把用户问题写入这个会话
const first = await openai.responses.create({
  model: "gpt-6-astra", // 按项目可用模型替换
  conversation: conversation.id,
  input: "我在做一个多轮问答页面，先给出上下文保存方案。"
});

// 第二轮继续使用同一个会话，因此可以引用上一轮内容
const second = await openai.responses.create({
  model: "gpt-6-astra", // 两轮保持同一模型配置更容易排查问题
  conversation: conversation.id,
  input: "基于刚才的方案，再补充会话过期和成本边界。"
});

console.log(first.output_text);
console.log(second.output_text);

这段代码的关键不是变量名，而是两次请求都携带同一个 conversation。如果页面刷新后仍要接着聊，就从业务存储中取回该 ID；如果用户切换到另一条会话，则应换成另一条会话 ID，而不是把所有用户内容混在一起。

用 previous_response_id 串联相邻轮次

如果只需要在当前流程中继续上一轮响应，可以直接把第一轮的 response.id 放到第二轮的 previous_response_id。这种方式不需要先创建 conversation，但要把最新响应 ID 作为流程状态的一部分保存或传递。

import OpenAI from "openai";

const openai = new OpenAI();

// 第一轮请求返回一个可供下一轮引用的响应 ID
const first = await openai.responses.create({
  model: "gpt-6-astra", // 按项目可用模型替换
  input: "请用三句话解释什么是上下文窗口。",
  store: true // 需要用 response.id 续接时保留响应对象
});

// 把上一轮 ID 传入，形成相邻响应链
const second = await openai.responses.create({
  model: "gpt-6-astra",
  previous_response_id: first.id,
  input: [{
    role: "user",
    content: "把刚才的解释改写成给新手看的版本。"
  }],
  store: true
});

console.log(second.output_text);

这条链适合“上一问—追问—再追问”的短流程。若需要长期保留多条消息、工具调用和工具输出，或者要在不同任务中复用同一上下文，使用 conversation 更直观。两种方式不要在同一个请求里混用成含义不清的双重状态来源。

处理指令、存储和上下文窗口边界

最容易被忽略的边界是 instructions。官方说明指出，使用 previous_response_id 时，上一轮的 instructions 不会自动带到下一轮。因此，角色设定、输出格式、合规约束等需要持续生效的内容，应在每次请求里重新提供，或由应用在组装请求时统一注入。

还要区分“能继续引用”与“没有成本”。即便使用 previous_response_id，响应链中之前的输入 token 仍会计入输入用量；对话越长，请求的上下文窗口压力和费用都可能上升。工程上可以在业务层设置最大轮数，或在需要时启动一条新的会话，并把真正必要的摘要作为新上下文。

存储策略也要先想清楚：响应对象默认有保存期限，而 Conversation 及其中的 items 不受同一个 30 天响应 TTL 约束。不要仅凭“有 response.id”就假设所有数据都会永久可取；需要长期业务记录时，仍应保存自己的会话关联信息，并按隐私和删除策略管理用户内容。

常见问题

只传 previous_response_id，为什么角色设定失效了？

因为上一轮的 instructions 不会自动继承。把需要持续生效的开发者指令随新请求再次传入，不要只依赖响应链。

conversation 和 previous_response_id 能同时传吗？

它们代表两种上下文来源。实际代码应选定一种主状态模型，避免让会话对象和响应链同时决定前文来源，造成排查困难。

归纳起来，短对话续接优先保存最新的 response.id，跨会话复用优先保存 conversation.id；无论选哪种方式，都要把指令重发、token 用量、上下文窗口和数据留存作为同一个工程问题处理。