Il problema dell’addestramento degli agenti non è più soltanto il modello: è tutto ciò che gli sta intorno. Microsoft Research Asia ha reso open source Agent Lightning 1.0, un framework di reinforcement learning di circa 3.500 righe che rovescia il paradigma tradizionale: invece di obbligare i team a reimplementare l’agente dentro il framework di training, lascia che sia l’harness usato in produzione a partecipare direttamente al ciclo di RL. Il framework si inserisce tra l’agente e il modello con un proxy compatibile con OpenAI: le chiamate al modello restano le stesse, mentre il sistema registra prompt, risposte e log-probabilità necessari al training.

Il cambio non è cosmetico. Nei sistemi agentici tradizionali, il training framework controlla il loop con l’ambiente: il modello genera un’azione, l’ambiente restituisce un’osservazione e il tutto viene mappato su un’unica traiettoria di token. Funziona con sistemi relativamente semplici, ma non con gli harness reali come mini-SWE-agent, OpenHands o Codex, che gestiscono contesto, tool e logica di esecuzione in modo autonomo. Reimplementarli nel framework di training è costoso e produce un agente che non coincide più con quello che va in produzione. Agent Lightning sposta il controllo: l’harness gestisce l’interazione con l’ambiente, il framework osserva e raccoglie campioni. In v1.0 questa scelta è formalizzata come Harnessed Agentic RL.

Il sistema è composto da tre componenti: un API Gateway che funge da proxy LLM, un Rollout Controller per l’esecuzione degli agenti e un trainer personalizzato basato su verl. Questa architettura introduce quattro difficoltà concrete: la ri-tokenizzazione, il calcolo del vantaggio a livello di rollout, la normalizzazione della loss e lo scheduling su risorse GPU fisse. Il punto non è teorico: se un rollout genera più campioni, una media per campione distorce il contributo statistico di quella rollout. I ricercatori mostrano che gestire vantaggio e normalizzazione a livello di rollout produce una reward di validazione più alta e un’entropia di policy più stabile.

Dal lato infrastruttura, Agent Lightning 1.0 punta su Kubernetes nativo. Gli agenti girano come job Kubernetes standard, su cluster self-managed, Kubernetes cloud o infrastruttura locale. Non servono sandbox commerciali come Modal o E2B: per chi ha già capacità di calcolo on-premise o cluster condivisi, questo riduce il costo marginale dei rollout su larga scala e mantiene codice e dati dentro i confini che l’organizzazione controlla. È un segnale strutturale: la disponibilità di framework leggeri e integrabili con Kubernetes abbassa la soglia per fare RL su agenti senza esternalizzare l’esecuzione.

Agent Lightning introduce anche Collocated Async RL, che fa condividere rollout e aggiornamenti allo stesso set di GPU. Nei test dichiarati, il guadagno end-to-end è di circa 2x rispetto all’RL sincrono, usando meno GPU dell’approccio asincrono convenzionale. Non si tratta solo di efficienza: per team con poche GPU, la possibilità di alternare rollout e update sullo stesso hardware rende l’addestramento di agenti più compatibile con infrastrutture locali moderate.

Il collaudo su una pipeline di coding end-to-end, basata su Qwen3.5-9B e il dataset SWE-smith, ha portato il Pass@1 su SWE-bench Verified dal 41,8% al 56,4%, un guadagno assoluto di 14,6 punti percentuali con circa 6.000 campioni. È un risultato rilevante non tanto per il benchmark in sé, quanto per il rapporto tra dati e risultato: non serve calcolo su larga scala per ottenere miglioramenti misurabili.

Chi ci guadagna? Chi dispone già di cluster Kubernetes self-managed, laboratori con risorse moderate e organizzazioni con vincoli di residenza dei dati. Chi perde? I fornitori di sandbox commerciali che fino a oggi offrivano il modo più rapido per scalare rollout senza avere un’infrastruttura dedicata. La direzione è chiara: l’addestramento di agenti si sta spostando dall’accesso a servizi cloud chiusi verso componenti open source che girano dove l’organizzazione decide, con un costo prevedibile. Per chi valuta deployment on-premise, AI-RADAR offre strumenti analitici su /llm-onpremise per valutare questi trade-off, ma la scelta resta legata a competenze interne e obiettivi specifici.

Il codice è disponibile su GitHub insieme al report tecnico. Un dettaglio che, insieme alla scelta di Kubernetes, sposta il confronto dal benchmark alla replicabilità.