别再祖传复制 AGENTS.md 了，试试 APM

原文链接：https://mp.weixin.qq.com/s/4jn-OATYM90wADmGNUHc1A

APM 把 prompts、skills、MCP 和 agent rules 收进 apm.yml，让团队的 AI 编程上下文可复现、可审计。

现在用 AI 写代码，很多团队的真实工作流长这样：这个项目有一份 AGENTS.md，那个项目有一份 CLAUDE.md，Cursor 还有自己的规则，Copilot 又吃另一套 instructions。再加上 prompts、skills、MCP server、内部代码规范，最后大家靠复制粘贴维持“祖传上下文”。

问题不是这些文件没用，恰恰相反，它们太有用了。AI Agent 能不能少犯错，很大程度取决于它拿到的项目约定、工具边界和操作习惯。但今天这些东西通常不可复现、不可升级、不可审计。一个新人 clone 仓库后，装依赖很简单，装“Agent 工作环境”却靠问同事。

开源项目简介

APM，全名 Agent Package Manager，是 Microsoft 开源的一个“给 AI Agent 用的包管理器”。它的目标很直白：像 package.json 管 JavaScript 依赖、requirements.txt 管 Python 依赖一样，用一个 apm.yml 管项目需要的 agent 上下文。

它能声明的东西不只是提示词，还包括 skills、prompts、instructions、agents、hooks、plugins，以及 MCP servers。开发者在一个项目里写好依赖，其他人 clone 之后跑 apm install，就能把同一套上下文部署到 GitHub Copilot、Claude Code、Cursor、OpenCode、Codex、Gemini、Windsurf 等工具里。

一句话说，APM 想解决的不是“让 Agent 更聪明”，而是“别让每台机器、每个仓库、每个同事都拿着一份不一样的上下文在写代码”。

几个核心亮点

第一，它把 Agent 配置从散落文件变成了 manifest。你可以在 apm.yml 里声明依赖，比如某个团队的代码规范包、一个 review skill、一个 API architect agent，甚至某个 monorepo 里的单个 prompt 文件。APM 支持 GitHub shorthand，也支持 GitLab、Bitbucket、Azure DevOps、Gitea、SSH URL、本地路径和带 path/ref/alias 的对象形式。

第二，它有 lockfile。apm.lock.yaml 会记录依赖解析到的 commit、内容 hash，以及实际部署到项目里的文件 hash。这点很关键：Agent 上下文不是普通文档，它会直接影响模型怎么改代码。没有 lockfile，你很难回答“这个仓库今天到底给 AI 装了什么规则”。

第三，它把 MCP 也纳入同一套依赖管理。很多团队一边给 Agent 接数据库、浏览器、GitHub、工单系统，一边又担心工具越多越不可控。APM 的思路是：MCP server 不应该是每个人本地随手加的黑盒，而应该跟项目配置一起声明、安装、审计。

第四，它开始面向团队治理。APM 文档里明确提到 hidden Unicode 扫描、内容 hash、transitive MCP trust prompt、apm-policy.yml、apm audit --ci 等机制。需要注意的是，它的 lockfile/audit 路线已经比较实用，但 policy engine 仍处在 early preview，真要拿来做生产级强制门禁，最好固定版本并先小范围试点。

怎么用

最快的试法很简单。安装以后，先初始化一个项目：

1 2	`apm init my-agent cd my-agent`

这一步会生成 apm.yml。然后你可以安装一个包：

1	`apm install microsoft/apm-sample-package#v1.0.0 --target copilot`

如果是给已有仓库用，思路也类似：把团队认可的 prompts、skills、instructions、MCP server 写进 apm.yml，提交 apm.lock.yaml，让新同事或 CI 用同一套文件恢复上下文。想临时加一个依赖，可以 apm install <pkg>；想移除，就改 manifest 后跑 apm prune；想做 CI 校验，可以看 apm install --frozen 和 apm audit --ci。

对个人开发者来说，APM 适合拿来整理自己的 agent 工具箱：常用 review prompt、测试规范、部署 skill、MCP server，不要每个项目复制一遍。对团队来说，它更像一层“AI 开发环境的依赖声明”：谁能装什么、装到哪里、锁在哪个版本，都写清楚。

简短判断

APM 现在还不是那种“所有人今天必须切过去”的成熟基础设施，但它抓住了一个很真实的变化：AI 编程的上下文，已经从几句提示词变成了工程依赖。

以前我们只管理代码依赖，后来管理 CI、容器、开发环境。现在 Agent 也开始有自己的依赖树、锁文件和安全边界。这个方向大概率会留下来。哪怕你暂时不用 APM，也值得借它的思路检查一下自己的项目：那些给 AI 看的规则，到底是工程资产，还是还躺在某个人电脑里的复制粘贴片段？

鍞旀兂编程 / vibecodinghub

每天挑一个真的有用的开源项目、AI 编程工具或开发者工作流，少一点热闹，多一点能上手的判断。

项目链接：https://github.com/microsoft/apm

官方文档：https://microsoft.github.io/apm/

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。