Ihr Agent vergisst alles: Datei-, Vektor- und MCP-Speicher im Vergleich

Letzten Monat beobachtete ich, wie Claude Code zum vierten Mal neu entdeckte, dass mein Projekt pnpm und nicht npm verwendet. Er führte npm test aus, sah es scheitern, entschuldigte sich und versuchte es mit pnpm erneut. Ich hatte das in drei vorherigen Sessions erklärt. Keine davon überlebte. Der Agent trägt zwischen Runs nichts mit sich, es sei denn, ich sorge dafür.

Das ist das ganze Problem. Ein Coding-Agent ist zwischen Runs zustandslos. Jede Session beginnt mit einem leeren Kontext-Fenster. Was immer er gestern herausgefunden hat – Ihre Build-Befehle, warum ein Test instabil ist, die Tatsache, dass die Staging-Datenbank um Mitternacht zurückgesetzt wird – ist weg. Sie erklären es erneut, er leitet es erneut ab, Sie beide verschwenden Token.

Also geben Sie ihm Gedächtnis. Und in dem Moment, in dem Sie suchen, finden Sie drei verschiedene Dinge, die alle "Gedächtnis" genannt werden, und das meiste darüber Geschriebene ist entweder ein Anbieterpitch oder ein Tutorial, das Ihnen nicht sagt, wann der Ansatz scheitert.

Die Kurzversion: Für einen Solo-Builder sind Flat Files der Standard, und Sie sollten sie ausschöpfen, bevor Sie etwas hinzufügen. Vektor-Stores zahlen sich aus, wenn Sie ein großes Korpus durchsuchen, das nicht in den Kontext passt. MCP-Speicher-Server sind die flexibelsten und am leichtesten still zu vergiften. Die meisten greifen zuerst nach dem ausgefallenen. Das ist verkehrt.

Was "Gedächtnis" hier tatsächlich bedeutet

Die drei Optionen sind keine konkurrierenden Implementierungen derselben Sache. Sie lösen unterschiedliche Probleme und scheitern unterschiedlich.

Flat Files sind Markdown oder Text, den der Agent beim Start liest – CLAUDE.md, AGENTS.md, eine Notiz-NOTES.md. Sie oder der Agent schreiben sie, und sie werden bei jeder Session in den Kontext geladen. Keine Suche, keine Embeddings – nur "lies diese Datei zuerst."

Vektor-Stores wandeln Text in Embeddings um und lassen den Agenten nach Bedeutung statt nach Dateinamen abrufen. Sie schreiben etwas einmal, der Store findet den relevanten Chunk später, auch wenn die Wörter nicht übereinstimmen.

MCP-Speicher-Server sind separate Prozesse, mit denen der Agent über das Model Context Protocol kommuniziert, das Tools, Ressourcen und Prompts für jeden kompatiblen Host bereitstellt. Ein Speicher-Server fügt Tools hinzu wie "speichere diese Tatsache" und "durchsuche mein Gedächtnis", die der Agent während einer Aufgabe aufruft.

Ich habe mit allen dreien geliefert. Hier ist die ehrliche Einschätzung zu jedem.

Dateien: langweilig, günstig und der richtige Standard

Datei-Gedächtnis ist das, was Sie bereits haben. Claude Code liest CLAUDE.md am Anfang jeder Session, vollständig als Benutzernachricht nach dem System-Prompt geladen – nicht als durchgesetzte Konfiguration, was wichtig ist, weil der Agent es immer noch ignorieren kann. Dateien werden aus einer Hierarchie geladen: eine verwaltete organisationsweite Datei, Ihr persönliches ~/.claude/CLAUDE.md, das Projekt-./CLAUDE.md und ein gitignoriertes CLAUDE.local.md, von der breitesten zur spezifischsten geordnet, sodass die nächste Anweisung zuletzt gelesen wird.

Es gibt jetzt auch Auto-Gedächtnis: Claude schreibt seine eigenen Notizen in ~/.claude/projects/<project>/memory/MEMORY.md, und die ersten 200 Zeilen (oder 25 KB) dieser Datei werden bei jeder Session geladen. Es speichert Build-Befehle und Debugging-Erkenntnisse, die es entdeckt, ohne dass Sie sie eintippen. Ich lasse es aktiviert; es hat einige Fakten wie "Oh richtig, die API-Tests brauchen ein lokales Redis" aufgefangen, die ich sonst erneut erklärt hätte.

Ich werde hier nicht wiederholen, was in eine CLAUDE.md gehört – ich habe dafür einen ganzen Beitrag geschrieben. Der Punkt hier ist architektonisch: Dateien sind gut in genau einer Sache, und es ist die Sache, die die meisten Agenten brauchen – ein kleiner, kuratierter Satz von Fakten, der in jeder Session wahr sein soll.

Worin Dateien gut sind:

• Null Infrastruktur. Es ist eine Textdatei in Ihrem Repo. Versionskontrolliert, differenzierbar, in einem PR überprüfbar.
• Sie können Ihr eigenes Gedächtnis lesen. Wenn der Agent etwas Dummes tut, öffnen Sie die Datei und sehen genau, was ihm mitgeteilt wurde. Versuchen Sie das mit einem Embedding.
• Es überlebt. Das Projekt-Root-CLAUDE.md wird sogar nach einem /compact neu injiziert, sodass eine lange Session es nicht verliert.

Worin Dateien schlecht sind:

• Sie kosten bei jeder Anfrage Token. Alles in CLAUDE.md befindet sich die gesamte Session über in Ihrem Kontext-Fenster. Die Dokumentation sagt, unter 200 Zeilen anzustreben, und das stimmt – darüber hinaus lässt die Einhaltung nach und Sie zahlen für Anweisungen, die der Agent überfliegt.
• Keine Abfrage. Sie können keine tausend Fakten in einer Datei halten, die der Agent jedes Mal liest. Es ist ein Arbeitssatz, keine Datenbank.
• Veraltung liegt bei Ihnen. Wenn sich Ihr Build-Befehl ändert und Sie vergessen, die Datei zu aktualisieren, führt der Agent zuversichtlich den alten aus. Die Datei weiß nicht, dass sie falsch ist.

Für die meisten Solo-Projekte reichen Dateien aus. Ich habe Produkte geliefert, bei denen CLAUDE.md plus Auto-Gedächtnis das gesamte Speichersystem war und ich nie mehr wollte.

Vektor-Stores: guter Abruf, kein Urteilsvermögen

Wenn das, was Sie sich merken möchten, zu groß ist, um in eine Datei zu passen, die der Agent jedes Mal liest – ein Jahr Architekturentscheidungen, ein großes internes Wiki, jeden vergangenen Bug und seine Lösung – wechseln Sie zum Abruf. Eine Vektordatenbank speichert hochdimensionale Embeddings Ihres Textes und findet die nächsten Übereinstimmungen zu einer Anfrage nach Bedeutung, typischerweise in Zehnten von Millisekunden.

Sie brauchen keine dedizierte Vektor-DB zum Starten. Wenn Sie bereits Postgres betreiben, fügt pgvector Vektorspeicherung und -suche zur Datenbank hinzu, die Sie bereits haben, was für einen Solo-Builder normalerweise der richtige erste Schritt ist. Der 2026er Standard ist hybride Suche – Schlüsselwort plus Vektor – weil reine semantische Suche exakte Übereinstimmungsfälle wie einen bestimmten Funktionsnamen oder Fehlercode verpasst.

Worin Vektor-Stores gut sind:

• Abruf in großem Maßstab. Das ist das einzige der drei, das mit "Ich habe zehntausend Notizen, finde die relevanten drei" umgehen kann. Dateien können das nicht und MCP-Graph-Server haben damit Mühe.
• Bedeutung über Formulierung. Sie schrieben "der Checkout-Ablauf belastet beim erneuten Versuch doppelt", Sie fragen später "warum löst die Zahlung zweimal aus", und es findet die Notiz. Schlüsselwortsuche würde das nicht.

Worin Vektor-Stores schlecht sind:

• Abrufqualität ist eine Pipeline, keine Einstellung. Embedding-Modell, Chunking-Strategie, Indextyp und Aktualisierungsrate interagieren alle. Chunking falsch machen und Sie rufen einen halben Gedanken ab. Das ist echte Arbeit, und es ist Arbeit, die die meisten Solo-Builder unterschätzen.
• Kein Begriff von wahr. Ein Vektor-Store gibt zurück, was ähnlich ist, nicht was korrekt oder aktuell ist. Wenn Sie eine Tatsache im März gespeichert haben und sich die Wahrheit im Mai geändert hat, sitzen beide Versionen im Index und die März-Version kann bei der Ähnlichkeit gewinnen.
• Es ist eine Vergiftungsfläche. Alles, was den Store speist – eine Webseite, die der Agent indiziert hat, ein Dokument, das jemand in einem freigegebenen Ordner abgelegt hat – kann Text einpflanzen, der später als autoritativer Kontext abgerufen wird. Mehr dazu unten.

Ich greife auf einen Vektor-Store zurück, wenn das Korpus wirklich zu groß für den Kontext ist und ich Abruf brauche. Für "merke dir meine fünf Projektkonventionen" ist das maßlos überdimensioniert.

MCP-Speicher-Server: flexibel, strukturiert und eine größere Angriffsfläche

Die dritte Option ist ein Speicher-Server, den Sie über MCP verbinden. Der Referenzserver ist Anthropics Knowledge-Graph-Speicher-Server. Er modelliert Gedächtnis als Graph: Entitäten (benannte Knoten mit einem Typ), Relationen (gerichtete, aktivstimmige Verbindungen zwischen ihnen) und Beobachtungen (atomare Fakten, die an eine Entität angehängt sind). Er persistiert in eine lokale memory.jsonl-Datei und stellt Tools wie create_entities, add_observations, search_nodes und read_graph bereit.

Das Versprechen ist, dass Struktur einen flachen Blob schlägt. "Benutzer bevorzugt pnpm" wird zu einer Beobachtung auf einer Benutzer-Entität, die mit einer Projekt-Entität verknüpft ist, und der Agent traversiert das, anstatt Prosa zu suchen. In der Praxis liegt es zwischen Dateien und Vektoren: abfragbarer als eine Textdatei, interpretierbarer als ein Embedding.

Wissenswert: Anthropics eigenes Memory Tool ist ein anderer Mechanismus – ein clientseitiges Tool, bei dem das Modell view, create, str_replace, delete-Befehle gegen ein /memories-Verzeichnis ausgibt und Sie implementieren, wo die Bytes leben. Sein System-Prompt weist das Modell an: "SCHAUEN SIE SICH IMMER ZUERST IHR GEDÄCHTNIS-VERZEICHNIS AN, BEVOR SIE IRGENDETWAS ANDERES TUN... Ihr Kontext-Fenster könnte jederzeit zurückgesetzt werden." Das sagt Ihnen etwas: Selbst Anthropics "Memory Tool" sind darunter Dateien.

Worin MCP-Speicher-Server gut sind:

• Strukturierter Abruf, über den der Agent nachdenken kann. Graph-Traversal beantwortet "Was weiß ich über dieses Projekt" präziser als eine Ähnlichkeitssuche.
• Portabilität. MCP ist ein Standard, sodass derselbe Server über Claude Code, Cursor und jeden kompatiblen Host hinweg funktioniert. Ein Gedächtnis, viele Tools.
• Explizite Schreibvorgänge. Der Agent entscheidet, was es wert ist, als diskrete Beobachtung gespeichert zu werden, was das Gedächtnis sauberer hält als das Abladen ganzer Transkripte in einen Vektor-Index.

Worin MCP-Speicher-Server schlecht sind:

• Einrichtung und ein laufender Prozess. Es ist ein weiteres bewegliches Teil, das installiert, konfiguriert und am Leben gehalten werden muss. Für ein Projekt ist das viel Zeremonie.
• Der Graph driftet. Ohne Disziplin erhalten Sie doppelte Entitäten ("Project", "the project", "my app") und widersprüchliche Beobachtungen. Die Struktur, die helfen sollte, braucht jetzt Pflege.
• Es ist am leichtesten zu vergiften. Persistent, beschreibbar, als autoritativ abgerufen – das ist genau das Profil, auf das Angreifer abzielen.

Die zwei Versagensmodi, die niemand auf die Landing Page schreibt

Jeder "Gib deinem Agenten Gedächtnis"-Beitrag verkauft die Vorteile. Hier sind die zwei, die mich gebissen haben.

Gedächtnisvergiftung. Das ist das Ernstnehmende. Im Gegensatz zu einer Prompt-Injection, die stirbt, wenn die Session schließt, ist Gedächtnisvergiftung ein Persistenz-Angriff – eine bösartige Anweisung, die heute in Ihrem Store gepflanzt wird, wird Wochen später ausgeführt, ausgelöst durch eine unrelated Aufgabe. Der Angriff und seine Wirkung sind zeitlich entkoppelt. Jede Pipeline, die in den Speicher schreibt, ist ein Einstiegspunkt: eine Webseite, die der Agent indiziert hat, die README einer Abhängigkeit, die er zusammengefasst hat, ein geteiltes Dokument. Vektor-Stores und MCP-Server sind beide exponiert, weil beide Inhalte automatisch aufnehmen und als vertrauenswürdigen Kontext zurückgeben. Dateien sind die sichere Option, genau weil ein Mensch sie schreibt und in einem Diff lesen kann.

Veraltete Fakten überschreiben die Realität. Weniger dramatisch, häufiger. Ihr Gedächtnis sagt, der Preistarif ist 20 Dollar. Er ging letzten Dienstag auf 25 Dollar. Der Agent ruft die gecachte Tatsache ohne Time-to-Live-Prüfung ab und präsentiert die alte Zahl als autoritativ. Der Agent hat keine Möglichkeit zu wissen, dass sich die Seite vor einer Stunde geändert hat. Jedes Gedächtnissystem hat dieses Problem, und je "automatischer" das System, desto schlimmer ist es, weil niemand beobachtet, was geschrieben wurde. Ich habe genau so einen falschen Konfigurationswert geliefert. Das Gedächtnis war zuversichtlich. Das Gedächtnis war falsch.

Die unbequeme Wahrheit: Je mehr Sie das Gedächtnis automatisieren, desto weniger bemerken Sie, wenn es Sie anlügt. Dateien sind mühsam von Hand zu pflegen, und diese Mühsal ist gleichzeitig die Prüfung.

Was ich als Solo-Builder tatsächlich betreiben würde

Beginnen Sie mit Dateien. CLAUDE.md für die Fakten, die Sie immer wieder erklären, Auto-Gedächtnis aktiviert, damit der Agent den Rest erfasst. Das deckt das meiste ab, was ein Solo-Projekt braucht, kostet nichts einzurichten, und Sie können jeden einzelnen Byte davon lesen. Fügen Sie kein zweites System hinzu, bis Dateien sichtbar versagen – und "versagen" bedeutet ein spezifisches Symptom: Der Agent kann eine Entscheidung nicht finden, von der Sie wissen, dass Sie sie aufgeschrieben haben, oder Ihre CLAUDE.md hat 200 Zeilen Zeug überschritten, das nur manchmal relevant ist.

Wenn das passiert, stellen Sie eine Frage: Ist das Problem Abruf oder Struktur? Wenn Sie ein großes Korpus haben und der Agent das richtige Stück nicht finden kann, das ist Abruf – fügen Sie einen Vektor-Store hinzu, beginnen Sie mit pgvector, wenn Sie bereits auf Postgres sind, und verwenden Sie hybride Suche. Wenn Sie möchten, dass der Agent über Beziehungen zwischen Sessions nachdenkt und Sie über mehrere Tools hinweg arbeiten, das ist Struktur – ein MCP-Speicher-Server verdient seine Einrichtungskosten.

Was immer Sie hinzufügen, behandeln Sie Gedächtnis als etwas, das falsch sein kann. Versehen Sie Fakten, die ablaufen, mit einem Datum. Lesen Sie regelmäßig, was geschrieben wurde – der Claude Code /memory-Befehl zeigt Ihnen genau das für Dateien, und es ist einfaches Markdown, das Sie bearbeiten oder löschen können. Lassen Sie niemals eine automatisierte Pipeline aus einer Quelle in den Speicher schreiben, die Sie nicht selbst in Ihr Terminal einfügen würden.

Der Agent, der alles vergisst, ist ärgerlich. Der Agent, der sich zuversichtlich etwas Falsches merkt, ist schlimmer. Wählen Sie das einfachste Gedächtnis, das Ihr eigentliches Problem löst, und halten Sie es klein genug, dass Sie noch erkennen können, wenn es falsch liegt.