LongHorizon-Harness: l’agente che non si fida di sé stesso finisce più compiti lunghi

Chi ha seguito la ristrutturazione di una casa sa come va a finire quando l’impresa si controlla da sola. L’idraulico dice che l’impianto è fatto, il muratore chiude la traccia, e il tubo che perde lo si scopre sei mesi dopo, sotto le piastrelle. Per questo nei cantieri seri i ruoli sono tre: chi decide che cosa si fa oggi, chi lo fa, e un direttore dei lavori che passa a guardare prima che si vada avanti. E sul registro del cantiere finisce ciò che ha visto chi controlla, non ciò che dice chi ha lavorato.

È questa, portata dentro un agente software, l’idea di LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks, depositato su arXiv il 3 agosto 2026 (2608.01964). Lo firmano otto ricercatori del DreamX Team di Alibaba Group, con Ziyu Ma, Hailang Huang, Shun Zou e Yong Wang primi autori a pari merito e Wang come responsabile del progetto.

Il problema dei compiti lunghi

Un compito lungo, per un agente, è una catena di decine o centinaia di passi che dipendono l’uno dall’altro: aprire un’applicazione, raccogliere dati, modificare un file, verificare, correggere. Il paper cita la misura di METR secondo cui l’orizzonte dei compiti che gli agenti di frontiera completano raddoppia circa ogni sette mesi, ogni quattro per i modelli recenti. Ma un orizzonte più lungo non rende l’esecuzione più affidabile, e gli autori ne elencano tre cause: gli errori che si accumulano e allontanano dall’obiettivo, il degrado di un contesto che cresce senza sosta, e la perdita dello stato del compito (che cosa era richiesto, che cosa è già fatto, quali file sono stati prodotti, che cosa si è scoperto dell’ambiente).

Harness come Claude Code, Codex CLI o OpenClaw hanno già pianificazione, sotto-agenti e revisori in contesti separati. Secondo il paper restano però due accoppiamenti strutturali. Il primo: lo stesso contesto serve a eseguire il lavoro e a ricordarsi a che punto si è, e più la cronologia si allunga più il secondo compito diventa difficile. Il secondo: chi esegue un passo è anche chi giudica se il passo è riuscito, e un giudizio sbagliato, una volta scritto, diventa la premessa delle decisioni successive.

Gestire, eseguire, verificare

La proposta riformula l’esecuzione lunga come un problema di gestione dello stato. Lo stato vive fuori dall’esecuzione, come registro esplicito, e si aggiorna solo con fatti verificati sull’ambiente. Il lavoro procede a giri, ognuno diviso in tre tempi: Manage-Execute-Audit, MEA.

Il manager è l’unico a possedere il registro, e non ha alcun accesso al computer: non vede lo schermo, non legge i file, non lancia comandi. Il registro contiene requisiti, artefatti e fatti, ciascuno marcato come completato, in sospeso, bloccato o non affidabile, con il rimando al controllo che ne sostiene lo stato. A ogni giro il manager aggiorna il registro e decide la mossa successiva:

$$(S_{i+1},\, q_{i+1},\, c_{i+1}) = \Phi_{\text{mgr}}(T,\, S_i,\, V_i)$$

dove $T$ è il compito originale, $S_i$ lo stato, $V_i$ la sequenza dei rapporti di verifica, e $q_{i+1}$ una fra quattro decisioni: eseguire, dichiarare finito, dichiarare bloccato, chiedere all’utente un’informazione o un’autorizzazione. Quando si esegue, $c_{i+1}$ è un contratto: un solo sotto-compito con obiettivo, criteri di accettazione, vincoli e le prove precedenti che servono.

L’esecutore è l’unico che può modificare l’ambiente, e parte ogni volta da un contesto nuovo: riceve il compito, lo stato, il contratto e i rapporti richiamati, non le traiettorie dei giri precedenti. Esiste in due versioni, una per l’interfaccia grafica (screenshot, clic, testo) e una per la riga di comando (shell, file, test), e il manager sceglie quale chiamare. Dentro il suo giro è un agente normale, Claude Code o Codex con il loro ciclo intatto dietro un adattatore leggero; ma a fine giro la sua traiettoria viene buttata. Resta solo un resoconto, che non vale come prova.

Il revisore, infine, parte anche lui da zero, non vede il ragionamento dell’esecutore e ispeziona l’ambiente in sola lettura: se tocca un file sotto controllo, l’harness lo registra come violazione d’integrità e il suo rapporto non può più far segnare nulla come completato. Il rapporto dice se il contratto è soddisfatto, se l’ambiente è integro e quali fatti sono stati accertati. Fra un giro e l’altro passano solo questi rapporti e il registro che il manager ne ricava: nient’altro fa da memoria.

Il ciclo si ferma quando lo stato verificato soddisfa il compito, quando nessun contratto permesso può più far avanzare i requisiti rimasti, quando serve l’utente, o quando si esaurisce il budget: negli esperimenti al massimo 25 giri, con 1800 secondi per ogni esecuzione e 300 per manager e revisore. Salvo diversa indicazione, i tre ruoli usano lo stesso modello.

I numeri

Le prove sono su tre benchmark recenti. WeaveBench: 114 compiti che mescolano interfaccia grafica e riga di comando nello stesso flusso di lavoro, divisi in otto domini. Superato vuol dire punteggio di almeno 0,8, assegnato da un giudice automatico (Claude Opus 4.7, da protocollo ufficiale). Con Qwen 3.7-Plus, passare da Claude Code da solo a LongHorizon-Harness (stesso modello, e Claude Code sempre come esecutore) alza sia la quota di superati sia il punteggio medio. La quota migliora in tutti gli otto domini, di più quelli di design e spaziali (+60 e +50 punti), poco il desktop, che partiva già da 83,3%. Gli autori scrivono che il risultato «quasi raddoppia» il miglior valore ufficiale, 41,2% di Claude Opus 4.7 con Claude Code, ma avvertono che le loro esecuzioni girano con privilegi di root e quelle ufficiali no: il confronto che regge è fra le loro due configurazioni.

OSWorld 2.0: 108 flussi di lavoro da scrivania, con un tempo mediano umano di circa 1,6 ore. Con Qwen 3.7-Plus crescono sia i compiti completati per intero sia il punteggio parziale. Qui però il termine di paragone è il risultato ufficiale di Qwen «un’azione alla volta», con la sola interfaccia grafica, mentre l’harness usa anche la riga di comando. Con Claude Opus 4.7, su un sottoinsieme di 34 compiti e con lo stesso squilibrio, la tabella del paper dà da 20,6% a 35,3% (7 e 12 compiti); l’abstract scrive 20,0% e 34,3%, valori che su 34 compiti non possono uscire. Su Terminal-Bench 2.1, solo riga di comando, Qwen 3.7-Plus migliora anche qui, in media su tre esecuzioni per compito; con Codex come esecutore e GPT-5.6 Luna si arriva all’83,1%.

Il dato più interessante sta nei 17 compiti del dominio giochi di WeaveBench, dove gli autori provano anche Opus 4.7 con e senza harness. Qwen con l’harness batte Opus con Claude Code.

I sei compiti in cui Qwen partiva quasi da zero (0,04 o meno) risalgono tutti fra 0,30 e 0,92, mentre cinque, quasi tutti già buoni in partenza, perdono fra 0,04 e 0,12: l’harness alza soprattutto il pavimento. Gli autori ne traggono che la capacità di un agente è del sistema modello più harness, non del modello da solo.

I casi scelti dagli autori rendono l’idea meglio delle medie. In un compito su Wireshark l’agente di base si accorge che una finestra di dialogo non risponde, ma l’osservazione resta sepolta nella cronologia e l’agente ci riprova per più di 400 passi; con MEA il blocco finisce nel registro, i giri successivi si concentrano sulle prove ancora mancanti, e il punteggio passa da 0,59 a 0,92. In un documento LibreOffice la base modifica direttamente l’XML, vede titoli che sembrano giusti e si ferma: ma il compito chiedeva di applicare gli stili dall’interfaccia, e prende 0. Con MEA l’esecutore passa dall’interfaccia e il revisore analizza l’XML per controllare che tutti e 15 i titoli abbiano davvero lo stile richiesto (0,89).

Il prezzo, e che cosa non dice

La verifica costa. Su OSWorld i token in uscita per compito passano da 28,9 mila a 104 mila; su WeaveBench il consumo totale è 2,3 volte la base. Il manager pesa poco (fra il 2 e l’8% dei token), il revisore molto (fra il 19 e il 38%). Ma il moltiplicatore non è fisso: su Terminal-Bench i token calano del 24%, e sui giochi Opus scende da 16,5 a 11,1 milioni di token per compito mentre Qwen sale da 10,7 a 34,3. La lettura degli autori: un modello forte soddisfa i contratti con meno giri, uno debole paga in ripetizioni.

I limiti, alcuni dichiarati dagli autori stessi fra analisi e appendice. Il guadagno si concentra dove il collo di bottiglia è tenere insieme molti stati dipendenti (amministrazione di sistema, su Terminal-Bench, sale da 0,593 a 0,889) e si assottiglia o diventa negativo nelle categorie analitiche brevi, dove conta la capacità del singolo passo: la verifica scopre un errore, non regala al modello una competenza che non ha. Nei compiti in cui la correttezza dipende da soglie nascoste o da convenzioni di valutazione non visibili, l’harness può produrre, parole loro, «una risposta sbagliata verificata con sicurezza»: il revisore controlla il contratto, e se il contratto è frainteso lo è anche il controllo. Le istruzioni simboliche (comandi, tabelle, campi) si scompongono bene in passi verificabili; tutorial video, geometria CAD e movimenti fini del mouse no.

Altro si nota leggendo. Manca un’ablazione che separi i tre ingredienti (registro esterno, contesto nuovo, revisore indipendente) e dica quale conta di più. Su OSWorld 2.0 nessuno dei due confronti è a parità di condizioni, benché la sezione sperimentale dichiari un confronto con Claude Code per ogni modello. Solo per Terminal-Bench si dichiarano più esecuzioni, e non compaiono intervalli di confidenza. E il revisore è lo stesso modello dell’esecutore con un altro incarico: indipendente nel contesto, non nelle debolezze.

Perché conta adesso

Il risultato più citabile del paper è anche il più circoscritto: sui 17 giochi un modello più debole, organizzato meglio, supera uno più forte organizzato peggio. Basta a dire che negli agenti conta anche come è organizzato il lavoro, non a misurare quanto. L’idea non ha niente di esotico: è la separazione dei poteri di ogni processo che debba essere affidabile (chi fa non certifica, il registro lo tiene chi non ha le mani sul lavoro) applicata a tre ruoli che sono lo stesso modello con tre cappelli diversi. Per chi costruisce agenti la lezione pratica è semplice e costa token: non scrivere mai nello stato di un compito lungo ciò che l’agente dice di aver fatto, ma ciò che qualcun altro ha visto.

Codice su github.com/AMAP-ML/LongHorizon-Harness, pagina del progetto su lh-harness.pages.dev.