在 AI 代理上，你有一条想让它遵守的规则。你写进 AGENTS.md。它不遵守。你写得更详细。还是不遵守。你再加一条条文。
这样运行 48 天后，常驻指令文件从 90KB 变成了 147KB。
违规并没有减少。
下面是数字。全部来自我自己的一台机器、一个人的运维（n=1）。
先看扩充指令文件后成本如何变化。48 天的汇总：
| 项目 | 实测值 |
|---|---|
| 累计 token | 62,250M |
| 其中缓存读取 | 58,751M（94.4%） |
| 真正生成的输出 | 185.9M（0.30%） |
| 消息数 | 268,766 |
| 每条消息的重读量 | 约 219k token |
常驻指令是 4 个文件共 204,309 字节。这些内容每一轮都会被重新注入。
也就是说，「累计 token 量」不是代理的工作量，而是 指令长度 × 轮数 的函数。如果把它当成自己运维强度的指标，写指令写得最长的人看起来就是用得最多的人。
99.3% 的缓存命中率也是同一个陷阱。它不是效率的证据，而是「我在反复投同一段上下文」的证据。
我在环境里放了一个小脚本，每次被指出错误就按规则给计数器加一。没什么复杂的。
加了条文之后计数器并没有停。甚至出现过前一天新设的条文第二天就被打破。
增加条文不是解决方案，而是症状。
被记录的 24 条规则刚好分成了两组：
同一台机器、同一个代理、同一时期。
| 组 | 规则数 | 复发的规则 | 累计复发 | 每条平均 |
|---|---|---|---|---|
| A：代码门禁 | 8 | 0 条（0%） | 0 次 | 0.00 |
| B：仅文档条文 | 16 | 16 条（100%） | 19 次 | 1.19 |
B 组全军覆没。16 条全部至少复发过一次。
A 组自门禁上线后，已经连续 2,500 到 4,053 轮没有复发。
三个值得认真对待的反驳。
反驳 1：选择偏差。你是给最糟糕的规则加了门禁吧？
没错。我的运维规则是同一类违规超过三次就落到代码里。所以 A 组正是原本复发最严重的 8 条。它们现在是 0 次。这个偏差让结论更强，而不是更弱。
反驳 2：反向因果。加门禁的时候其实已经学会了。
这个我无法排除。「第三次才加门禁」这个流程本身就和时间相关。但 B 组里有 3 条停在两次复发上一直没停，光靠时间解释不了。
反驳 3：代理根本没在读文档吧？
在读。204KB 每一轮都完整进入上下文。这个测量的意义恰恰是：读了，仍然不遵守。
我还在跑一个队列：每次被指出问题就入队，一直追踪到条文化为止。累计如下：
| 状态 | 件数 |
|---|---|
| 升级为条文 | 231 |
| 已验证 | 178 |
| 被驳回 | 229 |
| 未处理 | 12 |
| 等待人工判断 | 63 |
驳回率 49.8%。 捕捉到的学习信号有一半没能变成规则就消失了。而且有 63 项卡在等人做决定。我以为自动化了的机制，最后瓶颈还是人。
规则的存放位置分成三层：
第三层是关键。只要「我改了条文」还能结案，同样的违规就会来第四次。
只注入前 3 条也是有意的。条数一多就又没人读了。而增加没人读的条文，正是这一切的起因。
诚实地写下漏洞：
如果有人在自己机器上做过同样的测量，我想看数字。特别是 B 组的复发率会不会随环境改变。