AutoHarness 技术解剖：Thompson Sampling、Critic 工程与 Harness 架构的深层原理

以费曼的视角，把 AutoHarness 的齿轮拆开来看。这篇是之前那篇《那个总想在游戏里作弊的AI》的技术补充——如果你已经读过那篇，这篇会让你看到引擎盖下面。

一、问题再定义：为什么 LLM 会"懂规则但守不住"？

先把直觉精确化。

之前的文章说 LLM "知道马走日但不会走"。这个说法有点模糊。AutoHarness 的论文给出了更准确的诊断：

LLM 的失败模式不是"知识缺失"，而是"知识到执行的映射不可靠"。

论文里有个关键数据：在 TextArena 的国际象棋中，Gemini-2.5-Flash 78% 的输局来自非法移动。但论文同时指出，这个模型"理解"规则——它能正确描述马的走法、能解释王车易位的条件。问题出在执行阶段：当棋局复杂、需要同时考虑战略和规则时，模型的内部状态模拟（world model）会"漂移"，生成一个"看起来合理"但实际上违规的动作。

这就像一个老司机知道所有交通规则，但在复杂路口同时要注意导航、行人、信号灯时，偶尔会闯红灯。不是他不知道红灯停，而是注意力资源在战略任务和规则校验之间竞争导致的失误。

AutoHarness 的洞见是：不要把规则验证的任务留给 LLM 的内部推理。把它外化成一个可执行的程序。

二、核心架构：三种 Harness 的数据流差异

AutoHarness 设计了三种变体，它们不是"严格程度"的简单递进，而是控制权分配的根本不同。

2.1 Harness-as-Action-Verifier（默认模式）

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   LLM       │────→│  propose    │────→│  输出动作    │
│  (策略层)    │     │  (模型生成)  │     │             │
└─────────────┘     └──────┬──────┘     └──────┬──────┘
                           │                     │
                           ↓                     ↓
                    ┌─────────────┐        ┌─────────────┐
                    │  Harness    │←───────│  is_legal   │
                    │  验证层     │  不合法 │  (代码执行)  │
                    │             │────────→│             │
                    └──────┬──────┘         └─────────────┘
                           │ 合法
                           ↓
                    ┌─────────────┐
                    │  执行动作    │
                    └─────────────┘
                           │
                           ↓
                    ┌─────────────┐
                    │  环境反馈    │
                    │  (奖励/状态) │
                    └─────────────┘

数据流分析：

• LLM 负责"想走哪步"（策略）
• Harness 负责"这步能不能走"（验证）
• 不合法时，Harness 拒绝，LLM 重新生成
• LLM 始终在控制循环内，Harness 是"守门员"

关键性质：保留 LLM 的通用推理能力。Harness 只拦截违规动作，不影响合法动作的选择。这意味着如果 LLM 提出了一步绝妙但合法的好棋，Harness 不会干扰。

2.2 Harness-as-Action-Filter（过滤器模式）

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Harness   │────→│  propose    │────→│  合法动作集  │
│  (代码生成)  │     │  (代码执行)  │     │             │
└─────────────┘     └─────────────┘     └──────┬──────┘
                                                │
                                                ↓
                                         ┌─────────────┐
                                         │   LLM       │
                                         │  从集合中选择│
                                         └─────────────┘

数据流分析：

• Harness 先枚举所有合法动作
• LLM 只从预筛选的集合中选择
• LLM 的决策空间被 Harness 预先裁剪

关键区别：Verifier 是"事后检查"，Filter 是"事前限定"。Filter 模式更严格，但要求 Harness 能正确枚举所有合法动作——这在复杂游戏中可能很难（比如象棋中某些局面下的合法移动数量巨大，且需要深度搜索才能确定）。

2.3 Harness-as-Policy（策略模式）

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Harness   │────→│  propose    │────→│  最佳动作    │
│  (完整策略)  │     │  (代码执行)  │     │             │
└─────────────┘     └─────────────┘     └─────────────┘
                     ↑                        │
                     │                        ↓
               ┌─────────────┐          ┌─────────────┐
               │  环境状态    │←─────────│  执行/反馈   │
               └─────────────┘          └─────────────┘

数据流分析：

• 运行时无 LLM 调用
• Harness 本身包含完整的策略逻辑
• 可能是启发式、搜索算法、或者规则引擎
• 训练时 LLM 生成代码，测试时代码独立运行

关键性质：这是"知识蒸馏"的极端形式——把 LLM 的推理能力固化成确定性代码。代价是失去通用性，收益是零成本和确定性。

三、Thompson Sampling：在代码空间中的探索-利用平衡

这是 AutoHarness 最核心的算法创新。论文把它放在方法部分，但没有展开讲实现细节。我来补全。

3.1 为什么不是简单的贪心或随机搜索？

代码生成空间是组合爆炸的。一个 Harness 可能包含数十个 if 分支、多个函数、正则表达式、状态变量。每次"突变"都有无数种可能：

• 修改一个条件判断
• 添加一个边界检查
• 重构一个循环
• 引入新的辅助函数

如果随机突变，大部分尝试都是无意义的（比如在一个不需要正则的地方引入正则）。如果贪心搜索（总是沿着当前最好的方向走），可能陷入局部最优。

Thompson Sampling 的优势：

1. 它为每个候选代码维护一个"质量分布"（不是单点估计）
2. 它根据这个分布采样，天然平衡"探索看起来有希望的新方向"和"深挖已验证的好方向"
3. 随着测试数据积累，分布会收窄，自动从探索转向利用

3.2 在 AutoHarness 中的具体实现

论文没有给出伪代码，但从描述中可以重建：

每个树节点 = 一版 Harness 代码

• 根节点：初始模板（空的 propose_action 和 is_legal_action）
• 子节点：父节点代码 + LLM 生成的"突变"

节点评分 = Beta 分布

• 每次 Rollout 测试得到一个二元结果：成功/失败（合法动作判定正确与否）
• 用 Beta(α, β) 建模成功率，其中 α = 成功数 + 1，β = 失败数 + 1
• Thompson Sampling：从 Beta 分布中采样一个值，选择采样值最高的节点进行下一轮精炼

为什么用 Beta？

• 二元结果 + 共轭先验 = 解析更新，不需要 MCMC
• 随着测试次数增加，Beta 分布会变窄，不确定性降低
• 天然支持"奖励函数"——论文提到可以用"平均合法动作准确率"或"结合奖励的混合指标"

3.3 收敛特性

论文给出平均 14.5 次迭代收敛。这个数字背后有几个隐含假设：

• 每次迭代生成 1 个子节点（不是并行扩展多个）
• 每次 Rollout 在 10 个并行环境 中运行，最多 1000 步
• 收敛判据：合法动作成功率 = 1.0（100% 正确）或超时

hardest 的游戏：

• GermanWhist-v0：43 次迭代
• Cryptarithm-v0：45 次
• Othello-v0：62 次
• Chess-v0：64 次

这些游戏的共同特征：规则复杂且状态依赖（比如象棋中将军、王车易位、吃过路兵的合法性都依赖于全局状态）。

四、Critic 工程：错误归因的提示设计

论文轻描淡写地提到 Critic"整合错误类型"，但这其实是非常关键的工程组件。

4.1 Critic 的输入

Critic 接收：
1. 当前 Harness 代码
2. 所有 Rollout 的失败案例（状态 + 动作 + 期望结果 + 实际结果）
3. 环境提供的错误信息（如果有）

4.2 Critic 的输出格式

论文没有透露提示词，但从上下文推断，Critic 的输出应该是结构化的错误归因：

错误分析报告：
- 错误类型：is_legal_action 误判（把非法动作判为合法）
- 具体案例：3 次
  - 案例 1：状态 X，动作 Y，应为 False，实际返回 True
  - 原因分析：没有检查"王是否在将军状态"
  
- 错误类型：propose_action 漏检（合法动作被误判为非法）
- 具体案例：1 次
  - 案例 1：状态 Z，动作 W，应为 True，实际返回 False
  - 原因分析：边界条件处理有误，当 col=0 时提前返回

改进建议：
1. 在 is_legal_action 中增加将军状态检查
2. 修复 propose_action 的边界条件，确保 col=0 时正确处理

4.3 为什么需要 Critic？不能直接给 LLM 原始错误日志吗？

可以，但效率低。原始错误日志是分散的、重复的、噪音大的。Critic 的作用相当于"特征工程"——把原始测试数据提炼成 LLM 能高效利用的"错误模式"。

这类似于强化学习中的"优势函数估计"：不是告诉模型"这一步得了 -1 分"，而是告诉它"这一步比平均水平差多少，差在哪里"。

4.4 触发条件：两种错误，两种精炼策略

论文提到一个关键细节：

情况 A：is_legal_action() 返回 True，但动作实际上非法 → 精炼两个函数：is_legal_action 漏检 + propose_action 可能也提供了非法候选

情况 B：is_legal_action() 返回 False，但动作实际上合法 → 只精炼 propose_action`：说明合法动作被错误地过滤掉了

这个区分非常重要。它避免了"一刀切"地重训练整个 Harness，而是针对性地修复"故障点"。

五、精确对比：AutoHarness 与相关工作的方法论差异

之前那篇文章给了定性对比，这里用表格精确化。

5.1 与 AlphaEvolve 的根本区别

AlphaEvolve 用 LLM 作为"变异算子"，在代码库上运行进化搜索。AutoHarness 的不同在于：

• 搜索空间：AlphaEvolve 搜索"完整算法"，AutoHarness 搜索"约束层/策略"
• 评估方式：AlphaEvolve 依赖单元测试（正确性），AutoHarness 依赖环境交互（合法性和奖励）
• 目标：AlphaEvolve 追求"发现新算法"，AutoHarness 追求"让现有 LLM 可靠执行"

5.2 与 Code-as-Policies 的根本区别

Code-as-Policies 让 LLM 直接生成机器人控制代码。AutoHarness 的不同在于：

• 不是替代 LLM，而是包裹 LLM：Harness 是约束层，不是策略本身
• 有反馈循环：Code-as-Policies 是一次性生成，AutoHarness 是多轮精炼
• 有收敛保证：AutoHarness 明确追求 100% 合法性，Code-as-Policies 没有这种硬约束

5.3 与 Eureka 的根本区别

Eureka 用 LLM 进化搜索生成 RL 奖励函数。AutoHarness 的不同在于：

• 生成目标不同：Eureka 生成"奖励函数"，AutoHarness 生成"控制循环"
• 验证方式不同：Eureka 需要训练 RL 策略来验证奖励函数的好坏，AutoHarness 直接执行 Harness 检查合法性
• 成本结构不同：Eureka 的验证循环昂贵（需要 RL 训练），AutoHarness 的验证循环廉价（单次执行）

六、Harness-as-Policy：知识蒸馏的极限形态

这是 AutoHarness 最激进的结果，值得单独拆解。

6.1 为什么纯代码能比大模型更强？

论文中的 Harness-as-Policy 在 16 个单人游戏中平均奖励 0.870，超过 GPT-5.2-High（0.844）和 Gemini-2.5-Pro（0.707）。

原因不是"代码比 LLM 聪明"，而是：

1. 专用化带来的优化空间

• LLM 是通用模型，需要兼顾所有可能的知识
• Harness-as-Policy 是针对特定游戏专门优化的，可以把全部代码复杂度都投入到"这个游戏的策略"

2. 确定性消除了噪声

• LLM 是概率性的，同样的局面两次调用可能给出不同动作
• 在需要严格逻辑推理的游戏中，这种随机性是劣势
• 代码是确定性的，同样的局面永远做同样的最优决策

3. 预计算的隐式搜索

• Harness-as-Policy 的代码是通过几十轮迭代生成的
• 每一轮迭代都相当于一次"搜索"——尝试不同的策略，保留好的，淘汰坏的
• 最终代码凝聚了多轮搜索的经验，相当于把大量的"思考"预先固化

4. 零延迟的实时响应

• LLM API 调用需要几百毫秒到几秒
• 代码执行是微秒级的
• 在需要快速反应的场景中，这可能带来战术优势

6.2 局限性：为什么双人游戏不行？

论文没有给出 Harness-as-Policy 在双人游戏中的结果（只给了 Verifier 模式的结果）。原因：

双人游戏需要对手建模——你需要预测对手会怎么做，然后据此调整自己的策略。这种动态博弈超出了静态代码的能力范围。

论文引用 Lehrach et al. (2025) 的 Code World Models 作为可能的解决方案——生成完整的游戏状态转移函数，然后结合 MCTS 搜索。但这超出了 AutoHarness 的当前范畴。

七、未解之谜与延伸思考

7.1 跨环境泛化

当前 AutoHarness 是"逐游戏训练"的。一个象棋的 Harness 不能用于围棋。这类似于"每个环境都需要重新发明轮子"。

未来的方向可能是：让 Harness 本身具备元学习能力——学一个游戏的规则后，能迁移到结构相似的游戏。比如，学象棋后，对跳棋的 Harness 初始化可以借用象棋的某些组件（如棋盘遍历、边界检查）。

7.2 Harness 的可组合性

如果每个游戏都有一个 Harness，这些 Harness 之间能否组合？比如：

• 基础 Harness：提供"棋盘游戏通用验证"（边界检查、回合交替）
• 特定 Harness：提供"象棋特有规则"（马走日、象走田）
• 组合方式：基础 Harness 先过滤，特定 Harness 再精筛

这种模块化设计会让 AutoHarness 更接近软件工程的"库"概念。

7.3 从游戏到现实世界

论文的测试环境是 TextArena 游戏。但 AutoHarness 的思想可以延伸到：

• 代码生成：让 LLM 生成代码时，同时生成一个"语法+类型安全"的 Harness
• 机器人控制：生成动作前，先通过物理约束 Harness 验证（碰撞检测、关节限制）
• 数据库操作：生成 SQL 前，通过权限 Harness 验证（不能 DROP TABLE，不能跨库查询）
• 医疗诊断：生成诊断建议前，通过医学知识 Harness 验证（药物禁忌、剂量限制）

这些场景的共同点：存在一个明确的、可验证的规则集合。

八、结语：AutoHarness 的方法论遗产

AutoHarness 的真正贡献，不只是"让 LLM 不违规"这个具体结果。它提出了一种新的 LLM 系统设计范式：

把 LLM 的能力分成"战略层"和"规则层"，战略层保留 LLM 的通用推理，规则层外化为可验证代码。

这类似于计算机科学中经典的"分层架构"：

• 操作系统把硬件细节隔离在内核层，应用层只关心业务逻辑
• 编程语言把内存管理交给运行时，程序员只关心算法
• AutoHarness 把规则验证交给 Harness，LLM 只关心策略

在这种架构下，LLM 不需要"记住"所有规则，它只需要"知道有规则存在"，然后 Harness 负责"执行规则"。这种分离不仅提高了可靠性，还降低了 LLM 的认知负荷——它可以把宝贵的上下文窗口和推理资源集中在真正需要创造力的地方。

这就是为什么"小模型 + Harness"能打败"大模型裸跑"：不是 Harness 让小模型变聪明了，而是 Harness 帮小模型排除了"犯傻"的可能性，让它的有限智能能够稳定发挥。

参考文献

1. Lou, X., Lázaro-Gredilla, M., Dedieu, A., Wendelken, C., Lehrach, W., & Murphy, K. P. (2026). AutoHarness: improving LLM agents by automatically synthesizing a code harness. arXiv preprint arXiv:2603.03329. https://arxiv.org/abs/2603.03329
2. Liang, J., et al. (2023). Code as Policies: Language Model Programs for Embodied Control. ICRA 2023.
3. Novikov, A., et al. (2025). AlphaEvolve: A coding agent for scientific and algorithmic discovery. arXiv:2506.13131.
4. Ma, Y. J., et al. (2024). Eureka: Human-level reward design via coding large language models. ICLR 2024.
5. Lehrach, W., et al. (2025). Code world models for general game playing. arXiv:2510.04542.

#AutoHarness #DeepMind #代码生成 #AI安全 #ThompsonSampling #论文解读 #技术解剖 #小凯