Versioned Dependencies 与 Change Boundary

AI Behavior 依赖会独立变化的 Model、Prompt、Tool、Schema 与 Retrieval Source，因此 Production System 必须显式 Version Boundary。

核心心智模型

可复现 AI Outcome 是一整套 Versioned Stack 的函数：Model / Provider Behavior、Application Code、Prompt、Tool Contract、Retrieval Corpus、Policy 与 Runtime Configuration。

为什么重要

即使 Application Code 完全没改，Product 也可能 Regression。Provider 会更新 Model，Schema 会演化，Knowledge Source 会替换，Prompt 也会编辑。如果 Trace 与 Release Evidence 没有 Version Identifier，团队就无法判断哪个 Dependency 改了，也无法复现 User 真正看到的 Behavior。

让会变化的 Input 可识别、可测试

为 Prompt、Model Configuration、Tool Schema、Retrieval Index 与 Policy Artifact 分配 Stable Version 或 Content Hash，并把 Identifier 记录到 Trace 与 Evaluation Run。升级 Dependency 前执行 Targeted Compatibility / Regression Check；高风险 Upgrade 应预先设计 Rollback 或 Fallback，而不是出问题后才临时决定。

例子：Schema Update 破坏 Tool Call

Tool Provider 增加一个 Enum，同时 Model Update 开始选择这个新 Value；旧 Application Code 无法识别。Incident Trace 如果只写“Tool Validation Failed”就很难归因。记录 Model、Schema 与 App Version 后，团队可以复现精确 Combination，并选择 Patch、Pin 或 Rollback。

常见失败模式

只记录 Application Commit SHA，却忽略 External AI Dependency 独立变化。
Prompt 或 Retrieval Data 改动没有 Reviewable Version Boundary。
一次同时升级多个 Major Dependency，导致 Attribution 消失。

工程启发

所有可能实质改变 Behavior 的 Dependency 都附上 Version Identifier。
可行时一次只改变一个 Major Boundary，并运行 Regression Evidence。
高风险 Dependency Upgrade 之前先设计 Rollback / Fallback。

关键结论

01Reproducibility 不只是 Code Versioning。
02Version Metadata 能把 Incident 转成可归因的 Change。
03Dependency Upgrade 应接受与 Code Release 一样的 Evidence Discipline。