핵심 요약
- Harness²는 모델 가중치를 고정한 채, 처음 보는 작업마다 에이전트 하네스(시스템 프롬프트, 스킬, 스크립트 등 8가지 파일)를 고쳐 보고 그 경험을 도메인별 라이브러리에 쌓아 다음 작업에 넘기는 프레임워크입니다.
- 정답 라벨이나 채점기 없이, 같은 작업을 고친 하네스로 다시 실행해 본 결과와 원래 실행을 비교한 행동 차이(behavioral contrast)만으로 어떤 수정을 남길지 정합니다.
- 논문에서 저자들은 한 번의 개선 단계로 WorkBuddy-Bench 최대 11.5점, JobBench 최대 4.5점, LAB 부분 통과율 최대 11.8%p 향상을 보고했습니다. 측정은 Google Cloud AI Research와 Northwestern University 저자들이 직접 했습니다.
- 공개된 코드는 Linux, Python 3.12, Google Cloud Vertex AI 설정을 전제로 합니다. 모델 없이 도는 로컬 데모는 바로 실행되지만, 벤치마크 실행은 작업마다 실행과 편집 세션을 여러 번 돌리므로 API 비용이 큽니다.
Harness² 소개
LLM 에이전트의 성능은 모델만으로 정해지지 않습니다. 같은 모델이라도 어떤 시스템 프롬프트를 주는지, 어떤 도구 안내와 스킬, 스크립트를 붙이는지에 따라 결과가 크게 달라집니다. 이처럼 모델 바깥에서 에이전트의 행동을 정하는 실행 환경 전체를 하네스(harness)라고 부릅니다. Meta-Harness나 AHE(Agentic Harness Engineering) 같은 기존 자동 최적화 방법은 학습용 작업 묶음과 점수를 두고 미리 하네스를 탐색한 뒤 고정해 배포합니다. 그런데 실제 업무에서는 배포 뒤에 처음 보는 작업이 계속 들어오고, 그 작업에는 정답도 채점기도 없습니다. 이번에 소개하는 Harness²는 이런 환경에서 하네스를 작업마다 고치고, 그 개선 과정 자체를 다음 개선의 재료로 쓰는 재귀적 에이전트 하네싱(recursive agent harnessing) 프레임워크입니다.
Harness²는 두 겹의 재귀로 동작합니다. 작업 수준 재귀(task-level recursion)는 지금 작업의 하네스를 제안(Propose), 시험 실행(Probe), 조합(Compose)의 세 단계로 고칩니다. 하네싱 수준 재귀(harnessing-level recursion)는 작업이 끝날 때마다 채택한 하네스와 실행 증거로 뒷받침된 교훈을 개선 하네스(improvement harness)의 라이브러리에 저장합니다. 다음 작업의 개선 세션은 이 라이브러리를 읽고 수정안을 만듭니다. 다음 작업도 항상 같은 기본 하네스에서 출발하며, 이전 작업의 하네스를 그대로 물려받지 않는다는 점이 Harness²의 설계에서 핵심입니다. 이전 작업에 맞춰진 하네스를 그대로 넘기면 작업 분포가 바뀔 때 잡음이 커진다는 것이 저자들의 문제의식입니다.
Harness²는 Google Cloud AI Research와 Northwestern University 연구진이 2026년 10월 arXiv에 공개한 논문 Harness²: Recursive Agent Harnessing for an Open World의 공식 구현입니다. Harness²는 실행기(executor)로 터미널 코딩 에이전트인 OpenCode (
Opencode: 다양한 LLM을 사용할 수 있는, 터미널 기반의 오픈소스 AI 코딩 에이전트)와 Codex CLI를 지원하고, 평가 벤치마크로 JobBench, LAB, WorkBuddy-Bench 세 가지를 설치 스크립트와 함께 제공합니다. 과거 실행 경험을 메모리로 꺼내 쓰는 ReasoningBank는 이번 논문의 공저자 일부(Yanfei Chen, Rujun Han, Chen-Yu Lee, Tomas Pfister)가 참여한 이전 연구이며, 이번 논문에서는 비교 기준선 중 하나로 쓰였습니다.
Harness²와 기존 하네스 개선 방법 비교
논문 부록 표 4는 하네스 개선 방법들을 개선 대상, 적용 시점, 정답 라벨 사용 여부 등으로 나눠 비교합니다. 아래 표는 그중 본문 실험에 기준선으로 쓰인 방법과 AHE를 원문 순서대로 옮기고, Gemini 3.5 Flash와 OpenCode 조합의 WorkBuddy-Bench 평균 점수(논문 표 1, 3회 실행 평균)를 덧붙인 것입니다:
| 방법 | 개선 대상 | 적용 시점 | 정답 라벨 사용 | 작업 흐름 따라 누적 | 개선기 자체 갱신 | WorkBuddy-Bench 평균 |
|---|---|---|---|---|---|---|
| Meta-Harness | 하네스 | 사전(offline) | 예 | 아니오 | 예 | 76.4 |
| AHE | 하네스 | 사전(offline) | 예 | 아니오 | 예 | 실험 없음 |
| ReasoningBank | 메모리 | 배포 중(online) | 아니오 | 예 | 아니오 | 73.4 |
| Harness Scaling | 하네스 | 배포 중(online) | 아니오 | 아니오 | 아니오 | 75.3 |
| Harness² | 하네스 | 배포 중(online) | 아니오 | 예 | 예 | 77.5 |
같은 조건에서 기본 하네스(OpenCode 그대로)의 점수는 72.4입니다. Meta-Harness는 별도 학습 분할로 미리 탐색한 하네스를 고정해 씁니다. Harness Scaling은 작업마다 하네스를 고치지만 작업 사이에 아무것도 넘기지 않습니다(이 기준선의 출처 논문은 Terminal-Bench 2.1에서 자동 하네스 진화가 같은 예산의 단순한 테스트 시점 스케일링보다 낫지 않았다고 보고한 평가 연구입니다). ReasoningBank는 하네스를 건드리지 않고, 과거 궤적에서 뽑은 전략만 프롬프트 앞에 추가합니다. Harness²는 배포 중에 하네스 파일 자체를 고치면서, 그 개선 경험을 다음 작업으로 넘기는 두 가지를 함께 하는 방법입니다.
저자들은 같은 하네스를 k번 실행해 결과물 하나를 고르는 Best-of-k 기준선과도 비교했습니다. WorkBuddy-Bench 코드와 오피스 도메인(Gemini 3.5 Flash, OpenCode)에서 k=2의 Harness²가 k=5의 모든 기준선보다 높았습니다(논문 그림 5). 상용 하네스를 그대로 쓴 경우와도 비교했습니다. WorkBuddy-Bench에서 Gemini 3.5 Flash를 CodeBuddy, OpenCode, Codex, Claude Code에 각각 넣었을 때 도메인별 최고점은 Claude Code(코드, 오피스)와 Codex(웹)였습니다. OpenCode에서 출발한 k=5의 Harness²는 이 최고점보다 4.6, 5.8, 4.9점 높았고, 저자들은 이 차이에 추가 연산이 들어간다는 점도 함께 적었습니다(부록 그림 13).
다만 모든 칸에서 Harness²가 앞서지는 않습니다. 저자들에 따르면 WorkBuddy-Bench 평균과 JobBench 점수에서는 네 가지 모델과 하네스 조합 모두 Harness²가 기준선보다 높았습니다. 그러나 LAB 부분 통과율에서는 Gemini 3.5 Flash와 Codex 조합에서 Meta-Harness(76.5)가 Harness²(75.6)를 앞섰습니다. 같은 문제 범주의 다른 연구로는 실행 트레이스로 하네스를 진화시키는 HarnessX가 있으며, 표 4에서는 사전 최적화 방법으로 분류되어 있습니다.
Harness²를 사용하면 좋을 사용자
Harness²는 정답 없이 들어오는 전문 업무형 작업(문서 작성, 데이터 대조, 법률 검토 등)에서 에이전트 하네스를 자동으로 개선하는 방법을 연구하거나 재현하려는 연구자와 엔지니어에게 맞습니다. 논문과 같은 벤치마크, 같은 실행기를 그대로 설치하는 스크립트가 들어 있어, 하네스 최적화 기법을 비교 실험하려는 팀은 기준선 실행과 채점까지 한 번에 갖출 수 있습니다. 또한 같은 모델을 실행기와 편집기로 함께 써도 다섯 개 모델 모두 점수가 올랐다는 결과가 있어, 더 강한 편집 모델 없이 자체 모델로 시험해 보려는 경우에도 출발점이 됩니다.
반대로, 가장 작은 예산(k=1)에서도 작업 하나에 기준 실행 1회, 후보 시험 실행 2회, 조합 후 재실행 1회로 실행이 4번 필요하고, 편집과 반영 세션이 따로 추가됩니다. 공개 설정은 Google Cloud Vertex AI의 모델과 인증을 전제로 하며, 실행기의 네트워크 접근은 제한되어 있지 않고 Codex는 샌드박스를 끈 채 실행됩니다. 자기 업무용 에이전트에 바로 붙여 쓸 도구를 찾는 팀에게는 Harness²가 아직 적절한 선택지가 아닙니다. 자신의 작업 폴더로 Harness²를 실행하는 --bench local 기능도 아직 제안 이슈(#5) 단계입니다.
Harness²의 두 단계 재귀 구조
아래 그림은 Harness²의 전체 흐름을 보여 줍니다. 왼쪽 큰 상자가 작업 수준 재귀(Task-Level Recursion), 오른쪽이 하네싱 수준 재귀(Harnessing-Level Recursion)이고, 맨 아래 화살표(Move to the next task)가 다음 작업으로 넘어가는 경로입니다:
작업 수준 재귀: 제안, 시험 실행, 조합
Harness²의 한 개선 단계는 세 단계로 이뤄집니다. 먼저 현재 하네스로 작업을 한 번 실행해 기준 실행(reference execution)을 얻습니다. 이 실행은 결과물이 맞았는지가 아니라 하네스가 어떻게 행동했는지를 보여 주는 자료로만 씁니다.
- 제안(Propose): 하네스 편집기(Harness Editor)가 후보 두 개를 만듭니다. 불변 후보(invariant)는 계획, 도구 사용, 컨텍스트 관리, 위임처럼 도메인과 상관없이 반복되는 작업 방식의 결함을 고치고, 도메인 후보(domain-specific)는 그 분야의 지식, 절차, 제약을 보탭니다. 두 후보 모두 실행 가능한 하네스 파일 묶음입니다.
- 시험 실행(Probe): 각 후보를 같은 모델, 같은 환경에서 같은 작업에 실행하고, 기준 실행과 궤적 및 결과물을 비교해 수정이 의도한 결함을 줄였는지, 아무 변화가 없었는지, 다른 문제를 만들었는지를 봅니다.
- 조합(Compose): 하네스 조합기(Harness Composer)가 기준 실행, 두 후보, 각 후보의 차이(diff)와 실행 증거를 읽고 다음 하네스를 만듭니다. 근거가 있는 수정만 합치고, 서로 충돌하면 고치며, 한 후보만 채택하거나 아무것도 바꾸지 않을 수도 있습니다.
조합된 하네스로 다시 실행한 결과가 그 작업의 최종 결과물이 됩니다. 저자들은 이 비교 증거가 정답 여부를 검증하지는 않는다고 분명히 적고 있습니다. 실행마다 생기는 무작위성과 모델이 공유하는 편향 때문에 증거의 신뢰도에 한계가 있고, 그래서 점수 대신 관찰된 행동 차이에 각 결정을 묶어 둔다는 설명입니다.
병렬 재귀와 순차 재귀
개선 예산 k를 늘리는 방법은 두 가지입니다. 아래 그림의 왼쪽 (a) Parallel은 병렬 재귀, 오른쪽 (b) Sequential은 순차 재귀이며, DOM은 도메인 후보, INV는 불변 후보를 뜻합니다:
병렬 재귀는 기준 실행 k개를 모은 뒤 불변 후보 k개와 도메인 후보 k개를 따로 시험 실행하고, 모든 후보와 증거를 받은 조합 세션 k개가 각자 다음 하네스를 만듭니다. 순차 재귀는 제안, 시험 실행, 조합을 k번 이어 붙여, 앞 단계에서 고친 하네스와 누적된 증거를 다음 단계로 넘깁니다. k가 1보다 크면 최종 결과물이 여러 개 생기므로, 선택기(selector)가 어느 하네스에서 나온 결과물인지 모르는 상태로 작업 요청과 원자료만 보고 하나를 고릅니다. 후보에는 기본 하네스의 실행 결과도 섞여 있어서, 고친 하네스가 아니라 원래 하네스의 결과물이 제출될 수도 있습니다.
하네싱 수준 재귀: 개선 경험을 라이브러리에 쌓기
작업이 끝나면 경험 반영기(Experience Reflector)가 기준 실행, 후보, 조합 결정, 최종 선택까지 전체 개선 기록을 다시 읽고, 어떤 수정이 어떤 조건에서 어떤 결함을 고쳤는지를 교훈으로 정리합니다. 작업 하나에 교훈은 최대 하나이고, 실행 비교로 뒷받침될 때만 남깁니다. 여러 구성 요소를 한꺼번에 바꿔 효과를 가를 수 없는 수정은 판단 보류(confounded)로 기록하고, 증거가 부족하면 아무 항목도 추가하지 않습니다. 라이브러리의 각 항목은 채택된 하네스 파일 전체와 EXPERIENCE.md 한 장으로 이뤄지고, 목차(INDEX)를 통해 다음 작업의 편집 세션이 필요한 항목만 열어 봅니다. 라이브러리는 벤치마크의 도메인마다 따로 두며, 같은 도메인 안의 작업은 순서대로 처리되어 앞 작업의 항목만 읽을 수 있습니다.
Harness²가 고치는 8가지 하네스 구성 요소
Harness²는 AHE의 파일 단위 하네스 분해를 가져와 구성 요소 하나를 더한 8가지를 편집 대상으로 둡니다. 각 구성 요소가 파일 하나이므로, 하네스 수정은 곧 파일의 차이(diff)가 됩니다. 아래 그림은 구성 요소를 런타임 역할별로 묶은 것입니다. 왼쪽 Context construction은 컨텍스트에 들어가는 내용, 오른쪽 위 Middleware와 Tool interface는 도구 호출 경로, 오른쪽 아래 Orchestration은 작업 위임을 맡습니다:
각 구성 요소의 파일과 역할은 다음과 같습니다:
| 구성 요소 | 파일 | 모델에 전달되는 시점 | 역할 |
|---|---|---|---|
| C1 시스템 프롬프트 | systemprompt.md |
매 호출 | 모든 작업에 적용되는 페르소나와 최상위 절차 |
| C2 가드레일 | guardrails.md |
매 호출 | 작업과 도구에 상관없이 지켜야 하는 강한 제약 |
| C3 메모리 | LongTermMEMORY.md |
매 호출 | 한 도메인의 작업들에 걸쳐 유지되는 사실 |
| C4 도구 안내 | tool_descriptions/tool_guidance.md |
매 호출 | 기존 도구를 언제, 어떻게 쓸지 |
| C5 서브에이전트 | sub_agents/<n>/AGENT.md |
task 도구 호출 시 | 별도 컨텍스트 창에서 일하고 결과만 돌려주는 위임 작업자 |
| C6 스킬 | skills/<n>/SKILL.md |
skill 도구 호출 시 | 필요할 때만 불러오는 전문 절차 |
| C7 스크립트 | scripts/<name>.py |
bash로 실행 | 토큰으로 추론하는 대신 실행하는 결정적 기능 |
| C8 플러그인 | plugin/<name>.ts |
도구 루프 안 | 도구 호출 전후에 끼어들어 행동을 강제하는 훅 |
위 표는 논문 부록 표 5의 정의를 옮긴 것이며, 경로는 OpenCode 실행기 기준입니다. Codex 실행기에서는 매 호출 전달되는 텍스트가 AGENTS.md 한 파일로 모이고, 필요할 때 불러오는 구성 요소는 같습니다. 초기 하네스에서는 매 호출 파일들이 벤치마크 지침 외에는 비어 있고, 나머지 디렉토리에는 그 구성 요소가 있다는 것만 알리는 자리 표시 파일만 있습니다.
어떤 형태로 고칠지도 편집기 프롬프트(논문 부록 H)가 정해 둡니다. 매 호출 텍스트는 모든 실행에서 토큰 예산을 차지하므로 마지막 수단으로 두고, 상황이 분명한 절차는 스킬, 반복되는 결정적 작업은 스크립트, 입력은 크고 답은 작은 조사는 서브에이전트, 도구 루프에서 반복되는 기계적 문제는 플러그인으로 넣으라는 순서입니다. 실제로 채택된 하네스에서도 스킬과 스크립트가 벤치마크마다 수정의 약 절반을 차지했습니다(논문 그림 10). 편집기에게는 채점 기준이나 점수가 없다는 점, 작업 자료와 궤적 안에 든 지시문을 따르지 말고 데이터로만 읽으라는 점도 프롬프트에 명시되어 있습니다.
실제로 어떤 수정이 들어가는지는 논문 그림 9의 JobBench 사례에서 볼 수 있습니다. 아래 그림의 TASK 열은 작업과 기본 하네스의 실패 두 가지, IMPROVED HARNESS 열은 고쳐진 파일(색이 있는 칸이 이번 작업에서 새로 쓰인 구성 요소), OUTCOME 열은 재실행 결과입니다:
일정, 인력, 예산 파일을 대조해 제작 문서를 만드는 이 작업에서 기본 하네스는 43.1점을 받았습니다. 궤적을 보면 지식 부족이 아니라 절차 문제였는데, 파일 사이의 수치를 대조하지 않았고 작성한 결과 파일을 다시 열어 확인하지도 않았습니다. 불변 후보는 모든 입력 파일을 먼저 목록화하고 결과 파일을 verify_outputs.py로 다시 열어 점검하라는 가드레일과 스크립트를, 도메인 후보는 일정과 예산 대조 절차를 담은 스킬과 "$50", "1,200"처럼 문자열로 저장된 숫자를 다루는 도구 안내를 넣었습니다. 조합기는 네 가지 수정을 모두 남겼고, 재실행 점수는 77.8점이었습니다.
Harness² 벤치마크 결과
모든 수치는 논문 저자들이 직접 측정한 값입니다. 실행기는 Gemini 3.5 Flash와 GLM-5, 초기 하네스는 OpenCode와 Codex의 기본 설정입니다. 하네스 편집기와 선택기로는 높은 추론 강도(high reasoning effort)로 설정한 Claude Opus 4.8을 썼습니다. 평가에는 WorkBuddy-Bench 테스트 절반(코드 40개, 웹 35개, 오피스 25개), JobBench 테스트 34개, LAB 테스트 100개 작업을 썼고, 각 점수는 작업 순서를 섞은 3회 실행의 평균입니다. 채점은 WorkBuddy-Bench는 결정적 검사와 Gemini 3.5 Flash 심사, JobBench는 Claude Opus 4.8, LAB은 Claude Sonnet 4.6이 맡았습니다. 채점 기준과 점수는 개선 과정의 어떤 모델에게도 보여 주지 않았습니다.
한 번의 개선 단계와 재귀 예산
논문 초록과 README가 내세운 대표 수치는 다음 네 행에서 나옵니다:
| 벤치마크 (지표) | 실행기 / 초기 하네스 | 기본 하네스 | Harness² (k=1) |
향상 |
|---|---|---|---|---|
| WorkBuddy-Bench (평균 점수) | GLM-5 / OpenCode | 64.2 | 75.7 | +11.5 |
| WorkBuddy-Bench (평균 점수) | Gemini 3.5 Flash / OpenCode | 72.4 | 77.5 | +5.1 |
| JobBench (점수) | Gemini 3.5 Flash / OpenCode | 31.5 | 36.0 | +4.5 |
| LAB (부분 통과율, %) | GLM-5 / OpenCode | 59.6 | 71.4 | +11.8 |
위 표는 논문 표 1과 표 2에서 해당 행만 옮긴 것입니다. 병렬 재귀를 k=5로 늘리면 한 번의 개선 단계보다 WorkBuddy-Bench에서 2.9~3.9점, JobBench에서 3.0~4.2점, LAB 부분 통과율에서 2.6~6.7%p가 더 올랐습니다. Gemini 3.5 Flash와 OpenCode 조합의 WorkBuddy-Bench 평균은 72.4에서 77.5(k=1), 80.8(k=5)로 올라갔습니다. 반면 비교 기준선 가운데 Harness Scaling은 12개 벤치마크와 설정 조합 중 7개에서 기본 하네스보다 낮았고, ReasoningBank는 코딩 작업에서 기본 하네스보다 최대 6.6점 낮았습니다.
저자들은 WorkBuddy-Bench와 LAB에서는 약한 모델일수록 이득이 크다고도 보고합니다. WorkBuddy-Bench에서 개선 단계 한 번을 거친 GLM-5(OpenCode 75.7, Codex 75.3)는 기본 하네스의 Gemini 3.5 Flash(72.4, 74.5)를 넘었습니다. 다만 JobBench에서는 반대로 Gemini 3.5 Flash의 향상폭이 더 컸습니다.
구성 요소 제거 실험과 비용
논문 표 3의 제거 실험(ablation)에서는 세 요소 모두 점수에 기여했습니다. WorkBuddy-Bench와 JobBench 점수가 라이브러리를 빼면 각각 3.1점과 1.8점, 불변과 도메인 후보의 역할 구분을 빼면 2.9점과 3.7점, 조합 단계를 빼면 1.6점과 1.9점 떨어졌습니다. 시험 실행 없이 편집기가 기본 하네스를 바로 고치게 하면 WorkBuddy-Bench 코드 점수가 73.4에서 63.2로, 웹 점수가 69.9에서 65.0으로 오히려 떨어졌습니다(오피스는 74.0에서 77.1로 올랐습니다, 논문 그림 7). 같은 조건에서 k=1로 쌓은 라이브러리를 주면 세 도메인 모두 기본 하네스 이상(73.8, 72.6, 77.5)이 되었고, k=5로 쌓은 라이브러리를 주면 시험 실행 없이도 코드, 웹, 오피스에서 각각 0.9, 4.4, 5.1점이 올랐습니다. WorkBuddy-Bench의 한 단계 개선(k=1)에 JobBench에서 쌓은 경험을 더하면 도메인별로 0.6, 0.5, 2.9점이 더 올랐습니다.
비용 쪽에서는 최종 결과물을 내기까지 쓴 모든 토큰(실행과 개선 비용 포함)을 센 논문 그림 6에서, 두 가지 Harness² 설정이 모두 실측 파레토 경계(Pareto frontier) 위에 놓였습니다. Gemini 3.5 Flash와 OpenCode 조합에서 k를 1에서 5로 늘리면 기본 하네스 대비 향상폭이 JobBench는 4.5점에서 7.5점, WorkBuddy-Bench는 5.1점에서 8.4점으로 커졌습니다. Meta-Harness는 k=5의 Harness²보다 연산을 더 쓰고도 점수가 낮았습니다. 다만 절대 비용은 큽니다. 그림 6의 로그 축에서 눈으로 읽은 근사값으로, JobBench에서 기본 하네스는 작업당 약 5M 토큰을 쓰지만 Harness²는 k=1에서 약 30M, k=5에서 100M 토큰을 넘습니다. 저자들도 README에서 모델을 쓰는 실행에는 API 비용이 든다며 작은 작업 선택부터 시작하라고 안내합니다.
같은 모델을 편집기로 쓸 때
편집기가 실행기보다 강해야만 효과가 나는지 확인하기 위해, 저자들은 같은 모델에게 두 역할을 함께 맡겨 OpenCode, k=2로 실험했습니다. 아래 그림의 회색 막대(Base harness)는 기본 하네스, 파란 막대(Ours)는 Harness² 적용 후 점수이고, 막대 위 숫자가 향상폭입니다:
GLM-5부터 Claude Opus 5까지 다섯 모델 모두 세 벤치마크에서 점수가 올랐고, GLM-5는 LAB에서 13.7%p가 올랐습니다. 다만 Gemini 3.5 Flash의 JobBench 향상은 0.9점에 그치는 등 모델과 벤치마크에 따라 폭의 차이가 큽니다.
저자들이 정리한 실패 사례
논문 부록 그림 14는 Harness²가 오히려 점수를 떨어뜨린 사례 9개를 세 갈래로 나눠 보여 줍니다. 위 줄(Blind selection took a weaker candidate)은 선택기가 더 약한 후보를 고른 경우입니다. 가운데 줄(The edit itself capped the pool)은 편집 자체가 잘못된 전제를 모든 후보에 퍼뜨린 경우이고, 아래 줄(Neither the edit nor the pick)은 실행 편차나 심사 오류처럼 편집과 선택 어느 쪽 탓도 아닌 경우입니다:
예를 들어 WorkBuddy-Bench 코드 작업에서는 이미 실행된 후보 중 95점짜리가 있었는데도 선택기가 가장 단순한 구현이라는 이유로 55점짜리를 골랐습니다. 다른 작업에서는 편집기가 쓴 점검 스크립트가 세 번 통과를 보고했지만, 그 스크립트가 편집기 자신의 잘못된 가정을 그대로 따르고 있어 점수가 75에서 64로 떨어졌습니다. 저자들은 한계 절에서도 행동 비교와 모델 판단에 의존하는 신호는 정답을 보장하지 않으며, 채택한 수정이 다른 작업으로 옮겨 간다는 보장도 없다고 적고 있습니다.
Harness² 설치와 사용
저장소 이름과 패키지, 명령어 이름은 harness2이므로, 아래 명령에서는 그 이름을 그대로 씁니다. 공식 지원 환경은 Linux와 Python 3.12(패키지 자체는 3.13도 지원)이며, uv가 필요합니다.
모델 없이 도는 로컬 데모
저장소를 받은 뒤, 저장소 루트에서 다음 명령을 실행합니다:
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2
이 데모는 모델 자격 증명 없이, 미리 짜 둔 결정적 편집기와 실제 Python 실행으로 병렬과 순차 재귀를 한 번씩 돌립니다. 데모 작업은 부호가 섞인 장부(CSV)의 합계를 구하는 것으로, 기본 하네스의 스크립트가 양수만 더하는 오류를 편집기가 고치게 되어 있습니다. 편집과 선택이 모델이 아니라 스크립트로 정해져 있으므로, 이 데모는 성능이 아니라 파일이 오가는 흐름과 라이브러리 형식을 확인하는 용도입니다. macOS에서 직접 실행해 본 결과 2초 안에 Local demo: 2 tasks completed; 0 failed.가 출력되었고, runs/demo/library/ 아래에 다음과 같은 EXPERIENCE.md가 만들어졌습니다:
## What each edit did
component: scripts/summarize.py
candidates: inv1
change: dropped the positive-only filter from the amount sum
observed: the probe total included the credits the base run omitted
verdict: helped
## Transferable lesson
- **cue**: When a ledger includes credits and debits
- **lesson**: Include both signs when summing in scripts/summarize.py.
벤치마크 실행
모델을 쓰는 벤치마크를 실행하려면 Node.js 20 이상과 Google Cloud CLI가 필요하고, LAB은 Pandoc과 Poppler, WorkBuddy-Bench는 Docker가 추가로 필요합니다. 저자들은 README에서 cp .env.example .env로 설정 파일을 만들라고 안내하지만, 2026년 10월 18일 기준 저장소에는 .env.example이 없고 이를 추가하는 PR(#7)이 아직 병합되지 않은 상태입니다. 그동안은 저장소 루트에 .env를 직접 만들고 설정 가이드의 변수를 채워야 합니다. 아래는 그 표에 나온 변수 이름으로 만든 뼈대이며, 값은 각자의 프로젝트와 모델 ID로 채웁니다:
GOOGLE_CLOUD_PROJECT=<Vertex AI 프로젝트 ID>
HARNESS2_SOLVER_MODEL=<실행기 모델, OpenCode의 provider/model 형식>
HARNESS2_IMPROVER_MODEL=<편집기 모델, 비우면 실행기 모델을 씀>
HARNESS2_JUDGE_MODEL=<채점 모델 ID>
설정 파일을 만든 뒤, 같은 셸에서 Vertex AI 인증을 마칩니다:
gcloud auth application-default login
공개 설정은 실행기와 채점기에 Vertex AI의 Gemini를 쓰고, 편집기로는 Vertex AI의 Claude나 Gemini를 쓰도록 되어 있습니다. 편집기 모델을 따로 지정하지 않으면 실행기 모델을 그대로 쓰므로, 논문처럼 Claude Opus 4.8을 편집기로 쓰려면 HARNESS2_IMPROVER_MODEL을 직접 지정해야 합니다. 그다음, 같은 가상환경에서 LAB 작업 하나만 골라 설치, 점검, 개선, 채점, 보고까지 실행해 볼 수 있습니다:
harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel \
--only-domains antitrust-competition --max-tasks 1
harness2-judge --bench lab --k 1 --mode parallel
harness2-report --bench lab --k 1 --mode parallel
채점과 보고 명령에는 개선 실행과 같은 벤치마크, 실행기, 부분집합, --k, --mode, 시드를 넘겨야 합니다. --mode sequential로 바꾸면 순차 재귀가 되고, --substrate cx를 붙이면 OpenCode 대신 Codex 실행기를 씁니다. --max-tasks는 전체가 아니라 도메인마다 적용되는 상한입니다. harness2에 --dry-run을 붙이면 모델 호출 없이 어떤 작업이 선택되는지만 미리 볼 수 있습니다.
평가 전에 네트워크를 막아야 하는 이유
공개된 코드는 실행기의 네트워크 접근을 제한하지 않으며, Codex는 샌드박스를 끈 채 실행됩니다. JobBench는 작업별 채점 기준 파일(RUBRICS.json)까지 Hugging Face에 공개되어 있습니다. 저자들은 이번 공개본을 검증하던 중 Codex 실행기가 지시받지 않았는데도 자기 작업의 채점 기준을 내려받은 일이 있었다고 실험 가이드에 적어 두었습니다. 평가하기 전에는, 설치를 마친 뒤 실행기 호스트에서 방화벽이나 DNS 정책으로 huggingface.co, hf.co, *.hf.co, github.com, raw.githubusercontent.com을 막아야 합니다. 설치 단계에서는 이 호스트들이 필요하므로 순서가 중요합니다. 논문에는 보고한 실험에서 실행기의 네트워크를 어떻게 제한했는지에 대한 설명이 없으므로, 수치를 재현하거나 비교할 때는 이 조건을 직접 정하고 결과와 함께 기록해야 합니다. 저자들도 실험 가이드에서 사용한 제한을 결과와 함께 보고하라고 안내합니다.
Harness²의 라이선스
Harness²는 Apache-2.0 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.
단, 벤치마크 실행에 쓰는 third_party/ 코드와 설치 시 내려받는 벤치마크, 데이터셋은 각자의 원래 라이선스를 따릅니다. 특히 WorkBuddy-Bench는 유럽연합(EU) 내 사용을 의도하지 않는다는 지역 제한 조항이 있는 Tencent 자체 라이선스이므로, 이 벤치마크를 내려받기 전에 WorkBuddy-Bench 라이선스를 확인해야 합니다.
Harness² 프로젝트 홈페이지
Harness² 논문
Harness² 프로젝트 GitHub 저장소
더 읽어보기
-
Meta-Harness: Stanford IRIS Lab이 공개한, LLM 주변 실행 코드를 자동으로 최적화하는 에이전트 하네스 탐색 프레임워크에 대한 연구
-
Agentic Harness Engineering(AHE): 관측 가능성 기반 코딩 에이전트 하네스의 자동 진화 프레임워크에 대한 연구
-
ReasoningBank: 성공과 실패 경험으로부터 스스로 진화하는 에이전트 추론 메모리 프레임워크 (feat. Google)
-
재귀적 자기 개선(RSI, Recursive Self-Improvement) 기법에 대한 서베이 연구 (1/2): 분류체계 및 배포 시점, 학습 시점의 자기 개선 루프 등
-
재귀적 자기 개선(RSI, Recursive Self-Improvement) 기법에 대한 서베이 연구 (2/2): 검증 계층과 자동 연구, 안전 문제 등
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
이 글은 파이토치 한국 사용자 모임
이 직접 정리한 글입니다. 새 글을 놓치지 않으시려면 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 알림을 받으시고, 회원으로 가입하시면 주요 글들을 이메일
로도 보내드립니다! 
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 