I 10 migliori framework agentic AI per creare agenti intelligenti
Introduzione ai framework agentic AI
Un framework agentic AI è un toolkit software che si occupa delle operazioni di “back‑end” necessarie per far funzionare gli agenti intelligenti. Ogni componente del toolkit svolge un ruolo specifico: orchestrazione, utilizzo di tool esterni, gestione della memoria e coordinamento multi‑agent. Comprendere queste funzioni è fondamentale per scegliere la soluzione più adatta al proprio progetto.
L’orchestrazione decide quale passo eseguire successivamente, indirizza i compiti all’agente o allo strumento corretto e stabilisce quando il flusso di lavoro è terminato. Può essere centralizzata, con un unico orchestratore decisionale, o decentralizzata, con agenti che comunicano peer‑to‑peer.
L’uso di tool permette agli agenti di superare i limiti del modello di linguaggio, chiamando API esterne, eseguendo funzioni o recuperando dati da altri sistemi.
La memoria e la gestione dello stato tengono traccia del contesto a due livelli: la memoria a breve termine, valida per una singola sessione, e la memoria a lungo termine, persistente tra sessioni e spesso basata su database esterni.
Il coordinamento multi‑agent gestisce i passaggi di mano quando più agenti devono collaborare, definendo chi fa cosa e quando il controllo passa da un agente all’altro.
Tipologie di architettura dei framework
Le architetture variano notevolmente e influenzano le decisioni, il flusso di stato e l’integrazione dei LLM. Le principali tipologie sono:
- Graph‑based: LangGraph e Microsoft Agent Framework. I nodi e gli archi definiscono il flusso di esecuzione, offrendo prevedibilità ma richiedendo più configurazione.
- Role‑based: CrewAI. Gli agenti hanno ruoli, obiettivi e backstory, collaborando all’interno di “crews”.
- Event‑driven: LlamaIndex Workflows. I passi sono attivati da eventi, con ramificazioni e loop, ideale per compiti documentali e RAG.
- Handoff‑based: OpenAI Agents SDK. Gli agenti passano compiti tramite primitive di handoff, semplificando il modello multi‑agent.
- Full‑stack platform: Agno. Unisce SDK, runtime AgentOS e piano di controllo per sistemi singoli o multi‑agent.
- Type‑safe functional: PydanticAI. Usa modelli Pydantic per validare input e output, catturando errori a compile‑time.
- Code‑executing: Smolagents. L’agente scrive ed esegue codice Python, riducendo le chiamate LLM del ~30% rispetto a agenti basati su JSON.
- Pipeline‑based: Haystack. Connette componenti in grafi di elaborazione diretti, nato per la ricerca enterprise e ora esteso a orchestrazione generale.
- Workflow‑based: Mastra. Workflow TypeScript con memoria integrata e compressione, pensato per sviluppatori JavaScript/TypeScript.
Panoramica dei 10 framework
1. LangGraph
Architettura: graph‑based
Linguaggi: Python, JavaScript
Multi‑agent: nativo
Memoria/stato: checkpointing e “time travel”
Sovrintendenza umana: primitive Interrupt()
Caso d'uso ideale: workflow di produzione con stato persistente, dove il controllo esplicito e la revisione umana sono prioritari.
LangGraph consente di modellare i flussi come grafi diretti con transizioni di stato esplicite. Supporta sia Python che JavaScript e permette l’integrazione di tool MCP tramite adattatori. La piattaforma gestita LangSmith fornisce endpoint A2A, ma la versione open‑source non li include.
Pro:
- Checkpointing con “time travel”: possibilità di tornare a uno stato precedente per debug o ripresa.
- Interruzione umana tramite
Interrupt()senza workaround. - Provata scalabilità: Klarna ha migrato il proprio assistente AI su LangGraph per più di 85 milioni di utenti attivi.
Contro:
- Curva di apprendimento ripida a causa di concetti di grafo e schemi di stato.
- A2A disponibile solo nella versione gestita.
- Costi di osservabilità aggiuntivi tramite LangSmith.
Prezzo: open‑source gratuito; LangSmith offre un tier gratuito (5 000 tracce/mese) e piani a partire da 39 USD/seat/mese.
2. CrewAI
Architettura: role‑based
Linguaggi: Python
Multi‑agent: nativo con “crews”
Memoria/stato: API unificata per memoria e stato di flusso
Sovrintendenza umana: gate di approvazione nel piano di controllo
Caso d'uso ideale: prototipazione rapida di sistemi multi‑agent basati su ruoli ben definiti.
CrewAI permette di definire agenti con backstory, obiettivi e tool, raggruppandoli in crew che collaborano in modo orchestrato. Include “Flows”, un livello event‑driven che aggiunge routing deterministico alle collaborazioni LLM‑driven.
Pro:
- Velocità di prototipazione grazie a ruoli predefiniti.
- Supporto nativo per A2A senza costi aggiuntivi.
- Gate di approvazione integrati per controllo umano.
Contro:
- Meno controllo granulare rispetto a un grafo esplicito.
- Limitato a Python, quindi meno flessibile per team polyglot.
3. Microsoft Agent Framework
Architettura: graph‑based
Linguaggi: Python, .NET, Go
Multi‑agent: nativo
Memoria/stato: persistente e plug‑in
Sovrintendenza umana: approvazioni di primo livello
Caso d'uso ideale: soluzioni enterprise integrate nell’ecosistema Microsoft.
Il framework offre un modello di grafo con nodi configurabili in Python, .NET o Go, e supporta plug‑in per memorie persistenti. Le approvazioni di primo livello sono integrate, rendendolo adatto a contesti aziendali con requisiti di governance.
Pro:
- Compatibilità con l’intero stack Microsoft (Azure, Teams, Power Platform).
- Supporto a più linguaggi, facilitando l’integrazione con codebase esistenti.
- Persistenza della memoria plug‑in, personalizzabile.
Contro:
- Maggiore complessità di configurazione rispetto a soluzioni più leggere.
- Dipendenza dall’ecosistema Microsoft, limitando la portabilità.
4. LlamaIndex Workflows
Architettura: event‑driven
Linguaggi: Python
Multi‑agent: supportato
Memoria/stato: archiviazione di sessione
Sovrintendenza umana: manuale
Caso d'uso ideale: pipeline RAG e flussi documentali intensivi.
LlamaIndex Workflows attiva i passi in risposta a eventi, con supporto per branch e loop. La memorizzazione di sessione è integrata, ma la supervisione umana richiede implementazioni manuali.
Pro:
- Facile integrazione con modelli Llama e altre API di embedding.
- Buona per flussi basati su documenti e retrieval‑augmented generation.
Contro:
- Mancanza di strumenti di supervisione automatica.
- Limitata gestione di memoria a lungo termine senza estensioni.
5. OpenAI Agents SDK
Architettura: handoff‑based
Linguaggi: Python, TypeScript
Multi‑agent: nativo
Memoria/stato: configurabile, sessioni
Sovrintendenza umana: tool approval e guardrails
Caso d'uso ideale: agenti ottimizzati per l’ecosistema OpenAI con bassa frizione.
Il SDK consente di passare compiti tra agenti tramite primitive di handoff, con memoria configurabile e meccanismi di approvazione dei tool per garantire sicurezza.
Pro:
- Integrazione nativa con i modelli OpenAI più recenti.
- Guardrails e approvazione dei tool per mitigare usi indesiderati.
Contro:
- Modello di handoff meno granulare rispetto a un grafo completo.
- Dipendenza dall’API OpenAI, con costi variabili.
6. Agno
Architettura: agent‑platform
Linguaggi: Python
Multi‑agent: nativo con quattro modalità operative
Memoria/stato: sessione e vettoriale
Sovrintendenza umana: flussi di conferma utente
Caso d'uso ideale: piattaforme di agenti pronte per la produzione.
Agno combina SDK, runtime AgentOS e un piano di controllo per gestire sistemi singoli o multi‑agent in ambienti cloud. Le quattro modalità (ad esempio, batch, interattivo, streaming, cron) offrono flessibilità operativa.
Pro:
- Piattaforma completa “end‑to‑end”.
- Memoria vettoriale integrata per RAG.
- Flussi di conferma utente per supervisione.
Contro:
- Focalizzata su Python, limitando l’adozione da parte di team non‑Python.
- Richiede una configurazione iniziale più complessa rispetto a SDK leggeri.
7. PydanticAI
Architettura: type‑safe functional
Linguaggi: Python
Multi‑agent: supportato via Harness e Graph
Memoria/stato: iniezione di dipendenze
Sovrintendenza umana: gate di approvazione dei tool
Caso d'uso ideale: output strutturati e validati a livello di tipo.
PydanticAI utilizza modelli Pydantic per garantire che input e output rispettino schemi predefiniti, riducendo gli errori a runtime.
Pro:
- Validazione statica dei dati, riduzione di bug.
- Gate di approvazione per tool, migliorando la sicurezza.
Contro:
- Richiede familiarità con Pydantic e tipizzazione avanzata.
- Non orientato a linguaggi diversi da Python.
8. Smolagents
Architettura: code‑executing
Linguaggi: Python
Multi‑agent: supportato
Memoria/stato: effimera
Sovrintendenza umana: manuale
Caso d'uso ideale: agenti leggeri con codice eseguibile, rapidi da prototipare.
Gli agenti scrivono e eseguono script Python direttamente, riducendo la dipendenza da chiamate LLM per la generazione di JSON. Questo approccio diminuisce i costi di token di circa il 30%.
Pro:
- Minimo codice necessario per definire un agente.
- Efficienza operativa grazie all’esecuzione di codice nativo.
Contro:
- Memoria effimera, non adatta a scenari con stato persistente.
- Richiede attenzione alla sicurezza del codice eseguito.
9. Haystack
Architettura: pipeline‑based
Linguaggi: Python
Multi‑agent: supportato
Memoria/stato: document store integrato
Sovrintendenza umana: intercept di tool in human‑in‑the‑loop
Caso d'uso ideale: ricerca su larga scala e RAG con capacità di orchestrazione agentica.
Haystack collega componenti in grafi di elaborazione diretti, originariamente per la ricerca enterprise, ora esteso a workflow agentici completi.
Pro:
- Supporto nativo a store di documenti e indici di embedding.
- Human‑in‑the‑loop per interventi manuali sui tool.
Contro:
- Curva di apprendimento medio‑alta per configurare pipeline complesse.
- Focalizzato su casi d'uso di ricerca, meno su agenti generali.
10. Mastra
Architettura: workflow‑based
Linguaggi: TypeScript
Multi‑agent: nativo
Memoria/stato: memoria integrata e compressione
Sovrintendenza umana: manuale
Caso d'uso ideale: sviluppo di agenti in ambienti TypeScript/JavaScript.
Mastra offre workflow scritti in TypeScript con memoria nativa e compressione dei dati, rendendo più semplice la gestione di stati complessi per sviluppatori JavaScript.
Pro:
- Prima scelta per team che usano già TypeScript.
- Memoria compressa per ridurre overhead.
Contro:
- Meno maturo rispetto a soluzioni Python più consolidate.
- Documentazione ancora in fase di espansione.