모델이 에이전트 하네스를 스스로 만들고 고칩니다 | DAKER 커뮤니티

2026년 9월 1일 ByteDance Seed·SUTD·Georgia Tech 등이 HarnessDev를 arXiv에 공개했습니다. 에이전트 평가 단위를 과제 출력이 아니라, 실행 가능한 하네스 자체로 옮깁니다. Creation에서는 약한 시드에서 완전한 실행 시스템을 만들고, Evolution에서는 그 하네스를 피드백으로 고칩니다. Creation 결과는 생성 모델 6개·도메인 4개·다운스트림 벤치 5개·고유 인스턴스 2,207개를 덮습니다. 같은 GPT-5 가중치라도 Terminal-Bench 2.1에서 Terminus 2는 35.2%, Codex CLI는 49.6%로 하네스만 바꿔도 점수가 갈립니다. Self-Eval에서 Opus 4.8 overall은 67.8이고 human reference는 86.2입니다. 오늘 팀은 모델 카드 옆에 “어떤 하네스로 돌렸는지”를 같이 적습니다.

논문은 2026-09-01 arXiv에 올라왔습니다. 초록은 arXiv:2609.01437에서 확인할 수 있습니다. 영문 제목은 HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?입니다. 저자는 Yuhao Wu, Jingyuan Zhang 외 (ByteDance Seed, SUTD, Georgia Tech, M-A-P, TokenWave.AI)입니다. PDF는 같은 번호의 pdf입니다. 관련 페이지는 https://self-developing-agents.github.io/입니다. 오늘 본문은 제공된 사실과 초록·본문에서 확인한 범위만 옮깁니다. 없는 숫자는 쓰지 않습니다.

평가 대상을 하네스로 바꿉니다

에이전트가 연구 프로토타입에서 배포 도구로 갈수록, 능력은 모델 바깥의 실행 인프라(하네스)에 크게 의존합니다. 가중치를 고정한 채 하네스만 바꿔도 과제 성능이 크게 달라질 수 있습니다. 기존 평가는 선택한 하네스 아래의 다운스트림 점수만 보고, 모델이 하네스를 직접 개발하는 능력은 잘 재지 않았습니다.

HarnessDev는 Creation과 Evolution 두 단계입니다. Creation은 약한 시드와 소수 사례에서 완전한 실행 시스템을 만듭니다. Evolution은 스스로 만든 하네스를 다운스트림 실행 피드백으로 고칩니다. 능력(held-out 과제 성공)과 효율(실행 토큰 비용)을 같이 봅니다.

동기화 예시로, 동일 GPT-5 가중치가 Terminal-Bench 2.1에서 Terminus 2에서는 35.2%, Codex CLI에서는 49.6%를 냅니다. DAKER·DACON 제출에서도 “모델 이름만” 적지 말고 하네스·런타임·권한 범위를 같이 적습니다.

Creation 숫자와 한계

보고된 Creation은 생성 LLM 6개, 도메인 4개, 다운스트림 벤치 5개, 고유 인스턴스 2,207개입니다. 개발에 숨긴 평가 태스크도 있습니다. 생성 하네스는 코드와 검색·리서치에서 성숙한 사람 설계 참고 시스템에 크게 못 미치고, 글쓰기와 머신러닝 실험에서는 맞추거나 넘기도 합니다. 실행 비용 편차는 큽니다.

Self-Eval에서 Opus 4.8의 overall은 67.8로 생성 모델 중 가장 높았지만, human-engineered reference 86.2보다 낮습니다. Evolution은 일부 이득을 내지만 불안정하고, held-out 과제와 실행 모델이 바뀌면 전이가 제한적입니다. 고정 런타임 모델 실험도 이득이 실행 모델에 강하게 의존한다고 보고합니다.

프로젝트 페이지는 self-developing-agents.github.io입니다. 벤치 이름을 우리 실측처럼 쓰지 말고, 표 구조만 복제합니다.

빌더 팀에 옮기는 점검

팀이 오늘 할 일은 “우리 에이전트 점수”와 “우리 하네스 명세”를 분리하는 것입니다. 시드 하네스, 추가한 도구, 검증기, 스텝 한도를 파일로 남깁니다. 하드코딩된 스텝 한도가 다른 실행 모델에서 붕괴한 사례가 논문에 있으므로, 실행기별 설정을 점검합니다.

Creation 체크리스트에는 약한 시드에서 무엇을 추가했는지, Evolution 체크리스트에는 피드백 세트와 held-out이 겹치지 않는지를 넣습니다. DAKER 해커톤 README에 하네스 커밋 해시와 실행 모델 ID를 나란히 적습니다.

코드 하네스를 자랑할수록 토큰 비용을 숨기기 쉽습니다. 능력 점수 옆에 실행 토큰을 같이 둡니다. 배포가 제출입니다. 올린 링크가 제출입니다.

Controller·Worker를 나누면, 하네스 수정 권한과 과제 실행 권한을 분리합니다. 한 에이전트가 자기 채점기를 마음대로 고치지 못하게 합니다.

도구 권한과 공유 메모리를 쓰는 팀이면 전역 설정을 별도 파일로 둡니다. 시드 저장소에 비밀키를 넣지 않습니다.

하네스 명세를 모델 카드 옆에 둡니다

HarnessDev가 강조하는 점은 단순합니다. 같은 가중치라도 실행 인프라가 바뀌면 점수가 바뀝니다. Terminal-Bench 2.1의 35.2%와 49.6% 예시는 “모델만 고르면 끝”이 아니라는 경고입니다. 팀 README 상단에 모델 ID, 하네스 이름, 런타임, 권한 범위, 스텝 한도를 다섯 칸으로 고정합니다.

Creation 점수를 읽을 때는 overall만 보지 말고 도메인별 갭을 봅니다. 코드·검색/리서치는 human reference에 크게 못 미치고, 글쓰기·ML 실험은 맞추거나 넘는다는 보고입니다. Self-Eval Opus 4.8 overall 67.8 대 reference 86.2 차이도, “생성 하네스가 거의 같다”고 과장하지 말라는 기준선입니다.

Evolution을 우리 파이프라인에 넣을 때는 피드백 세트와 held-out을 물리적으로 분리합니다. 논문은 Evolution 이득이 불안정하고, held-out·실행 모델 전이가 제한적이라고 적습니다. 피드백에서 오른 점수를 최종 점수로 올리지 마십시오. DAKER 제출에서는 개발용 로그와 최종 평가 로그를 다른 폴더에 둡니다.

하드코딩된 스텝 한도처럼 실행기 전용 설정이 다른 모델에서 붕괴한 사례가 본문에 있습니다. 우리 하네스 점검표에 “스텝/출력 한도가 실행기 이름에 묶여 있는가”를 체크 항목으로 넣습니다. 토큰 비용 열을 능력 점수 옆에 항상 둡니다.

이 글이 아닌 것입니다

생성 하네스가 사람 설계 하네스를 전반적으로 이긴다는 주장이 아닙니다. 코드·검색은 뒤처지고, 글쓰기·ML 실험은 맞추거나 넘는다는 보고입니다.

Evolution이 안정적 자동 개선을 보장한다는 뜻이 아닙니다. 이득이 불안정하고 전이가 제한적이라고 적혀 있습니다.

Terminal-Bench 35.2%와 49.6%가 HarnessDev 생성 결과라는 혼동이 아닙니다. 동일 가중치·다른 하네스 동기화 예시입니다.

특정 대회 우승 공지가 아닙니다. 벤치마크와 방법 안내입니다.

Opus 4.8 overall 67.8이 모든 실행기에서 같다는 확장이 아닙니다. Self-Eval 집계입니다.

프로젝트 페이지의 표와 부록을 우리 실험 노트로 옮길 때는 생성기 모델 이름(Opus 4.8, GPT-5.5, Gemini 3.1 Pro, DeepSeek V4 Pro 등)을 우리 백본 이름과 섞지 않습니다. Creation 표의 SWE-Pro·Terminal-Bench·EQ-Bench3·BrowseComp·MLE-bench 열 구조만 복제합니다. 토큰 비용이 수백만 단위로 적힌 칸은 단위(M tokens)를 같이 씁니다.

DAKER 바이브코딩 해커톤에서는 “에이전트가 스스로 도구를 추가했다”는 문장 옆에, 추가된 도구 목록과 권한 범위를 붙입니다. DACON 코드 제출 과제라면 하네스 변경 diff와 평가 명령을 같은 커밋에 둡니다. 배포가 제출입니다. 올린 링크가 제출입니다.

오늘 할 일

첫째, 초록과 PDF를 직접 여십시오. arXiv:2609.01437와 pdf를 엽니다. 제출일 2026-09-01을 적습니다.

둘째, 프로젝트 페이지를 북마크하십시오. self-developing-agents.github.io를 저장합니다.

셋째, 우리 제출에 하네스 명세 칸을 만드십시오. 시드·도구·검증·스텝 한도를 표로 적습니다.

넷째, 모델 점수와 하네스 이름을 한 줄에 섞지 마십시오. 같은 모델·다른 하네스 비교 열을 둡니다.

다섯째, Evolution 피드백과 held-out을 분리하십시오. 개발에 본 과제를 최종 점수로 쓰지 않습니다.

여섯째, 실행 토큰과 실패 원인(하네스 결함 vs 모델 결함)을 기록하십시오.

일곱째, 명세와 로그를 공개 링크로 올리십시오. 배포가 제출입니다. 올린 링크가 제출입니다.

출처: arXiv:2609.01437 — HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness? (2026-09-01) · PDF · 코드/자료