Hermes KI-Assistent: Fähigkeiten für echte Produktionsumgebungen

Der Hermes KI-Assistent, offiziell dokumentiert als Hermes Agent, positioniert sich nicht als einfacher Chat-Wrapper.

Für die Installation, die Konfiguration des Anbieters, die Sandbox-Umgebung für Tools und die Gateway-Konfiguration siehe den Hermes AI Assistant Guide. Dieser Artikel konzentriert sich auf die Architektur von Fähigkeiten (Skills) und Profilen, die bestimmt, wie sich Hermes verhält, sobald er läuft.

Die offiziellen Dokumentationen und das Repository beschreiben einen sich selbst verbessernden Agenten mit einer integrierten Lernschleife, die Fähigkeiten aus Erfahrung erstellt, diese während der Nutzung verbessert, Wissen über Sitzungen hinweg persistiert und auf anything von einem kostengünstigen VPS bis hin zu Cloud-Sandboxes läuft.

Im April 2026 zeigt das öffentliche GitHub-Repository etwa 94.6k Sterne, 13.2k Forks und die neueste Release-Version ist als v0.10.0 vom 16. April 2026 getaggt. Das ist genug Aktivität, um das Projekt als schnelllebend, gut angenommen und gleichzeitig operationell jung zu bezeichnen.

Diese duale Natur ist für das Produktionsdesign von Bedeutung. Hermes ist reif genug, um echte Arbeit zu unterstützen, aber dynamisch genug, dass ein unordentliches Setup schnell veraltet. Der folgende Artikel behandelt Konfiguration und Fähigkeiten als Frage der operativen Architektur, nicht als reine Feature-Checkliste.

Warum Hermes eine profilzentrierte Architektur benötigt

Hermes-Skills sind Bedarfsdokumente für Wissen. Sie nutzen progressive Offenlegung, sodass der Agent zunächst einen kompakten Skill-Index sehen kann und den vollständigen Skill-Inhalt nur bei Bedarf lädt, was die Token-Nutzung unter Kontrolle hält, selbst wenn viele Skills installiert sind. Jeder installierte Skill wird zu einem Slash-Befehl in der CLI und in Messaging-Oberflächen, und die Dokumentationen positionieren Skills explizit als bevorzugten Erweiterungsmechanismus, wenn eine Fähigkeit durch Anweisungen, Shell-Befehle und vorhandene Tools ausgedrückt werden kann, anstatt benutzerdefinierten Agenten-Code zu schreiben.

Die Komplikation in der Produktion besteht darin, dass Hermes Skills als lebendigen Zustand behandelt, nicht als eingefrorene Pakete. Eingebundene Skills, über den Hub installierte Skills und von Agenten erstellte Skills leben alle unter ~/.hermes/skills/, und die Dokumentationen geben an, dass der Agent Skills modifizieren oder löschen kann. Dasselbe System bietet Aktionen zum Erstellen, Patchen, Bearbeiten, Löschen und Verwalten unterstützender Dateien für das Skill-Management. Das ist leistungsfähig, bedeutet aber auch, dass ein übergroßer „Alles-könner“-Agent tendenziell zu einem Ablagefach für Prozeduren wird.

Profile sind die Antwort. Hermes-Profile sind vollständig isolierte Umgebungen, jede mit eigener config.yaml, .env, SOUL.md, Erinnerungen, Sitzungen, Skills, Cron-Jobs und Zustandsdatenbank. Die CLI verwandelt ein Profil auch in seinen eigenen Befehlsalias, sodass ein Profil namens coder zu coder chat, coder setup, coder gateway start usw. wird. In der Praxis macht das Profile zur eigentlichen Einheit des Produktionsbesitzes, nicht den einzelnen Skill.

Das Produktions-Baseline

Die Basisstruktur ist überraschend klar. Hermes speichert nicht-geheimes Verhalten in ~/.hermes/config.yaml, Geheimnisse in ~/.hermes/.env, Identität in SOUL.md, persistente Fakten in memories/, prozedurales Wissen in skills/, geplante Jobs in cron/, Sitzungen in sessions/ und Logs in logs/. Der Befehl hermes config set leitet API-Schlüssel in .env und alles andere in config.yaml weiter, und die dokumentierte Prioritätsreihenfolge ist CLI-Flags zuerst, dann config.yaml, dann .env, dann die eingebauten Standardwerte. Das ist auch die sauberste Antwort auf die häufig gestellte Produktionsfrage, wie Geheimnisse und Konfiguration getrennt werden sollten.

Ein praktisches Multi-Profile-Layout sieht in der Regel so aus, mit einem Profil pro Verantwortung statt einem Profil pro Mensch:

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

Dieses Muster passt dazu, wie Hermes-Profile dokumentiert sind: Jedes Profil ist seine eigene isolierte Umgebung, und Profile können von einer Basis-Konfiguration geklont werden, wenn gemeinsame Standardwerte nützlich sind. Die Dokumentationen weisen auch darauf hin, dass Profile keine Erinnerungen oder Sitzungen teilen und dass aktualisierte Skills synchronisiert werden können, wenn die Hauptinstallation aktualisiert wird.

Die nächste Produktionsgrenze ist die Ausführung. Hermes unterstützt sechs Terminal-Backends – lokal, Docker, SSH, Modal, Daytona und Singularity – und die Sicherheitsdokumentationen beschreiben ein Defense-in-Depth-Modell, das die Genehmigung gefährlicher Befehle, Container-Isolation, MCP-Credential-Filterung, Kontextdatei-Scans, Cross-Session-Isolation und Eingabesäuberung umfasst. Mit anderen Worten: Die Entscheidung „Profil zuerst“ beantwortet, wer den Zustand besitzt, und die Backend-Entscheidung beantwortet, wo riskante Arbeit erlaubt ist.

Automatisierung sitzt auf dieser Basis. Hermes-Cron-Jobs können null, einen oder mehrere Skills anhängen und laufen in frischen Agentensitzungen, statt die aktuelle Chat-Sitzung zu erben. Das Messaging-Gateway ist auch der Hintergrundprozess, der Sitzungen verwaltet, Cron ausführt und Ergebnisse an Plattformen wie Telegram, Discord, Slack, WhatsApp, E-Mail, Matrix und andere zurückleitet. Der offizielle MCP-Guide fügt eine weitere Produktionsregel hinzu, die leicht übersehen wird: Das beste Muster ist nicht, alles zu verbinden, sondern die kleinstmögliche nützliche Oberfläche freizulegen.

Das Software-Engineering-Profil

Die offensichtlichste Hermes-Persona ist der Software-Ingenieur, der möchte, dass der Agent sich weniger wie ein Chat-Fenster und mehr wie ein wiederholbarer Repo-Operator verhält. Dieses Profil kümmert sich in der Regel um Repository-Authentifizierung, Issue-Triage, PR-Erstellung, Code-Review, Debugging und plangesteuerte Ausführung. In den Hermes-Katalogen ist der Kern der eingebauten Skills-Packungen für diese Aufgabe ungewöhnlich kohärent: github-auth, github-issues, github-pr-workflow, github-code-review, code-review, plan, writing-plans, systematic-debugging und test-driven-development. Wenn Delegation wichtig ist, liefert Hermes auch eingebaut autonome Agenten-Skills wie codex, claude-code, opencode und hermes-agent-spawning.

Was dieses Pack nützlich macht, ist nicht irgendein einzelner Skill. Es ist die Art und Weise, wie die Skills Entwicklungsprozedur kodieren. github-pr-workflow deckt den vollständigen PR-Lebenszyklus ab, github-issues formalisiert Issue-Operationen, github-code-review und code-review machen Review zu einem eigenen Schritt statt zu einem nachträglichen Gedanken, und systematic-debugging hindert den Agenten daran, direkt zu vorzeitigen Fixes zu springen. Das beantwortet auch die praktische Frage, welche KI-Assistenten-Skills für Coding-Workflows am meisten zählen. Die Skills mit dem höchsten Wert sind in der Regel diejenigen, die Repo-Hygiene und Review-Disziplin verankern, nicht diejenigen, die mehr rohe Code-Generation versprechen.

Hermes-Delegation verstärkt dieses Profil weiter. Die Plattform kann isolierte Child-Agents mit eigener Konversation, Terminal-Sitzung und Toolset spawnen, und nur die endgültige Zusammenfassung wird an den Parent zurückgegeben. Für Codebases ist das ein saubererer Fit, als jeden Zwischendiff, Stack-Trace und Review-Notiz in eine Konversation zu stopfen. In Produktionsbegriffen profitiert das Engineering-Profil von engen Skill-Sets, einem gesandten Backend wie Docker oder SSH und großzügiger Nutzung von Delegation, wenn Kontext-Lärm beginnt zu dominieren.

Das Forschungs- und Wissensprofil

Das Forschungsprofil ist der Ort, an dem Hermes sich von gewöhnlichen Assistenten zu unterscheiden beginnt. Die eingebauten Kataloge enthalten bereits arxiv, duckduckgo-search, blogwatcher, llm-wiki, ocr-and-documents, obsidian, domain-intel und ml-paper-writing, während der offizielle optionale Katalog qmd, parallel-cli, scrapling und eine breitere Forschungsebene für spezialisierte Domänen hinzufügt. Dieser Stack deckt Papersuche, Quellenüberwachung, OCR, lokale Notizsysteme, Domänenreconnaissance, Schreiben und hybrides Retrieval ab, ohne alles in ein einzelnes RAG-Muster zu zwingen.

Dieses Profil ist auch der klarste Ort, um die Frage nach Erinnerungen versus Skills zu beantworten. Hermes-Dokumentation definiert Erinnerungen als Fakten über Benutzer, Projekte und Präferenzen, während Skills Prozeduren speichern, wie man Dinge tut. Forschungsarbeit benötigt beides. Erinnerungen halten, was der Assistent bereits über die Domäne und die Präferenzen des Lesers gelernt hat; Skills kodifizieren wiederholbare Prozeduren wie „scan arXiv, fasse neue Papers zusammen und schreibe Notizen in Obsidian“. Diese Unterscheidung ist wichtig, weil Produktionsforschungssysteme scheitern, wenn alles als Erinnerung oder alles als Workflow behandelt wird. Hermes gibt diesen Anliegen separate Zuhause. Für das vollständige technische Bild davon, wie Erinnerung funktioniert – die Zwei-Datei-Architektur, Zeichenlimits, Prefix-Caching und alle acht externen Provider-Optionen – siehe Hermes Agent Memory System.

Das Forschungsprofil profitiert auch unverhältnismäßig stark von Cron. Hermes-Cron-Jobs können explizit Skills vor der Ausführung laden, und die Automatisierungsleitfäden betonen, dass geplante Prompts vollständig selbstständig sein müssen, da sie in frischen Sitzungen laufen. Eine wiederkehrende Pipeline, die blogwatcher, arxiv, obsidian oder llm-wiki kombiniert, ist daher zuverlässiger als ein vager Job „prüfe, was heute geändert wurde“. Mit anderen Worten: Forschungsprofile funktionieren am besten, wenn Quellenentdeckung, Notizschreiben und langfristige Speicherung jeweils durch einen benannten Skill repräsentiert werden, statt in einem langen Natural-Language-Prompt versteckt zu sein.

Das Automatisierungs- und Operationsprofil

Das Ops-Profil ist weniger glamourös und oft wertvoller. Das ist der Benutzer, der möchte, dass Hermes auf Ereignisse reagiert, Systeme inspiziert, skriptgesteuerte Checks ausführt, Ausgabe an einen Kanal weiterleitet und all das tut, ohne den Host zu einer Haftung zu machen. Hermes hat die richtigen Bausteine für diese Art von Arbeit: eingebaut webhook-subscriptions für ereignisgesteuerte Aktivierung, eingebaut native-mcp und mcporter für MCP-basierte Tools, und offizielle optionale Skills wie docker-management, fastmcp, cli und 1password, wenn der Workflow in Container, benutzerdefinierte MCP-Server oder Secret-Injektion expandiert.

Der Grund, warum dieses Pack funktioniert, ist, dass jeder Skill eine Grenze besitzt. webhook-subscriptions behandelt den Ingress von externen Systemen. docker-management verwandelt Container-Chores in eine benannte Prozedur statt in ein freies Shell-Spiel. fastmcp ist nützlich, wenn Hermes der Orchestrator um neue MCP-Tools herum werden muss, und 1password hält die Geheimnisverwaltung explizit, statt sie in Shell-Historie oder Markdown-Dateien zu schmuggeln. Die offizielle MCP-Leitlinie verstärkt dieselbe Produktionsinstinkt: Verbinde die richtige Sache mit der kleinstmöglichen nützlichen Oberfläche.

Dieses Profil ist auch der sauberste Ort, um zu beantworten, wie geplante AI-Workflows zuverlässig bleiben. Hermes-Cron-Dokumentation sagt, dass Jobs in frischen Sitzungen laufen, einen oder mehrere Skills anhängen können und selbstständige Prompts verwenden sollten. Die Cron-Fehlerbehebungsleitfaden fügt hinzu, dass automatisches Auslösen vom Gateway-Ticker abhängt, nicht von einer gewöhnlichen CLI-Chat-Sitzung. Das zuverlässige Muster ist daher straightforward, auch wenn die Implementierung es nicht ist: explizite Skills, explizites Ziel, selbstständiger Prompt, isoliertes Backend und ein Gateway, das tatsächlich läuft.

Das Executive-Operations-Profil

Es gibt eine leiseres, aber sehr reales Hermes-Persona, die wie ein Chief of Staff, Operations-Lead oder stark überlasteter Gründer aussieht. Die relevanten Skills sind weniger auffällig und mehr bürogeformt: google-workspace, notion, linear, nano-pdf, powerpoint und der eingebaut himalaya E-Mail-Skill, plus offizielle optionale Skills wie agentmail, telephony und one-three-one-rule. Diese Mischung gibt Hermes Zugang zu Inbox, Kalender, Docs, Tasks, Decks, PDF-Unterrichtung, einem strukturierten Kommunikationsframework und sogar Telefon- und SMS-Workflows, wo das tatsächlich wichtig ist.

Der Flow hier ist wichtiger als der Katalog. google-workspace verankert die tägliche Ausführung. Notion und Linear verhindern, dass der Assistent zum Aufzeichnungssystem für Tasks wird. one-three-one-rule ist überraschend nützlich, weil Entscheidungsunterstützung oft das schwierigste Ding zu standardisieren ist, und dieser Skill gibt Hermes eine benannte Prozedur für Vorschläge statt generischem „fasse das zusammen“-Verhalten. nano-pdf und powerpoint sind die Art von operativen Multiplikatoren, die klein aussehen, bis ein Team anfängt, Decks und PDFs jeden Tag zu berühren.

Hermes-Messaging- und Voice-Features machen dieses Profil praktischer, als es zunächst erscheint. Das Gateway kann den Agenten durch Slack, Telegram, Discord, WhatsApp, E-Mail, Matrix und mehrere andere Kanäle exponieren, und der Voice-Stack unterstützt Mikrofon-Eingabe, gesprochene Antworten im Messaging und Live-Discord-Voice-Konversationen. Die Dokumentationen weisen auch darauf hin, dass eine Hermes-Instanz mehrere Benutzer durch Allowlists und DM-Paarung bedienen kann, während Bot-Tokens exklusiv für ein einzelnes Profil bleiben. Das ist, warum eine kommunikationslastige Deployment in der Regel von mindestens einem dedizierten Profil profitiert, statt dieselbe Bot-Identität mit Engineering oder Ops zu teilen.

Das ML- und Data-Platform-Profil

Hermes wird von einem Forschungslabor gebaut, und diese Abstammung zeigt sich. Die Kataloge enthalten jupyter-live-kernel für zustandsbehaftete Notebook-ähnliche Arbeit, huggingface-hub für Model- und Dataset-Operationen, evaluating-llms-harness und weights-and-biases für Evaluierung und Experiment-Tracking, qdrant-vector-search für Produktions-RAG-Speicherung, und eine große eingebaut und optionale MLOps-Ebene mit Skills wie axolotl, fine-tuning-with-trl, modal-serverless-gpu, lambda-labs-gpu-cloud, flash-attention, tensorrt-llm, pinecone, qdrant und nemo-curator.

Was hier bemerkenswert ist, ist nicht nur die Breite. Es ist, dass die Skills den ganzen Stack abdecken, von Notebook-Iteration über Data-Curation, Evaluierung, Vektorsuche, Fine-Tuning bis hin zu Inferenzoptimierung. Für einen ML-Platform-Benutzer hört Hermes auf, wie ein Assistent zu fühlen, und beginnt wie eine Control Plane zu fühlen, die Prozeduren über den Lebenszyklus hinweg tragen kann. jupyter-live-kernel behandelt iterative Exploration, evaluating-llms-harness und weights-and-biases formalisieren Messung, und die optionalen Compute- und Optimierungs-Skills lassen Hermes kohärent über Experimentierung und Deployment sprechen.

Dies ist auch das Profil, wo Zurückhaltung am meisten zählt. Weil der optionale MLOps-Katalog so groß ist, profitiert eine Produktions-Hermes-Setup für ML-Arbeit in der Regel davon, opinionated über Umfang zu sein. Ein Platform-Engineering-Profil, das Evaluierung und Deployment besitzt, benötigt nicht jeden Trainingsframework installiert. Ein Forschungsprofil, das Papers und Notizsysteme besitzt, benötigt nicht jeden Vektordatenbank-Skill. Hermes kann riesige Skill-Inventare tragen, aber Produktionsnützlichkeit kommt immer noch von der Eingrenzung der aktiven Oberfläche.

Wo Skills zu Lasten werden

Der stärkste Teil des Hermes-Skills-Systems ist auch der Ort, an dem Produktions-Setups falsch laufen. Hermes kann Skills aus seinem eingebauten Katalog, dem offiziellen optionalen Katalog, Vercels skills.sh, bekannten Skill-Endpoints, direkten GitHub-Repositories und marktplatzartigen Community-Quellen durchsuchen und installieren. Das Sicherheitsmodell unterscheidet zwischen builtin, official, trusted und community Quellen, führt Security-Scans für Hub-installierte Skills durch und erlaubt --force nur für nicht-gefährliche Policy-Blöcke. Ein gefährliches Scan-Urteil bleibt blockiert. Hermes exponiert auch Upstream-Metadaten wie Repository-URL, wöchentliche Installationen und Audit-Signale während der Inspektion. Das ist ein solides Vertrauensmodell, aber es ist kein Ersatz für Geschmack.

Es gibt auch eine Grenze dafür, was von einem Skill verlangt werden sollte. Hermes-Dokumentation ist explizit, dass Skills die bevorzugte Wahl sind, wenn der Job als Anweisungen plus Shell-Befehle plus vorhandene Tools ausgedrückt werden kann, während Plugins die ehrlichere Abstraktion für benutzerdefinierte Tools, Hooks und Lifecycle-Verhalten sind. Der Plugin-Guide zeigt sogar, wie ein Plugin seinen eigenen Skill bündeln kann. In der Produktion bedeutet das, dass Skills am besten als wiederverwendbare Prozeduren behandelt werden, nicht als erzwungener Ersatz für echtes Tool- oder Plugin-Design.

Community und Support sehen gesund aus, aber sie tilgen nicht die Änderungsgeschwindigkeit. Hermes-Dokumentation verweist Benutzer auf Discord, GitHub Discussions, Issues und den Skills Hub, und das öffentliche Repository zeigt häufige Releases und einen großen Beitrags-Fußabdruck. Der operative Takeaway ist einfach genug: Updates sind Teil des Systems, kein Ereignis außerhalb davon. Eine echte Produktions-Setup geht davon aus, dass Profile, Skills und Workflow-Annahmen sich entwickeln werden, und verwendet dann Isolation und enge Skill-Packs, sodass Änderung lokal bleibt, wenn sie unweigerlich eintrifft.

Hermes funktioniert am besten, wenn Skills als prozedurale Verträge um klar getrennte Profile behandelt werden. Der Moment, in dem ein Profil der Engineering-Agent, der Forschungs-Assistent, der Ops-Arbeiter, der Inbox-Bot und die ML-Plattform alle auf einmal wird, hört das System auf, zu komponieren, und beginnt, Verantwortlichkeiten zu lecken. Das saubere Produktionsmuster ist weniger darum, mehr Skills zu haben, und mehr darum, jedem Profil eine Jobbeschreibung zu geben, die es tatsächlich halten kann.

Dieser Artikel ist Teil des AI Systems Clusters, der selbstgehostete Assistenten, Retrieval-Architektur, lokale LLM-Infrastruktur und Observability abdeckt.