도구·스킬·에이전트가 늘 때 기존 능력이 유지되는지 잽니다 | DAKER 커뮤니티

2026년 9월 3일 EVOHARNESSBENCH 논문이 arXiv에 공개되었습니다. 현대 LLM 에이전트는 도구·재사용 스킬·전문 에이전트로 이뤄진 하네스 위에서 보고 행동합니다. 실제로는 이 하네스가 계속 늘어납니다. 기존 연속 학습 벤치가 과제 스트림의 비정상성을 두고 하네스는 고정했다면, 이 벤치는 비정상성을 외부에서 공급되는 하네스 자체에 둡니다. 축은 도구·스킬·에이전트 세 가지입니다. 검증기 기반 벤치에서 결정적으로 만든 멀티스테이지 하네스 스트림이 17개이고, 과제는 802개, 도구 520개, 스킬 42개, 에이전트 62개라고 적습니다. 평가 설정은 두 가지입니다. deployment evaluation은 하네스가 커질 때 이전에 가능했던 능력이 남는지 봅니다. self-evolving adaptation evaluation은 새 능력이 들어와도 쌓아 둔 경험이 쓸모 있는지 봅니다. 결과로 세 가지 빈틈을 보고합니다. 첫째, 하네스 확장만으로도 이전에 풀었던 과제 성능이 떨어지는 harness-induced forgetting이 있습니다. 둘째, 자기 진화 적응의 이득이 단계·축·환경마다 일정하지 않습니다. 셋째, 유지(retention)와 적응(adaptation)이 서로 다른 방향으로 갈 수 있습니다. 초록에 코드 URL은 없습니다. 오늘 팀은 하네스 버전과 과제 점수를 같은 표에 둡니다.

논문은 2026-09-03 arXiv에 올라왔습니다. 초록은 arXiv:2609.04280에서 확인할 수 있습니다. 영문 제목은 EVOHARNESSBENCH: Can Your Agents Keep Pace with an Evolving Harness?입니다. 저자는 Zixuan Ke, Vaidehi Patil, Haizhou Shi, Yang Li, Ye Liu, Sarath Shekkizhar, Anurag Koul, Jiayu Wang, Xuan Phi Nguyen, Semih Yavuz, Mohit Bansal, Shafiq Joty입니다. PDF는 같은 번호의 pdf입니다. 오늘 본문은 초록에서 확인한 범위만 옮깁니다.

과제 스트림이 아니라 하네스가 바뀝니다

에이전트는 도구, 재사용 스킬, 전문 에이전트로 된 하네스를 통해 관찰하고 행동합니다. 실무에서는 새 능력이 붙을 때마다 하네스가 커집니다. 기존 연속 학습 벤치는 보통 시간이 지나며 바뀌는 쪽을 과제 스트림에 두고 하네스는 고정합니다. EVOHARNESSBENCH는 그 비정상성을 외부 공급 하네스에 둡니다.

축은 tools, skills, agents입니다. 검증기 기반 벤치에서 결정적으로 구성한 멀티스테이지 하네스 스트림이 17개입니다. 과제 802개, 도구 520개, 스킬 42개, 에이전트 62개를 포함한다고 적습니다. 세부 과제 이름 목록은 초록에 없으므로 쓰지 않습니다.

DAKER에서 에이전트 하네스에 도구를 추가할 때마다, 이전 과제 회귀 테스트를 같은 주기에 돌리는지를 체크리스트에 넣습니다.

유지 평가와 적응 평가를 나눕니다

deployment evaluation은 하네스가 확장될 때 이전에 접근 가능했던 능력이 남는지 분리해 봅니다. self-evolving adaptation evaluation은 새 능력이 들어와도 쌓인 경험이 계속 유용한지 시험합니다. 두 설정이 하네스 진화의 중심 과제에 대응한다고 적습니다.

결과에서 빈틈이 세 가지입니다. 하네스 확장만으로도 이전에 해결한 과제 성능이 떨어지는 harness-induced forgetting이 있습니다. 자기 진화 적응의 이득은 하네스 진화 단계, 능력 축, 환경에 따라 일정하지 않습니다. 이전 능력을 지키는 일과 새 능력에 적응하는 일이 서로 다른 방향으로 갈 수 있다고 적습니다. 지키면 적응이 자동으로 좋아지지는 않고, 그 반대도 마찬가지입니다.

해커톤 README에는 “스트림 17 / 과제 802 / 도구 520 / 스킬 42 / 에이전트 62”와 “forgetting·adaptation·retention 방향 불일치”만 한 줄에 고정합니다. 배포가 제출입니다. 올린 링크가 제출입니다.

빌더 팀에 옮기는 점검

팀이 오늘 할 일은 하네스 변경 로그에 도구·스킬·에이전트 추가를 버전으로 남기는 것입니다. 버전마다 이전 과제 세트 점수를 다시 측정합니다. 새 도구를 넣은 직후 점수가 떨어지면 forgetting 칸에 원인을 적습니다.

적응 실험을 할 때는 축적 경험 저장 위치와 새 능력 도입 시점을 표로 둡니다. retention 지표와 adaptation 지표를 한 점수로 합치지 마십시오. Controller와 Worker를 나누면, 하네스 매니페스트와 과제 러너를 한 프롬프트에 섞지 않습니다.

공유 환경에서는 도구 등록 권한과 스킬 파일을 커밋된 매니페스트로만 바꿉니다. API 키를 공개 저장소에 넣지 않습니다. 초록에 없는 코드 URL을 만들지 마십시오.

Mohit Bansal·Shafiq Joty 등이 저자에 포함되어 있으나, 그 사실만으로 점수를 과장하지 않습니다. 숫자는 초록에 나온 구성 규모와 정성 결론만 옮깁니다.

하네스 진화를 제출 문서로 옮기는 방법

EVOHARNESSBENCH가 강조하는 점은 과제만 바꾸는 연속 학습이 아니라, 하네스 자체가 바뀌는 설정입니다. 팀 문서에도 같은 구조를 둡니다. 하네스 버전, deployment 점수, adaptation 점수, forgetting 사례를 절로 나눕니다.

17개 스트림과 802개 과제를 인용할 때는 도구 520·스킬 42·에이전트 62를 같이 적습니다. forgetting을 보고할 때는 “하네스 확장만으로도”라는 조건을 붙입니다. retention과 adaptation이 어긋난 사례를 우리 내부 로그에서 찾을 때는 초록 수치를 우리 실측처럼 쓰지 않습니다.

데모 페이지에는 하네스 타임라인을 크게 두고, 바로 옆에 이전 과제 회귀 표를 둡니다. 없는 다운로드 URL을 만들지 마십시오.

회고에는 “유지”와 “적응”을 서로 다른 항목에 적습니다. 한 항목에 섞으면 재현이 어렵습니다.

하네스 변경을 릴리스 노트처럼 관리합니다

도구 520·스킬 42·에이전트 62라는 규모는, 한 번에 전부 넣는 실험이 아니라 스트림으로 늘어나는 설정을 전제로 합니다. 팀도 하네스 변경을 주간 릴리스 노트처럼 적습니다. 이번 주에 추가된 도구 이름, 제거된 스킬, 새로 붙인 전문 에이전트를 날짜와 함께 남깁니다.

deployment evaluation에 해당하는 내부 절차는 “하네스 버전 올린 뒤 이전 스모크 세트 재실행”입니다. adaptation evaluation에 해당하는 절차는 “새 도구를 쓰는 신규 과제만 따로 측정”입니다. 두 점수를 평균 내어 하나의 성공률로 발표하지 마십시오.

제출 전에 forgetting이 관측된 과제 ID를 목록으로 두고, 하네스 diff와 나란히 첨부합니다. 초록의 정성 결론을 우리 장애 원인처럼 단정하지 않습니다.

이 글이 아닌 것입니다

모든 하네스 확장이 반드시 forgetting을 낸다는 보증이 아닙니다. 벤치에서 관측된 빈틈을 옮깁니다.

세부 리더보드 점수를 이 글이 확정한다는 뜻이 아닙니다. 초록에 없는 항목은 쓰지 않습니다.

코드 저장소를 이 글이 확정한다는 뜻이 아닙니다. 초록에 URL이 없습니다.

DACON·DAKER 공식 우승 공지가 아닙니다. 빌더 점검 안내입니다.

오늘 할 일

첫째, 초록과 PDF를 직접 여십시오. arXiv:2609.04280와 pdf를 같은 탭에 둡니다.

둘째, 하네스 매니페스트에 버전을 붙이십시오. 도구·스킬·에이전트 추가를 기록합니다.

셋째, 버전마다 이전 과제 회귀를 돌리십시오. forgetting 칸을 만듭니다.

넷째, retention과 adaptation 지표를 분리하십시오. 한 점수로 합치지 않습니다.

다섯째, 스트림·과제·도구·스킬·에이전트 규모를 인용 조건과 같이 적으십시오. 17·802·520·42·62입니다.

여섯째, 자기 진화 적응 이득이 들쭉날쭉한지 단계·축별로 보십시오. 평균 하나만 남기지 않습니다.

일곱째, 데모와 매니페스트를 공개 주소로 올리십시오. 배포가 제출입니다. 올린 링크가 제출입니다.

출처: arXiv:2609.04280 — EVOHARNESSBENCH: Can Your Agents Keep Pace with an Evolving Harness? (2026-09-03) · PDF