Goose: dal modello all'agente

Un chatbot risponde. Un agente agisce: legge i file, scrive, esegue comandi, controlla il risultato e riprova. Goose — progetto open source di Block — è uno degli strumenti che rende questo salto possibile con un modello locale.

La differenza pratica: a una chat chiedi “come rinomino tutti questi file?” e ottieni le istruzioni; a un agente lo chiedi e i file vengono rinominati.

Cosa fa

Legge e scrive file, esegue comandi nel terminale, installa dipendenze, lancia i test e legge gli errori per correggersi. È il ciclo pensa-agisci-osserva della lezione sulle tecniche avanzate, messo in pratica con strumenti reali.

Si estende attraverso MCP, un protocollo ormai diffuso per collegare strumenti esterni: accessi a database, servizi, API. L’architettura a estensioni è nativa, non aggiunta dopo, e questo si sente nell’uso.

Il punto delicato: il tool calling

Perché un agente funzioni, il modello deve saper invocare gli strumenti in modo strutturato e affidabile: la richiesta deve arrivare nel formato giusto, ogni volta. Non tutti i modelli locali ci riescono con la stessa costanza, e non tutti i runtime li servono allo stesso modo.

È qui che ritorna la lezione precedente: LM Studio come backend dà risultati più affidabili proprio su questo aspetto. Un agente che sbaglia una chiamata su cinque non è uno strumento, è una fonte di frustrazione.

Vale anche la pena essere onesti sulle aspettative: un modello da 8 miliardi di parametri gestisce bene compiti circoscritti — rinominare, cercare, riorganizzare, piccole modifiche ripetitive — mentre i lavori lunghi con molti passaggi restano terreno dei modelli grandi.

La cautela che serve

Uno strumento che esegue comandi sulla tua macchina va trattato per quello che è. Tre regole che evitano guai:

Lavora in una cartella dedicata, non nella tua home o in una cartella di sistema. Tieni il controllo di versione attivo, così qualsiasi modifica è reversibile con un comando. E all’inizio conferma le azioni una per una invece di lasciarlo correre: serve a capire come ragiona, prima di dargli fiducia.

Non è pessimismo: è la stessa prudenza con cui si prova qualsiasi automazione nuova.

Perché provarlo

Anche solo per capire dove siamo. Vedere un modello che gira sul tuo portatile leggere un errore, correggere il codice e rieseguire il test è il momento in cui la faccenda smette di sembrare una demo e comincia a somigliare a uno strumento di lavoro.

Lavorare in sicurezza

Uno strumento che esegue comandi sul tuo computer va trattato per quello che è. Non allarmismo: le precauzioni che si usano con qualsiasi automazione nuova, applicate prima e non dopo.

Isola la cartella di lavoro. Un agente lanciato dalla cartella personale ha davanti tutto: documenti, chiavi, configurazioni. Lanciato in una cartella di progetto, il danno peggiore resta lì.

Tieni il controllo di versione attivo. Con git nella cartella, ogni modifica è reversibile con un comando e il confronto ti mostra esattamente cosa è stato toccato. È la rete di sicurezza più efficace e costa nulla.

All’inizio conferma le azioni una per una. La modalità che chiede il permesso prima di ogni comando è noiosa per dieci minuti e insegna moltissimo su come l’agente ragiona.

Attenzione ai segreti. Un agente che legge file può finire per mettere il contenuto di un file di configurazione dentro il contesto — e se il modello è remoto, quel contenuto esce dalla macchina. Con un modello locale il problema non si pone: è uno degli argomenti più solidi a favore dell’inferenza in casa.

Diffida delle istruzioni che arrivano dai dati. Un agente che legge una pagina web può incontrarci dentro istruzioni pensate per lui. Il confine vero non lo stabiliscono le raccomandazioni nel prompt, lo stabiliscono i permessi che gli hai dato.

Rischio	Difesa
Comando distruttivo	Cartella dedicata, git, conferme
Segreti che escono	Modello locale, o escludere i file sensibili
Istruzioni nascoste nei dati	Permessi minimi agli strumenti

Cosa gli si può chiedere davvero

L’entusiasmo iniziale porta a chiedere troppo, la delusione che segue porta ad abbandonarlo. Vale la pena essere precisi su dove la resa è buona e dove no, soprattutto con un modello locale.

Compito	Come va
Rinominare o riorganizzare file secondo uno schema	Molto bene
Cercare qualcosa in un progetto e riassumere dove sta	Molto bene
Modifiche ripetitive su molti file	Bene, se l’istruzione è precisa
Scrivere uno script che poi verifichi tu	Bene
Correggere un errore leggendo il messaggio	Discreto, dipende dal modello
Progettare una funzionalità da zero	Male con un modello piccolo
Lavori lunghi a molti passaggi	Male: perde il filo

La regola che emerge: compiti circoscritti con un criterio di successo verificabile. “Metti in ordine alfabetico le voci di questo elenco in tutti i file” funziona; “migliora questo progetto” no, perché non c’è modo di sapere quando ha finito.

Come si imposta una richiesta che riesce

Tre abitudini che cambiano il tasso di successo più di qualsiasi scelta di modello.

Dai il criterio di fine. Non “sistema i test”, ma “fai passare i test in questa cartella, senza modificare i file sorgente”. L’agente ha bisogno di sapere quando fermarsi.

Restringi il campo. Indicare i file o la cartella su cui lavorare evita che vada a esplorare mezzo progetto consumando contesto — e con un modello locale il contesto è la risorsa scarsa.

Chiedi un piano prima dell’azione. Su compiti non banali, farsi dire cosa intende fare prima che lo faccia costa una risposta e ti risparmia di dover disfare qualcosa.

E una nota realistica sui modelli locali: un modello da 8 miliardi di parametri sbaglia più spesso la forma della chiamata agli strumenti che il ragionamento. Se vedi errori ripetuti nell’invocazione, non è il compito a essere troppo difficile — è il modello o il programma che lo serve.

In sintesi

Concetto	In una riga
Agente	Non risponde soltanto: legge, scrive, esegue, verifica
MCP	Il protocollo con cui si collegano strumenti esterni
Tool calling	Il punto critico: serve un modello e un backend affidabili
Prudenza	Cartella dedicata, controllo di versione, conferme all’inizio
Aspettative	Compiti circoscritti sì, lavori lunghi ancora no
Sicurezza	Cartella dedicata, git, conferme: il confine sta nei permessi
Dove funziona	Compiti circoscritti con un criterio di successo verificabile
Come chiedere	Criterio di fine, campo ristretto, piano prima dell’azione