Confronto tra framework multi-agente: sfide e punti di forza
I sistemi multi-agente utilizzano agenti specializzati che collaborano per risolvere compiti complessi. Una sfida fondamentale è la seguente: le prestazioni si degradano con l'aggiunta di un numero maggiore di agenti e strumenti, oppure i meccanismi di orchestrazione sono in grado di gestire la crescente complessità in modo efficiente?
Abbiamo effettuato un benchmark di 5 framework agentici su 750 esecuzioni con tre attività. Abbiamo misurato la latenza, il consumo di token e l'overhead di orchestrazione per identificare quali modelli architetturali mantengono l'efficienza su larga scala e quali la degradano.
Benchmark del framework multi-agente
Abbiamo testato come l'utilizzo dei token e la latenza variano all'aumentare del numero di agenti e strumenti. In tre attività con lo stesso problema, abbiamo progressivamente ampliato il numero di agenti e la disponibilità di strumenti. Per LangChain e LangGraph, abbiamo utilizzato configurazioni a singolo agente per osservare come le loro architetture sequenziali gestiscono la stessa complessità affrontata dai sistemi multi-agente.
Non abbiamo incluso nel grafico il framework con un'accuratezza inferiore al 95% (Swarm). Puoi consultare la nostra metodologia di benchmarking.
Nello specifico per Swarm, abbiamo osservato che la precisione variava di pari passo con la complessità, a causa di differenze architetturali piuttosto che delle capacità del modello.
Nei framework basati su agenti, l'accuratezza può essere generalmente migliorata attraverso la selezione o la configurazione dei modelli LLM . Tuttavia, l'analisi delle cause architetturali delle variazioni di accuratezza nel nostro benchmark ha rivelato informazioni preziose, aiutandoci a comprendere le differenze di progettazione fondamentali tra i framework.
Risultati del benchmark del framework multi-agente
CrewAI obbliga tutti gli agenti a eseguire le proprie azioni in sequenza, causando una crescita esponenziale del numero di token poiché l'output di ciascun agente si somma al contesto dell'agente successivo. Questa rigidità garantisce la completezza, ma crea un sovraccarico enorme.
Swarm privilegia la velocità attraverso il routing senza stato, ma subisce un progressivo calo di precisione (dall'84% allo 0%) all'aumentare della complessità del compito. Senza il tracciamento dello stato globale, gli agenti terminano prematuramente, interrompendo le catene a più fasi.
LangChain utilizza un singolo "super-agente" con contesto unificato, evitando completamente il sovraccarico di coordinamento. Le prestazioni rimangono efficienti finché le dimensioni della libreria di strumenti (100 strumenti) e la complessità del ragionamento non aumentano significativamente la latenza.
LangGraph offre un'affidabilità paragonabile a quella di LangChain, ma introduce un overhead dovuto all'attraversamento del grafo. Il costo della gestione dello stato diventa più rilevante in presenza di elevata complessità, pur mantenendo un'elevata precisione.
AutoGen genera un elevato numero di trasferimenti di consegne tramite coordinamento basato su chat, ma utilizza GroupChatManager per eliminare dinamicamente gli agenti non necessari. Ciò impedisce la crescita esponenziale di CrewAI pur mantenendo un'elevata precisione, sebbene il consumo di token rimanga superiore rispetto ai modelli con un singolo agente a causa della rielaborazione della cronologia delle conversazioni.
CrewAI
La pipeline sequenziale basata sui ruoli di CrewAI esegue ogni agente assegnato senza filtrare gli agenti superflui durante l'intero processo. Questa caratteristica architetturale ha implicazioni significative per i sistemi agentici, in cui ogni agente svolge una funzione critica. Garantisce che il framework non salti alcun passaggio previsto e continui a utilizzare ogni agente anziché prendere decisioni di instradamento autonome. Tuttavia, questa rigidità ha un costo elevato in termini di consumo di risorse e latenza all'aumentare della complessità del compito.
Crescita esponenziale delle risorse tra le diverse attività
Dal compito 1 al compito 3, abbiamo osservato un continuo aumento del consumo di token e della latenza. La latenza è raddoppiata approssimativamente con ogni aumento del numero di compiti, mentre il consumo di token è cresciuto a un ritmo ancora più vertiginoso. Il numero di trasferimenti di agente è naturalmente aumentato parallelamente a questa scalabilità.
Perché CrewAI consuma più token e tempo
La pipeline sequenziale di CrewAI si è allineata in modo naturale con entrambi i flussi di lavoro. Nell'Attività 1, l'Analista dei dati ha raccolto le informazioni prima che l'Arbitro prendesse le decisioni. Nell'Attività 2, questo schema è proseguito con ruoli degli agenti ampliati. CrewAI ha selezionato correttamente tutti gli strumenti e ha dimostrato che l'esecuzione sequenziale elimina la confusione di coordinamento, con ciascun agente che esegue gli strumenti a lui assegnati senza ambiguità di instradamento.
Tuttavia, questo allineamento naturale ha comportato costi aggiuntivi considerevoli e crescenti:
Il meccanismo di composizione dello stato:
- Ogni agente genera un rapporto dettagliato al termine del proprio compito.
- Questo rapporto viene trasmesso all'agente successivo nella sequenza
- Nel momento in cui l'Arbitro finale riceve il passaggio di consegne, legge un documento contenente la cronologia e gli output di tutti gli agenti precedenti, oltre alle proprie istruzioni di sistema e ai metadati degli strumenti.
- L'LLM impiega molto tempo a leggere e rigenerare oggetti di stato Markdown di grandi dimensioni tra un'attività e l'altra.
Questa gestione dello stato, piuttosto prolissa, avvolgeva persino i singoli punti dati in metadati di orchestrazione sostanziali. CrewAI privilegia la consapevolezza del contesto complessivo rispetto all'efficienza.
Rigidità del compito 2-3:
- Il framework ha eseguito tutti e 5 gli agenti nella sequenza predefinita, anche quando solo un sottoinsieme era strettamente necessario
- Questa rigidità ha fatto lievitare sia i costi dei token che la latenza, pur mantenendo un'elevata precisione.
- L'incapacità del framework di omettere gli agenti non necessari è diventata sempre più evidente come un vincolo architettonico fondamentale.
- Ogni agente aggiuntivo ha complicato il contesto che gli agenti successivi devono elaborare
Sciame
Il meccanismo di routing leggero di Swarm ha dimostrato una vera delega multi-agente con un sovraccarico di orchestrazione minimo. Un agente iniziale raccoglieva il contesto necessario, riconosceva attivamente quando il suo compito era terminato e trasferiva esplicitamente la sessione a un agente decisionale distinto. Questa architettura senza stato privilegiava velocità e semplicità, raggiungendo prestazioni paragonabili a quelle di base con un singolo agente in scenari semplici. Tuttavia, con l'aumentare della complessità del compito, questo approccio leggero ha rivelato limiti fondamentali di scalabilità, in quanto l'assenza di tracciamento dello stato globale e di orchestrazione centrale causava un progressivo calo di precisione.
Degrado progressivo dell'accuratezza nel corso delle attività
Dal compito 1 al compito 3, abbiamo osservato un drastico calo di precisione nonostante il mantenimento di elevate velocità di esecuzione. La precisione è scesa dall'84% nel compito 1 al 22% nel compito 2, raggiungendo infine lo 0% nel compito 3. Questo progressivo degrado ha rivelato che l'architettura stateless di Swarm, ottimizzata per la velocità nelle interazioni a breve termine, è fondamentalmente non scalabile per catene di ragionamento a più fasi.
Perché la precisione diminuisce all'aumentare della complessità?
Il routing leggero di Swarm ha mantenuto i token di completamento estremamente bassi e la latenza ridotta durante tutte le attività. Il framework funzionava come una staffetta di agenti indipendenti senza stato globale, in cui ogni agente prendeva decisioni autonome di passaggio di consegne senza supervisione centrale. Questo approccio eccelle nel minimizzare il consumo di token e nel raggiungere un'esecuzione rapida, ma comporta un costo elevato in termini di affidabilità e precisione all'aumentare dei requisiti di persistenza operativa.
Il punto cieco architettonico:
Un'analisi post-mortem dei log ha rivelato un punto cieco architetturale che non poteva essere risolto solo tramite l'ingegneria dei prompt. Inizialmente, è stata identificata e corretta una svista nei prompt (istruzioni di trasferimento mancanti). Tuttavia, anche con comandi di trasferimento espliciti, Swarm non è riuscito a completare la catena.
Poiché il framework è senza stato e privo di tracciamento globale delle intenzioni, il primo agente destinatario (ad esempio, Finanza) si limiterebbe a emettere una conferma conversazionale (ad esempio, "Dati ricevuti, avvio audit finanziario") e a terminare la conversazione. Swarm interpreta qualsiasi fine di turno conversazionale come completamento dell'attività, portando ai risultati più rapidi ma meno affidabili. Senza un orchestratore centrale che mantenga lo stato dell'attività e garantisca l'esecuzione di tutti i passaggi, il framework non è in grado di distinguere tra "l'agente ha dato una conferma" e "l'attività è completamente completata". Questa limitazione fondamentale implica che nemmeno una vera delega multi-agente con passaggi di consegne espliciti può garantire il completamento dell'attività quando la catena si estende oltre le semplici interazioni.
Compito 1-2: Problemi di precisione crescenti
Nel Task 1, in cui Swarm ha dimostrato ottime prestazioni con brevi catene di agenti, il framework ha comunque fallito nel 16% delle esecuzioni a causa di una risoluzione incompleta del passaggio di consegne. Analizzando i log delle conversazioni, abbiamo scoperto che l'Arbitro aveva preso decisioni con successo, ma il meccanismo di output di Swarm ha mostrato il messaggio intermedio di passaggio di consegne dell'Analista dei dati. Gli utenti hanno ricevuto il messaggio "Ora trasferirò queste informazioni all'Arbitro" anziché la decisione effettiva, rivelando che i sistemi di routing dinamico rischiano di perdere i risultati finali durante le transizioni tra agenti.
Nel compito 2, con 5 opzioni di agente e 20 strumenti in gioco, la precisione si è degradata significativamente poiché la strategia di suggerimento leggera e povera di contesto del framework ha iniziato a cedere sotto la crescente complessità:
- La percentuale di strumenti scelti correttamente è scesa al 40%, rappresentando un calo del 20% rispetto al compito 1.
- Gli agenti a volte chiamavano strumenti non pertinenti o emettevano messaggi di instradamento laddove erano previste chiamate a strumenti reali.
- A volte gli agenti tentavano di utilizzare strumenti provenienti dal dominio sbagliato o riprovavano chiamate fallite.
- In assenza di un controller centrale, gli agenti perdevano traccia dello stato di esecuzione o venivano trasferiti a ruoli che sembravano conclusivi ma non avevano eseguito le chiamate agli strumenti necessari.
Compito 3: Il paradosso del passaggio di consegne
Il compito 3 ha messo in luce la limitazione architetturale fondamentale di Swarm, con un'accuratezza dello 0% nonostante mantenesse la velocità di esecuzione più elevata. Questo fallimento totale ha rivelato quello che definiamo il "Paradosso del passaggio di consegne": in una catena di 10 agenti, Swarm richiede trasferimenti basati al 100% su strumenti a ogni collegamento, ma senza un orchestratore centrale o un grafo di stato (come LangGraph), la catena si interrompe al primo collegamento. Mentre Swarm eccelle nei passaggi di consegne uno a uno, collassa nei flussi di lavoro a più fasi che richiedono persistenza operativa su lunghe catene.
Esaurimento della catena di passaggio di consegne:
Nel Task 1, con un solo passaggio di consegne, la catena era abbastanza breve da mantenere l'obiettivo nel contesto. Tuttavia, con l'estensione della catena a 9 passaggi di consegne nel Task 3, la probabilità cumulativa di successo è scesa a zero. Ogni specialista aggiuntivo fungeva da "punto di perdita" in cui una risposta conversazionale poteva interrompere il processo prima che si raggiungesse l'Arbitro finale. Questo tasso di fallimento geometrico dimostra che il routing senza stato, pur essendo ottimizzato per la velocità, non è scalabile per maratone di ragionamento a più fasi.
LangChain
LangChain eseguiva i compiti come una semplice macchina a stati: riceveva il prompt, valutava gli strumenti, eseguiva e finalizzava. Abbiamo configurato LangChain come un esecutore a singolo agente, senza passaggi intermedi e con un unico agente per tutti i compiti. Questo approccio a contesto unificato manteneva un'unica entità logica durante l'esecuzione, evitando salti conversazionali ed eseguendo esattamente ciò che ogni compito richiedeva, senza overhead di orchestrazione. Il modello di esecuzione lineare del framework ha dimostrato che i compiti che non richiedono la collaborazione tra agenti traggono un notevole vantaggio dall'evitare i costi di coordinamento intrinseci ai sistemi multi-agente.
Scalabilità efficiente fino alla soglia di entropia dello strumento
LangChain ha mantenuto risultati corretti in tutti e tre i compiti. Tuttavia, il compito 3 ha rivelato la sensibilità del framework alle dimensioni della libreria di strumenti e alla complessità del ragionamento, con una latenza che aumentava sensibilmente all'aumentare di entrambe le dimensioni.
Perché LangChain è rimasta efficiente
Compito 1-2: Vantaggio dell'esecuzione lineare
Nel Task 1, LangChain ha raggiunto una latenza minima e un utilizzo ottimizzato dei token con una selezione degli strumenti precisa. Il framework ha evitato di farsi distrarre da meccanismi di coordinamento, elaborando solo ciò che era necessario per completare il task. L'architettura a singolo agente ha eliminato il sovraccarico di comunicazione tra agenti, la generazione di report tra le fasi e le conversazioni superflue.
Nel Task 2, abbiamo implementato LangChain utilizzando un'architettura "super-agente" in cui un singolo controller aveva accesso diretto a tutti e 20 gli strumenti. Consolidando i ruoli in un'unica entità logica, il framework ha eliminato la necessità di scambio di dati tra agenti, generazione di report e riempitivi conversazionali. Questo modello di esecuzione lineare ha garantito che LLM elaborasse solo i risultati degli strumenti pertinenti, evitando la crescita esponenziale della cronologia dei prompt che si osserva nei framework multi-agente.
L'architettura di contesto unificata ha fatto sì che la presenza di 20 strumenti nella libreria non creasse alcuna confusione nella selezione. Il singolo agente elaborava le chiamate agli strumenti in sequenza senza bisogno di coordinarsi o negoziare con altri agenti, mantenendo la corretta selezione degli strumenti nonostante l'ampliamento della libreria. L'assenza di passaggi di consegne ha confermato che non è stato introdotto alcun sovraccarico di orchestrazione con l'aumentare della complessità.
Entropia degli strumenti e complessità del ragionamento
Il compito 3 ha introdotto due sfide significative che hanno avuto un impatto sulle prestazioni di LangChain:
Entropia dello strumento:
Mentre il compito 1 prevedeva 5 strumenti e il compito 2 ne prevedeva 20, il compito 3 ne presentava 100. Poiché LangChain opera come un sistema a singolo agente, ogni messaggio deve includere le definizioni di tutti i 100 strumenti nel prompt. Questo crea due colli di bottiglia:
- Il LLM deve valutare 100 opzioni per selezionare lo strumento corretto, aumentando i tempi di elaborazione.
- Le dimensioni enormi del prompt (che contengono tutte le definizioni degli strumenti) ritardano il tempo di generazione del primo token del modello, aumentando la latenza complessiva.
Complessità del ragionamento (10 ruoli di esperti):
Nei compiti 1 e 2, l'agente ha semplicemente agito come arbitro prendendo una decisione. Nel compito 3, all'agente è stato chiesto di ragionare considerando sequenzialmente 10 prospettive di esperti.
Questa istruzione ha indotto il modello a generare output significativamente più lunghi, con un aumento sostanziale dei token di completamento rispetto all'Attività 2. Una maggiore quantità di testo generato si traduce direttamente in tempi di esecuzione più lunghi, poiché il modello deve produrre ogni token in sequenza.
Nonostante queste difficoltà, LangChain ha mantenuto output corretti e non ha mai selezionato strumenti errati. La semplice struttura a ciclo del framework (AgentExecutor) ha elaborato le chiamate e le risposte degli strumenti senza ulteriori overhead architetturali, mantenendo gli aumenti di latenza proporzionali alla complessità intrinseca del compito, anziché aggravarli con meccanismi di orchestrazione.
L'approccio architetturale di LangChain ha dimostrato che l'esecuzione contestuale unificata può mantenere l'affidabilità all'aumentare della complessità, sebbene le prestazioni diventino sensibili alle dimensioni della libreria di strumenti e alla profondità del ragionamento. La capacità del framework di produrre output corretti per tutte le attività, evitando al contempo l'esplosione di token e il sovraccarico di coordinamento dei sistemi multi-agente, ha dimostrato il valore dei modelli di esecuzione lineare per le attività che non richiedono la collaborazione tra agenti.
LangGraph
Come osservato nel nostro benchmark sui framework agentici, LangGraph ha utilizzato un'architettura a stati finiti con transizioni di stato esplicite e un flusso di controllo basato su grafi. Abbiamo configurato LangGraph come un esecutore a singolo agente, senza passaggi intermedi e con un unico agente per tutte le attività. Questo approccio ha eliminato completamente la comunicazione tra agenti, fornendo al contempo una gestione strutturata dello stato che tracciava l'avanzamento dell'esecuzione attraverso nodi e archi definiti. Il framework ha dimostrato che il tracciamento formale dello stato può coesistere con l'esecuzione di un contesto unificato.
Affidabilità costante con gestione dei grafici
LangGraph ha prodotto risultati corretti in tutti e tre i compiti, senza errori. Nei compiti 1 e 2, le prestazioni sono rimaste pressoché identiche al modello di esecuzione lineare di LangChain. Tuttavia, il compito 3 ha rivelato un aumento della latenza più pronunciato rispetto a LangChain, evidenziando il costo computazionale della gestione dello stato basata su grafi in presenza di elevata entropia degli strumenti e complessità di ragionamento.
Perché LangGraph è compatibile con LangChain
Il grafo di stato di LangGraph ha fornito un flusso di controllo formale senza richiedere agenti multipli. In entrambi i compiti, il framework ha mantenuto zero passaggi di consegne, selezionando tutti gli strumenti corretti. Il singolo controller ha avuto accesso diretto a tutti gli strumenti necessari, elaborando ogni passaggio tramite transizioni di stato anziché tramite passaggi di consegne tra agenti.
L'implementazione del "super-agente" ha fatto sì che il framework non suddividesse mai il carico cognitivo tra più personaggi. La selezione degli strumenti è rimasta precisa anche con 20 strumenti disponibili nel Task 2, e l'agente non ha mai chiamato strumenti errati o irrilevanti. Il contesto unificato ha impedito la confusione di selezione che affliggeva i framework basati sul coordinamento tra agenti.
Perché il consumo di token corrispondeva a LangChain
Entrambi i framework hanno utilizzato la stessa configurazione LLM, le stesse definizioni degli strumenti e gli stessi prompt di sistema. A differenza dei framework multi-agente (AutoGen, CrewAI) che generano un sovraccarico di coordinamento attraverso conversazioni tra agenti e messaggi di coordinamento intermedi, entrambi i framework a singolo agente consolidano tutte le competenze in un'unica chiamata al modello. Ogni token speso rappresenta le istruzioni di input o l'output diretto, senza alcun sovraccarico intermedio del tipo "L'agente A ha parlato con l'agente B". Inoltre, entrambi i framework invocano gli stessi strumenti nella stessa sequenza per risolvere il compito, ricevendo dati identici dal sistema sottostante, il che si traduce in conteggi di token di completamento molto simili. Le differenze di token tra i framework erano trascurabili perché l'LLM ha eseguito lo stesso lavoro di ragionamento in entrambi i casi.
Attività 3: Amplificazione del sovraccarico dovuto all'attraversamento del grafo
Il compito 3 ha introdotto le stesse sfide affrontate da LangChain (100 strumenti e complessità di ragionamento a 10 ruoli), ma l'architettura basata sui grafi di LangGraph ha amplificato l'impatto sulle prestazioni:
Carico entropico dello strumento:
Come LangChain, anche LangGraph, a causa della sua architettura a singolo agente, deve includere tutte le 100 definizioni degli strumenti in ogni richiesta. L'LLM deve valutare l'intera libreria degli strumenti per ogni selezione e le dimensioni considerevoli della richiesta ritardano la generazione della risposta.
Complessità del ragionamento:
L'istruzione di ragionare attraverso 10 prospettive di esperti in sequenza ha fatto sì che LangGraph generasse output significativamente più lunghi, proprio come accadeva per LangChain. Tuttavia, il sovraccarico aggiuntivo di LangGraph è diventato evidente in questo caso.
Costi aggiuntivi dovuti alla gestione dei grafici:
Mentre LangChain utilizza una semplice struttura a ciclo (AgentExecutor) che richiama strumenti ed elabora le risposte, LangGraph attraversa un'intera struttura a grafo ad ogni passaggio. Per ogni chiamata di strumento:
- Il framework deve attraversare l'intero grafo dall'inizio alla fine
- La cronologia dei messaggi (stato) viene aggiornata ad ogni transizione di nodo.
- Il sistema convalida le transizioni tra i nodi e mantiene la coerenza dello stato.
Nei compiti 1 e 2, questo overhead era trascurabile. Nel compito 3, con 100 strumenti e requisiti di ragionamento complessi, questo onere di gestione del grafo è diventato sostanziale. La latenza aggiuntiva rispetto a LangChain rifletteva direttamente il costo di mantenimento e attraversamento della struttura del grafo di stato in condizioni di elevata complessità.
Nonostante questo sovraccarico, LangGraph non ha mai selezionato strumenti errati, richiamando sempre e solo le funzioni necessarie per completare ogni passaggio. Il tracciamento formale dello stato del framework ha fornito un flusso di controllo strutturato a costo di un aumento dei tempi di elaborazione.
L'approccio architetturale di LangGraph ha dimostrato che la gestione esplicita dello stato può mantenere la sua affidabilità all'aumentare della complessità, sebbene il sovraccarico dovuto all'attraversamento del grafo diventi più pronunciato in presenza di elevata entropia degli strumenti e complessità di ragionamento. Per le applicazioni che richiedono tracciabilità, capacità di rollback o logiche di ramificazione complesse, questo compromesso può essere vantaggioso. Per una semplice esecuzione sequenziale, la struttura aggiuntiva di LangGraph offre un valore limitato rispetto a modelli lineari più semplici come LangChain.
Autogen
AutoGen ha consumato molte più risorse rispetto alle configurazioni di base con un singolo agente, pur non raggiungendo i livelli estremi della pipeline sequenziale di CrewAI. Il framework prevedeva molteplici conversazioni tra un UserProxy e agenti specializzati. Ogni turno in questa chat richiedeva un passaggio LLM completo che rielaborava l'intera cronologia della conversazione fino a quel momento.
Tuttavia, AutoGen ha sempre selezionato gli strumenti corretti e prodotto risultati accurati in tutte le attività, senza richiamare strumenti non pertinenti. Ha introdotto un sovraccarico conversazionale, poiché il framework impiegava più tempo per il coordinamento che per l'esecuzione. Per questa attività semplice, il coordinamento basato sulla chat di AutoGen si è rivelato una complessità inutile anziché un vantaggio collaborativo.
AutoGen ha adottato un'architettura basata sulla chat in cui agenti specializzati collaborano tramite un UserProxy che gestisce il coordinamento del flusso di lavoro.
Abbiamo configurato AutoGen utilizzando GroupChatManager per tutte e tre le attività, consentendo la selezione dinamica degli agenti anziché imporre l'esecuzione sequenziale. Questa architettura ha dimostrato che l'orchestrazione intelligente può realizzare la collaborazione multi-agente senza i costi esponenziali di risorse tipici delle pipeline rigide.
Elevato numero di passaggi di consegne con prestazioni competitive
AutoGen ha registrato il maggior numero di passaggi di consegne tra tutti i framework. Già nel Task 1, il framework ha raggiunto livelli di passaggi di consegne che CrewAI ha raggiunto solo nel Task 3 (9 passaggi di consegne). Ciò riflette la natura conversazionale di AutoGen: ogni interazione tra UserProxy e gli agenti specializzati viene registrata come un passaggio di consegne, anche quando si discute su quale strumento chiamare.
Tuttavia, nonostante questi elevati numeri di handover, la latenza di AutoGen è rimasta competitiva rispetto ai framework sequenziali nei Task 1 e Task 2. Nel Task 3, mentre l'overhead del framework CrewAI ha raggiunto 1,35 milioni di token, AutoGen ne ha consumati solo 56.700 (rispetto ai 13.500 e 13.600 di LangChain e LangGraph).
Perché AutoGen ha consumato più token nonostante la sua latenza
AutoGen ha consumato un numero di token sostanzialmente maggiore rispetto alle configurazioni di base con un singolo agente, pur non raggiungendo i livelli estremi della pipeline sequenziale di CrewAI. Il framework prevedeva molteplici conversazioni tra un UserProxy e agenti specializzati. Ogni turno in questa chat richiedeva un passaggio LLM completo che rielaborava l'intera cronologia della conversazione fino a quel momento.
Questo accumulo ricorsivo di token spiega perché il consumo di token di AutoGen è rimasto superiore a quello di LangChain e LangGraph anche quando la latenza è rimasta competitiva. La cronologia della chat cresce a ogni turno, aumentando la dimensione del prompt, ma il GroupChatManager del framework impedisce l'esplosione esponenziale osservata nelle pipeline sequenziali eliminando gli agenti non necessari.
Tuttavia, AutoGen ha sempre selezionato gli strumenti corretti e prodotto risultati accurati in tutte le attività, senza richiamare strumenti irrilevanti. Il sovraccarico conversazionale ha comportato che il framework impiegasse più tempo per il coordinamento che per l'esecuzione, ma questo coordinamento ha garantito che nessun agente perdesse mai la concentrazione o richiamasse strumenti sbagliati.
GroupChatManager di AutoGen
Il punto di forza architetturale di AutoGen: la selezione dinamica degli agenti tramite GroupChatManager. A differenza dell'orchestrazione sequenziale del Task 2, la modalità GroupChat ha permesso al framework di attivare solo gli agenti necessari dal pool disponibile.
Il Manager ha eliminato gli specialisti non necessari, attivando solo 5-6 agenti dal pool di 10. Non appena l'Arbitro ha trovato motivi sufficienti per una decisione, il Manager ha interrotto il ciclo. Ciò ha impedito la crescita esponenziale dei token che si sarebbe verificata se il contesto fosse stato forzato attraverso ogni agente rimanente in sequenza.
Questa potatura dinamica ha comportato una latenza e un consumo di token notevolmente inferiori rispetto alla rigida pipeline sequenziale di CrewAI. Mentre CrewAI costringeva tutti e 10 gli agenti a eseguire le operazioni indipendentemente dalla necessità, GroupChat di AutoGen selezionava in modo adattivo solo gli agenti necessari per raggiungere una decisione.
Nonostante i costi di coordinamento, l'elevato numero di passaggi di consegne riflette un'attenta valutazione in cui gli agenti confrontano i risultati prima di concludere. La capacità di AutoGen di passare dalla modalità sequenziale a quella di chat di gruppo offre una flessibilità di cui le architetture rigide sono prive, dimostrando che l'orchestrazione basata sulla chat con selezione intelligente degli agenti può scalare in modo più efficiente rispetto alle pipeline fisse per flussi di lavoro complessi multi-agente.
Come funziona AutoGen GroupChatManager:
- Ad ogni passaggio, il Manager decide "quale agente deve parlare per primo?" in base al contesto della conversazione.
- Il framework non è tenuto a eseguire tutti gli agenti in sequenza
- Se si raccolgono informazioni sufficienti in anticipo, il manager può evitare di ricorrere a specialisti non necessari.
- Il Manager può interrompere il ciclo non appena l'agente ha informazioni sufficienti per prendere una decisione.
La sfida "Continua pure": il comportamento predefinito di AutoGen è quello di mantenere attive le conversazioni. Per i benchmark, segnali di terminazione precisi sono fondamentali per evitare la "dispersione di token". Abbiamo affrontato questo problema assicurandoci che tutti gli agenti specializzati includano segnali TERMINATE espliciti al completamento dell'attività.
Sovraccarico del gestore: anche con GroupChatManager, lo stato interno dei messaggi di AutoGen è più grande di quello di LangChain a causa dell'orchestrazione multi-agente. Tuttavia, questo fornisce registri e tracce di discussione significativamente più strutturati rispetto a framework più semplici.
Nota sulla differenza tra sequenziale e GroupChat: abbiamo eseguito tutte le attività utilizzando GroupChatManager. Nelle prove sperimentali con orchestrazione sequenziale, abbiamo osservato un consumo di token e una latenza almeno raddoppiati rispetto alla modalità GroupChat, confermando che la selezione dinamica degli agenti offre notevoli vantaggi in termini di efficienza rispetto alle pipeline fisse.
Metodologia di riferimento per framework multi-agente
Ciascun framework è stato testato per 50 iterazioni (N=50) per ogni attività.
Per eliminare la variabilità nel processo di ragionamento del modello, tutti i framework hanno utilizzato la stessa configurazione LLM. Il modello utilizzato è stato openai/gpt-5.2 tramite l'API OpenRouter. La temperatura è stata impostata a 0,0 .
Non è stato imposto alcun limite massimo di token alle risposte del modello LLM, consentendo ai framework di utilizzare tutto il contesto necessario, in base alla loro architettura interna, per risolvere il compito.
Le metriche acquisite includono: numero di chiamate API LLM, passaggi di consegne tra agenti, agenti unici invocati, chiamate di strumenti eseguite e accuratezza delle chiamate di strumenti. Tutte le metriche sono state registrate per ogni iterazione e aggregate sull'intero campione di 50 esecuzioni.
Abbiamo separato gli output grezzi del modello LLM dal sovraccarico aggiuntivo introdotto dall'orchestrazione per misurarne l'efficienza. I token di output del modello LLM rappresentano le risposte effettivamente utili generate dal modello, mentre il sovraccarico del framework comprende i comandi di sistema, le definizioni degli strumenti e le cronologie delle conversazioni che il framework deve fornire al modello LLM in background per ottenere tali risposte.
Questa metrica, calcolata sottraendo i token di output dai token totali (Totale – Token di output), rivela direttamente il "costo di gestione" che il framework nasconde all'utente. Grazie a questa distinzione, possiamo vedere quali framework rimangono efficienti e snelli, rispetto a quelli che caricano ripetutamente enormi quantità di dati nell'LLM per ogni fase di orchestrazione. Abbiamo basato la nostra analisi sui token di overhead del framework come metrica di efficienza principale.
Per garantire che i framework fossero valutati esclusivamente in base alla loro logica di coordinamento, abbiamo sincronizzato tutte le altre variabili. Ciò ha eliminato i fattori confondenti e isolato le differenze architetturali.
Gli agenti sono stati definiti in un file centrale. Il wrapper di ciascun framework ha iniettato la stessa stringa di persona nel suo parametro nativo, system_message per AutoGen, backstory per CrewAI, prompt di sistema per LangChain/LangGraph e descrizioni degli agenti per Swarm. Non è stata applicata alcuna ingegneria dei prompt specifica per framework.
Ogni framework utilizzava le stesse funzioni Python di base. Le definizioni degli strumenti, le docstring e gli schemi dei parametri erano standardizzati. Non venivano utilizzati strumenti predefiniti specifici per alcun framework. Ciò garantisce la coerenza della logica di esecuzione degli strumenti, con l'unica differenza rappresentata dai meccanismi di orchestrazione.
Per ogni iterazione, agli agenti veniva fornito il dataset "DataCo Smart Supply Chain". I dati di riferimento (stato della spedizione, stato del pagamento, margini di profitto) rimanevano costanti in tutti i framework.
Pur mantenendo identici gli input, ciascun framework ha operato nella sua modalità strutturale nativa. Non abbiamo forzato i framework ad adottare architetture innaturali. Al contrario, abbiamo implementato ciascun framework secondo il suo modello di progettazione previsto per misurare le prestazioni nel mondo reale.
AutoGen funziona come un sistema di chat di gruppo conversazionale. Utilizza messaggi di tipo initiate_chats con segnali TERMINATE per gestire le condizioni di uscita. Gli agenti comunicano tramite lo scambio di messaggi, con un UserProxy che coordina il flusso di lavoro.
CrewAI implementa una pipeline sequenziale basata su attività. Utilizza Process.sequential, in cui gli agenti vengono eseguiti in un ordine fisso. Ogni agente completa la propria attività e genera un report prima che l'agente successivo inizi a lavorare.
LangChain segue un'architettura a catena lineare. Utilizza un AgentExecutor standard che incapsula il ciclo di chiamata degli strumenti. L'agente esegue gli strumenti in sequenza all'interno di un singolo contesto.
LangGraph struttura l'esecuzione come un grafo di stato ciclico. Utilizza StateGraph, con nodi che rappresentano le fasi di elaborazione e archi di instradamento condizionale, per determinare il flusso.
Swarm utilizza routine basate sul trasferimento di controllo. Si serve di funzioni transfer_to_agent per spostare dinamicamente il controllo tra gli agenti in base alle decisioni prese in fase di esecuzione.
I compiti sono diventati progressivamente più complessi per mettere alla prova diverse capacità di orchestrazione e modalità di guasto.
Attività 1 (2 agenti / 5 strumenti): Verifica il sovraccarico di orchestrazione di base per un flusso di lavoro semplice che richiede la raccolta di informazioni sull'ordine e la decisione sul rimborso.
Attività 2 (5 agenti / 20 strumenti): Verifica l'intelligenza di instradamento in presenza di rumore. Sono necessari solo 2-3 agenti e 3-5 strumenti, ma sono disponibili 5 agenti e 20 strumenti.
Attività 3 (10 agenti / 100 strumenti): Verifica il filtraggio ad alta entropia e i limiti di scalabilità. Sono necessari solo 2-3 agenti e 3-5 strumenti, ma sono disponibili 10 agenti e 100 strumenti, inclusi 98 strumenti di rumore irrilevanti progettati per confondere il routing.
Prossimo da leggere
Benchmark delle piattaforme di agenti AI: Claude Managed Agents vs Google Vertex Agent Engine
Il panorama della valutazione dei Master in Giurisprudenza (LLM) con i relativi framework
Framework RAG: LangChain vs LangGraph vs LlamaIndex
Creazione di agenti IA personali + 18 piattaforme e strumenti per agenti
Creazione di agenti di intelligenza artificiale con modelli componibili
Confronto tra framework di intelligenza artificiale agentica nei flussi di lavoro di analisi
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.