8.0
热点
AI SCORE
技术实践2026-08-07 00:25
为智能体建立可迁移的模型生命周期
dev.to · AI#模型迁移#Agent#可靠性
Editor brief · 编辑速览
文章以模型下线导致生产故障为切入点，建议减少不可预测的动态路由，稳定使用经过验证的模型。智能体基础设施还应支持版本监控、替换评估和迁移演练。
gpt-5.2-chat-latest 和 gpt-5.3-chat-latest 将于 2026 年 8 月 10 日停止服务，也就是六天后。此后，它们将直接返回错误。
如果你的 Agent 背后使用了其中一个模型，那么这个日期就不是什么产品新闻，而是一场已经提前预告的生产事故。你的代码和 prompt 可以完全不变，基础设施也可以一切正常，但应用仍然可能突然崩溃。AI 团队往往会低估这种故障模式，因为他们自己的技术栈并没有发生任何变化。
我们曾经认为，网关应该为每一个 prompt 选择最合适的模型。因此，我们构建了一个路由器，根据请求的复杂程度进行分类，再把不同请求发送给不同的模型。这个设想听起来很合理：简单任务使用便宜的模型，困难任务使用昂贵的模型。最终，我们亲手废弃了它。
prompt 中没有足够的信息来预测完整任务。切换模型会让行为变得更不一致。为了节省成本而引入的不确定性，反过来又需要团队投入精力去评估、观测和维护。
这个教训让人有些难以接受：更频繁地选择模型，并不会让 Agent 变得更加可靠。
对于大多数工作负载，你都应该有意识地选定一个模型，了解它的行为，并保持其稳定。围绕这个模型搭建的基础设施，应当专注于另一项工作：当现实不再符合你的假设时，确保应用仍能继续运行。
团队通常把模型弃用当作 changelog 中的例行事项，但它实际上更像一张即将过期的证书。提供商公布一个日期，endpoint 随后几个月仍然可以正常使用，一切看起来都不紧急，于是迁移任务便一直躺在 backlog 里。
然后日期到了，昨天还能正常使用的模型 ID 突然返回 404。面对一个已经不再响应的依赖，Agent 无法通过推理绕过问题；如果原本应该向用户解释故障的正是这个已退役模型，那么它甚至无法告诉用户发生了什么。
可靠性始于请求发出之前。
重试可以应对暂时性的 timeout，fallback 可以应对提供商服务中断。但它们都不会告诉你：主模型已经有一个公开的停止服务日期。你必须在还有时间测试替代模型时收到预警。
这正是我们构建 modeldeprecations.dev 的原因。它是一个开源的 AI 模型生命周期目录。对于每个模型，它都会回答那些对实际运维至关重要的问题：
每个日期都会链接回信息来源。如果某个日期无法得到验证，目录会将其留空，而不是凭空猜测。
真正有用的不只是这个网站。相关数据还以 JSON 和 Markdown 格式提供，并配有日历 feed、changelog feed、状态徽章以及 Agent 可读取的文件。Agent 可以在启动一项耗时较长的工作流之前，检查自己的依赖。CI job 可以标记已经 deprecated 的模型。团队可以订阅模型停止服务日期，而不必依靠某个人记住提供商发布的公告。
这是一项很小的基础设施，而且这是有意为之。可靠性来自那些平淡无奇的检查——在问题变得紧急之前，你就已经在持续执行它们。
知道某个模型即将消失，只能为你争取时间，却不能保证 uptime。你仍然需要一套恢复方案。先从最朴素的版本开始：
两者的区别在于意图：主模型是一项产品决策，而 fallback 是一项可用性决策。混淆这两者的团队，最终会得到一个行为随每次请求不断漂移的 Agent。
网关不应该在每次请求时临场决定主模型。它的职责是避免某个提供商错误、异常请求或已经 retired 的依赖拖垮整个 Agent。
用户并不关心提供商是否更改了模型 ID，或者拒绝了某个参数。他们只关心应用是否正常工作。
Manifest 正是围绕这一理念构建的。它在不同提供商前提供一个兼容 OpenAI 的统一 endpoint：记录完整的请求体和错误响应体；当查询失败时，可以 fallback 到另一个已配置的模型；还可以在受支持的请求端错误抵达用户之前对其进行修复。目标不是让模型选择变得更加神秘，而是尽量不让用户感知到故障。
模型还会不断变化：有些模型会在内部进行路由，有些会彻底消失，与之相关的旧假设也会随之失效。你的 Agent 应该能够从这一切变化中存活下来。
请前往 modeldeprecations.dev 检查你的 Agent 所依赖的模型，并确保它的退役日期不会同时成为你的应用停止运行的日期。
如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。