Workspace Memory v2 (offline): Forschungsnotizen

Ziel: Ein Clawd-Style Workspace (agents.defaults.workspace, Standard: ~/.openclaw/workspace), in dem “Memory” als eine Markdown-Datei pro Tag (memory/YYYY-MM-DD.md) plus ein paar stabile Dateien (z. B. memory.md, SOUL.md) gespeichert wird.

Dieses Dokument schlägt eine offline-first Memory-Architektur vor, die Markdown als kanonische, überprüfbare Quelle beibehält, aber strukturiertes Abrufen (Suche, Entity-Zusammenfassungen, Konfidenz-Updates) über einen abgeleiteten Index hinzufügt.

Warum ändern?

Das aktuelle Setup (eine Datei pro Tag) ist hervorragend für:

  • “Append-only” Journaling
  • Manuelles Bearbeiten
  • Git-basierte Dauerhaftigkeit + Nachvollziehbarkeit
  • Reibungslose Erfassung (“einfach aufschreiben”)

Es ist schwach bei:

  • High-Recall-Abruf (“was haben wir über X entschieden?”, “letztes Mal als wir Y versucht haben?”)
  • Entity-zentrierte Antworten (“erzähl mir über Alice / The Castle / warelay”) ohne viele Dateien neu zu lesen
  • Meinungs-/Präferenz-Stabilität (und Nachweis, wenn sie sich ändert)
  • Zeitliche Einschränkungen (“was war im November 2025 wahr?”) und Konfliktlösung

Design-Ziele

  • Offline: Funktioniert ohne Netzwerk; kann auf Laptop/Castle laufen; keine Cloud-Abhängigkeit.
  • Erklärbar: Abgerufene Elemente sollten zuordenbar sein (Datei + Position) und von Inferenz trennbar.
  • Low ceremony: Tägliches Logging bleibt Markdown, keine aufwändige Schema-Arbeit.
  • Inkrementell: v1 ist nützlich nur mit FTS; semantische/Vektor- und Graph-Features sind optionale Upgrades.
  • Agent-freundlich: Macht “Abruf innerhalb von Token-Budgets” einfach (gibt kleine Fakten-Bündel zurück).

North Star Modell (Hindsight × Letta)

Zwei Teile zum Kombinieren:

  1. Letta/MemGPT-Style Control Loop
  • Halte einen kleinen “Core” immer im Context (Persona + wichtige User-Fakten)
  • Alles andere ist out-of-context und wird über Tools abgerufen
  • Memory-Schreibvorgänge sind explizite Tool-Aufrufe (append/replace/insert), persistiert, dann im nächsten Turn wieder eingefügt
  1. Hindsight-Style Memory Substrate
  • Trenne was beobachtet vs. geglaubt vs. zusammengefasst wird
  • Unterstütze retain/recall/reflect
  • Konfidenz-tragende Meinungen, die sich mit Beweisen entwickeln können
  • Entity-bewusstes Abrufen + temporale Abfragen (auch ohne vollständige Knowledge Graphs)

Vorgeschlagene Architektur (Markdown Source-of-Truth + abgeleiteter Index)

Kanonischer Speicher (git-freundlich)

Behalte ~/.openclaw/workspace als kanonischen, menschenlesbaren Memory.

Vorgeschlagenes Workspace-Layout:

~/.openclaw/workspace/
  memory.md                    # klein: dauerhafte Fakten + Präferenzen (core-ish)
  memory/
    YYYY-MM-DD.md              # tägliches Log (append; narrativ)
  bank/                        # "typisierte" Memory-Seiten (stabil, überprüfbar)
    world.md                   # objektive Fakten über die Welt
    experience.md              # was der Agent getan hat (Ich-Perspektive)
    opinions.md                # subjektive Präferenzen/Urteile + Konfidenz + Beweis-Pointer
    entities/
      Peter.md
      The-Castle.md
      warelay.md
      ...

Hinweise:

  • Tägliches Log bleibt tägliches Log. Keine Notwendigkeit, es in JSON umzuwandeln.
  • Die bank/-Dateien sind kuratiert, werden durch Reflection-Jobs erzeugt und können trotzdem manuell bearbeitet werden.
  • memory.md bleibt “klein + core-ish”: die Dinge, die Clawd in jeder Session sehen soll.

Abgeleiteter Speicher (Machine Recall)

Füge einen abgeleiteten Index unter dem Workspace hinzu (muss nicht unbedingt in Git getrackt werden):

~/.openclaw/workspace/.memory/index.sqlite

Unterstützt durch:

  • SQLite-Schema für Fakten + Entity-Links + Meinungs-Metadaten
  • SQLite FTS5 für lexikalisches Abrufen (schnell, winzig, offline)
  • Optionale Embeddings-Tabelle für semantisches Abrufen (trotzdem offline)

Der Index ist immer aus Markdown neu aufbaubar.

Retain / Recall / Reflect (operativer Loop)

Retain: Normalisiere tägliche Logs in “Fakten”

Hindsights wichtigste Erkenntnis, die hier zählt: Speichere narrative, in sich geschlossene Fakten, keine winzigen Schnipsel.

Praktische Regel für memory/YYYY-MM-DD.md:

  • Am Ende des Tages (oder währenddessen) füge einen ## Retain-Abschnitt mit 2–5 Bullets hinzu, die:
    • narrativ sind (Cross-Turn-Context erhalten)
    • in sich geschlossen sind (standalone ergibt später Sinn)
    • mit Typ + Entity-Erwähnungen getaggt sind

Beispiel:

## Retain
- W @Peter: Currently in Marrakech (Nov 27–Dec 1, 2025) for Andy's birthday.
- B @warelay: I fixed the Baileys WS crash by wrapping connection.update handlers in try/catch (see memory/2025-11-27.md).
- O(c=0.95) @Peter: Prefers concise replies (<1500 chars) on WhatsApp; long content goes into files.

Minimales Parsing:

  • Typ-Präfix: W (world), B (experience/biographical), O (opinion), S (observation/summary; meist generiert)
  • Entities: @Peter, @warelay, etc (Slugs mappen zu bank/entities/*.md)
  • Meinungs-Konfidenz: O(c=0.0..1.0) optional

Wenn du nicht willst, dass Autoren darüber nachdenken: Der Reflect-Job kann diese Bullets aus dem Rest des Logs ableiten, aber ein expliziter ## Retain-Abschnitt ist der einfachste “Qualitätshebel”.

Recall: Abfragen über den abgeleiteten Index

Recall sollte unterstützen:

  • lexikalisch: “finde exakte Begriffe / Namen / Befehle” (FTS5)
  • entity: “erzähl mir über X” (Entity-Seiten + Entity-verlinkte Fakten)
  • temporal: “was ist um den 27. November passiert” / “seit letzter Woche”
  • opinion: “was bevorzugt Peter?” (mit Konfidenz + Beweisen)

Das Rückgabeformat sollte Agent-freundlich sein und Quellen zitieren:

  • kind (world|experience|opinion|observation)
  • timestamp (Quelltag oder extrahierter Zeitbereich, falls vorhanden)
  • entities (["Peter","warelay"])
  • content (das narrative Faktum)
  • source (memory/2025-11-27.md#L12 etc)

Reflect: Erzeuge stabile Seiten + aktualisiere Überzeugungen

Reflection ist ein geplanter Job (täglich oder Heartbeat ultrathink), der:

  • bank/entities/*.md aus aktuellen Fakten aktualisiert (Entity-Zusammenfassungen)
  • bank/opinions.md Konfidenz basierend auf Verstärkung/Widerspruch aktualisiert
  • optional Bearbeitungen zu memory.md vorschlägt (“core-ish” dauerhafte Fakten)

Meinungs-Evolution (einfach, erklärbar):

  • Jede Meinung hat:
    • Statement
    • Konfidenz c ∈ [0,1]
    • last_updated
    • Beweis-Links (unterstützende + widersprechende Fakten-IDs)
  • Wenn neue Fakten ankommen:
    • Finde Kandidaten-Meinungen durch Entity-Überlappung + Ähnlichkeit (FTS zuerst, Embeddings später)
    • Aktualisiere Konfidenz durch kleine Deltas; große Sprünge erfordern starken Widerspruch + wiederholte Beweise

CLI-Integration: Standalone vs. tiefe Integration

Empfehlung: Tiefe Integration in OpenClaw, aber behalte eine trennbare Core-Library.

Warum in OpenClaw integrieren?

  • OpenClaw kennt bereits:
    • Den Workspace-Pfad (agents.defaults.workspace)
    • Das Session-Modell + Heartbeats
    • Logging + Troubleshooting-Patterns
  • Du willst, dass der Agent selbst die Tools aufruft:
    • openclaw memory recall "…" --k 25 --since 30d
    • openclaw memory reflect --since 7d

Warum trotzdem eine Library abtrennen?

  • Halte Memory-Logik testbar ohne Gateway/Runtime
  • Wiederverwendung aus anderen Kontexten (lokale Scripts, zukünftige Desktop-App, etc.)

Form: Das Memory-Tooling soll eine kleine CLI + Library-Schicht sein, aber das ist nur explorativ.

”S-Collide” / SuCo: Wann es verwenden (Forschung)

Falls “S-Collide” sich auf SuCo (Subspace Collision) bezieht: Es ist ein ANN-Retrieval-Ansatz, der starke Recall/Latenz-Tradeoffs anstrebt, indem er gelernte/strukturierte Kollisionen in Subspaces nutzt (Paper: arXiv 2411.14754, 2024).

Pragmatischer Ansatz für ~/.openclaw/workspace:

  • Starte nicht mit SuCo.
  • Starte mit SQLite FTS + (optional) einfachen Embeddings; du bekommst die meisten UX-Gewinne sofort.
  • Erwäge SuCo/HNSW/ScaNN-Klasse-Lösungen erst, wenn:
    • Das Corpus groß ist (Zehntausende/Hunderttausende von Chunks)
    • Brute-Force-Embedding-Suche zu langsam wird
    • Recall-Qualität bedeutend durch lexikalische Suche gebremst wird

Offline-freundliche Alternativen (in steigender Komplexität):

  • SQLite FTS5 + Metadaten-Filter (null ML)
  • Embeddings + Brute Force (funktioniert überraschend weit, wenn Chunk-Count niedrig ist)
  • HNSW-Index (verbreitet, robust; braucht ein Library-Binding)
  • SuCo (Forschungsgrad; attraktiv, wenn es eine solide Implementierung gibt, die du einbetten kannst)

Offene Frage:

  • Was ist das beste Offline-Embedding-Modell für “Personal Assistant Memory” auf deinen Maschinen (Laptop + Desktop)?
    • Falls du bereits Ollama hast: Embedde mit einem lokalen Modell; ansonsten liefere ein kleines Embedding-Modell in der Toolchain mit.

Kleinstes nützliches Pilot-Projekt

Wenn du eine minimale, trotzdem nützliche Version willst:

  • Füge bank/-Entity-Seiten und einen ## Retain-Abschnitt in täglichen Logs hinzu.
  • Nutze SQLite FTS für Recall mit Zitaten (Pfad + Zeilennummern).
  • Füge Embeddings nur hinzu, wenn Recall-Qualität oder Skalierung es erfordert.

Referenzen

  • Letta / MemGPT-Konzepte: “Core Memory Blocks” + “Archival Memory” + Tool-getriebenes selbst-editierendes Memory.
  • Hindsight Technical Report: “retain / recall / reflect”, Four-Network-Memory, narrative Faktenextraktion, Meinungs-Konfidenz-Evolution.
  • SuCo: arXiv 2411.14754 (2024): “Subspace Collision” Approximate Nearest Neighbor Retrieval.