Come creare un agente AI su un VPS

Che cos'è realmente un agente AI

Un agente AI è un ciclo costruito attorno a un modello linguistico. Il modello legge la situazione, decide un'azione, il codice esegue quell'azione, il risultato torna al modello e il ciclo riparte finché l'attività non è completata. Questa è l'idea fondamentale. Un chatbot standard risponde una volta e si ferma. Un agente continua a operare, eseguendo azioni reali tra una risposta e l'altra, finché raggiunge l'obiettivo assegnato. Il ciclo è abbastanza semplice da poter essere scritto autonomamente in un pomeriggio. È da qui che inizia un percorso graduale per imparare a costruire agenti da zero, prima di aggiungere strumenti, memoria e meccanismi di sicurezza.

L'azione è l'elemento importante. Da solo, un modello linguistico produce soltanto testo. Non può leggere un file, chiamare un'API o eseguire un comando. Un agente mette a disposizione del modello un insieme di strumenti autorizzati e un modo per richiederne l'uso. Quando il modello vuole cercare informazioni sul web o scrivere un file, non esegue direttamente l'operazione. Emette una richiesta strutturata, il codice esegue lo strumento e la risposta torna come elemento successivo che il modello legge. Il modello fornisce la capacità decisionale; il server fornisce l'accesso operativo.

Non tutte le attività richiedono un agente e ricorrere a un agente per impostazione predefinita è un errore comune. Se i passaggi sono noti in anticipo, un semplice script è più facile, più veloce e più affidabile. "Recupera questa pagina ogni ora e inviami il prezzo via email" è un'attività pianificata, non un agente. Conviene creare un agente quando il percorso non è definito in anticipo e il modello deve analizzare ciò che trova per decidere cosa fare dopo. Il costo di un agente è l'imprevedibilità. Va quindi sostenuto solo quando la flessibilità offre un vantaggio concreto.

Strumenti: come opera un agente

Uno strumento è una qualsiasi funzionalità messa a disposizione del modello e descritta in modo sufficientemente chiaro da permettergli di sapere quando utilizzarla. Leggere un file, eseguire un comando shell, interrogare un database o inviare un messaggio: ciascuna di queste operazioni è uno strumento con un nome, una breve descrizione e un elenco di input. Gli strumenti vengono definiti dall'utente; il modello decide quando chiamarli. La ricerca sul Web è in genere il primo strumento che conviene aggiungere. Se si esegue già una propria istanza di SearXNG, è possibile usarla come backend di ricerca dell'agente invece di pagare un'API di ricerca commerciale.

Il meccanismo è lo stesso in ogni ambiente, indipendentemente dal modello utilizzato. Il modello restituisce una richiesta strutturata che identifica uno strumento e ne compila gli input. Il codice rileva la richiesta, esegue la funzione corrispondente e invia il risultato nel turno successivo. Il modello legge il risultato e quindi chiama un altro strumento oppure scrive la risposta finale. Le function calling costituiscono il livello di collegamento alla base di ogni agente e il ciclo che le gestisce richiede soltanto poche righe di codice ordinario.

È anche il punto in cui si esercita il controllo. Il modello può chiedere di eseguire un comando, ma l'esecuzione non avviene finché il codice non decide di eseguirlo. In questo punto si inseriscono le richieste di approvazione per le operazioni pericolose, i limiti sulle risorse che uno strumento può modificare e un log di tutte le attività dell'agente. La sicurezza di un agente dipende dagli strumenti che gli vengono assegnati e dai controlli applicati prima del loro utilizzo.

MCP: uno standard per collegare gli strumenti

Scrivere manualmente una nuova integrazione per ogni servizio diventa rapidamente inefficiente. Il Model Context Protocol, o MCP, è uno standard aperto che risolve questo problema. Invece di programmare un nuovo strumento per i file, il database e il sistema di gestione delle issue, si collega l’agente a un server MCP che espone già queste risorse come strumenti. L’agente usa un unico protocollo; il server gestisce la comunicazione con il sistema reale.

Il vantaggio principale è il riutilizzo. Un server MCP sviluppato da altri per un servizio utilizzato diventa disponibile all’agente senza scrivere nuovo codice di integrazione. Allo stesso modo, un server sviluppato autonomamente può essere utilizzato da qualsiasi agente compatibile con il protocollo. Alcune applicazioni self-hosted ora ne includono uno: openGym, un tracker degli allenamenti espone un server MCP in sola lettura, quindi un agente può rispondere alle domande sulla cronologia degli allenamenti senza poterla modificare. Su un VPS questo è importante, perché è possibile eseguire i server MCP come piccoli servizi indipendenti accanto all’agente, assegnando a ciascuno soltanto gli accessi necessari. Quando i sistemi gestiti da questi server si trovano su una rete non raggiungibile dal VPS, ad esempio un database a casa o in ufficio, pubblicizzare quella rete nella tailnet con un subnet router consente all’agente di raggiungerli tramite indirizzi privati senza esporre nulla a Internet pubblico. La configurazione è descritta in eseguire server MCP su un VPS.

Memoria e recupero

Un modello linguistico non conserva memoria propria tra una chiamata e l'altra. A ogni turno è necessario fornirgli tutto ciò che sa dell'attività corrente. Per un'attività breve questo non è un problema, perché l'intera conversazione rientra in una sola richiesta. La quantità di contenuto dipende dalla finestra di contesto. Un modello self-hosted distribuito tramite Ollama su un server con meno di 24 GiB di memoria GPU, oppure senza GPU, usa per impostazione predefinita una finestra ridotta a 4k e scarta silenziosamente i turni più vecchi. Per questo conviene impostare num_ctx in base al traffico generato dal proprio loop prima di attribuire all'agente la perdita del contesto. Per attività più lunghe è necessario gestire autonomamente la memoria. Esistono due modelli principali.

Il primo è un blocco per appunti. Si fornisce all'agente un file che può leggere e modificare, chiedendogli di registrare ciò che apprende durante l'esecuzione. Al turno o alla sessione successiva, l'agente rilegge il file e riprende dal punto in cui si era fermato. In questo caso la memoria è un semplice documento. Il metodo funziona perché l'agente tratta il file come un altro strumento.

Il secondo è il recupero. Quando l'agente deve consultare una grande raccolta di documenti che non potrebbe mai rientrare in una sola richiesta, si archiviano i documenti in un formato ricercabile e si inseriscono nel contesto del modello soltanto le parti pertinenti, quando servono. Questo modello si chiama retrieval-augmented generation, o RAG. L'agente pone una domanda, il codice individua i pochi passaggi corrispondenti e soltanto questi vengono inviati al modello. L'archivio risiede sul server, quindi i documenti privati non lasciano l'infrastruttura.

Più agenti, un solo coordinatore

Un agente con molti strumenti è sufficiente per la maggior parte delle attività. Quando un lavoro è esteso o si divide naturalmente in più parti, è utile una struttura diversa: un agente coordinatore che delega il lavoro a sotto-agenti specializzati. Il coordinatore suddivide l'obiettivo, assegna ogni parte a un sotto-agente progettato per quel tipo di attività e combina i risultati. La delega richiede un canale di comunicazione tra le parti. La versione più semplice è già disponibile sul server: due sessioni di Claude Code sullo stesso VPS possono scambiarsi messaggi. È un modo economico per valutare il comportamento dei passaggi di consegne prima di implementare un sistema di coordinamento.

Il vantaggio è la concentrazione. Un sotto-agente con un compito circoscritto e un set ridotto di strumenti prende decisioni migliori rispetto a un agente generalista che deve gestire tutto. Inoltre, le parti indipendenti possono essere eseguite contemporaneamente. Il coordinamento ha però un costo reale, quindi usa un singolo agente finché l'attività non richiede chiaramente una struttura più articolata. Inizia con una configurazione semplice e aggiungi agenti solo quando uno di essi è chiaramente sovraccarico.

Self-hosted o hosted: quale modello esegue l'agente

Il modello è l'unico componente dell'agente che non è necessario eseguire autonomamente. Scegliere dove eseguirlo è la decisione più importante. Un modello hosted, raggiunto tramite API, offre le capacità di ragionamento più avanzate senza richiedere attività operative: si invia testo e si riceve testo. Un modello self-hosted viene eseguito sul proprio server. In questo modo le richieste restano su hardware sotto il proprio controllo, il costo per token viene sostituito dal costo del server e il funzionamento non dipende dalla disponibilità dell'API del provider del modello. Il compromesso riguarda capacità ed effort operativo. I migliori modelli hosted sono più avanzati rispetto a quelli che è possibile eseguire autonomamente. Eseguire un modello in proprio richiede inoltre memoria sufficiente per contenerlo.

Questo è il principale vincolo pratico. Il modello deve rientrare nella memoria del server e, se si usa una GPU, nella relativa memoria video. Un modello troppo grande per l'hardware non può essere caricato. Prima di progettare un agente self-hosted, verificare che il modello scelto rientri nelle risorse della macchina disponibile:

Se le dimensioni non sono compatibili, le alternative sono quattro: scegliere un modello più piccolo, usare una quantizzazione più aggressiva per ridurne le dimensioni, passare a un server con più memoria o distribuire il modello su più GPU, oppure usare un'API hosted per il ragionamento e mantenere sul server soltanto strumenti e dati. Molti agenti self-hosted iniziano con un modello locale tramite Ollama su un VPS e ricorrono a un'API hosted per i passaggi più complessi.

Il server è la parte più rischiosa

Un agente in grado di eseguire comandi shell e scrivere file è potente, ed è proprio per questo che è rischioso. Il modello è generalmente affidabile, ma non è perfetto. Un’istruzione errata, un bug o un input ostile possono trasformare un agente utile in un agente che elimina il file sbagliato o divulga un secret. La sicurezza non è opzionale. Su un server è l’aspetto più importante.

Alcune pratiche garantiscono gran parte della sicurezza. Esegui l’agente con un utente dedicato senza privilegi, mai come root, così un errore resta limitato; lo stesso principio è illustrato in eseguire i servizi con un utente senza privilegi. Mantieni i suoi secret, come le API key, fuori dal codice e leggibili soltanto da quell’utente. Applica inoltre il sandboxing agli strumenti che interagiscono con il sistema, in modo che l’agente possa accedere soltanto alle risorse realmente necessarie. Se preferisci non scrivere manualmente ogni controllo, i plugin di DeepSeek Harness che vale la pena installare coprono gli stessi aspetti con componenti già pronti: regole per le autorizzazioni degli strumenti, scansione contro la prompt injection e un limite alla spesa dell’agente, oltre il quale l’esecuzione si interrompe. Per un esempio completo di messa in sicurezza di un agente self-hosted reale, consulta eseguire OpenClaw in sicurezza su un VPS. Se preferisci usare un modello hosted per le capacità di ragionamento, la guida complementare creare un agente con Claude su un VPS applica gli stessi principi usando un modello specifico.

Per un esempio completo, creare un agente personale in stile OpenClaw applica questi componenti. Se preferisci eseguire un agente già pronto, inizia da self-hosting di Hermes Agent su un VPS oppure da eseguire Agent Zero sul proprio server. La guida i migliori agenti AI self-hosted nel 2026 confronta fianco a fianco tutte le soluzioni già pronte trattate.

FAQ

Qual è la differenza tra un agente AI e un chatbot?

Un chatbot risponde a un messaggio e si ferma. Un agente esegue un ciclo: il modello decide un'azione, il codice la esegue, il risultato torna al modello e il ciclo continua finché l'attività non è completata. La differenza è che un agente esegue azioni reali tra un passaggio e l'altro, chiamando strumenti per leggere file, eseguire comandi o interrogare servizi, invece di produrre soltanto testo.

Serve una GPU per eseguire un agente AI su un VPS?

Solo se ospiti autonomamente il modello. Il ciclo dell'agente, gli strumenti e la memoria sono normale codice, che funziona senza problemi su un VPS standard privo di GPU. La GPU è necessaria quando vuoi eseguire il modello linguistico sul tuo hardware, perché il modello deve poter essere contenuto in memoria. Se usi un modello ospitato tramite API, i calcoli più pesanti vengono eseguiti altrove e un VPS con risorse moderate è sufficiente.

Che cos'è MCP e serve per creare un agente?

MCP, il Model Context Protocol, è uno standard aperto per collegare un agente a strumenti e origini dati. Non è strettamente necessario, perché puoi scrivere manualmente ogni strumento. MCP evita questo lavoro consentendo di riutilizzare server esistenti per i servizi comuni e di esporre i tuoi sistemi una sola volta, rendendoli disponibili a qualsiasi agente. È una soluzione comoda, che diventa utile quando aumenta il numero di integrazioni.

È sicuro concedere a un agente AI l'accesso al mio server?

Può esserlo, se ne limiti l'ambito operativo. La sicurezza di un agente che esegue comandi dipende dall'account con cui viene eseguito e dagli strumenti che gli permetti di usare. Eseguilo con un utente senza privilegi, impedisci l'accesso ai secret, applica il sandboxing agli strumenti che interagiscono con il filesystem e richiedi l'approvazione per le azioni difficili da annullare. Tratta l'agente come codice non attendibile, anche se è in grado di operare in modo intelligente, e concedigli soltanto ciò che serve per l'attività.