8月26日，OpenAI 按一年前的预告关停了 Assistants API（beta）。这套用于托管 agent 配置和会话的接口停止服务后，/v1/assistants、/v1/threads 及关联端点不再可用。OpenAI 给出的替代品是 Responses API 与 Conversations API。迁移时仍有几项需要处理的问题：指南让开发者把 assistant 改写成 Prompt 对象，而 Prompt 既不能通过 API 创建，本身也已在今年 6 月被列入弃用清单、定于 11 月 30 日关停；thread 到 conversation 的迁移没有自动化工具。Azure OpenAI 的 Assistants API 在同一天关停，指向的却是另一个服务——Microsoft Foundry Agents。
从 v1 迁到 v2 后，整个 Assistants API 停服
Responses API 在 2025 年 3 月发布时，OpenAI 就宣布会把 Assistants API 的功能并入其中，并在达到功能对齐后弃用旧接口。2025 年 8 月 26 日，OpenAI 正式通知开发者：Assistants API 将在一年后关停。按官方定义，sunset 与 shut down 同义，意味着端点不再可访问。
这不是 Assistants 家族第一次被关停。2024 年 10 月，OpenAI 宣布停止 v1 beta 的服务，于 2024 年 12 月 18 日生效，当时是让开发者迁到 v2；现在则是把整个 Assistants API 从平台移除。此次停服意味着，OpenAI 不再维护「assistant／thread／run」这套在推理模型出现前设计的托管对象。
配置、会话与执行记录，分别迁往哪些对象
官方迁移指南给出的映射是：assistant 变成 Prompt（保存模型、工具、指令等配置），thread 变成 Conversation（保存消息、工具调用、输出等 item 流，而不只是消息），run 变成 Response，run step 变成 Item。指南称 Responses「更简单、更灵活」，一次调用即可跨多个工具与多轮模型执行多步工作流，并内置 deep research、MCP、computer use 等工具。
OpenAI 在关停公告里给出的理由是：Assistants 是「在推理模型出现之前，我们对如何构建 agent 的早期设想」；现在它把 code interpreter、持久化会话这些「Assistants 里最好的部分」整合进了 Responses，并称 Responses 的 token 活动量已超过 Chat Completions。这些是 OpenAI 对停用旧接口的解释，并不能替代开发者对自身迁移结果的检查。
Prompt 还会停用，历史会话需自行回填
首先是 Prompt 对象。指南明确写着 Prompt「只能在 dashboard 中创建」，也就是没有对应的 API，开发者无法再像过去用代码动态创建 assistant 那样程序化地建 Prompt。指南还提醒，可复用的 Prompt 对象「也在被弃用」，采用这条迁移路径前要先核对 prompts 的弃用时间线。按弃用文档，Prompt 对象于 2026 年 6 月 3 日宣布弃用，v1/prompts API 与可复用 Prompt 对象定于 2026 年 11 月 30 日关停。也就是说，官方迁移指南指向的目标对象，寿命只剩约三个月。
其次是 Thread 历史会话。OpenAI 明确表示「不会提供把 Thread 迁移到 Conversation 的自动化工具」，只建议把新会话落到 Conversation、旧会话按需回填，并在指南里附了一段手工回填的示例代码。对依赖历史线程状态的产品，这意味着要么自己写迁移脚本，要么放弃旧上下文。
应用的配置方式也需要调整。在 OpenAI 开发者论坛的弃用帖下，有开发者反馈这次迁移并非严格一一对应：过去可以完全通过 API 创建 assistant 并动态下发指令，新的 Prompt 却只能在工作台里手工建立。OpenAI 官方的回应是把 Prompt 定位为「带版本的行为配置」——应用代码负责裁剪历史、安排工具调用和重试，行为配置则在面板中维护。
Azure 推荐 Foundry Agents，工具只迁代码、不迁历史数据
同一天，Azure OpenAI 的 Assistants API 也停用。微软的迁移文档给出的终点是 Microsoft Foundry Agents 服务（GA），它建立在 Responses API 之上，把 agent 定义、版本化、身份治理与可观测性放进托管服务里。与 OpenAI「不提供自动化工具」不同，微软在 GitHub 上提供了一个迁移工具，但该工具只迁移代码结构（agent 定义、thread 创建、消息创建、run 创建），「不迁移状态数据，比如历史的 run、thread、message」。
微软还提示了一个额外约束：Responses API 与 Foundry Agent Service 并非在所有 Azure 区域可用，资源落在不支持区域的用户需要新建资源才能迁移。因此，两边的迁移方案需要分别评估：OpenAI 让应用代码承担更多任务调度，Azure 则通过托管的 Foundry Agents 提供这些功能。
团队要决定谁管理状态，并核对后续停用日期
对使用过 Assistants API 的团队，迁移需要决定由谁保存状态、安排工具和模型调用：由自己的应用代码负责，还是交给新的托管服务。OpenAI 的方向是把「做什么」放进 Prompt 配置、把「怎么做」留给应用代码；Azure 的方向则是把两者都收进 Foundry Agents。Responses/Conversations、面板里的 Prompt 和 Foundry Agents 的功能与停用安排不同，团队需要按自身部署方式逐项核对。
接下来需要关注的是 11 月 30 日 Prompt 对象关停前，OpenAI 会给出怎样的替代配置方式，是否支持通过代码管理。团队也应持续核对迁移指南与弃用清单，避免刚迁移完就再次使用即将停用的对象。
