Top 5 framework agentici IA open-source
Abbiamo testato 4 popolari framework agentici open-source su 2.000 esecuzioni (5 task, 100 esecuzioni ciascuno per framework), misurando latenza end-to-end, consumo di token e differenze architetturali.
Benchmark dei framework agentici IA
Abbiamo esaminato come i framework stessi influenzino il comportamento dell'agente e il conseguente impatto su latenza e consumo di token.
LangGraph è il framework più veloce con i valori di latenza più bassi in tutti i task, mentre LangChain ha la latenza e il consumo di token più elevati.
Su 5 task e 2.000 esecuzioni, LangChain emerge come il framework più efficiente in termini di token, mentre AutoGen primeggia per latenza; LangGraph e LangChain seguono da vicino. CrewAI presenta il profilo complessivo più pesante.
Task 1: Aggregazione di base
Per prima cosa, abbiamo misurato l'overhead di ciascun framework nella chiamata a un singolo strumento e nella restituzione del risultato, senza eseguire alcun ragionamento complesso.
LangChain & LangGraph: Per task semplici, le loro prestazioni sono quasi paragonabili a quelle di codice non agentico, terminando entrambi in meno di 5 secondi con meno di 900 token di prompt. L'architettura a macchina a stati di LangGraph non introduce latenza percepibile rispetto a LangChain a questo livello di semplicità; l'overhead della gestione dello stato si manifesta all'aumentare della complessità del task.
AutoGen: Si posiziona leggermente al di sopra di LangChain e LangGraph sia in termini di latenza che di consumo di token, riflettendo il costo di base del suo ciclo di conversazione multi-agente, due agenti che si scambiano messaggi anche per un task a singolo passo.
CrewAI: Anche quando gli viene chiesto di effettuare una singola chiamata a uno strumento, mostra quello che potremmo definire un “overhead manageriale”, consumando quasi 3 volte i token di LangChain e impiegando quasi 3 volte più tempo. Il processo di verifica a più fasi tra i suoi personaggi Planner e Analyst offre un approccio approfondito ma dispendioso in termini di risorse, che privilegia la completezza rispetto alla velocità. Questo costo è strutturale: si manifesta indipendentemente dalla complessità del task.
Task 2: Analisi comparativa dei ricavi (gestione dello stato)
Nel task 2, volevamo verificare la capacità dei framework di mantenere in memoria due diversi gruppi di filtri (persistenza dello stato) e di combinarli.
CrewAI
Nell'analisi dei nostri log, abbiamo riscontrato che CrewAI offre il più alto livello di trasparenza infrastrutturale tra i framework, ma al costo del consumo di risorse più elevato.
Invece di restituire immediatamente i dati recuperati, CrewAI convalida ripetutamente i propri processi attraverso un meccanismo di auto-revisione. Questo comportamento esplorativo ha causato il raggiungimento del limite configurato max_iter=10, lasciando alcune esecuzioni bloccate in un ciclo di pensiero continuo senza produrre un output JSON.
La causa principale di questo comportamento è che CrewAI inietta istruzioni multilivello nel prompt di sistema, assegnando a ciascun agente un ruolo, un obiettivo e una storia di background, e applicando a ogni passo un ciclo in stile ReAct Pensiero → Azione → Osservazione. Anche per task semplici, il LLM non può saltare questa cerimonia e produce diligentemente monologhi interni verbosi, che si aggravano ulteriormente negli scenari multi-agente.
CrewAI ha consumato quasi il doppio dei token degli altri framework e ha impiegato oltre tre volte il tempo di LangChain, rendendolo più adatto a transizioni di stato complesse e processi decisionali multifattoriali piuttosto che a task di recupero dati semplici.
LangChain
Il framework più veloce e conveniente. Nei nostri log, abbiamo osservato che LangChain completa il task in 5-6 passi senza deviazioni: Carica → Filtra → Calcola → Filtra → Calcola → Output. Poiché la sua gestione dello stato è molto semplice, l'overhead è quasi nullo e la latenza è la più bassa tra tutti i framework.
AutoGen
Ha offerto prestazioni molto equilibrate. Nel task 2, ha eguagliato LangGraph quasi esattamente sia nell'uso dei token che nella latenza, dimostrando che l'overhead del ciclo di conversazione non si accumula in modo significativo quando la catena del task rimane lineare.
Tuttavia, occasionalmente aggiunge un passaggio di verifica extra per confermare i parametri durante il processo di chiamata agli 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 suo ragionamento nel passo successivo e arriva al JSON corretto. Poiché gestisce gli output degli strumenti come un flusso conversazionale, è uno dei framework più resilienti contro gli errori logici.
LangGraph
In questo task, LangGraph è il framework più stabile grazie alla sua architettura basata su grafi. Nei suoi log, abbiamo osservato che lo stato viene trasportato in modo molto pulito durante l'esecuzione. Il rischio di contaminazione dei dati o di interferenza tra segmenti è al livello più basso in questo framework. In tutte le 100 esecuzioni, ha prodotto risultati con quasi lo stesso numero di passi e entro lo stesso intervallo di latenza.
Task 3: Analisi delle soglie (disciplina numerica)
In questo task, volevamo vedere con quanta precisione i framework traducono condizioni numeriche in linguaggio naturale, come “meno di 1 anno di anzianità” e “più di $70 di spese mensili”, in parametri di strumento precisi come tenure_max=12 e charges_min=70.0.
Il LLM sa come effettuare questa conversione; ciò che volevamo realmente testare era se il framework è in grado di proteggere questi parametri durante i propri meccanismi di retry, il contesto di re-prompt e i cicli di gestione dello stato.
LangChain & LangGraph
Entrambi i framework hanno passato i parametri (tenure_max=12, charges_min=70) direttamente allo strumento esattamente come li ha prodotti il LLM, senza alcuna modifica o ciclo di re-prompt. Questa efficienza si riflette nei numeri: entrambi i framework hanno completato il task 3 in meno di 9 secondi con meno di 1.800 token di prompt, il valore più basso in questo task.
Quando volevamo misurare se le soglie numeriche vengono preservate senza che il framework interferisca, questi due hanno soddisfatto le nostre aspettative: qualsiasi parametro venisse generato, quello è stato eseguito.
AutoGen
Autogen è pienamente efficace nella correttezza numerica. In alcune esecuzioni, si è osservato che il framework ha aggiunto un passo di verifica prima di passare il parametro generato dal LLM allo strumento, il che significa che il framework ha impiegato un passo aggiuntivo preservando il parametro. A 2.480 token e 8 secondi, ha eguagliato la latenza di LangChain nonostante il passo extra, confermando che l'overhead di verifica è reale ma contenuto. Ha soddisfatto le nostre aspettative in termini di integrità dei parametri, con il passo di conferma che introduce un costo marginale in token piuttosto che una penalità significativa sulla latenza.
CrewAI
Il comportamento più notevole è stato osservato in CrewAI, che ha completato il task 3 in 30 secondi con 4.360 token, il valore più alto in questo task. Dall'analisi dei log sono emersi due distinti modelli di fallimento.
In alcune esecuzioni, un valore che avrebbe dovuto essere 68.81% è stato restituito come 0.6878 (rapporto decimale). Ciò indica che la serializzazione dell'output del framework può privare l'output del LLM del suo contesto originale.
I log mostrano che il LLM inizialmente ha prodotto i parametri corretti, tenure_max=12 e charges_min=70. Tuttavia, una volta che CrewAI è entrato in un ciclo di “Impossibile analizzare”, il framework ha spinto il LLM a riconsiderare. Nel contesto di re-prompt, il LLM 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 in realtà è il tasso di abbandono di tutti i clienti con anzianità inferiore a 14. Questo era esattamente lo scenario che volevamo osservare: il meccanismo di retry del framework può corrompere un parametro che il LLM aveva individuato correttamente.
Task 4: Resilienza agli errori e capacità di pivot
In questo task, volevamo vedere come ciascun framework gestisce scenari di disturbo e osservare l'impatto su latenza e consumo di token. Lo strumento genera 3 diversi tipi di errore in successione (Rete, Timeout, Limite di velocità), mettendo l'agente alle strette. I primi due errori indicano all'agente di riprovare e, dopo aver riprovato entrambi, l'errore di Limite di velocità in arrivo dice all'agente di attendere 10 secondi. Una volta che l'agente ha atteso e riprovato, lo strumento inizia a funzionare normalmente.
LangGraph & Autogen
Questi due framework hanno trovato soluzioni alternative in modo autonomo di fronte ai guasti degli strumenti in questo task.
Quando lo strumento ha restituito un avviso di limite di velocità, invece di mettersi in pausa e attendere, questi agenti hanno deciso di abbandonare completamente lo strumento guasto e trovare un percorso alternativo. Il loro approccio è stato: “Dato che questo strumento non funziona, filtrerò ogni metodo di pagamento uno per uno, calcolerò il tasso di abbandono per ciascuno separatamente e poi combinerò i risultati da solo.”
Metodo: Invece di svolgere il task con una singola chiamata allo strumento, lo hanno suddiviso utilizzando due strumenti separati, uno per il filtraggio e uno per il calcolo, elaborando ciascun PaymentMethod (Electronic check, Mailed check, ecc.) individualmente.
Questi agenti operano con un ragionamento orientato agli obiettivi piuttosto che dipendente dal percorso. Se il percorso più breve non è disponibile, possono costruire un piano di esecuzione alternativo in pochi secondi.
LangGraph ha raggiunto 15.010 token di prompt nel task 4, il conteggio di token più alto per singolo task dell'intero benchmark, perché la sua macchina a stati accumulava la cronologia crescente di ogni chiamata manuale allo strumento riportandola nel contesto a ogni passo. AutoGen ha seguito con 10.750 token, leggermente più contenuto grazie alla sua gestione conversazionale dei risultati intermedi. Nonostante ciò, entrambi hanno terminato in circa 24-27 secondi, confermando che il costo aggiuntivo in token non si è tradotto in una latenza significativa perché il pivot stesso è stato rapido.
CrewAI
Nonostante avesse mostrato il consumo di token più elevato nei task precedenti, CrewAI ha esibito il più basso consumo di token) ma i valori di latenza più alti in questo task.
Perché il minor numero di token?
CrewAI non ha seguito un workaround manuale di 10-15 passi come i suoi concorrenti. Quando ha incontrato errori, invece di reinserire ripetutamente l'intera cronologia e i dati intermedi complessi nel LLM a ogni passo, ha costruito un ciclo di ragionamento più mirato e modulare. Evitando la verbosità non necessaria, è diventato il framework più conveniente in questo task.
Perché alta latenza?
La struttura manageriale di CrewAI mette in pausa e rivaluta il piano quando incontra un errore. Quando ha ricevuto l'avviso di attesa di 10 secondi, ha trascorso più tempo nella fase di “pianificazione strategica”. Inoltre, invece di passare a un altro strumento per il filtraggio, ha scelto persistentemente di attendere che lo strumento principale si riprendesse o di tentare con lo strumento stabile, prolungando così la durata complessiva.
LangChain
LangChain ha subito la sua trasformazione più significativa in questo task, dimostrando perché la resilienza dipenda da una configurazione adeguata.
Nella nostra esecuzione iniziale, LangChain è andato in crash a ogni singolo tentativo con un ConnectionError.
L'AgentExecutor predefinito di LangChain tratta le eccezioni Python grezze lanciate all'interno di uno strumento come errori fatali e termina il processo. A differenza dei suoi concorrenti, non applica una filosofia “gli errori sono osservazioni” per impostazione predefinita. Poiché l'agente non vede mai l'errore, non ha la possibilità di ragionarci sopra.
Abbiamo racchiuso la chiamata allo strumento all'interno di langchain_agent.py con un blocco try-except. Questo ha convertito l'errore in un messaggio leggibile che l'agente poteva elaborare.
Comportamento post-correzione: Dopo aver applicato la correzione, abbiamo osservato nei log di LangChain che ha mostrato esattamente lo stesso ragionamento di LangGraph. Ha ricevuto 3 errori dallo strumento, ha immediatamente cambiato strategia ed è passato all'utilizzo di due strumenti separati, uno per il filtraggio e uno per il calcolo, ha elaborato ciascun metodo di pagamento individualmente e ha combinato i risultati.
LangChain è in realtà altrettanto capace e adattivo di LangGraph, ma poiché la gestione degli errori del framework era disattivata per impostazione predefinita, non ha avuto l'opportunità di dimostrare questa capacità. Una volta configurato correttamente, ha raggiunto il risultato corretto utilizzando lo stesso approccio del percorso alternativo.
Perché si sono verificate queste differenze? (Analisi dell'architettura del framework)
Se il comportamento dell'agente dipendesse esclusivamente dal LLM (GPT-5.2), tutti i framework avrebbero dovuto comportarsi in modo simile. Tuttavia, le chiare differenze in questi rapporti sono radicate nei meccanismi dei loop interni dei framework:
1. LangGraph & AutoGen (90% Pivot):
LangGraph opera su un'architettura a macchina a stati, mentre AutoGen lavora su un modello basato sulla conversazione. In entrambi i sistemi, gli errori vengono elaborati come un ciclo di feedback. In LangGraph, lo stato che riceve l'errore passa al nodo successivo; in AutoGen, l'agente Proxy inoltra l'errore all'assistente come un messaggio di chat. Questo costante meccanismo di sollecitazione costringe l'agente a continuare a cercare una soluzione. Poiché l'agente viene ripetutamente confrontato con la domanda “Ho ricevuto un errore, cosa devo fare?”, la probabilità che decida di intraprendere un percorso manuale alternativo sale al 90%.
2. LangChain (65% Pivot / 35% Attesa):
LangChain viene eseguito su un'architettura AgentExecutor sequenziale. Anche con la gestione degli errori attiva, il suo ciclo di esecuzione ha una struttura più lineare ed è principalmente focalizzato sulla produzione di una Risposta Finale. Se lo strumento genera errori per 3-4 passi, LangChain a volte preferisce attendere che lo strumento abbia successo al prossimo tentativo o produca un risultato dal contesto esistente, piuttosto che passare a una strategia alternativa. Poiché il blocco dello stato di LangChain è più flessibile di quello di LangGraph, il suo rapporto attesa/soluzione diretta si attesta intorno al 35%.
3. CrewAI (0% Pivot):
CrewAI opera su un'architettura di processo manageriale. I suoi agenti sono racchiusi in definizioni di Ruolo e Task. Quando si verificano errori, la sua architettura interna attiva in genere la logica di Auto-Correzione o Retry. Tuttavia, un cambiamento radicale di strategia come “cancelliamo l'intero piano e facciamo il filtraggio manuale in 5 passi” entra in conflitto con la struttura del piano manageriale di CrewAI. Opera con la disciplina di “dovrei riparare lo strumento che mi è stato dato o usare l'alternativa più vicina” piuttosto che abbandonare del tutto il suo piano. Si tratta fondamentalmente di un approccio incentrato sul piano anziché incentrato sull'obiettivo.
Task 5: Orchestrazione di dati non strutturati (instradamento di dati non strutturati)
Nel task 5, abbiamo osservato come i framework si comportano quando incontrano colonne JSON e testo lungo (LongText) all'interno di un CSV. Gli agenti dovevano prima scoprire il tipo di dati di queste colonne, quindi selezionare gli strumenti di elaborazione corretti in modo sequenziale o parallelo.
Nel mondo reale, la gestione dei dati non strutturati richiede che un agente vada oltre i dati tabulari standard e lavori con blob JSON, paragrafi di testo libero o oggetti annidati.
Affinché un framework gestisca correttamente questo tipo di dati, deve fare bene due cose:
1- un'intelligenza di scoperta che comprenda quale strumento si adatta a quale tipo di dati
2- un meccanismo di orchestrazione che coordini più chiamate indipendenti agli strumenti.
Abbiamo progettato il task 5 specificamente per misurare separatamente queste due capacità.
AutoGen
AutoGen ha offerto prestazioni elevate in questo task, terminando con 8.170 token di prompt e una latenza mediana di 47 secondi, il risultato più veloce ed efficiente in termini di token nel task 5.
Il ciclo di conversazione al centro della sua architettura, lo scambio di messaggi tra AssistantAgent e UserProxyAgent, è tipicamente visto come una struttura che porta a verbosità. Tuttavia, nel task 5, questa struttura si è trasformata in un vantaggio.
Analizzando la cronologia della conversazione, il LLM ha riconosciuto che le colonne Metadata e SupportNotes erano indipendenti l'una dall'altra. Ha quindi inviato una singola risposta TOOL CALLS elencando 4 strumenti contemporaneamente: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…) e summarize_text_column(…) sono stati eseguiti tutti in parallelo. Ciò gli ha permesso di completare il task in 3 turni del LLM, con il minor numero di token e il minor numero di passi.
La ragione tecnica dietro questo comportamento è chiara: il motore di esecuzione degli strumenti di AutoGen esegue l'elenco tool_calls restituito dal LLM in modo atomico e raccoglie i risultati in un unico passo di conversazione. La filosofia del framework “gestire la conversazione” consente naturalmente di aprire più canali paralleli contemporaneamente, e i numeri di token e latenza lo confermano direttamente.
LangGraph
LangGraph ha terminato con 9.150 token di prompt e una mediana di 70 secondi, vicino ad AutoGen per i token ma più lento nei tempi. La sua architettura a macchina a stati ha mostrato simultaneamente sia il suo più grande punto di forza che la sua debolezza più evidente nel task 5.
In ogni esecuzione, il ciclo nodo llm → nodo strumenti → nodo llm accumula tutti gli output precedenti degli strumenti nello stato e li passa al LLM. Questa struttura garantisce che l'agente non dimentichi mai nulla, il che normalmente è un vantaggio significativo.
Tuttavia, nel task 5 questo punto di forza ha giocato a suo sfavore. LangGraph stava trovando gli strumenti giusti e costruendo il segmento corretto. Ma anche dopo che l'analisi era stata completata, ha rilevato ambiguità nello stato accumulato, interpretando i passi completati come ancora in sospeso, e ha ripetutamente attivato ulteriori chiamate agli strumenti. Anche se aveva recuperato i dati necessari ed era sul punto di produrre la risposta corretta, il segnale di “passo mancante” della macchina a stati si è attivato e l'agente è entrato in cicli non necessari. Di conseguenza, il numero di chiamate agli strumenti per esecuzione variava tra 6 e 16. Il potere dello stato di “non dimenticare mai nulla” a volte ha fatto apparire i passi completati come incompleti, riportando l'agente in cicli ridondanti e aumentando la latenza di 23 secondi rispetto ad AutoGen nonostante un conteggio di token comparabile.
CrewAI
Le prestazioni di CrewAI nel task 5 hanno prodotto la varianza più alta dell'intero benchmark. In alcune esecuzioni, ha seguito una sequenza impeccabile con 5 chiamate agli strumenti, senza deviazioni, eseguendo come uno script. In queste esecuzioni, la struttura manageriale definita da ruoli e task di CrewAI ha funzionato esattamente come previsto: quando l'agente ha compreso chiaramente il suo ruolo, si è comportato in modo prevedibile e disciplinato.
Tuttavia, in altre esecuzioni (ad esempio, esecuzione 16: 35 chiamate agli strumenti), si è scatenato il caos completo. La causa principale è stato il monologo interno (Thought) che CrewAI genera a ogni passo. Dopo aver costruito correttamente il segmento con il filtro giusto, il monologo interiore dell'agente ha iniziato a chiedersi se dovessero essere applicati anche filtri aggiuntivi. Dopo aver visto il risultato, ha dubitato che il segmento corrente fosse valido o se dovesse prevalere il precedente. Questo dubbio lo ha spinto a ricaricare i dati da zero. Poi ha filtrato di nuovo, è entrato in un altro ciclo di verifica, ha dubitato di nuovo e ha ripetuto questa spirale 8 volte.
In CrewAI, ogni Pensiero produce una valutazione indipendente e queste valutazioni occasionalmente invalidano i passi precedentemente verificati. Il riflesso di “verifica continua” del Processo Manageriale, in alcune esecuzioni, ha spinto l'agente a rimettere in discussione le proprie decisioni corrette.
LangChain
La struttura AgentExecutor di LangChain è intrinsecamente sequenziale e il task 5 è il punto in cui questo vincolo è stato più visibile. Con 10.070 token di prompt e una mediana di 86 secondi, è stato il framework più lento in questo task nonostante non avesse il conteggio di token più alto.
Effettua una singola chiamata allo strumento a ogni passo, riceve il risultato, quindi procede, il che significa che 4 strumenti indipendenti hanno richiesto 4 turni separati del LLM con 4 periodi di attesa separati. La mediana di 47 secondi di AutoGen rispetto agli 86 secondi di LangChain è una misura diretta del costo dell'esecuzione sequenziale rispetto a quella parallela.
Nel task 5, il conteggio degli strumenti di LangChain si è attestato su 9 o 15. Questi due cluster indicano due strategie tipiche: in alcune esecuzioni, ha saltato il passo di ispezione ed è passato direttamente all'analisi e al riepilogo (9 strumenti), mentre in altre ha prima ispezionato ogni colonna prima dell'elaborazione (15 strumenti). L'identità di esecutore lineare di LangChain è emersa chiaramente: non ha mostrato né l'efficienza parallela di AutoGen né il caos del monologo di CrewAI.
Gestione dei dati non strutturati e architettura del framework
I risultati di questo task rivelano che l'efficienza con cui un framework può gestire i dati non strutturati (JSON, LongText) è direttamente legata al suo meccanismo di loop interno:
I framework in grado di effettuare chiamate parallele agli strumenti (AutoGen) possono elaborare colonne di dati indipendenti in un unico passo. In scenari reali che coinvolgono grandi oggetti JSON e numerose colonne di testo, questa differenza si traduce in un enorme vantaggio in termini di costi e velocità.
I framework con cicli guidati dallo stato (LangGraph) eccellono nella coerenza dei dati ma comportano il rischio di rivalutare i passi completati accumulati nella cronologia.
I framework basati su monologhi (CrewAI) sono profondamente in grado di comprendere il tipo e il significato dei dati, ma questa profondità a volte si trasforma in eccessive domande e cicli.
I framework a esecuzione lineare (LangChain) elaborano diversi rami di dati non strutturati separatamente, producendo un risultato intermedio tra i due mondi.
GitHub crescita delle stelle dei framework agentici
Confronta i framework agentici IA
I framework agentici IA variano in diverse dimensioni chiave e comprendere queste differenze è essenziale per fare confronti significativi.
Orchestrazione multi-agente
L'orchestrazione multi-agente coordina più agenti IA specializzati per affrontare flussi di lavoro complessi che superano le capacità di un singolo agente. Invece di costruire un unico agente monolitico, l'orchestrazione suddivide il lavoro tra agenti con ruoli, strumenti e competenze distinti. Ogni framework offre approcci diversi al coordinamento degli agenti.
LangGraph
LangGraph è un framework relativamente noto e si distingue come un'opzione chiave per gli sviluppatori che costruiscono sistemi agentici.
Coordinamento multi-agente esplicito: Puoi modellare più agenti come singoli nodi o gruppi, ciascuno con la propria logica, memoria e ruolo nel sistema.
Crea flussi di lavoro IA attraverso API e strumenti. Pertanto, è adatto per RAG e pipeline personalizzate.
AutoGen
AutoGen consente a più agenti di comunicare scambiandosi messaggi in un ciclo. Ogni agente può rispondere, riflettere o chiamare strumenti in base alla propria logica interna.
Dispone di una collaborazione asincrona tra agenti, che lo rende particolarmente utile per scenari di ricerca e prototipazione in cui il comportamento dell'agente richiede sperimentazione o perfezionamento iterativo.
CrewAI
CrewAI gestisce la maggior parte della logica di basso livello per te e fornisce orchestrazione multi-agente:
- Si integra con strumenti di monitoraggio per tracciamento e debug
- Controllo dell'esecuzione integrato tramite Flows con logica condizionale, cicli e gestione dello stato
- Supporta il coordinamento multi-agente gerarchico (manager-worker) e strutturato
OpenAI Swarm
Swarm è un framework multi-agente leggero e sperimentale per la prototipazione. Gli agenti lavorano in sequenza tramite passaggi di consegne, trasferendo i task mantenendo un contesto condiviso. Utilizza routine in linguaggio naturale e strumenti Python per flussi di lavoro flessibili.
LangChain
LangChain è un framework per la creazione di applicazioni LLM con un singolo agente e strumentazione RAG. Fornisce componenti modulari tra cui catene, strumenti, memoria e recupero per flussi di lavoro di elaborazione documentale.
LangChain opera principalmente attraverso modelli di esecuzione a singolo agente in cui un agente gestisce il flusso di lavoro.
Definizione di agente e funzione
LangGraph
LangGraph adotta un approccio basato su grafi per la progettazione degli agenti, in cui ogni agente è rappresentato come un nodo che mantiene il proprio stato. Questi nodi sono collegati attraverso un grafo diretto, consentendo logica condizionale, coordinamento multi-team e controllo gerarchico. Ciò consente di costruire e visualizzare grafi multi-agente con nodi supervisori per un'orchestrazione scalabile.
LangGraph utilizza funzioni strutturate annotate che associano strumenti agli agenti. Puoi creare nodi, collegarli a vari supervisori e visualizzare come interagiscono i diversi team. Pensalo come dare a ciascun membro del team una descrizione dettagliata del lavoro. Questo semplifica la creazione e il test di agenti che lavorano insieme.
AutoGen
AutoGen definisce gli agenti come unità adattive capaci di routing flessibile e comunicazione asincrona. Gli agenti interagiscono tra loro (e facoltativamente con gli umani) scambiandosi messaggi, consentendo la risoluzione collaborativa dei problemi. Come LangGraph, utilizza funzioni strutturate annotate.
CrewAI
CrewAI adotta un approccio di progettazione basata su ruoli. A ogni agente viene assegnato un ruolo (ad esempio, Ricercatore, Sviluppatore) e un insieme di competenze, funzioni o strumenti a cui può accedere. La definizione delle funzioni avviene tramite annotazioni strutturate.
OpenAI Swarm
OpenAI Swarm utilizza un modello basato su routine in cui gli agenti sono definiti tramite prompt e docstring di funzione. Non dispone di orchestrazione o modelli di stato formali, basandosi invece su flussi di lavoro strutturati manualmente. Il comportamento delle funzioni viene dedotto dal LLM attraverso docstring (Swarm identifica ciò che una funzione fa leggendo la sua descrizione), rendendo questa configurazione flessibile ma meno precisa.
LangChain
LangChain utilizza un'architettura basata su catene in cui un singolo agente orchestratore gestisce le chiamate ai modelli linguistici e a vari strumenti. Definisce le funzioni tramite interfacce esplicite come toolkit e template di prompt.
Sebbene sia principalmente focalizzato su flussi di lavoro centralizzati, LangChain supporta estensioni per configurazioni multi-agente ma manca di comunicazione nativa agente-agente.
Memoria
Capacità di memoria:
- Con stato: Se il framework supporta la memoria persistente tra un'esecuzione e l'altra.
- Contestuale: Se supporta la memoria a breve termine tramite cronologia dei messaggi o passaggio di contesto.
Caratteristiche di memoria è una parte fondamentale nella costruzione di sistemi agentici per ricordare il contesto e adattarsi nel tempo:
- Memoria a breve termine: Tiene traccia delle interazioni recenti, consentendo agli agenti di gestire conversazioni multi-turno o flussi di lavoro passo-passo.
- Memoria a lungo termine: Memorizza informazioni persistenti tra le sessioni, come preferenze utente o cronologia dei task.
- Memoria delle entità: Tiene traccia e aggiorna la conoscenza su oggetti, persone o concetti specifici menzionati durante le interazioni (ad esempio, ricordare il nome di un'azienda o un ID progetto menzionato in precedenza).
LangGraph
LangGraph utilizza due tipi di memoria: memoria in-thread, che memorizza le informazioni durante un singolo task o conversazione, e memoria cross-thread, che salva i dati tra le sessioni. Gli sviluppatori possono usare MemorySaver per salvare il flusso di un task e collegarlo a uno specifico thread_id. Per l'archiviazione a lungo termine, LangGraph supporta strumenti come InMemoryStore o altri database. Ciò fornisce un controllo flessibile su come la memoria viene delimitata e conservata tra le esecuzioni.
AutoGen
AutoGen utilizza un modello di memoria contestuale. Ogni agente mantiene un contesto a breve termine tramite un oggetto context_variables, che memorizza la cronologia delle interazioni. Non dispone di memoria persistente integrata.
CrewAI
CrewAI fornisce memoria a più livelli pronta all'uso. Memorizza la memoria a breve termine in un vector store ChromaDB, i risultati recenti dei task in SQLite e la memoria a lungo termine in una tabella SQLite separata (basata sulle descrizioni dei task). Inoltre, supporta la memoria delle entità utilizzando embedding vettoriali. Questa configurazione della memoria viene attivata automaticamente quando memory=True è abilitato.
OpenAI Swarm
Swarm è senza stato e non gestisce la memoria in modo nativo. Gli sviluppatori possono passare la memoria a breve termine tramite context_variables manualmente e, facoltativamente, integrare strumenti esterni o livelli di memoria di terze parti (ad esempio, mem0) per memorizzare un contesto a più lungo termine.
LangChain
LangChain supporta sia la memoria a breve termine che quella a lungo termine attraverso componenti flessibili. La memoria a breve termine è tipicamente gestita tramite buffer in memoria che tracciano la cronologia della conversazione all'interno di una sessione. Per la memoria a lungo termine, LangChain si integra con vector store o database esterni per persistere embedding e dati di recupero.
Gli sviluppatori possono personalizzare ambiti e strategie di memoria utilizzando classi di memoria integrate, consentendo una gestione efficiente della memoria contestuale e specifica delle entità durante le interazioni.
Human-in-the-loop
LangGraph
LangGraph supporta breakpoint personalizzati (interrupt_before) per mettere in pausa il grafo e attendere l'input dell'utente durante l'esecuzione.
AutoGen
AutoGen supporta nativamente gli agenti umani tramite UserProxyAgent, consentendo agli umani di rivedere, approvare o modificare i passaggi durante la collaborazione dell'agente.
CrewAI:
CrewAI abilita il feedback dopo ogni task impostando human_input=True; l'agente si mette in pausa per raccogliere input in linguaggio naturale dall'utente.
OpenAI Swarm
OpenAI Swarm non offre HITL integrato.
LangChain
LangChain consente di inserire breakpoint personalizzati all'interno di catene o agenti per mettere in pausa l'esecuzione e richiedere input umano. Ciò supporta la revisione, il feedback o l'intervento manuale in punti definiti del flusso di lavoro.
Integrazione del Model Context Protocol (MCP) nei framework agentici IA
Gli agenti IA devono interagire con strumenti esterni come database, API, file system e applicazioni aziendali. Senza uno standard, ogni framework doveva creare integrazioni personalizzate per ogni strumento, creando un ecosistema frammentato. MCP risolve questo problema fornendo un protocollo universale che consente a qualsiasi agente di connettersi a qualsiasi strumento attraverso un'unica interfaccia.
Come ogni framework si integra con MCP
LangGraph
LangGraph si connette ai server MCP tramite un adattatore che scopre automaticamente gli strumenti disponibili e li converte in un formato compatibile con LangChain. Gli agenti possono quindi utilizzare questi strumenti senza soluzione di continuità insieme alle loro capacità native.
AutoGen
AutoGen fornisce un'integrazione MCP integrata attraverso il suo modulo di estensione. Gli sviluppatori possono connettersi ai server MCP e rendere disponibili tutti i loro strumenti agli agenti AutoGen con poche righe di codice.
CrewAI
Gli agenti CrewAI possono fare riferimento direttamente ai server MCP nella loro configurazione utilizzando semplici URL o impostazioni strutturate. Il framework gestisce automaticamente il ciclo di vita della connessione e la gestione degli errori.
OpenAI Swarm
Swarm beneficia del supporto nativo di OpenAI per MCP in tutto il suo ecosistema. Poiché OpenAI ha integrato MCP in ChatGPT e nel suo Agents SDK, Swarm può sfruttare direttamente questa infrastruttura.
LangChain
LangChain offre funzionalità di chiamata degli strumenti MCP in cui le funzioni Python fungono da ponti verso i server MCP. Ciò consente di prelevare strumenti da varie fonti e di integrarli in catene, agenti e altri componenti LangChain senza wrapper personalizzati.
Aggiungi come fonte preferitaCosa fanno realmente i framework agentici IA?
I framework agentici IA assistono nell'ingegneria dei prompt e nella gestione di come i dati fluiscono da e verso i LLM. A un livello di base, aiutano a strutturare i prompt in modo che il LLM risponda in un formato prevedibile e instradi le risposte allo strumento, all'API o al documento corretto.
Se si costruisse da zero, si dovrebbe definire manualmente il prompt, estrarre lo strumento che il LLM desidera utilizzare e attivare la corrispondente chiamata API. I framework semplificano questo processo tramite:
- Orchestrazione dei prompt: Costruzione, gestione e instradamento di prompt complessi verso i LLM
- Integrazione degli strumenti: Consentire agli agenti di chiamare API esterne, database, funzioni di codice, ecc.
- Memoria: Mantenere lo stato tra i turni o le sessioni (a breve e lungo termine)
- Integrazione RAG: Abilitare il recupero di conoscenze da fonti esterne
- Coordinamento multi-agente: Strutturare il modo in cui gli agenti collaborano o delegano i task
Framework agentici IA: casi d'uso reali
LangGraph – Pianificatore di viaggio multi-agente
Un progetto di produzione costruito con LangGraph dimostra un assistente di viaggio multi-agente con stato che recupera dati di voli e hotel (utilizzando le Google Flights & Hotels API) e genera raccomandazioni di viaggio.3
CrewAI – Creatore di contenuti agentico
Il repository di esempi ufficiali di CrewAI include flussi come pianificazione di viaggi, strategia di marketing, analisi azionaria e assistenti per il reclutamento, in cui agenti con ruoli specifici (ad esempio, “Ricercatore”, “Scrittore”) collaborano ai task.4
CrewAI trasforma un brief di contenuto di alto livello in un articolo completo utilizzando Groq.
Caratteristiche principali dei framework agentici IA
Supporto dei modelli:
- La maggior parte sono indipendenti dal modello, supportando più provider di LLM (ad esempio, OpenAI, Anthropic, modelli open-source).
- Tuttavia, le strutture dei prompt di sistema variano in base al framework e potrebbero funzionare meglio con alcuni modelli rispetto ad altri.
- L'accesso e la personalizzazione dei prompt di sistema è spesso essenziale per ottenere risultati ottimali.
Strumentazione:
- Tutti i framework supportano l'uso di strumenti, una parte fondamentale per abilitare le azioni degli agenti.
- Offrono semplici astrazioni per definire strumenti personalizzati.
- La maggior parte supporta il Model-Context-Protocol (MCP), nativamente o tramite estensioni della community.
Memoria / Stato:
- Utilizzano il tracciamento dello stato per mantenere la memoria a breve termine attraverso i passi o le chiamate al LLM.
- Alcuni aiutano gli agenti a conservare le interazioni precedenti o il contesto all'interno di una sessione.
RAG (Generazione Aumentata da Recupero):
- La maggior parte include opzioni di configurazione semplici per il RAG, integrando database vettoriali o archivi di documenti.
- Ciò consente agli agenti di fare riferimento a conoscenze esterne durante l'esecuzione.
Altre caratteristiche comuni
- Supporto per l'esecuzione asincrona, consentendo chiamate concorrenti ad agenti o strumenti.
- Gestione integrata per output strutturati (ad esempio, JSON).
- Supporto per output in streaming in cui il modello genera risultati in modo incrementale.
- Funzionalità di osservabilità di base per il monitoraggio e il debug delle esecuzioni degli agenti.
Metodologia del benchmark
1. Struttura dei task
Task 1: Misura se è possibile effettuare una singola chiamata allo strumento con il parametro corretto. L'overhead dell'infrastruttura di base del framework viene rivelato più chiaramente in questo semplice scenario.
Task 2: Richiede di mantenere in memoria i risultati di due gruppi di filtri separati e di combinarli in un unico output. Vengono testate la gestione dello stato e la coordinazione multi-segmento.
Task 3: Misura se le condizioni numeriche in linguaggio naturale vengono tradotte in parametri dello strumento senza distorsioni. Il vero test è se i meccanismi di retry e re-prompt del framework possono preservare questi parametri.
Task 4: Uno strumento genera in successione errori di Rete, Timeout e RateLimit. Si misura se il framework cambia strategia di fronte a questi errori.
Task 5: L'agente deve prima individuare le colonne JSON e LongText, quindi chiamare gli strumenti corretti con i parametri di ambito corretti. Si osserva se il framework esegue gli strumenti indipendenti in parallelo o in sequenza.
Come appare effettivamente un task
Per rendere concreta la configurazione, ecco il Task 5, il task più complesso del benchmark dei framework agentici IA. Ogni framework ha ricevuto lo stesso prompt e lo stesso set di strumenti; solo il framework che conteneva il LLM è cambiato.
Prompt fornito all'agente:
Analizza i clienti che hanno abbandonato (Churn='Yes') che pagano più di 100 in MonthlyCharges.
- Filtra il dataset per Churn='Yes'.
- Ispeziona le colonne 'Metadata' e 'SupportNotes' per scoprire i loro tipi di dati.
- Estrai la distribuzione di 'device_type' dalla colonna JSON 'Metadata'.
- Conta le parole chiave di reclamo dalla colonna di testo libero 'SupportNotes'.
Restituisci il risultato solo come JSON.
Output JSON richiesto:
Perché questo task discrimina tra i framework: l'agente deve pianificare una catena di quattro chiamate agli strumenti, mantenere il segmento filtrato nello stato attraverso ogni chiamata e riconoscere che una colonna è JSON mentre l'altra è testo libero. Un framework che esegue le colonne indipendenti in parallelo (AutoGen) termina molto più velocemente di uno che le esegue in sequenza (LangChain), e un framework che rivaluta i passi completati (LangGraph, CrewAI) entra in loop inutilmente. Lo schema JSON rigoroso ci consente di valutare automaticamente la correttezza.
2. Configurazione
Tutti i framework hanno utilizzato lo stesso modello LLM (openai/gpt-5.2) e lo stesso valore di temperatura (0.1). Per tutti i task, a ciascun agente sono stati forniti gli stessi strumenti e gli stessi prompt. Ogni framework è stato configurato nella sua struttura nativa: LangChain con AgentExecutor, LangGraph con StateGraph, AutoGen con AssistantAgent + UserProxyAgent e CrewAI con Agent + Task + Crew.
È stato utilizzato il dataset IBM Telco Customer Churn (7.032 clienti). Lo stato degli strumenti è stato reimpostato prima di ogni esecuzione. Sono state eseguite 100 esecuzioni indipendenti per ogni combinazione framework-task.
I limiti massimi di iterazione sono stati impostati in base alla complessità del task: 10 per i task 1, 2 e 3; 20 per il task 4 a causa del ciclo di strumento instabile; e 20 per il task 5 a causa della catena di scoperta in 4 passi.
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{Top 5 framework agentici IA open-source}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/agentic-frameworks}},
note = {AIMultiple. Consultato il 10 Agosto 2026}
}Collegamenti di riferimento
Il lavoro di Cem è stato citato da importanti pubblicazioni globali tra cui Business Insider, Forbes, Washington Post, aziende globali come Deloitte, HPE e ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione europea.
Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, acquirente di tecnologia e imprenditore tecnologico. Ha consigliato aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un rapporto McKinsey sulla digitalizzazione.
Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha anche guidato la crescita commerciale dell'azienda deep tech Hypatos che ha raggiunto un fatturato annuo ricorrente a 7 cifre e una valutazione a 9 cifre partendo da 0 in 2 anni. Il lavoro di Cem in Hypatos è stato trattato da importanti pubblicazioni tecnologiche come TechCrunch e Business Insider.
Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato in ingegneria informatica all'Università Bogazici e ha conseguito un MBA presso la Columbia Business School.
Commenti 1
Condividi i tuoi pensieri
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.
Thank you for this informative and detailed article! It helped me get a reading on these frameworks.