EnvHarness: l’ambiente di addestramento si adatta all’agente, senza riscriverlo

Un istruttore di scuola guida non costruisce una città nuova per ogni allievo. Usa le stesse strade, ma sceglie come usarle: a chi frena male fa partire la lezione in salita, a chi si affida troppo al navigatore lo spegne, a chi guida bene ma si distrae alla fine aggiunge un parcheggio in retromarcia dopo l’ultimo incrocio. Le strade restano quelle, e l’esame finale anche. Cambia il modo in cui l’allievo le incontra, e lo decide l’istruttore guardando come guida.

È l’idea di un paper depositato su arXiv il 20 agosto 2026, EnvHarness: Awakening Static Worlds for Agent Learning. Lo firmano diciassette autori, con Chengsong Huang (Washington University in St. Louis, allora in stage da Google) come primo nome e, insieme a Zifeng Wang e Chen-Yu Lee, come autore di riferimento; quasi tutti gli altri sono di Google Cloud AI Research, e il codice è su GitHub (google-research/envharness). Molte delle stesse firme compaiono un mese dopo su RRSI, il paper sul freno da mettere agli agenti che si riscrivono l’harness. Lì si lavorava sul lato dell’agente; qui sull’altro lato, il mondo in cui l’agente impara.

Il problema: ambienti ciechi e fermi

Un agente basato su un modello linguistico impara interagendo con un ambiente: una casa simulata in cui spostare oggetti, un sito web da navigare, un repository con una issue da risolvere. L’ambiente propone il compito, tiene lo stato, risponde alle azioni e alla fine dice, con un verificatore, se il compito è riuscito. Costruirne uno è lavoro manuale costoso: la logica dell’interazione e il verificatore vanno scritti a mano. E il risultato è statico: si comporta allo stesso modo con qualunque agente e a qualunque stadio del suo apprendimento. Gli autori ne ricavano due limiti. Un ambiente fermo non sa colpire i punti deboli di un agente preciso; e quando l’agente ha imparato a risolverne i compiti, non ha più niente da insegnare.

La risposta recente è generare ambienti nuovi con un modello linguistico. Funziona, ma con due costi che il paper mette in fila. Le pipeline di generazione sono specifiche di un dominio: quella fatta per il web non serve al codice. E i verificatori generati da un modello possono essere sbagliati, per cui si genera in eccesso e si filtra, senza mai la certezza di aver tolto tutti gli errori.

Un harness, ma dall’altra parte

La proposta rovescia un’idea già familiare. L’harness di un agente è lo strato software (ciclo di esecuzione, strumenti, memoria, gestione del contesto) che trasforma un modello congelato in un agente senza toccarne i pesi. EnvHarness applica lo stesso principio all’ambiente: uno strato di componenti che avvolge un ambiente congelato e ne cambia il comportamento passando solo dall’interfaccia standard, i metodi reset e step, senza toccare il simulatore né il codice interno.

Formalmente l’ambiente è una tupla $E = (\mathcal{S}, \mathcal{A}, \mathcal{O}, T, R, s_0)$ (stati, azioni, osservazioni, transizione, ricompensa data dal verificatore, stato iniziale), e un componente è una trasformazione $E’ = w(E)$ che agisce solo dall’esterno. Il punto che conta è il verificatore: siccome i compiti di base non cambiano, ogni ambiente rimodellato eredita quello originale, scritto e controllato da persone. Nessun verificatore generato, nessun filtro a valle.

I componenti proposti sono tre, illustrati tutti su un compito di ALFWorld, «metti una tazza pulita sulla scrivania», in cui la tazza è in bella vista.

Lo Stage cambia il punto di partenza. È una sequenza di azioni applicate allo stato restituito da reset:

$$s_0′ = T(\cdots T(T(s_0, a_1), a_2) \cdots, a_k)$$

Uno Stage può prendere la tazza, chiuderla in un cassetto e costringere l’agente a cercarla; un altro può pulirla in anticipo e lasciare solo l’ultimo passo. Nel primo caso il compito si fa più duro, nel secondo più corto.

Il Contract riscrive le regole dell’interazione, con tre mappe che trasformano azioni, transizioni e osservazioni. Può troncare la descrizione della stanza alle prime due frasi, bloccare l’azione «pulisci la tazza» se l’agente non la sta tenendo, togliere i comandi di teletrasporto e obbligare a muoversi passo per passo.

La Chain allunga il compito: attacca un secondo ambiente al primo (nell’esempio, «scalda una patata e mettila sul piano», nella stessa casa) e considera riuscito l’episodio solo se lo dicono entrambi i verificatori. I componenti si compongono, $E’ = w_{\text{chain}}(w_{\text{contract}}(w_{\text{stage}}(E)))$, e l’ordine conta: la composizione non è commutativa.

Chi decide come rimodellare

I componenti sono generici; la scelta di quali usare, e con che parametri, dipende dal compito e dall’agente. La fa EnvRigger, un secondo agente che tratta la politica da allenare come una scatola nera. Osserva cinque esecuzioni sul compito originale, quelle riuscite e quelle fallite; diagnostica le cause (cicli di azioni ripetute, osservazioni lunghe lette male, vincoli degli strumenti fraintesi); scrive i componenti in codice; li valida con cinque esecuzioni nuove nell’ambiente rimodellato. Un candidato irrisolvibile o troppo facile viene scartato, uno mal calibrato torna alla scrittura, al massimo cinque volte. Se la politica risolve già tutto, la diagnosi cambia verso: l’ambiente va reso più difficile.

Due scelte di metodo pesano sulla lettura dei risultati. EnvRigger usa lo stesso modello della politica (Gemini-3.1-Flash-Lite su ALFWorld e WebArena, Gemini-3.5-Flash altrove), così, osservano gli autori, i guadagni non possono venire dal travaso di un modello più forte. E nell’impostazione principale i pesi non si toccano: dagli episodi negli ambienti rimodellati si estraggono delle skill, istruzioni riusabili nello stile di ReasoningBank, e si misura l’agente che le usa sui compiti di test, rimasti originali e disgiunti da quelli di addestramento. La Chain, per ora, resta fuori dal ciclo automatico: EnvRigger fatica a leggere lo stato interno di due ambienti uniti.

I numeri

Cinque benchmark in quattro domini, medie su tre esecuzioni, e un confronto che isola l’effetto del rimodellamento: stesse istanze di partenza, stesso numero di ambienti, stessa estrazione di skill, cambia solo da dove vengono gli episodi.

Su tutti e cinque i benchmark le skill ricavate dagli ambienti rimodellati superano quelle ricavate dagli originali, e dove esiste un generatore di ambienti da confrontare superano anche quello.

Su ALFWorld la parte fuori distribuzione guadagna +9,0 punti (da 61,4 a 70,4). Su WebArena VeriEnv vince però sul sottodominio GitLab. Su SWE-bench Verified i passi medi per episodio scendono da 55,0 a 49,6: le skill dagli ambienti originali li avevano allungati rispetto al 53,6 di partenza. Sugli strumenti da ufficio c’è un dettaglio istruttivo: lì le skill dagli ambienti originali fanno peggio di nessuna skill (46,44).

Con il reinforcement learning, su Qwen3-8B base addestrato con GRPO, ALFWorld sale da 81,4 a 87,9 in distribuzione e scende di poco fuori (da 89,6 a 88,8); su WebShop il punteggio va da 75,6 a 79,2 e il successo da 66,0 a 67,4. La Chain, provata a parte su SWE-bench, porta i passi medi a 41,96, contro i 53,6 dell’agente senza skill, con un successo appena sotto quello degli ambienti originali (49,63 contro 49,88); unita alle altre skill dà 54,30 con 43,12 passi. E al crescere degli ambienti, a pari budget di 300, EnvHarness arriva a 54,79 continuando a salire, mentre gli ambienti originali si fermano a 52,13 e quelli generati a 50,37. Sui quattro modelli provati come politica su SWE-bench Verified, da Gemini 3.1 Flash-Lite a Claude Sonnet 4.6, il vantaggio sugli ambienti originali resta fra 2,7 e 3,7 punti.

Che cosa non dice

Molti margini stanno dentro il rumore. Su SWE-bench Verified la deviazione standard delle tre esecuzioni è di 2,72 punti per EnvHarness e 2,59 per gli ambienti originali, contro una differenza di 2,70. I guadagni su WebArena e OfficeQA sono dello stesso ordine. Il quadro è coerente (nelle tabelle principali EnvHarness non perde mai contro gli ambienti originali), ma i singoli numeri, presi uno per uno, non sono conclusivi. Nella prova di generalizzazione su ALFWorld, che toglie un tipo di compito e misura su quello, la media sale di 3,1 punti ma il tipo «scalda» perde 8,7.

Il costo è più alto, e il paper lo scrive. Secondo le stime in appendice, su ALFWorld il progetto dei componenti consuma 1,46 milioni di token contro 38 mila di GenEnv, e il totale è 228 milioni contro 64: 3,5 volte tanto. Gli autori osservano che GenEnv simula gli episodi con un modello invece di eseguirli, e che contro VeriEnv, che li esegue davvero, il conto è pari (137,3 contro 137,8 milioni). È un argomento ragionevole; resta che la qualità si paga in esecuzioni reali.

Il perimetro è stretto. Serve un ambiente con interfaccia reset/step su azioni e osservazioni testuali, e soprattutto con un reset deterministico: lo Stage deve poter rimettere l’ambiente in uno stato scelto. Restano fuori, per ammissione degli autori, gli agenti che agiscono su servizi reali (un’email spedita non si ritira), i robot fisici e, per ora, gli ambienti visivi. E la Chain, per ereditare verificatori affidabili, deve limitarsi a concatenare: con rami o compiti intrecciati non ci sono due verdetti da combinare, e in ogni caso non ha modo di sapere se i compiti che unisce abbiano senso insieme.

Perché conta adesso

Il dibattito sugli agenti si è spostato negli ultimi mesi dai pesi all’impalcatura: harness che si riscrivono, skill che si accumulano, memorie che si potano. EnvHarness porta lo stesso ragionamento dall’altra parte del tavolo, e la mossa ha un’utilità pratica prima che teorica. Chi ha un benchmark costoso, con verificatori scritti a mano e controllati, può ricavarne ambienti nuovi senza scriverne altri e senza fidarsi di un verificatore generato. Gli autori la riassumono così: costruire ambienti diventa un problema di avvolgimento, non di scrittura. I margini misurati sono piccoli e il costo è reale. Ma se l’istruttore conta più delle strade, la scarsità di ambienti da cui il paper parte si può allentare senza costruirne di nuovi: gli autori parlano di una strada praticabile, non di un problema risolto.