OpenAI Responses API 迁移时旧状态模型如何处理

如果你的系统还把 Assistants API 的 Thread ID 当成唯一会话状态，迁移到 Responses API 时最容易踩的坑不是改接口名，而是历史数据归属变了。Assistants API 已在 2026 年 8 月 26 日停止服务，旧 Thread 消息接口不能再作为迁移时的读取入口。正确做法是先使用应用自己保存的消息，转换为 Responses 的输入项，再创建 Conversation 或按需串联 Response。

官方迁移文档：https://developers.openai.com/api/docs/assistants/migration

旧状态不会因为换成 Responses API 就自动出现在新会话里。把历史消息掌握在自己的存储中，长期会话使用 Conversations，短链路续问使用 previous_response_id，并单独保存模型、提示词版本和业务会话的映射关系。

先处理历史归属：旧 Thread 不是新 Conversation

迁移前先列出每个业务会话的用户消息、助手消息、图片输入、工具调用结果和时间顺序。若这些内容只存在 OpenAI 的旧 Thread 中，迁移窗口已经结束后就没有可靠的旧接口可供读取；若应用曾同步保存消息，就应以自己的记录为准重建。

可以把旧对象按职责理解，而不要把 ID 直接互换：

历史消息应先转成输入项，再启动新会话

历史转换时至少区分 user 和 assistant，把文本放入对应的输入内容类型；图片输入则保留原始可访问地址或文件引用。迁移脚本应记录原 Thread ID、目标 Conversation ID、最后一条消息时间和转换失败原因，便于重跑而不重复导入。

import OpenAI from "openai";

const client = new OpenAI();

// 历史消息来自应用自己的数据库，不再读取已经停止服务的旧 Thread 接口。
const legacyMessages = await loadMessagesFromDatabase("biz-session-42");

const items = legacyMessages.map((message) => ({
  // 只把旧角色映射成 Responses 可理解的输入角色。
  role: message.role === "assistant" ? "assistant" : "user",
  content: [{
    // 迁移文本时保留原顺序，避免把多轮上下文拼成一段摘要。
    type: message.role === "assistant" ? "output_text" : "input_text",
    text: message.text,
  }],
}));

// 创建后把新 ID 与业务会话绑定，后续请求只使用这个映射。
const conversation = await client.conversations.create({ items });
await saveConversationLink("biz-session-42", conversation.id);

// 新消息走 Responses API；这里不把 conversation 和 previous_response_id 混用。
const response = await client.responses.create({
  model: "gpt-5.5",
  conversation: conversation.id,
  input: [{ role: "user", content: "请继续处理这条业务请求。" }],
});

console.log(response.output_text); // 只打印可展示文本，工具 Item 另行记录。

示例只表达迁移边界：真实项目需要为图片、工具调用、失败重试和重复导入增加分支。尤其不要把数据库中的助手输出重新包装成用户输入，否则后续模型会失去原有角色语义。

Conversation 与 previous_response_id 怎么选

Responses API 有两种常见的状态管理方式。Conversation 是一个可持续的项目级会话容器，输入项和输出项会归档到其中，适合客服会话、审核任务和需要跨进程恢复的业务。previous_response_id 则是把下一次 Response 接到上一次 Response 后面，适合一次任务中的短链路追问、分支实验或临时确认。

两者不能在同一次请求中同时使用。使用 previous_response_id 时，前一响应的 instructions 不会自动带到下一次请求，所以模型、提示词版本和租户策略不要只藏在上一轮。官方文档还提示，响应对象默认保存 30 天；Conversation 中的项目不受这个 30 天 TTL 约束。即便沿用 previous response 链，之前的输入 token 仍会计费，不能把它当成免费缓存。

迁移后的兼容检查要看三个结果

第一，用一段已脱敏的历史消息回放，确认角色顺序、图片输入和工具结果没有错位。第二，连续发送两条新消息，分别验证 Conversation 续接和 previous response 续接，确认业务侧拿到的是同一条会话链。第三，人为制造上下文过长、Response ID 不可取回和重复导入，检查系统是否能回退到自己的消息存储并重新组装输入。

如果只是新项目，不必再设计 Assistants、Thread、Run 三层对象；直接让业务会话、Prompt 版本、Conversation、Response 和 Item 各自承担清晰职责，后续切换模型或工具时会更容易追踪。

常见问题

旧 Assistant ID 能直接当作 Prompt ID 使用吗？

不能。迁移指南要求从控制台或新的配置流程创建 Prompt，并重新确认模型、指令、工具和版本；旧 ID 不是新资源的同义字段。

没有保存旧 Thread 消息怎么办？

先盘点业务日志、客服记录、缓存归档和导出文件。若历史确实没有留存，不要编造上下文，改为从新的用户输入建立 Conversation，并在系统中记录迁移缺口。

previous_response_id 适合永久保存聊天记录吗？

不适合单独承担永久记录职责。它解决的是响应之间的续接；长期可审计会话仍应使用 Conversation 或自己的消息存储，并设计删除、脱敏和归档策略。