Hermes Agent nel mio laboratorio: architettura, sicurezza e utilizzo reale

Hermes non è il nome che ho dato a una finestra di chat. Nel mio laboratorio è diventato un livello operativo personale tra i canali che uso ogni giorno e gli strumenti con cui amministro sistemi, produco documentazione e pubblico contenuti.

La distinzione è importante. Un chatbot riceve una domanda e genera testo. Un agente operativo riceve un obiettivo, ricostruisce il contesto, sceglie strumenti autorizzati, esegue controlli, produce un artefatto e verifica che il risultato esista davvero.

La regola che applico è semplice: una risposta plausibile non equivale a un lavoro concluso. Se chiedo una build, un controllo o una pubblicazione, voglio vedere l'output reale della build, lo stato del servizio e il risultato raggiungibile dall'esterno.

Questa Nota Tecnica descrive il mio setup e il metodo con cui lo utilizzo. Non è una guida per dare accesso indiscriminato a un modello linguistico: è il contrario. È un modo per rendere l'AI operativa senza rinunciare a perimetro, evidenze e rollback.

Da chatbot ad agente operativo

Il flusso di una chat tradizionale è lineare:

utente → domanda → modello → risposta

Il flusso che cerco con Hermes è diverso:

obiettivo → contesto → strumenti → verifica → risultato

Hermes aggiunge al modello linguistico alcuni componenti distinti:

• gateway, per ricevere e consegnare richieste attraverso Discord, CLI, API e altri canali;
• toolset, cioè capacità operative come terminale, SSH, file, browser, ricerca, immagini e cron;
• memoria, per preferenze e informazioni stabili che non voglio ripetere a ogni sessione;
• skill, procedure riutilizzabili con checklist, comandi, rischi e verifiche;
• scheduler, per attività ricorrenti e monitoraggi;
• profili, per separare configurazioni, contesti e strumenti quando serve;
• provider intercambiabili, così l'agente non dipende da un unico modello o endpoint.

Il modello propone e coordina. Gli strumenti osservano o agiscono. Le verifiche stabiliscono se il lavoro è realmente riuscito.

Come è costruito il mio setup

Nel mio ambiente Hermes gira su un server self-hosted e viene raggiunto principalmente da Discord. Il gateway conserva il legame tra canale e sessione, costruisce il contesto e inoltra il lavoro all'agente.

Il modello principale utilizza oggi un provider in abbonamento tramite autenticazione OAuth. Se il provider non è disponibile, posso mantenere una catena di fallback verso modelli esposti dal mio backend Ollama, locali o cloud. Questa separazione mi permette di cambiare il motore senza ridisegnare l'intero flusso operativo.

Gli strumenti non sono tutti attivi per principio. Vengono caricati in base alla piattaforma e al compito: terminale e file per un'attività sistemistica, browser per una verifica visuale, web per una ricerca, cron per un processo ricorrente.

Lo stato delle conversazioni vive in SQLite con journaling WAL. Memoria, skill e configurazione restano file separati e leggibili. Questa scelta rende il sistema ispezionabile: posso controllare processi, file, database, log e unità di servizio senza dipendere da una piattaforma opaca.

Il ciclo completo di una richiesta

Quando scrivo «controlla perché il servizio non risponde», il lavoro corretto non è generare una lista di ipotesi. Il ciclo che mi aspetto è questo:

1. Definizione dell'obiettivo — capire cosa considero funzionante e qual è il perimetro.
2. Raccolta del contesto — leggere configurazione, stato live, log e procedure già validate.
3. Esecuzione controllata — usare soltanto gli strumenti necessari.
4. Checkpoint di sicurezza — prima di modifiche ad alto impatto, dichiarare scope, backup e rollback.
5. Verifica — controllare output, processi, porte, HTTP, build, diff o integrità dei dati.
6. Consegna — spiegare cosa è stato verificato, cosa è cambiato e quali rischi restano.

Questo approccio evita due errori frequenti: fermarsi alla prima ipotesi convincente oppure dichiarare «fatto» dopo aver soltanto scritto un file.

Come lo utilizzo davvero

Diagnosi end-to-end

Uno degli utilizzi più frequenti è il troubleshooting. Posso partire da un sintomo molto breve e chiedere all'agente di attraversare tutti i livelli necessari: servizio, processo, porta, log, storage, rete e percorso pubblico.

Un prompt tipico è:

Il servizio risponde lentamente. Analizza stato, processi, log e risorse.
Non modificare nulla finché non hai identificato la causa probabile.
Alla fine dammi evidenze, fix minimo e rollback.

La parte utile non è l'elenco di comandi che avrei potuto eseguire. È la correlazione tra risultati reali e la capacità di proseguire fino a una diagnosi verificabile.

Operazioni su infrastruttura e homelab

Uso Hermes come supporto per attività su virtualizzazione, container, reti, NAS, VPN, monitoraggio e servizi self-hosted. In questo ambito applico una distinzione netta:

• letture e inventario possono procedere autonomamente;
• cambi reversibili richiedono backup e verifica;
• reboot, modifiche di routing, firewall, storage e accessi critici richiedono un perimetro esplicito;
• credenziali e chiavi non devono finire nella memoria o nei prompt.

Esempio:

Verifica il container e la relativa pagina pubblica.
Se serve una modifica, prepara prima backup e rollback.
Non riavviare host o rete senza una mia conferma esplicita.

Sviluppo e pubblicazione del sito

Per DanpLab l'agente può leggere il progetto, aggiornare contenuti o componenti, produrre diagrammi SVG, eseguire la build e verificare la pagina pubblica.

Il risultato atteso non è «ho scritto l'articolo». È:

contenuto → build → deploy → HTTP 200 → controllo visuale → sitemap

Questa stessa Nota Tecnica segue quel flusso: contenuto versionabile, diagrammi originali, build reale, pubblicazione e smoke test sul dominio pubblico.

Ricerca trasformata in decisione

Per prodotti, software, servizi o cambiamenti tecnici non mi serve una raccolta di link. Chiedo una valutazione con criteri espliciti: compatibilità, costo reale, rischi, alternative e decisione consigliata.

Confronta le opzioni usando fonti verificabili.
Scarta annunci obsoleti o incompatibili.
Dammi una scelta consigliata, una soglia di prezzo e i motivi per evitarne altre.

Documenti e note operative

Hermes può trasformare log, verbali, configurazioni e attività concluse in checklist, procedure e post mortem. Il valore sta nel partire dall'evidenza prodotta durante il lavoro, non nel generare documentazione generica a posteriori.

Attività ricorrenti

Uso lo scheduler per rassegne tecniche, controlli e report. Il job parte in una sessione fresca, raccoglie dati, applica criteri e consegna il risultato nel canale previsto.

Un cron agentico ben progettato deve avere:

• prompt autosufficiente;
• fonti e criteri dichiarati;
• toolset limitati;
• modello e fallback coerenti;
• delivery esplicito;
• comportamento silenzioso quando non c'è nulla da segnalare;
• output e stato finale ispezionabili.

Per semplici watchdog deterministici preferisco ancora uno script: meno costo, meno ambiguità e nessun modello coinvolto. L'agente serve quando bisogna interpretare, confrontare o sintetizzare.

Memoria e skill: due cose diverse

La memoria conserva fatti stabili: lingua, preferenze, convenzioni e dettagli dell'ambiente destinati a restare validi. Deve essere compatta. Se un'informazione sarà obsoleta tra una settimana, probabilmente non appartiene alla memoria persistente.

Le skill conservano invece il metodo. Una skill può descrivere come diagnosticare un problema SIP, come pubblicare un sito Next.js, come verificare un cron o come intervenire su un'infrastruttura senza perdere l'accesso.

La mia regola pratica è:

memoria  → fatti stabili
skill    → procedure ripetibili
sessione → dettagli temporanei
segreti  → mai nei tre livelli precedenti

Quando una procedura si dimostra incompleta, la skill va aggiornata. Una procedura sbagliata caricata automaticamente è più pericolosa di nessuna procedura.

Affidabilità e autoripristino

Un agente collegato ai sistemi deve essere raggiungibile, ma duplicare gateway e supervisori non aumenta l'affidabilità: crea competizione su porte, sessioni e canali.

Nel mio setup esiste un solo servizio autorevole, avviato al boot e configurato con riavvio automatico. Un watchdog separato resta come ultima cintura, ma interviene solo se il servizio root è realmente guasto. Uno stop volontario o una manutenzione devono rimanere tali.

Lo stato persistente viene controllato con verifiche SQLite e backup coerenti. Per lavori offline uso un maintenance lock: impedisce al fallback di riaprire il database mentre viene copiato o riparato.

Questa parte può sembrare secondaria rispetto al modello AI, ma non lo è. Un agente brillante sopra un runtime instabile resta uno strumento inaffidabile.

Il mio modello di autorizzazione

Non tratto tutte le azioni allo stesso modo.

| Livello | Esempi | Comportamento | |---|---|---| | Osservazione | log, stato, file, metriche, HTTP | procede e raccoglie evidenze | | Modifica reversibile | contenuti, configurazioni con backup, build | applica nello scope e verifica | | Alto impatto | reboot, rete, firewall, storage, cancellazioni | scope, backup, rollback e conferma | | Azione pubblica | pubblicazione, email, messaggi, account esterni | esegue solo su richiesta esplicita |

Il consenso vale per lo scope indicato. Un «vai» per pubblicare un articolo non autorizza modifiche laterali a DNS, firewall o altri servizi.

Come formulare una richiesta utile

Non servono prompt lunghi. Servono obiettivo, vincoli e definizione di successo.

Un formato efficace è:

Obiettivo: cosa vuoi ottenere.
Perimetro: dove può operare.
Vincoli: cosa non deve toccare.
Successo: come deve verificare il risultato.
Output: come vuoi ricevere la sintesi.

Esempio concreto:

Pubblica una Nota Tecnica su danplab.com.
Usa lo stile esistente e diagrammi SVG originali.
Non modificare DNS o reverse proxy.
Esegui build, deploy, controllo mobile e verifica URL pubblico.
Restituisci URL, verifiche e rollback disponibile.

Se l'interpretazione predefinita è ovvia, preferisco che l'agente inizi a lavorare. La richiesta di chiarimento serve solo quando una decisione cambia davvero strumenti, rischio o risultato.

Cosa non delego alla cieca

Hermes non sostituisce il giudizio operativo. Non gli delego senza controllo:

• modifiche che possono isolare router, VPN o accessi remoti;
• cancellazioni o migrazioni senza backup verificato;
• uso o conservazione di credenziali ricevute in chat;
• comunicazioni pubbliche non richieste;
• decisioni amministrative, legali o finanziarie presentate come certe;
• conclusioni basate su output non realmente osservato.

L'agente può preparare, confrontare, verificare e proporre. La responsabilità del perimetro resta umana.

Conclusione

Hermes mi è utile perché riduce il passaggio continuo tra chat, terminale, browser, note, dashboard e procedure sparse. Non elimina la complessità dei sistemi: la organizza dentro un ciclo più leggibile.

Il valore non è nel numero di tool disponibili e nemmeno nel modello più grande. È nella combinazione tra contesto corretto, azioni delimitate, procedure riutilizzabili ed evidenze reali.

Quando questa disciplina manca, un agente è soltanto un chatbot con accessi pericolosi. Quando è presente, può diventare uno strato operativo personale: capace di osservare, agire, verificare e documentare senza nascondere cosa è successo.

Fonti e riferimenti

• Documentazione ufficiale Hermes Agent
• Repository NousResearch/Hermes-Agent
• Le parti sul mio setup descrivono configurazione e utilizzo reale del laboratorio DanpLab alla data di pubblicazione.