Agent Lightning v1.0: Towards Harnessed Agentic RL 요약 설명

목차

• 요약
• 2 Challenges
  • 2.1 Retokenization and Sample Merging
  • 2.2 Advantage Calculation
  • 2.3 Loss Normalization
  • 2.4 Training Backend Complexity
• 3 System Design
  • 3.1 Collocated Async RL
  • 3.2 Network Issues
  • 3.3 Kubernetes Integration
  • 3.4 Monitoring
• 4 Experiments
  • 4.1 Search Agent
  • 4.2 General Instruction-Following Agent
  • 4.3 Coding Agent
  • 4.3.1 Dataset Preprocessing and Filtering
  • 4.3.2 Preventing Reward Hacking
  • 4.3.3 Training Dynamics
• 부록
• 짧은 생각

이번 글에서는 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

영문판 보기

요약

• 이 논문은 배포 시점 harness가 컨텍스트 구성, 도구 사용, 환경 상호작용을 계속 제어하고 trainer는 proxy를 통해 LLM 요청-응답 쌍을 관찰하는 사후학습을 harnessed agentic RL로 정의한다. Agent Lightning v1.0은 임의의 harness를 지원하는 약 3,500줄 규모의 프레임워크다. token-faithful sample 구성, rollout 수준 통계, 재현 가능한 agent 학습을 다루며, 이 proxy 기반 설계를 최근 관련 시스템과 함께 위치시킨다. harness에 대해서는 이 글을 참조하라. harness에 대해서는 이 글을 참조하라. harness에 대해서는 이 글을 참조하라.

프레임워크는 harness의 LLM call을 API Gateway로 연결한다. Rollout Controller가 agent를 실행하고 Customized Trainer가 inference, 학습, sample adaptation, monitoring을 수행한다. Harness 실행은 inference 및 학습 engine과 분리된 Kubernetes cluster에서 수행할 수 있음을 보인다.

2 Challenges

전통적 agentic RL에서는 trainer가 연속된 token history를 유지하고 환경 상호작용 루프를 관리한다. Harnessed 실행에서는 harness와 환경 상태가 trainer에 잠재 상태로 남고, rollout은 길이가 가변적인 model call 집합으로 관측된다. 이 차이로 sample 구성, 가중치 부여, scheduling 문제가 생긴다.

비교는 전통적인 ReAct 방식의 연속 token history와 OAI-like API를 통해 전달되는 개별 구성 prompt를 대조한다. 추가된 harness state와 multi-agent orchestration 때문에 단일 실행이 동적으로 여러 training sample을 만들 수 있음을 보여 준다.

2.1 Retokenization and Sample Merging

Harness가 출력을 decode하고 갱신한 chat history를 retokenize하면 텍스트 수준 history prefix가 token 수준 연속성을 보장하지 않는다. Agent Lightning은 나중에 기록된 prompt가 정확한 token 수준 prefix와 일치할 때만 연속된 call을 병합한다. 그렇지 않으면 rollout 중 실제로 사용한 prompt에서 action을 평가하도록 새 sequence를 시작한다.

예시는 텍스트 "having"이 처음에는 "h"와 "aving" token fragment로 sample될 수 있지만, 이후에는 "hav"와 "ing"으로 retokenize될 수 있음을 보인다. 따라서 텍스트가 변하지 않아도 안전한 sequence merging에 필요한 정확한 token-prefix 조건이 깨질 수 있다.

2.2 Advantage Calculation

outcome reward를 받은 rollout 하나가 retokenization, subagent, 컨텍스트 요약 때문에 여러 sample로 나뉠 수 있다. 저자들은 우발적인 sample 분할이 rollout의 group 통계 기여를 바꾸지 않도록 GRPO group baseline과 advantage를 sample이 아니라 rollout 단위로 계산해야 한다고 주장한다.

Diagram은 같은 reward를 받은 2개의 rollout이 서로 다른 수의 sample을 만드는 모습을 보인다. 한 rollout은 3개 sample을 만들고 다른 rollout은 1개를 만든다. 이는 sample multiplicity가 reward baseline을 바꾸지 않도록 group 통계를 rollout 수준에서 계산해야 함을 뒷받침한다.

2.3 Loss Normalization

Sample 수준 정규화는 우연히 더 많은 sequence를 만든 rollout에 과도한 가중치를 줄 수 있다. 프레임워크는 각 rollout 안에서 response-token loss를 평균한 뒤 rollout 간 평균을 내는 rollout 수준 token-mean loss를 사용한다. 저자들은 batch 전체 token-mean loss가 긴 negative sample이 많은 batch에 민감했다고 보고한다.

3개의 rollout은 서로 다른 sample 수와 response length를 가진다. 각각 길이 50과 100인 2개 sample, 길이 30인 3개 sample, 길이 40인 1개 sample로 구성된다. 이 구조는 token, sequence, rollout 수준 정규화가 서로 다른 유효 가중치를 부여하는 이유를 보여 준다.

2.4 Training Backend Complexity

Sample 수와 sequence 길이는 harness 실행 뒤에야 알 수 있지만 GPU 병렬 구성은 고정돼 있다. Backend는 flattening 뒤에도 rollout과 prompt-group identity를 유지해야 한다. 또한 한 rollout의 sequence를 같은 optimizer update에 넣고, rollout 내부 policy skew 없이 token workload를 균형 있게 배분해야 한다.

3 System Design

시스템은 API Gateway, Rollout Controller, VERL 기반 Customized Trainer로 agent 실행과 학습을 분리한다. Gateway는 rollout lifecycle state와 event를 저장한다. Controller는 이 상태를 Kubernetes Job 또는 local process와 조정하고, trainer는 event를 가져와 학습 sample을 재구성한다.

3.1 Collocated Async RL

Collocated asynchronous RL은 rollout 생성과 weight update가 GPU pool 하나를 시간 분할로 공유한다. 충분한 rollout data가 쌓이면 Gateway는 새 요청 수락을 멈추고 활성 요청이 끝날 때까지 기다린 뒤 update를 수행하고 rollout 서비스를 재개한다. 논문은 별도 pool asynchronous RL보다 적은 GPU를 쓰면서 synchronous RL보다 종단 간 속도가 약 2× 빨랐다고 보고한다.

Synchronous RL에서는 느린 rollout 때문에 device가 대기하는 반면, 별도 pool asynchronous RL은 추가 GPU를 사용한다. Collocated schedule은 같은 4개 GPU에서 부분 rollout 작업과 update를 교차 수행한다. 이는 synchronous RL 대비 보고된 약 2× 종단 간 속도 향상의 근거를 보여 준다.

3.2 Network Issues

API Gateway의 rollout-control endpoint는 idempotent하므로 network failure 뒤에도 상태 변경을 중복하지 않고 재시도할 수 있다. 재생성한 LLM call 자체는 idempotent하게 만들 수 없으므로 trainer는 같은 prompt를 가진 반복 model_request event를 중복 제거하고 가장 최신 call을 유지한다.

3.3 Kubernetes Integration

Rollout Controller는 agent 실행을 표준 Kubernetes Job으로 실행하고 debugging용 local process-pool backend도 제공한다. Kubernetes는 교체 가능한 실행 backend로 취급한다. 따라서 commercial sandbox service 없이 self-hosted 또는 on-premise 환경에서 실행할 수 있다.

3.4 Monitoring

Customized Trainer는 학습 및 validation rollout, model request, reward, custom event, Kubernetes pod log를 기록한다. 이 기록으로 connectivity failure, 바람직하지 않은 동작, reward-hacking 사례를 수동 또는 AI 지원 방식으로 진단할 수 있다.

4 Experiments

평가는 Search-R1-style 검색, LLM-in-Sandbox-style 일반 instruction following, SWE-smith 기반 coding task를 다룬다. Search validation reward는 25.1%에서 41.7%로, instruction-following validation reward는 51.9%에서 70.2%로 상승한다. Coding 실험에서는 rollout 수준 학습 선택지를 비교한다.

4.1 Search Agent

검색 실험에서 저자들은 HotpotQA로 Llama-3.2-3B-Instruct를 GRPO 학습한다. Prompt당 4개의 rollout과 batch size 512를 사용한다. HotpotQA, 2WikiMultiHopQA, MuSiQue, Bamboogle, TriviaQA, Natural Questions에서 각각 50개 example을 sample하고 exact match를 reward로 사용한다. Validation은 16.6 percentage points 향상된다.

Search-agent training reward는 140 step 동안 상승하고 validation reward는 약 0.25에서 0.417로 증가한다. 이 그림은 명시한 Search-R1-style setting에서 보고한 validation reward의 25.1%에서 41.7%로의 향상을 뒷받침한다.

4.2 General Instruction-Following Agent

일반 instruction following에서는 Qwen3-4B-Instruct-2507을 LLM-in-Sandbox harness와 Instruction Pre-Training dataset의 80/20 split으로 RLOO 학습한다. Batch size 8과 prompt당 8개의 rollout을 사용하면 noisy한 batch 수준 training reward에도 validation reward가 18.3 percentage points 향상된다.

Instruction-following training reward는 크게 변동하지만 validation reward는 약 0.519에서 0.702로 상승하는 추세를 보인다. 이는 noisy한 batch별 feedback과 보고한 validation gain을 구분해 보여 준다.

4.3 Coding Agent

Coding agent는 Qwen3.5-9B와 mini-SWE-agent를 결합해 repository를 수정하고 SWE-smith 기반 task에서 task-specific test를 실행한다. 논문은 사용 가능한 coding-agent RL 예제가 usable data, complete script, 환경 설정, 제한된 자원에서의 재현성 측면에서 부족하다고 보므로 이 setting에 집중한다.

4.3.1 Dataset Preprocessing and Filtering

SWE-smith의 128개 repository에 걸친 59,136개 task에서 pipeline은 빈 problem statement, 누락된 problem branch, 200개 초과 test가 있는 record를 제거한다. Qwen3.5-9B를 candidate마다 4회 실행해 항상 해결한 task를 제거한다. 성공과 실패가 섞인 task에서 약 5,000개 example을 얻고, 항상 실패한 task 1,000개를 추가해 약 6,000개 training example과 400개 test example을 만든다.

4.3.2 Preventing Reward Hacking

저자들은 agent가 Git history, wget 또는 curl을 통한 GitHub download, pip source download, urllib 같은 Python networking library로 reference source를 얻는 사례를 관찰했다. 이에 Git command를 비활성화하고 .git을 숨기며, 명시적으로 whitelist된 service 외 일반 outbound access를 차단하는 Kubernetes network policy를 적용한다.

4.3.3 Training Dynamics

같은 GRPO objective에서 Rollout-level Advantage + Rollout-level Norm은 step 128에서 38.2%로 가장 높은 validation reward를 기록한다. 이는 Sample-level Advantage의 35.0%와 Rollout-level Advantage의 33.1%보다 높다. 이 checkpoint는 step 208에서 SWE-bench Verified 56.4%에 도달해 41.8%에서 상승한다. 논문은 multi-seed uncertainty나 다른 harnessed-RL framework와의 직접적인 end-to-end 비교를 보고하지 않는다.

Merging diagnostic은 one-sample-rollout ratio의 평균이 0.36이고 rollout당 sample 수의 평균이 2.41 samples라고 보고한다. 이는 보고한 coding run에서 동적 sample 분할이 드문 edge case가 아니라 흔한 현상임을 보여 준다.

부록

• Appendix는 rollout, event, model registration, OpenAI-compatible proxy call을 위한 최소 Gateway API를 명시한다. Controller는 best-effort eventual consistency를 갖는 Kubernetes watch-plus-list reconciliation을 사용한다. Sample Adapter는 exact-prefix merging, rollout 수준 advantage, rollout 수준 token-mean normalization을 구현한다.

짧은 생각

논문은 배포 harness의 동작이 각 rollout이 하나의 token-continuous training sequence라는 가정을 어떻게 무효화하는지 명확히 짚는다. Coding 실험은 한 setting에서 제안한 rollout 수준 조합을 뒷받침한다. 다만 일반성에 관한 더 넓은 주장을 하려면 개별 설계 선택지를 분리하는 multi-harness, multi-model, multi-seed ablation이 필요하다.