Mid-Harness：在「模型-沙箱边界」做 test-time compute，让 terminal agent 不再被自己生成的差命令坑死

  • 关联论文：2609.39982
  • 作者：flyP
  • 更新：2026-10-02

§0 元层五问

  1. 真实问题：Terminal agent（命令行/代码 agent）哪怕生成了一个「对的」动作，落地执行时仍可能被自己前几步生成的「错的」命令坑死——例如装错包、删错文件、改坏环境配置，模型之后本可以给出更好的动作，却被污染的环境锁死。单纯把更多算力灌给「让模型生成更好的下一步」并不能解决这道坎。
  2. 核心主张：把 test-time compute 从「生成端」挪到「模型-沙箱边界」（即 action 真正被 harness 转发执行之前），先采样若干候选 action、用 verifier 检验、再放行一个。这种 action scaling 比单纯生成更多轨迹更便宜、更稳。强 verifier（GPT-5.6 Sol）能替弱 generator「翻盘」；弱 verifier 配再多采样也无收益。
  3. 谁应该关心：做 terminal agent、code agent、SWE-bench 类执行评估、test-time compute scaling 的工程与研究者；尤其关心 token 成本/可靠性权衡的人。
  4. 值得读否：值得。机制清晰、数据完整（TerminalBench-Lite 上 GPT-5.6 verifier 把 Pass@1 从 50.00% 拉到 68.03%，8 采样）、跨多个模型/沙箱/基准复现，是把 test-time scaling 从「LLM 内部」推到「LLM ↔ 沙箱接口」的标志性工作。
  5. 边界声明：①模型名 TMAX-9B / GPT-5.6 Sol 在 arXiv 原文如此写，原文未明确它们分别对应的实际开源/商用基座；②训练成本、verifier 推理延迟、完整 token 账单未给出具体数字；③TerminalBench-Lite 之外的基准仅给出方向性结论，原始表格未核；④项目页 byungkwanlee.github.io/MidHarness-page 已公布但本轮未做 clone 级验证。

一句话结论

Mid-Harness 把「动作生成」与「动作验证」解耦，让 agent 在真正落沙箱之前先用 verifier 在候选 action 里挑一个「安全且有效」的；在 TerminalBench-Lite 上，TMAX-9B 生成 + GPT-5.6 Sol 验证把 Pass@1 从 50.00% 提到 68.03%（8 采样），且比单纯多采样轨迹更省 token。

解决什么真问题

Terminal agent 的执行轨迹是「不可逆环境写入链」。一次 pip install wrong-package 会污染 venv，一次 rm -rf 会破坏后续定位。这种「单步错 → 全局不可逆」在文本推理里不存在——文本答错了改 answer 就行，环境没法「回滚」到干净状态重答。

现有三条思路都不够：

  1. 加更多训练数据让 generator 更准：没法解决分布外和对抗式命令；模型依然会偶发犯错。
  2. 给 generator 配更强的推理 prompting / self-critique：只能改下一次输出，已经写进环境的污染救不回来。
  3. 多采样多条 trajectory 再选一条：成本高、且需要长上下文回滚机制；尤其在不可逆环境下做 rollback 本身就坑。

Mid-Harness 的洞察是：绝大多数错误不必等到「整条 trajectory 结束」才被发现——只要在 harness 转发 action 之前加一道「verifier 检票」环节，单步错误就能拦下来。这把 test-time compute 的位置从「LLM 内部解码」挪到了「LLM ↔ 沙箱」的接口处——这是一个新位置（论文称之为 mid-harness），所以叫 Mid-Harness。

核心方法

整体结构

Mid-Harness 在不修改 generator 也不修改 harness 的前提下，在中间塞一个「采样-验证-转发」模块（论文称之为 sandwich / sigmoid，介于二者之间）：

┌─────────────┐   propose   ┌─────────────┐  verify  ┌────────┐
│  Generator  │ ─────────► │  Candidate  │ ───────► │ Harness│ → env
│  (TMAX-9B)  │   N 次采样  │   Actions   │  选 1 条  └────────┘
└─────────────┘            └─────────────┘
                                       ▲
                                       │ pairwise / score / 等验证机制
                                       │
                                ┌──────────────┐
                                │   Verifier   │
                                │ (GPT-5.6 Sol │
                                │  / TMAX-9B)  │
                                └──────────────┘

关键机制 1：action scaling

对同一个状态 $s$，generator 采样 $N$ 个候选动作 ${a_1, ..., a_N}$。验证后再把唯一一条送进 harness 执行。这是把 self-consistency / pass@k 的逻辑从「生成 token 序列」下沉到「生成可执行 action」。

形式上，给定策略 $\pi_g$（generator）和状态 $s$，候选集合为 ${a^{(1)}, \ldots, a^{(N)}} \sim \pi_g(\cdot|s)$。verifier $V$ 在该集合上选择最终动作 $a^* = V({a^{(1)}, \ldots, a^{(N)}})$，再交给 harness 执行。这种「先并行扩展，再串行筛一」的结构，相比「串行生成 $N$ 条完整轨迹再选」节省的算力主要来自：(1) 共享前缀的状态评估；(2) 不必为每个候选跑完完整 trajectory 才做选择；(4) 失败回滚不需要执行 $N-1$ 次，只在 verifier 拒绝时回到状态 $s$ 重新采样即可。

关键机制 2：verifier 的强弱决定 action scaling 收益

论文对比两类 verifier：

  • 强 verifier：GPT-5.6 Sol——能识别「更好的替代 action」，并准确选出。在 8 采样下，把 Pass@1 从基线 50.00% 提到 68.03%。
  • 弱 verifier：用 TMAX-9B 自己当 verifier，需要换验证机制。论文发现当 verifier 与 generator 是同一模型时，pairwise verification（让模型在两个候选之间二选一）比 score-based verification（让模型给每个候选打分）效果更好。

关键机制 3：verifier distillation

把强 verifier（GPT-5.6 Sol）的判别能力蒸馏回 TMAX-9B，使 generator+verifier 角色都压回小模型而不损失性能。这一步非常工程友好——部署时不再需要每步都调用 GPT-5.6 Sol。

关键机制 4：action scaling + trajectory scaling 的复合

论文在 TerminalBench-Lite 上画了一条 token-成本 vs. 成功率的 Pareto 曲线：在固定 token 预算下，「8 采样 + verifier」比单纯「8 条完整 trajectory 采样」能到更高的成功率。换句话说，对终端 agent 而言，把 test-time compute 放在「动作级」比放在「轨迹级」性价比更高。

伪代码（关键流程）

def mid_harness_step(state, generator, verifier, N=8, mode="pairwise"):
    # 1. 采样 N 个候选 action
    candidates = [generator.propose(state) for _ in range(N)]
    # 2. verifier 挑选
    if verifier.is_strong:
        chosen = verifier.best_of_n(candidates)
    else:
        # 同模型做 verifier 时 pairwise 比 score 更好
        chosen = pairwise_select(candidates, verifier)
    # 3. 转发到 harness
    return harness.execute(chosen)

关键实验与数据

设置 基准 关键数字 来源
TMAX-9B baseline (1 sample) TerminalBench-Lite Pass@1 = 50.00% abstract 核实
TMAX-9B + GPT-5.6 Sol verifier, N=8 TerminalBench-Lite Pass@1 = 68.03% (+18.03pp) abstract 核实
TMAX-9B 当 verifier, pairwise TerminalBench-Lite 同模型 verifier 评估机制中最佳 abstract 核实
Verifier distillation 回 TMAX-9B TerminalBench-Lite 在不动 generator 的前提下进一步提升 Pass@1 abstract 核实
Action scaling + trajectory scaling 组合 TerminalBench-Lite 同 token 预算下成功率高过纯轨迹采样 abstract 核实
跨模型/基准/沙箱 "additional models, benchmarks, harnesses" 性能一致提升（具体表格数字原文未明确给出） abstract 方向性表述

⚠️ 上表「跨模型/基准/沙箱」一栏的具体数字未在 abstract 里给出，原文需翻 PDF/附录确认，本轮不编造。

亮点与局限

亮点

  1. 位置选得巧：test-time compute 在「LLM ↔ 沙箱」接口做，能拦下不可逆错误的早期信号，这个观察本身就贡献了一个新维度。
  2. 「强 verifier 翻盘弱 generator」：50→68 在 terminal agent 上是非常可观的提升，且只用 8 采样，工程上负担得起。
  3. 同模型 verifier 配 pairwise 的工程建议：这条结论对自部署很关键——很多团队没强 verifier，这个结论给了一条可行路径。
  4. distillation 闭环：强 verifier 可蒸馏回小模型，部署成本不爆炸。
  5. 机制与成本同时给：用 Pareto 曲线而不是单一指标，比「我们 SOTA」诚实得多。

局限（诚实标注）

  1. 依赖 verifier 质量：8 采样 + 弱 verifier 几乎不涨。换言之 Mid-Harness 不是银弹，没有 verifier 时收益归零——这点论文自己也强调了「capable verifier can exploit useful alternatives」。
  2. TerminalBench-Lite 是新基准：覆盖 4 个 SE 域是 CUA-SWE 的范围，Mid-Harness 的 TerminalBench-Lite 是子集或并行基准；外部泛化（real-world dev task）仍待更多独立复现。
  3. verifier 推理本身的成本：每步 verifier 调用一次或 $N$ 次，延迟放大，论文未给出完整 wall-clock 与 token 数。
  4. N=8 不是免费：8 采样 + pairwise 在大动作空间下选 verifier 的延迟不可忽视。
  5. 跨沙箱/模型的数字模糊：abstract 只给方向性「improves across additional models, benchmarks, harnesses」，没有逐基准具体数字——本轮不补完，需翻 PDF/附录。

对工程落地的启发

  1. .5 立即可拿的工程动作：把 harness 入口改成「先采样 N 个 action → verifier 选 → execute」，是低侵入式改造，不动 generator 也不动 harness 内部。
  2. 没有 GPT-5.6 也能做：同模型做 verifier + pairwise 优于 score——这条是立即能复用的策略。
  3. action-level scaling 是新的算力预算维度：之前 SOTA scaling law 主要在「token / trajectory」维度，现在多一个「action 维度」可调。
  4. token 成本-成功率 Pareto 曲线：以后做 terminal agent 选型，应该看 Pareto 而非单一数字。
  5. Verifier distillation 路径可迁移：用 GPT-5.6 / Claude / Gemini 做 teacher，把判别能力蒸馏进开源 7B/9B，能以小模型承担 verifier 角色。
  6. ⚠️ 工程坑点——见下。
  7. Verifier 选型与延迟权衡：实际工程里 verifier 选 GPT-5.6 vs 本地 7B 蒸馏版涉及多目标 trade-off——精度、延迟、成本、可观测性，建议做小规模 A/B 再决策。

§八 工程实践坑点清单

  1. 现象：用 TMAX-9B 当 verifier 时，score-based 评分（让模型给每个候选独立打分）经常给出趋同分数，无法区分。影响：看起来「很多候选都好」，实际随机选一个。修复：换 pairwise，让模型在两两之间二选一，得到偏好差。
  2. 现象：强 verifier（GPT-5.6 Sol）每步调用延迟 0.5-2s 不等（具体数字原文未明确给出），单 trajectory 总时长放大 4-10x。影响：实时性敏感场景（CI 修 bug、用户交互）下不可用。修复：先做 verifier distillation，把 verifier 成本压回本地小模型；或异步做 verifier（下一轮 action 验证与当前执行 overlap）。
  3. 现象：采样 N 个候选 action 全部走完 verifier 才选一，wall-clock 浪费 7/8。影响：长 horizon 任务总成本爆炸。修复：early-stop——verifier 信心足够高就提前结束采样；或用 cascade verifier（先用便宜的弱 verifier 过滤，再用强 verifier 精排）。
  4. 现象：TerminalBench-Lite 包含 pip install wrong-package 类不可逆污染测试，但 verifier 只能拦当前 action，拦不住 generator 在更早的 step 已经写坏的状态。影响：污染一旦发生，后续无论 verifier 多强都救不回来。修复：在沙箱侧加 snapshot/rollback 机制（轻量容器快照），让 verifier 能在 sandbox 回滚下重新评估候选。
  5. 现象：Verifier 与 generator 同模型时存在 self-bias——模型倾向给自己生成的候选打更高分。影响：pairwise 选择退化到接近 score-based。修复：用不同 temperature / 不同 system prompt / 不同 few-shot 样本生成 verifier 与 generator，或引入专门 trained discriminator head。
  6. 现象：Mid-Harness 在「一次性动作」（删除文件、安装包）上收益大，在「连续动作」（连续 grep + 编辑 + 测试）上收益小——因为后面的动作正确性依赖前面动作的执行结果，verifier 在动作前看不到结果。影响：长 horizon 任务下 scaling 收益衰减。修复：把 verifier 从「pre-action」扩展到「post-action 复盘」，结合 trajectory-level evaluation。
  7. 现象：跨 harness（OpenHands、SWEBench、TerminalBench 等）abstract 仅给方向性「improves」，没有逐 harness 数字。影响：难以判断在自己用的 harness 上是否真有收益。修复：先在自己 harness 上做 30-50 任务小规模 pilot，量化 N=1/4/8 三档 Pass@1 与 wall-clock，再决定是否上 N=8。

与同方向工作的关系

  • Self-consistency / Best-of-N sampling（Wang et al. 2022）：把 majority vote / best-of-n 推到 action 级别，而不是 token 级别。
  • ReAct / Reflexion：在 trajectory 末端做反思，Mid-Harness 把反思时间点前移到每个 action。
  • Process Reward Model（PRM, Lightman et al. 2023）：在数学推理的 step 级别做 verifier，Mid-Harness 把同样的思路推到 terminal action。
  • Toolformer / Gorilla：让 LLM 调用工具的正确性靠训练数据 + API schema；Mid-Harness 不改 generator 也能靠 verifier 拦下错工具调用。
  • Sandbox / Snapshot（Docker commit、CRIU）：补 verifier 的「rollback」语义——本论文没有显式做，需要工程上配合。

适合谁读

  • Terminal/code agent 工程团队：把 Mid-Harness 当现成框架集成到自己的 harness 里，先跑 8 采样 + 同模型 pairwise verifier 看 Pass@1。
  • Test-time compute scaling 研究者：Mid-Harness 提出一个新位置（action-level），扩展了 scaling 的维度。
  • Agent safety / verification 研究者：把 verifier 的能力作为独立研究方向，distillation 路径有持续研究空间。
  • SWE-bench / TerminalBench 类基准建设者：跨 4 SE 域 + 视觉反馈是趋势，Mid-Harness 给了一个标定该趋势的方法学。
  • 不推荐：纯文本问答 / RAG / 单纯 LLM 推理研究者——Mid-Harness 不解决这类问题。

一句话定位

Mid-Harness 把「test-time compute」从「LLM 内部」推到「LLM ↔ 沙箱」接口，用 action-level sampling + verification 在不修改 generator 与 harness 的前提下，把 terminal agent 的可靠性与 token 成本比推上 Pareto 前沿。