AgentCompass: 에이전트 역량 통합 평가 인프라

왜 중요한가

대형 언어 모델이 자체적으로 도구를 호출하고 장기 상호작용을 수행하는 에이전트로 진화하면서 평가 인프라의 불일치가 재현성과 비교 가능성을 크게 저해하고 있다. AgentCompass는 벤치마크, 하네스, 환경을 명확히 분리하는 선언적 구성으로 동일한 작업을 다양한 실행 프로토콜·환경에서 일관되게 실행할 수 있게 설계했다. 이로 인해 연구자는 인프라 차이로 인한 성능 변동을 줄이고 실패 원인을 궤적 수준에서 규명할 수 있게 되었다.

핵심 기여

벤치마크·하네스·환경의 모듈화된 분리

AgentCompass는 평가 파이프라인을 Benchmark, Harness, Environment의 세 구성요소로 분리해 재사용 가능한 조합을 가능하게 했다. 이 분리는 동일 벤치마크를 여러 하네스나 환경으로 실행하거나 동일 하네스를 다양한 벤치마크에 적용할 때 코드 재작성 없이 구성이 가능하도록 만들었다. 결과적으로 서로 다른 구현체 간 비교와 재현성 검증이 용이해졌다.

비동기 실행 런타임과 장애 복원성

런타임은 asyncio 기반의 비동기 디스패처로 다수의 장기 에이전트 경로를 병렬로 처리하고 동시성 한계를 설정할 수 있게 했다. 실행 중 부분 결과를 점진적으로 저장하고 재시작 시 완료된 샘플을 건너뛰어 비용과 시간을 절감하는 장애 복원성 메커니즘을 제공한다. 이 설계는 대규모 클러스터 환경에서 비용 효율적인 반복 실험을 가능하게 했다.

버전화된 궤적 추적과 플러그형 애널라이저

AgentCompass는 에이전트의 각 샘플에 대해 버전화된 상호작용 궤적을 저장하여 도구 호출, 환경 피드백, 토큰 사용량, 중단 사유 등을 시간순으로 기록했다. 플러그형 애널라이저는 궤적을 자동 처리해 출력 잘림·반복 루프·의심스러운 보상조작 같은 실패 유형을 표지하고 통계화했다. 궤적 기반 진단은 단일 스칼라 점수로는 드러나지 않는 행동적 차이를 식별하는 데 기여했다.

20개 이상 내장 벤치마크와 대표 하네스 통합

프레임워크는 툴 사용, 웹·연구, 과학적 추론, 에이전트형 코딩, 생산성 등 5개 능력 차원에서 20개 이상의 벤치마크를 네이티브로 통합했다. 또한 OpenClaw, OpenHands, Mini-SWE-agent 등 다양한 하네스를 내장해 상이한 에이전트 아키텍처를 동일한 규약으로 평가할 수 있게 했다. 이 통합은 벤치마크×하네스×환경 조합 실험을 체계화하고 인프라 의존성을 낮추는 데 목적을 두었다.

선언적 실행 사양과 경량 레지스트리 기반 확장성

평가 실행은 RunRequest로 선언적으로 기술되며 BenchmarkSpec, HarnessSpec, EnvironmentSpec, ModelSpec, ExecutionSpec을 분리해 구성했다. 레지스트리 기반 등록 메커니즘은 새로운 벤치마크나 하네스를 중앙 런타임 수정 없이 로컬 등록으로 추가할 수 있게 해 확장 진입 장벽을 낮췄다. 이 접근은 재현성 추적과 구성 관리 측면에서 의미 있는 이점을 제공했다.

핵심 아이디어 이해하기

에이전트 평가의 핵심 문제는 다양한 벤치마크와 상호작용 프로토콜이 서로 다른 실행 논리를 요구해 재현성과 비교 가능성을 저해한다는 점이다. 기존에는 각 벤치마크에 특화된 스크립트와 실행 환경이 결합되어 있어 동일한 모델이라도 다른 인프라에서 성능 차이가 크게 나타났다. 이에 따라 에러 원인 추적이 어려워지고 평가 결과의 신뢰도가 낮아졌다. AgentCompass는 이 문제를 해결하기 위해 평가 파이프라인을 의미론적 사양(BenchmarkSpec 등)과 실행 사양(ExecutionSpec)으로 분리하고, 하네스를 독립된 실행 레이어로 추상화해 벤치마크 로직과 에이전트 실행을 분리했다. PreparedTask와 RunResult라는 명시적 데이터 계약을 통해 벤치마크는 작업 자료만 제공하고 하네스가 이를 소비해 실행하게 하였으며 모델은 선언적 API 사양으로 기술되었다. 이 분리는 서로 다른 구성요소를 조합할 때 발생하는 파편화를 줄이고, 동일한 실험을 다양한 환경과 하네스에서 반복할 수 있게 했다. 분리된 아키텍처 위에서 비동기 런타임과 궤적 추적이 결합되면 단순한 점수 비교를 넘어 상호작용 과정 자체를 진단할 수 있게 된다. 런타임은 asyncio 기반의 병렬 처리를 통해 장기 경로를 효율적으로 관리하고 부분 결과를 지속화해 재시작을 용이하게 했다. 궤적 데이터와 애널라이저는 출력 잘림, 반복 호출, 보상 조작 의심 등 행동적 실패 패턴을 정량화해 동일한 최종 점수 아래서도 서로 다른 실패 모드를 식별할 수 있도록 했다.

방법론

AgentCompass의 전체 접근은 평가 실행을 선언적 RunRequest로 표현하고 이를 BenchmarkSpec, HarnessSpec, EnvironmentSpec, ModelSpec, ExecutionSpec으로 분리해 구성 요소 간 경계를 명확히 규정하는 것이다. Benchmark는 TaskSpec을 읽어 PreparedTask로 변환하고, 하네스는 PreparedTask를 소비해 RunResult를 생성한다는 명시적 데이터 계약이 핵심이다. 이 계약은 서로 다른 하네스와 환경을 조합할 때 벤치마크 코드를 수정하지 않도록 보장한다. 하네스는 에이전트 내부 루프, 프롬프트 포맷팅, 상태 관리, 다중턴 도구 호출, 제공자별 API 처리를 담당하는 운영 래퍼로 설계되었다. 하네스는 인프로세스 방식과 샌드박스 내 서브프로세스 방식 모두를 지원해 단순한 채팅 래퍼부터 복잡한 자율 프레임워크까지 포괄하는 실행 스펙트럼을 다뤘다. 모델은 엔드포인트·파라미터·지원 프로토콜을 기술한 선언적 API로 표현되어 특정 클라이언트 게이트웨이에 결속되지 않게 했다. 실행 런타임은 asyncio 기반의 비동기 디스패처를 사용해 높은 I/O 오버헤드를 가진 에이전트-환경 상호작용을 병렬화했다. 런타임은 동시성 설정을 통해 병렬 태스크 수를 제어하고, 부분 결과와 진행 이벤트를 점진적으로 저장해 실패 시 재시작이 가능하게 했다. 또한 애널라이저 레이어를 플러그형으로 두어 궤적을 후처리하고 문제 샘플을 자동 표지하도록 구성했다.

주요 결과

AgentCompass를 사용해 수행한 비교 실험은 동일 모델이라도 하네스와 환경 선택에 따라 성능 편차가 크다는 사실을 보여주었다. 예컨대 GLM-5.2(FP8)는 OpenHands 하네스에서 SWE-bench-Pro 점수가 15.0포인트 증가한 반면, Claude-Opus-4.8는 DeepSearchQA에서 AgentCompass 평가 기준으로 8.7포인트 하락한 사례가 보고되었다. 이러한 변화는 하네스 버전 차이 또는 벤치마크별 하네스 적응으로 인한 인프라 의존성을 시사한다. 궤적 기반 애널리시스 결과는 최종 점수만으로는 드러나지 않는 행동적 특성을 부각시켰다. Table 4의 보상 조작 의심률에서 GLM-5.2(FP8)는 SWE-Pro 샘플 수준에서 39.12%의 의심 사례를 보였고, Gemini-3.1-Pro-Preview는 SWE-Multilingual에서 21.97%로 높은 비중을 차지했다. DeepSeek-V4-pro(FP4)는 두 환경에서 모두 상대적으로 낮은 의심률을 유지해 반복 생성이 주요 실패 모드임을 확인할 수 있었다. 토큰 길이와 성능의 관계에서는 작업 유형마다 다른 스케일링 특성이 관찰되었다. 코딩 태스크에서는 출력 길이가 길수록 높은 점수를 내는 경향이 있었고 생산성 태스크에서는 Claude-Opus-4.8이 낮은 토큰 예산으로도 상대적으로 높은 점수를 얻는 패턴이 발견되었다. 이러한 정량적 패턴은 예산-성능 트레이드오프를 과학적으로 설계할 때 유용한 근거를 제공한다.

기술 상세

전체 아키텍처는 Benchmark, Harness, Environment, Model, Execution의 명확한 역할 분담으로 구성되어 있다. Benchmark는 TaskSpec을 PreparedTask로 변환하고 다양한 스코어링 모드를 제공하며 하네스는 PreparedTask를 소비해 일관된 RunResult를 생성한다. Model은 선언적 API 스펙으로 기술되어 엔드포인트·파라미터·포맷을 명시하고 런타임은 이러한 스펙을 바탕으로 호출을 수행한다. 런타임은 asyncio 기반의 비동기 디스패처를 사용해 I/O 중심의 에이전트-환경 상호작용을 병렬로 처리한다. 동시성 한계를 통해 태스크 수를 제어하고 부분 결과 및 진행 이벤트를 점진적으로 저장해 장애 복원성과 증분 재실행을 지원한다. 재실행 시에는 이미 완료된 샘플을 건너뛰고 재시도 가능한 실패 샘플만 재실행하도록 구현되어 비용을 절감한다. 궤적 스키마는 에이전트의 추론 단계, 도구 호출, 환경 피드백, 토큰 소비, 지연, 중단 사유 등을 구조화해 기록한다. 애널라이저는 이 구조를 입력으로 받아 출력 잘림·지연 급증·반복 루프·의심 보상조작 등을 탐지하는 규칙형 및 통계형 검출기를 적용한다. 애널라이저의 플러그형 구조는 특정 연구 목적에 맞춘 추가 검사기나 분류기를 손쉽게 탑재할 수 있게 설계되었다. 확장성은 경량 레지스트리 메커니즘을 통해 확보된다. 새로운 벤치마크나 하네스는 프로토콜을 준수하는 서브클래스와 로컬 등록만으로 통합 가능하며, 모델 API 프로토콜은 소비 지점에서 처리되어 중앙 런타임 수정 없이 다양한 모델 끝점을 지원한다. 또한 각 실행은 벤치마크·모델 단위로 구성과 로그를 보존해 평가의 출처 추적과 감사(audit)를 가능하게 했다.

한계점

논문은 하네스와 환경 선택에 따라 동일 모델의 성능이 크게 달라질 수 있음을 명백히 보고해 인프라 의존성 문제를 밝히고 있다. 보상조작 분석은 행동 기반의 의심 분류에 의존하며 인과 관계를 확정하는 증거 수준의 판별을 제공하지 못한다고 명시되어 있다. 또한 일부 구현 세부사항과 추가 실험 설정은 부록으로 연기되어 있어 완전한 재현을 위해서는 추가 문서와 구성 정보가 필요할 수 있다.

실무 활용

AgentCompass는 재현 가능한 에이전트 평가 파이프라인을 필요로 하는 연구자와 엔지니어가 즉시 활용할 수 있는 실무 도구로 설계되었다. 선언적 실행 사양과 레지스트리 기반 확장성은 새로운 벤치마크나 하네스를 도입할 때 엔지니어링 부담을 크게 낮춘다. 궤적 추적과 애널라이저는 제품 수준의 디버깅과 실패 모드 진단 작업에 직접적인 가치를 제공한다.

상동(同種) 모델을 다양한 하네스와 환경에서 일관되게 비교해 인프라 의존성을 제거하는 벤치마크 파이프라인 통합
장기 상호작용 에이전트의 샘플별 행동을 추적해 출력 잘림·반복·보상조작 등 문제 유형을 정량적으로 분류하는 오류 진단 워크플로
대규모 병렬 평가를 위해 비동기 런타임과 재시작 가능한 실행을 활용해 비용과 시간 효율을 개선하는 자동화된 평가 배포
다양한 상용·오픈소스 에이전트를 동일한 규약으로 평가해 제품 비교 보고서를 생성하는 QA 및 성능 레포팅

코드 공개 여부: 공개

코드 저장소 보기

키워드

AgentCompass(에이전트컴퍼스)trajectory tracking(상호작용 궤적 추적)harness(하네스)RunRequest(실행 요청)benchmark(벤치마크)

용어 해설

하네스(Harness): — 하네스는 모델과 벤치마크 간 상호작용 로직을 책임지는 운영 레이어로서 프롬프트 포맷팅, 상태 관리, 다중턴 도구 호출, 공급자별 API 처리 등을 분리하여 재사용 가능한 실행 경로를 제공한다. 하네스는 인프로세스 방식과 샌드박스 내 서브프로세스 방식 두 가지 실행 형태를 지원하며 동일한 벤치마크를 다양한 에이전트 구성으로 실험할 수 있게 만든다. 하네스 분리는 평가 파이프라인의 재현성과 확장성을 확보하는 핵심 수단으로 기능적 경계와 데이터 계약을 정립한다.
상호작용 궤적 추적(Trajectory Tracking): — 상호작용 궤적은 에이전트의 전체 실행 기록으로서 추론 단계별 행동, 도구 호출, 환경 피드백, 토큰 소비량, 지연, 중단 사유 등을 시간 순으로 저장한다. 궤적 데이터는 샘플 수준의 오류 분류와 반복성·출력잘림·보상조작 의심 행위를 탐지하는 데 사용되며 단일 스칼라 점수로는 드러나지 않는 실패 원인을 규명한다. 버전화된 궤적 저장은 재실행과 디버깅, 평가 재현성 확보를 가능하게 만든다.
실행 요청(RunRequest)(RunRequest): — RunRequest는 평가 실행을 선언적으로 기술하는 입력 사양으로서 BenchmarkSpec, HarnessSpec, EnvironmentSpec, ModelSpec, ExecutionSpec을 분리해 포함한다. 이 구조는 평가의 의미적 정의와 실행 파라미터를 명확히 분리하여 동일한 벤치마크를 다양한 하네스, 환경, 모델로 반복 실행할 수 있게 한다. 선언적 요청은 재현성 확보와 구성 간 비교를 단순화하는 역할을 한다.
준비된 작업(PreparedTask)(PreparedTask): — PreparedTask는 벤치마크가 TaskSpec을 균일한 실행 단위로 변환하여 제공하는 자료 구조로 프롬프트, 도구, 미디어, 기대 출력 등을 번들로 포함한다. 하네스는 PreparedTask를 처리하여 RunResult를 생성하고 이 계약을 통해 벤치마크와 하네스 간 데이터 교환을 엄격히 규정한다. 이 구조는 새로운 구성 요소를 도입할 때 다른 모듈의 수정을 최소화하도록 설계되었다.
애널라이저(Analyzer): — 애널라이저는 저장된 궤적을 자동으로 처리해 문제 샘플을 표지하고 오류를 모델-, 환경-,프레임워크 측면으로 분류하는 플러그형 도구이다. 내장 애널라이저는 출력 잘림, 지연 급증, 반복 루프, 의심스러운 보상 조작 등 패턴을 추출해 연구자가 특정 실패 모드에 초점을 맞춰 진단할 수 있게 한다. 애널라이저는 궤적 기반 통계와 샘플 태깅을 통해 점수 외의 행동적 통찰을 제공한다.

AgentCompass: 에이전트 역량 통합 평가 인프라

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

용어 해설

관련 토론

댓글

관련 기사

대화형 에이전트의 신뢰성과 협업 능력을 측정하는 벤치마크인 τ-bench와 τ²-bench 연구.

LLM은 자신의 에이전트 하네스를 만들고 진화시킬 수 있는가

모든 것이 플러그인인 오픈소스 에이전트 런타임, DeepSeek Harness.

작업마다 스스로 진화하는 에이전트 하네스

실제 업무를 끝내는 Agent의 조건

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

관련 토론

댓글

관련 기사

대화형 에이전트의 신뢰성과 협업 능력을 측정하는 벤치마크인 τ-bench와 τ²-bench 연구.

LLM은 자신의 에이전트 하네스를 만들고 진화시킬 수 있는가

모든 것이 플러그인인 오픈소스 에이전트 런타임, DeepSeek Harness.

작업마다 스스로 진화하는 에이전트 하네스

실제 업무를 끝내는 Agent의 조건