에이전트 하네스를 설계하는 메타스킬로 고정된 모델의 성능을 올린다

무엇인가

에이전트의 성능은 추론 능력만으로 결정되지 않는다. 같은 모델이라도 어떤 도구와 메모리, 검증 절차, 작업 공간을 제공받느냐에 따라 결과가 달라진다. 이 논문은 테스트 시점의 AI-for-AI(AI4AI)를 다룬다. Builder 역할의 모델이 Target 역할의 모델을 위해 더 나은 실행 환경, 즉 하네스를 설계하는 것이 목표이며 두 모델의 가중치는 학습 내내 고정된다. 논문이 던지는 질문은 이것이다. Builder가 자신이 만든 하네스의 실행 결과를 어떻게 재사용 가능한 지식으로 바꿀 수 있는가.

어떻게 동작하나

저자들이 제안하는 단위는 메타스킬이다. 메타스킬 s = (when, provide, use)는 세 필드를 갖는다. when은 지원이 필요하다는 것을 알려주는 관찰 가능한 조건, provide는 환경이 공급해야 할 능력이나 자원, use는 Target이 그 지원을 어떻게 활용하며 어떤 판단은 여전히 자기 책임으로 남는지를 적는다. 학습은 빈 뱅크에서 시작한다. 개발셋의 각 태스크마다 Builder가 현재 뱅크와 중립 환경, 공개 인터페이스를 이용해 하네스를 만들고, Target이 그 안에서 실행해 공개 실행 기록과 벤치마크 점수를 남긴다. Builder는 그 증거를 검토해 기존 메타스킬을 고치거나, 새로운 지원 필요에 대한 메타스킬을 추가하거나, 아무것도 바꾸지 않는다. 배치마다 추가 또는 수정은 최대 하나로 제한되고, 그 변경은 반드시 해당 배치의 관찰 증거를 인용해야 한다. 개발셋을 두 번 도는 동안 이 과정이 반복된 뒤 뱅크는 동결된다.

무엇과 다른가

테스트 시점에는 동결된 뱅크가 새 태스크마다의 하네스 설계를 안내한다. Builder는 전체 뱅크를 받거나 BM25 검색기로 관련도가 양수인 메타스킬을 최대 두 개 받는다. 하네스는 일곱 가지 선택적 구성 요소군으로 이루어진다. 지시문, 메모리, 컨텍스트 구성, 조합 도구, 실행 제어, 검증과 복구, 작업 공간 준비다. Builder는 무엇을 메모리에 저장하고 언제 꺼내며 어떤 도구를 줄지 직접 결정하고, Target은 그 환경에서 추론하고 도구를 쓰되 최종 제출 책임은 계속 진다.

어떻게 쓰나

실험은 Harness-Bench(테스트 95개 태스크, 완료 오라클 점수)와 NewtonBench(테스트 292개 태스크, 상징 구조 정확도)에서 이뤄졌고, 각 벤치마크의 10%를 학습용으로 남겨두었다. Builder는 GPT-5.6-Sol, Target은 Gemini-3.6-Flash, Qwen3.8-Flash, GPT-OSS-120B다. 전체 뱅크 메타스킬을 쓴 Builder는 매크로 평균 65.31%를 기록해 스킬 없는 Builder보다 8.95%포인트, 같은 뱅크를 Target에게 직접 준 조건보다 12.02%포인트, Target이 독립적으로 학습한 구조화 스킬보다 10.93%포인트 높았다. 전체 뱅크는 6개 설정 중 5개에서 top-2 검색을 앞섰고 NewtonBench에서 평균 7.19%포인트 차이를 냈다. 스킬 없는 Builder 대비 향상은 NewtonBench에서 평균 10.96%포인트로 Harness-Bench의 6.95%포인트보다 컸다. 저자들은 실패 양상이 반복적으로 나타나는 벤치마크에서 축적된 경험이 더 유용하다고 해석한다.

전제와 한계

분석 결과는 몇 가지를 더 보여준다. 메타스킬 개선은 늦게 나타나고 단조롭지 않다. NewtonBench에서 첫 번째 개발 패스는 각 Target 점수를 1.1%포인트 미만으로 바꿨지만 두 번째 패스는 Gemini에 13.01%포인트, Qwen에 12.33%포인트를 더했다(0에서 2 패스까지 평균 10.42%포인트). 반면 Harness-Bench에서 Qwen은 첫 패스 정점에서 4.06%포인트 떨어졌다. 같은 모델이 Builder와 Target을 겸하는 자기개선 설정 3개에서는 스킬 없는 조건보다 평균 18.71%포인트, Target 직접 전달보다 14.14%포인트 향상됐다. 전이 실험에서는 Sol이 Qwen 실행에서 배운 뱅크가 Sol에게는 NewtonBench에서 13.36%포인트를 더했지만 Gemini-Pro로 옮기면 4.45%포인트 하락했고, Harness-Bench에서는 2.72%포인트 상승했다. 모든 신뢰구간이 0을 포함해 전이 이득은 불확실하다. 수신자 Builder가 직접 학습한 뱅크는 수입 뱅크보다 Harness-Bench에서 3.69%포인트, NewtonBench에서 9.93%포인트 좋았다. 하네스 구성 요소 제거 실험에서는 실행 제어기를 빼면 Gemini 13.36, Qwen 4.79, GPT-OSS 1.03%포인트가 떨어졌고, 메모리와 컨텍스트는 Gemini와 Qwen에 작은 양의 효과, GPT-OSS에 음의 효과를 보였지만 세 신뢰구간 모두 0을 포함했다. 결과 전이를 보면 NewtonBench에서 유효 제출이 없는 경우가 394건에서 254건으로 35.5% 줄고 정답 발견이 439건에서 535건으로 21.9% 늘었으며, 무효에서 정답으로의 회복이 145건, 퇴행이 46건이었다. 유효하지만 틀린 제출도 43건에서 87건으로 늘어, 완주가 정답을 보장하지는 않는다는 점이 드러난다.

개발자 관점에서 이 논문의 실용적 메시지는 프롬프트를 잘 쓰는 것과 환경을 잘 설계하는 것이 다른 축이라는 점이다. 같은 지식을 Target에게 직접 읽히는 것보다 Builder가 그것을 메모리, 도구, 검증 로직, 제어 흐름으로 구현해줄 때 성능이 더 올랐다는 결과는 에이전트 파이프라인에서 상태 관리와 실행 제어를 어디에 둘지 결정하는 근거가 된다. 다만 전이 실험이 보여주듯 메타스킬의 이득은 구현 방식에 의존하므로, 다른 모델이나 다른 Builder로 옮길 때는 자신의 실행 피드백으로 다시 다듬는 절차를 두는 편이 안전하다.

저자들이 밝힌 한계도 분명하다. 실험은 하나의 주 Builder, 두 개의 벤치마크, 태스크와 조건당 한 번의 실행으로 이뤄졌으므로 더 다양한 Builder와 태스크에서의 적용 가능성은 검증되지 않았다. 또한 하네스 구축 비용 대비 성능 이득은 평가하지 않았고, 예산 C_x는 Target 실행만 포함하며 Builder 연산은 제외한다. 윤리 진술에서는 생성된 도구와 제어기가 의도치 않은 행동을 가능하게 할 수 있으므로 벤치마크 밖 적용에는 권한 제한, 생성 구성 요소 검증, 사람의 감독이 필요하다고 적고 있다.