knowledge-base/wiki/architecture/memory-system.md

created	updated	sources	tags
2026-06-16	2026-06-19	other/2026-06-16_openclaw-releases-v2026.6.8.md	architecture memory knowledge-base plur1bus

Memory System Architecture

Migriert aus ByteRover context-tree (April 2026)

Schichten-Modell (4 Layer)

Layer	Name	Status
S1	Flat-File (MEMORY.md + memory/*.md) mit Tags	✅ Aktiv
S1.5	KNOWLEDGE.md — kuratierte Langzeit-Memos	⚠️ Geplant, nie implementiert
S2	OpenClaw built-in Memory (Voyage voyage-3-lite)	✅ Aktiv
S3	LanceDB Vector Store	❌ Entfernt (2026-04-06)

Tag-System (S1)

Vier Tags strukturieren die Flat-File-Erinnerungen:

• [PREF] — Präferenzen (z.B. Prefer functional over OOP)
• [FACT] — Fakten (z.B. We use PostgreSQL 15)
• [DECISION] — Architekturentscheidungen (z.B. Chose ByteRover over LanceDB)
• [ENTITY] — Personen/Systeme (z.B. Hector is the bot identity)

Evolution

1. Phase 1: Flat-Files mit Tags — funktional bis heute
2. Phase 1.5: KNOWLEDGE.md geplant, nie gebaut
3. LanceDB-Versuch: 3 Container-Resets → Datenverlust → entfernt
4. ByteRover (brv): Semantic Layer mit Voyage Embeddings → Query funktioniert, Curate blockiert durch OAuth-Token-Verlust bei Container-Reset

Siehe auch: decisions/2026-04-volume-persistence.md

Update 2026-06-16: OpenClaw v2026.6.8 Memory + State Recoveries

Mit v2026.6.8 (und z.T. v2026.6.7) hat OpenClaw mehrere Memory-relevante Fixes geliefert, die unsere S2-Schicht direkt betreffen:

QMD Memory Search: stabilisiert in transient mode

QMD (Queryable Memory Database) ist die JSON-basierte In-Memory-Suchschicht innerhalb von OpenClaws S2. Vorher konnte QMD in transient mode (z.B. während eines Reindex) komplett ausfallen — der Indexer stoppte und Fallbacks schlugen ebenfalls fehl, was zu "Memory temporarily unavailable"-Fehlern führte.

Jetzt (v2026.6.7 + v2026.6.8): QMD bleibt im transient mode verfügbar, Startup-Failures werden zusätzlich zu den Fallback-Errors reported, sodass die Fail-Recovery-Kette sichtbar wird.

Implikation für uns: Weniger Memory-Outages während intensiver Subagent- Spawns. Kein Action-Item, nur Benefit.

SQLite vermeidet WAL auf NFS State Volumes

Wenn unser State-Volume ein NFS-Mount ist (was in containerisierten Setups häufig vorkommt), hat SQLite mit WAL-Mode (Write-Ahead Log) Performance- und Locking-Probleme. OpenClaw v2026.6.8 detektiert NFS-Volumes und deaktiviert WAL automatisch in diesem Fall.

Implikation für uns: Unser bot-hector-Container läuft mit lokalem Volume (/home/node/workspace), kein NFS. Kein Action-Item, aber gut zu wissen für mögliche Cloud-Migrationen.

Oversized OpenAI embedding batches: jetzt split vor 431s

Vorher konnte ein Embedding-Request an OpenAI mit einem 431-Status ("Request Header Fields Too Large") fehlschlagen, wenn der Batch zu groß wurde. OpenClaw v2026.6.8 splittet solche Batches automatisch vor dem Send und rekonstruiert das Ergebnis.

Implikation für uns: Wir nutzen S2 (Voyage Embeddings), nicht OpenAI Embeddings — daher kein direkter Impact. Falls wir jemals auf OpenAI- Embeddings umstellen, ist die Resilience eingebaut.

Raw Memory Wiki source pages: explizit als Source Evidence

Wichtig für unser Wiki-Pattern: OpenClaw behandelt raw Memory Wiki source pages (also Wiki-Pages, die als Quelle in anderen Wiki-Pages referenziert werden) jetzt explizit als source evidence und indexiert sie korrekt. Vorher wurden sie manchmal als "malformed" markiert und von der Suche ausgeschlossen.

Implikation für uns: Genau das raw/ → wiki/-Pattern, das wir im RamaDama-Knowledge-Base praktizieren, ist damit nativ von OpenClaw unterstützt. Siehe concepts/llm/llm-knowledge-base.md für die konzeptionelle Grundlage.

Stuck-Session Recovery: Warning-Backoff wird nicht mehr resettet

Vorher konnte die Recovery-Scheduling-Warteschlange ihren Warning-Backoff bei jedem Recovery-Trigger zurücksetzen, was zu "thundering herd"-Problemen führte. Jetzt bleibt der Backoff erhalten, was die Recovery gleichmäßiger verteilt.

Implikation für uns: Kein direkter Impact auf unseren Workflow, aber verbessert die Stabilität bei vielen parallelen Sessions.

Full Memory Reindexes: Rollback/Cache Recovery preserved

Bei einem vollen Memory-Reindex gehen jetzt die Rollback-Punkte und Cache-Snapshots nicht mehr verloren. Falls der Reindex mittendrin fehlschlägt, kann auf den letzten konsistenten Stand zurückgerollt werden ohne Datenverlust.

Implikation für uns: Massiv relevant für den WMT-003-Wiki-Lint-Workflow — bei größeren Wiki-Cleanups (Stubs auflösen, Cross-Refs nachziehen) machen wir effektiv einen S2-Reindex. Mit v2026.6.8 ist dieser Prozess deutlich robuster.

Verwandte externe Ressourcen

• OpenClaw S2 (built-in Memory): siehe OpenClaw Repository und Releases v2026.6.8 (S2-Konzept im Memory-Block dokumentiert)
• QMD-Konzept: Queryable Memory Database (JSON-basiert, transient + persistent mode)
• Raw Memory Wiki source pages support in v2026.6.8

AGI-Realismus-Anwendung

Aschenbrenners „Situational Awareness" (siehe [[wiki/concepts/agi/aschenbrenner-situational-awareness]]) prognostiziert AGI bis 2027 und Superintelligenz kurz danach — mit AI-Forschung als erstem automatisierten Berufsfeld. Implikation für unser Memory-System:

• Memory-Disziplin als Differenziator: In einer Welt, in der AI-Systeme „human-equivalent" werden, ist die Qualität der Memory-Architektur (Schicht 1/2/3) der Unterschied zwischen Workhorse und System. Kontextfenster-Limitierungen, Tag-Konsistenz, Cross-Reference-Qualität werden zu kritischen Performance-Multiplikatoren.
• Wissens-Distillation vs. Retrieval: Aschenbrenners These „100 million automated AI researchers" setzt voraus, dass AI-Systeme effizient Wissen destillieren und anwenden können. Unser Karpathy-Wiki-Pattern ([[wiki/concepts/llm/llm-knowledge-base]]) ist eine Antwort darauf: kuratierte, persistente Wiki-Pages statt RAG-Retrieval.
• Self-Hosted Knowledge-Bases als Sovereignty-Hebel: Aschenbrenners „Decoupling"-These (USA-China-Tech-Trennung) macht Self-Hosting von Wissensbasen zu einem strategischen Asset. Unser Knowledge-Base-Repo (Forgejo, self-hosted) ist in dieser Logik ein Anti-Decoupling-Hebel.
• Praktische Konsequenz: Die aktuelle Arbeit an scripts/wiki-lint.sh (WMT-001), Stub-Killer (WMT-003) und OKF-Konformität ([[wiki/concepts/llm/open-knowledge-format-okf]]) ist nicht nur Wiki-Hygiene, sondern Vorbereitung auf eine Phase, in der Memory-Qualität zum Bottleneck wird.

Cross-Reference: plur1bus Gedächtnismodell (2026-06-19)

Das plur1bus Gedächtnismodell aus dem OME21-01 Debrief ist eine konzeptionelle Alternative zu Hector's Schichten-Architektur. Vergleich:

Aspekt	plur1bus	Hector (RamaDama)
Vector Store	LanceDB aktiv	S3 entfernt (2026-04-06)
Episodisches Gedächtnis	Zeitlich verknüpfte Situationen	Tag-basierte Flat-Files
Vergessen	Aktiv (Ebbinghaus-Curve)	Passiv (Dateien bleiben)
Emotionale Zustände	Ja (Agent verweigert Arbeit wenn müde)	Nein
Single Point of Truth	LanceDB	MEMORY.md + memory/*.md

Die Divergenz ist bewusst: Hector nutzt Flat-File-Simplicity für Stabilität; plur1bus exploriert das vollständige kognitive Analog. Beide Modelle ergänzen sich als Referenzpunkte im Design-Space.