Hermes Agent selbst hosten: Einrichtung, Automationen und der Betrieb dahinter
Hermes Agent auf eigener Hardware betreiben: Installation, Messaging-Gateway, Cron-Automationen und die drei Betriebsfallen, die mich echte Zeit gekostet haben.
import BlogFAQ from '../../src/components/BlogFAQ'; import KeyTakeaways from '../../src/components/KeyTakeaways';
<KeyTakeaways items= /
<p data speakable Hermes Agent ist ein selbst gehosteter KI Agent von Nous Research, quelloffen unter MIT Lizenz und nicht an einen Modellanbieter gebunden. Er läuft dauerhaft auf eigener Hardware, ist über Telegram, Discord, Slack oder Signal erreichbar und bringt einen eigenen Cron Scheduler mit, der Aufgaben unbeaufsichtigt ausführt. Der Nutzen entsteht dabei nicht im Chat, sondern in den wiederkehrenden Auswertungen, die niemand mehr anstoßen muss. Dieser Artikel zeigt die Einrichtung, die Automationen, die sich in meinem eigenen Betrieb bewährt haben, und die drei Fallen, die mich dabei echte Zeit gekostet haben. </p
Was Hermes Agent ist — und was er nicht ist
Hermes Agent kommt von Nous Research und steht unter MIT Lizenz auf GitHub. Er ist kein Coding Assistent im Sinne von Claude Code oder Codex, auch wenn sich die Werkzeugkästen überschneiden. Der Unterschied liegt im Betriebsmodell: Eine Coding CLI startet man, arbeitet damit und beendet sie. Hermes läuft durch.
Daraus folgt fast alles andere. Ein Prozess, der durchläuft, kann auf Nachrichten reagieren, ohne dass ein Terminal offen ist. Er kann geplante Aufgaben ausführen. Er kann sich zwischen zwei Sitzungen an etwas erinnern. Und er kann — das ist die unangenehme Kehrseite — auch dann etwas tun, wenn gerade niemand hinschaut.
Modellseitig legt Hermes nichts fest. Nous Portal, OpenRouter, OpenAI kompatible Endpunkte oder ein eigener Inferenz Server sind gleichwertige Optionen, der Wechsel läuft über hermes model. Wer die Grundsatzfrage zwischen eigenem Betrieb und Managed Service noch nicht entschieden hat, findet die ehrliche Rechnung dazu in meinem Vergleich KI lokal hosten oder als Managed Service beziehen.
Einrichtung
Die Installation ist ein Einzeiler:
Danach führen vier Befehle zu einem arbeitsfähigen Zustand:
hermes setup fragt alles ab, was für den ersten Lauf nötig ist. Wer die Sammlung einzelner API Schlüssel für Modell, Websuche, Bildgenerierung und Sprachausgabe vermeiden will, kann mit hermes setup portal stattdessen Nous Portal anbinden; die eigenen Schlüssel bleiben pro Werkzeug weiter möglich.
Kommen Sie von OpenClaw? Dann ist der Weg kürzer, als er aussieht. Der Setup Assistent erkennt eine vorhandene /.openclaw Installation und bietet die Übernahme von sich aus an. Nachträglich geht das auch:
Übernommen werden Persona Datei, Memories, selbst erstellte Skills, die Freigabe Muster für Befehle, Messaging Einstellungen und ausgewählte API Schlüssel. Wer sein OpenClaw Setup nach meiner Proxmox Anleitung abgesichert hat, behält die dortigen Grundsätze bei: Isolation, Firewall, kein offener Port ins Internet, Freigaben nur für explizit erlaubte Befehle. Die Härtung gilt für Hermes unverändert — der Agent hat dieselbe Klasse von Zugriff.
Der Gateway ist der eigentliche Unterschied
hermes gateway startet einen Prozess, der den Agenten an Messaging Plattformen hängt: Telegram, Discord, Slack, WhatsApp, Signal. Ab da ist der Agent kein Terminalprogramm mehr, sondern ein Kontakt.
Das klingt nach Bequemlichkeit und ist in Wahrheit der Punkt, an dem die Nutzung kippt. Ein Werkzeug, für das ich ein Terminal öffnen, in ein Verzeichnis wechseln und einen Befehl tippen muss, benutze ich, wenn ich ohnehin am Rechner arbeite. Ein Werkzeug, das in derselben App liegt, in der ich ohnehin lese, benutze ich unterwegs, abends und zwischendurch. Die Zahl der tatsächlichen Anfragen unterscheidet sich in meinem Betrieb deutlich zwischen beiden Zuständen.
Für den Dauerbetrieb gehört der Gateway hinter einen Dienst Manager, nicht in eine Terminal Sitzung. Unter Linux heißt das eine systemd Unit mit Restart=always. Genau daran hängt später Falle Nummer zwei.
Die Automationen, die sich wirklich lohnen
Der Cron Scheduler ist der Teil, der aus einem Chat Werkzeug ein Arbeitsmittel macht. Jobs werden in natürlicher Sprache beschrieben, laufen unbeaufsichtigt und liefern ihr Ergebnis an eine gewählte Plattform.
Vier Muster haben sich in meinem eigenen Betrieb gehalten:
Das tägliche Briefing. Ein Job liest abends Feeds und Nachrichtenquellen, gleicht sie gegen den aktuellen Stand meiner Projekte ab und liefert eine sortierte Einordnung: was heute zählt, was auf dem Radar bleibt, was Rauschen ist. Der Wert liegt im dritten Teil. Eine Zusammenfassung von zwanzig Meldungen kann jeder Feed Reader; die Entscheidung, dass achtzehn davon für meinen Stack irrelevant sind, braucht Kontext über meinen Stack.
Die Link Pipeline. Alle zwei Stunden werden gesammelte Links abgearbeitet — Videos transkribiert, Artikel eingeordnet, alles gegen eine Qualitätsprüfung geschickt und abgelegt. Das ersetzt den Stapel offener Tabs, den man sonst am Wochenende durchgeht und meistens eben nicht durchgeht.
Der Fristwächter. Ein Job pro Monat, der eine wiederkehrende Compliance Frist prüft und eine Nachricht schickt. Technisch trivial, wirtschaftlich einer der wertvollsten Jobs überhaupt, weil vergessene Fristen teuer sind und Kalendererinnerungen abstumpfen.
Der wöchentliche Rückblick. Ein Job, der die Arbeitsprotokolle der Woche liest und daraus einen Bericht erzeugt: was ist entschieden worden, was liegt fest, was ist offen geblieben. Das ist die Aufgabe, die man sich vornimmt und nie macht.
Das Muster hinter allen vieren ist dasselbe: wiederkehrend, klar abgegrenzt, mit einem Ergebnis, das dort landet, wo ohnehin gelesen wird. Aufgaben ohne diese drei Eigenschaften taugen nicht als Automation — sie werden zu Benachrichtigungen, die man wegwischt. Verwandte Überlegungen dazu stehen in meinen Agent Workflow Patterns für Engineering Teams.
Ohne Kontext bleibt es ein besserer Chatbot
Der Punkt, an dem die meisten Setups stehen bleiben: Der Agent kennt das eigene Umfeld nicht. Er weiß nicht, woran gearbeitet wird, was letzten Monat entschieden wurde und welche Systeme im Einsatz sind. Damit kann er allgemein antworten und sonst wenig.
In meinem Setup spiegelt ein Sync Skript die Wissensverzeichnisse aller Projekte auf die Maschine, auf der der Agent läuft, zusammen mit einem Volltextindex. Der Agent sucht damit in derselben Datenbank wie ich. Der Rückweg ist getrennt: Was der Agent erzeugt, landet in einem eigenen Export Verzeichnis und wird von dort abgeholt — er schreibt nicht in meine Quellen.
Diese Trennung ist keine Förmlichkeit. Ein Sync mit delete in die falsche Richtung löscht in Sekunden, was der Agent nie hätte anfassen dürfen. Wer Kontext bereitstellt, sollte vorher festlegen, welche Richtung schreiben darf und welche nur liest.
Drei Fallen, die mich Zeit gekostet haben
Erstens: der unbeaufsichtigte Schlüssel. Ein Sync Job braucht einen SSH Schlüssel ohne Passphrase. Genau dieser Schlüssel ist dann der schwächste Punkt im Setup, wenn er auf ein Root Login zeigt. Die Lösung ist ein Forced Command im authorized keys Eintrag, der den Schlüssel auf genau eine Operation in genau einem Verzeichnis festnagelt. Danach ist die Gegenprobe Pflicht: Jeder andere Befehl über diesen Schlüssel muss abgewiesen werden, und man muss das einmal wirklich ausprobiert haben.
Zweitens: die Systemd Unit ohne Laufzeitumgebung. Der Gateway lief bei mir als System Unit und startete Kindprozesse über einen systemd Scope. Nach einem Update begann jeder agent gestützte Cron Job zu scheitern, mit einer Meldung über einen nicht verfügbaren User Scope. Ursache war eine einzige fehlende Umgebungsvariable: Eine System Unit erbt kein XDG RUNTIME DIR, und ohne die findet der Aufruf den User Manager nicht. Interaktiv über SSH funktionierte derselbe Befehl einwandfrei — deshalb dauerte die Diagnose. Der Test, der es entschieden hat, war die Gegenprobe mit einer bewusst leergeräumten Umgebung:
```bash env i HOME=/root USER=root PATH=/usr/bin:/bin systemd run user scope true scheitert – wie im Dienst
env i HOME=/root USER=root PATH=/usr/bin:/bin \ XDG RUNTIME DIR=/run/user/0 systemd run user scope true läuft ```
Merksatz: Wenn etwas in der Shell geht und im Dienst nicht, ist es fast immer die Umgebung — und die vergleicht man am schnellsten, indem man sie absichtlich zerstört.
Drittens, und das ist die teuerste: der stille Ausfall. Derselbe Defekt hat einen Job 24 Mal hintereinander scheitern lassen, ohne dass irgendwo eine Warnung entstanden wäre. Der Job schrieb in ein Log, das niemand liest. Ein geplanter Job, der scheitert und schweigt, ist schlechter als gar kein Job: Man verlässt sich auf ein Ergebnis, das nicht mehr kommt.
Die Gegenmaßnahme, die bei mir funktioniert, ist unspektakulär: Die Warnung wird in die Datei geschrieben, die ohnehin gelesen wird — oben, vor den Inhalt. Wenn das Briefing älter als die erlaubte Frist ist, steht der Hinweis darauf im Briefing selbst. Ein Log, das man aktiv aufrufen muss, erreicht niemanden. Wer Automationen betreibt, braucht für jeden Job die Antwort auf eine Frage: Woran merke ich, dass dieser Job seit einer Woche nicht mehr läuft? Fällt die Antwort nicht in einem Satz, fehlt die Überwachung.
Wann sich das lohnt — und wann nicht
Es lohnt sich, wenn es wiederkehrende Auswertungen gibt, die heute niemand macht, weil sie zu klein für einen Termin und zu lästig für den Feierabend sind. Es lohnt sich, wenn der Kontext im Haus liegt und nicht in ein öffentliches Werkzeug soll. Und es lohnt sich, wenn jemand da ist, der den Betrieb übernimmt — ein Agent ist ein laufender Dienst mit allem, was dazugehört.
Es lohnt sich nicht als Selbstzweck. Ein selbst gehosteter Agent, der einmal die Woche eine Frage beantwortet, ist ein teurer Chatbot. Und es lohnt sich nicht ohne geklärten Datenweg: Welche Daten der Agent sieht, wohin sie zur Inferenz gehen und wer im Fehlerfall verantwortet, gehört vor die Installation, nicht danach. Einen Einstieg dazu gibt mein Leitfaden zu DSGVO konformer KI.
Wie ich dabei unterstütze
Ich betreibe dieses Setup selbst, im Alltag, mit allem was daran kaputtgeht. Das ist der Grund, warum ich es anbiete — und auch der Grund, warum ich ehrlich sagen kann, wo der Aufwand liegt.
Es gibt zwei sinnvolle Einstiege:
Sie haben eine konkrete Automation im Kopf. Ein wiederkehrender Prozess, der heute manuell läuft, oder ein bestimmter Ablauf, den ein Agent übernehmen soll. Dann sind Umfang und Weg meist schon klar genug, um direkt zu bauen: Einrichtung, Anbindung an Ihre Systeme, der Job selbst, die Überwachung dazu und eine dokumentierte Übergabe.
Sie haben eine Idee, aber keinen belastbaren Umfang. Das ist der häufigere Fall und der Grund, warum es die Produkt Discovery gibt: ein Festpreis, an dessen Ende ein Scope Dokument steht — Ziel, Nutzer, benötigte Daten und Integrationen, technische Richtung, Risiken und ein belastbares Folgeangebot. Bei Bedarf mit einem begrenzten Proof of Concept, der die zentrale Annahme prüft, statt sie zu behaupten. Die Discovery Gebühr wird auf ein anschließendes Projekt vollständig angerechnet.
Was danach kommt, ist die eigentliche KI Produktentwicklung — in abgegrenzten, einzeln beschriebenen Abschnitten bis zu Livegang und Übergabe. Wenn Sie danach Weiterentwicklung oder Betriebsunterstützung brauchen, ist das ein separater Auftrag und keine automatische Bindung.
Kostenloses Erstgespräch buchen
Weiterlesen
OpenClaw auf Proxmox sicher selbst hosten — Isolation, Firewall und Prompt Injection Schutz für Agenten mit Shell Zugriff KI lokal hosten oder AWS Bedrock — wann sich eigener Betrieb rechnet und wann nicht Agent Workflows im Engineering Team — sieben Patterns, die reproduzierbar funktionieren MCP Server entwickeln: Leitfaden — eigene Werkzeuge an einen Agenten anbinden
<BlogFAQ items= /