用 APM 管 Agent Skills：锁版本，Dependabot 自动升级
GitHub 11 月 3 日（美国时间）宣布，Dependabot 的版本更新正式支持 Agent Package Manager（APM）。你项目里给 Copilot、Claude Code、Cursor 们装的 Skill、提示词和指令文件，从此可以写进 apm.yml 锁住版本，再交给 Dependabot 每周开 PR 升级。下面按 APM 官方文档和 GitHub 文档（2026-11-04 北京时间查阅），把装 APM、声明依赖、锁版本、开 Dependabot、在 CI 里查漂移这条链路走一遍。
APM 管的是 Agent 的「依赖」
APM 是微软开源的命令行工具，仓库 microsoft/apm，MIT 许可证，截至 2026-11-04 有 4185 个 star，最新版 v0.35.0 发布于 10 月 23 日（北京时间）。README 拿 package.json、requirements.txt 作比，它管的对象换成了 AI Agent 的配置。支持的客户端有 GitHub Copilot、Claude Code、Cursor、OpenCode、Codex、Gemini、Windsurf、Kiro 等。
常见的情况是团队里每个人手动 npx skills add，装的版本各不相同；上游 Skill 修了 bug，本地那份没人跟；新同事 clone 仓库后，Agent 配置要从头再配一遍。APM 的做法和 npm 一样，清单 apm.yml 写声明，锁文件 apm.lock.yaml 记下解析到的提交和内容哈希，apm install 在任何机器上还原同一套东西。
前置条件
- 一台 macOS、Linux 或 Windows（x86_64 有原生二进制），或者 Python 3.10+ 走 pip。
- 一个放在 GitHub 上的仓库，你有权限改
.github/。Dependabot 的 APM 支持在 github.com 所有套餐可用，GitHub Enterprise Server 要等 3.24。 - 知道自己项目用哪个 Agent 客户端。没有
.github/、.claude/、.cursor/这类标记目录时，安装要手动加--target。
第一步：装 APM，初始化清单
# macOS（Homebrew，无需额外 tap）
brew install apm
# Linux / macOS 不用 Homebrew
curl -sSL https://aka.ms/apm-unix | sh
# 或者用 pip
pip install apm-cli
apm --version
apm init my-agent && cd my-agentapm init 只写一个文件 apm.yml。第一天要看的就三项：dependencies.apm（Skill、插件等包）、dependencies.mcp（MCP 服务）、scripts（可选）。targets: 默认是注释掉的，APM 会按仓库里已有的目录自动判断要部署给哪个客户端。Homebrew 装的用 brew upgrade apm 升级，别用 apm self-update。
第二步：声明依赖，钉住版本
可以直接用命令装，APM 会顺手写进 apm.yml：
# 装一个带版本的完整包
apm install microsoft/apm-sample-package#v1.0.0 --target copilot
# 从 npx skills add 迁过来：整包或只要其中一个 Skill
apm install vercel-labs/agent-skills
apm install vercel-labs/agent-skills --skill deploy-to-vercel
# 加一个 MCP 服务，写进所有选中的客户端
apm install --mcp io.github.github/github-mcp-server --transport http手写清单也行，README 给的例子是这样：
name: your-project
version: 1.0.0
targets:
- copilot
dependencies:
apm:
- anthropics/skills/skills/frontend-design
- github/awesome-copilot/plugins/context-engineering
- github/awesome-copilot/agents/api-architect.agent.md
- microsoft/apm-sample-package#v1.0.0
mcp:
- name: io.github.github/github-mcp-server
transport: http注意这里前三条没有 # 后面的版本号。本地用没问题，可 Dependabot 不会碰没钉版本的条目，下一步会讲。官方 Quickstart 的示例输出里，一次 apm install 会把提示词放进 .github/prompts/、Skill 放进 .agents/skills/，连同包的传递依赖一起装好，并生成 apm.lock.yaml。安装时 APM 还会扫描隐藏的 Unicode 字符（零宽字符、双向控制符这类能偷偷改 Agent 行为的东西）。
哪些文件进 git，官方 Quickstart 列了一张表：
| 路径 | 提交？ | 原因 |
|---|---|---|
apm.yml | 是 | 清单，全队共享 |
apm.lock.yaml | 是 | 锁定提交和内容哈希，可复现 |
.github/、.claude/、.agents/ 等部署目录 | 是 | clone 下来就能看、能审 |
apm_modules/ | 否 | 缓存，自动 gitignore，apm install 按锁文件还原 |
第三步：选对钉法，Dependabot 才会动
Dependabot 读的是 apm.yml 里 dependencies.apm 和 devDependencies.apm 下的 git 依赖。怎么升级，取决于你怎么钉：
| 钉法 | 写法示例 | Dependabot 的行为 |
|---|---|---|
| SemVer tag | owner/repo#v1.0.0 | 升到最新的 SemVer tag；支持包级 tag，如 …/skills/review#review-v1.4.0 |
| 完整 SHA | owner/repo#<40 位 SHA> | 移到最新一个带注释、非预发布的 release tag 对应的提交，并加 # v1.4.0 注释 |
| 分支 | owner/repo#main | 只改 apm.lock.yaml 里锁的提交；必须已有锁文件 |
| 不写版本 | owner/repo | 不更新 |
有 apm.lock.yaml 时，Dependabot 会跑 apm lock 一起重生成；没有的话它不会替你建。所以先在本地 apm install 一次，把锁文件提交上去。
想让 Dependabot 帮你盯，就给每个第三方 Skill 写上 tag 或完整 SHA。
第四步：写 dependabot.yml
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "apm"
directory: "/" # apm.yml 所在目录
schedule:
interval: "weekly"
cooldown:
default-days: 7 # 新版本发布满 7 天才提
groups:
agent-context:
patterns: ["*"] # 所有 APM 依赖合成一个 PR10 月 22 日 beta 阶段要加 enable-beta-ecosystems: true，现在 GitHub 文档把这个选项标成「Not currently in use」，正式版不用写。Dependabot 对版本更新默认就有 3 天冷却期，上面改成 7 天，是给上游留点时间暴露问题，Skill 的指令会直接改变 Agent 行为，晚几天升级比较稳。groups 把一堆 Skill 的升级合进一个 PR，省得每周收到一串。私有仓库里的 Skill，要在 dependabot.yml 里配 git 类型的 registry 给它访问权限。
第五步：CI 里查漂移，挡住手改
Dependabot 负责提醒升级。仓库里的文件和锁文件是否一致，要靠 APM 自带的 apm audit 来查。官方漂移检测文档推荐的做法，对提交了部署文件的仓库是这样：
# .github/workflows/apm.yml 里的 steps
- uses: actions/checkout@v4
- uses: microsoft/apm-action@v1
with:
setup-only: true # 只装 CLI，不跑 apm install
- run: apm audit --ciapm audit --ci 依次跑九项基线检查，包括锁文件是否存在、版本引用是否一致、部署文件是否齐全、内容哈希是否匹配，之后在临时目录重放一次安装，和工作区做 diff，有人手改了 .github/instructions/ 里的文件就会报出来。用 setup-only 的原因文档也写了：先跑 apm install 会把手改的托管文件恢复回去，审计就看不出来了。其他几个常用命令：
apm install --frozen：只按锁文件装，和清单不一致就失败，相当于npm ci。apm outdated：只读，列出哪些依赖上游有新版本。apm update：本地手动升级，会先征求确认。
常见坑
- 没钉版本就等 PR：不带
#的条目、缩写 SHA、本地路径./my-package、MCP 条目，Dependabot 都不会更新。等了一周没 PR，先查这个。 - 写法太花哨：对象形式（
git:、registry:、path:这类映射）、YAML 块标量（>、|）、带转义的引号字符串、托管在 Azure DevOps 上的、http://或git://克隆地址，都会被跳过。清单里设了registries.default时，owner/repo#v1.2.0这种简写也不更新，要写完整克隆地址。 - 分支钉法没有锁文件：
#main这类写法，Dependabot 只能挪锁文件里的提交。仓库里没有apm.lock.yaml，它就什么也不做。 - 以为有安全告警：这次只支持版本更新，Dependabot 不会对 Skill 依赖发安全更新。内容安全靠 APM 安装时的扫描和
apm audit。 - PR 自动合并：Skill 和指令文件就是给 Agent 的程序。今天另一条快讯里 Postman 给 Agent 自动装插件和启动钩子，就是没人审时会发生的事。Dependabot 开的 PR 要看一眼 diff，尤其是
SKILL.md和钩子的改动。
完成标准
- 仓库根目录有
apm.yml和apm.lock.yaml，apm_modules/不在 git 里。 - 每个第三方依赖都带 tag 或 40 位 SHA，
apm outdated能列出它们的状态。 .github/dependabot.yml有package-ecosystem: "apm"条目，仓库的 Insights → Dependency graph → Dependabot 页能看到它。- CI 里
apm audit --ci通过；随手改一个部署出去的指令文件再推，它会失败。
最后
先把你仓库里最常用的两三个 Skill 改成带 tag 的写法，跑一次 apm install 提交锁文件，再加上面那段 dependabot.yml。还没写过 Skill 的，可以从写你的第一个 Agent Skill开始；这次更新本身的快讯见 Dependabot 开始帮你更新 Agent Skills 依赖。
