Abilità di Hermes AI Assistant per ambienti di produzione reali

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 dell’assistente AI Hermes. Questo articolo si concentra sull’architettura delle competenze e dei profili che determina il comportamento di Hermes una volta in esecuzione.

La documentazione ufficiale e il repository descrivono un agente a miglioramento automatico con un ciclo di apprendimento integrato che crea competenze dall’esperienza, le migliora durante l’uso, persiste le conoscenze tra le sessioni e funziona su qualsiasi cosa, dal 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 contrassegnata v0.10.0 in data 16 aprile 2026. Si tratta di un’attività sufficiente per definire il progetto in rapida evoluzione, ben adottato e, allo stesso tempo, ancora giovane dal punto di vista operativo.

Questa duplice natura è importante per la progettazione in produzione. Hermes è abbastanza maturo da supportare lavori reali, ma è sufficientemente dinamico che una configurazione disordinata invecchierà male. L’articolo seguente tratta la configurazione e le competenze come una questione di architettura operativa, non come una checklist di funzionalità.

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

Le competenze di Hermes sono documenti di conoscenza on-demand. Utilizzano la divulgazione progressiva in modo che l’agente possa vedere prima un indice di competenze compatto e caricare il contenuto completo della competenza solo quando necessario, mantenendo sotto controllo l’utilizzo dei token anche quando sono installate molte competenze. Ogni competenza installata diventa un comando slash nella 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 vivo, non come pacchetti congelati. Le competenze incluse nel pacchetto, quelle installate tramite 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 di creazione, patch, modifica, eliminazione e supporto di file per la gestione delle competenze. Questo è potente, ma significa anche che un singolo agente “fai tutto” troppo grande tende a diventare un cassetto procedurale disordinato.

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 nel proprio alias di comando, quindi un profilo chiamato coder diventa coder chat, coder setup, coder gateway start e così via. Nella pratica, ciò rende i profili l’unità reale di proprietà in produzione, non la singola competenza.

La base operativa

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/, le conoscenze procedurali 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, infine i valori predefiniti integrati. Questa è anche la risposta più pulita alla domanda frequente sulla produzione su come separare segreti e configurazioni.

Un layout pratico multi-profilo solitamente finisce per assomigliare a questo, con un profilo per responsabilità piuttosto che un profilo per persona:

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

Questo modello corrisponde a come i profili di Hermes sono documentati: ogni profilo è un 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 memorie o sessioni e che le competenze aggiornate possono essere sincronizzate tra i profili quando l’installazione principale viene aggiornata.

Il prossimo confine operativo è l’esecuzione. Hermes supporta sei backend terminali: locale, Docker, SSH, Modal, Daytona e Singularity, e la documentazione di sicurezza descrive un modello di difesa in profondità che include l’approvazione di comandi pericolosi, l’isolamento dei container, il filtraggio delle credenziali MCP, la scansione dei file di contesto, l’isolamento cross-sessione e la sanitizzazione degli input. In altre parole, la decisione “prima i profili” risponde a chi possiede lo stato, e la decisione sul backend risponde a dove è consentito che avvengano lavori rischiosi.

L’automazione si sovrappone a questa base. I lavori cron di Hermes possono allegare zero, uno o più competenze e vengono eseguiti in sessioni agenti fresche invece di 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 altri. La guida ufficiale MCP aggiunge un’ulteriore regola operativa facile da trascurare: il miglior pattern non è collegare tutto, ma esporre la superficie più piccola utile.

Il profilo di ingegneria del software

La persona più ovvia di Hermes è l’ingegnere software che vuole che l’agente si comporti meno come una finestra di chat e più come un operatore di repository ripetibile. Questo profilo solitamente si preoccupa dell’autenticazione del repository, della triage delle issue, della creazione di PR, della revisione del codice, del debug e dell’esecuzione supportata da piani. Nei cataloghi di Hermes, il pacchetto di competenze integrato fondamentale è insolitamente coerente per questo 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 include anche competenze integrate per agenti autonomi come codex, claude-code, opencode e hermes-agent-spawning.

Ciò che rende utile questo pacchetto non è alcuna singola competenza. È 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 dopo-pensiero, e systematic-debugging impedisce all’agente di saltare direttamente a riparazioni 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 consolidano l’igiene del repository e la disciplina di revisione, non quelle che promettono più 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 conversazione con differenze intermedie, stack trace e note di revisione. In termini operativi, il profilo di ingegneria beneficia di set di competenze ristretti, un backend sandboxato 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 pattern RAG.

Questo profilo è anche il luogo più chiaro per rispondere alla domanda memoria contro competenze. La documentazione di Hermes definisce la memoria come fatti sugli utenti, progetti e preferenze, mentre le competenze memorizzano le procedure su come fare le cose. Il lavoro di ricerca ha bisogno di entrambi. La memoria contiene ciò che l’assistente ha già imparato sul dominio e sulle preferenze del lettore; le competenze codificano procedure ripetibili come “scansionare arXiv, riassumere nuovi paper e scrivere 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.

Il profilo di ricerca beneficia anche in modo sproporzionato 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 rappresentate ciascuna da una competenza nominata piuttosto che nascoste all’interno di 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, ispezioni i sistemi, esegua controlli scriptati, instrada l’output verso un canale e faccia tutto questo senza trasformare l’host in una responsabilità. Hermes ha i giusti mattoni per questo stile di lavoro: webhook-subscriptions integrati per l’attivazione guidata da 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 in container, server MCP personalizzati o iniezione di segreti.

Il motivo per cui questo pacchetto funziona è che ogni competenza possiede un confine. webhook-subscriptions gestisce l’ingresso da sistemi esterni. docker-management trasforma i compiti dei container in una procedura nominata invece di un gioco a shell libera. fastmcp è utile quando Hermes ha bisogno di diventare l’orchestratore intorno a nuovi strumenti MCP, e 1password mantiene la gestione dei segreti esplicita invece di nasconderla nella cronologia del shell o nei file markdown. La guida ufficiale MCP rafforza la stessa istinto operativo: collegare la cosa giusta con la superficie più piccola utile.

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

Il profilo delle operazioni esecutive

C’è una persona Hermes più silenziosa ma molto reale che sembra un capo di stato maggiore, un responsabile delle operazioni o un fondatore pesantemente sovraccarico. Le competenze rilevanti sono meno appariscenti e più orientate all’ufficio: google-workspace, notion, linear, nano-pdf, powerpoint e la competenza integrata himalaya per la posta elettronica, più competenze opzionali ufficiali come agentmail, telephony e one-three-one-rule. Questa miscela dà a Hermes accesso alla casella di posta, al calendario, ai documenti, ai compiti, alle presentazioni, alla pulizia dei PDF, a un framework di comunicazione strutturato e anche flussi di lavoro telefonici e SMS laddove ciò è effettivamente importante.

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

Le funzionalità di messaggistica e voce di Hermes rendono questo profilo più pratico di quanto sembri 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, risposte vocali nella messaggistica e conversazioni vocali live su Discord. La documentazione nota anche che un’istanza di Hermes può servire più utenti tramite allowlist e accoppiamento DM, mentre i token bot rimangono esclusivi di un singolo profilo. Ecco perché una distribuzione intensiva di comunicazione beneficia solitamente di almeno un profilo dedicato invece di condividere la stessa identità bot con ingegneria o operazioni.

Il profilo della piattaforma ML e dati

Hermes è costruito da un laboratorio di ricerca, e questa discendenza è evidente. I cataloghi includono jupyter-live-kernel per lavori di 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 ampio 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 curatela dei dati, valutazione, ricerca vettoriale, fine-tuning e ottimizzazione dell’inferenza. Per un utente della piattaforma ML, Hermes smette di sentirsi come un assistente e inizia a sentirsi come 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 computazionali e di ottimizzazione opzionali permettono a Hermes di parlare coerentemente sia di sperimentazione che di deployment.

Questo è anche il profilo dove la moderazione è più importante. Poiché il catalogo MLOps opzionale è così grande, una configurazione Hermes in produzione per il lavoro ML beneficia solitamente di essere opinata sullo scope. 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 di 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 passività

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

C’è anche un limite a ciò che si dovrebbe chiedere a una competenza. La documentazione di Hermes è esplicita nel dire 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 comportamenti del ciclo di vita. La guida sui plugin mostra persino come un plugin possa includere la propria competenza. In produzione, questo significa che le competenze sono meglio 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à del cambiamento. La documentazione di Hermes indirizza gli utenti a Discord, GitHub Discussions, Issues e Skills Hub, e il repository pubblico mostra rilasci frequenti e una grande impronta di contributi. La conclusione operativa è abbastanza semplice: gli aggiornamenti fanno parte del sistema, non sono un evento esterno ad esso. Una vera configurazione in produzione assume che profili, competenze e presupposti di flusso di lavoro evolveranno, poi usa l’isolamento e pacchi di competenze ristretti in modo che il cambiamento rimanga locale quando inevitabilmente arriva.

Hermes funziona meglio quando le competenze sono trattate come contratti procedurali intorno a profili chiaramente separati. Nel momento in cui un profilo diventa l’agente di ingegneria, l’assistente di ricerca, il lavoratore ops, il bot della casella di posta e la piattaforma ML tutto insieme, il sistema smette di comporsi e inizia a perdere responsabilità. Il pattern di produzione pulito è meno legato ad avere più competenze e più legato a dare a ogni profilo una descrizione del lavoro che può effettivamente mantenere.

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