GitHub的Dependabot版本更新开始支持Agent Package Manager：只更新apm.yml里带引用的git依赖，不含安全更新，GHES要等3.24

2026年11月3日，GitHub更新日志宣布，Dependabot版本更新现在支持Agent Package Manager（APM），用来让AI智能体的技能、提示词和指令保持最新。具体做法是：Dependabot为apm.yml里声明的、受支持的git依赖开出更新拉取请求，如果仓库里有apm.lock.yaml，也会重新生成它。更新日志明确说，这项支持只覆盖版本更新，不包括安全更新。因此不能把这项版本更新支持当作APM依赖的安全更新请求；公告没有说明APM安全告警是否可用。Dependabot会按设定的计划检查受支持依赖的新版本。

开启方法并不复杂：在.github/dependabot.yml里加一条apm条目，指定apm.yml所在的目录，并选择更新计划。可用范围是：在github.com上对所有GitHub套餐正式可用，GitHub Enterprise Server要等到3.24版才会提供。所以自托管的企业用户暂时用不上，具体时间取决于自己的升级节奏。

更新日志只有几句话，细节在GitHub文档的APM一节，那里说明得更严格。Dependabot会更新dependencies.apm和devDependencies.apm下的条目，怎么更新取决于依赖是如何固定的。固定到语义化版本标签的，会更新到最新的语义化版本标签，普通标签和带包名的标签都可以，带包名的标签必须以包名开头，包名是仓库名或虚拟包路径的最后一段。固定到提交SHA的，会更新到最新的、带注释的、非预发布的发布标签所对应的提交，并把标签名作为注释加上。固定到分支的，会更新到该分支的最新提交，此时只有apm.lock.yaml会变，因为清单仍写着分支名，而且必须已经存在apm.lock.yaml。如果仓库有apm.lock.yaml，Dependabot通过运行apm lock来重新生成它，但不会在没有锁文件时创建一个。

文档给出的具体例子，可以帮助核对这些规则。写成octo-org/octo-skills#v1.0.0的依赖，会被更新到最新的语义化版本标签。带包名的标签长得像octo-org/octo-skills/skills/review#review-v1.4.0，标签以包名review开头。写成octo-org/octo-skills#加40位SHA的依赖，会被移到最新带注释发布标签所对应的提交，并加上类似“# v1.4.0”的注释。写成octo-org/octo-skills#main的依赖，会被移到main分支的最新提交。相对地，没有引用的octo-org/octo-skills、作为本地路径的./my-package，以及使用http://克隆地址的条目，都在跳过名单里。把自己清单里的每一类写法逐条对照这个名单，比阅读更新日志的几句话可靠得多。

这里是我们的解读，不是文档的内容：固定方式决定了更新的可审阅程度。语义化版本标签会在apm.yml里产生可读的改动，审阅者可以对照发布说明。提交SHA提供可复现性，Dependabot加上的标签注释会告诉审阅者这个提交对应哪个发布。想让智能体指令自动更新的团队，可能因此更愿意采用这两种固定方式，而分支固定应留给已经完全信任的依赖，因为那样审阅者几乎得不到信号。如果团队的规范要求每次变更都要有可追溯的版本号，那么带注释的发布标签是更合适的选择。

文档同时列出了不会更新的情况，这些才是最需要核对的地方：对象形式的条目（带git、registry、id或path的映射）和mcp条目；没有引用的条目，比如只写仓库名；本地路径条目；托管在Azure DevOps上的条目；使用http://或git://克隆地址的条目；写成YAML块标量或带转义序列的引号字符串的条目；缩写的提交SHA；以及清单设置了registries.default时的简写条目，不过使用显式克隆地址的条目仍会被更新。私有仓库通过git注册表支持，在dependabot.yml里配置。

这些条件的实际含义是，不是所有APM依赖都会被自动跟踪。许多团队习惯只写仓库名而不带引用，或者用本地路径引用共享的技能包，这些都会被默默跳过，不会出现在Dependabot的拉取请求里。启用之后，建议先看一次Dependabot的运行日志，确认自己关心的依赖确实被识别，而不是以为配置了条目就等于全部覆盖。

还有一点是我们的判断，不是更新日志的内容：技能、提示词和指令是智能体会照着执行的文本，更新它们等于改变智能体的行为。更新日志没有讨论审阅或信任控制，所以这类拉取请求最好像对待代码变更一样人工审阅，尤其是分支固定的依赖，因为分支更新只改锁文件，清单里看不出变化。