因为一个 git 单词，CauterRule v0.3.1 把通过率直接拉高了 40 个点

想给 Agent 建立一套「错误经验库」的可以关注下 CauterRule，它现在出了 v0.3.1 版本，核心逻辑就是把 Agent 重复失败的教训提取成永久规则，然后通过回放测试来验证。简单说就是：提取教训 → 回放验证 → 晋升为正式规则。

这次 v0.3.1 的更新非常关键，解决了之前一个极其离谱的「误判」问题，直接让通过率从个位数跳到了 50% 以上。

为什么之前很多好规则被判定为失效

在 v0.3.0 里，很多正确的规则被判定为「破坏性」规则（broken）。比如模型提取出一条很精准的规则：「当 git push 提示 non-fast-forward 失败时，请先 pull 最新更改」。这条规则本身没问题，但在回放测试时，只要测试集里出现了 git status 或者 git commit-hook 这种包含 git 单词的成功案例，系统就会认为这条规则「干扰」了原本成功的操作，从而把这条规则给毙了。

说白了，之前的判定逻辑太死板，只要触发词重合，就认为规则干扰了成功路径。但实际上，git push 的规则和 git status 的成功案例共用一个 git 单词纯属巧合，根本不是干扰。

v0.3.1 做了哪些关键修复

这次更新通过调整评分逻辑，把这种「词汇巧合」从干扰项中剔除掉了，具体改动在 #724 这个 PR 里：

1. 重新定义评分顺序：现在的判定流程变成了 → 无信号则判定为 inconclusive → 如果 broken 数量大于 prevented 数量则判定为 fail → 如果 near_misses 超过 2 个则判定为 inconclusive → 其余情况判定为 pass。
2. 放宽精度阈值：不再采取零容忍的近失惩罚，只要规则防止的失败数多于破坏的成功数（精度 $\ge 0.5$），就承认它是有效规则。
3. 优化候选池：通过 #731 引入了召回率加权排序（替代之前的精度优先），并用 #732 解决了签名感知的两轮去重问题（之前发现 40% 的候选规则其实是重复的）。

两个云端模型的实测数据

这次 v0.3.1 在 failures/positive（n=50）数据集上跑了 4,742 次轨迹运行，对比结果非常夸张。之前 v0.3.0 的通过率只有 8% 到 10%，而更新后：

• gpt-4o-mini：通过率升至 50% [0.37, 0.63]，精度 0.544，召回率 0.221。
• llama-3.1-8b：通过率升至 52% [0.39, 0.65]，精度 0.554，召回率 0.240。

在 gpt-4o-mini 的分布中，有 25 个通过，17 个无信号，只有 3 个被 broken 拦截，4 个被 near_miss 拦截。这证明了之前的「词汇巧合」确实是导致通过率低的主因。

怎么上手尝试

目前 CauterRule 已经在 PyPI 上线，直接安装即可使用全套 CLI 和框架适配器：

pip install cauterule

对于经常跑 Agent 且深受「同一个坑掉进去好几次」困扰的人来说，这种能把失败轨迹转化为确定性规则的 sidecar 方案非常实用。