Agent 规则为何总被违反：结构化决策记录实践

我曾经测量过，一条书面规则在新的 agent 会话中能存活多久：67 分钟。那条规则记录在一次会话将另一个会话的半成品文件一股脑塞进提交之后，内容很简单：

• 只暂存明确路径，不使用 git add -A。

下一个会话从未经历过那件事，把这条规则当作建议，然后还是做了同样的事。

每个使用编程 agent 的人最终都会保留某种错误记录文件——agent 搞砸了什么，你就记下来，希望这条笔记能防止重演。我也有一个。67 分钟教会我的是，那个文件只是问题中最容易的三分之一。剩下三分之二是让规则被遵守，以及保持记录足够小，让任何人类或 agent 仍然愿意读。

书面规则不会自己存活，这是诚实的一面。Agent 会在记得规则的情况下重复犯错，你可以看到它们承认规则存在，然后还是做了那件事。散文体输给了模型的先验。所以我的决策记录不再使用散文体，而是变成了有固定格式的条目。以下是完整结构，用那条暂存规则作为实例：

## D-035 — 2026-08-02 — Stage explicit paths only, never add-all
**Decision:** 一条祈使句，无保留。
**Why:** 为没有对话记录的陌生人而写。
**Invariant:** 这条规则成立所必须保持为真的那条线。
**Boundary:** 这条规则停止适用的条件。
**Rung:** 法律或惯例，约束力有多强。
**Verify:** `grep -rn "git add -A" hooks/ scripts/` → 无结果
**Scope:** 本条目覆盖哪些项目。

改变一切的两个字段恰恰是最不引人注目的。

第一个是 Why，为没有对话记录的陌生人而写。不是"如前所议"，不是对一段已不存在的对话的总结。如果理由不能独立成立，下一个会话就会重新争论这个决定，而且大概率会输。

第二个是 Verify，一条可执行的命令及预期输出。只有能阅读的规则靠运气检查。能执行的规则靠机器检查，定时执行，永远有效。当我的某个条目与现实脱节时，审计会将其标记为检查失败，修复只需要一行提交。衰减浮现为发现而非意外。这套系统中唯一公开的部分是 audit 工具 etymd，它读取你的指令文件做出的声明，并与实际仓库进行比对，npx etymd audit 即可运行。

在错误文件和记录之间有一条路径，而我认为这条路径才是真正的系统。事故在发生地点被记录，便宜且无结构。重复发生使其可计数。只有可计数的模式才能升级为记录，包含 invariant 和 verify 行，也只有被记录的规则才能被接入钩子，从建议变为阻止。

incident, noted where it happened      便宜，无结构
        │  再次发生
        ▼
countable pattern                      可计数，不是感觉
        │  升级
        ▼
record entry: invariant + verify       法律
        │  接入
        ▼
hook that blocks instead of advising   强制执行

跳过中间环节，得到的是无人相信的规则。跳过末端，得到的是无人遵守的信仰。

• 证据，然后法律，然后强制执行。

然后是膨胀，在 agent 时代这是默认结局。模型写的比任何人都读得多，记录增长快于约束力，三千字的决策文档不过是换了名字的散文。我的反膨胀手段都是机械的。索引行有字符预算，超出的提交会被钩子拒绝，我曾见过它在我自己的 agent 执行任务中途拒绝它，这正是重点。文件有词汇预算，由审计检查。一个事实只存在于一个文档中，同一决策出现两次被视为缺陷，因为两份副本总会漂移。

不过格式本身才是安静的 anti-bloat 工具。七个短字段让长篇大论无处藏身。