Ich habe OpenClaws Standard-Markdown-Speicher entfernt und stattdessen eine Node.js/Postgres-API-Schicht erstellt

Ein Entwickler, der mit OpenClaw einen kognitiven Produktivitätsanalysator erstellt, stieß nach Wochen der Nutzung auf eine Wand mit der Standarddatei MEMORY.md. Die flache Textdatei verwandelte sich in eine Halluzinationsmaschine – der Agent erinnerte sich an veraltete API-Designs als Wahrheit und vergaß vereinbarte Systemkompromisse. Die Lösung: Deaktivieren des memory-core-Plugins und Aufbau einer deterministischen Durchsetzungsschicht.

Architekturdetails

• Datenbank: PostgreSQL mit strengen Schemata für system_architecture_rules, api_design_decisions und feature_roadmaps.
• Middleware: Node.js/Express-Backend, das OpenClaw über benutzerdefinierte Tool-Aufrufe zugänglich gemacht wird.
• Typisierte Verträge: Der Agent muss POST /memory/architecture mit einem TypeScript-validierten JSON-Payload ausführen, um Designkompromisse oder API-Routen aufzuzeichnen.
• Unveränderliche Kontextinjektion: Bei einer Abfrage ruft die Tool-Schicht exakte Zeilen aus Postgres ab und injiziert sie in das Kontextfenster, bevor der Agent argumentiert.

Ergebnisse

Die Kontextdrift sank auf absolut Null. Der Agent kann kein Datenbankschema halluzinieren, da er durch relationale Daten eingeschränkt ist. Das Aktualisieren einer Architekturregel überschreibt die alte Zeile – keine widersprüchlichen Notizen. Nachteil: ~150 ms Latenz pro Tool-Aufruf und ein Wochenende Backend-Programmierung.

Fazit

Der Entwickler argumentiert, dass Agentenspeicher kein Speicherproblem, sondern ein API-Designproblem ist. Das LLM zu zwingen, Gedanken durch strenge Tool-Grenzen zu kategorisieren, verhindert Zustandskorruption über Hunderte von Iterationen hinweg. Er erwägt, das Node-Repository als Open Source zu veröffentlichen.