Metodologia del test

Per valutare le performance dei principali framework di orchestrazione, abbiamo implementato lo stesso workflow di pianificazione viaggi su tredici piattaforme diverse, eseguendo ciascuna variante 100 volte. In totale sono state realizzate 1 300 iterazioni, a cui si aggiungono 100 run su OpenCode, utilizzato come agente di riferimento.

Il workflow prevede cinque agenti sequenziali:

    • Richiesta dell'utente: “Voglio viaggiare dal 27 ottobre 2026 da Berlino a Roma, per 3 giorni”.
    • Ricerca del volo (flight‑finder) – utilizza un tool dedicato.
    • Report meteo (weather‑reporter) – utilizza un tool dedicato.
    • Selezione dell'attività (activity‑agent) con regola specifica.
    • Pianificatore finale (itinerary‑planner) che aggrega le risposte in un piano giornaliero.

Ogni agente riceveva la stessa istruzione testuale e doveva restituire una risposta in formato JSON. Solo i due agenti intermedi (volo e meteo) facevano effettivo uso di tool; tutti gli altri operavano esclusivamente sul testo.

Regola dell’attività e comportamento del modello

L’attività‑agent doveva scegliere un’attività indoor se la probabilità di pioggia fosse ≥ 50 % o se fosse previsto temporale; altrimenti doveva proporre un’attività outdoor. Nei tre giorni di test il meteo era sempre soleggiato o nuvoloso con probabilità di pioggia compresa tra 5 % e 10 %, quindi la risposta corretta era sempre “outdoor”.

Abbiamo osservato due tipologie di comportamento del modello:

    • Pensare prima di rispondere (model “thought”).
    • Rispondere immediatamente (model “no‑thought”).

Quando il modello ha pensato, ha rispettato la regola in 100 % dei casi (388 su 388). Quando ha risposto senza pensare, la conformità è scesa al 38 %.

Esempio di LangGraph

Nel framework LangGraph il modello ha pensato in 3 run, rispettando la regola in tutti e tre. Nei rimanenti run, in cui non ha pensato, la percentuale di rispetto è stata del 46 %.

Influenza del framework sulla capacità di pensare

Il framework determina con quale frequenza il modello entra in modalità “thought”. I dati più significativi sono:

    • Google ADK e smolagents: 100 % di run con pensiero.
    • Microsoft Agent Framework: 86 %.
    • CrewAI: 78 %.
    • Altri 9 framework: da 0 % a 9 % di run con pensiero.

Quando il modello non pensa, il formato di input influisce sulla conformità: framework che trasmettono l’istruzione invariata mostrano una conformità tra 42 % e 53 %, Strands solo 2 %, e AutoGen 0 %.

Claude Haiku 5.5 come motore di base

Tutte le richieste sono state elaborate da Claude Haiku 5.5, che decide autonomamente se “pensare” o meno in base al contenuto ricevuto. Sebbene tutti i framework inviassero la stessa istruzione e gli stessi dati, la struttura interna di ciascuno ha determinato cosa veniva aggiunto al prompt.

Token, lunghezza e struttura dell’input

La lunghezza dell’input da sola non spiega le differenze. Ad esempio:

    • CrewAI invia solo 648 token per l’attività‑agent, ma il modello pensa in 78 % dei casi.
    • AutoGen invia 1 093 token, ma il modello pensa in appena 9 % dei casi.

Quindi sia la dimensione sia la struttura (presenza di template, messaggi di sistema, ecc.) sembrano influire sul comportamento “thought”.

Analisi delle violazioni della regola

Il modello non ha mai ignorato il meteo: tutte le violazioni si sono verificate in giorni nuvolosi, mai in giornate soleggiate. Il tipo di attività più frequentemente errato è stato “Musei Vaticani”, che ha rappresentato l’87 % delle scelte indoor.

Quando il modello non pensa, sembra trattare “nuvoloso” come equivalente a “condizioni indoor”, ignorando la soglia del 50 % di probabilità di pioggia. Quando pensa, rispetta la regola in ogni run.

Impatto delle aggiunte del framework al prompt

In tutti i test, gli agenti hanno ricevuto esattamente il testo scritto dallo sviluppatore, tranne per i framework che inseriscono automaticamente:

    • Template o intestazioni (da 50 token in Strands a oltre 3 000 token in Google ADK).
    • Messaggi di sistema aggiuntivi.

Queste aggiunte hanno influito sia sulla probabilità che il modello pensi sia sulla percentuale di conformità alla regola. Prima di ottimizzare i prompt in un sistema multi‑agente, è fondamentale registrare la richiesta finale inviata al modello per ogni agente, ad esempio tramite un proxy di logging o il tracing interno del framework.

Confronto con OpenCode

OpenCode 1.19.5 è stato eseguito come agente di coding open‑source, con tutti i tool di coding disattivati. Ogni agente è stato avviato in una sessione separata e il nostro codice ha passato l’output di un agente al successivo, replicando la logica di una pipeline.

Risultati:

    • OpenCode ha prodotto un piano corretto in 100 % delle 100 run.
    • Ha rispettato la regola meteo in 100 % dei casi, pari solo a Google ADK e smolagents.
    • L’unica differenza risiede in alcune righe aggiuntive inserite da OpenCode (nome del modello, blocco ambientale con cartella di lavoro, OS e data).

Configurazioni e impostazioni di default

Alcuni framework offrono opzioni configurabili. Google ADK e Microsoft Agent Framework, ad esempio, consentono di limitare la conversazione che ogni agente può vedere. Nei nostri test abbiamo mantenuto le impostazioni di default per garantire comparabilità.

Le differenze di performance tra i framework dipendono anche dalla modalità di passaggio dei dati:

    • Pipeline fissa: ogni agente riceve solo le uscite necessarie dei predecessori. Questo approccio ha mostrato 1 299 run corrette su 1 300, con consumo di token più contenuto.
    • Conversazione condivisa: tutti gli agenti vedono l’intera cronologia. In Google ADK e Microsoft Agent Framework il numero di token per run è più che raddoppiato, ma è necessario quando gli agenti devono considerare le ragioni degli altri.

Costi di esecuzione e tempi di risposta

Ogni chiamata al modello ha aggiunto 1‑3 secondi al tempo totale di una run. Il codice del framework ha consumato circa 1 % del tempo totale; il resto è stato speso in chiamate al modello e nella latenza di rete (escludendo l’API latency, poiché i tool hanno risposto istantaneamente).

Le tre leve principali per ottimizzare un workflow multi‑agente sono quindi:

    • Ridurre il numero di chiamate al modello (ad esempio, combinando più operazioni in un unico prompt).
    • Minimizzare la lunghezza dei prompt, evitando aggiunte inutili da parte del framework.
    • Scegliere la modalità di passaggio dei dati più adatta (pipeline vs conversazione condivisa) in base alle esigenze di contesto.

Raccomandazioni per la scelta del framework

Basandoci sui risultati, ecco alcune linee guida pratiche:

    • Massima affidabilità della regola: Google ADK, smolagents e OpenCode hanno garantito il rispetto al 100 % grazie all’alto tasso di “thought”.
    • Efficienza token‑wise: CrewAI e LangGraph mostrano un buon equilibrio tra consumo di token e tasso di pensiero (78 % e 46 % rispettivamente).
    • Flessibilità di contesto: se gli agenti hanno bisogno di vedere le ragioni degli altri, optare per un modello di conversazione condivisa, accettando l’aumento di token.
    • Semplicità di implementazione: Strands e AutoGen richiedono poca configurazione ma hanno tassi di pensiero molto bassi, con conseguente scarsa conformità alle regole.

Conclusioni

Il nostro studio dimostra che la scelta del framework di orchestrazione influisce significativamente sulla capacità del modello di “pensare”, sulla conformità a regole semplici e sui costi operativi in termini di token e tempo. Anche piccoli dettagli – come l’aggiunta di 50 token di intestazione – possono cambiare il comportamento del modello. Prima di adottare una soluzione, è fondamentale testare il workflow con il modello di destinazione, registrare le richieste finali inviate al modello e valutare il trade‑off tra contesto condiviso e efficienza.