The Pulse
Microsoft e Hugging Face mettono alla prova gli agenti su 507 flussi di lavoro
Microsoft e Hugging Face hanno pubblicato ThinkingBox, un benchmark che mette alla prova gli agenti di IA su 507 flussi di lavoro aziendali e verifica i dati che modificano. Le valutazioni su 20 esecuzioni hanno rilevato che molti agenti ri
AI.info Team ·
Il 67% dei tentativi falliti sembrava comunque concluso
In un test degli agenti di IA su flussi di lavoro aziendali, il 67,24% dei tentativi falliti si è concluso senza errori degli strumenti, anche se i sistemi non avevano completato il lavoro richiesto. Microsoft e Hugging Face hanno pubblicato i risultati il 3 ottobre 2026 insieme a ThinkingBox, un ambiente isolato e un benchmark progettati per verificare che cosa gli agenti modificano effettivamente nei dati del backend.
Il dato proviene dall’analisi di 121.680 prove condotte su 12 modelli. Tra i tentativi che non hanno superato i controlli eseguibili del benchmark, molti avevano effettuato chiamate a strumenti che modificavano lo stato dei dati, per poi arrestarsi normalmente. I controlli hanno comunque rilevato valori errati nei campi nel 77,61% di questi fallimenti, effetti aggiuntivi non voluti nel 43,30% ed effetti richiesti ma mancanti nel 25,36%; le categorie si sovrappongono.
Il risultato mette in discussione una scorciatoia comune nella valutazione dei sistemi che usano strumenti: considerare una risposta finale scorrevole o una chiamata valida a uno strumento come prova che un compito sia stato completato. «Thinkingbox-bench rivela un ampio divario tra il trovare occasionalmente un percorso che porta al successo e il completare in modo affidabile compiti aziendali che comportano modifiche allo stato dei dati», scrivono Zhuochun Li e gli altri autori nell’articolo su ThinkingBox.
ThinkingBox controlla i dati, non soltanto la trascrizione
ThinkingBox-Bench comprende 507 flussi di lavoro soggetti a policy nei settori della vendita al dettaglio, dell’ospitalità, delle assicurazioni auto, dell’assistenza di una neobanca e della consulenza informatica e delle risorse umane. Ogni compito fornisce a un agente un obiettivo, uno stato iniziale del backend, gli strumenti disponibili e le policy applicabili. Il sistema confronta poi i dati risultanti e gli effetti collaterali con requisiti verificabili mediante controlli eseguibili.
Ogni compito viene eseguito 20 volte a partire da un backend inizializzato da zero, con i tentativi isolati l’uno dall’altro. Il benchmark riporta diverse misure distinte: pass@1 per il tasso di successo al primo tentativo, pass@20 per i compiti risolti almeno una volta in 20 tentativi e observed 20/20 per i compiti superati in tutti i tentativi registrati. Quest’ultima misura valuta direttamente la ripetibilità: riuscirci una volta non dimostra che un agente sappia gestire in modo affidabile lo stesso flusso di lavoro.
I compiti pubblici sono ricostruzioni sintetiche di schemi aziendali, non dati di clienti reali. Nell’esempio riportato nell’annuncio, un agente gestisce la consegna in ritardo di un elettrodomestico, apre un ticket di assistenza e poi lo contrassegna erroneamente come risolto mentre l’eccezione segnalata dal trasportatore resta aperta. Le chiamate agli strumenti sembrano ordinate; è lo stato finale del ticket a rivelare l’errore.
I modelli guadagnano in ampiezza a scapito della costanza
I risultati distinguono la capacità di riuscire occasionalmente dall’esecuzione affidabile. Kimi-K3 ha risolto almeno un tentativo in 476 dei 507 compiti, pari al 93,89%, ma ha superato tutti i 20 tentativi in soli 68 compiti. Claude Opus 5 ha risolto almeno un tentativo in un numero inferiore di compiti, ma ha completato tutti i tentativi nel 47,53% dei compiti del benchmark.
Claude Opus 5.5 ha ottenuto un punteggio più alto di Opus 5 nel singolo tentativo, 67,16% contro 66,50%, ma entrambi hanno superato esattamente 241 compiti in tutti i 20 tentativi. I dati mostrano perché il benchmark distingue tra svolgere correttamente un compito una volta e farlo con costanza. I risultati variavano anche in base al flusso di lavoro: per alcuni modelli, l’annuncio segnala un ampio divario tra le prestazioni nella vendita al dettaglio e quelle nelle assicurazioni auto.
Un ambiente di test, non una prova di affidabilità nell’uso reale
ThinkingBox isola ogni esecuzione in una sessione di strumenti compatibile con MCP e confronta lo stato finale del backend con controlli specifici per il compito. Dei 507 compiti, 477 si basano soltanto su controlli dello stato; i restanti 30 usano anche criteri di valutazione delle risposte per requisiti che non corrispondono direttamente a un valore nel database. Il modello riceve il compito, il dialogo e gli schemi degli strumenti, mentre il benchmark mantiene fuori dalla vista dell’agente lo stato atteso e i dettagli della valutazione.
Il framework e il benchmark sono disponibili tramite Hugging Face e OpenEnv; il benchmark eseguibile è stato pubblicato nella versione 1.0. I risultati offrono agli sviluppatori un modo per esaminare i fallimenti e ripetere lo stesso flusso di lavoro in condizioni controllate, anziché affidarsi soltanto al resoconto dell’agente su ciò che ha fatto.
La pubblicazione, però, non stabilisce quanto i flussi di lavoro sintetici siano in grado di prevedere i tassi di fallimento nei sistemi aziendali in uso. Resta da capire se i divari osservati tra esecuzioni ripetute si riscontrino anche nei dati reali.