Responses API vs Chat Completions：该迁移了吗

Responses API 是 OpenAI 的当前主力接口：input 字段、默认状态存储、内置工具体系；Chat Completions 是上一代接口（messages 字段），官方定位为仍受支持但新项目不推荐。两者的迁移关系类似"主线与维护分支"。这个决策在本周变得紧迫了一个量级：Assistants API 已于 2026-08-26 关停——OpenAI 的接口版图正在收敛到 Responses 一条主线。本文按状态管理、工具定义、内置能力逐项对比，并给出按用户流渐进迁移的路径。

1. 一张表看懂两代接口

2. 官方口径：supported，但不是推荐

官方对比指南的原话值得逐字读："Chat Completions remains supported, Responses is recommended for all new projects." 以及 "Chat Completions remains supported, so you can migrate one user flow at a time."

翻译成决策语言：不存在"下周就停"的强制 deadline，但新能力全部长在 Responses 侧——继续用 Chat Completions 的成本不是"会坏"，而是"新东西都没有"。Assistants API 的关停（8-26）则给出了另一面的参照：旧接口的生命周期确实有限，只是官方给足了缓冲与迁移工具。

3. 状态管理：最大的范式差异

Chat Completions 是无状态的：每轮把完整历史重传一遍，上下文管理是你的事。Responses 把这件事产品化了：

• 默认存储（store: true）：对话状态由 API 侧维护，跨轮保留推理与工具上下文。
• previous_response_id：后续请求引用 earlier 响应，官方描述为"更高准确率的连续推理结果"。
• 可控：不想被存储就显式关闭，数据保留在 API 控制里管理。

对你的代码意味着：会话历史、token 累计、工具上下文管理这些自建模块，迁移后可以大幅简化——但数据驻留有硬性要求的团队要评估默认存储的合规面，按请求关闭或用区域处理能力兜底。

4. 内置工具：迁移收益最大的部分

Responses 侧的内置工具清单：web search、file search、computer use、code interpreter、remote MCP。

这些能力在 Chat Completions 时代要么不存在、要么靠自建胶水层（搜索接第三方、代码执行自建沙箱、MCP 自己串协议）。如果你的应用里有这类手写模块，迁移的收益不是"接口更现代"，而是直接删掉一整层自建工程，换成配置项。

5. 渐进迁移路径

官方建议"按用户流逐条迁移"（migrate one user flow at a time），落地分四步：

1. 盘点：列出所有 Chat Completions / Assistants 调用点，按风险与流量排序。
2. 选一条低风险读流量：切到 Responses 验证——字段改 input、prompt 原样搬、确认输出一致。
3. 改写工具定义：函数声明按 Responses 格式重写（官方明确两代不同，不能只换字段名）。
4. 逐条收尾：写流量与复杂工具调用分批迁移，每条独立回滚开关。

Assistants API 的存量代码没有渐进的 luxury——它已于 8-26 关停，直接按官方迁移指南切 Responses / Conversations API。

常见问题

1. Chat Completions 还能用吗？会被强制下线吗？

能用。官方对比指南原话：Chat Completions remains supported, Responses is recommended for all new projects——并且明确可以 migrate one user flow at a time。但"仍受支持"是维护态不是发展态：新能力（内置工具、状态存储）都在 Responses 侧，Assistants API 的先例说明旧接口的生命周期是有限的。

2. 迁移的最大改动是什么？

三处：字段从 messages 改为 input；状态管理从"自己存历史"改为可选的默认存储 + previous_response_id；工具定义按 Responses 的格式改写（官方明确两代函数定义方式不同）。逻辑层（prompt、业务代码）基本不动。

3. Responses 的默认状态存储是什么意思？

Responses 默认 store: true——对话状态由 API 侧维护，跨轮保留推理与工具上下文，后续请求可用 previous_response_id 引用 earlier 响应，得到更高准确率的连续推理。不想存就显式关掉，数据保留策略在 API 控制里管理。

4. 内置工具里有什么值得迁移的？

web search、file search、computer use、code interpreter、remote MCP——这些在 Responses 侧是内置工具，等于把"接搜索、跑代码、连 MCP"从自建工程变成配置项。你的应用里如果手写过这类胶水层，迁移的收益最大。

5. 从 Assistants API 迁过来的路径一样吗？

方向一致（都是去 Responses），但 Assistants 迁移更重：线程、运行、助手对象的状态模型需要重新映射到 Responses 的会话与工具体系，官方提供专门的迁移指南。Assistants 已于 2026-08-26 关停，这条迁移没有"再等等"的选项。

6. 怎么设计渐进迁移？

官方建议按用户流逐条迁移：先挑一条低风险的读流量切到 Responses 验证，再逐条搬；写流量与复杂工具调用放在最后。两代接口可以并存一段时间——这正是"迁移一条用户流"的含义。

下一步

• 结构化输出在新接口下的写法？读 《OpenAI 结构化输出完全指南：json_schema、strict 模式与常见报错》。
• 本周 Assistants 关停与 Sol 降价的完整背景？读 《OpenAI 生态第 42 周速报（2026-08-30 至 2026-08-31）：Assistants API 已关停 / Sol 降价确认 / 转写模型弃用》。
• 从零开始上手 Responses API？读 《OpenAI API 入门：第一个 GPT-5.6 调用详解》。