I 13 framework open‑source per intelligenza artificiale agentica: risultati del benchmark 2026

Panoramica del benchmark e metodologie

Nel febbraio 2026 abbiamo condotto il primo benchmark su quattro framework – LangChain, LangGraph, AutoGen e CrewAI – utilizzando il modello GPT‑5.2. All’epoca, CrewAI impiegava quasi il doppio del tempo rispetto agli altri (media 52,7 s contro 27,5‑29,6 s) e consumava il 64 % in più di token rispetto al framework più leggero.

Con le versioni attuali, tutti e quattro hanno ridotto drasticamente i tempi, attestandosi tra 8,20 s e 8,39 s, e la differenza di token è scesa al 26 %. Per la nostra analisi dettagliata della procedura di testing, consultare la sezione “Benchmark‑Methodik”.

Il nuovo test ha ampliato il campione a tredici framework, includendo anche Agno, CAMEL, Google ADK e altri nove non nominati esplicitamente nel testo originale. Ogni framework è stato valutato su cinque task distinti, ciascuno eseguito 100 volte, per un totale di 6 500 esecuzioni.

Un’eccezione importante è smolagents, che è stato deliberatamente escluso dalla grafica finale. Con una media di 20,55 s per esecuzione e un costo di 4,52 $ per 1 000 run, smolagents avrebbe sovrastato tutti gli altri risultati, rendendo il confronto poco leggibile. Le ragioni di questa scelta sono approfondite più avanti.

Gestione simultanea dei tool e comportamento sequenziale

Il modello può richiedere l’uso di più tool contemporaneamente. In questo scenario, Agno, CAMEL e Google ADK eseguono i tool in modo sequenziale: il successivo avvia solo quando il precedente termina. Gli altri dieci framework, invece, avviano tutti i tool simultaneamente per impostazione predefinita.

Quando i tool dipendono l’uno dall’altro, l’avvio simultaneo può generare conflitti, ad esempio un tool che scrive in un database mentre un altro tenta di leggere lo stesso record. Questo comportamento è stato osservato nei nostri test, soprattutto nei task più complessi.

Il comportamento sequenziale è stato verificato per le chiamate sincrone (Agno.run(), CAMEL.sastep()) e per gli strumenti asincroni di Google ADK, che comunque eseguono le chiamate in parallelo.

La scelta di mantenere le impostazioni predefinite è consigliata solo quando i tool sono lenti (ad esempio chiamate API con latenza di diversi secondi) e indipendenti. Nei nostri test, i tool completavano l’esecuzione in millisecondi, quindi il parallelismo ha introdotto errori senza alcun guadagno di velocità.

Strategie alternative per tool condivisi

• Utilizzare la sequenzialità quando i tool manipolano dati comuni.
• Conservare la parallelizzazione se i tool sono lenti ma indipendenti.

Formato dei prompt e impatto sulle performance

Tutti i framework hanno ricevuto le stesse funzioni Python con identiche descrizioni. Tuttavia, ciascuno le traduce in “tool‑definition” proprie, influenzando la lunghezza della prima richiesta al modello. La media dei token è stata di 1 917 per Agno e 2 754 per AutoGen, con la differenza principale dovuta alla definizione dei tool.

Due framework aggiungono testo alle istruzioni: CrewAI inserisce una sezione con ruolo, background e obiettivo, mentre Google ADK aggiunge una riga finale “Sie sind ein Agent”. Queste aggiunte sono marginali rispetto al peso delle definizioni dei tool.

Le definizioni dei tool vengono inviate ad ogni richiesta, generando costi ricorrenti. Nonostante Agno e AutoGen effettuino quasi lo stesso numero di chiamate LLM per run (4,40 e 4,45 rispettivamente), AutoGen invia in media il 37 % di token in più (14 932 vs 10 899).

Una possibile riduzione del carico token‑wise consiste nell’utilizzare descrizioni più concise o una descrizione separata del tool, opzione supportata da alcuni framework (ad esempio CrewAI, dove è possibile modificare i template systemtemplate e prompttemplate).

Costi e tempi di esecuzione

Il codice interno di ciascun framework aggiunge un overhead medio di 0,04‑0,14 s per run, meno del 2 % del tempo totale. Il tempo di avvio varia: circa 1 s per Google ADK, 0,6 s per CAMEL e meno di 0,35 s per gli altri.

Questi tempi di avvio non sono inclusi nei risultati del benchmark, ma diventano rilevanti in ambienti “serverless” dove ogni richiesta comporta un nuovo avvio. In scenari in cui il framework rimane caricato in memoria, l’avvio è un costo una tantum.

Per dare un punto di riferimento, abbiamo eseguito le stesse cinque task con OpenCode, un agente di coding open‑source, mantenendo modello, istruzioni e tool identici ma disattivando i suoi tool di coding. OpenCode ha completato tutti i 500 run correttamente, con un tempo medio di 6,42 s (tra i più rapidi) e un costo di 1,78 $ per 1 000 run, collocandosi nella metà superiore dei costi (da 1,41 $ a 1,88 $).

Gestione degli errori e resilienza dei framework

Il task 4 ha simulato il fallimento di un tool (calcolo del churn per metodo di pagamento) nei primi tre tentativi (errori di connessione, timeout, rate‑limit) e il successo al quarto. Ogni messaggio di errore conteneva la parola “retry”. L’agente poteva scegliere di ritentare il tool o di calcolare manualmente ogni metodo.

Il modello influisce sulla decisione: in un test di controllo con GPT‑5.2 e un solo run per framework, sei dei tredici framework hanno abbandonato il tool difettoso, optando per la via alternativa.

Mostrando al modello gli errori così come si verificano, i framework che non gestiscono i retry internamente perdono la possibilità di intervenire, rendendo il comportamento dipendente dal framework stesso.

Architettura dei framework e orchestrazione multi‑agente

I tredici framework supportano l’esecuzione simultanea di più agenti, sebbene il benchmark abbia valutato un singolo agente per semplicità. Abbiamo confrontato il codice sorgente delle versioni testate, raggruppandole in tre categorie principali:

• MCP (Model Context Protocol): fornisce un metodo standard per connettere agenti a tool e fonti dati esterne. Tutti i framework possono utilizzare tool da server MCP.
• Gestione delle autorizzazioni: tre modalità sono supportate – richiedere l’autorizzazione prima dell’esecuzione di un tool, sospendere il flusso e attendere la risposta umana, o procedere senza approvazione.
• Memoria persistente: alcuni framework non includono una memoria a lungo termine (l’applicazione deve salvare e reinserire lo storico), mentre altri offrono un “graph‑based” agent con stato esplicito gestito dallo sviluppatore. Sono disponibili versioni Python e JavaScript, con tracciamento dei run tramite la piattaforma LangSmith di LangChain.

Un caso emblematico è il più lungo run di LangGraph nel task 3, che ha effettuato 25 chiamate a tool prima di arrivare alla risposta corretta, di cui 16 erano ripetizioni inutili. Questo evidenzia l’importanza di una gestione efficiente del loop di retry.

Conclusioni e raccomandazioni pratiche

Il benchmark rivela che la differenza principale tra i framework non risiede tanto nella velocità di esecuzione delle funzioni di base, quanto nella modalità di gestione dei prompt, nella definizione dei tool e nella capacità di gestire errori temporanei.

Per chi deve scegliere un framework per agenti IA, consigliamo di considerare:

• Dimensione dei prompt: preferire framework che minimizzano le definizioni dei tool o consentono descrizioni concise.
• Gestione dei tool simultanei: se i tool sono lenti e indipendenti, mantenere la parallelizzazione; altrimenti, optare per l’esecuzione sequenziale.
• Supporto per il retry: framework che propagano gli errori al modello permettono una maggiore flessibilità, ma richiedono una logica di fallback più robusta.
• Overhead di avvio: per ambienti serverless, scegliere soluzioni con avvio rapido o mantenere il framework in memoria.
• Memoria persistente: valutare se è necessario mantenere lo stato tra più task o conversazioni.

Infine, smolagents dimostra che un’eccessiva verbosità (6 780 caratteri di template e reinvio del contesto ad ogni step) può portare a costi proibitivi e a tempi di risposta poco competitivi. Riducendo il template o passando a una versione più snella di prompt_template, è possibile mitigare questi effetti.

Con questi dati a disposizione, sviluppatori e ricercatori possono orientare le proprie scelte verso i framework più adatti alle specifiche esigenze di scalabilità, efficienza economica e robustezza operativa.