Servizi
Contattaci

I 5 migliori framework agentici IA open-source

Cem Dilmegani
Cem Dilmegani
aggiornato il 6 lug. 2026

Abbiamo confrontato 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.

Confronto tra framework di IA agentica

Abbiamo esaminato come i framework stessi influenzano il comportamento dell'agente e l'impatto risultante sulla latenza e sul consumo di token.

Loading Chart

LangGraph è il framework più veloce con i valori di latenza più bassi in tutti i task, mentre LangChain ha la latenza e l'utilizzo 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 nella latenza; LangGraph e LangChain seguono da vicino. CrewAI mostra il profilo complessivo più pesante.

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

Task 1: Aggregazione di base

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

LangChain e LangGraph: Per compiti semplici, sono veloci quasi quanto il 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 aggiuntiva rispetto a LangChain a questo livello di semplicità; l'overhead della gestione dello stato si manifesta con l'aumentare della complessità del task.

AutoGen: Si colloca leggermente al di sopra di LangChain e LangGraph sia per latenza che per utilizzo di token, riflettendo il costo di base del suo ciclo di conversazione multi-agente, con due agenti che si scambiano messaggi anche per un task a singolo passo.

CrewAI: Anche quando gli viene richiesto di fare 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 a più passi tra i suoi ruoli di Pianificatore e Analista offre un approccio approfondito ma ad alta intensità 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 vedere la capacità dei framework di mantenere in memoria due diversi gruppi di filtri (persistenza dello stato) e combinarli.

CrewAI

Dall'analisi dei log, abbiamo rilevato che CrewAI offre il più alto livello di trasparenza infrastrutturale tra i framework, ma al costo del più alto 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 a più livelli nel prompt di sistema, assegnando a ogni agente un ruolo, un obiettivo e una storia passata, imponendo al contempo un ciclo di tipo ReAct Pensiero → Azione → Osservazione a ogni passo. Anche per compiti 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 oltre tre volte il tempo di LangChain, risultando più adatto a transizioni di stato complesse e a processi decisionali multifattoriali piuttosto che a compiti di recupero dati lineari.

LangChain

Il framework più veloce ed economico. Dai log, abbiamo osservato che LangChain completa il task in 5-6 passi senza deviazioni: Carica → Filtra → Calcola → Filtra → Calcola → Output. Poiché la 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 aggrava in modo significativo quando la catena di task rimane lineare.

Tuttavia, occasionalmente aggiunge un ulteriore passo di verifica 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 suo ragionamento al 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 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. Su tutte le 100 esecuzioni, ha prodotto risultati con un numero quasi identico di passi e un intervallo di latenza simile.

Task 3: Analisi delle soglie (disciplina numerica)

In questo task, volevamo vedere con quanta precisione i framework traducono le condizioni numeriche in linguaggio naturale, come "meno di 1 anno di anzianità" e "più di $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 realmente testare era se il framework può 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 il LLM li aveva prodotti, 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 interferenze da parte del framework, questi due hanno soddisfatto le nostre aspettative: qualsiasi parametro fosse stato generato, è stato eseguito.

AutoGen

AutoGen ha pieno successo nella correttezza numerica. In alcune esecuzioni, è stato 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 extra pur 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 pattern 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 aveva inizialmente prodotto i parametri corretti, tenure_max=12 e charges_min=70. Tuttavia, una volta che CrewAI è entrato in un ciclo di "Analisi fallita", 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 prodotto correttamente.

Task 4: Resilienza agli errori e capacità di cambiare strategia

In questo task, volevamo vedere come ciascun framework gestisce scenari di disturbo e osservare l'impatto sulla latenza e sul consumo di token. Lo strumento genera 3 diversi tipi di errore in successione (Rete, Timeout, Limite di frequenza), mettendo l'agente alle strette. I primi due errori istruiscono l'agente a riprovare, e dopo aver riprovato entrambi, l'errore di Limite di frequenza 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 fallimenti degli strumenti in questo task.

Quando lo strumento ha restituito un avviso di limite di frequenza, invece di fermarsi e attendere, questi agenti hanno deciso di abbandonare del tutto lo strumento in errore e di 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 svolgere il compito con una singola chiamata a uno strumento, lo hanno scomposto utilizzando due strumenti separati, uno per il filtraggio e uno per il calcolo, elaborando individualmente ciascun MetodoDiPagamento (Bonifico elettronico, Assegno postale, 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 nel giro di secondi.

LangGraph ha raggiunto 15.010 token di prompt nel Task 4, il più alto conteggio di token per singolo task in tutto il benchmark, perché la sua macchina a stati accumulava la cronologia crescente di ogni chiamata manuale agli strumenti reinserendola 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 intorno ai 24-27 secondi, confermando che il costo aggiuntivo in token non si è tradotto in una latenza significativa perché il cambio di strategia è stato rapido.

CrewAI

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

Perché il più basso utilizzo di token?

CrewAI non ha eseguito una soluzione manuale da 10-15 passi come i suoi concorrenti. Quando incontrava 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 verbosità inutili, è diventato il framework più economico in questo task.

Perché alta latenza?

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 recupero dello strumento principale o di riprovare 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.

Nell'esecuzione iniziale, LangChain si arrestava in modo anomalo a ogni singolo tentativo con un ConnectionError.

L'AgentExecutor predefinito di LangChain tratta le eccezioni Python grezze generate da uno strumento come errori fatali e termina il processo. A differenza dei suoi concorrenti, non applica per impostazione predefinita 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 poteva elaborare.

Comportamento post-correzione: Dopo aver applicato la correzione, abbiamo osservato nei log di LangChain che ha mostrato lo stesso identico 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 individualmente ciascun metodo di pagamento 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 basato su un percorso alternativo.

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

Se il comportamento dell'agente dipendesse unicamente 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 interni di ciascun framework:

1. LangGraph e AutoGen (90% cambio strategia):

LangGraph opera su un'architettura a macchina a stati, mentre AutoGen opera 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% cambio strategia / 35% attesa):

LangChain viene eseguito 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 Risposta Finale. Se lo strumento genera errori per 3-4 passi, LangChain a volte preferisce attendere che lo strumento abbia successo 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% cambio strategia):

CrewAI opera su un'architettura a Processo Manageriale. I suoi agenti sono racchiusi in definizioni di Ruolo e Compito. Quando si verificano errori, la sua architettura interna attiva in genere una logica di Auto-Correzione o Retry. Tuttavia, un cambiamento radicale di strategia come "rifacciamo l'intero piano e facciamo il filtraggio manuale in 5 passi" è in conflitto con la struttura del piano manageriale di CrewAI. Opera con la disciplina del "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 centrato sul piano piuttosto che centrato 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 di 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.

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

1- un'intelligenza di scoperta che capisca quale strumento si adatta a quale tipo di dato

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

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

AutoGen

AutoGen ha mostrato ottime prestazioni 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.

Esaminando la cronologia della conversazione, il LLM ha riconosciuto che le colonne Metadati e NoteDiSupporto erano indipendenti l'una dall'altra. Ha quindi inviato una singola risposta CHIAMATE A STRUMENTI elencando 4 strumenti contemporaneamente: ispeziona_colonna(Metadati), ispeziona_colonna(NoteDiSupporto), analizza_colonna_json(…) e riassumi_colonna_testo(…) 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 di 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 singolo passo della conversazione. La filosofia del framework di "gestire la conversazione" consente naturalmente l'apertura di più canali paralleli contemporaneamente, e i numeri su token e latenza lo confermano direttamente.

LangGraph

LangGraph ha terminato con 9.150 token di prompt e 70 secondi di mediana, vicino ad AutoGen nel numero di token ma più lento in termini di tempo. La sua architettura a Macchina a Stati ha mostrato contemporaneamente sia il suo più grande punto di forza che la sua più evidente debolezza nel Task 5.

In ogni esecuzione, il ciclo nodo llm → nodo strumenti → 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 che l'analisi era completa, rilevava ambiguità nello stato accumulato, interpretando i passi completati come ancora in sospeso, e attivava ripetutamente chiamate aggiuntive agli strumenti. Anche se aveva recuperato i dati necessari e stava per produrre la risposta corretta, si attivava il segnale di "passo mancante" della macchina a stati e l'agente entrava 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 faceva apparire i passi completati come incompleti, trascinando l'agente in cicli ridondanti e portando la latenza 23 secondi al di sopra di AutoGen nonostante un numero di token paragonabile.

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 a strumenti, senza deviazioni, eseguendo come uno script. In queste esecuzioni, la struttura manageriale definita da ruoli e compiti di CrewAI ha funzionato esattamente come previsto: quando l'agente capiva chiaramente il suo ruolo, si comportava in modo prevedibile e disciplinato.

Tuttavia, in altre esecuzioni (ad es., esecuzione 16: 35 chiamate a strumenti), ne è seguito il caos completo. La causa principale era il monologo interno (Pensiero) che CrewAI genera a ogni passo. Dopo aver costruito correttamente il segmento con il filtro giusto, il monologo interno dell'agente iniziava a chiedersi se dovessero essere applicati anche filtri aggiuntivi. Dopo aver visto il risultato, dubitava che il segmento attuale fosse valido o che quello precedente dovesse avere la precedenza. Questo dubbio lo spingeva a ricaricare i dati da zero. Poi filtrava di nuovo, entrava in un altro ciclo di verifica, dubitava di nuovo e ripeteva 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, spingeva l'agente a rimettere in discussione le proprie decisioni corrette.

LangChain

La struttura AgentExecutor di LangChain è intrinsecamente sequenziale, e il Task 5 è dove tale vincolo è stato più evidente. A 10.070 token di prompt e 86 secondi di mediana, è stato il framework più lento in questo task nonostante non avesse il numero più alto di token.

Effettua una singola chiamata a uno strumento a ogni passo, riceve il risultato, poi 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 contro gli 86 secondi di LangChain è una misura diretta del costo dell'esecuzione sequenziale rispetto a quella parallela.

Nel Task 5, il numero di strumenti di LangChain si è attestato su 9 o 15. Questi due gruppi indicano due strategie tipiche: in alcune esecuzioni, ha saltato la fase di ispezione ed è passato direttamente all'analisi e al riassunto (9 strumenti), mentre in altre ha ispezionato prima ogni 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 è in grado di gestire dati non strutturati (JSON, LongText) è direttamente legata al suo meccanismo di ciclo interno:

I framework in grado di effettuare chiamate parallele agli strumenti (AutoGen) possono elaborare colonne di dati indipendenti in un unico passo. 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 passi completati accumulati nella cronologia.

I framework basati sul monologo (CrewAI) sono profondamente in grado di comprendere il tipo e il significato dei dati, ma questa profondità a volte si trasforma in un eccessivo interrogarsi e in cicli.

I framework a esecuzione lineare (LangChain) elaborano separatamente i diversi rami dei dati non strutturati, producendo un risultato intermedio da entrambi i 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

Framework LangGraph

LangGraph è un framework relativamente noto e si distingue come un'opzione chiave per gli sviluppatori che costruiscono sistemi ad agenti.

Coordinamento multi-agente esplicito: È possibile modellare più agenti come nodi o gruppi individuali, 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

Framework AutoGen1

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 affinamento iterativo.

CrewAI

Crew IA2

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

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

OpenAI Swarm

Framework Swarm

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

LangChain opera principalmente attraverso pattern di esecuzione ad agente singolo 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 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 i diversi team interagiscono. È come dare a ciascun membro del team una descrizione dettagliata del lavoro. Questo facilita la creazione e il test di agenti che collaborano.

AutoGen

AutoGen definisce gli agenti come unità adattive capaci di instradamento flessibile e comunicazione asincrona. Gli agenti interagiscono tra loro (e opzionalmente 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 sui ruoli. A ogni agente viene assegnato un ruolo (ad es., 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 delle funzioni. Non dispone di orchestrazione formale o 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 leggendone la 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 attraverso interfacce esplicite come toolkit e modelli 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 memoria persistente tra le esecuzioni.
  • Contestuale: Se supporta memoria a breve termine tramite cronologia dei messaggi o passaggio di contesto.

Le funzionalità di memoria sono una parte fondamentale della 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 dell'utente o la cronologia delle attività.
  • Memoria di entità: Tiene traccia e aggiorna le conoscenze su oggetti, persone o concetti specifici menzionati durante le interazioni (ad es., 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 una singola attività o conversazione, e memoria cross-thread, che salva i dati tra le sessioni. Gli sviluppatori possono usare MemorySaver per salvare il flusso di un'attività 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 attraverso un oggetto context_variables, che memorizza la cronologia delle interazioni. Non dispone di memoria persistente integrata.

CrewAI

CrewAI fornisce memoria a più livelli già pronta all'uso. Memorizza la memoria a breve termine in un vector store ChromaDB, i risultati delle attività recenti in SQLite e la memoria a lungo termine in una tabella SQLite separata (basata sulle descrizioni delle attività). Inoltre, supporta la memoria di entità utilizzando embedding vettoriali. Questa configurazione di memoria viene configurata automaticamente quando memory=True è abilitato,

OpenAI Swarm

Swarm è senza stato e non gestisce la memoria in modo nativo. Gli sviluppatori possono passare manualmente la memoria a breve termine attraverso context_variables e, opzionalmente, integrare strumenti esterni o livelli di memoria di terze parti (ad es., 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 è generalmente gestita tramite buffer in memoria che tengono traccia della cronologia delle conversazioni 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 l'ambito e le strategie di memoria utilizzando le classi di memoria integrate, consentendo una gestione efficiente della memoria contestuale e specifica dell'entità attraverso le interazioni.

Lascia che il nostro team automatizzi uno dei tuoi processi aziendali con agenti IA, gratuitamente.
Automatizza un processo

Human-in-the-loop

LangGraph

LangGraph supporta punti di interruzione personalizzabili (interrupt_before) per mettere in pausa il grafo e attendere l'input dell'utente durante l'esecuzione.

AutoGen

AutoGen supporta nativamente agenti umani tramite UserProxyAgent, consentendo agli umani di rivedere, approvare o modificare i passi durante la collaborazione tra agenti.

CrewAI:

CrewAI abilita il feedback dopo ogni attività 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 punti di interruzione personalizzati all'interno di catene o agenti per mettere in pausa l'esecuzione e richiedere input umano. Questo supporta la revisione, il feedback o l'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 attraverso un'unica interfaccia.

Come ciascun framework si integra con MCP

LangGraph
LangGraph si connette ai server MCP tramite un adattatore che rileva 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 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 MCP nativo di OpenAI 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 a strumenti MCP in cui le funzioni Python fungono da ponte verso i server MCP. Ciò consente di estrarre strumenti da varie fonti e integrarli in catene, agenti e altri componenti di 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.
GoogleAggiungi come fonte preferita

Cosa fanno realmente i framework di IA agentica?

I framework di IA agentica assistono nell'ingegnerizzazione dei prompt e nella gestione del flusso di dati verso e dai 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, alla API o al documento corretto.

Se si costruisce 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 tutto questo:

  • Orchestrazione dei prompt: Costruzione, gestione e instradamento di prompt complessi verso i LLM
  • Integrazione di strumenti: Consentire agli agenti di chiamare API esterne, database, funzioni di codice, ecc.
  • Memoria: Mantenimento dello stato attraverso i turni o le sessioni (a breve e lungo termine)
  • Integrazione RAG: Abilitazione del recupero di conoscenze da fonti esterne
  • Coordinamento multi-agente: Strutturazione del modo in cui gli agenti collaborano o delegano i compiti
Framework agentico3

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 con stato che recupera dati di voli e hotel (utilizzando le API di Google Flights e Hotels) e genera raccomandazioni di viaggio.4

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 di reclutamento, in cui agenti specifici per ruolo (ad es., "Ricercatore", "Scrittore") collaborano sui compiti.5

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

Caratteristiche principali dei framework di IA agentica

Supporto dei modelli:

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

Strumenti:

  • 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 Model-Context-Protocol (MCP), nativamente o tramite estensioni della comunità.

Memoria / Stato:

  • Utilizzano il tracciamento dello stato per mantenere la memoria a breve termine tra i passi o le chiamate al LLM.
  • Alcuni aiutano gli agenti a conservare le interazioni o il contesto precedenti all'interno di una sessione.

RAG (Generazione Aumentata da Recupero):

  • La maggior parte include opzioni di facile configurazione per il RAG, integrando database vettoriali o archivi documentali.
  • 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 es., JSON).
  • Supporto per output in streaming dove 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 del task

Task 1: Misura se è possibile effettuare una singola chiamata a uno strumento con il parametro corretto. L'overhead dell'infrastruttura di base del framework è rivelato più chiaramente in questo scenario semplice.

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 il coordinamento 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 errori di Rete, Timeout e Limite di frequenza in successione. Viene misurato 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 strumenti indipendenti in parallelo o in sequenza.

Come si presenta realmente un task

Per rendere concreta la configurazione, ecco il Task 5, il task più complesso nel benchmark dei framework di IA agentica. Ogni framework ha ricevuto lo stesso prompt e lo stesso insieme di strumenti; è cambiato solo il framework che avvolge 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 'device_type' dalla colonna JSON 'Metadata'.
  4. Conta le parole chiave dei reclami 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 a 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 cicli non necessari. 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 ogni agente sono stati forniti gli stessi strumenti e gli stessi prompt. Ciascun framework è stato impostato 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 ciascuna 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 strumenti instabili; e 20 per il Task 5 a causa della catena di scoperta a 4 passi.

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

Cem Dilmegani and Nazlı Şipi (2026) - "I 5 migliori framework agentici IA open-source". Pubblicato online su AIMultiple.com. Consultato il 6 Luglio 2026, da: https://aimultiple.com/agentic-frameworks [Risorsa online]

Dilmegani, C., & Şipi, N. (2026, 6 Luglio). I 5 migliori framework agentici IA open-source. AIMultiple. https://aimultiple.com/agentic-frameworks

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Şipi, Nazlı},
  title  = {{I 5 migliori framework agentici IA open-source}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/agentic-frameworks}},
  note   = {AIMultiple. Consultato il 6 Luglio 2026}
}
Cem Dilmegani
Cem Dilmegani
Analista principale
Cem è analista principale presso AIMultiple dal 2017. AIMultiple fornisce informazioni a centinaia di migliaia di aziende (secondo SimilarWeb), tra cui il 55% delle aziende Fortune 500, ogni mese. Il lavoro di Cem è stato citato da importanti pubblicazioni globali come Business Insider, Forbes, Washington Post, società globali come Deloitte e HPE, ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione Europea. È possibile consultare l'elenco di altre aziende e risorse autorevoli che hanno citato AIMultiple. Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, responsabile acquisti tecnologici e imprenditore nel settore tecnologico. Ha fornito consulenza alle aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un report di McKinsey sulla digitalizzazione. Ha guidato la strategia tecnologica e gli acquisti di un'azienda di telecomunicazioni, riportando direttamente al CEO. Ha inoltre 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 zero in soli 2 anni. Il lavoro di Cem in Hypatos è stato oggetto di articoli su importanti pubblicazioni tecnologiche come TechCrunch e Business Insider. Cem partecipa regolarmente come relatore a conferenze internazionali di settore. Si è laureato in ingegneria informatica presso l'Università di Bogazici e ha conseguito un MBA presso la Columbia Business School.
Visualizza il profilo completo
Ricercato da
Nazlı Şipi
Nazlı Şipi
Ricercatore AI
Nazlı è un'analista di dati presso AIMultiple. Ha precedente esperienza nell'analisi dei dati in vari settori, dove ha lavorato per trasformare insiemi di dati complessi in informazioni utili.
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.

0/450
Chaitanya
Chaitanya
Dec 19, 2025 at 01:47

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