Kontext-Engine & Kompaktierung

Viele behandeln Kontext wie einen nebulösen KI-Nebel. Genau so landet man bei Debugging nach Aberglaube.

Ein besseres Bild ist eine Werkbank. Bei jedem Turn entscheidet OpenClaw, was auf diese Werkbank gelegt wird, damit das Modell es sehen kann. Ist die Fläche sauber, wirkt das Modell fokussiert. Liegt sie unter alten Tool-Logs, riesigen Dateien und abgestandenen Schleifen begraben, verfehlt das Modell langsam den Punkt.

Die offiziellen Docs zu concepts/context, concepts/context-engine und concepts/compaction kreisen alle um dieselbe praktische Wahrheit: Kontext ist der live genutzte Arbeitssatz, und OpenClaw hat explizite Mechanismen, um diesen Arbeitssatz nutzbar zu halten.

Was Kontext eigentlich ist

In OpenClaw ist Kontext alles, was für einen Lauf an das Modell geschickt wird, begrenzt durch das Kontextfenster des Modells.

• der System Prompt, den OpenClaw für diesen Lauf baut
• die Gesprächshistorie der Sitzung
• Tool Calls und Tool Results
• Anhänge, Transkripte und andere injizierte Inhalte
• Kompaktierungs-Zusammenfassungen und verwandte Prompt-Artefakte

Diese Liste ist wichtig, weil sie einen typischen Anfängerfehler beendet. Viele glauben, nur der sichtbare Chattext zähle. Tut er nicht. Tool-Schemas, lange Datei-Injektionen, Kommandoausgaben und alte Sitzungsreste kämpfen alle um dasselbe Fenster.

Wo die Kontext-Engine hineinpasst

Die Kontext-Engine ist der Teil, der steuert, wie dieser Arbeitssatz zusammengesetzt wird.

Standardmäßig nutzt OpenClaw die eingebaute legacy-Engine. Die Docs sagen ziemlich klar, dass die meisten Nutzer sie in Ruhe lassen sollten. Trotzdem besitzt diese Engine unter der Haube einen echten Lifecycle.

• ingest: neue Nachrichten beim Eintreffen verarbeiten
• assemble: die geordneten Nachrichten bauen, die ins Token-Budget passen
• compact: ältere Historie reduzieren, wenn das Fenster zu voll wird
• after turn: Zustand nach dem Lauf speichern oder aufräumen

Genau das ist der nützliche Unterschied. Die Kontext-Engine ist nicht bloß ein Formatter. Sie ist die Policy-Schicht dafür, was das Modell sieht und wie Sitzungsverlauf über Zeit umgebaut wird.

Warum OpenClaw das überhaupt offenlegt

Wenn du nur kurze Chats führst, bleibt der Standardpfad fast unsichtbar. Das ist völlig okay.

OpenClaw ist aber für langlebige Sitzungen, tool-lastige Arbeit, Hintergrundaufgaben und Subagenten gebaut. In dieser Welt ist Kontext-Assembly kein kleines Implementierungsdetail. Es ist Betriebshygiene. Die Docs erlauben sogar Plugin-Engines mit eigener Assembly, eigener Kompaktierung und optionalen Subagent-Lifecycle-Hooks, weil manche Setups mehr brauchen als nur ein rollendes Standard-Transkript.

Denk an einen Redakteur in einer Redaktion. Reporter liefern jede Menge Rohmaterial. Der Redakteur entscheidet, was auf Seite eins kommt, was verdichtet wird und was archiviert wird, ohne vergessen zu sein. Das Modell arbeitet besser, wenn diese redaktionelle Arbeit absichtlich geschieht.

Was Kompaktierung verändert

Kompaktierung ist OpenClaws Methode, alte Gespräche zu schrumpfen, ohne so zu tun, als wären sie nie passiert.

Wenn eine Sitzung an die Kontextgrenze kommt, fasst OpenClaw ältere Turns in einem kompakten Eintrag zusammen, lässt die neueren Nachrichten intakt und speichert diese Zusammenfassung im Transkript. Die vollständige Historie bleibt auf der Platte. Was sich ändert, ist die Version dieser Historie, die das Modell im nächsten Lauf sieht.

Dieser Unterschied verdient eine fette Unterstreichung. Kompaktierung ist nicht dasselbe wie Löschen. Es ist eher so, als würdest du einen Stapel Meeting-Notizen durch eine gute Management-Zusammenfassung ersetzen, damit das nächste Meeting weitergehen kann.

Auto-Kompaktierung vs. manuelle Kompaktierung

OpenClaw aktiviert Auto-Kompaktierung standardmäßig. Sie kann anspringen, wenn sich die Sitzung dem Kontextlimit nähert oder wenn ein Provider einen Kontext-Overflow meldet. Sie ist also sowohl vorbeugend als auch reaktiv.

Du kannst sie auch selbst auslösen, wenn du schon weißt, dass das Gespräch aufgebläht wird.

/status
/context list
/context detail
/compact
/compact Fokus auf die API-Entscheidungen

Diese Befehle sind unterschätzt, weil sie Rätselraten durch Sichtbarkeit ersetzen. Wenn sich eine Sitzung merkwürdig anfühlt, schau erst auf die Werkbank, bevor du dem Handwerker die Schuld gibst.

Speicher ist nicht Kontext

Hier werfen viele drei verschiedene Dinge zusammen: Live-Kontext, gespeicherten Speicher und Sitzungs-Transkript-Historie.

Kontext ist das, was das Modell gerade jetzt sieht. Speicher sind dauerhaft abgelegte Informationen, die später wieder geholt werden können. Das Transkript ist die protokollierte Historie der Sitzung auf der Platte.

• Kontext = aktueller Arbeitssatz
• Speicher = gesicherte Fakten oder Notizen für später
• Transkript = vollständige aufgezeichnete Historie dessen, was passiert ist

Du kannst wichtige Speicherinhalte haben, die gar nicht im Live-Prompt liegen. Du kannst Transkript-Historie haben, die auf der Platte erhalten bleibt, aber für den aktuellen Turn bereits zusammengefasst wurde. Und du kannst trotzdem ein überladenes Kontextfenster haben, obwohl Speicher ordentlich eingerichtet ist.

Genau deshalb erinnern die Docs den Agenten vor der Kompaktierung daran, wichtige Notizen zu sichern. Speicher trägt weiter, was dauerhaft bleiben soll. Kontext trägt, was jetzt nützlich ist. Gleiches Ökosystem, andere Aufgabe.

Kompaktierung ist auch nicht dasselbe wie Pruning

Noch eine Verwechslung, die oft passiert: Kompaktierung und Session Pruning lösen unterschiedliche Probleme.

Kompaktierung fasst ältere Gesprächsteile zusammen und schreibt diese Zusammenfassung ins Transkript. Session Pruning trimmt alte Tool-Ausgaben im Arbeitsspeicher vor einem Modellaufruf, ohne das Transkript umzuschreiben. Das eine ist zusammenfassende Historien-Reduktion. Das andere ist leichte Reinigung von Tool-Ausgaben.

Wenn eine Sitzung vor allem wegen riesiger exec-Ausgaben, Datei-Reads oder Suchresultate aufbläht, kann Pruning dir mehr Luft verschaffen, bevor volle Kompaktierung überhaupt nötig wird.

Wie du Kontext-Bloat praktisch reduzierst

Du brauchst keine eigene Plugin-Engine, um bessere Ergebnisse zu bekommen. Meist brauchst du einfach bessere Ordnung.

1. Erst prüfen, dann raten

Nutze /status, /context list und /context detail. Die offiziellen Docs zeigen ziemlich deutlich, dass große Workspace-Dateien, Tool-Schemas und alte Tool-Ausgaben weit mehr Platz fressen können, als man denkt.

2. Workspace-Dateien schlank halten

OpenClaw injiziert Bootstrap-Dateien wie AGENTS.md, SOUL.md, TOOLS.md und andere in den Project Context. Große Dateien können gekürzt werden, kosten aber trotzdem Kontext. Wenn eine Datei zur Gerümpelschublade wird, bezahlt dein Agent sie bei jedem Turn mit.

3. Bewusst kompaktieren

Warte nicht erst, bis das Modell schon stolpert. Wenn eine Sitzung den Punkt erreicht hat, an dem alte Debatten weniger wichtig sind als aktuelle Ausführung, nutze /compact und gib bei Bedarf einen Fokus mit.

4. Dauerhafte Notizen in Speicher ablegen

Wenn etwas über das aktuelle Arbeitsfenster hinaus wichtig bleibt, speichere es sauber ab, statt zu hoffen, dass die Live-Historie es für immer mitschleppt. Das gilt besonders für Präferenzen, Entscheidungen und stabile Projektfakten.

5. Pruning für tool-lastige Sitzungen verwenden

Tool-Ausgaben sind oft der stille Killer. Session Pruning kann alte Resultate zurückschneiden, ohne das eigentliche Gespräch plattzumachen.

6. Die Engine nur ändern, wenn der Standard nicht mehr passt

Der Plugin-Slot ist für Teams gedacht, die eigene Assembly, besondere Recall-Muster oder engine-eigene Kompaktierungslogik brauchen. Das ist ein Power-Feature, kein Anfänger-Kästchen. Wenn du nicht erklären kannst, welches Problem deine neue Engine löst, lass die Standard-Engine drin.

Wann eine eigene Kontext-Engine sinnvoll wird

Selten heißt nicht nie. Eine eigene Engine kann sinnvoll sein, wenn du sitzungsübergreifendes Recall-Verhalten brauchst, eine andere Kompaktierungsstrategie willst oder für bestimmte Runtimes strenger kontrollieren musst, was überhaupt in den Prompt gelangt.

Die offizielle concepts/context-engine-Doku erwähnt außerdem Host-Anforderungen, Plugin-Fehlerisolation und das Flag ownsCompaction. OpenClaw sagt dir damit ziemlich höflich: Dieses Feature ist ernst. Wenn deine Engine kaputtgeht, kann Prompt-Assembly degradiert werden oder in bestimmten Fällen bewusst fail closed. Also behandle eigene Engines wie Infrastruktur, nicht wie Deko.

Ein praktisches Denkmodell

Wenn du die Kurzfassung willst, nimm dieses Bild:

• Kontext ist die Werkbank
• die Kontext-Engine entscheidet, was darauf landet
• Kompaktierung räumt alten Ballast weg und ersetzt ihn durch eine Zusammenfassung
• Speicher bewahrt dauerhafte Notizen an einem sichereren Ort als auf der Werkbank
• Pruning kehrt alte Tool-Reste weg, bevor sie den ganzen Raum übernehmen

Dieses Modell ist simpel, aber nah genug an der echten Maschine, um bessere Entscheidungen zu treffen.

Der praktische Gewinn für Betreiber

Sobald du Kontext-Engine und Kompaktierung verstehst, lässt sich merkwürdiges Verhalten in langen Sitzungen deutlich sauberer einordnen.

Wenn Antworten abdriften, frag dich, ob der aktuelle Prompt überladen oder abgestanden ist. Wenn Kosten steigen, prüfe, ob Tool-Ausgaben und injizierte Dateien jeden Turn unnötig aufblasen. Wenn ein Agent etwas Wichtiges vergisst, frag dich, ob es als Speicher hätte gesichert werden sollen, statt im rohen Gesprächsverlauf überleben zu müssen.

Genau darin liegt der eigentliche Gewinn. Du behandelst langlaufende KI-Sitzungen nicht mehr wie Magie, sondern wie Systeme mit Budgets, Engpässen und Aufräumregeln.