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 language model non conserva memoria propria tra una chiamata e l'altra. A ogni turno è necessario fornirgli tutte le informazioni relative all'attività corrente. Per un'attività breve questo non è un problema, perché l'intera conversazione rientra in una singola richiesta. La quantità di contenuto dipende dalla context window; un modello self-hosted fornito tramite Ollama ne usa una di dimensioni ridotte per impostazione predefinita e rimuove silenziosamente i turni più vecchi. Per questo conviene impostare num_ctx in base al traffico generato dal loop prima di attribuire all'agent problemi di memoria. Per attività più lunghe è necessario gestire direttamente la memoria. Esistono due approcci importanti.

Il primo è uno scratchpad. Si assegna all'agent un file che può leggere e modificare e gli si chiede di registrare ciò che apprende durante l'esecuzione. Al turno o alla sessione successiva, l'agent 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'agent tratta il file come un altro tool.

Il secondo è il retrieval. Quando l'agent deve utilizzare informazioni provenienti da un insieme ampio di documenti che non potrebbe mai rientrare in una singola richiesta, si archiviano i documenti in un formato ricercabile e si inseriscono nella context window del modello soltanto le parti pertinenti, quando servono. Questo approccio si chiama retrieval-augmented generation, o RAG. L'agent pone una domanda, il codice individua le poche sezioni corrispondenti e soltanto quelle vengono inviate al modello. Lo store risiede sul server, quindi i documenti privati non lo lasciano.

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 il tuo agent

Il modello è l'unica componente di un agent che non devi eseguire necessariamente in autonomia, e scegliere dove eseguirlo è la decisione più importante. Un modello hosted, accessibile tramite API, offre le migliori capacità di ragionamento senza richiedere attività operative: invii testo e ricevi testo. Un modello self-hosted viene eseguito sul tuo server, mantiene private tutte le richieste, ha un costo fisso invece di un costo per token e non dipende dalla disponibilità di servizi gestiti da terzi. Il compromesso riguarda capacità e impegno operativo. I migliori modelli hosted sono più avanzati di quelli che puoi eseguire in autonomia, mentre l'esecuzione in proprio richiede memoria sufficiente per contenerli.

Questo è il principale limite pratico. Il modello deve essere contenuto nella memoria del server e, se usi una GPU, nella relativa memoria video. Un modello troppo grande per l'hardware non verrà caricato. Prima di progettare un agent self-hosted, verifica che il modello scelto sia compatibile con la macchina disponibile:

Se i valori non sono compatibili, hai tre possibilità: scegliere un modello più piccolo, usare una quantizzazione più aggressiva per ridurne le dimensioni oppure usare un'API hosted per il ragionamento, mantenendo sul server soltanto strumenti e dati. Molti agent self-hosted iniziano con un modello locale tramite Ollama su un VPS e ricorrono a un'API hosted per le attività più complesse.

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à.