Dreischichtige Speicherarchitektur für persistente OpenClaw-Agentenkontexte

Speicherarchitektur für persistente Agentenkontexte

Ein Entwickler, der einen Multi-Agenten-OpenClaw-Betrieb für Immobilien betreibt, stieß auf persistente Kontextverluste, bei denen Agenten jede Sitzung von Null starteten und eine erneute Erklärung vorheriger Arbeiten benötigten. Dies führte zu konkreten Geschäftskosten, einschließlich Agenten, die warme Leads wie Fremde behandelten und Fristen aufgrund fehlenden Zustands verpassten.

Die Lösung ist eine 3-schichtige Speicherarchitektur, die auf der bestehenden Arbeitsbereichs- und Speicherinfrastruktur von OpenClaw aufbaut. Informationen fließen abwärts durch die Schichten und werden nie über sie hinweg dupliziert.

Schicht 1: Gehirn (Arbeitsbereichsdateien)

OpenClaw injiziert automatisch bei jedem Zugriff einen festen Satz von Arbeitsbereichsdateien als Projektkontext. Diese sieben Dateien bilden das Betriebssystem des Agenten:

• SOUL.md: Persönlichkeit, Stimme, Werte
• AGENTS.md: Rolle, Regeln, Zuständigkeit
• MEMORY.md: Was gerade aktiv ist (eine Zeile pro Eintrag, Präsens)
• USER.md: Wie der Nutzer denkt und was er braucht
• TOOLS.md: Maschinenspezifische Befehle und Workarounds
• IDENTITY.md: Name, Rolle, Kurzreferenz
• HEARTBEAT.md: Stehende Aufgaben für wiederkehrende Überprüfungen

Der Entwickler etablierte eine Budgetregel: Während OpenClaw bis zu 20.000 Zeichen pro Datei erlaubt, zielen sie auf 500-1.000 Tokens pro Datei ab, wobei das gesamte L1 unter 7.000 Tokens bleibt. Dies stellt sicher, dass Agenten tatsächlich alles lesen, anstatt aufgeblähte Dateien zu überfliegen. Ein trim-Befehl erzwingt dieses Limit.

Stabilitätsregel: Nur der Nutzer oder ein Checkpoint aktualisiert L1-Dateien. Agenten ändern nicht willkürlich ihre eigenen Regeln, mit der Ausnahme, dass MEMORY.md aktualisiert werden kann, um den aktuellen Zustand widerzuspiegeln.

Schicht 2: Speicher (semantische Suche)

Dies ist Langzeitabruf mit OpenClaws eingebautem memory_search-Tool, das semantisch über MEMORY.md und alles im memory/-Verzeichnis sucht. Wenn ein Agent nach vorheriger Arbeit, Entscheidungen oder Kontext gefragt wird, durchsucht er L2 automatisch.

Zwei Arten von Dateien befinden sich hier:

• Tägliche Notizen: memory/YYYY-MM-DD.md (OpenClaw-Konvention) mit Sitzungsverlauf, getroffenen Entscheidungen, abgeschlossener Arbeit und Korrekturen
• Brotkrümel-Dateien: memory/[themenname].md (Entwicklerergänzung) mit kuratierten Fakten, nach Situation organisiert, maximal 4 KB pro Datei, eine Tatsache pro Zeile

Jede Schlüsseltatsache in Brotkrümel-Dateien enthält einen Verweis auf L3: → Vertiefung: reference/dateiname.md. Dies schafft eine Brücke zwischen L2 und L3, sodass Agenten nicht vollständige Referenzdokumente laden müssen, nur um sich an eine relevante Tatsache zu erinnern.

Kritische Erkenntnis: Die Genauigkeit von L2 hängt vollständig davon ab, was hineingeschrieben wird. Wenn ein Agent eine Aktion ausführt und sie nicht erfasst, bevor er weitergeht, beginnt die Zustandsdatei, veraltete Informationen zurückzugeben.

Schicht 3: Referenz (bei Bedarf)

Dies ist vollständig die Ergänzung des Entwicklers, keine OpenClaw-Konvention. Ein reference/-Verzeichnis enthält tiefen Kontext: SOPs, Frameworks, Playbooks und Recherchen.

Agenten greifen bei Bedarf auf L3 zu, wenn eine spezifische Aufgabe Tiefe erfordert. Es wird absichtlich nicht von memory_search durchsucht, um zu vermeiden, Kontext mit Dingen zu belasten, die selten wichtig sind.

Der vollständige Ablauf: L1 (immer geladen) → Suche L2 (Speicher) → Öffne L3 (Referenz) bei Bedarf.