Competenze dell'assistente AI Hermes per ambienti di produzione reali

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

Per l’installazione, la configurazione del provider, il sandboxing degli strumenti e la configurazione del gateway, consulta la guida all’assistente AI Hermes. Le interfacce CLI quotidiane (hermes profile, hermes skills, hermes cron e comandi correlati) sono riassunte nella scheda di riferimento rapida per la CLI di Hermes Agent. Questo articolo si concentra sull’architettura delle competenze e dei profili che determina il comportamento di Hermes una volta in esecuzione. Per dettagli sulla creazione di SKILL.md — campi frontmatter, struttura delle directory, segreti rispetto a config.yaml e competenze che scompaiono dai comandi con slash — consulta Creazione di competenze per Hermes Agent — Struttura e best practice di SKILL.md.

La documentazione ufficiale e il repository descrivono un agente auto-migliorante con un ciclo di apprendimento integrato che crea competenze dall’esperienza, le migliora durante l’uso, persiste la conoscenza tra le sessioni e gira su qualsiasi cosa, da un VPS a basso costo a 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 del 16 aprile 2026. È un’attività sufficiente per definire il progetto in rapida evoluzione, ben adottato e ancora operativo giovane, tutto contemporaneamente.

Questa natura duplice è importante per la progettazione in produzione. Hermes è abbastanza maturo da supportare lavoro reale, ma abbastanza 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 disclosure progressiva in modo che l’agente possa vedere prima un indice delle competenze compatto e caricare il contenuto completo della competenza solo quando necessario, mantenendo l’utilizzo dei token sotto controllo anche quando sono installate molte competenze. Ogni competenza installata diventa un comando con 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 stato vivente, non come pacchetti congelati. Le competenze bundled, quelle installate dall’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 file di supporto per la gestione delle competenze. Questo è potente, ma significa anche che un agente “faccio tutto” eccessivamente grande tende a diventare un cassetto della spazzatura procedurale.

I profili sono la soluzione. I profili 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 singola competenza.

La base produttiva

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 pianificati 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 CLI, poi config.yaml, poi .env, poi i valori predefiniti integrati. 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 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 memoria o sessioni, e che le competenze aggiornate possono essere sincronizzate tra i profili quando l’installazione principale viene aggiornata.

Il confine produttivo successivo è 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 approvazione di comandi pericolosi, isolamento dei container, filtraggio delle credenziali MCP, scansione dei file di contesto, isolamento cross-sessione e 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 è permesso accadere il lavoro rischioso.

L’automazione si basa su questa base. I lavori cron di Hermes possono attaccare zero, uno o più competenze, e si eseguono in sessioni agente fresche piuttosto che ereditare la chat corrente. Il gateway di messaggistica è anche il processo in background che gestisce le sessioni, esegue i cron e instrada i risultati verso piattaforme come Telegram, Discord, Slack, WhatsApp, Email, Matrix e altre. La guida ufficiale MCP aggiunge un’altra regola di produzione facile da trascurare: il modello migliore non è connettere tutto, ma esporre la superficie minima utile. Per l’esecuzione multi-agente in stile coda su modelli auto-gestiti, usa Kanban in Hermes Agent per Flussi di Lavoro LLM Auto-gestiti come runbook companion. Se il tuo layout di produzione posiziona Hermes su una macchina headless e gli operatori si connettono da client desktop, usa Configurazione Server Headless e Desktop Remoto per Hermes Agent per la topologia di rete e servizi.

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 repo ripetibile. Questo profilo di solito si preoccupa di autenticazione repo, triage delle issue, creazione PR, revisione del codice, debugging ed esecuzione basata su piani. Nei cataloghi 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 è alcuna singola competenza. È il modo in cui le competenze codificano la procedura di sviluppo. github-pr-workflow copre l’intero ciclo di vita della PR, github-issues formalizza le operazioni delle issue, github-code-review e code-review rendono la revisione un passo distinto invece di un’idea successiva, e systematic-debugging impedisce all’agente di saltare direttamente a correzioni premature. Questo risponde anche alla domanda pratica su quali competenze dell’assistente AI sono più importanti per i flussi di lavoro di coding. Le competenze a valore più alto sono di solito quelle che bloccano l’igiene del repo 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 infilare 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 ristretti, 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, monitoraggio delle fonti, OCR, sistemi di note locali, ricognizione del dominio, scrittura e recupero ibrido senza forzare tutto in un unico 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 contiene ciò che l’assistente ha già imparato sul dominio e sulle preferenze del lettore; le competenze codificano procedure ripetibili come “scansiona arXiv, riassumi 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 l’immagine tecnica completa di come funziona la memoria — l’architettura a due file, limiti di caratteri, caching dei prefixi e tutte le otto opzioni di provider esterne — consulta Sistema di Memoria di Hermes Agent.

Il profilo di ricerca beneficia anche in modo sproporzionato di cron. I lavori cron di Hermes possono caricare esplicitamente le competenze prima dell’esecuzione, e le guide di automazione sottolineano che i prompt pianificati devono essere completamente auto-contenuti perché si eseguono in sessioni fresche. Una 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 ciascuno rappresentati da una competenza nominata piuttosto che nascosti 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, ispetti i sistemi, esegua controlli scriptati, instradi l’output verso un canale e faccia tutto ciò senza trasformare l’host in una responsabilità. Hermes ha i giusti mattoni per quel tipo di lavoro: webhook-subscriptions integrato 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 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’ingress da sistemi esterni. docker-management trasforma le faccende dei container in una procedura nominata invece di un gioco shell libero. fastmcp è utile quando Hermes deve diventare l’orchestratore attorno a nuovi strumenti MCP, e 1password mantiene la gestione dei segreti esplicita piuttosto che nascosta nella storia shell o nei file markdown. La guida ufficiale MCP rafforza lo stesso istinto di produzione: connettere la cosa giusta con la superficie minima utile. Quando questo profilo ops viene consumato attraverso interfacce di chat mobili, i dettagli di implementazione sono coperti in Controllo Vocale di Hermes dal Tuo Telefono.

Questo profilo è anche il posto più pulito per rispondere a come i flussi di lavoro AI pianificati rimangono affidabili. La documentazione cron di Hermes dice che i lavori si eseguono in sessioni fresche, possono attaccare una o più competenze e dovrebbero usare prompt auto-contenuti. La guida di risoluzione dei problemi cron aggiunge che l’attivazione automatica dipende dal ticker del gateway piuttosto che da una sessione di chat CLI ordinaria. Quindi il modello affidabile è straightforward anche se l’implementazione non lo è: competenze espliciti, target di consegna esplicito, prompt auto-contenuto, backend isolato e un gateway che è effettivamente in esecuzione.

Il profilo di operazioni esecutive

C’è una persona Hermes più silenziosa ma molto reale che assomiglia a un capo di staff, responsabile delle operazioni o fondatore sovraccarico. Le competenze rilevanti sono meno brillanti 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 casella di posta, calendario, documenti, task, deck, pulizia PDF, un framework di comunicazione strutturato e persino 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 record dei task. 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 quel tipo di moltiplicatori operativi che sembrano piccoli finché un team non inizia a toccare deck 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 input microfonico, risposte vocali nella messaggistica e conversazioni vocali live su Discord. La documentazione nota anche che un’istanza Hermes può servire più utenti attraverso allowlist e abbinamento DM, mentre i token bot rimangono esclusivi a un singolo profilo. Ecco perché una distribuzione pesante sulla comunicazione beneficia di solito 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 quella linea si vede. I cataloghi includono jupyter-live-kernel per lavoro in 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 lo storage 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 curazione dei dati, valutazione, ricerca vettoriale, fine-tuning 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 distribuzione.

Questo è anche il profilo dove la moderazione conta di più. Poiché il catalogo MLOps opzionale è così grande, una configurazione Hermes in produzione per lavoro ML di solito beneficia di essere opinionata sull’ambito. Un profilo di ingegneria della piattaforma che possiede valutazione e distribuzione 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ò portare inventari di competenze enormi, 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 le configurazioni di produzione vanno male. Hermes può navigare e installare competenze dal suo catalogo integrato, il catalogo opzionale ufficiale, skills.sh di Vercel, endpoint di competenze ben noti, repository GitHub diretti e fonti comunitarie in stile marketplace. Il modello di sicurezza distingue tra fonti builtin, official, trusted e community, esegue scansioni di sicurezza per le competenze installate dall’hub e permette --force solo per blocchi di policy 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 solido modello di fiducia, ma non è un sostituto del gusto.

C’è anche un limite a ciò a cui si dovrebbe chiedere di fare 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 anche come un plugin possa raggruppare la propria competenza. In produzione, questo significa che le competenze sono meglio trattate come procedure riutilizzabili, non come un sostituto forzato per il design di strumenti o plugin appropriati.

La comunità e il supporto sembrano sani, ma non cancellano la velocità di cambiamento. La documentazione di Hermes indirizza gli utenti a Discord, Discussioni GitHub, Issue e Skills Hub, e il repository pubblico mostra rilasci frequenti e un grande impronta di contributi. La conclusione operativa è abbastanza semplice: gli aggiornamenti sono parte del sistema, non un evento esterno. Una vera configurazione di produzione assume che profili, competenze e assunzioni di flusso di lavoro evolveranno, poi usa l’isolamento e pacchetti di competenze ristretti in modo che il cambiamento rimanga locale quando arriva inevitabilmente.

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 casella di posta e la piattaforma ML tutto insieme, il sistema smette di comporre e inizia a perdere responsabilità. Il modello di produzione 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 auto-gestiti, architettura di recupero, infrastruttura LLM locale e osservabilità.