HarnessEngineeringLab

주요 내용

• 진행 방식
  • Lab마다 baseline·가설·기각 조건을 정하고, 같은 task·model·budget으로 변경 전후를 측정해 기록
  • 같은 측정 절차로 Claude Code 같은 production 하네스도 함께 측정해 비교
  • 진행에는 주로 DeepSeek API를 사용
• 구현 범위: agent loop, 편집·검색 tool, context 관리(spill·compaction), 권한 게이트와 hook, sandbox(macOS Seatbelt), session, subagent와 병렬 실행, 평가(pass@k·pass^k)

구조

하네스는 model이 볼 context를 구성하고, model이 요청한 tool을 권한 게이트와 sandbox 안에서 실행해 결과를 돌려주는 loop를 반복합니다.

model 행동 실험

1. ① 환경 정보

   관측

   환경 정보 없이 실행하면 model은 which로 쓸 수 있는 CLI tool을 확인하고, ls -la 출력을 보고 macOS로 추측했으며, GNU식 sed -i를 쓰다 실패한 뒤에야 BSD sed임을 알아챔

   예측

   OS·shell 정보를 시스템 프롬프트로 주면, 환경을 알아내려는 tool 호출과 실패 후 재시도가 줄어들 것

   결과

   which 확인, OS 차이로 실패한 sed -i 재시도, OS를 추측하는 reasoning이 모두 사라짐. 결과의 정확성은 그대로

2. ② 전용 편집 tool

   관측

   bash만 있을 때 model은 bash 안에서 python으로 파일을 고쳤고, 고치기 전에 /tmp에 백업을 만들며 작업 디렉터리 밖에 접근함

   예측

   전용 편집 tool을 주면 model이 bash 대신 이를 골라, 작업 디렉터리 밖에 접근하지 않고 하네스가 제어할 수 있는 범위 안에서 파일을 고칠 것

   결과

   전용 tool을 먼저 고르는 경향을 확인함. 한 줄 수정에는 search_replace(6번 중 5번), 새 파일에는 write_file(4번 중 4번)을 골랐고, 작업 디렉터리 밖 접근은 6번 중 4번에서 1번으로 줄어듦. bash가 함께 있는 한 밖 접근은 남음

3. ③ 지침에는 강제성이 없어 권한 게이트가 필요함

   관측

   HEL.md에 적은 규칙은 model이 지켰지만 하네스가 강제하지는 않음. bash와 write_file도 작업 범위를 검사하지 않아, 지침을 어기는 호출을 막을 장치가 없음

   예측

   tool이 거절되면 지침대로 파일을 그대로 두고 거절 사실을 보고할 것

   결과

   search_replace가 거절되자 write_file로 같은 변경을 다시 요청함. 지침만으로는 막지 못했고, 실행 직전의 권한 게이트가 두 요청을 모두 차단해 파일은 그대로 남음

4. ④ compaction

   관측

   매 호출마다 대화 전체를 다시 보내서, tool 호출이 늘수록 입력 token이 대화 길이에 따라 커짐. 오래된 대화를 줄여야 하지만, 요약으로 앞부분을 바꾸면 앞부분이 같을 때만 재사용되는 provider cache가 깨짐

   예측

   기준을 넘으면 오래된 구간은 model이 쓴 요약으로, 최근 구간은 원문으로 남기면 압축 직후 한 번 cache miss가 난 뒤 다시 오르고, 앞에서 읽은 내용으로 작업을 이어 갈 것

   결과

   한 세션에 지시 6개를 보내고 3번째 지시 뒤에 압축을 일으킴. 압축 직후 cache hit는 14~15%로 떨어졌다가 다음 요청에서 89~94%로 회복했고, 마지막 답은 세 번 모두 정답. 요약 한 번의 출력은 480~768 token이었고, 요약에 시스템 프롬프트의 작업 경로·shell 정보가 다시 적혀 중복됨

5. ⑤ subagent 역할

   관측

   작업 일부를 자식 agent에게 맡기면 부모 context는 덜 쌓이지만, 자식이 받는 내용은 전달 방식(전체 복사, tool 기록 제외, 위임 지시만)에 따라 다름. 전체 복사 방식의 자식은 부모의 시스템 프롬프트와 사용자 지시를 그대로 받음

   예측

   자식 agent는 위임받은 작업만 처리하고 최종 답을 부모에게 돌려줄 것

   결과

   역할을 알려 주지 않으면 복사된 사용자 지시의 "위임하라"를 보고 자신도 다시 위임하려 함. 지시에 역할을 넣자 사라짐. 세 전달 방식 모두 위임부터 부모의 확인까지 이어졌지만, 입력 token은 2.1~2.5배로 늘어 이 크기의 작업에서는 비용이 먼저 드러남

6. ⑥ harness 평가

   관측

   같은 system message로 다시 실행해도 fallback command를 붙이는 빈도가 3번에서 1번으로 바뀌는 등 결과가 달라졌지만, evals는 반복 실행의 평균만 집계함. 판정 규칙은 exit code가 0이 아니면 모두 실패로 기록해, 차이를 찾아 exit 1을 돌려준 diff도 실패로 집계됨

   예측

   pass@k와 pass^k를 함께 집계하고 실행 기록으로 실패를 분류하면, 하네스를 어떤 기준으로 고칠지 판단할 수 있을 것

   결과

   report에 task별 pass@k·pass^k와 실패 종류 다섯 가지별 수를 보여 주게 됨. 다만 실패 종류 자동 판정 규칙은 처음 보는 사례 2건을 모두 틀려, 판정이 아니라 기록을 읽을 대상을 고르는 참고 분류로 둠. 기록에 무엇이 남는지가 평가할 수 있는 범위를 정한다는 것도 확인함

관련 글

• [HEL] Harness: model의 결과를 믿을 수 있게 만드는 구조

  2026년 10월 7일

  harness를 밑바닥부터 만들어 본 경험을 바탕으로 한 회고입니다.