模型退役已经成为日历上的一个事件。生产栈背后的模型如今按固定节奏来去，每家供应商对你提出的要求都一样：在关闭日期之前完成迁移。难的部分很少是模型本身，而是当模型 ID 硬编码散落在源文件、环境变量、CI 流水线和仪表盘各处时随之而来的迁移蔓延——没人说得清还有多少地方仍依赖着这个即将退役的模型。本手册涵盖需要弄清的术语、清点工作流、别名层、测试例程、分阶段切换，以及一项把下一次模型弃用迁移变成日常杂务的预检。
为什么模型退役变成了日常运维
供应商现在发布模型的速度快过大多数团队的评估速度，每一代新模型都会把旧模型推向退役。三大平台都把这件事描述为正常运维，而非紧急事件。OpenAI 的弃用页面开篇就说，公司“会定期退役较旧的模型”，依赖其模型的软件“可能需要偶尔更新才能继续工作”。Anthropic 的模型弃用页面说法大致相同：随着更安全、能力更强的模型推出，较旧的模型会被定期退役，应用可能需要偶尔更新。Gemini API 的发布说明也按类似的发布与退役节奏推进。
从这三家身上可以看清一点：退役不是供应商或你的团队的失败。它是一个附带日期、按计划发生的事件，这意味着它可以像其他任何维护工作一样被规划、编入预算并自动化。
2026 年 10 月的这批是最新的现成例子：关闭汇总列出了每一个停止工作的快照及其替代方案。
弃用演变成事故的三种方式
大多数弃用带来的痛苦来自三种模式之一。
1. 影响范围未知。模型 ID 是有版本的依赖项，它们会积累在出人意料的地方：应用代码、环境变量、CI 配置、基础设施即代码、评估脚本和仪表盘。通知到来时，第一个问题就是该 ID 用在哪里；如果回答这个问题需要翻箱倒柜，迁移的成本就已经很高了。
2. 术语被误读。“已弃用”并不意味着“已经坏了”。OpenAI 和 Anthropic 都把已弃用的模型描述为在公告发布时仍可正常使用。把“坏了”听进去的团队会过度反应；把“不急”听进去的团队会一直拖到关闭日期，那时请求开始失败，切换就变得紧迫。
3. 把替代模型当成可直接替换。更新的模型并不自动是它所替代模型的超集。输出结构可能漂移，工具调用 schema 可能变化，参数可能被移除。Gemini API 2026 年 9 月 17 日的发布说明就说明了这一点：该条目指出，对于在本地运行工具的团队，内置工具参数改为 PascalCase，文件编辑变为行范围替换。只替换模型 ID 的迁移会让这些调用方出错。
各家供应商眼中的“已弃用”
每个平台都发布自己的术语体系，这些词背后有具体的机制，在动手规划之前值得先弄清楚。
OpenAI 的弃用页面记录其已弃用的模型和端点以及推荐的替代方案。它把弃用定义为“退役模型或端点的过程”。公告发布时，该模型或端点立即变为已弃用，并且始终附带一个关闭日期；到了该日期它便无法访问。该页面把“sunset”和“shut down”当作同义词使用，并把“legacy”模型和端点标为不再接收更新、预期将来会被弃用的对象。对于确实无法按时迁移的团队，页面提到可通过销售团队获得在关闭日期之后继续访问的专用容量。
Anthropic 的模型弃用页面使用四个生命周期术语。Active 表示完全支持并推荐使用。Legacy 表示模型将不再接收更新，之后可能被弃用。Deprecated 表示模型仍可正常使用但不再推荐，附带已公布的替代方案和退役日期。Retired 表示模型已不可用，对它的请求将失败。
每页上最关键的那句话是一样的：已弃用的模型仍然可用。这正是团队误判窗口的原因，也正是应当围绕这个窗口来设计流程的原因。
模型弃用迁移：按最短的通知窗口来设计
通知窗口因供应商和模型类别而异，所以要按你技术栈中最短的窗口来规划，而不是最宽裕的那个。
Claude 的退役通知按明确的时钟走：Anthropic 表示，对于即将退役的模型，它会通知有活跃部署的客户，“对于公开发布的模型，在模型退役前至少提前 60 天通知”。注意这个框架：通知发给正在活跃使用该模型的账户，且该页面针对的是 Anthropic 运营的平台。Amazon Bedrock 和 Google Cloud 等合作方运营的平台有自己的退役时间表，因此模型的状态和日期在那里可能不同。
OpenAI 在公告弃用的同时给出关闭日期，其页面按模型类别说明最低通知期：正式可用模型至少六个月，专用变体至少三个月，而预览模型可能只提前很短时间退役，例如两周。页面还补充说，安全或合规方面的考虑可能缩短其中任何时间线。
Gemini API 的发布说明节奏更快。根据官方发布说明，2026 年 9 月 17 日的条目发布了 antigravity-preview-09-2026，“它取代并弃用 antigravity-preview-05-2026”，较旧的 agent 于 2026 年 10 月 5 日关闭。同一份发布说明还记录，现有的 gemini-omni-flash-preview 端点将于 2026 年 9 月 30 日弃用。这类日期会随计划变化而变动，所以请把变更日志当作实时参考，而不是本文。
从这三者中得出的规划规则：按你能找到的最短通知期来设定迁移流程、人力和告警的规模。如果你的流程能承受两周的预览模型退役，那么六个月的窗口就是白送的。
清点：把每一个硬编码的模型 ID 找出来
在动代码之前，先找出即将退役的模型在哪些地方被引用。把模型 ID 当作有版本的依赖项，像搜索固定版本的库那样去搜索它们：仓库源码、环境与部署变量、CI 配置、基础设施即代码、评估工具、仪表盘，以及任何调用该 API 的内部工具。
然后把源码层面看到的图景与供应商自己的视角核对。Anthropic 记录了确切的路径：在控制台打开 Usage 页面，点击 Export，查看下载的 CSV，它按 API key 和模型细分用量。这份导出回答了 grep 无法回答的问题：今天还有哪些 key 在调用即将退役的模型。两者不一致时，以导出为准。
在控制台里还有一件运维细节：两家供应商的通知都只发给正在活跃使用某个模型的账户和部署，所以请确认你的账单和账户设置里的邮箱是一个有人负责、有人盯的别名地址。
用别名层解耦调用点
弃用之所以伤人，是因为模型 ID 就住在调用点上。修法是结构性的：让业务代码引用逻辑别名，例如 summarize、extract-fields 或 code-review，并在一个地方把每个别名解析为具体的模型 ID——一个小注册表或配置文件，由你的服务在启动时读取。
下一次通知到来时，迁移就变成改一张映射表，而不是翻遍每个服务。注册表还记录每个映射存在的原因：它通过了哪些测试、何时被评审、它替代了什么。
这种模式在单个 OpenAI 兼容端点上运行得很干净，这也是平台文档在搭建时值得一看的原因。String AI 的文档描述了一个 base URL (https://www.string.ink/v1)，提供与 OpenAI Bearer 兼容的接口，另有一个列出 key 可访问模型的 models 列表接口。如果你要把多个工具整合到一个端点上，我们关于用一个 key 运行 Codex CLI、Claude Code 和 Cursor的指南覆盖了集成侧；别名层是它在代码侧的对应物，正是它让未来的切换变得便宜。
先在黄金集上验证切换
不要凭感觉迁移。用真实流量构建一组固定的代表性输入作为黄金集，并附上预期输出断言，在改变路由之前让新旧模型并排运行。有三类失败值得显式检查。
- 输出形态漂移。如果下游代码要解析 JSON、抽取段落或对模型输出做正则匹配，请确认结构仍然成立；人读起来没问题的回答，仍可能让解析器崩掉。
- 工具调用与结构化输出。agent 会依据返回的调用采取行动；请验证工具调用的载荷仍然有效，任何结构化输出模式的行为仍然正常。
- 被移除的参数与能力。替代模型不保证接受旧模型接受过的每一个参数，也不保证支持你 prompt 所假设的每一项能力。要测的不是新模型能不能用，而是你的用法在它上面还能不能用。
把结果记录在注册表条目里。失败的检查要么修好，要么带截止日期延期处理，而不是默默接受。
逐步切换，让旧路径触手可及
路由变更值得按部署级别的纪律来处理：先放一小片流量，保持旧 ID 配置在位且可达，只有在冒烟测试和错误预算都保持干净之后才删除它。因为别名层只在一个地方解析，切回去就是改一行，而不是到处重新部署。
切换验证通过后，趁上下文还新鲜就做清理：从注册表移除失效的模型 ID，从文档中移除相应条目，并删除为过渡临时加的任何熔断措施。失效的 ID 和仅供应急的代码路径，正是下一次弃用变得混乱的原因。
让下一次退役变得无聊
两个轻量自动化就能消掉剩下的大部分意外。
第一，把“这个模型 ID 还存在吗？”变成一项检查，而不是一次发现。在启动时或 CI 中，把配置里的每个模型 ID 与端点的 models 列表比对；缺失的 ID 应当快速失败，而不是作为生产错误暴露出来。models 列表接口返回某个 key 可访问的模型，这让比对只需几行代码。
第二，按计划比对这份列表并对变化告警。每周对 models 列表做一次 diff，配合常规监控，可以标出新增和变化，并抓住配置漂移，例如某个环境仍指向旧的 key。
最后，写一页运行手册：通知到来时由谁评估替代方案、哪些别名条目受影响、回滚目标是什么、切换如何验证。运行手册把跨团队的慌乱变成一张清单。
LLM API 迁移清单
- 阅读退役通知并记下关闭日期。已弃用还不等于坏掉；日期才是关键。
- 拉取供应商侧的用量导出，列出仍在调用即将退役模型的每个 key 和服务。
- 在仓库、CI 配置、基础设施即代码和仪表盘中搜索硬编码的模型 ID。
- 在每次变更前后，确认该模型 ID 存在于端点的 models 列表中。
- 更新别名注册表，而不是调用点。
- 在候选替代模型上运行黄金集；检查输出形态、工具调用和参数。
- 对一小片流量做金丝雀；在冒烟测试通过前保持旧模型可达。
- 用真实任务验证，然后删除失效的 ID 和临时兜底。
- 把决定记录在注册表条目中，并更新团队运行手册。
- 为 models 列表 diff 排定计划，让下一次通知永远不是你的第一个警告。
这些都消灭不了退役。它只是让退役变便宜：改一次映射、跑一次测试，以及一条在关闭日期之前而不是之后到来的告警。
相关阅读
- 别再让每个 AI 模型什么都做：把研究、写作和评审分配给不同的模型，而不增加协调工作。
- 开发者文章：平台的安装指南和集成说明。