LLM은 자신의 에이전트 하네스를 만들고 진화시킬 수 있는가

왜 중요한가

기존 agent benchmark는 고정된 harness 안에서 task를 얼마나 잘 해결하는지 측정했지만, 실제 배포 성능은 실행 루프와 도구 정책, Context 관리, State, 검증 로직에도 크게 의존합니다. HarnessDev는 모델 가중치를 바꾸지 않고도 시스템 성능을 바꾸는 이 실행 인프라 자체를 평가 대상으로 삼아, LLM이 단순한 답변 생성을 넘어 지속적으로 재사용할 수 있는 agent system을 구축하고 개선할 수 있는지 측정합니다.

핵심 기여

실행 가능한 하네스를 평가 단위로 전환

HarnessDev는 한 번의 task output이 아니라 여러 downstream task에서 재사용되는 frozen runnable harness를 제출물로 삼습니다. 하네스의 task 성공률과 executor-model token 사용량을 함께 측정해 capability와 efficiency를 분리합니다.

Creation과 Evolution의 두 단계 구성

Creation에서는 약한 seed와 1~3개의 development case에서 완전한 실행 시스템을 만들게 합니다. Evolution에서는 자신이 만든 Code harness를 feedback 결과로 반복 수정하게 하여, 처음부터 만드는 능력과 기존 시스템을 유지·개선하는 능력을 구분합니다.

Creator와 Executor를 분리한 평가

Creator LLM은 development environment에서 harness를 만들고, harness가 freeze된 뒤 Executor LLM이 downstream task를 실행합니다. Self-Eval과 고정 Gemini 3.1 Pro를 사용하는 Unified-Eval을 병행해 하네스 설계와 실행 모델의 호환성을 따로 관찰합니다.

비공개 task와 실행 기록을 이용한 일반화 측정

Creation에서는 hidden evaluation task를 개발 과정에서 차단하고, Evolution에서는 feedback에 사용하지 않은 630개 SWE-Pro 인스턴스로 모든 공식 버전을 재평가합니다. 소스 코드와 trajectory, result, metric artifact를 보존해 금지된 경로 사용 여부도 사후 감사했습니다.

핵심 아이디어 이해하기

일반적인 LLM agent는 모델이 다음 행동을 고르는 것만으로 작동하지 않습니다. 모델 출력이 도구 호출과 파일 변경으로 이어지려면 실행 루프가 반복을 관리하고, Tool policy가 사용할 수 있는 도구와 순서를 정하며, Context 관리가 필요한 정보를 모델 입력에 남겨야 합니다. State와 Memory는 task 진행 상태를 보존하고, Lifecycle과 Recovery는 실패 뒤 재시작과 종료를 제어하며, Verification은 결과가 실제로 유효한지 검사합니다.

기존 benchmark에서는 이 여섯 기능이 이미 구현된 harness로 제공되므로 모델의 task-solving 능력만 비교하기 쉽습니다. HarnessDev는 이 경계를 뒤집어, 모델이 약하지만 실행 가능한 seed에 task decomposition, 도구 조정, Context 처리, State 저장, 복구, 검증, 종료 규칙을 추가하도록 합니다. 입력은 task specification과 소수의 development case이고, 처리 과정은 harness 코드 수정과 공개 case 실행이며, 출력은 여러 task에서 재사용 가능한 frozen execution system입니다.

Evolution에서는 제작자가 자신의 harness를 downstream 실행 feedback에 맞춰 다시 수정합니다. 점수 상승만 보면 개선처럼 보이지만, 특정 feedback task에 맞춘 변경은 보지 못한 task에서 재현되지 않거나 다른 executor에서 깨질 수 있습니다. 따라서 HarnessDev는 보이는 feedback score와 별도로 held-out task 성능, 실행 토큰 비용, executor 변경 후 성능을 비교합니다.

결과적으로 harness의 품질은 모델의 지능과 동일하지 않습니다. Opus 4.8의 Code harness는 Self-Eval에서 SWE-Pro 69.3을 기록했지만 Gemini 3.1 Pro가 실행하면 33.0으로 떨어졌고, Search harness의 중복 query 비율도 executor 변경 뒤 10.1%에서 88.2%로 상승했습니다. 하네스가 실행 모델의 출력 형식과 행동 특성에 맞춰져 있었기 때문입니다.

방법론

HarnessDev의 Creation에서는 모든 creator에게 동일한 weak seed를 제공합니다. Seed는 입력 파싱, 저수준 도구 노출, 결과·trajectory·log 기록만 담당하고 agent loop, task decomposition, tool policy, Context 관리, persistent state, verifier, retry·recovery, stopping rule은 제공하지 않습니다. Creator는 task-family specification과 1~3개의 development case를 이용해 harness H를 수정하며, hidden task와 human implementation은 볼 수 없습니다.

완성된 H는 freeze한 뒤 executor LLM과 downstream task x를 결합해 결과 y를 생성하고 evaluator가 native metric으로 점수를 계산합니다. Self-Eval에서는 creator가 executor도 맡고, Unified-Eval에서는 모든 생성 harness를 고정된 Gemini 3.1 Pro가 실행합니다. 비교 대상은 SWE-bench Pro public split 731개, Terminal-Bench 2.1 89개, MLE-bench 75개, EQ-Bench3 46개, BrowseComp 1,266개로 총 2,207개 downstream instance입니다.

Evolution에서는 각 creator의 Creation Code harness H₀를 시작점으로 삼습니다. 100개 SWE-Pro task와 89개 Terminal-Bench task의 완전한 평가 쌍을 feedback으로 사용하며, 최대 10개의 post-H₀ 평가 쌍과 쌍 사이의 제한된 probe를 허용합니다. 공식 버전은 두 benchmark 평가를 모두 완료한 동일 commit으로만 기록하고, 마지막에는 feedback에서 공개하지 않은 630개 SWE-Pro task를 사용해 held-out generalization을 측정합니다.

각 frozen harness에 대해 benchmark native metric의 task performance와 executor가 소비한 token 수를 기록합니다. Evolution의 pair score는 SWE-Pro-100 점수와 Terminal-Bench-89 점수의 평균으로 계산합니다. 또한 모든 실행의 source, trajectory, result, metric artifact를 보존해 hard-coded solution, hidden answer 접근, 자체 scoring 경로 같은 금지된 동작을 검사합니다.

주요 결과

Creation 성능은 domain별 편차가 컸습니다. Self-Eval에서 Opus 4.8의 전체 평균은 67.8로 human-engineered reference 86.2보다 낮았지만, Writing은 reference에 근접했고 MLE-bench에서는 Opus 4.8과 Gemini 3.1 Pro가 각각 32.9와 32.4 medal rate를 기록했습니다. 반면 Search에서 가장 큰 격차가 나타났고 Code도 reference보다 낮았습니다. Data task 실패의 77.8%가 harness defect로 분류되어 executor 능력만이 병목은 아니었습니다.

실행 비용과 성능은 일관되게 비례하지 않았습니다. MLE-bench의 executor token 사용량은 creator에 따라 약 19배 차이가 났지만, 더 많은 token을 쓴 harness가 항상 더 높은 점수를 얻지는 않았습니다. Code harness 18개는 총 17,111 net LOC를 추가했으나, 가장 적은 1,006 LOC를 추가한 Gemini 3.1 Pro가 Terminal-Bench 68.8로 가장 높은 점수를 기록했습니다. 코드 양보다 focused change와 반복 검증이 중요하게 작동했습니다.

생성된 harness의 내부 구현에도 공통적인 결함이 있었습니다. 18개 Code artifact 중 State class를 정의한 것은 11개였지만 state-saving interface와 periodic checkpointing을 구현한 것은 각각 1개뿐이었고, 기록된 26,679개 trajectory에는 checkpoint event가 없었습니다. 실행된 Data task 2,325개 중 441개는 degenerate submission을 만들었지만 이를 감지한 harness는 없었습니다. Self-test 횟수와 downstream score의 Spearman correlation은 0.13~0.26으로 유의하지 않았고, revision call의 correlation은 0.57이었습니다.

Evolution에서는 self-runtime 다섯 계열 모두 held-out 성능이 H₀보다 1.43~4.44점 상승했으며 평균 상승폭은 3.11점이었습니다. Opus 4.8의 held-out 상승폭이 +4.44점으로 가장 컸습니다. 그러나 feedback score와 held-out score가 같은 방향으로 움직인 경우는 64개 비교 전환 중 34회, 즉 53.1%뿐이었고, creator가 선언한 최종 버전 중 held-out 최적 버전은 2/9개였습니다. 고정 Gemini executor에서는 Opus만 held-out 성능이 개선됐고 Qwen 3.7 Max, DeepSeek V4 Pro, GPT-5.5 계열은 각각 -1.11, -2.38, -10.32점 하락했습니다.

Evolution의 개선은 주로 실행·제어 흐름 수정에서 나왔습니다. 64개 공식 전환 중 58개가 실행 또는 제어 흐름을 바꿨고, Tool 변경은 37개, Lifecycle·Recovery 변경은 17개, Context 변경은 16개, State 변경은 4개였습니다. Opus는 100개 실행 중 99개가 성공을 보고하지만 실제 통과는 48개인 문제를 찾아 completion check를 추가했습니다. 반대로 Qwen의 message sanitizer는 Gemini의 유효한 tool-result sequence를 깨뜨렸습니다. 동일 commit도 pair score가 약 ±4.75점 변동해 작은 상승을 코드 변경의 효과로 단정하기 어려웠습니다.

기술 상세

HarnessDev가 제출받는 산출물은 한 번의 답변이 아니라 downstream task 사이에서 freeze 후 재사용되는 통합 executable system입니다. Creator LLM은 development environment D 안에서 weak seed를 수정해 H를 만들고, H가 고정된 뒤 Executor LLM이 H 내부에서 task를 실행합니다. H에는 Execution loop, Tool policy, Context, State & memory, Lifecycle, Verification의 여섯 제어 모듈과 unified audit output, domain-specific scorer-readable artifact가 포함됩니다.

Seed는 task-solving policy를 제공하지 않는 compatibility layer입니다. Task와 model configuration을 파싱하고 허용된 low-level tool과 artifact I/O를 노출하지만, 실제 tool orchestration이나 계획·복구·검증은 수행하지 않습니다. 따라서 수정하지 않은 seed는 모든 downstream benchmark에서 0점을 기록하며, Creation 점수는 creator가 추가한 실행 로직에서 나옵니다. 완성된 harness는 Code에서 repository state와 patch, Data/ML에서 submission과 metrics, Writing에서 최종 prose, Search에서 answer와 cited evidence를 scorer-readable artifact로 출력합니다.

평가 분리는 harness와 executor의 결합 효과를 드러냅니다. Self-Eval은 L_E = L_C 조건으로 creator가 만든 시스템 전체를 측정하고, Unified-Eval은 모든 harness를 Gemini 3.1 Pro로 실행합니다. Opus 4.8 Code harness의 SWE-Pro가 Self-Eval 69.3에서 고정 Gemini 33.0으로 내려간 사례처럼, 120-step limit이나 stopping rule이 원래 executor에 맞춰져 있으면 실행 모델 전이가 깨집니다. Opus Search harness에서는 executor 변경 뒤 duplicate-query 비율이 10.1%에서 88.2%로 올랐습니다.

Evolution은 H₀에서 시작해 완전한 SWE-Pro-100과 Terminal-Bench-89 평가 쌍을 거친 commit만 공식 버전으로 채택합니다. 두 benchmark pair score는 두 percentage score의 동일 가중 평균이며, probe는 첫 5개 task만 검사하는 진단용 실행으로 공식 점수에 포함하지 않습니다. 모든 공식 버전은 이후 보지 못한 SWE-Pro-630에서도 실행되어 online feedback 적응과 held-out 일반화를 분리합니다.

구현 증거를 정적 코드 선언만으로 세지 않고 실제 trajectory에서 확인한 점도 핵심입니다. Code의 108개 component instance 중 72개는 실제 실행을 유발했고 18개는 부분 증거만 있었으며 18개는 관찰되지 않았습니다. 새로 추가된 169개 function·class 중 entry point에서 reachable한 것은 113개, dead code를 통해서만 reachable한 것은 31개, caller가 없는 것은 25개였습니다. 이 방식은 작성된 기능과 실행 경로에 실제로 연결된 기능을 구분합니다.

한계점

Human-engineered baseline은 domain별로 출처와 조건이 균일하지 않고 최적 시스템이라고 보장되지 않습니다. Unified-Eval도 복잡한 harness–model 상호작용을 완전히 제거하지 못합니다. Evolution은 creator–runtime 조합별 trajectory가 하나뿐이며 일부 main-runtime cell은 완료되지 않아 불확실성 추정이나 모집단 수준 비교가 어렵습니다. Held-out 평가는 현재 SWE-Pro에만 적용됐고, development environment D는 두 단계 모두 고정되어 있어 evolved harness가 다음 evolution의 개발 환경이 될 수 있는지는 검증하지 않았습니다. 또한 HarnessDev는 model-external learning을 평가할 뿐 parameter training을 대체한다고 주장하지 않습니다. 생성된 harness는 컨테이너에서 실행됐지만 해당 경계는 재현성을 위한 설정이며 강한 격리를 보장하지 않으므로, 재사용 시 untrusted code로 취급해야 합니다.

실무 활용

HarnessDev의 평가 구조는 LLM agent를 task 정답률만으로 비교하지 않고, 실행 루프부터 검증·복구까지 포함한 배포 가능한 시스템 단위로 점검할 때 활용할 수 있습니다. 특히 executor 변경에 따른 성능 하락과 feedback 과적합을 함께 측정하므로, 특정 모델에만 맞춘 harness를 운영 환경에 배포하기 전 호환성과 유지보수성을 확인하는 데 적합합니다.

Coding assistant harness의 Tool policy, patch 검증, 종료 조건, 실패 복구를 SWE-Pro와 Terminal-Bench에서 비교
동일한 harness를 여러 executor LLM에 연결해 Prompt·도구 프로토콜·실행 예산의 모델 의존성 측정
feedback task와 held-out task를 분리해 agent harness 수정이 실제 일반화 성능으로 이어지는지 확인
task 성공률과 task당 실행 token을 함께 기록해 운영 비용 대비 harness 효율 비교

코드 공개 여부: 미확인

키워드

HarnessDev(에이전트 하네스 개발 벤치마크)Agent Harness(에이전트 실행 인프라)Creation(하네스 생성)Evolution(하네스 진화)Executor Transfer(실행 모델 전이)Held-out Evaluation(비공개 일반화 평가)Execution-Token Cost(실행 토큰 비용)

용어 해설

에이전트 하네스(Agent Harness): — Agent Harness는 LLM의 출력이 실제 행동으로 이어지도록 실행 루프, 도구 사용 정책, Context 관리, State와 Memory, Lifecycle 제어, 실패 복구, 결과 검증을 묶은 실행 인프라입니다. 같은 모델 가중치라도 하네스 구성에 따라 downstream task 성능과 비용이 달라집니다.
비공개 평가 벤치마크(Held-out Benchmark): — Held-out benchmark는 개발 과정에서 모델이나 하네스 제작자에게 정답과 점수를 공개하지 않고, 개발이 끝난 뒤 일반화 성능을 측정하는 평가 세트입니다. HarnessDev에서는 Evolution 중 보지 못한 630개 SWE-Pro 인스턴스를 사용해 feedback set 과적합 여부를 확인합니다.
실행 모델 전이(Executor Transfer): — Executor transfer는 한 LLM이 만든 하네스를 다른 LLM이 실행할 때 기능과 성능이 유지되는지를 측정하는 관점입니다. 하네스의 Prompt, 도구 프로토콜, 실행 예산, 종료 규칙이 제작 모델에 맞춰져 있으면 실행 모델이 바뀔 때 성능이 크게 떨어질 수 있습니다.
실행 토큰 비용(Execution-Token Cost): — Execution-token cost는 고정된 하네스가 downstream task를 해결하는 동안 실행 모델에 소비한 토큰 수입니다. 제작 과정에서 사용한 토큰은 제외하고, 전체 토큰과 task당 평균 토큰을 따로 계산합니다. 성능뿐 아니라 운영 비용과 처리 효율을 평가하기 위한 지표입니다.
통합 실행 모델 평가(Unified-Eval): — Unified-Eval은 서로 다른 creator LLM이 만든 하네스를 동일한 고정 executor LLM으로 실행하는 평가 방식입니다. Creator와 executor의 능력 및 호환성이 섞이는 Self-Eval과 달리, 하네스 설계 차이를 비교하기 위한 조건을 제공합니다.

LLM은 자신의 에이전트 하네스를 만들고 진화시킬 수 있는가

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

용어 해설

관련 토론

댓글

관련 기사

AI가 다른 AI의 코딩 성능을 개선하는가

최종 점수를 넘어선 장기 AI 연구 에이전트 평가

작업마다 스스로 진화하는 에이전트 하네스

실행 Trace로 LLM Agent Harness를 자동 개선

코딩 에이전트의 정의와 성능 평가를 위한 벤치마크 연구 동향.

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

관련 토론

댓글

관련 기사

AI가 다른 AI의 코딩 성능을 개선하는가

최종 점수를 넘어선 장기 AI 연구 에이전트 평가

작업마다 스스로 진화하는 에이전트 하네스

실행 Trace로 LLM Agent Harness를 자동 개선

코딩 에이전트의 정의와 성능 평가를 위한 벤치마크 연구 동향.