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。
一年预告，两次关停
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「只能在 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 走了另一条路
同一天，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 区域可用，资源落在不支持区域的用户需要新建资源才能迁移。结果是，同一个 Assistants API 关停事件，在 OpenAI 和 Azure 两侧指向了两个方向不同的继任者——一个把编排权交回应用代码，一个把编排收进托管 agent 服务。
开发者真正要面对的
对仍在使用 Assistants API 的团队，这次关停不是改一个 endpoint，而是一次架构决策：把状态与编排重新拿回自己手里，还是迁入新的托管层。OpenAI 的方向是把「做什么」放进 Prompt 配置、把「怎么做」留给应用代码；Azure 的方向则是把两者都收进 Foundry Agents。三条并存的落点（Responses/Conversations、面板里的 Prompt、Foundry Agents）意味着短期内没有唯一答案，只有按各自锁定期限倒排的迁移窗口。
接下来最值得盯的变量，不是「迁移是否顺利」，而是官方路径本身是否还会再动：11 月 30 日 Prompt 对象关停后，OpenAI 会不会补上可编程创建 Prompt 与 Conversation 的 API 对齐，还是继续把配置留在面板里。如果这份弃用清单的下一行，再指向 Responses 的某个中间对象，那才是这次「收敛」真正的未定之处。