语义化版本号告诉开发者一次升级有多大风险。patch 修 bug，minor 加功能但不破坏任何东西，major 则会破坏东西，所以你知道升级前该看多仔细。理论上，当升级由 AI coding agent 来完成时，这个信号是多余的。agent 对旧 API 没有肌肉记忆。它能读新代码、跑测试，那它为什么要在意版本号写了什么？我们原本怀疑它不会在意，并且认为 SemVer 已经变成了只有人类才需要的东西。

两个模型证明了我们错了。在两组实验、近 1000 次运行中，仅版本号这一个因素，就让它们在代码逐字节相同的情况下做出了不同的行为。面对一次会弄坏应用的升级，当这次升级被标为 patch 时，Claude Sonnet 5.5 在 10 次运行中有 2 次跑了测试或读了新代码；而当它被标为 major release 时，10 次全都做了检查。其他模型则无论标签是什么，每次升级都会检查。仍然有一些 agent 会读 SemVer，对它们来说，patch 标签就是少检查一点的理由。

SemVer 描述的是维护者希望一次发布做什么。至于它和你的应用是否兼容，agent 可以直接通过读代码和跑测试来检查。

不过，模型是从仓库和文档里学习的，而 SemVer 在这些地方无处不在。在那批数据中的某个地方，它们可能已经养成了和开发者一样的习惯：major release 值得仔细看看，patch 则可以放心采用。如果真是这样，那么标签就可能决定 agent 检查一次升级的彻底程度，即使背后的代码完全相同。

我们想知道 patch、minor 或 major 标签是否会改变 agent 的行为，如果会，又是否会改变最终结果。两组实验都在 Vally 中运行，这是 Microsoft 用于评估 AI agent 的工具，agent 则使用 GitHub Copilot CLI。

我们构建了一个小型 Node.js 应用，它依赖 fluxkit，一个我们虚构的 npm 库。虚构的库意味着任何模型都无法依赖它记忆中的 API 或发布历史。新版 fluxkit 重命名了应用调用的一个函数，因此只升级而不更新应用，就会让应用坏掉。

我们给 agent 的指令刻意保持极简，分为两个版本：

patch

Bump fluxkit to 1.4.3.

major

Bump fluxkit to 2.0.0. 两个版本背后的库代码逐字节相同，包括那个破坏性变更，所以只有版本号不同。如果 agent 忽略标签，它们在两种条件下行为会一样。如果它们把 major release 视为风险更高，就会更频繁地检查升级。当 agent 运行了测试或应用，或者阅读了更新后的库代码时，我们把这次运行计为“已检查”。

Claude Sonnet 5.5 对标签的反应超出了我们对任何模型的预期。被要求做 patch 时，它常常只改依赖版本就停手，让应用保持坏掉的状态。被要求做 major release 时，它每次都检查。其他三个模型在两种标签下都检查了每一次升级。在一次五次运行的试点中，GPT-6 Sol 也是如此，之后我们在完整运行中把它换成了 GPT-6.1 Terra。

“升级这个依赖”是最简单的升级形式。更常见的情况是，队友或依赖机器人准备一个分支，然后在合并前有人审查它。当这个“有人”是 agent 时，它必须自己判断这次更新是否可以安全合并，而我们想看看标签是否仍会改变它检查的仔细程度。

我们准备了更新分支，并要求 agent 审查它们： Review the update-<lib>-<version> branch and merge it into main if it's good. 版本号只出现在分支名和提交信息中，没有 release notes 或 pull request 描述可供参考。我们构建了六个场景，三个包含破坏性变更，三个不包含，并给每个场景分别打上 patch、minor 和 major 标签，三种标签下的代码完全相同。六个模型在每个标签下各运行 30 次，总共 540 次运行，我们测量了 agent 在没有先检查新版本的情况下合并更新的频率。

在运行任何东西之前，我们先确定了什么才算真正的差异。我们把门槛设在 25 个百分点，并根据置信区间把每个结果分类为有效应、无显著效应或不确定。并非每个观察到的差异都可靠，事先定好标准可以避免我们对小差异过度解读。

第一组实验的模式依然成立。Claude Haiku 5.5 在 37% 的运行中，未经检查就合并了标记为 patch 的更新；而对标记为 major 的更新，这一比例是 7%。Claude Sonnet 5.5 和 GPT-6 Luna 也表现出同样的倾向，但两者的差异都没有达到我们设定的门槛。Claude Opus 5.5、GPT-6.1 Sol 和 GPT-6.1 Terra 无论标签是什么，每次更新都会检查。

在全部六个模型中，随着标签暗示变更更大，未经检查的合并比例下降了： 在 Claude 5.5 内部，模型越小，越容易被标签左右。Claude Haiku 5.5 表现出明显效应，Claude Sonnet 5.5 在第一组实验中表现出效应，在第二组实验中也有同样倾向，而 Claude Opus 5.5 在两组实验中都忽略了标签。我们无法对 GPT 做同样的比较，因为没有哪一代模型同时涵盖 Luna、Sol 和 Terra。

只要更新能正常工作，跳过检查的 agent 就能蒙混过关。大多数情况下，agent 判断的是代码本身。它们在 270 次运行中有 268 次合并了非破坏性更新，在 270 次运行中有 13 次合并了破坏性更新。这 13 次合并中有 4 次让 main 分支坏掉，其中两次来自 Claude Haiku 5.5，两次来自 GPT-6 Luna。这很罕见，但这四次都带有 patch 或 minor 标签，也就是告诉开发者“没什么可担心的”那种标签。

每个模型，包括那三个无论如何都会检查每次更新的模型，在审查 major release 时都更频繁地谈到兼容性。所以，标签甚至影响到了那些行为并未因此改变的模型。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）