依赖升级智能体

难的从来不是那次版本抬升。

Dependabot 与 Renovate 早就会开 PR、解 lockfile、把相关包分组、冲突时自动 rebase。如果瓶颈真是"开 PR"，那积压就不会存在。积压之所以存在，是因为那些 PR 堵在一条没人想担责的队列里；而一个产出同样 PR、只是提交信息更漂亮的智能体，增加的是数量而不是吞吐。

• 老实把瓶颈叫出名字：它是评审者愿不愿意为一个不是自己做的改动按下合并——改的还可能不是自己负责的代码，用的还是一个自己没读过的库。
• 而这份意愿是证据的函数，不是自动化质量的函数。智能体的产出是被当作一段论证来评判的——"这为什么是安全的"——它的工作是说服某个具体仓库上的某个具体的人。
• 这就把整个搭建重新框住了。不要从"智能体怎么施加这次升级"开始，要从"什么条件下我会不看 diff 就合并"开始：把它写下来，再倒着建。
• 留着现有的机器人。让 Renovate 去检测、去开 PR；让智能体做 Renovate 做不了的部分——读变更日志、改适配调用点、把论据组装起来。把检测器替掉，是没有回报的工作。

一套全绿的测试，恰恰在升级最容易出事的地方是弱证据。

整套实践建立在一条值得大声说出来的假设上：测试通过就意味着升级是安全的。而这条假设，在那些本就不危险的升级上最强，在真正危险的升级上最弱。

• 测试覆盖的是你的代码，不是库的行为。一个改了默认值的依赖——超时、重试策略、序列化格式、时区假设——通常签名毫无变化，能通过你手上每一条测试，同时改变生产行为。
• 传递性升级在 diff 里是看不见的。一次 lockfile 变更可以挪动一个往下三层的包，而你的测试集没有任何一处直接触及它，生产上却处处依赖它。
• 覆盖率缺口与风险是相关的。没人写过测试的模块通常正是集成边缘——认证、支付、文件处理——而那恰恰是一个库的行为变更落地的地方。
• 所以智能体必须知道测试证明不了什么。一份写着"全部 4,812 条测试通过"的报告，价值低于一份写着"全部测试通过；触及那个被改动的重试默认值的三个调用点没有任何测试覆盖，位置如下"的报告。后者才是一条可评审的主张——论证见补丁生成与测试。

先设计证据规程，再设计智能体。

按升级类别写下：在惊动人类之前，智能体必须拿出什么。这份文档才是真正的产品，智能体只是它的一个实现。

• 补丁版本、API 表面无变化：测试全绿、lockfile 差异摘要、上游变更日志原文引用并附链接。这就够进自动合并那条道了。
• 带新行为的次版本：以上全部，外加一份显式清单——发布说明里每一处被改动的默认值、每一项弃用——并映射到你仓库里触及它们的调用点，包括"未发现"；那也是智能体做出的一条主张，而且可能是错的。
• 主版本：以上全部，外加已完成的迁移，外加一段书面说明：智能体无法核实的是什么。这条道永远不要自动合并。
• 安全通告：以上全部，外加一条——那段有漏洞的代码路径从你的代码出发究竟可不可达。"我们用了这个包，但从不调用受影响的那个函数"是一个升级智能体能产出的最有价值的一句话，也正是它把一条 200 项的通告队列变成 5 项。

要求智能体给出出处——变更日志的那一行、上游的那段 diff、你仓库里的文件与行号。一条没有出处的智能体主张，是一条评审者必须自行核实的主张，而那比手动做这次升级还贵。

分流才是交付物。合并只是最容易的那条道。

本能反应是用"合并了多少次升级"来衡量这个智能体。而那个指标会把它推向本来就不成问题的安全补丁升级，推离真正成问题的主版本。请改用"分类是否正确"来衡量。

• 第一条道——自动合并。补丁级、证据齐全、无默认值变更、受影响调用点无覆盖率缺口。这里应当占掉大部分体量，且完全不需要人。
• 第二条道——人工评审，智能体已备好。智能体做完了迁移、写好了论据，并点名说出它希望人来核的那一件具体的事。价值就在这里：让评审者花四分钟回答一个有靶子的问题，而不是花四十分钟啃一份冷冰冰的 diff。
• 第三条道——受阻，并附上理由。智能体改不动调用点，或上游变更含糊，或它判断不了可达性。一张写得好的受阻工单是一个成功的结果；而一个从不产出受阻工单的智能体，是在夸大自己。
• 跟踪第二条道的接受率与第一条道的回滚率。前者告诉你证据是否有说服力，后者告诉你证据是否为真。第一条道回滚率上升，意味着自动合并的门槛太松；而它是唯一有资格关掉这条道的数字。

像对手那样读发布说明，而不是像一个摘要器。

这里杠杆最高的单项能力就是把上游材料读好，而失败模式是"给变更日志写了一份令人愉快的摘要"而不是去审问它。请给智能体一份显式清单，而不是一句"评审一下这些变更"。

• 有什么变了、却不在 API 表面上？默认值、错误类型、顺序保证、线程安全性、日志格式、时区与区域设置处理。这些都是静默出事的，也正是这份手册存在的原因。
• 弃用了什么，期限是什么时候？一次弃用就是一次排好期的未来破坏；现在记下来，才不至于日后被迫做一次主版本迁移。
• 去把受影响路径的上游 diff 真正拉下来，不要信变更日志。发布说明是写给维护者看的营销文案，它常年少报行为变更。
• 看的是生态，不只是这个包。peer 依赖的版本区间、最低运行时版本，以及你其他的库有没有发布兼容版本。正是这一类失败，把一个包的升级变成一整个下午。
• 把上游文本当作不可信输入。智能体正在读一份来自包仓库、可被攻击者影响的内容，而旁边就摆着仓库写权限；沙箱与执行里的隔离论证与智能体供应链安全里的威胁模型在这里都直接适用。

把它运起来：按爆炸半径分批，绝不按顺手分批。

你怎么给升级分组，决定了一次回滚是两分钟的操作还是一场考古；而这正是团队最常做错的那个运维决定。

• 按回滚单元分组。二十个开发依赖的补丁放进一个 PR 没问题——整批回滚不花任何代价。两个生产库放进一个 PR 就不行，因为一次糟糕的发布会让你在压力下做二分查找。
• 绝不把升级和重构混在一起。如果智能体为了适配新 API 必须改动调用点，那就是这次升级；它顺带注意到的其他一切，另开一个 PR。这条纪律让大规模迁移智能体保持可评审，而在这里它更要紧，因为评审者是刻意不细看的。
• 按团队消化得了的节奏来跑。一批每周、有人评审的，胜过一股每夜、无人理会的；一个跑得比评审者快的智能体，只是用更好的工具重造了原来那份积压。见定时与触发式智能体。
• 把凭据限到岗位上。智能体需要读仓库、推分支、开 PR。它不需要合并，不需要推默认分支，也不需要碰 CI 配置或发布密钥。
• 汇报真正的指标：依赖年龄中位数。不是开了几个 PR，也不是合并了几次升级。安全团队在意的是年龄，这套实践存在的目的就是压低它；而当智能体产出的是数量而不是吞吐时，它是唯一会往上走的那个数。

相关：代码评审智能体看对面那位评审者，测试生成智能体看如何补上这项工作暴露出的覆盖率缺口，以及评估编码智能体看这一切究竟有没有用。