AutoHarness

01 / MOTIVATION

会解释规则，为什么还会走错？

一个动作可能战略上很差，也可能根本不被环境接受。下棋走入将军、提交错误坐标、在不允许的阶段使用某个操作，都属于后者。语言模型即使能讲出规则，仍可能在漫长交互中丢失局部状态、误读棋盘或拼错动作。论文引用 GameArena 的观察：Gemini 2.5 Flash 的国际象棋败局中，78% 被归因于非法走法。这个分母是败局，不是全部动作，也不是本文 TextArena 上测出的错误率。§1，p.1

手写每个游戏的 guard 可以拦住错误，但维护不同规则、变体和文本格式需要人工；微调则改动模型权重，训练成本更高。本文提出的研究问题是：能否利用模型的代码生成能力，把环境反馈积累为可重复执行的约束，而不是每个回合重新在语言里推理全部规则？

贡献在哪里？

核心贡献是环境反馈驱动的 harness 程序搜索：保存多个代码版本，用 Thompson sampling 决定继续修哪一个，LLM 负责提出代码变更，环境负责给出合法性和最终奖励。它将代码合成、失败诊断与交互 rollout 接起来；没有提出新神经网络架构，也没有证明一种新的通用搜索收敛定理。§2–3，p.2

02 / REPRESENTATION & PIPELINE

两层循环，三种职责边界。

外层是代码版本搜索：哪份程序值得继续修？内层是游戏交互：这一步该采取什么动作？训练时生成并执行候选代码；评测时使用已选定的 harness。不要把代码搜索树当作运行时的棋局搜索树，也不要把每次拒绝重试当作重新训练模型。

表示层面没有 image encoder、latent token 或可微 renderer。状态首先是字符串，生成的代码可自行解析成棋盘数组、坐标、集合和约束。函数签名不显式传入环境隐藏状态；论文未完整披露每个游戏的 observation/history 包装方式，因此不能假定单个棋盘字符串在所有游戏中都是完备状态。Appendix C

外层：一次代码改进怎样发生

图 1 将代码、反馈和评分连成循环；初始化代码模板、树先验、扩展次数的更新公式没有在本文展开。可确认的是“多个假设＋反馈修复＋Thompson selection”，不能把自己补写的树搜索控制器称为作者开源实现。

内层：三种 harness 并不等价

接口细节：Appendix C 的 propose_action 返回单个字符串，而 §3 的 filter 描述需要候选集合；如何反复调用、去重以及候选数量，本文未明确。不要据描述擅自指定 top-k。

Agent 各组件怎样对应

Reasoning：游戏 LLM 的策略分析与 Refiner 的代码诊断属于不同调用。Action：提交给游戏的动作字符串。Observation：文字棋盘及游戏信息。Feedback：环境错误、合法性与终局奖励。Reflection：Critic 整理失败并驱动代码修订。Retry：Verifier 的同一步重提动作，与外层代码重修分开。Memory：持久化的知识主要在候选程序树；没有单独评估长期 episodic memory 模块。Tools：Python 执行与 TextArena 交互，本文没有视觉渲染反馈。

03 / MATHEMATICAL VIEW

合法性是约束，奖励才是策略目标。

除明确标注的 policy heuristic 外，本节公式是 Our Interpretation：把正文机制形式化，方便理解与复现；不是原文给出的定理或完整实现规范。

1. 程序空间中的无梯度优化

优化变量是代码 c，而不是模型权重 θ。LLM 读取失败状态生成新代码，环境评估新代码。这里没有反向传播、学习率或 optimizer；“14.5 次训练迭代”是代码搜索迭代，不是 epoch，也不必等于所有 LLM API 请求的总数。

2. 合法率 heuristic 与被测试状态分布

它概括正文“平均合法动作准确率”的含义：N 是被计数的动作数，指示函数记录环境是否接受。论文没有完全说明终止 rollout、失败动作与异常的聚合权重，故上式仅作概念表达。通过运行代码产生测试动作，与随机构造全部合法/非法动作做二分类测试并不相同；它不能给出验证器的完整 recall / precision，更不是所有可达状态的证明。

3. Verifier 作为 rejection sampler

在每次提议独立、提示固定、接受概率非零的理想条件下，代码把分布重新归一化到它认可的动作集合上；期望提议次数为 \(1/Z_c(o)\)。但真实方法会把非法警告写进下次提示，因此提议分布会变，上式并非对其运行过程的精确描述。

若 \(v_c\) 错放一个非法动作，它仍可能进入环境；若错拒所有可行动作，循环可能无法退出。即使验证器完美，也只是过滤无效动作，不会自动把合法但低奖励的动作变成好策略。

4. Policy heuristic：先守规则，再追求回报

Paper Verified · §4.3 这是论文明确给出的目标。奖励只在轨迹结束时可用；合法但零奖励也得到 0.5，而有非法动作则得到 0。它把“能执行”设为首要门槛，在合法轨迹内部才按奖励排序。例：合法且 r=0.8 时 H=0.9；高回报轨迹若出现一次非法动作，H 仍为 0。它不是逐步提供密集策略奖励。

训练平均 H=0.939 与测试平均奖励 0.870 不是同一量。即使假设全部训练轨迹合法，从前者反算得到 r=0.878，也不能拿它替代独立测试分数。

5. Thompson sampling 为什么保留多份代码

这是 Thompson sampling 的一般解释：从每个候选的不确定性分布采样“值得继续探索”的分数，再选最大者。已经不错的代码通常被选中，尚不确定的分支也有机会。这里 u 是通用价值变量，不代表本文具体实现了某个 Beta 后验；本文只给出 heuristic weight=1.0，并引用 REx，未公开完整先验、更新和回传方程。不能替作者补出一套确定的 Beta-Bernoulli 算法。

04 / REPRODUCTION

哪些设置已知，哪些仍然缺失。

模型、数据与训练预算

推理与测试协议

Prompt 的信息流

Appendix B.1 将 {player_id} 和 {observation} 放入游戏玩家模板，要求先分析再给出一个最佳动作，以 <move>...</move> 包裹，闭合标签后不再添加内容。这是作者的原始提示设计描述，不代表额外公开了模型的内部推理轨迹。

B.2 向 Refiner 提供 {name}、{description}、{action_space}、{tasks_with_feedback}、{code} 与 {code_signatures}。它要求定位失败步骤、修复当前错误、兼容全部已见棋盘、提高进度、避免循环；必要时从最佳合法动作中随机取一个，禁止 try-except，代码放在 Python code block。禁止捕获异常使失败更容易暴露，但提示词本身不是执行沙箱。

You are an expert, logical, and strategic AI game player. Your task is to analyze the following game information and determine the single best move to make.

Read the game rules, your player role, the current game state, and all available moves carefully. Your objective is to play optimally to maximize your chances of winning the game.

You are now player {player_id}.

The game information is as follows:
{observation}

**YOUR TASK:**

You must now analyze the situation and provide your move. Follow these two steps precisely.

**Step 1: Think**
First, provide your step-by-step reasoning. Analyze the current game state, your goal, and the available moves. Evaluate the pros and cons of the most promising options and explain why you are selecting your final move.

**Step 2: Move**
After your thinking block, provide *only* the single best move you have chosen. The move must be one of the valid moves listed in the game information.

Enclose your final move in `<move></move>` tags. Do not add any other text, explanation, or punctuation after the closing `</move>` tag.

Example of a correct response format:
<move>
[Your chosen move]
</move>

You are a python programmer with expertise in text games.

You are given a text game with the following name: {name}

Here is a description of the game.
{description}

Here is a description of the action space of the game.
{action_space}

You are observing the following game boards as text with error feedback.
{tasks_with_feedback}

Your task is to write or refine the following python functions.
```python
{code}
```

Make sure to follow these function signatures.
```python
{code_signatures}
```

Make sure to follow these instructions.

* Think step by step about the code, the game boards and the error feedback.

* Reason about each action through the game board and write down critical failure steps.

* Reason about code refinements that can help fix the failure steps.

* Reason about the entire sequence of actions and write down the progress of the game as a value between 0 and 1.

* Reason about code refinements that can help improve the game progress.

* Reason about code refinements that can avoid running in loops.

* Write down your thoughts before writing the code.

* Make sure to follow the given function signatures.

* Make sure the new code can satisfy all the observed game boards.

* Make sure the new code can fix all the current errors.

* Make sure to only produce code that is safe to execute.

* Make sure the code is concise and precise.

* If necessary, randomply sample one of the best legal actions and return it as the proposed action.

* Do not use any the try-except blocks.

* Write your functions in a python code block enclosed in ```python

可执行的复现路线

1. 固定 TextArena 版本与 32 个主评测 ID，显式保存合法动作提示的删除规则；为合成、开发、最终测试分配不同 seeds。
2. 按 Appendix C 的签名建立候选程序执行器，记录完整文本观测、动作、验证器结果、环境判定、异常与终局奖励。
3. 实现候选版本树与可替换选择器，按失败样本构造 B.2 提示；将未公开的搜索细节写入自己的配置，标记为复现假设。
4. 先跑独立合法性测试，再冻结代码，分别评测 Verifier 与 Policy；至少分开统计“被提出”“被拒绝”“被提交”“环境接受”的动作。
5. 在相同 seeds、调用 / token 预算下比较裸模型、反馈重试、手写 / oracle verifier 与自动 verifier；报告奖励、拒绝率、漏放率、延迟和总成本。

上述步骤是可复现工程建议；论文并未提供这些步骤中所有实现与对照。

05 / RESULTS

收益清楚，优势并不均匀。

16 个单人游戏：平均奖励

下表重建正文 §4.2–4.3 / Figure 5 的均值。奖励按原文保留三位小数；最佳加粗、次佳加下划线。不同模型重复次数不同，不把 0.026 的均值差直接表述为统计显著。

Our Interpretation · 根据报告均值计算 Flash＋Verifier 相对 Flash 增加 0.072（约 10.7%），相对 Pro 增加 0.038（约 5.4%）；纯代码策略比 GPT-5.2-High 高 0.026（约 3.1%）。这些是平均奖励的差 / 相对变化，不是准确率的百分点。

Figure 6：逐游戏奖励，重建为可读数据表

直接按原论文图内数字转录。每行最高值加粗，次高的不同数值加下划线；并列保留。Flash＋H 指 Verifier；Code 指 Harness-as-Policy。可横向滚动。

纯代码策略在 2048（0.912 vs 0.745）、FifteenPuzzle（0.597 vs 0.183）和 PegJump（1.000 vs 0.429）明显超过 GPT-5.2-High；后者在 Bandit、Blackjack、Minesweeper、Secretary、Sokoban 五个任务领先，另外八项持平。这解释了“平均更高”与“赢的任务更少”可以同时成立：差值幅度比简单计胜更重要。Figure 6，p.11

Verifier 的强项也不是一概增益。相比裸 Flash，Bandit 从 0.398 降至 0.208，Secretary 从 0.550 升至 0.650 但低于 Pro 的 0.700；在已满分的任务上则没有额外空间。合法性约束能移除错误，也可能改变动作采样、限制探索；论文没有用单独实验分解这些成因。

查看原论文 Figure 6，与转录表逐项对照

16 个双人游戏：对战而非单模型分数

每游戏 40 局、16 个游戏，意味着每组对手比较计划包含 640 局。9/16 是环境层面的计数，56.3% 是对局胜率；数值碰巧相近，不能把它们视为同一个统计量。图 3 中 Othello、GermanWhist 等仍然难打；Chess、Checkers、Stratego 上则优势更明显，说明检查动作并不能替代全部对抗规划。

成本：把离线合成算进去

作者报告 GPT-5.2 与 GPT-5.2-High 的实验约花费 640 美元，纯代码策略测试时成本近零。这里的近零主要指没有 LLM 推理费用，不能理解成总项目成本为零；Policy 先做了平均 89.4 次代码合成迭代，Verifier 运行时仍需模型，拒绝时还可能多次调用。原文没有提供完整、统一的 token / 延迟 / 合成成本表。§4.3

Our Interpretation：当分母为正时，这个摊销关系说明高频使用更有利于代码策略。论文没有给出足够数据求实际 break-even 局数；640 美元不是所有方法在等量任务上的统一预算。

06 / EVIDENCE AUDIT

三个不能被摘要抹掉的细节。

一：100% 指哪一种实验？

Table 1 对 145 个环境的独立合法性 rollout 都报告 1.0；但 Appendix Figure 7 的端到端 Flash＋Harness列中，有 7 个单人游戏小于 100%。例如 FifteenPuzzle 是 96.59%，RushHour 是 97.24%，PegJump 是 98.25%。因此网页不会把“自动 harness 永远消除所有非法动作”当成已被全面证明的结论。

Figure 7 的纯代码策略列为全部 100%。两组实验的动作来源不同，确实可能造成差异；然而正文没有把 Figure 7 的“legal action rate”分母讲清楚：是在过滤之前计数，还是最终提交之后？失败重试是否纳入？是分布变化还是统计口径？目前只能确认报告差异，不能替作者给出已证实的解释。独立 rollout 的通过率也不是验证器在所有状态上的形式正确性。Figure 7，p.11

查看原论文 Figure 7

二：平均 14.5 次，对应 32 项而非 145 项

我们对 Table 1 做了复算：带星号的 32 个游戏学习步数平均正好为 14.5，其中 19 个少于 10 次，与正文一致。若使用全部 145 行，则均值为 10.303；最大值是 Breakthrough-v0-small 的 136。因此正文关于“最难游戏”的讨论应放在所选子集内理解，不能套到所有变体。Table 1 表头叫 Learning Steps，caption 又描述 LLM calls；由于系统还有 Critic 等角色，不将其等同于完整账单请求数。

三：8 胜 5 平的文字总结，与逐项表不完全一致

正文称 Flash＋Harness 对比 Pro 是 8 胜、5 平，余下 3 负。但按 Figure 6 的三位小数逐行比较，得到 9 胜、5 平、2 负（负项是 2048、Secretary）。Bandit 的 0.208 与 0.201 也构成一个表面胜项。未知作者是否使用了未报告的容差或另一份统计；这里不擅自修正原文，也不把微小差值当显著改进。纯代码对 GPT-5.2-High 的 3 胜、8 平、5 负则与表一致。

Table 1：全部 145 个环境条目

原始编号、学习步数和合法率按 Appendix Table 1 转录。* 表示参加 32 游戏端到端评测。筛选只改变显示，不改数据；“全部 145”包含同一游戏的多种配置。

Ablation：论文没有给出完整消融矩阵

尤其缺少：首次生成不修复、去掉 Critic、纯文本反思、等预算反馈重试、oracle verifier、手工 verifier、不同采样权重，以及更换合成 LLM 的实验。文章展示了系统可行性，却尚未证明每一个设计选择都是必要的。

07 / PAPER VS. IMPLEMENTATION

公开代码片段，能告诉我们多少？

本节基于 Appendix D 的真实代码片段进行静态阅读。作者明确表示不是完整 harness；本次没有确认完整官方训练、推理仓库，所以既不宣称已运行复现，也不把同名第三方仓库视作证据。

Minesweeper：规则推导与手工形式的启发式共同出现

1. 解析文本。调用 parse_board_to_grid 和 get_board_dimensions；这两个辅助函数不在该片段里完整展示。空棋盘或零维度抛异常。
2. 首次动作。若所有格子为点号，选择靠中心的格子；这是一种策略偏好，单凭片段不能保证该格在任意扫雷环境中安全。
3. 约束传播。每个数字格提供邻域雷数：剩余雷数等于未知格数，则全部标雷；剩余雷数为零，则全部标安全。
4. 子集规则。如果一个线索的未知集合是另一线索的子集，比较两者雷数之差，推断差集全部安全或全部为雷。
5. 启发式猜测。没有确定安全格时，用相邻线索给出的局部风险均值；无相邻线索则用全局剩余雷比例，随机选择最小风险格。
6. 兜底。没有上述候选时，尝试从仍未知的格子随机选；无可选动作则抛异常，不默默吞掉错误。

Our Interpretation：N 是数字线索，k 是已知邻域雷数，U 是仍未知邻域；这是代码中的约束传播关系。对子集 \(U_1\subset U_2\)，若 \(m_2-m_1=0\)，差集安全；若 \(m_2-m_1=|U_2\setminus U_1|\)，差集全为雷。局部风险的算术平均不等于考虑所有重叠约束后的精确后验。

Chess：动作格式和攻击关系被显式程序化

片段实现 UCI 坐标与数组索引互换，棋盘固定为 8×8，用大写 / 小写识别阵营；枚举兵斜向攻击、马的八种偏移、王的邻格，以及车 / 后直线、象 / 后斜线的阻挡关系。对标准国际象棋而言，这些常量是规则编码，不是随意偏置。

但附录只展示辅助函数：没有给出完整 is_legal_action，也无法从中核实王车易位、吃过路兵、升变、历史状态、走后自将军等情况如何处理。因此“片段看起来合理”并不等于已经审计了一个完整国际象棋规则引擎。Appendix D.2，pp.19–21

08 / REVIEWER COMMENTARY

有价值的系统思路，仍需更严格的归因。

主要弱点与可能影响

1. 评测覆盖与泛化。145 项包含大量变体，端到端只选 32 项，选择标准未完整交代；每个环境专门合成代码，尚未证明对新规则零样本迁移。不能当作通用 harness 已经自动完成。
2. 合法率度量不透明。Table 1 与 Figure 7 的差异需要解释。当前测试偏向所执行的动作，可能遗漏验证器的 false rejection；“永远拒绝”或过度保守的验证器必须通过活性与任务完成率识别。
3. 因果归因不足。增加重试计算、反馈文本、代码检查一起发生，没有等预算或单组件对照。能说整个系统有效，不能说 Thompson sampling 或特定 Critic 独立贡献了多少。
4. 统计可信度有限。单人游戏只有 20 / 10 / 5 局，不等量；公开图表没有相应置信区间或显著性检验。对 0.870 与 0.844 的差异，应报告不确定性和配对 seed 结果。
5. 可复现性与成本。完整实现未确认公开，LLM 依赖专有 API，版本与采样配置缺失；约 640 美元的测试费用无法直接证明总成本最优。
6. 语义与信息边界。规则检查需要的信息未必全部可见，尤其是历史相关或部分可观测任务；移除候选列表后保留“从列表选择”的 prompt 也需要验证影响。

下一步应该怎样做实验

对 Procedural Material Generation 的可迁移启发

Research Extension · 未经本文验证 可以让模型为某一种材质图接口合成 is_valid_edit(graph, edit)：先检查端口类型、参数域、环与节点支持情况，再允许 renderer 执行；把失败日志按编译、执行、视觉质量分开反馈。程序合法与材质像不像目标，应始终是两个独立评价维度。

更有研究价值的命题不是“加一个 checker 会不会好”，而是：在同等渲染预算下，自动生成的执行约束能否提高有效探索比例，又不误拒新颖图结构？设计时可使用不可改的编译器判定、独立测试集与多指标选择，防止候选代码通过放松检查器来“刷分”。材质图的拓扑、连续参数、视觉相似度和不可微执行链条均未在 AutoHarness 中实验；这里仅提出迁移方向。

09 / REFERENCES & READING MAP

回到一手资料。

1. Lou et al. · AutoHarness · arXiv 元数据：标题、作者、版本与提交记录。
2. AutoHarness v1 原始 PDF，21 页：本页主要依据。pp.1–3 动机与方法；pp.3–5 实验；pp.8–10 Table 1；p.11 Figures 6–7；pp.12–14 observation、prompts、signatures；pp.15–21 代码片段。
3. arXiv HTML 全文与附录：交叉核对表格、函数与提示词；正文数据仍以 PDF 对照为准。
4. ICLR 2026 Workshop on Recursive Self-Improvement · 官方接收列表：Poster #68。OpenReview 条目由官方列表链接；本次正文访问遇到验证页，未据此声称读过评审意见。
5. Kevin Murphy · Code Synthesis for Improving Agentic Decision Making，April 2026：作者报告，补充 code-as-harness / code-as-world-model 的关系。
6. TextArena 官方仓库：环境入口；当前仓库状态不等于论文实验快照，本文没有以当前规则替换论文设置。

来源许可：论文 arXiv HTML 标明 CC BY 4.0。原论文 Figures 1–7 及 Table 1 保留编号、作者归属和来源链接；图像裁切、表格重排与中文解读属于本页整理。原始 prompt 的引用位于折叠区。其余数学形式化和 reviewer 意见已分别标注。