OpenAI Assistants API 关停复盘：厂商 API 依赖的架构经验

30 秒答案：Assistants API 关停说明，厂商 API 同时包含两层东西：传输契约和托管产品语义。OpenAI-compatible 路由可以在请求能表达为兼容模型调用时帮助处理传输层切换，但它不会保留服务端 Assistant、Thread、Run、工具资源或生命周期承诺。把每一个托管 Agent API 都当作可替换基础设施来设计：监控退役公告，维护版本账本，自己掌握不能丢失的编排逻辑，并在关停周之前测试 fallback 路径。

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model， 并返回 OpenAI 形式的流式响应。

Assistants API 关停到底改变了什么

OpenAI 的 Assistants migration guide 写明，在 Responses API 达到功能对齐后，Assistants API 已被弃用，并将在 2026 年 8 月 26 日关停。同一份文档把旧对象映射到新的心智模型：Assistants 走向 Prompts，Threads 走向 Conversations，Runs 走向 Responses，Run steps 则变成更通用的 Items。来源：OpenAI Assistants migration guide，检索于 2026-08-24。

这个映射很重要，因为它说明这不是一次简单的 model ID 替换。替换模型通常是配置变更；退役 endpoint 或对象模型则是应用架构变更。

对于深度依赖 Assistants 的团队，风险主要在四处：

OpenAI 的 deprecations 页面还说明了更广泛的模型退役政策：GA 模型至少提前 6 个月通知，专用变体至少提前 3 个月，preview 模型可能只有更短窗口。来源：OpenAI deprecations，检索于 2026-08-24。Assistants API 事件提醒我们，endpoint 生命周期也需要运营机制，而不只是模型目录。

为什么迁移清单必要，但不够

我们已经发布过更偏实操的 Assistants 迁移内容，包括最终迁移清单和 Responses API 替代方案对比。它们回答的是紧急问题：截止日前应该改什么。

这篇文章回答更慢、更耐用的问题：为什么这个截止日会痛。

痛点不在于 OpenAI 推荐新项目使用 Responses API。OpenAI 的 Responses migration guide 把 Responses 定位为新的 agent-like 应用 primitive，包含内置工具、多模态输入、typed output Items 和状态上下文选项。来源：OpenAI Responses migration guide，检索于 2026-08-24。

真正的痛点在于，Assistants 鼓励团队把行为、工具声明、状态和执行语义放进一个供应商拥有的对象模型里。当这个产品面被退役，清单能帮助搬代码，却不能让当初的设计自动变得可移植。

复盘结论很直接：迁移准备不是看到 shutdown date 后才开始的冲刺，它应该是架构本身已有的属性。

托管语义和兼容传输是两类风险

大家说一个 API 是 OpenAI-compatible，通常指请求和响应形状接近某个熟悉的 OpenAI endpoint。这很有用。它让客户端、SDK、网关和路由层可以用同一种方言连接多个 provider。

但 Assistants 不只是请求形状。它还是一个托管语义层，保存 Assistants、Threads、tool resources、Run 状态和 step history。下游模型调用可以通过 OpenAI-compatible 接口表达，并不代表这些语义也自动可移植。

TheRouter 应该用来澄清这个边界，而不是模糊这个边界。我们可以把 OpenAI-compatible 请求路由到已配置 provider，也可以在兼容传输路径上降低 provider 或 model 切换摩擦。我们不应该声称能保留 Assistants API 的托管语义、消除迁移工作，或保护所有厂商特定功能不受退役影响。

这个边界是健康的。它让架构判断保持诚实。

厂商 AI API 的依赖风险模型

好的复盘要问清楚，失败的是哪一种依赖。对于 LLM API，我们通常拆成五层：

1. 模型身份：具体 model ID、snapshot 或 tier。
2. Endpoint 契约：路径、请求 schema、响应 schema、streaming 形状和错误行为。
3. 托管状态：服务端 conversations、files、vector stores、prompts、assistants 或 agent definitions。
4. 托管执行语义：工具循环、代码执行、web search、file search、computer use 和调度行为。
5. 运营政策：数据保留、rate limits、价格、退役通知、地域可用性和合规控制。

路由层最擅长的是第 1 层和第 2 层，前提是存在兼容路径。它有时也能帮助第 5 层，例如在某个模型家族不可用或成本过高时选择已配置 provider 路径。它不会神奇地让第 3 层和第 4 层可移植。

这个区分应该进入设计评审。如果某个工作流是业务关键路径，就要问：如果 provider 在 90 天后退役这个产品面，哪一层会断？

退役监控应该算生产基础设施

OpenAI 在专门页面记录 deprecations，并说明会通过邮件和文档通知受影响客户，重大变化还会有 blog posts。来源：OpenAI deprecations，检索于 2026-08-24。这很有价值，但不能只靠邮箱记忆。

可以沿用我们在跨 provider changelog 监控指南里的做法：

• 定时 diff provider deprecation 页面和 changelog；
• 把每个 shutdown date 规范化进内部账本；
• 为每个 model、endpoint 和托管产品对象标注 owner；
• 在 freeze window 之前创建日历提醒，而不是截止日当天；
• 用 CI 检查已弃用 model ID 和 endpoint path；
• 给每个生产集成留一份人能读懂的迁移备注。

账本应该跟踪 endpoint，而不只是模型。Assistants 关停就是最好的证明。

哪些东西应该放回应用代码

最安全的设计不是“永远不要用托管 API”。托管 API 经常正是正确选择。它们缩短上线时间，也提供很多自建成本很高的能力。

更安全的设计是提前决定，如果托管产品面消失，哪些东西必须可恢复：

• 会话历史：保存足够规范化的历史，方便重放或迁移关键会话。
• 工具定义：即使也注册到 vendor，schema 仍然放进源码仓库。
• Prompt 行为：system instructions、output schema 和安全约束要版本化。
• 执行轨迹：用 provider-neutral 形状记录 tool calls、tool outputs 和 final outputs。
• 模型选择：model ID 放配置，不要散落在应用代码里。
• Fallback 预期：写清楚哪些工作流能切 provider，哪些不能。

这不只适用于 OpenAI。Anthropic、DashScope、DeepSeek、Google 或其他 provider 调整模型、价格、政策和 endpoint 行为时，同样会出现这些设计压力。

路由和 fallback 什么时候有用，什么时候没用

当问题是兼容模型访问时，路由层很有价值。如果某个 workload 发送的是 OpenAI-compatible 的 chat 或 responses-style 请求，TheRouter 可以位于已配置 providers 前面，让 provider/model 选择更容易运营。内部链接可以从 OpenAI、DeepSeek 和 DashScope 开始，检查你的路由目录里有哪些 provider 页面和 model 页面。

模型层面的评审也应该看 /models/openai--gpt-5.6-sol/ 这样的页面。应用应该知道每个工作流允许哪些模型、哪些模型还在实验、哪些模型明确不能用。

如果依赖的是已经退役的托管对象模型，路由就帮不上核心问题。如果你的应用假设 provider 保存 Assistant、拥有 Thread、调度 Run、执行工具循环，并暴露专有 Run-step 对象，那么 fallback 路径必须替代这些语义。这是应用架构，不只是流量路由。

更现实的姿态是混合判断：

给下一次厂商 API 退役的架构清单

在下一条 deprecation notice 到来之前，先做这轮评审：

• 列出生产环境使用的每个 vendor endpoint、model ID、托管对象类型和 dashboard-managed resource。
• 把每一项标注为 portable transport、hosted state、hosted execution 或 policy dependency。
• 给版本账本补上 owner、source URL、shutdown date、replacement target 和 last verified date。
• 把 prompts、tool schemas 和 routing policy 放进源码管理。
• 导出或镜像必须在 vendor 产品退役后继续存在的会话状态。
• 每季度做一次故障演练：把一个 provider-specific surface 替换为兼容路径或本地 adapter。
• 对每一条 fallback claim，写清楚它成立的具体条件。
• 永远不要把 OpenAI-compatible 当成 semantically identical 的缩写。

真正的复盘目标是少意外，而不是零依赖

目标不是移除所有厂商依赖。那会让大多数团队更慢，而且未必更好。目标是知道哪些依赖在模型层，哪些在 endpoint 层，哪些在产品语义层。

Assistants API 关停之所以有价值，是因为它把边界暴露出来。Responses 对许多 OpenAI 用户来说可能就是正确目的地，OpenAI 的迁移文档也解释了具体路径。但架构经验比一个 endpoint 更大：可移植传输、自有状态、退役监控和明确 fallback 边界，已经是严肃 LLM API 运营的一部分。

Sources: OpenAI deprecations (retrieved 2026-08-24); OpenAI Assistants migration guide (retrieved 2026-08-24); OpenAI Responses migration guide (retrieved 2026-08-24); OpenAI community announcement (retrieved 2026-08-24).