Che cos’e’ un agente AI
Un agente e’ un’applicazione AI che va oltre la singola risposta a un prompt: combina un modello generativo (LLM) con un insieme di istruzioni (che ne definiscono ruolo, comportamento e vincoli) e con uno o piu’ tool che gli permettono di agire sul mondo esterno. In Azure AI Foundry un agente si costruisce quindi assemblando tre elementi concettuali: il modello, le istruzioni e i tool.
La differenza rispetto a una semplice chiamata a un modello sta nell’agentic AI: l’agente non si limita a produrre testo, ma puo’ ragionare su un obiettivo, decidere autonomamente quali passi compiere, invocare strumenti, valutare i risultati e iterare finche’ il compito non e’ completato. E’ questa capacita’ di pianificare e agire in piu’ passaggi — non un solo turno domanda-risposta — a rendere “agentico” il sistema.
Per l’esame ricorda il criterio di scelta: usi un modello “nudo” quando ti basta generare o trasformare testo in un unico passaggio; usi un agente quando servono azioni concrete, accesso a dati esterni o piu’ passi orchestrati verso un risultato.
Come un agente usa i tool
I tool sono le capacita’ che estendono il modello oltre la sua conoscenza pre-addestrata. Concettualmente si dividono in due famiglie:
- Knowledge tool: forniscono all’agente informazioni aggiornate o proprietarie tramite il grounding, cioe’ ancorare le risposte a fonti reali. Esempi tipici sono la ricerca su documenti aziendali (file/vector store), l’integrazione con Azure AI Search o la ricerca web.
- Action tool: permettono all’agente di fare qualcosa — eseguire codice, chiamare una funzione applicativa o un’API esterna.
Il meccanismo con cui l’agente attiva un tool e’ il function calling (o tool calling). Quando il modello riconosce che, per rispondere, gli serve un dato o un’azione, non risponde a testo libero: emette una richiesta strutturata che indica quale tool usare e con quali argomenti. L’esecuzione vera e propria avviene fuori dal modello (dall’applicazione o dal servizio); il risultato viene poi restituito all’agente, che lo integra nel ragionamento e formula la risposta finale. Il modello, quindi, decide cosa chiamare ma non esegue direttamente il codice: e’ un punto che l’esame ama verificare.
La gestione della conversation history
Un agente utile deve ricordare il contesto di una conversazione: le domande precedenti, i risultati dei tool gia’ chiamati, le preferenze espresse dall’utente. Questa conversation history e’ cio’ che rende coerente un dialogo su piu’ turni.
In Foundry la cronologia e’ gestita in modo persistente tramite il concetto di thread: un thread raccoglie in ordine i messaggi dell’utente e dell’agente relativi a una singola conversazione. Lo sviluppatore non deve ricostruire manualmente l’intera storia a ogni turno: aggiunge il nuovo messaggio al thread e il servizio si occupa di mantenere lo stato. Questo semplifica il codice e separa la logica applicativa dalla gestione della memoria conversazionale.
Attenzione pero’ ai limiti: il modello ha una context window finita. Se la conversazione cresce troppo, i messaggi piu’ vecchi possono essere troncati o riassunti, con impatto su costi (piu’ token) e coerenza. La conversation history e’ memoria di sessione, non un archivio permanente di conoscenza aziendale: per quello servono i knowledge tool e il grounding.
Trappole tipiche d’esame
- Serve una risposta aggiornata su dati aziendali privati → soluzione: usa un knowledge tool con grounding (file search / Azure AI Search); non affidarti alla conoscenza pre-addestrata del modello, ferma alla data di training.
- “L’agente esegue direttamente il codice della funzione” → soluzione: falso; con il function calling il modello decide e propone la chiamata, ma l’esecuzione avviene nell’applicazione o nel servizio, non dentro il modello.
- Mantenere il contesto su piu’ turni senza riscrivere la storia ogni volta → soluzione: usa un thread, che persiste la conversation history; non concatenare manualmente tutti i messaggi in un unico prompt.
- Basta un solo passaggio di generazione testo → soluzione: non serve un agente; una chiamata diretta al modello e’ piu’ semplice ed economica. Gli agenti convengono quando servono tool, azioni o piu’ passi orchestrati.
- La conversazione diventa lunghissima e le risposte perdono coerenza → soluzione: e’ il limite della context window; considera riassunti o riduzione della storia, invece di dare per scontato che l’agente “ricordi tutto” all’infinito.
- Confondere conversation history con knowledge base → soluzione: la history e’ memoria di sessione temporanea; per conoscenza stabile e condivisa servono grounding e knowledge tool.