행동별 검증으로 에이전트 하네스를 진화시킵니다 | DAKER 커뮤니티

2026년 8월 27일 Jinghan Xu 연구팀이 행동에 맞춰 검증하는 에이전트 하네스 진화 프레임워크 HarnessLens를 arXiv에 공개했습니다. 에이전트 하네스는 언어 모델 에이전트가 지시, 도구, 런타임 구성 요소를 쓰는 방식을 정합니다. 하네스를 바꾸려면 검증 비용이 큽니다. 기존 propose-and-verify는 후보마다 고정 과제 집합 전체를 돌려, 관련 없는 행동에 롤아웃을 낭비하고, 합산 점수가 특정 퇴보를 가립니다. HarnessLens는 예산 인식형으로 과제 공간과 사용자 설정 구성 요소를 같이 탐색합니다.

논문은 2026년 8월 27일 arXiv에 올라왔습니다. 초록은 arXiv:2608.27311에서 확인할 수 있습니다. 저자는 Jinghan Xu, Yikai Zhang, Aili Chen, Weiyuan Li, Jiaqing Liang, Deqing Yang입니다. PDF는 같은 번호의 pdf입니다. 코드는 https://github.com/jhxu5214/HarnessLens에 공개되어 있습니다. 오늘 본문은 초록이 적은 숫자와 범위만 옮깁니다.

하네스 진화는 검증 예산이 병목입니다

에이전트 하네스는 지시문, 도구 목록, 런타임 구성이 맞물린 운영 층입니다. 모델 가중치를 바꾸지 않아도 하네스만으로 행동이 달라집니다. 문제는 후보 하네스를 믿을 만큼 검증하려면 롤아웃이 많이 필요하다는 점입니다. 고정 과제 집합에 모든 후보를 돌리면, 이번 수정과 무관한 행동에도 예산이 씁니다.

합산 점수는 더 위험합니다. 평균이 조금 올라도 특정 행동이 퇴보하면, 해커톤 제출에서는 그 퇴보가 치명적입니다. 초록은 기존 propose-and-verify가 관련 없는 행동에 롤아웃을 낭비하고, 합산이 특정 퇴보를 가린다고 적습니다. HarnessLens는 이 두 실패를 같이 겨냥합니다.

DACON 코드 에이전트나 DAKER 해커톤처럼 상호작용 예산이 짧은 자리에서는, “후보 열 개를 전부 전체 벤치에 돌리기”가 불가능합니다. 오늘 팀이 가져갈 한 줄은 이것입니다. 후보마다 전체 과제를 돌리지 말고, 행동과 관련된 과제만 골라 검증하십시오.

행동 관련 과제만 골라 검증합니다

HarnessLens는 예산 인식형 자동화 하네스 진화 프레임워크입니다. 과제 공간과 사용자 설정 가능 구성 요소를 함께 탐색합니다. 실행 궤적에서 후보 수정을 끌어내고, 각 후보를 행동 관련 과제에서만 선택적으로 검증합니다. 검증 앞에는 attributable-evidence gate, 곧 귀속 가능한 근거 게이트를 둡니다.

궤적에서 수정을 뽑으면, “왜 이 지시문을 바꿨는지”가 로그에 남습니다. 근거 없이 프롬프트만 고치면 다음 라운드에서 같은 실패가 반복됩니다. 게이트는 그 근거가 검증 과제 선택과 연결되게 합니다. 초록이 강조한 명시적 attribution이 여기 있습니다.

빌더 팀에 옮기면 세 줄입니다. 첫째, 하네스 구성 요소를 사용자 설정 가능 목록으로 적습니다. 둘째, 실패 궤적에서 수정 후보를 뽑을 때 관련 행동 태그를 붙입니다. 셋째, 그 태그에 묶인 과제만 검증 큐에 넣습니다. 전체 벤치를 기본값으로 두지 않습니다.

세 하네스·네 벤치에서 예산 대비 이득

초록은 세 가지 에이전트 하네스와 네 가지 벤치에서, HarnessLens가 평균 held-out 성능을 7.6–13.6% 개선하면서도 경쟁 베이스라인보다 평가 예산을 크게 덜 쓴다고 적습니다. 숫자는 이 구간만 옮깁니다. 벤치 이름을 지어내지 않습니다. 개별 벤치 점수를 만들지 않습니다.

해커톤 운영으로 읽으면, 성능만 보는 표와 예산만 보는 표를 분리하라는 뜻입니다. held-out이 올라도 롤아웃이 폭증하면 다음 제출에 쓸 예산이 없습니다. 반대로 예산을 아끼려고 검증을 비우면 퇴보가 숨습니다. HarnessLens가 보여 주는 방향은 행동 인식 검증과 명시적 attribution으로 둘을 같이 잡는 것입니다.

팀 README에는 “7.6–13.6% held-out, 예산은 베이스라인보다 적음”이라는 초록 문장과, 우리 과제에서 쓴 롤아웃 횟수를 나란히 적습니다. 우리 숫자를 초록 숫자로 바꾸어 쓰지 않습니다. 초록 숫자와 우리 측정은 표의 다른 행입니다.

합산 점수가 가리는 퇴보를 드러냅니다

고정 과제 집합의 합산은 편하지만, 특정 행동 퇴보를 가립니다. 행동별 검증은 그 퇴보를 과제 선택 단계에서 드러냅니다. 후보 A가 도구 호출 행동을 고치면, 도구 관련 과제만 먼저 봅니다. 후보 B가 지시문 충돌을 고치면, 지시 충돌 과제만 봅니다. 관련 없는 과제에 예산을 쓰지 않습니다.

운영 규칙으로 옮기면 네 줄입니다. 실패 궤적에 행동 태그를 붙입니다. 태그별 과제 부분집합을 저장소에 둡니다. 후보 검증은 그 부분집합으로 시작합니다. held-out 전체는 후보가 게이트를 통과한 뒤에만 돌립니다. 이 순서를 바꾸면 다시 예산 낭비가 납니다.

사람 리뷰도 같은 태그를 봅니다. “평균이 올랐다”만 보고 머지하지 마십시오. 행동 태그별 승패를 한 페이지에 두고, 퇴보가 있는 태그는 머지를 보류합니다. DAKER처럼 여러 팀이 같은 에이전트 스택을 돌리는 자리에서는, 태그 사전을 공유하면 리뷰가 빨라집니다.

공개 코드로 게이트를 재현합니다

코드가 https://github.com/jhxu5214/HarnessLens 에 공개되어 있으므로, 팀은 오늘 저장소를 북마크하고 우리 하네스 스키마와의 차이를 한 줄로 남길 수 있습니다. 차이만 적고 없는 점수를 붙이지 않습니다. 게이트와 행동 태그가 우리 로그 포맷과 맞는지를 먼저 확인합니다.

다른 팀의 하네스 진화 스크립트를 받을 때도 같은 절제를 유지합니다. 전체 벤치 루프만 있고 행동 태그가 없으면, 그것은 propose-and-verify의 예산 낭비 형태입니다. 태그·게이트·선택 검증이 같이 있어야 HarnessLens 방향을 따른 것입니다.

오늘 팀이 후보마다 고정 과제 전체를 돌리면, 내일 예산이 바닥나고 퇴보는 합산에 숨습니다. 그 순환을 끊는 일이 이 글을 읽는 이유입니다. 행동 관련 과제만 골라 검증하십시오.

attributable-evidence gate를 오늘 검증 큐 앞에 두십시오.

궤적에서 뽑은 수정을 공개 기록으로 남깁니다

실행 궤적에서 후보 수정을 끌어내는 단계는, 채팅 메모가 아니라 주소가 있는 파일이어야 합니다. 궤적 문장은 짧게 쓰되, 행동 태그·관련 과제·수정 요약·게이트 통과 여부를 빠뜨리지 마십시오. 네 항목이 한 페이지에 보이면 다음 검증 큐가 그 페이지를 밟을 수 있습니다.

해커톤 기간이 짧을수록 이 습관이 빨리 무너집니다. 밤에 본 퇴보를 아침에 다른 팀원이 못 읽으면, 그 신호는 없는 것과 같습니다. DAKER와 DACON처럼 여러 사람이 같은 에이전트를 만지는 자리에서는, 궤적 포맷을 저장소 루트에 두고 커밋 해시에 날짜를 남기십시오.

게이트를 통과하지 못한 후보도 버리지 말고 “보류”로 남깁니다. 보류 사유가 없으면 같은 후보가 다음날 다시 전체 벤치로 들어가 예산을 씁니다. 초록이 말한 예산 인식형은, 실패한 후보를 기록해 재검증을 줄이는 운영까지 포함합니다.

다른 팀의 하네스 패치를 받을 때도 궤적과 태그 없이 패치만 오면 거부합니다. 패치만 있는 변경은 합산 점수에 다시 숨습니다. 태그·게이트·선택 검증 로그가 같이 와야 리뷰가 끝납니다.

오늘 팀이 합산만 보고 머지하면, 내일 특정 행동 퇴보가 제출에서 드러납니다. 그 순환을 끊으려면 행동별 표를 머지 조건에 넣으십시오. held-out 전체는 게이트 통과 뒤에만 돌립니다.

상호작용 예산이 Constrained일수록, 관련 없는 과제에 롤아웃을 쓰는 비용이 커집니다. 초록은 제약된 상호작용 예산 아래에서 행동 인식 검증이 더 믿을 만하고 표본 효율적이라고 정리합니다. 우리 과제에서도 예산 한도를 README 첫 줄에 적으십시오.

샘플 효율을 해커톤 일정에 맞춥니다

초록은 제약된 상호작용 예산 아래에서 행동 인식 검증이 더 믿을 만하고 표본 효율적이라고 정리합니다. 해커톤 일정은 그 예산의 실제 형태입니다. 하루 롤아웃 한도를 README에 숫자로 적지 않으면, 후보 검증이 밤사이 예산을 모두 씁니다. 한도를 적은 뒤에는 행동 태그별 큐만 그 한도 안에서 돌리십시오.

held-out 7.6–13.6% 개선은 초록이 보고한 구간입니다. 우리 팀이 같은 구간에 들었다고 쓰지 않습니다. 대신 같은 날의 롤아웃 횟수와 held-out 승패를 한 표에 남겨, 예산 대비 이득을 우리 단위로 읽습니다. 경쟁 베이스라인보다 예산을 덜 쓴다는 문장도 초록 인용과 우리 측정을 행으로 나눕니다.

게이트가 거부한 후보를 다음날 전체 벤치로 올리는 우회는 금지합니다. 우회하면 행동별 검증의 의미가 사라집니다. 거부 사유를 고친 뒤에만 선택 검증을 다시 넣습니다. DAKER 팀 리뷰에서는 이 우회 여부를 체크리스트 항목으로 두십시오.

이 글이 아닌 것입니다

벤치 이름과 개별 점수표가 아닙니다. 초록은 세 하네스·네 벤치와 held-out 7.6–13.6%만 적습니다. 벤치 이름을 지어내거나 우리 대회 점수와 같다고 쓰지 않습니다.

모델 가중치 학습 방법이 아닙니다. 대상은 에이전트 하네스, 곧 지시·도구·런타임 구성입니다. “LoRA로 7% 올렸다”로 바꾸어 쓰지 않습니다.

검증을 생략하라는 처방이 아닙니다. 선택적 검증과 근거 게이트로 예산을 줄입니다. 검증 자체를 끄라는 운영이 아닙니다.

특정 회사 제품 출시 공지가 아닙니다. 연구 논문과 공개 코드 안내입니다. 에이전트 플랫폼이 오늘 이 기능을 켰다고 적힌 글이 아닙니다.

합산 점수가 항상 틀리다는 선언도 아닙니다. 합산이 특정 퇴보를 가릴 수 있으니 행동별 검증을 앞에 두라는 뜻입니다. held-out 전체를 버리라는 뜻이 아닙니다.

오늘 할 일

첫째, 초록과 PDF를 직접 여십시오. arXiv:2608.27311와 pdf를 같은 탭에 둡니다. 저자 여섯 이름과 제출일 2026-08-27을 메모 첫 줄에 적습니다.

둘째, 우리 에이전트 하네스 구성 요소 목록을 쓰십시오. 지시문, 도구, 런타임 설정을 사용자 설정 가능 항목으로 나눕니다. DAKER 또는 DACON 과제 하나에 맞춥니다.

셋째, 실패 궤적에 행동 태그를 붙이는 포맷을 정하십시오. 태그, 관련 과제 ID, 수정 후보를 한 표에 남깁니다. 채팅에만 남긴 문장은 다음 라운드에 사라집니다.

넷째, 후보 검증 큐를 행동 관련 과제 부분집합으로 바꾸십시오. 전체 고정 과제 집합을 기본값에서 뺍니다. 게이트 통과 뒤에만 held-out 전체를 돌립니다.

다섯째, 롤아웃 예산과 held-out 변화를 같은 표에 기록하십시오. 초록의 7.6–13.6%와 우리 측정을 같은 칸에 섞지 않습니다. 행을 분리합니다.

여섯째, 공개 코드를 북마크하십시오. https://github.com/jhxu5214/HarnessLens 와 우리 스키마 차이를 한 줄로 남깁니다.

일곱째, 태그 사전·게이트 규칙·검증 표를 공개 링크로 올리십시오. DAKER와 DACON에는 빌더와 대회 기록이 쌓여 있습니다. 배포가 제출입니다. 올린 링크가 제출입니다.

출처: arXiv:2608.27311 — HarnessLens (2026-08-27) · PDF · Code