에이전트 하니스란? 연구, 오픈 소스 프로젝트 및 업계 사례

두 에이전트가 정확히 같은 모델을 사용해도 같은 벤치마크에서 점수가 크게 다를 수 있습니다. OpenAI가 이를 직접 측정했습니다. SWE-bench Lite에서 GPT-4는 한 하니스에서는 2.7%, 다른 하니스에서는 28.3%를 기록했습니다. 하니스만으로 10배의 격차가 난 것입니다. 업계의 관심이 "어떤 모델이 가장 똑똑한가"에서 "어떤 에이전트가 실제로 작업을 완료하는가"로 옮겨가면서, 에이전트 하니스는 신뢰성이 좌우되는 계층이 되었습니다. 계속 읽으며 에이전트 하니스의 정의, 최신 논문과 벤치마크가 말하는 하니스 설계, 주목할 만한 오픈 소스 하니스, 주요 AI 연구소가 자체 하니스를 설계하는 방식을 알아보세요. 여기에는 Moonshot AI가 자체 하니스와 함께 사용하는 오픈웨이트 모델 Kimi K3.1 Pro도 포함됩니다.

에이전트 하니스는 대규모 언어 모델이 실제 환경에서 에이전트로 작동하도록 하는 주변 인프라입니다. 모델이 token을 생성한다면, 하니스는 나머지 모든 일을 담당합니다. 매 단계에서 프롬프트를 구성하고, 사용할 수 있는 도구와 호출 방식을 정의하며, 샌드박스 또는 터미널에서 작업을 실행하고, 관찰 결과를 모델에 다시 전달하며, 단계 및 비용 제한을 적용하고, 평가나 디버깅을 위해 전체 궤적을 기록합니다.

이 용어는 평가 분야에서 비롯되었습니다. "테스트 하니스"는 통제된 조건에서 시스템을 실행하는 장치를 뜻합니다. 에이전트 AI에서는 이 개념이 프로덕션으로 확장되었습니다. 하니스는 SWE-bench 또는 Terminal-Bench처럼 에이전트를 측정하는 장치이면서, SWE-agent, OpenHands 또는 Claude Code처럼 에이전트를 실행하는 하니스이기도 합니다.

Anthropic의 SWE-bench 연구는 이를 명확히 설명합니다. 이 벤치마크는 "AI 모델 하나만을 분리해 평가하는 것이 아니라 전체 '에이전트' 시스템을 평가"하며, 에이전트는 "AI 모델과 이를 둘러싼 소프트웨어 기반 구조의 결합"입니다. 업그레이드된 Claude 3.5 Sonnet은 복잡한 프레임워크가 아니라 프롬프트 하나와 범용 도구 두 개(Bash 도구와 Edit 도구)로 구성된 미니멀 하니스로 SWE-bench Verified에서 49%를 달성했습니다.

수년간 리더보드의 성과 향상은 모델 규모 덕분으로 여겨졌습니다. 최근 연구는 두 방향에서 이 가정을 뒤집었습니다.

첫째, "적을수록 낫다"는 결과입니다. 2025년 7월 SWE-bench 팀은 bash 외의 도구가 없고, 완전히 선형적인 메시지 기록을 사용하며, 모든 작업을 독립적인 subprocess.run 호출로 실행하는 약 100줄의 Python 하니스 mini-SWE-agent를 공개했습니다. 이 하니스는 훨씬 더 복잡한 프레임워크와 경쟁할 수 있는 벤치마크 점수를 기록했습니다(아래 연구 섹션에서 다룹니다). 이 결과가 주는 도발적인 교훈은 모델이 충분히 강력하다면 매우 단순하고 예측 가능한 하니스가 무거운 하니스보다 더 뛰어날 수 있다는 것입니다. 이미 Meta, NVIDIA, IBM, Princeton, Stanford가 기준선으로 사용하고 있습니다.

둘째, "많을수록 오히려 적다"는 결과입니다. 도구 출력이 잡음으로 가득하거나, 루프가 무제한으로 반복되거나, 오류 복구가 부실한 하니스는 최첨단 모델조차 평범해 보이게 만들 수 있습니다. OpenAI는 SWE-bench의 결함 있는 작업을 정리하자(자세한 내용은 아래 OpenAI 섹션 참조) 측정된 모델 성능이 두 배 이상 향상된다는 사실을 확인했습니다.

이 때문에 하니스 엔지니어링은 독자적인 분야로 자리 잡았습니다. 하니스는 다음을 결정합니다.

• 모델이 보는 것: 프롬프트 구조, 도구 스키마, 컨텍스트 창에 포함되는 환경 상태와 이력의 양.

• 모델이 할 수 있는 것: 사용할 수 있는 도구(셸, 파일 편집기, 브라우저, 검색)와 실행 전 작업을 파싱하고 검증하는 방식.

• 실패 처리 방식: 재시도, 시간 초과, 창이 가득 찼을 때의 컨텍스트 압축, 그리고 정상적인 종료.

• 작업 측정 방식: 궤적 로깅, 채점, 비용 산정 — 이것이 없으면 평가도 개선 순환도 불가능합니다.

연구 벤치마크 장비이든 프로덕션 코딩 어시스턴트이든, 거의 모든 에이전트 하니스는 동일한 핵심 루프를 구현합니다.

1. 작업 접수: 이슈, 지시사항 또는 목표를 읽고 격리된 환경(보통 Docker 컨테이너 또는 VM 스냅샷)을 시작합니다.

2. 프롬프트 구성: 시스템 프롬프트, 도구 정의, 작업 설명, 그리고 작업과 관찰의 누적 이력을 결합합니다.

3. 작업 파싱: 모델의 출력을 bash 명령, 파일 편집, API 요청 같은 구체적인 도구 호출로 변환하고, 형식이 잘못된 작업은 거부합니다.

4. 실행 및 관찰: 환경에서 작업을 실행하고 stdout/stderr 또는 UI 상태를 캡처한 뒤, 컨텍스트 예산에 맞게 잘라냅니다.

5. 제어 흐름: 단계 제한, 비용 제한, 중지 조건을 적용하고, 사람에게 문의하거나 에피소드를 종료할 시점을 결정합니다.

6. 기록 및 채점: 전체 궤적을 저장하고 최종 상태를 평가합니다. 예를 들어 SWE-bench에서는 리포지토리의 테스트 모음을 실행합니다.

각 단계의 설계 선택은 누적되어 영향을 미칩니다. 잘라내기 전략만으로도 장기 작업의 점수가 눈에 띄게 달라질 수 있습니다. ამიტომ 진지한 팀은 하니스를 단순한 접착 코드가 아니라 버전 관리와 테스트가 가능한 소프트웨어로 다룹니다.

에이전트 하니스에 관한 학술 문헌은 어렵게 얻어낸 몇 가지 결론으로 수렴했습니다. 이 섹션에서는 모든 벤치마크를 나열하는 대신, 이 분야가 하니스를 진지하게 다루게 만든 연구 질문을 따라가 봅니다.

논문을 보기 전에 간단히 짚고 넘어가겠습니다. 벤치마크는 서로 다른 시스템을 같은 조건에서 비교할 수 있도록 설계한, 고정된 작업 집합과 채점 규칙입니다. 에이전트 평가에서 벤치마크는 세 가지 구성 요소로 이루어집니다. 작업 집합(실제 GitHub 이슈, 터미널 명령, 웹 작업), 실행 환경(Docker 컨테이너, 브라우저, 터미널), 채점기(테스트 모음, 상태 확인, 사람 검토)입니다. 하니스는 모델과 이 세 요소 사이에 위치하며, 모델의 역량이 점수에 드러날지를 결정하는 변수입니다.

점수가 실제로 어떻게 측정되는지는 헤드라인 수치보다 더 중요합니다. SWE-bench에서 에이전트는 코드 패치를 생성하고, 벤치마크는 두 가지 테스트 모음을 실행합니다. FAIL_TO_PASS(수정 전에는 실패했지만 이제 통과해야 하는 테스트)와 PASS_TO_PASS(수정 전에도 통과했으며 실패해서는 안 되는 테스트)입니다. 둘 다 통과해야만 작업이 해결된 것으로 집계됩니다. 따라서 테스트 실행이나 diff 생성 같은 하니스 기능은 선택적인 부가 기능이 아닙니다. 바로 여기서 점수를 얻거나 잃습니다.

벤치마크 점수를 읽는 세 가지 원칙:

1. 점수가 무엇을 감추는지 물어보세요. 공개 GitHub 데이터로 학습된 모델은 테스트 대상인 바로 그 이슈를 이미 봤을 수 있습니다. 데이터 오염은 실제 역량 향상 없이도 점수를 부풀릴 수 있습니다. 재현 가능한 환경과 홀드아웃 작업 집합이 그 해법입니다.

2. 굿하트의 법칙을 경계하세요: 측정 지표가 목표가 되는 순간, 더는 좋은 측정 지표가 아닙니다. 하나의 벤치마크에서 최고 점수를 내도록 조정된 하니스는 일반 역량이 아니라 벤치마크 특유의 요령을 학습하고 있을 수 있습니다. 그래서 진지한 팀은 하나 이상의 벤치마크로 평가합니다.

3. 모델뿐 아니라 하니스도 확인하세요. 이 섹션의 나머지 내용에서 보듯, 같은 모델도 지원 구조에 따라 2.7% 또는 28.3%의 점수를 낼 수 있습니다. 명시된 하니스가 없는 점수는 측정값이 아니라 일화에 불과합니다.

최초의 SWE-bench 논문("Can Language Models Resolve Real-World GitHub Issues?")은 이제 표준이 된 평가 방식을 도입했습니다. 모델에 실제 GitHub 이슈와 전체 리포지토리를 제공하고, 생성한 패치가 실패한 테스트를 통과하게 하는지 평가하는 방식입니다. 가장 많이 인용되는 결과는 흔히 잘못 해석됩니다. 당시 최고 모델이었던 Claude 2는 작업의 1.96%만 해결했습니다. 저자들은 이 벤치마크가 "전통적인 코드 생성을 훨씬 뛰어넘는 복잡한 추론"을 시험한다고 설명했습니다. 하지만 후속 연구는 격차의 상당 부분이 추론 능력이 아니라 리포지토리를 탐색하고, 테스트를 실행하고, 반복 작업할 수 있는 하니스의 부재에서 비롯됐음을 분명히 했습니다. 즉, SWE-bench는 모델만 측정한 것이 아니라 모델을 둘러싼 하니스가 빠진 조각임을 드러냈습니다.

SWE-agent 논문("Agent-Computer Interfaces Enable Automated Software Engineering")은 하니스 설계 분야의 출발점으로 여겨지는 문서입니다. 핵심 주장은 인터페이스 설계가 일차적 변수라는 것입니다. 저자들은 에이전트-컴퓨터 인터페이스(ACI)라는 용어를 도입하고, 린터로 보호되는 파일 편집기, 간결한 셸 피드백, 잘못된 명령에 대한 가드레일로 이루어진 목적 특화 인터페이스가 SWE-bench의 pass@1을 한 자릿수 초반에서 당시 최고 수준인 12.5%까지 높였음을 보였습니다. 이 논문의 지속적인 기여는 인간에게 IDE가 필요하듯, "LM 에이전트는 새로운 범주의 최종 사용자"이며 이들을 위한 소프트웨어가 필요하다는 주장입니다. 이후의 모든 하니스 논문은 이 결과를 인용합니다.

2024년의 두 논문은 하니스 연구를 코드 리포지토리에서 전체 컴퓨터 환경으로 확장했습니다. OSWorld는 Ubuntu, Windows, macOS 전반에서 웹 및 데스크톱 앱을 아우르는 369개 작업으로 구성된 최초의 확장 가능한 실제 컴퓨터 환경을 구축했습니다. 사람은 작업의 72.36%를 완료하는 반면 최고 모델은 12.24%만 완료한다는 대표 수치는 GUI 그라운딩(모델 출력을 올바른 클릭과 키 입력으로 변환하는 작업)을 지식 문제가 아닌 하니스 문제인 주된 실패 원인으로 지목했습니다. WebArena는 다른 접근을 취했습니다. 전자상거래, 포럼, GitLab, CMS를 포함하는 자체 호스팅 방식의 완전 재현 가능한 웹 환경에서 GPT-4는 인간의 78.24%에 비해 종단 간 성공률 14.41%에 그쳤습니다. 두 논문 모두 하니스 평가는 모델 출력의 패턴을 맞추는 방식이 아니라 실행 기반(환경의 최종 상태를 확인하는 방식)이어야 한다는 점을 확립했습니다.

Sierra의 τ-bench("A Benchmark for Tool-Agent-User Interaction in Real-World Domains")는 더 미묘한 점을 제시했다. 프로덕션 환경에서 하니스는 모델과 환경을 감싸는 데 그치지 않고 사용자도 매개한다. 이 벤치마크는 언어 모델 사용자와 도메인 API 및 정책 가이드라인을 갖춘 에이전트 간의 동적 대화를 시뮬레이션한 뒤, 최종 데이터베이스 상태를 평가한다. 핵심 지표인 pass^k(독립적인 k회 시행 전반의 성공)는 에이전트가 얼마나 일관성 없는지 드러냈다. GPT-4o는 단 한 번의 시행에서 과제의 50% 미만을 해결했고, 리테일 분야에서는 pass^8이 25% 아래로 떨어졌다. 하니스를 구축하는 이들이 얻어야 할 교훈은 신뢰성이 단일 실행의 속성이 아니라 분포적 속성이라는 점이다. 한 번 작동하는 하니스는 제대로 작동하는 하니스가 아니다.

METR의 "Measuring AI Ability to Complete Long Software Tasks"는 50% 과제 완료 시간 지평을 도입했다. 이는 모델이 50%의 신뢰도로 완료하는 과제의 길이로, 인간의 완료 시간으로 측정한다. 프런티어 모델은 2019년부터 2025년 사이 이 시간이 몇 분에서 약 한 시간으로 늘었으며, 약 7개월마다 두 배가 되었다. 하니스 엔지니어링에서 이는 지난 10년간 가장 중요한 발견이다. 2024년 모델을 제약하는 하니스는 2026년 모델에게는 불필요한 짐이 된다. Anthropic의 관점에 따르면 하니스의 모든 구성 요소에는 모델이 무엇을 할 수 없는지에 대한 가정이 담겨 있으며, 모델이 개선될수록 그 가정은 낡아진다.

원래 벤치마크는 이러한 교훈을 실천하는 생태계로 성장했다.

• SWE-bench Verified(OpenAI와 함께, 2024): 명세가 부족하거나 평가가 불공정한 과제를 제거한 500개 인스턴스의 인간 검토 하위 집합이다. 원래 풀의 68.3%가 제외되었고, 이로 인해 측정 점수는 두 배 이상 높아졌으며 기본 리더보드가 되었다.

• SWE-smith(2025): 모델이 에이전트 하니스에서 단순히 평가받는 데 그치지 않고 이를 위해 학습할 수 있도록 합성 학습 과제를 생성하는 파이프라인이다.

• mini-SWE-agent(2025): 현재 SWE-bench Verified에서 74%를 넘는 약 100줄짜리 하니스다. 모델이 충분히 강력하다면 선형 이력 기반의 최소한의 bash 전용 루프만으로도 충분함을 보여 주며, 커뮤니티의 기본 베이스라인으로 자리 잡고 있다.

• Terminal-Bench(Stanford × Laude, 2025): Harbor 프레임워크를 기반으로 한 터미널 과제 평가로, 하니스의 범위를 코드 편집을 넘어 시스템 관리로 확장한다.

• CodeClash(2025) 및 ProgramBench(2026): 목표 지향적 소프트웨어 제작과 처음부터 만드는 소프트웨어 제작을 다루며, 하니스의 범위를 단일 이슈 수정에서 개방형 개발로 확장한다.

이 모든 연구를 관통하는 흐름은 일관적이다. 하니스는 배관 설비가 아니라 연구 대상이다. 점수와 함께 하니스를 보고하고, 환경을 재현 가능하게 유지하며, 하니스를 점검할 수 없는 결과는 의심해야 한다.

대부분의 팀은 오픈 소스 하니스에서 시작한다. 아래 프로젝트들은 대규모 GitHub 커뮤니티(선두 프로젝트는 수만 개의 스타 보유)와 활발한 유지보수를 모두 갖추고 있다.

이들 중에서 선택할 때 커뮤니티의 경험칙은 다음과 같습니다. 작업을 표현할 수 있는 가장 단순한 하니스를 사용하고(mini-SWE-agent 철학), 측정된 실패가 요구할 때만 복잡성을 더하는 것입니다. DeepSeek Harness는 모든 계층을 교체 가능하게 만들고자 하는 팀을 위한 완전한 플러그인 기반 플랫폼으로, 이 스펙트럼의 반대편에 있습니다. 그러나 둘은 모델이 본 내용을 보여 주는 단일 정보 원천으로서 내구성 있는 추가 전용 세션 로그를 둔다는 공통된 원칙을 공유합니다.

최첨단 연구소들은 하니스 엔지니어링을 핵심 IP로 여기며, 그중 여러 곳이 자신들의 접근 방식을 이례적으로 자세히 공개했습니다.

Anthropic은 하니스 엔지니어링에 관한 가장 완전한 공개 기록을 내놓았으며, 효과적인 에이전트 구축하기 (2024), SWE-bench 하니스 게시물 (2024), 관리형 에이전트 (2026)에 걸쳐 상세히 소개된 아키텍처는 세 겹의 동심원 구조로 볼 수 있습니다.

실행 계층은 의도적으로 최소화되어 있습니다. 명령을 실행하는 Bash 도구와 파일을 확인하고 수정하는 Edit 도구가 전부입니다. 설계 노력은 이러한 도구의 오류를 방지하는 데 집중되었습니다. 절대 경로를 요구하고, 긴 출력은 잘라 내며, 고유한 문자열 일치가 있을 때만 수정 사항을 적용해 모델이 피할 수 있는 도구 오류에서 복구해야 하는 경우를 드물게 만듭니다.

세션 계층은 모델의 컨텍스트 윈도우 밖에 존재하는 내구성 있는 추가 전용 이벤트 로그입니다. 모든 작업과 관찰 결과가 이곳에 기록되며, 모델의 컨텍스트는 로그 자체가 아니라 그 로그를 투영한 것입니다. 이러한 분리 덕분에 실패한 하니스 프로세스를 재부팅해 작업 중간부터 재개할 수 있고, 하니스를 애완동물이 아닌 교체 가능한 "가축"처럼 다룰 수 있습니다.

오케스트레이션 계층 — Anthropic이 "메타 하니스"라고 부르는 것 — 은 명시적인 인터페이스를 통해 "두뇌"(모델과 그 루프)와 "손"(샌드박스와 도구)을 분리합니다. 두뇌가 더 이상 실행 컨테이너 내부에 있지 않으므로, 필요할 때 샌드박스를 프로비저닝하고 샌드박스가 절대 접근하지 않는 볼트에 자격 증명을 보관할 수 있습니다. 이들이 보고한 성과는 외형적인 것이 아니라 구조적입니다. 세션이 사용하지 않을 수도 있는 컨테이너를 더 이상 기다리지 않기 때문에 첫 token 생성까지 걸리는 p50 시간은 약 60%, p95는 90% 이상 감소했습니다.

이러한 발전 과정은 효과적인 에이전트 구축하기 (2024), SWE-bench 하니스 게시물 (2024), 관리형 에이전트 (2026)이라는 세 문서에서 확인할 수 있습니다.

OpenAI는 하니스에 깨끗한 작업이 필요하다는 이유로 SWE-bench 팀과 협력해 사람이 검증한 Verified 분할을 만들었습니다. 이들의 주석 캠페인(개발자 93명, 샘플 1,699개)에서는 원래 벤치마크 작업의 68.3%에 문제가 있는 것으로 나타났고, 이를 제거하자 측정된 성능이 두 배 이상 높아졌습니다. 같은 게시물에서는 하니스 선택만으로도 SWE-bench Lite에서 GPT-4의 성능이 2.7%에서 28.3%로 달라졌다고 언급하며, 평가 시 커뮤니티가 구축한 하니스의 발전을 고려해야 한다는 근거로 이 차이를 제시합니다.

오픈소스 측면에서 Codex CLI는 완전한 참조 하니스로 제공됩니다. 그 아키텍처는 이 섹션의 다른 시스템과 유사하게 계층화되어 있습니다. 핵심 에이전트 루프가 계획 수립과 도구 호출을 처리하고, 샌드박스 계층은 작업별로 구성 가능한 정책으로 실행을 격리하며, 세션 계층은 대화를 지속적으로 저장해 재개, 분기, 압축할 수 있게 합니다. 도구 계층은 로컬 셸 액세스와 MCP 기반 외부 도구를 모두 제공합니다. 단일 인터페이스를 하드코딩하는 대신, 같은 엔진을 세 가지 방식으로 노출합니다. 대화형 작업을 위한 터미널 UI, VS Code 같은 풍부한 클라이언트를 위한 JSON-RPC 앱 서버, 그리고 클라우드 샌드박스를 위한 원격 코드 실행 서비스입니다. 따라서 하니스는 로컬에서 실행하거나 프로그래밍 방식으로 구동할 수 있습니다. 이 설계는 연구 문헌이 권장하는 것과 같은 절충안을 따릅니다. 최소한의 루프, 강력한 샌드박스, 명시적인 컨텍스트 관리, 그리고 모델과 외부 세계 사이의 분명한 경계입니다.

Agent Development Kit (ADK)와 Agent2Agent (A2A) 프로토콜을 통해 Google은 하네스 계층을 제품화하고 있다. 2025년 4월 Atlassian, Salesforce, SAP, ServiceNow를 비롯한 50곳 이상의 기술 파트너와 함께 출시된 A2A는 에이전트가 역량을 알리고(JSON "에이전트 카드"를 통해), 장기 실행 작업을 관리하며, 아티팩트를 교환하고, UI 형식을 협상하는 방식을 표준화한다. 이로써 하네스는 맞춤형 접착제가 아니라 상호운용 가능한 인프라가 된다. A2A는 하네스의 도구 측면을 표준화하는 Anthropic의 Model Context Protocol (MCP)을 보완하도록 명시적으로 설계되었다.

Microsoft의 AutoGen과 Magentic-One은 오케스트레이터 에이전트가 사실과 진행 상황의 원장을 관리하는 하네스를 제공한다. 이는 단순한 하네스에서 발생하는 무한 루프를 막기 위해 공개된 설계다. Meta와 Hugging Face의 GAIA는 웹 탐색과 파일 처리가 필요한 실제 질문을 하네스가 평가하는 범용 어시스턴트 벤치마크를 만들었다. Hugging Face의 Open Agent Leaderboard는 비교 가능한 하네스 인식 순위 체계를 계속해서 발전시키고 있다.

DeepSeek Harness (dsh)는 메타 하네스 개념을 조합 가능한 형태로 구현한다. 아키텍처는 Cordis 프레임워크를 기반으로 하며, 핵심 주장은 하네스의 모든 부분이 교체 가능한 플러그인이라는 것이다. 여기에는 모델 어댑터, 도구 레지스트리, 세션 로그, 에이전트 루프 자체까지 포함된다.

이 설계는 세 가지 기본 요소에 기반한다. 첫째, 모델이 확인한 내용을 담는 단일 정보원인 영속 세션 로그다. 모델에 전달되는 모든 내용은 로그로부터 재구성할 수 있어야 하며, 이는 런타임 불변 조건으로 강제된다. 둘째, 역량 경계면이다. 에이전트와 외부 세계 사이의 교체 가능한 프로바이더 인터페이스로, 파일시스템 및 서브프로세스 프로바이더를 원격 샌드박스로 연결하면 하네스를 포크하지 않고도 Bash, 터미널, 언어 서버 접근을 함께 옮길 수 있다. 셋째, 명명된 확장 이벤트(agent/pre-step, tools/execute, agent/turn-stopping)를 갖춘 명시적인 턴/단계 수명 주기다. 이를 통해 플러그인은 핵심 코드를 수정하지 않고 루프를 가로채거나 재작성할 수 있다.

그 결과는 Anthropic의 메타 하네스를 오픈 소스로 구현한 사례에 가장 가깝다. 구조가 고정된 프레임워크가 아니라 설정만으로 교체할 수 있는 플러그인의 조합으로 이루어진 하네스다. 출시 후 첫 몇 달 만에 GitHub 스타 17만 개 이상을 얻은 것은 에이전트 하네스가 그 자체로 하나의 제품 범주가 되고 있음을 보여준다.

이들 모두에서 공통으로 나타나는 패턴은 간단하다. 루프는 단순하게 유지하고, 모든 것을 샌드박스에 격리하며, 모든 단계를 기록하고, 그것을 만든 하네스 없이 점수를 신뢰하지 않는 것이다.

지금까지 이 섹션에서 다룬 모든 것, 즉 최소 루프, 영속 세션 로그, 샌드박스 실행, 플러그인 아키텍처는 하나의 가정을 공유한다. 에이전트의 환경은 컴퓨터라는 가정이다. 터미널, 브라우저, 파일시스템, 리포지토리. 하네스는 에이전트가 그 기계를 안정적으로 조작할 수 있도록 존재한다.

그러나 앞서 살펴본 연구의 궤적은 다른 곳을 향한다. τ-bench는 사용자를 하네스 안에 포함했다. METR은 에이전트가 몇 분이 아닌 며칠에 걸친 업무를 맡는 모습을 보였다. OSWorld와 WebArena는 환경을 정돈된 리포지토리에서 복잡한 현실 세계로 옮겼다. 방향은 일관적이다. 에이전트가 코딩 도구에서 실제 업무 보조자로 이동하면서, 이들이 탐색해야 하는 환경은 더 이상 실리콘만이 아니다. 기대를 가진 사용자, 역사를 공유한 팀, 권한과 조직 지식을 갖춘 조직이 그 환경이다.

이 변화는 무엇보다 하네스의 컨텍스트 관리 하위 시스템에 영향을 미친다. 터미널 세션에는 한 명의 작업자와 제한된 이력이 있지만, 장기 업무에는 열 명의 이해관계자, 수개월간의 의사 결정, 그리고 계속 커지는 리포지토리가 있다. 파일시스템은 수동적이지만, 업무 관계는 암묵적 약속, 미완성된 생각, 지나가듯 내려진 선택이 이어지는 흐름이다. 이 모든 내용은 모델에 전달되기 전에 요약하거나 압축하거나 버려야 하며, 그러한 결정 하나하나가 에이전트가 작업에 필요한 무언가를 잃는 지점이 된다.

하네스는 압축할 수 있지만, 무한정 압축할 수는 없다. 그래서 컨텍스트 윈도의 크기는 모델 사양이 아니라 하네스 설계 매개변수가 되었다.

Moonshot AI의 하네스 포트폴리오는 이 글 앞부분에서 정의한 구조를 하나의 관리형 스택에 적용한다. 에이전트 × 컴퓨터 문제에서 이 하네스들은 표준 루프를 확장한다. Kimi Browser Extension은 무균 상태의 샌드박스 대신 Chrome DevTools Protocol을 통해 실제 브라우저 세션을 조작하고, 행동 전 확인 경계면은 파일시스템 수준에서 동의를 강제하며, Agent Swarm은 장기 작업을 위해 오케스트레이션을 300개의 하위 에이전트까지 확장한다.

그 루프를 구동하는 것은 Kimi K3.1 Pro다. K3.1 시리즈의 첫 모델이자 현재까지 Moonshot AI가 내놓은 가장 성능이 뛰어난 3T급 오픈 웨이트 모델로, 1,048,576-token 컨텍스트 윈도를 제공한다. 이 모델의 세 가지 특성은 하네스 설계와 직접적으로 관련된다.

• 압축을 늦출 만큼 큰 윈도. 백만 token이면 작업 중인 리포지토리, 진행 중인 궤적, 참조 문서를 동시에 담을 수 있다. 하네스는 여전히 잘라내야 한다. 언제나 그래야 한다. 하지만 요약이 정보를 훼손하기 시작하는 기준점이 충분히 뒤로 밀리므로, 장기 작업이 중간에 소리 없이 성능 저하를 겪지 않게 된다.

• 하네스 조절값으로서의 추론 노력. K3.1 Pro는 항상 추론하며, reasoning_effort는 low, high, max를 받을 수 있고 기본값은 max다. 이로써 모델의 추론 비용은 고정된 진입 비용이 아니라 하네스가 작업별로 설정하는 예산이 된다.

• 에피소드 중간에 도착하는 도구. 동적 도구 로딩을 사용하면 하네스가 시스템 메시지 안에 완전한 도구 정의를 삽입할 수 있다. 따라서 해당 메시지부터 도구를 사용할 수 있으며, 재시작할 필요도 없고, 한 번도 사용하지 않을 도구의 스키마 비용을 대화의 매 턴마다 지불할 필요도 없다.

Moonshot은 모델과 함께 하네스를 보고하며, 이는 이 글이 주장하는 원칙이다. 엄격한 작업별 테스트 아래 현실적이고 자원이 제한된 터미널 작업에서 코딩 에이전트를 평가하는 Terminal-Bench 4.0에서 K3.1 Pro는 65.7%를 기록했다. GPT-6 Astra의 58.2%를 앞서고 Claude Opus 5.5의 66.4%에 근소하게 뒤진다. 다단계 실행, 도구 사용, 엔드투엔드 문제 해결을 위한 내부 벤치마크인 Kimi Code Bench 3.0 Long-horizon에서는 K3의 55.95% 대비 61.2%를 기록했다. 문서는 반대 방향의 결합 관계도 똑같이 명확히 밝힌다. temperature, top_p 같은 샘플링 매개변수는 고정되어 있으므로 요청에서 생략해야 하며, 전체 어시스턴트 메시지는 턴 간에 변경 없이 반환해야 한다. 메시지를 재작성하는 하네스는 다음 도구 호출이 의존하는 추론을 잃게 된다.

동일한 모델이 전체 환경에서 실행된다. Kimi Agent를 통해 관리형 웹 버전을 사용해 볼 수 있고, Kimi Work로 전체 로컬 하네스를 실행할 수 있으며, Kimi Code로 터미널에서 작업하거나 Kimi API를 통해 kimi-k3.1-pro를 직접 호출할 수 있다. kimi-k3.1-pro-highspeed 변형은 token 가격을 약 두 배로 높이는 대신 출력 속도를 두세 배로 제공한다.

모델을 평가하든 제품을 출시하든, 동일한 체크리스트가 적용된다.

1. 프레임워크가 아니라 작업에서 시작하라. 에이전트가 코드를 편집한다면 SWE-agent의 ACI 같은 Bash와 편집기 기반 하네스가 검증되어 있다. GUI나 실제 웹을 조작한다면 실제 세션 관찰과 클릭 수준의 동작이 필요하다.

2. 환경을 재현 가능하게 만들어라. Docker 이미지, 고정된 종속성, 시드 데이터는 벤치마크와 일화의 차이를 만든다.

3. 컨텍스트 윈도를 의도적으로 예산화하라. 관찰 내용 자르기, 이력 요약, 압축은 점수와 비용을 직접 바꾸는 하네스 기능이다. 또한 긴 컨텍스트 모델이 하네스가 버려야 하는 양을 줄여 주는 이유이기도 하다.

4. 엄격한 한도를 적용하라. 에피소드별 단계 상한, 실제 경과 시간 제한, 비용 예산은 에이전트를 안전하게 유지하고 평가의 비교 가능성을 보장한다.

5. 첫날부터 전체 궤적을 기록하라. 사람 검토, 실패 군집화, 미세 조정 등 모든 진지한 개선 루프는 궤적 데이터를 사용한다. Anthropic의 Managed Agents와 DeepSeek Harness는 여기서 한 걸음 더 나아간다. 세션 로그를 하네스 루프 외부에 추가 전용 이벤트 스트림으로 보관해 하네스 자체는 교체 가능하게 하고, 모델의 컨텍스트는 언제나 재구성할 수 있게 한다.

6. 둘 이상의 하네스에서 평가하라. 에이전트가 하나의 하네스 안에서만 작동한다면, 역량이 아니라 하네스 종속적 동작을 만든 것이다.

7. 자격 증명은 샌드박스 밖에 두거나, 아예 클라우드 밖에 두어라. 에이전트의 실행 환경을 신뢰할 수 없는 것으로 취급하라. token은 볼트에 보관하고 프록시를 통해 주입하거나, 자격 증명과 페이지 콘텐츠가 기기를 떠나지 않도록 전체 세션을 로컬에서 실행하라. 이는 Kimi가 로컬 하네스에 적용하는 방식이다.

에이전트 하니스는 조용히 에이전트 스택에서 가장 중요한 계층이 되었습니다. SWE-bench, mini-SWE-agent, Terminal-Bench, METR의 연구에 따르면 하니스 설계는 모델 업그레이드에 맞먹는 영향을 낼 수 있습니다. DeepSeek Harness, OpenHands, SWE-agent, Aider 같은 오픈 소스 프로젝트는 누구나 프로덕션급 하니스를 활용할 수 있게 했으며, Anthropic, OpenAI, Google, Microsoft, Moonshot AI 모두 이제 하니스 엔지니어링을 핵심 업무로 다룹니다.

하지만 더 근본적인 변화는 개념적인 측면에 있습니다. 1세대 하니스는 에이전트 × 컴퓨터 문제를 해결했습니다. 즉, 모델이 터미널, 브라우저, 파일 시스템을 안정적으로 다룰 수 있는 손을 제공한 것입니다. 다음 세대는 이러한 환경이 만들어내는 컨텍스트 문제를 해결하고 있습니다. 며칠에 걸치고, 이해관계자와 저장소를 아우르며, 어떤 요약기도 손실 없이 압축할 수 없는 작업 말입니다. 하니스는 발판 역할에서 운영 환경으로 진화하고 있으며, 하니스가 관리해야 하는 영역과 모델이 단순히 보유할 수 있는 영역의 경계는 계속 이동하고 있습니다. Kimi K3.1 Pro의 100만 token 컨텍스트 윈도우는 현재 가장 분명한 사례입니다. 이전에는 하니스가 해야 했던 작업을 없애는 모델 변화입니다.

자체적으로 구축하든, 오픈 소스 프레임워크를 도입하든, 프로덕션 하니스를 운영하든, 하니스를 엔지니어링되고 버전 관리되며 측정 가능한 소프트웨어로 다루는 팀의 에이전트가 실제로 업무를 끝까지 완수합니다.