依赖更新与升级自动化
仓库连续几周没有依赖更新 Pull Request，团队通常会得到一个危险的安慰：“最近大概没有新版本。”真正排查后，原因可能完全不同：机器人没有发现嵌套目录里的清单，私有 Registry Token 已过期，版本源被代理阻断，PR 数量达到上限，分组规则把候选全部过滤，Dependabot PR 长期无人处理后被平台暂停，甚至旧机器人卸载后再也没有新的 owner。页面上的安静不是健康证据，它只是缺少可见状态。
依赖更新自动化也不等于“定时把版本号加一”。一次更新会依次经过声明发现、版本查询、候选过滤、锁文件或不可变引用重算、隔离分支、PR、测试、审查、合并和运行观察。每一步都保存不同状态，也会以不同方式失败。机器人能创建 PR，只证明它走到了变更提议阶段；只有团队能够解释为何选中这个版本、实际解析成什么内容、哪些证据允许合并、失败后怎样回退，自动化才真正减少维护成本。
图中的 Manager 负责从文件中识别依赖，版本源负责回答有哪些候选；策略层才决定何时更新、如何分组、谁来审查。把三者混成“机器人没找到版本”，会让排障在配置、网络和权限之间来回猜测。锁文件、镜像 digest 和 Action SHA 也不是装饰性 diff：它们记录某次解析得到的实际供应链身份，审查时必须和上层版本约束一起看。
先证明仓库里的更新面没有失踪
新接入一个仓库时，先走依赖更新面盘点。它把每个版本引用记录为声明位置、解析器、版本源、可移动引用、不可变身份、派生锁、PR 更新单元和验证命令。这样才能看见 package manifest 之外的 Dockerfile、Compose、GitHub Actions、Dev Container、Terraform/OpenTofu、Helm 与自定义 YAML，也能识别同一引用被两套机器人重复管理的冲突。
发现引用后，再读版本约束、锁文件与不可变引用。^1.2.0、1.2.3、镜像 tag、镜像 digest、Action tag、Action commit SHA、provider 约束和 Chart.lock 表达的是不同承诺。更新 PR 必须同时回答“允许范围变了吗”和“实际选择的内容身份变了吗”，不能只看标题里的版本号。
选择机器人时先选择运行责任
Renovate适合需要跨生态 manager、datasource、共享 preset、精细 packageRules、自定义引用或 GitHub/GitLab 多平台接入的团队。托管 App 减少机器人基础设施维护，自托管则把运行版本、调度、网络、凭据、日志和升级责任交回团队。两种形态都需要从依赖抽取、版本查询到完整决策逐层验证，不能用“安装成功”代替仓库接入证据。
GitHub Dependabot与 GitHub 仓库、安全告警和平台工作流紧密结合。Version Updates 与 Security Updates 是两条不同链路；.github/dependabot.yml、仓库设置、Dependabot secrets、Actions secrets、分支保护与 Merge Queue 也处于不同安全边界。选择它时要按当前官方生态矩阵核对能力，并为未支持的引用保留其他更新路径。
工具选择不是终点。无论使用哪个机器人，都应该能从日志回答：配置从哪里加载，哪些文件被扫描，哪个版本源返回了候选，哪条规则匹配，为什么没有创建 PR，以及退出时哪些 App、Token、分支和定时任务必须清理。
把团队政策编译成机器可执行规则
更新策略、分组与调度处理的是更新流量，而不是做一张 major/minor/patch 标签表。稳定期、维护窗口、PR 并发、每小时创建速率、冻结期和例外必须组合起来，既避免新版本刚发布就冲入关键仓库，也避免限流把安全修复饿死。规则顺序和分组边界属于运行行为，改动后要用候选样本验证最终命中结果。
Monorepo 还会引入共享锁文件、内部包、多个项目目录和跨生态兼容单元。Monorepo 协同升级把“同一个仓库”和“应该进入同一个 PR”分开判断：某些更新必须原子合并，某些则应拆小以缩短失败定位。错误分组会让一条失败检查阻塞几十个无关依赖，错误拆分又会产生任何单个 PR 都无法通过的中间状态。
自动合并之前先建立可信证据
机器人能否读取私有包、创建分支和触发检查，取决于机器人身份、私有源与权限。版本查询和锁文件重建可能使用不同客户端与凭据路径；“查到版本”不证明“能重建锁文件”。App、Bot、Group Token、Registry Token 和 Secret 必须按仓库与主机收窄，日志脱敏、轮换恢复和撤销也要分别验证。
更新 PR 验证与自动合并把风险分类转换为检查集合、owner、分支保护和合并方式。低风险更新只有在必需检查确实存在且通过时才进入自动合并；数据库迁移、运行时大版本、基础镜像、构建插件和供应链身份变化通常需要更强证据。Merge Queue、rebase 和自动合并是平台状态机，不应由机器人作者身份绕过。
安全修复进入安全更新、例外与紧急通道。这里消费扫描与漏洞治理给出的修复结论，负责把紧急更新送入更快但仍有证据的路径。没有补丁、暂时忽略或必须回退时，要留下 owner、理由、到期条件、补偿控制和回补动作；“紧急”不能成为永久跳过验证的别名。
没有新 PR 时也要能看见系统状态
更新积压、可观测与故障恢复把“没有更新”拆成可诊断状态：没有发现引用、没有候选、策略延迟、PR 达到上限、身份失效、版本源限流、锁文件重建失败、CI 失败、等待审查、平台暂停或机器人根本没有运行。覆盖率、最老 PR 年龄、各阶段失败率、忽略项年龄和最后成功运行时间需要共同解释队列，而不是用 PR 数量一个指标代替健康度。
退出同样是运行链的一部分。先暂停新候选并保留观察窗口，再让旧机器人关闭或接管遗留 PR，撤销 App 与 Token，清理定时任务、Webhook、分支和缓存，最后验证没有第二套身份继续写仓库。团队能够在任何时刻指出“哪些引用被管理、候选停在哪一阶段、谁有权合并、失败如何恢复、怎样彻底退出”，依赖更新自动化才从一个会发 PR 的机器人变成可靠的研发基础设施。