Assistants API 已停用，客户的聊天记录可能随之消失

OpenAI 的迁移指南如今用过去时开篇：Assistants API 已于 2026 年 8 月 26 日正式关停，无法再使用。这已经不是预警。凡是还在调用这个 API 的应用都已经坏了，只是可能还没人发现。

准备时间并不少。2025 年 8 月 26 日，OpenAI 在开发者论坛宣布弃用 Assistants beta，并在整整一年后关闭。即便如此，对于处在“运行正常、不用动它”状态的项目，一年时间很容易在无人问津中过去。

想做前线部署工程师（FDE），不妨设想这样一张工单：客户有一个去年做的聊天机器人或内部 Agent，现在开始报错，写它的人已经离职。乍看只是换个端点的事。实际上，难点在数据，以及读取输出的下游系统。

OpenAI 为什么放弃 Assistants？

OpenAI 把 Assistants 描述为推理模型出现之前构建 Agent 的一次早期尝试。Responses API 则被定位为当前和长期推荐的集成方式。按照迁移指南的说法，迁移过来的客户能获得更好的性能，以及网页搜索、MCP 和 computer use 等内置工具。

但换到 Responses 带来的不只是新功能。按 OpenAI 的概念对应关系，工具调用循环现在放在客户的代码里；客户想继续使用的旧历史，也必须由客户自己存储。Responses 把控制权交还给你，你也就要承担以前从未考虑过的工作。

三个概念改名，三项职责转移

OpenAI 的指南把概念两两对应。Assistant 变为 Prompt：模型、工具和指令的一套配置，更便于版本管理和更新。Thread 变为 Conversation，存储的是一串条目（item），而不只是消息；Run 变为 Response，工具调用循环改由客户自己的代码控制。

逐行看，这些都不吓人。只有把每组对应关系放到“客户那边谁要改做什么”这个问题下，风险才显现出来。下表就按这个思路整理：

Assistants	Responses	FDE 需要在客户处核查的内容
Assistant	Prompt（模型、工具、指令，带版本）	配置是写死在代码里还是放在控制台？谁能修改，如何回滚？
Thread	Conversation（一串条目，不只是消息）	客户是否另外存储了旧历史？迁移后保留多少？
Run	Response，工具循环由客户代码控制	客户代码能否处理 function call、重试和迭代次数上限？
输出只包含消息	输出新增活动条目（file search、function call）	下游解析器、日志、看板和 CRM 能否识别新的条目类型？

第二行和最后一行最容易让客户损失数据或信任。下面两节分别讨论。

会话历史：找不回来的部分

OpenAI 的指南写得很明确：Assistants 中获取 thread 消息的调用已经失效，请使用自己存储的消息。说白了，如果客户一直把 OpenAI 的 thread 当数据库用，那么 2026 年 8 月 26 日之后，只存在于这些 thread 里的历史再也取不回来了。

设想一家物流公司用 Assistants 做客服机器人。每条投诉是一个 thread，员工在给客户回电前，会重新打开 thread 读完整的往来记录。

如果后端只存了 thread_id 而没有存内容，那个页面现在就是空的，问题也就不再是 API，而是公司的业务流程本身。

即使是谨慎的供应商，也没法把所有东西都搬过来。Zoho SalesIQ 迁移了自家的集成，因此客户现有的 Assistant ID、会话 ID 和文件 ID 在 SalesIQ 托管的集成中仍然可用。但迁移一个会话时，SalesIQ 只带上最近的 100 条消息。

设想一个持续了几周、累计 340 条消息的客服会话：到了新系统只剩 100 条，最早的 240 条落在模型可见的上下文之外。如果合同编号、退款承诺这类关键信息恰好在早期消息里，新机器人回答时就会像从没听说过一样。

所以到客户那里，第一件事不是写代码，而是盘点：哪些会话客户另外存了，哪些只剩 ID，哪些业务流程需要完整历史而不只是最近一段。

然后和客户书面约定保留多少才够，而不是让一个默认数字替他们做决定。

工具循环现在是你的代码

OpenAI 的指南明确指出，使用 Responses 时，工具调用循环由客户自己的代码控制。这段代码要发送请求、接收 function call、执行函数、回传结果，并决定何时停止。

结果是，以前不必考虑的事现在都归你负责。如果模型不停地调用工具，迭代多少次后切断？

客户某个函数超时了，怎么告诉模型？两个工具并行调用、其中一个失败时又怎么办？这些是系统可靠性问题，不只是 API 语法问题。

好处是，客户一旦写了这个循环，就有了一个挂载点：可以加日志、测量每一步的延迟，在危险操作执行前拦截。优秀的 FDE 会把这一点作为客户得到的收益来介绍，而不是强加给他们的负担。

输出变了形，下游系统读错了

第三个风险最难发现，因为不会报任何错。Zoho 提醒客户，响应中现在可能包含处理过程中产生的活动条目，比如 file search 和 function call，而不只是最终答案。

设想一段旧代码取输出的第一个元素，作为机器人的回复写入 CRM。在新系统上，第一个元素可能是一条 file search 记录。CRM 照样收到数据，不抛异常，员工却开始在客户历史里看到奇怪的文字。

应对办法是把输出从 API 一路追踪到所有用到它的地方：解析器、日志、看板、报表系统。在每一处检查代码是按条目类型过滤，还是默认输出里只有消息。这份清单应当在改动任何一行代码之前就整理好。

开发者该如何对待这次迁移？

如果你所在的公司曾为客户在 Assistants 上搭建聊天机器人或 Agent，迁移工单迟早会落到团队里某个人头上。不要回避。这正好锻炼 FDE 需要的能力：进入一个陌生系统，找出可能丢数据的地方，在动手之前和客户达成一致。

看岗位描述时，留意是否提到迁移、遗留系统集成或工具调用；如果有，这次迁移的经验值得在面试中提出来。简历上不要只写“迁移到 Responses API”。

要具体写出盘点了多少会话、保留了多少历史、避免了哪些下游故障，因为这说明你考虑的是对客户的影响，而不只是端点。

OpenAI 恰好提前了 12 个月通知，今天仍在调用 Assistants 的项目已经没有等待的余地。被叫去处理的人需要先弄清客户的数据在哪里，这件事排在改代码之前。