I 5 migliori framework open-source per l'IA agentica nel 2026
Abbiamo effettuato un benchmark di 4 popolari framework open-source per agenti, eseguendo 2.000 test (5 attività, 100 test ciascuna per framework), misurando la latenza end-to-end, il consumo di token e le differenze architetturali.
benchmark dei framework di IA agentiva
Abbiamo esaminato come i framework stessi influenzino il comportamento degli agenti e il conseguente impatto sulla latenza e sul consumo di token.
LangGraph è il framework più veloce con i valori di latenza più bassi in tutte le attività, mentre LangChain presenta la latenza e l'utilizzo di token più elevati.
Su 5 attività e 2.000 esecuzioni, LangChain si rivela il framework più efficiente in termini di token, mentre AutoGen primeggia in termini di latenza; LangGraph e LangChain lo seguono a breve distanza. CrewAI presenta il profilo complessivo più pesante.
Qui potete consultare la nostra metodologia in dettaglio.
Attività 1: Aggregazione di base
Innanzitutto, abbiamo misurato il sovraccarico di ciascun framework semplicemente richiamando un singolo strumento e restituendo il risultato, senza eseguire alcun ragionamento complesso.
LangChain e LangGraph: per compiti semplici, le loro prestazioni sono quasi pari a quelle del codice non agente, con entrambi i sistemi che terminano in meno di 5 secondi e con meno di 900 token di richiesta. L'architettura a stati finiti di LangGraph non introduce latenza apprezzabile rispetto a LangChain a questo livello di semplicità; il sovraccarico dovuto alla gestione dello stato si manifesta solo con l'aumentare della complessità del compito.
AutoGen: Si posiziona leggermente al di sopra di LangChain e LangGraph sia in termini di latenza che di utilizzo dei token, a causa del costo di base del suo ciclo di conversazione multi-agente, in cui due agenti si scambiano messaggi anche per un'attività a singolo passaggio.
CrewAI: Anche quando gli viene richiesto di effettuare una singola chiamata a uno strumento, mostra quello che potremmo definire un "overhead gestionale", consumando quasi il triplo dei token di LangChain e impiegando quasi il triplo del tempo. Il processo di verifica in più fasi tra le sue personalità Planner e Analyst offre un approccio accurato ma ad alta intensità di risorse, che privilegia la completezza rispetto alla velocità. Questo costo è strutturale: si manifesta indipendentemente dalla complessità dell'attività.
Compito 2: Analisi comparativa delle entrate (gestione statale)
Nel compito 2, volevamo verificare la capacità dei framework di mantenere in memoria due diversi gruppi di filtri (persistenza dello stato) e di combinarli.
CrewAI
Dalla nostra analisi dei log, abbiamo scoperto che CrewAI offre il livello più elevato di trasparenza dell'infrastruttura tra i framework, ma a costo del maggior consumo di risorse.
Invece di restituire immediatamente i dati recuperati, CrewAI convalida ripetutamente i propri processi attraverso un meccanismo di auto-verifica. Questo comportamento esplorativo ha portato al 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 del sistema, assegnando a ciascun agente un ruolo, un obiettivo e un retroscena, imponendo al contempo un ciclo Pensiero → Azione → Osservazione in stile ReAct a ogni passaggio. Persino per compiti semplici, il LLM non può saltare questa cerimonia e produce diligentemente prolissi monologhi interni, che si amplificano ulteriormente negli scenari multi-agente.
CrewAI ha consumato quasi il doppio dei token rispetto agli altri framework e ha impiegato oltre tre volte il tempo di LangChain, risultando quindi più adatto a transizioni di stato complesse e processi decisionali multifattoriali piuttosto che a semplici attività di recupero dati.
LangChain
Il framework più veloce ed economico. Dai nostri log abbiamo osservato che LangChain completa l'attività in 5-6 passaggi senza alcuna deviazione: Caricamento → Filtro → Calcolo → Filtro → Calcolo → Output. Poiché la sua gestione dello stato è molto semplice, l'overhead è pressoché 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 nell'utilizzo dei token che nella latenza, dimostrando che l'overhead del ciclo di conversazione non si accumula in modo significativo quando la catena di attività rimane lineare.
Tuttavia, occasionalmente aggiunge un ulteriore passaggio di verifica per confermare i parametri durante il processo di chiamata dello strumento, risultando leggermente più lento di LangChain. Quando incontra un errore in una chiamata dello strumento o i dati non vengono restituiti come previsto, aggiorna immediatamente il suo ragionamento nel passaggio successivo e arriva al JSON corretto. Poiché gestisce gli output degli strumenti come un flusso conversazionale, è uno dei framework più resilienti agli errori logici.
LangGraph
In questo compito, LangGraph si è dimostrato il framework più stabile grazie alla sua architettura basata sui grafi. Dai log abbiamo osservato che lo stato viene gestito in modo molto pulito durante l'esecuzione. Il rischio di contaminazione dei dati o di interferenze tra i segmenti è minimo in questo framework. Su tutte le 100 esecuzioni, ha prodotto risultati con un numero di passaggi pressoché identico e con una latenza pressoché costante.
Compito 3: Analisi sintattica di soglia (disciplina numerica)
In questo compito, volevamo verificare con quale precisione i framework traducono le condizioni numeriche espresse in linguaggio naturale, come "meno di 1 anno di anzianità" e "più di 70 dollari di spese mensili", in parametri precisi per gli strumenti, come tenure_max=12 e charges_min=70.0.
L'LLM sa già come effettuare questa conversione; ciò che volevamo realmente testare era se il framework fosse in grado di proteggere questi parametri attraverso i propri meccanismi di ritentativo, il contesto di richiesta di input 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 aveva generati l'LLM, senza alcuna modifica o ciclo di richiesta. Questa efficienza si riflette nei numeri: entrambi i framework hanno completato l'Attività 3 in meno di 9 secondi con meno di 1.800 token di richiesta, il numero più basso in questa attività.
Quando abbiamo voluto verificare se le soglie numeriche venissero preservate senza interferenze da parte del framework, questi due test hanno soddisfatto le nostre aspettative: qualunque parametro venisse generato, quello veniva effettivamente eseguito.
AutoGen
Autogen ha dimostrato piena accuratezza numerica. In alcune esecuzioni, è stato osservato che il framework aggiungeva una fase di verifica prima di passare il parametro generato da LLM allo strumento, il che significa che il framework impiegava un passaggio aggiuntivo per preservare il parametro. Con 2.480 token e 8 secondi, la latenza è risultata in linea con quella di LangChain, nonostante il passaggio aggiuntivo, confermando che l'overhead di verifica è reale ma ridotto. Ha soddisfatto le nostre aspettative in termini di integrità dei parametri, con la fase di conferma che introduceva solo un costo marginale in termini di token anziché una significativa penalità di latenza.
CrewAI
Il comportamento più notevole è stato osservato in CrewAI, che ha completato il Task 3 in 30 secondi con 4.360 token, il numero più alto in questo compito. Dall'analisi dei log sono emersi due distinti modelli di errore.
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ò estrarre l'output del LLM dal suo contesto originale.
I log mostrano che inizialmente l'LLM ha prodotto i parametri corretti, tenure_max=12 e charges_min=70. Tuttavia, una volta che CrewAI è entrato in un ciclo "Failed to parse", il framework ha spinto l'LLM a riconsiderare la situazione. Nel contesto di re-prompt, l'LLM ha spostato la soglia a tenure_max=14 e ha disabilitato completamente il filtro charges_min, producendo un tasso di abbandono del 46,84%, che corrisponde effettivamente al tasso di abbandono di tutti i clienti con un'anzianità inferiore a 14. Questo era esattamente lo scenario che volevamo osservare: il meccanismo di retry del framework può corrompere un parametro che l'LLM aveva già calcolato correttamente.
Compito 4: Resilienza agli errori e capacità di adattamento
In questo compito, volevamo vedere come ogni framework gestisce gli scenari di interruzione e osservare l'impatto sulla latenza e sul consumo di token. Lo strumento genera 3 diversi tipi di errori in successione (Rete, Timeout, Limite di frequenza), mettendo l'agente alle strette. I primi due errori indicano all'agente di riprovare e, dopo averli entrambi ritentati, l'errore relativo al Limite di frequenza gli impone di attendere 10 secondi. Una volta che l'agente attende e riprova, lo strumento inizia a funzionare normalmente.
LangGraph e Autogen
Questi due modelli hanno trovato autonomamente soluzioni alternative in caso di guasti agli strumenti durante lo svolgimento di questo compito.
Quando lo strumento ha segnalato un limite di utilizzo, invece di mettere in pausa e aspettare, questi agenti hanno deciso di abbandonare completamente lo strumento difettoso e trovare una soluzione alternativa. Il loro approccio è stato: "Dato che questo strumento non funziona, filtrerò ogni metodo di pagamento singolarmente, calcolerò il tasso di abbandono per ognuno separatamente e poi combinerò i risultati da solo".
Metodo: Invece di eseguire l'operazione con una singola chiamata di strumento, l'hanno suddivisa utilizzando due strumenti separati, uno per il filtraggio e uno per il calcolo, elaborando individualmente ciascun metodo di pagamento (assegno elettronico, assegno inviato per posta, ecc.).
Questi agenti operano con un ragionamento orientato agli obiettivi piuttosto che basato sulla dipendenza dal percorso. Se il percorso più breve non è disponibile, possono elaborare un piano di esecuzione alternativo in pochi secondi.
LangGraph ha raggiunto 15.010 token di prompt nel Task 4, il conteggio di token per singola attività più alto dell'intero benchmark, perché la sua macchina a stati ha accumulato la cronologia crescente di ogni chiamata manuale dello strumento nel contesto a ogni passaggio. AutoGen ha seguito con 10.750 token, leggermente più contenuto grazie alla sua gestione conversazionale dei risultati intermedi. Nonostante ciò, entrambi hanno completato l'operazione in circa 24-27 secondi, confermando che il costo aggiuntivo dei token non si è tradotto in una latenza significativa perché il pivot stesso era veloce.
CrewAI
Nonostante avesse mostrato il consumo di token più elevato nei compiti precedenti, CrewAI ha registrato l'utilizzo di token più basso ma i valori di latenza più elevati in questo compito.
Perché il token più basso?
CrewAI non ha utilizzato una procedura manuale in 10-15 passaggi come i suoi concorrenti. Quando si è imbattuto in errori, invece di reinserire ripetutamente l'intera cronologia e i complessi dati intermedi nel modello LLM a ogni passaggio, ha creato un ciclo di ragionamento più mirato e modulare. Evitando inutili ridondanze, è diventato il framework più efficiente in termini di costi per questo compito.
Perché una latenza elevata?
La struttura gestionale di CrewAI mette in pausa e rivaluta il piano quando incontra un errore. Quando ha ricevuto l'avviso di attesa di 10 secondi, ha dedicato più tempo alla fase di "pianificazione strategica". Inoltre, invece di passare a un altro strumento di filtraggio, ha costantemente scelto di attendere il ripristino dello strumento principale o di tentare con lo strumento stabile, il che ha allungato la durata complessiva.
LangChain
In questo compito LangChain ha subito la sua trasformazione più significativa, dimostrando perché la resilienza dipende da una configurazione adeguata.
Durante la nostra prima esecuzione, LangChain si è bloccato a ogni tentativo con un errore di connessione (ConnectionError).
L'AgentExecutor predefinito di LangChain tratta le eccezioni Python non elaborate generate all'interno di uno strumento come errori irreversibili e termina il processo. A differenza dei suoi concorrenti, non applica di default la filosofia "gli errori sono osservazioni". Poiché l'agente non vede mai l'errore, non ha la possibilità di analizzarlo.
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 successivo alla correzione: Dopo aver applicato la correzione, abbiamo osservato nei log di LangChain che il suo ragionamento era esattamente lo stesso di LangGraph. Riceveva 3 errori dallo strumento, cambiava immediatamente strategia e passava a utilizzare due strumenti separati, uno per il filtraggio e uno per il calcolo, elaborava ciascun metodo di pagamento singolarmente e combinava i risultati.
LangChain è in realtà altrettanto capace e adattabile 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 percorsi alternativi.
Perché si sono verificate queste differenze? (analisi dell'architettura del framework)
Se il comportamento dell'agente dipendesse esclusivamente dall'LLM (GPT-5.2), tutti i framework avrebbero dovuto comportarsi in modo simile. Tuttavia, le evidenti differenze in questi rapporti sono radicate nei meccanismi di ciclo interni dei framework stessi:
1. LangGraph e AutoGen (pivot al 90%):
LangGraph opera su un'architettura a macchina a stati, mentre AutoGen si basa su un modello conversazionale. In entrambi i sistemi, gli errori vengono elaborati tramite 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 si trova ripetutamente di fronte alla domanda "Ho riscontrato un errore, cosa devo fare?", la probabilità che decida di intraprendere un percorso manuale alternativo sale al 90%.
2. LangChain (65% Pivot / 35% Wait):
LangChain si basa su un'architettura AgentExecutor sequenziale. Pur essendo dotato di gestione degli errori, 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 passaggi, LangChain a volte preferisce attendere che lo strumento abbia successo al tentativo successivo o che 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 tra attesa e soluzione diretta si attesta intorno al 35%.
3. CrewAI (0% Pivot):
CrewAI opera secondo un'architettura di processo gestionale. I suoi agenti sono definiti in base a ruoli e compiti. Quando si verificano errori, la sua architettura interna attiva in genere una logica di autocorrezione o di ripetizione. Tuttavia, un cambiamento di strategia radicale come "abbandoniamo l'intero piano e procediamo con il filtraggio manuale in 5 fasi" è in conflitto con la struttura di pianificazione gestionale di CrewAI. Il sistema opera secondo la disciplina del "devo riparare lo strumento che mi è stato fornito o utilizzare l'alternativa più simile" piuttosto che abbandonare completamente il piano. Si tratta fondamentalmente di un approccio incentrato sul piano, anziché sugli obiettivi.
Attività 5: Orchestrazione di dati non strutturati (instradamento di dati non strutturati)
Nel compito 5, abbiamo osservato come si comportano i framework quando incontrano colonne JSON e di testo lungo (LongText) all'interno di un file 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 a un agente di andare oltre i dati tabellari standard e di lavorare con blob JSON, paragrafi di testo libero o oggetti annidati.
Affinché un framework possa gestire correttamente questo tipo di dati, deve svolgere bene due funzioni:
1- Un sistema di intelligenza artificiale per la scoperta di informazioni che comprende quale strumento è più adatto a ciascun tipo di dati.
2- un meccanismo di orchestrazione che coordina più chiamate di strumenti indipendenti.
Abbiamo progettato il compito 5 specificamente per misurare separatamente queste due capacità.
AutoGen
AutoGen ha ottenuto un'ottima prestazione in questo compito, completando 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, ovvero 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.
Analizzando la cronologia della conversazione, LLM ha riconosciuto che le colonne Metadata e SupportNotes erano indipendenti l'una dall'altra. Ha quindi inviato una singola risposta TOOL CALLS elencando simultaneamente 4 strumenti: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…) e summarize_text_column(…) sono stati eseguiti in parallelo. Ciò ha permesso di completare l'attività in soli 3 turni LLM, con il minor numero di token e il minor numero di passaggi.
La ragione tecnica alla base di questo comportamento è chiara: il motore di esecuzione degli strumenti di AutoGen esegue in modo atomico l'elenco tool_calls restituito da LLM e raccoglie i risultati in un singolo passaggio di conversazione. La filosofia del framework, incentrata sulla "gestione della conversazione", consente naturalmente l'apertura simultanea di più canali paralleli, come confermano direttamente i valori di token e latenza.
LangGraph
LangGraph ha completato l'esecuzione con 9.150 token di prompt e una mediana di 70 secondi, un risultato simile ad AutoGen per numero di token ma più lento in termini di tempo. La sua architettura a macchina a stati ha mostrato contemporaneamente il suo punto di forza e la sua debolezza più evidente nel Task 5.
Ad ogni esecuzione, il ciclo nodo llm → nodo strumenti → nodo llm accumula tutti gli output degli strumenti precedenti nello stato e li passa all'LLM. Questa struttura garantisce che l'agente non dimentichi mai nulla, il che di solito rappresenta un vantaggio significativo.
Tuttavia, nel Task 5 questo punto di forza si è rivelato controproducente. LangGraph individuava gli strumenti corretti e costruiva il segmento corretto. Ma anche dopo aver completato l'analisi, rilevava ambiguità nello stato accumulato, interpretando i passaggi già completati come ancora in sospeso e attivando ripetutamente ulteriori chiamate agli strumenti. Sebbene avesse già recuperato i dati necessari e stesse per produrre la risposta corretta, il segnale di "passaggio mancante" della macchina a stati si attivava e l'agente entrava in cicli inutili. Di conseguenza, il numero di chiamate agli strumenti per ogni esecuzione variava tra 6 e 16. La capacità dello stato di "non dimenticare mai nulla" a volte faceva apparire i passaggi completati come incompleti, riportando l'agente in cicli ridondanti e aumentando la latenza di 23 secondi rispetto ad AutoGen, nonostante un numero di token comparabile.
CrewAI
Le prestazioni di CrewAI nel Task 5 hanno mostrato la maggiore varianza nell'intero benchmark. In alcune esecuzioni, ha seguito una sequenza impeccabile con solo 5 chiamate di strumenti, senza deviazioni, eseguendo il tutto come uno script. In queste esecuzioni, la struttura gestionale di CrewAI, definita da ruoli e compiti, 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 esempio, esecuzione 16: 35 chiamate di strumenti), si è scatenato il caos più totale. La causa principale era il monologo interno (Pensiero) 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 dovessero essere applicati anche filtri aggiuntivi. Dopo aver visto il risultato, ha dubitato della validità del segmento corrente o se quello precedente dovesse avere la precedenza. Questo dubbio lo ha spinto a ricaricare i dati da zero. Quindi ha applicato nuovamente il filtro, è entrato in un altro ciclo di verifica, ha dubitato di nuovo e ha ripetuto questa spirale per 8 volte.
In CrewAI, ogni Pensiero produce una valutazione indipendente, e queste valutazioni a volte invalidano passaggi precedentemente verificati. Il riflesso di "verifica continua" del Processo Gestionale, 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 caso in cui tale limitazione è risultata più evidente. Con 10.070 token di prompt e una mediana di 86 secondi, è stato il framework più lento in questo task, nonostante non avesse il numero più elevato di token.
Esegue una singola chiamata di strumento ad ogni passaggio, riceve il risultato e poi procede, il che significa che sono necessari 4 strumenti indipendenti, 4 cicli LLM separati 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 utilizzati da LangChain si è generalmente attestato a 9 o 15. Questi due gruppi indicano due strategie tipiche: in alcune esecuzioni, il programma ha saltato la fase di ispezione ed è passato direttamente all'analisi e alla sintesi (9 strumenti), mentre in altre ha ispezionato prima ogni colonna prima di procedere all'elaborazione (15 strumenti). L'identità di esecutore lineare di LangChain è emersa chiaramente in questo contesto: 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 compito rivelano che l'efficienza con cui un framework può gestire dati non strutturati (JSON, LongText) è direttamente legata al suo meccanismo di ciclo interno:
I framework in grado di gestire chiamate parallele agli strumenti (come AutoGen) possono elaborare colonne di dati indipendenti in un unico passaggio. In scenari reali che coinvolgono oggetti JSON di grandi dimensioni e numerose colonne di testo, questa differenza si traduce in un enorme vantaggio in termini di costi e velocità.
I framework con cicli basati sullo stato (LangGraph) eccellono nella coerenza dei dati, ma comportano il rischio di rivalutare passaggi già completati e accumulati nella cronologia.
I framework basati su monologhi (CrewAI) sono in grado di comprendere a fondo il tipo e il significato dei dati, ma questa profondità a volte si traduce in un eccesso di domande e cicli ripetitivi.
I framework di esecuzione lineare (LangChain) elaborano separatamente diversi rami di dati non strutturati, producendo un risultato intermedio che combina i vantaggi di entrambi gli approcci.
Crescita stellare dei framework agentici su GitHub
Confronta i framework di intelligenza artificiale agentica
I framework di intelligenza artificiale basati su agenti variano in base a diverse dimensioni chiave, e comprendere queste differenze è essenziale per effettuare confronti significativi.
Orchestrazione multi-agente
L'orchestrazione multi-agente coordina più agenti di intelligenza artificiale specializzati per affrontare flussi di lavoro complessi che superano le capacità di un singolo agente. Invece di creare 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 creano sistemi ad agenti.
Coordinamento esplicito multi-agente: è possibile modellare più agenti come nodi o gruppi individuali, ognuno con la propria logica, memoria e ruolo nel sistema.
Consente di creare flussi di lavoro di intelligenza artificiale che coinvolgono API e strumenti diversi. Pertanto, si adatta perfettamente a pipeline RAG e personalizzate.
AutoGen
AutoGen consente a più agenti di comunicare scambiandosi messaggi in un ciclo. Ciascun agente può rispondere, riflettere o richiamare strumenti in base alla propria logica interna.
Presenta 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 l'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 (dirigente-dipendente) e strutturato.
OpenAI Sciame
Swarm è un framework multi-agente leggero e sperimentale per la prototipazione. Gli agenti lavorano in sequenza attraverso passaggi di consegne, trasferendo i compiti pur 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 a singolo agente con strumenti RAG. Fornisce componenti modulari, tra cui catene, strumenti, memoria e recupero per i flussi di lavoro di elaborazione dei documenti.
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 sui grafi per la progettazione degli agenti, in cui ogni agente è rappresentato come un nodo che mantiene il proprio stato. Questi nodi sono collegati tramite un grafo orientato, che consente la logica condizionale, il coordinamento tra più team e il controllo gerarchico. Ciò permette di costruire e visualizzare grafi multi-agente con nodi supervisori per un'orchestrazione scalabile.
LangGraph utilizza funzioni annotate e strutturate che collegano strumenti agli agenti. È possibile creare nodi, connetterli a diversi supervisori e visualizzare come interagiscono i vari team. Si può pensare a questo come a una descrizione dettagliata del lavoro assegnato a ciascun membro del team. Ciò semplifica la creazione e il test di agenti che collaborano tra loro.
AutoGen
AutoGen definisce gli agenti come unità adattive capaci di instradamento flessibile e comunicazione asincrona. Gli agenti interagiscono tra loro (e facoltativamente con gli esseri umani) scambiandosi messaggi, consentendo la risoluzione collaborativa dei problemi. Come LangGraph, utilizza funzioni strutturate e annotate .
CrewAI
CrewAI adotta un approccio di progettazione basato sui ruoli . A ciascun 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 Sciame
OpenAI Swarm utilizza un modello basato su routine in cui gli agenti sono definiti tramite prompt e docstring di funzioni. Non dispone di orchestrazione formale o modelli di stato, affidandosi invece a flussi di lavoro strutturati manualmente. Il comportamento delle funzioni viene dedotto dal LLM tramite docstring (Swarm identifica cosa fa una funzione leggendone la descrizione), rendendo questa configurazione flessibile ma meno precisa.
LangChain
LangChain utilizza un'architettura a catena 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 modelli di prompt.
Sebbene sia principalmente focalizzato sui flussi di lavoro centralizzati, LangChain supporta estensioni per configurazioni multi-agente ma non dispone di una funzionalità integrata per la comunicazione tra agenti.
Memoria
Capacità di memoria :
- Stateful : Indica se il framework supporta la persistenza della memoria tra le esecuzioni.
- Contestuale : indica se supporta la memoria a breve termine tramite la cronologia dei messaggi o il passaggio del contesto.
Le funzionalità di memoria sono un elemento chiave nella creazione di sistemi agentici in grado di ricordare il contesto e adattarsi nel tempo:
- Memoria a breve termine : tiene traccia delle interazioni recenti, consentendo agli agenti di gestire conversazioni a più turni o flussi di lavoro passo-passo.
- Memoria a lungo termine : memorizza informazioni persistenti tra una sessione e l'altra, come le preferenze dell'utente o la cronologia delle attività.
- Memoria delle entità : tiene traccia e aggiorna le informazioni relative a oggetti, persone o concetti specifici menzionati durante le interazioni (ad esempio, ricordando il nome di un'azienda o l'ID di un progetto menzionati in precedenza).
LangGraph
LangGraph utilizza due tipi di memoria: la memoria in-thread , che memorizza le informazioni durante una singola attività o conversazione, e la memoria cross-thread , che salva i dati tra sessioni diverse. Gli sviluppatori possono utilizzare 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ò offre un controllo flessibile su come la memoria viene gestita e conservata tra le esecuzioni.
AutoGen
AutoGen utilizza un modello di memoria contestuale . Ogni agente mantiene il 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 livelli pronta all'uso. Memorizza la memoria a breve termine in un archivio vettoriale ChromaDB, i risultati delle attività recenti in SQLite e la memoria a lungo termine in una tabella SQLite separata (in base alle descrizioni delle attività). Inoltre, supporta la memoria delle entità utilizzando gli embedding vettoriali. Questa configurazione della memoria viene configurata automaticamente quando memory=True è abilitato,
OpenAI Sciame
Swarm è stateless e non gestisce la memoria in modo nativo. Gli sviluppatori possono passare manualmente la memoria a breve termine tramite context_variables e, facoltativamente, integrare strumenti esterni o livelli di memoria di terze parti (ad esempio, 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 viene in genere 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 archivi vettoriali o database esterni per rendere persistenti gli embedding e i dati di recupero.
Gli sviluppatori possono personalizzare gli ambiti e le strategie di memoria utilizzando le classi di memoria integrate, consentendo una gestione efficiente della memoria contestuale e specifica dell'entità tra le interazioni.
Interazione umana
LangGraph
LangGraph supporta breakpoint personalizzati (interrupt_before) per mettere in pausa il grafico 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 :
CrewA I abilita il feedback dopo ogni attività impostando human_input=True; l'agente si mette in pausa per raccogliere l'input in linguaggio naturale dall'utente.
OpenAI Sciame
OpenAI Swarm non offre HITL integrato.
LangChain
LangChain consente di inserire breakpoint personalizzati all'interno di catene o agenti per sospendere l'esecuzione e richiedere l'intervento 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 di intelligenza artificiale agentiva
Gli agenti di intelligenza artificiale devono interagire con strumenti esterni come database, API, file system e applicazioni aziendali. In assenza di uno standard, ogni framework era costretto a creare integrazioni personalizzate per ogni singolo strumento, generando 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 ogni 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 problemi, insieme alle loro funzionalità native.
AutoGen
AutoGen offre un'integrazione nativa con MCP 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 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 Sciame
Swarm beneficia del supporto nativo MCP di OpenAI in tutto il suo ecosistema. Poiché OpenAI ha integrato MCP in ChatGPT e nel suo SDK per agenti, Swarm può sfruttare direttamente questa infrastruttura.
LangChain
LangChain offre funzionalità di chiamata di strumenti MCP, in cui le funzioni Python fungono da ponte verso i server MCP. Ciò consente di prelevare strumenti da diverse fonti e integrarli in catene, agenti e altri componenti di LangChain senza bisogno di wrapper personalizzati.
Che cosa fanno concretamente i framework di intelligenza artificiale agentiva?
I framework di intelligenza artificiale basati su agenti aiutano nella progettazione dei prompt e nella gestione del flusso di dati da e verso i LLM . A livello base, aiutano a strutturare i prompt in modo che il LLM risponda in un formato prevedibile e a instradare le risposte allo strumento, all'API o al documento appropriato.
Se si partisse da zero, si dovrebbe definire manualmente il prompt, estrarre lo strumento che LLM desidera utilizzare e attivare la corrispondente chiamata API. I framework semplificano questo processo:
- Orchestrazione dei prompt : creazione, gestione e instradamento di prompt complessi verso i LLM
- Integrazione degli strumenti : consentire agli agenti di richiamare API esterne, database, funzioni di codice, ecc.
- Memoria : Mantenimento dello stato tra turni o sessioni (a breve e a lungo termine)
- Integrazione RAG : Abilitazione del recupero di conoscenze da fonti esterne
- Coordinamento multi-agente : Strutturare le modalità di collaborazione o di delega dei compiti tra gli agenti.
Framework di intelligenza artificiale agentiva: casi d'uso reali
LangGraph – Pianificatore di viaggio multi-agente
Un progetto di produzione realizzato con LangGraph dimostra un assistente di viaggio multi-agente e con stato che recupera dati su voli e hotel (utilizzando le API Flights & Hotels di Google) e genera raccomandazioni di viaggio. 4
CrewAI – Creatore di contenuti agentici
Il repository ufficiale di esempi di CrewAI include flussi come pianificazione di viaggi , strategia di marketing , analisi di mercato e assistenti al reclutamento , in cui agenti con ruoli specifici (ad esempio, "Ricercatore", "Scrittore") collaborano allo svolgimento dei compiti. 5
CrewAI trasforma un brief di alto livello in un articolo completo utilizzando Groq.
Caratteristiche principali dei framework di intelligenza artificiale agentiva
Supporto del modello :
- La maggior parte è indipendente dal modello , supportando più fornitori di LLM (ad esempio, OpenAI, Anthropic, modelli open-source).
- Tuttavia, le strutture dei prompt di sistema variano a seconda del framework e potrebbero funzionare meglio con alcuni modelli rispetto ad altri.
- L'accesso e la personalizzazione dei messaggi di sistema sono spesso essenziali per ottenere risultati ottimali.
Attrezzatura :
- Tutti i framework supportano l'utilizzo di strumenti , un elemento fondamentale per abilitare le azioni degli agenti.
- Offrire astrazioni semplici per definire strumenti personalizzati.
- La maggior parte supporta il protocollo Model-Context-Protocol (MCP) , sia nativamente che tramite estensioni della community.
Memoria / Stato :
- Utilizza il tracciamento dello stato per mantenere la memoria a breve termine tra le fasi o le chiamate LLM.
- Alcuni di questi aiutano gli agenti a conservare le interazioni precedenti o il contesto all'interno di una sessione.
RAG (Retrieval-Augmented Generation) :
- La maggior parte include opzioni di configurazione semplici per 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 , che consente chiamate simultanee 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 di benchmarking
1. Struttura del compito
Attività 1: Verifica se è possibile effettuare una singola chiamata di strumento con il parametro corretto. In questo semplice scenario, il sovraccarico dell'infrastruttura di base del framework viene rivelato in modo più chiaro.
Compito 2: Richiede di memorizzare 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.
Compito 3: Misura se le condizioni numeriche in linguaggio naturale vengono tradotte in parametri dello strumento senza distorsioni. La vera prova consiste nel verificare se i meccanismi di ripetizione e richiesta del framework sono in grado di preservare questi parametri.
Attività 4: Uno strumento genera in successione errori di tipo Rete, Timeout e RateLimit. Viene misurato se il framework modifica la propria strategia in presenza di tali errori.
Attività 5: L'agente deve innanzitutto individuare le colonne JSON e LongText, quindi richiamare gli strumenti corretti con i parametri di ambito appropriati. Viene osservato se il framework esegue gli strumenti indipendenti in parallelo o in sequenza.
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 compiti, 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 dello strumento è stato reimpostato prima di ogni esecuzione. Sono state eseguite 100 esecuzioni indipendenti per ogni combinazione di framework e attività.
I limiti massimi di iterazioni sono stati impostati in base alla complessità del compito: 10 per i compiti 1, 2 e 3; 20 per il compito 4 a causa del ciclo di utensile instabile; e 20 per il compito 5 a causa della catena di scoperta in 4 fasi.
Collegamenti di riferimento
Prossimo da leggere
Confronto tra framework multi-agente: sfide e punti di forza
Agentic Search nel 2026: benchmark 8 API di ricerca per agenti
Il panorama della valutazione dei Master in Giurisprudenza (LLM) con i relativi framework
Framework RAG: LangChain vs LangGraph vs LlamaIndex
Confronto tra framework di intelligenza artificiale agentica nei flussi di lavoro di analisi
Oltre 10 framework e strumenti per l'orchestrazione di agenti
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.