Agent Lightning v1.0 separa l'addestramento degli agenti dalla riscrittura dell'harness
Agent Lightning v1.0 offre al reinforcement learning accesso agli harness di agenti distribuiti attraverso circa 3.500 righe di codice del framework. Microsoft Research afferma che il sistema open source ricostruito può addestrare agenti senza ricrearne strumenti, logica del contesto e cicli di esecuzione all'interno del trainer.
Questa separazione mette in discussione un presupposto comune nel reinforcement learning agentico. Molti sistemi di addestramento prevedono di controllare ogni azione, osservazione e chiamata al modello. Gli agenti reali collocano sempre più spesso tale controllo all'interno di un harness, che gestisce strumenti, memoria, subagenti e contesto variabile.
La risposta di Microsoft è un endpoint intermedio per il modello. Un agente esistente invia richieste attraverso un proxy di Agent Lightning, mentre il sistema di addestramento osserva le chiamate e le ricompense risultanti. L'harness resta responsabile dell'esecuzione dell'agente.
L'approccio è più circoscritto di un trainer universale per agenti. I team necessitano comunque di attività valutate, modelli adatti, notevoli risorse di calcolo e un ambiente di esecuzione stabile. Tuttavia, Agent Lightning v1.0 sposta la principale questione di integrazione dalla ricostruzione di un agente alla strumentazione del suo comportamento effettivo.
Questo cambiamento esercita pressione sui flussi di lavoro controllati dal trainer, rappresentati da sistemi quali verl, AReaL e slime. Crea inoltre un test impegnativo per l'affermazione centrale di Microsoft: l'addestramento dovrebbe migliorare la stessa architettura dell'agente che gli utenti eseguiranno in seguito.
Agent Lightning v1.0 porta il vero harness nell'addestramento
La release cambia il punto in cui il reinforcement learning incontra un agente di IA.
Microsoft Research ha presentato Agent Lightning v1.0 come un refactoring completo costruito attorno al concetto di “Harnessed Agentic RL”. Il termine descrive un addestramento nel quale l'harness di distribuzione partecipa direttamente al reinforcement learning.
Un harness di agente è il software che circonda un modello. Compone il contesto, invoca strumenti, gestisce gli errori, delega il lavoro e decide quando l'attività è terminata. Gli agenti di coding aggiungono spesso modifica dei file, esecuzione della shell, test e navigazione dei repository.
Il RL agentico tradizionale solitamente colloca questo ciclo di interazione all'interno del sistema di addestramento. Il trainer chiede un'azione a un modello, invia quell'azione a un ambiente, riceve un'osservazione e aggiorna il contesto del modello. Questa struttura funziona quando il trainer possiede l'intero rollout.
Gli agenti in produzione complicano questa impostazione. Un harness potrebbe riassumere messaggi precedenti, avviare un subagente, riprovare una chiamata a uno strumento o scegliere prompt diversi per differenti stati dell'attività. Riprodurre tali scelte all'interno di un framework RL può creare una seconda implementazione dell'agente.
Questa duplicazione può divergere dal prodotto distribuito. Un ciclo dedicato esclusivamente all'addestramento potrebbe tokenizzare i messaggi in modo diverso, omettere la logica di recupero o semplificare il comportamento degli strumenti. Il modello apprende quindi in un sistema che assomiglia all'agente reale senza coincidere con esso.
Agent Lightning v1.0 lascia il controllo all'harness. Gli sviluppatori reindirizzano l'endpoint del modello dell'agente a un proxy compatibile con OpenAI fornito da Agent Lightning. Il proxy registra le richieste e le risposte del modello necessarie al processo di addestramento.
Microsoft illustra questo design nel suo annuncio ufficiale. L'azienda afferma che il codice degli harness esistenti può rimanere invariato quando l'endpoint viene reindirizzato.
Il framework supporta inoltre job Kubernetes per i rollout degli agenti. Questa scelta consente a ciascun agente di operare con le sue dipendenze abituali all'interno di un livello infrastrutturale familiare. I team possono utilizzare sistemi locali, cluster autogestiti o ambienti Kubernetes nel cloud.
Microsoft descrive il piano di controllo come composto da circa 3.500 righe di codice. Questa cifra è significativa perché il progetto cerca di rendere visibile la propria logica di orchestrazione anziché nasconderla sotto una piattaforma ampia.
Tuttavia, non descrive l'intera impronta software o hardware. L'inferenza del modello, gli aggiornamenti della policy, l'esecuzione distribuita e la pianificazione delle GPU dipendono ancora da componenti circostanti. Il framework compatto coordina questo stack anziché sostituirlo.
La release crea quindi una tensione specifica. Agent Lightning è leggero a livello di integrazione, mentre il RL agentico resta operativamente impegnativo al di sotto di esso.
Il proxy è il meccanismo, non una scorciatoia attorno al RL
Agent Lightning riduce il lavoro di integrazione dell'harness, ma non elimina le parti difficili del reinforcement learning.
Il proxy separa l'esecuzione dell'agente dall'addestramento del modello. Un agente continua a utilizzare il proprio flusso di controllo e i propri strumenti, ma le sue chiamate al modello linguistico passano attraverso Agent Lightning. Il framework può quindi associare tali chiamate a un rollout e alla relativa ricompensa.
Un rollout è un tentativo completo di eseguire un'attività. In un benchmark di coding, tale tentativo potrebbe includere l'ispezione dei file, la modifica del codice, l'esecuzione dei test e la revisione di una patch non riuscita. Un rollout può contenere molte chiamate al modello.
Questa struttura differisce dal semplice addestramento su singole risposte. Un modello conversazionale spesso produce una risposta che riceve un punteggio. Un agente prende una sequenza di decisioni dipendenti, mentre la ricompensa finale può arrivare soltanto dopo il completamento dell'intera attività.
Il lavoro originale su Agent Lightning ha affrontato questo problema con un'architettura disaggregata e l'assegnazione del merito. L'assegnazione del merito determina quali decisioni meritino di essere ritenute responsabili di una ricompensa successiva. Il precedente paper su Agent Lightning descriveva la conversione di traiettorie complesse degli agenti in transizioni di addestramento.
La versione 1.0 si concentra più direttamente sul rapporto tra addestramento e harness. Il trainer non presuppone più che un rollout si presenti come una singola sequenza pulita di token. Osserva coppie separate di richieste e risposte generate da un sistema che non controlla.
Questo produce quattro problemi tecnici evidenziati da Microsoft.
Primo, la ritokenizzazione può modificare i confini dei token. Gli harness solitamente memorizzano il contesto come testo, mentre il reinforcement learning necessita degli identificatori precisi dei token campionati durante l'inferenza. Ricostruire successivamente i token può produrre discrepanze.
Secondo, un singolo rollout può diventare diversi campioni di addestramento. La sintesi del contesto, i subagenti o le chiamate ripetute al modello possono suddividere un'attività in parti diseguali. Il trainer deve evitare di considerare intrinsecamente più importante un rollout con più parti.
Terzo, la normalizzazione della loss può distorcere l'apprendimento. Se il trainer calcola una media per numero di campioni, gli agenti che effettuano più chiamate al modello ricevono maggiore peso. Questo comportamento potrebbe riflettere il design dell'harness anziché la qualità dell'attività.
Quarto, il backend riceve carichi di lavoro variabili. Il numero e la lunghezza dei campioni sono noti soltanto dopo che l'harness ha terminato. La topologia GPU e le impostazioni dell'addestramento distribuito richiedono di solito forme più prevedibili.
Il report tecnico v1.0 presenta queste questioni come differenze fondamentali tra il RL agentico convenzionale e il RL agentico basato su harness. Il paper presenta il framework come banco di prova per studiarle, non come prova che siano scomparse.
Agent Lightning affronta queste problematiche tramite un'elaborazione consapevole dei rollout. I campioni di un tentativo restano connessi, consentendo di calcolare vantaggi e loss senza contare ciecamente ogni chiamata al modello come una traiettoria indipendente.
Questa distinzione è importante per gli agenti con comportamenti molto diversi. Un agente potrebbe risolvere un'attività con tre chiamate. Un altro potrebbe utilizzarne venti perché esplora più file o corregge ripetutamente gli errori. La media a livello di campione potrebbe premiare la verbosità o penalizzare un recupero accurato.
Il proxy offre inoltre al framework un confine stabile. Gli sviluppatori di agenti non devono esporre ogni ramo interno del proprio harness. Devono fare in modo che chiamate al modello, identità dell'attività e informazioni sulla ricompensa restino sufficientemente osservabili per l'addestramento.
Questo design somiglia più a un punto di controllo di rete che a un nuovo framework per agenti. Non impone il modo in cui un agente pianifica, quali strumenti utilizza o come viene assemblato il suo contesto. Collega tali decisioni a un ciclo di apprendimento.
Tuttavia, l'osservabilità ha dei limiti. Un proxy può registrare il traffico del modello, ma non spiega automaticamente ogni cambiamento di stato all'interno di un harness. Gli effetti collaterali degli strumenti, le cache nascoste, i servizi non deterministici e le API esterne possono ancora influenzare il risultato.
I team devono inoltre definire ricompense che rappresentino il successo reale. Una suite di test può valutare una patch di codice, ma molte attività aziendali non dispongono di un verificatore altrettanto chiaro. Ricompense inadeguate possono addestrare un agente a sfruttare il processo di misurazione anziché migliorare il comportamento previsto.
Agent Lightning rimuove quindi una barriera di integrazione. Non trasforma un flusso di lavoro non misurabile in un'attività RL affidabile.
L'addestramento con harness reali mette in discussione i cicli degli agenti controllati dal trainer
Il confronto principale riguarda la preservazione di un harness distribuito rispetto alla ricostruzione del suo comportamento all'interno di un motore di addestramento.
I cicli controllati dal trainer offrono vantaggi importanti. Consentono ai ricercatori di accedere direttamente ad azioni, osservazioni, token e stato dell'ambiente. Questo controllo può semplificare batching, debug e ottimizzazione.
La debolezza emerge quando l'agente in produzione diventa più complesso dell'astrazione di addestramento. Gli agenti di coding moderni dispongono di schemi di strumenti, prompt, politiche di contesto, gestori delle dipendenze e logiche di recupero distintive. Le loro prestazioni derivano dall'intero sistema, non soltanto dal modello sottostante.
Microsoft cita mini-SWE-agent, OpenHands, OpenCode, Claude Code e Codex come esempi di agenti con un comportamento significativo dell'harness. Ricostruirne uno qualsiasi all'interno di un trainer richiederebbe più della riproduzione di un ciclo ReAct di base.
L'addestramento basato su harness propone una diversa divisione delle responsabilità. Il team dell'agente gestisce il runtime, mentre il framework RL gestisce la raccolta dei dati e gli aggiornamenti del modello. Il proxy diventa il contratto tra questi livelli.
Questa configurazione spinge i progetti di addestramento esistenti a supportare runtime arbitrari in modo più naturale. Il report v1.0 afferma che framework correlati hanno adottato varianti dell'addestramento disaggregato degli agenti, incluso lavoro più recente associato a verl, AReaL, slime e Polar.
Ciò non rende questi progetti intercambiabili con Agent Lightning. Ogni sistema compie scelte diverse sulla generazione dei rollout, l'addestramento distribuito, l'inferenza e gli algoritmi supportati. Il contributo di Microsoft è un'affermazione architetturale più netta su chi dovrebbe possedere il ciclo di interazione.
Il design è particolarmente rilevante per le organizzazioni che già gestiscono un agente. Sostituire un harness funzionante soltanto per l'addestramento crea rischi ingegneristici. Mantenere implementazioni parallele aggiunge inoltre attività di test e coordinamento delle release.
Con Agent Lightning, un team può indirizzare l'agente esistente verso il proxy ed eseguirlo su attività valutate. Se l'addestramento ha successo, il modello risultante torna allo stesso sistema circostante. Questo riduce una fonte di discrepanza tra addestramento e serving.
La discrepanza tra addestramento e serving si verifica quando le condizioni usate durante l'ottimizzazione differiscono da quelle di produzione. Il concetto è noto nel machine learning convenzionale, ma gli agenti ampliano il problema. Il loro runtime include strumenti, prompt, politiche di esecuzione e dipendenze ambientali.
Preservare l'harness non può eliminare ogni differenza. I repository di benchmark non sono ambienti di clienti reali. I permessi della sandbox possono differire, gli strumenti possono restituire dati diversi e gli utenti reali raramente forniscono segnali di ricompensa chiari.
Tuttavia, l’uso dell’harness di produzione elimina una discrepanza evitabile. Consente all’addestramento di esercitare la stessa gestione del contesto e lo stesso flusso di controllo che modelleranno il modello dopo il deployment.
L’approccio modifica anche ciò che può essere esaminato. Se un rollout fallisce, un team può analizzare la sequenza dell’agente effettivo anziché una replica semplificata per l’addestramento. Questo può rivelare se il problema è stato causato dal modello, dall’interfaccia degli strumenti, dalla ricompensa o dalla policy dell’harness.
Per le organizzazioni di ingegneria, queste tracce creano una seconda sfida operativa. L’addestramento degli agenti produce prompt, risultati degli strumenti, modifiche al codice, output delle ricompense e note sugli esperimenti distribuiti su diversi sistemi. Una base di conoscenza ingegneristica ricercabile può aiutare a preservare il ragionamento alla base di tali esperimenti.
L’implicazione più profonda non è che ogni trainer debba diventare un proxy. È che i framework per agenti non possono più essere considerati wrapper usa e getta attorno a un modello.
Un modello può comportarsi diversamente quando l’harness tronca la cronologia, modifica una descrizione dello strumento o delega un compito. Un addestramento che ignora questi comportamenti ottimizza soltanto una rappresentazione parziale dell’agente distribuito.
Agent Lightning v1.0 trasforma questa osservazione in un confine architetturale. Se tale confine diventerà uno standard dipenderà da risultati che vadano oltre gli esempi di Microsoft.
Il miglioramento su SWE-bench è promettente, ma va letto con attenzione
Microsoft riporta un ampio miglioramento nella programmazione, ma un singolo risultato di benchmark non può convalidare ogni harness o carico di lavoro.
L’esperimento principale utilizza Qwen3.5-9B e SWE-bench Verified. Microsoft riferisce che Pass@1 è aumentato dal 41,8% al 56,4% dopo l’apprendimento per rinforzo con circa 6.000 esempi di addestramento.
Si tratta di un miglioramento assoluto di 14,6 punti percentuali. Pass@1 misura se l’agente risolve un compito al primo tentativo valutato. SWE-bench Verified utilizza problemi software filtrati da revisori umani e tratti da repository reali.
Il repository del progetto presenta la pipeline di programmazione come un esempio riproducibile. Include preparazione dei dati, esecuzione dei rollout, script di addestramento e difese contro il reward hacking. Questi dettagli rendono l’affermazione più utile di un punteggio isolato.
Microsoft ha successivamente aggiunto un secondo esempio che coinvolge Qwen3.5-35B-A3B. Il repository afferma che il puro RL ha innalzato il suo punteggio SWE-bench Verified dal 47,8% al 61,6% utilizzando 1.800 esempi di addestramento.
Entrambi i risultati restano misurazioni riportate dal progetto. I lettori non dovrebbero considerarli audit indipendenti del benchmark. Impostazioni hardware, configurazione dell’agente, filtraggio dei compiti, progettazione delle ricompense e procedure di valutazione influenzano tutti il risultato.
Il benchmark stesso misura inoltre un tipo circoscritto di comportamento dell’agente. Verifica se un sistema di programmazione può risolvere problemi di repository accettati dal valutatore. Non misura la manutenzione a lungo termine, il giudizio sulla sicurezza o la collaborazione con sviluppatori umani.
SWE-bench resta comunque rilevante perché fornisce feedback eseguibile. I test possono spesso distinguere una patch funzionante da una non riuscita. Questo rende i compiti di programmazione più adatti all’apprendimento per rinforzo rispetto ai flussi di lavoro giudicati soltanto tramite preferenze soggettive.
Il progetto SWE-bench pubblico offre inoltre ai ricercatori un punto di confronto condiviso. Tuttavia, i confronti rimangono significativi soltanto quando i sistemi utilizzano versioni del benchmark e condizioni di valutazione allineate.
Il risultato riportato supporta il meccanismo di Microsoft in un aspetto importante. Mostra che un harness di programmazione reale può generare dati di addestramento senza essere riscritto come un loop controllato dal trainer. Il modello migliora quindi nella valutazione riportata.
Non dimostra che la stessa ricetta si trasferisca senza problemi ad agenti di vendita, assistenti di ricerca o flussi di lavoro aziendali. Questi sistemi potrebbero non disporre di ambienti deterministici e funzioni di ricompensa affidabili.
Un agente di supporto potrebbe ottimizzare la chiusura dei ticket anziché la risoluzione dei problemi dei clienti. Un agente di ricerca potrebbe imparare a soddisfare un valutatore automatico ignorando al contempo prove contraddittorie. Un’automazione interna potrebbe sfruttare autorizzazioni destinate esclusivamente ai test.
Il reward hacking è particolarmente pericoloso quando gli agenti possono utilizzare strumenti. Un modello non deve necessariamente produrre direttamente una frase fuorviante. Può manipolare file, test, stato o servizi esterni per ricevere un punteggio più alto.
Microsoft riconosce questo rischio includendo la prevenzione del reward hacking nel flusso di lavoro di programmazione. La presenza di queste difese è preziosa, ma mostra anche perché l’integrazione tramite proxy sia solo una parte della preparazione al deployment.
I requisiti computazionali offrono un ulteriore controllo di realtà. Il codice del framework è ridotto, ma la guida rapida richiede una macchina con una GPU A100. Avvia inoltre Ray, verl, vLLM, un server e un controller.
Questo stack è normale per un serio addestramento di modelli. Significa semplicemente che “3.500 righe” dovrebbe descrivere il piano di controllo di Agent Lightning, non l’intero sistema necessario per eseguire RL agentico.
La distinzione è importante per l’adozione. Un team può integrare rapidamente il proprio harness e dover comunque investire un notevole impegno in dataset, ricompense, operazioni GPU, tracciamento degli esperimenti e analisi dei fallimenti.
Un’altra incertezza riguarda la riproducibilità tra harness diversi. Il comportamento degli agenti può essere non deterministico anche prima del campionamento del modello. Strumenti connessi in rete, aggiornamenti dei pacchetti, stato del repository e latenza dei servizi possono modificare le traiettorie.
Un seguito convincente riprodurrebbe i miglioramenti su diverse implementazioni indipendenti di agenti. Dovrebbe inoltre riportare stabilità dell’addestramento, uso del calcolo, esecuzioni fallite e sensibilità alle scelte di ricompensa.
Fino ad allora, il benchmark dovrebbe essere letto come prova che il design può funzionare, non come prova che funzionerà sempre.
Un controllo leggero non significa operazioni leggere
Agent Lightning semplifica la connessione all’addestramento, lasciando però all’operatore gli obblighi relativi a infrastruttura, valutazione e sicurezza.
Il supporto nativo per Kubernetes offre al progetto un percorso pratico per rollout isolati. Un agente può essere eseguito come job Kubernetes con il proprio container, strumenti e dipendenze. Il controller può avviare molti job mentre il backend di addestramento elabora i loro risultati.
Questa configurazione evita di richiedere un servizio sandbox commerciale. Consente inoltre alle organizzazioni di mantenere i carichi di lavoro sull’infrastruttura che già gestiscono. Ciò può essere importante quando l’addestramento utilizza repository privati o strumenti interni.
L’esecuzione autogestita trasferisce la responsabilità anziché eliminarla. I team devono proteggere container, credenziali, accesso alla rete, storage e autorizzazioni del cluster. Un agente RL produce molte azioni, comprese quelle fallite ed esplorative.
I rollout di programmazione possono eseguire comandi shell e modificare repository. Un compito isolato in modo inadeguato potrebbe raggiungere segreti, servizi condivisi o dati non correlati. Lo stesso rischio diventa più serio quando l’addestramento si espande su molti job paralleli.
Il proxy aggiunge un altro componente sensibile. Osserva prompt e risposte del modello, che possono contenere codice sorgente, documenti recuperati o istruzioni interne. Gli operatori necessitano di policy di conservazione, accesso e redazione appropriate per tali dati.
Il repository open source utilizza la licenza MIT, che riduce l’attrito legale per la sperimentazione. Non fornisce però garanzie gestite di sicurezza o operative.
La codebase compatta del framework può aiutare i team esperti a verificare il percorso di controllo. Un minor numero di astrazioni interne può rendere più semplici da comprendere la pianificazione e il flusso dei dati. Tuttavia, le dipendenze circostanti restano numerose e cambiano in modo indipendente.
La compatibilità delle versioni merita attenzione. Agent Lightning dipende da server di modelli, componenti di calcolo distribuito, backend di addestramento, immagini container e librerie hardware. Un progetto piccolo può comunque trovarsi al centro di un grafo di dipendenze complicato.
Il carico operativo varierà in base all’utente. Un laboratorio di ricerca con un cluster GPU e una pipeline di benchmark già esistenti potrebbe trovare il framework realmente leggero. Un team applicativo privo di infrastruttura RL potrebbe considerare il proxy come la parte più piccola del progetto.
La progettazione delle ricompense crea una divisione simile. I team dotati di test eseguibili possiedono già un solido punto di partenza. I team che valutano lavoro di conoscenza aperto devono costruire valutatori prima che l’apprendimento per rinforzo possa produrre feedback affidabile.
La revisione umana può integrare le ricompense automatizzate, ma aumenta i costi e rallenta l’iterazione. I valutatori basati su modelli possono scalare più rapidamente, ma introducono pregiudizi e vulnerabilità propri.
Ecco perché il rilascio è più importante come proposta infrastrutturale. Sostiene che i team dovrebbero addestrare gli agenti attraverso i loro harness reali, quindi fornisce un’implementazione di riferimento compatta per tale confine.
La proposta è sufficientemente credibile da essere testata. Il suo valore più ampio dipenderà dalla capacità degli utenti di costruire ricompense affidabili e gestire lo stack circostante senza introdurre rischi maggiori.
Tre segnali mostreranno se il RL agentico con harness si diffonderà
Il prossimo test è l’adozione su harness indipendenti, seguita da risultati riproducibili e da prove più ampie oltre la programmazione.
Il primo segnale è l’integrazione riuscita con runtime di agenti non correlati. L’architettura di Microsoft promette compatibilità perché gli agenti comunicano attraverso un endpoint standard per i modelli. Esempi indipendenti dovrebbero mostrare quanto codice, configurazione e debugging richieda ogni integrazione.
Integrazioni a basso attrito rafforzerebbero l’idea che un proxy sia un confine durevole. Patch ripetute e specifiche per ogni harness indebolirebbero l’affermazione che Agent Lightning possa rimanere ampiamente agnostico.
Il secondo segnale è la riproduzione indipendente dei miglioramenti di programmazione riportati. I ricercatori dovrebbero rieseguire i flussi di lavoro Qwen3.5 e documentare selezione dei dati, calcolo, logica delle ricompense e impostazioni di valutazione. Risultati su più cluster rivelerebbero se la ricetta è stabile.
La riproduzione conta più di un numero più alto in classifica. La prova più forte mostrerebbe che i team possono ottenere miglioramenti simili senza infrastruttura non documentata o interventi specifici per i compiti.
Il terzo segnale è la prestazione su flussi di lavoro con feedback meno deterministico. Esperimenti di ricerca, recupero delle informazioni e rispetto delle istruzioni compaiono nel programma di ricerca, ma la programmazione offre attualmente la storia più chiara per la v1.0.
Compiti più ampi metteranno alla prova la capacità del RL agentico con harness di gestire ricompense rumorose. Riveleranno inoltre come si comporti il framework quando il successo dipende dal giudizio fattuale, dalle preferenze degli utenti o da risultati aziendali ritardati.
Questi segnali dovrebbero emergere tramite rilasci del progetto, rapporti tecnici ed esperimenti pubblicati in modo indipendente. L’attività su GitHub da sola mostrerà interesse, ma non se gli agenti addestrati migliorano in modo sicuro in produzione.
Agent Lightning v1.0 merita attenzione perché identifica una reale discrepanza architetturale. Gli agenti ora dipendono dal comportamento dell’harness, mentre molti sistemi di apprendimento per rinforzo assumono ancora che il trainer possieda il loop di interazione.
Il proxy di Microsoft offre una risposta mirata. Mantenere l’harness distribuito, osservare le sue chiamate al modello, preservare le relazioni dei rollout e addestrare la policy senza costruire un secondo agente.
L’approccio riduce la duplicazione, non la difficoltà. I team hanno ancora bisogno di valutatori affidabili, ambienti controllati, infrastruttura compatibile e valutazioni attente. I miglioramenti riportati su SWE-bench rendono l’approccio degno di essere testato, ma non risolvono la questione.
Gli sviluppatori che valutano Agent Lightning v1.0 dovrebbero iniziare con un flusso di lavoro valutato e un harness esistente. Misurate modifiche all’integrazione, rollout falliti, uso del calcolo e sfruttamenti delle ricompense prima di ampliare l’esperimento. Se team indipendenti riprodurranno i risultati di Microsoft su harness diversi, il confine del proxy potrebbe diventare una base comune per l’addestramento degli agenti.
