Meta-Harness — 모델을 그대로 두고 harness를 탐색한다

0. 이 논문이 주장하는 것

• Online text classification: state-of-the-art context management 시스템(ACE)보다 정확도 7.7 points 높으면서 context token은 4× 적게 쓴다.

• Retrieval-augmented math reasoning: 발견된 harness 하나가 IMO급 200문제에서 held-out 모델 5종 평균 +4.7 points.

• Agentic coding: TerminalBench-2에서 수작업으로 다듬어진 최고 harness들을 넘어선다. Haiku 4.5 기준 1위, Opus 4.6 기준 2위.

1. harness란 무엇인가, 왜 지금인가

A harness is a stateful program that wraps a language model and determines what context the model sees at each step.

Based on earlier exploration, we think this workflow only became practical recently, following major improvements in coding-agent capabilities around early 2026.

최적화 목표

H* = arg max_H  E_{x~X, τ~p_M(H,x)} [ r(τ, x) ]

2. 기존 text optimizer가 이 문제에 맞지 않는 이유

• 현재 후보만 조건으로 삼는 것들

• 주로 scalar score에 의존하는 것들

• 피드백을 짧은 템플릿이나 LLM 요약으로 제한하는 것들

3. Meta-Harness의 구조

1. agent가 이전 후보 전부의 source code·execution trace·score가 담긴 filesystem을 읽고 새 harness를 제안한다.

2. 제안된 harness를 evaluation task에서 평가한다.

3. 모든 로그(제안 코드, reasoning trace, evaluation score)를 새 디렉터리에 저장하고 루프를 반복한다.

proposer는 raw LLM이 아니라 coding agent다

outer loop는 의도적으로 최소한만 둔다

Algorithm 1  Meta-Harness outer loop over harnesses
 1: Input: tasks X, LLM M, proposer P, iterations N
 2: Initialize: population H                      ▷ Initial set of valid harnesses
 3: Initialize: filesystem D ← ∅                  ▷ stores code, scores, traces
 4: for H ∈ H do
 5:     E_H ← Evaluate(H, M, X)
 6:     D ← D ∪ {(H, E_H)}
 7: for t = 1 … N do
 8:     Proposer P queries filesystem D            ▷ inspects prior harnesses and scores
 9:     Proposer P proposes k new harnesses {H_1, …, H_k}
10:     for H in {H_1, …, H_k} do
11:         if H passes interface validation then
12:             D ← D ∪ {(H, Evaluate(H, M, X))}
13: return Pareto frontier of harnesses stored in D

code space에서 탐색하면 좋은 점

실제 구현

• harness 하나 = single-file Python program. task별 prompting, retrieval, memory, orchestration 로직을 담는다.

• proposer P = Claude Code [4] with Opus-4.6.

• proposer는 minimal domain-specific skill의 안내를 받는다. 새 harness를 어디에 쓸지, 이전 harness와 execution trace를 어떻게 볼지, 어떤 파일을 고칠 수 있고 없는지를 적은 문서다.

• base model M은 도메인마다 다르고 항상 frozen.

• 전형적인 실행은 20 iteration에 harness 약 60개 평가.

4. 실험

4.1 Online Text Classification

• LawBench (Law) [16] — 사건 기술에서 형사 혐의를 예측. 215 classes.

• Symptom2Disease (S2D) [19] — 증상 기술에서 질병 예측. 22 classes.

• USPTO-50k [41] — 생성물 분자에서 전구체 반응물 예측. 180 classes.

• Best-of-N — seed에서 독립 샘플링, 탐색 구조 없음. 탐색이 의미가 있는지 자체를 재는 compute-matched control.

• OpenEvolve [43] — LLM mutation을 쓰는 evolutionary program search.

• TTT-Discover [55] — 이 방법의 text-optimization 요소만 사용, 즉 PUCT reuse rule로 proposal을 선택하는 부분.

• ACE (Agentic Context Engineering) [59] — reflective memory curation으로 시간에 걸쳐 context를 쌓는다.

• MCE (Meta Context Engineering) [52] — context 구성을 위한 natural-language skill 라이브러리를 유지·진화시킨다.

4.2 Retrieval-Augmented Math Reasoning

• NuminaMath-1.5는 competition-math 부분집합(AMC/AIME, olympiad references, number theory, inequalities 및 관련 소스)으로 제한하고 품질이 낮은 웹 스크랩 항목을 버렸다.

• OpenMathReasoning은 문제당 해답 하나로 중복 제거했고(독립 verifier의 pass rate가 가장 높은 해답을 남김), 중복 제거 전에 출처가 평가 벤치마크 계열(IMO, AIME, HMMT, SMT, USAMO, Putnam)과 겹치는 문제를 먼저 제거했다.

• 전체 코퍼스를 모든 평가 벤치마크와 harness 탐색에 쓴 search set 기준으로 오염 제거했다. exact prefix matching 후 fuzzy Jaccard similarity(threshold 0.8)를 적용해 둘 중 하나라도 걸리면 폐기.

• OpenMathReasoning과 DeepMath의 해답은 5,000자로 자른다. 런타임에는 선택된 harness가 해답이 비어 있지 않고 4,000자 미만인 항목으로 검색을 더 제한하고, prompt에 넣을 때 다시 3,000자로 자른다.

• geometry route용으로 NuminaMath에서 difficulty > 6인 문제만 모은 별도의 hard-reference index를 만든다.

• search set: Olympiad 난이도 문제 250개(OlympiadBench + Omni-MATH hard)

• 40 iteration, 후보 retrieval harness 109개 생성

• search population 초기화: zero-shot, few-shot, ACE

• search-set 성능으로 GPT-OSS-20B 기준 harness 하나를 선택

• 평가: 처음 보는 IMO급 문제 200개 (IMO-AnswerBench, IMO-ProofBench, ArXivMath [30; 6])

• 탐색에서 보지 않은 모델 4종에 같은 harness를 적용: GPT-5.4-nano, GPT-5.4-mini, Gemini-3.1-Flash-Lite, Gemini-3-Flash

• 선행 연구 [30]의 표준 프로토콜을 따라 문제당 3 샘플 평균 정확도 보고

4.3 Agentic Coding — TerminalBench-2

5. proposer는 실제로 무엇을 했나

5.1 파일 접근 통계

5.2 실패에서 인과를 읽어내는 궤적

Hypothesis: CMD_END marker fragments leak into LLM observations on long-running
tasks, causing the model to get confused and enter infinite no-tool-call loops.
Stripping these markers + adding a loop breaker will recover wasted steps.

긴 작업에서 CMD_END 마커 조각이 LLM observation으로 새어 들어가 모델이 혼란에 빠지고 tool call이 없는 무한 루프에 갇힌다. 마커를 제거하고 loop breaker를 넣으면 낭비된 step을 회수한다.

Double-confirmation completion mechanism causes verification spirals. Observed in
trajectories where the agent solves the task early but burns 15--40+ additional steps
re-verifying because each verification command resets pending completion, requiring
another task complete → checklist → verify cycle.

이중 확인 completion 메커니즘이 검증 나선을 만든다. agent가 과제를 일찍 풀고도 15~40 step 이상을 재검증에 태우는 trajectory가 관찰된다. 검증 명령이 실행될 때마다 pending completion이 초기화되면서 task complete → 체크리스트 → 검증 주기를 또 돌아야 하기 때문이다.

Prior attempts: evo marker fix (58.9%, -5.6pp), evo single confirm (57.8%, -6.7pp)
--- both regressed. Root cause of regressions: Prompt template changes (cleanup
directives) caused the agent to delete necessary state before task completion. The
structural bugfixes were confounded with harmful prompt changes. evo strip only
isolates the two proven structural fixes.

이전 시도 둘 다 후퇴했다. 후퇴의 근본 원인은 prompt 템플릿 변경(정리 지시)이며, 이 때문에 agent가 과제 완료 전에 필요한 상태를 지워버렸다. 구조적 버그 수정이 해로운 prompt 변경과 뒤섞여 있었다. evo strip only는 검증된 구조 수정 두 개만 분리한다.

Remove the two self. pending completion = False lines that reset the completion
flag when intermediate commands run. This fixes a state machine bug where: (1)
Agent calls task complete → sees QA checklist, pending completion = True (2) Agent
runs verification commands → pending completion = False (bug!) (3) Agent calls
task complete again → sees checklist AGAIN → infinite loop.

Empty-command turns waste full LLM round-trips when terminal output hasn't changed.
Smart-waiting (poll pane up to 3×5s) before the next LLM call saves 5--15 turns on
long-running tasks.

터미널 출력이 바뀌지 않았는데도 빈 명령 턴이 LLM 왕복을 통째로 낭비한다. 다음 LLM 호출 전에 smart-waiting(최대 3×5초 pane 폴링)을 두면 긴 작업에서 5~15턴을 아낀다.

All 6 prior iterations regressed from the 64.4% baseline because they modified the
completion flow, prompt template, or observation processing. evo env bootstrap takes
a different approach --- purely additive. It gathers an environment snapshot via a
single shell command before the first LLM call and appends it to the initial prompt.
No other methods are changed. This should eliminate 3--5 wasted exploration turns on
dependency-heavy tasks without risking regression on already-passing tasks.

앞선 6개 iteration이 모두 64.4% baseline에서 후퇴한 건 completion flow, prompt 템플릿, observation 처리를 건드렸기 때문이다. evo env bootstrap은 다르게 접근한다 — 순수 additive다. 첫 LLM 호출 전에 shell 명령 하나로 환경 스냅샷을 모아 초기 prompt에 덧붙인다. 다른 메서드는 바꾸지 않는다. 이러면 의존성이 많은 과제에서 3~5턴의 탐색 낭비를 없애면서 이미 통과하는 과제의 후퇴 위험은 지지 않는다.

Combining two orthogonal fixes --- env snapshot (saves early exploration turns) +
marker stripping with no-tool-call loop breaker --- will yield +1--3pp because they
address independent failure modes without touching prompts or confirmation flows
(which caused regressions in 5 of 7 prior iterations).

직교하는 두 수정을 결합한다. 서로 독립적인 실패 모드를 다루면서 prompt나 confirmation flow는 건드리지 않으므로 +1~3pp를 기대한다(앞선 7개 중 5개의 후퇴 원인이 그쪽이었다).

The evolution history showed ``don't cleanup service artifacts'' was worth +18pp. Iter
9 (evo no cleanup directive) targeted the same idea but crashed before evaluation.

evolution 이력을 보면 “서비스 산출물을 정리하지 말 것”이 +18pp 가치가 있었다. Iteration 9(evo no cleanup directive)가 같은 아이디어를 겨눴지만 평가 전에 죽었다.

5.3 이 궤적이 말해주는 것

6. 발견된 harness들의 실제 모습

6.1 Text Classification — 하나가 아니라 계열이 나온다

• Stage 1: Draft — 가장 유사한 labeled example 5개를 검색해 초기 예측을 받는다.

• Stage 2: Verification — 그 draft label을 조건으로 memory를 다시 검색한다. 같은 label의 confirmer 5개와 다른 label의 challenger 5개를 가져와, 초기 답을 유지할지 수정할지 모델에게 묻는다.

• Cold start — labeled example이 5개 미만이면 2단계 절차를 건너뛰고 표준 단일 호출 few-shot prompt를 쓴다.

• 왜 저렴한가 — 두 호출 모두 짧은 검색 context를 쓰므로 모델을 두 번 부르고도 전체 context 비용이 frontier의 낮은 쪽에 머문다.

• Label primer — 예제를 보여주기 전에 유효한 출력 label을 나열해 모델이 답 공간 전체를 먼저 보게 한다.

• Coverage block — 알려진 label마다 query와 가장 관련 깊은 labeled example을 검색해 클래스당 대표 예제를 하나씩 넣는다.

• Contrastive block — 매우 유사하지만 label이 다른 예제 쌍을 만들어, 현재 query 주변의 국소 결정 경계를 prompt에 노출한다.

• Retrieval rule — label을 무시한 최근접 이웃 대신 TF-IDF 유사도 + query-anchored 파트너 선택을 쓴다.

6.2 Math Retrieval — 네 갈래 라우터

6.3 TerminalBench-2 — environment bootstrap

Hypothesis: ``Injecting an environment snapshot (OS, installed languages, package
managers, /app contents) before the first LLM turn will reduce wasted exploration
episodes by 3--5 turns on dependency-heavy tasks''

Changes: ``Added _gather_env_snapshot() that runs a single compound shell command to
collect working directory, /app listing, available languages (python, gcc, node, java,
rustc, go), package managers (pip, apt) [...] and injects as [Environment Snapshot]
block''

7. 새 도메인에 Meta-Harness를 적용할 때 (Appendix D)

8. 이웃 연구들과의 위치 (Section 2 + Appendix E)

9. 논의와 한계

• 발견된 harness가 OOD 분류 데이터셋(Table 5)과 미지의 base model(Table 6)로 일반화한다.

• 탐색 실행 하나가 몇 시간의 wall-clock으로 끝나면서, 읽을 수 있고 옮길 수 있는 전략을 내놓는다. 앞으로 나올 더 강한 모델을 포함해 여러 모델에 재사용할 수 있다.

• code space의 과적합은 검사 가능하다. 취약한 if-chain이나 하드코딩된 클래스 매핑은 코드를 읽으면 보인다. weight space의 과적합은 그렇지 않다.

남는 한계

• 세 도메인에서 검증했지만, 실험이 보여준 건 harness 탐색이 특히 강한 coding-agent proposer 하나(Claude Code)로 작동한다는 사실이다. proposer agent에 따라 효과가 어떻게 달라지는지는 남은 과제다.

• TerminalBench-2 실험은 탐색과 최종 평가에 같은 89개 과제를 쓴다. 논문이 discovery problem으로 명시하고 근거를 대며 과적합 감사를 붙였지만, 다른 두 도메인처럼 깨끗한 held-out 설계는 아니다.

• ForgeCode(81.8%)의 리더보드 점수는 공개 코드만으로 재현되지 않았다. Opus 4.6에서 Meta-Harness가 2위라는 서술은 이 재현 실패를 전제로 읽어야 한다.

• Table 2의 Ctx는 token 단위(천), Table 9의 Ctx는 문자 단위(천)다. 두 표의 숫자를 나란히 비교하면 안 된다.

• Appendix A.2의 baseline은 64.4%인데 Table 7의 Terminus-KIRA는 74.7%다. Appendix는 10 iteration짜리 별도 탐색 실행 기록이고, 그 실행의 기준선 수치다.

• Appendix C.3에는 편집 흔적이 남아 있다. “When included, the table in this section should report each benchmark separately for both Base and Meta-Harness across the five held-out models.” — 벤치마크별 분해 표는 v1에 실리지 않았다.

10. 정리하며 남는 것

부록: 용어 대조