OpenClaw Native Memory richtig einrichten: Agents, die sich wirklich erinnern
Das Problem mit zustandslosen Agenten
Ein Tweet von heute Morgen bringt es auf den Punkt:
> *"OpenClaw with native memory is a different experience. When memory sits inside the context flow, agents can actually carry forward work instead of starting over each time."*
470 Impressionen, 4 Likes, 3 Bookmarks in unter 10 Minuten. Das trifft einen Nerv.
Der Grund: Die meisten OpenClaw-Installationen laufen noch zustandslos. Jede Session beginnt von vorne. Der Agent weiß nicht, was gestern besprochen wurde, vergisst Präferenzen nach einem Neustart, und jede neue Konversation ist Blindflug. Das ist nicht der Zustand, für den OpenClaw gebaut wurde — es ist der Zustand, in dem die meisten Installationen steckenbleiben, weil das Memory-System nirgendwo klar dokumentiert ist.
Diese Anleitung schließt diese Lücke.
---
Wie OpenClaw Memory funktioniert (die Architektur)
OpenClaw's Gedächtnissystem ist dateibasiert. Das klingt primitiv — ist aber ein Feature, kein Bug. Dateien sind:
Die Struktur ist einfach:
```
~/.openclaw/workspace/
├── MEMORY.md # Langzeitgedächtnis — kuratiert, dicht
├── SOUL.md # Identität und Regeln
├── USER.md # Wer nutzt den Agenten
├── AGENTS.md # Workspace-Regeln (wird bei jedem Start geladen)
├── HEARTBEAT.md # Aktive Aufgaben / Erinnerungen
└── memory/
├── 2026-03-28.md # Tagesnotizen (wird täglich angelegt)
├── 2026-03-27.md
└── heartbeat-state.json
```
Diese Dateien werden vom Agenten gelesen, geschrieben und gepflegt — nicht von dir. Du legst die Struktur an, der Agent füllt sie.
---
Schritt 1: Die Basis anlegen
Falls noch nicht vorhanden:
```bash
mkdir -p ~/.openclaw/workspace/memory
# MEMORY.md anlegen
cat > ~/.openclaw/workspace/MEMORY.md << 'EOF'
# Long-Term Memory
_This file is maintained by the agent. Do not overwrite unless intentional._
Key Facts
Decisions
Preferences
EOF
# Tagesnotiz anlegen
touch ~/.openclaw/workspace/memory/$(date +%Y-%m-%d).md
```
Das war's für die Struktur. Jetzt das Entscheidende: dem Agenten sagen, wie er sie nutzen soll.
---
Schritt 2: AGENTS.md — die Spielregeln
Das ist der häufigste Fehler bei OpenClaw-Memory-Setups: MEMORY.md existiert, aber der Agent weiß nicht, wann er sie schreiben soll.
In `AGENTS.md` (oder deiner Hauptanweisung an den Agenten) musst du explizit festlegen:
```markdown
Memory Rules
Tägliche Notizen: memory/YYYY-MM-DD.md
MEMORY.md — Langzeitgedächtnis
Memory-Regeln
```
Ohne diese Regeln weiß der Agent nicht, ob er Memory schreiben soll oder nicht. Mit ihnen beginnt er automatisch, alles zu protokollieren.
---
Schritt 3: Der Session-Ablauf — wie Memory im Kontext fließt
OpenClaw lädt bei Session-Start die Workspace-Dateien. Damit Memory funktioniert, muss der Agent wissen, was er wann laden soll.
Die korrekte Priorität:
```
Session-Start:
1. SOUL.md lesen → Wer bin ich?
2. USER.md lesen → Wen helfe ich?
3. memory/heute.md → Was ist heute passiert?
4. memory/gestern.md → Was war gestern relevant?
5. MEMORY.md → Nur in Hauptsessions (nicht in Gruppen/Discord)
Während der Session:
- memory_search() für spezifische Erinnerungen aufrufen
- memory/heute.md nach wichtigen Ereignissen aktualisieren
Session-Ende / relevanter Moment:
- MEMORY.md mit kuratierten Langzeiterkenntnissen aktualisieren
```
Der Schlüssel: MEMORY.md wird nicht bei jedem Turn geladen — nur bei Session-Start, in Hauptsessions. Das verhindert Context Bloat.
---
Schritt 4: memory_search — der unterschätzte Superkraft
Das Memory-System wäre halb so gut ohne `memory_search`. Statt alle Dateien in den Kontext zu laden, sucht der Agent semantisch:
```
# Statt: alle daily files einlesen (100.000+ Token)
# So: nur relevante Snippets holen (~500 Token)
memory_search("was haben wir letzten Monat über Deployment entschieden?")
→ Gibt top 3-5 relevante Stellen zurück, mit Dateipfad und Zeilennummer
```
Das ist der Unterschied zwischen einem Agenten, der alles weiß, und einem Agenten, der weiß, wo er nachschauen muss. Letzteres skaliert — ersteres nicht.
Tipp: Wenn du in MEMORY.md oder Tagesnotizen schreibst, verwende klare, suchbare Formulierungen:
```markdown
# Gut (leicht findbar):
Entscheidung 2026-03-15: Wir verwenden Convex statt Supabase für alle neuen Projekte.
# Schlecht (nicht findbar):
Wir haben das heute final geklärt.
```
---
Schritt 5: HEARTBEAT.md — Kontinuität zwischen Sessions
HEARTBEAT.md ist das Bindeglied zwischen Sessions. Es ist nicht für Langzeitgedächtnis — das ist MEMORY.md. Es ist für das, was gerade passiert:
```markdown
# HEARTBEAT.md — Active Context
Laufende Projekte
Heute noch zu tun
Offene Fragen
```
Der Agent liest HEARTBEAT.md bei jedem Heartbeat-Poll (default: alle 30 Minuten). So bleiben laufende Tasks auch nach Neustarts sichtbar — ohne dass du sie erneut erklären musst.
Haltung: HEARTBEAT.md klein halten. Wenn eine Aufgabe erledigt ist, raus damit. Wenn etwas wichtig genug ist für Langzeitgedächtnis, gehört es in MEMORY.md.
---
Schritt 6: Heartbeat-State — was wurde wann geprüft
Damit der Agent nicht bei jedem Heartbeat alles prüft (E-Mails, Kalender, Wetter — das wäre API-Verschwendung), trackt er in `memory/heartbeat-state.json`, was wann zuletzt geprüft wurde:
```json
{
"lastChecks": {
"email": 1743124800,
"calendar": 1743110400,
"weather": null,
"twitter": 1743118200
},
"lastActive": 1743124900
}
```
Mit dieser Datei entscheidet der Agent selbst: "E-Mail wurde vor 47 Minuten geprüft, das reicht. Kalender wurde vor 4 Stunden geprüft, das sollte ich nochmal anfassen." Keine redundanten API-Calls, kein Raten.
---
Das Zusammenspiel: Vollständiger Memory-Lifecycle
Um es konkret zu machen — so sieht ein Tag mit vollem Memory-Setup aus:
08:30 Uhr — Erste Session:
10:00 Uhr — Task abgeschlossen:
14:00 Uhr — Du fragst nach einer Entscheidung von letzter Woche:
18:00 Uhr — Session-Ende:
Nächsten Morgen:
---
Häufige Fehler und wie du sie vermeidest
Fehler 1: MEMORY.md unkontrolliert wachsen lassen
MEMORY.md ist Langzeitgedächtnis, kein Tagebuch. Wenn sie über 1.500 Wörter wächst, leidet die Qualität. Lass den Agenten regelmäßig aufräumen — oder tu es selbst mit einem Monatscron.
Fehler 2: Memory in Discord/Gruppen-Chats laden
MEMORY.md enthält persönliche Informationen. Sie darf nicht in Gruppen-Chats, Discord-Kanälen oder anderen geteilten Kontexten geladen werden. Nur in deiner direkten Hauptsession. Das steht so in AGENTS.md — stelle sicher, dass die Regel dort drin steht.
Fehler 3: "Mental Notes" statt Datei-Updates
Wenn du sagst "merke dir, dass wir nächste Woche Stripe-Webhook upgraden", und der Agent sagt "notiert" — aber nichts schreibt — ist das eine "mental note". Sie überlebt den Neustart nicht. Teste es: Sag dem Agenten etwas Spezifisches, starte ihn neu, frag danach. Wenn er es nicht weiß, schreibt er es nicht auf.
Fehler 4: Memory-Suche nicht nutzen
Viele Setups laden MEMORY.md + alle täglichen Notizen blind in den Kontext. Das erzeugt Context Bloat. Nutze memory_search stattdessen — es gibt dir präzisere Antworten mit einem Bruchteil der Token.
---
Zusammenfassung
OpenClaw mit nativem Gedächtnis braucht keine externe Datenbank, kein Vector-Store, keine Embeddings-Pipeline. Es braucht:
1. Die richtigen Dateien (MEMORY.md, memory/YYYY-MM-DD.md, HEARTBEAT.md)
2. Klare Regeln in AGENTS.md, wann was gelesen und geschrieben wird
3. Disziplin beim Schreiben (suchbar formulieren, veraltet entfernen)
4. memory_search statt blind laden
Das Ergebnis ist ein Agent, der tatsächlich eine Arbeitsbeziehung mit dir aufbaut — der sich erinnert, wer du bist, was gerade läuft und was letzte Woche entschieden wurde. Das ist kein Feature-Add-On. Das ist der Unterschied zwischen einem Werkzeug und einem Mitarbeiter.
Die vollständige Konfiguration — alle Dateien, alle Regeln, das vollständige 6-Agenten-Setup — ist im OpenClaw Setup Playbook dokumentiert.
Auch vollständig auf Englisch verfügbar. 🇬🇧