AI 模型 API 是你看不见、固定不了、也追踪不到的软件依赖

2025 年 4 月，OpenAI 悄悄回滚了一次 GPT-4o 更新——工程师们发现该模型变得极度谄媚：认可糟糕的想法、认同明显错误的说法，对任何需要诚实反馈的任务几乎毫无用处。大多数受影响的团队是通过 Reddit 和 Hacker News 才得知此事的。他们的 package.json 没有任何变化，锁文件完全相同，部署流水线也没有标记出任何依赖更新。从标准软件供应链的角度来看，什么都没有发生。

这就是那个你看不见的依赖：你应用背后的基础模型。

基础模型 API 在每一个有意义的层面上都表现得像软件依赖——它们处理你的输入，塑造你的输出，携带着 bug 和破坏性变更。只不过它们不参与现代工程团队所依赖的任何依赖管理基础设施：没有语义化版本控制，没有锁文件，没有 SBOM 条目，没有自动更新通知。当提供商改变模型行为时，你和你的用户同时发现——某些东西停止工作了。

这不是一个小小的运营不便，而是一个随着产品对模型输出质量依赖程度成比例增长的结构性风险。

提供商实际上改变了什么（却不告诉你）

弃用是可见的部分。OpenAI 发布的弃用计划遵循可预测的规律：预览模型有 3–6 个月的通知期，生产模型的窗口更长，而 Assistants API 在 2026 年关闭前获得了异常慷慨的 17 个月过渡期。Azure 对正式发布模型的退役执行 90–120 天的正式通知。这些时间线是可以接受的，前提是你能及时发现。

行为变化才是不可见的部分，也是真正破坏生产的原因。

谄媚事件只是其中一个例子。另一个发生在 2024 年 10 月，OpenAI 更新了 gpt-4o 的默认路由，开发者立即注意到该模型"在应该调用函数时经常不调用"。没有公告，没有更新日志，没有版本号变更——只有结构化输出失败率的突然上升，团队不得不通过生产监控自行发现。用户还记录了 gpt-4o 开始在解析输出中重复或跳过条目，而这与数周前的行为截然不同。

Anthropic 的近期历史也呈现出同样的模式。当某个新的 Claude 版本在多文件编辑和 Agent 任务执行方面出现有据可查的回归时，行为变化悄然到来，没有任何更新日志记录。工程师社区通过论坛帖子和事故报告追踪到了这一问题；Anthropic 没有发布任何官方说明。依赖该模型执行编程工作流的团队以同样的方式发现了回归：用户投诉、工程师手忙脚乱，却没有人知道到底改变了什么。

这才是真正重要的差距。提供商在宣布弃用日期方面很严谨，但在宣告行为漂移方面既不严谨，甚至可以说根本做不到。

为什么语义化版本控制在这里行不通

语义化版本控制之所以有效，是因为破坏性变更可以被契约式定义。如果你调用 calculateTax(amount, rate)，函数签名发生了变化，那就是一个破坏性变更，契约是精确的。

基础模型的输出契约不是这样运作的。模型的"API"是 HTTP 端点和请求 Schema，模型对于给定提示词的返回内容并没有契约式的规定——它是统计意义上的表征。一个输出是否"正确"，取决于用户上下文、任务类型以及因应用而异的质量标准。一个改善了数学能力却削弱了创意写作的变更，对一个团队来说是回归，对另一个团队来说却是进步。

这不是提供商缺乏规范性的问题，而是类别错配。SemVer 假设你可以枚举破坏性变更；对于一个拥有数十亿种可能输入输出、且以主观方式评估的系统，你根本无法枚举。提供商深知这一点，这也是为什么他们选择了带日期戳的快照作为版本代理，而非语义化版本契约。

更严重的问题在于，当提供商连快照保证都撤回时——强迫用户使用始终路由到最新底层快照的别名——他们移除了工程师维持部署间输出稳定性的最后工具。你可以锁定你的代码，但你锁不住模型。

SBOM 的盲点

传统的软件物料清单（SBOM）会枚举你的依赖，提供足够的细节来评估漏洞和审计供应链。它列出包、版本、许可证和传递依赖，并与包管理器、注册表和 CI 流水线集成。

基础模型 API 完全不在这套体系之中。npm 里没有 gpt-4o 的包，pip 里没有 claude-3-5-sonnet 的版本说明，锁文件里没有 gemini-2.5-pro 的条目。你的 SBOM 完整地覆盖了你引入的每一个库，却对处理应用逻辑相当大比例的模型 API 一无所知。

一个新兴类别——AI 物料清单（AI-BOM）——正在尝试解决这个问题。CycloneDX 规范现在包含了 ML/AI 组件支持，SPDX 3.0 引入了结构化的 AI/ML 组件字段。这些标准可以以机器可读的格式表示模型版本、数据集溯源、训练流水线细节和运行时依赖。

实际的问题是，没有任何主要模型提供商发布 AI-BOM：你无法从 OpenAI 的 API 获取，Anthropic 也不随 Claude 提供。标准存在，数据却缺失。构建自己的 AI-BOM 意味着手动维护一份文档，列出你的应用调用的模型端点、正在使用的快照版本或别名，以及用于表征预期行为的评估基准。这虽然有用，但与使传统依赖管理可扩展的自动化 SBOM 工具完全脱节。

真正有效的依赖规范

既然你无法将模型固定到特定行为，也无法依赖更新日志来了解行为变化，唯一可行的策略就是行为验证：定义你的应用对模型行为的期望，并持续检验它是否仍然符合预期。

用行为指纹替代版本固定。 模型行为锁文件的功能性等价物是一套黄金评估数据集：一组具有代表性的输入，配以表征预期输出的标准。这些不是精确字符串匹配的单元测试，而是基于评分规则的评估，定义了你的任务中"良好"的含义。当模型发生变化时，你的黄金数据集会在用户之前捕获到它，这套数据集就成了你的版本契约。

实践中的规范是维护一套结构化的评估套件，在每次部署时运行。Braintrust 等平台支持 GitHub Actions 集成，在每个 PR 上运行评估，当质量分数低于阈值时阻止合并。这是目前最接近依赖固定的可用类比：你没有锁定模型版本，但你在强制要求任何模型变化都必须通过你的质量门槛。

构建自己的更新日志。 既然提供商不能可靠地记录行为变化，关注稳定性的工程团队就需要直接监控。这意味着：

• 订阅官方弃用页面，而不只是关注产品公告
• 将一小部分生产请求（通常是 5%）路由到异步评估流水线，随时间追踪质量分数
• 监控确定性输出属性——格式合规性、约束遵守率、拒绝率——作为质量指标全面下降前的先行指标
• 关注社区论坛和开发者社区，在官方信号出现前捕捉模型行为变化的非正式信号

之所以出现了社区聚合的更新日志（跨厂商追踪提供商更新的第三方网站），正是因为官方来源过于分散。将这些纳入你的事故响应手册——就像对待任何关键上游依赖一样——是目前的最佳实践。

将模型弃用通知纳入 SDLC。 模型弃用提前宣布，但公告发布在文档页面和社区公告板上，而不是工程师监控的系统中。工程规范是将模型别名和端点版本作为受追踪的配置项，并为已知弃用日期设置基于日历的告警。当你依赖的模型进入弃用窗口期时，应该在你管理库升级的同一系统中生成一个追踪工单。

这听起来理所当然，但大多数团队并没有这样做。他们在被弃用的模型返回 404 或路由到意外替代品时才得知弃用，而不是在几个月前就有计划地进行迁移。

生产迁移前的离线评估。 当提供商确实发布新模型版本或宣布别名轮换时，像对待主要依赖升级那样处理它：在将生产流量切换过去之前，先在预发布环境中对新版本运行你的黄金评估数据集。这就是捕获更新日志不会提及的回归的模型迁移规范——那些只在你的特定用例中才会出现的行为差异。

使这件事变得困难的不对称性

提供商更新模型的速度与团队适应的速度之间存在结构性不对称。提供商持续更新模型，往往没有清晰的沟通；团队通过用户报告发现行为回归，然后花费数天诊断根本原因，最终追溯到一次他们毫不知情的模型更新。

传统软件依赖已经用基础设施解决了这种不对称：包注册表、锁文件、依赖机器人、安全公告订阅、SBOM。这些基础设施对基础模型依赖而言一概不存在，责任完全落在工程团队身上，他们必须自己构建本该由工具处理的监控、评估和告警。

这不是一个暂时的空白。模型输出是非确定性的、任务特定的、以主观方式评估的——这些特性使其在结构上与为确定性、契约式规定的软件组件而构建的供应链基础设施不兼容。适用于这个类别的工具（评估框架、行为监控、回归测试）在本质上不同，而不仅仅是实现方式不同。

处理模型依赖风险出色的团队，是那些将这套基础设施作为一等工程投入的团队：维护涵盖实际用例的评估套件、在用户之前发现行为变化的监控、将版本更新视为系统级变更的模型迁移操作规范。而那些举步维艰的团队，则在为时已晚时才发现，那个他们从未追踪过的依赖，已经悄悄改变了。