Von OpenClaw zu Hermes

Nach einigen Monaten OpenClaw im Dauerbetrieb hat sich meine Umstellung auf Hermes Agent gelohnt. Während OpenClaw mit wachsendem Verlauf spürbar träger wurde und beim Ressourcenverbrauch aus dem Ruder lief, bringt Hermes Agent ein schlankeres Speichermodell und einen eingebauten Lernmechanismus mit. Im Folgenden zeige ich meine Installation in einem LXC-Container auf meinem Proxmox-Server auf und stelle die Nachteile von OpenClaw den Vorteilen von Hermes Agent gegenüber anhand eines realen Debugging-Falls.

Hermes Agent in einem LXC-Container auf Proxmox installieren

Für einen Agenten, der dauerhaft im Hintergrund läuft, eignet sich ein schlanker, unprivilegierter LXC-Container besser als eine vollwertige VM. Auf meinem Proxmox-Host habe ich daher ein aktuelles Debian-Template heruntergeladen und einen frischen Hermes-Host erstellt.

Nous Research liefert für die Einrichtung von Hermes ein einzeiliges Installationsskript, das sämtliche Abhängigkeiten inklusive einer eigenen Python-Umgebung mitbringt.

apt update && apt install -y curl sudo
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Wer bereits produktiv mit OpenClaw gearbeitet hat, muss die bisherige Konfiguration nicht von Hand nachbauen. Hermes Agent bringt einen eigenen Migrationsbefehl mit, der Einstellungen, Erinnerungen, Skills und API-Schlüssel aus einer bestehenden ~/.openclaw-Installation übernimmt, wie auf Github dokumentiert ist.

# Interaktive Migration aus einer bestehenden OpenClaw-Installation
hermes claw migrate --dry-run   # zeigt zunächst nur eine Vorschau
hermes claw migrate             # führt die eigentliche Migration durch

Danach folgt der Setup-Assistent, der ein Sprachmodell mit mindestens 64.000 Token Kontextfenster verlangt. Kleinere Modelle werden laut Dokumentation beim Start abgelehnt, da sie für mehrstufige Tool-Aufrufe schlicht nicht genug Arbeitsspeicher im Kontext bereitstellen. Ein Blick auf Ornith und mein Artikel über die Optimierung des Kontextfensters sei hiermit ebenfalls empfohlen.

hermes setup --portal

Wer ohnehin schon einen Ollama-Server im Homelab betreibt, kann Hermes Agent auch vollständig lokal betreiben, solange das gewählte Modell die 64K-Grenze erreicht.

Die Schattenseiten von OpenClaw im Dauerbetrieb

OpenClaw hat mit dem viralen Wachstum Anfang 2026 gezeigt, wie schnell ein Community-Projekt zur festen Größe im Homelab werden kann. Das Projekt ist ein selbst gehostetes Gateway, das Sprachmodelle mit über zwanzig Messaging-Kanälen verbindet und dabei standardmäßig mit vollem Zugriff auf den Host läuft, solange nur eine einzelne Person damit arbeitet.

Genau dieser Standard-Zugriff ist einer der Kritikpunkte. Mehrere Unternehmen, darunter Meta, haben OpenClaw laut einem Bericht von MindStudio mittlerweile auf Firmengeräten gesperrt, weil das Verhalten des Agenten als unvorhersehbar eingestuft wurde. Prompt Injection lässt sich auf Ebene des Sprachmodells grundsätzlich nicht vollständig verhindern, und OpenClaw begegnet diesem Problem zwar mit Freigabe-Workflows und Docker-Sandboxing für Nebensitzungen, kann das Grundrisiko aber nicht beseitigen.

Der zweite spürbare Nachteil betrifft die Performance im Alltag, die auch den Ausschlag für den Wechsel gegeben hat. OpenClaw liest laut demselben Bericht den bisherigen Gesprächsverlauf bei jeder Anfrage erneut ein, was mit wachsendem Verlauf zu spürbaren Verzögerungen und zu deutlich schwankenden Kosten führt. Wer ein Frontier-Modell als Orchestrator einsetzt, bewegt sich nach denselben Angaben je nach Nutzungsintensität zwischen wenigen Euro und mehreren hundert Euro pro Monat, in Einzelfällen sogar im vierstelligen Bereich.

Hinzu kommt die Reife des Skill-Ökosystems. Da praktisch jede Person eigene Skills zu ClawHub beitragen kann, warnt die freeCodeCamp-Anleitung ausdrücklich, jeden Community-Skill vor der Installation zu prüfen, statt ihm blind zu vertrauen. Ein früherer Artikel auf meinem Blog geht auf die grundlegende Architektur von OpenClaw bereits genauer ein.

Was Hermes Agent im Vergleich besser macht

Der auffälligste Unterschied liegt im Umgang mit erlerntem Wissen. Hermes Agent verfügt laut eigener Projektbeschreibung über einen eingebauten Lernkreislauf, der aus gelösten Aufgaben automatisch wiederverwendbare Skill-Dokumente erzeugt, statt bei jeder Anfrage bei null anzufangen. Diese Skills folgen dem offenen Standard von agentskills.io und lassen sich damit auch außerhalb von Hermes weiterverwenden.

Beim Kontextmanagement geht das Projekt einen bewusst strengeren Weg. Die Mindestanforderung von 64.000 Token zwingt dazu, ein Modell zu wählen, das tatsächlich genug Arbeitsspeicher für Systemprompt, aktive Skills, Erinnerungen und Gesprächsverlauf gleichzeitig bereithält, anstatt das Problem stillschweigend in Kauf zu nehmen.

Sicherheitsseitig punktet Hermes Agent zunächst durch seine schiere Genese, also es ist aktuell noch nicht Ziel derart vieler kursierender Community-Skills wie OpenClaw. Das Projekt ist wie OpenClaw quelloffen unter der MIT-Lizenz, verzichtet laut eigenen Angaben komplett auf Telemetrie und lässt sämtliche Daten auf dem eigenen Server verbleiben (mit Ausnahme der Recherchen im Internet).

Für Nutzer mit vorhandener OpenClaw-Installation ist zudem der bereits erwähnte Migrationspfad relevant. Statt bei null anzufangen, übernimmt der Assistent Erinnerungen, Skills und Zugangsdaten automatisch, was die Einstiegshürde für einen Wechsel deutlich senkt.

Praxisbeispiel: Aufbau eines Briefing-Agenten

Ein gutes Beispiel für den Arbeitsstil von Hermes Agent liefert der Aufbau eines automatisierten Morgen-Briefings, das täglich aktuelle Neuigkeiten aus Netzwerksicherheit, Datenschutz und Self-Hosting zusammenfasst.

Der Weg dorthin verlief iterativ. Aus einer groben ersten Themensammlung entstand über mehrere Gesprächsrunden hinweg eine präzise Suchlogik mit Versionsangaben wie CheckPoint R82, FortiOS 7.4 und dem aktuellen Release der OPNsense, ergänzt um eine Vorgabe, Herstellermeldungen weniger stark zu gewichten als Fundstellen aus der unabhängigen Sicherheitsforschung.

Jede Anpassung ließ sich vorab in einem sogenannten Dry Run überprüfen, bevor der eigentliche Cronjob eingerichtet wurde.

Besonders aufschlussreich war der Moment, in dem die deutsche Sprachausgabe des Briefings zunächst mit englischem Akzent klang. Anstatt nur eine Vermutung zu äußern, zeigte der Agent den exakt ausgeführten Tool-Aufruf und erklärte, dass sein text_to_speech-Werkzeug keinen Parameter für Sprache oder Stimme entgegennimmt. Anschließend recherchierte er selbstständig im Internet und stieß auf die zugrunde liegende Bibliothek edge-tts.

Dabei kam eine wichtige Einschränkung ans Licht, nämlich dass die Unterstützung für individuelles SSML seit Version 5.0.0 vollständig entfernt wurde, weil Microsoft nur noch SSML zulässt, das der Edge-Browser selbst erzeugen kann. Ein einzelnes <voice>-Tag mit <prosody> bleibt zwar erlaubt, komplexere Sprachumschaltungen per Markup funktionieren damit nicht mehr.

Da eine Anpassung des Tools selbst nicht möglich war, führte der Agent stattdessen strukturiert durch die Konfigurationsdatei des Systems. Über gezielte grep-Abfragen in den eigenen Logdateien und der config.yaml identifizierte er die fehlende tools.text_to_speech-Sektion und schlug die passende Ergänzung vor.

# Ergänzung in ~/.hermes/config.yaml
tools:
  text_to_speech:
    voice: "de-DE-KatjaNeural"

Nach einem Neustart des Dienstes klang die Sprachausgabe erwartungsgemäß auf Deutsch.

Dieses Beispiel zeigt gut, wie der Lernkreislauf von Hermes Agent in der Praxis funktioniert.

Ab jetzt bekomme ich morgen eine Text-Nachricht und eine Sprachnachricht, die mich informiert, welche Termine anstehen und was zu Themen bekannt wurde, die mich interessieren.

Weiteres Praxisbeispiel: Firewall zeigt keine Logs für eine Verbindung

In diesem konkreten Fall meldete ein Kunde ein Problem mit einer TCP-Verbindung von 192.168.78.31 auf Port 5008 eines internen Servers (172.17.31.12), obwohl dies in den Firewall-Logs nie zu sehen war. Der erste Schritt war eine Paketmitschnitt-Prüfung direkt auf der FortiGate fw-muc-rmm1, bei dem nur die SYN-Pakete zu sehen waren. Das ist seltsam, denn es dokumentiert, dass versucht wird, die Verbindung aufzubauen. Im Logfile muss eine Reaktion der Firewall zu finden sein: PASS oder DROP.

Die Pakete kommen also an der Firewall an - vom Ziel aber keine Antwort. Um herauszufinden, warum die FortiWifi 30D den Traffic verwirft, folgte eine Analyse der Flow-Daten. Diese sind meist sehr überwältigend, enthalten aber fast immer die richtigen Informationen. Oft fehlt mir die Lust, all diese Details durchzuschauen. Aber zum Test von Hermes gebe ich das mal ein:

2026-06-02 10:23:02 id=65308 trace_id=185 func=print_pkt_detail line=5811 msg="vd-root:0
    received a packet(proto=6, 192.168.78.31:42148->172.17.31.12:5008) tun_id=0.0.0.0 from portX1.992
    flag [S], seq 442514007, ack 0, win 64240"
2026-06-02 10:23:02 id=65308 trace_id=185 func=init_ip_session_common line=5995 msg="allocate a new session-c62d9830"
2026-06-02 10:23:02 id=65308 trace_id=185 func=iprope_dnat_check line=5276 msg="in-[portX1.992], out-[]"
2026-06-02 10:23:02 id=65308 trace_id=185 func=iprope_dnat_tree_check line=834 msg="len=0"
2026-06-02 10:23:02 id=65308 trace_id=185 func=iprope_dnat_check line=5288 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2026-06-02 10:23:02 id=65308 trace_id=185 func=vf_ip_route_input_common line=2611 msg="find a route: flag=00000000 gw-192.168.22.254 via port2.986"
2026-06-02 10:23:02 id=65308 trace_id=185 func=iprope_fwd_check line=766 msg="in-[portX1.992], out-[port2.986], skb_flags-02000000, vid-0, app_id: 0, url_cat_id: 0"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_tree_check line=539 msg="gnum-100004, use addr/intf hash, len=8"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-417, ret-no-match, act-accept"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-2, ret-no-match, act-accept"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-3, ret-no-match, act-accept"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-430, ret-no-match, act-accept"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-431, ret-no-match, act-accept"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-16, ret-no-match, act-accept"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-492, ret-matched, act-accept"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_user_identity_check line=1799 msg="ret-matched"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check line=2273 msg="gnum-4e20, check-ffffffffa002f230"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2025 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2025 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2025 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check line=2290 msg="gnum-4e20 check result: ret-no-match, act-accept, flag-00000000, flag2-00000000"
2026-06-02 10:23:02 id=65308 trace_id=185 func=__iprope_check_one_policy line=2243 msg="policy-492 is matched, act-drop"
2026-06-02 10:23:02 id=65308 trace_id=185 func=iprope_fwd_check line=803 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-492"
2026-06-02 10:23:02 id=65308 trace_id=185 func=iprope_fwd_auth_check line=822 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-492"
2026-06-02 10:23:02 id=65308 trace_id=185 func=fw_forward_handler line=827 msg="Denied by forward policy check (policy 492)"

Aus dem resultierenden Flow-Output hat Hermes die wichtigsten Informationen extrahiert und gab folgende Antwort:

diagnostic_workspace:

[Topologie & Rollen]:
- Client: 192.168.78.31 (Eingang: portX1.992)
- Ziel/Server: 172.17.31.12 (Ausgang: port2.986 via GW 192.168.22.254)
- Middlebox: fw-muc-rmm1 (FortiGate) fungiert als Layer 3 Router
  und Policy Enforcement Point.

[Δt & Temporaler Status]:
- Intervalle zwischen den Traces (185→186→188): ca. 1,0s bzw. 6,0s.
- Bestätigt exponentiellen Backoff durch ausbleibende ACKs = Blackhole
  durch die Firewall.

[L3/L4-Telemetrie]:
- Protokoll: TCP (proto=6), Flags: [S] (SYN)
- L3-Routing: Valider Routing-Entry gefunden (find a route via port2.986)
- L4: Sequenznummer 442514007, Window Size 64240. Keine TCP-Headeranomalien.

[Falsifikation]:
- KEIN Routing-Fehler: Trace beweist validen Routing-Entry.
- KEIN NAT-Problem: iprope_dnat_check zeigt ret-no-match.
- KEINE Upstream-Störung: Paket wird auf der FortiGate verarbeitet,
  Entscheidung erfolgt lokal durch die Policy-Engine.
- KEIN Interface-Down: Inbound auf portX1.992 ist aktiv.

Management-Zusammenfassung:
Die Verbindung wird durch Forward Policy 492 auf fw-muc-rmm1 blockiert.
Die Policy-Engine trifft die Entscheidung deterministisch auf Layer 4.

Root Cause:
Layer 4 Security Policy Violation - Policy 492 (act-drop).

Handlungsempfehlung:
1. Policy 492 reviewen: Prüfen ob die Regel ein zu breites Subnetz
   oder eine falsche Source-Group erfasst.
2. Allow-Rule mit niedrigerem Index als 492 erstellen.
3. Nach Änderung: erneuten debug flow trace zur Verifikation durchführen.

Die Analyse trifft den Kern: Im FortiOS-Trace sind die entscheidenden Zeilen eindeutig - Policy 492 wird zunächst mit ret-matched, act-accept gelistet, doch ein nachgelagerter Security-Profile-Check (gnum-4e20) schlägt fehl und überschreibt die Entscheidung auf act-drop. Der finale Eintrag bestätigt es:

func=fw_forward_handler line=827 msg="Denied by forward policy check (policy 492)"

Das Retransmission-Muster im Sniffer (SYN bei t=0s, t+1s, t+3s) entspricht exakt dem exponentiellen TCP-Backoff, den Hermes korrekt als Beweis für einen stillen Drop identifiziert.

Was mir an der Analyse besonders gut gefallen hat, ist das Anwenden eines Ausschlußverfahrens. Hermes hat klar benannt, was nicht Ursache des Problems ist. Das war bei wirklich großen Problemen eine entscheidende Eingrenzung der möglichen Probleme und hat die Analysezeit drastisch verkürzt. Das soll künftig als Basis für weitere Analysen dienen...

Und so findet sich eine weitere Fähigkeit in Hermes´ Liste der Skills:

Digitale Souveränität - mit einem blinden Fleck

Hier lohnt ein kurzer, aber wichtiger Einschub. Der beschriebene Aufbau - Hermes lokal, Modell lokal über Ollama, keine Cloud-API - klingt nach vollständiger digitaler Souveränität. Und für reine Textgenerierung stimmt das auch. Der blinde Fleck entsteht, sobald Hermes Research-Tools nutzt, also selbstständig im Web sucht, URLs abruft oder externe APIs anfragt.

In meinem Netzwerk-Forensik-Kontext bedeutet das: Werden interne IP-Adressen, Hostnamen oder Subnetz-Informationen als Teil einer Suchanfrage an Suchmaschinen oder externe Dienste weitergegeben, verlässt sensible Infrastrukturinformation das eigene Netz - unabhängig davon, wo das LLM läuft. Forschungsarbeiten zur Netzwerk-Metadaten-Analyse zeigen, dass Web-Research-Agenten durch ihre charakteristischen Suchmuster (Besuch von 70 bis 140 Domains mit erkennbaren Timing-Korrelationen) selbst dann über passive Netzwerk-Beobachtung analysierbar sind, wenn TLS-Verschlüsselung eingesetzt wird.

Für produktive Einsatzszenarien mit internen Netzwerkdaten empfehlen sich daher folgende Maßnahmen:

• Web-Search deaktivieren für Forensik-Sessions mit internen Daten (hermes model → Toolset einschränken oder Search-Skill deaktivieren).
• Kontext bereinigen: Interne IPs in Logs durch Platzhalter ersetzen, bevor Log-Daten in den Agent-Context eingehen.
• Offline-Modus erzwingen: Netzwerkzugriff des Hermes-Prozesses per Firewall-Regel auf localhost beschränken, wenn keine externe Recherche gewünscht ist.
• Skills prüfen: Hermes prüft bei der Skill-Installation über einen "Skills Guard" zwar auf verdächtige Environment-Zugriffe, MCP-Subprozesse erhalten nur eine gefilterte Umgebung ohne API-Keys - dennoch sollten extern bezogene Skills vor der Nutzung mit Produktionsdaten überprüft werden.

Das klingt natürlich nach einer extremen Einschränkung, doch eine klare Ansage, wie Hermes im Internet suchen darf (z.B. IP-Adressen durch Platzhalter ersetzen etc.) schien bis jetzt zu funktionieren.

Fazit

OpenClaw war zwar ein solider Einstieg in selbst gehostete KI-Agenten, zeigt im Dauerbetrieb aber deutliche Schwächen bei Performance, Kosten und dem standardmäßig vollen Systemzugriff. Hermes Agent begegnet diesen Punkten mit einem eingebauten Skill-Lernkreislauf, einer strengeren Kontext-Mindestanforderung und einem direkten Migrationspfad, der den Umstieg ohne Datenverlust ermöglicht. In einem schlanken LXC-Container auf Proxmox lässt sich der Wechsel mit wenigen Befehlen und ohne größeren Konfigurationsaufwand vollziehen.