컴백부터 K-뷰티까지 — K-컬쳐의 모든 것을 메일로 받아보세요메일로 받아보기

METAL MEDIA

코딩 AI 에이전트를 강화학습으로 훈련시킬 때 생기는 거짓 신호와 속도 문제를 잡아주는 틀, LEGO-RL

arXiv:2608.173932026-08-17

LEGO-RL: Harness-Native Reinforcement Learning for Coding Agents

코딩 AI 에이전트를 강화학습으로 훈련시킬 때 생기는 거짓 신호와 속도 문제를 잡아주는 틀, LEGO-RL

LEGO-RL은 Claude Code, OpenHands SDK, OpenCode 같은 기존 코딩 에이전트 프로그램을 건드리지 않은 채로 강화학습 훈련에 연결해주는 프레임워크다. 실행 환경 오류나 보상 조작으로 학습 신호가 오염되는 문제, 그리고 실제 행동과 학습 계산이 어긋나는 문제를 동시에 해결한다. Qwen3.5-35B-A3B 모델을 세 가지 에이전트 환경에서 훈련시킨 결과 SWE-bench Verified 문제 해결률이 모두 크게 올랐다.

METAL MEDIA 해설 도표

코딩 AI 에이전트를 강화학습으로 훈련시킬 때 생기는 거짓 신호와 속도 문제를 잡아주는 틀, LEGO-RL

  1. 01강화학습으로 코딩 에이전트를 훈련시키려면 에이전트가 실제로 사용하는 프로그램(하니스)의 내부 동작을 손대지 않으면서도, 그 안에서 실제로 어떤 토큰이 생성됐는지 정확히 기록해야 하는데 기존 방식은 이를 놓치기 쉬웠다
  2. 02LEGO-RL은 모델 호출이 오가는 지점에 프록시를 심어 실제 생성된 토큰과 확률값을 그대로 포착하고, 여러 전문가 모델 중 일부만 쓰는 구조(MoE)에서도 훈련 시 그 선택을 그대로 재현하도록 만들었다
  3. 03샌드박스(격리된 실행 공간)에서 이미지 캐싱과 단계별 방어 장치를 두어 코드가 몰래 채점 정보를 훔쳐보는 식의 보상 조작을 막고, 훈련 도중 실패한 시도가 전체 학습을 방해하지 않도록 걸러낸다
  4. 04실시간 모니터링 화면(Live UI)을 통해 어떤 단계에서 실패가 나는지, 어떤 작업이 풀리고 안 풀리는지를 사람이 직접 들여다보고 진단할 수 있게 했다
  5. 05OpenHands SDK에서 64.0%→70.4%, Claude Code에서 62.4%→68.2%, OpenCode에서 57.2%→66.6%로 SWE-bench Verified 해결률이 올랐고, 롤아웃 시점과 학습 시점의 확률 값 일치도가 0.99 이상으로 유지됐다
METAL MEDIA이 원문을 바탕으로 재구성한 해설 도표이며, 논문 저자의 원문 figure가 아닙니다.

무엇을 했나

  1. 강화학습으로 코딩 에이전트를 훈련시키려면 에이전트가 실제로 사용하는 프로그램(하니스)의 내부 동작을 손대지 않으면서도, 그 안에서 실제로 어떤 토큰이 생성됐는지 정확히 기록해야 하는데 기존 방식은 이를 놓치기 쉬웠다
  2. LEGO-RL은 모델 호출이 오가는 지점에 프록시를 심어 실제 생성된 토큰과 확률값을 그대로 포착하고, 여러 전문가 모델 중 일부만 쓰는 구조(MoE)에서도 훈련 시 그 선택을 그대로 재현하도록 만들었다
  3. 샌드박스(격리된 실행 공간)에서 이미지 캐싱과 단계별 방어 장치를 두어 코드가 몰래 채점 정보를 훔쳐보는 식의 보상 조작을 막고, 훈련 도중 실패한 시도가 전체 학습을 방해하지 않도록 걸러낸다
  4. 실시간 모니터링 화면(Live UI)을 통해 어떤 단계에서 실패가 나는지, 어떤 작업이 풀리고 안 풀리는지를 사람이 직접 들여다보고 진단할 수 있게 했다
  5. OpenHands SDK에서 64.0%→70.4%, Claude Code에서 62.4%→68.2%, OpenCode에서 57.2%→66.6%로 SWE-bench Verified 해결률이 올랐고, 롤아웃 시점과 학습 시점의 확률 값 일치도가 0.99 이상으로 유지됐다
Figure 1: Overview of the Lego-RL training infrastructure.
Figure 1: Overview of the Lego-RL training infrastructure.
Table 1: Comparison of representative agentic RL frameworks. ✓: supported; △: partial/conditional support; –: not reported. R3: rollout routing replay. Observability denotes monitoring training runs and diagnosing execution- or trajectory-level failures.
Harness-native fidelityExecution & rewardObservability
FrameworkBlack-box harnessToken-in/ Token-outHistory alignmentR3Fully asyncSandbox executionReward-hack defenseTraining observability
verl (Sheng et al. 2025)
slime (THUDM 2025)
MOLT (NVIDIA NeMo 2026)
SkyRL-Agent (Cao et al. 2025)
AReaL (Fu et al. 2025)
Agent Lightning (Luo et al. 2025)
Polar (Xu et al. 2026)
rLLM (Berkeley Sky Computing Lab 2026)
OpenForgeRL (Yu et al. 2026)
ALE (ROLL/ROCK) (Wang et al. 2025a)
Lego-RL
Figure 2: Closed-loop operational workflow of Lego-RL. The five stages cover data preparation, run validation, training, live observability, and human review. Stage (3) corresponds to the training infrastructure shown in Figure 1, while the agent plugin acts as the control plane.
Figure 2: Closed-loop operational workflow of Lego-RL. The five stages cover data preparation, run validation, training, live observability, and human review. Stage (3) corresponds to the training infrastructure shown in Figure 1, while the agent plugin acts as the control plane.
Table 2: SWE-bench Verified performance across the three coding agents. All numbers are measured by us under the same harness version and evaluation protocol (temperature 0.7, 200 turns, 200k context budget).
Coding agentModelSWE-bench Verified (%)
OpenHands SDKQwen3.5-35B-A3B (Qwen Team 2026a)64.0
Qwen3.6-35B-A3B (Qwen Team 2026b)67.4
KAT-Coder-V2.5-Dev (KwaiKAT Team 2026)67.0
Lego-RL-Qwen3.5-35B-A3B70.4​(+6.4)
Claude CodeQwen3.5-35B-A3B (Qwen Team 2026a)62.4
Qwen3.6-35B-A3B (Qwen Team 2026b)63.4
KAT-Coder-V2.5-Dev (KwaiKAT Team 2026)66.8
Lego-RL-Qwen3.5-35B-A3B68.2​(+5.8)
OpenCodeQwen3.5-35B-A3B (Qwen Team 2026a)57.2
Qwen3.6-35B-A3B (Qwen Team 2026b)60.6
KAT-Coder-V2.5-Dev (KwaiKAT Team 2026)64.8
Lego-RL-Qwen3.5-35B-A3B66.6​(+9.4)
Figure 3: Training behavior of OpenHands SDK, Claude Code, and OpenCode over three epochs (126 training steps), showing training reward, validation reward, policy entropy, and mean response length.
Figure 3: Training behavior of OpenHands SDK, Claude Code, and OpenCode over three epochs (126 training steps), showing training reward, validation reward, policy entropy, and mean response length.
Table 3: Rollout-to-training alignment over the three matched production runs: probabilities captured at the serving boundary against trainer-side recomputation over the corresponding assistant tokens. All statistics are medians over training steps.
|Δ​log⁡p¯| per trajectory (×10−3)
Coding agentPearson rKL (×10−3)p50p90p99
OpenHands SDK0.99930.750.71.22.1
Claude Code0.99801.350.71.32.7
OpenCode0.99930.600.61.12.0
Figure 4: Trajectory termination profiles across agent scaffolds. Bars show the proportion of trajectories by termination reason; timeout and environment-setup failures are excluded from optimization.
Figure 4: Trajectory termination profiles across agent scaffolds. Bars show the proportion of trajectories by termination reason; timeout and environment-setup failures are excluded from optimization.
Table 4: Stage-wise wall-clock statistics across 3,699 OpenHands SDK training trials. Mean-time fraction is computed relative to the mean total trial duration; Other includes scheduling, trajectory handling, and sandbox cleanup.
StageMean (s)p50p90p99Mean-time fraction
Sandbox setup21.67.741.8275.22.3%
Agent setup4.24.04.88.40.5%
Agent execution840.5708.41604.32801.191.3%
Verification35.94.129.6928.53.9%
Other20.38.112.3965.52.2%
Trial total920.4770.01742.73189.1100%
Figure 5: In-batch reward distributions across training. (a–c) Distribution of tasks by the number of successful rollouts out of eight in the first and last epoch for each scaffold. The 0/8 and 8/8 groups provide no group-relative advantage. (d) Combined proportion of these zero-variation groups across epochs.
Figure 5: In-batch reward distributions across training. (a–c) Distribution of tasks by the number of successful rollouts out of eight in the first and last epoch for each scaffold. The 0/8 and 8/8 groups provide no group-relative advantage. (d) Combined proportion of these zero-variation groups across epochs.
Table 5: Ablation of sandbox optimizations.
Median latencyPaired ratio
OptimizationStageWithWithoutMedianp10–p90n
Lazy image pullsandbox setup1.57 s2.66 s1.7×100
Prebuilt task imagesandbox setup1.04 s36.2 s33.2×17.9–67.5×50
Mounted agent runtimeagent setup0.51 s7.82 s15.4×14.5–16.6×50
Packaged grading toolchainverification3.81 s2.72 s0.71×0.67–0.73×50
Figure 6: Task-selection ablation across four 951-task pools. (a) Held-out validation solve rate, measured over the validation tasks that executed. (b) Training verifier reward; levels are pool-specific, so only the slopes are comparable.
Figure 6: Task-selection ablation across four 951-task pools. (a) Held-out validation solve rate, measured over the validation tasks that executed. (b) Training verifier reward; levels are pool-specific, so only the slopes are comparable.
Table 6: Reward-integrity failure modes and their mitigations. Incidence rates are measured prior to deploying the defenses; “—” indicates cases not separately quantified.
Failure ModeIncidenceDefense
Agent-side: shortcut exploitation
Reads git history4.6–20.5%Rebase history to a single commit during agent phase; restore before grading
Downloads reference fix1.9%Per-phase egress firewall in privilege-separated sidecar
Edits test files2.4–19.4%Withhold tests until grading; revert test-path edits
Environment-side: reward detached from agent
Grader applies reference patch2.5%Audit affected instances out of pool; flag live if degenerate reward propagates
Grader requires network accessPackage all grade-time dependencies; ensure deterministic invocation
Incomplete repository buildHermetic fail-fast build; report setup failure explicitly, not as zero reward
Figure 7: Failure diagnosis with the Live UI. (a) Per-step termination reasons for an environment-failure run. (b) Assisted analysis of a collapsed run and the corresponding early-stop condition. (a) and (b) are two different diagnostic runs, neither is the Claude Code production run reported elsewhere in this section.
Figure 7: Failure diagnosis with the Live UI. (a) Per-step termination reasons for an environment-failure run. (b) Assisted analysis of a collapsed run and the corresponding early-stop condition. (a) and (b) are two different diagnostic runs, neither is the Claude Code production run reported elsewhere in this section.
Table 7: Routing-replay configurations compared. Expert overlap and top-1 agreement are undefined when replay is disabled.
Routing replay configurationPearson rMean |Δ​p|Expert overlapTop-1 agreement
Disabled0.99460.0062
Enabled, misaligned0.75030.09540.0830.026
Enabled, aligned0.99930.00250.9960.985
Figure 8: Behavioral analysis with the Live UI, Claude Code run. (a) Tool-use trajectories for eight rollouts of one task. (b) Task-level solve rates in the first and last sampled epochs.
Figure 8: Behavioral analysis with the Live UI, Claude Code run. (a) Tool-use trajectories for eight rollouts of one task. (b) Task-level solve rates in the first and last sampled epochs.
Table 8: Evidence supplied for the collapsed run. t is the least-squares slope divided by its standard error over all logged steps; the gradient norm does not clear |t|=2 and is therefore read as noise. Tokens per turn is a ratio of two rows above it and carries no separate trend statistic.
SeriesFirst five stepsLast five stepst
training reward0.3510.050−7.5
turns per trajectory18.90.96−14.8
response length (tokens)12,1702,276−7.7
tokens per turn6502,397
policy entropy0.1340.230+7.2
KL term of the loss0.00460.130+3.4
rollout–training agreement0.9950.970−3.3
gradient norm0.310.034+0.4
Figure 9: Trainer schedule under synchronous and asynchronous execution.
Figure 9: Trainer schedule under synchronous and asynchronous execution.
Table 9: Agent behaviors before and after training, over 420 trajectories at each end of the production OpenHands SDK run; the pass@k rows are over prompt groups in the first and last third of the run.
BehaviorFirstLastΔ
Reads back a file it edited73.6%98.1%+24.5
Runs the test suite85.0%93.6%+8.6
Files explored before 1st edit3.456.92+3.47
Ends with an explicit finish88.3%91.9%+3.6
Reproduces failure before editing6.7%11.2%+4.5
Solves despite a failed command63.9%66.8%+2.9
Malformed tool calls (of all calls)1.07%0.15%−0.92
Coverage, pass@883.2%87.9%+4.7
Reliability, pass828.3%39.4%+11.1
Figure 10: Lazy versus full image delivery over the same 100 task images. Nydus streams image chunks on demand, whereas OCI denotes the conventional pull, which materializes the entire image before the container starts. The panels report startup latency, cumulative network and disk traffic, and in-container read throughput.
Figure 10: Lazy versus full image delivery over the same 100 task images. Nydus streams image chunks on demand, whereas OCI denotes the conventional pull, which materializes the entire image before the container starts. The panels report startup latency, cumulative network and disk traffic, and in-container read throughput.
Table 10: Resolved hyperparameters of the three production runs (Qwen3.5-35B-A3B through the OpenHands SDK, Claude Code, and OpenCode).
Policy lossGSPO
Clip range (sequence-level)(3×10−4, 4×10−4)
Advantage estimatorGRPO
Loss aggregationseq-mean-token-mean
KL reward penaltynone
KL loss coefficient10−3
Learning rate1×10−6
Learning-rate scheduleconstant
Gradient clip1.0
Prompts per batch64
Rollouts per prompt8
Micro-batch per GPU1
Rollout temperature1.0
Rollout top-p1.0
Validation temperature0.7
Validation samples per instance1
Prompt budget30k tokens
Response budget170k tokens
Staleness threshold1
Partial-rollout recoveryon
Importance-sampling correctionoff
Training pool2,699 tasks
Epochs3
Figure 11: Reasoning share of the response over training on a fixed 120-task validation cohort. (a) Mean over tasks (solid) and character-weighted mean (dashed); (b) Median share at each task’s first (open) and last (filled) sampled epoch, grouped by number of rollouts solved.
Figure 11: Reasoning share of the response over training on a fixed 120-task validation cohort. (a) Mean over tasks (solid) and character-weighted mean (dashed); (b) Median share at each task’s first (open) and last (filled) sampled epoch, grouped by number of rollouts solved.

왜 중요한가

코딩 에이전트를 강화학습으로 개선하려는 연구자와 기업이 기존에 이미 잘 만들어둔 에이전트 프로그램을 새로 뜯어고치지 않고도 안전하게 성능을 끌어올릴 수 있는 실용적 도구를 준다. 훈련 도중 어디서 문제가 생기는지 추적 가능하게 만든 점은 실제 서비스 규모의 훈련에서 신뢰도를 높이는 데 중요하다.

Figure 12: Agent behaviors before and after training, computed over 420 trajectories at each end of the production OpenHands SDK run. The pass@k and passk rows are computed over prompt groups in the first and last third of the run.
Figure 12: Agent behaviors before and after training, computed over 420 trajectories at each end of the production OpenHands SDK run. The pass@k and passk rows are computed over prompt groups in the first and last third of the run.

이 논문의 용어

  • 강화학습(RL) · 결과에 따라 보상을 주고받으며 정책(행동 방식)을 개선해나가는 학습 방법
  • 하니스(harness) · 에이전트가 도구 사용, 대화 맥락, 실행 결과를 관리하도록 만든 실행 프로그램
  • 샌드박스 · 코드를 안전하게 실행하고 테스트하기 위해 격리시켜 놓은 실행 공간
  • MoE(전문가 혼합 모델) · 여러 하위 신경망(전문가) 중 일부만 골라 쓰는 대형 모델 구조
  • SWE-bench Verified · 실제 소프트웨어 저장소의 이슈를 얼마나 잘 해결하는지 검증하는 벤치마크

저자 · Yiming Du

arXiv에서 원문 보기

최신 논문

논문 전체 보기 →

METAL MEDIA 최신 기사

그림 출처: Yiming Du et al., arXiv:2608.17393, CC0 1.0