Nocturne Memory: ein MCP-Server, der Agenten-Gedächtnis in SQLite oder PostgreSQL legt

Das Problem: Kontext, der mit jeder Sitzung neu aufgebaut wird

Ein MCP-Agent startet jede Sitzung ohne Gedächtnis. Was in der vorherigen Unterhaltung besprochen wurde, ist weg, sobald der Kontext geschlossen wird. Die übliche Antwort darauf ist Vector RAG: Textstücke werden eingebettet und über Ähnlichkeitssuche zurückgeholt. Nocturne Memory geht einen anderen Weg und speichert Erinnerungen als strukturierte, adressierbare Knoten in einer Datenbank, die der Agent über MCP-Werkzeuge liest und schreibt. Das README formuliert die Zielgruppe selbst: Nutzer, die denselben Agenten über Claude, Gemini, GPT oder ein lokales Modell hinweg weiterführen wollen. Der Speicher liegt außerhalb des Modells, also bleibt er beim Modellwechsel erhalten. Genau das ist der Kern des Projekts, und es ist eine andere Aufgabe als die, die ein Vektorindex löst.

Wie der Speicher aufgebaut ist: Boot-Knoten, Pfade, Namespaces

Die Beispiele im README zeigen das Datenmodell recht deutlich. Erinnerungen haben Pfade wie system://boot, core://work_jobstation/commercialization oder core://salem/survival_state. Der Agent ruft beim Sitzungsstart read_memory("system://boot") auf und lädt damit nur die als Kern markierten Einträge. Alles Weitere kommt über search_memory oder gezieltes read_memory auf einen bekannten Pfad nach. Das ist der Mechanismus hinter der Token-Aussage im README: nicht alles wird geladen, sondern ein kleiner Einstiegspunkt plus bedarfsgesteuerte Nachladung. Die Dokumentation nennt dazu eine Zahl aus einem konkreten Speicher: bei 969.000 Zeichen Gesamtbestand lädt die erste Nachricht 7,2K Zeichen. Das ist eine Angabe des Projekts zu einem eigenen Bestand, keine allgemeine Messung, und sie hängt stark davon ab, wie der Boot-Knoten gepflegt wird. Zusätzlich unterstützt der Server Namespace-Isolation, sodass mehrere Personen oder Agenten getrennte Speicherräume erhalten. Der Speicher läuft auf SQLite oder PostgreSQL, je nach Konfiguration.

Rollback als eigentliches Unterscheidungsmerkmal

Interessanter als die Pfadstruktur ist die Versionierung. Das README beschreibt ein Review-Dashboard mit visuellem Diff, in dem Änderungen akzeptiert oder zurückgerollt werden können, sowie automatische Sicherungen vor jeder Operation des Agenten. Aufräumvorgänge müssen laut README von einem Menschen bestätigt werden. Das adressiert ein Problem, das Vektoransätze strukturell schlecht lösen: dort ist schwer nachvollziehbar, welcher Eintrag wann hinzugefügt wurde und was eine Löschung mit sich zieht. Ein Pfadbaum mit Versionen erlaubt dagegen, einen einzelnen Knoten zurückzusetzen, ohne den Rest anzufassen. Wer schon einmal erlebt hat, wie ein Agent eine falsche Annahme über sich selbst in den Speicher schreibt und sie danach bei jeder Sitzung mitliest, erkennt den Wert davon sofort. Die Kehrseite: Der Agent braucht Disziplin beim Schreiben. Ein sauberes Rollback hilft nur, wenn jemand die Änderungen auch durchsieht, und das Dashboard ist eine Oberfläche, die jemand bedienen muss.

Installation: zwei Befehle, dann die Client-Konfiguration

Die Einrichtung ist knapp beschrieben. Vorausgesetzt werden Python 3.10 oder neuer und Node.js, wobei Node nur beim ersten Start gebraucht wird, um das Dashboard-Frontend zu bauen. Danach folgen zwei Schritte: git clone https://github.com/Dataojitori/nocturne_memory.git, dann cd nocturne_memory, dann pip install -r backend/requirements.txt. Der zweite Schritt ist die MCP-Konfiguration im jeweiligen Client. Hier gibt es eine Stolperstelle, die das README ausdrücklich benennt: Bei Antigravity muss das Argument auf backend/mcp_wrapper.py zeigen, weil sonst ein CRLF-Problem unter Windows auftritt. Bei allen anderen Clients zeigt es auf backend/mcp_server.py. Wer die Konfiguration falsch herum einträgt, bekommt einen Server, der startet und trotzdem keine Werkzeuge bereitstellt. Für einen schnellen Test ohne eigene Installation bietet das Projekt eine öffentliche Demo unter https://misaligned.top/mcp an, die im Codex-Fall über einen Eintrag [mcp_servers.nocturne_memory_demo] mit url in .codex/config.toml eingebunden wird. Diese Demo ist laut README schreibgeschützt und stellt nur read_memory und search_memory bereit.

Wo das Konzept an Grenzen stößt

Der Ansatz verlangt, dass der Agent weiß, wonach er suchen muss. Ein Vektorindex findet thematisch Verwandtes auch dann, wenn die Suchanfrage andere Wörter benutzt. Ein Pfadbaum tut das nicht: search_memory muss den passenden Begriff treffen, sonst bleibt der Knoten unentdeckt. In den README-Beispielen funktioniert das, weil der Nutzer den Projektnamen oder den Personennamen nennt und der Agent daraus einen Suchbegriff ableitet. Bei vagen Fragen ohne solchen Anker ist der Abruf schwächer als bei einer Ähnlichkeitssuche. Zweitens ist der Speicher nur so gut wie seine Struktur. Wer Knoten anlegt, ohne über Pfade und Hierarchie nachzudenken, bekommt einen flachen Haufen mit URLs davor. Drittens: Die Beispiele im README stammen aus einem sehr persönlichen Anwendungsfall, in dem ein Agent über Monate eine Identität aufbaut. Das ist die Stärke des Projekts, aber es sagt wenig darüber, ob der Server für einen Team-Agenten taugt, der Fakten über Produkte und Tickets sammeln soll. Dafür wäre ein Vektorindex mit Metadatenfilter womöglich der direktere Weg. Wer den Speicher zudem mehrfach parallel beschreibt, sollte klären, wie sich konkurrierende Schreibvorgänge auf denselben Knoten verhalten. Das Material äußert sich dazu nicht.

Alternative: Chroma oder pgvector mit Embeddings

Die naheliegende Alternative ist ein Vektorspeicher wie Chroma oder pgvector, in den ein Agent Textstücke mit Embeddings schreibt und per Ähnlichkeitssuche zurückholt. Der Unterschied liegt nicht in der Datenbank, sondern im Abrufweg. Ein Vektorspeicher braucht keinen vom Agenten gepflegten Pfad und keine Strukturentscheidung im Voraus; er ordnet Anfragen nach Nähe im Embedding-Raum. Dafür lässt sich ein einzelner Eintrag kaum sauber korrigieren, weil die Einheit das Textstück ist und nicht der adressierbare Knoten. Ein Rollback auf einen früheren Stand des gesamten Gedächtnisses ist bei pgvector über Tabellenversionierung nachbaubar, aber nicht Teil des Standardvorgehens, und ein Diff über Änderungen an einer Persona gibt es dort nicht. Nocturne Memory tauscht also Abrufkomfort gegen Kontrolle und Nachvollziehbarkeit. Wer die Kontrolle nicht ausübt, verliert beides.

Wartung, Lizenz und was das für den Betrieb bedeutet

Das Projekt steht unter MIT-Lizenz. Das erlaubt kommerzielle Nutzung und Änderungen, solange der Lizenztext und der Urheberrechtshinweis erhalten bleiben. Für eine lokale Instanz mit SQLite entstehen dadurch keine weiteren Pflichten. Wer den Server jedoch als gehosteten Dienst mit der Demo-URL als Vorbild betreibt, sollte die Bedingungen der MIT-Lizenz nicht mit einer Betriebs- oder Supportzusage verwechseln: es gibt keine. Die Release-Historie zeigt drei Einträge innerhalb weniger Monate, darunter 2.5.6 mit dem Titel MCP 2.0 Compatibility & Long-Form Improvements und 2.5.2, das unter anderem chinesische Sprachunterstützung brachte. Das deutet auf aktive Pflege hin, aber auch auf eine bewegliche Zielscheibe: Wer die MCP-Spezifikation mitzieht, muss den Server mitziehen. Der Upgrade-Aufwand liegt weniger im Code als in der Datenhaltung. Ein Schemawechsel an den Knoten oder an den Boot-Konventionen trifft den gesamten gespeicherten Bestand, und das ist der Teil, der sich nicht einfach neu installieren lässt. Vor einem Versionssprung ist deshalb ein Blick in die Release Notes und ein Backup der Datenbank die günstigere Reihenfolge.

Redaktionelles Fazit

Sinnvoll ist Nocturne Memory für Nutzer, die denselben Agenten über mehrere MCP-Clients hinweg betreiben und den Speicher selbst kontrollieren wollen. Wer nur innerhalb einer Plattform arbeitet, bekommt dort meist schon ein Gedächtnis und braucht diesen Server nicht. Vor dem Produktiveinsatz zu prüfen: ob die eigene Python-Version 3.10 oder höher ist, ob der Client stdio oder SSE spricht, ob der Wrapper backend/mcp_wrapper.py oder backend/mcp_server.py eingetragen werden muss, und wie das Verhalten bei mehreren gleichzeitigen Schreibzugriffen auf denselben Knoten aussieht. Diese letzte Frage beantwortet das vorliegende Material nicht.

Offizielle Quellen

1. Dataojitori/nocturne_memory on GitHub
2. License: MIT
3. Project website
4. README
5. Releases