Skip to content

TTHE: Test-Time Harness Evolution

🕒 Published (v1): 2026-07-09 05:53 UTC · Source: Arxiv · link

Why this paper was selected

Core topic: defines harness as executable scaffold; proposes test-time harness evolution

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

TTHE (Test-Time Harness Evolution) adapts an LLM agent's executable harness—the control program governing tool use, context construction, and error recovery—during evaluation itself, using only unlabeled execution traces and no gold labels. A population of candidate harnesses is iteratively refined by agentic proposers and committed by a judge via execution-derived proxy signals. Across five execution-grounded benchmarks, TTHE improves fixed ReAct baselines substantially without touching model weights.

Problem

Deployed LLM agent harnesses are frozen after pre-deployment search on labeled development data. At test time, the harness remains static even as the evaluation stream exposes rich execution evidence—tool call patterns, runtime errors, intermediate artifacts—that a human engineer would use to revise the scaffold. No existing method adapts the persistent executable harness at test time without gold labels, weight updates, or a separate repair model.

Method

TTHE treats the harness \(H \in \mathcal{H}\) (a Python class) as the adaptation state. For each unlabeled test batch \(X_t\), it maintains \(G\) parallel candidate harness branches evolved over \(R\) rounds via three operators:

  • OBSERVE: executes every candidate harness on \(X_t\), collecting full traces (prompts, completions, tool calls, stdout/stderr, artifacts, errors) and three proxy signals: execution health \(s \in \{0,1\}\), round-trip consistency \(b \in [0,1]\) (output back-translated and scored against input without gold), and public-test pass rate \(p \in [0,1]\).
  • PROPOSE: \(G\) coding agents run in parallel; each proposes a code edit to its own branch while reading other branches' traces; three branches are steered toward conservative-repair, exploratory, and adversarial edit objectives for diversity.
  • JUDGE: an agentic selector inspects code, traces, and proxy signals (may re-execute candidates) and commits one harness \(H_{t+1}\) (Eq. 2) that persists to the next batch.

Gold labels \(y\) are strictly outside the loop, used only for post-selection measurement. The solver, proposers, and judge all invoke the same frozen backbone (deepseek-v4-flash in main runs) through different harnesses; Claude Code serves as the coding-agent scaffold for proposers and judge. Baseline is a standard ReAct harness \(H_0\).

Key Contributions

  • Formulates test-time harness evolution as population-based generate-and-judge over executable programs, with no weight updates, gold labels, or separate adaptation model.
  • Demonstrates improvements across five execution-grounded domains (text-to-SQL, competitive programming, software engineering, data-science coding, agentic tool-use).
  • Exposes harness code, execution traces, and per-batch decisions for behavioral inspection.
  • Provides diagnostics—search-budget, batch-size, and cross-model ablations plus per-batch trace audits—characterizing failure modes: non-monotonic gains with budget, selection regret (better candidate generated but not committed), and proxy gaming.

Results

  • BIRD (hard slice, text-to-SQL): 12.0% → 50.0% vs. fixed ReAct baseline (baseline constructed from systematic failures, so large absolute gap reflects recovery on those queries).
  • LiveCodeBench (hard slice, competitive programming): 30.0% → 38.3%.
  • SWE-bench Verified (hard slice, 40 multi-file/large-diff instances): 20.0% → 35.0% (harness evolved from mini-swe-agent baseline).
  • DS-1000 (hard slice, data-science code): 38.0% → 44.0%.
  • claw-eval (agentic tool-use): 48.9 → 69.8 mean graded score (Ă—100 scale).
  • Batch-size ablation on BIRD (G=3, R=3): committed-harness accuracy is non-monotonic in \(B\), peaking at \(B=10\); fixed baseline is 12%.
  • Additional SQL runs with MiMo V2.5 and Kimi K2.5 corroborate cross-model generalization.

Limitations

  • Proxy signals are imperfect oracles: a harness can pass public tests while failing hidden ones, or optimize round-trip consistency while answering the wrong question—proxy gaming is a central failure mode.
  • Performance is non-monotonic in search budget; more candidates do not monotonically improve results.
  • Selection regret: the judge can commit a plausible but suboptimal program under imperfect proxy evidence even when a better candidate was generated.
  • Transductive scoring (harness selected and measured on the same batch) is distinct from prequential generalization; real-world deployment would require the committed harness to generalize to the next batch.
  • Hard slices are constructed from baseline failures and should not be used for cross-model absolute comparison.
  • Wall-clock and compute costs scale with \(G \times R\) executions per batch; fixed resource budgets bound but do not eliminate overfit risk.

Relevance to Harnesses / Meta-Harnesses

TTHE directly addresses the central challenge in meta-harness design: how to adapt the control layer (tool routing, context construction, error recovery) without retraining the underlying model or requiring labeled outcomes. Its use of execution-derived proxy signals — traces alone, no gold labels — makes it deployable against any black-box LLM, which is exactly the constraint practitioners face when building harnesses over hosted models. The population-based proposer/judge loop is essentially an automated harness search algorithm, making it a concrete blueprint for self-improving scaffolds rather than a one-shot design. For someone building or evaluating agent harnesses, TTHE is a direct methodological contribution: it shows that harness quality is itself optimizable at test time, shifting harness design from a static engineering decision to a dynamic, evidence-driven process.