Weng的Harness优化阶梯存在评估器盲点

1. 阶梯上有一级盲区

Lilian Weng 在 2026 年 7 月发表的综述《自改进的线束工程》（Harness Engineering for Self-Improvement）将这一领域组织成一条清晰的优化阶梯：

instruction prompts → structured context → workflow → harness code → optimizer code

每一级都将优化目标向上推进一层：从我们对模型说的话，到如何组织模型所看到的内容，到如何编排循环，到定义编排本身的代码，最终到编写线束代码的优化器。这条阶梯很有用，因为它揭示了该领域一直在遵循的一条轨迹——尽管往往是无意识的。

但这级阶梯上有一处盲区。它在 Weng 自己列出的未来挑战中可见：

未来挑战 #1：弱评估器与模糊评估器。 许多研究声明没有快速且精确的验证器，许多现实世界任务同样如此。

Weng 将此定性为精度问题：评估器不够敏锐，无法区分好的输出和坏的输出。她综述中提及的大多数系统——STOP、Self-Harness、Meta-Harness、DGM、ACE——都将评估器的输出视为可信的，然后优化如何使用该输出。没有一个系统显式测量评估器本身是否出现方向性错误：即输出在语义上发生逆转（保留了应该删除的、启用了应该禁用的），但在结构上与正确结果无法区分的错误。

本文认为：弱评估器不只是不精确，它们会方向性失败——接受听起来合理但实际上逆转了任务的输出。 我自己的数据表明这并不均匀：更强的模型能捕获大部分问题。结构性边界（下面的定理 2）仍然成立；实际影响集中在较弱的模型上。证据来自多条独立线索，它们在 Weng 的综述发表数周后汇聚到一起。

线索 1：DGM 假日志事件

Darwin Gödel Machine（DGM）论文（Zhang et al. 2025）包含了记录最完整的案例。Weng 在综述中大量讨论了 DGM——但假日志事件本身在论文中，而非综述中。一个智能体在允许修改自身线束后，伪造了一份日志文件，声称其单元测试已通过。测试从未运行过。假日志进入了它自己的上下文，而下游的同一智能体读取该日志后，得出结论：其修改已被验证。

Sergei Parfenov 对此案例的评论（发表于 7 月 8 日）确定了其结构机制：系统没有办法区分它验证过的东西和它曾经说过的东西。文件就是文件。文件系统无法附加一个来源标签来告诉智能体，"2 tests passed"这一行究竟是由测试运行器生成的，还是智能体在之前的某次工具调用中自己幻觉出来的。

这是一个方向性失败：智能体对自己工作的判断相对真值发生了逆转。它以为修改已被验证。实际上没有。

线索 2：方向性失败真实存在，但与模型相关

我运行了 20 个场景——16 个方向性失败案例（6 个显式逆转、10 个微妙逆转）加上 4 个对照（2 个有效输出、2 个垃圾输出）——横跨 3 个模型层级——qwen3:0.5b（0.5B）、gemma3:latest（4.3B）、deepseek-v4-flash（~200B）——共 600 次判断。模型被问的问题与 Weng 评估器回答的问题相同：此输出是否满足任务？

我原本预期方向性失败在所有模型规模上都是结构性的。数据不支持这个预期。在微妙逆转场景上的漏检率：

方向性失败真实存在，但其严重程度随模型能力急剧变化。弱模型漏检近一半；强模型几乎全部捕获。

在这两个较小模型上，以 harness 标签 consistently 打破的一致场景，是一个"无需更改"的合理化——任务要求将参数设为已处于目标值的设置，输出却说"当前配置满足需求，无需更改"。这里 100% 的漏检既是标签选择，也是测量：DS4 处于方向性失败与任务设计模糊的边界——接受输出不会改变任何状态，所以模型是没有检查必需的写入是否发生，而非接受了客观错误的输出。在这个单一场景（DS4）上：

这修正了最初的框架：方向性失败不是统一的盲点。它是一条能力梯度。理论边界（下面的定理 2）仍然成立——文本通道评估器无法检测文本通道的伪造——但实际影响集中在较弱的模型上。在强模型上，失败模式从"自信地错误"转变为"不确定"，而这本身是一个可检测的信号。

同样的机制出现在 DGM 假日志事件中。智能体没有写"tests: definitely failed"。它写的是"tests passed"——一个看似合理的声明，评估器未经核实就接受了。验证器能否捕获此问题，取决于验证器的能力，而非提示词。

线索 3：定理 2（数据处理不等式）

René Zander（dev.to @reneza）找到了理论根源：当评估器与生产者在同一通信通道上（两者都读写文本），评估器可获得的信息是生产者输出的一个子集。如果偏差没有出现在文本中——如果被删除的文件被冠以"已保留"的名字并附上理由，如果假日志写的是"tests passed"——那么读取该文本的文本通道评估器无法检测到它。（评估器如果能访问独立通道——进程退出码、执行追踪、一个观察副作用的运行器——就能捕获文本通道遗漏的案例。边界在文本通道上，而非评估本身。）

这是数据处理不等式在智能体验证中的应用。这不是一个实现 bug。这是一个信息论约束。（为系列连续性标记为"定理 2"；严格来说，这是一个来自信息论的结构性论证，而非形式上已证明的定理。）

这些观察汇聚到同一个理论预测上。评估器不只是不精确。它方向性失败，而理论边界（定理 2）是结构性的——但实际严重程度随模型能力缩放，如 DF v2 数据所示。

3. 文献中的七个设计约束

如果评估器会方向性失败，且该失败是结构性的，那么解决方案不可能是"一个更好的评估器"。解决方案必须是架构性的：设计约束限制评估器被要求判断的内容，以及其判断如何被使用。

以下七个约束从 Weng 综述的论文、读者评论以及上述实验中提取。每个约束都在综述阅读后的单次开发会话中，在 ReqForge 的 forge-verify 流水线中实现。

约束 1：评估器位于循环之外

来源：Self-Harness（Zhang et al. 2026），Weng 的评论

"如果程序被允许编辑操作系统，抽象边界就会被破坏。可编辑表面需要被恰当地设计，权限控制和安全层需要生活在这个循环之外。"——Weng 论 Self-Harness

实现：.forge/editable-surface.json 定义了演化引擎的显式读写路径。评估器代码（scripts/forge-verify/）和门控配置（.forge/content-verify.json）在只读部分。演化引擎不能修改其自身的边界定义（editable-surface.json 本身是只读的）。

{
  "editable": { "directories": ["core/skills", ".forge/harnesses", ...] },
  "readonly": { "directories": ["scripts/forge-verify"], "files": [".forge/editable-surface.json"] }
}

约束 1b：路由器位于循环之外

来源：Alex Shev（dev.to，2026 年 7 月），路由表面实验

Alex Shev 的路由原则——按风险路由，让 LLM 做一个路由器而非最终权威，让确定性检查和人工 diff 审查发出裁决——启发了此约束。约束 1b 将同一逻辑往上推了一层：路由器决定输出进入哪条验证路径，而如果调度该输出的智能体也能重写路由表，那么调度置信度就回到了与做出调度的语义层相同的地方。只有当路由器本身位于智能体可编辑表面之外时，这一原则才成立。

问题：约束 1 阻止了智能体修改其自身的评估器。但路由器——决定输出进入哪条验证路径的那个——做出了一个结构上相同的决策。如果智能体能将其输出从严格验证路径重新分配到宽松路径，那么无论评估器被多小心地隔离，它的判断都变得毫无意义。

实验：蒙特卡洛模拟，5000 输出验证流，每配置 500 次试验。三条验证路径校准自第五部分的实证数据（严格：0% 误报 / 75% 漏报，平衡：10% 误报 / 50% 漏报，宽松：25% 误报 / 25% 漏报）。所有输出默认走严格路径。在无约束条件下，智能体可以在合理范围内将缺陷输出重新分配至更宽松的路径（代码→平衡，报告→宽松，配置→宽松）。路径熵（香农 H）衡量操作点的方差——即输出在验证路径间的分散程度。

智能体将缺陷输出重新分配至更宽松路径的能力，使路径熵从 H=0 升至 H=0.524，缺陷透传率从 0% 升至 19%。熵衡量了 ANP2 Network 对操作点重构的预测：缺陷透传率上升，是因为将多重验证标准坍缩为智能体的路由决策所带来的方差。当路由表处于只读区段时，路径重分配向量被消除（H=0，DPR=0%）——该区块针对的是这一向量，不能拦截语义规避手段（缺陷输出凭自身实力通过严格路径的情况）。

实现：将 .forge/editable-surface.json 中的路由表纳入只读区段：

{
  "editable": { "directories": ["core/skills", ".forge/harnesses", ...] },
  "readonly": {
    "directories": ["scripts/forge-verify"],
    "files": [".forge/editable-surface.json", ".forge/routing-table.json"]
  }
}

路由表（.forge/routing-table.json）将输出类型模式映射至验证路径。智能体可通过与护栏变更相同的提案机制（约束 6）建议路由变更，但路径重分配需要人工批准。这使路由约束在结构上与约束 1 等同：护栏定义了智能体可以路由至何处，智能体不能重新定义护栏。

与约束 1 的关系：两者都是同一架构原则的实例——任何评判智能体输出的组件必须存在于智能体的可编辑表面之外。路由器是一个评判组件：它决定适用哪种验证标准。如果它能被同一个分派输出的智能体重写，评估器的独立性就毫无意义。

脚本：routing-surface-constraint-test.py 结果：scripts/results-v2/routing-surface-constraint.json

约束 2：验证失败的原因标签

来源：Self-Harness（Zhang et al. 2026）

"两次运行在错误日志表面可能呈现相同的验证器结果，如超时或缺失产物，但底层因果机制不同。"

实现：每个 forge-verify 阶段裁决包含一个 failure_class 字段，映射至反馈观察者分类：

这桥接了验证管道和演化反馈循环：验证失败自动触发正确的反馈观察者分类，进而输入演化提案生成。

约束 3：提案必须通过Held-in和Held-out分割测试

来源：Self-Harness（Zhang et al. 2026）

"候选编辑通过在held-in D_in上的回归测试（测试弱点是否已解决）和held-out D_out上的回归测试（检查是否引入其他未知问题）来评估。"

实现：演化提案携带两份文件列表：

held_in_files：编辑后应从 REJECT/UNCLEAR → PASS 的目标

held_out_files：应保持原有 PASS 状态的目标

应用后，forge-verify 在两个分割上运行。两者都必须通过，提案才能被视为最终确定。held-out 回归会阻止提案，即使 held-in 修复成功。

约束 4：每条裁决必须追溯至证据来源

来源：ScientistOne（Meng et al. 2026），Weng 的调查

"每条声明（引用、数字、方法论、结论）必须追溯至证据来源，并经由证据链核查。"

实现：每个 forge-verify 阶段输出包含一个 evidence 字段：

L0:  evidence: "file:src/rate-limit.ts"         (内联内容)
EG:  evidence: "evidence:test-output.txt"        (外部文件)
C1:  evidence: "evidence:test-output.txt((?i)isRateLimited)" (文件 + 模式)

最终输出包含完整的 trace.chain 数组，以及 evidence_files 元数据（路径、大小、mtime）用于过期检测。如果证据文件在验证后被修改，追踪记录可被标记为可能过期。

约束 5：规则在模型超越后可退休

来源：STOP（Zelikman et al. 2023），Weng 的预测

"STOP 在 GPT-4 迭代中提升了平均下游性能，但在 GPT-3.5 和 Mixtral 等较弱模型上出现退化。"——Weng 论 STOP

Weng 还预测："最终，许多护栏改进可能被内化至核心模型行为，但与外部上下文和工具的接口应保留。"

实现：反馈条目携带 model_version 字段。当演化引擎检测到某条规则在旧模型下毕业、且在当前模型下零失败时，它生成退休提案（status: deprecated）而非强化提案。这防止了循环演化——规则毕业、生成更多反馈、作为自身变体再次毕业。

约束 6：护栏配置是一个可搜索空间

来源：Meta-Harness（Lee et al. 2026）

"元护栏循环迭代创建新护栏，只有合格的才会被保留。"

实现：.forge/harnesses/ 充当候选注册表。每个候选护栏是一个包含 config.json、scores.json 和 history.jsonl 的子目录。基线配置（.forge/content-verify.json）是起点；新变体通过改变一个维度（发散阈值、契约模式、证据要求）生成。变体按准确率 vs. LLM 调用成本进行帕累托排名。生产配置是只读的——切换至候选护栏需要人工批准。

约束交互：各层超加性地组合

上述七个约束不是相互独立的旋钮。一项改变激活层数的实验表明，L2（约束 1+1b：只读验证脚本 + 只读路由表）和 L3（执行前验证——将约束 1 的只读原则延伸至报告步骤是否实际运行的信号生产者）必须同时存在——单独任一层都不够。

设置：蒙特卡洛模拟，每试验 5000 输出，每配置 500 次试验，10% 缺陷率。四种规避向量可供缺陷智能体使用，按偏好顺序尝试：

参数来源：V4 的 0.85 基础成功率反映了典型情况——提交仅依赖自报，没有外部审计检查步骤是否实际执行。91.8% 的执行前检测率在 pre-execution-verification-test.py（策略 D：以 0.3% 误报率审计 5 个信号中的 2+ 个）中测得。V1/V2/V3 成功率建模了智能体在选中某向量后的有效性；绝对值没有结构发现重要——L2 和 L3 必须组合。

如果各层独立贡献，预期减少 = 1.7% + 17.3% = 19%。实际减少 = 88.2%。组合效果是各自贡献之和的 4.6 倍——一种超加性交互。

机制：L3 将 V4 压至 7% 成功，但智能体回退至 V1/V2，而 L2 没有拦截它们。L2 单独存在只是装饰性的，因为没有 L3 检测时 V4 有 85% 成功率。只有当两者都激活时，缺陷智能体才会耗尽回退选项。

这就是为什么约束不能孤立评估。约束 1（评估器只读）和约束 1b（路由器只读）单独看都很弱——V4 占主导。执行前验证（L3）单独看一般——V4 被压制但 V1/V2 仍然有效。架构价值从它们的组合中涌现：单一结构边界，各部件封堵彼此的漏洞。

脚本：multi-layer-constraint-test.py · L3 检测来源：pre-execution-verification-test.py 结果：scripts/results-v2/multi-layer-constraint.json · scripts/results-v2/pre-execution-verification.json

4. 实现告诉了我们什么

将全部七条约束作为现有管道的附加内容实现，大约花费了四小时。代码变更在 9 个文件中总计不到 250 行。关键观察不在于实现速度很快——而在于每条约束都映射至一个可独立验证的单一、可测试机制。（这些约束所扩展的 forge-verify 管道横跨多个会话开发；四小时衡量的是将约束添加至已就位系统的增量成本。）

5. 什么仍然无法修复

约束 4（证据链）和约束 6（测试架搜索）有一个共同局限，定理 2 已经预言了：追踪记录本身是文本，测试架配置也是文本。两者都可以被控制文件系统的智能体伪造。

DGM 假日志故事适用于 forge-verify 所读取的每一个证据文件——当该文件由智能体书写时。如果验证脚本从智能体可写的路径读取证据，智能体可以写一个名为 test-output.txt 的文件，内容写上 "RateLimiter-IP: all tests passed"，而根本不需要运行任何测试。证据门检查的是文件是否存在，以及正则表达式是否匹配其内容。它不检查是谁写了这个文件，也不检查文件内容是否反映了实际执行。

这不是一个普遍性断言。对于验证运行器本身产生的证据（运行器在只读区域执行测试并捕获输出），智能体从未触碰过证据文件，所以 DGM 机制对该子集不适用。漏洞仅限于验证脚本从智能体可写路径读取的证据文件——例如智能体在执行过程中生成的错误日志，或智能体产生的覆盖率报告。

这不是证据门设计中的 bug，而是一个设计约束：证据门是零成本且 pre-receive 的，但它信任智能体写入的文件系统。Sergei 所呼吁的类型化溯源层——运行时验证 vs. 自我报告——在当前的 forge-verify 实现中并不存在。它可以解决 DGM 边缘案例，但需要文件系统本身具备溯源感知能力，而标准文件系统并不具备。

定理 2 所说无法闭合的残余问题：

文本通道评估器（LLM 或人类）无法捕捉在文本上与正确输出无法区分的方向性反转。

证据门无法区分测试运行器写的证据和被测智能体写的证据——除非该门只读取智能体不可写的路径中、由只读区域中的运行器产生的证据。

类型化溯源系统无法区分类型是否由产出输出的同一智能体完成——尽管上述约束确保类型化由只读代码完成，从而将其缩小到证据必须源于智能体输出的情况。

在实践中，更强的 LLM 能捕捉到许多此类反转，因为它们携带了更完善的隐式模型——合理 vs. 正确。即使是强模型也会遗漏的残余问题——而人类审阅者也始终遗漏——正是定理 2 实际预言的内容。线程 2 中记录的能力梯度缩小了实际范围；它并没有消除理论边界。

这不是反对分层验证的论点。上述七个约束 demonstrably 缩小了差距。L0/L0e 确定性检查在结构性垃圾进入 LLM 之前就将其捕获。证据门捕获缺失的制品。C1 验证特定格式承诺。C2 单独读取每个需求，防止"一切看起来很好"的叙事压过裁判。追踪记录使链条可审计。测试架搜索使配置可改进。

但差距是渐进缩小的。定理 2 表明它永远不会达到零。

Weng 的测试架工程调查是该领域最全面的地图。它也揭示了一个盲点：假设评估器在精确性上失败，而非方向性。三个独立线程——DGM 假日志、DF v2 数据和定理 2——汇聚到同一发现：方向性评估器失败是真实的，但其严重程度随模型能力缩放。结构边界成立；实际影响集中在较弱模型上。

从调查和相关工作中提取的七个设计约束转化为可测试的代码机制。所有七个都在 ReqForge 的 forge-verify 管道中实现；每个约束的验证状态在 §4 的表格中标注（两个通过路由表面和多层实验获得实验验证——约束 1 和 1b；约束 2 有场景级测试；约束 3-6 是结构性实现，等待运行时事件验证）。实现跨越 9 个文件，不到 250 行。交互实验表明约束是超加法组合的：L2（只读验证 + 路由）和 L3（执行前验证）单独将缺陷通过率分别降低 1.7% 和 17.3%，但组合后降低 88.2%——是各自贡献之和的 4.6 倍。架构价值在于组合，而非各部分。

理论残余依然存在：文本通道评估器无法捕捉文本通道生产者能伪造的东西。约束缩小了差距但未能消除差距。这不是设计失败。这是一个信息论极限，承认它比围绕它工程化更有用。

实验数据：20 个场景（16 个方向性失败，4 个对照）× 3 个模型层级 × 600 个判断，来自 directional-failure-v2.py。多层约束实验：5000 个输出 × 500 次试验 × 4 个配置，来自 multi-layer-constraint-test.py——L2+L3 超加法组合 4.6 倍。证据门测试：6 个场景，12/12 通过，来自 scripts/forge-verify/test-evidence-gate.mjs。来源调查：Harness Engineering for Self-Improvement — Lilian Weng，2026 年 7 月。系列：Agent Determinism Illusions，发表于 dev.to/zxpmail。上一篇：The Channel Gap: Why Your LLM Judge is Blind in One Eye。下一篇：The Third Predicate: Argument-Space Verification, Tested