微软 APM 统一管理编程智能体依赖

微软推出了面向 AI 智能体的依赖管理工具 APM：项目用一份 apm.yml 声明技能、提示词、指令文件、插件和 MCP 服务，再由 apm install 解析依赖、生成锁文件，并部署到支持的编程工具。它要解决的是团队在多个编程助手之间反复复制、维护上下文配置的问题。

目前能确认什么

节选列出了 GitHub Copilot、Claude Code、Cursor、Codex 等九种目标工具。APM 会把源文件转换成各工具的原生目录和格式，例如 Claude Code 的 CLAUDE.md、Cursor 的 .mdc 规则文件。

覆盖九种工具，不代表每种工具都原生支持全部配置。

例如，Gemini 没有原生的 instructions 和 agents 类型，APM 会将它们编译为上下文文件。生成后的文件属于构建产物，修改应回到 .apm/ 源目录，再重新安装。

依赖可以指定 Git 引用、子目录或单个文件，也能限定部署目标、选择部分技能。如果省略 targets，APM 会根据已有目录自动识别工具；节选提醒，CI 中的目录差异可能改变部署结果。

apm.lock.yaml 记录精确版本和内容哈希，用来固定依赖内容。节选还提到安装时扫描隐藏 Unicode，以及默认阻止传递引入的 MCP 服务，但后者的放行条件在截断处没有展示完整。

我的判断

APM 最直接的价值，是让团队共用的智能体配置进入依赖管理和代码审查流程，减少成员手动同步文件的成本。涉及 CI 时，我会优先显式配置 targets，避免部署范围随目录变化。

锁文件能固定上下文内容，不能保证智能体回答一致，也不能证明规则正确。

一条与项目构建方式冲突的指令，被锁定后仍然会出错。因此，审查依赖升级时还需要检查指令内容。不同工具转换后是否保留相同语义、MCP 放行机制具体如何工作，现有节选不足以确认，不能把文件成功生成当作行为验证通过。