Dal modello che risponde al modello che agisce

Dal modello che risponde al modello che agisce

Finora tutti i capitoli descrivevano un LLM in un ruolo passivo: riceve un prompt, genera una risposta, finisce lì. Il modello non fa nulla nel mondo: produce testo.

Ma qualcosa è cambiato. Gli LLM possono ora chiamare strumenti: cercare sul web, eseguire codice, leggere un file, inviare un'email. E con questa capacità diventa possibile un'architettura completamente diversa.

Il limite del modello senza strumenti

Fai questa domanda a un LLM senza accesso a internet: "Qual è il prezzo dell'azione Apple in questo momento?"

Inventerà qualcosa di plausibile. Oppure dirà che non lo sa. In entrambi i casi non può rispondere correttamente, perché l'informazione non è nei suoi parametri.

Dagli uno strumento — un'API di quotazioni in tempo reale — e la risposta diventa banale. Il modello non deve imparare questa informazione durante l'addestramento. La ottiene nel momento in cui gli serve.

Il ciclo ReAct

L'architettura di riferimento per gli agenti si chiama ReAct (Reasoning + Acting). Funziona in tre fasi cicliche:

Think (Pensare) — Il modello analizza la situazione. Scrive la sua catena di ragionamento: "Per rispondere a questa domanda ho bisogno di X. Chiamerò lo strumento Y con questi parametri."

Act (Agire) — Il modello genera una chiamata strumento strutturata: il nome dello strumento e i suoi parametri. Il sistema esegue la chiamata e recupera il risultato.

Observe (Osservare) — Il risultato dello strumento viene iniettato nel contesto. Il modello vede cosa è successo e decide cosa fare dopo.

Poi si ricomincia. Finché il modello stima di avere informazioni sufficienti per rispondere.

Avanza passo dopo passo

Ecco tre compiti: uno semplice (calcolo), uno che richiede un'API, uno che concatena più strumenti. Avanza passo per passo per vedere il ragionamento del modello e come il contesto si accumula a ogni turno.

Osserva il loop: il modello pensa, sceglie uno strumento, legge il risultato, ricomincia. Ogni ciclo è una nuova predizione di token — l'« agente » emerge da un LLM a cui è stato insegnato a chiamare funzioni, non da una nuova architettura.

Ciò che bisogna trattenere da questi tre compiti: in nessun momento il modello esegue alcunché. Produce testo — una riflessione, poi una chiamata di strumento ben formata — ed è il sistema attorno a lui a eseguire davvero la chiamata e a rimandargli il risultato. L'altra cosa visibile a schermo è che il contesto non fa che ingrossarsi: ogni giro vi aggiunge il pensiero, la chiamata e l'osservazione. Un agente non è quindi un nuovo tipo di modello. È un loop di predizione di token in cui si reinietta il mondo esterno a ogni giro — e queste due proprietà spiegano tutto il resto del capitolo, dal formato degli strumenti fino ai rischi.

Come sono definiti gli strumenti

Uno strumento non è un pezzo di codice che il modello "capisce magicamente". È una definizione strutturata — nome, descrizione, parametri — che il modello vede nel suo contesto:

{
  "name": "web_search",
  "description": "Cerca informazioni recenti sul web.",
  "parameters": {
    "query": "string — la query di ricerca"
  }
}

Il modello ha imparato durante l'addestramento a produrre chiamate di strumenti in questo formato. Quando "sceglie di usare uno strumento", genera semplicemente testo che assomiglia a una chiamata API.

È il sistema che rileva questo testo, esegue la chiamata reale e rimanda il risultato nel contesto.

Il contesto che cresce

Ogni iterazione del ciclo aggiunge token al contesto: riflessione, chiamata strumento, risultato. Un compito complesso che richiede cinque iterazioni può consumare facilmente diverse migliaia di token.

È per questo che gli agenti tendono a essere più lenti e costosi dei semplici scambi domanda-risposta. Ed è per questo che la gestione del contesto — sapere cosa conservare, cosa riassumere, cosa buttare — è un problema aperto nella progettazione di sistemi agentici.

Tool use vs fine-tuning

Domanda naturale: perché insegnare al modello a usare strumenti invece di insegnargli direttamente le informazioni?

Diverse ragioni:

I dati cambiano. Prezzo di un'azione, meteo, stato di un database: queste informazioni cambiano continuamente. Nessun addestramento può catturarle.

Precisione. Un calcolo, una query SQL, una conversione di unità: gli strumenti sono deterministici ed esatti. Gli LLM no.

Modularità. Dare un nuovo strumento a un modello richiede poche righe. Riaddestrare un modello per integrare una nuova competenza richiede settimane e milioni di dollari.

Planning e decomposizione dei compiti

Gli agenti più capaci non si limitano a un ciclo lineare. Decompongono un compito complesso in sotto-compiti, ne eseguono alcuni in parallelo e combinano i risultati.

Per esempio, "scrivi un rapporto comparativo su tre concorrenti" può decomporsi in: cercare le informazioni su ogni concorrente (tre chiamate in parallelo), poi sintetizzare i risultati.

È ancora un campo di ricerca attiva. Gli LLM attuali pianificano ragionevolmente su compiti brevi, ma deragliano facilmente su compiti lunghi e complessi.

I rischi degli agenti

Con la capacità di agire arriva la capacità di fare danni.

Azioni irreversibili. Un agente che ha accesso alla tua email può inviare un messaggio. Nessun annullamento possibile. Le buone architetture agentiche distinguono le azioni di lettura (innocue) da quelle di scrittura (da confermare).

Loop infiniti. Senza guardrail, un agente può restare bloccato in un ciclo: cerca un'informazione, non la trova, riformula, cerca di nuovo… indefinitamente.

Reward hacking. Se l'obiettivo è specificato male, un agente può trovare scorciatoie inattese per massimizzare il punteggio — senza fare ciò che volevamo davvero.

Allucinazioni sugli strumenti. Il modello può inventare chiamate a strumenti che non esistono, o con parametri sbagliati.

MCP: verso uno standard per gli strumenti

All'inizio, ogni vendor definiva il proprio formato di tool use: OpenAI aveva function calling, Anthropic i suoi blocchi tool_use / tool_result, ogni framework agentico reinventava la ruota. Formati pubblici e documentati, ma ognuno il suo. Risultato: incompatibilità, integrazioni rifatte per ogni modello, ecosistema frammentato.

A novembre 2024, Anthropic pubblica il Model Context Protocol (MCP): uno standard aperto per descrivere strumenti, risorse e prompt in modo indipendente dal modello. Un server MCP espone un insieme di strumenti (per esempio "leggi questo file", "interroga questo database"). Qualsiasi client compatibile MCP — Claude Desktop, Cursor, estensioni VSCode, framework agentici — può collegarsi.

L'analogia che ricorre spesso: MCP sta agli LLM come USB-C sta alle periferiche. Una presa comune.

L'adozione è stata rapida: OpenAI, Microsoft e la maggior parte dei vendor principali hanno annunciato la compatibilità MCP nel 2025. È diventato di fatto il protocollo standard per il tool use.

Code interpreter, sandbox, computer use

Alcune classi di strumenti particolarmente importanti:

Code interpreter. Un sandbox Python (a volte JavaScript) in cui il modello può eseguire codice arbitrario. Calcoli precisi, manipolazioni di dati, generazione di grafici — tutto ciò che gli LLM fanno male nativamente, possono delegarlo a Python. Disponibile su OpenAI, Claude, Google.

Browser / web automation. Uno strumento che rende il modello capace di cliccare, scrollare, compilare moduli su pagine web. Anthropic lo chiama computer use, e OpenAI ha aperto la strada a inizio 2025 con Operator — un prodotto separato, poi confluito in ChatGPT. Oggi tutti i grandi vendor propongono una modalità di questo tipo. Ancora fragile, ma l'evoluzione è rapida.

File system & shell. Uno strumento che dà accesso a un disco virtuale, a un terminale. Cuore dei "coding agents" come Cursor, Cline, Aider, Claude Code.

Memoria a lungo termine

Il contesto di un agente cresce, ma resta limitato. Come fa un assistente a riconoscerti nella conversazione successiva? Con una memoria a lungo termine esterna.

Diversi approcci:

• Memoria vettoriale — ogni interazione importante viene riassunta e salvata come embedding. A ogni nuova conversazione, si recuperano i ricordi pertinenti (RAG, versione memoria).
• Profilo utente strutturato — l'agente aggiorna un dossier sull'utente (preferenze, progetti in corso, storico).
• Memoria procedurale — l'agente tiene traccia delle ricette che hanno funzionato ("per riassumere un paper, segui questi passi").

ChatGPT ha introdotto una memoria nel 2024, Claude nel 2025. È uno dei cantieri più attivi nella progettazione agentica.

Multi-agent: più LLM che collaborano

Tendenza recente: invece di un solo agente, far collaborare più LLM specializzati.

Un agente orchestratore riceve il compito, lo decompone e delega ad agenti specializzati (un esperto di codice, un esperto di ricerca web, un verificatore). I risultati risalgono all'orchestratore, che li combina.

Questa architettura assomiglia a un'organizzazione umana — e ha gli stessi vantaggi (parallelizzazione, specializzazione) e gli stessi problemi (comunicazione, coordinamento, perdita di informazione tra agenti).

Cosa cambia

L'LLM non è più un oracolo da interrogare: è un cervello collegato a braccia.

Questa transizione è ancora recente. Gli agenti attuali sono impressionanti su compiti ben delimitati e fragili su compiti lunghi e ambigui. Ma l'evoluzione è rapida, e capire l'architettura fondamentale — ReAct, tool use, contesto che cresce — è il miglior punto di partenza.

Aggiornato il 2 agosto 2026