Assistants API

这页现在更适合拿来做“旧项目迁移说明”，不适合新项目入门。原因很明确：OpenAI 官方已经把 Assistants API 标成已弃用，并给出关闭日期 2026-08-26，同时建议迁移到 Responses API。

#先说结论

• 新项目：不要再把 Assistants 当默认方案
• 老项目：先看清楚自己用了哪些 Assistant / Thread / Run
• 迁移目标：逐步转到 Responses API

如果你现在正在读旧仓库代码，这一页还有价值；如果你准备新接 OpenAI 功能，应该直接去看 Responses API 路线。

#为什么会迁移

OpenAI 在官方迁移文档里给出的方向很清楚：

• Assistants → Prompts
• Threads → Conversations
• Runs → Responses

官方给出的原因，是 Responses API 心智更简单、能力更统一，也更适合后续 agent 能力扩展。

#老的 Assistants 模型长什么样

旧流程通常是：

1. 创建 Assistant
2. 创建 Thread
3. 往 Thread 里写 Message
4. 发起 Run
5. 等待工具调用和最终结果

这套模型本身不是不能用，而是对新项目来说已经不是主路线了。

#什么时候你还需要关心它

• 你在维护一套已经上线的旧集成
• 你要读历史教程或旧 SDK 示例
• 你要做迁移盘点，确认哪些对象和流程要替换

#迁移时先盘什么

我建议先列这三样，不要急着直接改代码：

1. 每个 Assistant 的 instructions 和 tools
2. 业务里哪些地方依赖 Thread 持久上下文
3. 哪些 Run 逻辑里包含工具循环、重试或人工兜底

把这三件事盘清楚，再迁到 Responses，改动会顺很多。

#一个更现实的迁移思路

不要整仓一口气切。更稳的办法是：

1. 先找一个最简单的助手流程
2. 用 Responses API 重做一条等价链路
3. 对比结果、日志和错误处理
4. 再逐步替换复杂工作流

这种迁移节奏更适合真实业务，不容易把线上能力一次性打坏。

#官方参考

• Assistants migration guide: https://platform.openai.com/docs/assistants↗
• Migrate to Responses: https://platform.openai.com/docs/guides/migrate-to-responses↗