OpenAI Assistants API 已废弃：8 月 26 日前迁移到 Responses API

OpenAI Assistants API 将于 2026 年 8 月 26 日正式关闭，距今仅剩 60 天。如果你的团队有任何生产工作负载运行在 Assistants 上——包括 threads、runs、文件搜索、代码解释器——在这一日期之后，所有调用将直接报错，除非已完成迁移至 Responses API。

这不是软性废弃，没有兜底 fallback。8 月 26 日之后，对 openai.beta.threads、openai.beta.assistants 及相关 endpoint 的 API 调用将返回错误。替代方案是 Responses API，该接口现已完整支持深度研究、MCP 工具连接和计算机操作等能力，功能上与 Assistants API 完全对等。

发生了什么

OpenAI 在 Responses API 达到功能对等后宣布废弃 Assistants API beta。根本原因在于架构设计：Assistants 将模型选择、指令和工具声明捆绑进持久化的服务端对象（Assistant），并由其掌管执行状态（Thread、Run）。Responses API 则将这些关注点解耦，交由每次调用时的路由层动态决策。

对应关系如下：

Responses API 同样支持与聊天补全相同的模型选择器，这意味着现有的路由策略（模型 fallback、延迟分级、成本阈值）可以直接作用于有状态的 agent 会话。

对 AI 工程团队的影响

模型选择变为每次调用级别。 Assistants API 中，模型被固化在 Assistant 对象中，更换模型需要更新对象并可能导致缓存状态失效。Responses API 将模型作为每次请求的参数——你的路由层可以在不修改任何配置对象的情况下，动态切换 provider、在负载高峰期降级模型层级、或基于成本执行模型选择。

Prompt 版本管理取代静态系统指令。 Prompt 是可在仪表盘中管理并支持快照版本控制的对象。只需在代码中替换 prompt_id，即可对行为配置进行 A/B 测试，无需创建或删除对象，也不会导致状态失效。这一模式与网关层路由完美契合：Prompt ID 作为版本化的行为契约，模型选择作为运行时路由决策。

工具循环变为显式管理。 Assistants 通过轮询 Run 的方式抽象了工具执行过程。Responses API 要求调用方直接管理工具调用循环——从输出 item 中接收工具调用、执行后将结果作为输入 item 返回。这种显式化设计意味着路由代理可以像处理普通模型调用一样，拦截、记录和路由工具调用，而不必将其视为不透明的 Run 状态。

Conversation 支持跨会话存储上下文。 Thread 只存储消息；Conversation 存储 item（消息、工具调用、工具输出）。对于有状态的 agent 工作流，当 provider 负责管理上下文时，这消除了在自有数据库中维护并行会话状态的需求。

路由与运营视角

Assistants API 在架构上对路由代理极为不友好。由于模型选择被嵌入 Assistant 对象，执行状态存储在 Thread 和 Run 中，路由代理若要拦截或修改路由决策，就必须接管整个 Assistants 生命周期管理，代价极高。

Responses API 的设计截然不同：model 参数存在于每个请求中，工具 schema 来自版本化的 Prompt，执行是同步的。这意味着位于 API 前端的路由代理可以采用与处理聊天补全相同的路由逻辑——provider 选择、fallback 链、重试策略、用量计量——而无需担心丢失状态或破坏执行流程。

对于多 provider 架构的团队，这一点至关重要：Responses API 的 model 参数接受任何路由器可解析的模型标识符。你可以将会话前几轮请求路由至成本较低的模型，当检测到复杂度上升时，在会话中途升级至高能力模型，并在 provider 不可用时自动 fallback 至备选——所有这些都无需让 Assistant 对象掌管模型选择。

8 月 26 日前必须完成的审计清单：

1. 找出所有 Assistants API 用量。 在代码库中搜索 openai.beta.threads、openai.beta.assistants、openai.beta.runs、已保存的 Assistant ID 和 Thread ID——任何 Assistants beta 命名空间下的调用都受影响。
2. 梳理你所持有的 Thread 状态。 如果你存储了 Thread ID 并跨会话引用，需要规划 Conversation 迁移路径：Conversation 的 ID 格式和 item 结构均有所不同。
3. 审计工具定义。 将工具 schema 迁移至仪表盘中的版本化 Prompt，代码改为引用 prompt_id，而非内联工具定义。
4. 测试路由代理的兼容性。 如果你代理了 OpenAI API 调用，需验证代理能正确处理 Responses API 的请求/响应格式——它与聊天补全和 Assistants beta endpoint 均有所不同。
5. 单独确认 Azure OpenAI 的时间表。 Azure 有独立的退役计划；8 月 26 日的日期适用于 OpenAI API 平台，请查阅 Azure 文档以了解对应时间节点。

TheRouter 用户应关注或尝试的事项

Responses API 的每请求 model 参数与任何 OpenAI 兼容的路由网关均可兼容。如果你通过 TheRouter 网关路由至 OpenAI 后端，Responses API 调用的迁移路径与聊天补全完全一致——更新 base URL、保留 Authorization header，现有路由策略（模型 fallback、provider 选择、重试逻辑）即可自动生效。

请参阅 TheRouter 文档，了解 OpenAI 兼容 provider 路由的配置方法。正在迁移 Assistants API 工作负载的团队，应在 8 月 26 日截止日期前，通过路由层对工具调用流程进行端到端测试——Responses API 中工具循环的显式化设计，使得代理层对工具调用的拦截、记录与路由变得简单直接。

67 天的窗口期对大多数迁移任务来说足够充裕，但前提是现在就开始审计。等到 8 月再行动的团队，将在压力之下迎头撞上这个截止日期。