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

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 22 MB Embedding-Modell, 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 all-MiniLM-L6-v2-Modell.

• Venv nur ca. 275 MB statt 1,4 GB.
• Modell nur 22 MB.
• Läuft auf der CPU – die Linux-VM hat keine GPU.
• Vollständig offline, mit semantischer Suche.

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 hängt vom kleinen all-MiniLM-L6-v2-Modell ab. Es ist nicht so leistungsfähig wie große Embedding-Modelle, für das Wiederfinden von Notizen aber ausreichend.
• 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. Die Entscheidung für ONNX statt PyTorch war entscheidend, um den Speicherbedarf auf ein akzeptables Maß zu reduzieren.

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.