Anthropic 将于 8 月 17 日下线 Prompt 生成 API：每位运营商的工具链必须替换的内容

2026 年 7 月 17 日，Anthropic 宣布旧版 Workbench 将于 2026 年 8 月 17 日 正式关闭——与此同时，三个实验性 API 端点也将一并下线。如果你的团队曾调用过 /v1/experimental/generate_prompt、/v1/experimental/improve_prompt 或 /v1/experimental/templatize_prompt，你只剩不到四周时间完成替换，否则这些调用在截止日期后将直接返回错误。

UI 下线影响直观，但 API 移除才是真正的运营风险。已将这些端点集成进自动化 prompt 迭代流程的团队，将面临硬性断点。

具体下线内容

受影响的三个端点如下：

这些并非冷僻的内部路径。部分团队将其集成进了 CI 流程——比如检验提议中的系统 prompt 修改是否在 improve 端点上得分高于当前生产版本，或利用 generate 端点在回归测试工作流中生成测试套件。8 月 17 日之后，上述三个端点将无条件返回错误。

旧版 Workbench UI（platform.claude.com/workbench）同日关闭。在其中保存的 prompt、变量和评估数据不会自动迁移到新版 Playground（platform.claude.com/playground）。Anthropic 提供数据导出窗口，入口位于 Workbench UI 顶部横幅以及组织设置页面。

立即行动：如果组织内有人需要保留 Workbench 数据，请在 8 月 17 日前完成导出。关闭后不提供恢复路径。

为何与众不同：没有其他提供商提供同等端点

这是值得关注的跨提供商信号。Anthropic 是唯一一家将模型辅助 prompt 工程作为可调用 API 接口开放的主流提供商。OpenAI 的 Prompt Playground 仅面向用户，没有对应的编程 API；Google Vertex AI 在控制台提供 prompt 模板，但没有 AI 驱动的 prompt 改进 API；DeepSeek、Mistral 及所有其他 OpenAI 兼容提供商均无类似接口。

这意味着：

• 仅通过 Claude 路由的团队从未为 prompt 生成构建过多提供商 fallback，因为根本没有可 fallback 的对象。
• 将这些端点集成进 Claude 专属自动化流程的团队，现在面临双重问题：端点消失，且发现任何其他提供商都没有等效替代。
• 已通过 gateway 抽象多个提供商进行路由的团队，从未使用这些端点——因为它们是 Anthropic 专属的，打破抽象层的代价不值得承担。

如果你属于第三类，此次废弃不影响运行时流量——但这是关于在任何自动化工作流中使用提供商专属实验性端点的结构性风险信号。

迁移路径

Anthropic 及任何其他提供商均未提供直接替代方案。以下三条可行路径按工程投入由低到高排列：

路径一：自建元 prompt 工作流（零基础设施变动）

直接调用任意模型——包括 Claude——配合元 prompt 指令："这是一个系统 prompt。请针对以下任务和约束条件对其进行改进。"这复刻了 improve 和 templatize 端点在内部所做的事情。输出质量取决于所调用的模型，且你现在可以显式控制改进指令。

成本：每次改进周期一次 API 调用，按标准 token 费率计费。原实验性端点在内部也会调用模型，但费率未公开说明。

路径二：外部 prompt 管理平台

Braintrust、LangSmith 和 Weights & Biases Weave 均提供 prompt 版本管理、A/B 测试及模型辅助迭代功能，且不依赖任何单一提供商的 API。

对于运行多提供商路由的团队而言，这是架构上更合理的选择：prompt 管理不应依附于某一提供商的实验性 API 路径，而应位于一个能在提供商 API 变化中存续的独立层级。

路径三：Anthropic 新版 Playground（仅限手动）

新版 Playground（platform.claude.com/playground）支持 prompt 迭代，但没有 API 访问接口。如果你的工作流原本就是人工参与的，这是零迁移成本的选项。如果你在自动化中调用了旧端点，这不构成替代方案。

面向路由运营商的架构启示

实验性 prompt API 被标注为 experimental 自有其原因——实验性 API 要么晋升为稳定版，要么被移除。这批 API 在没有稳定替代的情况下直接被移除，这意味着所有基于它们构建的自动化，与基于会被无通知下线的模型别名所构建的自动化处于相同境地。

对于管理多提供商路由的团队，架构层面的启示是：prompt 存储和管理工具从第一天起就应当与提供商无关。如果你的 prompt 迭代流程需要调用提供商专属端点，那就制造了一个任何提供商废弃周期都可能打破的耦合。

对于目前通过 TheRouter 或任何其他 gateway 路由 Claude 的团队，此次废弃对运行时流量没有影响——这些端点仅可通过直接调用 Claude API 访问，从未成为 OpenAI 兼容接口的一部分。但如果你在离线 prompt 工程工作中使用了它们，工具链影响是真实的。

8 月 17 日前的检查清单

• 在代码库中搜索 v1/experimental/generate_prompt、v1/experimental/improve_prompt、v1/experimental/templatize_prompt——任何命中都需要迁移计划。
• 通过横幅或组织设置 → Workbench 导出数据。
• 决定采用自建元 prompt 工作流还是引入外部 prompt 管理平台。
• 从所有追踪这些端点可用性的监控或告警配置中移除相关项，否则 8 月 17 日后这些告警将持续触发。
• 如果有依赖调用这些端点的 prompt 质量 CI 门控的 SLA，在迁移完成前应阻断对应发布流程。