Home
Blog
Hinzufügen von persistentem Speicher zu Claude Code mit dem Lightweight memsearch Plugin

Hinzufügen von persistentem Speicher zu Claude Code mit dem Lightweight memsearch Plugin

Engineering

February 13, 2026

Cheney Zhang

Vor kurzem haben wir memsearch entwickelt und veröffentlicht, eine eigenständige Plug-and-Play-Langzeitspeicher-Bibliothek, die jedem Agenten einen persistenten, transparenten und vom Menschen editierbaren Speicher bietet. Sie verwendet dieselbe Speicherarchitektur wie OpenClaw - nur ohne den Rest des OpenClaw-Stacks. Das bedeutet, dass Sie sie in jedes beliebige Agenten-Framework (Claude, GPT, Llama, benutzerdefinierte Agenten, Workflow-Engines) einfügen können und sofort dauerhaften, abfragbaren Speicher hinzufügen können. (Wenn Sie einen tieferen Einblick in die Funktionsweise von memsearch erhalten möchten, haben wir hier einen separaten Beitrag verfasst).

In den meisten Agenten-Workflows funktioniert memsearch genau wie vorgesehen. Aber bei der Agentencodierung sieht es anders aus. Coding-Sitzungen dauern lange, der Kontext wechselt ständig, und die Informationen, die es wert sind, gespeichert zu werden, sammeln sich über Tage oder Wochen an. Das schiere Volumen und die Volatilität zeigen die Schwächen typischer Agentenspeichersysteme auf - Memsearch eingeschlossen. In Coding-Szenarien unterscheiden sich die Abfragemuster so stark, dass wir das vorhandene Tool nicht einfach so weiterverwenden konnten.

Um dieses Problem zu lösen, haben wir ein Plugin für den persistenten Speicher entwickelt, das speziell für Claude Code konzipiert wurde. Es setzt auf der memsearch CLI auf und wir nennen es das memsearch ccplugin.

GitHub Repo: https://zilliztech.github.io/memsearch/claude-plugin/ (Open-Source, MIT-Lizenz)

Mit dem leichtgewichtigen memsearch ccplugin, das den Speicher hinter den Kulissen verwaltet, erhält Claude Code die Fähigkeit, sich an jede Konversation, jede Entscheidung, jede Stilpräferenz und jeden mehrtägigen Thread zu erinnern - automatisch indiziert, vollständig durchsuchbar und über Sitzungen hinweg beständig.

Zur Verdeutlichung in diesem Beitrag: "ccplugin" bezieht sich auf die obere Schicht, also das Claude Code Plugin selbst. "memsearch" bezieht sich auf die untere Schicht, das eigenständige CLI-Tool darunter.

Warum also braucht Coding ein eigenes Plugin, und warum haben wir etwas so Leichtgewichtiges entwickelt? Das liegt an zwei Problemen, auf die Sie mit Sicherheit schon gestoßen sind: Claude Codes Mangel an persistentem Speicher und die Schwerfälligkeit und Komplexität bestehender Lösungen wie claude-mem.

Warum also überhaupt ein eigenes Plugin entwickeln? Weil Kodieragenten auf zwei Probleme stoßen, die Sie mit Sicherheit schon selbst erlebt haben:

Claude Code hat keinen persistenten Speicher.
Viele bestehende Community-Lösungen - wie claude-mem - sindzwar leistungsfähig, aber schwerfällig, klobig oder zu komplex für die tägliche Arbeit mit Codes.

Das ccplugin zielt darauf ab, beide Probleme mit einer minimalen, transparenten, entwicklerfreundlichen Schicht über memsearch zu lösen.

Das Speicherproblem von Claude Code: Er vergisst alles, wenn eine Sitzung endet

Beginnen wir mit einem Szenario, das Claude Code-Benutzer mit Sicherheit schon einmal erlebt haben.

Sie öffnen Claude Code am Morgen. Du tippst: "Setze den gestrigen Auth-Refactor fort". Claude antwortet: "Ich bin mir nicht sicher, woran du gestern gearbeitet hast." Also verbringst du die nächsten zehn Minuten damit, die Protokolle von gestern zu kopieren und einzufügen. Es ist kein großes Problem, aber es wird schnell lästig, weil es so häufig auftritt.

Auch wenn Claude Code über eigene Speichermechanismen verfügt, sind diese alles andere als zufriedenstellend. Die Datei CLAUDE.md kann Projektrichtlinien und Voreinstellungen speichern, aber sie funktioniert besser für statische Regeln und kurze Befehle, nicht für die Ansammlung von Langzeitwissen.

Claude Code bietet zwar die Befehle resume und fork, aber sie sind alles andere als benutzerfreundlich. Für Fork-Befehle müssen Sie sich Sitzungs-IDs merken, Befehle manuell eingeben und einen Baum mit verzweigten Gesprächsverläufen verwalten. Wenn Sie /resume ausführen, erhalten Sie eine Wand von Sitzungstiteln. Wenn Sie sich nur an ein paar Details darüber erinnern, was Sie getan haben und es mehr als ein paar Tage her ist, haben Sie viel Glück, die richtige Sitzung zu finden.

Für eine langfristige, projektübergreifende Wissensakkumulation ist dieser ganze Ansatz unmöglich.

Um diese Idee zu verwirklichen, verwendet claude-mem ein dreistufiges Speichersystem. Die erste Ebene durchsucht Zusammenfassungen auf hoher Ebene. Die zweite Ebene durchforstet eine Zeitleiste nach weiteren Details. In der dritten Ebene werden vollständige Beobachtungen für die unbearbeitete Konversation abgerufen. Darüber hinaus gibt es Datenschutzkennzeichnungen, Kostenverfolgung und eine Webvisualisierungsschnittstelle.

So funktioniert es unter der Haube:

Laufzeitschicht. Ein Node.js Worker-Dienst läuft auf Port 37777. Sitzungsmetadaten werden in einer leichtgewichtigen SQLite-Datenbank gespeichert. Eine Vektordatenbank sorgt für die präzise semantische Abfrage von Speicherinhalten.
Interaktionsschicht. Über eine React-basierte Web-UI können Sie erfasste Erinnerungen in Echtzeit anzeigen: Zusammenfassungen, Zeitleisten und Rohdaten.
Schnittstellenschicht. Ein MCP-Server (Model Context Protocol) stellt standardisierte Tool-Schnittstellen zur Verfügung. Claude kann search (Abfrage von High-Level-Zusammenfassungen), timeline (Anzeige von detaillierten Zeitleisten) und get_observations (Abruf von Interaktionsrohdaten) aufrufen, um Erinnerungen direkt abzurufen und zu verwenden.

Fairerweise muss man sagen, dass dies ein solides Produkt ist, das das Speicherproblem von Claude Code löst. Aber es ist klobig und komplex in einer Weise, die im Alltag von Bedeutung ist.

Ebene	Technologie
Sprache	TypeScript (ES2022, ESNext-Module)
Laufzeit	Node.js 18+
Datenbank	SQLite 3 mit bun:sqlite-Treiber
Vektor-Speicher	ChromaDB (optional, für semantische Suche)
HTTP-Server	Express.js 4.18
Echtzeit	Server-gesendete Ereignisse (SSE)
UI-Framework	React + TypeScript
AI SDK	@anthropic-ai/claude-agent-sdk
Build-Werkzeug	esbuild (bündelt TypeScript)
Prozess-Manager	Bun
Testen	In Node.js eingebauter Test-Runner

Für den Anfang ist die Einrichtung sehr aufwändig. Um claude-mem zum Laufen zu bringen, muss man Node.js, Bun und die MCP-Laufzeitumgebung installieren und dann einen Worker-Dienst, einen Express-Server, eine React UI, SQLite und einen Vektorspeicher darauf aufsetzen. Das ist eine Menge an beweglichen Teilen, die bereitgestellt, gewartet und im Falle eines Fehlers debuggt werden müssen.

All diese Komponenten verbrauchen auch Token, die Sie nicht ausgeben wollten. MCP-Werkzeugdefinitionen werden permanent in das Kontextfenster von Claude geladen, und jeder Werkzeugaufruf verschlingt Token für die Anfrage und die Antwort. Bei langen Sitzungen summiert sich dieser Overhead schnell und kann die Token-Kosten außer Kontrolle geraten lassen.

Der Speicherabruf ist unzuverlässig, weil er vollständig davon abhängt, dass Claude sich für die Suche entscheidet. Claude muss selbst entscheiden, ob er Tools wie search aufruft, um den Abruf auszulösen. Wenn es nicht merkt, dass es einen Speicher benötigt, taucht der relevante Inhalt einfach nicht auf. Und jede der drei Speicherebenen erfordert einen eigenen expliziten Toolaufruf, so dass es keine Ausweichmöglichkeit gibt, wenn Claude nicht daran denkt, zu suchen.

Schließlich ist die Datenspeicherung undurchsichtig, was das Debugging und die Migration erschwert. Die Speicher sind auf SQLite für Sitzungsmetadaten und Chroma für binäre Vektordaten aufgeteilt, ohne dass es ein offenes Format gibt, das sie miteinander verbindet. Migrieren bedeutet, Exportskripte zu schreiben. Um zu sehen, was die KI tatsächlich speichert, muss man die Web-UI oder eine spezielle Abfrageoberfläche verwenden. Es gibt keine Möglichkeit, sich einfach die Rohdaten anzusehen.

Warum ist das memsearch Plugin für Claude Code besser?

Wir wollten eine Speicherschicht, die wirklich leichtgewichtig ist - keine zusätzlichen Dienste, keine verworrene Architektur, kein betrieblicher Overhead. Das hat uns motiviert, das memsearch ccplugin zu entwickeln. Im Kern war dies ein Experiment: Könnte ein kodierungsorientiertes Speichersystem radikal einfacher sein?

Ja, und wir haben es bewiesen.

Das gesamte ccplugin besteht aus vier Shell-Hooks und einem Hintergrund-Watch-Prozess. Kein Node.js, kein MCP-Server, keine Web-UI. Es handelt sich lediglich um Shell-Skripte, die die memsearch CLI aufrufen, was den Einrichtungs- und Wartungsaufwand drastisch reduziert.

Das ccplugin kann so schlank sein, weil die Verantwortlichkeiten strikt abgegrenzt sind. Es kümmert sich nicht um die Speicherspeicherung, den Vektorabruf oder die Texteinbettung. All das wird an die darunter liegende memsearch CLI delegiert. Das ccplugin hat nur eine Aufgabe: die Lebenszyklusereignisse von Claude Code (Sitzungsstart, Eingabeaufforderung, Antwortstop, Sitzungsende) mit den entsprechenden memsearch CLI-Funktionen zu verbinden.

Dieses entkoppelte Design macht das System über Claude Code hinaus flexibel. Die memsearch CLI arbeitet unabhängig von anderen IDEs, anderen Agenten-Frameworks oder sogar von manuellen Aufrufen. Sie ist nicht an einen einzigen Anwendungsfall gebunden.

In der Praxis bietet dieses Design drei wesentliche Vorteile.

1. Alle Erinnerungen leben in einfachen Markdown-Dateien

Jede Erinnerung, die das ccplugin erstellt, wird in .memsearch/memory/ als Markdown-Datei gespeichert.

.memsearch/memory/
├── 2026-02-09.md
├── 2026-02-10.md
└── 2026-02-11.md

Es ist eine Datei pro Tag. Jede Datei enthält die Zusammenfassungen der Sitzungen des jeweiligen Tages in Klartext, der für Menschen lesbar ist. Hier ist ein Screenshot der täglichen Speicherdateien aus dem memsearch-Projekt selbst:

Sie können das Format sofort erkennen: Zeitstempel, Sitzungs-ID, Zug-ID und eine Zusammenfassung der Sitzung. Nichts ist versteckt.

Möchten Sie wissen, was sich die KI merkt? Öffnen Sie die Markdown-Datei. Möchten Sie eine Erinnerung bearbeiten? Verwenden Sie Ihren Texteditor. Möchten Sie Ihre Daten migrieren? Kopieren Sie den Ordner .memsearch/memory/.

Der Milvus-Vektorindex ist ein Cache, der die semantische Suche beschleunigt. Er kann jederzeit aus Markdown neu aufgebaut werden. Keine undurchsichtigen Datenbanken, keine binären Blackboxen. Alle Daten sind nachvollziehbar und vollständig rekonstruierbar.

2. Automatische Context Injection kostet keine zusätzlichen Token

Transparente Speicherung ist die Grundlage dieses Systems. Der eigentliche Nutzen ergibt sich aus der Verwendung dieser Speicher, und in ccplugin erfolgt der Speicherabruf vollautomatisch.

Jedes Mal, wenn eine Eingabeaufforderung übermittelt wird, löst der UserPromptSubmit -Hook eine semantische Suche aus und fügt die drei wichtigsten relevanten Erinnerungen in den Kontext ein. Claude entscheidet nicht, ob gesucht werden soll. Er holt sich einfach den Kontext.

Während dieses Prozesses sieht Claude niemals MCP-Werkzeugdefinitionen, so dass das Kontextfenster nicht zusätzlich belegt wird. Der Hook läuft auf der CLI-Schicht und gibt die Suchergebnisse im Klartext aus. Kein IPC-Overhead, keine Tool-Call-Token-Kosten. Die Aufblähung des Kontextfensters, die mit MCP-Werkzeugdefinitionen einhergeht, entfällt vollständig.

Für Fälle, in denen die automatische Top-3-Suche nicht ausreicht, haben wir außerdem drei Stufen der progressiven Suche entwickelt. Alle drei sind CLI-Befehle, keine MCP-Tools.

L1 (automatisch): Jede Eingabeaufforderung liefert die Top-3 der semantischen Suchergebnisse mit einer chunk_hash und einer 200-Zeichen-Vorschau. Dies deckt die meisten alltäglichen Anwendungen ab.
L2 (bedarfsgesteuert): Wenn ein vollständiger Kontext benötigt wird, gibt memsearch expand <chunk_hash> den kompletten Markdown-Abschnitt plus Metadaten zurück.
L3 (tief): Wenn die ursprüngliche Konversation benötigt wird, ruft memsearch transcript <jsonl_path> --turn <uuid> den rohen JSONL-Datensatz von Claude Code ab.

3. Sitzungszusammenfassungen werden im Hintergrund zu nahezu Nullkosten generiert

Das Retrieval deckt ab, wie die Speicher verwendet werden. Aber die Erinnerungen müssen zuerst geschrieben werden. Wie werden all diese Markdown-Dateien erstellt?

Das ccplugin erzeugt sie durch eine Hintergrundpipeline, die asynchron läuft und fast nichts kostet. Jedes Mal, wenn Sie eine Claude-Antwort stoppen, wird der Stop -Hook ausgelöst: Er analysiert das Gesprächsprotokoll, ruft Claude Haiku (claude -p --model haiku) auf, um eine Zusammenfassung zu erstellen, und hängt sie an die Markdown-Datei des aktuellen Tages an. Haiku-API-Aufrufe sind extrem billig, fast vernachlässigbar pro Aufruf.

Anschließend erkennt der Überwachungsprozess die Datei-Änderung und indiziert den neuen Inhalt automatisch in Milvus, damit er sofort abrufbar ist. Der gesamte Ablauf läuft im Hintergrund, ohne Ihre Arbeit zu unterbrechen, und die Kosten bleiben unter Kontrolle.

Schnellstart des memsearch-Plugins mit Claude Code

Installieren Sie zunächst das Plugin vom Claude Code Marktplatz:


bash
# Run in Claude Code terminal
/plugin marketplace add zilliztech/memsearch
/plugin install memsearch

Zweitens: Starten Sie Claude Code neu.

Das Plugin initialisiert seine Konfiguration automatisch.

Drittens, nach einem Gespräch, die Speicherdatei des Tages überprüfen:

bash
cat .memsearch/memory/$(date +%Y-%m-%d).md

Viertens: Viel Spaß.

Wenn Claude Code das nächste Mal startet, ruft das System automatisch die relevanten Erinnerungen ab und fügt sie ein. Es sind keine weiteren Schritte erforderlich.

Fazit

Kehren wir zur ursprünglichen Frage zurück: Wie gibt man der KI ein persistentes Gedächtnis? claude-mem und memsearch ccplugin verfolgen unterschiedliche Ansätze, die jeweils unterschiedliche Stärken haben. Wir haben einen kurzen Leitfaden für die Wahl zwischen diesen beiden Ansätzen zusammengestellt:

Kategorie	memsearch	claude-mem
Architektur	4 Shell-Haken + 1 Überwachungsprozess	Node.js-Worker + Express + React UI
Integration Methode	Native Haken + CLI	MCP-Server (stdio)
Abruf	Automatisch (Hook-Injektion)	Agent-gesteuert (erfordert Tool-Aufruf)
Context-Verbrauch	Null (nur Ergebnistext injizieren)	MCP-Werkzeugdefinitionen bleiben bestehen
Zusammenfassung der Sitzung	Ein asynchroner Haiku-CLI-Aufruf	Mehrere API-Aufrufe + Komprimierung der Beobachtung
Speicherformat	Normale Markdown-Dateien	SQLite + Chroma-Einbettungen
Daten-Migration	Einfache Markdown-Dateien	SQLite + Chroma-Einbettungen
Methode der Migration	Kopieren von .md-Dateien	Exportieren aus der Datenbank
Laufzeit	Python + Claude CLI	Node.js + Bun + MCP-Laufzeit

claude-mem bietet umfangreichere Funktionen, eine ausgefeilte Benutzeroberfläche und eine feinere Steuerung. Für Teams, die Zusammenarbeit, Web-Visualisierung oder detaillierte Speicherverwaltung benötigen, ist es eine gute Wahl.

memsearch ccplugin bietet minimales Design, keinen Kontextfenster-Overhead und vollständig transparenten Speicher. Für Ingenieure, die eine leichtgewichtige Speicherebene ohne zusätzliche Komplexität wünschen, ist es die bessere Wahl. Welche Lösung besser ist, hängt von Ihren Bedürfnissen ab.

Möchten Sie tiefer eintauchen oder Hilfe bei der Entwicklung mit memsearch oder Milvus erhalten?

Treten Sie der Milvus-Slack-Community bei, um sich mit anderen Entwicklern auszutauschen und zu zeigen, was Sie bauen.
Buchen Sie unsere Milvus-Sprechstunden fürLive-Fragen und direkte Unterstützung durch das Team.