OpenClaw & Hermes Agent: Das Zwei-Agenten-System, das ich täglich einsetze

OpenClaw & Hermes Agent: Das Zwei-Agenten-System, das ich täglich einsetze

Meine OpenClaw-Instanz stürzte um 23:43 Uhr an einem Mittwoch ab. Kein sanfter Fehler — ein harter Absturz, nachdem ein Update eine fehlerhafte API-Schlüssel-Konfiguration eingespielt hatte, die stillschweigend jede aktive Sitzung ungültig machte. Ich hatte gerade eine Content-Pipeline laufen, die mitten in der Ausführung war. Drei Artikel in der Warteschlange, Recherche bereits gezogen, Gliederungen entworfen. Alles eingefroren in einem toten Prozess.

Vor sechs Monaten hätte mich dieser Absturz einen ganzen Vormittag zur Wiederherstellung gekostet. Sitzungen neu verbinden, Kontext erneut einspeisen, die Pipeline komplett von vorne starten. Ich habe diesen Tanz oft genug gemacht, um genau zu wissen, wie sich diese Frustration anfühlt — die Sorte, bei der man nicht auf das Tool wütend ist, sondern auf sich selbst, weil man einem Single Point of Failure vertraut hat.

Doch diesmal lief es anders. Innerhalb von vier Sekunden nach dem Ausfall von OpenClaw erkannte mein Hermes-Agent den Fehler. Er prüfte die Fehlerprotokolle, identifizierte die fehlerhafte API-Schlüssel-Konfiguration, patchte die Konfigurationsdatei und startete den OpenClaw-Prozess neu. Als ich nach dem Telegram-Benachrichtigungston auf mein Handy schaute, lief die Pipeline bereits wieder. Gesamtausfallzeit: elf Sekunden.

Dieser Moment — zuzusehen, wie ein KI-Agent einen anderen KI-Agenten diagnostiziert und repariert, während ich nichts tun musste — hat meine Sicht auf den Aufbau von KI-Workflows grundlegend verändert. Nicht, weil die Technologie neu war, sondern weil ich sie endlich richtig eingerichtet hatte. Zwei Agenten, komplementäre Stärken, die als Einheit arbeiten statt isoliert.

Dieses System werde ich für dich aufschlüsseln. Nicht die Theorie von Multi-Agenten-Workflows — die tatsächliche Implementierung, die ich jeden Tag nutze, einschließlich der vier spezifischen Workflow-Muster, die OpenClaw und Hermes zusammen deutlich leistungsfähiger machen als jeden für sich allein.

Doch zuerst musst du verstehen, warum genau diese beiden Tools — und warum die Kombination wichtiger ist als die individuellen Fähigkeiten jedes einzelnen Tools.

Warum Zwei Agenten Besser Sind als Einer — Und Warum Genau Diese Zwei

Ich habe bereits mit Multi-Agenten-Setups experimentiert. Vor einigen Monaten schrieb ich über OpenClaws Multi-Agenten-Team-Konfiguration, und das Fazit aus dieser Erfahrung war eindeutig: Mehrere Instanzen desselben Agenten zu betreiben, erzeugt einen Koordinationsaufwand, der die Produktivitätsgewinne oft wieder zunichtemacht. Vier OpenClaw-Agenten, die unterschiedliche Aufgaben übernehmen, teilen sich dennoch dieselben Fehlerquellen, dieselben Update-Zyklen und dieselben Modellabhängigkeiten.

Das Zusammenspiel von OpenClaw und Hermes funktioniert, weil diese beiden Tools auf grundlegend unterschiedlichen Designprinzipien basieren – und sich diese Unterschiede in der Praxis als komplementär erweisen, nicht nur in der Architektur.

OpenClaw ist ein Gateway-First-Tool. Es legt einen Agenten um eine Messaging-Infrastruktur. Ob Slack, Telegram, Discord, SMS – OpenClaw ist flexibel. Es übernimmt die Orchestrierung über mehrere Kanäle, Terminplanung, Skill-Bibliotheken (über 44.000 Skills, Stand April 2026) und das Management persistenter Sitzungen. Wenn ich einen Agenten brauche, der komplexe Aufgaben plant, plattformübergreifend koordiniert und langlaufende Sessions verwaltet, greife ich zu OpenClaw. Es ist der Projektmanager meines KI-Stacks.

Hermes ist ein Agent-First-Tool. Entwickelt von Nous Research und veröffentlicht im Februar 2026, legt es ein Gateway um einen lernenden Agenten. Der zentrale Unterschied ist das, was Hermes als seinen Lern-Loop bezeichnet: ausführen, evaluieren, extrahieren, verfeinern, abrufen. Jede Aufgabe, die Hermes erledigt, wird anhand des eigenen Outputs bewertet, nützliche Muster werden als wiederverwendbare Skills extrahiert, und diese Skills werden durch wiederholte Nutzung weiter verbessert. Der Agent wird buchstäblich mit jeder Ausführung besser.

Diese Unterscheidung – Gateway-First versus Agent-First – schafft eine natürliche Arbeitsteilung. OpenClaw glänzt bei der hochrangigen Orchestrierung: Es entscheidet, was wann und in welcher Reihenfolge passieren muss. Hermes überzeugt bei der Ausführung: Es erledigt die eigentliche Aufgabe schnell, kostengünstig und mit stetig steigender Qualität.

Auch die Kosten spielen eine erhebliche Rolle. OpenClaw läuft am besten auf leistungsfähigen Modellen. Für meine Hauptinstanz setze ich Opus 4.6 ein, da die Planungs- und Review-Aufgaben starke Reasoning-Fähigkeiten erfordern. Das ist teuer – die Token-Kosten bei Opus summieren sich schnell, wenn man persistente Sessions betreibt. Hermes hingegen läuft problemlos auf leichteren Modellen. Für die meisten Aufgaben nutze ich das $20-ChatGPT-Abo, und für einige Batch-Prozesse setze ich GLM-5 ein, das nur einen Bruchteil der Opus-Kosten verursacht.

Das Ergebnis: Ich erhalte Opus-Niveau bei Planung und Qualitätskontrolle für die Aufgaben, die es benötigen, und eine budgetfreundliche Ausführung für alles andere. Meine gesamten KI-Ausgaben sind nach dem Wechsel vom reinen OpenClaw-Setup auf das kombinierte System um etwa 40 % gesunken – während mein tatsächlicher Durchsatz gestiegen ist.

Das ist die Theorie. Wie das in der Praxis aussieht, zeige ich am Workflow, der mir den Mittwochabend gerettet hat.

Workflow 1: Das Backup-System, das meine Ausfallzeiten eliminiert hat

OpenClaw wird häufig aktualisiert. Schmerzhaft häufig. Das Entwicklungsteam liefert Verbesserungen in einem Tempo, das bewundernswert wäre, wenn nicht jedes Update eine nicht unerhebliche Wahrscheinlichkeit hätte, etwas zu zerstören. Allein im Februar 2026 erreichte das Repository 100.000 GitHub-Sterne – zum Teil, weil das Tool wirklich leistungsstark ist. Aber der Update-Zyklus bedeutet, dass „wirklich leistungsstark“ mit „bricht gelegentlich zu ungünstigen Zeitpunkten“ einhergeht.

Vor der Hermes-Kopplung bedeutete ein OpenClaw-Absturz manuelle Wiederherstellung. Per SSH auf den Mac Mini einloggen, die Logs lesen, das Problem identifizieren, den Fix anwenden, den Prozess neu starten. Im besten Fall: fünfzehn Minuten. Im schlimmsten Fall: eine Stunde Debugging wegen eines obskuren Konfigurationskonflikts, der durch das letzte Update eingeführt wurde.

Der Backup-Workflow ist in seiner Einfachheit elegant. Hermes führt alle dreißig Sekunden einen schlanken Health-Check gegen den OpenClaw-Prozess durch. Kein schwergewichtiger API-Call – nur ein Prozess-Status-Ping, der fast nichts an Tokens kostet. Schlägt der Ping dreimal hintereinander fehl (um Fehlalarme durch kurze Aussetzer zu vermeiden), eskaliert Hermes zu einer Diagnosesequenz:

1. Lese die Fehlerprotokolle der letzten OpenClaw-Sitzung
2. Klassifiziere den Fehlertyp – handelt es sich um ein Konfigurationsproblem, einen Fehler beim Modell-Provider, eine Speicherbeschädigung oder etwas anderes?
3. Wende den passenden Fix an aus seiner stetig wachsenden Bibliothek von Reparaturmustern
4. Starte OpenClaw neu und prüfe, ob der Prozess gesund ist
5. Sende mir eine Benachrichtigung via Telegram mit einer Zusammenfassung des Vorfalls und der durchgeführten Reparatur

Die Fix-Bibliothek ist der Bereich, in dem sich Hermes’ Lernschleife besonders auszahlt. Als Hermes zum ersten Mal nach einem OpenClaw-Update auf einen API-Key-Fehler stieß, dauerte Diagnose und Reparatur etwa vierzig Sekunden. Beim dritten Mal – weil Hermes das Muster extrahiert und verfeinert hatte – waren es elf Sekunden. Diese Zahl verbessert sich weiter, je mehr Hermes neue Fehlertypen erkennt und katalogisiert.

Das funktioniert übrigens in beide Richtungen. OpenClaw überwacht die Gesundheit von Hermes nach demselben Prinzip. Wenn Hermes abstürzt (selten, aber es kommt vor), übernimmt OpenClaw die Wiederherstellung. Das System hat keinen Single Point of Failure – genau die Eigenschaft, die man sich von jeder produktionsreifen Infrastruktur wünscht.

Hier ist das Setup, das ich für den Health-Check auf der Hermes-Seite verwendet habe. Die Konfiguration liegt im Task-Scheduler von Hermes:

name: openclaw_health_monitor
schedule: "*/30 * * * * *"  # alle 30 Sekunden
model: chatgpt  # leichtgewichtiges Modell für Kosteneffizienz
task: |
  Prüfe, ob der OpenClaw-Prozess läuft und reagiert.
  Falls bei 3+ aufeinanderfolgenden Checks keine Reaktion:
  1. Lese /var/log/openclaw/latest.log
  2. Identifiziere die Ursache
  3. Wende Fix aus der repair-patterns-Bibliothek an
  4. Starte den openclaw-Dienst neu
  5. Benachrichtige via Telegram: Zusammenfassung von Fehler + angewendetem Fix
retry_on_failure: true
max_retries: 3

Profi-Tipp: Setze das Health-Check-Intervall nicht unter 30 Sekunden. Ich habe anfangs 10-Sekunden-Intervalle ausprobiert und die Token-Kosten waren spürbar – nicht katastrophal, aber unnötig. Dreißig Sekunden bieten eine schnelle Erkennung, ohne das Budget für redundante Pings zu verbrennen.

Allein der Backup-Workflow rechtfertigte das Hermes-Setup. Aber der nächste Workflow – der, den ich für die eigentliche Projektarbeit nutze – ist der Punkt, an dem die Produktivitätssteigerung wirklich spürbar wird.

Workflow 2: Das Supervisor-Builder-Muster, das meine Arbeitsweise revolutioniert hat

Dies ist der Workflow, den ich am häufigsten verwende – und der die beeindruckendsten Ergebnisse liefert. Das Konzept stammt aus klassischen Software-Teams: Eine Person plant und prüft, eine andere baut.

In diesem Muster übernimmt OpenClaw die Rolle des Supervisors. Es nimmt ein übergeordnetes Ziel – „Erstelle ein Next.js-Dashboard für das Scanner-Monitoring-System“ – und zerlegt es in einen detaillierten Implementierungsplan. Komponentenarchitektur, Dateistruktur, Datenfluss, API-Endpunkte, spezifische Bibliotheken und Versionen. OpenClaw auf Opus 4.6 ist für diese Art von Architekturüberlegungen hervorragend geeignet. Es berücksichtigt Edge Cases, antizipiert Integrationsprobleme und erstellt Pläne, die tatsächlich produktionsreif sind.

Anschließend erhält Hermes den Plan und setzt ihn um.

Die Übergabe erfolgt über ein gemeinsames Arbeitsverzeichnis – dazu mehr in Workflow 4. OpenClaw schreibt den Plan als strukturiertes Markdown-Dokument. Hermes übernimmt, analysiert die Anforderungen und beginnt mit der Ausführung. Da Hermes auf einem leichteren Modell läuft, kostet die Ausführung nur einen Bruchteil dessen, was es kosten würde, wenn OpenClaw selbst bauen würde.

Doch hier liegt der entscheidende Punkt, den viele übersehen: Nachdem Hermes den Build abgeschlossen hat, prüft OpenClaw das Ergebnis. Es gleicht den Code mit dem ursprünglichen Plan ab, identifiziert Lücken, schlägt Verbesserungen vor und genehmigt entweder das Ergebnis oder sendet gezielte Überarbeitungsanfragen an Hermes zurück.

Dieser Review-Schritt ist essenziell. Ohne ihn vertraut man auf das Ergebnis eines leichteren Modells – ohne Qualitätskontrolle. Mit ihm erhält man die Kosteneffizienz eines günstigen Ausführungsmodells kombiniert mit der Qualitätssicherung eines Premium-Review-Modells. Die Ergebnisqualität ist durchweg höher als bei jedem Agenten allein.

Ein echtes Beispiel von letzter Woche: Ich brauchte ein Dashboard zur Überwachung eines Scanner-Fuhrparks – Statusanzeigen für jeden Scanner, Fehlerprotokolle, Uptime-Metriken und ein einfaches Alarmsystem. Hier die Kurzfassung des Ablaufs:

OpenClaws Plan (in ca. 90 Sekunden auf Opus 4.6 generiert):

• Next.js-15-App mit App Router
• Vier Hauptkomponenten: ScannerGrid, StatusCard, ErrorLog, AlertPanel
• Serverseitiges Daten-Fetching mit 30-Sekunden-Revalidierung
• Tailwind CSS mit dunklem Theme passend zu meinem bestehenden Designsystem
• WebSocket-Verbindung für Echtzeit-Statusupdates der Scanner
• Konkrete Dateistruktur, Komponenten-Props und Datenschemata

Hermes’ Build (in ca. sechs Minuten auf ChatGPT abgeschlossen):

• Alle vier Komponenten gebaut und funktionsfähig
• Layout und Routing konfiguriert
• API-Routen für Scanner-Daten implementiert
• Grundlegendes Styling angewendet

OpenClaws Review (ca. 45 Sekunden):

• Fehlende Error Boundary um die WebSocket-Verbindung erkannt
• Vorschlag, eine Reconnect-Strategie mit exponentiellem Backoff zu ergänzen
• Angemerkt, dass die StatusCard-Komponente den „Scanner offline seit 24+ Stunden“-Zustand nicht behandelt
• Gesamte Architektur und Komponentenstruktur genehmigt

Hermes’ Überarbeitung (ca. zwei Minuten):

• Alle drei Korrekturen umgesetzt
• Reconnect-Logik ergänzt
• Extended-Offline-State behandelt

Gesamtdauer vom Ziel bis zum funktionierenden Dashboard: etwa zehn Minuten. Gesamtkosten: ca. $0,85 an API-Tokens. Hätte ich OpenClaw alles machen lassen – Planung, Bau und Review auf Opus 4.6 – hätte die gleiche Arbeit etwa $3,40 gekostet und rund fünfzehn Minuten gedauert. Gleiche Qualität, 75 % geringere Kosten.

Dieses Verhältnis gilt für die meisten meiner Projekte. Das Supervisor-Builder-Muster ist nicht nur ein Produktivitätstrick – es ist eine strukturelle Kostenoptimierung, die sich mit der Zeit auszahlt.

Falls du möchtest, dass jemand so ein Multi-Agenten-Setup von Grund auf für dich baut, übernehme ich AI-Infrastrukturprojekte über mein Fiverr-Profil.

Der nächste Workflow behandelt etwas, das die Backup- und Supervisor-Muster nicht abdecken: die kontinuierliche Überwachung von lang laufenden Prozessen.

Workflow 3: Das Monitor-System, das während meines Schlafs wacht

Manche Aufgaben erfordern kein aktives Erstellen. Sie erfordern Überwachung. Meine Scanner-Flotte beispielsweise läuft rund um die Uhr auf mehreren Zielsystemen. Ich kann nicht alle paar Stunden persönlich den Status jedes Scanners prüfen. Und das muss ich auch nicht – genau diese Art von repetitiver, taktbasierter Arbeit erledigt ein KI-Agent perfekt.

Im Monitor-Workflow übernimmt Hermes die Rolle des Wachhunds. Alle zwei Stunden (selbstverständlich konfigurierbar) führt Hermes eine geplante Überprüfung der vordefinierten Überwachungsziele durch. Er ruft die Scanner-Status ab, prüft auf Fehlerzustände, vergleicht die Performance mit den Basiswerten und schickt mir eine Zusammenfassung via Telegram.

Die entscheidende Designentscheidung: Hermes übernimmt das Monitoring, nicht OpenClaw. Dafür gibt es zwei Gründe.

Erstens, die Kosten. Eine Überprüfung alle zwei Stunden, 24/7, summiert sich auf 84 Checks pro Woche. Diese auf Opus 4.6 laufen zu lassen, wäre deutlich teurer als auf ChatGPT oder GLM-5. Die Monitoring-Aufgabe erfordert kein Opus-Niveau an Schlussfolgerungen – es geht um Mustererkennung und Schwellenwertvergleiche. Das leichtere Modell erledigt das perfekt.

Zweitens, die Verfügbarkeit. Wenn OpenClaw gerade mit einer komplexen Planungs- oder Review-Aufgabe beschäftigt ist, möchte man nicht, dass das Monitoring dahinter ansteht. Hermes läuft unabhängig, sodass das Monitoring nie durch andere Aufgaben verzögert wird. Die beiden Agenten arbeiten auf getrennten Ressourcenpools.

So sieht ein typischer Monitoring-Zyklus aus:

[Hermes Monitor — 2026-04-14 02:00 UTC]
Scanner-Flotten-Statusprüfung:
  ├── Scanner Alpha: ✅ Online (Uptime: 99,7 %, letzte 24h)
  ├── Scanner Beta: ✅ Online (Uptime: 98,2 %, letzte 24h)  
  ├── Scanner Gamma: ⚠️ Beeinträchtigt (Antwortzeit 340ms → 890ms, Untersuchung läuft)
  └── Scanner Delta: ✅ Online (Uptime: 100 %, letzte 24h)

Ergriffene Maßnahme: Untersuchung wegen Latenzspitze bei Scanner Gamma eingeleitet.
Ursache: Verzögerung bei der DNS-Auflösung durch Upstream-Provider.
Empfehlung: Kein sofortiges Handeln erforderlich – Überwachung auf Behebung.

Nächste Überprüfung: 2026-04-14 04:00 UTC

Dieser Bericht kam an, während ich schlief. Als ich um 7 Uhr morgens aufwachte, hatte sich das Gamma-Problem bereits von selbst gelöst – und Hermes hatte die Behebung inklusive Ursache und Zeitverlauf im Shared-Memory-System protokolliert. Sollte es erneut auftreten, kennen beide Agenten das Muster und können schneller reagieren.

Die Cronjob-Konfiguration dafür ist unkompliziert:

# hermes-tasks/scanner-monitor.yml
name: scanner_fleet_monitor
schedule: "0 */2 * * *"  # alle 2 Stunden
model: chatgpt
task: |
  Status aller aktiven Scanner prüfen.
  Für jeden Scanner verifizieren:
  - Prozess läuft
  - Antwortzeit liegt im Basisbereich (< 500ms)
  - Keine Fehlerprotokolle in den letzten 2 Stunden
  - Uptime-Prozentsatz für die letzten 24h
  Alle Anomalien mit Schweregrad melden.
  Bei kritisch: sofortige Benachrichtigung via Telegram.
  Bei Warnung: in den nächsten Zusammenfassungsbericht aufnehmen.
  Alle Ergebnisse im Shared-Memory-Workspace protokollieren.
escalation_threshold: critical
notify_channel: telegram

Der Monitor-Workflow ergänzt sich ideal mit dem Backup-Workflow. Erkennt Hermes, dass OpenClaw selbst die Ursache eines Problems ist – etwa weil OpenClaw eine Aufgabe gestartet hat, die zu viele Ressourcen verbraucht – kann Hermes dies melden, bevor das Problem eskaliert. So entsteht ein System, in dem nichts unbemerkt ausfällt – die gefährlichste Art von Fehler in jedem automatisierten System.

Doch alle drei bisher beschriebenen Workflows haben eine Einschränkung: Die Agenten lernen unabhängig voneinander. OpenClaw entwickelt sein eigenes Verständnis von Problemen und Lösungen. Hermes entwickelt sein eigenes. Keiner profitiert von den Erkenntnissen des anderen.

Genau das löst der vierte Workflow.

Workflow 4: Gemeinsamer Speicher — Wo beide Agenten gemeinsam dazulernen

Dies ist der Workflow, der das OpenClaw-Hermes-Duo von „nützlich“ zu „sich potenzierend“ erhebt. Das Konzept ist verblüffend einfach: Beide Agenten lesen aus und schreiben in eine gemeinsame Wissensdatenbank. In der Praxis entsteht dadurch etwas, das einer organisatorischen Erinnerung nahekommt — institutionelles Wissen, das unabhängig davon bestehen bleibt, welcher Agent gerade aktiv ist.

Ich setze das mit Obsidian um. Nicht, weil Obsidian die einzige Option wäre — jedes gemeinsame Dateisystem würde funktionieren — sondern weil Obsidians verlinkte Markdown-Struktur die Wissensbasis auch für Menschen durchsuchbar macht. Ich kann den Vault öffnen, darin suchen, Verbindungen zwischen Einträgen sehen und nachvollziehen, was meine Agenten gelernt haben. Diese Transparenz ist wichtig, wenn man autonomen Systemen echte Aufgaben anvertraut.

Der gemeinsame Speicherarbeitsbereich befindet sich in einem synchronisierten Ordner, auf den beide Agenten Zugriff haben. Die Struktur sieht so aus:

shared-memory/
├── logs/
│   ├── openclaw/
│   │   └── 2026-04-14-session.md
│   └── hermes/
│       └── 2026-04-14-monitor.md
├── mistakes/
│   ├── api-key-rotation-failure.md
│   ├── websocket-reconnection-missing.md
│   └── scanner-dns-resolution-delay.md
├── patterns/
│   ├── repair-patterns.md
│   ├── build-review-patterns.md
│   └── monitoring-baselines.md
├── decisions/
│   └── architecture-decisions.md
└── context/
    ├── project-scanner-fleet.md
    └── project-content-pipeline.md

Jedes Mal, wenn ein Agent auf etwas Erinnerungswürdiges stößt — einen Fehler, ein erfolgreiches Reparaturmuster, eine Entscheidung zum Umgang mit einem bestimmten Szenario — schreibt er einen Eintrag in den entsprechenden Ordner. Der Eintrag enthält, was passiert ist, warum es passiert ist, was der Agent dagegen unternommen hat und was er beim nächsten Mal anders machen würde.

Hier ist ein echter Eintrag aus meinem „mistakes“-Ordner, verfasst von Hermes nach einem Fehlalarm beim Monitoring:

# Fehlalarm: Scanner Gamma Timeout — 2026-04-11
---

## Was geschah

Hermes markierte Scanner Gamma um 14:22 UTC als „kritisch — nicht reagierend“.  
Sofortige Telegram-Benachrichtigung gesendet. OpenClaw startete Notfalldiagnose.

## Was tatsächlich geschah

Scanner Gamma reagierte normal. Der Monitoring-Check lief aufgrund einer kurzen Netzwerkstörung auf dem Monitoring-Host in einen Timeout, nicht wegen des Scanners selbst.

## Auswirkungen
Unnötiger Alarm. Etwa 0,12 $ an Diagnosetoken-Kosten verschwendet. Mejbas Nachmittag wurde durch eine falsche Notfallbenachrichtigung gestört.

## Fix angewendet
Wiederholungslogik hinzugefügt: 3 aufeinanderfolgende Fehlschläge, bevor auf "kritisch" eskaliert wird.  
Einzelner Fehlschlag wird jetzt als "wird untersucht" protokolliert, ohne eine Benachrichtigung auszulösen.

## Extrahiertes Muster
Netzwerkschicht-Probleme auf dem Monitoring-Host können Ziel-Ausfälle vortäuschen. Immer erneut versuchen, bevor eskaliert wird. Überprüfen Sie die Gesundheit des Monitoring-Hosts als Teil der Diagnosesequenz.

Dieser Eintrag steht nun beiden Agenten zur Verfügung. Wenn OpenClaw seine eigenen Überwachungsaufgaben ausführt, hat es Zugriff auf dieses Muster. Wenn Hermes in Zukunft auf eine ähnliche Situation stößt, wiederholt es nicht denselben Fehler. Das System hat einmal gelernt und beide Agenten profitieren davon.

Das ist es, was ich unter rekursiver Selbstverbesserung verstehe. Es ist nicht die Hollywood-Version, in der die KI plötzlich superintelligent wird. Es ist die langweilige, praktische Variante: Das System sammelt im Laufe der Zeit betriebliches Wissen an, und dieses Wissen macht es zuverlässiger, genauer und günstiger im Betrieb.

Hermes hat hier einen nativen Vorteil dank seiner eingebauten Lernschleife. Das Hermes Memory Keep-Alive Plugin für Obsidian synchronisiert den internen Speicher mit dem Vault, sodass Kern-Erinnerungen, Entitätsdaten und Gesprächsverläufe automatisch in den gemeinsamen Workspace fließen. OpenClaw erfordert etwas mehr manuelle Konfiguration, um in den gemeinsamen Ordner zu schreiben — ich verwende dafür eine eigene Fähigkeit, die nach jeder Sitzung ausgelöst wird und relevante Erkenntnisse ablegt — aber das Endergebnis ist dasselbe: Beide Agenten tragen zur gemeinsamen Wissensbasis bei und greifen darauf zu.

Nach drei Monaten Betrieb enthält mein gemeinsamer Memory Vault über 400 Einträge. Die Agenten greifen während ihrer Arbeit eigenständig auf diese Einträge zurück. Ich habe beobachtet, wie OpenClaw beim Planen eines Builds einen Hermes-Fehler-Eintrag zitiert und seine Architektur anpasst, um einen bekannten Fehlerfall zu vermeiden. Genau diese Art von agentenübergreifendem Lernen sorgt dafür, dass sich das gesamte System weniger wie zwei getrennte Tools und mehr wie ein einziges Team mit gemeinsamem institutionellen Wissen anfühlt.

Die Kostenrechnung, über die niemand ehrlich spricht

Ich werde beim Thema Kosten direkt sein, denn die meisten Artikel über Multi-Agenten-Setups ignorieren sie entweder komplett oder stellen sie als vernachlässigbar günstig dar.

OpenClaw auf Opus 4.6 zu betreiben ist nicht billig. Eine persistente Session mit aktiven Planungs- und Review-Aufgaben kostet mich etwa 80–120 $ pro Monat an API-Gebühren, je nach Arbeitsaufkommen. Das ist der Aufpreis, den man für erstklassige Reasoning-Leistung bei komplexen Aufgaben zahlt.

Hermes läuft bei mir auf dem 20-Dollar-ChatGPT-Plan und deckt damit den Großteil meiner Ausführungs- und Monitoring-Workloads ab. Für Batch-Processing-Aufgaben, bei denen ich noch niedrigere Kosten brauche, übernimmt GLM-5 das Ganze für etwa 0,001–0,003 $ pro 1.000 Tokens – vernachlässigbar für Monitoring und einfache Ausführungsaufgaben.

Meine gesamten monatlichen Ausgaben für das Zwei-Agenten-System: etwa 130–160 $.

Zum Vergleich: Mein vorheriges Setup – alles lief über OpenClaw auf Opus – kostete mich etwa 200–280 $ pro Monat, mit weniger Gesamtfunktionalität und keinerlei Redundanz. Das kombinierte System kostet weniger und leistet mehr. Allein das Supervisor-Builder-Muster spart so viele Opus-Token-Kosten ein, dass damit die gesamten Betriebskosten von Hermes abgedeckt sind.

Aber es gibt einen Kostenfaktor, den die meisten nicht berücksichtigen: die Einrichtungszeit. Die beiden Agenten richtig zu konfigurieren, das Shared-Memory-System zum Laufen zu bringen, die Health-Checks abzustimmen und die Übergabe zwischen Supervisor und Builder zuverlässig zu machen, hat mich etwa zwei volle Wochenenden gekostet. Das ist ein echter Zeitaufwand. Wenn du einen einzelnen Agenten für einfache Aufgaben betreibst und das funktioniert, könnte ein Multi-Agenten-Setup schlicht Overengineering sein.

Der Break-even-Punkt liegt meiner Erfahrung nach ungefähr in dem Moment, in dem du dich dabei ertappst, „Ich muss prüfen, ob mein Agent noch läuft“ zu sagen. Wenn du deinen Agenten überwachst, statt dein Agent deine Arbeit überwacht, brauchst du einen zweiten Agenten.

Was dieses System falsch macht – und was ich noch herausfinden muss

Nach drei Monaten ist das System nicht perfekt. Ehrlich über die Lücken zu sprechen ist wichtiger, als so zu tun, als gäbe es sie nicht.

Kontextdrift zwischen den Agenten. Selbst mit gemeinsam genutztem Speicher entwickeln OpenClaw und Hermes manchmal leicht unterschiedliche Auffassungen vom selben Projekt. OpenClaw plant möglicherweise ein Feature mit einem bestimmten Architekturpattern, während Hermes im Rahmen seines Lernzyklus bereits ein anderes Pattern weiterentwickelt hat. Der gemeinsame Speicher hilft, aber er beseitigt die Divergenz nicht vollständig. Ungefähr einmal pro Woche führe ich einen manuellen Abgleich durch, bei dem ich den gemeinsamen Workspace überprüfe und das Verständnis der Agenten über aktive Projekte explizit synchronisiere.

Update-Konflikte. Sowohl OpenClaw als auch Hermes spielen regelmäßig Updates ein. Wenn beide im selben Zeitraum aktualisiert werden – was häufiger vorkommt, als mir lieb ist – besteht eine nicht unerhebliche Wahrscheinlichkeit, dass ein Update die Kompatibilität mit dem anderen bricht. Ich habe begonnen, meine Updates zu staffeln: OpenClaw montags, Hermes donnerstags. Das erhöht den Verwaltungsaufwand, aber so sind nie beide Agenten gleichzeitig außer Betrieb.

Das Debugging-Paradoxon. Wenn im Zwei-Agenten-System etwas schiefgeht, ist die Diagnose manchmal schwieriger als bei einem Einzelagenten-Fehler. Hat OpenClaw Hermes einen schlechten Plan geliefert? Hat Hermes einen guten Plan falsch ausgeführt? Enthielt der gemeinsame Speicher ein fehlerhaftes Pattern, das beide Agenten in die Irre geführt hat? Die Debugging-Oberfläche ist größer. Gutes Logging mildert das Problem, beseitigt es aber nicht.

Modellabhängigkeitsrisiko. Mein aktuelles Setup basiert auf Opus 4.6 für OpenClaw und ChatGPT für Hermes. Wenn einer der Modellanbieter eine Störung hat, fällt die Hälfte meines Systems aus. Ich experimentiere mit Fallback-Konfigurationen – OpenClaw auf Sonnet 4.6 als degradierter, aber funktionaler Backup, Hermes auf GLM-5 als Fallback – aber ich habe die Qualitätsauswirkungen dieser Fallbacks unter realen Workloads noch nicht vollständig getestet.

Das sind lösbare Probleme, keine grundlegenden Schwächen. Und der Produktivitätsgewinn durch das Agentenpaar überwiegt jeden einzelnen dieser Punkte bei weitem. Aber man sollte mit realistischen Erwartungen an das herangehen, was „Multi-Agent“ im Alltag tatsächlich bedeutet: Es ist kein Set-and-Forget. Es ist Set-and-Maintain, wobei die Wartungskosten mit wachsendem gemeinsamen Speicher im Laufe der Zeit sinken.

So starten Sie: Das 30-Minuten-Setup, das Ihnen 80 % des Nutzens bringt

Wenn Sie das System ausprobieren möchten, ohne gleich ein ganzes Wochenende zu investieren, finden Sie hier die minimal funktionsfähige Version. Von hier aus können Sie später erweitern, sobald Sie den Mehrwert erkannt haben.

Schritt 1: Beide Agents installieren (10 Minuten).
OpenClaw läuft auf jedem System mit Node.js. Das GitHub-Repository (openclaw/openclaw) bietet eine Ein-Befehl-Installation. Hermes wird ähnlich aus NousResearch/hermes-agent installiert. Beide unterstützen Mac, Linux und Windows.

Schritt 2: Das Backup-Workflow konfigurieren (10 Minuten).
Richten Sie Hermes so ein, dass alle 60 Sekunden die Prozessgesundheit von OpenClaw überwacht wird (starten Sie konservativ, optimieren Sie später). Allein dieser Schritt liefert Ihnen den unmittelbar größten Mehrwert – automatische Wiederherstellung nach Abstürzen.

Schritt 3: Den Shared-Memory-Ordner anlegen (5 Minuten).
Eine einfache Verzeichnisstruktur: logs, mistakes, patterns. Beide Agents darauf verweisen lassen. Sie können später Obsidian hinzufügen, wenn Sie eine durchsuchbare Oberfläche möchten.

Schritt 4: Ihre erste Supervisor-Builder-Aufgabe ausführen (5 Minuten).
Geben Sie OpenClaw eine kleine Planungsaufgabe. Lassen Sie den Plan im gemeinsamen Ordner speichern. Weisen Sie Hermes an, den Plan auszuführen. Überprüfen Sie das Ergebnis. Das ist der Workflow.

Sie brauchen am ersten Tag keine Cronjobs zur Überwachung. Sie benötigen keine ausgefeilten Shared-Memory-Schemata. Sie müssen nicht sofort die Kostenoptimierung perfektionieren. Starten Sie mit Backup und Supervisor-Builder. Diese beiden Muster liefern den Großteil des Nutzens und zeigen Ihnen, wie die Agents zusammenarbeiten, bevor Sie weitere Komplexität hinzufügen.

Wohin sich Multi-Agenten-Systeme entwickeln

Die Kombination aus OpenClaw und Hermes, die ich heute täglich nutze, ist meiner Meinung nach ein Vorgeschmack darauf, wie die meisten Entwickler in den nächsten zwölf Monaten mit KI arbeiten werden. Nicht ein monolithischer Agent, der alles erledigt, sondern spezialisierte Agenten mit klar definierten Rollen, gemeinsamem Kontext und sich ergänzenden Stärken.

Die Anzeichen dafür sind bereits sichtbar. Databricks hat eine Supervisor-Agenten-Architektur für Unternehmens-Workflows eingeführt. CrewAI und LangGraph entwickeln Orchestrierungsschichten für die Koordination mehrerer Agenten. Die Roadmap von OpenClaw selbst sieht tiefere Protokolle für die Kommunikation zwischen Agenten vor. Der Lernkreislauf von Hermes – die Idee, dass ein Agent bei wiederholten Aufgaben messbar besser werden sollte – taucht inzwischen auch in anderen Frameworks auf.

Der Wettbewerbsvorteil besteht derzeit nicht darin, den besten Einzelagenten zu haben. Es geht darum, das beste Agenten-Team zu haben. Ein System, bei dem die Planung auf einem Modell erfolgt, das besonders gut im Planen ist, die Ausführung auf einem Modell, das besonders gut im Ausführen ist, und das Monitoring kontinuierlich ohne menschliches Eingreifen stattfindet.

Vor ein paar Wochen habe ich darüber geschrieben, wie OpenClaw-Agenten ein Unternehmen skalieren können, und über den Wandel von Aufgaben zu Jobs. Das Zwei-Agenten-System geht noch einen Schritt weiter: Es geht nicht nur darum, Agenten Jobs zuzuweisen – es geht darum, Agenten Kollegen zu geben. Ein Agent mit Backup, einem Reviewer und einer gemeinsamen Wissensbasis ist qualitativ etwas anderes als ein Agent, der allein arbeitet.

Richte heute Abend den Backup-Workflow ein. Beobachte, wie ein Agent den anderen zum ersten Mal korrigiert. Diese elfsekündige Wiederherstellung, die ich am Anfang dieses Beitrags beschrieben habe? Sie ist nicht die Obergrenze dessen, was dieses System leisten kann. Sie ist das Fundament.

Häufig gestellte Fragen

Kann ich OpenClaw und Hermes auf demselben Rechner ausführen?

Ja. Beide Agenten sind leichtgewichtig genug, um auf einem einzelnen Mac Mini M4 oder einem vergleichbaren Linux-Rechner mit 16 GB RAM zu laufen. Ich betreibe beide auf einer Maschine – OpenClaw als Hauptprozess und Hermes als Hintergrunddienst. Wichtig ist, dass sie unterschiedliche Modellanbieter nutzen, damit API-Rate-Limits nicht kollidieren.

Wie viel kostet das OpenClaw- und Hermes-Zwei-Agenten-Setup pro Monat?

Rechnen Sie mit insgesamt 130–160 $ pro Monat – etwa 80–120 $ für OpenClaw auf Opus 4.6 und 20–40 $ für Hermes auf ChatGPT oder GLM-5. Die genauen Kosten hängen von der Arbeitslast ab. Das Supervisor-Builder-Muster spart in der Regel 40–75 % im Vergleich zum alleinigen Betrieb auf einem Premium-Modell.

Brauche ich Obsidian für das Shared-Memory-System?

Nein. Jeder gemeinsam genutzte Ordner, auf den beide Agenten Lese- und Schreibzugriff haben, genügt. Obsidian bietet eine durchsuchbare, verlinkte Notiz-Oberfläche, die die Wissensbasis für Menschen lesbar macht, aber ein einfacher Ordner mit Markdown-Dateien bringt den Agenten denselben funktionalen Nutzen. Ich empfehle, mit einem einfachen Ordner zu starten und Obsidian später hinzuzufügen, wenn Sie die Shared Memory manuell prüfen und erkunden möchten.

Was passiert, wenn beide Agenten gleichzeitig abstürzen?

Das ist selten, aber möglich – meist verursacht durch ein systemweites Problem wie einen Stromausfall oder einen OS-Absturz, nicht durch einen Fehler auf Agenten-Ebene. Ich verwende einen einfachen systemd-Watchdog (launchd auf macOS), der beide Agenten neu startet, falls ihre Prozesse beendet werden. Diese dritte Redundanzebene kostet nichts und löst diesen Spezialfall zuverlässig.

Kann ich andere Modelle als Opus 4.6 und ChatGPT verwenden?

Absolut. OpenClaw unterstützt über 50 Modellanbieter, darunter Gemini, GLM-5, Sonnet 4.6 und lokale Modelle über Ollama. Hermes arbeitet mit jeder OpenAI-kompatiblen API. Die Kombination Opus + ChatGPT ist meine Empfehlung für das beste Verhältnis von Qualität und Kosten, aber Sie können beide auch auf günstigeren Modellen betreiben, wenn das Budget die Hauptrolle spielt – rechnen Sie dann allerdings mit geringerer Qualität bei komplexen Planungsvorgängen.

Lassen Sie uns zusammenarbeiten

Möchten Sie KI-Systeme entwickeln, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

• Fiverr (individuelle Lösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io