Harness2: Recursive Agent Harnessing for an Open World
Harness²: 정답 검증기 없이 실행 harness를 재귀적으로 개선하기
모델 가중치는 고정한 채 현재 과제의 실행 구성을 고치고, 그 경험을 다음 과제의 개선에 재사용하는 Harness²를 설명합니다. 행동 대조와 사후 평가, 두 수준의 반복 개선, 성능과 추가 비용을 구분합니다.
Paper: Ruiyao Xu; Yanfei Chen; Zhongying CuiZhu; Bhavana Dalvi Mishra; Yifei Ming; Han Yu; Rujun Han; Chen-Yu Lee; Tomas Pfister (2026). "Harness2: Recursive Agent Harnessing for an Open World". arXiv preprint, arXiv:2610.14224v1. HTML · PDF.
이 글은 2026년 10월 9일 공개된 arXiv v1을 기준으로 논문의 설정, 알고리즘, 실험과 저자가 보고한 한계를 정리한다. Harness는 모델의 가중치가 아니라 모델이 도구를 쓰고 결과물을 만드는 실행 주변부를 뜻한다. Harness2는 이 주변부를 한 task에 맞게 고치는 task-level recursion과, 그 고침의 경험을 다음 task의 개선 절차에 공급하는 harnessing-level recursion을 분리해 연결한다. 두 층 모두 모델 가중치를 업데이트하지 않는다.
1. 문제 설정과 기여
LLM agent의 행동은 같은 모델이라도 system prompt, memory, skill, tool guidance, subagent, script, middleware를 어떻게 연결하는지에 따라 달라진다. 고정된 harness를 미리 골라 배포하면 처음 보지 못한 open-world task의 요구에 대응하기 어렵고, task마다 실행 harness를 직접 고치면 한 task에만 맞춘 변경이 다음 task의 harnessing에 그대로 일반화되지 않을 수 있다. 논문은 정답 라벨이나 신뢰할 수 있는 verifier가 온라인 편집 세션에 주어지지 않는 task stream에서 두 문제를 함께 다룬다.
논문이 제시하는 기여는 다음 세 가지다.
- 현재 task의 실행 harness를 고치면서 그 과정에서 재사용 가능한 경험을 보존하는 recursive agent harnessing이다.
- ground-truth feedback 없이 reference와 후보의 실행 결과를 대조하는 Propose–Probe–Compose 단계와, 이를 확장하는 parallel·sequential task-level recursion이다.
- WorkBuddy-Bench, JobBench, Harvey’s Legal Agent Benchmark(LAB)의 세 전문 benchmark와 네 executor–harness 조합에서의 실험이다. 논문은 한 단계가 base harness보다 WorkBuddy-Bench에서 최대 11.5점, JobBench에서 4.5점, LAB Partial pass rate에서 11.8퍼센트포인트 높았고, parallel recursion을 늘리면 추가 상승이 나타났다고 보고한다.
2. 두 harness와 두 종류의 신호
2.1 모델과 실행 harness
논문은 가중치가 고정된 모델을 \mathcal{M}, 편집 가능한 harness를 다음과 같이 둔다.
\mathcal{H}=(c^1,\ldots,c^K),\qquad i\in\{1,\ldots,K\}.c^i는 harness의 파일 단위 component이고, \mathcal{M}과 \mathcal{H}가 agent를 구성한다.
\text{Agent}=\text{Model}+\text{Harness}.AHE의 file-level decomposition을 확장한 실행 harness는 K=8 component를 갖는다. system prompt, guardrails, memory, skills, tool guidance, scripts, subagents, middleware plugin이다. q_1,\ldots,q_N인 open-world task stream의 각 task는 공통 실행 harness \mathcal{H}_0에서 시작하며, 현재 task는 정해진 예산 안에서 여러 번 실행할 수 있다.
2.2 실행 harness와 improvement harness
두 재귀는 서로 다른 객체를 갱신한다.
| 객체 | 현재 task에서 하는 일 | task가 끝난 뒤의 역할 |
|---|---|---|
실행 harness \mathcal{H} |
모델이 trajectory와 deliverable을 만드는 runtime 파일 tree다. | 채택된 tree가 library entry로 보존될 수 있지만 다음 task의 초기 tree로 자동 장착되지는 않는다. |
improvement harness \mathcal{R}_t |
editor, composer, reflector가 제안·probe·조합·기록하는 절차를 안내한다. | 채택 harness와 증거가 있는 경험을 library에 넣어 \mathcal{R}_{t+1}을 만든다. |
따라서 task-level recursion은 현재 task의 \mathcal{H}를 바꾸고, harnessing-level recursion은 task가 끝난 뒤 \mathcal{R}_t 안의 개선 library를 바꾼다. 다음 task는 다시 \mathcal{H}_0에서 시작하지만, proposal과 composition이 library의 component와 경험을 선택적으로 읽을 수 있다.
2.3 행동 대비와 correctness score
실행 기록을 e=(\tau,y)로 쓰면 \tau는 trajectory이고 y는 deliverable이다. Harness2의 온라인 편집 세션은 benchmark의 expected value, rubric, grader verdict, score를 보지 않는다. reference와 후보를 같은 model·environment에서 실행해 얻는 trajectory·deliverable의 차이는 behavioral contrast다. 이 신호는 어떤 변경 뒤에 행동이 달라졌는지, 목표로 삼은 deficiency가 줄었는지, regression이 보이는지를 알려 주지만 deliverable의 외부 correctness를 증명하지 않는다.
benchmark score는 이와 다른 사후 평가다. WorkBuddy-Bench의 composite verifier, JobBench의 weighted rubric, LAB의 criterion judge가 task가 끝난 뒤 점수를 계산한다. 이 점수는 실험 비교의 지표이며 온라인 Probe가 받은 correctness signal이 아니다. k>1의 selector도 anonymized deliverable을 task request와 source material에 비교해 이미 실행된 output을 하나 채택할 뿐이며, 그 output을 만든 harness를 보고 새 내용을 합성하지 않는다. 논문은 \mathcal{H}_t^\star의 별표가 verified optimum이 아니라 adoption을 뜻한다고 설명한다.
3. Propose–Probe–Compose
3.1 한 contrastive improvement step
현재 task를 q_t, 실행 harness를 \mathcal{H}, task-local history를 \mathcal{E}, improvement harness를 \mathcal{R}_t라고 하면 논문의 핵심 단계는 다음과 같다.
(\mathcal{H}^{\prime},e^{\prime},\xi)=\Phi(q_t,\mathcal{H},\mathcal{E};\mathcal{R}_t). \tag{1}이 단계는 successor harness \mathcal{H}^{\prime}, successor execution e^{\prime}, 그리고 reference execution·candidate·probe·composition decision·successor execution을 담은 step record \xi를 반환한다. 같은 model과 environment는 단계 중 고정되고, improvement harness \mathcal{R}_t도 task-level recursion 중에는 고정된다.
Propose. 먼저 현재 harness에서 reference execution을 샘플한다.
e^0\sim\mathcal{A}(q_t;\mathcal{M},\mathcal{H}).reference는 harness가 실제로 어떻게 행동했는지는 보여 주지만 결과물이 맞는지는 보여 주지 않는다. 그 뒤 두 편집자가 후보를 만든다. invariant 후보는 planning, tool use, context management, delegation처럼 여러 domain에서 반복될 수 있는 agentic deficiency를 다룬다. domain-specific 후보는 현재 업무의 지식, 절차, 제약을 다룬다. 후보는 현재 harness의 component 파일을 편집해 만든 실행 가능한 tree이며, library의 component를 재사용하거나 변형할 수 있지만 task-specific fact는 현재 task의 evidence로 확인해야 한다.
Probe. 각 후보를 같은 task와 matched model·environment에서 실행한다. reference와 후보의 trajectory 및 deliverable을 대조해 목표 deficiency의 완화, 관련 행동의 보존, regression을 관찰한다. 실행의 stochasticity와 후보가 공유하는 model bias 때문에 이 대조는 correctness 검증이 아니다.
Compose. composer는 reference, 후보와 현재 tree의 diff, 후보 실행, task-local evidence를 읽고 변경을 선택적으로 merge·수정·채택·보류한다. 그 결과인 successor harness를 다시 실행하고 decision과 근거를 \xi에 기록한다. 따라서 단순히 여러 출력 중 하나를 고르는 것과 달리 실행 artifact 자체가 다음 단계의 harness가 된다.
그림 1. Xu et al. (2026), Figure 3, PDF p. 5. “The Harness2 pipeline. Task-level recursion proposes invariant and domain-specific harness edits, probes their effects, and composes a successor execution harness. After each task, harnessing-level recursion updates the improvement harness with reusable harnesses and lessons from the refinement process.”
그림 1의 앞부분은 한 task 안에서 \mathcal{H}를 바꾸는 task-level recursion이고, task가 끝난 뒤의 Reflect–Update는 \mathcal{R}_t를 바꾸는 harnessing-level recursion이다. 논문은 두 시간을 하나의 업데이트로 취급하지 않는다.
3.2 parallel과 sequential task-level recursion
양의 정수 k가 exploration budget을 정한다. parallel에서는 k개의 reference, k개의 invariant 후보와 k개의 domain 후보, k개의 composition session을 사용한다. \mathcal{B}를 reference 실행 집합, \mathcal{P}를 후보 harness와 실행 기록의 pool이라고 하면 각 successor는 다음과 같다.
\mathcal{H}^{\prime}_{j}=\operatorname{Compose}_{j}(q_t,\mathcal{H},\mathcal{B},\mathcal{P};\mathcal{R}_t),\qquad j=1,\ldots,k. \tag{2}각 \mathcal{H}^{\prime}_{j}를 실행한 뒤 k>1이면 selector가 anonymized deliverable을 비교해 하나를 반환한다. 구현의 parallel recursion은 한 population update이며 k=5가 다섯 세대의 깊이를 뜻하지 않는다.
sequential recursion은 이전 successor와 누적 history를 다음 단계로 넘긴다. \mathcal{H}^{(0)}=\mathcal{H}_0에서 시작하면 다음 식으로 k단계를 연결한다.
(\mathcal{H}^{(r)},e^{(r)},\xi^{(r)})=\Phi(q_t,\mathcal{H}^{(r-1)},\mathcal{E}^{(r-1)};\mathcal{R}_t),\qquad r=1,\ldots,k. \tag{3}초기 history에는 k개의 base execution이 있고 매 단계의 \xi^{(r)}가 누적된다. parallel은 같은 pool에서 여러 composition을 독립적으로 만들고, sequential은 앞 단계의 harness와 증거를 다음 editor가 읽는다는 점이 다르다.
4. 실행 component와 구현 조건
4.1 편집 가능한 여덟 component
논문 Appendix D.3의 Table 5는 다음 파일과 runtime activation을 정의한다.
| ID | component와 파일 | activation | runtime에서의 정의 |
|---|---|---|---|
| C1 | System prompt, systemprompt.md |
매 call | persona와 top-level procedure다. |
| C2 | Guardrails, guardrails.md |
매 call | task·tool과 무관하게 지킬 hard constraint다. |
| C3 | Memory, LongTermMEMORY.md |
매 call | domain에 걸쳐 보존되는 사실이다. |
| C4 | Tool guidance, tool_descriptions/tool_guidance.md |
매 call | 기존 tool을 언제 어떻게 쓰는지 안내한다. |
| C5 | Subagents, sub_agents/<n>/AGENT.md |
task tool 호출 |
별도 context에서 실행하는 worker이며 inference context를 하나 추가한다. |
| C6 | Skills, skills/<n>/SKILL.md와 skills/<n>/scripts/* |
skill 호출 | 필요할 때만 불러오는 전문 절차와 helper다. |
| C7 | Scripts, scripts/<name>.py |
bash 실행 |
token 단위 추론 대신 결정적 추출·변환·검사를 수행한다. |
| C8 | Middleware plugin, plugin/<name>.ts |
tool loop 내부 | model 바깥에서 tool call과 turn 경계를 제어하는 hook이다. |
OpenCode에서는 이 component tree를 사용하고 Codex에서는 항상 켜지는 텍스트가 AGENTS.md에 놓인다. stock harness에는 benchmark reference instruction 외의 always-on file이 비어 있다. Skills는 호출될 때만 context 비용이 들고, subagent는 독립 context를 만들며, plugin은 모델의 prose 지시를 거치지 않고 tool loop 안에서 동작한다.
4.2 editor session, validator, library
기본 editor와 selector는 OpenCode 안에서 높은 reasoning effort로 실행되는 Claude Opus 4.8 agentic session이다. 각 session은 task, current harness, trajectory, deliverable, library가 들어 있는 workspace를 파일로 읽는다. grader verdict, rubric, score가 들어 있는 workspace를 넘기지 않는 guard가 있다. invariant editor는 workflow·tool use·completion을, domain editor는 현재 업무의 지식·절차·제약을 담당한다.
validator는 trigger 문장이 없는 skill, compile되지 않는 script, skill이 호출하지만 함께 배포되지 않은 helper 같은 invalid tree를 검사한다. validator가 실패하면 한 번 재시도하고, 다시 실패하면 stage가 시작할 때의 tree를 상속하며 fallback을 기록한다. 이 검사는 tree 형식과 의존성을 다루는 실행 방어선이다.
benchmark domain마다 library directory가 따로 있다. 각 entry는 채택된 전체 harness tree와 EXPERIENCE.md로 구성되며, 후자는 어떤 상황에서 어떤 weakness를 다뤘는지와 근거를 기록한다. index가 관련 entry를 찾아 주지만, 이전 execution harness를 다음 task의 초기 tree로 자동 상속하지는 않는다. task가 끝나면 reflector가 전체 improvement record \mathcal{D}_t를 읽고 실행 contrast로 지지되는 lesson만 보존한다. update는 다음과 같다.
\mathcal{R}_{t+1}=\operatorname{Update}(\mathcal{R}_t,\mathcal{H}^{\star}_t,\mathcal{D}_t). \tag{4}5. 실험 설계
5.1 benchmark, 분모, 채점
| benchmark | task 구성과 실험 분모 | 점수와 채점기 |
|---|---|---|
| WorkBuddy-Bench | Code 80개, Web 70개, Office 50개다. category로 반씩 나누고 test 절반인 40/35/25개를 사용한다. | deterministic hidden check와 필요한 LLM/VLM judge를 합친 composite verifier다. 필요한 judge에는 Gemini 3.5 Flash를 사용하며, task score는 통과한 check의 비율이다. |
| JobBench | 65개 professional task 중 frozen 31/34 split의 test 34개를 사용한다. | Claude Opus 4.8이 weighted rubric으로 채점하며, task score는 weighted total을 maximum으로 나눈 benchmark 자체 점수다. rubric은 executor·editor·selector에 공개하지 않는다. |
| LAB | Harvey’s Legal Agent Benchmark의 1,251개 legal task, 24 practice area, analyse·draft·review·research 네 work type 중 100개 held-out test를 사용한다. 24개 dev task는 Meta-Harness의 search set에만 쓰인다. | executable check 없이 Claude Sonnet 4.6이 task criterion을 채점한다. 논문은 criterion별 pass rate인 Partial을 보고한다. |
각 방법의 점수는 shuffled task order를 사용한 세 개의 독립 stream의 평균과 표준편차다. #Steps는 executor session에서 task 하나를 처리하는 model turn 수다. WorkBuddy와 JobBench의 train 절반, LAB의 dev 24개는 Meta-Harness의 offline search에만 사용하고, Harness2와 다른 baseline은 test stream을 empty library 또는 empty memory에서 처리한다.
5.2 executor, harness, editor와 baseline
frozen executor는 Gemini 3.5 Flash 또는 GLM-5이고 초기 harness는 OpenCode 또는 Codex다. 같은 improvement step을 네 executor–harness configuration과 세 benchmark에 적용한다. 표의 Harness2는 한 contrastive step인 k=1이고, + Recursion은 parallel task-level recursion k=5가 k=1 결과에 더한 평균 변화다. library는 benchmark stream마다 비어 있는 상태로 시작하고 task 뒤에 갱신된다.
비교 방법은 다음과 같다.
- Base harness는 초기 harness를 그대로 실행한다.
- ReasoningBank는 harness를 바꾸지 않고 유사 task의 distilled strategy를 memory로 retrieval한다.
- Meta-Harness는 별도 train/dev task의 score로 harness를 offline search한 뒤 test stream에 고정한다.
- Harness Scaling은 각 task에서 verifier-blind revision을 반복하지만 task 사이에 library와 state를 넘기지 않는다.
- **Best-of-
k**는 base harness를k번 실행하고 selector로 deliverable 하나를 고른다. 후보 tree를 만들거나 composition하지 않는다.
5.3 주 결과
다음 표는 Tables 1–2의 base와 Harness2 (k=1) 평균, 그리고 parallel k=5의 평균 변화다. 괄호는 세 run의 SD다. WorkBuddy Avg는 Code·Web·Office 세 domain의 unweighted macro-average다.
| executor / initial harness | WorkBuddy base Avg | Harness2 Avg (SD) | +Recursion Avg | JobBench base | Harness2 (SD) | +Recursion | LAB base Partial | Harness2 (SD) | +Recursion Partial |
|---|---|---|---|---|---|---|---|---|---|
| Gemini 3.5 Flash / OpenCode | 72.4 | 77.5 (2.5) | +3.3 | 31.5 | 36.0 (2.3) | +3.0 | 79.9 | 81.9 (0.6) | +2.6 |
| Gemini 3.5 Flash / Codex | 74.5 | 77.5 (2.0) | +2.9 | 33.9 | 35.3 (3.5) | +4.2 | 71.6 | 75.6 (4.5) | +2.9 |
| GLM-5 / OpenCode | 64.2 | 75.7 (2.2) | +3.9 | 20.6 | 24.2 (0.9) | +4.2 | 59.6 | 71.4 (2.9) | +6.7 |
| GLM-5 / Codex | 64.4 | 75.3 (1.3) | +3.0 | 23.6 | 24.8 (0.2) | +3.1 | 58.1 | 65.9 (2.7) | +4.8 |
WorkBuddy의 domain별 평균은 다음과 같다. +Recursion은 같은 row의 Harness2에서 평행 recursion을 k=5로 늘렸을 때의 변화다.
| executor / harness | base Code / Web / Office | Harness2 Code / Web / Office | +Recursion Code / Web / Office |
|---|---|---|---|
| Gemini 3.5 Flash / OpenCode | 73.4 / 69.9 / 74.0 | 76.5 / 76.4 / 79.5 | +4.3 / +1.9 / +3.9 |
| Gemini 3.5 Flash / Codex | 74.0 / 72.5 / 77.0 | 79.4 / 74.7 / 78.5 | +1.6 / +2.6 / +4.3 |
| GLM-5 / OpenCode | 58.4 / 59.2 / 75.1 | 77.1 / 69.1 / 80.8 | +4.8 / +5.3 / +1.7 |
| GLM-5 / Codex | 56.8 / 59.6 / 76.9 | 74.9 / 70.0 / 81.1 | +2.3 / +3.3 / +3.2 |
#Steps는 score와 같은 방향으로 항상 움직이지 않는다. 다음은 base의 평균 step, Harness2 (k=1)의 평균(SD), 그리고 k=5 변화다.
| executor / harness | WorkBuddy base → H2, +Rec | JobBench base → H2, +Rec | LAB base → H2, +Rec |
|---|---|---|---|
| Gemini 3.5 Flash / OpenCode | 25.4 → 21.9 (0.4), −0.8 | 63.6 → 69.3 (3.5), −3.9 | 29.0 → 33.0 (1.1), −1.7 |
| Gemini 3.5 Flash / Codex | 28.3 → 23.9 (0.6), −0.2 | 53.6 → 54.5 (1.9), +1.2 | 49.8 → 44.2 (1.3), +4.8 |
| GLM-5 / OpenCode | 13.5 → 13.7 (0.2), −2.7 | 20.0 → 23.6 (1.4), −0.5 | 13.6 → 15.8 (2.1), +3.0 |
| GLM-5 / Codex | 23.3 → 21.3 (1.3), −1.3 | 22.3 → 25.3 (1.4), +1.7 | 16.5 → 22.3 (2.5), +4.4 |
원문은 한 단계가 네 configuration 모두에서 세 benchmark의 base보다 높았다고 보고한다. WorkBuddy에서 가장 큰 one-step 차이는 GLM-5/OpenCode의 64.2에서 75.7로의 변화이고, JobBench의 가장 큰 차이는 Gemini/OpenCode의 31.5에서 36.0으로의 변화이며, LAB의 가장 큰 차이는 GLM-5/OpenCode의 59.6에서 71.4로의 변화다. Parallel recursion의 추가 변화 범위는 WorkBuddy 2.9–3.9점, JobBench 3.0–4.2점, LAB Partial 2.6–6.7퍼센트포인트다.
6. recursion budget, library 재사용과 component 분석
6.1 budget scaling과 compute
Figure 5는 WB-code와 WB-office에서 parallel·sequential task-level recursion의 k를 1에서 5로 바꾼 결과를 비교한다. 두 recursion은 이 두 domain에서 k가 증가할수록 상승하며, parallel은 Code 76.5에서 80.8, Office 79.5에서 83.4로 올라간다.
그림 2. Xu et al. (2026), Figure 5, PDF p. 9. “Effect of task-level recursion. Performance comparison on WB-code and WB-office as the scaling budget k increases.”
Figure 6의 compute는 최종 deliverable 제출 전 execution과 improvement에 사용한 모든 token을 task당 합산한다. Gemini 3.5 Flash/OpenCode에서 k=1에서 k=5로 갈 때 base 대비 gain은 JobBench 4.5점에서 7.5점으로, WorkBuddy-Bench 5.1점에서 8.4점으로 증가한다. 그래프의 가로축은 task당 총 M-token이고 parallel session의 실제 latency는 동시 실행 자원과 rollout duration에 따라 달라진다. 따라서 #Steps와 total token은 같은 단위가 아니며, parallel은 추가 계산을 없애지 않는다.
6.2 library와 harnessing-level recursion
각 task 뒤 reflector는 \mathcal{D}_t의 reference, 후보·probe, composition decision, selected result를 읽고, 어떤 변경이 어떤 deficiency를 어떤 조건에서 다뤘는지 기록한다. 실행 contrast로 지지되지 않은 lesson은 library에 새로 넣지 않는다. 다음 task는 \mathcal{H}_0에서 시작하고 library의 component와 EXPERIENCE.md를 proposal·probe·compose에 선택적으로 사용한다.
Figure 7 왼쪽에서 reference execution·candidate probe·improvement library 없이 base harness를 직접 고치면 WorkBuddy Code가 73.4에서 63.2로, Web이 69.9에서 65.0으로 내려간다. Office는 74.0에서 77.1로 올라간다. k=1에서 축적한 library는 base 수준을 회복하고, k=5에서 축적한 library는 이후 one-step refinement에서 Code·Web·Office에 각각 +0.9, +4.4, +5.1점을 지원한다. 이는 더 큰 task-level exploration이 추가 probing 없이도 다음 harnessing에 사용할 execution evidence와 composition decision을 더 남긴다는 결과다.
오른쪽의 JobBench→WorkBuddy-Bench transfer에서는 JobBench에서 얻은 library가 WorkBuddy one-step refinement에 들어가 Code·Web·Office를 각각 +0.6, +0.5, +2.9점 높인다. 이는 이전 execution harness를 장착하는 실험이 아니라 improvement library의 선택적 재사용이다.
그림 3. Xu et al. (2026), Figure 7, PDF p. 11. “Harnessing-level recursion. Left: direct refinement with the improvement harness. Right: JobBench-to-WorkBuddy-Bench library transfer for one-step refinement.”
stream 완료 뒤 각 task의 자기 entry를 제거하고 다시 실행한 leave-one-out 분석에서는 WorkBuddy-Bench가 77.5에서 79.4로, JobBench가 36.0에서 37.7로 변한다. 이 분석은 뒤 task의 entry와 반복 실행을 사용할 수 있는 retrospective 분석으로 제시된다.
6.3 ablation과 component
Table 3은 Gemini 3.5 Flash/OpenCode, k=1에서 library·scoping·composition을 하나씩 제거한 결과다. WorkBuddy는 세 domain의 평균, JobBench는 benchmark score다.
| method | WorkBuddy | JobBench |
|---|---|---|
| Harness2 | 77.5 | 36.0 |
| w/o library | 74.4 | 34.2 |
| w/o scoping | 74.6 | 32.3 |
| w/o composition | 75.9 | 34.1 |
w/o library는 앞 task의 entry를 읽거나 새 entry를 쓰지 않는다. w/o scoping은 invariant/domain 역할을 나누지 않은 두 generic editor를 사용하지만 후보 수와 probe budget은 같다. w/o composition은 두 후보를 probe한 뒤 merge하지 않고 evidence가 favour하는 하나를 반환한다.
Table 6은 이미 개선된 Gemini 3.5 Flash/OpenCode harness에서 component group을 제거하고 improvement를 다시 하지 않은 결과다.
| configuration | Code | Web | Office | Avg |
|---|---|---|---|---|
| Base harness | 73.4 | 69.9 | 74.0 | 72.4 |
Harness2 full (k=5 parallel) |
80.8 | 78.3 | 83.4 | 80.8 |
| w/o prompt group | 78.8 | 76.0 | 83.1 | 79.3 |
| w/o skills | 77.2 | 71.4 | 77.9 | 75.5 |
| w/o scripts | 79.3 | 76.0 | 76.0 | 77.1 |
논문은 full harness가 모든 domain에서 모든 ablation보다 높았고, skills 제거는 Code와 Web에서 각각 3.6점과 6.9점, scripts 제거는 Office에서 7.4점의 손실을 보였다고 기술한다. 이 표는 개선된 artifact에서 component group의 기여를 비교한 것이며, 제거 뒤 재최적화는 하지 않았다.
6.4 모델 전이와 도구 사용
같은 model을 executor와 editor로 사용한 OpenCode k=2 실험에서 GLM-5부터 Claude Opus 5까지 다섯 model이 세 benchmark 모두에서 향상된다. Opus 5의 WorkBuddy·JobBench·LAB gain은 각각 3.3점, 5.5점, 3.0점이고 GLM-5의 LAB gain은 13.7점이다.
Gemini 3.5 Flash/OpenCode에서 만든 harness를 수정 없이 다른 executor에 적용한 Figure 12에서는 GLM-5의 Code가 58.5에서 75.8로, Gemini 3.7 Flash의 Code와 Office가 각각 +0.3점과 +6.4점으로, Claude Opus 4.8의 Code와 Office가 각각 +2.6점과 +1.1점으로 변한다. 전이는 executor와 domain에 따라 크기가 다르다.
Table 7은 Gemini 3.5 Flash/OpenCode k=1에서 평균 tool call 수와 tool-error rate를 비교한다.
| benchmark | base calls | Harness2 calls | base error | Harness2 error |
|---|---|---|---|---|
| WorkBuddy-Bench | 20.0 | 17.8 (−11.0%) | 0.8% | 0.5% (−37.5%) |
| JobBench | 27.4 | 32.8 (+19.7%) | 14.4% | 9.1% (−36.8%) |
| LAB | 20.8 | 25.2 (+21.2%) | 2.0% | 1.6% (−20.0%) |
논문은 error rate가 세 benchmark에서 모두 낮아졌지만 call 수는 WorkBuddy에서만 줄고 JobBench와 LAB에서는 늘었다고 설명한다.
7. 저자가 보고한 사례와 한계
7.1 qualitative case
JobBench task에서 Gemini 3.5 Flash/OpenCode의 base run score는 43.1이었다. trajectory에는 source file 사이의 data reconciliation이 빠지고, 작성한 output을 다시 열어 확인하지 않는 두 절차적 문제가 나타났다. invariant intervention은 모든 입력을 inventory하고 figure를 정확한 source로 추적하며 verification script로 결과 파일을 다시 열도록 했다. domain intervention은 schedule·venue·labor·budget 파일의 reconciliation mechanics를 담은 skill과 tool guidance를 추가했다. 개선 harness를 다시 실행한 score는 77.8이었다. 논문 Figure 9는 이 사례에서 C2 guardrails, C4 tool guidance, C6 skills, C7 scripts가 어떻게 배치됐는지 보여 준다.
7.2 Figure 14의 아홉 regression
논문은 retrospective evaluation에서 pipeline에 score가 공개되지 않은 아홉 regression을 세 범주로 묶는다. 다음 숫자는 모두 Figure 14에 표시된 before→after score다.
| 범주와 task | 관찰된 regression | score |
|---|---|---|
선택 오류, WB-code python_port · blog_tags |
selector가 95점 후보 대신 55점 후보를 골랐다. 후보 pool에는 95, 85, 85, 80, 55가 있었다. | 96→55 |
공유 전제, WB-code security · header injection |
후보들이 “keep key = name storage; it must not be fixed”라는 잘못된 전제를 공유했다. | 50→42 |
선택·변동, JobBench web administrators |
취약점 표가 all-or-nothing criterion인데 한 번의 bimodal sample이 평균을 올리는 방향으로 선택됐다. | 31→24 |
선택 오류, WB-web ui-state-rebuild |
다섯 후보 중 plainest implementation을 고른 결과 coverage가 필요한 평가를 충족하지 못했다. | 100→70 |
선택·coverage 실패, LAB tax · transfer pricing |
Mexico, guarantee fee, Form 3CEB를 포함한 형제 후보의 범위를 놓친 후보가 선택되어 한 규칙 item만 맞췄다. | 54→26 |
공유 전제, WB-code performance · validator cache |
id() key cache 가정이 12개 check 중 6개의 equivalent dict lookup을 놓쳤다. |
75→64 |
편집 효과 부족, LAB tax · notice of deficiency |
editor가 추천하지 말아야 할 추가 $106,153를 규칙으로 만들었다. | 83→81 |
평가 변동, WB-web particle boundary |
세 judge session이 verdict를 반환하지 않았고 stock run도 같은 항목에서 실패했다. | 44→10 |
평가 범위, JobBench court clerks |
PDF form-filling skill이 값을 기록했지만 33개 중 33개를 실행해도 criterion이 PDF를 읽지 않았다. | 16→8 |
이 사례들은 논문이 설명하는 세 종류의 문제, 즉 약한 후보를 고르는 selection, 후보 사이에 공유되는 잘못된 premise, outcome variability·missing verdict·평가 criterion과 맞지 않는 edit를 보여 준다. Figure 14의 score는 온라인 pipeline에 제공된 값이 아니라 회고 평가에서 얻은 값이다.
7.3 현재 방법의 한계
논문의 Limitations는 다음 두 가지를 명시한다.
- 추가 비용: Propose, Probe, Compose를 위해 추가 execution과 editor session이 필요하다. recursion budget을 늘리면 inference cost가 늘어나며, parallel session은 자원이 허용할 때 latency를 줄일 수 있지만 추가 computation을 없애지는 않는다. Figure 6은 제한된 budget 범위의 compute–performance 관계를 보일 뿐 보편적으로 최적인 배분을 제시하지 않는다.
- 불완전한 실행 신호: ground-truth supervision이 없으므로 refinement는 behavioral contrast와 model judgment에 의존한다. 이 신호는 execution variability와 shared model bias에 민감하고 correctness를 보장하지 않으며, 채택한 변경이 다른 task로 전이된다고 보장하지도 않는다.
References
Xu, R., Chen, Y., CuiZhu, Z., Mishra, B. D., Ming, Y., Yu, H., Han, R., Lee, C.-Y., & Pfister, T. (2026). Harness2: Recursive agent harnessing for an open world [Preprint]. arXiv. https://arxiv.org/abs/2610.14224v1
Keywords: recursive harnessing, agent harness, test-time adaptation, continual improvement, open-world agents Author: PaperWiki Last Updated: 2026-10-24