Workspace Memory v2 (offline): Forschungsnotizen

Ziel: Clawd-artiger Workspace (agents.defaults.workspace, Standard ~/.openclaw/workspace), in dem „Memory” als eine Markdown-Datei pro Tag (memory/YYYY-MM-DD.md) plus ein kleiner Satz stabiler 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 Source of Truth behält, aber strukturierten Recall (Suche, Entity-Zusammenfassungen, Konfidenz-Updates) über einen abgeleiteten Index hinzufügt.

Warum etwas ändern?

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

  • „Append-only”-Journaling
  • Menschliche Bearbeitung
  • Git-gestützte Dauerhaftigkeit + Auditierbarkeit
  • Reibungsarmes Erfassen („schreib es einfach auf”)

Es ist schwach bei:

  • High-Recall-Retrieval („was haben wir zu X entschieden?”, „letztes Mal als wir Y versucht haben?”)
  • Entity-zentrierten Antworten („erzähl mir von Alice / The Castle / warelay”) ohne viele Dateien erneut zu lesen
  • Meinungs-/Präferenz-Stabilität (und Belege wenn sie sich ändert)
  • Zeitbeschränkungen („was war im Nov 2025 wahr?”) und Konfliktauflösung

Design-Ziele

  • Offline: funktioniert ohne Netzwerk; kann auf Laptop/Castle laufen; keine Cloud-Abhängigkeit.
  • Erklärbar: Abgerufene Items sollten zuordenbar sein (Datei + Position) und von Inferenz trennbar.
  • Wenig Aufwand: Tägliches Logging bleibt Markdown, kein aufwändiges Schema-Werk.
  • Inkrementell: v1 ist mit FTS allein nützlich; Semantic/Vector und Graphen sind optionale Upgrades.
  • Agent-freundlich: macht „Recall innerhalb von Token-Budgets” einfach (kleine Fakten-Bündel zurückgeben).

North-Star-Modell (Hindsight x Letta)

Zwei Teile zum Verschmelzen:

  1. Letta/MemGPT-artiger Kontroll-Loop
  • einen kleinen „Core” immer im Kontext halten (Persona + Key-User-Facts)
  • alles andere ist Out-of-Context und wird via Tools abgerufen
  • Memory-Writes sind explizite Tool-Calls (append/replace/insert), persistiert, dann nächsten Turn re-injiziert
  1. Hindsight-artiges Memory-Substrat
  • trennen was beobachtet vs. was geglaubt vs. was zusammengefasst ist
  • Retain/Recall/Reflect unterstützen
  • Konfidenz-behaftete Meinungen, die sich mit Belegen entwickeln können
  • Entity-bewusstes Retrieval + zeitliche Abfragen (auch ohne vollständige Knowledge-Graphen)

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

Kanonischer Store (git-freundlich)

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

Vorgeschlagenes Workspace-Layout:

~/.openclaw/workspace/
  memory.md                    # klein: dauerhafte Fakten + Präferenzen (core-artig)
  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 Prefs/Urteile + Konfidenz + Beleg-Verweise
    entities/
      Peter.md
      The-Castle.md
      warelay.md
      ...

Hinweise:

  • Tägliches Log bleibt tägliches Log. Kein Bedarf, es in JSON umzuwandeln.
  • Die bank/-Dateien sind kuratiert, erzeugt von Reflexionsjobs, und können trotzdem von Hand bearbeitet werden.
  • memory.md bleibt „klein + core-artig”: die Dinge, die Clawd bei jeder Session sehen soll.

Abgeleiteter Store (maschineller Recall)

Einen abgeleiteten Index unter dem Workspace hinzufügen (nicht unbedingt git-tracked):

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

Gestützt durch:

  • SQLite-Schema für Fakten + Entity-Links + Meinungs-Metadaten
  • SQLite FTS5 für lexikalischen Recall (schnell, winzig, offline)
  • Optionale Embeddings-Tabelle für semantischen Recall (weiterhin offline)

Der Index ist immer aus Markdown rekonstruierbar.

Retain / Recall / Reflect (operativer Loop)

Retain: tägliche Logs in „Fakten” normalisieren

Hindsights Schlüsselerkenntnis, die hier zählt: narrative, in sich geschlossene Fakten speichern, keine winzigen Schnipsel.

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

  • am Tagesende (oder währenddessen) einen ## Retain-Abschnitt mit 2-5 Bullets hinzufügen, die:
    • narrativ sind (Turn-übergreifender Kontext bewahrt)
    • in sich geschlossen (eigenständig später sinnvoll)
    • mit Typ + Entity-Erwähnungen getaggt

Beispiel:

## Retain
- W @Peter: Ist gerade in Marrakesch (27. Nov - 1. Dez 2025) für Andys Geburtstag.
- B @warelay: Ich habe den Baileys-WS-Crash behoben, indem ich connection.update-Handler in try/catch gewrappt habe (siehe memory/2025-11-27.md).
- O(c=0.95) @Peter: Bevorzugt knappe Antworten (<1500 Zeichen) auf WhatsApp; lange Inhalte kommen in Dateien.

Minimales Parsing:

  • Typ-Präfix: W (Welt), B (Erfahrung/biografisch), O (Meinung), S (Beobachtung/Zusammenfassung; meist generiert)
  • Entities: @Peter, @warelay usw. (Slugs mappen auf bank/entities/*.md)
  • Meinungs-Konfidenz: O(c=0.0..1.0) optional

Wenn Autoren nicht darüber nachdenken sollen: der Reflect-Job kann diese Bullets aus dem Rest des Logs ableiten, aber einen expliziten ## Retain-Abschnitt zu haben ist der einfachste „Qualitätshebel”.

Recall: Abfragen über den abgeleiteten Index

Recall sollte unterstützen:

  • Lexikalisch: „exakte Begriffe / Namen / Befehle finden” (FTS5)
  • Entity: „erzähl mir über X” (Entity-Seiten + entity-verlinkte Fakten)
  • Zeitlich: „was ist um den 27. Nov passiert” / „seit letzter Woche”
  • Meinung: „was bevorzugt Peter?” (mit Konfidenz + Belegen)

Rückgabeformat sollte agent-freundlich sein und Quellen zitieren:

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

Reflect: stabile Seiten erzeugen + Überzeugungen aktualisieren

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

  • bank/entities/*.md aus jüngsten Fakten aktualisiert (Entity-Zusammenfassungen)
  • bank/opinions.md-Konfidenz basierend auf Bestätigung/Widerspruch aktualisiert
  • optional Bearbeitungen an memory.md vorschlägt („core-artige” dauerhafte Fakten)

Meinungsentwicklung (einfach, erklärbar):

  • jede Meinung hat:
    • Aussage
    • Konfidenz c in [0,1]
    • last_updated
    • Beleg-Links (unterstützende + widersprechende Fakt-IDs)
  • wenn neue Fakten ankommen:
    • Kandidaten-Meinungen per Entity-Overlap + Ähnlichkeit finden (FTS zuerst, Embeddings später)
    • Konfidenz um kleine Deltas aktualisieren; große Sprünge erfordern starken Widerspruch + wiederholte Belege

CLI-Integration: eigenständig vs. tiefe Integration

Empfehlung: Tiefe Integration in OpenClaw, aber eine trennbare Core-Bibliothek beibehalten.

Warum in OpenClaw integrieren?

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

Warum trotzdem eine Bibliothek abtrennen?

  • Memory-Logik testbar ohne Gateway/Runtime halten
  • Wiederverwendung aus anderen Kontexten (lokale Skripte, zukünftige Desktop-App usw.)

Form: Das Memory-Tooling soll eine kleine CLI + Bibliotheksschicht 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 Teilräumen nutzt (Paper: arXiv 2411.14754, 2024).

Pragmatische Einschätzung für ~/.openclaw/workspace:

  • Nicht mit SuCo starten.
  • Mit SQLite FTS + (optionalen) einfachen Embeddings starten; die meisten UX-Gewinne kommen sofort.
  • SuCo/HNSW/ScaNN-artige Lösungen erst in Betracht ziehen wenn:
    • Corpus groß ist (Zehn-/Hunderttausende von Chunks)
    • Brute-Force-Embedding-Suche zu langsam wird
    • Recall-Qualität bedeutsam durch lexikalische Suche limitiert ist

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

  • SQLite FTS5 + Metadatenfilter (null ML)
  • Embeddings + Brute-Force (funktioniert überraschend weit wenn Chunk-Anzahl niedrig)
  • HNSW-Index (verbreitet, robust; braucht ein Library-Binding)
  • SuCo (Forschungsgrad; attraktiv wenn es eine solide Implementierung zum Einbetten gibt)

Offene Frage:

  • Was ist das beste Offline-Embedding-Modell für „persönlichen Assistenten-Memory” auf deinen Maschinen (Laptop + Desktop)?
    • Falls Ollama schon vorhanden: mit einem lokalen Modell embedden; sonst ein kleines Embedding-Modell in die Toolchain einbauen.

Kleinster nützlicher Pilot

Für eine minimale, dennoch nützliche Version:

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

Referenzen

  • Letta / MemGPT-Konzepte: „Core-Memory-Blöcke” + „Archival Memory” + tool-gesteuerte selbst-bearbeitende Memory.
  • Hindsight Technical Report: „Retain / Recall / Reflect”, Vier-Netzwerk-Memory, narrative Faktenextraktion, Meinungs-Konfidenz-Evolution.
  • SuCo: arXiv 2411.14754 (2024): „Subspace Collision” approximiertes Nearest-Neighbor-Retrieval.
arrow_back
Zurück
Session Binding Channel Agnostic
Weiter
Model Config
arrow_forward