OpenAI Evals 平台、Agent Builder 与 Reusable Prompts 宣布弃用：2026 年 11 月停服

2026 年 6 月 3 日，OpenAI 在官方弃用追踪页面新增三项平台级弃用条目，停服时间均为 2026 年 11 月 30 日：Evals Platform、Agent Builder 以及 Reusable Prompts（即 v1/prompts API）。与模型 ID 弃用不同——后者通常只需修改一行配置——这三项属于基础设施退役，影响的是团队如何集中管理 prompt、大规模评估模型输出，以及在不编写 SDK 代码的情况下构建 Responses API agent。本文逐一拆解每项退役内容，并梳理 OpenAI 停止托管后，哪些能力可以迁移到 routing 和 gateway 层。

OpenAI 2026 年 6 月 3 日弃用的三项内容

OpenAI evals platform 弃用涵盖三个独立产品：

Evals Platform：OpenAI 托管的 eval 运行器——可通过 Dashboard 或 Evals API 创建、执行、评分 LLM 评估套件。10 月 31 日起进入只读状态；11 月 30 日起所有 eval 运行全部停止。

Agent Builder：用于组合 Responses API agent（工具配置、指令编辑、测试）的无代码 / 低代码 Dashboard UI。注意：底层 Responses API 本身不在弃用范围内，仅 Builder UI 及其保存的 agent 对象被退役。

Reusable Prompts（v1/prompts）：允许团队在 OpenAI 基础设施中存储和版本化 prompt 模板的 POST /v1/prompts 端点。任何在推理时调用 /v1/prompts 获取存储模板的应用，在 11 月 30 日后将直接报错。

OpenAI evals platform 弃用对 routing 运营商的影响

三项退役各自以不同方式将责任转移到运营商层。

v1/prompts API 下线与 gateway 侧 prompt 管理

Reusable Prompts API 提供的是最简抽象：调用 OpenAI、取回存储的 prompt、注入请求。停服后，依赖它进行集中 prompt 版本管理的团队——尤其是多团队共享 prompt 库的场景——需要另寻托管位置。

routing 和 gateway 层是最自然的归宿。在出站请求离开基础设施前，能够拦截请求的 AI gateway 可以从版本化存储中注入 prompt 模板。这样的设计让 prompt 资产具备可移植性：无论下游模型是 OpenAI、Anthropic 还是 DashScope 等国内提供商，同一模板均可生效。对于已经使用 多 provider routing 实现 fallback 或成本路由的团队，在 gateway 侧增加 prompt 注入无需引入新的网络跳转，还能提升可移植性。

附加收益：将 prompt 版本化管理纳入自有基础设施后，合规审计有据可查。OpenAI 托管的 prompt 存储对合规而言是黑盒；gateway 侧存储则是 CI/CD 流水线中的一等公民。

Evals Platform 停服与 routing 层可观测性

Evals Platform 承担双重职责：部署前的自动化基准测试，以及生产环境中的持续质量监控。停服并不消除这一需求，而是转移所有权。

对 routing 影响最直接的后果是线上 eval 覆盖。通过 Evals 检测模型版本切换时的回归，这一信号在停服后需要从别处获取。两种方案可与 routing 层无缝对接：

1. 带影子流量的模型对比路由：将可配置比例的线上流量以影子模式路由到候选模型，与参考模型输出进行比对并记录差异，无需任何 OpenAI 托管的 eval 基础设施。
2. 通过 Promptfoo 等工具构建结构化 eval 流水线：直接对 TheRouter 的 /v1/chat/completions 端点运行 eval 套件，让评估覆盖完整的 routing 路径和 fallback 链，而非仅针对单一模型。

长尾目标——openai evals platform 和 agent builder 2026 年 11 月停服 routing 层迁移——最终收敛为两个动作：将 eval 执行迁移到开放框架，将 eval 路由（我该评估哪个模型系列？）交由 gateway 管理。

Agent Builder 停服与基于 SDK 的 agent 编写

Agent Builder 是生产力工具，而非运行时依赖。曾用它原型化工具调用链、指令集和移交流程的团队，需要将这些配置直接迁移到 Responses API SDK。底层 Responses API（POST /v1/responses）不受影响。

对于已经用代码编写生产级 agent 的团队而言，这三项退役中此项影响最小。对于重度依赖 Builder UI 让非工程师配置 agent 的团队，停服将强制推动流程变革：agent 配置从此进入版本控制代码，不再存于 Dashboard。

从 routing 视角来看，这反而使 agent 配置在默认情况下更具可移植性。用 SDK 代码编写、带有明确模型 ID 和 fallback 列表的 agent，通过任何 OpenAI 兼容 gateway 均能正常运行；而仅保存在 Builder 中的 agent 对象，则隐式锁定在 OpenAI 基础设施上。

2026 年 11 月 30 日停服迁移清单

在 Evals 10 月 31 日只读截止日期前，按此清单评估并排定优先级：

1. 审查 v1/prompts 使用情况。 在代码库和 API 日志中搜索对 /v1/prompts 的调用。逐一确认：prompt ID 是什么，导出存储的模板，并决定替代存储方案（gateway 侧注入、密钥管理器或专用 prompt 注册表）。

2. 在 10 月 31 日前导出 Evals 配置。 Evals Platform 于 2026 年 10 月 31 日进入只读状态。在此之前导出所有 eval 定义、评分器及历史运行数据。10 月 31 日后只读；11 月 30 日后无法访问。

3. 清点 Agent Builder 保存的 agent。 列出 Agent Builder 中创建的所有 agent，下载其指令和工具配置，转换为 Responses API SDK 调用。在 11 月 30 日前确认每个 agent 端到端可用。

4. 选择 eval 框架替代方案。 Promptfoo、LangSmith 和 Braintrust 均原生支持 OpenAI 兼容端点。若 routing 配置使用了 多 provider fallback，将 eval 框架指向 gateway 端点而非直连 OpenAI，使 eval 覆盖完整的 routing 路径。

5. 将内部截止日期定为 10 月 15 日。 11 月 30 日停服恰逢许多组织的 Q4 变更冻结期。10 月至 11 月的内部冻结政策将压缩实际迁移窗口。建议目标：10 月上半月完成全部迁移。

6. 针对 v1/prompts：测试 gateway 侧 prompt 注入。 如将 prompt 存储迁移至 gateway 层，验证注入的 prompt 内容在不同语言环境和模型系列间保持稳定——尤其对路由至非 OpenAI provider 的团队，不同 provider 在 system prompt 格式约定上存在细微差异。

关于 openai v1 prompts API 迁移至 gateway 的补充说明

openai v1 prompts api migration gateway 这一路径值得作为一项架构决策认真对待，而不仅仅是找替换方案。最初选择在 OpenAI 托管存储中集中管理 prompt，往往是因为需要在多个服务间共享单一事实来源。在 gateway 层重建这一能力——而非将 prompt 字符串散落回各应用代码库——可在移除 OpenAI 依赖的同时，保留原始设计意图。

gateway 侧 prompt 存储与多 provider routing 也能自然融合：当某个 provider 出现质量下降或故障时，fallback 链切换至其他模型，但 prompt 模板保持不变，不再与特定 provider 的基础设施绑定。

时间线

从现在到停服还有五个月，如果现在就开始审查，完全可以从容完成迁移。Evals 的 10 月 31 日只读截止是关键节点——请将其作为内部软性截止日期，而非 11 月 30 日。