I framework agentic AI (intelligenza artificiale con agenti) rappresentano un avanzamento significativo nell'esecuzione automatizzata e decisionale. Questo articolo analizza in profondità i cinque principali framework open source per agenzia AI. Attraverso un test di 2000 esecuzioni (cinque compiti, 100 esecuzioni ognuna per framework), abbiamo misurato latenza, consumo di token e differenze architetturali.
I risultati mostrano un chiaro vantaggio competitivo nei framework in termini di efficienza e capacità di gestire compiti complessi. LangGraph risulta essere il più veloce con le minori latenze tra tutte le compiti, mentre LangChain mostra la maggiore latenza e il maggior consumo di token.
LangChain, invece, si presenta come il framework più efficiente in termini di token, ma mostra una leggera peggioramento in termini di latenza. AutoGen mantiene una buona media in termini di latenza, seguito da LangGraph e LangChain. CrewAI, invece, risulta essere il più lento a causa della sua architettura più complessa.
Per comprendere meglio le prestazioni di ogni framework, l’analisi include diversi esercizi di complessità crescente; inizialmente abbiamo testato il tempo di esecuzione per compiti semplici: chiamata strumentale e restituzione di dati, senza necessitare di inferenze complesse. LangChain e LangGraph si comportano come codice non basato sugli agenti; entrambi impiegano meno di 5 secondi e utilizzano meno di 900 token.
AutoGen mostra un lievo aumento sia in termini di token che in latenza rispetto ai primi due, riflesso del costo della sua architettura basata su conversazione tra due agenti anche per compiti semplici. CrewAI, invece, mostra un consumo considerevolmente maggiore: quasi triplica la latenza e il consumo di token in confronto a LangChain, a causa di un processo di verifica a multi-stati tra planner e analista. Questo processo, mentre rigoroso, consuma risorse in eccesso.
In una seconda compito abbiamo testato la capacità dei framework di gestire due gruppi di filtri distinti in una struttura (persistenza di stato) e la loro integrazione. La log analysis ha mostrato che CrewAI offre la maggiore trasparenza strutturale tra i framework, ma al costo di un consumo eccessivo risorse.
Contrariamente a quanto normalmente accade, CrewAI non restituisce immediatamente i dati richiesti. Esso passa attraverso un processo di autoverifica esteso. Questo processo esplorativo ha causato, in alcuni casi, un limite raggiunto di iterazioni (maxiter=10), in cui il sistema è andato in standby senza produrre una risposta JSON.
La causa di tale comportamento risiede nella struttura complessa usata da CrewAI, che include istruzioni multilivello all'interno delle richieste, assegna ruoli, obiettivi e background ai vari agenti, e richiede una schermata ReAct (Riflessione → Azione → Osservazione) in ogni ciclo di iterazione. Anche per semplici compiti, il modello non può saltare il processo, producendo dettagli interni molto lungi – un problema che si amplifica con un numero maggiore di agenti.
In termini di token consumati, CrewAI quasi raddoppia il consumo rispetto agli altri framework e richiede più di tre volte il tempo di LangChain completando l’assegnazione. Se i bisogni richiedono complessità nella gestione di stati multipli o decisioni multifattoriali, CrewAI si rivela più adatto. Per semplici estrazioni di dati, invece, non è il migliore.
LangGraph si rivela come il framework più veloce e economico in termini di utilizzo. Nei nostri log abbiamo visto che completa la compito in 5-6 passi diretti, caricando, filtrando e calcolando in modo diretto. Grazie al suo semplice management dello stato, non presenta overhead significativi, mantenendo le minori latenze tra tutti i framework.
La sua prestazione è estremamente bilanciata. In compiti 2 mostra un uso quasi identico a LangGraph in termini di token e latenza. Questo dimostra che l’overhead della ciclo conversazionale non si incrementa significativamente, mantenendo la catena di lavoro lineare e stabile.
Robustezza alla Gestione di Errori
Può occasionalmente aggiungere un passo di verifica per confermare i parametri nel corso della richiesta di uno strumento, rendendolo un po’ più lento di LangChain. Quando si verifica un errore durante l’esecuzione di uno strumento, LangChain aggiorna immediatamente la sua logica, correggendo il JSON restituito con un minimo overhead.
Perciò, trattando l’output come un processo dialogico, LangChain si rivela uno dei framework più robusti in termini di tolleranza agli errori logici. LangGraph si presenta estremamente stabile e precisa. Nei nostri log abbiamo notato che lo stato è sempre rimasto pulito attraverso tutto il processo. Il rischio di contaminazione da dati non attendibili o segmenti interagenti è minimo.
Precisione nel Riconoscimento di Valori Numerici
Nei nostri test abbiamo valutato la capacità dei framework di trasformare descrizioni di condizioni numeriche ("inferiore a 1 anno di servizio", "quote mensili superiore a 70$") in parametri precisi (tenuremax=12, chargesmin=70.0). Il modello sa già come effettuare questa conversione, ma abbiamo verificato se i framework riescono a preservare tali parametri durante il proprio ciclo di gestione, ricontesto e controllo del stato.
LangChain e LangGraph li passano direttamente e senza modifiche alle strumenti – esattamente come li ricevono, generandoli dal modello linguistico senza aggiustamenti. Questo livello di efficienza è riconoscibile nei dati: entrambi risolvono la compito in meno di 9 secondi, utilizzando meno di 1.800 token, il minimo tra i framework.
Tra le prove abbiamo notato una particolarità con Autogen, che fornisce risultati numerici perfetti. In alcuni casi, però, esso ha incluso un passo di validazione prima dell’utilizzo del parametro generato dal modello. Anche se ciò ha richiesto un tempo supplementare (8 secondi e 2480 token), LangChain è riuscito a raggiungere un livello di latenza equivalente, dimostrando che il processo di verifica non ha avuto un impatto troppo pesante.
CrewAI ha completato la compito in 30 secondi, utilizzando 4.360 token – il massimo del test. Nel log abbiamo identificato due tipi diversi di errori. In diversi casi ha restituito un valore che in realtà avrebbe dovuto essere 68.81%, ma come 0.6878 – un rapporto decimale impreciso.
La restituzione e l’analisi delle uscite da parte di CrewAI ha mostrato la capacità di separare i risultati del modello da contesti originari. I log rivelano che inizialmente il modello ha restituito i parametri corretti (tenuremax=12, chargesmin=70). Ma una volta entrato in una “loop” di parsing, CrewAI ha costretto il modello a verificare nuovamente i parametri, aggiungendo un overhead inutilmente esteso. Nei test successivi, il modello ha modificato i valori in tenuremax=14.