Issue 13 27.09.2026 · Lesezeit 8 Min Open Source · self-hosted

Ein Agent, der immer läuft. Und die 3 Fallen, die keiner nennt.

Claude Code läuft nur, wenn du es startest. Der Open-Source Hermes Agent lebt 24/7 auf deinem Server, ist über 16+ Kanäle erreichbar und arbeitet proaktiv. Ich hab mir einen aufgesetzt — hier ist die ehrliche Bilanz.

Hermes-Kit

Install · Verbindungsmodell · Wächter-Skript

Die Installationswege, das Verbindungsmodell erklärt, ein fertiger Self-Restart-Wächter (systemd) zum Anpassen und ein Spickzettel der drei Stolperfallen.

Herunterladen

Quelle: github.com/NousResearch/hermes-agent · eigener Betrieb, Stand 09/2026

Was Hermes von Claude Code unterscheidet

Claude Code ist ein Werkzeug, das du aufmachst, wenn du es brauchst. Hermes ist die andere Kategorie: ein persistenter, selbstgehosteter Agent, der als Dauerprozess auf deinem eigenen Server läuft — und der dich erreicht, nicht umgekehrt. Er schickt dir morgens ein Briefing, erinnert an Fristen, beantwortet eine E-Mail (mit deiner Freigabe), alles ohne dass du ein Terminal öffnest.

In einem Satz: Claude Code ist on-demand. Hermes ist always-on. Beides gute Werkzeuge — für verschiedene Jobs.

Was er kann — kompakt

16+ Kanäle

Matrix, E-Mail, Telegram, Signal, WhatsApp, Slack, SMS … ein Agent, überall erreichbar.

Jedes LLM

OpenRouter (400+ Modelle mit Failover), Anthropic, OpenAI, Google, lokal — deine Wahl.

Proaktiv per Cron

Briefings, Fristen-Erinnerungen, Reports — er meldet sich von selbst.

MCP · Bot Mode · Computer-Use

Beliebige Tools über MCP, ein Roster benannter Bots, und er steuert notfalls den Rechner selbst.

Die ausführliche Übersicht (Fähigkeiten, Tech-Stack, Einrichtung) liegt als eigene Referenzseite in der Lounge. Hier geht es um den Teil, der dort bewusst kurz bleibt: die Praxis.

Falle 1: Er kann sich nicht selbst neu starten

Die teuerste Lektion zuerst. Hermes kann sich selbst umbauen — neue Bots, neues Image, neuer Container. Klingt praktisch, bis er es tut: Er stoppt seinen alten Container, um den neuen zu starten — und tötet damit genau den Prozess, der den neuen hochfahren müsste. Ergebnis: Der neue Container steht auf created, aber niemand startet ihn. Der Agent ist komplett weg — und kommt von allein nicht zurück.

Der Kern: Ein Container kann sich nicht von innen selbst starten. Wer einem Agenten erlaubt, sich selbst neu zu deployen, braucht eine Hand von außen, die den letzten Schritt macht.

Die Lösung ist ein winziger Wächter auf dem Host — außerhalb des Agenten —, der jede Minute genau eine Sache prüft:

status = docker inspect <container> -f '{{.State.Status}}'
wenn status == "created":
    docker compose up -d      # = die Hand von aussen
sonst:
    nichts tun

Er greift nur beim Zustand created — also genau diesem Fehlerbild. Absichtliche Stops und echte Abstürze lässt er in Ruhe (kein blindes Crash-Loop-Wiederbeleben). Das komplette Skript inkl. systemd-Timer liegt im Kit.

Falle 2: Keine offene Verbindung, sondern ein Account-Hub

Man erwartet, dass die Desktop-App den Agenten über eine offene Adresse erreicht — IP und Port. Falsch. Hermes veröffentlicht keinen Port; App und Server finden sich über einen Account-Hub (bei Hermes das „Portal", per Login).

Die Falle: Nach jedem Redeploy ist der Portal-Login weg — und die Desktop-App findet den Agenten nicht mehr, obwohl er läuft. Der Server ist gesund, die Verbindung nicht. Fix: nach dem Redeploy einmal hermes portal neu einloggen. Wer das nicht weiß, sucht den Fehler stundenlang am falschen Ende.

Falle 3: Die Bind-Mount-Falle

Du editierst die Persona-Datei, startest neu — und nichts ändert sich. Der Grund: Das echte Datenverzeichnis des Containers liegt nicht dort, wo es intuitiv steht. Man bearbeitet eine Datei auf dem Host, die so heißt wie die richtige, aber ein verwaister Alt-Ordner ist — nicht der Mount, den der Container tatsächlich liest.

Der Reflex, der es löst: Nie raten, welche Datei der Container liest — docker inspect fragen:

docker inspect <container> \
  -f '{{range .Mounts}}{{.Source}} -> {{.Destination}}
{{end}}'

Das zeigt schwarz auf weiß, welcher Host-Ordner im Container wo landet. Verifizieren, nicht vermuten — das gilt bei jedem Container.

Wann sich das Selbermachen lohnt — und wann nicht

Lohnt sich

  • Du willst einen persönlichen Always-on-Assistenten, ohne deine Daten einem SaaS zu geben
  • Du hast einen kleinen Server und keine Scheu vor Docker + Terminal
  • Dir sind Datenhoheit und EU-Hosting wichtiger als Ein-Klick-Komfort

Lohnt sich nicht

  • Du willst nur nutzen, nicht betreiben — Wartung, Updates, Fallen inklusive
  • Du arbeitest in einer §203-Branche und brauchst dokumentierte Compliance statt Bastellösung

Mein Fazit

Ein eigener, always-on KI-Agent ist kein Zukunftsversprechen mehr — er ist ein Nachmittag Setup. Aber es ist ein Betrieb, kein Produkt: Es gibt Fallen, und die drei oben sind die, an denen ich hängengeblieben bin. Mit dem Wächter und den zwei Reflexen (hermes portal nach Redeploy, docker inspect statt raten) läuft es dann erstaunlich stabil.

Kleine Offenlegung: Genau diese Technik betreiben wir auch gemanagt — als Felix / VeloAssist, §203-konform, für Kanzleien und Praxen, die nicht selbst schrauben wollen. Details auf der Referenzseite. Dieser Issue ist aber fürs Selbermachen — und dafür braucht es keinen Anbieter, nur einen Server und das Kit unten.

Zum Selbermachen

Hermes-Kit

Installationswege, das Verbindungsmodell erklärt, der fertige Self-Restart-Wächter (systemd) zum Anpassen und der Spickzettel der drei Stolperfallen.

Herunterladen

Quelle: github.com/NousResearch/hermes-agent


Das war Issue 13 der Velo-Wissen-Reihe. Jeden Sonntag um 15 Uhr eine Empfehlung — ein Tool, eine Bibliothek, ein Workflow oder ein Skill, das ich selbst getestet habe und für nützlich halte.