Google Harness2 rende open source l'auto-miglioramento degli agenti, ma la verifica resta il banco di prova

Google ha reso open source Google Harness2 dopo aver riportato miglioramenti fino a 11,5 punti modificando il software che circonda un agente anziché il suo modello. Questa distinzione crea la tensione centrale. Il framework consente a un agente di rivedere prompt, strumenti, memoria e altre istruzioni operative, ma deve valutare tali revisioni senza conoscere risposte corrette.

Denominato Harness² dai suoi autori, il progetto proviene da ricercatori affiliati a Google Cloud AI Research e Northwestern University. Il suo codice è apparso insieme a un articolo di ricerca del 9 ottobre 2026 e utilizza la licenza Apache 2.0. Il rilascio trasforma un metodo di ricerca in software che gli sviluppatori possono ispezionare, eseguire e modificare.

Il progetto mette inoltre in discussione un'ipotesi familiare sugli agenti AI. Risultati migliori non richiedono sempre un modello più nuovo o più grande. Possono derivare dalla modifica dell'harness, ovvero il software e le istruzioni che trasformano un modello linguistico in un sistema operativo.

Questa argomentazione mette sotto pressione i framework di agenti fissi. OpenCode, Codex, Claude Code e sistemi simili combinano modelli con prompt, strumenti, memoria e orchestrazione. Google Harness2 si chiede se questi componenti circostanti debbano rimanere fissi dopo il deployment.

La risposta conta oltre le classifiche dei benchmark. Un harness che si modifica autonomamente può adattarsi a lavori legali, d'ufficio, web e di programmazione non familiari. Può anche preservare un presupposto errato, selezionare una revisione più debole o impiegare molta più capacità di calcolo per arrivare a una risposta.

Google Harness2 modifica il software attorno a un modello congelato

Il rilascio sposta il miglioramento ricorsivo dall'addestramento del modello a otto parti modificabili del runtime dell'agente.

Un agente AI è più del modello linguistico che risponde ai suoi prompt. Dipende anche da istruzioni, strumenti disponibili, contesto archiviato, regole di delega e software che controlla ogni azione. Collettivamente, questi componenti formano l'harness dell'agente.

Google Harness2 espone otto componenti alla revisione: il prompt di sistema, i guardrail, la memoria, la guida agli strumenti, i subagenti, le skill, gli script e i plugin middleware. Ogni componente è rappresentato come un file montato nel runtime. I pesi del modello sottostante rimangono congelati.

Questa separazione è importante. Addestrare o sottoporre a fine-tuning un modello richiede infrastruttura specializzata, dati preparati e un processo di deployment separato. Modificare un prompt, una skill o un'istruzione relativa agli strumenti può avvenire mentre l'agente sta lavorando a un compito.

Il repository open source distribuisce il metodo come progetto Python per Linux. Supporta Python 3.12, il refinement parallelo e sequenziale e integrazioni con gli executor OpenCode e Codex. La dimostrazione inclusa utilizza editor deterministici ed esecuzione Python locale, così gli sviluppatori possono ispezionare il flusso di lavoro senza credenziali del modello.

Le valutazioni supportate da modelli richiedono più infrastruttura. Il repository specifica Node.js, autenticazione Google Cloud, accesso ai modelli tramite Vertex AI e dipendenze specifiche dei benchmark. WorkBuddy-Bench richiede Docker, mentre il benchmark legale richiede utility per l'elaborazione dei documenti.

Questa configurazione segnala il pubblico attuale del progetto. Si tratta di software di ricerca per team pronti a eseguire valutazioni controllate, non di una funzione per consumatori che aggiorna silenziosamente ogni agente. Il rilascio fornisce la meccanica per la sperimentazione, ma gli adottanti hanno comunque bisogno di compiti, ambienti di esecuzione, valutatori e limiti operativi.

Il framework avvia ogni compito in arrivo da un harness di base comune. Non trasferisce semplicemente la più recente configurazione specifica del compito all'assegnazione successiva. Al contrario, rifinisce temporaneamente l'harness corrente e registra lezioni riutilizzabili in una libreria di miglioramento separata.

Questa decisione affronta un problema comune nei sistemi adattivi. Un'istruzione utile per l'analisi dei contratti può danneggiare un compito su un foglio di calcolo. Accumulare direttamente ogni modifica riuscita renderebbe l'harness sempre più specializzato e difficile da comprendere.

Harness² cerca invece di conservare prove del motivo per cui una modifica sia stata utile. Un compito futuro può attingere da tale esperienza senza ereditare l'intera configurazione di esecuzione precedente.

Il progetto rappresenta quindi due forme di software. Un harness svolge il lavoro, mentre un altro migliora il sistema che lo svolge. Questo secondo livello spiega perché gli autori descrivono il metodo come recursive agent harnessing anziché come normale ottimizzazione dei prompt.

Per gli sviluppatori che già mantengono manualmente le istruzioni degli agenti, il rilascio formalizza un flusso di lavoro riconoscibile. I team esaminano gli errori, rivedono le istruzioni, rieseguono i compiti e conservano tecniche utili. Google Harness2 affida gran parte di questo ciclo agli agenti e registra le modifiche risultanti come artefatti strutturati.

Come Google Harness2 rifinisce un agente senza risposte corrette

Il suo meccanismo centrale confronta il comportamento in condizioni equivalenti invece di chiedere a un verificatore perfetto di identificare l'output corretto.

Il framework chiama il suo principale processo a livello di compito Propose-Probe-Compose. Un proposer studia prima l'esecuzione originale e suggerisce modifiche mirate all'harness. Un probe riesegue lo stesso compito con quei candidati. Un composer combina poi le modifiche supportate dalle differenze tra le traiettorie risultanti.

Una traiettoria è la sequenza registrata di risposte del modello, chiamate agli strumenti, osservazioni e file generati. Offre al sistema più prove di una sola risposta finale. L'editor può vedere se una revisione ha trovato input mancanti, richiamato uno strumento adeguato o verificato un documento prima dell'invio.

Il sistema divide le proposte in due ambiti. Un editor invariabile si concentra sul comportamento generale di esecuzione, come il controllo degli output dopo averli scritti. Un editor di dominio si concentra su conoscenze, formati o procedure specifiche del compito.

Questa separazione riduce la possibilità che ogni problema riceva la stessa correzione generica. Consente inoltre al composer di combinare una regola di processo ampiamente utile con una guida specializzata quando entrambe producono cambiamenti comportamentali utili.

In modo cruciale, il processo online non riceve la chiave delle risposte del benchmark. L'articolo di ricerca descrive un contesto open-world in cui i compiti arrivano dopo la progettazione dell'harness. Durante l'esecuzione potrebbe non essere disponibile alcun verificatore affidabile basato sulla verità di riferimento.

Invece di dichiarare corretto un candidato, il sistema cerca contrasti. Supponiamo che l'agente di base trascuri diversi file sorgente. Una revisione inventaria ogni input, mentre un'altra aggiunge una guida alla riconciliazione dei fogli di calcolo. Le loro traiettorie rivelano se questi interventi hanno modificato il processo dell'agente.

Il composer utilizza tali prove per costruire un altro harness ed eseguire nuovamente il compito. L'approccio non elimina il giudizio. Sposta il giudizio dal confronto di un output con una risposta nota al confronto del comportamento osservabile tra esecuzioni.

Gli sviluppatori possono impiegare calcolo aggiuntivo in fase di test in due modi. La ricorsione parallela esplora più revisioni candidate simultaneamente, quindi compone le prove di tali tentativi. La ricorsione sequenziale applica un ulteriore refinement dopo ogni revisione precedente.

La variabile k controlla questo budget di esplorazione. Un valore più elevato offre al sistema più opportunità di trovare e testare modifiche, ma ogni opportunità aggiunge chiamate al modello, uso degli strumenti e tempo di esecuzione.

Dopo la conclusione del compito, un secondo livello di ricorsione aggiorna l'harness di miglioramento continuo. Un reflector archivia l'harness adottato e un file di esperienza che descrive l'intervento, le prove e il risultato. Le proposte successive possono consultare quella libreria.

Questo design rende l'esperienza più portabile di un prompt finito. Una lezione archiviata potrebbe dire che i compiti di generazione di documenti traggono beneficio dalla riapertura dei file finali e dal controllo delle sezioni richieste. Tale processo può applicarsi trasversalmente ai domini anche quando i documenti esatti differiscono.

La distinzione collega inoltre il framework al lavoro quotidiano basato sulla conoscenza. Un agente potrebbe dover combinare note di riunioni, fogli di calcolo, policy e documenti di progetto prima di produrre un memorandum decisionale. La parte difficile è spesso tracciare le affermazioni attraverso le fonti, non generare prosa fluente.

I team possono già ridurre questo onere creando una base di conoscenza ricercabile. Harness² estende l'idea alla policy di esecuzione: l'agente può rivedere il modo in cui raccoglie, verifica e utilizza quel materiale per un compito specifico.

Il meccanismo resta tuttavia sperimentale. Il contrasto comportamentale è una prova, non la verità. Due candidati possono condividere la stessa premessa errata e una traiettoria rifinita può comunque portare a un risultato inadeguato.

I guadagni nei benchmark mettono sotto pressione gli harness di agenti fissi

I risultati riportati suggeriscono che il design dell'harness può modificare le prestazioni quanto la sostituzione dei modelli, soprattutto per i sistemi di partenza più deboli.

I ricercatori hanno valutato Harness² su tre benchmark professionali. WorkBuddy-Bench copre compiti di programmazione, web e ufficio. JobBench testa il lavoro professionale, mentre Harvey’s Legal Agent Benchmark misura le prestazioni nei compiti legali.

I test hanno coperto quattro combinazioni di due modelli e due harness iniziali. I modelli erano Gemini 3.5 Flash e GLM-5. Gli harness iniziali di esecuzione erano OpenCode e Codex, mentre Claude Opus 4.8 ha svolto il ruolo di editor predefinito negli esperimenti principali.

Secondo gli autori, un singolo passaggio di refinement ha migliorato ogni combinazione di modello e harness testata in tutti e tre i benchmark. I maggiori guadagni riportati hanno raggiunto 11,5 punti su WorkBuddy-Bench, 4,5 punti su JobBench e 11,8 punti percentuali nel tasso di superamento parziale del benchmark legale.

La maggiore variazione in WorkBuddy-Bench è apparsa con GLM-5 sotto OpenCode. Il suo punteggio medio è salito da 64,2 a 75,7 dopo un passaggio. Gemini 3.5 Flash sotto OpenCode è salito da 72,4 a 77,5.

Questi numeri supportano un'inferenza pratica. L'harness può ridurre parte del divario tra i modelli correggendo comportamenti di esecuzione che la sola capacità del modello non risolve.

I risultati variavano in base alla configurazione. GLM-5 sotto Codex ha guadagnato solo 1,2 punti su JobBench, passando da 23,6 a 24,8. Gemini sotto OpenCode è migliorato di 4,5 punti sullo stesso benchmark.

Questa variazione conta più della cifra di punta più alta. Il metodo non ha prodotto un miglioramento uniforme per ogni modello, harness e compito. Il suo valore dipendeva dal sistema di partenza e dal dominio.

I ricercatori hanno inoltre aumentato il budget di ricorsione. Con Gemini sotto OpenCode, il passaggio da un refinement alla ricorsione parallela con k=5 ha ulteriormente aumentato le prestazioni di WorkBuddy-Bench. La programmazione ha raggiunto 80,8, il web 81,7 e l'ufficio 83,4.

L'articolo riporta che sia i punteggi paralleli sia quelli sequenziali sono aumentati quando il budget è salito da uno a cinque in domini selezionati di WorkBuddy-Bench. I metodi concorrenti hanno mostrato cambiamenti minori o meno coerenti in quei test.

Una maggiore esplorazione non era l'intera spiegazione. In uno studio di ablazione, la rimozione della libreria di miglioramento ha ridotto le prestazioni medie di WorkBuddy-Bench di 3,1 punti. La rimozione dei ruoli degli editor con ambiti definiti è costata 2,9 punti, mentre saltare la composizione è costato 1,6 punti.

JobBench ha mostrato un modello simile. La rimozione della libreria ha ridotto il punteggio di 1,8 punti, gli editor generici hanno perso 3,7 punti e l'omissione della composizione ha perso 1,9 punti. Questi risultati indicano che l'esperienza conservata, le proposte specializzate e la combinazione basata sulle prove hanno contribuito ciascuna.

Un caso di studio di JobBench illustra il meccanismo. L'agente di base non è riuscito a riconciliare le informazioni tra i file sorgente e non ha riaperto il proprio output finale per verificarlo. Il suo punteggio è stato 43,1.

Un intervento proposto richiedeva un inventario di ogni input e una tracciabilità esplicita delle fonti. Un altro aggiungeva linee guida di dominio per la riconciliazione di calendario, sede, personale e budget. Il compositore ha mantenuto tutte e quattro le modifiche introdotte da tali interventi e la nuova esecuzione ha ottenuto 77,8.

Questo esempio rafforza l'argomentazione a favore del miglioramento dell'harness dell'agente, perché il fallimento era procedurale. Al modello non mancavano né competenze linguistiche di base né accesso ai file. Gli mancava un metodo operativo affidabile.

Gli harness fissi hanno comunque ottenuto risultati diversi nei vari domini. Il confronto dello studio ha rilevato che Claude Code era in testa tra i sistemi fissi per le attività di codice e d'ufficio, mentre Codex guidava nelle attività web. Nessun harness invariato primeggiava ovunque.

Partendo da OpenCode con un budget di ricorsione più ampio, Harness² ha superato la migliore alternativa fissa di 4,6 punti nel codice, 5,8 sul web e 4,9 nelle attività d'ufficio. Gli autori rilevano esplicitamente che questo risultato adattivo ha utilizzato calcolo aggiuntivo in fase di test.

La pressione competitiva si rivolge quindi all'approccio dell'harness fisso, non a un prodotto specifico. Un fornitore può migliorare il proprio modello, ma gli utenti potrebbero comunque ottenere risultati incoerenti se le istruzioni e gli strumenti circostanti non sono in grado di adattarsi.

Gli Harness di Agenti Auto-Miglioranti Necessitano Ancora di Verifiche Indipendenti

Harness² può migliorare il processo di un agente, ma le sue stesse evidenze mostrano che le modifiche ricorsive talvolta selezionano comportamenti peggiori o diffondono un'assunzione errata.

I risultati del benchmark provengono dagli autori del progetto e non hanno ancora dimostrato affidabilità in produzione attraverso implementazioni indipendenti. Lo studio riporta medie su tre esecuzioni, il che aiuta a misurare la variabilità ma non sostituisce una replica esterna.

Il metodo utilizza inoltre calcolo aggiuntivo prima di produrre l'output finale. Ogni proposta, sonda, composizione e nuova esecuzione consuma token e tempo di esecuzione. L'elaborazione parallela può ridurre il tempo trascorso quando è disponibile capacità, ma non elimina il costo sottostante in termini di risorse.

Lo studio colloca le configurazioni valutate su una frontiera empirica tra calcolo e prestazioni per JobBench e WorkBuddy-Bench. Questo risultato significa che i miglioramenti misurati si sono confrontati favorevolmente con le alternative testate. Non significa che la ricorsione sarà economica per ogni carico di lavoro in produzione.

Un'attività a basso valore potrebbe non giustificare più esecuzioni del modello. Un parere legale o una decisione operativa potrebbero giustificare verifiche più approfondite, ma tali ambiti richiedono anche controlli più rigorosi di quelli forniti da un esecutore di benchmark.

L'avvertimento più importante proviene dall'analisi dei fallimenti degli stessi autori. Hanno esaminato nove regressioni e le hanno raggruppate in fallimenti nella selezione dei candidati, premesse condivise errate e incertezza nella valutazione o nell'esecuzione.

In un esempio di programmazione, il framework ha selezionato un output con punteggio 55 rispetto a un'alternativa con punteggio 95. In un compito legale, una revisione più ristretta ha ridotto la copertura e abbassato il punteggio da 54 a 26.

Altri fallimenti sono iniziati da un'assunzione errata condivisa tra i candidati. Tali errori hanno prodotto perdite comprese tra 2 e 11 punti. Se ogni modifica proposta accetta la stessa premessa falsa, il confronto del loro comportamento non mette in luce l'errore originario.

Lo studio identifica inoltre decisioni mancanti del giudice e la normale variabilità tra un'esecuzione e l'altra come problemi di attribuzione. Un punteggio modificato può riflettere la modifica, l'esecuzione stocastica o il rumore della valutazione. Più sonde aiutano, ma aumentano il costo.

L'attività del repository ha evidenziato anche rischi di implementazione. Un problema aperto di identità della cache segnala che gli esperimenti ripresi possono riutilizzare output precedenti dopo la modifica delle istruzioni del compito o dei file sorgente, mentre gli identificatori del compito restano costanti.

L'autore del problema ha riprodotto il comportamento senza chiamate al modello e ha osservato che il contenuto degli input è assente da parti dell'identità salvata dell'esecuzione. La segnalazione non quantifica alcun effetto sui punteggi dei benchmark pubblicati e, al momento della revisione, non era allegata alcuna risoluzione del manutentore.

Ciononostante, il problema illustra una sfida operativa più ampia. Un sistema ricorsivo necessita di una provenienza affidabile per attività, materiale sorgente, revisioni dell'harness, output in cache e impostazioni di valutazione. Altrimenti, un miglioramento apparente può riflettere evidenze obsolete.

La sicurezza solleva un'altra preoccupazione. Gli otto componenti modificabili includono guardrail, script, plugin e istruzioni per gli strumenti. Questi file possono influenzare ciò a cui un agente accede e le azioni che esegue.

Un editor autonomo non dovrebbe ricevere autorità illimitata per indebolire i controlli di accesso, eseguire script non revisionati o conservare dettagli sensibili delle attività. L'uso in produzione richiede autorizzazioni a livello di componente, confini di sicurezza immutabili, registri di audit e rollback.

L'esperienza persistente merita una cautela simile. Una lezione utile tratta da un cliente, un reparto o una questione legale può esporre informazioni riservate quando viene recuperata per un altro contesto. Una libreria di miglioramenti necessita quindi di separazione dei dati e politiche di conservazione, non soltanto di rilevanza semantica.

I team dovrebbero inoltre distinguere l'ottimizzazione delle prestazioni dalla validazione della sicurezza. Un punteggio di benchmark premia il completamento del compito secondo il proprio valutatore. Non misura automaticamente privacy, autorizzazione, accuratezza fattuale o resistenza agli input dannosi.

Lo stesso Google Harness2 dimostra perché questa distinzione conta. Il suo compositore può preferire un candidato convincente sul piano comportamentale ma oggettivamente più debole. L'assenza di una verità di riferimento è il problema affrontato dal framework, ma rimane un limite che il framework non può eliminare.

Un progetto di produzione sensato consentirebbe al sistema di modificare indicazioni a minor rischio proteggendo al contempo le politiche fondamentali. La formulazione dei prompt e le checklist del flusso di lavoro potrebbero essere modificabili. Regole sulle credenziali, confini di rete, passaggi di approvazione e limiti alle azioni distruttive dovrebbero restare al di fuori dell'autorità dell'agente.

Anche la revisione umana resta preziosa per le modifiche proposte che persistono tra le attività. Il framework può produrre evidenze che spiegano perché una modifica è stata adottata. Gli operatori possono utilizzare tale registro per approvare, respingere o limitare la modifica prima che entri in una libreria condivisa.

L'Harnessing Ricorsivo degli Agenti Ridefinisce la Roadmap dell'Ingegneria degli Agenti

Il prossimo banco di prova è se le organizzazioni riusciranno a replicare i guadagni controllando al contempo calcolo, regressioni e memoria persistente.

Il primo segnale da osservare è la replica indipendente dei benchmark. Il repository espone codice, configurazioni, prompt e comandi di valutazione, offrendo ai team esterni un punto di partenza pratico. Le repliche dovrebbero riportare sia i punteggi finali sia l'utilizzo totale del modello.

Una replica riuscita presso fornitori diversi rafforzerebbe l'affermazione centrale. Dimostrerebbe che l'harnessing adattivo non è strettamente legato ai modelli testati, all'editor o all'ambiente Google Cloud.

L'incapacità di replicare i guadagni indebolirebbe l'argomentazione a favore della generalità. I ricercatori dovrebbero identificare se la differenza derivasse dal comportamento del modello, dalle versioni del benchmark, dagli ambienti di esecuzione o dalle impostazioni di valutazione.

Il secondo segnale riguarda le prestazioni su flussi di attività reali anziché su esecuzioni isolate di benchmark. La ricorsione a livello di harness promette valore cumulativo perché le lezioni delle attività precedenti guidano le proposte successive.

Lo studio offre evidenze iniziali di tale trasferimento. Una libreria di esperienze costruita su JobBench ha migliorato il perfezionamento in un solo passaggio su WorkBuddy-Bench di 0,6 punti per il codice, 0,5 per il web e 2,9 per le attività d'ufficio.

Questi guadagni sono inferiori ai risultati più forti a livello di attività e un'analisi ha utilizzato retrospettivamente l'esperienza di attività successive. Un'implementazione dal vivo dovrebbe dimostrare che le lezioni utili si accumulano in ordine cronologico senza importare informazioni future.

Gli operatori dovrebbero misurare i tassi di regressione insieme alle prestazioni medie. Dovrebbero inoltre monitorare la frequenza degli interventi, la latenza, il consumo del modello e la percentuale di modifiche persistenti che superano la revisione umana.

Il terzo segnale è un livello più solido di verifica e governance. Gli autori raccomandano sonde che mettano in discussione le assunzioni condivise, esecuzioni ripetute per separare le modifiche dalla variabilità e metodi di selezione migliori che bilancino copertura e precisione.

Le correzioni del repository possono fornire un altro indicatore. Identità della cache sensibili al contenuto, revisioni di benchmark bloccate e un'invalidazione affidabile renderebbero gli esperimenti più facili da riprodurre. Confini di sicurezza chiari per i componenti modificabili renderebbero l'implementazione più sicura.

Il più ampio campo della ricerca testerà anche forme alternative di adattamento dell'harness. Meta-Harness ricerca configurazioni prima dell'implementazione. ReasoningBank recupera esperienze di ragionamento utili lasciando fisso l'harness. Harness Scaling rivede un harness per singole attività.

Harness² combina l'adattamento online delle attività con un meccanismo di miglioramento persistente. Questa combinazione è la sua principale distinzione, ma concentra anche il rischio. Una revisione errata a livello di attività influisce su un risultato, mentre una lezione errata conservata può influenzare attività successive.

Per gli sviluppatori, il messaggio pratico non è che ogni agente dovrebbe riscriversi immediatamente. È che prompt, memoria, strumenti e orchestrazione meritano di essere valutati come un sistema connesso.

I team possono iniziare con esperimenti circoscritti. Possono selezionare attività rappresentative, preservare un harness di base immutabile, consentire revisioni solo in una sandbox e confrontare la qualità dell'output con il calcolo totale. Ogni modifica persistente dovrebbe rimanere attribuibile e reversibile.

I knowledge worker dovrebbero interessarsene perché la qualità dell'harness modella il comportamento visibile dell'agente. Un modello può apparire inaffidabile quando le istruzioni dei suoi strumenti sono deboli, la sua memoria è rumorosa o il suo flusso di lavoro omette la verifica. Al contrario, una procedura migliore può migliorare i risultati senza cambiare il modello.

Il rilascio open rende queste ipotesi verificabili. Offre ai ricercatori un'implementazione comune per studiare come gli agenti diagnosticano i fallimenti, rivedono le istruzioni operative e conservano esperienza.

Google Harness2 sposta in definitiva il dibattito sull'auto-miglioramento dall'intelligenza astratta del modello ad artefatti software ispezionabili. È uno spostamento utile perché i team possono esaminare i file, tracciare le revisioni e misurare le esecuzioni.

Non risolve la domanda più difficile: chi verifica il miglioratore quando non esiste una chiave di risposta? Il framework sostituisce la modifica cieca con evidenze comportamentali strutturate, ma le evidenze possono comunque trarre in inganno.

Nei prossimi mesi, osservate le repliche indipendenti, i risultati in tempo reale tra attività diverse e controlli più rigorosi sui componenti modificabili. Questi segnali determineranno se l'harnessing ricorsivo degli agenti diventerà un livello ingegneristico affidabile o resterà un promettente flusso di lavoro di ricerca.

Per i team che valutano gli agenti AI oggi, l'azione immediata è semplice. Testate separatamente il modello e il suo harness, registrate ogni modifica e richiedete evidenze chiare prima di conservare una revisione automatizzata. Google Harness2 fornisce un framework concreto per questo esperimento, mentre i suoi fallimenti riportati mostrano perché la supervisione continua a essere importante.