用统计假设检验验证Agent指令变更效果

对 Agent 指令变更的统计门控

一次对 Agent 指令文件的编辑就是一次部署，我不再让自己凭直觉发货。维护我助手 CLAUDE.md 的每日调参任务现在要求在指令变更被允许保留之前，必须在统计上取得显著改善——Welch's t-test，p < 0.10，至少 5% 的提升——基于 14 天滚动基线来衡量。

然后我对自己的门控做了功效计算，发现 5% 这个阈值只是装饰性的。在每窗口 14 天的情况下，检验只能检测到大约 0.97 个标准差的偏移。任何更小的变化都无法被发现，不管提升阈值声称是多少。

这两部分就是本文的内容。机制值得抄。窗口大小是我之前搞错的部分，而算术足够简短，可以验证。

在大多数 Agent 系统中，prompt 是测试最少代码

Agent 流水线中的其他每个产物都有门控。应用代码有测试套件和 review。基础设施有 plan 和 diff——我写过的 Terraform 模块和托管过的远程状态足够多，知道没人会盲目合并那些东西。

指令文件没有任何门控。有人注意到 Agent 做了件烦人的事，就加了一行告诉它不要这样做，然后发货。没有基线，没有留置，也没有记录前十一行是否还在挣它们的 token。

这就是指令文件腐化的方式。它们累积了在某个糟糕的下午成立的规则，此后一直在消耗上下文。

你无法测试你没有打分的东西

门控需要一个因变量，所以第一个构建物是一个评分 rubric，而不是测试。五个维度，每个对话按 0–10 打分：目标清晰度、返工率、上下文命中率、范围纪律、响应密度。每日本分是当天对话的平均分，按对话长度加权。

Rubric 是冻结的。改变它会使所有历史比较失效，所以 rubric 变更本身也是一个被追踪的元编辑，会重置所有基线。

分数锚定在可观测的摩擦上，而不是自我评估。评分器解析 transcript，查找五类模式——纠正（"不，那样"，"实际上"，"不要"）、返工（"重做"，"从头开始"）、范围漂移（"我没问"，"就做"）、遗漏的上下文（"我之前告诉过你"，"检查 memory"）、表扬（"正是"，"太棒了"）。摩擦拉低维度分数，表扬拉高。

这是承载整个决策的部分。一个 Agent 给自己的 transcript 评分会趋向于宽容。用正则表达式在人类实际说的话上操作则不会。

Welch，不是 Student，以及为什么这不是迂腐

每次编辑获得 14 天前窗口和 14 天后窗口的每日分数，用 Welch's t-test 比较。三种结果：p < 0.10 且提升 ≥ 5% 标记为编辑保留；p < 0.10 且提升 ≤ −5% 触发自动回滚；其他都是不确定，编辑继续留待观察。

用 Welch 而不是 Student's t，因为两个窗口不应该有相等方差。一个好的指令通常通过移除一个失败模式来起作用，这会压缩坏尾巴——方差下降的幅度和均值上升的幅度一样大。

Student's t 假设相等方差，当小方差组是大样本时会过度拒绝。这正是你所关心的情况，所以 pooled 检验会在你最有信心的好编辑上给你最多的假阳性。Welch 损失一些自由度，但去掉了那个假设。

打破了设计的算术

在 α = 0.10 和 80% 功效下，双样本检验能检测到的最小效应大约是 (t_α/2 + t_β) × √(2/n) 个标准差。对于 14 天窗口：

门控只能看到黄线以上的效应。5% 阈值位于阴影带内部——一直在它下面，没有任何作用。

现在转换成门控实际使用的单位。假设基线 7.0（0–10 rubric），日间标准差 0.6 分，这对少数对话平均的指标来说是很平常的。

5% 的提升是 0.35 分，或 0.58 SD。14 天窗口检测 0.97 SD，即 0.58 分——占基线的 8.3%。统计检验比它旁边的提升阈值严格大约 1.7 倍。

所以 5% 这个数字永远不会生效。它没有任何作用。每个通过 t 检验的编辑都已经远远超过了 5%，而每个失败的编辑都是因为功效，不是因为效应大小。

在这种方差下检测一个真实的 5% 提升需要每窗口 38 天，而不是 14 天。而需求随方差快速移动：

门的诚实标签。黄虚线右侧的每个条形都是配置中从未提及的阈值。

把最后一列读作门的诚实标签。在 SD 1.0 时，"5% 阈值"实际上是 14% 阈值，而差异完全对阅读配置文件的人隐藏。

窗口大小必须根据方差来设定，而不是根据日历。选择了 14 天是因为两周是一个整齐的数字，这不是理由。

有两条路，只有一条是省钱的。延长窗口，你就每个 lesson 等待更久。或者通过每天评分更多对话来缩小方差——日均的标准误随 √n 下降，所以日均量翻三倍将 SD 削减约 42%，并将所需窗口从 38 天拉到大约 17 天。

把同样的算术反过来看。如果一次编辑真的提供了 5% 的提升，14 天窗口只有 44% 的概率称其为显著。这对你自己最好的变更来说是抛硬币。38 天时是 81%。

同样的算术，正向运行。每一帧是一个窗口长度；阴影尾部是好编辑被判定为显著的概率。

门控做不到的事，坦白说

它不能控制多重比较。在每三天一次低风险编辑的配置频率下，一年大约 122 次评估。在 α = 0.10 双侧情况下，噪声本身会产生大约六个虚假的保留裁定和六个虚假的自动回滚。自动回滚那一边才是让人痛心的：系统偶尔会以统计置信度回滚一个好的编辑。

它也不是随机实验。前后窗口是连续的日历时间，所以模型版本变更、假期或一个月异常混乱的工作完全落在其中一个窗口上，被归因于那次编辑。

这使得它是一个噪声过滤器，而不是因果声明。它阻止了明显更差的编辑和明显是想象出来的胜利。它不会告诉你为什么任何东西移动了。

防护措施比检验本身做更多的工作

三条规则防止循环吞噬自己，它们比 p 值更重要。

冷却期。每三天一次低风险自动编辑，每周一次高风险提案。没有冷却期，窗口会重叠得太严重，没有编辑能被干净地归因。

plateau 检测。如果 14 天滚动分数在过去 14 天没有改善 2%，且没有摩擦触发，当天的编辑就被跳过。容易的胜利来得早；在那之后，编辑主要是一种增加方差的方式。

与人类共同承担风险的分割。措辞和格式变更自动应用。任何添加段落或改变 Agent 决策方式的内容都会被写入 proposals 文件夹并等待。每次编辑先备份之前的文件，进入一个可回滚的日志，带标签，所以一次糟糕的判断是一行回滚而不是考古项目。

配置文件有一个名为"何时不编辑"的章节，最后一行是整个系统中最有用的东西：什么都不做始终是一个有效的操作。

延迟。这是整个账单，而且比我构建时估计的要大。

一个有关控的指令文件最好情况在 14 天钟面上学习，如果上述方差数字正确的话，实际上在 38 天钟面上学习。一个无关控的在下午学习，但以没人测量的方式出错。我仍然会选择慢版本，但我不会假装权衡是免费的，而且我不会为一个仍在原型阶段的系统构建这个。

我还没有保留裁定的报告可报告，因为第一个诚实的裁定要等到完整的后窗口关闭后才能存在。在结果之前发布设计是重点——设计是可以检查的部分，而上面的算术是我希望有人来争论的部分。

如果你在你的团队中对 prompt 或指令变更进行统计门控，我想知道你最终用了什么窗口以及你每天的方差是什么样的。那个数字是全局的关键，但几乎没有人发布它。

Originally published at michael-kaminski.io. I write field notes on agent infrastructure — evals, MCP servers, and what it costs to run agents in production.