模型退役：你上线了一个带保质期的依赖，而它不在你的 lockfile 里。
你代码里的每一个模型 ID，都会在别人挑定的某一天被关掉，而你拿到的通知以周到月计——Anthropic 承诺对公开发布的模型至少提前 60 天，而某些平台侧的退役给的时间还要短得多。真正的错误是把这件事归进"维护"。替换模型是另一个系统，有另一套失败模式，所以一次迁移就是一次重新资格认证，而那个通知窗口就是你全部的回归测试预算。等邮件到了才发现这件事的团队，会把这段时间用来慌；演练过的团队用一天。
那个你无法 vendor 的依赖。
你栈里其他每一个依赖都有退路。某个库不再维护，你就把最后一个好版本永远钉住；某个包仓库挂了，你就从镜像发；某家厂商涨价，你就继续跑手上已有的。托管模型一个都没有。退役日期一过，对那个模型 ID 的请求就会失败，而磁盘上没有一份副本可退。
这让它成为一个确实不寻常的依赖，也值得不寻常的对待：
- 它按别人的时间表过期。你没有投票权，日期由"继续服务旧权重的经济性"决定，而不是由你的发布日历决定。
- 它冻结不了。"我们下季度再升级"这个选项对你用的每一个库都成立，对你的模型一个都不成立。
- 它的替代品并不等价。打了补丁的库保持契约不变。更新的模型不会——那恰恰是它存在的全部理由。
- 爆炸半径是行为上的，不是结构上的。什么都不会编译失败。智能体只是开始做一些略有不同的事，而那要难察觉得多。
模型 ID 值得被当作 lockfile 里的钉死版本来对待，外加一样 lockfile 没有的东西：过期时间。维护一份清单——每一个模型 ID、用在哪里、哪个团队负责、已公布的退役日期——并且把"清单里缺一项"当作构建期失败来处理。如果你没法在一分钟内列出你的模型 ID，那你的迁移已经开局不利了。
通知窗口，以及为什么最短的那个决定你的排期。
厂商确实有公开政策，而且并不算不讲理。Anthropic 承诺在公开发布模型退役前至少 60 天通知有活跃部署的客户，并有成文的生命周期——Active、Legacy、Deprecated、Retired——每次状态转换都有邮件加文档通知。OpenAI 有一个 deprecations 页面，给基础模型的窗口比给专用快照的更长。这些政策是真实的，值得从厂商自己的页面上完整读一遍，而不是读某份摘要。
但关于它们，仍有两件事在实践中咬人：
- 要紧的是那个下限。"至少 60 天"是关于最坏情况的承诺，而你应该按最坏情况来排——因为让你后悔的那个模型，恰恰是拿到下限的那个。60 天听上去很宽裕，直到你减去"没人读那封邮件"的两周、工作真正落进的那个迭代，以及"替代品需要一整轮评测"这个事实。
- 面向消费者的时间线和市场平台的时间线是分开的。从某个聊天产品里退役的模型，未必从 API 上退役；而同一个模型通过某个云市场提供时，走的是那个市场的日期，不是实验室的日期。如果你是通过转售方消费模型，那转售方的排期就是你的排期。
由此得出的排期结论是一条常设假设，而不是一条日历项：假设你栈里每个季度至少有一个模型进入退役。一旦接受这一点，迁移就不再是一个打断路线图的项目，而变成一项有演练好运维手册的周期性操作——这也是这件事唯一能规模化的版本。
迁移是一次重新资格认证，不是一次字符串替换。
改动本身只有一行。所有昂贵的东西都在它下游，因为你换掉的不是一个组件——你换掉的是决定你的智能体做什么的那个东西。下面这四样都会动：
- 提示词敏感性。针对某个模型脾气调出来的指令，放到下一个模型上最好的情况也就是中性。当初修好某个格式问题的那几个 few-shot 例子，现在可能正是引起问题的原因。任何写成"针对某个具体失败的绕行方案"的东西，都是删除的候选，而不是翻译的候选。
- 工具调用行为。schema 的严格程度、愿不愿意并行调用、失败后重试的意愿、倾向于编一个参数还是回来问——这些都因模型而异，而且没有一样写在发布说明里。智能体迁移真正会断的，就是这一层。
- 步数与成本。一个八步就收工而不是二十步的更强模型，即使令牌单价更高，每完成一个任务也更便宜；而一个话更多的模型，即使单价更低也更贵。从实测轨迹重新推导单位经济，别从价目表推导。
- 延迟与缓存。不同的分词、不同的吞吐，以及一个从冷开始的缓存。切换当天你的 p95 会动，原因跟质量毫无关系；见提示词缓存。
正因为这四样一起动，唯一诚实的门禁是把你的评测套件跑成一次配对比较——同样的任务、同样的种子、新旧模型、放在同一批里。做不到这一点，你要么把噪声算到迁移头上，要么更糟，漏掉藏在里面的真实回归。这里的统计学在评测方差与统计功效里，而这套机制该放进你已经在用的那道发布与版本管理门禁里。
要为"替代品在你这个负载上更差"这种可能性留预算。这会发生，尤其当一个通用后继者取代了一个你曾围绕它调优过的模型；而应对办法不是去跟退役日期争辩，而是足够早地发现，以便在还剩几周而不是几天的时候去评估第二个候选——可能来自另一家厂商。
自动升级：那次没人选择的迁移。
有些平台不只是退役一个模型；它们会把你搬过去。Azure 就曾在退役时对标准部署做强制升级——2026 年 3 月，GPT-4o 的两个 2024 年快照到期时，那些部署被自动迁到了当前模型，而不是任其失败。从平台可用性的角度看，这是体贴的做法。从智能体运维的角度看，这是最糟的结局，因为它把一次响亮的失败换成了一次静默的行为变更。
想想你更愿意排查哪一种。硬失败会产出一个错误、一条告警、一份指向某个模型 ID 的调用栈。自动升级产出的是这样一个周二：你的智能体工具调用行为变了、你的评测没跑、而没有人有任何假设。第二种更贵，尽管它一分钟停机都没有。
- 搞清楚你的哪些部署可以在你不动手的情况下被搬走。这是一个按平台、按部署类型的问题，而答案通常藏在计费档位里——预留或预置容量往往和标准档待遇不同。
- 在有得选的地方，优先选显式失败。对一个已退役模型的请求报错，比它被另一个模型静默地服务掉要好，因为前者是一个已知原因的事故。
- 对响应里回传的模型标识告警，而不只是对你配置里的那个。厂商会回传究竟是谁服务了这次请求。如果那个字段变了而你没有任何一次发布导致它变，你会想在几分钟内知道。这是个很便宜的检查，而几乎没人做。
- 让流量走一层你能控制的东西。一个网关或路由层意味着模型 ID 只住在一个地方，切换它是一次带开关的配置变更而不是一次重新部署。见模型路由与智能体的功能开关。
那套常设演练。
能在一天内处理完退役的团队，并不是对模型更懂；他们只是提前建好了三样东西，而没有一样是奇技淫巧。
- 一份是生成出来、而不是维护出来的清单。每次构建都在代码库与配置存储里 grep 模型标识，遇到不在注册表里的就让构建失败。手工维护的列表一个月内就会错，而某个被遗忘的批处理任务里的那个模型 ID，恰恰就是会咬你的那个。
- 一条始终热着的候选通道。套件应当只改一个参数就能对任意模型 ID 跑起来，并且无论有没有退役在路上，都按固定节奏对当前的后继模型跑一遍——每月一次就够。这样通知邮件找到你的时候，你手上已经有一份新鲜的配对结果，于是迁移是一个决定，而不是一个项目。
- 一次演练过的切换。把开关拨到新模型，先放 5% 的流量，盯住轨迹指标与每完成一个任务的成本，并且能在几秒内拨回来。如果你对模型变更的回滚办法是重新部署，那你就没有回滚。爬坡期间该盯什么，见线上评测与线下评测。
还有一件事该写进运维手册，因为它在出事之前完全不可见：替代模型有一个不同的知识截止时间。你提示词里任何为了补偿旧模型时间盲区而存在的东西——注入的当前日期、硬编码的"截至某某"免责说明、只为覆盖近期事件而存在的检索步骤——都需要重新检查；而任何悄悄依赖"旧截止时间就在那个位置"的东西也一样。
这周该做什么。
第 5 步那套完整演练要一个季度才建得起来。有三件事一个下午就能做完，而且能移除大部分暴露面：
- 先把清单做出来一次，必要时手工做。每一个模型 ID、它出现的每一处、每一条一个负责人。多数团队会找到至少一个他们不知道存在的——一个批处理任务、一个评测评判器、一个嵌入模型、一条自写下来就没跑过的兜底通路。
- 今天就拿每一条去对照厂商自己的 deprecations 页面。不是摘要、不是某篇博客、也不是本页：是厂商那份实时的、唯一权威的、而且会变的列表。把公布的退役日期写在每个 ID 旁边。
- 确保退役邮件寄到的是一个值班轮转，而不是一个人。这类通知会寄给账单或账户联系人，而那常常是一个已经离职的人；一封躺着没人读 50 天的 60 天通知，就是一封两周通知。
先做清单，先于本页其他任何事。它是一小时的工作量，不需要任何新基础设施，而它把一个无界的风险变成了一份带日期的列表——到那时，剩下的每个决定都是可排期的。这件事出岔子最常见的方式，并不是一次难搞的迁移；而是一个没人知道在生产里的模型 ID，待在一个没人负责的服务里，在请求开始失败的那天被发现。
相关：如何选模型讲你每次都要重复的那次评估，智能体的事故响应讲它还是出事的那一天，模型家族讲怎么把厂商的产品线读到能预测你下一个要换的是哪个。