Harness^2가 실행 하네스를 스스로 고쳐 다음 과제 적응까지 학습한다

무엇인가

LLM 에이전트의 성능은 기반 모델만이 아니라 실행 하네스(harness), 즉 프롬프트·메모리·스킬·도구·오케스트레이션에 좌우된다. 같은 모델도 하네스가 바뀌면 성적이 크게 달라지는데, 코딩을 넘어 사무 워크플로와 법률처럼 요구사항이 다양한 영역으로 에이전트가 확장되면서 하네스를 사람이 계속 손보는 비용이 커졌다. 재귀적 자기개선(RSI)으로 하네스를 자동 진화시키려는 시도가 있었지만 오픈월드에서는 두 가지가 걸린다. 첫째, 테스트 시점의 과제는 하네스 설계 단계에서 본 적이 없어 정답 검증기가 없고, 둘째, 한 과제에 맞춘 개선이 다음 과제의 개선 방식 자체를 좋게 만들지 못한다. 이 논문은 이 두 문제를 동시에 겨냥한다.

어떻게 동작하나

제안 프레임워크 Harness^2는 플러그앤플레이 방식으로, 서로 맞물린 두 층의 재귀를 쓴다. 하네스는 파일 단위로 8개 컴포넌트(시스템 프롬프트, 가드레일, 메모리, 스킬, 도구 가이드, 스크립트, 서브에이전트, 미들웨어 플러그인)로 나뉘어 런타임에 파일로 마운트되고, 모델 가중치는 고정된 채 이 파일들만 편집된다. 과제 수준 재귀의 핵심은 정답 없이 편집을 이끄는 대조적 Propose–Probe–Compose 한 스텝이다. Propose에서 먼저 현재 하네스로 기준 실행 e0을 뽑아 하네스가 어떻게 행동하는지 관찰한 뒤 두 개의 후보 하네스를 제안한다. 하나는 도메인을 넘나들며 반복되는 계획·도구 사용·컨텍스트 관리·위임 같은 에이전트 결함을 겨냥하는 불변(invariant) 후보, 다른 하나는 현재 도메인의 지식·절차·제약을 겨냥하는 도메인 특화 후보이며, 둘 다 컴포넌트 파일을 편집해 만든 실행 가능한 하네스다. Probe에서는 두 후보를 동일한 모델·환경 설정으로 같은 과제에 실행하고, 그 궤적과 산출물을 기준 실행과 비교해 행동 대조(behavioral contrast)를 얻는다. 이는 과제 정답 검증이 아니라 편집이 겨냥한 결함을 완화했는지, 행동이 그대로인지, 회귀가 생겼는지를 보는 증거다. Compose는 기준 실행, 후보 하네스, 현재 하네스 대비 diff, 모든 실행 증거를 읽고 지지된 변경을 병합하거나 충돌하는 편집을 수정하거나 한 후보를 채택하거나 현재 하네스를 그대로 두는 선택적 결정을 내린다. 결정은 추정 점수가 아니라 구체적 관찰에 묶이고, 합성된 하네스를 다시 실행해 e'를 얻으며 결정과 증거는 스텝 기록 ξ에 남는다.

무엇과 다른가

이 스텝 위에 두 가지 확장이 있다. 병렬 재귀는 현재 하네스의 기준 실행 k개를 모으고 불변·도메인 특화 후보를 각각 k개 제안·탐침한 뒤, k개의 독립 합성 세션이 전체 후보 풀을 받아 각자 후속 하네스를 만든다(폭을 넓히는 한 번의 개체군 업데이트). 순차 재귀는 k개의 대조 스텝을 사슬처럼 이어 붙이며, 각 스텝은 직전 하네스와 누적 실행 이력을 조건으로 받는다. k가 1보다 크면 익명화된 산출물을 과제 요청·원자료와 비교하는 에이전트 선택기가 하나를 고르는데, 새 내용을 합성하지 않고 하네스 수정도 하지 않는다. k=1이면 두 형태 모두 기본 대조 스텝으로 줄어든다. 두 번째 층인 하네싱 수준 재귀는 과제가 끝난 뒤 개선 기록 전체를 되돌아보고, 실행 대조로 뒷받침된 교훈만 골라 하네스 개선 라이브러리를 갱신한다(ℛ_{t+1} = Update(ℛ_t, ℋ_t*, 𝒟_t)). 라이브러리 항목은 실행 가능한 하네스와, 적용 상황·교훈·근거를 적은 EXPERIENCE.md로 구성되고 인덱스로 검색된다. 다음 과제는 다시 공통 실행 하네스 ℋ_0에서 출발하지만 개선은 갱신된 개선 하네스의 안내를 받는다. 모델 가중치와 스테이지 지시문, 결정 규칙은 고정이고 라이브러리만 진화한다.

어떻게 쓰나

실험은 서로 다른 전문 영역의 벤치마크 세 개에서 이뤄졌다. WorkBuddy-Bench(Code·Web·Office 사무 산출물), JobBench(장시간 실행되는 엔드투엔드 직무 과제), 그리고 Harvey의 법률 에이전트 벤치마크 LAB(기준별 통과율 Partial로 보고)이다. 실행 모델은 Gemini 3.5 Flash와 GLM-5, 초기 하네스는 OpenCode와 Codex로 네 가지 조합을 만들고 기본 하네스·ReasoningBank·Meta-Harness·Harness Scaling과 비교했다. 기본 하네스 편집자는 Claude Opus 4.8(OpenCode)이다. 단일 개선 스텝(k=1)만으로 네 조합 모두에서 두 모델이 좋아졌다. WorkBuddy-Bench에서 GLM-5는 OpenCode 기준 11.5점 올라 이 벤치마크 최대 단일 스텝 개선을 기록했고, JobBench에서 4.5점, LAB Partial에서 11.8%포인트가 올랐다. 반면 ReasoningBank는 코딩 과제에서 기본 하네스보다 최대 6.6점 낮았고, Harness Scaling은 12개 벤치마크-조합 쌍 중 7개에서 기본보다 못했다. Harness^2는 WorkBuddy-Bench 평균과 JobBench 점수에서 네 조합 모두 비교 베이스라인을 앞섰고, LAB Partial에서는 Codex 아래 Gemini 3.5 Flash에 한해 Meta-Harness가 앞섰다. 병렬 재귀 k=5는 단일 스텝 대비 WorkBuddy-Bench 2.9~3.9점, JobBench 3.0~4.2점, LAB Partial 2.6~6.7%포인트를 더 얹었다.

전제와 한계

분석에서 병렬 재귀는 k가 1에서 5로 늘 때 WB-code 76.5→80.8, WB-office 79.5→83.4로 단조 증가했고, 두 재귀 형태 모두 k=2에서 그림에 나온 모든 베이스라인의 k=5보다 높았다. 컴퓨트 대비 성능에서 Harness^2의 두 설정은 경험적 파레토 프런티어에 놓였고, Gemini 3.5 Flash·OpenCode에서 k를 1에서 5로 늘리면 JobBench 이득이 4.5→7.5점, WorkBuddy-Bench가 5.1→8.4점이 됐다. Meta-Harness는 k=5의 Harness^2보다 컴퓨트를 더 쓰고도 성능은 낮았다. 절제 실험(WorkBuddy-Bench 3개 도메인 평균, JobBench, Gemini 3.5 Flash·OpenCode, k=1)에서 라이브러리를 빼면 3.1점·1.8점, 스코프 편집자 역할을 빼면 2.9점·3.7점, 합성을 빼면 1.6점·1.9점이 각각 떨어져 세 요소가 모두 기여했다. 하네싱 수준 재귀에서는 기준 실행·후보 탐침·라이브러리 없이 기본 하네스를 직접 고치면 Code가 73.4→63.2, Web이 69.9→65.0으로 오히려 나빠졌고, k=1로 쌓은 라이브러리는 기본 성능을 회복시켰으며 k=5 라이브러리는 Code·Web·Office에서 0.9·4.4·5.1점 이득을 지지했다. JobBench에서 쌓은 라이브러리를 WorkBuddy-Bench에 옮겨도 0.6·0.5·2.9점이 올랐다. 같은 모델을 실행자와 편집자로 쓴 실험(OpenCode, k=2)에서는 GLM-5부터 Claude Opus 5까지 다섯 모델 모두 모든 벤치마크에서 개선됐다(Opus 5는 3.3·5.5·3.0점, GLM-5는 LAB에서 13.7점). 사례 연구로 Gemini 3.5 Flash·OpenCode가 43.1점을 받은 JobBench 과제는 원자료 간 수치 대사와 산출물 재검증이 빠진 절차적 실패였고, 불변 가드레일과 도메인 특화 스킬·도구 가이드를 적용한 뒤 77.8점이 됐다.

실무적으로 이 논문이 말하는 것은 모델을 바꾸지 않고도 프롬프트·메모리·스킬·도구·오케스트레이션 파일을 자동 편집하는 것만으로 에이전트 성능을 두 자릿수까지 끌어올릴 수 있다는 점이다. 특히 정답 라벨이 없는 사내 워크플로나 사무·법률 같은 전문 과제에서 검증기 대신 기준 실행과 후보 실행의 행동 대조를 증거로 쓰는 방식은 그대로 참고할 만하다. 도입을 검토한다면 세 가지를 확인해야 한다. 개선 이득이 과제별 일회성인지 다음 과제로 전이되는지(논문은 라이브러리 전이를 별도로 측정한다), 병렬 재귀의 폭 k가 늘릴 만한 컴퓨트 대비 이득을 주는지, 그리고 실행자와 편집자가 같은 모델이어도 되는지다. 마지막 항목은 논문이 별도 실험으로 다뤄 더 강한 편집자가 필요하지 않다고 보고한다.

논문은 별도의 한계 절을 두지 않지만 본문 곳곳에 전제가 깔려 있다. 개선 증거는 실행 확률성과 모델의 공유 편향 때문에 신뢰도가 제한되며, 대조는 과제 정답 검증이 아니라 행동 비교일 뿐이다. 선택기가 고른 하네스 ℋ_t*는 검증된 최적이 아니라 채택된 것이라는 표기이며, 증거가 불충분하면 되돌아보기 단계에서 새 경험 항목을 추가하지 않는다. 라이브러리 전이를 평가한 실험은 이후 과제의 경험을 사용한 회고적 테스트로 온라인 적응을 측정한 것이 아니다. 또한 재귀가 초기 하네스 간 격차를 균일하게 좁히지는 않았다(WorkBuddy-Bench에서 Gemini 격차는 2.1→0.4로 줄었지만 GLM-5는 0.2→1.3으로 늘었다). 실험은 한 번의 배포 스트림에서 모델 가중치 갱신 없이 이뤄지며, 스테이지 지시문과 결정 규칙은 고정이다.