Wenn LLM-Agenten von Prototypen in die Produktion überführt werden, sind die gefährlichsten Ausfälle selten falsche Antworten, sondern Systemabstürze um 2 Uhr morgens wegen eines 429-Fehlers, eines überlangen Logs oder eines abgelaufenen API-Keys. Viele Frameworks überlassen das dem try/except des Entwicklers. Hermes Agent baut die Wiederherstellung direkt in die Laufzeit ein.

Dieser Artikel zerlegt Hermes Agents sechsstufigen Fehlertoleranz-Stack: Fehlerklassifizierung, adaptive Wiederholung, Provider-Fallback, Kontextkomprimierung, Checkpoint-Rollback und Sitzungswiederherstellung. Sie werden genau sehen, wie Hermes sich selbst wieder auf die Beine stellt, wenn etwas schiefgeht.

1. Erst klassifizieren, dann entscheiden: Der Fehlerklassifikator

Hermes leitet jeden API-Fehler durch classify_api_error() in agent/error_classifier.py. Es behandelt nicht jede Ausnahme als generisches Netzwerkproblem, sondern ordnet sie einem konkreten FailoverReason zu: rate_limit, overloaded, context_overflow, payload_too_large, long_context_tier, auth, billing, content_policy_blocked, ssl_cert_verification, timeout, stream_drop, thinking_signature, model_incompatible und invalid_request.

Jeder Grund trägt drei Flags: retryable, should_fallback und should_compress. Die Wiederherstellungsschleife handelt auf Basis dieser Flags, nicht des rohen Fehlertexts. Das macht die Strategie vorhersagbar, testbar und erweiterbar.

2. Adaptive Wiederholung: Retry-After lesen, nicht nur schlafen

Hermes implementiert adaptive_rate_limit_backoff() in agent/retry_utils.py. Es handelt sich nicht um einen naiven exponentiellen Backoff. Es:

• Liest den HTTP-Header Retry-After.
• Begrenzt die Wartezeit auf 600 Sekunden, damit ein Provider die Sitzung nicht ewig blockiert.
• Verwendet spezielle Long-/Short-Backoff-Richtlinien für Z.AI-Coding-Überlastung.
• Fügt Jitter hinzu, damit mehrere gleichzeitige Hermes-Instanzen nicht gleichzeitig auf den Provider zurückschlagen.

Während der Wiederholungsschleife gibt Hermes einen kompakten Statusblock aus: Fehlertyp, Provider, Modell, verstrichene Zeit, Kontextgröße und Countdown. Diese Transparenz ist entscheidend für das Debugging von 24×7-Gateways oder Cron-Jobs.

3. Provider-Fallback: Vom lokalen Retry zum Cross-Provider-Escape

Hermes starrt nicht auf einen einzigen Provider. Es wählt den Pfad basierend auf dem Fehlertyp.

• Transparenter lokaler Retry: Bei Verbindungsabbrüchen, 5xx und 408 wird mehrmals auf demselben Provider wiederholt.
• Authentifizierungserneuerung und Credential-Pools: Bei auth-Fehlern werden Credentials aktualisiert, Nous-Portal-Runtime erneuert und Keys rotiert, falls ein Pool konfiguriert ist.
• Abrechnung und Rate Limits: Der aktuelle Provider wird als unhealthy markiert und die Fallback-Kette aktiviert: zuerst benutzerdefinierte fallback_chain, dann globale fallback_providers, dann interne Auto-Discovery-Kette.
• Inhaltspolitik: Bei content_policy_blocked wird nicht wiederholt; stattdessen bekommt der Nutzer eine klare Handlungsanweisung.

Bei Nous-Portal-429s schreibt Hermes einen sitzungsübergreifenden rate_limit-Datensatz, damit alle Worker denselben erschöpften Bucket nicht weiter belasten. Das ist ein Schutz für hochkonkurrente, langlaufende Deployments.

4. Kontextkomprimierung: Aus “Kontext-Explosion” wird Routine

Der häufigste Fehler in langen LLM-Gesprächen ist das Überschreiten des Kontextfensters. Hermes geht dabei ungewöhnlich präzise vor:

• Output-Cap-Fehler: Wenn max_tokens das Provider-Limit für das Modell übersteigt, wird der Nutzer aufgefordert, model.max_tokens zu senken, ohne Wiederholungen zu verschwenden.
• Input-too-large: Hermes extrahiert das echte Limit aus der Fehlermeldung, aktualisiert die context_length des Kompressors und komprimiert die Nachrichten.
• Minimax-Sonderfall: Wenn der Provider nur “um X Token überschritten” meldet, wird das Originalfenster beibehalten und komprimiert.

Die Komprimierung ist nicht einstufig: zuerst werden Nachrichten zusammengefasst, dann Bild-Payloads aus Tool-Nachrichten entfernt, und erst dann wird der Nutzer zu /new oder /compress aufgefordert. Bei Anthropic-Long-Context-Tier-Fehlern wird das Fenster temporär von 1M auf 200K reduziert und komprimiert, ohne den Downgrade zu persistieren.

5. Checkpoints und Rollbacks: Versicherung für Dateien und Zustand

Hermes enthält in tools/checkpoint_manager.py einen Dateisystem-Checkpoint-Manager. Jederzeit kann /rollback ausgeführt werden, um verfügbare Checkpoints aufzulisten und wiederherzustellen. Für Refactorings, Konfigurationsänderungen oder Batch-Dateioperationen ist das eine leichte Undo-Schicht.

Snapshots gehen weiter:

/snapshot create before-major-refactor
/snapshot restore 20260717_142030
/snapshot prune 10

/snapshot speichert Hermes-Konfiguration und Laufzeitstatus, während /rollback Arbeitsverzeichnis-Dateien sichert. Zusammen decken sie Zustand und Dateien ab.

6. Sitzungswiederherstellung: nahtloses Handoff zwischen CLI und Telegram

Hermes persistiert jede Konversation in einer SQLite-Datenbank unter ~/.hermes/state.db, inklusive vollständigem Nachrichtenverlauf, Tool-Calls, Token-Zählern, System-Prompt-Snapshots, Zeitstempeln und Parent-Sitzungs-IDs. Das bedeutet:

• hermes --continue oder hermes -r <session_id> setzt die letzte CLI-Sitzung fort.
• /new payments-refactor benennt eine Sitzung, und /resume payments-refactor ruft sie später ab.
• Sitzungen können zwischen Plattformen übergeben werden: starten in der CLI, auf Telegram weitermachen, später mit /resume auf dem Desktop fortsetzen.

Beim Wiederherstellen zeigt Hermes eine kompakte Zusammenfassung, damit Sie den Thread nicht neu lesen müssen. Lange Sitzungen lassen sich mit /compress im Griff behalten.

7. Befehlsübersicht für Notfälle

Befehl	Funktion
/retry	Letzte Nachricht erneut senden.
/resume [name]	Vorherige Sitzung fortsetzen.
/new [name] / /reset	Neue Sitzung starten, optional benennen.
/compress [here [N] | focus topic]	Kontext manuell komprimieren.
/undo	Letzten Austausch Nutzer/Assistant entfernen.
/rollback [number]	Dateisystem-Checkpoint auflisten oder wiederherstellen.
/snapshot create/restore/prune	Snapshots speichern, wiederherstellen oder aufräumen.
/stop	Alle Hintergrundprozesse beenden.
hermes --continue	Letzte CLI-Sitzung fortsetzen.
hermes -r <id>	Sitzung per ID fortsetzen.
hermes -c "name"	Sitzung per Name fortsetzen.

8. Vergleich mit gängigen Frameworks

Fähigkeit	Hermes Agent	OpenAI Agents	AutoGen/AG2	CrewAI	LangGraph
Fehlerklassifizierung	Integriertes FailoverReason	SDK-Basisfehler	Einfacher	Tool-Ebene	Selbst designen
Automatischer Provider-Fallback	Integrierte Fallback-Kette	Manuelle Implementierung	Teilweise	Nicht unterstützt	Manuelle Implementierung
Kontextkomprimierung	Integrierte Mehrstufigkeit	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt
Sitzungspersistenz/-wiederherstellung	SQLite + /resume	Selbst speichern	Selbst speichern	Nicht unterstützt	State-Machine-Checkpoint
Dateisystem-Checkpoints	/rollback	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt
Plattformübergreifendes Handoff	Integriert	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt

Der Unterschied bei Hermes: Fehlerbehandlung ist kein optionales Plugin, sondern Teil des Agent-Runtimes. Sie schreiben keine try/except-Blöcke, pflegen keine Provider-Listen und kürzen keine Kontexte manuell. Das alles ist Standardverhalten.

9. Praktische Empfehlungen für Engineering-Teams

1. Konfigurieren Sie einen Fallback-Provider. Mindestens einer in Produktion, damit 429 und 402 nicht zu nächtlichen Alerts werden.
2. Benennen Sie wichtige Sitzungen. Mit /new <task-name> können Sie später /resume nutzen und zwischen Plattformen wechseln.
3. Erstellen Sie Snapshots vor großen Änderungen. /snapshot create <label> ermöglicht schnelles Zurückrollen.
4. Nutzen Sie cron no-agent für wiederholbare Aufgaben. Für wiederkehrende, kritische Jobs vermeiden no_agent: true-Cron-Scripts mit direktem stdout die Unsicherheit der LLM-Inferenz.
5. Sichern Sie ~/.hermes/state.db. Dort lebt Ihr gesamter Konversationsverlauf.

Fazit

Hermes Agents Fehlerbehandlungssystem ist weit mehr als “ein paar Mal wiederholen und aufgeben”. Es greift die häufigsten Fehlermodi von LLM-Operationen aus sechs Richtungen an: Klassifizierung, Wiederholung, Fallback, Komprimierung, Checkpoints und Sitzungswiederherstellung. Für Teams, die Agenten in Produktion betreiben wollen, ist diese Selbstheilungsfähigkeit genauso wichtig wie die Reasoning-Fähigkeit des Modells selbst.

Wenn Sie noch Ad-hoc-Skripte für Provider-Ausfälle, Kontext-Blähung oder Modellwechsel schreiben, lassen Sie Hermes diese Drecksarbeit übernehmen. Konfigurieren Sie Ihren Fallback, drücken Sie /resume und machen Sie weiter.