원문 정보
Ziyu Ma, Hailang Huang, Shun Zou, Yong Wang, Shidong Yang, Yiming Hu, Fei Wei, XiangXiang Chu, "LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks", arXiv:2608.01964 [cs.CV], 2026-08-03 제출, 29쪽, DOI 10.48550/arXiv.2608.01964. 소속: 알리바바 그룹 DreamX 팀. 코드·프로젝트 페이지 공개(github.com/AMAP-ML/LongHorizon-Harness).
동료심사를 거치지 않은 프리프린트입니다. 1분류가 컴퓨터비전(cs.CV)으로 등록돼 있는데, 내용은 에이전트 하니스 설계에 가깝습니다 — OSWorld 같은 GUI 조작 벤치마크가 포함된 데 따른 분류로 보이며, 인용 시 분류만 보고 성격을 짐작하면 어긋납니다. 이해상충은 명확합니다. 저자 전원이 알리바바 그룹 소속이고, 주 실험에 쓰인 기반 모델 Qwen 3.7-Plus 역시 같은 회사의 모델입니다. 다만 코드와 프로젝트 페이지를 공개했다는 점은 외부 재현 가능성 쪽으로 가산 요인입니다.
연구 개요
문제 설정은 장기 실행 에이전트를 운영해 본 쪽이라면 익숙합니다. 기존 하니스는 실행 이력·작업 상태·완료 판정을 모두 하나의 늘어나는 컨텍스트 안에 담습니다. 그러면 상태를 추적하기 어려워지고, 무엇보다 잘못된 자기 평가("이 단계는 끝냈다")가 이후 판단으로 그대로 전파됩니다.
저자들의 처방은 실행을 작업 상태 관리 문제로 재정의하는 것입니다. Manage-Execute-Audit(MEA) 루프는 역할을 셋으로 쪼갭니다. 매니저는 현재 작업 상태를 읽고 의존관계·제약·완료 기준을 명시한 하위 작업 하나를 정의합니다. 실행자는 매 라운드 새 컨텍스트에서 그 라운드에 필요한 정보만 받아 예산 한도 안에서 돌아갑니다. 감사자는 실행자의 자기보고가 아니라 실행 결과로 바뀐 환경 상태를 직접 대조해 완료를 판정합니다.
설계에서 가장 논쟁적인 결정은 라운드가 끝나면 실행자의 원시 상호작용 궤적을 폐기하고 작업 상태와 감사 리포트만 남긴다는 규칙입니다. 컨텍스트를 늘려 기억을 보존하는 통상적 방향과 반대입니다. 평가는 WeaveBench(114개 과제), Terminal-Bench 2.1, OSWorld 2.0(전체 108개 과제 및 Opus 서브셋 34개 과제)에서 진행됐습니다.
핵심 결과
주 실험은 같은 모델(Qwen 3.7-Plus)을 기존 하니스와 제안 하니스에 각각 태워 비교하는 방식입니다. 벤치마크마다 지표 정의가 다르므로 기준을 함께 봐야 합니다 — WeaveBench의 PassRate는 완전 통과 비율, Overall은 부분 점수를 반영한 종합 점수, OSWorld의 Binary와 Partial은 각각 완전 성공률과 부분 성공률입니다.
| 벤치마크 (지표) | 기존 하니스 | LongHorizon-Harness | 차이 |
|---|---|---|---|
| WeaveBench 114과제 — PassRate | 51.8% | 80.7% | +28.9%p |
| WeaveBench — Overall 점수 | 0.702 | 0.835 | +0.133 |
| Terminal-Bench 2.1 — 성공률 | 69.7% | 77.2% | +7.5%p |
| OSWorld 2.0 108과제 — Binary | 2.8% | 8.3% | +5.5%p |
| OSWorld 2.0 108과제 — Partial | 21.5% | 35.2% | +13.7%p |
OSWorld의 Opus 서브셋 34개 과제에서는 기반 모델을 Claude Opus 4.7로 바꿔 같은 비교를 반복했고, Binary 20.6% → 35.3%, Partial 55.8% → 66.9%였습니다. 자사 모델에서만 나오는 효과가 아니라는 점을 보이려는 설계이며, 이 시리즈가 보기에 논문에서 가장 설득력 있는 대목입니다.
비용은 벤치마크마다 방향이 갈렸습니다. 이 부분은 기준이 서로 달라 특히 주의해서 읽어야 합니다.
| 벤치마크 | 토큰 소비 변화 (기준) | 역할별 토큰 비중 (매니저/실행자/감사자) |
|---|---|---|
| WeaveBench | 2.3배 증가 (총 토큰) | 2.8% / 77.8% / 19.4% |
| OSWorld 2.0 | 3.6배 증가 (출력 토큰 기준) | 2.0% / 73.2% / 24.8% |
| Terminal-Bench 2.1 | 24% 감소 | 8.1% / 53.8% / 38.1% |
OSWorld의 3.6배는 공식 데이터 제약 탓에 출력 토큰만을 기준으로 한 수치이므로, WeaveBench의 총 토큰 2.3배와 나란히 놓고 비교할 수 없습니다. 논문이 명시한 적용 범위 한계도 함께 기록해 둡니다 — 시각 인식·수학 추론·코딩·알고리즘 설계처럼 단일 모델 역량이 성패를 좌우하는 과제에서는 MEA의 이득이 작고, 이득은 서로 의존하는 여러 환경 상태를 보존·점검·수정해야 하는 과제에 몰립니다.
신뢰도 평가
믿을 근거는 세 가지입니다. 첫째, 핵심 비교가 같은 기반 모델을 두 하니스에 태우는 통제 구조라 하니스 효과와 모델 효과가 섞이지 않습니다. 둘째, 서로 성격이 다른 세 벤치마크(다도메인 과제, 터미널, GUI 데스크톱)에서 방향이 일관됩니다. 셋째, 코드와 프로젝트 페이지가 공개돼 있어 외부 검증 경로가 열려 있습니다.
감안할 점은 그만큼 뚜렷합니다. 저자 전원이 알리바바 소속이고 주 모델도 자사 모델이라는 이해상충이 있고, Opus 서브셋 교차 확인은 34개 과제라는 작은 표본입니다. 논문에는 구성 요소를 하나씩 제거해 보는 어블레이션이 없어 개선분이 매니저의 계획 분해에서 왔는지, 실행자의 새 컨텍스트에서 왔는지, 감사자의 독립 검증에서 왔는지 분리할 수 없습니다. Terminal-Bench 결과는 다른 모델(GPT-5.6, Claude Opus 4.8 등)의 외부 리더보드 수치와 같은 화면에 제시되는데, 이들은 조건이 달라 제안 하니스의 성적과 직접 비교할 대상이 아닙니다. 별도의 한계 절도 없고, 시행 횟수·분산 보고가 없어 표에 적힌 차이가 실행 간 변동을 얼마나 넘어서는지 판단할 근거가 부족합니다. 동료심사 전 초고라는 점은 그대로입니다.
리뷰어 판단
첫째, 이 논문에서 가장 반직관적이고 그래서 가장 값진 결과는 80.7%가 아니라 Terminal-Bench의 조합이라고 판단합니다. 성공률은 7.5%p 올랐는데 토큰은 24% 줄었습니다. 감사 단계를 추가하면 비용이 늘어난다는 통념의 반례이며, 원인은 감사 자체가 아니라 궤적 폐기 규칙일 가능성이 높습니다. 실패한 시도의 장황한 로그를 다음 라운드로 끌고 가지 않으면, 검증을 한 번 더 하고도 총량이 줄어들 수 있습니다.
둘째, OSWorld 수치는 배수로 인용하면 오독을 부릅니다. 2.8%에서 8.3%는 약 3배지만, 여전히 열 번 중 아홉 번은 완전 성공에 이르지 못합니다. 부분 성공률 35.2%가 함께 오른 것은 진척이 실제로 있었다는 뜻이지만, GUI 데스크톱 자동화를 사람 없이 맡기는 판단의 근거로는 부족합니다. 상대 개선과 절대 수준을 분리해 읽는 습관이 이 표에서 특히 중요합니다.
셋째, 역할별 토큰 비중은 이 논문이 의도치 않게 제공한 운영 지표입니다. 감사자가 전체 토큰의 19.4~38.1%를 쓴다는 사실은 "검증 세금"의 크기를 처음으로 숫자로 보여 줍니다. 자체 파이프라인에 검증 단계를 넣을지 논의할 때, 근거 없는 추정 대신 이 구간을 출발점으로 삼을 수 있습니다.
넷째, 어블레이션 부재는 도입 판단에 직접 영향을 줍니다. 세 역할을 모두 구현하는 비용은 작지 않은데, 개선분의 출처를 모르면 축소판(예: 감사자만 추가)이 어느 정도 효과를 낼지 예측할 수 없습니다. 도입한다면 자체 과제로 감사자 유무만 바꾼 비교를 먼저 돌려 보는 편이 안전하다고 봅니다.
실무 적용
- 상태를 컨텍스트 밖으로 — 작업 상태를 대화 이력이 아니라 구조화된 객체로 관리하고, 라운드 간에는 상태와 검증 결과만 넘깁니다.
- 실행 궤적 폐기 정책 — 실패한 시도의 원시 로그를 다음 라운드 프롬프트에 자동 포함하지 않습니다. Terminal-Bench의 토큰 24% 감소가 이 규칙의 값입니다.
- 완료 판정의 독립화 — 에이전트의 자기보고 대신 환경 상태(파일·DB·화면 상태)를 대조하는 별도 검증 역할을 둡니다.
- 역할별 토큰 회계 — 계획·실행·검증에 각각 얼마가 쓰이는지 분리 집계해, 검증 세금이 20~40% 구간을 벗어나면 설계를 다시 봅니다.
- 과제 유형별 도입 판단 — 상태 의존적 다단계 작업에만 적용하고, 단일 역량이 좌우하는 작업(인식·수학·코딩)에는 하니스를 얹지 않습니다.
결론
LongHorizon-Harness의 기여는 새 모델이 아니라 컨텍스트를 다루는 방향을 뒤집은 데 있습니다. 다 기억하게 하는 대신 상태와 검증 결과만 남기고 나머지를 버리는 선택이, 세 벤치마크에서 일관된 개선과 한 벤치마크에서는 비용 절감까지 만들었습니다. 다만 어블레이션·분산 보고가 없고 이해상충이 있는 조건이므로, 수치는 방향 신호로 받고 도입 전 자체 비교를 거치는 것이 맞습니다. 인계와 상태 전달을 운영 절차로 옮기는 쪽은 에이전트 핸드오프 플레이북에서 이어집니다.