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

• 21.9.2026 – Memory-first-Regel im Installer (Paket v8): Die Nutzungsregeln im Setup-Paket (RULES.md) beginnen jetzt mit der wichtigsten Regel: Memory-first — memory_search als erster Schritt jeder Frage/Aufgabe, bevor geantwortet oder gehandelt wird, inklusive der dokumentierten Verstoßbeispiele und der Anweisung, die Regel dauerhaft in die immer geladene Anweisungsdatei des Agenten (~/.qwen/QWEN.md) einzutragen. Server und Wörterbuch sind unverändert (Stand v7).
• 21.9.2026 – Satzzeichen-Fix + erweitertes Übersetzungswörterbuch (Paket v7): Brücken-Wörter am Satzende (z. B. „…Seite anzulegen?“) wurden wegen der angehängten Satzzeichen nie expandiert — der Server entfernt jetzt Randzeichen vor dem Abgleich. Das Übersetzungswörterbuch wuchs auf 13 Gruppen (u. a. „Kurzzusammenfassung“ → Abstract, „Dateipfad“ → Pfad/Path, „Übersetzung“ → Translation); in der unabhängigen Vermessung (125 Suchanfragen) stieg die Trefferquote der zweiten Runde auf 90,5 % Recall@5.
• 20.9.2026 – Auto-Migration für Alt-Datenbanken (Paket v6): Der Server migriert Datenbanken des Schemas vor 19.9. beim Start selbstständig (die key-Spalte wird in notes ergänzt, eine veraltete FTS-Tabelle bekommt (content, key)) — manuelles ALTER TABLE ist nicht mehr nötig.
• 20.9.2026 – Suchqualität deutlich verbessert (Forschungsprojekt abgeschlossen): Auf Basis von 21 im Volltext ausgewerteten Studien und 125 gemessenen Real-Anfragen wurde die Suche deutlich geschärft: Schlüsselzeilen als Suchanker (die erste Zeile jeder Notiz zählt in der Volltextsuche 3-fach und wird zusätzlich ins Einbettungsmodell eingespeist), Suchgewichtung (der Stichwort-Arm zählt 0,85-fach statt gleich — behebt Fusionsverluste), ein Übersetzungswörterbuch (synonyms.json übersetzt Alltagswörter unsichtbar in Fachbegriffe, z. B. „Tresor“ → Passwort-Datenbank), Snippet-Return (jeder Treffer zeigt seinen besten Textausschnitt) und ein optionaler Token-Budget-Parameter für die Suche. Im härtesten der drei Messkörbe stieg die Trefferquote von 68,4 % auf 89,2 %; ein Datums-Feld in der Suche wurde gemessen, verworfen und zurückgebaut. Dazu: Bereinigung der Notizdatenbank (446 → 403 Notizen, überlange Notizen auf Kurzfassung plus Dateiverweis) und ein Gesundheitscheck-Skript, das die Messkörbe regelmäßig gegen das Wörterbuch rechnet. Das Paket wurde auf diesen Stand gebracht (synonyms.json ist neu enthalten; das Setup kopiert es automatisch). Alle Messwerte und die Studienliste: die neue Seite Der Memory-Server im Labor.
• 16.9.2026 – Gedächtnis-Downloads aktualisiert, neue Datei zur Provider-Konfiguration: Die Memory-MCP-Nutzungsregeln haben drei neue Regeln (R11: fehlende Tools sofort melden — auch bei Workaround; R12: Behauptungen nur nach Verifikation; R13: Quellenangaben bei Datentabellen), und R8 verbietet jetzt zusätzlich ungeschützte personenbezogene/patientenbezogene Daten im Memory oder LLM-Kontext. Die Lern-Timeline ist ergänzt um den Index-Zwischenfall 8.9. (Ein-Kanal-Prinzip: genau ein automatisierter Kanal für Index-Aktionen, kein Auto-Resume, Status-Gate) und die Desktop-vs-CLI-Diagnose 12.9. (Umgebungslecks via PYTHONHOME/LD_LIBRARY_PATH laden falsche Systembibliotheken und produzieren irreführende Fehlermeldungen — /proc/<pid>/environ und maps vergleichen). Der Zotero-MCP-Knowledge-Export wurde auf Zoteus v1.20.1 gehoben: wählbare Gewichtspräzision beim lokalen Embedder seit v1.14.0 (q8 ≈ 129 MB, Benchmark 80,6 % identische Top-10-Slots gegen fp32), kuratierte Pooling-Registry, Produktivbetrieb mit lokalem e5-small seit 13.9. (Voll-Rebuild über Nacht, 272.896 Passagen — Bücher vollständig statt 1-Million-Zeichen-Cap), re-verifizierte Volltext-Update-Pflicht, neues Ein-Kanal-Prinzip für Index-Aufträge sowie zwei neue Abschnitte: der Standardworkflow für evidenzbasierte Literaturzusammenfassungen (§9) und der Fünf-Durchgänge-Standard zur Prüfung LLM-erstellter Texte (§10). Neu als Download: Qwen Code: Modell-Provider-Konfiguration in der settings.json — Anatomie der Provider-Einträge, Key-Handhabung, Reasoning-Effort-Override, Timeouts, Quantisierungs- und JSONC-Gotchas (ohne Schlüssel).
• 13.9.2026 – Nutzungshinweise erweitert (Quantisierung): Die Hinweise für Einsteiger (nutzungshinweise.md / usage-notes.md) haben einen zwölften Punkt: Bei der Provider-/Modellwahl auf die Quantisierung achten — 16-Bit (fp16/bf16) ist Referenzqualität (teurer), 8-Bit (fp8) der sichere Branchenstandard für Facharbeit (Programmieren, Medizin, Jura), 4-Bit (fp4) nur bei Modellen, die damit trainiert wurden (z. B. gpt-oss/MXFP4); nachträgliche fp4-Quantisierung kostet spürbar Qualität bei Reasoning, Code und Agenten-Aufgaben. Das Download-Paket wurde auf diesen Stand gebracht.
• 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 (31 KB, Paket v8, Stand 21.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, lokale Embeddings (multilingual-e5-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 (53 KB, Stand 16.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 (21 KB, Stand 20.9.2026) – Alle Regeln für den Umgang mit dem Memory-MCP-Server: Memory-first-Pflicht, Speicher- und Pflegeregeln, Tag-Disziplin, die Schreibregeln (kurze Einträge, ein Thema pro Eintrag, lange Inhalte nur als Dateiverweis, die erste Zeile als gepflegte Schlüsselzeile) 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.)

⚙️ Qwen Code: Modell-Provider-Konfiguration in der settings.json (10 KB, Stand 20.9.2026) – Erarbeitetes Konfigurationswissen: Anatomie eines modelProviders-Eintrags, Keys in der .env statt in der settings.json, die Fallen von Top-Level-Modell vs. Provider-Einträgen (Reasoning-Effort-Override, Effort-Persistenz-Falle, baseUrl-Falle), Timeouts und Hot-Reload, Quantisierung bei der Modellwahl, JSONC-Gotchas und App-Attribution bei OpenRouter. Enthält keinerlei Schlüssel — die eigene Konfiguration lässt sich damit nachbauen. (Die englische Fassung steht auf der englischen Seite.)

Neu: Die Forschungsseite. Wie wir die Trefferquote des Gedächtnis-Servers gemessen und im härtesten Messkorb von 68,4 % auf 89,2 % gesteigert haben — 21 ausgewertete Studien, 125 gemessene Suchanfragen, jeder Hebel einzeln belegt: Der Memory-Server im Labor.

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.