Cross-Session-Memory für KI-Agenten: Mem0, SQLite oder ein eigener ONNX-Server?

English version

Neben einem MCP-Server für Zotero nutze ich für KI-Coding-Agenten wie Kimi Code noch einen zweiten, thematisch eigenständigen MCP-Server: ein sitzungsübergreifendes Gedächtnis. Beide Bausteine ergänzen sich, sind aber unabhängig voneinander einsetzbar. Dieser Beitrag dokumentiert, welche Alternativen ich geprüft habe, wofür ich mich entschieden habe und warum.

Ausgangslage: welche Memory-Dateien gibt es schon?

Kimi Code liest bei jedem Start drei Arten von Memory-Dateien:

Diese Dateien funktionieren gut für explizite, langfristige Regeln. Sie sind aber schwach bei zwei Dingen:

1. Unstrukturierte oder halbstrukturierte Informationen – zum Beispiel: „Vor drei Wochen hat der Nutzer erwähnt, dass er X bevorzugt.” Solche Fakten müssen manuell in die richtige Markdown-Datei eingepflegt werden.
2. Wiederfinden über viele Sitzungen hinweg – Wenn Informationen in MEMORY.md verstreut sind, müssen sie beim Start alle gelesen oder gezielt durchsucht werden. Bei wachsendem Umfang wird das ineffizient.

Was war das Problem?

Trotz der Memory-Dateien blieb das sitzungsübergreifende Gedächtnis begrenzt, weil:

• nicht jede Information manuell in eine Markdown-Datei eingetragen wird,
• die Suche in statischen Dateien nicht semantisch ist,
• der Kontext einer laufenden Sitzung komprimiert wird – dabei können Details verloren gehen, die nicht in den Memory-Dateien stehen.

Geprüfte Alternativen

1. Nur Markdown-Dateien weiter ausbauen

Das Einfachste: mehr Dateien, bessere Struktur, längere MEMORY.md.

• Vorteil: keine Installation, vollständig transparent, versionskontrollierbar.
• Nachteil: manuelle Pflege, keine semantische Suche, schlechte Skalierbarkeit.

2. Mem0 / OpenMemory MCP-Server

Mem0 ist ein bekannter Memory-Dienst für KI-Agenten.

• Problem: Der offizielle mem0-mcp ist archiviert und cloud-lastig. Ein lokaler OpenMemory-Branch war nicht mehr auffindbar – nur Weiterleitungen in der Dokumentation.
• Fazit: nicht für einen rein lokalen, offline-fähigen Betrieb geeignet.

3. Eigener SQLite-Server ohne Embeddings

Eine einfache Datenbank mit Volltextsuche.

• Vorteil: schlank, offline, schnell.
• Nachteil: keine semantische Suche; man müsste exakte Schlüsselwörter kennen.

4. Memory-MCP-Server mit PyTorch / Transformers

Ein eigener Python-Server mit fastmcp + sentence-transformers + sqlite-vec.

• Vorteil: lokale Embeddings, semantische Suche, vollständig offline.
• Nachteil: Die Python-Umgebung allein benötigte ca. 1,4 GB. Nach temporären Dateien blieben nur noch ca. 900 MB freier Speicher – der Versuch wurde deshalb abgebrochen.

5. Hindsight (Vectorize)

Hindsight ist vermutlich die funktional mächtigste geprüfte Alternative: Statt nur Text-Embeddings zu speichern, extrahiert es strukturierte Fakten, löst Entitäten auf, baut daraus einen Wissensgraphen auf und aktualisiert daraus automatisch „mentale Modelle". Die drei Kernoperationen heißen passend retain (speichern), recall (suchen) und reflect (schlussfolgern), ergänzt um Cross-Encoder-Reranking der Suchergebnisse.

• Vorteil: deutlich mehr als reine Ähnlichkeitssuche – strukturierte Wissensrepräsentation, die auch Zusammenhänge zwischen Fakten abbildet.
• Nachteil (Einrichtungsaufwand): Hindsight ist kein einzelnes Skript, sondern ein kleiner Dienste-Verbund (u. a. Backend-Service, Dashboard, MCP-Server), der eine PostgreSQL-Datenbank mit Vektor-Erweiterung (pgvector oder vergleichbar) voraussetzt und typischerweise per Docker Compose betrieben wird – Installation und Konfiguration (.env, Datenbankanbindung, ggf. mehrere Container) sind ungleich aufwendiger als ein einzelnes Python-Venv.
• Nachteil (Ressourcenbedarf): Für die Wissensgraph-Extraktion braucht Hindsight zusätzlich ein LLM – entweder eine bezahlte Cloud-API pro Speichervorgang oder ein lokales Modell über Ollama. Für lokale Verarbeitung in überzeugender Qualität nennt der Hersteller selbst deutlich größere Modelle (bis hin zu Varianten, die rund 80 GB RAM oder eine dedizierte GPU benötigen); kleinere lokale Modelle laufen zwar auch, mit Abstrichen bei der Extraktionsqualität. Gegenüber der gewählten Lösung (ein rund 275 MB großes Venv plus 112,8 MB Embedding-Modell (multilingual-e5-small), ganz ohne zusätzlichen LLM-Aufruf pro Notiz) ist das ein deutlich größerer Fußabdruck.

Für die Linux-VM ohne GPU und mit begrenztem Speicherplatz kam Hindsight damit nicht infrage – nicht weil es technisch schwächer wäre, im Gegenteil, sondern weil Aufwand und Ressourcenbedarf für den angestrebten Zweck (ein schlankes, schnell wiederfindbares Sitzungsgedächtnis) deutlich über dem lagen, was nötig ist.

6. Memory-MCP-Server mit ONNX (die gewählte Lösung)

Statt PyTorch verwendet der Server onnxruntime mit einem quantisierten, multilingualen Embedding-Modell.

• Venv nur ca. 275 MB statt 1,4 GB.
• Modell 112,8 MB (multilingual-e5-small, 12 Layer, multilingual).
• Läuft auf der CPU – die Linux-VM hat keine GPU.
• Vollständig offline, mit Hybrid-Suche (Vektor + FTS5).

Die gewählte Lösung im Detail

Verfügbare Tools

Warum ONNX statt PyTorch?

1. Speicherplatz: Nach dem gescheiterten PyTorch-Versuch war klar, dass nur eine schlanke Lösung infrage kommt.
2. Offline-Betrieb: Der Server sollte keine Cloud-Verbindung benötigen.
3. Semantische Suche: Im Gegensatz zu reinen Markdown-Dateien oder SQLite-Volltext ermöglicht sie das Wiederfinden von Informationen über Begriffsähnlichkeit statt exakter Schlüsselwörter.
4. CPU-only: Die Linux-VM hat keine GPU-Unterstützung.
5. Integration in den KI-Client: Als MCP-Server steht das Gedächtnis automatisch nach dem Start zur Verfügung.

Erwartungen und Grenzen

Kurzfristig

• Standard-Ablage für sitzungsübergreifend relevante Informationen.
• Schnelles Wiederfinden von Notizen über memory_search anhand von Stichworten oder Konzepten.
• Ergänzung zu AGENTS.md / MEMORY.md / WORKLOG.md, nicht deren Ersatz: Dauerhafte Regeln und technische Details bleiben in den Markdown-Dateien, situationsübergreifende Notizen landen primär im Memory-MCP.

Mittelfristig

• Bessere Kontinuität bei wiederkehrenden Themen, etwa Zotero-Workflows, Prompt-Versionen oder Fehlerbehebungen.
• Weniger manuelles Kopieren von Informationen in Markdown-Dateien.
• Möglichkeit, bei neuen Aufgaben gezielt auf frühere Notizen zu verweisen.

Grenzen

• Die Qualität der semantischen Suche wurde durch den Wechsel auf multilingual-e5-small (12 Layer, multilingual) und die Hybrid-Suche (FTS5 + RRF) deutlich verbessert. Deutschsprachige Texte werden jetzt semantisch präziser erfasst, exakte Begriffe über die Volltextsuche gefunden.
• Der Server speichert, was man ihm gibt. Er ersetzt keine aktive Zusammenfassung oder Planung.
• Tags helfen bei der Filterung, erfordern aber disziplinierte Pflege.

Fazit

Die Markdown-Dateien bleiben das Fundament für Regeln und technische Dokumentation. Der Memory-MCP-Server ergänzt sie um eine schlanke, offline-fähige, semantische Notizdatenbank mit Hybrid-Suche. Nach dem Upgrade auf multilingual-e5-small und FTS5-Volltextsuche ist die Trefferqualität für deutschsprachige Notizen und exakte Suchbegriffe deutlich gestiegen – bei nur moderat höherem Speicherbedarf (112,8 MB statt 22 MB für das Modell).

Changelog

• 3.9.2026 – Chunked Embedding (kein 512-Token-Abschnitt mehr): Notizen mit mehr als ~450 Tokens werden an Markdown-Grenzen in Chunks von maximal 450 Tokens zerlegt (mit 50 Tokens Überlappung, falls ein einzelner Absatz das Limit sprengt) und vollständig embedded. Vorher war eine lange Notiz im Vektor nur am Anfang vertreten (max. 512 Tokens) — semantische Treffer, die tief in einer langen Notiz liegen, blieben so unsichtbar. Die Suche aggregiert Chunk-Treffer pro Notiz (kleinste Distanz) und fusioniert sie wie bisher mit der Volltextsuche; memory_status meldet jetzt zusätzlich chunk_entries. Das Download-Paket wurde auf diesen Stand gebracht.
• 3.9.2026 – Knowledge-Dateien aktualisiert: Zotero-MCP-Knowledge auf Zoteus-v1.12.0-Stand (semantische Suche jetzt vollständig über Zoteus: 0,33–0,84 s/Query statt 93–105 s; 429-Drossel-Dials 256/8000; neue Gotchas create_items-Quoting und Seitenverifikation), Timeline der Nutzungsregeln ergänzt (31.8.–3.9.2026).
• 31.8.2026 – Automatische Backups: setup.sh richtet jetzt automatisch einen stündlichen Backup-Job ein — Snapshot der Memory-Datenbank nur bei Änderung, 8 Tage Aufbewahrung, Wiederherstellung mit einem einzigen cp-Befehl. Kein Zutun nötig; Voraussetzung ist sqlite3, das das Skript ggf. selbst installiert. Dazu kommt jetzt eine Prüfroutine (verify.sh): Sie prüft venv, Python-Pakete, Modell-Dateien, Datenbank, Backup-Job und Speicherplatz und schreibt einen Markdown-Bericht nach ~/.qwen/memory-install-report.md, den die KI direkt auswerten kann. (Damit behoben: Der bisherige Modell-Download über huggingface-cli war mit huggingface_hub ≥ 1.x still kaputt und läuft jetzt über die Python-API.)
• 30.8.2026 – Server-Überarbeitung (jetzt 7 Tools): Neues Tool memory_update (Notizen in place ändern; Re-Embedding und Index-Sync nur bei Inhaltsänderung). Selbstheilung beim Serverstart: Der FTS-Index wird aus der Content-Tabelle neu aufgebaut und fehlende Vektoren werden nachbetet — beides wird jetzt explizit committed (der alte Backfill ging beim Schließen der Verbindung verloren, weil nie committed wurde). FTS-Sync beim Löschen/Aktualisieren repariert: Bei External-Content-FTS5 erhält der Index den alten Inhalt per ‘delete’-Command, bevor die Zeile verschwindet — die alte Reihenfolge hinterließ verwaiste Indexeinträge (empirisch bestätigt). memory_search quotet Suchbegriffe einzeln und verknüpft sie per OR statt die ganze Query als Phrase zu suchen (besserer Recall bei Mehrwortfragen); Tokenizer-Truncation auf 512 Tokens (E5-Limit, verhindert ONNX-Absturz bei langen Notizen); neuer DB-Pfad-Override MEMORY_DB_PATH für Tests/portable Nutzung; SQLite-Timeout 30 s gegen „database is locked“. Das Download-Paket wurde auf diesen Stand gebracht.
• 28.8.2026 – Bugfix memory_search: Treffer, die nur über die Volltextsuche (FTS5) und nicht auch über die Vektorsuche gefunden werden, ließen die gesamte Suche mit einem NoneType-Fehler abbrechen. Solche Treffer liefern jetzt vector_distance: null, statt die Suche zu beenden. Das Download-Paket wurde auf diesen Stand gebracht (inkl. portabler Server-Version mit aktuellen Pfaden).
• 25.8.2026 – Hybrid-Suche v2: Wechsel auf multilingual-e5-small, Volltextsuche per FTS5, Fusion per RRF, Temporal Decay deaktiviert.

Download: Memory-MCP-Server als Setup-Paket

Das gesamte Setup (Server-Script, Installationsskript, Konfigurationsvorlage, Anleitung) gibt es als ZIP-Paket zum Selber-Installieren auf einem eigenen Linux-System:

📦 memory-mcp-setup.zip (24 KB, Stand 5.9.2026)

Neu: Das Paket richtet jetzt automatische stündliche Backups der Memory-Datenbank ein (nur bei Änderung, 8 Tage Aufbewahrung) — dein Assistent sichert sein eigenes Gedächtnis selbst. Mein Assistent pflegt sein Umfeld darüber hinaus vollautomatisch: Er aktualisiert täglich den semantischen Zotero-Index (Zoteus, text-embedding-3-small, inkrementell mit Volltext) und prüft wöchentlich auf Updates für Zoteus, Zotero und die Plugins — siehe die Automatismen-Absätze auf der Studienarbeitsplatz-Seite (§6.3, §12). Seit 4.9.2026 enthält das Paket zudem die Nutzungshinweise für Einsteiger: Die Installationsroutine kopiert nutzungshinweise.md (bzw. usage-notes.md) nach ~/.qwen/, und der §3.2-Auftrag der Studienarbeitsplatz-Anleitung lässt deinen Agenten sie als Memory-Notiz ablegen und bei jedem Start anzeigen.

📄 Zotero-MCP-Knowledge für KI-Agenten (39 KB, Stand 3.9.2026) – Komprimierte Erfahrungen, Workflow-Regeln, Tool-Vergleiche und Benchmark-Ergebnisse aus der Praxis. Als Markdown-Datei, die jeder KI-Agent direkt in sein Memory-System importieren kann.

📜 Memory-MCP-Nutzungsregeln & Lernprotokoll (13 KB) – Alle Regeln für den Umgang mit dem Memory-MCP-Server: Memory-first-Pflicht, Speicher- und Pflegeregeln, Tag-Disziplin und die Lern-Timeline mit allen Zeitpunkten. Als Markdown-Datei zum direkten Import in jedes Memory-System. (Die englische Fassung steht auf der englischen Seite.)

Wer diesen Ansatz mit einem MCP-Server für Zotero kombinieren will, findet die technische Einrichtung dafür auf der Seite Zotero-MCP-Server vs. Beaver. Erfahrungen mit Kimi Code als KI-Client stehen unter Von Claude Code Sonnet zu Kimi Code K2.7-code. Einen schnellen Einstieg in Qwen Code samt Memory-MCP-Einrichtung – ein bis zwei Stunden – bietet die Seite KI-Agent in ein bis zwei Stunden.