目录

1. 问题：代理上下文漂移 2. 设想：如果代理上下文有个package.json会怎样？ 3. 三大强保证

• 清单可移植
• 默认安全
• 策略治理 4. APM 包可以包含什么 5. 你实际会用到的五个命令 6. 一个清单，所有平台通用 7. 插件与市场：打包工作流，而不是单个文件 8. 安全：将提示视为真正的可执行程序 9. 治理：单一策略文件，仅可收紧的继承 10. AgentRC：上下文工程自动化 11. AgentRC + APM 如何协同 12. 周一如何开始 13. 三个要点 链接

上下文即代码：APM 与 AgentRC 漫游

如果你在过去十二个月内将 AI 代理部署到真实的代码库中，你一定体会过这种感觉：每个代理、每位开发者、每台机器——设置各不相同。一份 README 写着“安装这些扩展”。一份某人从其他仓库复制粘贴过来的 copilot-instructions.md。MCP 服务器配置分散在三个不同的文件里。同一套技能在 Copilot、Claude、Cursor 和 Codex 中重复编写。

没有版本锁定。

没有完整性保证。

没有可复现性。

这就是 APM（Agent Package Manager，代理包管理器）要解决的问题。它与 AgentRC 配合使用，形成从“生成”到“评估”上下文的完整闭环。

1. 问题：代理上下文漂移

如今大多数团队的代理设置都是一堆手工拼接的文件：

• 一份 copilot-instructions.md，第一个 Sprint 之后就再也没人更新过。
• 同样的内容被（拙劣地）复制到 CLAUDE.md 和 .cursor/rules 里。
• MCP 服务器配置在 .vscode/mcp.json、个人配置文件以及某个没人记得的 Makefile 中。
• 技能、提示词和规则在团队尝试过的每个平台上重复编写。

结果是：

• “在我的代理上能跑” 🤷 —— AI 时代的“在我机器上能跑”版本。
• 开发者之间的上下文漂移，即使是在同一个仓库内。
• 上下文无声腐烂，代码在演进，但指令却没有跟上。
• 无法将代理上下文作为版本化制品分发。
• 提示词没有安全边界——而对 LLM 来说，提示词就是可执行程序。

如果我们把提示词当作纯文本对待，就会继续在供应链审查中忽略它们。如果我们把它们当作代码来版本化、哈希化、审计化——我们就为代理的行为建立了真正的防护边界。

2. 设想：如果代理上下文有个package.json会怎样？

一个清单。一次安装。所有代理配置到位。就这么简单。

# apm.yml —— 随仓库一起发布
name: your-project
version: 1.0.0
dependencies:
  apm:
    # 技能、提示词、代理、插件 —— 来自任意 Git 仓库，版本锁定
    - anthropics/skills/skills/frontend-design
    - github/awesome-copilot/plugins/context-engineering#v2.1
    - microsoft/apm-sample-package#v1.0.0
  mcp:
    # MCP 服务器由同一清单管理
    - name: io.github.github/github-mcp-server
      transport: http

然后：

$ git clone <repo> && cd <repo>
$ apm install
→ resolving 14 packages...
→ deploying primitives to .github/, .vscode/
✓ every agent is configured

三个值得强调的细节：

1. 锁定（#v2.1、#v1.0.0）—— 可复现性，就像 package-lock.json 为你提供的保障。
2. MCP 服务器与清单共存于同一文件 —— 声明一次，用统一策略来管控。
3. Git 就是注册中心 —— 任意 Git URL 均可。GitHub、GitLab、Azure DevOps、Bitbucket、内部 Gitea 或 Gogs 都行。不需要中央市场（当然也存在精心策划的市场）。

3. 三大强保证

APM 提供三项核心保证，其他所有功能都源于此。

清单可移植

一份 apm.yml 描述了所有原始构件 —— 指令、技能、提示词、代理、钩子、插件、MCP 服务器，而 apm install 能在所有平台、所有机器上复现同一套设置。apm.lock.yaml 锁定解析后的依赖树，就像 package-lock.json 对 npm 所做的那样。

默认安全

代理上下文实际上具有可执行性。每次安装都会扫描隐藏的 Unicode 字符（双向/零宽攻击是真实的提示注入向量），锁定内容哈希，并让传递性 MCP 服务器通过信任提示才能启用。

策略治理

apm-policy.yml 在安装时强制执行，包括对传递性依赖和传递性 MCP 服务器的检查。仅可收紧的继承机制从企业 → 组织 → 仓库逐层传递。

4. APM 包可以包含什么

六种原始构件类型，可以自由组合。

这是大多数人低估的部分。APM 不仅仅是关于指令的——它是所有代理所需构件的单一清单。

5. 你实际会用到的五个命令

apm install                  # 解析清单、扫描、部署原始构件、写入锁文件
apm install <pkg>            # 添加包到 apm.yml 并安装
apm compile -t copilot       # 渲染根上下文文件（AGENTS.md / copilot-instructions.md）
apm audit                    # 安全 + 策略检查；输出 SARIF 格式供 CI 使用
apm pack                     # 打包你的包以分发

6. 一个清单，所有平台通用

同一组包可以渲染为你团队使用的任何平台：

apm.yml  →  apm compile  →  GitHub Copilot · Claude Code · Cursor
                                OpenCode · Codex · Gemini · Windsurf

对于 Copilot 而言，apm install 是零配置的——它会写入 VS Code 和 GitHub Copilot 期望的那些文件（.github/instructions/、.github/prompts/、.vscode/mcp.json），而 apm compile -t copilot 则会生成汇总文件 .github/copilot-instructions.md。APM 自身也在其仓库中践行了这一点。

对于其他平台，apm compile 会在仓库根目录下生成 AGENTS.md（开放式的 agents.md 标准）以及各平台特有的规则树。因此，如果团队成员使用 Claude Code、Cursor、Codex、Gemini、OpenCode 或 Windsurf，他们的代理都会从同一个清单进行配置。这是你对抗代理供应商锁定的有利武器：上下文超越平台本身。

7. 插件与市场：打包工作流，而不是单个文件

单个技能或指令文件并不是工作流。真正的能力——代码审查、发布说明、事件应急——需要多个原始构件打包在一起。

以代码审查插件为例：

• 一个指令文件（审查标准）
• 一个代理文件（通过 /review 激活）
• 两个技能（总结差异、发现缺失的测试）
• 一个MCP 服务器（发表 PR 评论）

如果没有插件，每位开发者需要手动拼凑四个元素，并祈祷版本匹配。有了 APM 插件：

$ apm install acme/code-review

一条命令把四个原始构件放到 .github/ 和 .vscode/ 的正确位置，并在 apm.lock.yaml 中锁定它们。插件可以依赖其他 APM 包（传递依赖，就像 npm 一样）。apm pack 导出一个标准的 plugin.json 包，Copilot、Claude 和 Cursor 都能使用。

市场是上层的精心策划层：一条命令从注册中心安装，部署到所有目标，锁定在锁文件中。apm pack 在声明时会在包旁边生成一个 marketplace.json。

8. 安全：将提示视为真正的可执行程序

关于安全的坦诚表述是这样的：代理上下文实际上具有可执行性，其完整性保障必须与之匹配。

• 隐藏 Unicode 扫描。每次安装都会屏蔽可能劫持代理行为的双向和零宽字符。这是一个真实存在且已被证实的提示注入向量。
• 锁文件完整性。apm.lock.yaml 为每个文件记录 SHA-256 哈希。包也内置了哈希信息，因此安装打包的包时会重新计算每个文件的哈希后再写入。
• MCP 信任防护。传递性的 MCP 服务器不会悄悄潜入——你需要重新声明或明确信任它们。
• apm audit 用于按需扫描，以 CI 友好的方式输出 SARIF 格式。
• 漂移检测，确保生成的文件不会与清单无声地产生差异。
• CI/CD 就绪，通过官方的 microsoft/apm-action 集成 GitHub Actions。

需要注意的是（截至 2026 年 6 月 5 日）：包签名尚未实现。当前的完整性保障是内容哈希 + 锁文件 + 来源许可名单。但这已经比大多数团队的现状好很多了。

9. 治理：单一策略文件，仅可收紧的继承

apm-policy.yml 让企业设置上限，组织进一步收紧，仓库再进一步收紧。每一层都只能收紧，不能放宽。具体规则：许可列表取交集，拒绝列表取并集，max_depth 取最小值，执行等级按 off < warn < block 递进。

# apm-policy.yml
allow:
  sources:
    - github.com/microsoft/*
    - github.com/anthropics/*
    - dev.azure.com/contoso/*
  mcp:
    - io.github.github/github-mcp-server
    - io.github.microsoft/playwright-mcp

deny:
  primitives:
    - hooks   # 全组织禁止 shell 钩子

require:
  signed: true
  lockfile: present

将文件放在 /.github/apm-policy.yml 下，组织内的每个仓库都会自动应用，无需为每个仓库单独配置。CI 检查通过 apm audit --ci --policy org 运行，执行所有检查并在 PR 上呈现结果。

对于应急响应，有两个已记录的绕过方式——apm install --no-policy 和 APM_POLICY_DISABLE=1——并且会大声记录日志。请谨慎使用。

架构师的核心要点：你可以在整个组织范围内推广 APM，而不会失去对代理加载内容的控制。

10. AgentRC：上下文工程自动化

APM 负责分发代理上下文。但上下文的内容从何而来？这正是 AgentRC 的用武之地。

注意：AgentRC 在其 README 中标记为实验性。如果现在采用，请在非关键仓库上试用，并锁定一个提交。

AgentRC 是一个 CLI + VS Code 扩展，它读取你的代码库，生成代理所需的有用文件：指令、MCP 配置、VS Code 设置，以及评测。三个命令对应一个完整的生命周期：

$ npx github:microsoft/agentrc readiness
Scoring 9 pillars · 5-level maturity model

  Build & test          L4  ████████░░
  Linting               L2  ████░░░░░░
  Architecture docs     L1  ██░░░░░░░░
  MCP configuration     L0  ░░░░░░░░░░

$ npx github:microsoft/agentrc instructions
→ reading repo, generating .github/copilot-instructions.md
→ generating .vscode/mcp.json
→ generating agentrc.eval.json
✓ done

$ npx github:microsoft/agentrc eval
→ running 12 evals against generated instructions
✓ 11 passed, 1 regressed

三合一：测量（readiness）、生成（instructions）、维护（eval）。

评测的角度是大多数人忽略的。指令只有在实际改善代理响应时才有意义。AgentRC 能测量这一点，并且在上下文退化时可以让 CI 失败。这是大多数团队代理设置中缺失的反馈回路。

11. AgentRC + APM 如何协同

你的仓库 → agentrc (测量 · 生成 · 评测)
            → .instructions.md · mcp.json · eval.json
            → apm.yml (打包 · 发布)
            → 全组织 apm install

关键的兼容点：.instructions.md 格式是两个工具共享的。 将内容从 AgentRC 移入 APM 包时无需转换。

三种角色，三种流程：

• 在自己的项目中（个人开发者）：agentrc init 生成基线，然后 apm install org/standards 拉入组织共享包。
• 为你的团队（团队负责人）：将你最优秀的指令和技能打包成 APM 包；团队成员只需一次 apm install 即可获得。
• 大规模实施（平台工程师）：apm audit + apm-policy.yml 强制执行标准；agentrc eval 在 CI 中捕获上下文漂移。

12. 周一如何开始

六个步骤。大多数团队本周应完成第 1–3 步，下个季度完成第 4–6 步。

1. 试用它。 curl -sSL https://aka.ms/apm-unix | sh，然后在一个测试仓库中运行 apm install microsoft/apm-sample-package。
2. 测量你的仓库。 npx github:microsoft/agentrc readiness 会给出成熟度评分和需要优先补充的缺失上下文列表。
3. 锁定现有内容。 将你现有的 copilot-instructions.md 和技能移入 apm.yml。提交锁文件。
4. 在团队内共享。 提取组织通用的部分，创建一个共享的 APM 包。团队成员运行 apm install。
5. 在 CI 中设关卡。 在 PR 检查中添加 apm-action 和 agentrc readiness --fail-level 3。这一步可以防止倒退——不要跳过。
6. 治理。 在组织层级推行 apm-policy.yml。随着学习积累逐步收紧。

13. 三个要点

1. 代理上下文就是代码。 给它版本控制，锁定它，像依赖一样分发它。
2. APM 提供清单，AgentRC 提供内容。 两者共同形成闭环。
3. 安全与治理不是事后补丁。 每次安装默认执行哈希、审计、策略。

如果你只记住一句话，那就是这句：

停止手工拼凑代理配置。把它像依赖一样锁定，像二进制文件一样扫描，像基础设施一样治理。

链接

• github.com/microsoft/apm
• microsoft.github.io/apm
• github.com/microsoft/agentrc
• agents.md
• modelcontextprotocol.io

本文《Context Is Code: A Tour of APM and AgentRC》最初发表于 foojay。