Coffee & Cake: Modelli, agenti e harness Canonical episode: https://move37.app/cafe/it/episodes/coffee-cake-models-agents-harnesses-it/ Published: 2026-08-17T07:47:49Z Language: it TRANSCRIPT Benvenuti da Andy's Café, dove le macchine preparano e le persone assaggiano. Oggi serviamo Coffee and Cake. Il modello, l'agente e ciò che li tiene insieme Due applicazioni dichiarano di usare lo stesso modello linguistico. Alla prima fai una domanda e ricevi una risposta. Alla seconda affidi un problema: apre dei file, consulta un registro degli errori, modifica un programma, esegue una prova e, se qualcosa non funziona, cambia strada. Verrebbe naturale pensare che dietro la seconda ci sia un modello molto più intelligente. Ma il modello può essere identico. A cambiare è tutto ciò che gli è stato costruito attorno. Per capire questa differenza conviene separare tre livelli: il modello, l'agente e il software che coordina il lavoro. I confini non sono ufficiali e universali. Nel settore, la parola agente può indicare un modello configurato con istruzioni e strumenti, oppure un sistema più autonomo che decide da sé come procedere. Invece di inseguire una definizione perfetta, possiamo guardare alla funzione svolta da ciascun livello. Il modello è la componente addestrata. Riceve un insieme di informazioni in ingresso e produce un risultato. Per un modello linguistico, l'ingresso può contenere la richiesta dell'utente, le istruzioni dell'applicazione, alcuni messaggi precedenti e la descrizione degli strumenti disponibili. Il risultato può essere un testo, ma anche una richiesta strutturata: leggi questo file, cerca questa espressione, avvia questa prova. Una richiesta del genere non è ancora un'azione. Se il modello produce le parole necessarie per chiedere un registro degli errori, non ha aperto alcun registro. Ha soltanto indicato che cosa vorrebbe fare. Un altro componente deve riconoscere la richiesta, inviarla allo strumento giusto, attendere il risultato e riportarlo al modello. È una distinzione piccola, ma fondamentale: il modello propone; l'ambiente esterno esegue. L'agente emerge nel tempo. Riceve un obiettivo, sceglie una mossa, osserva ciò che è accaduto e adatta la mossa successiva. Lo stesso modello può essere interrogato molte volte durante un solo incarico. Ogni risposta dell'ambiente entra nel contesto della chiamata seguente. L'agente, quindi, non è una creatura digitale nascosta nel modello. È un modo di organizzare decisioni e osservazioni attorno a un obiettivo. Immaginiamo che il modulo di contatto di un sito abbia smesso di inviare messaggi. L'incarico è trovare la causa e correggerla. Il modello potrebbe chiedere per prima cosa il registro degli errori. Da lì ricava il nome di un file, chiede di leggerlo e propone una modifica. Poi richiede una prova. La prova fallisce e produce un nuovo messaggio. Il modello vede quella risposta, abbandona la prima ipotesi e controlla un'altra parte del programma. Questa capacità di cambiare il passo successivo in base a ciò che si è appena scoperto è la parte propriamente agentica. Nessuno aveva stabilito in anticipo quale file aprire o quanti tentativi compiere. Il modello può decidere di cercare altrove, usare uno strumento diverso, fare una domanda all'utente oppure concludere di non avere elementi sufficienti. Non ogni sequenza che contiene un modello è però un agente. Un programma potrebbe cercare sempre in una banca dati, riassumere sempre i primi risultati e inviare sempre un messaggio, nello stesso ordine. Il modello partecipa, ma il percorso resta fissato dal codice. Questo è un flusso di lavoro predefinito, spesso chiamato workflow. Se invece il modello decide, alla luce dei risultati, se cercare ancora, cambiare fonte o fermarsi, il sistema diventa più simile a un agente. Non esiste un interruttore netto tra le due categorie. Resta da spiegare chi organizza il ciclo. Serve un software di coordinamento che prepari il contesto, chiami il modello, interpreti una richiesta di strumento, la instradi verso il servizio corretto e inserisca il risultato nella chiamata successiva. Questa struttura di orchestrazione è spesso indicata con il termine inglese harness, o più precisamente agent harness. Non aggiunge conoscenza ai parametri del modello. Tiene in movimento il processo. L'harness può anche stabilire quali istruzioni e quali strumenti siano visibili, conservare il filo della sessione, gestire un errore, interrompere un ciclo troppo lungo o chiedere una conferma prima di un'azione importante. Ogni prodotto assegna a questo strato compiti leggermente diversi, e il termine non è standardizzato. Ciò che rimane costante è il ruolo di mediazione tra i risultati del modello e il mondo in cui devono produrre effetti. Non bisogna però confondere l'harness con ogni componente esterno. Uno strumento legge davvero il file. Un ambiente di esecuzione avvia davvero la prova. Un registro della sessione può conservare la storia del lavoro. L'harness collega questi elementi al modello e fa circolare le informazioni. Alcune piattaforme li vendono come un unico pacchetto, ma separarli mentalmente aiuta a capire dove avviene ciascuna cosa. Riprendiamo il modulo di contatto. Il modello chiede il registro. L'harness consegna la richiesta allo strumento, poi riporta il contenuto nel contesto. Il modello sceglie un file. L'harness fa eseguire la lettura. In seguito coordina la modifica e la prova. Se la prova fallisce, il nuovo errore torna al modello e il ciclo continua. L'utente vede un agente che lavora; sotto la superficie, vede l'effetto combinato di chiamate al modello, strumenti esterni e orchestrazione. Ecco perché due agenti fondati sullo stesso modello possono avere risultati molto diversi. In uno, le descrizioni degli strumenti sono ambigue, il contesto è pieno di materiale inutile e i risultati importanti vengono tagliati. Nell'altro, gli strumenti hanno funzioni chiare e ogni errore torna al modello in una forma comprensibile. I parametri addestrati non sono cambiati, ma è cambiata la qualità dell'ambiente in cui vengono usati. Vale anche il contrario. Un harness può accumulare istruzioni e scorciatoie per compensare una debolezza di un certo modello. Quando il modello viene sostituito, quegli aiuti possono diventare peso morto o perfino creare confusione. Inoltre, alcuni modelli vengono preparati proprio per produrre particolari formati di chiamata agli strumenti. Modello e harness sono livelli distinti, ma non sono pezzi completamente indipendenti che si possono sempre scambiare senza conseguenze. A questo punto diventano più semplici anche alcuni malintesi. Un agente non deve per forza essere un modello speciale. Un modello capace di nominare uno strumento non lo ha ancora usato. L'harness non è soltanto una lunga istruzione iniziale, perché gestisce il ciclo e i collegamenti con l'ambiente. E per avere un agente non serve una squadra di agenti: può bastare un solo modello che riceve osservazioni e sceglie come proseguire. Nemmeno il nome del modello descrive da solo ciò che il prodotto sa fare. Senza accesso ai file, il modello non può correggere il programma. Se il sistema perde l'esito della prova, può ripetere lo stesso errore. Per confrontare due agenti servono anche informazioni sugli strumenti disponibili, sul contesto fornito, sul numero di tentativi consentiti e sul modo in cui gli insuccessi vengono restituiti al modello. Più autonomia, infine, non significa automaticamente un sistema migliore. Quando un compito è stabile e i passaggi sono noti, un flusso predefinito è spesso più rapido, economico e prevedibile. Lasciare che il modello scelga il percorso offre flessibilità, ma richiede più chiamate e permette a un errore iniziale di propagarsi. La soluzione migliore non è quella che concede il massimo spazio possibile all'agente. È quella che lascia aperte soltanto le decisioni che il problema rende davvero imprevedibili. Quando incontri di nuovo l'espressione agente di intelligenza artificiale, prova quindi a fare tre domande. Quale modello propone le mosse? Chi sceglie il passo successivo: il codice, una persona o il modello dopo aver visto un risultato? E che cosa mette a disposizione l'harness: quali strumenti, quale contesto, quali osservazioni e quali condizioni per fermarsi? Il modello porta la capacità appresa. L'agente usa quella capacità lungo una sequenza orientata a un obiettivo. L'harness collega la sequenza agli strumenti e all'ambiente. Tenere distinti questi tre livelli permette di guardare oltre l'etichetta e capire che cosa, in concreto, può fare il sistema che abbiamo davanti. Per oggi è tutto. Il café è sempre aperto. A presto. MORE INFORMATION TEXT LICENSE This transcript, description and original Andy's Café editorial text are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). License: https://creativecommons.org/licenses/by/4.0/ Attribution: Andy's Café — https://move37.app/cafe/it/episodes/coffee-cake-models-agents-harnesses-it/ Indicate changes when adapting. Identified third-party quotations and linked source material remain under their own terms. AUDIO AND OTHER MATERIAL The composed episode has separate component terms because its piano cues are third-party material. Artwork and the Andy's Café brand are not included in the CC BY licence. Rights map: https://move37.app/cafe/welcome/#reuse Contact: hello@move37.app