Harness engineering: come gli agenti migliorano il sistema che li governa
Un’esecuzione fallita può rivelare un difetto nel sistema intorno al modello. Alcuni progetti recenti affidano all’agente la proposta di una correzione, ma lasciano ai test indipendenti il giudizio sul risultato.
Un agente avvia un server di sviluppo in background. Venti minuti dopo deve verificarne lo stato, ma il terminale ha restituito soltanto una riga di testo. Non esiste un identificatore persistente, i log sono usciti dal contesto e un secondo avvio trova la porta occupata.
Un tool migliore registra ID del processo, comando, directory, stato e percorso dei log. L’agente può controllare o terminare il job. Il modello è lo stesso; è cambiato il suo harness.
L’harness trasforma le predizioni del modello in un processo operativo. Costruisce il contesto, espone le azioni, conserva lo stato, gestisce tentativi e deleghe, applica i permessi e collega il lavoro a test e supervisione umana. Quello che sembrava semplice codice di raccordo è diventato una variabile importante nelle prestazioni degli agenti.
La ricerca più recente aggiunge un passaggio: l’agente legge le proprie traiettorie fallite, propone modifiche all’harness e le sottopone a verifica. Self-Harness riporta un aumento dal 40,5% al 61,9% per uno dei modelli testati sul proprio split di regressione. Agentic Harness Engineering (AHE) passa dal 69,7% al 77,0% su Terminal-Bench 2 dopo dieci iterazioni. I protocolli sono diversi e i numeri non costituiscono una classifica.
Il miglioramento è credibile solo se la parte modificabile ha confini netti. Un agente capace di riscrivere il valutatore, ampliare i permessi o aumentare il budget può alzare il punteggio senza lavorare meglio.
La capacità appartiene all’intero stack
Un modello predice la continuazione di una sequenza. Un agente aggiunge un ciclo di azioni in un ambiente:
obiettivo → contesto → modello → azione → ambiente → osservazione
↑ │
└──────── prossimo turno ─────┘Ogni freccia contiene scelte progettuali. L’harness decide quali file entrano nel contesto, come restituire gli errori del compilatore, se i job in background restano visibili e cosa fare dopo un test fallito. Un modello può sapere che deve controllare un server già avviato e fallire comunque perché il tool non fornisce un riferimento al processo.
OpenAI chiama agent loop la parte di Codex che coordina utente, modello e strumenti. In un esperimento interno agent-first, l’azienda riferisce che Codex ha scritto circa un milione di righe di codice in un decimo del tempo umano stimato. Gli ingegneri si sono concentrati sulla leggibilità del repository, sui vincoli architetturali e sui cicli di feedback. (agent loop, esperimento)
Anthropic descrive un risultato simile per i lavori che attraversano più finestre di contesto. Il suo harness lascia piani, file di avanzamento e incrementi verificabili alle sessioni successive. La continuità nasce da artefatti persistenti, non da una nuova memoria neurale. (Effective harnesses for long-running agents)
modello di base
├── formato dei messaggi e dei tool
├── costruzione e compressione del contesto
├── memoria e artefatti persistenti
├── workflow, tentativi e parallelismo
├── valutatori e osservabilità
└── permessi, sandbox e supervisioneUn benchmark misura questo stack anche quando la classifica mostra soltanto il nome del modello. L’harness può rivelare o nascondere una capacità; se è calibrato sulle abitudini di un modello, può funzionare male con quello successivo.
Questo rende più delicato il confronto tra modelli. Un punteggio può salire perché il modello ragiona meglio, perché la descrizione del tool è più chiara, perché il retrieval del contesto funziona meglio o perché il sistema compie più tentativi. Sono tutti progressi ingegneristici, ma sostengono affermazioni diverse. Per interpretare il risultato servono versione dell’harness, budget e protocollo di valutazione.
Il legame tra i livelli spiega anche perché piccoli difetti dell’interfaccia abbiano effetti estesi. Un tool di modifica ambiguo trasforma ripetutamente intenzioni corrette in patch non valide; la perdita dello stato dei processi ostacola ogni workflow asincrono. Una correzione persistente può invece trasferirsi tra task perché cambia l’ambiente nel quale le decisioni diventano azioni.
L’harness non sostituisce un modello capace. Non può fornire conoscenze assenti e un’orchestrazione elaborata può aggiungere latenza o nuovi errori. Il suo compito è più limitato: conservare lo stato utile, rendere osservabili le conseguenze ed evitare che difetti dell’interfaccia consumino il budget di ragionamento. Un sistema può quindi migliorare su un benchmark senza che il modello acquisisca una nuova capacità generale.
Tre schemi che funzionano
Il primo requisito è rendere visibile l’esito di ogni azione. autoresearch di Andrej Karpathy riduce il ciclo all’essenziale: modifica un piccolo sistema di training, lo esegue per cinque minuti, legge la metrica e conserva o scarta la modifica. A rendere credibile l’esperimento sono misura e budget fissi. Una traccia che dice «timeout» spiega poco; una sequenza che mostra l’avvio riuscito, la perdita dello stato e la successiva collisione della porta identifica un meccanismo.
Il secondo è lasciare che lo stato sopravviva al prompt. Log, diff, screenshot e report di test non devono occupare tutti il contesto attivo. Possono restare in file indirizzabili, mentre il prompt contiene un indice e lo stato corrente. La memoria è ciò che il sistema può recuperare; il contesto è la parte che il modello vede in quel momento. Gli artefatti persistenti permettono inoltre di ricostruire una conclusione.
Il terzo riguarda il lavoro parallelo. Un agente coordinatore deve poter avviare, controllare, interrompere e raccogliere un worker. Servono responsabilità delimitata, stato visibile e output persistente: lo stesso contratto necessario per un qualsiasi processo in background.
Il parallelismo è utile quando gli incarichi sono separabili. Più worker sugli stessi file introducono costi di integrazione e responsabilità incerte; più worker su fonti indipendenti possono restituire evidenze distinte. L’harness deve conservare l’origine di ogni artefatto e l’esito della sua valutazione. Avviare più sessioni senza raccolta e attribuzione aggiunge concorrenza, non coordinamento.
Questi schemi hanno un obiettivo concreto. Il runtime non deve imitare la memoria o la gestione umana: servono identificatori stabili, artefatti recuperabili, stati espliciti del ciclo di vita e risultati del verificatore collegati alle prove. Così l’errore rimane disponibile per l’esperimento successivo invece di sparire nella conversazione.
Dall’errore alla modifica dell’harness
Il prompt engineering cambia le istruzioni. Il context engineering seleziona le evidenze presentate al modello. Il workflow engineering interviene su ordine delle operazioni, verifiche, tentativi e deleghe. L’harness engineering può modificare il runtime: tool, parser, middleware, memoria e procedure di ripristino.
La ricerca tratta sempre più spesso questi livelli come spazi di ricerca. Agentic Context Engineering cura lezioni ricavate da traiettorie riuscite e fallite; Meta Context Engineering evolve la funzione che le recupera e formatta. Automated Design of Agentic Systems e AFlow cercano workflow eseguibili.
Un ciclo verificabile ha pochi passaggi:
leggere le esecuzioni fallite
→ individuare un meccanismo ricorrente
→ proporre una modifica circoscritta e una previsione
→ provarla su evidenze separate
→ conservarla oppure annullarlaMeta-Harness: conservare la traccia
Meta-Harness parte da un limite degli ottimizzatori testuali: riassumono gli errori troppo presto. Il sistema offre a un coding agent una directory con implementazioni, punteggi e traiettorie precedenti, consultabili con normali strumenti per file e shell.
Lo studio riporta un vantaggio di 7,7 punti rispetto a un solido sistema di gestione del contesto nella classificazione testuale online, usando quattro volte meno token di contesto. Nel ragionamento matematico con retrieval, un harness scoperto durante la ricerca guadagna in media 4,7 punti su 200 problemi di livello IMO e cinque modelli held-out. I candidati superano anche le baseline di TerminalBench-2 considerate dagli autori.
Su TerminalBench, però, ricerca e valutazione finale usano gli stessi 89 task. Gli autori controllano la presenza delle stringhe dei task, ma non si tratta di generalizzazione held-out. Solo l’esperimento matematico misura il trasferimento a cinque modelli non visti.
Self-Harness: una modifica circoscritta
Self-Harness raggruppa gli errori per causa, non soltanto per etichetta del valutatore. Un timeout dovuto a un processo invisibile richiede una soluzione diversa da quello provocato da un’esplorazione inconcludente. Il proponente riceve una superficie modificabile limitata e la cronologia dei tentativi; le alternative vengono provate su un insieme held-in e su uno split di regressione nascosto al proponente.
Su Terminal-Bench-2 lo studio riporta 40,5% → 61,9% per MiniMax M2.5, 23,8% → 38,1% per Qwen3.5-35B-A3B e 42,9% → 57,1% per GLM-5. I punteggi dello split di regressione sono consultati a ogni promozione: è quindi un insieme di selezione, non un test finale indipendente. I risultati valgono per modelli, task e harness iniziale dell’esperimento.
AHE: scrivere prima la previsione
Agentic Harness Engineering associa a ogni modifica una previsione: quale errore dovrebbe correggere, quale comportamento deve conservare e quali regressioni potrebbe introdurre. I riassunti rimandano alle evidenze grezze e i componenti modificabili restano in file ispezionabili.
Dieci iterazioni portano pass@1 su Terminal-Bench 2 dal 69,7% al 77,0%, oltre la baseline Codex-CLI del 71,9% riportata nello studio. L’harness congelato si trasferisce ad altre famiglie di modelli con incrementi dichiarati tra 5,1 e 10,1 punti percentuali e usa il 12% di token in meno dell’harness iniziale su SWE-bench Verified. Gran parte dei miglioramenti arriva da tool, middleware e memoria a lungo termine, non dal system prompt.
Le previsioni sulle regressioni raggiungono però soltanto 11,8% di precision e 11,1% di recall. Dichiarare l’ipotesi aiuta ad attribuire il risultato; sono comunque i test a decidere se conservare la modifica.
Gli studi usano modelli, benchmark e budget differenti. Il contributo comune è un metodo per trasformare un errore operativo in una modifica verificabile.
Ricerca, ricorsione e costi
L’ottimizzazione dell’harness rientra nel tentativo più ampio di migliorare il processo che cerca le soluzioni. Self-Taught Optimizer applica un ottimizzatore alla funzione che migliora i programmi. Con GPT-4 le prestazioni medie aumentano tra le iterazioni; con modelli più deboli possono peggiorare. La ricorsione amplifica la capacità diagnostica disponibile, non la crea.
Darwin Gödel Machine conserva un archivio di agenti, seleziona genitori diversi e valuta i discendenti che modificano il proprio codice. Con Claude 3.5 Sonnet lo studio riporta un aumento dal 20,0% al 50,0% su un sottoinsieme di 200 task di SWE-bench Verified, dopo filtri su 10 e 60 task, e dal 14,2% al 30,7% su Polyglot. La ricerca su SWE-bench, eseguita in sandbox con supervisione umana, è costata circa 22.000 dollari ai prezzi API storici.
AlphaEvolve applica la ricerca evolutiva a programmi dotati di valutatori automatici forti. Google DeepMind dichiara di aver eguagliato lo stato dell’arte in circa il 75% di oltre cinquanta problemi matematici e di averlo migliorato in circa il 20%. Sono risultati comunicati dall’azienda.
I tre approcci richiedono variazioni eseguibili, valutazioni ripetibili, un archivio delle evidenze e una regola di selezione esplicita. Il codice si presta perché le proposte possono essere eseguite; il vantaggio si riduce quando la correttezza è difficile da misurare.
Gli aggiornamenti dei pesi sono meno reversibili. SIA sceglie tra modifiche all’harness e ai pesi, ma le evidenze sono preliminari e il task agent è più debole dei modelli che lo dirigono. Continual Harness studia modifiche online dell’harness nei giochi a lungo orizzonte e la distillazione da un teacher più forte. Un tool difettoso può essere rimosso; un aggiornamento dei pesi può alterare comportamenti non coperti dal benchmark. Prima di intervenire sui pesi conviene quindi verificare interfacce, contesto e workflow.
L’autonomia dipende dalla verificabilità
L’auto-miglioramento è più convincente quando misurare «meglio» costa poco ed è ripetibile: un test passa, un kernel corretto diventa più veloce, una loss scende a budget fisso. Manutenzione software, ricerca, strategia e design hanno valutatori più deboli. Una diff può superare i test e complicare la migrazione successiva; un esperimento valido può occuparsi della domanda sbagliata.
The AI Scientist può coordinare idee, codice, esperimenti, analisi e scrittura. È automazione sostanziale del processo, ma il valore scientifico dipende ancora da domande, baseline, evidenze e competenza disciplinare. Un falso positivo diventa più grave se viene promosso nel sistema che produrrà gli esperimenti successivi.
La superficie modificabile può includere istruzioni, descrizioni dei tool, strategie di contesto, indici di memoria, workflow e codice applicativo circoscritto. Test held-out, tracce immutabili, modello e budget di ragionamento, policy di rete, credenziali, limiti di costo e regole di deployment devono restarne fuori.
La separazione non elimina i limiti. I benchmark fissi favoriscono l’overfitting dell’harness; i test trascurano manutenibilità e impatto sugli utenti; il punteggio finale può nascondere i costi della ricerca. La selezione può ridurre troppo presto la diversità, modifiche simultanee indeboliscono l’attribuzione causale e valutazioni brevi possono premiare un harness che chiude il task di oggi rendendo più opaco il repository di domani.
Le evidenze devono sopravvivere all’ottimizzazione
Un punteggio non spiega perché un candidato sia migliorato. Il registro deve indicare versione dell’harness, modello dichiarato, budget di ragionamento e di tempo, chiamate ai tool, output, verdetto, costo e causa terminale. I report aggregati devono rimandare alla traiettoria grezza. Senza questi dati non si distingue una correzione utile da un campione fortunato o da un aumento non dichiarato del compute.
Anche la diagnosi richiede più livelli. Il valutatore fornisce il sintomo, per esempio «timeout». La traiettoria mostra il comportamento: l’agente ha avviato un secondo server senza controllare il primo. L’analisi dell’harness propone il meccanismo: il terminale ha restituito l’output senza conservare un riferimento al processo. Solo l’ultimo livello suggerisce una modifica riutilizzabile. Raggruppare tutti i timeout mescolerebbe cause diverse e produrrebbe un generico richiamo nel prompt.
I ruoli sperimentali devono restare espliciti. Un insieme held-in verifica se il difetto mirato cambia; uno split di regressione protegge i comportamenti già validi. Quando i suoi punteggi guidano ripetutamente la promozione, però, anche lo split di regressione entra nel processo di addestramento. Nascondere le traiettorie al proponente non lo rende un test finale indipendente. Per sostenere quella conclusione serve un terzo insieme mai consultato.
Il costo fa parte delle evidenze. Allungare un timeout, aggiungere tentativi o chiamare un modello più potente può aumentare il pass rate insieme a latenza e spesa. Il confronto deve quindi fissare modello e budget oppure mostrare una curva qualità-costo. Il minor uso di token di AHE e la spesa stimata della Darwin Gödel Machine sono rilevanti proprio perché l’accuratezza finale non include le risorse usate per scoprirla.
Infine, l’intervento deve essere attribuibile. Una modifica limitata per ipotesi è più leggibile di un pacchetto che cambia insieme prompt, tool e memoria. Alcune correzioni richiedono davvero più componenti; l’esperimento deve dichiararle come pacchetto, senza costruire a posteriori una spiegazione causale. Anche i candidati respinti vanno conservati, per evitare ripetizioni e mantenere alternative che potrebbero funzionare con un altro modello.
Questi controlli non impongono un’approvazione per ogni chiamata. Le decisioni umane servono ai passaggi ad alto impatto: permessi e valutatori, spese significative, pubblicazione, accesso alla produzione e migrazioni irreversibili. Ricerche e modifiche di file reversibili possono restare nel ciclo. La supervisione segue così le conseguenze, non i singoli comandi.
Che cosa dimostrano questi risultati
L’harness engineering rende possibile una forma circoscritta di auto-miglioramento. L’agente può analizzare un errore, proporre una modifica al proprio sistema operativo e conservarla quando evidenze separate la sostengono. Non è necessario cambiare i pesi.
I risultati mostrano che tool, stato, contesto e workflow incidono sulla capacità misurata. Non dimostrano un agente capace di migliorarsi senza confini; alcuni esperimenti riutilizzano i task di selezione o dipendono da benchmark specifici. L’unità credibile di progresso è una modifica versionata, accompagnata da una traccia, da un budget fisso e da un valutatore che il proponente non può modificare.
Fonti e perimetro: Lilian Weng, “Harness Engineering for Self-Improvement”; OpenAI su harness engineering e Codex agent loop; Anthropic sugli agenti long-running; gli studi collegati su ACE, MCE, Meta-Harness, Self-Harness, AHE, Darwin Gödel Machine, STOP, AlphaEvolve, SIA, Continual Harness e The AI Scientist. I risultati seguono protocolli diversi e non vanno letti come una classifica.