Definizione in una frase
Sistema que utiliza un modelo para decidir pasos, mantener estado y operar herramientas bajo objetivos, permisos y reglas definidos.
Che cos’è un agente di IA
Un agente di IA è un sistema che riceve informazioni dall’ambiente, seleziona azioni in funzione di un obiettivo e osserva che cosa accade in seguito per decidere se proseguire, cambiare strategia o fermarsi. La parola importante è «sistema»: l’agente non coincide necessariamente con un modello di intelligenza artificiale preso isolatamente. Può comprendere un modello o una politica di controllo, istruzioni, informazioni contestuali, strumenti, un ambiente e regole che limitano le azioni possibili.
Questa definizione descrive un ciclo di percezione, decisione e azione. Non richiede che il sistema abbia una personalità, coscienza, memoria permanente né libertà di fare qualsiasi cosa. E non presuppone che utilizzi un modello linguistico di grandi dimensioni (LLM). Il quadro classico degli agenti è più ampio degli attuali assistenti generativi: questi ultimi sono una possibile famiglia di implementazioni, non l’intera definizione.
In questa scheda, «agente» è usato in senso funzionale: conta se il sistema può scegliere tra più azioni possibili in base allo stato che osserva e al compito da svolgere. Un sistema può avere un’autonomia molto limitata — per esempio scegliere uno strumento tra due opzioni autorizzate — e mostrare comunque un comportamento agentico. L’autonomia, quindi, non è un interruttore acceso o spento.
Possibili componenti e ciclo di funzionamento
Un agente può combinare diversi elementi. L’obiettivo definisce il risultato da raggiungere; il modello o la politica di controllo aiuta a scegliere il passo successivo; le istruzioni e il contesto delimitano il compito; lo stato raccoglie le informazioni necessarie per proseguire; gli strumenti o gli attuatori consentono di agire; l’ambiente è ciò che l’agente osserva o modifica. Possono esserci anche autorizzazioni, controlli, limiti di utilizzo e condizioni di arresto. Sono componenti possibili, non un elenco di requisiti che ogni agente deve soddisfare.
In un’implementazione basata su un modello generativo, il ciclo può consistere nell’inviare al modello il compito e lo stato disponibile, esaminare la risposta, eseguire uno strumento se il sistema lo consente e consultare di nuovo il modello con il risultato. Il processo termina quando viene prodotta una risposta finale, si verifica una condizione di arresto, si raggiunge un limite o è necessario l’intervento di una persona. La documentazione di uno specifico SDK descrive un ciclo di esecuzione di questo tipo; altre architetture possono organizzarsi diversamente.
Anche il concetto di memoria va precisato. Il sistema può conservare informazioni durante un compito o ricevere uno stato salvato tra un’attività e l’altra, ma non bisogna presumere che ogni implementazione lo faccia. Allo stesso modo, può utilizzare uno, più strumenti o nessuno. Avere strumenti a disposizione non significa che l’agente possa invocarli senza restrizioni: sono le autorizzazioni e le regole di controllo a determinare quali azioni siano effettivamente possibili.
Il ciclo di un agente, passo dopo passo
- 01Ricevere un compito e determinare l’obiettivo e i limiti applicabili.
- 02Osservare lo stato rilevante dell’ambiente e il contesto disponibile.
- 03Scegliere se rispondere, chiedere informazioni, usare uno strumento autorizzato o fermarsi.
- 04Eseguire l’azione autorizzata e raccoglierne il risultato.
- 05Aggiornare lo stato con la nuova osservazione e decidere se proseguire, affidare il compito a una persona o concluderlo.
- 06Verificare la condizione di arresto e, se opportuno, controllare il risultato prima di presentarlo.
Quattro esempi in ambiti diversi
Gli esempi che seguono sono schemi illustrativi, non affermazioni sul funzionamento di tutti i prodotti di questi settori. In ogni caso, ciò che rende agentica l’architettura è il ciclo tra osservazione, selezione delle azioni e verifica dei risultati. Un compito circoscritto può avere autorizzazioni limitate e controlli umani senza smettere di essere un sistema che sceglie i propri passi in base a ciò che rileva.
Agente, chatbot, uso di strumenti e automazione: differenze pratiche
Un chatbot è generalmente descritto in base alla sua interfaccia conversazionale: riceve messaggi e produce risposte. Può limitarsi a rispondere, ma può anche includere azioni e un ciclo decisionale. Perciò «chatbot» e «agente» non sono sempre categorie che si escludono a vicenda: il primo termine può indicare la modalità di interazione, mentre il secondo descrive come il sistema seleziona le azioni per portare avanti un compito.
La chiamata a uno strumento è una capacità o una fase di esecuzione, non una garanzia di ampia autonomia. Un modello può decidere quale strumento chiamare, quando farlo e con quali argomenti, come studia Toolformer; tuttavia, il sistema completo include il meccanismo che autorizza ed esegue la chiamata. Esistono anche agenti che non ricorrono a strumenti esterni. Un’interfaccia per strumenti, come MCP, è un concetto correlato, ma il semplice collegamento a uno strumento non basta a stabilire quanto il sistema decida autonomamente.
Un’automazione o un flusso di lavoro definisce in anticipo i passaggi: se si verifica una condizione, viene eseguita un’azione prestabilita. Se uno di questi passaggi include un LLM, il flusso utilizza l’IA, ma non acquisisce necessariamente la capacità di selezionare dinamicamente le azioni. In senso ampio, si potrebbe chiamare «agentico» un flusso che comprende decisioni. In questa scheda, riserviamo «agente dinamico» a un’architettura che può scegliere il passo successivo in base al compito e alle osservazioni, anziché limitarsi a seguire una sequenza chiusa.
Un assistente è una categoria di prodotto o un ruolo che può comprendere attività diverse, dal rispondere a domande allo svolgere compiti con strumenti; il termine, da solo, non definisce l’architettura. Un sistema multiagente coordina più agenti, ma il numero di componenti non dimostra che la soluzione sia migliore. La memoria dell’agente, l’ingegneria del contesto, la generazione aumentata dal recupero (RAG) e l’intervento umano nel ciclo sono concetti correlati che possono comparire in alcune architetture; nessuno di essi è un requisito universale per definire agente un sistema.
Tabella decisionale: quale descrizione si adatta meglio al sistema?
| Ciò che osservi | Descrizione più precisa | Che cosa resta da verificare |
|---|---|---|
| Riceve messaggi e risponde, senza che siano descritte azioni successive. | Chatbot o interfaccia conversazionale. | Se può selezionare ed eseguire azioni al di fuori della risposta. |
| Esegue sempre gli stessi passaggi quando si verifica la stessa condizione. | Automazione o flusso predefinito. | Se può scegliere dinamicamente il passo successivo in base a nuovi risultati. |
| Il modello richiede uno strumento e il sistema lo esegue. | Uso di strumenti, che può far parte di un agente. | Chi decide, quali autorizzazioni si applicano e come viene utilizzato il risultato. |
| Osserva i risultati e sceglie tra le azioni consentite per portare avanti un compito. | Comportamento agentico, con il grado di autonomia permesso dai controlli. | Ambito, verifiche, intervento umano e condizioni di arresto. |
Errori frequenti e limiti
Il primo errore è trattare l’agente come se fosse soltanto l’LLM. Un modello può proporre un’azione, ma è il sistema che riceve la proposta a decidere se eseguirla, con quali autorizzazioni e come restituire il risultato al passaggio successivo. La distinzione è importante per analizzare sicurezza e responsabilità: una risposta testuale e un’azione che modifica una risorsa non hanno le stesse conseguenze.
Il secondo errore è dedurre un’autonomia estesa dal solo fatto che il sistema usa strumenti. Potrebbe avere un unico strumento a disposizione, richiedere un’approvazione per ogni azione o operare in un ambiente di prova. D’altra parte, anche un’automazione senza LLM può selezionare azioni in funzione delle osservazioni. È preferibile descrivere il comportamento e i controlli, invece di affidarsi a un’etichetta commerciale.
Non bisogna neppure confondere autonomia e affidabilità. Un agente può interpretare male un compito, pianificare in modo inadeguato, ricevere osservazioni incomplete o utilizzare in modo scorretto il risultato di uno strumento. Può ripetere azioni in un ciclo, fermarsi troppo presto o produrre una sintesi che non rispecchia le evidenze recuperate. Una risposta fluida, una dimostrazione o un’esecuzione riuscita non provano, da sole, che le prestazioni siano costanti.
Quando un sistema elabora istruzioni o contenuti esterni, questi possono tentare di influenzare le sue decisioni, per esempio tramite prompt injection. Il rischio dipende dai dati che il sistema legge, dalle azioni che può eseguire e dal modo in cui vengono separate le istruzioni attendibili dai contenuti osservati. Le autorizzazioni minime, la revisione umana nei passaggi sensibili e la possibilità di annullare le modifiche sono misure progettuali che possono ridurre le conseguenze, ma non rendono infallibile un compito aperto.
Infine, memoria persistente, pianificazione esplicita o più agenti non sono requisiti universali né garanzie di risultati migliori: sono scelte progettuali. La loro utilità dipende dal compito, da come vengono implementate e da come sono valutate. Le fonti disponibili per questa scheda non consentono di stabilire un confronto generale delle prestazioni tra tutte queste opzioni, né di proporre una classificazione universale degli agenti.
Come valutare un agente prima di usarlo
Inizia definendo un compito osservabile. «Aiutare con le operazioni» è troppo generico; «classificare le richieste di una certa categoria e preparare una bozza di risposta senza inviarla» permette di individuare gli input, il risultato atteso e i limiti. Descrivi poi l’ambiente, le informazioni a cui il sistema può accedere e le azioni che può compiere. In questo modo distingui una risposta generata da un intervento effettivo.
Specifica autorizzazioni e controlli: quali azioni sono di sola lettura, quali modificano i dati, quali richiedono un’approvazione e quali sono vietate. Definisci anche che cosa deve accadere in presenza di dati mancanti, risultati contraddittori, errori degli strumenti o incertezza. Le condizioni di arresto devono essere esplicite: per esempio, fermarsi davanti a un’azione non autorizzata oppure inoltrare una richiesta che non rientra nei criteri concordati.
Valuta separatamente il risultato del compito e la sicurezza. Una misura può indicare se il risultato raggiunge l’obiettivo, ma non basta a stabilire se il sistema ha rispettato le autorizzazioni, evitato modifiche indesiderate o chiesto aiuto quando necessario. Considera anche i costi, i tempi, la ripetizione delle azioni, la facilità di revisione dei risultati e la possibilità di annullare un’operazione. Il metodo di valutazione dovrebbe comprendere sia casi ordinari sia situazioni limite dell’ambiente reale.
L’intervento umano non deve necessariamente avvenire nello stesso momento in ogni fase. Può essere necessario prima di un’azione irreversibile, dopo la preparazione di una proposta o quando il sistema rileva un’ambiguità. L’importante è chiarire chi approva, quali informazioni riceve e se il sistema può agire prima dell’approvazione. Se il risultato viene verificato dallo stesso agente che lo ha prodotto, valuta se sia necessaria una verifica indipendente.
Lista pratica per la valutazione
- 01Descrivi il compito, gli input accettati e il risultato che sarà considerato un successo.
- 02Elenca l’ambiente, le fonti di informazione e tutte le azioni disponibili.
- 03Distingui le autorizzazioni di lettura, scrittura e invio dalle azioni che richiedono approvazione.
- 04Definisci le condizioni di arresto, inoltro, annullamento e gestione di errori o incertezza.
- 05Prova casi ordinari, ambigui e avversi; registra gli errori e gli interventi necessari.
- 06Prima di ampliare l’ambito, controlla qualità, sicurezza, costi e possibilità di verificare i risultati.
Concetti correlati e criteri conclusivi
La chiamata a strumenti aiuta a capire come un modello possa richiedere un’azione esterna; la memoria dell’agente e l’ingegneria del contesto riguardano le informazioni che il sistema conserva o riceve; RAG tratta l’integrazione di informazioni recuperate in una risposta o in un compito. L’intervento umano nel ciclo e il principio del privilegio minimo aiutano a ragionare su supervisione e limiti di accesso. Sono argomenti da collegare alle rispettive schede del glossario, non componenti da considerare obbligatori per ogni agente. Può essere utile consultare anche il confronto tra agenti e altre forme di automazione per esaminare i casi di confine.
In sintesi, ha senso parlare di agente quando è possibile descrivere un obiettivo, le osservazioni dell’ambiente e una selezione di azioni che si adatta ai risultati ottenuti. Per valutarlo, non fermarti all’etichetta: chiediti che cosa decide, che cosa può eseguire, quali azioni richiedono approvazione, come verifica il risultato e quando si arresta. Una descrizione concreta di questi limiti è più informativa della semplice affermazione che un prodotto è autonomo.
