Tipi di agenti AI: quali sono e quali puoi eseguire

Quali sono i tipi di agenti AI

I tipi di agenti AI derivano da una tassonomia: agenti a riflesso semplice, agenti a riflesso basati su modello, agenti basati su obiettivi, agenti basati sull'utilità e agenti con capacità di apprendimento. Ogni nome descrive un aspetto: quanto l'agente ricorda e con quanto anticipo pianifica prima di agire. Altri due termini, multi-agente e gerarchico, descrivono il modo in cui più agenti vengono collegati tra loro, non il modo in cui decide uno di essi.

Questa classificazione è più vecchia di qualsiasi modello tu abbia usato. Proviene dal manuale standard sull'intelligenza artificiale ed è sopravvissuta all'arrivo dei large language model perché pone la domanda che determina ancora il progetto: che cosa deve sapere questo sistema prima di agire? Se stai ancora cercando di capire dove finisca un agente e inizi un assistente basato su chat, leggi prima la differenza tra un agente AI e il LLM su cui viene eseguito. Questa pagina parte da quel punto.

Agenti riflessi semplici: una condizione, un'azione

Un agente riflesso semplice associa l'input corrente a un'azione e non conserva alcuna memoria degli eventi precedenti. Se la temperatura supera 25, accendi la ventola. Questo è l'intero meccanismo.

Ne hai quasi certamente già eseguito uno. Un webhook che attiva un workflow n8n, legge l'invio di un modulo e scrive una riga in un database è un agente riflesso semplice. Rimane tale anche quando al suo interno viene usato un modello linguistico per scegliere una categoria per quella riga. Se gli chiedi che cosa ha fatto un'ora prima, non può dirtelo, perché nessun componente ha conservato la risposta.

Questo tipo di agente è più spesso corretto di quanto ci si aspetti. Ha costi di esecuzione ridotti e i suoi errori sono facilmente interpretabili: la condizione corrispondeva oppure no. Quando il compito consiste davvero in "quando arriva X, esegui Y", la memoria introduce nuovi possibili errori senza offrire vantaggi. Un agente n8n attivato da un webhook rappresenta questo elemento della tassonomia con un'interfaccia utente.

Fallisce nel momento in cui l'azione corretta dipende dalla cronologia. Un bot per le risposte privo dello stato della conversazione si contraddirà al terzo messaggio, perché i primi due messaggi non hanno mai fatto parte del suo input.

Agenti riflessivi basati su un modello: mantenere lo stato tra gli eventi

Un agente riflessivo basato su un modello conserva una rappresentazione interna dell’ambiente e la aggiorna quando arriva un nuovo input. In questo caso, il termine «modello» indica un modello del mondo, non una rete neurale. Il termine precede di circa quaranta anni il significato attuale e, alla prima lettura, genera confusione in quasi tutti.

Una regola di automazione domestica che spegne le luci dopo venti minuti senza rilevare movimento è basata su un modello. Deve esserlo. «Nessun movimento in questo momento» e «nessun movimento dalle 21:40» sono lo stesso input per un semplice agente riflessivo. Solo lo stato memorizzato consente di distinguerli.

Nel contesto degli LLM, si tratta di qualsiasi agente che utilizzi un archivio di memoria: un riepilogo progressivo della conversazione oppure un semplice file markdown che l’agente legge all’inizio di ogni esecuzione. Un servizio di memoria locale per un agente applica questa idea in forma pronta all’uso. Il meccanismo non cambia. La rappresentazione del mondo dell’agente sopravvive all’evento che l’ha generata.

Lo stato ha un costo. Un’informazione obsoleta è peggiore dell’assenza di informazioni, perché l’agente agisce su di essa con piena fiducia e senza avvisi. Ogni dato memorizzato deve poter scadere oppure essere verificato nuovamente. In caso contrario, l’agente continuerà a ragionare su un server dismesso a marzo.

Agenti basati su obiettivi: pianificare verso uno stato verificabile

Un agente basato su obiettivi riceve uno stato obiettivo e cerca una sequenza di azioni per raggiungerlo. Procede a ritroso dal risultato che deve ottenere, quindi il percorso non viene definito in anticipo.

Un agente di coding è l'esempio più semplice da eseguire direttamente. «Fai passare il test che non riesce» non specifica alcun file né alcun passaggio. L'agente legge il test, elabora un piano, modifica qualcosa, esegue il test, legge l'errore e riprova. Il ciclo termina con una verifica che può eseguire concretamente. Per questo l'istruzione funziona, mentre «migliora questo codice» non funziona. Un obiettivo che l'agente può valutare è un obiettivo che può raggiungere. Un obiettivo che non può valutare diventa un ciclo infinito con un costo associato. Eseguire un agente di coding sul proprio VPS sposta questo ciclo in un ambiente in cui può continuare a lavorare senza occupare il laptop.

Il costo si concentra in questo ciclo. Ogni passaggio di pianificazione genera un'altra chiamata al modello, che include tutta la cronologia accumulata fino a quel momento. Perciò un'attività in dieci passaggi non costa dieci volte una singola operazione: costa di più. L'aspetto ingegneristico rilevante è la struttura del ciclo e la condizione che lo interrompe. Questo è l'argomento di progettazione dei cicli.

Agenti basati sull'utilità: scelta tra più risposte valide

Un obiettivo è binario. L'utilità è un punteggio. Un agente basato sull'utilità si trova di fronte a diversi risultati accettabili e sceglie quello con il punteggio più alto in base a una funzione definita dall'utente.

Un processo di backup che deve terminare prima dell'inizio della giornata lavorativa senza saturare l'uplink è un problema di utilità. Non esiste un'unica risposta corretta, ma solo un compromesso. Un router che decide quale modello deve gestire ogni richiesta, valutando il costo rispetto alla qualità della risposta, presenta la stessa struttura.

L'algoritmo non è l'aspetto più difficile. Lo è definire una funzione di utilità corretta. Se assegni un punteggio basato soltanto sul costo, il sistema sceglierà il modello più economico per ogni richiesta, anche per quella che richiedeva il modello più costoso. Il sistema ottimizza esattamente ciò che hai misurato. Questo diventa un problema quando hai scelto quella metrica solo perché era facile da misurare.

Agenti con apprendimento: il tipo che molti presumono di avere già

Un agente con apprendimento modifica il proprio comportamento sulla base del feedback sui risultati precedenti. Ha bisogno di un componente che valuti il risultato e di un componente che modifichi la policy in risposta.

Pochissimi sistemi self-hosted rientrano in questa categoria. Un agente che legge note scritte da sé la settimana precedente è un agente basato su modello con un file di memoria. I suoi pesi sono identici. La sua policy è identica. Il recupero delle informazioni non è apprendimento e la distinzione è pratica: un sistema basato sulla memoria ripete un errore indefinitamente, a meno che qualcuno non modifichi la memoria, mentre un sistema con apprendimento dovrebbe smettere di commetterlo.

Se vuoi la parte relativa all'apprendimento, costruisci prima la valutazione. Un set di test con punteggi, un'esecuzione della modifica su quel set e una decisione per mantenere o scartare la modifica costituiscono un ciclo chiuso in cui il componente con apprendimento sei tu. È più lento di quanto sembri ed è l'unica versione che oggi funziona con componenti self-hosted. Configurare autonomamente un eval harness è il punto di partenza.

Sistemi multi-agente e gerarchici: configurazioni, non tipi

Questi non sono un sesto e un settimo tipo. Descrivono come sono organizzati gli agenti.

Un sistema multi-agente esegue contemporaneamente diversi agenti all'interno di un ambiente condiviso, ad esempio una coda o un repository git. Poiché l'ambiente è condiviso, gli agenti possono interferire tra loro. Due agenti che modificano lo stesso file sono il caso di errore più comune; la soluzione consiste nell'usare un lock o una coda di lavoro. Nessun prompt risolve il problema.

Un sistema gerarchico colloca un supervisore al di sopra dei worker. Il supervisore suddivide un'attività, assegna le singole parti e unisce i risultati ricevuti. Questo modello è diffuso perché corrisponde al modo in cui le persone dividono il lavoro, ma è costoso perché il contesto del supervisore cresce con ogni report che legge. Un harness multi-agente mostra come realizzare questo collegamento in pratica.

Un agente che funziona è meglio di quattro che funzionano solo in parte.

Ogni passaggio di consegne può causare la perdita di informazioni. Inizia con un solo ciclo. Suddividilo soltanto quando puoi identificare il passaggio che costituisce il collo di bottiglia.

Perché quasi ogni sistema reale è ibrido

Consideriamo un deployment agent che potreste eseguire autonomamente. Un webhook lo avvia: questo è un comportamento riflesso. L’agent legge lo stato della release corrente: questo si basa su un modello. Pianifica i passaggi dalla versione in esecuzione a quella di destinazione: questo si basa su un obiettivo. Sceglie una finestra di rollout in base al carico corrente: questo si basa sull’utilità. Non modifica mai la propria policy, quindi non apprende.

Un solo sistema comprende contemporaneamente quattro categorie della tassonomia. La tassonomia è utile come checklist di progettazione, non come etichetta da applicare al prodotto finito. Quando il sistema si comporta in modo errato, la domanda utile è quale livello sia in errore. Un trigger attivato dall’evento sbagliato, uno stato diventato obsoleto, un controllo dell’obiettivo che non può mai avere esito positivo e un punteggio che premia il risultato sbagliato sono quattro bug diversi, con quattro correzioni diverse.

Quale tipo è adatto a quale compito

• Trigger fisso, risposta fissa, nessuna cronologia necessaria: riflesso semplice.
• La risposta corretta dipende da ciò che è accaduto in precedenza: riflesso basato sul modello.
• Lo stato finale è verificabile, ma il percorso non è noto in anticipo: orientato agli obiettivi.
• Sono possibili diversi risultati accettabili, con un compromesso reale tra loro: basato sull'utilità.
• Se servono risultati migliori nel tempo, crea un ciclo di valutazione e considera te stesso il componente di apprendimento.

È possibile ospitare autonomamente questi agenti? Quanto costa?

Sì, e il costo si divide in due componenti. L’orchestrazione costa poco. Un’istanza n8n o un ciclo agente in Python trascorre la maggior parte del tempo in attesa di chiamate di rete, quindi 2 vCPU e 4 GB di RAM sono sufficienti. Il modello è la componente più costosa.

Se l’agente chiama un’API gestita, al server serve quasi nulla e il costo cresce in base al numero di token. Per un agente basato su obiettivi, il costo cresce quindi in base al numero di passaggi di pianificazione consentiti. Imposta un limite per il ciclo.

Se esegui il modello sul tuo hardware, la RAM determina quali modelli puoi eseguire. Le cifre riportate di seguito sono dimensioni tipiche pubblicate dei file per pesi quantizzati a 4 bit ad agosto 2026, affiancate da una stima della RAM totale necessaria, perché la finestra di contesto e il runtime richiedono memoria aggiuntiva oltre a quella occupata dai pesi.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

Un modello 8B a 4 bit occupa circa 4.9 GB di pesi; un sistema con 10 GB di RAM può eseguirlo senza ricorrere allo swap. Un modello 70B con la stessa quantizzazione occupa 43 GB di pesi e richiede circa 64 GB di RAM. Queste cifre non indicano però la velocità. Su una VPS senza GPU, un modello 8B a 4 bit produce pochi token al secondo. È sufficiente per un agente che elabora una coda durante la notte, ma è troppo lento per le attività interattive che una persona sta aspettando. Usa l’inferenza locale per i lavori batch e una GPU o un’API per le attività interattive. La selezione degli agenti AI eseguibili autonomamente indica quali progetti giustificano lo spazio su disco, mentre un percorso di apprendimento sugli agenti nel 2026 indica cosa imparare e in quale ordine.

Quando la tassonomia non è più utile

Non dice nulla sugli strumenti o sulle autorizzazioni. Gli agenti descritti nei manuali percepiscono e agiscono. Chi ha scritto quel capitolo non si preoccupava di un agente in possesso di un token API di produzione. Un agente basato sugli obiettivi con accesso alla shell e un agente basato sugli obiettivi con una sola connessione in sola lettura a un database occupano la stessa riga della tabella, ma presentano rischi completamente diversi. Stabilite che cosa può toccare un agente prima di decidere quanto debba essere sofisticato e leggete come impedire che i secret restino esposti in un agente AI prima di assegnargli una credenziale.

Inoltre, non dice nulla su ciò che accade quando un passaggio non riesce. Gli agenti reali trascorrono gran parte del tempo di esecuzione a gestire gli errori: un rate limit o uno strumento che restituisce un risultato inatteso per il modello. È quel codice a determinare se il sistema è utilizzabile, ma nessuna riga della tassonomia lo descrive.

FAQ

Quali sono i cinque tipi di agenti AI?

Agenti a riflesso semplice, a riflesso basato su modello, basati su obiettivi, basati sull'utilità e agenti con apprendimento. Sono ordinati in base a quanto l'agente conosce prima di agire. Un agente a riflesso semplice vede solo l'input corrente. Un agente basato su modello conserva lo stato dell'ambiente. Un agente basato su obiettivi pianifica il raggiungimento di uno stato target. Un agente basato sull'utilità assegna un punteggio a diversi risultati accettabili e sceglie quello con il punteggio più alto. Un agente con apprendimento modifica la propria policy in base al feedback, cosa che quasi nessuna configurazione self-hosted esegue realmente.

Quale tipo di agente AI dovrei usare per una semplice automazione?

Un agente a riflesso semplice, che in pratica consiste in un webhook o in una pianificazione che attiva una sequenza fissa. Se la risposta corretta dipende solo dall'input appena ricevuto, la memoria aggiunge possibilità di errore senza offrire nuove funzionalità. Passa a una progettazione basata su modello quando puoi indicare una decisione che deve conoscere ciò che è accaduto prima.

Posso eseguire i miei agenti AI su un VPS?

Sì. Il livello di orchestrazione è leggero, quindi 2 vCPU e 4 GB di RAM eseguono comodamente un workflow engine o un agent loop. La decisione reale riguarda il luogo in cui viene eseguito il modello. Un'API in hosting mantiene contenute le risorse del server e sposta il costo sui token. Un modello locale richiede una quantità di RAM proporzionale al numero di parametri e, senza una GPU, genera una quantità a una cifra di token al secondo. È quindi adatto al lavoro batch in coda, non a una finestra di chat.

Un large language model è di per sé un agente AI?

No. Un modello converte il testo di input in testo di output e poi si arresta. Diventa un agente quando un componente lo inserisce in un loop che può agire sull'ambiente e reinserire il risultato nel loop. A questo servono strumenti che il modello possa chiamare e una condizione che indichi al loop quando arrestarsi. L'agente è il componente wrapper. Il modello è uno dei componenti al suo interno.

Ho bisogno di un sistema multi-agent?

Di solito no. Un singolo loop con diversi strumenti gestisce la maggior parte delle attività ed è molto più semplice da sottoporre a debug. Più agenti sono utili quando alcune parti di un'attività sono realmente indipendenti e possono essere eseguite contemporaneamente, oppure quando una parte richiede un modello diverso. Il costo è il coordinamento: stato condiviso e un supervisor il cui contesto cresce a ogni report dei worker che legge. Aggiungi il secondo agente quando puoi indicare il passaggio che è lento.