Ich habe 5 Tage damit verbracht, den Speicher meines OpenClaw-Agenten zu debuggen. Hier ist alles, was ich gelernt habe.

Mein Agent heißt Chiti. Er läuft auf Telegram, kümmert sich um den Kundensupport für zwei SaaS-Produkte, entwirft Tweets, verwaltet Rechnungen und koordiniert mit meinem Mitgründer über Zeitzonen hinweg. Er ist das, was ich einem Junior-Angestellten am nächsten komme.

Und wochenlang hat er ständig Dinge vergessen.

Nicht auf eine subtile Art. Ich verbrachte eine Stunde damit, einen täglichen Cron-Job zu konfigurieren, wechselte die Modelle, und in der nächsten Sitzung tat Chiti, als hätten wir nie miteinander gesprochen. Ich bezog mich auf eine Entscheidung von vor zwei Tagen und bekam einen leeren Blick. Ich bat ihn, eine Aufgabe fortzusetzen, und er fing von vorne an.

Also hörte ich auf, Features zu bauen, und investierte 5 Tage, wann immer ich Zeit hatte, nur um den Speicher zu reparieren. Das hier ist alles, was ich gefunden, alles, was ich kaputt gemacht, und alles, was tatsächlich funktioniert hat.

Tag 1: Der Agent vergisst nach langen Unterhaltungen alles

Das erste Problem war einfach zu beschreiben und schmerzhaft zu diagnostizieren.

Nach langen Unterhaltungen begann Chiti, früheren Kontext zu verlieren. Nicht allmählich – er verschwand einfach. Dinge, die ich ihm vor 20 Nachrichten gesagt hatte, waren weg. Entscheidungen, die wir zu Beginn der Sitzung getroffen hatten? Nie passiert.

Der Übeltäter war die Kompaktierung. Wenn die Unterhaltung das Kontextfenster füllt, komprimiert OpenClaw ältere Nachrichten zu einer Zusammenfassung, um Platz für neue zu schaffen. Die Zusammenfassung erfasst das Wesentliche, lässt aber Details weg. Namen, Zahlen, genaue Entscheidungen – weg.

Das ist beabsichtigt. Das Kontextfenster ist endlich. Aber das Standardverhalten behandelt alles gleich, was bedeutet, dass deine sorgfältig formulierte Anweisung aus Nachricht #3 genauso behandelt wird wie ein beiläufiges Smalltalk aus Nachricht #7.

Was ich getan habe:

Ich habe den Speicher-Flush vor der Kompaktierung aktiviert. Das weist den Agenten an, wichtigen Kontext auf die Festplatte zu schreiben, bevor der Kompressor läuft.

1{
2  "compaction": {
3    "memoryFlush": {
4      "enabled": true,
5      "softThresholdTokens": 4000
6    }
7  }
8}

Wenn sich die Sitzung der Kontextgrenze nähert, löst OpenClaw einen stillen Zug aus, der den Agenten daran erinnert, dauerhafte Fakten in memory/YYYY-MM-DD.md zu speichern, bevor die Kompaktierung sie löscht. Der Agent schreibt auf, was wichtig ist, die Kompaktierung läuft, und die wichtigen Dinge überleben auf der Festplatte, selbst wenn die Kontextzusammenfassung sie verliert.

Was ich gelernt habe:

Kompaktierung ist nicht dein Feind. Informationen während der Kompaktierung zu verlieren, ist es. Die Lösung ist sicherzustellen, dass alles, was es wert ist, erinnert zu werden, in eine Datei geschrieben wird, bevor der Kompressor es anfasst. Wenn es nur im Kontextfenster ist, ist es temporär. Wenn es auf der Festplatte ist, überlebt es.

Tag 2: Suche liefert Müll

Mit täglichen Protokollen, die sich anhäufen, und MEMORY.md, das wächst, musste ich, dass der Agent tatsächlich Dinge findet. Die integrierte Speichersuche lieferte irrelevante Ergebnisse oder übersah offensichtliche Übereinstimmungen.

Das Problem war das Such-Backend. OpenClaws standardmäßige SQLite-basierte Suche verwendet Vektor-Embeddings (semantische Ähnlichkeit), um relevante Stücke zu finden. Sie funktioniert für breite Suchanfragen, hat aber Schwierigkeiten mit exakten Übereinstimmungen. Ich suchte nach einem bestimmten Kundennamen und bekam Ergebnisse zu einem völlig anderen Thema, das zufällig ähnliche Sprache verwendete.

Was ich getan habe:

Ich bin zu QMD als Such-Backend für den Speicher gewechselt. QMD kombiniert BM25 (Stichwortabgleich) mit Vektor-Embeddings und einem Reranker. Wenn ich also nach "Charles Zahlungsfehler" suche, findet es Ergebnisse, die diese genauen Wörter enthalten, UND Ergebnisse, die semantisch verwandt sind, und ordnet sie dann nach Relevanz neu.

Ich habe auch die QMD-Pfade so konfiguriert, dass sie meinen Lernordner enthalten:

1{
2  "memory": {
3    "qmd": {
4      "paths": "paths": [
5        {
6          "path": "/Users/ramya/clawd",
7          "name": "memory-root",
8          "pattern": "MEMORY.md"
9        },
10        {
11          "path": "/Users/ramya/clawd",
12          "name": "memory-alt",
13          "pattern": "memory_alt.md"
14        },
15        {
16          "path": "/Users/ramya/clawd/memory",
17          "name": "memory-dir",
18          "pattern": "**/*.md"
19        },
20        {
21          "path": "/Users/ramya/clawd/learnings",
22          "name": "learnings",
23          "pattern": "**/*.md"
24        }
25      ]
26    }
27  }
28}

Was ich gelernt habe:

Reine semantische Suche klingt in der Theorie gut, versagt aber bei Eigennamen, spezifischen Zahlen und exakten Phrasen. Hybride Suche (Stichwörter + Vektoren + Reranking) ist für das Gedächtnis eines Agenten in der realen Welt deutlich besser. Wenn dein Agent etwas nicht finden kann, von dem du weißt, dass es in seinen Dateien ist, ist das Such-Backend wahrscheinlich der Engpass, nicht die Dateien selbst.

Tag 3: Der Agent findet es, nutzt es aber nicht

Das war der frustrierendste Tag. Ich bestätigte, dass die Suche funktionierte – ich konnte manuell abfragen und die richtigen Ergebnisse bekommen. Aber während echter Unterhaltungen rief Chiti keinen relevanten Kontext ab, obwohl er eindeutig im Speicher existierte.

Das Problem war, dass der Abruf nicht automatisch erfolgt. Der Agent muss entscheiden, zu suchen. Und wenn die Unterhaltung nicht die richtigen Hinweise auslöst, schaut er nichts nach.

Was ich getan habe:

Ich habe explizite Abrufanweisungen zur Boot-Sequenz hinzugefügt. Anstatt zu hoffen, dass der Agent bei Bedarf sucht, habe ich ihm gesagt, wann er suchen soll:

markdown

Bevor du eine Aufgabe startest:

• Durchsuche tägliche Protokolle nach verwandtem Kontext
• Überprüfe LEARNINGS.md auf Regeln für diese Art von Aufgabe
• Wenn ein Kunde erwähnt wird, suche nach seiner Historie

Ich habe auch einen Abruftest gebaut. Ich habe einen bestimmten Marker im täglichen Protokoll platziert – so etwas wie "MARKER: 2026-02-20 – Denk dran, immer den Git-Status zu überprüfen, bevor du behauptest, Code sei gepusht." Dann wartete ich, startete eine neue Sitzung und fragte: "Was war der Marker von gestern?" Wenn der Agent ihn fand, funktionierte der Abruf. Wenn nicht, war etwas kaputt.

Was ich gelernt habe:

Es gibt einen Unterschied zwischen "die Information existiert" und "der Agent nutzt die Information." Du brauchst beides. Die Suchinfrastruktur kümmert sich um den ersten Teil. Boot-Anweisungen und Abrufgewohnheiten um den zweiten. Teste beide getrennt.

Tag 4: Es kompaktierungssicher machen

Jetzt hatte ich Speicher-Flush, hybride Suche und Abrufanweisungen. Aber ich verlor weiterhin Kontext in einem bestimmten Szenario: sehr langen Sitzungen, in denen die Kompaktierung mehrmals lief.

Das Problem war, dass der Speicher-Flush nur einmal pro Kompaktierungszyklus ausgelöst wird. Wenn die Sitzung lang genug für zwei oder drei Kompaktierungen war, erhielt nur die erste die Flush-Behandlung. Alles danach war gefährdet.

Was ich getan habe:

Ich habe Kontextbereinigung so konfiguriert, dass sie mit der Kompaktierung zusammenarbeitet:

1{
2  "contextPruning": {
3    "mode": "cache-ttl",
4    "ttl": "6h",
5    "keepLastAssistants": 3
6  }
7}

Das bereinigt alten Kontext nach 6 Stunden aggressiv, während die letzten 3 Assistentenantworten erhalten bleiben. In Kombination mit dem Speicher-Flush bedeutet das, dass der Agent wichtige Dinge früh auf die Festplatte schreibt und alter Kontext bereinigt wird, bevor er zu einem Überlauf führt.

Ich habe auch ein MARKER-Testprotokoll hinzugefügt: Nach jeder größeren Konfigurationsänderung platziere ich einen Marker im täglichen Protokoll und teste den Abruf über Kompaktierungsgrenzen hinweg. Wenn der Marker überlebt, hat die Änderung funktioniert. Wenn nicht, ist etwas kaputt.

Was ich gelernt habe:

Lange Sitzungen sind der Ort, an dem Speichersysteme tatsächlich getestet werden. Kurze Unterhaltungen erreichen selten die Kompaktierung. Es sind die 2-stündigen Tiefenarbeitssitzungen, in denen du Kontext verlierst und nicht herausfinden kannst, warum. Teste dein Speichersystem unter Last, nicht nur in schnellen Chats.

Tag 5: Der System-Prompt war um 28 % aufgebläht

Das war der Tag, an dem alles zusammenkam. Ich führte /context detail aus und starrte auf die Zahlen.

Mein Agent lud 11.887 Token System-Prompt, bevor er überhaupt meine Nachricht las. 51 Fähigkeiten, von denen ich 20 nie benutzt hatte. MEMORY.md war eine 200-zeilige Firmen-Wiki, die bei jeder einzelnen Sitzung geladen wurde. Und ich hatte zwei konkurrierende Boot-Sequenzen – eine in BOOT.md (die OpenClaw nicht einmal erkennt) und eine, die 200 Zeilen tief in AGENTS.md vergraben war.

Am schlimmsten: Jedes Mal, wenn ich die Modelle wechselte, vergaß Chiti alles. Kein Übergabeprotokoll. Kein Zurückschreiben des aktuellen Kontexts. Einfach weg.

Die Ursache:

OpenClaw liest diese Dateien automatisch bei jeder neuen Sitzung: AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, HEARTBEAT.md, MEMORY.md.

Alles andere – LEARNINGS.md, tägliche Protokolle, Dokumente, Referenzdateien – muss der Agent selbst mit Tools lesen. Wenn die Anweisung, diese Dateien zu lesen, nicht in einer der automatisch geladenen Dateien (insbesondere AGENTS.md) steht, wird der Agent sie nie sehen.

Meine BOOT.md enthielt die gesamte Boot-Sequenz. Aber OpenClaw lädt BOOT.md nicht automatisch. Also saßen die Anweisungen einfach da, ungelesen, und taten nichts.

Was ich getan habe:

Ich habe eine vollständige Überprüfung und Bereinigung durchgeführt:

1. Boot-Sequenz an den Anfang von AGENTS.md verschoben (der einzige zuverlässige Ort für Startanweisungen)
2. BOOT.md gelöscht (wird von OpenClaw nicht erkannt)
3. BOOTSTRAP.md gelöscht (einmalige Onboarding-Datei, bereits abgeschlossen, verschwendet 361 Token pro Sitzung)
4. MEMORY.md von 200 Zeilen auf 90 reduziert, indem Referenzdokumente in einen docs/-Ordner verschoben wurden
5. 20 ungenutzte Marketing-Fähigkeiten entfernt, die 3.000 Token pro Sitzung fraßen
6. Schreibdisziplin hinzugefügt: jede Aufgabe protokolliert ihr Ergebnis, jeder Fehler wird zu einer Regel
7. Ein Übergabeprotokoll hinzugefügt: vor jedem Modellwechsel oder Sitzungsende schreibt der Agent den aktuellen Kontext in das tägliche Protokoll

Die Boot-Sequenz sieht jetzt so aus:

markdown

Bevor du IRGENDETWAS tust:

1. Lies USER.md
2. Lies learnings/LEARNINGS.md
3. Lies memory/YYYY-MM-DD.md (heute + gestern)
4. Lies MEMORY.md (nur in der Hauptsitzung, niemals in Gruppen)
5. Lies PROTOCOL_COST_EFFICIENCY.md
6. Gib aus: GELADEN: USER | LEARNINGS | TÄGLICH | MEMORY | PROTOCOL

Die Schreibdisziplin:

markdown

Nach jeder Aufgabe:

1. Protokolliere Entscheidung + Ergebnis → memory/YYYY-MM-DD.md
2. Bei Fehler → hänge an learnings/LEARNINGS.md an
3. Bei bedeutendem Kontext → aktualisiere MEMORY.md (nur während Heartbeat-Überprüfungen, niemals direkt während Aufgaben)

Das Übergabeprotokoll:

markdown

Vor Sitzungsende oder Modellwechsel:

Schreibe einen HANDOVER-Abschnitt in memory/YYYY-MM-DD.md:

• Was besprochen wurde
• Was entschieden wurde
• Ausstehende Aufgaben mit genauen Details
• Nächste Schritte, die noch anstehen

Ergebnisse:

• System-Prompt: 11.887 → 8.529 Token
• Fähigkeiten: 51 → 32
• Sitzungs-Token: 18.280 → 14.627
• 28 % leichter. Gleicher Agent. Gleiche Modelle. Nur weniger Rauschen.

Was ich gelernt habe:

Die eigentliche Lösung war nicht, mehr Dateien hinzuzufügen. Es war, die zu entfernen, die nichts taten. Jeder Token im System-Prompt ist Overhead, den der Agent bei jeder einzelnen Nachricht mit sich herumträgt. Ungenutzte Fähigkeiten, aufgeblähte Speicherdateien, Dateien, die das System nicht einmal liest – sie summieren sich alle still und leise.

Die Regeln, die ich am ersten Tag gerne gekannt hätte

Nach 5 Tagen des Kaputtmachens und Reparierens sind das die Regeln, die ich jedem geben würde, der das OpenClaw-Gedächtnis einrichtet:

1. Nur diese Dateien werden automatisch geladen: AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, MEMORY.md.

Alles andere braucht eine explizite Leseanweisung in AGENTS.md. Wenn es nicht in der Boot-Sequenz steht, wird der Agent es nicht sehen. BOOT.md ist in OpenClaw keine echte Sache. Ich hatte eine wochenlang. Sie hat nichts getan.

2. Die Boot-Sequenz kommt an den Anfang von AGENTS.md.

Nicht in die Mitte. Nicht ans Ende. Ganz an den Anfang. Automatisch geladene Dateien werden in den System-Prompt eingefügt, also müssen die Boot-Anweisungen das Erste sein, was der Agent verarbeitet.

3. Schreibdisziplin ist wichtiger als Lesedisziplin.

Die meisten Leute richten Dateien ein, die der Agent lesen soll, erzwingen aber nie das Zurückschreiben. Wenn der Agent keine Entscheidungen, Ergebnisse und Fehler auf der Festplatte protokolliert, existieren diese Dinge nur im Kontextfenster. Und das Kontextfenster wird kompaktiert. Zurückschreiben ist der Weg, wie temporärer Kontext zu dauerhaftem Gedächtnis wird.

4. Schreibe niemals direkt während Aufgaben in MEMORY.md.

Tägliche Protokolle sind roh und nur zum Anhängen. MEMORY.md ist kuratiertes Langzeitgedächtnis. Wenn du den Agenten alles in MEMORY.md ablegen lässt, bläht es sich innerhalb von Wochen zu einem 200-zeiligen Chaos auf. Kuratiere MEMORY.md während regelmäßiger Überprüfungen (Heartbeat oder Cron), indem du Erkenntnisse aus den letzten täglichen Protokollen destillierst. Das habe ich von einem anderen OpenClaw-Benutzer gelernt, der seinen Agenten genau dabei erwischt hat – wie er MEMORY.md mit unkuratiertem Rauschen aufblähte, bis es nutzlos war.

5. LEARNINGS.md ist die am meisten unterschätzte Datei.

Jeder Fehler, den der Agent macht, sollte zu einer einzeiligen Regel werden. "Behaupte nie, Code sei gepusht, ohne den Git-Status zu überprüfen." "Lies MEMORY.md nicht vollständig in Gruppenchats." "Bestätige immer die Zeitzone des Benutzers, bevor du etwas planst." Diese Regeln summieren sich. Nach ein paar Wochen hat dein Agent ein persönliches Betriebshandbuch, das aus seinen eigenen Fehlern aufgebaut ist.

6. Teste den Abruf, nicht nur die Speicherung.

Informationen speichern und sie abrufen sind unterschiedliche Probleme. Ich hatte Dateien, die indiziert und durchsuchbar waren, aber nie abgerufen wurden, weil der Agent nicht wusste, dass er nach ihnen suchen sollte. Platziere Marker, teste über Sitzungen hinweg, teste über Modellwechsel hinweg. Wenn der Agent nicht finden kann, was du gestern gespeichert hast, spielt die Speicherung keine Rolle.

7. Das Übergabeprotokoll ist die Lösung für den Modellwechsel.

OpenClaw-Agenten verlieren den gesamten Kontext, wenn du die Modelle wechselst. Das neue Modell startet mit einem frischen Kontextfenster – es sieht nur die automatisch geladenen Dateien. Ohne ein Übergabeprotokoll, das den aktuellen Zustand vor dem Wechsel in das tägliche Protokoll schreibt, hat das neue Modell keine Ahnung, was vor sich ging. Das war wochenlang mein größter Schmerzpunkt.

8. Führe regelmäßig /context detail aus.

Dieser Befehl zeigt genau, was deine Token frisst. Fähigkeiten, von denen du vergessen hast, dass du sie installiert hast, Dateien, die gewachsen sind, ohne dass du es bemerkt hast, Werkzeuge, die du nie benutzt. Ich habe 20 ungenutzte Fähigkeiten gefunden, die 3.000 Token pro Sitzung verbrannten. Das sind 3.000 Token Overhead bei jeder einzelnen Nachricht, für Funktionen, die ich nie angerührt hatte.

9. Hybride Suche schlägt reine semantische Suche.

BM25 (Stichwörter) + Vektoren (Bedeutung) + Reranking liefert deutlich bessere Ergebnisse als Vektoren allein. Kundennamen, spezifische Zahlen, exakte Phrasen – die semantische Suche übersieht sie. Die Stichwortsuche fängt sie ein. Verwende beide.

10. Kompaktierung ist nicht der Feind. Ungeschriebener Kontext ist es.

Ich habe tagelang gegen die Kompaktierung gekämpft, bevor ich erkannte, dass die Lösung einfacher war: Stelle sicher, dass alles Wichtige in eine Datei geschrieben wird, bevor die Kompaktierung läuft. Der Speicher-Flush erledigt das automatisch. Wenn es auf der Festplatte ist, überlebt es die Kompaktierung. Wenn es nur in der Unterhaltung ist, ist es gefährdet.

Mein aktuelles Setup

Zur Referenz, so sieht mein Arbeitsbereich jetzt aus:

workspace/

├── AGENTS.md (Boot-Sequenz + Schreibdisziplin + Übergabeprotokoll)

├── SOUL.md (Persönlichkeit und Verhalten)

├── IDENTITY.md (Name, Rolle)

├── USER.md (Besitzerinformationen)

├── TOOLS.md (Richtlinien zur Werkzeugnutzung)

├── HEARTBEAT.md (autonomes Check-in-Verhalten)

├── MEMORY.md (kuratiertes Langzeitgedächtnis, ~90 Zeilen)

├── PROTOCOL_COST_EFFICIENCY.md

├── learnings/

│ └── LEARNINGS.md (Regeln aus Fehlern)

├── memory/ (tägliche Protokolle: YYYY-MM-DD.md)

├── docs/ (Referenzdokumente aus MEMORY.md verschoben)

│ ├── tweetsmash-arch.md

│ ├── knowledge-transfer.md

│ ├── infrastructure.md

│ └── group-chat-rules.md

└── skills/ (32 Fähigkeiten, von 51 reduziert)

System-Prompt: 8.529 Token. Sitzungs-Token: 14.627 von 200.000 Kontextfenster (7,3 %). Der Agent bootet, liest, was er braucht, schreibt, was er lernt, und übergibt den Kontext vor Modellwechseln.

Es hat 5 Tage gedauert, um hierher zu kommen. Das meiste davon war, die Annahme zu verlernen, dass mehr Dateien gleich besseres Gedächtnis bedeutet. Tut es nicht. Disziplin tut es. Mein Experiment läuft noch.

Ich baue TweetSmash und LinkedMash – Social-Media-Lesezeichentools – mit meinem Mitgründer. Ich teile, was ich über den Betrieb von OpenClaw-Agenten in der Produktion auf X lerne: @code_rams