Harness learning: un modello da 4 miliardi impara a riscrivere l’harness di un altro, senza toccarne i pesi

Il lunedì un allenatore non cambia i giocatori. Riguarda la partita, nota che il centrocampo si perde sempre allo stesso modo sui lanci lunghi, e cambia lo schema: chi copre, chi sale, quando si passa indietro. I giocatori sono quelli della domenica prima, la squadra che scende in campo è un’altra. E un buon allenatore si riconosce da una cosa precisa: sa fare questo lavoro anche con una squadra che non ha mai visto, in un campionato che non conosce.

Al posto della squadra c’è un modello linguistico; al posto dello schema c’è l’harness, il programma che decide che cosa il modello vede, quali strumenti può usare e in che ordine procede il lavoro. È l’idea che regge Harness Learning Enables Generalizable Test-Time Adaptation, depositato su arXiv il 28 settembre 2026 (2609.35738). Lo firmano nove autori, fra cui Ruslan Salakhutdinov, Daniel Khashabi e Andrea Zanette; il progetto è guidato da Alvin Zhang. La domanda è quella dell’allenatore: si può addestrare un modello a correggere l’harness di un altro modello guardando come è andata l’esecuzione, in modo che sappia farlo anche su compiti che non ha mai incontrato?

Un agente è una coppia

L’abstract si apre con una definizione: un agente basato su un modello linguistico è definito insieme dal modello e dal suo harness. Per migliorarlo ci sono quindi due leve. Si possono cambiare i pesi, con un addestramento, oppure si può cambiare il programma attorno e lasciare i pesi dove sono. La seconda leva è quella che oggi si chiama harness engineering, ed è in gran parte un mestiere manuale: si guarda dove l’agente sbaglia, ci si chiede che cosa gli mancava, si cambia il codice e si riprova.

Il paper prova ad automatizzare quel mestiere e, soprattutto, a farlo imparare. I modelli in gioco sono due. Il solver risponde alle domande ed è congelato: i suoi pesi non cambiano mai, né durante l’addestramento né dopo. Il proposer fa l’allenatore. Riceve la descrizione del compito, il codice dell’harness attuale e un rapporto di esecuzione (i punteggi, le domande sbagliate, pezzi delle tracce; su Reasoning Gym, uno dei due banchi di prova, anche la storia delle revisioni già fatte) e scrive una modifica al codice, su Reasoning Gym nella forma «cerca questo blocco, sostituiscilo con quest’altro». L’esempio illustrativo con cui il paper apre è elementare: un harness che passava la domanda al solver e restituiva la risposta diventa un harness che controlla la risposta e, se non è valida, riprova.

Le revisioni al posto dei passi di gradiente

La forma del lavoro viene dal meta-apprendimento. Di solito un modello si adatta a un compito con passi di gradiente sui pesi. Qui l’adattamento a un compito nuovo avviene con revisioni del codice: giro dopo giro il proposer legge il rapporto e corregge l’harness, e i pesi di nessuno dei due modelli si muovono. È il ciclo interno. Il ciclo esterno si fa una volta sola, in addestramento, e insegna al proposer a scrivere revisioni che migliorano davvero le cose.

L’insegnamento passa dal rinforzo. Per ogni situazione il proposer genera un gruppo di revisioni candidate; ciascuna viene applicata, e l’harness che ne risulta viene eseguito su un insieme di domande del compito. Il punteggio di un harness $h$ su un insieme di domande $Q$ è la media dei voti del correttore automatico,

$$J(h;\,Q)=\frac{1}{|Q|}\sum_{q\in Q}\mathrm{score}(h,q),$$

e la ricompensa della revisione $i$ è il punteggio dell’harness modificato più un premio per una modifica che si applica e gira senza errori: $r_i = J(h’_i;\,Q^{\mathrm{score}}) + v_i$. Le ricompense del gruppo si confrontano fra loro con GRPO, l’algoritmo di rinforzo introdotto nel 2024 con DeepSeekMath, e il proposer si sposta verso le revisioni che hanno fatto meglio delle sorelle. Nel compito di ragionamento il rinforzo è preceduto da una fase supervisionata: il proposer studia 432 revisioni riuscite, scritte da un modello più grande che fa da insegnante.

Un dettaglio di metodo rende i numeri credibili. Le domande su cui si misura il risultato finale non entrano mai nel processo: né nel rapporto che il proposer legge, né nella scelta di quale revisione tenere. E in addestramento le domande su cui si assegna la ricompensa sono diverse da quelle da cui nasce il rapporto. È il principio del cancello di verifica portato un passo più in là: un sistema che si corregge da sé va misurato con un metro che non può toccare. E il rapporto che passa da un giro all’altro, quando porta con sé la storia delle revisioni, fa per il proposer quello che il registro fa per un agente che lavora a turni: è l’unica memoria di che cosa si è già provato.

Due banchi di prova

Il primo è Reasoning Gym, una raccolta di famiglie di problemi generati a macchina (labirinti, sudoku, anagrammi, aritmetica e molto altro), ciascuna con il suo correttore. Proposer e solver sono lo stesso modello, Qwen3.5 da 4 miliardi di parametri, e l’harness di partenza è il più povero possibile: una sola chiamata al solver, poi si estrae la risposta. Il secondo è la risposta a domande che richiedono più passaggi di ricerca (multi-hop question answering). Qui il proposer è Qwen3 da 4 miliardi, il solver Qwen3 da 8, e l’harness di partenza è già un piccolo flusso di lavoro: cerca due volte in un archivio di documenti, riassume, risponde. Il proposer si addestra su HotpotQA e viene messo alla prova anche su MuSiQue e 2WikiMultihopQA, che non ha mai visto.

Che cosa ha imparato a scrivere

Su Reasoning Gym la revisione più frequente, dopo la fase supervisionata e dopo il rinforzo, è il ciclo con interprete: invece di chiedere la risposta al solver, l’harness gli fa scrivere il calcolo in Python e lo esegue. Era già la mossa più frequente negli esempi dell’insegnante (il 48%), e il rinforzo non l’ha spostata.

Sulle domande a più passaggi le revisioni sono più interessanti, perché cambiano la forma del flusso. Una delle più comuni dopo il rinforzo separa due usi delle prove: i riassunti continuano a guidare la ricerca successiva, ma la risposta finale si scrive leggendo i passaggi recuperati, non i riassunti. Altre revisioni aggiungono un terzo giro di ricerca. Una introduce un controllo: la bozza di risposta si accetta solo se compare davvero nei passaggi recuperati, altrimenti diventa a sua volta una query e si cerca di nuovo. È un cancello di verifica, scritto dal proposer invece che da un ingegnere. Sono tutte modifiche ai passi di un flusso fisso: nella distinzione che il libro fa fra percorsi scritti e percorsi scelti, un workflow, non un agente che decide da sé i propri passi. Il proposer di partenza, prima dell’addestramento, faceva a volte l’opposto: riduceva il flusso a una sola chiamata, o toglieva del tutto il solver.

I numeri

Sulle 21 famiglie di Reasoning Gym escluse sia dalla fase supervisionata sia dal rinforzo, il punteggio medio di una singola revisione passa da 0,32 con il proposer di partenza a 0,62 dopo l’addestramento, sopra le revisioni dell’insegnante da 35 miliardi di parametri (0,56). È la media di tutte le proposte, non la migliore.

Il risultato più curioso riguarda i giri successivi. Su MuSiQue, mai visto in addestramento, una revisione isolata migliora appena l’harness di partenza. Dieci revisioni in fila, ciascuna costruita sul rapporto della precedente, arrivano invece più in alto della migliore fra ottanta revisioni indipendenti. Le proposte sono ottanta in tutti e due i casi.

Su Reasoning Gym, invece, sulle domande riformulate il proposer addestrato con il rinforzo ottiene alla prima revisione la maggior parte del guadagno dei cinque giri. Gli autori ipotizzano che conti il punto di partenza (un harness da una chiamata sola ha una correzione evidente, un flusso di ricerca ha molte manopole), senza poterlo isolare. E addestrare il proposer su sequenze di revisioni, invece che su revisioni singole, non dà un vantaggio stabile: quelli addestrati su un passo solo migliorano già giro dopo giro.

I conti da rifare

La riga che l’abstract non nomina è l’ultima della prima tabella. In appendice gli autori riportano il punteggio di un harness fisso, uguale per tutte le famiglie, che dà al solver un interprete Python per al massimo cinque turni: 0,69 sulle 21 famiglie mai viste, sopra la revisione media del proposer addestrato. Non è nascosto, ma nel testo principale non compare. Letto insieme al fatto che la mossa preferita del proposer è proprio il ciclo con interprete, dice che su Reasoning Gym buona parte di quello che il proposer impara è riscoprire, compito per compito, una ricetta generica che una persona può scrivere una volta per tutte. La migliore di otto proposte (0,83) va oltre, ma è un oracolo, scelto guardando le domande riservate, e non una regola utilizzabile in esercizio. Dopo cinque giri i punteggi salgono ancora (0,725 sulle domande riformulate), ma come media su 24 famiglie, sette delle quali viste in addestramento, e il paper non confronta i cinque giri con l’harness fisso.

Anche il titolo più facile, il modello da 4 miliardi che batte quello da 35, va letto con cura. L’insegnante è Qwen3.6-35B-A3B, e nella convenzione dei nomi di Qwen la sigla A3B indica un modello a esperti con circa 3 miliardi di parametri attivi per token: la distanza nel calcolo è molto più piccola di quella nei nomi. Il vantaggio regge comunque si contino le modifiche che non si applicano, ma non se si tolgono gli harness con punteggio zero. L’insegnante ne produce di più (30 su 152 contro 19, in una delle valutazioni), e gli autori scrivono che escluderli può rovesciare il confronto. Sulla migliore di otto, l’insegnante resta davanti.

Le figure principali, poi, escludono cinque famiglie mai viste che sia i proposer sia l’insegnante faticano ad affrontare con un harness algoritmico. Su tutte e 26 i punteggi scendono (0,28 il proposer di partenza, 0,53 quello addestrato, 0,50 l’insegnante), anche se l’ordine resta lo stesso. E il confronto fra dieci giri e ottanta tentativi isolati pareggia il numero di proposte, non il calcolo né la quantità di informazione ricevuta: i giri successivi leggono rapporti nuovi, i tentativi isolati condividono quattro rapporti sull’harness di partenza, e gli autori lo dichiarano. È la cautela da tenere davanti a ogni confronto fra harness: se insieme all’harness cambia il budget, non si sa più che cosa si sta misurando.

Infine il perimetro. I modelli sono piccoli (4 e 8 miliardi), i compiti sono rompicapi sintetici e domande a più passaggi con un motore di ricerca classico; niente agenti di programmazione, niente compiti lunghi con decine di chiamate a strumenti. Il proposer non esegue test da sé prima di proporre una modifica: legge un rapporto preparato da altri. E il solver resta sempre lo stesso, quindi non si sa se le capacità di revisione imparate restino utili quando il modello cambia, che è la situazione normale di chi lavora con questi sistemi. Una parte di questi limiti il paper la elenca da sé.

Che cosa c’è in gioco

L’harness engineering è nato come un gesto da artigiano: un fallimento si attribuisce a un pezzo del programma attorno al modello, lo si ripara lì, si riprova. Questo paper prende quel gesto e ne fa una politica addestrabile, con il rapporto di esecuzione al posto delle tracce che un ingegnere leggerebbe. Non è il solo: nel 2026 il filone si è affollato in fretta (Meta-Harness, AutoHarness, Harness-R1, JIT-Agent, TTHE, solo fra quelli che gli autori citano). Il contributo specifico qui è il trasferimento a famiglie di compiti e banchi di prova esclusi dall’addestramento, insieme alla revisione ripetuta. Il proposer non impara a correggere un harness, impara a correggere gli harness, anche di compiti che non ha visto, e la risposta è un sì parziale, con modelli piccoli e compiti contenuti.

La tabella in appendice, intanto, tiene aperta la domanda che conta per chi costruisce agenti. Non se un modello sa ritoccare un harness, perché ormai è chiaro che sa farlo, ma se lo ritocca meglio di un buon harness generico scritto da una persona che conosce il mestiere. Per una revisione singola, su Reasoning Gym, i numeri del paper stesso dicono di no. Il prossimo passo interessante non è un proposer più grande: è lo stesso confronto, fatto alla pari, su un compito dove la ricetta generica non esiste ancora.

Per approfondire

Il paper: Harness Learning Enables Generalizable Test-Time Adaptation, arXiv, 28 settembre 2026, arxiv.org/abs/2609.35738.

Nel Paithon Book il capitolo «Harness engineering: tutto ciò che non è il modello» parte dalla coppia fra modello e harness e prosegue in sei sezioni:

• Il repository come memoria: le istruzioni per l’agente, con AGENTS.md come indice e non come manuale;
• Il primo turno: la sessione che prepara il lavoro, e l’elenco delle funzionalità;
• Lavorare a turni: il registro per chi viene dopo, e la scelta fra compattare e ripartire da capo;
• Finito vuol dire collaudato: la verifica di un lavoro lungo, e chi può toccare il metro;
• Quando nessuno guarda: osservabilità ed entropia;
• Dal ciclo al grafo: percorsi scritti, percorsi scelti e il grafo come struttura dati.

Il mestiere che il paper prova ad automatizzare è raccontato soprattutto in post tecnici. Justin Young, Effective harnesses for long-running agents, Anthropic Engineering, 26 novembre 2025 (anthropic.com), con il codice d’esempio in claude-quickstarts/autonomous-coding. Prithvi Rajasekaran, Harness design for long-running application development, Anthropic Engineering, 24 marzo 2026 (anthropic.com). Ryan Lopopolo, Harness engineering: leveraging Codex in an agent-first world, OpenAI, 11 febbraio 2026 (openai.com). La distinzione fra workflow e agenti usata sopra viene da Erik Schluntz e Barry Zhang, Building effective agents, Anthropic Engineering, 19 dicembre 2024 (anthropic.com).

Il principio del metro che il sistema non può toccare ha un caso di scuola in autoresearch di Andrej Karpathy (marzo 2026): un agente modifica di notte il codice di addestramento di un piccolo modello e tiene un cambiamento solo se la misura migliora. Il caso mostra anche quanto il principio sia fragile: il divieto di toccare il file della valutazione è un’istruzione, non un controllo, e la valutazione chiama il modello che l’agente stesso ha scritto. Sui file di istruzioni ci sono anche delle misure: Gloaguen, Mündler-Sasahara, Müller, Raychev e Vechev, Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (arXiv 2602.11988, terza versione del 29 settembre 2026), e Lulla, Mohsenimofidi, Galster, Zhang, Baltes e Treude, On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents (arXiv 2601.20404, workshop JAWs di ICSE 2026). Per lo stato che un grafo di agenti salva a ogni passo, la documentazione dei checkpointer di LangGraph.