OpenClaw implementiert Agent History Compression, um die Kontextnutzung zu reduzieren

✍️ OpenClawRadar📅 Veröffentlicht: 10. März 2026🔗 Source
OpenClaw implementiert Agent History Compression, um die Kontextnutzung zu reduzieren
Ad

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.

Ad

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.

📖 Read the full source: r/openclaw

Ad

👀 Siehe auch

Unsloth und NVIDIA arbeiten zusammen, um das LLM-Training um etwa 25 % zu beschleunigen
Werkzeuge

Unsloth und NVIDIA arbeiten zusammen, um das LLM-Training um etwa 25 % zu beschleunigen

Unsloth und NVIDIA veröffentlichen Optimierungen für das Training großer Sprachmodelle: Caching von Metadaten gepackter Sequenzen (~14,3% Beschleunigung) und doppelt gepuffertes asynchrones Gradienten-Checkpointing (~8% Beschleunigung), ohne Genauigkeitsverlust. Automatisch aktiviert auf RTX-Laptops, Data-Center-GPUs und DGX Spark.

OpenClawRadar
Gemma 4 26B vs. Qwen 3.5 27B: Benchmark für lokale Geschäftsabläufe auf der RTX 4090
Werkzeuge

Gemma 4 26B vs. Qwen 3.5 27B: Benchmark für lokale Geschäftsabläufe auf der RTX 4090

Ein Entwickler testete Gemma 4 26B und Qwen 3.5 27B auf einer RTX 4090 Workstation mit 18 realen Geschäftsbetreiber-Aufgaben. Gemma gewann mit 13:5, zeigte schnellere Geschwindigkeit und bessere Disziplin für tägliche Ausführungsarbeit, während Qwen bei breiterem strategischem Denken glänzte.

OpenClawRadar
ExposureGuard MCP Server fügt Claude Desktop Domänensicherheitsscans hinzu
Werkzeuge

ExposureGuard MCP Server fügt Claude Desktop Domänensicherheitsscans hinzu

Ein Entwickler hat einen MCP-Server für Domain-Sicherheitsscans mit Claude Code erstellt, der vier Tools bereitstellt, die SPF, DMARC, SSL, Sicherheitsheader, DNSSEC, offene Ports, MX und HTTPS überprüfen. Der Server ist über pip install exposureguard-mcp verfügbar und bietet eine kostenlose Stufe von 100 API-Aufrufen pro Tag.

OpenClawRadar
ClawCloud Managed Service vereinfacht die OpenClaw-Bereitstellung für Slack-Teams
Werkzeuge

ClawCloud Managed Service vereinfacht die OpenClaw-Bereitstellung für Slack-Teams

ClawCloud bietet einen verwalteten Bereitstellungsdienst für OpenClaw, der sich mit Slack-Arbeitsbereichen verbindet, die Infrastruktur verwaltet und die Antwortlatenz auf unter 2 Sekunden reduziert. Ein Benutzer berichtete von einer Einrichtungszeit von 20 Minuten im Vergleich zu 3 Tagen für das Selbsthosting, mit Kosten von etwa 30 US-Dollar pro Monat für ein 40-köpfiges Team.

OpenClawRadar