Shanghai Artificial Intelligence Laboratory ha presentato Self-Harness, un framework sperimentale per agenti basati su modelli linguistici che non modifica i pesi del modello, ma consente all’agente di intervenire sul proprio “harness”: l’insieme di istruzioni, strumenti, memoria, regole di verifica, procedure di recupero dagli errori e logiche di orchestrazione che determinano come il modello usa l’ambiente operativo.
Il punto centrale è che lo stesso modello linguistico può ottenere risultati molto diversi in base al sistema che ne governa l’esecuzione. Un agente può avere accesso agli stessi strumenti e allo stesso budget di inferenza, ma fallire perché non crea in tempo un file richiesto, ripete comandi già falliti, perde modifiche all’ambiente tra sessioni di shell, continua a esplorare senza passare all’implementazione oppure dichiara concluso un compito senza verificare l’artefatto prodotto. Self-Harness tratta questi problemi come difetti del livello di orchestrazione, non necessariamente come limiti intrinseci del modello.
Il framework introduce un ciclo iterativo composto da tre fasi. Nella prima, chiamata Weakness Mining, l’agente viene eseguito su una serie di task e vengono raccolte le tracce operative: messaggi, chiamate agli strumenti, comandi eseguiti, errori, risultati intermedi e verifiche finali. Le esecuzioni fallite non vengono considerate singolarmente, ma raggruppate in base a firme di errore ricorrenti. In questo modo il sistema cerca pattern osservabili, come retry ripetuti dello stesso comando, assenza di file obbligatori, errori di parsing, loop di esplorazione o mancata persistenza delle variabili d’ambiente.
Nella seconda fase, Harness Proposal, il modello riceve le evidenze ricavate dalle proprie esecuzioni e propone modifiche limitate al proprio harness. Le modifiche possono riguardare istruzioni operative, controlli sugli artefatti, middleware attivati dopo un errore, gestione dei tool, procedure di verifica, regole per interrompere cicli improduttivi o meccanismi di recupero. Il framework richiede che ogni proposta sia collegata a uno specifico meccanismo di fallimento e che non sostituisca integralmente l’architettura dell’agente. L’obiettivo è produrre interventi piccoli, verificabili e attribuibili a una causa tecnica precisa.
La terza fase, Proposal Validation, è il filtro che evita di trasformare ogni modifica apparentemente sensata in una nuova regola permanente. Ogni variante dell’harness viene sottoposta a test di regressione su task separati. Una modifica viene promossa soltanto se migliora le prestazioni senza degradare in modo misurabile i risultati sulle attività non utilizzate per ricavare il problema iniziale. Le modifiche accettate possono essere poi combinate nel successivo harness operativo, mentre quelle respinte vengono conservate come tentativi non adottati.
Gli autori hanno valutato Self-Harness su Terminal-Bench-2.0, benchmark composto da task in ambienti containerizzati nei quali un agente deve lavorare attraverso file system, shell, comandi, strumenti di modifica e verificatori deterministici. Il test ha usato un harness iniziale volutamente essenziale, costruito sul software DeepAgent di LangChain, con prompt di sistema ridotto e strumenti base per lettura, scrittura, modifica di file ed esecuzione di comandi shell. Sono stati mantenuti invariati modello, strumenti, budget, ambiente e valutatore: l’unico elemento modificato è stato l’harness.
I tre modelli analizzati sono MiniMax M2.5, Qwen3.5-35B-A3B e GLM-5. Sui task held-out, cioè non mostrati al sistema durante l’analisi delle tracce di errore, MiniMax M2.5 è passato dal 40,5% al 61,9% di task completati correttamente. Qwen3.5-35B-A3B è salito dal 23,8% al 38,1%, mentre GLM-5 è passato dal 42,9% al 57,1%. Il miglior incremento assoluto rilevato è di 21,4 punti percentuali; per Qwen3.5, che partiva da una base più bassa, il miglioramento relativo sui task usati nel ciclo di ottimizzazione ha raggiunto il 138%.
Le modifiche selezionate non sono state identiche per tutti i modelli. Per MiniMax M2.5, il framework ha introdotto regole per creare prima gli artefatti obbligatori, gestire con maggiore precisione l’output strutturato dei tool e interrompere sequenze di chiamate troppo lunghe o improduttive. Nel caso di Qwen3.5-35B-A3B, le correzioni hanno riguardato la verifica preventiva delle dipendenze, l’evitamento di comandi falliti ripetuti, la gestione degli errori di strumenti e il recupero degli artefatti mancanti. Per GLM-5, invece, Self-Harness ha privilegiato la persistenza delle modifiche all’ambiente tra sessioni shell e il passaggio più rapido dall’esplorazione alla scrittura e al collaudo della soluzione.
Il risultato più rilevante non è una forma di autoaddestramento del modello. Self-Harness non aggiorna parametri, pesi o dataset del modello linguistico. Opera sul livello software che circonda il modello e ne disciplina il comportamento operativo. In pratica, l’agente conserva lo stesso motore di inferenza ma può riscrivere, sottoporre a test e adottare alcune regole del proprio ciclo di lavoro, purché il cambiamento sia supportato da tracce di esecuzione e superi una verifica automatica contro regressioni.
La ricerca resta circoscritta a modifiche limitate e a un benchmark con verificatori deterministici. Gli stessi autori precisano che non si tratta di un meccanismo di auto-miglioramento aperto o illimitato: la qualità del processo dipende dalla qualità delle tracce raccolte, dalla correttezza dei verificatori e dalla robustezza dei test di regressione. In applicazioni più sensibili, soprattutto dove un agente può intervenire su infrastrutture, dati o processi aziendali, la semplice non regressione del tasso di successo non sarebbe sufficiente e servirebbero vincoli, autorizzazioni e controlli più rigorosi.
Self-Harness propone quindi un modello di sviluppo per agenti in cui prompt, procedure, memoria operativa, strumenti e regole di recupero non vengono ottimizzati soltanto da sviluppatori umani o da modelli esterni più potenti. Il sistema può usare i propri fallimenti osservabili per suggerire modifiche circoscritte al proprio strato di orchestrazione, mantenendo ogni revisione registrabile, testabile e reversibile.