AutoHarness: improving LLM agents by automatically synthesizing a code harness 论文汇报
让 LLM 自动合成代码 harness，用可执行程序补齐 agent 在动作合法性与环境接口上的短板。
1. 论文基本信息
- 论文标题：AutoHarness: improving LLM agents by automatically synthesizing a code harness
- 作者：Xinghua Lou, Miguel Lázaro-Gredilla, Antoine Dedieu, Carter Wendelken, Wolfgang Lehrach, Kevin P. Murphy
- 机构：Google DeepMind
- 版本：arXiv:2603.03329v1
- 时间：2026 年 3 月 5 日
- 汇报人：待填写
本文提出 AutoHarness，核心思想是让 LLM 自动为自己合成一个代码 harness，用外部可执行程序约束 agent 的动作合法性，而不是完全依赖模型内部的规则理解。论文在 TextArena 的 145 个 1-player / 2-player 文本游戏上测试，合成出的 harness 在所有游戏上都达到 100% legal action success rate。进一步地，作者让模型直接合成整套 code policy，在 16 个 1-player 游戏上取得 0.870 平均 reward，高于 Gemini-2.5-Pro 和 GPT-5.2-High。
2. 提纲 / 背景
2.1 背景：LLM agent 会犯“非法动作”错误
LLM 在代码生成和数学推理上进步明显，但作为 agent 进入外部环境时，常常会做出环境规则禁止的动作。论文举的动机例子是 Kaggle GameArena chess competition 中，Gemini-2.5-Flash 的失败有 78% 来自 illegal moves，而不是战略错误。
这类问题说明模型可能“看起来理解规则”，但在实际状态下不一定能稳定判断哪些动作可执行。AI planning 中这类问题被称为 action applicability：在给定状态下，某个动作是否可用。
2.2 传统解决方式的局限
常见修复方式有两种。
第一种是微调模型，让模型从轨迹中学习规则和策略。但大模型微调成本高，也可能损害通用 instruction following 能力。
第二种是人工编写 harness，例如动作合法性检查器、格式约束器、环境包装器。这种方法有效，但每个新环境都要手写，扩展性弱。
本文的判断是：既然 LLM 已经很擅长写代码，就可以让 LLM 自动写出这个 harness。模型不只是输出动作，而是先为任务生成一段外部程序，用程序补齐自己在规则遵守上的短板。
2.3 本文定位
AutoHarness 不直接训练 LLM，也不只是在 prompt 里要求“不要犯错”。它把 agent 的改进问题转化为程序搜索问题：
在代码空间中搜索一个 harness，使它能在环境反馈下持续修复非法动作，并最终稳定过滤或生成合法动作。
这个视角和普通 prompt refinement 不同。prompt refinement 改的是自然语言上下文；AutoHarness 改的是可执行代码。
3. 研究问题与目标
3.1 研究问题
本文要解决的问题是：
如何让一个相对小的 LLM 自动合成任务特定的代码 harness，从而减少或消除 agent 与环境交互时的非法动作，并提升实际游戏表现？
这个问题可以拆成三层。
- 合法性层：代码能否稳定判断或生成 legal action？
- 性能层：过滤非法动作之后，agent 的 reward / win rate 是否提升？
- 成本层：小模型自动合成 harness 是否比直接使用更大模型更划算？
3.2 工作目标
论文的目标包括：
用 Gemini-2.5-Flash 自动合成 action verifier / action proposer。
在 145 个 TextArena 游戏中验证合成 harness 能否避免非法动作。
在 16 个 1P 和 16 个 2P 游戏中测试 end-to-end 游戏表现。
探索极限设定 harness-as-policy：不再让 LLM 在测试时决策，而是让代码直接产生动作。
4. 核心方法 / 模型
4.1 方法总览：code as harness
AutoHarness 把 agent 看成两部分：
Agent = LLM + Harness其中 LLM 负责理解环境和生成候选动作，harness 负责把模型输出连接到环境，并检查、修复或替代不合法动作。本文的关键变化是：这个 harness 不再由人手写，而是由 LLM 在环境反馈下自动合成。
4.2 两个核心函数
论文主要使用两个函数签名：
def propose_action(board: str) -> str:
\"\"\"给定文本形式的游戏状态，提出一个动作。\"\"\"
def is_legal_action(board: str, action: str) -> bool:
\"\"\"判断某个动作在当前游戏状态下是否合法。\"\"\"这两个函数分别负责“提出动作”和“判定动作”。在 harness-as-action-verifier 设置下，LLM 先提出动作，代码用 is_legal_action() 检查；如果非法，就带着 illegal action warning 重新提示 LLM，再尝试生成新动作。
4.3 三种 harness 形态
| 形态 | 动作来源 | LLM 是否参与测试时决策 | 主要作用 |
|---|---|---|---|
| harness-as-action-filter | 代码生成一组 legal moves，LLM 排序 | 是 | 让代码负责合法性，LLM 负责策略选择 |
| harness-as-action-verifier | LLM 先生成动作，代码验证并拒绝非法动作 | 是 | 本文主要实验设置，像 rejection sampler |
| harness-as-policy | 代码直接选择动作 | 否 | 测试时不再调用 LLM，成本几乎为零 |
这三种形态代表不同的代码介入程度。action-verifier 是较保守的版本，只拦截非法动作；harness-as-policy 是最激进的版本，整个策略都由代码实现。
4.4 搜索算法：tree search + Thompson sampling
AutoHarness 把代码合成视为搜索问题。每个节点是一份代码候选，节点的 heuristic value 是平均 legal move accuracy。系统用 Thompson sampling 选择下一个要 refine 的节点，从而在探索新代码结构和利用已有好代码之间平衡。
初始化若干代码候选
while 没有达到 100% legal action rate 且未超时:
用 Thompson sampling 选择一个代码节点
在多个环境中 rollout
收集非法动作、执行错误、reward 等反馈
Critic 汇总失败案例
Refiner 调用 Gemini-2.5-Flash 修改代码
Evaluator 评估新代码
把新代码和 heuristic value 加入搜索树和简单 iterative prompting 相比，这里不是只维护一条代码轨迹，而是维护多条候选分支。这样可以避免某一次错误修改把整个优化过程带偏。
4.5 反馈如何驱动代码修复
论文提到一个关键规则：
- 如果
is_legal_action()返回 True，但环境判定该动作 invalid，说明 verifier 放过了非法动作，需要同时修复is_legal_action()和propose_action()。 - 如果
is_legal_action()返回 False，而且动作确实 invalid，说明 verifier 工作正常，主要需要修复propose_action()，让它更可能提出合法动作。
这体现了 AutoHarness 的一个重要机制：环境不是只给 reward，而是提供“动作是否合法、代码是否执行失败”的结构化反馈。LLM 的任务不是盲目重写，而是根据失败类型定位该改 verifier 还是 proposer。
4.6 训练配置
在 harness-as-action-verifier 实验中，每次迭代使用 10 个并行环境，最多 rollout 1000 步，环境会自动 reset。一旦代码产生 illegal move 或代码执行失败，当前 rollout 终止。最多采样 5 个失败步骤给 Critic，Critic 合并错误信息，再交给 Refiner 修改代码。
训练停止条件是 heuristic value，也就是 legal action success rate，达到 1.0，或者超时。训练模型使用 Gemini-2.5-Flash。
论文报告平均训练 14.5 次 tree search iteration 即可结束，32 个 end-to-end 评估游戏中有 19 个在 10 次以内完成。较难学习的游戏包括 GermanWhist-v0、Cryptarithm-v0、Othello-v0 和 Chess-v0。
4.7 Harness-as-policy 的目标函数
当系统直接学习 code policy 时，legal action 只是最低要求，还要考虑 reward。论文把 heuristic value 改成：
如果采取非法动作：H = 0
否则：H = 0.5 + 0.5r其中 r ∈ [0, 1] 是 episode 结束时的 sparse reward。这个设计让非法动作直接归零，合法但低收益的动作得分中等，高 reward 的代码策略得分更高。
4.8 Mermaid 方法流程
Mermaid 源码
flowchart LR
A["旧代码候选"] --> B["Thompson sampling 选择节点"]
B --> C["环境 rollout"]
C --> D["收集非法动作 / 执行错误 / reward"]
D --> E["Critic 汇总失败案例"]
E --> F["Refiner 调用 LLM 修改代码"]
F --> G["Evaluator 评估新代码"]
G --> H["更新搜索树与 heuristic value"]
H --> B4.9 附录代码示例说明
附录给了 Minesweeper 和 Chess 的代码片段。Minesweeper 的 propose_action() 会先解析棋盘，判断是否是首步；然后根据数字格周围约束推断安全格和地雷；没有确定安全格时，再用概率风险估计选择低风险动作。Chess 示例则包含 UCI 坐标转换、王的位置查找、攻击格判断等基础规则逻辑。
这些示例说明 AutoHarness 合成出的不是简单格式检查，而是可以包含任务特定的状态解析、规则推理和启发式策略。
5. 实验结果与分析
5.1 数据集和任务设置
实验使用 TextArena 中的 1-player 和 2-player 文本游戏。作者排除了 9 个动作空间是自由文本或对话的游戏，保留 145 个游戏，包括 Chess、Checkers、Blackjack、Sudoku 以及许多变体。
为了提高难度，作者还手动移除了部分游戏 observation 中的 Available Moves 提示。这样 harness 不能简单复制合法动作列表，而必须从棋盘状态和环境反馈中推断动作合法性。
5.2 合法动作率：145 个游戏全部达到 100%
附录 Table 1 列出 145 个 TextArena 游戏。所有游戏的 learned harness 在测试 rollout 上都达到 1.0 legal action rate。这个结果支撑了论文最直接的 claim：自动合成的代码 harness 可以系统性消除非法动作。
但这个结果主要证明的是合法性，不等价于策略最优。一个 harness 可以完全避免非法动作，但仍然可能选择很差的合法动作。因此论文进一步做了实际游戏表现评估。
5.3 2-player 游戏表现
这个结果说明 harness 不只是让模型“少犯规”，在一些对抗游戏中也能转化为胜率收益。不过 2P 结果仍受对手策略、随机种子和游戏类型影响，不能直接推出代码 harness 已经学会复杂战略。
5.4 1-player 游戏表现
这个结果说明较小模型加 task-specific harness 可以超过更大模型。但提升幅度不是每个游戏都显著，有些游戏本身已经接近满分，harness 的边际收益有限。
5.5 Harness-as-policy 结果
这一结果是论文最强的效率论点：如果任务足够规则化，先用 LLM 搜索/合成策略代码，再在测试时运行代码，可能比每一步调用大模型更便宜、更稳定。
5.6 附录 per-game 结果
5.7 关键实验结论
| 问题 | 实验证据 | 结论 |
|---|---|---|
| harness 能否消除非法动作 | 145 个 TextArena 游戏 legal action rate 都为 1.0 | 合法性约束非常有效 |
| 小模型 + harness 能否超过大模型 | 2P 对 Gemini-2.5-Pro 9/16 胜，整体 win rate 56.3% | 在部分游戏上成立 |
| 1P reward 是否提升 | 0.745 vs Gemini-2.5-Pro 0.707 vs Flash 0.673 | 平均有提升，但不是所有游戏都大幅提升 |
| code policy 是否可行 | Harness-as-Policy 平均 reward 0.870 | 规则化 1P 游戏上很有潜力 |
| 成本是否降低 | code policy 测试时几乎不调用 LLM | 推理成本优势明确 |
6. 总结
本文的贡献可以概括为四点。
第一，提出 code as harness：让 LLM 自动合成外部代码约束器，用可执行程序补齐 agent 在动作合法性上的短板。
第二，把 harness 生成建模为代码空间中的 tree search，而不是单轮代码生成或线性 prompt refinement。Thompson sampling 使系统能在探索新代码和修复已有代码之间平衡。
第三，在 TextArena 145 个游戏上验证自动合成 harness 能把 legal action success rate 提升到 100%。这说明很多 agent failure 可以通过自动生成环境接口代码来修复，而不一定需要直接训练模型。
第四，提出并验证 harness-as-policy 的极限形态：在部分规则化 1P 游戏中，LLM 先生成策略代码，测试时不再调用 LLM，平均 reward 超过更强的大模型 agent。
这篇论文最重要的启发是：改进 LLM agent 不一定只靠更大的模型、更强的 prompt 或更长的推理链。对于有清晰规则和环境反馈的任务，自动合成“模型外部的程序化约束与策略”可能更稳、更便宜。
7. 个人思考与展望
7.1 优点
AutoHarness 抓住了 LLM agent 的一个真实痛点：很多失败不是因为模型完全不会玩，而是因为它在接口层面违反环境规则。用外部代码修复合法性，比单纯提示模型“注意规则”更可靠。
方法也比较务实。它不要求访问模型参数，不需要 fine-tuning，只需要模型能写代码、环境能执行和反馈。对于许多工程型 agent 场景，这比训练一个新模型更可落地。
另一个优点是成本逻辑清晰。尤其是 harness-as-policy，把昂贵的 LLM 推理成本前置到训练/合成阶段，测试时只运行代码。这对大量重复环境很有吸引力。
7.2 局限性
第一，任务必须有可执行环境反馈。AutoHarness 依赖 rollout、错误消息和 reward。如果任务没有明确环境、没有可验证动作合法性，方法就难以直接使用。
第二，当前实验集中在 TextArena 游戏。游戏规则清晰、状态文本结构相对稳定，这有利于代码 harness。真实软件操作、网页任务、机器人任务中的 observation 可能更杂乱，错误反馈也未必足够结构化。
第三，harness 的泛化方式仍是 one harness per environment。论文也承认当前为每个游戏生成单独 harness。这样能解决单任务，但还没有证明能形成跨任务可复用的通用 harness 库。
第四，合法动作不等于好动作。action-verifier 能过滤非法动作，但不能保证战略最优。Harness-as-policy 能进一步提高 reward，但在 2P 对抗游戏上学习完整策略更难，可能需要 world model 或搜索。
第五，安全和执行风险需要认真处理。论文要求生成 safe-to-execute 代码，但自动生成并执行代码天然有风险。真实系统中需要沙箱、权限隔离、资源限制和代码审计。
7.3 可追问的问题
AutoHarness 是否能从 145 个游戏中抽象出可复用组件，而不是每个游戏单独学习？
如果环境反馈很稀疏或错误消息不清楚，Critic 和 Refiner 是否还能稳定修复代码？
对网页 agent、工具调用 agent、数据库 agent 这类真实任务，action legality 如何定义？
harness-as-policy 的上限在哪里？它是在学习真正策略，还是只在规则化小游戏上写启发式？
自动执行 LLM 生成代码时，如何保证安全性和资源可控性？
7.4 后续研究方向
一个自然方向是建立 reusable harness library。不同游戏或任务可能共享状态解析、动作格式检查、搜索模板、约束求解器等组件。如果系统能检索和组合已有 harness，合成成本会进一步下降。
另一个方向是把 harness 反哺给模型。论文未来工作提到希望把 domain-specific experts 蒸馏回 base LLM，使系统递归自我改进。这会把“外部代码修复”转成“模型内部能力提升”。
第三个方向是扩展到真实 agent 工具链。比如浏览器自动化、API 调用、数据库操作、机器人控制中，都有明确的非法动作和环境约束。AutoHarness 的思想可以用来自动生成 action validator、参数检查器、状态解析器或 fallback policy。
总体来看，AutoHarness 的价值不在于证明小模型全面强过大模型，而在于指出一种更工程化的 agent 改进路径：让模型用代码为自己补上环境接口和规则约束。这个路径在规则明确、反馈可执行、调用频率高的任务中尤其有意义。