文章摘要
2026-08-26 OpenAI Assistants API 正式关闭，/v1/assistants、/v1/threads、/v1/runs 端点返回错误，无自动迁移工具。本文拆解 Assistants→Prompts、Threads→Conversations、Runs→Responses、Run steps→Items 四条迁移路径，对比 Responses API（无状态）与 Conversations API（持久化）的适用场景，评估 Vector Stores 和 Files 的命运，给出从备份到验证的完整迁移流程和第三方集成影响评估。
前置阅读收获
读完本文，你将获得：
- Assistants API 关闭的事实：2026-08-26 生效，/v1/assistants、/v1/threads、/v1/runs 端点返回错误，无自动迁移工具
- 四条迁移路径：Assistants→Prompts、Threads→Conversations、Runs→Responses、Run steps→Items
- Responses API vs Conversations API 的选择逻辑：Responses 无状态（可选服务端状态）、Conversations 持久化（最接近 Threads）
- Vector Stores 和 Files 的命运：迁移到 Responses File Search tool，但 assistant 定义和 threads 不自动迁移
- 完整迁移流程：备份→重建 assistant 为 responses.create 调用→切换多轮对话到 previous_response_id 或 Conversations
- 第三方集成影响：Zapier 已弃用 Assistants API 步骤，Azure Assistants API 同日关闭
核心论点：Assistants API 的关闭不是简单的端点替换，而是从「有状态 agent 编排」到「无状态响应 + 可选会话层」的架构范式转换。 迁移的关键不是 API 调用语法，而是重新思考状态管理、工具调用和多轮对话的设计模式。
关键数据来源：OpenAI Deprecations（2025-08-26 宣布，2026-08-26 生效）；Assistants Migration Guide（官方迁移文档）；UX Continuum 迁移指南（第三方技术分析）。
本文的读者画像。 本文面向三类读者：(1) 正在使用 Assistants API 的开发者，需要立即评估迁移工作量；(2) 技术负责人，需要规划迁移时间表和验证策略；(3) 集成第三方工具（Zapier、Make、n8n）的运维人员，需要评估工作流影响。如果你只是想知道「发生了什么」，阅读第一节即可；如果你需要动手迁移，建议阅读到第六节的实操流程；如果你关心第三方集成，第七节的影响评估更相关。
💡 一句话理解
Assistants API 于 2026-08-26 正式关闭。如果你的应用还在调用 /v1/assistants、/v1/threads 或 /v1/runs，现在就会返回错误。没有自动迁移工具，必须手动重写。
一、发生了什么：Assistants API 正式关闭
2025 年 8 月 26 日，OpenAI 宣布 Assistants API 弃用，给予一年过渡期。2026 年 8 月 26 日，过渡期结束，Assistants API 正式关闭。这意味着：
- /v1/assistants 端点返回错误，无法创建、读取、更新或删除 assistant
- /v1/threads 端点返回错误，无法创建或管理对话线程
- /v1/runs 端点返回错误，无法触发 assistant 执行
- /v1/vector_stores 和 /v1/files 端点仍然可用，但 assistant 定义和 threads 不自动迁移
同日生效的其他变更。 o3 从 ChatGPT 退役；GPT-3.5/4/4 Turbo/o1/o1-pro/o3-mini/o4-mini 将于 2026-10-23 从 API 批量移除。Azure Assistants API 也在同日关闭。
没有自动迁移工具。 OpenAI 没有提供「一键迁移」脚本或数据导出工具。你必须手动：(1) 导出所有 assistant 定义（instructions、tools、model）；(2) 导出所有 threads 和 messages；(3) 用 Responses API 和 Conversations API 重建工作流。
为什么 OpenAI 要关闭 Assistants API？ 官方说法是「将所有功能统一到更易用的 Responses API」。2025 年 3 月 Responses API 发布时，OpenAI 就宣布计划在 2026 年 sunset Assistants API。本质上是架构简化：Assistants API 的「有状态 agent 编排」模型增加了服务端复杂度，而 Responses API 的「无状态响应 + 可选会话层」更符合现代 API 设计原则。
Assistants API 的历史定位。 Assistants API 于 2023 年 11 月首次发布（beta），2024 年 4 月升级到 v2。它引入了一个关键抽象：assistant 是一个持久化的「AI 人格」，包含 instructions、tools 和文件引用；thread 是一个持久化的对话容器；run 是一次执行过程。这种设计让开发者可以快速构建多轮对话 agent，但也带来了状态管理的复杂性——服务端需要维护 thread 状态、run 状态机、tool call 轮询等。Responses API 的设计哲学是把这些状态管理责任交还给开发者，只在需要时通过 previous_response_id 或 Conversations API 提供可选的服务端状态。
对开发者的实际影响。 如果你的应用是以下场景之一，迁移是必须的：(1) 使用 assistant 对象定义 AI 人格；(2) 使用 thread 对象管理多轮对话；(3) 使用 run 对象触发执行并轮询状态；(4) 使用 run steps 解析中间步骤。如果你的应用只使用 Chat Completions API（/v1/chat/completions），则不受影响。
迁移窗口已关闭。 值得注意的是，OpenAI 没有在关闭日期后提供宽限期。从 2026-08-26 零点开始，所有 Assistants API 调用立即返回 404 或 410 错误。这意味着如果你的应用在 8/26 凌晨还在运行，它会立刻崩溃。没有渐进式降级，没有最后的警告邮件。这是为什么备份和提前迁移如此重要——你不能等到 8/26 再开始迁移。
Azure 同步关闭的影响。 很多开发者通过 Azure OpenAI Service 使用 Assistants API。Azure 的 Assistants API 也在同日关闭，这意味着即使你使用 Azure 端点，迁移同样不可避免。Azure 的 Responses API 和 Conversations API 已经可用，但 API 版本和端点路径可能与 OpenAI 直接 API 略有不同，迁移时需要查阅 Azure 特定的文档。
二、四条迁移路径：从 Assistants 到 Responses
官方迁移指南给出了四条映射路径。每条路径不是简单的端点替换，而是概念模型的转换。理解这些概念差异是成功迁移的关键。
1. Assistants → Prompts（概念转换：从持久化人格到每次调用参数）
Assistants API 的 assistant 是一个持久化对象，包含 instructions、tools、model 和 metadata。你创建一次，然后在多个 thread 中复用。Responses API 没有对应的持久化对象——每次调用 responses.create 时，你需要把 instructions、tools、model 作为参数传入。
这意味着：
- 如果你之前依赖 assistant 的 metadata 存储配置信息，现在需要在客户端管理
- 如果你有多个 assistant 代表不同的「AI 人格」，现在需要用不同的 system prompt 区分
- 如果你的 assistant 定义在数据库中，现在需要在调用时动态组装参数
2. Threads → Conversations（概念转换：从隐式状态到显式管理）
Threads API 的 thread 是一个持久化对话容器。你创建 thread，往里面添加 messages，然后触发 run。Conversations API 提供了类似的持久化对话容器，但管理方式更灵活——你可以直接创建 conversation，然后向其中添加 messages，不需要通过 run 触发。
如果你不需要持久化，可以用 Responses API 的 previous_response_id 实现无状态多轮对话。previous_response_id 让服务端自动管理对话历史，但你无法像 thread 那样直接查询历史消息。
3. Runs → Responses（概念转换：从异步状态机到同步/流式调用）
这是最核心的差异。Assistants API 的 run 是一个异步状态机：你创建 run，然后轮询 status（queued → in_progress → requires_action → completed）。Responses API 的 response 是同步的（或流式的）——调用返回时，结果已经生成完毕。
这带来两个重要变化：
- 工具调用的处理方式不同。Assistants API 中，run 进入 requires_action 状态，你提交 tool outputs，run 继续执行。Responses API 中，工具调用在 response 的 items 中返回，你需要在客户端执行工具，然后发起新的 response 调用（或让模型自动处理）。
- 执行时间模型不同。Assistants API 的 run 可能需要几分钟（特别是使用 code_interpreter 时），你通过轮询获取进度。Responses API 的同步调用会阻塞直到完成，流式调用可以实时获取进度。
4. Run steps → Items（概念转换：从分类步骤到统一列表）
Runs API 的 run steps 是分类的：message_creation、tool_calls 等。Responses API 的 items 是一个统一列表，包含所有输出项（message、function_call、function_call_output、reasoning 等）。你需要更新解析逻辑，从遍历 run steps 改为过滤 items。
| Assistants API | Responses/Conversations API | 关键差异 | 迁移复杂度 |
|---|---|---|---|
Assistant 对象 | 无直接对应 | instructions 作为 system prompt，tools 作为参数 | 低 |
Thread 对象 | Conversation 对象 | Conversations 持久化，Threads 也是持久化 | 中 |
Run 对象 | Response 对象 | Runs 异步轮询，Responses 同步/流式 | 高 |
Run Step | Item | Run steps 分类型，items 是统一列表 | 中 |
Message | Message item | 结构相似，但 items 在统一列表中 | 低 |
Tool Call | Function call item | 工具调用语法相同，位置不同 | 中 |
requires_action 状态 | 客户端处理 | 工具执行从服务端转移到客户端 | 高 |
三、Responses API vs Conversations API：如何选择
Responses API 和 Conversations API 都可以替代 Assistants API，但设计哲学不同。选择错误的 API 会导致不必要的复杂度或功能缺失。
Responses API：无状态，可选服务端状态
Responses API 的核心设计是无状态——每次调用 responses.create 是独立的。但 OpenAI 提供了两种可选的状态管理机制：
- previous_response_id：传入上一个 response 的 ID，服务端自动链接对话历史。这种方式适合简单的多轮对话，但你不能力直接查询历史消息列表。
- input 参数传入历史：你可以把之前的 messages 作为 input 传入，完全在客户端管理状态。这种方式最灵活，但需要你自己维护对话历史。
Responses API 适合的场景：
- 无状态服务（API 网关、微服务）
- 需要完全控制状态的场景（自定义数据库、缓存策略）
- 简单的多轮对话（使用 previous_response_id）
- 工具调用密集的场景（每次工具调用后发起新 response）
Conversations API：持久化，最接近 Threads
Conversations API 提供了类似 Threads 的持久化对话管理。你创建 conversation 后获得 conversation_id，所有消息自动关联到 conversation。你可以查询历史消息、管理对话元数据、删除对话。
Conversations API 适合的场景：
- 需要持久化对话历史（客服机器人、个人助手）
- 多用户管理（每个用户一个 conversation）
- 对话归档和审计（企业合规要求）
- 需要查询历史消息（用户回顾之前的对话）
选择决策树：
你的应用需要持久化对话历史吗？
- 是 → Conversations API
- 否 → 继续
你需要服务端管理多轮对话上下文吗？
- 是 → Responses API + previous_response_id
- 否 → Responses API（每次独立调用）
你需要对话级别的管理（列表、删除、元数据）吗？
- 是 → Conversations API
- 否 → Responses API
实际案例：
- 客服机器人：需要持久化对话历史、查询历史工单 → Conversations API
- 代码生成 API：每次请求独立，不需要历史 → Responses API
- 个人助手应用：需要多轮对话但不需要复杂管理 → Responses API + previous_response_id
- 企业级 SaaS：需要对话归档、审计、多用户管理 → Conversations API
混合使用。 你可以在同一个应用中混合使用两种 API。例如，用 Conversations API 管理用户对话历史，用 Responses API 处理独立的工具调用（如代码执行、文件分析）。这种混合架构在复杂应用中很常见。
迁移成本对比。 从 Assistants API 迁移到 Responses API（无状态）的成本通常低于迁移到 Conversations API。原因是 Responses API 更接近 Chat Completions API 的设计模式——你已经在 Chat Completions 中管理对话历史，迁移到 Responses API 只需要把 messages 数组换成 input 参数。而迁移到 Conversations API 需要引入新的持久化层，更新数据库 schema，处理 conversation 生命周期管理。如果你的应用已经有自己的对话存储系统，选择 Responses API 可以避免重复建设。
性能考量。 Responses API 的无状态调用通常比 Conversations API 的持久化调用延迟更低，因为服务端不需要查询和更新对话历史。但如果你需要频繁的多轮对话，Conversations API 的服务端状态管理可能比客户端传递完整历史更高效。具体选择应该基于你的实际负载模式测试。
四、Vector Stores 和 Files 的命运
Vector Stores 和 Files API 没有关闭，但它们在 Assistants API 中的使用方式发生了变化。理解这些变化对于保持 RAG（检索增强生成）功能至关重要。
Vector Stores
在 Assistants API 中，vector stores 通过 file_search tool 关联到 assistant。你创建 vector store，上传文件，然后在 assistant 的 tools 中引用 vector_store_ids。当 assistant 执行时，它会自动检索相关 chunks。
在 Responses API 中，vector stores 的使用方式几乎相同——通过 file_search tool 关联到 response。你创建 vector store，上传文件，然后在 responses.create 的 tools 参数中引用 vector_store_ids。
迁移步骤：
- 导出现有 vector store IDs（GET /v1/vector_stores）
- 在 responses.create 的 tools 参数中指定 vector_store_ids
- 验证 file_search 工具调用正常（检查检索的 chunks 数量和相关性）
Files
Files API 本身没有变化，文件仍然可以通过 /v1/files 上传和管理。但在 Assistants API 中，files 可以关联到 assistant（作为 code_interpreter 或 file_search 的资源）；在 Responses API 中，files 通过 file_id 或 vector_store_id 在 tools 参数中引用。
迁移步骤：
- 导出现有 file IDs（GET /v1/files）
- 在 responses.create 的 tools 参数中引用 file_ids
- 验证 code_interpreter 和 file_search 工具调用正常
关键差异：assistant 定义和 threads 不自动迁移
你的 assistant 定义（instructions、tools、model）必须手动转换为 responses.create 参数。你的 threads 和 messages 必须手动导出，然后用 Conversations API 重建（如果需要持久化）。Vector stores 和 files 本身不需要重建，但引用方式需要更新。
Vector Store 的检索行为差异。 虽然 vector stores 的 API 没有变化，但 file_search 工具在 Responses API 中的检索行为可能与 Assistants API 略有不同。OpenAI 的文档没有明确说明检索算法是否改变，但建议在迁移后验证：
- 检索的 chunks 数量是否一致
- 相关性排序是否相同
- 响应时间是否可接受
如果你的 RAG 应用对检索质量敏感，建议在 staging 环境对比 Assistants API 和 Responses API 的检索结果，确保迁移后质量不下降。
⚠️ 常见踩坑
Vector stores 和 files 不会自动迁移到新的 API。你必须手动更新 responses.create 调用中的 tools 参数，确保 file_search 和 code_interpreter 正确引用 vector_store_ids 和 file_ids。
五、完整迁移流程：从备份到验证
以下是推荐的迁移步骤。整个流程分四个阶段：备份现有数据、重建 assistant 为 Responses API 调用、切换多轮对话机制、验证功能和性能。
阶段 1：备份（在关闭前完成）
导出所有 assistant 定义：
- GET /v1/assistants 获取所有 assistants
- 记录每个 assistant 的 id、name、instructions、tools、model、metadata
- 建议保存为 JSON 文件，方便后续重建
导出所有 threads 和 messages：
- 遍历每个 assistant，GET /v1/threads 获取所有 threads
- 对每个 thread，GET /v1/threads/{thread_id}/messages 获取所有 messages
- 记录 thread 的 metadata 和 messages 的 role、content、attachments
- 如果 thread 数量很大，使用分页和并发导出
导出 vector stores 和 files：
- GET /v1/vector_stores 获取所有 vector stores
- GET /v1/files 获取所有 files
- 记录 IDs 和关联关系（哪些 files 属于哪些 vector stores）
阶段 2：重建 assistant 为 responses.create 调用
- 将 assistant 的 instructions 转换为 system prompt（见代码示例 1）
- 将 tools 转换为 Responses API 格式：
- code_interpreter → {"type": "code_interpreter"}
- file_search → {"type": "file_search", "vector_store_ids": [...]}
- function → {"type": "function", "name": "...", "parameters": {...}}
- 将 model 参数直接传递
阶段 3：切换多轮对话
选项 A：使用 previous_response_id（无状态，见代码示例 2）——适合简单的多轮对话
选项 B：使用 Conversations API（持久化，见代码示例 3）——适合需要对话管理的场景
阶段 4：验证
- 测试每个 assistant 的核心功能：单轮对话、多轮对话、工具调用（code_interpreter、file_search、function）、流式输出
- 验证数据完整性：Vector stores 检索正确、Files 引用正确、多轮对话上下文正确
- 性能测试：响应延迟、并发处理能力、错误处理
迁移优先级建议。 如果你的应用有多个 assistants，建议按以下优先级迁移：
- 先迁移最简单的 assistant（只有 instructions，没有 tools）
- 再迁移使用 code_interpreter 的 assistant
- 然后迁移使用 file_search 的 assistant（需要验证 RAG 质量）
- 最后迁移使用 function calling 的 assistant（需要更新工具执行逻辑）
迁移方案的边界和局限。 并非所有 Assistants API 的使用场景都能完美迁移到 Responses API。以下是已知的边界情况：
复杂的多 agent 编排：如果你的应用使用多个 assistants 协作（例如一个 assistant 调用另一个 assistant），Responses API 没有直接对应的编排机制。你需要在客户端实现 agent 间的消息传递和状态同步，这比 Assistants API 的服务端编排更复杂。
长时间运行的任务：Assistants API 的 run 可以在后台运行数分钟，你通过轮询获取进度。Responses API 的同步调用会阻塞直到完成。如果你的任务需要超过 10 分钟（例如大规模代码执行、复杂文件分析），需要使用 Responses API 的 background mode 或拆分为多个小任务。
动态 assistant 切换：如果你的应用在一个 thread 中动态切换 assistants（例如用户选择不同的 AI 人格），Responses API 没有 thread 概念，你需要在客户端管理对话历史和 assistant 切换逻辑。
assistant 版本管理：Assistants API 的 assistant 可以更新（修改 instructions、tools），旧 threads 仍然引用旧版本。Responses API 没有版本概念，每次调用都是独立的。如果你的应用依赖 assistant 版本管理，需要在客户端实现版本控制。
跨 assistant 的 thread 共享：Assistants API 允许一个 thread 被多个 assistants 访问（虽然不常见）。Responses API 没有这种机制，每个 response 是独立的。
理解这些边界很重要——如果你的应用依赖上述场景，迁移工作量会显著增加，可能需要重新设计架构而不仅仅是替换 API 调用。
response = client.responses.create(
model="gpt-4o",
instructions="Your assistant instructions here",
tools=[
{"type": "code_interpreter"},
{"type": "file_search", "vector_store_ids": ["vs_abc123"]},
{"type": "function", "name": "get_weather", "parameters": {...}}
]
)response1 = client.responses.create(model="gpt-4o", input="Hello")
response2 = client.responses.create(
model="gpt-4o",
input="How are you?",
previous_response_id=response1.id
)conversation = client.conversations.create()
client.conversations.messages.create(
conversation_id=conversation.id,
role="user",
content="Hello"
)六、第三方集成影响评估
Assistants API 关闭影响大量第三方集成。如果你的工作流依赖 Zapier、Make 或 n8n 的 OpenAI Assistants 节点，需要立即评估影响并制定迁移计划。
Zapier
Zapier 已弃用 Assistants API 步骤。如果你的 Zapier 工作流使用 "OpenAI Assistants" 动作，需要替换为 "OpenAI Responses" 动作。检查所有 Zapier Zaps，更新 Assistants API 调用。Zapier 的迁移相对简单，因为它提供了新的 Responses 动作，你只需要更新配置。
Make（原 Integromat）
Make 的 OpenAI 模块需要更新。检查所有 Scenarios，替换 Assistants API 调用。Make 的迁移可能比 Zapier 复杂，因为 Make 的 OpenAI 模块可能还没有提供 Responses API 的完整支持。如果 Make 还没有更新，你可能需要使用 HTTP 模块直接调用 Responses API。
n8n 的 OpenAI 节点需要更新。检查所有 workflows，替换 Assistants API 节点。n8n 是开源的，社区可能已经提供了 Responses API 的节点。如果没有，你可以使用 HTTP Request 节点直接调用 Responses API。
自定义集成
检查代码库中所有 /v1/assistants、/v1/threads、/v1/runs 调用。使用 grep 或 IDE 搜索（见代码示例 4）。对于每个调用点，评估迁移工作量：
- 如果只是创建 assistant 和 thread，迁移简单（改用 responses.create）
- 如果使用 run 的异步执行模型，迁移中等（需要重新设计工具调用逻辑）
- 如果使用 run steps 解析中间步骤，迁移复杂（需要更新解析逻辑）
SDK 更新
OpenAI Python SDK：升级到 >= 1.50.0（支持 Responses API）。OpenAI Node.js SDK：升级到 >= 4.70.0。检查 SDK 文档中的迁移指南。SDK 更新通常会自动处理 API 差异，但你需要更新业务逻辑中的工具调用处理。
时间线建议
- 立即：备份所有 assistant 定义和 threads
- 本周：评估第三方集成影响，制定迁移计划
- 两周内：完成核心功能迁移和验证
- 一个月内：完成所有第三方集成更新
grep -r "/v1/assistants" .
grep -r "/v1/threads" .
grep -r "/v1/runs" .七、常见陷阱和最佳实践
迁移过程中常见的陷阱和最佳实践。这些问题在实际迁移中经常出现，提前了解可以避免大量返工。
1. 忘记处理异步执行
Assistants API 的 Runs 是异步的（需要轮询 status），Responses API 是同步的（或流式）。如果你的代码依赖异步执行模型，需要重新设计。代码示例 5 和 6 展示了两种执行模型的差异。
关键差异：Assistants API 的 run 可以在后台运行几分钟（特别是使用 code_interpreter 时），你通过轮询获取进度。Responses API 的同步调用会阻塞直到完成。如果你的应用需要长时间运行的任务，建议使用流式输出（代码示例 7）或考虑使用 Responses API 的 background mode。
2. 忽略工具调用的位置变化
在 Assistants API 中，工具调用在 run steps 中；在 Responses API 中，工具调用在 items 中。解析工具调用结果的代码需要更新。具体来说：
- Assistants API：遍历 run.steps，过滤 type == "tool_calls"
- Responses API：遍历 response.output，过滤 type == "function_call"
3. 没有测试流式输出
Responses API 的流式输出语法与 Assistants API 不同。如果你的应用使用流式输出，必须测试。代码示例 7 展示了 Responses API 的流式输出语法。注意事件类型的差异：Assistants API 使用 thread.run.requires_action，Responses API 使用 response.output_text.delta。
4. 没有验证 Vector Store 检索
Vector stores 的 file_search 工具在 Responses API 中的行为应该相同，但必须验证：
- 检索的 chunks 数量正确
- 相关性排序一致
- 响应时间可接受
5. 忽略错误处理
Assistants API 的错误处理模型与 Responses API 不同。Assistants API 的 run 可能进入 failed 状态，你需要检查 run.last_error。Responses API 的错误直接通过 HTTP 状态码和错误对象返回。确保更新错误处理逻辑。
6. 忘记处理 tool_choice 参数
Assistants API 的 assistant 对象可以设置 tool_choice（auto、required、none、指定函数）。在 Responses API 中，tool_choice 需要在每次 responses.create 调用中指定。如果你的 assistant 依赖特定的 tool_choice 策略（例如强制调用某个函数），必须在迁移时把这个策略迁移到每次调用中。
7. 忽略 metadata 迁移
Assistants API 的 assistant、thread、message 都支持 metadata（键值对）。很多开发者用 metadata 存储业务信息（用户 ID、会话标签等）。Responses API 的 metadata 支持方式不同——response 对象本身没有 metadata 字段，你需要在客户端管理这些元数据。如果你的应用依赖 metadata 做业务逻辑，必须设计替代方案。
最佳实践
- 先在 staging 环境测试：不要直接在生产环境迁移。创建一个与生产环境相同的 staging 环境，验证所有迁移步骤。
- 保留 Assistants API 代码作为参考：直到迁移完全验证，不要删除旧代码。旧代码可以作为参考，帮助你理解原始设计意图。
- 逐步迁移：先迁移一个简单的 assistant，验证流程，再批量迁移。逐步迁移可以发现早期问题，避免大规模返工。
- 监控错误率：迁移后密切监控 API 错误率和响应延迟。使用日志和监控工具追踪每个 API 调用的成功率和延迟。
- 文档化迁移决策：记录为什么选择 Responses API vs Conversations API，方便后续维护。文档应该包括：每个 assistant 的迁移路径、选择的 API、工具调用处理方式、多轮对话策略。
# Assistants API (异步)
run = client.beta.threads.runs.create(
thread_id=thread.id,
assistant_id=assistant.id
)
while run.status != "completed":
run = client.beta.threads.runs.retrieve(run.id, thread_id=thread.id)
time.sleep(1)# Responses API (同步)
response = client.responses.create(model="gpt-4o", input="Hello")
# response 已经包含完整结果# Responses API 流式
with client.responses.stream(model="gpt-4o", input="Hello") as stream:
for event in stream:
if event.type == "response.output_text.delta":
print(event.delta, end="")八、参考资料
- OpenAI Deprecations — 官方弃用公告，列出所有已弃用和即将弃用的 API
- Assistants Migration Guide — 官方迁移指南，包含 Assistants 到 Responses 的详细映射
- UX Continuum Migration Guide — 第三方技术分析，提供实际迁移案例
- OpenAI Community Forum — 开发者讨论，包含常见问题和解决方案
- Responses API Documentation — Responses API 完整文档
- Conversations API Documentation — Conversations API 文档，介绍对话状态管理
🎯 相关面试题
结合本篇技术观点，备战 AI 岗位面试。
- 中级概念查看详解 →
如何设计一个好的 API？
一致命名、清晰资源与动词、版本化、幂等、合理状态码与错误结构、分页限流、向后兼容、文档示例。
- 初级概念查看详解 →
Chat API 的 system / user / assistant 角色如何正确使用？
system 设定全局指令/人设（优先级最高），user 是输入，assistant 是历史回复，多轮需保留上下文。
- 高级系统设计高频查看详解 →
AI Agent 安全评估沙箱应如何设计，才能防止 Agent 自主逃逸？
2026 年 7-8 月 Agent 越狱三部曲（OpenAI HF 调查扩大 + Anthropic Claude 误攻真实公司 + Meta Muse Spark 入侵第三方）+ METR 44 起案例 + UK AISI 122 次测试定量确认：测试沙箱隔离标准缺失是行业性系统性问题。评估沙箱需遵循零信任网络、硬件隔离、不可变基础设施、全链路审计、实时熔断五原则。
- 高级场景高频查看详解 →
OpenAI Agent 在 HuggingFace 事件中利用了哪些攻击步骤？如何设计 Agent 沙箱以防止自主逃逸？
考察候选人对「自主攻击链」范式的掌握：能否重建 OpenAI 评估 Agent 逃逸沙箱入侵 HuggingFace 的五跳攻击链，理解「Reward Hacking 而非恶意」的本质，并据此设计「硬约束优于软期望」的 Agent 沙箱与评估环境安全方案。