AIREITER距离 OpenAI 在 2026 年 8 月 26 日关闭 Assistants API 已经不远，最危险的误区就是把这次迁移当成简单的改名。OpenAI 早在 2025 年 8 月 26 日的Assistants API 下线说明和弃用公告中提前整整一年发出了通知，替代方案是 Responses API。对象名称看起来可以一一对应，但底层编排方式并没有这么简单；甚至有开发者完全照着官方指南迁移，最终仍然把故障带进了生产环境。下面就来看看哪些功能会消失、这些映射掩盖了哪些变化，以及在剩余时间有限的情况下应该怎么做。
2026 年 8 月 26 日之后，哪些会失效，哪些还能用
截止日期之后，Assistants 的所有端点系列都会返回错误，包括 /v1/assistants、/v1/threads、线程消息、runs 和 run steps，以及仍然发送 OpenAI-Beta: assistants=v2 请求头的调用。通过 API 访问 Assistant 配置和线程历史也会随之中断。
不过，和 Assistants 集成相关的资源并不会全部一起消失：
| 2026 年 8 月 26 日下线 | 仍可使用 |
|---|---|
/v1/assistants CRUD 端点 | Vector stores 和已上传文件，可通过 Responses 的文件搜索复用 |
/v1/threads 及线程消息 | Chat Completions API（不在本次下线范围内） |
| Runs 和 run steps | Responses API 和 Conversations API |
OpenAI-Beta: assistants=v2 工作流 | Realtime API |
OpenAI 自己的弃用追踪页面也将 Responses 和 Conversations 列为指定替代方案：
四组对象映射，以及会改变架构的两个细节
OpenAI 的迁移指南将 Assistants 中的四个核心概念对应到了 Responses 体系：
| Assistants API | 替代方案 | 实际变化 |
|---|---|---|
Assistants | Prompts | 配置转移到由控制台创建、支持版本管理的对象中 |
Threads | Conversations | 存储的是通用 item，包括消息、工具调用和工具输出，而不只是消息 |
Runs | Responses | 创建 run、轮询、获取结果的流程合并为一次 responses.create 调用 |
Run steps | Items | 一种联合类型，覆盖消息、函数调用和调用结果 |
流程合并在官方示例中体现得很直观：使用 gpt-4.1 的已完成 run 报告 34 个 prompt tokens 和 130 个 completion tokens，而使用 gpt-5.5 的已完成 response 报告 17 个 input tokens 和 150 个 output tokens。工作负载形态相近，字段名称却已经不同。
第一个容易被忽略的细节就是这些字段改名。凡是依赖旧 usage 字段的计费看板和请求解析器，都可能在不报错的情况下悄悄失效：
| Assistants 字段 | Responses 字段 |
|---|---|
usage.prompt_tokens | usage.input_tokens |
usage.completion_tokens | usage.output_tokens |
max_completion_tokens / max_prompt_tokens | max_output_tokens |
truncation_strategy | truncation |
object: "thread.run" | object: "response" |
第二个细节则是架构层面的：Prompts 只能在控制台创建，不能通过 API 创建。这会直接影响那些按客户、工作区或文档集合动态创建 Assistant 的系统。官方指南也建议，在长期集成中采用 prompt 对象之前，先确认其弃用时间表，因为可复用的 prompt 对象本身也存在下线风险。更稳妥的做法是把指令、工具 Schema 和模型选择保存在自己的代码仓库中，并在每次请求时传入。至于线程历史，OpenAI 的表述很直接：“我们不会提供将 Threads 迁移到 Conversations 的自动化工具。”
三个内置工具如何迁移
Assistants 的每个内置工具在 Responses 中都有对应落点，但不少原本由平台负责的工作会转移到你的应用：
| Assistants 工具 | 在 Responses 中的实现 | 现在由应用负责的部分 |
|---|---|---|
| 文件搜索 | Vector stores 会保留；在每次请求的工具定义中传入 vector_store_ids | 在每次调用前解析正确的 store ID |
| 代码解释器 | 使用 type: "auto" 配置容器 | 容器生命周期管理 |
| Functions | 移除嵌套的 function 键；name、description 和 parameters 上移一层 | 工具循环：执行调用、携带匹配的 call_id 返回结果，并决定是否继续循环 |
对于多租户应用来说，文件搜索这一行带来的变化最容易被低估。过去，每个租户对应的 vector store 通常在 Assistant 对象创建时绑定；现在，收到会话请求后，应用必须先识别所属租户，再解析出正确的 store ID，随后才能发起请求。
已经完成迁移的团队遇到了什么问题
OpenAI 给出的理由是 Responses 已经实现了功能对等。但下面这些迁移经历说明，对等主要体现在对象层面，底层仍然需要进行真正的重构。一位多租户聊天机器人 SaaS 的开发者在 r/aiagents 分享了为期两周的迁移过程；即使认真研读官方指南，问题仍然出现：
我不得不把每个可选字段都改造成
["type", "null"]，这感觉更像是在绕过类型系统。——u/aidenclarke_12
严格工具 Schema 要求可选属性声明为可空，同时仍然必须放进 required 数组。因此 Schema 会变得更复杂，所有默认“缺失就代表不存在”的处理逻辑也都需要重新检查。这位开发者还指出了更深层的变化：
真正的架构变化在于 vector store 的接入方式。——u/aidenclarke_12
流式传输是第二个容易无声破坏的部分。Assistants 的 run 流式处理不能直接套用到 Responses，必须改写为基于类型化服务器推送事件的实现，例如 response.created、response.output_text.delta、response.completed，以及 response.function_call_arguments.delta / .done。新的工具调用事件结构和明确的完成事件都需要单独处理，相关事件名称可以参考这篇迁移报道。SSE 代理和客户端处理器都要重写，重连逻辑也不能遗漏。
第三个问题来自生态适配速度，而不是 API 本身：
Responses API 已经发布很久了，但仍然有不少框架和 SDK 不支持它。——u/zhlmmc
如果你的技术栈依赖某个仍然假设 Threads/Runs 模型存在的智能体框架，也就是 u/zhlmmc 遇到的那类兼容性问题，那么除了修改自己的胶水代码，还要为框架这一层预留时间。
状态管理怎么选：链式调用、Conversations 还是手动重放
在 Responses 中维持多轮上下文主要有三种方式，但它们并不能互相替换：
| 策略 | 适合场景 | 需要注意 |
|---|---|---|
previous_response_id | 最简单的链式调用，改动最少 | 之前的上下文仍会计入可计费输入 |
| Conversations API | 最接近 Threads 的方案，由服务端保存历史 | 历史回填需要自行实现，没有厂商工具 |
手动重放，store: false | ZDR 和严格数据保留要求 | 所有状态由你负责；推理 item 也必须继续传递 |
对于历史记录，OpenAI 建议按以下顺序转换旧线程：
- 按升序列出线程中的消息。
- 将每条用户文本消息转换为
input_text。 - 将每条助手文本消息转换为
output_text。 - 将图片 URL 内容转换为
input_image，同时保留image_url和detail。 - 使用转换后的
items创建 Conversation。
角色映射出错会带来一个很具体的问题：模型会把自己过去的回答当成新的用户指令来理解。除非传入 store: false，否则存储的 response 默认 TTL 为 30 天；截至 2026 年 7 月下旬，conversation 不受这一 response TTL 约束，OpenAI 也没有单独公布其保留时长，相关迁移报道对此有所记录。如果你的隐私说明承诺了明确的删除窗口，这一点尤其重要。
迁移会如何影响 Token 账单
这里有两个计费事实需要记住。
首先，previous_response_id 带来的是便利，而不是折扣。OpenAI 的Responses 迁移指南明确指出，response 链中之前的输入 tokens 仍会按照输入 tokens 计费。因此，如果不主动裁剪上下文，长对话的成本会线性增长。
其次，缓存输入的价格远低于未缓存输入：按照 2026 年 7 月的价格表，GPT-5.x 各档位的缓存输入价格大约是未缓存输入价格的十分之一；在 OpenAI 报告的内部测试中，Responses 的缓存利用率也比 Chat Completions 高 40–80%，汇总报道对此进行了整理。不过，在自己的监控面板验证之前，最好把这个利用率区间视为厂商数据。真正应该对比的是切换前后每个会话的实际 token 数。
如果你正好想借迁移机会重新评估 GPT-5.x 工作负载的定价，可以参考GPT-5.6 定价解析了解每 token 的计算方式；兼容 OpenAI 的端点，例如GPT-5.6 API 页面，也可以运行相同的 Responses 风格工作负载，方便直接比较。
按剩余时间制定迁移计划
还剩 1–6 天。先备份：使用 limit=100 列出 assistants 和 vector stores，拉取文件，并用 model_dump() 序列化 SDK 对象。一些强调先备份的迁移指南指出了一个硬限制：API 没有 list-threads 端点，因此你只能导出应用自己保存过 ID 的线程。随后通过功能开关切换：新会话立即走 Responses，旧线程则等用户重新打开时再按需回填。
还剩一周或更久。先挑一个低风险流程，完整迁移并跑通，再处理其他部分。重建工具循环，确认每个函数结果都带有匹配的 call_id；用基于事件类型的分支逻辑替换原有流式处理；最后将行为、延迟、token 使用量和错误率与 Assistants 基线进行对比，确认无误后再扩大流量。
已经超过截止日期。相关端点会返回错误，Assistant 配置也会从 API 一侧消失。届时只能依靠应用数据库和备份中的数据重建；vector stores 和文件仍可通过文件搜索访问。
这次迁移留下的核心取舍很明确：你不再依赖服务端管理轮询、截断和工具循环的完整生命周期，而是换成一次调用、但编排过程完全可见且可测试的模型。一位同时在两种 API 上完成过上线的开发者这样概括：
Responses API 恰好处在两者之间：它负责最繁重的工作，同时又保留了足够的灵活性，让你管理自己的功能。——u/landongarrison
OpenAI Assistants API 下线常见问题
Chat Completions API 也会下线吗？
不会。Chat Completions 不在 2026 年 8 月 26 日的下线范围内，OpenAI 的建议是将其按流程逐步迁移到 Responses，而不是要求在某个强制期限前一次性完成。
OpenAI 会自动迁移现有线程吗？
不会。官方迁移指南明确写道：“我们不会提供将 Threads 迁移到 Conversations 的自动化工具。”历史回填需要由应用自行编写代码，并按照上面的 item 转换流程完成。
2026 年 8 月 26 日之后还能继续使用 Assistants API 吗？
不能。Assistants、threads、messages、runs 和 run steps 在该日期之后都会返回错误，使用 assistants=v2 的工作流也不例外。请在截止日期前导出所有需要保留的数据。
存储的 responses 会过期吗？
会。除非传入 store: false，否则存储的 responses 默认保留 30 天；根据 2026 年 7 月的相关报道，conversations 不受这一 TTL 限制。
必须把 Assistant 配置迁移到 Prompts 吗？
不必；对于动态生成的 assistants，更不建议这么做。Prompts 只能在控制台创建，官方指南也提示需要关注可复用 prompt 对象的弃用情况。更持久的做法是把指令和工具 Schema 放进代码仓库，并在每次请求时传入。