OpenAI Assistants API 失败拆解：两年半 beta，终被 Responses 整建制吸收
拆解 OpenAI Assistants API：2023 年 DevDay 以托管线程降低 Agent 门槛，却长期停在 beta，最终在 2026-08-26 被 Responses / Conversations 吸收并正式日落。
OpenAI Assistants API 用两年半 beta 证明：把「持久线程 + 工具调用 + 托管状态」打包成独立 Agent 产品面，可以降低首版编排成本；但当同一家公司把同等能力折进更简单的 Responses / Conversations，并把 reasoning、MCP、computer use 等新工具只挂在新原语上时，旧产品面就失去了独立存在的理由。
增长判断： Assistants API 的失败不是「开发者不需要 Agent」，而是「需要 Agent 的人最终要的是可组合的原语与可迁移的状态，不是永远停在 beta 的一整套对象模型」。官方从未公开 Assistants 的活跃应用数、迁移完成率或独立收入；公开可核验的硬结果只有一条——2026 年 8 月 26 日正式日落，服务不可用，开发者被导向 Responses API。
增长因果链： DevDay 用托管 Threads 降低 Agent 首版门槛 → 对象模型（Assistant / Thread / Run / Run steps）偏重、长期停在 beta → Responses 以更简单的 input/output items 吸收工具与会话能力 → 新能力（deep research、MCP、computer use）只长在新栈 → 官方宣布日落并给一年迁移窗 → 产品面关停，能力并入平台推荐路径。
状态边界： 本文将 Assistants API 记为平台产品面战略退役 / 能力吸收，不是创业公司倒闭，也不是「从未有人用过」。官方迁移页写明 2026-08-26 日落且「no longer available」；经营规模、attach rate、单位经济一律「未披露」。OpenAI 关于「Responses 已在 token 活动上超过 Chat Completions」的说法，只作官方口径引用，不作独立审计事实。
G｜增长系统
结论： Assistants 卖的是「少写编排代码」的激活，不是可公开验证的开发者留存漏斗；增长断点在「第二次生产工作流」和「平台是否还把新能力挂在这条 API 上」。
增长对象
| 角色 | 要完成的事 | 成功信号 |
|---|---|---|
| 应用开发者 | 在自有产品里跑有目标、会调工具的助手 | 首个生产 Thread/Run 上线；90 天内第二个真实工作流仍走同一 API |
| 终端用户（间接） | 在客户应用里完成多轮任务 | 任务完成率、人工接管率——OpenAI 侧未披露 |
| OpenAI 平台 | 提高 API 用量与 Agent 栈采用 | token 消耗、工具调用、迁移到推荐 API |
AARRR（按可观察指标重写）
| 环节 | 指标 | 公开证据 | 置信度 |
|---|---|---|---|
| Acquisition | 新接入 Assistants 的项目 / 密钥 | 未披露；DevDay 2023-11-06 向全体付费开发者开放 beta1 | A（开放事实）/ —（数量） |
| Activation | 首个带工具的生产 Run 成功（非 playground 试玩） | 提供 Playground 与 API；无转化漏斗 | B（机制）/ C（数字） |
| Retention | 90 天内第二套生产工作流；未迁走的活跃 Thread | 未披露 | — |
| Referral | 教程、示例、社区集成 | 社区长期讨论存在，非经营漏斗 | C |
| Revenue | Assistants 相关 token / 工具费 | 无独立 SKU；按模型与工具标准计价；规模未披露 | B（计价逻辑）/ —（规模） |
增长断点：
- 激活被定义成「能跑通 demo」。 对平台 API，激活应是「客户产品里的真实用户任务走通，且 30 天内再次发生」。Playground 创建 assistant 只能证明兴趣。
- beta 时间过长，等于把「生产承诺」悬空。 2023-11 上线到 2025-08 宣布退役，产品面始终带 beta 标签；宣布时官方仍用「winding down the Assistants API beta」表述2。开发者难以把核心路径押在「可能改对象模型」的面上。
- 留存被自家后继 API 抽走。 2025-03-11 OpenAI 发布 Responses API，明确写了：它结合 Chat Completions 的简洁与 Assistants 的工具能力；并在达到特性对齐后计划于 2026 年中退役 Assistants3。新能力默认长在 Responses 上，Assistants 的「第二次工作流」会自然流向新面。
可证伪阈值（测试用，非历史事实）：
- 宣布退役前 90 天，Assistants 周活应用数环比仍 ≥ 0
- 生产 Run 中，第二次同类任务占比 ≥ 40%
- 迁移窗口内，官方公布的迁移完成率 ≥ 70%（三项官方均未披露）
O｜市场机会
结论： Agent 编排总需求没有消失，变的是「哪一层值得做成独立产品面」。Assistants 卡在「平台托管的会话与工具封装」这一层，而这层最容易被同一平台的更薄原语替代。
三层需求
| 层级 | 买方要买什么 | 谁在供给 | Assistants 是否还匹配 |
|---|---|---|---|
| L1 单轮补全 | 便宜、稳定的 chat / 补全 | Chat Completions 等 | 弱：Assistants 过重 |
| L2 有状态多轮 + 工具 | 线程、工具循环、文件/代码执行 | 曾是 Assistants；现为 Responses + Conversations | 曾匹配，后被后继 API 直接覆盖 |
| L3 多 Agent 编排与可观测 | 交接、护栏、trace、评测 | Agents SDK 及外部框架 | 弱：Assistants 主模型是单助手对象，不是编排运行时 |
规模（决策估算，非事实）
OpenAI 不披露 Assistants 单独 GMV 或调用份额。若假设：
- 平台 API 收入主要来自模型 token，Agent 封装是附着层（置信度 B，来自公开计价结构：Responses「不单独收费，按 token 与工具标准价」3）
- 开发者愿意为「少维护状态机」付的是工程时间，不是第二张发票
则 Assistants 的有效机会不是「所有 Agent 预算」，而是「愿意把会话状态存在 OpenAI、并接受其对象模型的应用」——子集会在后继 API 提供同等能力且更简单时迅速收缩。
可证伪市场信号： 若 L2 流量在官方推荐语切换后 6 个月内明显迁到 Responses，而 Assistants 无对等新工具，独立产品面会先于合同到期失血。官方在退役公告中称 Responses 已在 token 活动上超过 Chat Completions2——这是平台重心迁移的旁证（官方口径，置信度 A 引用 / C 独立度量），不能直接等于 Assistants 的流失曲线。
S｜战略定位
结论： 2023 年的定位是「帮开发者在自有产品里做有目标、会调工具的助手，并把无限长线程状态交给 OpenAI」；2025–2026 年的现实是：平台要把 Agent 能力收成统一原语（Responses），Assistants 被明确写成「reasoning 模型出现之前对 Agent 的早期尝试」2。
原定位（一手口径）
- DevDay 2023-11-06：Assistants API 是「first step」——在客户应用内构建 agent-like 体验；助手有特定指令、可调用模型与工具；提供 Code Interpreter、Retrieval、function calling；persistent and infinitely long threads，开发者把线程状态管理交给 OpenAI1。
- 与同日 GPTs 产品共用指令与工具能力叙事，但 Assistants 面向 API 集成。
战略错位
| 维度 | 原假设 | 2025–2026 现实 |
|---|---|---|
| 产品形状 | 独立对象模型（Assistant/Thread/Run）值得长期维护 | 统一为 Responses 的 items + Conversations / Prompts4 |
| 状态托管 | 服务端无限线程是核心卖点 | Conversations 与 previous_response_id 承接持久上下文；Response 默认存储策略另有 TTL 讨论2 |
| 能力演进 | Assistants 继续接新模型与新工具 | 新内置工具与 agent 工作流优先 Responses + Agents SDK3 |
| 成熟度承诺 | beta 可过渡到 GA | 以 beta 身份直接进入 deprecation → sunset，未经历公开 GA 里程碑 |
| 对内叙事 | Agent 产品线之一 | 「early take on how agents could be built (before reasoning models)」2 |
战略判决： 退役公告与 deprecations 页把 Assistants 从「未来方向」改写成「已完成历史任务的 beta」。官方 deprecations 记录：条目日期 2025-08-20，文中写明 deprecation 公告日 2025-08-26、sunset 2026-08-26；迁移目标为 Responses 与 Conversations5。能力可以迁走；独立对象模型没有被证明必须保留。
C｜竞品分析
结论： 真正的替代者首先是 OpenAI 自己的 Responses + Conversations + Agents SDK，其次才是开发者自建编排或外部 agent 框架。把「Assistants 克隆 API」当主竞品，会看错战场。
| 对照 | 官方自我定位 | 相对 Assistants 的差异 | 压力来源 |
|---|---|---|---|
| Responses API | 新的 API 原语；结合 Chat Completions 简洁与 Assistants 工具能力 | 一次调用可多工具多轮；内置 web/file search、computer use 等；官方推荐新项目默认路径36 | 直接吸收 L2 需求 |
| Conversations / Prompts | 会话与配置的新载体 | Threads→Conversations（存 items 不只 message）；Assistants→Prompts（配置可版本化，偏 dashboard）4 | 拆掉 Assistants 的状态与配置封装 |
| Chat Completions | 仍广泛支持的对话 API | 无同等内置工具深度；官方称继续支持，但新集成推荐 Responses3 | 简单场景的「不升级」选项 |
| Agents SDK | 单/多 agent 编排与可观测 | 补齐 Assistants 弱的多 agent 与 trace；开源、接 Responses3 | 抢走 L3 编排心智 |
| 外部编排（如 LangGraph 等） | 开发者自管图与状态 | 状态与供应商解耦；成本是自建复杂度 | 对「怕锁进某一对象模型」的团队 |
竞争要点：
- 内部产品替代的杀伤力高于外部抄袭。 同一账单、同一模型目录、官方迁移指南和一年 sunset 倒计时，比任何第三方兼容层都更强。
- 比较维度应是「生成 + 状态 + 工具 + 编排入口」四件套，不能只比首轮回复质量。
- Chat Completions 仍在，说明 OpenAI 删的是「重封装」，不是「对话能力」。 迁移指南写明 Chat Completions remains supported，Responses recommended for new projects6。
P｜产品设计
结论： Assistants 把 Agent 需要的配置、记忆、执行拆成四个持久对象，适合 2023 年「少写胶水代码」的目标；在 reasoning 与更细粒度 items 出现后，这套对象显得重，且把编排责任藏进 Run，开发者反而不容易控循环。
核心对象（官方迁移映射）
| 旧（Assistants） | 新（Responses 体系） | 官方解释要点 |
|---|---|---|
| Assistants | Prompts | 配置（模型、工具、指令）可版本化、更新4 |
| Threads | Conversations | 从「只存 message」变为 item 流（message、tool call、output 等）4 |
| Runs | Responses | 提交 input items，拿回 output items；工具循环显式管理4 |
| Run steps | Items | 更通用的步骤/产物对象4 |
设计上成立的部分
- 状态外置： 无限长 threads 降低客户端自己裁上下文的负担1
- 工具打包： Code Interpreter、Retrieval、function calling 开箱可用，减少自建沙箱与 RAG 管道1
- 与 GPTs 叙事对齐： 同一套「指令 + 工具」心智，降低教育成本
设计上的结构性缺口
| 缺口 | 为何致命 | 后继补法（官方方向） |
|---|---|---|
| 对象多、心智重 | Assistant/Thread/Run 异步状态机学习成本高 | Responses：input → output items，结构更简单4 |
| 工具循环不够显式 | 复杂 agent 难插自定义重试、护栏、人机确认 | Responses 强调显式管理 tool loop4 |
| 新工具挂载滞后 | deep research、MCP、computer use 等出现在 Responses 叙事中2 | 能力只在新栈长齐后，旧栈失去对等 |
| 配置与代码耦合方式 | Assistant 对象主要通过 API 管理 | Prompt 偏 dashboard 版本化，和应用编排分离4 |
| 长期 beta | 生产合规与路线图信任不足 | 以 sunset 结束不确定性，而不是 GA |
产品一句话： Assistants 优化的是「把 agent 跑起来」；平台后来要的是「把 agent 拆成可组合、可观测、可迁走的 items」。
E｜商业模式
结论： Assistants 没有公开的独立套餐，商业模式附着在模型 token 与工具计价上；关停的是产品面与对象存储形态，不是一条单独的 P&L 对外披露。
收费逻辑（公开结构）
- DevDay 写明 Assistants 与其工具定价见定价页，按平台标准能力计费1
- Responses 发布时写明：API 不单独加收一层「Responses 费」，token 与工具按标准价3
- 迁移到 Responses 的官方卖点包含内部评测下的缓存改善（相对 Chat Completions 约 40%–80% 成本侧改善，官方内部测试口径，置信度 B 引用 / C 外部复现）6
未披露项
- Assistants 贡献的 ARR / 调用占比 / 活跃 assistant 数
- Thread 存储与检索的真实单位成本
- 迁移窗口内的流失调用量
- 因对象模型简化节省的基础设施费用
单位经济逻辑（推演，置信度 C）
- 收入端：与是否叫 Assistants 关系弱，主要随模型调用与工具调用
- 成本端：持久 Thread、检索、Code Interpreter 沙箱、Run 状态机都有固定与变动成本
- 当 Responses 能用更简单的存储与更高缓存命中承接同类任务时，维持两套 Agent API 的边际理由变弱
- 对 OpenAI：关掉旧面、集中工程与文档到 Responses，是平台侧单位经济，而不是「Assistants 订阅卖不动」的消费应用故事
商业判决： 公开证据支持「产品面合并」，不支持「该 API 从未产生用量」。没有公开数字证明 Assistants 亏损；有公开时间表证明平台不愿再并行维护它。
L｜洞察提炼
结论： Assistants 留下的不是「不要做 Agent API」，而是五条可迁移判断。
- Beta 超过两个大版本周期，本身就是战略信号。 客户会用「能不能押核心路径」投票；迟迟不 GA，等于邀请他们少依赖。
- 托管状态是卖点，也是迁移税。 Threads 越省事，sunset 时导出与重写成本越高；产品设计要提前给「状态可携带」的出口。
- 平台内部的后继 API 是最硬的竞品。 同一官网、同一密钥、官方迁移文与日落日，外部兼容层很难赢。
- Agent 产品面要经得起「拆回原语」测试。 若配置、会话、工具循环、编排都可以被更薄的 items 表达，厚封装只能靠明显更好的默认体验续命。
- 新能力挂在哪条 API，决定旧 API 的留存。 deep research / MCP / computer use 只出现在 Responses 叙事时，Assistants 的第二次工作流已经被定好方向。
D｜决策分析
结论： 对平台产品、AI 应用创始人和投资人，Assistants 提供的是一组可证伪门槛，用来判断「封装层」该不该做成长期产品。
若你做平台 / Agent API
| 决策点 | 通过门槛 | 失败信号 |
|---|---|---|
| 成熟度 | 公开 GA 标准与 SLA，或明确「仅实验」 | 长期 beta 却默认进生产教程 |
| 能力对等 | 新工具 90 天内在旧面可用，或旧面停止接新客 | 新能力只上新栈，旧栈靠迁移文维持 |
| 状态可迁 | 一键导出会话/配置，字段稳定 | 状态锁死在专有对象，无对等 schema |
| 简化测试 | 能用更薄原语表达 80% 工作流仍保持体验 | 为了对象模型完整牺牲调用简洁 |
| 日落纪律 | 对等功能 + ≥12 月窗口 + 迁移指南（本案官方给了约一年）2 | 无对等就关，或无窗口 |
若你是应用创始人 / 技术负责人
- 核心路径优先绑「官方写明长期支持」的原语；封装层当加速器，不当唯一数据库
- 自建一层极薄的会话与工具接口，背后可切换 Assistants / Responses / 自管
- 迁移预算按「对象数 × 工作流数」估，而不是按「改 endpoint 字符串」估
- 关注官方 deprecations 页与社区 Announcements，而不是等第三方解读
若你是投资人
- 区分「Agent 应用公司」与「绑死某一平台对象模型的集成」
- 尽调问三句：状态存谁那里、换 API 要几人月、新模型/新工具是否自动可达
- 对「我们用了 Assistants」本身不打分；对「工作流可在 Responses 或自管栈复现」打分
一句话决策
当平台能用更简单的原语表达同一类 Agent 工作时，厚 API 产品面必须证明自己多出来的对象配得上永久维护费——否则日落只是时间问题。 Assistants 在 2026-08-26 给出了答案。
资料与边界
明确未披露： Assistants 活跃应用数、调用量、收入贡献、迁移完成率、Thread 存储成本、单位毛利。文中涉及时间线、对象映射与官方口径的句子，均在段落内附可点击原链；OpenAI 关于 token 活动对比的表述仅作官方自称引用。
References
- 1OpenAI DevDay 2023 公告\
openai.com
- 2OpenAI 社区：Assistants API beta 退役公告\
community.openai.com
- 3OpenAI：New tools for building agents\
openai.com
- 4Assistants migration guide\
developers.openai.com
- 5OpenAI API deprecations：Assistants API\
developers.openai.com
- 6Migrate to the Responses API\
developers.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.