Hermes KI-Assistenten-Funktionen für echte Produktionsumgebungen

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

Für die Installation, die Konfiguration der Provider, das Tool-Sandboxing und die Gateway-Konfiguration siehe den Hermes AI Assistant Leitfaden. Die täglichen CLI-Oberflächen (hermes profile, hermes skills, hermes cron und verwandte Befehle) sind im Hermes Agent CLI Cheat Sheet zusammengefasst. Dieser Artikel konzentriert sich auf die Architektur von Fähigkeiten und Profilen, die bestimmt, wie sich Hermes verhält, sobald er läuft. Für die konkrete Erstellung von SKILL.md-Dateien – Frontmatter-Felder, Verzeichnisstruktur, Geheimnisse gegenüber config.yaml und Fähigkeiten, die aus Slash-Befehlen verschwinden – siehe Hermes Agent Skill Authoring – Struktur und Best Practices für SKILL.md.

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

Im April 2026 zeigt das öffentliche GitHub-Repository etwa 94,6k Stars, 13,2k Forks und die neueste Version mit dem Tag v0.10.0 vom 16. April 2026. Das ist genug Aktivität, um das Projekt als schnelllebend, gut angenommen und zugleich noch operativ 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 chaotisches Setup schnell veraltet. Der folgende Artikel betrachtet Konfiguration und Fähigkeiten als Frage der operativen Architektur, nicht als reine Feature-Checkliste.

Warum Hermes eine profilzentrierte Architektur benötigt

Hermes-Fähigkeiten sind bedarfsgerecht abrufbare Wissensdokumente. Sie nutzen progressive Enthüllung, sodass der Agent zuerst einen kompakten Fähigkeitsindex sehen kann und den vollständigen Fähigkeitsinhalt nur bei Bedarf lädt, was die Token-Nutzung unter Kontrolle hält, selbst wenn viele Fähigkeiten installiert sind. Jede installierte Fähigkeit wird zu einem Slash-Befehl in der CLI und in Messaging-Oberflächen, und die Dokumentation positioniert Fähigkeiten explizit als bevorzugten Erweiterungsmechanismus, wenn eine Fähigkeit durch Anweisungen, Shell-Befehle und bestehende Werkzeuge ausgedrückt werden kann, anstatt benutzerdefinierten Agenten-Code zu schreiben.

Die Komplikation in der Produktion besteht darin, dass Hermes Fähigkeiten als lebendigen Zustand behandelt, nicht als eingefrorene Pakete. Eingebundene Fähigkeiten, über den Hub installierte Fähigkeiten und vom Agenten erstellte Fähigkeiten leben alle unter ~/.hermes/skills/, und die Dokumentation besagt, dass der Agent Fähigkeiten ändern oder löschen kann. Dasselbe System stellt Aktionen zum Erstellen, Patchen, Bearbeiten, Löschen und für unterstützende Dateien für das Fähigkeitsmanagement bereit. Das ist leistungsstark, bedeutet aber auch, dass ein übergroßer „Alles-könner“-Agent schnell zu einem unübersichtlichen Sammelsurium wird.

Profile sind die Antwort. Hermes-Profile sind vollständig isolierte Umgebungen, jede mit ihrer eigenen config.yaml, .env, SOUL.md, Erinnerungen, Sitzungen, Fähigkeiten, Cron-Jobs und Zustandsdatenbank. Die CLI macht aus einem Profil auch einen eigenen Befehlsalias, sodass ein Profil namens coder zu coder chat, coder setup, coder gateway start und so weiter wird. In der Praxis macht das Profile zur eigentlichen Einheit der Produktionsverantwortung, nicht die einzelne Fähigkeit.

Das Produktions-Grundgerüst

Die Grundstruktur ist überraschend klar. Hermes speichert nicht-geheime Verhaltensweisen 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, 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 aufgeteilt werden sollten.

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

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

Dieses Muster entspricht der Dokumentation von Hermes-Profilen: Jedes Profil ist eine eigene isolierte Umgebung, und Profile können von einer Basis-Konfiguration geklont werden, wenn gemeinsame Standardwerte nützlich sind. Die Dokumentation weist auch darauf hin, dass Profile keine Speicher- oder Sitzungsdaten teilen und dass aktualisierte Fähigkeiten 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 Sicherheitsdokumente beschreiben ein Defense-in-Depth-Modell, das die Genehmigung gefährlicher Befehle, Container-Isolation, MCP-Zugangsfilterung, Kontextdatei-Scans, Cross-Session-Isolation und Eingangs-Sanitisierung umfasst. Mit anderen Worten: Die Entscheidung „Profil zuerst“ beantwortet, wer den Zustand besitzt, und die Backend-Entscheidung beantwortet, wo riskante Arbeiten erlaubt sind.

Automatisierung sitzt auf diesem Grundgerüst. Hermes-Cron-Jobs können null, eine oder mehrere Fähigkeiten anhängen und laufen in neuen Agentensitzungen, anstatt 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-Leitfaden fügt eine weitere Produktionsregel hinzu, die leicht übersehen wird: Das beste Muster ist nicht, alles zu verbinden, sondern die kleinste nützliche Oberfläche freizulegen. Für queue-basierte Multi-Agent-Ausführung auf selbst gehosteten Modellen nutzen Sie Kanban in Hermes Agent für selbst gehostete LLM-Workflows als begleitendes Handbuch. Wenn Ihr Produktionslayout Hermes auf einer headless Maschine platziert und Betreiber von Desktop-Clients aus verbinden, nutzen Sie Hermes Agent Headless Server und Remote Desktop Setup für die Netzwerk- und Diensttopologie.

Das Software-Engineering-Profil

Die offensichtlichste Hermes-Persona ist der Softwareentwickler, der möchte, dass der Agent sich weniger wie ein Chat-Fenster und mehr wie ein wiederholbarer Repo-Betreiber verhält. Dieses Profil kümmert sich normalerweise um Repository-Authentifizierung, Issue-Triage, PR-Erstellung, Code-Review, Debugging und planbasierte Ausführung. In den Hermes-Katalogen ist das Kernpaket der eingebauten Fähigkeiten 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 Delegierung wichtig ist, liefert Hermes auch eingebauten autonome Agenten-Fähigkeiten wie codex, claude-code, opencode und hermes-agent-spawning.

Was dieses Paket nützlich macht, ist nicht eine einzelne Fähigkeit. Es ist die Art und Weise, wie die Fähigkeiten Entwicklungsverfahren kodieren. github-pr-workflow deckt den gesamten PR-Lebenszyklus ab, github-issues formalisiert Issue-Operationen, github-code-review und code-review machen das Review zu einem eigenständigen Schritt statt eines nachträglichen Gedankens, und systematic-debugging verhindert, dass der Agent direkt zu vorzeitigen Lösungen springt. Das beantwortet auch die praktische Frage, welche KI-Assistenten-Fähigkeiten für Coding-Workflows am wichtigsten sind. Die wertvollsten Fähigkeiten sind normalerweise diejenigen, die Repo-Hygiene und Review-Disziplin festlegen, nicht diejenigen, die mehr reine Code-Generation versprechen.

Hermes-Delegierung stärkt dieses Profil weiter. Die Plattform kann isolierte Child-Agenten mit eigener Konversation, Terminal-Sitzung und Werkzeugset spawnen, und nur die finale Zusammenfassung wird an den Parent zurückgegeben. Für Codebases ist das eine sauberere Passform, als jeden Zwischendiff, Stack Trace und Review-Notiz in eine Konversation zu stopfen. In Produktionsbegriffen profitiert das Engineering-Profil von engen Fähigkeits-Sets, einem sandboxed Backend wie Docker oder SSH und dem großzügigen Einsatz von Delegierung, wenn Kontextrauschen zu dominieren beginnt.

Das Forschungs- und Wissensprofil

Das Forschungsprofil ist der Ort, an dem Hermes sich von gewöhnlichen Assistenten abhebt. 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 Forschungsschicht für spezialisierte Domänen hinzufügt. Dieser Stack deckt Papersuche, Quellenüberwachung, OCR, lokale Notensysteme, 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 Speicher versus Fähigkeiten zu beantworten. Die Hermes-Dokumentation definiert Speicher als Fakten über Benutzer, Projekte und Präferenzen, während Fähigkeiten Verfahren für das Wie der Dinge speichern. Forschungsarbeit benötigt beides. Speicher hält, was der Assistent bereits über die Domäne und die Präferenzen des Lesers gelernt hat; Fähigkeiten kodieren wiederholbare Verfahren wie „scan arXiv, fasse neue Papers zusammen und schreibe Notizen in Obsidian“. Diese Unterscheidung ist wichtig, weil Produktionsforschungssysteme scheitern, wenn alles als Speicher oder alles als Workflow behandelt wird. Hermes gibt diesen Belangen separate Häuser. Für das vollständige technische Bild, wie Speicher 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 von Cron. Hermes-Cron-Jobs können Fähigkeiten explizit vor der Ausführung laden, und die Automatisierungsleitfäden betonen, dass geplante Prompts vollständig in sich geschlossen sein müssen, da sie in neuen Sitzungen laufen. Eine wiederkehrende Pipeline, die blogwatcher, arxiv, obsidian oder llm-wiki kombiniert, ist daher zuverlässiger als ein vager Job „prüfen, was heute geändert wurde“. Mit anderen Worten: Forschungsprofile funktionieren am besten, wenn Entdeckung von Quellen, Notizschreiben und Langzeitspeicherung jeweils durch eine benannte Fähigkeit repräsentiert werden, anstatt in einem langen Natural-Language-Prompt versteckt zu sein.

Das Automatisierungs- und Operationsprofil

Das Ops-Profil ist weniger glamourös und oft wertvoller. Dies ist der Benutzer, der möchte, dass Hermes auf Ereignisse reagiert, Systeme inspiziert, skriptbasierte Checks ausführt, Ausgabe zu einem Kanal leitet und all das tut, ohne den Host zur Haftung zu machen. Hermes hat die richtigen Bausteine für diese Art von Arbeit: Eingebaute webhook-subscriptions für ereignisgesteuerte Aktivierung, eingebauten native-mcp und mcporter für MCP-basierte Werkzeuge und offizielle optionale Fähigkeiten wie docker-management, fastmcp, cli und 1password, wenn der Workflow in Container, benutzerdefinierte MCP-Server oder Geheimniseinsprinjektion expandiert.

Der Grund, warum dieses Paket funktioniert, ist, dass jede Fähigkeit eine Grenze besitzt. webhook-subscriptions behandelt den Ingress von externen Systemen. docker-management verwandelt Container-Chores in ein benanntes Verfahren statt eines freien Shell-Spiels. fastmcp ist nützlich, wenn Hermes zum Orchestrierer um neue MCP-Werkzeuge herum werden muss, und 1password hält die Geheimnisverwaltung explizit, anstatt sie in Shell-Historie oder Markdown-Dateien zu schmuggeln. Die offizielle MCP-Anleitung verstärkt dieselbe Produktionsintuition: Verbinde die richtige Sache mit der kleinsten nützlichen Oberfläche. Wenn dieses Ops-Profil über mobile Chat-Oberflächen konsumiert wird, sind die Implementierungsdetails in Hermes Voice Control von Ihrem Telefon behandelt.

Dieses Profil ist auch der klarste Ort, um zu beantworten, wie geplante KI-Workflows zuverlässig bleiben. Die Hermes-Cron-Dokumentation besagt, dass Jobs in neuen Sitzungen laufen, eine oder mehrere Fähigkeiten anhängen können und in sich geschlossene Prompts verwenden sollten. Die Cron-Fehlerbehebung fügt hinzu, dass das automatische 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 Fähigkeiten, explizites Lieferziel, in sich geschlossener Prompt, isoliertes Backend und ein Gateway, das tatsächlich läuft.

Das Executive-Operations-Profil

Es gibt eine leiserere, aber sehr reale Hermes-Persona, die wie ein Chief of Staff, Operations-Lead oder stark überlasteter Gründer aussieht. Die relevanten Fähigkeiten sind weniger auffällig und eher bürogeprägt: google-workspace, notion, linear, nano-pdf, powerpoint und die eingebauten himalaya E-Mail-Fähigkeit, plus offizielle optionale Fähigkeiten wie agentmail, telephony und one-three-one-rule. Diese Mischung gibt Hermes Zugang zu Posteingang, Kalender, Docs, Aufgaben, Decks, PDF-Bereinigung, 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 Aufgaben wird. one-three-one-rule ist überraschend nützlich, weil Entscheidungsunterstützung oft das Schwierigste ist zu standardisieren, und diese Fähigkeit gibt Hermes ein benanntes Verfahren 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 jeden Tag Decks und PDFs berührt.

Hermes-Messaging- und Sprachfunktionen 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 Sprachstack unterstützt Mikrofoneingabe, gesprochene Antworten im Messaging und Live-Discord-Sprachkonversationen. Die Dokumente weisen auch darauf hin, dass eine Hermes-Instanz mehrere Benutzer durch Allowlists und DM-Pairing bedienen kann, während Bot-Tokens exklusiv für ein einzelnes Profil bleiben. Deshalb profitiert eine kommunikationsintensive Bereitstellung normalerweise von mindestens einem dedizierten Profil, anstatt dieselbe Bot-Identität mit Engineering oder Ops zu teilen.

Das ML- und Data-Platform-Profil

Hermes wird von einem Forschungslabor gebaut, und diese Herkunft zeigt sich. Die Kataloge enthalten jupyter-live-kernel für zustandsbehaftete Notebook-ähnliche Arbeit, huggingface-hub für Modell- und Dataset-Operationen, evaluating-llms-harness und weights-and-biases für Evaluation und Experimentverfolgung, qdrant-vector-search für Produktions-RAG-Speicher und eine große eingebaute und optionale MLOps-Schicht mit Fähigkeiten 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 Fähigkeiten den gesamten Stack abdecken, von Notebook-Iteration über Datenkuratierung, Evaluation, 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 Verfahren ü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 Optimierungsfähigkeiten lassen Hermes kohärent über sowohl Experimentierung als auch Deployment sprechen.

Dies ist auch das Profil, in dem Zurückhaltung am wichtigsten ist. Weil der optionale MLOps-Katalog so groß ist, profitiert ein Produktions-Hermes-Setup für ML-Arbeit normalerweise davon, sich bezüglich des Umfangs zu äußern. Ein Platform-Engineering-Profil, das Evaluation und Deployment besitzt, benötigt nicht jeden installierten Trainingsframework. Ein Forschungsprofil, das Papers und Notensysteme besitzt, benötigt nicht jede Vektordatenbank-Fähigkeit. Hermes kann riesige Fähigkeitsinventare tragen, aber Produktionsnützlichkeit kommt immer noch vom Einschränken der aktiven Oberfläche.

Wo Fähigkeiten zu Haftungen werden

Der stärkste Teil des Hermes-Fähigkeitssystems ist auch der Ort, an dem Produktionssetups schiefgehen. Hermes kann Fähigkeiten aus seinem eingebauten Katalog, dem offiziellen optionalen Katalog, Vercels skills.sh, bekannten Skill-Endpunkten, 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 Fähigkeiten durch und erlaubt --force nur für nicht-gefährliche Policy-Blöcke. Ein gefährliches Scan-Urteil bleibt blockiert. Hermes zeigt auch Upstream-Metadaten wie Repository-URL, wöchentliche Installationen und Audit-Signale während der Inspektion an. Das ist ein solides Vertrauensmodell, aber es ist kein Ersatz für Geschmack.

Es gibt auch eine Grenze dafür, was von einer Fähigkeit verlangt werden sollte. Die Hermes-Dokumentation ist explizit, dass Fähigkeiten die bevorzugte Wahl sind, wenn die Aufgabe als Anweisungen plus Shell-Befehle plus bestehende Werkzeuge ausgedrückt werden kann, während Plugins die ehrlichere Abstraktion für benutzerdefinierte Werkzeuge, Hooks und Lifecycle-Verhalten sind. Der Plugin-Leitfaden zeigt sogar, wie ein Plugin seine eigene Fähigkeit bündeln kann. In der Produktion bedeutet das, dass Fähigkeiten am besten als wiederverwendbare Verfahren behandelt werden, nicht als erzwungener Ersatz für richtiges Werkzeug- oder Plugin-Design.

Community und Support sehen gesund aus, aber sie löschen die Änderungsvelocity nicht aus. Die Hermes-Dokumentation weist Benutzer auf Discord, GitHub Discussions, Issues und den Skills Hub hin, 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. Ein echtes Produktions-Setup geht davon aus, dass Profile, Fähigkeiten und Workflow-Annahmen sich entwickeln werden, und nutzt dann Isolation und enge Fähigkeits-Packs, damit Veränderung lokal bleibt, wenn sie unvermeidlich eintrifft.

Hermes funktioniert am besten, wenn Fähigkeiten als prozedurale Verträge um klar getrennte Profile behandelt werden. Der Moment, in dem ein Profil gleichzeitig der Engineering-Agent, der Forschungsassistent, der Ops-Arbeiter, der Inbox-Bot und die ML-Plattform ist, hört das System auf, zu komponieren, und beginnt, Verantwortlichkeiten zu lecken. Das saubere Produktionsmuster geht weniger darum, mehr Fähigkeiten 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 selbst gehostete Assistenten, Retrieval-Architektur, lokale LLM-Infrastruktur und Observability abdeckt.