AutoLab: Can Frontier Models Solve Long-Horizon Auto Research and Engineering Tasks? Review

0. Introduction

Paper link

Project page

Code link

AutoLab은 frontier model 평가에서 점점 더 중요해지는 질문을 던진다. 모델이 단답형 문제나 짧은 coding task를 잘 푸는 것은 이미 많이 측정된다. 하지만 실제 연구와 엔지니어링은 대개 한 번의 답변으로 끝나지 않는다. 코드를 읽고, 가설을 세우고, 실험을 돌리고, 결과를 보고, 다시 수정하는 긴 loop가 필요하다.

AutoLab은 이 loop 자체를 benchmark로 만든다. 각 task는 이미 correct but suboptimal baseline을 제공한다. Agent는 정해진 wall-clock budget 안에서 baseline을 개선해야 한다. 중요한 것은 처음 낸 답이 좋은가가 아니라, 여러 시간 동안 benchmark, edit, rerun, analysis, refinement를 계속할 수 있는가다.

한 줄 요약: AutoLab은 36개 executable research and engineering task를 통해 frontier model이 long-horizon closed-loop optimization을 얼마나 지속적으로 수행할 수 있는지 평가하는 benchmark다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같다.

• 현재 agent benchmark의 많은 부분은 short-horizon interaction이나 final patch success에 집중되어 있다.
• AutoLab은 연구와 엔지니어링을 “정답 생성”이 아니라 “반복적인 artifact improvement”로 평가한다.
• Continuous calibrated scoring, sealed verifier, immutable-file check, adversarial auditing 등 benchmark hacking을 줄이는 장치를 포함한다.
• 모델 성능 차이를 raw intelligence보다 persistence, time awareness, empirical feedback use 관점으로 해석한다.
• Auto research agent를 실제로 만들려는 팀에게 evaluation harness 설계의 기준점을 제공한다.

이 논문은 agent가 더 똑똑한지 묻기보다, 오래 버티며 실험할 수 있는지를 묻는다. 그래서 AutoLab은 coding benchmark라기보다 research process benchmark에 가깝다.

1. Problem Setting

1-1. Problem definition

AutoLab이 겨냥하는 문제는 ultra long-horizon closed-loop optimization이다. 여기서 closed-loop는 agent가 한 번 답을 내고 끝나는 것이 아니라, 실행 결과를 다시 읽고 다음 행동을 정하는 구조를 뜻한다.

실제 연구와 엔지니어링에서는 다음 loop가 반복된다.

1. 현재 artifact를 읽는다.
2. 병목이나 개선 가설을 세운다.
3. 코드를 수정하거나 hyperparameter를 바꾼다.
4. 실험을 실행한다.
5. metric, failure, log를 해석한다.
6. 다음 실험을 고른다.
7. 시간이 끝나기 전에 가장 좋은 artifact를 제출한다.

기존 benchmark는 이 중 일부만 본다. SWE-bench류 benchmark는 final patch가 맞는지에 강하고, terminal benchmark는 짧은 interactive task를 잘 본다. 하지만 몇 시간 동안 계속 시행착오를 축적하는 능력은 충분히 분리해서 보지 못한다.

AutoLab의 task는 모두 correct but deliberately suboptimal baseline에서 시작한다. 즉 agent는 무에서 유를 만드는 것이 아니라, 이미 돌아가는 artifact를 더 좋게 만들어야 한다. 이 설정은 실제 system optimization, ML training, CUDA kernel tuning과 매우 가깝다.

1-2. Why previous approaches are insufficient

기존 benchmark의 한계는 세 가지다.

첫째, horizon이 짧다. 많은 benchmark는 몇 번의 tool call이나 한 번의 code patch 안에서 끝난다. 이런 setting에서는 agent가 시간을 어떻게 배분하는지, 실패한 실험에서 무엇을 배우는지, 중간 결과를 어떻게 축적하는지가 잘 드러나지 않는다.

둘째, score가 pass/fail 중심이다. 실제 optimization task에서는 0점과 1점 사이에 의미 있는 개선이 많다. Runtime을 10% 줄였지만 reference에는 못 미친 경우, perplexity를 일부 낮춘 경우, kernel correctness는 맞지만 speed가 부족한 경우를 모두 binary로 처리하면 agent behavior를 분석하기 어렵다.

셋째, benchmark hacking surface가 넓다. Agent가 codebase를 자유롭게 수정하고 실행할 수 있으면, 평가 script를 건드리거나 held-out condition을 우회하려는 shortcut이 생길 수 있다. AutoLab은 sealed verifier, correctness gate, immutable-file check, adversarial auditing을 통해 이 문제를 줄이려 한다.

2. Core Idea

2-1. Main contribution

AutoLab의 핵심 기여는 “long-horizon improvement”를 측정 가능한 benchmark protocol로 만든 것이다.

구체적으로는 다음과 같다.

1. 36개 executable task를 만든다.
   • System optimization
   • Puzzle and challenge
   • Model development
   • CUDA kernel optimization

2. 각 task에 baseline, reference solution, local evaluator, sealed final verifier, wall-clock budget을 둔다.

3. Agent는 동일한 harness 안에서 작업한다.
   • Codebase 읽기
   • File edit
   • Local eval 실행
   • Profiling과 log 분석
   • Final submission
4. Score는 continuous calibrated score로 산정한다.
   • Runtime, accuracy, parameter count, perplexity 등 task별 metric을 비교 가능한 scale로 mapping한다.
5. 모델별로 3회 independent rollout을 수행하고 Avg@3, Best@3, Dominance를 보고한다.

AutoLab이 중요한 이유는 단순히 task 수가 많아서가 아니다. Benchmark가 “agent trajectory의 질”을 분석할 수 있도록 설계되어 있다는 점이 중요하다.

2-2. Design intuition

AutoLab의 설계 직관은 다음과 같다.

좋은 research agent는 처음부터 정답을 쓰는 agent가 아니라, 틀린 실험에서 정보를 얻고 다음 실험을 더 잘 고르는 agent다.

이 관점에서는 one-shot solution quality보다 persistence가 중요해진다. Agent가 처음에 좋은 아이디어를 냈더라도, 중간 실험이 실패했을 때 바로 포기하면 최종 성능은 낮다. 반대로 처음 아이디어가 평범해도, 꾸준히 benchmark를 돌리고 결과를 읽고 작은 개선을 축적하면 더 좋은 artifact에 도달할 수 있다.

AutoLab은 이 차이를 분리하려 한다. 동일 harness, 동일 task, 동일 budget을 두고 모델을 비교한다. 이렇게 해야 model capability와 bespoke system engineering의 효과를 어느 정도 분리할 수 있다.

3. Architecture / Method

3-1. Overview

Item	Description
Goal	long-horizon auto research and engineering capability 평가
Task count	36 executable tasks
Domains	system optimization, puzzle and challenge, model development, CUDA kernel optimization
Initial state	correct but suboptimal baseline
Agent objective	wall-clock budget 안에서 artifact score 개선
Evaluation	sealed verifier와 continuous calibrated score
Metrics	Avg@3, Best@3, Dominance
Harness	unified terminal-based agent harness

3-2. Module breakdown

1) Task package

각 AutoLab task는 instruction, environment, verifier, reference solution, budget으로 구성된다.

• Instruction은 optimization target을 설명한다.
• Environment는 Docker 또는 GPU sandbox와 codebase를 포함한다.
• Baseline은 correct but suboptimal implementation이다.
• Local evaluation script는 agent가 개발 중 호출할 수 있다.
• Final verifier는 held-out evaluation을 수행한다.
• Reference solution은 scoring scale을 잡는 데 쓰이며 agent에게 공개되지 않는다.

이 구조는 실제 engineering workflow와 유사하다. 이미 돌아가는 시스템이 있고, agent는 이를 개선해야 한다.

2) Continuous scoring

AutoLab은 단순 pass/fail을 피한다. 어떤 task는 runtime을 줄이는 것이 목표이고, 어떤 task는 model accuracy를 올리는 것이 목표이며, 어떤 task는 parameter count나 memory를 줄여야 한다. 이질적인 metric을 모두 binary로 바꾸면 비교가 거칠어진다.

그래서 AutoLab은 baseline과 reference solution을 기준으로 score를 calibration한다. Baseline보다 나아졌는지, reference에 얼마나 가까운지, correctness gate를 통과했는지를 함께 본다.

3) Anti-hacking safeguards

Agent가 자유롭게 code를 수정하는 benchmark는 쉽게 exploit될 수 있다. AutoLab은 이 문제를 줄이기 위해 여러 guard를 둔다.

• Sealed verifier
• Correctness gate
• Immutable-file check
• Budget rule
• Adversarial auditing

이 장치들은 benchmark score가 실제 artifact improvement를 반영하도록 만들기 위한 것이다.

4) Trajectory analysis

AutoLab은 final score만 보지 않는다. 논문은 zero-score rollout을 manual inspection하고, agent가 왜 실패했는지 분석한다. 특히 premature termination과 budget exhaustion이 중요한 failure mode로 나온다.

Premature termination은 agent가 충분히 탐색하지 않고 너무 빨리 제출하는 경우다. Budget exhaustion은 오랜 시간 실행했지만 final solution을 만들지 못하거나 valid submission을 놓치는 경우다. 둘 다 raw reasoning ability만으로 설명하기 어렵다.

4. Training / Data / Recipe

4-1. Data

AutoLab은 model training dataset이 아니라 evaluation benchmark다. Task는 네 domain으로 구성된다.

Domain	What it tests
System optimization	기존 system implementation의 speed, memory, throughput 개선
Puzzle and challenge	algorithmic search, hidden structure discovery, robust optimization
Model development	model training, data, hyperparameter, retention gate를 포함한 ML workflow
CUDA kernel optimization	correctness를 유지하면서 GPU kernel performance 개선

이 구성이 중요한 이유는 agent의 능력을 한 domain에 가두지 않기 때문이다. 실제 auto research agent는 code patching, experiment management, performance profiling, training stability, GPU workload를 모두 다루어야 한다.

4-2. Evaluation strategy

논문은 17개 state-of-the-art model을 평가한다. Proprietary model과 open-weight model이 함께 포함된다. 모든 모델은 동일한 harness와 task definition, action interface, budget rule을 사용한다.

각 model-task pair는 3회 independent rollout으로 평가된다. 그리고 다음 metric을 보고한다.

• Avg@3: 세 번의 rollout score 평균이다. 일반적인 성능을 나타낸다.
• Best@3: 세 번 중 최고 score다. 운이 좋거나 탐색이 잘 된 경우의 ceiling을 본다.
• Dominance: 다른 model과의 task-wise head-to-head win rate에 가깝다. 몇몇 고득점 task에 덜 흔들리는 ranking을 제공한다.

4-3. Engineering notes

AutoLab을 실제로 읽을 때 유용한 engineering note는 다음과 같다.

1. Benchmark는 model만 평가하지 않는다.
   • Harness, local evaluator, sandbox, timeout, final submission protocol이 모두 결과에 영향을 준다.
2. Long-horizon agent에는 time awareness가 필요하다.
   • 실험 하나를 오래 돌릴지, 다른 가설을 시도할지, 언제 제출할지 결정해야 한다.
3. Local score와 final verifier 사이의 gap을 관리해야 한다.
   • Local eval에 과적합하면 final score가 낮아질 수 있다.
4. Agent memory와 experiment log가 중요해진다.
   • 같은 실패를 반복하지 않으려면 중간 결과를 구조적으로 저장해야 한다.
5. Continuous scoring은 diagnosis에 좋다.
   • Binary success보다 어떤 종류의 부분 개선을 했는지 훨씬 잘 보인다.

5. Evaluation

5-1. Main results

논문의 main result에서 Claude Opus 4.6이 overall Avg@3 0.68, Dominance 0.93으로 가장 강한 결과를 보인다. 2위인 Gemini 3.1 Pro는 Avg@3 0.50으로 보고된다. 논문은 이 차이를 long-horizon iterative improvement capability의 분리로 해석한다.

또 하나 중요한 점은 open-weight model 중에서도 domain별로 강약이 다르게 나타난다는 것이다. 어떤 model은 puzzle 쪽에서 상대적으로 강하고, 어떤 model은 system optimization이나 model development에서 차이를 보인다. 따라서 AutoLab의 결과는 단일 leaderboard보다 category profile로 보는 편이 더 유용하다.

논문은 전체 evaluation에 2,544 wall-clock hours와 8.60 billion tokens가 사용되었다고 보고한다. 이 숫자는 AutoLab이 단순 benchmark가 아니라 상당한 resource cost를 가진 long-horizon protocol임을 보여준다.

5-2. What really matters in the experiments

AutoLab에서 진짜 중요한 결과는 “모델 순위”보다 failure mode다.

첫째, 많은 모델은 충분히 오래 탐색하지 않는다. Premature termination은 모델이 early success나 shallow improvement를 보고 더 이상 실험하지 않는 경우다. 실제 연구 환경에서는 이런 행동이 큰 손실이 된다.

둘째, 반대로 일부 모델은 budget을 끝까지 쓰지만 final submission을 제대로 만들지 못한다. 이는 planning과 time management의 실패다. 많이 실행하는 것과 잘 마무리하는 것은 다르다.

셋째, final performance는 initial attempt quality보다 persistence와 더 강하게 연결된다. 즉 첫 코드가 얼마나 좋은가보다, 반복적으로 benchmark를 돌리고 결과를 반영하는 루프가 더 중요하다.

이 관점은 agent 연구에 중요한 메시지를 준다. Strong model을 agent harness에 넣는 것만으로는 충분하지 않다. Long-horizon loop를 안정적으로 운영하는 시간 감각, 실험 기록, 실패 복구, submit discipline이 필요하다.

6. Limitations

1. AutoLab은 scientific discovery 전체를 평가하지 않는다.
   • 논문도 executable system and ML engineering workflow에 초점을 둔다.
   • 새로운 hypothesis generation이나 이론적 discovery까지 포괄하는 benchmark는 아니다.
2. Evaluation cost가 크다.
   • Multi-hour execution, API call, GPU workload가 필요하다.
   • 일반 연구자가 전체 benchmark를 자주 돌리기는 부담이 크다.
3. Harness dependence가 남는다.
   • 논문은 동일 harness로 apples-to-apples 비교하려 하지만, agent harness 자체가 결과에 영향을 준다.
   • 다른 harness를 쓰면 모델 순위가 일부 달라질 수 있다.
4. Task distribution이 특정 engineering style에 치우칠 수 있다.
   • CUDA, system optimization, model development는 매우 유용하지만, 모든 연구 업무를 대표하지는 않는다.
5. Proprietary model 비교는 재현성이 어렵다.
   • API model은 시간이 지나며 바뀔 수 있고, latency와 cost도 변한다.

7. My Take

7-1. Why this matters for my work

AutoLab은 agent evaluation에서 매우 중요한 방향을 보여준다. 앞으로의 agent benchmark는 final answer correctness만 볼 수 없다. Agent가 몇 시간 동안 어떤 실험을 했고, 어떤 실패에서 무엇을 배웠고, 언제 중단했는지까지 봐야 한다.

특히 internal coding agent나 research automation system을 만들 때는 AutoLab식 task가 유용하다. Baseline implementation을 주고, score를 개선하되, final verifier는 숨기는 구조는 실제 업무와 가깝다.

7-2. Reuse potential

이 논문의 구조는 다음처럼 재사용할 수 있다.

• 사내 codebase optimization benchmark
• ML experiment automation benchmark
• Retrieval pipeline tuning benchmark
• Data preprocessing and evaluation loop benchmark
• GPU kernel 또는 inference server optimization benchmark

실무 적용에서는 AutoLab 전체를 그대로 쓰기보다, 자사 workload에 맞는 mini-AutoLab을 만드는 방식이 좋아 보인다. 중요한 것은 task를 executable artifact로 만들고, baseline, local eval, sealed final eval, continuous score를 분리하는 것이다.

7-3. Follow-up papers

• MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
• Terminal-Bench: Evaluating Agents in the Terminal
• ResearchClawBench: End-to-End Autonomous Research Benchmark
• Frontier-Eng: Benchmarking Self-Evolving Agents on Real-World Engineering Tasks

8. Summary

• AutoLab은 long-horizon closed-loop optimization을 평가하는 executable benchmark다.
• 36개 task는 system optimization, puzzle and challenge, model development, CUDA kernel optimization을 포함한다.
• 각 task는 correct but suboptimal baseline에서 시작하며, agent는 wall-clock budget 안에서 artifact를 개선해야 한다.
• 결과는 모델의 one-shot ability보다 persistence, time awareness, empirical feedback use가 중요함을 보여준다.
• Auto research agent를 평가하려면 final answer가 아니라 실험 loop 자체를 benchmark로 만들어야 한다.