The Story Deep Dive

Quando un'IA diagnostica i propri punti ciechi: dentro il loop di auto-miglioramento di Hermes

Hermes Agent

Hermes Agent

@hermesagents

April 9, 2026

10 min di lettura

C'è un tipo particolare di PR nelle release notes che devi leggere due volte, perché alla prima lettura non capisci cosa è realmente successo. La voce rilevante nelle note di Hermes Agent v0.8.0 è questa:

Guidance auto-ottimizzata per l'uso di tool GPT/Codex — L'agente ha diagnosticato e corretto 5 modalità di fallimento nelle chiamate tool di GPT e Codex tramite benchmarking comportamentale automatizzato, migliorando drasticamente l'affidabilità sui modelli OpenAI. (#6120)

La prima volta che l'ho letta, ho dato per scontato che qualcuno fosse stato un po' generoso con il significato di "auto-ottimizzata". La seconda volta, ho capito che era letterale. L'agente ha eseguito una suite di benchmark contro se stesso, ha individuato fallimenti sistematici nel modo in cui i modelli OpenAI chiamavano i suoi strumenti, ha generato guidance mirata per correggere quei fallimenti e ha misurato che le correzioni funzionavano davvero. Gli umani hanno approvato il risultato. Ma l'intero passaggio di diagnosticare e correggere era automatizzato.

Vale la pena smontare il tutto, perché è il tipo di capacità che entra in una release come una singola riga e cambia l'aspetto che le release future potranno avere.

Il problema concreto

L'abbinamento di Hermes Agent con i modelli OpenAI — GPT-5, Codex — era visibilmente traballante da qualche release. Gli utenti segnalavano che Anthropic Claude girava liscio, mentre GPT-5 a volte produceva argomenti nel formato sbagliato, saltava passaggi o perdeva il filo di cosa aveva già fatto in una sequenza multi-tool. Non sono bug sottili: li puoi guardare mentre accadono. Ma sono anche esasperanti da correggere a mano, perché le modalità di fallimento sono specifiche per modello e dipendono dalla formulazione del prompt in modi difficili da intuire.

Secondo la descrizione del PR, c'erano cinque pattern ricorrenti:

  • Saltare le verifiche preliminari raccomandate prima di chiamate tool distruttive.
  • Produrre argomenti come stringhe grezze dove lo schema si aspettava oggetti strutturati o numeri.
  • Perdere traccia di quale chiamata tool era già riuscita in una sequenza concatenata, causando chiamate duplicate.
  • Rifiutarsi di fare retry dopo errori transitori anche quando la guidance lo indicava.
  • Scivolare da "eseguire il piano" a "ripianificare il piano" quando il contesto diventava lungo.

Nessuno di questi è teorico. Ognuno aveva una scia di issue su GitHub alle spalle.

Il loop che li ha corretti

L'approccio del PR #6120 ha tre parti mobili.

Primo, una suite automatizzata di benchmark comportamentale. Un harness esegue l'agente contro un insieme di scenari sintetici progettati per provocare ciascuna delle cinque modalità di fallimento. Per ogni scenario, il benchmark registra cosa ha fatto il modello, cosa avrebbe dovuto fare e se la differenza rientra in uno dei pattern di fallimento noti.

Secondo, una fase di generazione della guidance. Quando il benchmark segnala un fallimento, l'harness produce stringhe di guidance candidate — istruzioni brevi, specifiche per il modello, da aggiungere al system prompt, che mirano esattamente al pattern che ha fallito. Non "stai più attento"; cose come "prima di chiamare qualsiasi tool distruttivo, chiama prima il tool di preview corrispondente con gli stessi argomenti e riporta il suo output." Le candidate sono generate a partire dai fallimenti effettivamente osservati, non da una rubrica generica.

Terzo, una fase di re-benchmarking. Ogni stringa di guidance candidata viene testata sulla stessa suite di scenari. La guidance che migliora i punteggi viene mantenuta. Quella che fa regredire altri scenari viene scartata. Le stringhe sopravvissute vengono aggregate nel system prompt GPT/Codex che Hermes distribuisce.

Perché questa è una cosa diversa

Storicamente, i prompt distribuiti con un framework di agenti sono scritti da umani — a volte uno solo, a volte un piccolo team — che sviluppano opinioni su cosa funziona e cosa no scorrendo personalmente le conversazioni. Questo processo ha tre problemi: non scala su molti modelli, non può essere rieseguito a basso costo quando un modello viene aggiornato, e produce prompt che codificano le superstizioni di una persona insieme alle sue evidenze reali.

Sostituire il loop "un umano scrive, un umano valuta" con "un benchmark scrive candidati, un benchmark li valuta" non è la stessa cosa che lasciar fare auto-tuning a un'IA senza supervisione. Gli umani approvano comunque la guidance finale. Ma il lavoro concreto di trovare pattern e proporre correzioni è ora misurabile e ripetibile. Quando uscirà GPT-6, lo stesso harness girerà di nuovo. Quando verrà segnalata una nuova modalità di fallimento, verrà aggiunto un nuovo scenario e il loop ripartirà. Il costo di tenere il prompt sincronizzato con il comportamento effettivo del modello cala di un ordine di grandezza.

Le modifiche correlate nella v0.8.0 puntano nella stessa direzione. La continuazione prefill solo-pensiero (#5931) gestisce il caso specifico in cui un modello produce un blocco di ragionamento senza blocco di contenuto e si blocca. Le direttive di disciplina di esecuzione (#5414) aggiungono al system prompt una regola generale: "non ripianificare a meno che qualcosa sia effettivamente cambiato". La coercizione degli argomenti delle chiamate tool (#5265) converte silenziosamente stringhe in numeri e booleani quando lo schema JSON li richiede — esattamente l'errore di tipizzazione degli argomenti che il benchmark aveva catturato. In un changelog, questi tre PR sembrano scollegati. Letti insieme al PR #6120, sono la superficie visibile di una campagna deliberata: rendere l'agente più affidabile su una famiglia di modelli specifica misurando, correggendo e rimisurando.

L'implicazione silenziosa

Quello che fa sembrare questo un momento di svolta, e non solo una buona release, è ciò che lascia intravedere sull'ingegneria degli agenti quando si smette di scrivere i prompt a mano. Un repo come Hermes deve puntare a dodici provider diversi e trenta modelli diversi. Tracciare il comportamento di ciascuno manualmente è già impossibile. Se invece tratti "come dovremmo promptare il modello X" come un problema di tuning che un harness di benchmark risolve, hai un processo che scala con le dimensioni dello zoo di modelli anziché annegare in esso.

Niente di tutto questo era il titolone della v0.8.0. Il titolone era "the intelligence release" e la demo era il cambio di modello in tempo reale. Ma la cosa silenziosa sotto il pavimento è che Hermes ora ha un modo per mantenere l'agente intelligente su ogni modello che supporta, senza che un umano passi un fine settimana per modello a ri-tunare il system prompt. È il tipo di capacità che non comparirà come feature nemmeno nella prossima release — si manifesterà semplicemente come "l'affidabilità di GPT su Hermes continua a migliorare" nel corso delle prossime sei release consecutive.

E se leggete le release notes per divertimento, come faccio io, questa è la forma della cosa da tenere d'occhio.

Per approfondire

Resta aggiornato

Aggiornamenti dalla community sulle release di Hermes Agent, nuove skill e integrazioni. Niente spam, cancellati quando vuoi.