Hermes AI-assistentfärdigheter för produktionsmiljöer

Hermes AI-assistenten, officiellt dokumenterad som Hermes Agent, positioneras inte som en enkel chattinpackning.

För installation, providerkonfiguration, verktygssandboxning och gateway-konfiguration, se Hermes AI Assistant-guide. Dagliga CLI-ytor (hermes profile, hermes skills, hermes cron och relaterade kommandon) sammanfattas i Hermes Agent CLI-fuskort. Denna artikel fokuserar på arkitekturen för skills och profiler som bestämmer hur Hermes beter sig när den är igång. För konkret SKILL.md-autorisering – frontmatter-fält, katalogstruktur, hemligheter kontra config.yaml, och skills som försvinner från slash-kommandon – se Hermes Agent Skill Authoring – SKILL.md Struktur och Bästa Praxer.

De officiella dokumenten och repositoryt beskriver en självutvecklande agent med en inbyggd lärslinga som skapar skills från erfarenhet, förbättrar dem under användning, bevarar kunskap över sessioner och körs på allt från en lågkostnad VPS till molnsandboxar.

I april 2026 visar det offentliga GitHub-repositoryt cirka 94,6k stjärnor, 13,2k forks och en senaste release med taggen v0.10.0 den 16 april 2026. Det är tillräcklig aktivitet för att kalla projektet snabbt rörligt, väl adopterat och samtidigt operativt ungt.

Denna dubbla natur är viktig för produktionsdesign. Hermes är mogen nog att stödja verkligt arbete, men dynamisk nog att en rörig konfiguration ålderdoms snabbt. Artikeln nedan behandlar konfiguration och skills som en fråga om operativ arkitektur, inte som en kontrolllista över funktioner.

Varför Hermes behöver en profil-först-arkitektur

Hermes skills är kunskapsdokument efter behov. De använder progressiv disclosure så att agenten först kan se en kompakt skill-index och endast ladda full skill-innehåll när det behövs, vilket håller tokenanvändningen under kontroll även när många skills är installerade. Varje installerad skill blir ett slash-kommando i CLI och på chattytorna, och dokumenten positionerar explicit skills som det föredragna utökningsmekanismen när en kapacitet kan uttryckas med instruktioner, shell-kommandon och befintliga verktyg snarare än anpassad agentkod.

Produktionskomplikationen är att Hermes behandlar skills som levande tillstånd, inte frusna paket. Inbyggda skills, hubbinstallerade skills och agent-skapade skills finns alla under ~/.hermes/skills/, och dokumenten anger att agenten kan modifiera eller ta bort skills. Samma system exponerar åtgärder för att skapa, patcha, redigera, ta bort och stödfil för skillhantering. Det är kraftfullt, men det innebär också att en överdimensionerad “gör allt”-agent tenderar att bli en proceduralskåp för skräp.

Profiler är svaret. Hermes profiler är fullt isolerade miljöer, var och en med sin egen config.yaml, .env, SOUL.md, minnen, sessioner, skills, cron-jobb och statdatabas. CLI:n gör också en profil till sin egen kommandoalias, så en profil kallad coder blir coder chat, coder setup, coder gateway start, och så vidare. I praktiken gör det profiler till den verkliga enheten för produktionsägarskap, inte den enskilda skillen.

Produktionsbaslinjen

Baslinjens utformning är överraskande ren. Hermes lagrar icke-secret beteende i ~/.hermes/config.yaml, hemligheter i ~/.hermes/.env, identitet i SOUL.md, bestående fakta i memories/, procedurkunskap i skills/, schemalagda jobb i cron/, sessioner i sessions/ och loggar i logs/. Kommandot hermes config set ruttar API-nycklar till .env och allt annat till config.yaml, och den dokumenterade prioriteringsordningen är CLI-flaggor först, sedan config.yaml, sedan .env, sedan inbyggda standardvärden. Det är också det renaste svaret på produktions-FAQ:n om hur hemligheter och konfiguration bör delas upp.

En praktisk multiprofilstruktur ser oftast ut ungefär som detta, med en profil per ansvarsområde snarare än en profil per människa:

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

Detta mönster matchar hur Hermes profiler dokumenteras: varje profil är sin egen isolerade miljö, och profiler kan klonas från en baskonfiguration när gemensamma standardvärden är användbara. Dokumenten noterar också att profiler inte delar minne eller sessioner, och att uppdaterade skills kan synkroniseras över profiler när huvudinstallationen uppdateras.

Den nästa produktionsgränsen är exekvering. Hermes stödjer sex terminalbackends – lokal, Docker, SSH, Modal, Daytona och Singularity – och säkerhetsdokumenten beskriver ett defense-in-depth-modell som inkluderar godkännande av farliga kommandon, containerisolering, MCP-credential-filtering, kontextfil-scanning, cross-session-isolering och input-sanitizing. Med andra ord svarar beslutet “profil först” på vem som äger tillståndet, och backend-beslutet svarar på var riskabelt arbete får ske.

Automatisering vilar ovanpå denna baslinje. Hermes cron-jobb kan koppla noll, en eller flera skills, och de körs i friska agent-sessioner snarare än att ärva den aktuella chatten. Chattgatewayn är också bakgrundsprocessen som hanterar sessioner, kör cron och ruttar resultat tillbaka till plattformar som Telegram, Discord, Slack, WhatsApp, Email, Matrix och andra. Den officiella MCP-guiden lägger till en till produktionsregel som lätt kan överses: bäst praxis är inte att koppla ihop allt, utan att exponera den minsta användbara ytan. För köbaserad multi-agent-exekvering på självhostade modeller, använd Kanban i Hermes Agent för självhostade LLM-arbetsflöden som ett kompletterande handlingsdokument. Om din produktionslayout placerar Hermes på en headless-maskin och operatörer ansluter från skrivbordsklienter, använd Hermes Agent Headless Server och Remote Desktop Setup för nätverks- och tjänstetopologin.

Software Engineering-profilen

Den mest uppenbara Hermes-personan är mjukvaruingenjören som vill att agenten ska bete sig mindre som ett chattfönster och mer som en återanvändbar repo-operator. Denna profil bryr sig vanligtvis om repository-autentisering, issue-triage, PR-skapande, kodgranskning, felsökning och plan-baserad exekvering. I Hermes-katalogerna är den inbyggda kärnpacken av skills ovanligt sammanhållen för det jobbet: github-auth, github-issues, github-pr-workflow, github-code-review, code-review, plan, writing-plans, systematic-debugging och test-driven-development. Om delegering är viktig levererar Hermes också inbyggda autonoma agent-skills som codex, claude-code, opencode och hermes-agent-spawning.

Det som gör den packen användbar är inte någon enskild skill. Det är sättet som skills kodar utvecklingsproceduren. github-pr-workflow täcker hela PR-livscykeln, github-issues formaliserar issue-operationer, github-code-review och code-review gör granskning till ett distinkt steg istället för en eftertanke, och systematic-debugging hindrar agenten från att hoppa rakt till prematura fixar. Det svarar också på den praktiska frågan om vilka AI-assistent-skills som är viktigast för kodningsarbetsflöden. De mest värdefulla skills är oftast de som låser in repo-hygiene och granskningsdisciplin, inte de som lovar mer rå kodgeneration.

Hermes delegering stärker denna profil ytterligare. Plattformen kan spawna isolerade underagent med sin egen konversation, terminalsession och verktygsuppsättning, och endast den slutliga sammanfattningen returneras till föräldern. För kodbasar är det en renare passform än att stoppa varje mellanliggande diff, stacktrace och granskningsanteckning i en konversation. I produktionsmässiga termer gynnas engineering-profilen av smala skill-set, en sandboxad backend som Docker eller SSH, och generös användning av delegering när kontextbrus börjar dominera.

Research och Knowledge-profilen

Research-profilen är där Hermes börjar kännas distinkt från vanliga assistenter. De inbyggda katalogerna inkluderar redan arxiv, duckduckgo-search, blogwatcher, llm-wiki, ocr-and-documents, obsidian, domain-intel och ml-paper-writing, medan den officiella valfria katalogen lägger till qmd, parallel-cli, scrapling och en bredare research-tier för specialiserade domäner. Den stacken täcker papperssökning, källövervakning, OCR, lokala notesystem, domänrekonsterans, skrivning och hybrid hämtning utan att tvinga allt in i ett enda RAG-mönster.

Denna profil är också den tydeligaste platsen för att svara på minne-vs-skills-frågan. Hermes-dokumentation definierar minne som fakta om användare, projekt och preferenser, medan skills lagrar procedurer för hur man gör saker. Research-arbete behöver båda. Minnet innehåller vad assistenten redan lärt sig om domänen och läsarens preferenser; skills kodar återanvändbara procedurer som “scanna arXiv, sammanfatta nya papper och skriv anteckningar till Obsidian.” Den distinktionen är viktig eftersom produktionsresearchsystem misslyckas när allt behandlas som minne eller allt behandlas som arbetsflöde. Hermes ger dessa bekymmer separata hem. För den fulla tekniska bilden av hur minne fungerar – den två-fils-arkitekturen, karaktärsgränser, prefix-caching och alla åtta externa provider-alternativ – se Hermes Agent Memory System.

Research-profilen gynnas också oproportionerligt av cron. Hermes cron-jobb kan explicit ladda skills före exekvering, och automatiseringsguiderna betonar att schemalagda prompts måste vara helt självständiga eftersom de körs i friska sessioner. En återkommande pipeline som kombinerar blogwatcher, arxiv, obsidian eller llm-wiki är därför mer pålitlig än ett vagt jobb som “kolla vad som ändrades idag”. Med andra ord fungerar research-profiler bäst när källdiscovery, noteskrivning och långsiktig lagring var och en representeras av en namngiven skill snarare än gömd inuti en lång naturlig språk-prompt.

Automation och Operations-profilen

Ops-profilen är mindre glamourös och ofta mer värdefull. Detta är användaren som vill att Hermes ska reagera på händelser, inspektera system, köra skriptade kontroller, rutta output till en kanal och göra allt det utan att göra värden till en säkerhetsrisk. Hermes har rätt byggblock för den typen av arbete: inbyggda webhook-subscriptions för händelsedriven aktivering, inbyggda native-mcp och mcporter för MCP-baserade verktyg, och officiella valfria skills som docker-management, fastmcp, cli och 1password när arbetsflödet expanderar till containrar, anpassade MCP-servrar eller secret-injektion.

Anledningen till att denna pack fungerar är att varje skill äger en gräns. webhook-subscriptions hanterar ingress från externa system. docker-management gör container-chore till en namngiven procedur istället för ett fritt form shell-spel. fastmcp är användbar när Hermes behöver bli orkestratorn runt nya MCP-verktyg, och 1password håller secret-hantering explicit snarare än smugglad in i shell-historik eller markdown-filer. Den officiella MCP-guiden förstärker samma produktionsinstinkt: koppla rätt sak med den minsta användbara ytan. När denna ops-profil konsumeras via mobila chattgränssnitt täcks implementeringsdetaljerna i Hermes Voice Control from Your Phone.

Denna profil är också den renaste platsen för att svara på hur schemalagda AI-arbetsflöden håller sig pålitliga. Hermes cron-dokumentation säger att jobb körs i friska sessioner, kan koppla en eller flera skills, och bör använda självständiga prompts. Cron-felsökningsguiden lägger till att automatisk avfyrning beror på gateway-tickern snarare än en vanlig CLI-chatsession. Så det pålitliga mönstret är rakt fram, även om implementationen inte är det: explicita skills, explicit leveransmål, självständig prompt, isolerad backend och en gateway som faktiskt körs.

Executive Operations-profilen

Det finns en tystare men mycket verklig Hermes-persona som ser ut som en chief of staff, operations-ledare eller tungt överbelastad grundare. De relevanta skills är mindre flashy och mer kontorsformade: google-workspace, notion, linear, nano-pdf, powerpoint och den inbyggda himalaya email-skill, plus officiella valfria skills som agentmail, telephony och one-three-one-rule. Den blandningen ger Hermes åtkomst till inbox, kalender, docs, tasks, decks, PDF-rengöring, ett strukturerat kommunikationsramverk och till och med telefon- och SMS-arbetsflöden där det faktiskt spelar roll.

Flödet här är viktigare än katalogen. google-workspace förankrar daglig exekvering. Notion och Linear förhindrar att assistenten blir systemet för uppgiftsbevis. one-three-one-rule är överraskande användbar eftersom beslutsstöd ofta är det svåraste att standardisera, och den skillen ger Hermes en namngiven procedur för förslag snarare än generisk “sammanfatta detta”-beteende. nano-pdf och powerpoint är den typen av operationella multiplikatorer som ser små ut tills ett team börjar röra vid decks och PDFs varje dag.

Hermes chatt- och röstfunktioner gör denna profil mer praktisk än den först verkar. Gatewayn kan exponera agenten genom Slack, Telegram, Discord, WhatsApp, Email, Matrix och flera andra kanaler, och röststacken stödjer mikrofoninput, talade svar i chatt och live Discord röstkonversationer. Dokumenten noterar också att en Hermes-instans kan servera flera användare genom allowlists och DM-parning, medan bot-tokens förblir exklusiva för en enda profil. Det är därför en kommunikationstung deployment oftast gynnas av minst en dedikerad profil snarare än att dela samma bot-identitet med engineering eller ops.

ML och Data Platform-profilen

Hermes är byggd av ett forskningslaboratorium, och den arvet syns. Katalogerna inkluderar jupyter-live-kernel för stateful notebook-liknande arbete, huggingface-hub för modell- och dataset-operationer, evaluating-llms-harness och weights-and-biases för evaluation och experimenttrackning, qdrant-vector-search för produktions RAG-lagring, och en stor inbyggd och valfri MLOps-tier med skills som axolotl, fine-tuning-with-trl, modal-serverless-gpu, lambda-labs-gpu-cloud, flash-attention, tensorrt-llm, pinecone, qdrant och nemo-curator.

Det som är märkvärdigt här är inte bara bredden. Det är att skills sträcker sig över hela stacken från notebook-iteration till datakuratering, evaluation, vektorsökning, finjustering och inferensoptimering. För en ML-plattformanvändare slutar Hermes att kännas som en assistent och börjar kännas som en kontrollplan som kan bära procedurer över livscykeln. jupyter-live-kernel hanterar iterativ utforskning, evaluating-llms-harness och weights-and-biases formaliserar mätning, och de valfria compute- och optimeringsskills låter Hermes tala sammanhängande om både experiment och deployment.

Detta är också profilen där avhållsamhet är viktigast. Eftersom den valfria MLOps-katalogen är så stor gynnas oftast en produktions-Hermes-setup för ML-arbete av att vara opinerad om scope. En platform engineering-profil som äger evaluation och deployment behöver inte varje träningsramverk installerat. En research-profil som äger papper och notesystem behöver inte varje vektordatabasskill. Hermes kan bära enorma skill-inventarier, men produktionsanvändbarhet kommer fortfarande från att smalsäta den aktiva ytan.

Där skills blir skulder

Den starkaste delen av Hermes skills-system är också den plats där produktionssetups går fel. Hermes kan bläddra och installera skills från sin inbyggda katalog, den officiella valfria katalogen, Vercels skills.sh, välkända skill-endpoints, direkta GitHub-repositories och marknadsplats-liknande community-källor. Säkerhetsmodellen skiljer på builtin, official, trusted och community-källor, kör säkerhetsskanningar för hubbinstallerade skills och tillåter --force endast för icke-farliga policy-block. Ett farligt skanningsdomstol förblir blockerat. Hermes exponerar också upstream-metadata som repository-URL, veckovisa installationer och audit-signaler under inspektion. Det är en solid förtroendemodell, men det är inte ett substitut för smak.

Det finns också en gräns för vad en skill bör be att göra. Hermes-dokumentation är explicit om att skills är det föredragna valet när jobbet kan uttryckas som instruktioner plus shell-kommandon plus befintliga verktyg, medan plugins är den mer ärliga abstraktionen för anpassade verktyg, hooks och livscykelsbeteende. Plugin-guiden visar till och med hur en plugin kan bundla sin egen skill. I produktion betyder det att skills bäst behandlas som återanvändbara procedurer, inte som ett tvingat substitut för verktygs- eller plugin-design.

Community och support ser friska ut, men de raderar inte förändringshastighet. Hermes-dokumentation pekar användare mot Discord, GitHub Discussions, Issues och Skills Hub, och det offentliga repositoryt visar frekventa releases och ett stort bidragsavtryck. Den operativa slutsatsen är enkel nog: uppdateringar är en del av systemet, inte en händelse utanför det. En riktig produktionssetup antar att profiler, skills och arbetsflödesantaganden kommer att utvecklas, och använder sedan isolering och smala skill-packs så att förändring förblir lokal när den oundvikligen kommer.

Hermes fungerar bäst när skills behandlas som proceduravtal kring tydligt separerade profiler. Ögonblicket en profil blir engineering-agenten, research-assistenten, ops-arbetaren, inbox-botn och ML-plattformen all på en gång, slutar systemet att compounda och börjar läcka ansvarsområden. Den rena produktionsmönstret handlar mindre om att ha fler skills och mer om att ge varje profil en jobbeskrivning den faktiskt kan hålla.

Denna artikel är en del av AI Systems-klustret, som täcker självhostade assistenter, retrieval-arkitektur, lokal LLM-infrastruktur och observability.