I 5 migliori framework open-source di IA agentica

Un benchmark completo dei framework agentici open-source

Nel panorama in rapida evoluzione dell'intelligenza artificiale agentica, la scelta del framework giusto può fare la differenza tra un sistema efficiente e uno dispendioso. Un'analisi approfondita ha sottoposto a benchmark quattro dei più popolari framework agentici open-source, conducendo 2.000 esecuzioni distribuite su 5 task differenti con 100 esecuzioni ciascuno per framework. L'obiettivo era misurare e confrontare la latenza end-to-end, il consumo di token e comprendere come le differenze architetturali influenzano il comportamento degli agenti e le conseguenti implicazioni in termini di prestazioni.

Questo studio rappresenta uno sforzo sistematico per andare oltre le valutazioni teoriche e fornire dati concreti basati su scenari reali. I framework esaminati — LangGraph, LangChain, AutoGen e CrewAI — rappresentano approcci architetturali differenti all'implementazione di sistemi agentici, ciascuno con i propri punti di forza e debolezze quando misurati in termini di efficienza computazionale e affidabilità.

Risultati complessivi del benchmark

I risultati globali del benchmark rivelano un quadro articolato e sfumato. LangGraph si distingue come il framework più veloce, con i valori di latenza più bassi registrati in tutti i task testati. LangChain, d'altra parte, mostra la latenza e il consumo di token più elevati quando considerati isolatamente, sebbene su 5 task e 2.000 esecuzioni totali emerga come il framework più efficiente in termini di consumo globale di token.

AutoGen primeggia in latenza assoluta per alcuni scenari specifici, mentre LangGraph e LangChain seguono da vicino in molti test. CrewAI, invece, presenta il profilo complessivamente più pesante, con overhead strutturale che non varia significativamente in base alla complessità del task. Questi risultati suggeriscono che non esiste una soluzione universale ottimale per tutti gli scenari; piuttosto, la scelta del framework dovrebbe essere guidata dai requisiti specifici dell'applicazione in questione.

Task 1: misurazione dell'overhead di framework semplici

Il primo task era progettato per misurare l'overhead di ciascun framework nella situazione più semplice possibile: una singola chiamata a uno strumento e il ritorno del risultato, senza alcun ragionamento complesso. Questo setup consente di isolare l'overhead intrinseco del framework dal costo computazionale della logica dell'agente.

Prestazioni di LangChain e LangGraph

Per i task semplici, LangChain e LangGraph si dimostrano quasi veloci quanto il codice non agentico. Entrambi completano la loro esecuzione in meno di 5 secondi con meno di 900 prompt token. Questo risultato è particolarmente significativo perché dimostra che l'overhead architetturale di questi framework è minimo quando la complessità del task rimane bassa.

L'architettura a macchina a stati di LangGraph non introduce latenza evidente rispetto a LangChain a questo livello di semplicità. Tuttavia, l'overhead della gestione dello stato inizia a manifestarsi in modo più evidente man mano che la complessità dei task cresce, suggerendo che l'approccio basato su grafi di LangGraph offre vantaggi maggiori in scenari più complessi.

Prestazioni di AutoGen

AutoGen si colloca leggermente al di sopra di LangChain e LangGraph sia in latenza che in consumo di token, riflettendo il costo di base del suo ciclo di conversazione multi-agente. Anche quando esegue un task a singolo passaggio, AutoGen mantiene il suo approccio conversazionale dove due agenti si scambiano messaggi. Questo design di base introduce un overhead aggiuntivo ma stabile.

Prestazioni di CrewAI

CrewAI si distingue negativamente in questo primo task. Anche quando gli viene chiesto di effettuare una singola chiamata a uno strumento, mostra quello che potrebbe definirsi "overhead manageriale", consumando quasi 3 volte i token di LangChain e impiegando quasi 3 volte più tempo. Il processo di verifica multi-step tra i personaggi Planner e Analyst offre un approccio accurato ma estremamente dispendioso in termini di risorse, che privilegia la completezza alla velocità piuttosto che l'efficienza.

Il costo di questo approccio è strutturale: si presenta indipendentemente dalla complessità del task. Questo suggerisce che CrewAI è concepito per scenari dove la trasparenza dei processi e la verifica multi-step sono prioritari rispetto alla velocità di esecuzione.

Task 2: persistenza dello stato e combinazione di dati

Nel Task 2, l'obiettivo era verificare la capacità dei framework di mantenere in memoria due diversi gruppi di filtri e combinarli correttamente. Questo rappresenta uno scenario intermedio in termini di complessità, dove la gestione dello stato diventa significativa.

Trasparenza e consumo di risorse in CrewAI

L'analisi dei log ha rivelato che CrewAI offre il più alto livello di trasparenza dell'infrastruttura tra i framework testati, ma a un costo estremamente elevato in termini di consumo di risorse. Invece di restituire immediatamente i dati recuperati, CrewAI convalida ripetutamente i propri processi tramite un meccanismo di auto-revisione. Questo comportamento esplorativo ha portato CrewAI a raggiungere il limite configurato max_iter=10, lasciando alcune esecuzioni bloccate in un loop di pensiero continuo senza produrre un output JSON valido.

La causa principale di questo comportamento è che CrewAI inietta istruzioni multi-livello nel prompt di sistema, assegnando a ogni agente un ruolo specifico, un obiettivo dichiarato e una backstory narrativa. Contemporaneamente, il framework impone un loop in stile ReAct — Thought → Action → Observation — a ogni passaggio. Anche per i task semplici, il modello linguistico non può saltare questa procedura e produce diligentemente monologhi interni verbosi che si aggravano ulteriormente negli scenari multi-agente.

Nel Task 2, CrewAI ha consumato quasi il doppio dei token degli altri framework e ha impiegato più del triplo del tempo di LangChain. Questo rende CrewAI più adatto a transizioni di stato complesse e processi decisionali multi-fattore piuttosto che a task di recupero dati diretti e lineari.

Efficienza di LangChain nel Task 2

LangChain si è rivelato il framework più veloce ed economico nel Task 2. Nei log, è stato osservato che LangChain completa il task in soli 5-6 passaggi senza deviazioni: Load → Filter → Calculate → Filter → Calculate → Output. Poiché la sua gestione dello stato è molto semplice e diretta, l'overhead è quasi nullo e la latenza è la più bassa tra tutti i framework testati.

Prestazioni equilibrate di AutoGen

AutoGen ha offerto una prestazione molto equilibrata nel Task 2, eguagliando LangGraph quasi esattamente sia in consumo di token che in latenza. Questo dimostra che l'overhead del ciclo di conversazione non si accumula in modo significativo quando la catena del task rimane lineare e ben strutturata.

Tuttavia, si è osservato che AutoGen occasionalmente aggiunge un passaggio di verifica extra per confermare i parametri durante il processo di chiamata degli strumenti, rendendolo leggermente più lento di LangChain. Quando incontra un errore in una chiamata a uno strumento o i dati non tornano come previsto, aggiorna immediatamente il ragionamento nel passaggio successivo e arriva al JSON corretto. Poiché gestisce gli output degli strumenti come un flusso conversazionale naturale, è uno dei framework più resilienti contro gli errori logici.

Stabilità di LangGraph

In questo task, LangGraph emerge come il framework più stabile grazie alla sua architettura basata su grafi. Nei suoi log, lo stato viene trasportato in modo molto pulito durante tutta l'esecuzione. Il rischio di contaminazione dei dati o di interferenza tra segmenti è al livello più basso tra i framework testati. Su tutte le 100 esecuzioni, ha prodotto risultati con quasi lo stesso numero di passaggi e entro lo stesso intervallo di latenza, dimostrando una coerenza eccezionale.

Task 3: traduzione accurata di condizioni numeriche

Nel Task 3, l'obiettivo era verificare con quanta precisione i framework traducono condizioni numeriche espresse in linguaggio naturale, come "anzianità inferiore a 1 anno" e "oltre $70 di addebiti mensili", in parametri precisi per gli strumenti come tenure_max=12 e charges_min=70.0. Questo test è cruciale perché esamina non solo la capacità del modello linguistico sottostante, ma anche quanto bene il framework protegge questi parametri attraverso i propri meccanismi di retry, il contesto di re-prompt e i cicli di gestione dello stato.

Prestazioni di LangChain e LangGraph nel Task 3

Entrambi i framework hanno passato i parametri (tenure_max=12, charges_min=70) direttamente allo strumento esattamente come li ha prodotti il modello linguistico, senza alcuna modifica né loop di re-prompt non necessari. Questa efficienza si riflette nei numeri: entrambi i framework hanno completato il Task 3 in meno di 9 secondi con meno di 1.800 prompt token, il valore più basso registrato in questo task.

Quando l'obiettivo era misurare se le soglie numeriche vengono preservate senza che il framework interferisca con la decisione del modello, questi due framework hanno pienamente soddisfatto le aspettative: qualunque parametro venisse generato dal modello linguistico, era esattamente quello che veniva eseguito, senza alterazioni non necessarie.

Successo di AutoGen nella correttezza numerica

AutoGen ha raggiunto il pieno successo nella correttezza numerica nel Task 3. In alcune esecuzioni, il framework ha aggiunto un passaggio di verifica prima di passare il parametro generato dal modello linguistico allo strumento, il che significa che il framework ha impiegato un passaggio extra pur preservando l'integrità del parametro. Con 2.480 token e 8 secondi, ha eguagliato la latenza di LangChain nonostante il passaggio di verifica aggiuntivo, confermando che l'overhead di verifica è reale ma contenuto.

AutoGen ha soddisfatto pienamente le aspettative in termini di integrità dei parametri, con il passaggio di conferma che introduce un costo marginale in token piuttosto che una penalità di latenza significativa.

Problemi critici di CrewAI nel Task 3

CrewAI ha presentato il comportamento più notevole e problematico nel Task 3, completando il task in 30 secondi con 4.360 token, il valore più alto registrato in questo task. L'analisi dettagliata dei log ha rivelato due schemi di errore distinti che minano la fiducia nel framework per compiti che richiedono precisione numerica.

Nel primo pattern di errore, un valore che avrebbe dovuto essere 68,81% è stato restituito come 0.6878 (rapporto decimale). Questo indica chiaramente che la serializzazione dell'output del framework può privare l'output del modello linguistico del suo contesto originale, causando una trasformazione indesiderata e potenzialmente catastrofica dei dati.

Nel secondo pattern di errore, ancora più preoccupante, i log mostrano che il modello linguistico ha inizialmente prodotto i parametri corretti: tenure_max=12 e charges_min=70. Tuttavia, una volta che CrewAI è entrato in un loop "Failed to parse", il framework ha spinto il modello linguistico a riconsiderare i parametri nel contesto di re-prompt. In questo nuovo contesto, il modello linguistico ha spostato la soglia a tenure_max=14 e ha completamente disabilitato il filtro charges_min, producendo un tasso di abbandono del 46,84%, che rappresenta esattamente il tasso di abbandono di tutti i clienti con anzianità inferiore a 14 anni — uno scenario completamente diverso da quello inteso.

Questo era esattamente lo scenario che i test volevano osservare: il meccanismo di retry del framework può corrompere un parametro che il modello linguistico aveva azzeccato inizialmente, trasformandolo in un valore completamente errato a causa del re-prompting nel nuovo contesto. Questo rappresenta un rischio significativo per applicazioni critiche dove la precisione numerica è essenziale.

Task 4: gestione di errori e scenari dirompenti

Nel Task 4, l'obiettivo era osservare come ciascun framework gestisce scenari dirompenti e misurare l'impatto su latenza e consumo di token. Lo strumento era configurato per lanciare 3 diversi tipi di errori in successione: Network, Timeout, e Rate Limit, mettendo l'agente alle strette. I primi due errori indicavano all'agente di riprovare, mentre l'errore Rate Limit in arrivo diceva all'agente di attendere 10 secondi. Una volta che l'agente attendeva e riprovava, lo strumento iniziava a funzionare normalmente.

Innovazione e resilienza di LangChain e AutoGen

LangChain e AutoGen hanno trovato soluzioni alternative autonomamente di fronte ai guasti degli strumenti in questo task, dimostrando un livello notevole di resilienza e flessibilità. Quando lo strumento ha restituito un avviso di rate limit, invece di fermarsi e attendere come istruito, questi agenti hanno deciso di abbandonare completamente lo strumento guasto e trovare un percorso alternativo.

Il loro ragionamento è stato: "Poiché questo strumento non funziona, filtrerò ciascun metodo