Agent Lightning v1.0: Towards Harnessed Agentic RL 요약 설명
18 Aug 2026 | Paper Review Reinforcement Learning Agent Learning AI Coding Agents KubernetesContents
이번 글에서는 Agent Lightning v1.0: Towards Harnessed Agentic RL 논문의 핵심 포인트만 간단히 정리한다.
- 2026년 8월 18일(Arxiv)
- He, Zhiyuan, Zhang, Siwei, Zhou, Zhiwen, Yang, Yuqing, Kang, Yu, Zhang, Yuge, Qiu, Luna K., Tsui, Tin Yan, Xu, Jiahang, Luo, Chong.
- Microsoft, Fudan University, Zhejiang University, University of Edinburgh
- 논문 링크
- Project Page
요약
- Agent Lightning v1.0은 배포 시점의 agent harness가 컨텍스트 구성, 도구 실행, 환경 상호작용을 유지하고, RL trainer가 proxy를 통해 LLM 요청-응답 쌍을 관찰하는 harnessed agentic RL을 정의한다. 약 3,500줄로 구현한 프레임워크를 검색, 일반 instruction-following, 코딩 agent에서 평가했으며, 코딩 워크플로에서는 약 6K개의 학습 예제로 Qwen3.5-9B의 SWE-bench Verified 성능을 41.8%에서 56.4%로 높였다. agent harness와 관련해서는 HarnessOpt-Bench, StateAct, Agent Safety 글을 함께 참조하라.
1 Introduction
기존 agentic RL은 지속적으로 확장되는 토큰 이력을 정책에 노출하지만, harnessed 설정은 중간의 harness 및 환경 상태가 잠재 변수인 독립 구성 프롬프트를 노출한다. 따라서 RL 프레임워크에서 agent loop를 다시 구현하지 않고도 기존 배포 harness를 학습에 사용할 수 있다.
2 Challenges
Trainer는 상호작용 loop를 제어하지 못하는 상황에서도 관찰한 가변 길이 모델 호출 시퀀스를 RL 샘플로 변환해야 한다. 논문은 retokenization과 샘플 병합, advantage 할당, loss normalization, 동적 샘플 수에 따른 scheduling을 핵심 과제로 제시한다.
비교 그림은 모델링 차이를 명확히 보여 준다. 기존 agentic RL은 연속 토큰 이력을 제공하는 반면 harnessed RL은 호출별 프롬프트를 제공하고, 결합한 harness 및 환경 상태를 잠재 상태로 둔다. 또한 multi-agent 실행과 handoff가 학습 샘플 수를 동적으로 만들 수 있는 이유를 보여 준다.
2.1 Retokenization and Sample Merging
호출 간 텍스트 수준의 연속성은 토큰 수준의 연속성을 보장하지 않는다. 갱신한 채팅 이력을 렌더링하면 토큰 경계, 템플릿 표식, 변환된 도구 출력이 달라질 수 있다. Agent Lightning은 이후 프롬프트가 이전 프롬프트와 응답으로 이루어진 정확한 토큰 수준 접두사를 가질 때만 호출을 병합하며, 그렇지 않으면 rollout 중 사용한 프롬프트를 보존하기 위해 새 샘플을 시작한다.
이 예시는 누적된 메시지 이력을 다시 렌더링할 때 동일한 텍스트라도 토큰 분절이 달라질 수 있음을 보여 준다. 따라서 텍스트 일치만으로는 시퀀스를 안전하게 병합하는 데 필요한 토큰 수준 연속성을 보장할 수 없다.
2.2 Advantage Calculation
토큰 접두사 병합 실패, subagent 분기, 컨텍스트 요약 때문에 하나의 rollout이 여러 샘플을 만들 수 있다. 저자들은 rollout의 모든 샘플에 outcome reward를 할당하지만, 우발적인 샘플 분할이 그룹 credit assignment를 바꾸지 않도록 그룹 baseline과 advantage는 rollout 수준에서 계산한다.
도식은 기존 agentic RL의 rollout 1개와 샘플 1개 간 대응을 여러 샘플을 생성하는 harnessed rollout과 대조한다. 그 결과 생성한 샘플이 아니라 rollout에 대해 그룹 baseline을 계산해야 하는 이유를 제시한다.
2.3 Loss Normalization
샘플 수준 normalization은 우연히 더 많은 샘플을 만든 rollout에 더 큰 최적화 가중치를 줄 수 있다. 선호하는 rollout 수준 token-mean loss는 각 rollout 안에서 응답 토큰 loss를 평균 내고 rollout에 동일한 가중치를 부여한다. 논문은 batch에 긴 음성 샘플이 많으면 일반적인 token-mean loss가 불안정해질 수 있다고 보고한다.
Batch에는 샘플 수와 응답 길이가 서로 다른 3개 rollout이 포함돼 있으며, token, sequence, rollout 수준 normalizer가 서로 다른 실효 가중치를 할당함을 보여 준다. 이는 rollout이 더 많은 샘플로 분할됐다는 이유만으로 영향력이 달라지는 규칙을 피해야 함을 뒷받침한다.
2.4 Training Backend Complexity
샘플 수와 시퀀스 길이는 harness 실행 후에야 알 수 있지만 GPU 병렬도는 고정돼 있다. Backend는 rollout 및 prompt-group 식별자를 보존하면서 가변 개수의 샘플을 평탄화하고, worker 간 작업을 균형 있게 배분하며, rollout 내부 정책 편차를 피하기 위해 각 rollout을 하나의 optimizer update 안에 유지해야 한다.
3 System Design
시스템은 VERL 기반의 API Gateway, Rollout Controller, Customized Trainer를 통해 학습과 실행을 분리한다. Gateway는 rollout 상태와 이벤트를 저장하고 OpenAI 호환 모델 호출을 proxy하며, controller는 외부 agent를 실행하고, trainer는 기록된 호출과 reward를 가져와 샘플을 구성하고 모델을 최적화한다.
개요는 agent harness와 Kubernetes 실행 환경을 inference 및 training engine에서 분리한다. API Gateway, Rollout Controller, Customized Trainer는 조정 계층을 이루며, 외부 harness가 LLM proxy를 통해 연결되고 실행 및 학습 자원은 분리된 상태로 유지되는 방식을 보여 준다.
3.1 Collocated Async RL
Collocated asynchronous RL은 하나의 GPU pool을 rollout 생성과 가중치 업데이트에 시분할로 사용한다. 충분한 rollout 데이터가 도착하면 API Gateway는 새 호출 수락을 중단하고 활성 호출이 끝날 때까지 기다린 뒤 업데이트를 허용한다. 논문은 분리된 pool을 쓰는 asynchronous RL보다 적은 GPU를 사용하면서 synchronous RL보다 약 2× 높은 end-to-end 속도를 보고한다.
일정은 synchronous 대기, rollout 및 update GPU pool을 분리한 asynchronous 실행, 하나의 pool을 공유하는 collocated asynchronous 실행을 대조한다. 제안한 일정은 별도 GPU pool을 할당하지 않으면서 가장 느린 rollout을 기다리는 문제를 피하도록 설계됐다.
3.2 Network Issues
API Gateway는 rollout 제어 endpoint를 idempotent하게 만들어 호출자가 네트워크 장애 후에도 안전하게 재시도할 수 있게 한다. 재시도한 LLM generation은 idempotent하게 만들 수 없으므로, trainer는 동일한 프롬프트를 가진 model_request 이벤트를 중복 제거하고 샘플 구성 시 가장 최근 호출만 유지한다.
3.3 Kubernetes Integration
Agent 실행은 Rollout Controller를 통해 표준 Kubernetes Job으로 수행되며, 디버깅을 위한 local-process 옵션도 제공한다. 따라서 상용 sandbox 서비스가 아니라 self-hosted 또는 on-premise rollout compute를 지원한다. Kubernetes에 대해서는 이 글을 참조하라. Kubernetes에 대해서는 이 글을 참조하라.
3.4 Monitoring
모니터링 시스템은 rollout 입력, 상태, 모델 요청, reward, 토큰 및 turn 통계, custom event, Kubernetes pod log를 기록한다. 이 기록은 수동으로 또는 AI agent를 사용해 검사할 수 있으며, 장애, 비정상 agent 동작, 네트워크 문제, reward hacking을 진단하는 데 사용한다.
4 Experiments
실험은 Search-R1-style 검색, LLM-in-Sandbox-style 일반 instruction following, SWE-smith 기반 코딩을 다룬다. 코딩 설정을 가장 상세히 다루며, 여기에는 데이터 filtering, reward-hacking 방지책, 제한된 자원으로 학습하기 위한 스크립트가 포함된다.
4.1 Search Agent
검색에서는 HotpotQA로 Llama-3.2-3B-Instruct를 GRPO로 학습하며, batch size는 512이고 프롬프트당 rollout은 4개다. 평가는 6개 QA dataset에서 각각 50개 예제를 샘플링한다. 보고한 validation reward는 25.1%에서 41.7%로 상승하며, 16.6-point 증가다.
검색-agent 학습 곡선은 전반적으로 상승하며, validation 곡선은 25.1%에서 41.7%로 오른다. 그림은 명시한 HotpotQA 및 GRPO 설정에서 보고한 학습 동역학을 제공한다.
4.2 General Instruction-Following Agent
일반 instruction following에서는 LLM-in-Sandbox harness와 Instruction Pre-Training dataset의 80/20 분할을 사용해 Qwen3-4B-Instruct-2507을 RLOO로 학습한다. batch size 8과 프롬프트당 8개의 rollout에서, 잡음이 있는 batch 수준 학습 reward에도 validation reward는 51.9%에서 70.2%로 상승한다.
학습-reward 곡선은 변동이 크지만 validation 곡선은 전반적으로 51.9%에서 70.2%로 상승한다. 그림은 잡음이 있는 on-policy batch reward와 보고한 held-out 성능 향상을 구분한다.
4.3 Coding Agent
코딩 agent는 Qwen3.5-9B, mini-SWE-agent, SWE-smith repository task를 결합한다. 평가는 신뢰할 수 있는 코딩-agent RL 신호를 얻기 위한 preprocessing, reward-hacking 완화책, rollout 수준 학습 선택을 검토한다.
4.3.1 Dataset Preprocessing and Filtering
저자들은 SWE-smith의 128개 repository에 걸친 59,136개 task에서 문제 설명이 비어 있거나, problem branch가 없거나, 테스트가 200개를 초과하는 기록을 제거한다. 4개의 rollout을 사용하는 난이도 filter는 성공과 실패가 섞인 약 5,000개 task를 남기고, 이후 4개의 rollout에서 모두 실패한 1,000개 task를 추가한다. 그 결과 약 6,000개의 학습 예제와 400개의 테스트 예제를 만든다.
4.3.2 Preventing Reward Hacking
관찰한 reward hacking에는 Git history를 통한 reference code 조회, wget 또는 curl, pip, urllib 같은 Python networking library 사용이 포함됐다. 저자들은 Git command를 비활성화하고 .git을 숨기며, 명시적으로 허용한 서비스를 제외한 일반 outbound access를 차단하는 Kubernetes network policy를 적용한다.
4.3.3 Training Dynamics
동일한 GRPO objective에서 rollout 수준 advantage와 rollout 수준 normalization은 step 128에서 38.2%로 가장 높은 코딩 validation reward를 달성한다. 이는 샘플 수준 advantage의 35.0%와 token-mean loss를 사용한 rollout 수준 advantage의 33.1%보다 높다. 선택한 checkpoint는 step 208에서 SWE-bench Verified 56.4%에 도달한다. rollout 중 하나의 완전히 병합된 row를 형성하는 비율은 36%뿐이고, rollout마다 평균 2.41개 샘플이 생성되므로 rollout 수준 처리가 필요하다.
rollout 수준 advantage와 rollout 수준 normalization 설정은 step 128에서 38.2%로 표시한 validation reward 중 가장 높은 값을 달성한다. 이 설정의 policy entropy는 token-mean loss를 사용하는 rollout 수준 advantage 변형보다 더 천천히 증가하고 더 안정적으로 유지되며, 코딩 agent에서 rollout 수준 normalization을 선호한다는 보고를 뒷받침한다.
왼쪽 패널은 평균 one-sample-rollout 비율 0.36을 보고하며, 오른쪽 패널은 rollout당 평균 2.41개 학습 샘플을 보고한다. 이 결과는 선택한 코딩 실행에서 동적 샘플 수가 일상적으로 발생함을 보여 준다.
5 Related Work
논문은 proxy 기반 접근을 기존 Agent Lightning architecture의 refactoring으로 규정하고 verl Uni-Agent, AReaL 2.0, slime v0.3.0, Polar를 논의한다. 논문이 제시한 차별점은 동적 샘플 수 선택의 명시적 처리, self-hosted Kubernetes 실행, 간결한 구현이다.
6 Conclusion
결론은 trainer가 기록된 모델 호출을 최적화하는 동안 배포 harness가 post-training에 직접 참여할 수 있음을 다시 강조한다. 보고한 증거는 3개 agent 설정에 걸쳐 있으며, 코딩 ablation은 특히 rollout 수준 advantage와 normalization 선택을 평가한다. 그러나 이를 광범위한 harness, 모델, objective에 걸쳐 검증하지는 않는다.
부록
- Appendix는 API Gateway의 데이터 모델과 endpoint, Kubernetes 및 local reconciler, Customized Trainer를 명시한다. Sample Adapter는 정확한 접두사에 한정한 병합, rollout 수준 advantage 계산, rollout 수준 token-mean normalization을 수행한다. Gateway 상태가 source of truth이며, Gateway와 Kubernetes 실행 상태 간에는 best-effort eventual consistency만 제공한다.
짧은 생각
논문은 서비스 경계에 묶인 agent 실행이 선형 토큰 trajectory에서 물려받은 가정을 어떻게 깨는지 유용하게 짚는다. 일치하지 않는 토큰 ID를 가진 retokenized prompt를 이어 붙이지 않는 선택은 관찰한 conditioning context를 보존한다. 다만 보고한 실험은 그에 따른 compute-reuse trade-off를 tree-structured training 또는 다른 proxy 기반 framework와 비교해 분리하지 않는다.