I migliori 10+ framework e strumenti di orchestrazione agentica

• Dieci framework sono vicini tra loro per costi e velocità: 1.000 esecuzioni costano circa da 1.4 a 1.7 USD, e un'esecuzione richiede in media da 12 a 14 secondi.
• Google ADK, smolagents e Microsoft Agent Framework si distinguono: costano circa da 1.6 a 1.9 volte in più, e un'esecuzione richiede in media da 1 a 5 secondi in più.
• I framework più economici (LangGraph, LangChain, Agno) hanno impiegato circa 1 secondo in più per esecuzione rispetto al gruppo più veloce: Strands, OpenAI Agents SDK, AutoGen, Pydantic IA e CAMEL.

L'agente attività aveva una sola regola: scegliere un'attività al chiuso se la probabilità di pioggia del giorno è pari o superiore al 50% o se sono previste piogge; altrimenti scegliere un'attività all'aperto. Tutti e tre i giorni erano soleggiati o nuvolosi con una probabilità di pioggia dal 5 al 10%, quindi la risposta corretta era un'attività all'aperto per ogni giorno.

Risultati del benchmark di orchestrazione agentica

Quando il modello pensava prima di rispondere, seguiva la regola ogni volta (388 su 388 esecuzioni). Quando rispondeva senza pensare, la seguiva solo nel 38% delle esecuzioni.

Lo stesso schema vale all'interno di ciascun framework. In LangGraph, ad esempio, il modello ha pensato in 3 esecuzioni e ha seguito la regola in tutte e 3; nelle esecuzioni in cui non ha pensato, la conformità è stata del 46%.

Il framework cambia la frequenza con cui il modello pensa. Il modello ha pensato nel 100% delle esecuzioni con Google ADK e smolagents, nell'86% con Microsoft Agent Framework e nel 78% con CrewAI. Negli altri 9 framework il tasso è stato dallo 0 al 9%.

Quando il modello non pensava, il formato dell'input determinava la conformità: dal 42 al 53% nei framework che passano l'istruzione invariata, 2% in Strands e 0% in AutoGen.

Perché il framework influenza il pensiero

Claude Haiku 5.5 decide per ogni richiesta se pensare, in base a ciò che riceve. Tutti i framework hanno inviato la stessa istruzione e gli stessi dati, ma l'architettura di ciascun framework determina cos'altro arriva con essi:

• Quanto contesto precedente riceve ciascun agente: i framework in stile pipeline passano all'agente attività solo i dettagli del viaggio e le previsioni (541 token, inclusa l'istruzione). Google ADK e Microsoft Agent Framework passano l'intera conversazione fino a quel punto, incluse le chiamate agli strumenti e i risultati precedenti (3.579 e 2.439 token).
• Quale template racchiude l'istruzione: smolagents la inserisce all'interno di un lungo template di sistema con regole per l'uso degli strumenti ed esempi (2.162 token). CrewAI la trasforma in un ruolo, un obiettivo e un “task corrente” con un output previsto.
• Come vengono presentati gli output degli agenti precedenti: possono arrivare come semplici blocchi di input, come messaggi di chat di altri agenti o come risposte precedenti dell'agente stesso.

La sola lunghezza non spiega il risultato. L'input di CrewAI per l'agente attività era di soli 648 token, eppure il modello ha pensato nel 78% delle esecuzioni. Quello di AutoGen era di 1.093 token e il modello ha pensato solo nel 9% delle esecuzioni. Sia la dimensione sia la struttura dell'input sembrano avere importanza.

Errori

Il modello non ha ignorato il meteo: ogni violazione è avvenuta in un giorno nuvoloso e nessuna esecuzione ha collocato un'attività al chiuso nel giorno soleggiato. La violazione più comune sono stati i Musei Vaticani, che hanno rappresentato l'87% delle scelte al chiuso. Senza pensare, il modello sembra aver considerato il cielo nuvoloso come tempo da attività al chiuso invece di applicare la regola del 50%. Quando il modello pensava, seguiva la regola ogni volta.

Framework che passano il testo invariato

Questi framework non aggiungono testo proprio; l'agente riceve esattamente ciò che scrive lo sviluppatore. Nel nostro test abbiamo scritto lo stesso input per tutti e sette, quindi l'agente attività ha ricevuto una richiesta identica in ciascuno. Il modello ha pensato in una quota di esecuzioni compresa tra lo 0% e il 3%, e la conformità è stata compresa tra il 42 e il 54%.

• LangGraph: ogni agente è un nodo in un grafo di stato. Il nodo legge gli output precedenti dallo stato condiviso e costruisce il proprio messaggio.
• LangChain: gli agenti sono passaggi di una catena LCEL. Ogni passaggio costruisce il proprio messaggio a partire dai valori passati lungo la catena.
• Agno: ogni agente è un passaggio di un workflow. Il passaggio legge gli output dei passaggi precedenti in base al nome.
• LlamaIndex: ogni agente è un passaggio di un workflow guidato dagli eventi. Gli eventi trasportano gli output precedenti al passaggio successivo.
• OpenAI Agents SDK: gli agenti vengono chiamati uno dopo l'altro nel codice. I passaggi di consegna dell'SDK consentono al modello di scegliere l'agente successivo, quindi non li abbiamo usati per una sequenza fissa.
• Pydantic IA: gli agenti vengono chiamati uno dopo l'altro nel codice, seguendo lo schema di passaggio programmatico descritto nella documentazione.
• CAMEL: gli agenti vengono chiamati uno dopo l'altro nel codice. La funzionalità Workforce aggiunge un agente coordinatore con chiamate extra al modello, quindi non l'abbiamo usata.

Framework che aggiungono il proprio formato

• CrewAI: colloca l'istruzione nel proprio template “ruolo, retroscena, obiettivo” e presenta il passaggio come “task corrente” con un output previsto, seguito dagli output dei task precedenti. L'input dell'agente attività era di soli 648 token, eppure il modello ha pensato nel 78% delle esecuzioni e l'86% delle esecuzioni ha seguito la regola.
• smolagents: ogni istruzione viene inserita nel lungo template di sistema di smolagents, che spiega come chiamare gli strumenti, fornisce esempi e regole e richiede la risposta tramite uno strumento final_answer. Con questo template, sia il pensiero sia la conformità alla regola hanno raggiunto il 100%.
• Google ADK: le risposte degli agenti precedenti, le chiamate agli strumenti e i risultati degli strumenti arrivano uno alla volta come note “Per contesto”, e ogni istruzione riceve una riga di identità. Con questo input da 3.579 token, il modello ha pensato prima di ogni risposta e non ha mai violato la regola.
• Microsoft Agent Framework: l'agente riceve l'intera conversazione, incluse le chiamate agli strumenti, con gli output degli agenti precedenti presentati come proprie risposte precedenti; l'opzione richiesta da Claude aggiunge “per favore continua.” alla fine. Il modello ha pensato in 86 esecuzioni su 100 e la conformità ha raggiunto il 92%.
• AutoGen: nella conversazione di gruppo di AutoGen, le risposte degli agenti precedenti raggiungono ciascun agente come messaggi di chat. Il modello ha pensato solo in 9 esecuzioni e quelle 9 sono state le uniche a seguire la regola.
• Strands: gli input arrivano sotto le intestazioni “Attività originale” e “Input dai nodi precedenti”. In questo formato il modello non ha mai pensato e ha seguito la regola solo in 2 esecuzioni su 100.

Alcuni di questi formati sono configurabili; Google ADK e Microsoft Agent Framework, ad esempio, dispongono di impostazioni che restringono la conversazione ricevuta da ciascun agente. Abbiamo usato le impostazioni predefinite in ogni framework.

Questi risultati provengono da Claude Haiku 5.5, che decide per ogni richiesta se pensare. Altri LLM possono comportarsi diversamente, quindi il divario tra i framework può essere minore o maggiore con un altro modello.

Raccomandazioni dal nostro test

• Testate una regola con il framework e il modello che intendete mettere in produzione. Un'istruzione che funziona in un framework potrebbe non dare lo stesso risultato in un altro.
• Se una regola è importante, usate un'impostazione di ragionamento più alta o attivate il pensiero. Con l'impostazione media che abbiamo usato, il modello ha saltato il pensiero nella maggior parte delle esecuzioni; ogni esecuzione in cui ha pensato ha seguito la regola, al costo di più tempo e più token.
• Se una regola è semplice ed esatta (ad esempio, “al chiuso se la probabilità di pioggia è superiore al 50%”), verificatela nel codice invece di lasciarla al modello. Un piccolo passaggio di validazione sull'output dell'agente intercetta l'errore in qualsiasi framework.
• Nei framework che inviano a ciascun agente l'intera conversazione, restringere il contesto riduce i costi. Nel nostro test, tuttavia, quei framework hanno anche innescato più pensiero, quindi verificate che la conformità alla regola rimanga valida dopo averlo ristretto.

Overhead dei framework e tempo di completamento

• Il codice dei framework ha aggiunto da 55 a 148 ms per esecuzione, circa l'1% del totale. Il resto è stato il tempo di risposta del modello.
• L'overhead non predice la velocità. Strands, uno dei framework più veloci, aveva un overhead elevato (115 ms); Microsoft Agent Framework, il più lento, aveva un overhead basso (73 ms).
• Le chiamate extra al modello contano di più. Una chiamata ripetuta a uno strumento o un passaggio extra aggiunge una chiamata al modello, ovvero da 1 a 3 secondi.
• Il tempo di esecuzione variava di circa 2 secondi da un'esecuzione all'altra all'interno di ciascun framework, quindi differenze inferiori a circa mezzo secondo tra i framework rientrano nel rumore.

Cosa inviano i framework a ciascun agente e uso dei token

Il pianificatore di viaggio è l'ultimo agente del workflow. Combina gli output dei quattro agenti precedenti in un piano giorno per giorno e ha bisogno solo di quei quattro output, ma i framework gli hanno inviato quantità di testo molto diverse. I numeri seguenti sono i token di prompt per esecuzione, sommati su tutti e cinque gli agenti.

Framework che passano solo gli input necessari

Questi framework eseguono gli agenti come passaggi di una pipeline. Il pianificatore riceve 2 messaggi: la sua istruzione e i quattro output. Piccole differenze derivano dal modo in cui ciascun framework scrive le definizioni degli strumenti.

• Agno: 6.052 token.
• LangGraph: 6.053 token.
• LangChain: 6.054 token.
• CAMEL: 6.094 token.
• OpenAI Agents SDK: 6.235 token. Le sue definizioni degli strumenti sono più lunghe.
• Pydantic IA: 6.411 token. Le sue definizioni degli strumenti sono più lunghe.
• LlamaIndex: 6.590 token. Le sue descrizioni degli strumenti includono la firma completa della funzione e la docstring.

Framework che aggiungono un template o input extra

• CrewAI: 7.456 token. Avvolge ogni istruzione nel suo template “ruolo, retroscena, obiettivo”, presenta il passaggio come un task con un output previsto e aggiunge gli output dei task precedenti come contesto.
• Strands: 7.693 token. Ripete la richiesta dell'utente a ogni agente come blocco “Attività originale”. Gli archi che mantengono in ordine gli agenti forniscono anche a alcuni agenti input extra; l'agente meteo, ad esempio, riceve l'output dell'agente voli.
• smolagents: 16.576 token. Avvolge ogni istruzione nel proprio grande template, che spiega l'uso degli strumenti e include esempi. Il prompt del primo agente era di 1.686 token, contro 173 nella maggior parte degli altri framework.

Framework che condividono l'intera conversazione

Questi framework eseguono gli agenti come una squadra che condivide un'unica conversazione, quindi ogni agente vede ciò che è avvenuto prima.

• AutoGen: 8.419 token. Passa solo le risposte finali degli agenti precedenti, come messaggi di chat; il pianificatore ha ricevuto 6 messaggi.
• Microsoft Agent Framework: 13.252 token. Passa l'intera conversazione, incluse le chiamate agli strumenti e i risultati degli strumenti precedenti; il pianificatore ha ricevuto 11 messaggi.
• Google ADK: 17.315 token. Inoltra ogni risposta precedente, chiamata a uno strumento e risultato di uno strumento come nota separata “Per contesto”; il pianificatore ha ricevuto 10 messaggi. L'input dell'agente meteo era di 6.358 token, contro circa 1.800 nei framework a pipeline.

Effetto su costi e correttezza

• La correttezza non è stata influenzata. In tutti e 13 i framework i dati sono arrivati integri al pianificatore, con un'eccezione in una singola esecuzione di Microsoft Agent Framework.
• I costi sono stati influenzati. 1.000 esecuzioni costano circa 1.4 USD nei framework a pipeline e da 2.4 a 2.8 USD in Microsoft Agent Framework, Google ADK e smolagents.
• In Google ADK, smolagents, Microsoft Agent Framework e CrewAI, il modello ha pensato più spesso. Questo ha allungato le esecuzioni ma ha aumentato la conformità alla regola.

Affidabilità

• Tutte le 1.300 esecuzioni sono state completate senza errori o timeout.
• In 1.299 esecuzioni su 1.300, i dati sono arrivati correttamente al piano finale.
• L'unico errore si è verificato in Microsoft Agent Framework. Il pianificatore di viaggio aveva tutte le offerte di volo nel proprio input ma ha lasciato vuoti i campi del volo. Questo può aver contribuito: Microsoft Agent Framework passa gli output degli agenti precedenti al pianificatore come se li avesse scritti lui stesso.

Chiamate extra al modello

Ogni chiamata extra al modello ha aggiunto da 1 a 3 secondi a un'esecuzione.

• CrewAI: in 12 esecuzioni su 100, l'agente voli ha ripetuto la stessa ricerca di voli, con gli stessi input, dopo aver ottenuto il risultato.
• smolagents: accetta una risposta solo tramite il suo strumento final_answer. In 14 esecuzioni su 100, il modello ha prima risposto in testo semplice, quindi smolagents ha avuto bisogno di un ulteriore passaggio.

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

Aggiungi come fonte preferita

Impostazioni predefinite che hanno richiesto modifiche

Abbiamo dovuto modificare alcune impostazioni predefinite per far eseguire ai framework questo workflow:

• Microsoft Agent Framework: la sua catena sequenziale non funzionava affatto con Claude (HTTP 400). La catena invia a ciascun agente una conversazione che termina con la risposta dell'agente precedente, che Claude rifiuta. L'opzione ensure_trailing_user_turnoption risolve il problema aggiungendo un messaggio utente alla fine della conversazione.
• Agno: per impostazione predefinita, il suo workflow salta un passaggio non riuscito e riporta comunque l'esecuzione come riuscita. Abbiamo impostato il criterio di errore dello step su “fail” affinché gli errori emergano.
• Strands: il suo grafo avvia un agente non appena uno qualsiasi degli agenti da cui dipende termina. Con archi semplici, il pianificatore verrebbe eseguito troppo presto e più volte, quindi abbiamo aggiunto condizioni agli archi per mantenere l'ordine.
• smolagents: obbliga il modello a chiamare uno strumento a ogni passaggio. Claude lo rifiuta quando il pensiero è attivo, quindi l'abbiamo impostato su “auto”.
• OpenAI Agents SDK: usa per impostazione predefinita l'API Responses di OpenAI. Per usarla con un endpoint Chat Completions, offerto dalla maggior parte degli altri provider, è necessaria la sua classe di modello Chat Completions.

Pipeline o conversazione condivisa per un workflow fisso

Quando l'ordine degli agenti è fisso, ogni agente ha bisogno solo di pochi output precedenti. Nel nostro test, passare solo quegli output ha spostato i dati tra gli agenti in modo affidabile quanto condividere l'intera conversazione: 1.299 esecuzioni su 1.300 erano corrette in entrambi i gruppi. La conversazione condivisa in Google ADK e Microsoft Agent Framework ha più che raddoppiato i token di prompt per esecuzione. Le conversazioni condivise sono adatte agli agenti che devono vedere i ragionamenti reciproci. In una pipeline fissa, passare input espliciti costa meno e si può vedere esattamente cosa riceve ciascun agente.

Controllate cosa invia il vostro framework al modello

Sette dei 13 framework hanno inviato all'agente attività esattamente il testo che abbiamo scritto. Gli altri sei hanno aggiunto template propri, messaggi inoltrati o intestazioni, da circa 50 token extra in Strands a oltre 3.000 in Google ADK. Tali aggiunte hanno cambiato la frequenza con cui il modello pensava e se seguiva la regola. Prima di ottimizzare i prompt in un sistema multi-agente, registrate la richiesta finale che ciascun agente invia al modello. Un proxy di registrazione o il tracing del framework mostra cosa ha aggiunto il framework.

Cosa determina la velocità di un workflow multi-agente

Il codice dei framework ha richiesto circa l'1% di ogni esecuzione. Il resto derivava dal numero di chiamate al modello e dal tempo impiegato da ciascuna chiamata. Ne derivano tre leve:

• Meno chiamate al modello: fate attenzione alle chiamate ripetute agli strumenti e ai passaggi extra; ognuna ha aggiunto da 1 a 3 secondi.
• Input più piccoli: input più brevi per ogni agente riducono i token e lasciano meno testo da leggere al modello.
• Agenti indipendenti in parallelo: in questo workflow gli agenti voli e meteo non dipendono l'uno dall'altro. Eseguirli in parallelo eliminerebbe il più breve dei due, circa 3 secondi. Non abbiamo testato l'esecuzione parallela; questa stima deriva dai tempi per singolo agente.

Metodologia del benchmark

Ogni framework ha eseguito lo stesso workflow di pianificazione del viaggio con cinque agenti, mantenendo gli agenti sempre in questo ordine:

1. Parser: estrae origine, destinazione, data di partenza e durata del viaggio dalla richiesta dell'utente.
2. Ricerca voli: chiama uno strumento di ricerca voli ed elenca le offerte per prezzo.
3. Reporter meteo: chiama uno strumento meteo per le date del viaggio.
4. Suggeritore di attività: sceglie un'attività al giorno, usando la regola al chiuso/all'aperto descritta sopra.
5. Pianificatore di viaggio: combina i quattro output in un piano giorno per giorno con il volo più economico.

La richiesta dell'utente era: “Voglio viaggiare da Berlino a Roma il 27 ottobre 2026. Resterò per 3 giorni.” Ogni agente aveva la stessa istruzione scritta in ogni framework e restituiva la risposta in JSON. Solo la ricerca voli e il reporter meteo disponevano di strumenti.

Dati degli strumenti

Entrambi gli strumenti restituivano dati fissi, quindi ogni esecuzione in ogni framework riceveva risultati identici dagli strumenti:

• Voli: sei offerte di sola andata da Berlino a Roma. Si tratta di dati sintetici: i vettori, gli orari e i prezzi plausibili non provengono da una ricerca tariffe in tempo reale.
• Meteo: una previsione reale di Roma per il periodo dal 27 al 29 ottobre 2026, registrata una volta da WeatherAPI.com.

Poiché gli strumenti rispondevano istantaneamente, i tempi di completamento riflettono le chiamate al modello e il codice dei framework, non la latenza dell'API.

Framework

• Versioni testate: LangGraph 1.2.17, LangChain 1.4.7, CrewAI 1.15.30, AutoGen 0.7.5, Microsoft Agent Framework 1.23.0, OpenAI Agents SDK 0.24.0, Google ADK 2.13.0, Agno 3.1.10, Pydantic IA 2.61.0, smolagents 1.26.0, LlamaIndex 0.14.25, Strands Agents 1.62.0 e CAMEL 0.2.90, tutti su Python 3.12.
• Come sono stati eseguiti gli agenti: ogni framework ha eseguito gli agenti con il proprio costrutto multi-agente laddove disponibile. OpenAI Agents SDK, Pydantic IA, smolagents e CAMEL non hanno un costrutto per una sequenza fissa, quindi i loro agenti sono stati chiamati uno dopo l'altro nel codice.
• Impostazioni: tutte le impostazioni sono rimaste ai valori predefiniti, tranne le modifiche elencate in “Impostazioni predefinite che hanno richiesto modifiche”.

Modello ed esecuzioni

• Modello: ogni agente in ogni framework ha utilizzato Claude Haiku 5.5 tramite OpenRouter, servito da Anthropic, con l'impostazione di ragionamento fissata su media. Le impostazioni che un framework tentava di aggiungere, come la temperatura, venivano rimosse prima che la richiesta raggiungesse il modello.
• Esecuzioni: ogni framework ha eseguito il workflow 100 volte, per un totale di 1.300 esecuzioni, il 27 ottobre 2026. Le esecuzioni sono state eseguite una alla volta, in ordine casuale tra i framework.
• Warm-up: prima di ogni esecuzione cronometrata, lo stesso workflow veniva eseguito una volta contro un modello di test simulato, in modo che i costi di caricamento una tantum non fossero conteggiati nel tempo misurato.
• Limiti: ogni esecuzione era limitata a 30 chiamate al modello e 300 secondi. Nessuna esecuzione ha raggiunto uno dei due limiti.

Cosa abbiamo misurato

• Richieste: un proxy di registrazione ha registrato ogni richiesta e risposta tra i framework e il modello. Ogni agente aveva il proprio endpoint, quindi ogni chiamata al modello poteva essere ricondotta all'agente che l'aveva effettuata. Le chiamate agli strumenti venivano registrate separatamente.
• Tempo di completamento: tempo dall'inizio del workflow fino al piano finale.
• Token e costi: token di prompt, di completamento e di pensiero e costo di ciascuna chiamata, come riportato dal provider.
• Overhead dei framework: la parte di un'esecuzione non trascorsa né ad attendere il modello né a eseguire strumenti.
• Pensiero: un'esecuzione viene conteggiata come esecuzione in cui il modello ha pensato se il provider ha riportato token di pensiero per la chiamata dell'agente attività.
• Itinerario corretto: il piano finale contiene il volo più economico (numero del volo e prezzo), le tre date del viaggio, il meteo di ciascun giorno come da previsione e l'attività e l'ambiente di ciascun giorno esattamente come prodotti dal suggeritore di attività.
• Conformità alla regola: tutti e tre i giorni seguono la regola al chiuso/all'aperto. Poiché nessun giorno aveva una probabilità di pioggia vicina al 50%, la risposta corretta era un'attività all'aperto per ogni giorno.

Cita questo benchmark

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

@misc{sipi2026,
  author = {Şipi, Nazlı},
  title  = {{I migliori 10+ framework e strumenti di orchestrazione agentica}},
  year   = {2026},
  month  = oct,
  howpublished    = {\url{https://aimultiple.com/agentic-orchestration}},
  note   = {AIMultiple. Consultato il 30 ottobre 2026}
}

Registro delle modifiche

4 aggiornamenti

Tutte4Generale3Metodologia1

20262025

1. 27 gen

   Rimossa la sezione "Agentic orchestration benchmark".

2. 26 gen

   Aggiornata la sezione 'Benchmark di orchestrazione agentica' con nuove metriche.

Nazlı Şipi

Ricercatrice IA

Segui

Nazlı è un'analista di dati presso AIMultiple. Ha precedente esperienza nell'analisi dei dati in diversi settori, dove ha lavorato per trasformare dataset complessi in informazioni operative.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento