Abilità dell'Assistente AI Hermes per Configurazioni di Produzione Reale

L’assistente AI Hermes, documentato ufficialmente come Hermes Agent, non è posizionato come un semplice wrapper per la chat.

Per l’installazione, la configurazione del provider, il sandboxing degli strumenti e la configurazione del gateway, consultare la guida per l’assistente AI Hermes. Questo articolo si concentra sulle competenze e sull’architettura del profilo che determinano il comportamento di Hermes una volta avviato.

La documentazione ufficiale e il repository descrivono un agente in grado di auto-migliorarsi, dotato di un ciclo di apprendimento integrato che crea competenze dall’esperienza, le migliora durante l’uso, mantiene le conoscenze tra le sessioni e gira su qualsiasi cosa, dai VPS a basso costo ai sandbox cloud.

Ad aprile 2026, il repository pubblico su GitHub mostra circa 94.6k stelle, 13.2k fork e l’ultima release taggata come v0.10.0 il 16 aprile 2026. Questa è un’attività sufficiente per definire il progetto in rapida evoluzione, ben adottato e, allo stesso tempo, ancora operativamente giovane.

Questa natura duale è importante per la progettazione in produzione. Hermes è sufficientemente maturo da supportare un lavoro reale, ma sufficientemente dinamico che una configurazione disordinata invecchierà male. L’articolo sottostante tratta la configurazione e le competenze come una questione di architettura operativa, non come un elenco di funzionalità.

Perché Hermes ha bisogno di un’architettura basata sui profili

Le competenze di Hermes sono documenti di conoscenza su richiesta. Utilizzano la rivelazione progressiva in modo che l’agente possa vedere prima un indice delle competenze compatto e caricare il contenuto completo delle competenze solo quando necessario, mantenendo sotto controllo l’uso dei token anche quando sono installate molte competenze. Ogni competenza installata diventa un comando slash nell’interfaccia a riga di comando (CLI) e nelle interfacce di messaggistica, e la documentazione posiziona esplicitamente le competenze come il meccanismo di estensione preferito quando una capacità può essere espressa con istruzioni, comandi shell e strumenti esistenti piuttosto che con codice agente personalizzato.

La complicazione in produzione è che Hermes tratta le competenze come uno stato vivente, non come pacchetti congelati. Le competenze incluse, quelle installate dal hub e quelle create dall’agente risiedono tutte sotto ~/.hermes/skills/, e la documentazione afferma che l’agente può modificare o eliminare le competenze. Lo stesso sistema espone azioni per la gestione delle competenze come creare, patchare, modificare, eliminare e file di supporto. Questo è potente, ma significa anche che un agente “faccio tutto” eccessivamente grande tende a trasformarsi in un cassetto della spazzatura procedurale.

I profili sono la soluzione. I profili di Hermes sono ambienti completamente isolati, ciascuno con il proprio config.yaml, .env, SOUL.md, memorie, sessioni, competenze, lavori cron e database di stato. La CLI trasforma anche un profilo in un proprio alias di comando, quindi un profilo chiamato coder diventa coder chat, coder setup, coder gateway start, e così via. Nella pratica, questo rende i profili l’unità reale di proprietà in produzione, non la competenza individuale.

La baseline per la produzione

La forma di base è sorprendentemente pulita. Hermes memorizza il comportamento non segreto in ~/.hermes/config.yaml, i segreti in ~/.hermes/.env, l’identità in SOUL.md, i fatti persistenti in memories/, la conoscenza procedurale in skills/, i lavori programmati in cron/, le sessioni in sessions/ e i log in logs/. Il comando hermes config set instrada le chiavi API in .env e tutto il resto in config.yaml, e l’ordine di precedenza documentato è: prima i flag della CLI, poi config.yaml, poi .env, poi le impostazioni predefinite integrate. Questa è anche la risposta più pulita alla FAQ di produzione su come separare segreti e configurazione.

Un layout pratico multi-profilo di solito finisce per assomigliare a questo, con un profilo per responsabilità piuttosto che un profilo per essere umano:

~/.hermes/profiles/
  eng/
  research/
  ops/
  execops/
  ml/

Questo modello corrisponde a come i profili di Hermes sono documentati: ogni profilo è un proprio ambiente isolato, e i profili possono essere clonati da una configurazione di base quando i valori predefiniti comuni sono utili. La documentazione nota anche che i profili non condividono memoria o sessioni, e che le competenze aggiornate possono essere sincronizzate tra i profili quando l’installazione principale viene aggiornata.

Il prossimo confine produttivo è l’esecuzione. Hermes supporta sei backend terminali - locale, Docker, SSH, Modal, Daytona e Singularity - e la documentazione sulla sicurezza descrive un modello di difesa in profondità che include l’approvazione di comandi pericolosi, l’isolamento dei contenitori, il filtraggio delle credenziali MCP, la scansione dei file di contesto, l’isolamento tra sessioni e la sanitizzazione degli input. In altre parole, la decisione “prima il profilo” risponde a chi possiede lo stato, e la decisione sul backend risponde a dove il lavoro rischioso è permesso di accadere.

L’automazione si sovrappone a questa baseline. I lavori cron di Hermes possono allegare zero, uno o più competenze, e vengono eseguiti in sessioni dell’agente fresche piuttosto che ereditare la chat corrente. Il gateway di messaggistica è anche il processo in background che gestisce le sessioni, esegue il cron e instrada i risultati verso piattaforme come Telegram, Discord, Slack, WhatsApp, Email, Matrix e altre. La guida ufficiale MCP aggiunge un’ulteriore regola produttiva facile da trascurare: il modello migliore non è connettere tutto, ma esporre la superficie più piccola utile.

Il profilo di ingegneria del software

La persona più ovvia di Hermes è l’ingegnere del software che vuole che l’agente si comporti meno come una finestra di chat e più come un operatore di repository ripetibile. Questo profilo di solito si preoccupa di autenticazione del repository, triage delle issue, creazione di PR, revisione del codice, debug ed esecuzione basata su piani. Nei cataloghi di Hermes, il pacchetto di competenze integrato principale è insolitamente coerente per quel lavoro: github-auth, github-issues, github-pr-workflow, github-code-review, code-review, plan, writing-plans, systematic-debugging e test-driven-development. Se la delega è importante, Hermes fornisce anche competenze integrate per agenti autonomi come codex, claude-code, opencode e hermes-agent-spawning.

Ciò che rende utile quel pacchetto non è qualsiasi competenza singola. È il modo in cui le competenze codificano la procedura di sviluppo. github-pr-workflow copre l’intero ciclo di vita delle PR, github-issues formalizza le operazioni sulle issue, github-code-review e code-review rendono la revisione un passo distinto invece di un afterthought, e systematic-debugging impedisce all’agente di saltare direttamente a correzioni premature. Questo risponde anche alla domanda pratica su quali competenze dell’assistente AI siano più importanti per i flussi di lavoro di coding. Le competenze a più alto valore sono solitamente quelle che bloccano l’igiene del repository e la disciplina di revisione, non quelle che promettono una maggiore generazione di codice grezzo.

La delega di Hermes rafforza ulteriormente questo profilo. La piattaforma può generare agenti figli isolati con la propria conversazione, sessione terminale e set di strumenti, e solo il riepilogo finale viene restituito al genitore. Per le codebase, questo è un adattamento più pulito rispetto a riempire ogni diff intermedio, stack trace e nota di revisione in una sola conversazione. In termini di produzione, il profilo di ingegneria beneficia di set di competenze ridotti, un backend sandboxed come Docker o SSH e un uso generoso della delega quando il rumore del contesto inizia a dominare.

Il profilo di ricerca e conoscenza

Il profilo di ricerca è dove Hermes inizia a sentirsi distinto dagli assistenti ordinari. I cataloghi integrati includono già arxiv, duckduckgo-search, blogwatcher, llm-wiki, ocr-and-documents, obsidian, domain-intel e ml-paper-writing, mentre il catalogo opzionale ufficiale aggiunge qmd, parallel-cli, scrapling e un livello di ricerca più ampio per domini specializzati. Questo stack copre la ricerca di paper, il monitoraggio delle fonti, l’OCR, i sistemi di note locali, la ricognizione del dominio, la scrittura e il recupero ibrido senza forzare tutto in un singolo modello RAG.

Questo profilo è anche il posto più chiaro per rispondere alla domanda memoria-versus-competenze. La documentazione di Hermes definisce la memoria come fatti sugli utenti, progetti e preferenze, mentre le competenze memorizzano procedure su come fare le cose. Il lavoro di ricerca ha bisogno di entrambi. La memoria conserva ciò che l’assistente ha già imparato sul dominio e sulle preferenze del lettore; le competenze codificano procedure ripetibili come “scansiona arXiv, riassume i nuovi paper e scrivi note in Obsidian”. Questa distinzione è importante perché i sistemi di ricerca in produzione falliscono quando tutto è trattato come memoria o tutto è trattato come flusso di lavoro. Hermes dà a queste preoccupazioni case separate. Per il quadro tecnico completo di come funziona la memoria — l’architettura a due file, i limiti di caratteri, la cache dei prefissi e tutte le otto opzioni di provider esterni — vedere Sistema di Memoria di Hermes Agent.

Il profilo di ricerca beneficia anche in misura sproporzionata dal cron. I lavori cron di Hermes possono caricare esplicitamente le competenze prima dell’esecuzione, e le guide di automazione sottolineano che i prompt programmati devono essere completamente autosufficienti perché vengono eseguiti in sessioni fresche. Un pipeline ricorrente che combina blogwatcher, arxiv, obsidian o llm-wiki è quindi più affidabile di un lavoro vago “controlla cosa è cambiato oggi”. In altre parole, i profili di ricerca funzionano meglio quando la scoperta delle fonti, la scrittura delle note e l’archiviazione a lungo termine sono ciascuna rappresentate da una competenza nominata piuttosto che nascoste dentro un lungo prompt in linguaggio naturale.

Il profilo di automazione e operazioni

Il profilo ops è meno glamour e spesso più prezioso. Questo è l’utente che vuole che Hermes reagisca agli eventi, ispezionasse i sistemi, eseguisse controlli scriptati, instradasse l’output verso un canale e facesse tutto ciò senza trasformare l’host in una responsabilità. Hermes ha i giusti blocchi costruttivi per quel tipo di lavoro: webhook-subscriptions integrate per l’attivazione guidata dagli eventi, native-mcp e mcporter integrati per strumenti basati su MCP, e competenze opzionali ufficiali come docker-management, fastmcp, cli e 1password quando il flusso di lavoro si espande nei contenitori, nei server MCP personalizzati o nell’iniezione di segreti.

Il motivo per cui questo pacchetto funziona è che ogni competenza possiede un confine. webhook-subscriptions gestisce l’ingressione dai sistemi esterni. docker-management trasforma le faccende dei contenitori in una procedura nominata invece di un gioco shell libero. fastmcp è utile quando Hermes ha bisogno di diventare l’orchestratore attorno a nuovi strumenti MCP, e 1password mantiene la gestione dei segreti esplicita piuttosto che nascosta nella cronologia shell o nei file markdown. La guida ufficiale MCP rafforza lo stesso istinto produttivo: connettere la cosa giusta con la superficie più piccola utile.

Questo profilo è anche il posto più pulito per rispondere a come i flussi di lavoro AI programmati rimangano affidabili. La documentazione cron di Hermes dice che i lavori vengono eseguiti in sessioni fresche, possono allegare una o più competenze e dovrebbero usare prompt autosufficienti. La guida alla risoluzione dei problemi del cron aggiunge che l’attivazione automatica dipende dal ticker del gateway piuttosto che da una normale sessione di chat CLI. Quindi il modello affidabile è semplice anche se l’implementazione non lo è: competenze esplicite, target di consegna esplicito, prompt autosufficiente, backend isolato e un gateway che è effettivamente in esecuzione.

Il profilo di operazioni esecutive

C’è una persona di Hermes più silenziosa ma molto reale che assomiglia a un capo di stato maggiore, un responsabile delle operazioni o un fondatore fortemente sovraccarico. Le competenze rilevanti sono meno appariscenti e più a forma d’ufficio: google-workspace, notion, linear, nano-pdf, powerpoint e la competenza email integrata himalaya, più competenze opzionali ufficiali come agentmail, telephony e one-three-one-rule. Quel mix dà a Hermes accesso alla posta in arrivo, al calendario, ai documenti, alle attività, alle presentazioni, alla pulizia dei PDF, a un quadro di comunicazione strutturato e persino a flussi di lavoro telefonici e SMS dove ciò conta davvero.

Il flusso qui è più importante del catalogo. google-workspace ancora l’esecuzione quotidiana. Notion e Linear impediscono all’assistente di diventare il sistema di registrazione delle attività. one-three-one-rule è sorprendentemente utile perché il supporto decisionale è spesso la cosa più difficile da standardizzare, e quella competenza dà a Hermes una procedura nominata per le proposte piuttosto che un comportamento generico “riassumi questo”. nano-pdf e powerpoint sono il tipo di moltiplicatori operativi che sembrano piccoli finché un team non inizia a toccare presentazioni e PDF ogni giorno.

Le funzionalità di messaggistica e voce di Hermes rendono questo profilo più pratico di quanto appaia a prima vista. Il gateway può esporre l’agente attraverso Slack, Telegram, Discord, WhatsApp, Email, Matrix e diversi altri canali, e lo stack vocale supporta l’input del microfono, le risposte vocali nella messaggistica e le conversazioni vocali live su Discord. La documentazione nota anche che un’istanza di Hermes può servire più utenti attraverso elenchi di autorizzazione e abbinamento DM, mentre i token bot rimangono esclusivi di un singolo profilo. Ecco perché un deployment pesante di comunicazione beneficia solitamente di almeno un profilo dedicato invece di condividere la stessa identità bot con ingegneria o operazioni.

Il profilo piattaforma ML e dati

Hermes è costruito da un laboratorio di ricerca, e quella lignea si vede. I cataloghi includono jupyter-live-kernel per il lavoro stile notebook con stato, huggingface-hub per operazioni su modelli e dataset, evaluating-llms-harness e weights-and-biases per valutazione e tracciamento degli esperimenti, qdrant-vector-search per l’archiviazione RAG in produzione, e un grande livello MLOps integrato e opzionale con competenze come axolotl, fine-tuning-with-trl, modal-serverless-gpu, lambda-labs-gpu-cloud, flash-attention, tensorrt-llm, pinecone, qdrant e nemo-curator.

Ciò che è notevole qui non è solo l’ampiezza. È che le competenze coprono l’intero stack dall’iterazione del notebook alla cura dei dati, valutazione, ricerca vettoriale, tuning fine e ottimizzazione dell’inferenza. Per un utente della piattaforma ML, Hermes smette di sembrare un assistente e inizia a sembrare un piano di controllo che può trasportare procedure attraverso il ciclo di vita. jupyter-live-kernel gestisce l’esplorazione iterativa, evaluating-llms-harness e weights-and-biases formalizzano la misurazione, e le competenze opzionali di calcolo e ottimizzazione permettono a Hermes di parlare coerentemente sia di sperimentazione che di deployment.

Questo è anche il profilo dove la moderazione conta di più. Poiché il catalogo MLOps opzionale è così grande, un setup di produzione Hermes per il lavoro ML beneficia solitamente di essere opinionato sull’ambito. Un profilo di ingegneria della piattaforma che possiede valutazione e deployment non ha bisogno di ogni framework di training installato. Un profilo di ricerca che possiede paper e sistemi di note non ha bisogno di ogni competenza del database vettoriale. Hermes può trasportare enormi inventari di competenze, ma l’utilità in produzione deriva ancora dal restringere la superficie attiva.

Dove le competenze diventano responsabilità

La parte più forte del sistema di competenze di Hermes è anche il posto dove i setup di produzione vanno male. Hermes può navigare e installare competenze dal suo catalogo integrato, dal catalogo opzionale ufficiale, da skills.sh di Vercel, da endpoint di competenza ben noti, repository GitHub diretti e fonti comunitarie stile marketplace. Il modello di sicurezza distingue tra fonti builtin, official, trusted e community, esegue scansioni di sicurezza per le competenze installate dal hub e permette --force solo per blocchi di politica non pericolosi. Un verdetto di scansione pericoloso rimane bloccato. Hermes espone anche metadati upstream come URL del repository, installazioni settimanali e segnali di audit durante l’ispezione. Questo è un modello di fiducia solido, ma non è un sostituto del gusto.

C’è anche un limite a ciò che si dovrebbe chiedere a una competenza. La documentazione di Hermes è esplicita che le competenze sono la scelta preferita quando il lavoro può essere espresso come istruzioni più comandi shell più strumenti esistenti, mentre i plugin sono l’astrazione più onesta per strumenti personalizzati, hook e comportamento del ciclo di vita. La guida dei plugin mostra persino come un plugin possa raggruppare la propria competenza. In produzione, questo significa che le competenze sono migliori se trattate come procedure riutilizzabili, non come un sostituto forzato per un design di strumento o plugin appropriato.

La comunità e il supporto sembrano sani, ma non cancellano la velocità di cambiamento. La documentazione di Hermes indirizza gli utenti a Discord, GitHub Discussions, Issues e Skills Hub, e il repository pubblico mostra release frequenti e un’ampia impronta di contributi. La presa operativa è semplice: gli aggiornamenti sono parte del sistema, non un evento al di fuori di esso. Un setup di produzione reale assume che profili, competenze e presupposti di flusso di lavoro evolveranno, e poi usa l’isolamento e pacchetti di competenze ristretti in modo che il cambiamento rimanga locale quando inevitabilmente arriva.

Hermes funziona meglio quando le competenze sono trattate come contratti procedurali attorno a profili chiaramente separati. Il momento in cui un profilo diventa l’agente di ingegneria, l’assistente di ricerca, il lavoratore delle operazioni, il bot della posta in arrivo e la piattaforma ML tutto allo stesso tempo, il sistema smette di comporre e inizia a perdere responsabilità. Il modello produttivo pulito è meno avere più competenze e più dare a ogni profilo una descrizione del lavoro che può effettivamente mantenere.

Questo articolo fa parte del cluster Sistemi AI, che copre assistenti self-hosted, architettura di recupero, infrastruttura LLM locale e osservabilità.