I 5 migliori framework open-source di IA agentica

Abbiamo sottoposto a benchmark 4 popolari framework agentici open-source su 2.000 esecuzioni (5 task, 100 esecuzioni ciascuno per framework), misurando la latenza end-to-end, il consumo di token e le differenze architetturali.

Benchmark dei framework di IA agentica

Abbiamo esaminato come i framework stessi influenzino il comportamento degli agenti 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 in latenza; LangGraph e LangChain seguono da vicino. CrewAI presenta il profilo complessivamente più pesante.

Puoi consultare la metodologia del benchmark dei framework di IA agentica per maggiori dettagli sui task.

Task 1: Aggregazione di base

Innanzitutto, abbiamo misurato l'overhead di ciascun framework quando chiama un singolo strumento e restituisce il risultato, senza eseguire ragionamenti complessi.

LangChain e LangGraph: per i task semplici, sono quasi veloci quanto il codice non agentico, entrambi completano in meno di 5 secondi con meno di 900 prompt token. L'architettura a macchina a stati di LangGraph non introduce latenza evidente rispetto a LangChain a questo livello di semplicità; l'overhead della gestione dello stato si manifesta man mano che la complessità dei task cresce.

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, due agenti che si scambiano messaggi anche per un task a singolo passaggio.

CrewAI: anche quando gli viene chiesto di effettuare una singola chiamata a uno strumento, mostra quello che si potrebbe definire “overhead manageriale”, consumando quasi 3× i token di LangChain e impiegando quasi 3× più tempo. Il processo di verifica multi-step tra i personaggi Planner e Analyst offre un approccio accurato ma dispendioso in termini di risorse, che privilegia la completezza alla velocità. Questo costo è strutturale: si presenta 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 combinarli.

CrewAI

Nell'analisi dei log, abbiamo riscontrato che CrewAI offre il più alto livello di trasparenza dell'infrastruttura tra i framework, ma al costo del più elevato 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 lo ha portato a raggiungere il limite configurato max_iter=10, lasciando alcune esecuzioni bloccate in un loop di pensiero continuo senza produrre un output JSON.

La causa principale di questo comportamento è che CrewAI inietta istruzioni multi-livello nel prompt di sistema, assegnando a ogni agente un ruolo, un obiettivo e una backstory, imponendo al contempo un loop in stile ReAct Thought → Action → Observation a ogni passaggio. Anche per i task semplici, il LLM non può saltare questa procedura 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 più del triplo del tempo di LangChain, rendendolo più adatto a transizioni di stato complesse e processi decisionali multi-fattore piuttosto che a task di recupero dati diretti.

LangChain

Il framework più veloce ed economico. Nei nostri log, abbiamo osservato che LangChain completa il task in 5-6 passaggi senza deviazioni: Load → Filter → Calculate → Filter → Calculate → 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 una prestazione molto equilibrata. Nel Task 2, ha eguagliato LangGraph quasi esattamente sia in consumo di token che in 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 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, è 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 tutta l'esecuzione. Il rischio di contaminazione dei dati o di interferenza tra segmenti è al livello più basso in questo framework. Su tutte le 100 esecuzioni, ha prodotto risultati quasi con lo stesso numero di passaggi e entro lo stesso intervallo di latenza.

Task 3: Parsing delle soglie (disciplina numerica)

In questo task, volevamo 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.

Il LLM sa come effettuare questa conversione; ciò che volevamo davvero testare era se il framework riesce a proteggere questi parametri attraverso i propri meccanismi di retry, il contesto di re-prompt e i cicli di gestione dello stato.

LangChain e 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 né loop 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 prompt token, 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: qualunque parametro venisse generato, è quello che veniva eseguito.

AutoGen

AutoGen ha pieno successo nella correttezza numerica. In alcune esecuzioni, è stato osservato che il framework ha aggiunto un passaggio di verifica prima di passare il parametro generato dal LLM allo strumento, il che significa che il framework ha impiegato un passaggio extra pur preservando il parametro. Con 2.480 token e 8 secondi, ha eguagliato la latenza di LangChain nonostante il passaggio extra, confermando che l'overhead di verifica è reale ma contenuto. Ha soddisfatto le nostre 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.

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 schemi di errore distinti.

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 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 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 azzeccato.

Task 4: Resilienza agli errori e capacità di pivot

In questo task, volevamo vedere come ciascun framework gestisce scenari dirompenti e osservare l'impatto su latenza e consumo di token. Lo strumento lancia 3 diversi tipi di errori in successione (Network, Timeout, Rate Limit), mettendo l'agente alle strette. I primi due errori indicano all'agente di riprovare e, dopo aver riprovato entrambi, l'errore Rate Limit in arrivo dice all'agente di attendere 10 secondi. Una volta che l'agente attende e riprova, lo strumento inizia a funzionare normalmente.

LangGraph e AutoGen

Questi due framework hanno trovato soluzioni alternative autonomamente di fronte ai guasti degli strumenti in questo task.

Quando lo strumento ha restituito un avviso di rate limit, invece di fermarsi e attendere, questi agenti hanno deciso di abbandonare completamente lo strumento guasto e trovare un percorso alternativo. Il loro approccio è stato: “Poiché questo strumento non funziona, filtrerò ciascun metodo di pagamento uno per uno, calcolerò il tasso di abbandono per ciascuno separatamente e poi combinerò i risultati da solo”.

Metodo: invece di completare il task con una singola chiamata a uno strumento, lo hanno scomposto usando due strumenti separati, uno per il filtraggio e uno per il calcolo, elaborando individualmente ciascun PaymentMethod (Electronic check, Mailed check, ecc.).

Questi agenti operano con un ragionamento orientato all'obiettivo piuttosto che alla dipendenza dal percorso. Se il percorso più breve non è disponibile, possono costruire un piano di esecuzione alternativo in pochi secondi.

LangGraph ha raggiunto 15.010 prompt token nel Task 4, il numero di token più alto per un singolo task in tutto il benchmark, perché la sua macchina a stati accumulava la storia crescente di ogni chiamata manuale a uno strumento nel contesto a ogni passaggio. AutoGen ha seguito con 10.750 token, un po' più contenuto grazie alla 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 latenza significativa perché il pivot stesso è stato rapido.

CrewAI

Nonostante avesse mostrato il consumo di token più elevato nei task precedenti, in questo task CrewAI ha mostrato il consumo di token più basso) ma i valori di latenza più alti.

Perché il consumo di token più basso?

CrewAI non ha eseguito un workaround manuale di 10-15 passaggi come i suoi concorrenti. Quando ha incontrato errori, invece di reimmettere ripetutamente l'intera cronologia e i dati intermedi complessi nel LLM a ogni passaggio, ha costruito un ciclo di ragionamento più focalizzato e modulare. Evitando la verbosità non necessaria, è diventato il framework più conveniente in questo task.

Perché una latenza elevata?

La struttura manageriale di CrewAI si ferma 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 ostinatamente di attendere il ripristino dello strumento principale o di tentare con lo strumento stabile, il che ha prolungato la durata complessiva.

LangChain

LangChain ha attraversato la sua trasformazione più significativa in questo task, dimostrando perché la resilienza dipende 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 da uno strumento come errori fatali e termina il processo. A differenza dei suoi concorrenti, non applica di default una filosofia “gli errori sono osservazioni”. Poiché l'agente non vede mai l'errore, non ha modo 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 ha potuto 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'uso di due strumenti separati, uno per il filtraggio e uno per il calcolo, ha elaborato individualmente ciascun metodo di pagamento e ha combinato i risultati.

LangChain è in realtà altrettanto capace e adattivo quanto LangGraph, ma poiché la gestione degli errori del framework era disattivata di default, non ha avuto l'opportunità di dimostrare questa capacità. Una volta configurato correttamente, ha raggiunto il risultato corretto utilizzando lo stesso approccio basato su percorsi alternativi.

Perché si sono verificate queste differenze? (analisi dell'architettura dei framework)

Se il comportamento degli agenti dipendesse soltanto 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 di ciclo interno dei framework stessi:

1. LangGraph e AutoGen (90% Pivot):

LangGraph opera su un'architettura State Machine, mentre AutoGen funziona 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 messaggio di chat. Questo meccanismo di sollecitazione costante costringe l'agente a continuare a cercare una soluzione. Poiché l'agente viene ripetutamente messo di fronte alla 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 gira su un'architettura sequenziale AgentExecutor. Anche con la gestione degli errori attiva, il suo ciclo di esecuzione ha una struttura più lineare ed è principalmente focalizzato sulla produzione di una Final Answer. Se lo strumento lancia errori per 3-4 passaggi, LangChain a volte preferisce attendere che lo strumento riesca al tentativo successivo o produrre 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 Managerial Process. I suoi agenti sono racchiusi in definizioni di Role e Task. Quando si verificano errori, la sua architettura interna in genere attiva la logica Self-Correction o Retry. Tuttavia, un cambiamento radicale di strategia come “abbandoniamo l'intero piano e facciamo un filtraggio manuale in 5 passaggi” è in conflitto con la struttura del piano manageriale di CrewAI. Opera con la disciplina di “dovrei aggiustare lo strumento che mi è stato dato o usare l'alternativa più vicina” piuttosto che abbandonare del tutto il piano. Questo è fondamentalmente un approccio incentrato sul piano, contrapposto a uno incentrato sull'obiettivo.

Task 5: Orchestrazione dei dati non strutturati (routing dei dati non strutturati)

Nel task 5, abbiamo osservato come si comportano i framework 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 in parallelo.

Nel mondo reale, la gestione dei dati non strutturati richiede che un agente vada oltre i dati tabellari standard e lavori con blob JSON, paragrafi di testo gratuito o oggetti annidati.

Affinché un framework gestisca correttamente questo tipo di dati, deve fare bene due cose:

1- un'intelligenza di scoperta che comprende quale strumento si adatta a quale tipo di dati

2- un meccanismo di orchestrazione che coordina più chiamate a strumenti indipendenti.

Abbiamo progettato il Task 5 specificamente per misurare separatamente queste due capacità.

AutoGen

AutoGen ha offerto una prestazione solida in questo task, terminando con 8.170 prompt token 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, è generalmente considerato una struttura che porta alla verbosità. Tuttavia, nel Task 5, questa struttura si è trasformata in un vantaggio.

Esaminando 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. Questo gli ha permesso di completare il task in 3 turni di LLM, con il minor numero di token e il minor numero di passaggi.

La ragione tecnica di questo comportamento è chiara: il motore di esecuzione degli strumenti di AutoGen esegue atomicamente la lista tool_calls restituita dal LLM e raccoglie i risultati in un unico passaggio conversazionale. 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 prompt token e 70 secondi di mediana, vicino ad AutoGen in token ma più lento nel tempo. La sua architettura State Machine ha mostrato contemporaneamente il suo più grande punto di forza e 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 questa forza ha giocato a suo sfavore. LangGraph trovava gli strumenti corretti e costruiva il segmento corretto. Ma anche dopo il completamento dell'analisi, rilevava ambiguità nello stato accumulato, interpretando i passaggi completati come ancora in sospeso, e attivava ripetutamente ulteriori chiamate agli strumenti. Pur avendo recuperato i dati necessari e pur essendo sul punto di produrre la risposta corretta, il segnale di “passaggio mancante” della macchina a stati entrava in azione e l'agente entrava in loop inutili. 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 faceva apparire incompleti i passaggi completati, trascinando l'agente in cicli ridondanti e portando la latenza 23 secondi sopra AutoGen nonostante un numero di token comparabile.

CrewAI

La prestazione di CrewAI nel Task 5 ha 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 ruolo e task di CrewAI ha funzionato esattamente come previsto: quando l'agente comprendeva chiaramente il proprio ruolo, si comportava in modo prevedibile e disciplinato.

Tuttavia, in altre esecuzioni (ad es., esecuzione 16: 35 chiamate agli strumenti), è seguito il caos completo. La causa principale era il monologo interno (Thought) che CrewAI genera a ogni passaggio. Dopo aver costruito correttamente il segmento con il filtro giusto, il monologo interno dell'agente ha iniziato a chiedersi se non si dovessero applicare anche filtri aggiuntivi. Dopo aver visto il risultato, dubitava se il segmento corrente fosse valido o se quello precedente dovesse avere la precedenza. 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 ancora e ha ripetuto questa spirale 8 volte.

In CrewAI, ogni Thought produce una valutazione indipendente e queste valutazioni occasionalmente invalidano i passaggi precedentemente verificati. Il riflesso di “verifica continua” del Managerial Process, in alcune esecuzioni, ha spinto l'agente a rimettere in discussione le proprie decisioni corrette.

LangChain

La struttura AgentExecutor di LangChain è intrinsecamente sequenziale, ed è nel Task 5 che questo vincolo è stato più visibile. Con 10.070 prompt token e 86 secondi di mediana, è stato il framework più lento in questo task pur non avendo il numero di token più alto.

Effettua una singola chiamata a uno strumento a ogni passaggio, riceve il risultato e poi prosegue, il che significa che 4 strumenti indipendenti hanno richiesto 4 turni separati di 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 è assestato su 9 o 15. Questi due gruppi indicano due strategie tipiche: in alcune esecuzioni, ha saltato il passaggio di ispezione ed è passato direttamente al parsing e alla sintesi (9 strumenti), mentre in altre ha ispezionato prima ciascuna colonna prima dell'elaborazione (15 strumenti). L'identità di esecutore lineare di LangChain è emersa chiaramente qui: non ha mostrato né l'efficienza parallela di AutoGen né il caos da monologo di CrewAI.

Gestione dei dati non strutturati e architettura dei 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 ciclo interno:

I framework in grado di effettuare chiamate a strumenti in parallelo (AutoGen) possono elaborare colonne di dati indipendenti in un unico passaggio. Negli 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 passaggi completati accumulati nella cronologia.

I framework basati su monologo (CrewAI) sono profondamente capaci di comprendere il tipo e il significato dei dati, ma questa profondità a volte si trasforma in domande eccessive e loop.

I framework a esecuzione lineare (LangChain) elaborano separatamente i diversi rami dei dati non strutturati, producendo un risultato intermedio tra i due mondi.

Crescita delle stelle GitHub dei framework agentici

Confronta i framework di IA agentica

I framework di IA agentica variano su 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 di agenti.

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 di IA tra 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, il che lo rende particolarmente utile per scenari di ricerca e prototipazione in cui il comportamento degli agenti richiede sperimentazione o perfezionamento iterativo.

CrewAI

CrewAI gestisce per te la maggior parte della logica di basso livello e fornisce orchestrazione multi-agente:

• Si integra con strumenti di monitoraggio per tracciamento e debug
• Controllo dell'esecuzione integrato tramite Flows con logica condizionale, loop e gestione dello stato
• Supporta il coordinamento multi-agente gerarchico (manager-lavoratore) e strutturato

OpenAI Swarm

Swarm è un framework multi-agente leggero e sperimentale per la prototipazione. Gli agenti lavorano in sequenza tramite passaggi di consegna, 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 single-agent con strumenti RAG. Fornisce componenti modulari tra cui catene, strumenti, memoria e recupero per flussi di lavoro di elaborazione documentale.

LangChain opera principalmente tramite modelli di esecuzione a singolo agente in cui un agente gestisce il flusso di lavoro.

Definizione di agenti e funzioni

LangGraph

LangGraph adotta un approccio basato su grafi alla progettazione degli agenti, in cui ogni agente è rappresentato come un nodo che mantiene il proprio stato. Questi nodi sono collegati tramite un grafo orientato, consentendo logica condizionale, coordinamento multi-team e controllo gerarchico. Questo permette di costruire e visualizzare grafi multi-agente con nodi supervisore per un'orchestrazione scalabile.

LangGraph utilizza funzioni annotate e strutturate che collegano gli strumenti agli agenti. Puoi creare nodi, collegarli a diversi supervisori e visualizzare come interagiscono i diversi team. Pensalo come dare a ciascun membro del team una descrizione dettagliata del lavoro. Questo rende più facile costruire e testare 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 opzionalmente con gli esseri umani) scambiandosi messaggi, consentendo la risoluzione collaborativa dei problemi. Come LangGraph, utilizza funzioni annotate e strutturate.

CrewAI

CrewAI adotta un approccio di progettazione basata su ruoli. A ogni agente viene assegnato un ruolo (ad es. Researcher, Developer) 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 delle funzioni. Non dispone di orchestrazione formale né di modelli di stato, basandosi invece su flussi di lavoro strutturati manualmente. Il comportamento delle funzioni è dedotto dal LLM attraverso le docstring (Swarm identifica cosa fa una funzione 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 integrata tra agenti.

Memoria

Capacità di memoria:

• Con stato: se il framework supporta memoria persistente tra le esecuzioni.
• Contestuale: se supporta la memoria a breve termine tramite cronologia dei messaggi o passaggio di contesto.

Le funzionalità di memoria sono 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 le preferenze degli utenti o la cronologia dei task.
• Memoria delle entità: traccia e aggiorna la conoscenza di oggetti, persone o concetti specifici menzionati durante le interazioni (ad es. ricordare il nome di un'azienda o un ID di 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. Questo fornisce un controllo flessibile su come la memoria viene delimitata e mantenuta 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 di memoria viene attivata automaticamente quando memory=True è abilitato,

OpenAI Swarm

Swarm è stateless e non gestisce la memoria nativamente. Gli sviluppatori possono passare manualmente la memoria a breve termine tramite context_variables e, opzionalmente, integrare strumenti esterni o livelli di memoria di terze parti (ad es. mem0) per memorizzare il contesto a lungo termine.

LangChain

LangChain supporta sia la memoria a breve termine che quella a lungo termine tramite componenti flessibili. La memoria a breve termine è generalmente gestita tramite buffer in-memory che tracciano la cronologia delle conversazioni all'interno di una sessione. Per la memoria a lungo termine, LangChain si integra con vector store esterni o database per persistere embedding e dati di retrieval.

Gli sviluppatori possono personalizzare ambiti e strategie di memoria utilizzando le classi di memoria integrate, consentendo una gestione efficiente della memoria contestuale e specifica delle entità tra le interazioni.

Intervento umano nel ciclo

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 tra agenti.

CrewAI:

CrewAI abilita il feedback dopo ogni task impostando human_input=True; l'agente si ferma 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 revisione, feedback o intervento manuale in punti definiti del flusso di lavoro.

Integrazione del Model Context Protocol (MCP) nei framework di IA agentica

Gli agenti IA devono interagire con strumenti esterni come database, API, file system e applicazioni aziendali. Senza uno standard, ogni framework doveva costruire 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 tramite un'unica interfaccia.

Come ciascun 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 tramite il suo modulo di estensione. Gli sviluppatori possono connettersi ai server MCP e rendere tutti i loro strumenti disponibili agli agenti AutoGen con poche righe di codice.

CrewAI
Gli agenti CrewAI possono fare direttamente riferimento 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 estrarre strumenti da varie fonti e di integrarli in catene, agenti e altri componenti LangChain senza wrapper personalizzati.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Cosa fanno realmente i framework di IA agentica?

I framework di IA agentica assistono nel prompt engineering e nella gestione di come i dati fluiscono da e verso gli LLM. A livello di base, aiutano a strutturare i prompt affinché il LLM risponda in un formato prevedibile e instradino le risposte allo strumento, all'API o al documento giusto.

Se si costruisse da zero, bisognerebbe definire manualmente il prompt, estrarre lo strumento che il LLM vuole usare e attivare la corrispondente chiamata API. I framework semplificano questo processo:

• Orchestrazione dei prompt: creare, gestire e instradare prompt complessi verso gli 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 a lungo termine)
• Integrazione RAG: consentire il recupero di conoscenza da fonti esterne
• Coordinamento multi-agente: strutturare il modo in cui gli agenti collaborano o delegano i task

Framework di IA agentica: casi d'uso reali

LangGraph – Pianificatore di viaggio multi-agente

Un progetto di produzione realizzato con LangGraph dimostra un assistente di viaggio multi-agente stateful che recupera dati su voli e hotel (utilizzando le Google Flights & Hotels API) e genera raccomandazioni di viaggio.³

CrewAI – Creatore di contenuti agentici

Il repository di esempi ufficiali di CrewAI include flussi come pianificazione di viaggi, strategia di marketing, analisi azionaria e assistenti al reclutamento, in cui agenti con ruoli specifici (ad es. “Researcher”, “Writer”) collaborano su task.⁴

CrewAI trasforma un brief di contenuti di alto livello in un articolo completo utilizzando Groq.

Funzionalità principali dei framework di IA agentica

Supporto dei modelli:

• La maggior parte sono model-agnostic, supportando più fornitori di LLM (ad es. OpenAI, Anthropic, modelli open-source).
• Tuttavia, le strutture dei prompt di sistema variano a seconda del framework e possono funzionare meglio con alcuni modelli rispetto ad altri.
• L'accesso e la personalizzazione dei prompt di sistema sono spesso essenziali per ottenere risultati ottimali.

Strumenti:

• Tutti i framework supportano l'uso degli 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 tra i passaggi o le chiamate al LLM.
• Alcuni aiutano gli agenti a conservare interazioni o contesto precedenti all'interno di una sessione.

RAG (Retrieval-Augmented Generation):

• La maggior parte include opzioni di configurazione semplici per RAG, integrando database vettoriali o archivi documentali.
• Ciò consente agli agenti di fare riferimento a conoscenze esterne durante l'esecuzione.

Altre funzionalità comuni

• Supporto per l'esecuzione asincrona, che consente chiamate concorrenti a agenti o strumenti.
• Gestione integrata per output strutturati (ad es. 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 una singola chiamata a uno strumento può essere effettuata con il parametro corretto. L'overhead dell'infrastruttura di base del framework emerge più chiaramente in questo scenario semplice.

Task 2: richiede di mantenere in memoria i risultati di due gruppi di filtri separati e combinarli in un unico output. Vengono testate la gestione dello stato e il coordinamento multi-segmento.

Task 3: misura se le condizioni numeriche espresse in linguaggio naturale vengono tradotte in parametri per gli strumenti senza distorsioni. Il vero test è se i meccanismi di retry e re-prompt del framework possono preservare questi parametri.

Task 4: uno strumento lancia errori Network, Timeout e RateLimit in successione. Si misura se il framework cambia strategia di fronte a questi errori.

Task 5: l'agente deve prima scoprire 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 si presenta concretamente un task

Per rendere concreta la configurazione, ecco il Task 5, il task più complesso del benchmark dei framework di IA agentica. Ogni framework ha ricevuto lo stesso identico prompt e lo stesso identico insieme di strumenti; cambiava solo il framework che avvolgeva il LLM.

Prompt fornito all'agente:

Analizza i clienti che hanno abbandonato (Churn='Yes') che pagano più di 100 in MonthlyCharges.

1. Filtra il dataset per Churn='Yes'.
2. Ispeziona le colonne 'Metadata' e 'SupportNotes' per scoprire i loro tipi di dati.
3. Estrai la distribuzione di 'device_type' dalla colonna JSON 'Metadata'.
4. Conta le parole chiave dei reclami dalla colonna di testo gratuito 'SupportNotes'.
   Restituisci il risultato solo come JSON.

Output JSON richiesto:

Perché questo task distingue i framework: l'agente deve pianificare una catena di quattro chiamate a strumenti, mantenere il segmento filtrato nello stato durante ogni chiamata e riconoscere che una colonna è JSON mentre l'altra è testo gratuito. 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 passaggi 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 di framework e 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 loop instabile dello strumento; e 20 per il Task 5 a causa della catena di scoperta a 4 passaggi.

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  = {{I 5 migliori framework open-source di IA agentica}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/agentic-frameworks}},
  note   = {AIMultiple. Consultato il 10 Agosto 2026}
}

Registro delle modifiche

10 aggiornamenti

Tutte10Generale9Metodologia1

1. 20262 Mar

   Sostituiti i risultati e l'analisi del benchmark nella sezione "Agentic AI frameworks benchmark".

2. 22 Gen

   Rimossa una modifica metodologica che descriveva come le attività venivano integrate nelle architetture basate su agenti.

3. 20257 Nov

   Espansa la sezione "Agentic frameworks benchmark" con un elenco di framework benchmarkati.

4. 11 Ott

   Aggiunto un disclaimer ai dati della sezione "Classifica generale".

5. 8 Ott

   Aggiornati i dati dei risultati nella sezione "Risultati".

6. 7 Ott

   Rimossa la sezione 'Agentic frameworks benchmark'.

7. 16 Lug

   Espansa la sezione del benchmark dei framework agentici con una spiegazione dettagliata delle differenze nell'utilizzo dei token.

8. 8 Lug

   Espansa la sezione "Agentic Frameworks Benchmark: CrewAI vs LangChain" per includere OpenAI Swarm e LangGraph.

9. 30 Giu

   Aggiunto un benchmark che confronta CrewAI e LangChain all'introduzione.

10. 30 Giu

    Aggiunta una metodologia di benchmark alla sezione metodologia.

Collegamenti di riferimento

1.

Top 5 Frameworks for Building AI Agents in 2024 (Plus 1 Bonus) - DEV Community

DEV Community

2.

Agentic AI and Automation - by Sasha Pasmanik

Stay Curious

3.

Automate Your Travel Plans with Multi-Agent AI & LangGraph | by Jalaj Agrawal | Medium

Medium

4.

CrewAI Documentation - CrewAI

Mintlify

Cem Dilmegani

Analista principale

Segui

Cem è analista principale presso AIMultiple dal 2017.

Il lavoro di Cem presso AIMultiple è stato citato da importanti testate internazionali tra cui Business Insider, Forbes, Morning Brew e Washington Post, da aziende globali come Deloitte e HPE, da ONG come il World Economic Forum e da organizzazioni sovranazionali come la Commissione europea. [1], [2], [3], [4], [5]

Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, acquirente tecnologico e imprenditore tecnologico. Ha consigliato le aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per più di un decennio. Ha inoltre pubblicato un report McKinsey sulla digitalizzazione.

Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto ricavi ricorrenti annuali a 7 cifre e una valutazione a 9 cifre partendo da zero in 2 anni. Il lavoro di Cem in Hypatos è stato ripreso da importanti testate tecnologiche come TechCrunch e Business Insider.

Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato come ingegnere informatico presso l'Università di Bogazici e possiede un MBA della Columbia Business School.

Visualizza il profilo completo

Ricercato da

Nazlı Şipi

Ricercatrice AI

Segui

Nazlı è un'analista di dati presso AIMultiple. Ha esperienza pregressa nell'analisi dei dati in diversi settori, dove ha lavorato alla trasformazione di dataset complessi in insight attuabili.

Visualizza il profilo completo

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.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento

Chaitanya

Dec 19, 2025 at 01:47

Thank you for this informative and detailed article! It helped me get a reading on these frameworks.

Rispondere