In der OpenClaw-Architektur lösen wir dieses Problem durch ein hybrides Speichersystem, das zwischen flüchtigem Arbeitsgedächtnis (RAM/Context) und persistentem Langzeitgedächtnis (Markdown/Vektoren) jongliert.
1. Die Anatomie der Erinnerung: Short-Term vs. Long-Term
Damit OpenClaw autonom agieren kann, muss es Informationen priorisieren. Wir unterteilen den Speicher technisch in drei Schichten:
| Schicht | Medium | Funktion | Haltbarkeit |
|---|---|---|---|
| Active Context | LLM Context Window | Aktueller Chat-Verlauf & Tool-Outputs | Minuten (Flüchtig) |
| Short-Term Memory | SOUL.md / SESSION.log | Aktuelle Unterziele und Zwischenstände | Stunden (Session-basiert) |
| Long-Term Memory | MEMORY.md + Vector DB | Historische Fakten, Benutzerpräferenzen | Permanent |
2. Der "Summarization-Trigger": Den Überlauf verhindern
Wenn ein Agent stundenlang in der Shell arbeitet, füllt sich das Kontextfenster (z.B. 128k Tokens bei Claude 3.5 Sonnet) rasant. Bevor das Fenster "überläuft" und das Modell beginnt, die ersten Instruktionen zu vergessen, initiiert OpenClaw einen rekursiven Kompressions-Loop:
- Token-Monitoring: Der Node.js-Core überwacht ständig die Token-Anzahl der Payload.
- Self-Summarization: Erreicht die Auslastung einen Schwellenwert (z.B. 80%), sendet der Orchestrator einen internen Prompt: "Fasse die bisherigen Erkenntnisse und den aktuellen Systemstatus prägnant zusammen.
- "The Swap: Die detaillierten Log-Daten werden aus dem aktiven Prompt entfernt und durch die kompakte Zusammenfassung ersetzt. Die Details werden gleichzeitig in die SESSION.log auf die Festplatte geschrieben.
3. Vektor-Pruning:
Relevanz durch MathematikFür das Langzeitgedächtnis nutzt OpenClaw RAG (Retrieval-Augmented Generation). Wenn der User fragt: "Wie haben wir das Problem mit dem Docker-Container vor drei Wochen gelöst?", sucht der Agent nicht linear in Textwüsten, sondern mathematisch im Vektorraum.Technisch gesehen wird jeder Textabschnitt in einen hochdimensionalen Vektor (Embedding) umgewandelt. Die Ähnlichkeit zwischen der Anfrage ($q$) und den gespeicherten Dokumenten ($d$) wird über die Cosinus-Ähnlichkeit berechnet
Das Problem:
Mit der Zeit veraltet das Wissen (Stale Data).
Die OpenClaw-Lösung (Vector-Pruning):
Der Agent führt periodisch "Gedächtnis-Audits" durch. Wenn Informationen in der MEMORY.md widersprüchlich sind (z.B. eine alte API-Dokumentation vs. eine neue), erkennt das LLM den Konflikt beim Indizieren. Es "pruned" (löscht oder archiviert) den alten Vektor-Eintrag aktiv, um die Präzision der Suchergebnisse hochzuhalten.
4. Write-Back: Die Kunst der Selbstaktualisierung
Das Herzstück ist der Tool-Call update_memory. OpenClaw schreibt seine eigene "Persönlichkeit" und Wissensbasis ständig fort.
Beispiel für einen automatisierten Workflow:
- Agent löst einen komplexen Bug in einem Python-Skript.
- Der ReAct-Loop entscheidet: "Das ist wichtig für die Zukunft."
- Aufruf: fs.writeFile('MEMORY.md', new_insight, { flag: 'a' }).
- Beim nächsten Start von OpenClaw wird diese Markdown-Datei eingelesen, vektorisiert und steht als "Erfahrung" zur Verfügung.
Dieser Prozess macht OpenClaw Local-First und Human-Readable. Du kannst jederzeit die MEMORY.md öffnen und sehen, was dein Agent über dich und seine Aufgaben gelernt hat – und es bei Bedarf manuell korrigieren.
5. Fazit: Konsistenz durch Abstraktion
Durch den intelligenten Swap zwischen flüchtigem Token-Kontext und permanenter Markdown-Vektor-Logik umgeht OpenClaw die physikalischen Grenzen heutiger LLMs. Der Agent behält seinen "Fokus" (Short-Term), ohne seine "Identität" (Long-Term) zu verlieren.