RRSI: l’agente che si riscrive l’harness impara meglio se gli si mette un freno

Chi ha preparato un esame orale su un elenco di domande note conosce la tentazione: invece di capire la materia, si imparano a memoria le risposte. Funziona benissimo finché il professore non cambia una domanda. E se l’elenco lo si ripassa venti volte, correggendo ogni volta la risposta che non convince, il rischio cresce: ogni ripasso migliora il voto sull’elenco, e nessuno misura più se si sa la materia.

È esattamente quello che succede agli agenti che si migliorano da soli, e un paper depositato su arXiv il 21 settembre 2026 prova a curarlo. Si intitola RRSI: Regularized Recursive Self-Improvement of Agent Harnesses, lo firmano quattordici ricercatori guidati da Peng Xia (UNC-Chapel Hill, allora in stage da Google) e Chen-Yu Lee, quasi tutti di Google Cloud AI Research, con Stanford e Washington University in St. Louis. In questi giorni è fra i paper in tendenza su Papers with Code, e il motivo è che tocca un nervo scoperto del settore.

Che cosa si sta auto-migliorando

Un agente basato su un modello linguistico non è solo il modello. Attorno ai pesi, che restano congelati, c’è l’harness: i prompt di sistema, il flusso di controllo che decide quando pianificare, agire o fermarsi, le descrizioni degli strumenti, i file di memoria e di skill, la gestione del contesto. È l’harness che decide se lo stesso modello legge il file giusto prima di modificarlo o si riprende da un comando fallito. E buona parte dei progressi recenti dei prodotti agentici, osservano gli autori, è venuta da qui, non da pesi nuovi.

Scrivere un harness è lavoro manuale: un ingegnere legge le traiettorie fallite e ritocca l’impalcatura. Da qualche mese una famiglia di metodi (Meta-Harness, AHE, TTHE, HarnessX fra gli altri) automatizza il giro: un modello propone modifiche all’harness, le modifiche si provano su un insieme di compiti, la migliore diventa il nuovo harness, e si ricomincia. È una forma pratica di auto-miglioramento ricorsivo, applicata non ai pesi ma al programma che li circonda.

Il problema è l’esame orale. Il giro riusa sempre lo stesso insieme finito di compiti, e le proposte del round $t$ dipendono dai punteggi misurati sugli stessi compiti nei round precedenti. Gli autori scrivono l’obiettivo così:

$$H_{t+1} = \arg\max_{H’ \in \mathcal{H}_t \cup \{H_t\}} \hat S(H’; \mathcal{D}_{\text{evolve}})$$

dove $\hat S$ è il punteggio medio su $k$ esecuzioni stocastiche per compito. Non c’è nessun termine che parli di generalizzazione. E il risultato, riportato da diversi studi recenti, è che i guadagni sull’insieme di casa spesso si restringono o spariscono appena si cambia benchmark. Gli autori individuano tre meccanismi: la ricerca codifica pattern specifici del benchmark, insegue il rumore della valutazione, oppure accumula complessità che alza il punteggio senza migliorare l’agente.

La cura: regolarizzare la ricerca, non l’harness

La scelta di fondo di RRSI è non restringere lo spazio delle modifiche: prompt, flusso di controllo, strumenti, memoria, subagenti, tutto resta modificabile, aggiungibile, rimovibile. Quello che si vincola è il percorso che la ricerca fa in quello spazio. È la traduzione, in un contesto dove non ci sono parametri da penalizzare, dei principi di regolarizzazione del machine learning classico, e gli interventi stanno sui due lati del giro.

Dal lato di chi propone, il primo freno è un tetto al numero di modifiche indipendenti che un candidato può contenere, e il tetto scende nel tempo seguendo un coseno:

$$b_t = \left\lceil b_{\min} + (b_{\max} – b_{\min}) \cdot \tfrac{1}{2}\big(1 + \cos(\pi t / T)\big) \right\rceil$$

Nei primi round si possono combinare fino a tre o quattro cambiamenti coordinati, per scoprire meccanismi nuovi; negli ultimi uno solo, così che se il punteggio sale si sa a che cosa attribuirlo. Gli autori la chiamano un vincolo «in stile $L_0$»: conta quante modifiche sono attive, non quanto sono grandi. Il secondo freno è la memoria: ogni candidato valutato viene registrato con il componente toccato, l’ipotesi che voleva verificare, il diff, la variazione di punteggio e di costo, e l’esito. Un’idea già bocciata resta bocciata, invece di essere riproposta con parole diverse. Il terzo è l’esplorazione forzata: se per tre round il progresso resta dentro la fascia di rumore, una parte del budget va ai componenti mai toccati. Il caso tipico è il proponente che continua a riscrivere il prompt e non guarda mai la gestione della memoria.

Dal lato di chi seleziona, i filtri sono quattro e non si compensano fra loro. Un critico, lo stesso modello con un altro ruolo, legge il diff prima della valutazione e scarta le modifiche che contengono nomi di task, entità, valori o risposte del benchmark, oppure meccanismi inerti. Il punto sottile è il «prima»: una modifica che bara non riceve mai il punteggio gonfiato che la renderebbe attraente nei round successivi. Poi c’è la soglia di rumore: prima di cominciare si valuta più volte l’harness di partenza per stimare quanto oscilla il punteggio da solo, la fascia $\delta$, e nessun candidato può scendere sotto il miglior punteggio visto meno $\delta$. Serve a impedire la discesa per piccoli passi, ognuno abbastanza piccolo da sembrare rumore.

Il terzo filtro mette un prezzo alla complessità. Se un candidato guadagna $\Delta S$ punti oltre la fascia di rumore e aumenta del $\Delta C$ relativo i token consumati dal modello, deve valere

$$\Delta C \le \beta_0 + \beta_1 \, \Delta S$$

cioè: un aumento di costo è tollerato solo se pagato da un aumento di punteggio. Nell’impostazione di codice, per esempio, $\beta_1$ corrisponde a un margine del 25% di token in più per ogni esecuzione riuscita in più. Infine la potatura: i componenti che in una finestra di quattro o cinque round non hanno prodotto un guadagno misurabile vengono segnalati al proponente come candidati all’eliminazione. Un meccanismo deve continuare a guadagnarsi il posto.

I numeri

La prova è su otto benchmark in tre domini. In ciascuno l’harness evolve su un solo insieme e poi viene eseguito, invariato, su benchmark mai visti. Per il codice si evolve su Terminal-Bench 2.1 e si trasferisce su SWE-bench Verified; per il lavoro d’ufficio agentico si evolve su Harvey LAB (compiti legali, 120 per l’evoluzione e 40 tenuti da parte) e si trasferisce su JobBench, GDPval e APEX-Agents; per la progettazione ingegneristica si evolve su EngDesign e si trasferisce su Frontier-Eng. Il modello congelato è Claude Opus 4.8, e lo stesso modello fa da proponente, analista e critico.

L’harness evoluto guadagna in casa e fuori casa, in tutti e tre i domini. Nessun insieme tenuto da parte peggiora.

La tabella più istruttiva è il confronto con i quattro metodi precedenti, tutti fatti partire dallo stesso harness con lo stesso budget di candidati. Su Harvey LAB tutti migliorano il punteggio di casa, e Meta-Harness più di tutti. Fuori distribuzione, sulla media di JobBench, GDPval e APEX-Agents, la classifica si capovolge: AHE e TTHE finiscono sotto l’harness da cui erano partiti. RRSI ha il guadagno di casa più piccolo di tutti, e l’unica media esterna che supera quella di partenza di più di un punto.

L’ablazione racconta la stessa storia. Senza alcun freno, l’evoluzione tocca 92,8 in casa (il massimo di tutti) e resta a 40,3 fuori, a meno di un punto dal non aver fatto nulla. E consuma 3,80 milioni di token per esecuzione contro 2,42. Togliere i soli filtri di selezione alza il punteggio di casa e fa cadere quello esterno a 41,0. Togliere i soli vincoli del proponente sposta appena di 0,2 punti il risultato in casa (90,7 contro 90,5), ma ne costa 1,7 fuori. L’abstract parla di un harness che consuma il 30% di token in meno dell’evoluzione senza regole; nell’ablazione il confronto diretto è 2,42 contro 3,80 milioni per esecuzione, cioè circa il 36% in meno, e il paper non spiega lo scarto fra le due cifre. Resta però un fatto che gli autori non nascondono: l’harness di partenza costa 1,56 milioni di token, e nessun harness evoluto è altrettanto economico. Parte del guadagno è comprata con più calcolo.

Due prove di robustezza. Ripetendo l’evoluzione del codice con Gemini 3.5 Flash come modello, Terminal-Bench sale da 64,6 a 78,7 (+14,1, il massimo del paper) e SWE-bench Verified guadagna 2,2 punti. E lo stesso harness, eseguito con Gemini 3.1 Flash Lite, un modello più piccolo che non ha mai partecipato alla ricerca, passa da 11,2 a 14,6 su Terminal-Bench: pochi punti assoluti, ma un harness che aiuta anche un modello che non l’ha scritto è un indizio che dentro ci sia un meccanismo, non un adattamento.

Che cosa non dice

I limiti dichiarati sono tre: si lavora solo sull’harness con pesi congelati; il metodo dipende comunque da un insieme finito di compiti e da parecchi iperparametri (budget, fascia di rumore, finestre, i due $\beta$), e quindi dalla qualità del segnale e dal budget di ricerca scelto (in appendice gli autori precisano di averli fissati sull’insieme di casa senza guardare i test esterni); la validazione su architetture, ecosistemi di strumenti e processi più lunghi resta da fare. Se ne aggiungono altri. La maggior parte dei benchmark agentici è valutata da un modello giudice, e un harness potrebbe imparare a scrivere come piace al giudice: gli autori rispondono che nel dominio ingegneristico i voti vengono da simulatori deterministici e i guadagni reggono, argomento valido ma limitato a quel dominio. Nelle tabelle dei risultati non compaiono intervalli di confidenza, e differenze di un punto su benchmark giudicati da modelli vanno lette con prudenza. E i numeri vengono da un solo gruppo, con un modello proponente fra i più capaci disponibili: quanto il critico anti-scorciatoie funzioni con un modello più modesto non è misurato.

Perché conta adesso

L’auto-miglioramento ricorsivo è una delle promesse più citate del momento, e di solito se ne parla in termini di pesi e di intelligenze che si superano. Questo paper lo riporta a terra: la sua forma già praticata è un modello che ritocca il programma attorno a sé, e il suo difetto principale non è la velocità ma l’onestà della misura. Un sistema che migliora sé stesso contro un punteggio finisce per migliorare il punteggio. La risposta di RRSI non ha niente di nuovo in senso stretto (è la lezione della validazione e della regolarizzazione, vecchia quanto il machine learning), ma dimostra che va riapplicata anche quando l’oggetto ottimizzato è codice e non parametri. Per chi costruisce agenti la morale è pratica: un’evoluzione automatica che non misura su compiti esterni, non stima il proprio rumore e non paga i token che aggiunge rischia di imparare le risposte a memoria.

Codice e traiettorie complete, con ogni proposta, ogni decisione del critico e ogni diff, sono annunciati su github.com/google-research/rrsi e sul sito del progetto.