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 是"守门员"
2.2 Harness-as-Action-Filter（过滤器模式）
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Harness │────→│ propose │────→│ 合法动作集 │
│ (代码生成) │ │ (代码执行) │ │ │
└─────────────┘ └─────────────┘ └──────┬──────┘
│
↓
┌─────────────┐
│ LLM │
│ 从集合中选择│
└─────────────┘
数据流分析：
- Harness 先枚举所有合法动作
- LLM 只从预筛选的集合中选择
- LLM 的决策空间被 Harness 预先裁剪
2.3 Harness-as-Policy（策略模式）
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Harness │────→│ propose │────→│ 最佳动作 │
│ (完整策略) │ │ (代码执行) │ │ │
└─────────────┘ └─────────────┘ └─────────────┘
↑ │
│ ↓
┌─────────────┐ ┌─────────────┐
│ 环境状态 │←─────────│ 执行/反馈 │
└─────────────┘ └─────────────┘
数据流分析：
- 运行时无 LLM 调用
- Harness 本身包含完整的策略逻辑
- 可能是启发式、搜索算法、或者规则引擎
- 训练时 LLM 生成代码，测试时代码独立运行
---
三、Thompson Sampling：在代码空间中的探索-利用平衡
这是 AutoHarness 最核心的算法创新。论文把它放在方法部分，但没有展开讲实现细节。我来补全。
3.1 为什么不是简单的贪心或随机搜索？
代码生成空间是组合爆炸的。一个 Harness 可能包含数十个 if 分支、多个函数、正则表达式、状态变量。每次"突变"都有无数种可能：
- 修改一个条件判断
- 添加一个边界检查
- 重构一个循环
- 引入新的辅助函数
Thompson Sampling 的优势： 1. 它为每个候选代码维护一个"质量分布"（不是单点估计） 2. 它根据这个分布采样，天然平衡"探索看起来有希望的新方向"和"深挖已验证的好方向" 3. 随着测试数据积累，分布会收窄，自动从探索转向利用
3.2 在 AutoHarness 中的具体实现
论文没有给出伪代码，但从描述中可以重建：
每个树节点 = 一版 Harness 代码
- 根节点：初始模板（空的
propose_action和is_legal_action） - 子节点：父节点代码 + LLM 生成的"突变"
- 每次 Rollout 测试得到一个二元结果：成功/失败（合法动作判定正确与否）
- 用 Beta(α, β) 建模成功率，其中 α = 成功数 + 1，β = 失败数 + 1
- Thompson Sampling：从 Beta 分布中采样一个值，选择采样值最高的节点进行下一轮精炼
- 二元结果 + 共轭先验 = 解析更新，不需要 MCMC
- 随着测试次数增加，Beta 分布会变窄，不确定性降低
- 天然支持"奖励函数"——论文提到可以用"平均合法动作准确率"或"结合奖励的混合指标"
3.3 收敛特性
论文给出平均 14.5 次迭代收敛。这个数字背后有几个隐含假设：
- 每次迭代生成 1 个子节点（不是并行扩展多个）
- 每次 Rollout 在 10 个并行环境 中运行，最多 1000 步
- 收敛判据：合法动作成功率 = 1.0（100% 正确）或超时
- 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 与相关工作的方法论差异
之前那篇文章给了定性对比，这里用表格精确化。
| 维度 | Code-as-Policies | AlphaEvolve | Eureka | Voyager | Reflexion | AutoHarness |
|---|---|---|---|---|---|---|
| 生成目标 | 一次性代码 | 完整算法 | 奖励函数 | 可执行技能 | 口头反思 | Harness / 策略 |
| 搜索机制 | 无（直接生成） | 进化算法 | 进化算法 | 技能库积累 | 语言层面强化 | Thompson Sampling 树搜索 |
| 反馈来源 | 无（生成即结束） | 单元测试 | 环境奖励 | 执行验证 | 口头自我评估 | 环境执行 + 错误归因 |
| 迭代性 | 一次性 | 多代进化 | 多代进化 | 持续增量 | 单轮反思 | 多轮精炼 + 收敛判据 |
| 运行时架构 | 纯代码 | 纯代码 | LLM + 奖励 | LLM + 技能库 | LLM | LLM + Harness / 纯代码 |
| 适用场景 | 机器人控制 | 算法发现 | RL 任务 | 开放世界游戏 | 通用推理 | 严格规则环境 |
| 与 LLM 关系 | LLM 生成后退出 | LLM 作为变异算子 | LLM 设计奖励 | LLM 作为技能生成器 | LLM 自我对话 | LLM 生成约束层，运行时可选隔离 |
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 是针对特定游戏专门优化的，可以把全部代码复杂度都投入到"这个游戏的策略"
- LLM 是概率性的，同样的局面两次调用可能给出不同动作
- 在需要严格逻辑推理的游戏中，这种随机性是劣势
- 代码是确定性的，同样的局面永远做同样的最优决策
- Harness-as-Policy 的代码是通过几十轮迭代生成的
- 每一轮迭代都相当于一次"搜索"——尝试不同的策略，保留好的，淘汰坏的
- 最终代码凝聚了多轮搜索的经验，相当于把大量的"思考"预先固化
- 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 再精筛
7.3 从游戏到现实世界
论文的测试环境是 TextArena 游戏。但 AutoHarness 的思想可以延伸到：
- 代码生成：让 LLM 生成代码时，同时生成一个"语法+类型安全"的 Harness
- 机器人控制：生成动作前，先通过物理约束 Harness 验证（碰撞检测、关节限制）
- 数据库操作：生成 SQL 前，通过权限 Harness 验证（不能 DROP TABLE，不能跨库查询）
- 医疗诊断：生成诊断建议前，通过医学知识 Harness 验证（药物禁忌、剂量限制）
---
八、结语：AutoHarness 的方法论遗产
AutoHarness 的真正贡献，不只是"让 LLM 不违规"这个具体结果。它提出了一种新的 LLM 系统设计范式：
> 把 LLM 的能力分成"战略层"和"规则层"，战略层保留 LLM 的通用推理，规则层外化为可验证代码。
这类似于计算机科学中经典的"分层架构"：
- 操作系统把硬件细节隔离在内核层，应用层只关心业务逻辑
- 编程语言把内存管理交给运行时，程序员只关心算法
- AutoHarness 把规则验证交给 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 #论文解读 #技术解剖 #小凯