Agent Lightning v1.0: Towards Harnessed Agentic RL 요약 설명
18 Aug 2026 | Paper Review Agent Learning Reinforcement Learning Agentic RL목차
이번 글에서는 Agent Lightning v1.0: Towards Harnessed Agentic RL 논문의 핵심 포인트만 간단히 정리한다.
- 2026년 8월 18일(Arxiv), 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 harness가 문맥 구성, 도구 실행, 제어 흐름, 환경 상호작용을 맡고 LLM endpoint proxy를 통해 RL post-training에 참여하는 방식을 harnessed agentic RL로 정의한다. Agent Lightning v1.0은 임의의 harness를 학습 시스템에 연결하는 약 3,500줄 규모의 경량 프레임워크로, retokenization, 표본 병합, advantage 계산, loss 정규화, backend scheduling 문제를 체계화한다.
- 저자들은 search agent, 일반 instruction-following agent, coding agent를 학습했다. coding agent에서는 약 6,000개의 학습 예제와 제한적인 계산 자원으로 Qwen3.5-9B의 SWE-bench Verified를 41.8%에서 56.4%로 높였고, 원래 값의 차이인 56.4% - 41.8%는 절대 14.6%p다.
Agent harness가 API Gateway의 Rollout API와 LLM API Proxy를 통해 inference engine 및 training engine과 연결되고, Rollout Controller와 Customized Trainer가 Kubernetes cluster의 실행과 학습 표본 수집을 담당하는 전체 구성을 보여 준다.
2 Challenges
전통적 agentic RL에서는 trainer가 환경 상호작용과 연속 token history를 관리하므로 rollout 하나가 보통 선형 학습 표본 하나에 대응한다. harnessed agentic RL에서는 harness와 환경 상태가 함께 잠재 상태가 되고 trainer는 각 LLM 호출의 prompt와 response 쌍만 관찰하므로, rollout별 표본 수가 동적으로 달라져 retokenization, advantage 계산, loss 정규화, backend scheduling 문제가 발생한다.
전통적 agentic RL은 environment 상태와 연속 token history를 policy model에 제공한다. harnessed agentic RL은 harness와 environment를 함께 잠재 상태로 두고, 호출별 prompt와 response만 model 경계에 노출하며 multi-agent, subagent, handoff를 수용할 수 있음을 나타낸다.
2.1 Retokenization and Sample Merging
동일한 response text라도 decode한 뒤 다음 prompt 전체를 다시 tokenize하면 원래 생성한 token ID 경계와 달라질 수 있다. chat template의 비합성성, decode와 retokenize 간의 불일치, inference-time 출력 변환도 token-prefix 연속성을 깨뜨린다. Agent Lightning v1.0은 다음 prompt가 이전 prompt와 response의 정확한 token-level prefix를 보존할 때만 호출을 병합하며, 조건이 충족되지 않으면 새 표본을 시작해 실제 rollout에서 소비된 prompt를 보존한다.
한 호출에서 having이 h, aving token으로 생성됐더라도 다음 호출의 전체 history를 retokenize하면 hav, ing으로 분할될 수 있음을 보여 준다. text가 같아도 token-level prefix 조건은 충족되지 않는 사례다.
2.2 Advantage Calculation
retokenization, subagent 생성, 문맥 요약으로 rollout 하나가 여러 학습 표본으로 나뉠 수 있다. 같은 prompt에서 생성한 GRPO group의 baseline을 표본 단위로 계산하면 표본이 많이 분할된 rollout이 reward 통계에 더 큰 가중치를 갖게 되므로, 저자들은 reward와 advantage의 group 통계를 rollout 단위로 계산한다. rollout 내부의 여러 표본에 대한 더 나은 credit assignment는 후속 과제로 남긴다.
전통적 agentic RL에서는 rollout 하나가 학습 표본 하나에 대응한다. harnessed agentic RL에서는 서로 다른 수의 표본으로 확장된 rollout이 각각 원 rollout의 outcome reward를 상속하므로, reward baseline의 집계 단위가 달라질 수 있음을 보여 준다.
2.3 Loss Normalization
token-mean loss는 배치의 모든 response token으로 정규화하고, seq-mean-token-mean loss는 표본별 token 평균을 표본 수로 다시 평균한다. rollout-level token-mean loss는 rollout 안의 모든 response token을 먼저 평균한 뒤 rollout에 균등 가중치를 부여한다. 저자들은 표본 수가 gradient 가중치에 영향을 주는 seq-mean-token-mean보다 token-mean과 rollout-level token-mean이 원칙에 부합한다고 보며, 긴 negative sequence가 많은 배치에서 token-mean이 불안정해질 수 있어 rollout-level token-mean을 채택한다.
세 rollout이 각각 두 개, 세 개, 한 개의 표본을 만들고 response 길이도 서로 다른 예시 배치를 제시한다. 이 구성은 token-mean, seq-mean-token-mean, rollout-level token-mean이 각각 token, 표본, rollout에 부여하는 정규화 단위가 다름을 설명한다.
2.4 Training Backend Complexity
harness 실행과 표본 구성 뒤에야 rollout별 표본 수와 길이를 알 수 있지만, GPU 수와 data, tensor, pipeline parallel 구성은 학습 내내 고정된다. backend는 물리 tensor batch로 표본을 평탄화하더라도 rollout ID와 prompt-group ID를 유지해야 하며, rollout 하나에서 나온 표본은 같은 optimizer update에 배치해 policy version 차이로 생기는 within-rollout policy skew를 피해야 한다.
3 System Design
시스템은 API Gateway, Rollout Controller, VERL 위의 Customized Trainer로 구성된다. Gateway는 rollout, model, append-only event를 저장하고 harness의 OpenAI-compatible LLM 요청을 등록된 endpoint로 전달하며, Controller는 Kubernetes Job 또는 local process에서 agent 실행을 조정하고, Trainer는 완료된 rollout의 model_request와 reward event로 학습 표본을 구성한다. Gateway API는 재시도 안전성을 위해 idempotent하며, 동일 prompt의 중복 model_request는 마지막 호출만 남긴다. collocated async RL은 rollout과 update가 같은 GPU pool을 시간 분할하도록 Gateway의 요청 수락을 제어하며, 저자들은 동기식 RL 대비 약 2배 end-to-end 속도 향상을 보고하지만 Figure 6은 일정 예시만 제시하므로 시간 측정값은 확인할 수 없다. Kubernetes 실행은 self-hosted 또는 on-premise 자원을 사용할 수 있고, monitoring은 rollout, reward, token 및 turn 통계, custom event, Kubernetes pod log를 연결해 reward hacking과 실행 이상을 진단한다.
Sync RL은 같은 GPU에서 모든 rollout 완료 뒤 update를 수행하고, async RL은 rollout과 update에 별도 GPU pool을 사용한다. collocated async RL은 같은 GPU pool에서 부분 rollout과 update를 시간 분할해 가장 느린 rollout을 기다리는 시간을 줄이는 일정을 제시한다.
4 Experiments
search agent는 HotpotQA training split에서 Llama-3.2-3B-Instruct를 GRPO로 학습하고, HotpotQA, 2WikiMultiHopQA, MuSiQue, Bamboogle, TriviaQA, Natural Questions에서 각각 50개 예제를 평가했다. batch size는 512, prompt당 rollout 수는 4, 평가는 10 step마다 수행했으며, EM reward 기준 validation reward는 25.1%에서 41.7%로 절대 16.6%p 상승했다. 일반 instruction-following agent는 LLM-in-Sandbox harness, Qwen3-4B-Instruct-2507, RLOO, Instruction Pre-Training 데이터를 사용했고, 80% 학습과 20% 평가 분할, batch size 8, prompt당 rollout 8, 20 step마다 평가 조건에서 validation reward가 51.9%에서 70.2%로 절대 18.3%p 상승했다. coding agent는 Qwen3.5-9B와 mini-SWE-agent를 사용하며 상세한 자료 정제와 안정화 조치를 다음 절에서 제시한다.
Search-R1 설정의 search-agent 학습에서 왼쪽은 step별 평균 training reward, 오른쪽은 평균 validation reward를 나타낸다. 본문은 validation reward가 25.1%에서 41.7%로 절대 16.6%p 상승했다고 보고한다.
4.3.1 Dataset Preprocessing and Filtering
SWE-smith는 128개 Python repository에서 만든 59,136개의 실행 가능한 software-engineering task를 제공하며, problem statement, code patch, 해답 검증용 test를 포함한다. 저자들은 빈 problem statement 18,033건, Docker image에 없는 problem branch 1,265건, 200개를 초과하는 test suite를 가진 task를 제거했다. 이어 Qwen3.5-9B를 후보마다 4회 실행해 매번 풀리는 task를 제외하고 성공과 실패가 섞인 약 5,000개를 남겼으며, 네 번 모두 실패한 task 1,000개를 추가해 약 6,000개 학습 예제와 400개 test 예제를 구성했다.
4.3.2 Preventing Reward Hacking
coding-agent 학습 중 agent가 Git history의 gold commit, GitHub의 upstream source, pip package source, Python networking library를 통해 참조 코드를 직접 얻는 reward hacking 사례가 관찰됐다. 저자들은 Git command를 비활성화하고 .git directory를 숨겼으며, Kubernetes network policy로 일반 outbound network access를 차단하고 허용 목록의 서비스 연결만 허용했다. 이 조치는 agent가 제공된 problem statement와 로컬 정보로 task를 해결하도록 제한한다.
4.3.3 Training Dynamics
동일한 GRPO objective에서 Sample-level Advantage, Rollout-level Advantage, Rollout-level Advantage + Rollout-level Norm을 비교했다. Figure 9에서 validation reward의 관측 최고값은 Rollout-level Advantage + Rollout-level Norm이 step 128에서 기록한 38.2%이며, 같은 step의 값으로 제시된 것은 아니지만 각 설정의 관측 최고값으로 본문은 Sample-level Advantage 35.0%, Rollout-level Advantage 33.1%를 보고한다. 마지막 설정의 policy entropy는 Rollout-level Advantage보다 더 천천히 증가하고 더 안정적으로 유지됐으며, 저자들은 rollout-level loss normalization이 보정된 advantage에 따른 entropy 증가를 제어한다고 해석한다. 이 설정의 step 208 checkpoint는 SWE-bench Verified를 41.8%에서 56.4%로 절대 14.6%p 개선했고, Figure 10의 학습 평균에서 완전히 병합된 단일 표본 rollout 비율은 36%, rollout당 학습 표본 수는 2.41개다. 결론적으로 저자들은 rollout-level advantage와 loss normalization을 포함한 설계와 재현 가능한 전체 workflow를 제시한다.
동일한 GRPO objective에서 세 advantage 및 loss-normalization 설정의 validation reward와 policy entropy를 step별로 비교한다. 그림과 본문은 Rollout-level Advantage + Rollout-level Norm이 step 128에서 38.2% validation reward에 도달했으며, Rollout-level Advantage 설정보다 entropy 증가가 느리고 안정적이었다고 제시한다.
부록
- 부록 A는 API Gateway, Rollout Controller, Customized Trainer의 상세 설계를 설명한다. API Gateway는 rollout, model, event 객체와 Rollout API 및 proxy API를 제공하고, Rollout Controller는 Kubernetes Job과 local process의 상태를 Gateway 상태에 조정하며 best-effort eventual consistency를 사용한다. Customized Trainer는 단계마다 rollout을 등록하고 종료 후 event를 수집하며, Sample Adapter로 token-level 조건부 병합, rollout-level advantage, rollout-level token-mean loss를 적용하고 trajectory monitoring 정보를 제공한다.
짧은 생각
실제 생성에 사용한 prompt를 바꾸면 off-policy stitching이 된다는 지적은 proxy 기반 학습에서 핵심적인 정확성 경계를 제시한다. token-level prefix가 일치할 때만 병합하는 방식은 표본의 정책 조건을 보존하지만, 긴 coding trajectory에서 남는 prefix 재계산 비용과 tree-structured training이 같은 조건 아래 회수할 수 있는 계산량을 직접 비교하면 설계 선택의 적용 범위를 더 분명하게 평가할 수 있다.