你的 AGENTS.md 是你还没测试过的、杠杆最高的代码
我曾经发布过一次糟糕的 AGENTS.md 改动。
agent 变得没那么对齐，开始悄悄把改动过度工程化。它本来可以写一个干净的 20 行函数，结果会写成臃肿的 40 行。
那一个糟糕的改动影响的不只是我自己的工作流。它降低了我们这个有 100 名开发者的 monorepo 里使用 coding agents 的每一位工程师的产出质量。
为什么我们没有拦住它？
测量缺口
我们没有拦住它，是因为我们根本不知道有什么东西坏了。
这里有一种模式，我自己也犯过：把 AGENTS.md 当成 AI 生成的代码来对待。发出去就不管了。希望它别弄坏什么。每次模型变了就再调一调。
问题在于，AGENTS.md 重要得离谱。它是 harness 里杠杆最高的点，会被拉进代码库里每一位工程师的每一轮交互。
AGENTS.md 里的每一行都应该被认真对待。如果 agents 正在写你 80% 到 100% 的代码，那么这种对 harness 如此基础的东西，就应该得到比现在多得多的打磨。
我们应该像对待重要基础设施一样对待 AGENTS.md 改动。
为什么这很难
你没法直接 diff 一个 AGENTS.md 改动的输出。Agents 本质上必须是非确定性的。
AGENTS.md 里的一行改动，可能不会产生可靠且一致的行为变化。同一个指令编辑，在不同任务、repo、模型、harness 和时间点上都可能产生不同结果。
反馈循环是不可见的，也很难闭合。在现在的工具条件下，一个组织怎么知道自己的 agents 在规模化使用中变差了 5%？你只会得到稍微差一点的 PR。没有报警页面。没有失败测试。没有明显信号。
我们的工具还没有跟上 agentic engineering 的要求。我们需要一种方式，把修改 AGENTS.md 和看见这个修改产生了什么影响之间的反馈循环闭合起来。
测量
AGENTS.md 改动应该做 A/B 测试。没有 A/B 测试，你就不了解这个改动的影响。
应该测量这些东西：
- 测试通过率
- Agent diff 与 human diff 的等价性
- Agent 相对于 human diff 多写了多少额外代码
关键是要测量 agent 与你的代码库对齐得怎么样，以及它有多接近你的预期。
监控
Agents 会随时间变化。周一，一切都正常。周三，Anthropic 或 OpenAI 发布了一个静默更新，在你毫不知情时改变了底层行为。
如果没有监控，就无从知道发生了什么。不是你的 AGENTS.md 坏了。是它脚下的沙地移动了。
这就是为什么组织需要持续监控，而不只是发布前测试。这和我们在部署后继续监控生产环境，而不是永远信任绿色 CI，是同一个原因。
审查
我们应该用审查关键生产代码时同样的严谨度来审查 AGENTS.md。
每一次改动都应该由人仔细阅读并批准。
垃圾进，垃圾出。把这件事放大到组织里的每一位工程师身上，就很明显为什么 AGENTS.md 如此重要。
结论
当我们在测试通过率之外测量 agent 质量时，我们发现了一个隐藏在眼皮底下的 2x 质量缺口：你的 AI coding benchmark 正隐藏着 2x 质量缺口。
如果你没有有意识地测量和发布 AGENTS.md 改动，你就是在规模化地靠猜。
你今天是如何测量和发布 AGENTS.md 改动的？如果答案是“我们没有”，那你并没有发布流程。你只有一个靠希望运转的流程。