OpenClaw implementiert Agent History Compression, um die Kontextnutzung zu reduzieren

Problem der Kontextverwaltung

Wenn OpenClaw innerhalb von Docker läuft, füllt das direkte Code-Schreiben durch den Agenten den Kontext mit Rauschen: Dateien lesen (5K Token), Bearbeitungen schreiben (500 Token), Tests ausführen (200 Token) und Stack-Traces empfangen (3K Token). Ein einzelner Debug-Zyklus verbraucht 10K-15K Token, hauptsächlich durch Konsolenausgaben und Stack-Traces, die nach Fehlerbehebungen nutzlos werden. Bei 20-30 Debug-Zyklen pro Sitzung wird das gesamte Kontextfenster von Rauschen verbraucht.

Brain/Worker-Architektur

Die Lösung beinhaltet die Trennung von Verantwortlichkeiten: OpenClawd (in Docker) fungiert als das Gehirn für Planung, Aufteilung der Arbeit in Teilaufgaben, Delegierung und Koordination. Ein lokaler Worker auf dem macOS-Host, betrieben von Qwen3.5-27B auf Apple Silicon über MLX ohne Kosten, dient als die Hände zum Lesen von Dateien, Schreiben von Code, Ausführen von Tests und Debuggen. Dadurch bleibt der laute Hin-und-Her-Verkehr im Kontext des Workers, während das Gehirn nur Endergebnisse wie "Aufgabe erledigt, hier sind die geänderten Dateien" sieht.

Kompressionsstrategie

Selbst mit der Brain/Worker-Trennung füllt sich der Kontext des Orchestrators weiterhin mit Betriebsdokumenten: AGENTS (~6,6K Token), SOUL (~1,5K Token), LESSONS (~10K Token) und Pläne/Anleitungen (~13K Token auf der Festplatte), insgesamt 20K-30K Token, bevor überhaupt Arbeit beginnt. Sitzungen können 100K-200K Token erreichen.

Die entscheidende Erkenntnis: Abgeschlossene Arbeit benötigt keine Rohdetails. Sobald eine Teilaufgabe abgeschlossen ist, wird ihr Rohverlauf zu totem Gewicht. Der Agent muss nur wissen: Was war die Aufgabe, war sie erfolgreich, welche Dateien wurden geändert und gab es Fehler.

Implementierungsdetails

Schritt 1: Lebenszyklusgrenzen erkennen - Der Orchestrator zerlegt die Arbeit in Teilaufgaben mit Lebenszyklen: Spawn (Agent ruft sessions_spawn oder delegate_task auf), Execute (Tool-Aufrufe, Überlegungen) und Complete (Systemnachricht "subagent 'task_name' completed"). Ein 4-Pass-Scanner durchläuft die Session-JSONL:

• Pass 1: Spawn-Ereignisse finden
• Pass 2: Spawn-Fehler finden
• Pass 3: Abschlussmarker finden
• Pass 4: Tokenanzahl und Dauer pro Lebenszyklus berechnen

Dies identifiziert Nachrichtenbereiche, die zu abgeschlossenen Teilaufgaben gehören.

Schritt 2: In "Agentensprache" zusammenfassen (Maskierung) - Zusammenfassungen werden so generiert, dass sie wie normale Agentenausgaben aussehen, um die Kompatibilität mit dem erwarteten Nachrichtenformat des Orchestrators beizubehalten (Rollen, Inhaltsblöcke, Tool-Aufrufstrukturen, Eltern-Kind-ID-Ketten). Diese maskierten Zusammenfassungen ersetzen den Rohaufgabenverlauf.

Beispiel einer kompakten Aufgabenübersicht:

── KOMPAKTE AUFGABE ──
ursprung: agent
aufgabe: Leerlauf-Timeout für MLX-Server implementieren
ergebnis: erfolgreich
resultat: 5-Minuten-Leerlauftimer zu MlxServerManager hinzugefügt.
Server entlädt automatisch, wenn keine Anfragen empfangen werden.
dateien+: src/services/mlx_idle_monitor.py
dateien~: src/services/mlx_server.py, config.json
fehler: keine
versucht_und_gescheitert: threading.Timer — Race-Condition
merken: MLX-Server darf nur bei expliziter Worker-Anfrage neu laden, nicht bei jedem Tool-Aufruf
─────────────────

Diese ~100-Token-Zusammenfassung ersetzt 5K Token an Roh-Tool-Aufrufen und Überlegungen (99,2 % Reduktion). Zusammenfassungen werden von einem kostengünstigen LLM (Gemini Flash Lite oder lokalem MLX) generiert, mit Fallback-Mechanismen, falls die Generierung fehlschlägt.