2026-02-14 · Aktualisiert 2026-07-14

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

AI Agent Memory Architektur im Jahr 2026: Checkpoints, Vector Stores und dateibasierte Speicherung

Teil 2 der Serie „Engineering des Agentic-Stacks“

Ein Reasoning Loop überlebt nur eine Anfrage lang, es sei denn, sein Zustand wird außerhalb des Workers gespeichert. Ohne Agent Memory kann der Agent keinen pausierten Ablauf wieder aufnehmen, sich nach einem Absturz erholen oder eine Präferenz aus einem früheren Session abrufen. Teil 1 Der Kontrollfluss wurde behandelt. In diesem Beitrag wird aufgezeigt, welchen Zustand jeder nachfolgende Schritt benötigt und wo dieser Zustand gespeichert werden sollte.

Ich erläutere Ihnen die Speicherverwaltung der Marktanalyst Agent, Es wird gezeigt, wie heißer Checkpoints-, kälterer Vector Stores- und auf Dateien basierender Dokumentenspeicher zusammenarbeiten, um langlaufende Agents-Prozesse zu unterstützen. Anschließend erläutere ich, in welchen Fällen PostgreSQL, Redis, Qdrant, Schlüssel-Wert-Speicher sowie einfache Markdown-Dateien sinnvoll eingesetzt werden können.

TL;DR: Trennen Sie den Speicher nach dem Zugriffsmuster. Heiße Daten stellen den threadbezogenen Checkpoint Zustand für Pausen und Wiederaufnahmen dar. Kalte Daten speichern cross-Session relevante Informationen in Form von Schlüssel-Wert-Paaren oder Vector Store. Dokumentenspeicher dienen dazu, Projektwissen in übersichtlichen Dateien zu bewahren. Beginnen Sie mit dem Fehler, den Sie beheben müssen, und wählen Sie anschließend den geeigneten Speicherort aus. Legen Sie keine präzisen Fakten in ein ungenaues Retrieval System ab, und betrachten Sie einen Checkpoint nicht als Audit-Log.

Was ist AI Agent Memory?

AI Agent Memory stellt die Zustandsschicht dar, die es einem Agent ermöglicht, den Fortschritt einer Aufgabe beizubehalten, vorheriges Wissen abzurufen sowie sein Wissen über mehrere Ausführungen hinweg zu aktualisieren. In der Produktion handelt es sich dabei nicht um eine einzige Vector Database. Vielmehr besteht sie aus einer Kombination aus aktiven Checkpoints-, kalten semantischen oder strukturierten Speichern sowie menschenlesbarer Dokumentenmemorie.

Beginnen Sie nicht mit dem Speicher, da dieser Begriff intelligent klingt. Konzentrieren Sie sich stattdessen auf den vom Benutzer wahrnehmbaren Fehler: das Verlieren von Fortschritten, das Vergessen einer Einstellung, das Wiederholen von Recherchen oder das Versäumnis, gängige Projektkonventionen erneut zu nutzen.

Die Fehler, die auf Speicherzugriff angewiesen sind

Ein stateless Agent kann eine isolierte Anfrage beantworten, vergisst die Anfrage jedoch umgehend, sobald der Aufruf beendet ist. Dieses Design versagt, wenn das Produkt eines der folgenden Verhaltensweisen benötigt:

• Pausieren und Fortsetzen: Ein Benutzer startet eine Forschungsaufgabe, schließt seinen Laptop und kehrt erst am nächsten Tag zurück. Ohne gespeicherten Zustand startet der Agent von vorne.
• Kohärenz über mehrere Gesprächsrunden: Im Laufe eines langen Dialogs muss der Agent sich daran erinnern, welche Tools er verwendet hat, welche Daten er gesammelt hat sowie welche Planungs Schritte bereits abgeschlossen sind.
• Personalisierung: Ein zurückkehrender Benutzer erwartet, dass der Agent seine Risikotoleranz, seine bevorzugte Analysetiefe sowie frühere Interaktionen kennt.
• Human-in-the-Loop (HITL): Der Agent erstellt einen Bericht und wartet auf Freigabe. Der „Wartezustand“ muss auch bei Neustart des Prozesses erhalten bleiben.

In dem Marktanalyst Agent von Teil 1, Der Aufruf „Analyze NVDA“ erzeugt einen Plan, fünf Tool Calls, gesammelte Daten sowie einen Entwurf eines Berichts. Wenn der Benutzer antwortet „Sieht gut aus, aber fügen Sie eine Wettbewerbsanalyse hinzu“, ermöglicht ein Checkpoint-Speicher es dem Agent, den Zustand des vorherigen Nodes zu laden und den Schritt zur Analyse der Konkurrenten hinzuzufügen. Ohne einen gespeicherten Zustand kann das System nicht erkennen, worauf sich die Aussage „Sieht gut aus“ bezieht, und muss von vorn beginnen.

Long-Term Memory behandelt einen anderen Fall. Wenn der Benutzer eine Woche später zurückkehrt und fragt: „Aktualisieren Sie meine NVDA-Analyse“, muss der Agent möglicherweise an die Präferenz für konservative Risikobewertungen sowie das Interesse an Halbleiteraktien erinnert werden. Ein auf Vektoren basierter Speicher kann diese Informationen unabhängig von Sessions abrufen, ohne sie erneut anfordern zu müssen.

LangGraph teilt die Daten nach ihrem Scope auf. Jede Ausführung eines Graphen erfolgt innerhalb eines Threads, was einer einzelnen Konversation oder Aufgabe entspricht. Der im jeweiligen Thread persistierte Zustand wird als Short-Term Memory bezeichnet. Der Zustand, der zwischen den Threads geteilt wird, ist hingegen Long-Term Memory. Der aktuelle Kontext sowie die im Prozess verfügbaren Variablen des Model bilden die Arbeitsgedächtnisschicht, die über beiden Speichern liegt.

Eine Taxonomie von AI Agent Memory

Bevor man mit der Implementierung beginnt, ist es hilfreich, zu klären, welche Aspekte Agents berücksichtigt werden müssen. Die CoALA Framework (Sumers, Yao et al., 2023) stellt die gängige Taxonomie dar und stützt sich auf Erkenntnisse der Kognitionswissenschaft. Ich habe den Begriff „Memory Scoping“ in meiner Arbeit eingeführt. Context Engineering-Post; Hier erweitere ich es auf sechs Kategorien:

Arbeitsspeicher ist das, womit der LLM derzeit aktiv Reasoning arbeitet: Python-Variablen in der aktuellen Funktion, dem Inhalt des Context Window sowie den Tool Call Argumenten während der Ausführung. Es handelt sich dabei um die schnellste und kurzlebigste Ebene – nichts bleibt über den aktuellen Schritt hinaus bestehen. Der Arbeitsspeicher wird durch die Context Window des Model begrenzt, wodurch er zur eigentlichen Bottleneck wird. Alles, was der Agent zum Zeitpunkt einer Entscheidungsfindung „weiß“, muss hier Platz finden, egal ob es aus dem Checkpoint-Speicher stammt, aus einer Vektorabfrage oder aus einer Datei-Lesung. Die anderen Ebenen dienen dazu, zur richtigen Zeit die richtigen Informationen in den Arbeitsspeicher zu liefern.

Short-Term Memory ist der Datensatz, den das Checkpoint LangGraph nach jedem Node schreibt. Episodische sowie semantische Erinnerungen bleiben über verschiedene Threads hinweg bestehen. Die Dokumentenerinnerung speichert Projektnotizen, Forschungsübersichten sowie erlernte Konventionen in Dateien, die von Menschen und Agents eingesehen werden können. Die prozedurale Erinnerung befindet sich hingegen in Systemanweisungen und Tool-Definitionen und ändert sich daher nicht für jeden Benutzer.

Bei der Implementierung lassen sich diese Kategorien auf drei Ebenen zusammenfassen. Die Hot-Memory speichert den aktuellen Session. Die Cold-Memory ermöglicht das Abrufen von Informationen über Sessions. Die Document-Memory sorgt dafür, dass angesammeltes Projektwissen weiterhin lesbar und direkt bearbeitbar bleibt.

CoALA klassifiziert Arbeitsgedächtnis, episodisches Gedächtnis, semantisches Gedächtnis sowie prozedurales Gedächtnis. Die Speicher im Zeitalter der AI Agents-Umfrage Es legt besonderen Wert auf Vector Stores sowie Knowledge Graphs, während LangGraph Checkpoints und seine Store-Schnittstelle dokumentiert. Projektwissen, das auf Dateien basiert, fällt außerhalb dieser Taxonomien, obwohl Claude Code, Cursor, Windsurf und Devin alle persistente Projektdateien laden.

Dasselbe Speichermuster kommt auch in anderen Bereichen vor. Voyager speichert wiederverwendbare Spielfähigkeiten als Codebibliotheken, die Teams von ECR3 arbeiteten an prozeduralen Prompt-Dokumenten, und Agent Workflow-Memory erzeugt aus erfolgreichen Episoden wiederverwendbare Web-Workflows-Komponenten. Durch Dateien wird dieses Wissen ohne den Einsatz eines separaten Embedding-Services überprüfbar und versionierbar.

Agent-Gemanagte Speicher werden zudem von einem festen RAG Pipeline dadurch unterschieden, dass sie unterschiedliche Akteure für die Schreibvorgänge haben. Der Agent oder seine Harness entscheiden, was gespeichert, aktualisiert oder gelöscht werden soll, und wählen anschließend den Zeitpunkt aus, zu dem die Daten wieder abgerufen werden.

Der Generatives Agents-Paper (Park et al., 2023) zeigten, wie weit dies gehen kann: simulierte Agents speicherten, reflektierten über ihre eigenen Erinnerungen nach und holten sie wieder ab. Ihr Memory Stream ordnete die Kandidaten nach Aktualität, Bedeutung und Relevanz, ein Design, das auch weiterhin einen nützlichen Referenzpunkt für Agent-Erinnerungen Retrieval darstellt.

Kurzfristige Agent Memory-Phase: der Checkpoint-Speicher

Jedes Mal, wenn ein LangGraph-Knoten ausgeführt wird, serialisiert der Framework den vollständigen Graphenzustand und schreibt ihn in einen Checkpoint-Speicher. Dies bildet die Grundlage für Funktionen wie Pause/Fortsetzen, Debugging mittels Zeitreise sowie HITL Workflows.

Ein Checkpoint enthält den Graphenzustand, der zur Wiederaufnahme erforderlich ist: die AgentState aus Teil 1 (mitteilungen, Identität, Benutzerprofil, Schritt für Schritt der Ausführung, Forschungsdaten, Ausführungsmodus) sowie LangGraph-Metadaten wie dem Knoten, der die Daten erzeugt hat, und seiner Checkpoint-ID. Nach einem HITL-Unterbruch oder einem Prozessneustart lädt das Graph das neueste aufgezeichnete Grenzwertprofil und wechselt zum nächsten Knoten. Es setzt seine Ausführung nicht an einer beliebigen Python-Schleife fort. Ein Checkpoint unterscheidet sich außerdem von einem nur zum Hinzufügen geeigneten Ereignisprotokoll oder Trace. Teil 5 trennt diese Runtime Observability Oberflächen explizit voneinander.

Wie das Checkpointing bei LangGraph funktioniert

LangGraphs BaseCheckpointSaver es handelt sich um eine einfache Schnittstelle: put() schreibt einen Checkpoint. get_tuple() liest den neuesten Eintrag für einen Thread. list() gibt die Historie zurück. Jeder Checkpoint ist durch einen Schlüssel identifiziert. (thread_id, checkpoint_ns, checkpoint_id), wo thread_id identifiziert das Gespräch. checkpoint_ns kümmert sich um die Namensräumung von Subgraphen, und checkpoint_id es handelt sich um eine eindeutige Version.

Die entscheidende Frage ist, welcher Backend dahinter verwendet wird. PostgreSQL und Redis zählen zu den gängigen Wahlmöglichkeiten in der Produktion.

PostgreSQL gegen Redis

Allgemeine Datenbanken Benchmarks können die Checkpoint Leistung nicht vorhersagen. Messen Sie stattdessen die Größe des serialisierten Zustands, die Schreibfrequenz, die Persistenzeinstellungen sowie die Konkurrenzzustände Ihrer eigenen Graph-Datenstruktur.

PostgreSQL: Der zuverlässige Standard

PostgreSQL ist die sicherere Standardwahl für die meisten Teams. Checkpoints überstehen Ausfälle problemlos, es stehen vollständige Transaktionssemantiken zur Verfügung, und die Checkpoint-Historie erleichtert das Fehlersuchen durch rückwärtsgerichtete Analyse erheblich.

Von checkpointer_setup.py:

from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver

async def create_postgres_checkpointer(connection_string: str) -> AsyncPostgresSaver:
    """Create a PostgreSQL-backed checkpoint store.

    PostgreSQL gives us ACID guarantees — if a checkpoint write succeeds,
    the state is durable even if the process crashes immediately after.
    """
    checkpointer = AsyncPostgresSaver.from_conn_string(connection_string)

    # Create the checkpoint tables if they don't exist.
    # This is idempotent — safe to call on every startup.
    await checkpointer.setup()

    return checkpointer

# Usage: wire into the graph compilation
checkpointer = await create_postgres_checkpointer(
    "postgresql://user:pass@localhost:5432/agent_memory"
)
graph = create_graph(checkpointer=checkpointer)

# Every invoke/stream call now persists state automatically
config = {"configurable": {"thread_id": "user-123-session-1"}}
result = await graph.ainvoke({"messages": [HumanMessage(content="Analyze NVDA")]}, config)

# Resume later — loads the latest checkpoint for this thread
result = await graph.ainvoke({"messages": [HumanMessage(content="approved")]}, config)

Der AsyncPostgresSaver verwendet den langgraph-checkpoint-postgres Paket, das drei Tabellen erstellt: checkpoints (die serialisierte Zustandsdarstellung) checkpoint_blobs (größe binäre Datenmengen) und checkpoint_writes (Wartende Schreibvorgänge für die Krash-Wiederherstellung.) Das Schema unterstützt gleichzeitigen Zugriff und verwendet Advisory-Locks, um Schreibkonflikte zu verhindern.

Redis: wann Latency der Bottleneck ist

Wenn submillisekundengenaue Reaktionszeiten Checkpoint Latency entscheidend sind – beispielsweise bei Echtzeit-Dialogsystemen Agents oder hochfrequenten Tool-Schleifen – ist Redis die bessere Wahl.

Von checkpointer_setup.py:

from langgraph.checkpoint.redis.aio import AsyncRedisSaver

async def create_redis_checkpointer(redis_url: str) -> AsyncRedisSaver:
    """Create a Redis-backed checkpoint store.

    Redis stores checkpoints in memory for sub-millisecond access.
    Trade-off: less durable than PostgreSQL unless AOF is enabled.
    """
    checkpointer = AsyncRedisSaver.from_conn_string(redis_url)

    # Initialize Redis data structures
    await checkpointer.setup()

    return checkpointer

# Usage: same graph API, different backend
checkpointer = await create_redis_checkpointer("redis://localhost:6379")
graph = create_graph(checkpointer=checkpointer)

Der AsyncRedisSaver aus langgraph-checkpoint-redis speichert Checkpoints als JSON-Dokumente, die nach dem Thread-ID-Schlüssel geordnet sind. Die v0.1.0-Neugestaltung mehrere Suchoperationen durch eine einzige ersetzt JSON.GET durch Aufruf erheblich reduziert Latency. Redis 8.0+ enthält standardmäßig RedisJSON und RediSearch – es müssen keine zusätzlichen Module installiert werden.

Für Deployments mit begrenzter Speicherkapazität, ShallowRedisSaver Es speichert pro Thread lediglich den neuesten Checkpoint – es werden keine Historiedaten aufbewahrt, wodurch der RAM-Verbrauch auf ein Minimum reduziert wird. Verwenden Sie dieses Verfahren, wenn Sie eine Pause bzw. Wiederaufnahme benötigen, aber kein Debugging mit Rückverfolgung von Zeitpunkten erforderlich ist.

Wann welchen verwenden

Verwenden Sie PostgreSQL, wenn:

• Sie benötigen eine vollständige Historie von Checkpoint für das Debuggen im Zeitreise-Modus oder zur Gewährleistung reproduzierbarer Ergebnisse.
• Belastbarkeit ist unverzichtbar – insbesondere in Bereichen wie Finanzdienstleistungen und Gesundheitswesen.
• In Ihrem Technologiestack wird bereits PostgreSQL genutzt.
• Ihre Agent führen langwierige Aufgaben aus, bei denen ein Verlust des Zustands zu stundenlangen Neuberechnungen führt.
• Sie wünschen ein einheitlicher Datenspeicher — PostgreSQL mit pgvector kann als einziger Backend für Checkpoints, Long-Term Memory und Vector Search dienen und somit Ihre Infrastruktur vereinfachen.

Verwenden Sie Redis, wenn:

• Checkpoint Latency stellt Ihre Bottleneck dar (Echtzeit-Chat, strömende Benutzeroberfläche)
• Sie entwickeln Sprachbots – von STT zu LLM bis hin zu TTS Pipelines Sub-Millisekunden-Zugriff auf den Zustand
• Es ist eine horizontale Skalierung über viele gleichzeitige Threads erforderlich.
• Hocheffiziente Muster mit hoher Konkurrenz, bei denen mehrere Agents gemeinsam einen Zustand teilen.
• Kurzlebige Sessions, bei denen der Verlust eines Checkpoint wieder behoben werden kann.
• Es wird ein semantisches Caching gewünscht, um überflüssige Aufrufe von LLM zu reduzieren.Redis LangCache Speichert semantisch ähnliche Abfragen, um wiederholte Aufrufe von LLM zu vermeiden)

Weitere Optionen: langgraph-checkpoint-sqlite eignet sich für die lokale Entwicklung sowie für Einzelprozess-Umgebungen Deployments. Für auf AWS basierende Stack-Strukturen hingegen nicht. langgraph-checkpoint-aws bietet einen DynamoDBSaver Durch intelligente Handhabung des Payloads bleiben kleine Checkpoints-Dateien (<350 KB) in DynamoDB, während größere automatisch auf S3 verschoben werden. Die Serverless-Preisstruktur sowie das Fehlen einer zu verwalternden Infrastruktur machen diese Lösung besonders attraktiv für Anwendungen mit variabler Last Deployments.

Long-Term Memory: Merkfähigkeit über Sessions hinweg

Hinweis: Der aktuelle Gesprächsverlauf wird im „Hot Memory“ gespeichert. Wie verhält es sich jedoch mit Benutzern, die erst nächste Woche wiederkommen? Long-Term Memory speichert Fakten, Präferenzen sowie den Interaktionsverlauf, sodass diese Informationen über verschiedene Gesprächsstränge hinweg erhalten bleiben.

LangGraph stellt ein Store Interface zur Kommunikation mit Speicherinhalten zwischen Threads über dessen BaseStore Klasse. Jeder Speicherwert ist ein (namespace, key) Es wird mit einem Wert von JSON sowie optional einem Vektor Embedding gepaart. Der Namespace kodiert in der Regel den Benutzer oder die Organisation. ("user", "user-123", "preferences").

Vektor-Speicherung: semantische Abfragen mithilfe von Qdrant

Wenn der Agent unstrukturierte Fakten abrufen muss („Was hat der Benutzer bezüglich seines Investitionszeitplans gesagt?“), übernimmt der Vector Search die semantische Abfrage. Anstelle von präzisen Schlüsselabfragen führt der Agent Suchanfragen nach Bedeutung durch.

Qdrant ist ein speziell dafür entwickelter Vector Database, der in Rust geschrieben ist und sich um die Verwaltung von Embedding-Daten, das Indexieren (HNSW) sowie suchbasierte Filterung kümmert. Ich habe HNSW sowie seine Vor- und Nachteile ausführlich in meinem Suchranking-Beitrag. Qdrant bietet außerdem einen MCP-Server dies fungiert als eine Semantic Memory-Schicht – nützlich, wenn Ihr Agent Framework das Model Context Protocol unterstützt.

Von memory_store.py:

from qdrant_client import QdrantClient
from qdrant_client.models import PointStruct, Distance, VectorParams
from langchain_anthropic import ChatAnthropic
import hashlib
import json

class UserMemoryStore:
    """Long-term memory backed by Qdrant vector search.

    Stores user facts as embedded vectors for semantic retrieval.
    Each fact is a short natural-language statement about the user.
    """

    def __init__(self, qdrant_url: str, collection_name: str = "user_memory"):
        self.client = QdrantClient(url=qdrant_url)
        self.collection_name = collection_name
        self._ensure_collection()

    def _ensure_collection(self):
        """Create the collection if it doesn't exist."""
        collections = [c.name for c in self.client.get_collections().collections]
        if self.collection_name not in collections:
            self.client.create_collection(
                collection_name=self.collection_name,
                vectors_config=VectorParams(
                    size=1536,  # text-embedding-3-small dimensions
                    distance=Distance.COSINE,
                ),
            )

    def store_fact(self, user_id: str, fact: str, embedding: list[float]):
        """Store a user fact with its embedding."""
        point_id = hashlib.md5(f"{user_id}:{fact}".encode()).hexdigest()
        self.client.upsert(
            collection_name=self.collection_name,
            points=[PointStruct(
                id=point_id,
                vector=embedding,
                payload={"user_id": user_id, "fact": fact},
            )],
        )

    def recall(self, user_id: str, query_embedding: list[float], top_k: int = 5):
        """Retrieve the most relevant facts for a user given a query."""
        results = self.client.query_points(
            collection_name=self.collection_name,
            query=query_embedding,
            query_filter={"must": [{"key": "user_id", "match": {"value": user_id}}]},
            limit=top_k,
        )
        return [hit.payload["fact"] for hit in results.points]

Der Ablauf ist wie folgt: (1) Nach jeder Konversation extrahiert ein LLM die wichtigsten Fakten aus der Interaktion („der Nutzer hat eine hohe Risikotoleranz“, „der Nutzer ist an Halbleiteraktien interessiert“), (2) diese Fakten werden in Qdrant eingebettet und gespeichert, (3) zu Beginn der nächsten Konversation fragt der Agent Qdrant mit der neuen Nachricht des Nutzers ab, um den relevanten Kontext abzurufen.

Retrieval Scoring: Jenseits der Kosinusähnlichkeit

Die reine kosinusähnliche Ähnlichkeit stellt zwar einen Ausgangspunkt dar, doch Produktionsmemoriesysteme benötigen umfangreichere Retrieval. Die Generatives Agents-Paper (Park et al., 2023) stellten eine Bewertungsfunktion vor, die drei Signale miteinander verbindet:

• Aktualität: regelbasierte Abklingung, wodurch kürzlich erinnerte Informationen eine höhere Bewertung erhalten. Eine exponentielle Abklingungsfunktion sorgt dafür, dass ein gestriger Sachverhalt einer gleichwertigen Information von vor sechs Monaten vorgezogen wird.
• Bedeutung: auf einer Skala von 1 bis 10 bewertete Wichtigkeit gemäß LLM. „Das Portfolio des Benutzers ist um 40 Prozent gefallen“ erhält eine höhere Bewertung als „Der Benutzer hat Hallo gesagt“.
• Relevanz: Embedding-basierte Kosinusähnlichkeit zwischen der Abfrage und der gespeicherten Information.

Der endgültige Wert von Retrieval ist eine gewichtete Summe: score = alpha * recency + beta * importance + gamma * relevance. Dadurch werden aktuelle, wichtige Fakten daran gehindert, unter veralteten, aber semantisch ähnlichen Informationen begraben zu werden. Für den Marktanalyst Agent, Die Weight weist die höchste Gewichtung auf (0,5), gefolgt von Aktualität (0,3) und Relevanz (0,2), da die aktuelle Abfragedynamik des Benutzers am wichtigsten ist. Dabei handelt es sich um Ausgangswerte für Weights, die aus dem Paper zur generativen Agents übernommen wurden (in dem alle Faktoren gleich gewichtet wurden). Ich stellte fest, dass eine Betonung der Relevanz bei Abfragen im Bereich Finanzanalyse bessere Ergebnisse liefert, wobei die zugewiesenen Werte eher auf Intuition beruhen als auf empirischer Optimierung.

Alternative zu Vector Search

Vector Search ist leistungsstark, stellt jedoch nicht immer das geeignete Werkzeug dar. Hier sind die Fälle, in denen man auf Alternativen zurückgreifen sollte:

Schlüssel-Wert-Speicher eignen sich hervorragend für strukturierte Daten. Wenn Ihr Long-Term Memory ein Benutzerprofil darstellt – mit Angaben zur Risikotoleranz, Investitionshorizont und bevorzugten Branchen – sind Redis-Hashes oder PostgreSQL-JSONB-Spalten einfacher und schneller zu verwalten als Embedding sowie das Abfragen von Vektoren. Wenden Sie Vector Search an, wenn die Daten unstrukturiert sind und die Retrieval-Abfragen in ihrer Formulierung variieren.

LangGraphs eingebaute Store bietet eine namensbasierte Schlüssel-Wert-Schnittstelle mit optionaler Vector Search-Unterstützung. Die BaseStore API ist einfach: put(), get(), search(), und delete() mit hierarchischem Namensraumskoping. Es stehen drei Implementierungen zur Verfügung:

• InMemoryStore — zur Entwicklung und zum Testen (Daten gehen bei Beendigung des Prozesses verloren) PostgresStore — Produktivspeicher mit vollständiger Unterstützung für SQL-Abfragen AsyncRedisStore — mehrthreadige Speicherzugriffe mithilfe von Vector Search, TTL-Unterstützung sowie Filterung von Metadaten

Der index Durch die Konfiguration wird es möglich, über gespeicherte Elemente mithilfe eines konfigurierbaren Embedding Model auf Vector Search zuzugreifen. Für viele Anwendungsfälle reicht dieser eingebaute Speicher aus, ohne dass ein spezieller Vector Database erforderlich ist.

from langgraph.store.memory import InMemoryStore

# Create a store with vector search enabled
store = InMemoryStore(
    index={
        "dims": 1536,
        "embed": my_embedding_function,  # e.g., OpenAI text-embedding-3-small
    }
)

# Store a user preference (namespace scopes to user)
await store.aput(
    namespace=("user", "user-123", "preferences"),
    key="risk-profile",
    value={"risk_tolerance": "high", "horizon": "long-term"},
)

# Semantic search across user's memories
results = await store.asearch(
    namespace=("user", "user-123"),
    query="What is their investment style?",
    limit=5,
)

Auswahl einer Long-Term Memory-Strategie

Beginnen Sie mit Schlüssel-Wert-Paaren, wenn Ihr Speicher strukturiert und klar definiert ist (z. B. Benutzerprofile, Einstellungen, benannte Entitäten). Fügen Sie Vector Search hinzu, wenn Sie semantische Retrieval-Informationen zu unstrukturierten Fakten benötigen oder die Formulierung der Abfragen unvorhersehbar variiert.

Wissensgraphen sind von Nutzen, wenn die Beziehungen zwischen Entitäten entscheidend sind – beispielsweise bei der Frage „Welche Unternehmen, nach denen der Benutzer gefragt hat, sind Konkurrenten von NVDA?“ Das interessanteste aktuelle Projekt in diesem Bereich ist Graphiti (von Zep), welcher einen zeitbewussten Wissensgraphen erstellt, der nicht nur festhält, was wahr ist, sondern auch wann die Fakten zutrafen. Jede Kante verfügt über Gültigkeitsintervalle, sodass eine Änderung der Risikotoleranz des Benutzers den alten Wert ungültig macht, anstatt ihn stillschweigend zu überschreiben. Graphiti liefert Berichte darüber. 94,8 % Genauigkeit auf dem DMR Benchmark, und sein bi-temporales Model-Konzept bewältigt das Problem veralteter Daten im Datenlayer.

Das Problem liegt im Betrieb. Der Betrieb einer Graph-Datenbank ist keineswegs trivial, und für die meisten Agent-Anwendungen erfüllt Vector Search das Filtern von Metadaten denselben Zweck bei geringerer Infrastrukturlast.

Gemanagte Speicher Frameworks wie Mem0 und Letta (formerly MemGPT) übernehmen die Extraktion-Konsolidierung-Retrieval Pipeline für Sie. Der Ansatz von Mem0 zeichnet sich dadurch aus, dass ein LLM potenzielle Erinnerungen extrahiert, ein Entscheidungsmechanismus jeden neuen Fakt mit den vorhandenen Einträgen im Vector Store vergleicht und schließlich ein Resolver entscheidet, ob dieser hinzugefügt, aktualisiert oder gelöscht werden soll – wodurch der Speicher kohärent und frei von Redundanzen bleibt. Letta verfolgt einen Ansatz aus der Betriebssystemtechnik: Agents verwalten ihre eigenen Context Window mithilfe von Speichermanagement-Tools und bewegen Daten autonom zwischen dem „Kernspeicher“ (im Kontext) und dem „Archivspeicher“ (außerhalb des Kontexts). Beide Lösungen lohnen eine Bewertung, falls Sie eine schnellere Zeit bis zur Produktivsetzung anstreben und keine vollständige Kontrolle über den Speicher Pipeline benötigen.

Dokumentenmemorie: der Aktenschrank des Agent

Die auf Dateien basierende Speicherlösung weist in den oben genannten Speichertaxonomien eine höhere Verbreitung als einen umfassenderen Abdeckungsgrad auf. In einer von einem Hersteller durchgeführten LoCoMo-Bewertung Letta hat berichtet. 74,0 % für seinen Dateisystem-Ansatz. Es muss sichergestellt werden, dass dieses Ergebnis innerhalb der Bedingungen von Model, Benchmark und Harness bleibt, doch der operative Vorteil ist offensichtlich: Entwickler können das gespeicherte Wissen direkt lesen, bearbeiten und vergleichen.

Längere Context Windows machen das Lesen ganzer Dateien für bestimmte Projektdokumente praktikabel. In Blöcken strukturierte Retrieval-Methoden eignen sich weiterhin für große Korpora, doch kurze Konventions- oder Übergabedateien können häufig direkt geladen werden. Die Wahl hängt von der Größe des Dokuments, der Retrieval-Genauigkeit, dem verfügbaren Kontextbudget sowie davon ab, wie oft die darin enthaltenen Informationen überprüft oder geändert werden müssen.

Vector Stores sowie Schlüssel-Wert-Paare Backends kann semantische Abrufmechanismen sowie strukturierte Abfragen effektiv handhaben. Es gibt jedoch eine dritte Kategorie von Agent Kenntnisse, die nicht sauber abgebildet werden können: der akkumulierte Projektkontext – also die Konventionen, Forschungsnotizen sowie Entscheidungen, die im Laufe der Zeit entstehen. Agent notwendige Anforderungen auf verschiedenen Ebenen Sessions und sie profitieren davon, menschenlesbar sowie versioniert zu sein.

Dies ist die Dokumentenmemorie: Der Agent liest und schreibt strukturierte Dateien (Markdown, JSON, YAML) in einen definierten Verzeichnisort. Es gibt weder Embeddings noch Datenbanken oder Infrastruktur – lediglich Dateien auf der Festplatte, die sowohl der Agent als auch der Entwickler nutzen können. cat, grep, git diffund manuell bearbeiten.

Warum Dateien?

für langlebige Agent Workflows, das effektivste Muster, das ich je gesehen habe, ist kein Vector Database. Es handelt sich um einen ordentlich strukturierten Ordner mit Notizen. Betrachten Sie, was geschieht, wenn beim Programmieren Agent arbeitet wochenlang an einem Projekt:

• Es erkennt, dass das Projekt Pydantic v2 und nicht v1 verwendet.
• Es stellt fest, dass die Tests mit … ausgeführt werden müssen. pytest -x --tb=short
• Es sammelt Wissen über die Architektur der Codebasis.
• Es lernt die Präferenzen des Entwicklers kennen („immer verwenden“). pathlib, niemals os.path”)

Diese Fakten weisen eine zu starre Struktur auf, um mit Vector Search verarbeitet zu werden (es wird eine exakte Wiedererkennung benötigt, keine verschwommene Ähnlichkeit), und ihre Anzahl ist zu groß für einen Schlüssel-Wert-Speicher – schließlich bilden sie voneinander verbundene Dokumente statt isolierter Fakten. Zudem sind es Fakten, die der Entwickler direkt einsehen und bearbeiten möchte. Falls der Agent etwas falsch lernt, öffnet man einfach die Datei und korrigiert den Fehler.

So sieht es aus. Claude Code’s CLAUDE.md und .claude/ Verarbeitung von Verzeichnissen. Der Agent liest auf Projektebene. CLAUDE.md Dateien für Konventionen und Anweisungen sowie Schreibvorgänge in ~/.claude/MEMORY.md zur Übertragung von Wissen zwischen den Session. Die Dateien sind im reinen Markdown-Format: Sie lesen sie, bearbeiten sie, speichern sie in Git und teilen sie mit Ihrem Team. Der Cursor .cursorrules und Windsurfen .windsurfrules einfache Textdateien, die der Agent beim Start lädt, um den Projektkontext zu erfassen.

Implementierung eines Dateimemoriestores

Die Implementierung ist absichtlich schlicht gehalten. Der Agent bietet vier Operationen: das Schreiben eines Dokuments, das Lesen eines Dokuments, die Auflistung verfügbarer Dokumente sowie die Suche in den Dokumenten nach Schlüsselwörtern.

Von file_memory.py:

from pathlib import Path
import json
import fnmatch

class FileMemory:
    """Document memory backed by the local filesystem.

    Stores agent knowledge as human-readable files organized by topic.
    No embeddings, no database — just files that both the agent and
    the developer can read, edit, and version-control.
    """

    def __init__(self, base_dir: str | Path):
        self.base_dir = Path(base_dir)
        self.base_dir.mkdir(parents=True, exist_ok=True)

    def write_doc(self, path: str, content: str, metadata: dict | None = None):
        """Write or overwrite a document at the given path.

        Paths are relative to base_dir. Directories are created automatically.
        Metadata (if provided) is stored as a JSON sidecar file.
        """
        full_path = self.base_dir / path
        full_path.parent.mkdir(parents=True, exist_ok=True)
        full_path.write_text(content, encoding="utf-8")

        if metadata:
            meta_path = full_path.with_suffix(full_path.suffix + ".meta")
            meta_path.write_text(json.dumps(metadata, indent=2), encoding="utf-8")

    def read_doc(self, path: str) -> str | None:
        """Read a document by path. Returns None if not found."""
        full_path = self.base_dir / path
        if full_path.exists():
            return full_path.read_text(encoding="utf-8")
        return None

    def list_docs(self, pattern: str = "**/*") -> list[str]:
        """List documents matching a glob pattern."""
        return [
            str(p.relative_to(self.base_dir))
            for p in self.base_dir.glob(pattern)
            if p.is_file() and not p.name.endswith(".meta")
        ]

    def search_docs(self, query: str, pattern: str = "**/*.md") -> list[dict]:
        """Search documents by keyword. Returns matching files with context.

        This is intentionally simple — grep-style keyword search.
        For semantic search, use a vector store instead.

        NOTE: This is a sketch for demonstration. A simple substring check
        won't scale beyond a few hundred documents. For production with 500+
        documents, use TF-IDF/BM25 scoring (e.g., rank_bm25) or a full-text
        search backend (PostgreSQL GIN index, Elasticsearch).
        """
        results = []
        for path in self.base_dir.glob(pattern):
            if not path.is_file() or path.name.endswith(".meta"):
                continue
            content = path.read_text(encoding="utf-8")
            if query.lower() in content.lower():
                # Return the paragraph containing the match for context
                for paragraph in content.split("\n\n"):
                    if query.lower() in paragraph.lower():
                        results.append({
                            "path": str(path.relative_to(self.base_dir)),
                            "match": paragraph.strip()[:500],
                        })
        return results

Ordnerstruktur

Der größte Teil des Wertes der Dokumentenerinnerung ergibt sich aus der Strukturierung des Verzeichnisses. Hier ist die Struktur, die ich verwende für den Marktanalyst Agent:

.agent-memory/
    README.md                  # What this directory is, for human readers
    user-profiles/
        user-123.md            # Preferences, history, risk profile
        user-456.md
    research/
        NVDA-2026-02.md        # Research notes from recent analysis
        TSLA-2026-01.md
    conventions/
        analysis-format.md     # How to structure analysis reports
        data-sources.md        # Preferred data sources and API patterns
    learnings/
        common-errors.md       # Mistakes the agent has learned to avoid
        tool-patterns.md       # Effective tool call sequences

Jeder Datei liegt ein Markdown-Format vor. Der Zweck jeder Datei geht aus ihrem Pfad hervor. Sie können git diff den gesamten Speicherverzeichnis, um zu erkennen, was der Agent im Rahmen eines Session gelernt hat. git revert Bei einem fehlerhaften Lernvorgang kann es hilfreich sein, den Ordner in ein anderes Projekt zu kopieren. Versuchen Sie, eines dieser Verfahren mit einer Qdrant-Kollektion auszuprobieren.

Wann sollte man Dokumentenmemoria, Vektoren oder Schlüssel-Wert-Paare verwenden?

Die drei Speicher Backends weisen unterschiedliche Zugriffsmuster auf:

Verwenden Sie die Dokumentenerinnerung, wenn:

• Der Agent sammelt über mehrere Sessions hinweg Projektwissen an.
• Entwickler müssen prüfen, ändern oder überschreiben, was der Agent „weiß“.
• Das Wissen ist als Dokumente (Notizen, Zusammenfassungen, Konventionen) strukturiert und nicht als isolierte Fakten.
• Man wünscht eine auf Git basierende Versionierung von Agent Memory.
• Eine Infrastruktur ohne externe Komponenten ist eine strenge Voraussetzung.

Verwenden Sie Vector Stores, wenn:

• Es wird eine verschwommene semantische Suche nach Retrieval benötigt („Erinnerungen, die mit X zusammenhängen, finden“).
• Die Formulierung der Abfragen variiert unvorhersehbar.
• Es stehen Tausende bis Millionen einzelner Fakten zur Verfügung.

Verwenden Sie Key-Value-Speicher, wenn:

• Für strukturierte Daten (Benutzerprofile, Einstellungen) sind präzise und schnelle Abfragen erforderlich.
• Das Datenschema ist klar definiert.

In der Praxis kombinieren Produktionsumgebungen Agents häufig alle drei Ansätze. Marktanalyst Agent Es wird PostgreSQL Checkpoints zur Verwaltung des Hot-Memory-Speichers, Qdrant zur effizienten Abfrage semantischer Benutzerdaten sowie ein auf Dateien basierender Dokumentenspeicher für Projektstandards und Forschungsnotizen genutzt.

Beispiele aus der Praxis

Das Muster ist bereits weit verbreitet in den AI-Coding-Assistenten:

• Claude Code liest ein CLAUDE.md Fächer aus dem Projektwurzelverzeichnis sowie den übergeordneten Verzeichnissen und schreibt in ~/.claude/MEMORY.md zur Übertragung von Erkenntnissen zwischen Session. Das gesamte Speichersystem besteht aus gewöhnlichen Markdown-Dateien, die Sie zusammen mit Ihrem Code speichern.
• Cursor lädt ein .cursorrules Dateien für projektbezogene Agent-Anweisungen: Codierkonventionen, Framework-Einstellungen sowie architektonische Entscheidungen.
• Windsurf verwendet .windsurfrules Dateien plus ein memories/ Verzeichnis, in dem der Agent die aus Ihrer Codebasis gelernten Muster speichert.
• Anthropics Speichermittel für den Claude API bietet create_memory, read_memory, update_memory, und delete_memory Die Operationen werden auf der Client-Seite ausgeführt. Ihre Anwendung bestimmt, wo die Dateien tatsächlich gespeichert sind – auf der lokalen Festplatte, in S3 oder in einer Datenbank.

Der gemeinsame Nenner: All diese Ansätze speichern Agent-Wissen als für Menschen lesbare Textdateien mit expliziten Lese-/Schreiboperationen. Es gibt keine Embeddings. Auch keine Vektorinfrastruktur. Der Agent entscheidet, was geschrieben wird, der Entwickler kann alles einsehen und bearbeiten, und das gesamte System passt in einen git diff.

Jenseits von Code-Assistenten

Das Dokumentenmemory ist nicht auf das Programmieren beschränkt Agents. Dieses Muster tritt in völlig unterschiedlichen Agent Domänen auf:

• Offenes Spielweltspiel Agents: Voyager (Wang et al., 2023) entwickeln eine dauerhafte Fähigkeitsbibliothek aus überprüften JavaScript-Programmen, die ein Minecraft Agent im Laufe der Zeit sammelt. Auf diese Weise werden 3,3-mal mehr einzigartige Elemente erfasst und Meilensteine 15,3-mal schneller erreicht als bei den Baseline-Szenarien. Die erlernten Fähigkeiten können auf neue Welten übertragen werden, ohne dass ein erneutes Trainieren erforderlich ist. JARVIS-1 Erweitern Sie dies um ein multimodales Gedächtnis, das textbasierte Pläne mit visuellen Beobachtungen verbindet, wodurch bei den schwierigsten Aufgaben eine Erfolgsrate von 5 Mal erreicht wird.

  Ein Unterschied, der hier hervorgehoben werden sollte: Skill-Bibliotheken sind ausführbare Speicherinhalte (importierte und ausgeführte Code-Dateien), während der Dokumentenspeicher in Coding-Assistenz-Tools deklarativ strukturiert ist (Markdown-Texte, die in Prompts eingefügt werden). Die Fehlermuster unterscheiden sich dabei. Schlechter ausführbarer Code führt zum Absturz des Agent, während fehlerhafter deklarativer Text zu Reasoning-Fehlern führt. Dennoch sind das Speichermuster sowie die betrieblichen Vorteile – wie Debuggierbarkeit und Versionskontrolle – identisch.

• Unternehmensweite Workflow-Automatisierung: Die Wettbewerb ECR3 Die Gewinner setzten die Dokumentenerinnerung ein, um eine iterative Prompt-Verfeinerung durchzuführen. Der Analyzer sowie der Versioner einer der siegreichen Teams Agents durchforsteten insgesamt 80 Prompt Versionen, die als prozedurale Dokumente gespeichert waren. Ein weiteres führendes Team entwickelte mehr als 20 Erweiterungsmodule, die als dokumentbasiertes prozedurales Wissen fungierten. LEGOMem (2025) formalisiert dies als eine modulare Speicherstruktur Framework für multi-agent-Systeme, wobei spezialisierte Speichertypen (sensorisch, kurzfristig, langfristig) vorhanden sind, die sich wie Bausteine Agents zusammensetzen lassen.

• Web-Automatisierung: Agent Workflow Speicher (Wang et al., 2024) ermöglicht es Web Agents, wiederverwendbare Workflows aus erfolgreichen Szenarien abzuleiten, was zu einer Steigerung der Erfolgsrate um 51 % auf WebArena führt. SkillWeaver (2025) geht noch einen Schritt weiter: Agents ermöglicht es, aus den Erkundungsergebnissen wiederverwendbare API-Tools zu synthetisieren, wodurch sich die Erfolgsrate um 31,8 % erhöht. Die erlernten Fähigkeiten übertragen sich zudem auf schwächere Models-Systeme (Verbesserung um 54,3 %), sodass das angesammelte Wissen eines leistungsstärkeren Agent dazu beitragen kann, das Niveau eines kleineren Systems zu heben.

• Kundensupport: Gartner prognostiziert Dieser AI Agents wird bis 2029 autonom 80 Prozent der gängigen Kundenservice-Probleme lösen. Dabei greift er auf Agents – also Referenz-SOPs, Playbooks sowie Kundenhistorien – zurück, die alle als Formen einer Dokumentenerinnerung fungieren.

Der Workshop „MemAgents“ auf dem ICLR 2026 Ein Zeichen dafür, dass die Forschungsgemeinschaft allmählich aufschließt an das, was die Praktiker bereits entwickelt haben, ist zweifellos die Tatsache, dass Dokumentenmemorien ihre ursprünglichen Aufgaben als Code-Assistenten längst überschritten haben.

Fähigkeiten nutzen Dokumente, um prozedurale Anweisungen zu verpacken. Der Agent Fähigkeitsstandard speichert diese Anweisungen in SKILL.md Dateien mit YAML-Frontmatter sowie einem Markdown-Körper. Dies entspricht auf der Speicherschicht einer Dokumentenerinnerung, erfüllt jedoch eine andere Funktion: Eine Skill weist den Agent an, wie eine bestimmte Art von Aufgabe ausgeführt werden soll, während die Erinnerung Fakten speichert, die aus einem Projekt oder einer früheren Ausführung gelernt wurden. Teil 3 er behandelt diesen Unterschied aus Sicht der Tool-Plattform.

MCP (Model Kontextprotokoll) verläuft in dieselbe Richtung: Die Tool-Definitionen sind JSON Schema-Dateien, die jedes Agent entdecken und aufrufen kann. Das Protokoll verfügt über 97 Millionen monatliche Downloads von SDK und wird von OpenAI, Google, Microsoft sowie AWS unterstützt. MCP ist nicht auf die Programmierung beschränkt. Diese gleichen Server verbinden Agents mit Datenbanken, internen APIs sowie Unternehmenssystemen.

Beide deuten auf dasselbe Muster hin: Prozedurales Wissen, das als durch Schemata gestützte Dokumente gespeichert wird und über explizite Lese-/Schreiboperationen verfügt. MCP, wird nun durch die Agentic AI Grundlage, Es handelt sich dabei um das dem Interoperabilitätsstandard am nächsten kommende Element im Agent-Ökosystem.

Skalierung der Dokumentenmemorie für die Produktion

Die oben beschriebene dateibasierte Implementierung eignet sich gut für Laptops einzelner Entwickler sowie für kleinere Deployments-Systeme. Für produktionsebene Umgebungen mit mehreren Nutzern und Tausenden von Dokumenten ist hingegen eine völlig andere Architektur erforderlich.

Die Einschränkungen bei Dateien auf einem einzigen Knoten werden schnell deutlich: Es ist nicht möglich, die Datei-E/S horizontal zu skalieren, konkurrierende Schreibvorgänge erfordern Sperren, und das Verwalten von Berechtigungen für verschiedene Nutzergruppen ist äußerst aufwendig. Für die Produktion ist daher ein Backend-Speicher erforderlich, der Konkurrenzsituationen, Suchfunktionen sowie das Multi-Tenancy-Modell ordnungsgemäß handhaben kann.

Drei gängige Ansätze:

Ansatz A: Hybrid mit einer dünnen Datenbankschicht

Bewahren Sie die Dateien für die Erstellung auf (Entwickler bearbeiten den Markdown lokal), doch liefern Sie sie über eine Datenbank bei Runtime aus. Auf Deployment werden die Dateien mit den Zeilen in PostgreSQL synchronisiert. Der Agent liest von der Datenbank und nicht vom Festplattenspeicher. Dadurch erhalten Sie:

• Entwicklerergonomie (Bearbeiten von Markdown, Commit in Git)
• Leistung von Abfragen in der Produktion (Lesevorgänge aus indizierten Datenbanken)
• Saubere Trennung zwischen Erstellung und Serving

Ansatz B: Objektspeicherung + Vector-Index-Sidecar

Dokumente werden als Objekte in S3/GCS gespeichert, wobei eine Qdrant-Kollektion deren Embeddings indiziert. Die Agent suchen in Qdrant nach den entsprechenden Dokument-ID‑Werten und holen anschließend den Inhalt aus dem Objektspeicher ab. Dieser Ansatz ermöglicht horizontales Skalieren und unterstützt Semantic Search, führt jedoch zu zusätzlicher Komplexität: Es müssen zwei Systeme verwaltet werden, ein Embedding Pipeline muss aufrechterhalten werden, und es besteht die Notwendigkeit, eine eventuelle Konsistenz zwischen Speicher und Index sicherzustellen.

Ansatz C: strukturierte Dokumentenlagerung mit PostgreSQL (empfohlen)

Speichern Sie Dokumente als PostgreSQL-JSONB-Spalten mit Volltextsuche (GIN-Index) sowie optionalen Vektordaten Embeddings (pgvector). Dadurch erhalten Sie eine hybride Suchfunktion (Schlüsselwörter + Semantik), ACID-konforme Transaktionen sowie ein einheitliches Betriebssystem.

Ein Überblick über Ansatz C:

from typing import Optional
import asyncpg

class ProductionDocumentMemory:
    """PostgreSQL-backed document memory with hybrid search.

    Schema:
        CREATE TABLE documents (
            id SERIAL PRIMARY KEY,
            tenant_id TEXT NOT NULL,
            path TEXT NOT NULL,
            content TEXT NOT NULL,
            metadata JSONB,
            embedding vector(1536),  -- pgvector extension
            ts_vector tsvector GENERATED ALWAYS AS (to_tsvector('english', content)) STORED,
            created_at TIMESTAMPTZ DEFAULT NOW(),
            UNIQUE(tenant_id, path)
        );
        CREATE INDEX ON documents USING GIN(ts_vector);
        CREATE INDEX ON documents USING ivfflat(embedding vector_cosine_ops);
    """

    def __init__(self, pool: asyncpg.Pool):
        self.pool = pool

    async def write(
        self,
        tenant_id: str,
        path: str,
        content: str,
        metadata: Optional[dict] = None,
        embedding: Optional[list[float]] = None,
    ):
        """Write or update a document."""
        async with self.pool.acquire() as conn:
            await conn.execute(
                """
                INSERT INTO documents (tenant_id, path, content, metadata, embedding)
                VALUES ($1, $2, $3, $4, $5)
                ON CONFLICT (tenant_id, path) DO UPDATE
                SET content = EXCLUDED.content,
                    metadata = EXCLUDED.metadata,
                    embedding = EXCLUDED.embedding
                """,
                tenant_id, path, content, metadata, embedding,
            )

    async def search(
        self,
        tenant_id: str,
        query: str,
        embedding: Optional[list[float]] = None,
        limit: int = 5,
    ) -> list[dict]:
        """Hybrid search: full-text + optional vector similarity."""
        async with self.pool.acquire() as conn:
            if embedding:
                # Hybrid scoring: 0.6 * text relevance + 0.4 * vector similarity
                rows = await conn.fetch(
                    """
                    SELECT path, content, metadata,
                           (0.6 * ts_rank(ts_vector, plainto_tsquery('english', $2)) +
                            0.4 * (1 - (embedding <=> $3))) AS score
                    FROM documents
                    WHERE tenant_id = $1
                      AND ts_vector @@ plainto_tsquery('english', $2)
                    ORDER BY score DESC
                    LIMIT $4
                    """,
                    tenant_id, query, embedding, limit,
                )
            else:
                # Full-text search only
                rows = await conn.fetch(
                    """
                    SELECT path, content, metadata,
                           ts_rank(ts_vector, plainto_tsquery('english', $2)) AS score
                    FROM documents
                    WHERE tenant_id = $1
                      AND ts_vector @@ plainto_tsquery('english', $2)
                    ORDER BY score DESC
                    LIMIT $3
                    """,
                    tenant_id, query, limit,
                )
            return [dict(row) for row in rows]

Was Sie erhalten:

• Hybride Suche: Schlüsselwortabgleich (GIN-Index) + semantische Ähnlichkeit (pgvector), wobei beide Bewertungen zusammengeführt werden
• Multi-Tenancy: tenant_id Bereichsdefinition unter Verwendung von Zeilenbereichssicherheit
• ACID-Garantien: Keine Probleme bezüglich eventueller Konsistenz
• Einziges Betriebssystem: Kein separater Vector Database zur Verwaltung erforderlich
• Horizontale Skalierung: Lese-Replikas zur Bewältigung der Abfragedatenlast sowie Partitionierung nach Nutzern zur Steigerung der Schreibleistung

Dateien eignen sich hervorragend für Einzelentwickler Workflows. In produzierenden Umgebungen mit mehreren Nutzern stellt ein strukturiertes Dokumentenspeichersystem auf PostgreSQL in der Regel das richtige Gleichgewicht aus Einfachheit, Leistung und betrieblicher Reife dar.

Zusammenfassung: Die vollständige Architektur

So arbeiten alle drei Speicherebenen zusammen im Marktanalyst Agent. Das Diagramm veranschaulicht den vollständigen Ablauf von der Benutzeranfrage bis zur Antwort, wobei alle Speicherschichten aktiv sind.

Die Architektur verfügt über drei Speicherpfade:

1. Hot Path (Checkpoint Store): Jeder Knoten im LangGraph schreibt seinen wieder aufnehmbaren Graphenzustand in den Checkpoint Store. Wenn der Graph auf ein interrupt_before Node (ähnlich dem Reporter in Teil 1), Es kommt zu Ausführungspausen. Der Benutzer kann die Anwendung schließen, und wenn er zurückkehrt, setzt das Diagramm seine Darstellung an der Stelle fort, an der es beim Checkpoint aufgehört hat. Die Protokollierung von Runtime-Ereignissen sowie die Verwaltung von Traces sind eigenständige Aspekte der Produktionssicherheit.

2. Kalte Pfade (langfristiger Speicher): Zu Beginn jeder Konversation fragt der Agent den langfristigen Speicher nach relevantem Benutzerkontext ab. Am Ende werden neue Fakten extrahiert und dort gespeichert. Dieser Vorgang läuft asynchron – er darf auf keinen Fall den Hauptprozess des Reasoning Loop blockieren.

3. Dokumentenpfad (Dateispeicher): Beim Start lädt der Agent die Projektkonventionen sowie relevante Forschungsnotizen aus dem Dateispeicher. Während der Ausführung schreibt er neue Forschungszusammenfassungen sowie erlernte Muster wieder auf die Festplatte. Im Gegensatz zum „cold path“ sind die Lesevorgänge von Dokumenten synchron (sie beeinflussen die laufende Aufgabe), während Schreibvorgänge verschoben werden können.

Die Verkabelung in LangGraph ist unkompliziert – der Checkpoint Store sowie der Langzeit-Store werden bei der Kompilierung des Graphen übergeben, während der Dokumentenspeicher als Abhängigkeit eingefügt wird. Der untenstehende lokale Entwurf verwendet InMemoryStore Damit der Codeausschnitt klein bleibt, verwendet die Referenz-Docker-Topologie Qdrant für dieselbe Aufgabe der semantischen Aufrufrate.

from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver
from langgraph.store.memory import InMemoryStore

# Hot memory: PostgreSQL for durable checkpoints
checkpointer = await create_postgres_checkpointer(pg_connection_string)

# Cold memory: local sketch with vector search
# (The reference Docker topology uses Qdrant for persistent recall.)
memory_store = InMemoryStore(
    index={"dims": 1536, "embed": embedding_function}
)

# Document memory: file-based store for project knowledge
doc_memory = FileMemory(base_dir=".agent-memory")

# Checkpoint store and long-term store wired into the graph
graph = create_graph(
    checkpointer=checkpointer,
    store=memory_store,
)

# The store is accessible inside any node via the store parameter
def planner_node(state: AgentState, *, store: BaseStore) -> dict:
    """Plan with user context from long-term memory."""

    # Recall relevant user facts from vector store
    user_memories = store.search(
        namespace=("user", state.user_id),
        query=state.messages[-1].content,
        limit=5,
    )

    # Load project conventions from document memory
    conventions = doc_memory.read_doc("conventions/analysis-format.md")

    # Inject both into planning context
    memory_context = "\n".join(m.value["fact"] for m in user_memories)
    # ... rest of planning logic with personalized context and conventions

Der vollständige Ablauf

Was geschieht, wenn ein zurückkehrender Benutzer „Analyze TSLA“ sendet? Marktanalyst Agent:

1. Dokumenten-Memory-Auslastung: Beim Start liest der Agent die Projektkonventionen aus dem Dokumentenspeicher ein – darunter Vorlieben bezüglich der Analyseformatierung, bevorzugte Datenquellen sowie Muster im Toolgebrauch. Diese Informationen legen das Basiseverhalten fest.

2. Kalte Speicherabrufung: Bevor der Router-Node ausgeführt wird, fragt das Graph das Langzeitspeichersystem mit der Nachricht des Benutzers ab. Dabei werden folgende Informationen abgerufen: „Der Benutzer weist eine hohe Risikotoleranz auf“, „Der Benutzer bevorzugt detaillierte Wettbewerbsanalysen“ sowie „Der Benutzer hat zuvor NVDA und AMD recherchiert“.

3. Router + Planner: Die Router klassifiziert dies als DEEP_RESEARCH. Der Planner erstellt einen 5-stufigen Forschungsplan, der den ermittelten Präferenzen angepasst ist. Er umfasst außerdem eine Schritt der Wettbewerbsanalyse, da die Nutzerhistorie zeigt, dass dieser gewünscht wird. Der Plan folgt dem Format aus dem Konventionsdokument.

4. Executor-Schleife (heiße Speicher): Jeder Schritt wird über das ReAct-Muster ausgeführt Teil 1. Nach jedem Knoten (Router, Planner, jeder Executor Schritt) schreibt LangGraph einen Checkpoint in PostgreSQL. Sollte der Prozess nach Schritt 3 von insgesamt 5 abbrechen, startet man ihn erneut und setzt mit Schritt 4 fort.

5. HITL-Interrupt: Der Graph erreicht den reporter Node mit interrupt_before. Der Entwurf des Berichts befindet sich in dem Checkpoint. Der Benutzer prüft ihn einige Stunden später, wobei die Grafik aus dem Checkpoint geladen wird und die Verarbeitung fortgesetzt wird.

6. Speicheraktualisierungen: Nach Beendigung des Gesprächs: (a) ein asynchroner Prozess extrahiert neue Benutzerfakten („Der Benutzer verfolgt nun TSLA“, „Der Benutzer hat das Berichtsformat genehmigt“) und speichert sie im langfristigen Vector Store, sowie (b) der Agent schreibt eine Forschungszusammenfassung in den Dokumentenspeicher.research/TSLA-2026-02.md) zur zukünftigen Referenz.

Das dreistufige Muster trennt die Aufgabenbereiche klar voneinander. Der Checkpoint-Speicher ist für Langlebigkeit und Wiederaufnahme zuständig; er gehört zur Infrastruktur. Der Langzeitspeicher kümmert sich um Personalisierung; er stellt die Produktlogik dar. Der Dokumentenspeicher enthält das angesammelte Projektwissen; er fungiert als Notizbuch des Agent.

Abwägungen und zu berücksichtigende Aspekte

Speicher fügt Wert hinzu, verursacht aber gleichzeitig Kosten und erhöht die Komplexität. Seien Sie ehrlich bezüglich der Abwägungen:

• Embedding-Kosten: Jeder in einem Vector Database gespeicherte Datensatz erfordert einen Aufruf von Embedding API. Die Kosten betragen 0,02 US-Dollar pro Million Tokens (OpenAI) text-embedding-3-small), der tatsächliche Kostenfaktor ist vernachlässigbar, kumuliert sich jedoch bei Tausenden von Nutzern und Sessions. Führen Sie Embedding-Aufrufe in Batches durch und cachen Sie die Ergebnisse. Der eigentliche Kostenfaktor liegt bei Latency: 100–300 ms an Embedding API Latency-Zeit beim Abrufen aus dem kühlen Speicher, was für Echtzeit-Dialogsysteme mit Agents wichtiger ist als die monetäre Kostenbelastung. Cachen Sie Embeddings für häufig gestellte Anfragen oder verwenden Sie einen lokalen Embedding Model für arbeitsintensive Aufgaben, bei denen Latency eine Rolle spielt.

• Veraltete Speicherdaten: Die Präferenzen des Benutzers ändern sich. Eine vor sechs Monaten gespeicherte Tatsache wie „Der Benutzer bevorzugt konservative Anlagen“ ist möglicherweise nicht mehr aktuell. Es sollten Ablaufregeln festgelegt werden. Ich verwende für Präferenzen einen Zeitraum von 365 Tagen und für einmalige Ereignisse 90 Tage, wie in meiner Dokumentation beschrieben. Context Engineering-Beitrag.

• Speicherkosten im Kontext: Jeder abgerufene Fakt verbraucht Tokens im LLM’s Context Window. Wenn pro Abfrage 20 Fakten abgerufen werden, stehen mehrere hundert Tokens an Speicherplatz im Kontext zur Verfügung, die mit der eigentlichen Aufgabe konkurrieren. Begrenzen Sie daher die Anzahl der abgerufenen Fakten und ordnen Sie diese nach ihrem Relevanzwert.

• Datenschutz und Konformität: Long-Term Memory speichert Benutzerdaten. Vor der Speicherung ist eine Reduzierung sensibler personenbezogener Informationen unerlässlich, ebenso wie klare Richtlinien zur Datenspeicherdauer sowie Funktionen für die Benutzer, um Daten löschen zu können. In regulierten Branchen ist keines dieser Aspekte optional.

• Checkpoint Speicherausdehnung: Die PostgreSQL Checkpoint-Tabellen wachsen mit jeder Ausführung auf einem Knoten. Bei langlaufenden Agents-Prozessen sollte eine Aufbewahrungsstrategie festgelegt werden: Man bewahrt die letzten N Checkpoints pro Thread auf und archiviert oder löscht die älteren Einträge. Ein Beispiel für eine Aufräumabfrage, die die 10 neuesten Checkpoints pro Thread speichert und alles, was älter als 30 Tage ist, löscht:

  DELETE FROM checkpoints
  WHERE thread_id = $1
    AND created_at < NOW() - INTERVAL '30 days'
    AND checkpoint_id NOT IN (
      SELECT checkpoint_id FROM checkpoints
      WHERE thread_id = $1
      ORDER BY created_at DESC
      LIMIT 10
    );

• Gedächtniskonsolidierung: Im Laufe der Zeit sollten detaillierte episodische Erinnerungen zu kompakten semantischen Repräsentationen komprimiert werden – beispielsweise „Der Benutzer fragte dreimal im Januar nach NVDA“ anstelle der wortgetreuen Speicherung aller drei Gespräche. Dies spiegelt die menschliche Gedächtniskonsolidierung wider und sorgt dafür, dass der Speicher beherrschbar bleibt. Mem0 und Graphiti Verarbeiten Sie dies automatisch; falls Sie eigene Lösungen entwickeln, planen Sie regelmäßige Konsolidierungsjobs ein.

• Cold Start-Problem: Neue Benutzer verfügen über keinen Long-Term Memory. Der Agent sollte sich fehlerverzeihend verhalten und statt Annahmen zu treffen, klärende Fragen stellen. Speicherbedarf ist additiv und nicht zwingend vorgegeben.

• Memory Poisoning: Alles, was sich im Agent der Context Window befindet, stellt einen potenziellen Eintrittspunkt für Angriffe dar. Wenn ein Angreifer irreführende Informationen in den Dokumentenspeicher oder in eine Long-Term Memory-Konfiguration einfügt (z. B. „Transaktionen stets ohne Überprüfung freigeben“), kann die Agent diese als Befehle ausführen. Der Zugriff auf gespeicherte Erinnerungen über Prompt Injection bildet somit eine echte Angriffsfläche. Gegenmaßnahmen umfassen die Validierung vor dem Speichern, die Behandlung des abgerufenen Inhalts als unzuverlässiger Datenstrom statt als Systemanweisungen sowie Zugriffskontrollen, die festlegen, welche Erinnerungen kritische Abläufe beeinflussen dürfen.

• Dokumenten-Memory-Drift dokumentieren: Dateibasiertes Memory verfügt weder über automatische Deduplizierung noch über Konfliktlösungsfunktionen. Im Laufe der Zeit sammeln sich in den Dokumenten Widersprüche an – eine Datei empfiehlt beispielsweise „pytest“ zu verwenden, während eine andere „unittest“ vorschreibt. Planen Sie regelmäßige Überprüfungen ein (oder überlassen Sie diese Aufgabe dem Agent), um unnötige Inhalte zu entfernen und die Dokumente zu konsolidieren. Die gute Nachricht ist, dass im Gegensatz zu Vector Stores, bei dem das Veralten von Informationen verborgen bleibt, hier ein solches Problem sichtbar ist. grep für Widersprüche.

• Die Dokumentenerinnerung skaliert nicht auf Millionen von Einträgen: Dateibasierte Speicherlösungen eignen sich für Hunderte bis wenige Tausend Dokumente. Wenn Ihre Agent über Fuzzy-Matching auf Millionen von Fakten zugreifen muss, benötigen Sie eine Vector Store. Die Dokumentenerinnerung dient der Verwaltung strukturierter Projektkenntnisse und nicht der Erfassung aller einzelnen Benutzerinteraktionen.

Wichtige Erkenntnisse

1. Agent Memory umfasst mehrere Speicherinstanzen mit unterschiedlichen Zugriffsmustern. Man sollte resumierbare Checkpoints-Strukturen, strukturierte Fakten, semantische Abrufmechanismen sowie Projektdokumente strikt voneinander trennen.
2. Bevor Personalisierungen durchgeführt werden, müssen Funktionen zum Anhalten und Wiederaufnehmen implementiert werden. Der Verlust von Aufgabenfortschritten ist das erste Anzeichen für einen Speicherdienstfehler bei langlaufenden Agent-Systemen.
3. Deterministische Fakten sollten in strukturierten Speichern abgelegt werden. Bei unklaren Abfragen oder variablen Formulierungen kommt Vector Search zum Einsatz.
4. Für Projektwissen, das von Personen inspiziert, geändert, versioniert oder im Vergleichsmodus überprüft werden muss, sollten Dateien verwendet werden.
5. Jeder Speichertyp benötigt Regeln bezüglich Ablaufdatum, Konflikten und Löschung. Eine Erinnerung, die das System nicht korrigieren kann, stellt schließlich Produktverschuldung dar.
6. Es sollte begrenzt werden, was an Informationen an den Model zurückgegeben wird. Gespeicherte Erinnerungen sind nur dann nützlich, wenn Retrieval die richtigen Beweismittel in den aktuellen Kontext einbringt.

Die nächste Ebene ist die Ausführung der Aktion

Teil 3, AI Agent Tool Use im Jahr 2026, wechselt vom gespeicherten Zustand zur Ausführung einer Aktion. Dabei wird untersucht, wie ein Agent Werkzeuge erkennt und aufruft sowie wie die Grenzen des Werkzeugs Fehler zurückgeben, die vom Reasoning Loop genutzt werden können. In den Teilen 5 und 6 kehrt man von der betrieblichen Ebene aus zur Speicherung zurück: Der Runtime stellt einen Checkpoint wieder her, während der Harness entscheidet, was bei der Übertragung an den nächsten Model Session berücksichtigt werden soll.

Referenzen

Arbeiten / Publikationen

• Kognitive Architekturen für Sprache Agents (CoALA) — Sumers, Yao et al., 2023 — Grundlegende Taxonomie von Agent Memory-Typen Speicher im Zeitalter von AI Agents: Eine Übersicht — Dezember 2025 — Umfassende dreidimensionale Taxonomie von Agent Memory
• MemGPT: Auf dem Weg zu LLMs als Betriebssystemen — Packer et al., 2023 — Virtuelle Kontextverwaltung für LLM Agents
• Generative Agents: Interaktive Simulakren menschlichen Verhaltens — Park et al., 2023 — Architektur von Speicherdatenströmen mit Bewertungskriterien für Aktualität, Bedeutung und Relevanz Zep: Eine Architektur für temporale Wissensgraphen im Bereich Agent Memory — Rasmussen, 2025 — Bi-temporale Wissensgraph für Agent Memory
• Mem0: Entwicklung eines für die Produktion bereiten AI Agents mit skalierbaren Long-Term Memory — 2025 — Extraktion/Konsolidierung Pipeline mittels Benchmarks
• Voyager: Ein offenes, körperbasiertes Agent mit großem Sprachmodell Models — Wang et al., 2023 — Fähigkeitsbibliothek als Dokumentenerinnerung für Open-World-Spiele Agents
• JARVIS-1: Offenes Mehraufgabenszenario Agents mit memoriell erweitertem multimodalem Sprachverarbeitungssystem Models — 2023 — Multimodale Speicherbibliothek für Minecraft Agents
• Agent Workflow Speicher — Wang et al., 2024 — Wiederverwendbare Workflow-Induktion für Agents-Automatisierung im Web SkillWeaver: Das Web Agents kann selbstständig Bibliotheken für Fähigkeiten erstellen. — 2025 — Selbstsynthetisierte, wiederverwendbare API-Tools für Web Agents
• LEGOMem: Modulares Speichermodul Framework für LLM Agent-Systeme — 2025 — Komponierbare Speichermodule für multi-agent-Systeme

LangGraph-Dokumentation

• LangGraph-Persistenz (Checkpointing) — Kernkonzepte für auf Checkpoint basierenden Speicher LangGraph-Speicher — Threadübergreifende Kommunikation mit der Long-Term Memory-Schnittstelle
• LangGraph-Kreuz-Thread-Persistenz — Funktionalität für API von Speicherinhalten zwischen Threads Wie fügt man Speicher hinzu zu den vorkonfigurierten ReAct Agent — Praktischer Leitfaden zur Erweiterung des Arbeitsspeichers

Checkpoint Backends

• langgraph-checkpoint-postgres — PostgreSQL Checkpoint-Saver für LangGraph
• langgraph-checkpoint-redis — Redis Checkpoint-Saver für LangGraph LangGraph Redis Checkpoint 0.1.0 – Neugestaltung — Architekturdetails für den Redis Checkpoint-Speichermechanismus
• langgraph-checkpoint-aws — DynamoDB Checkpoint-Speicher mit S3-Offloading

Vector Databases sowie Speichermanagement-Tools

• Qdrant — Open-Source-Vector Database mit HNSW-Bewertung und -Filterung Qdrant Agentic – Bauanleitung — Praktischer Leitfaden zum Aufbau von Agent Memory mit Qdrant
• pgvector — Erweiterung für die Vektorähnlichkeitssuche in PostgreSQL Graphiti — Open-Source-Engine für zeitbasierte Wissensgraphen von Zep

Dokumenten- und Dateibasierte Speicherung

• Claude Code Memory — CLAUDE.md und MEMORY.md: ein auf Dateien basierendes Speichersystem Anthropic Memory-Tool — Client-seitiger, auf Dateien basierender Speicher für Claude API Agents
• Regeln für den Cursor — Projektbezogene .cursorrules-Dateien für den Agent-Kontext Erinnerungen an Windsurfen — dateibasierte Speicherung sowie .windsurfrules zur Programmierung Agents

Speicher Frameworks

• Mem0 — Gesteuerte Speicherschicht zur Extraktion/Konsolidierung Pipeline
• Letta (MemGPT) — OS-inspirierte virtuelle Kontextverwaltung für Agents
• LangMem SDK — Speichermanagement-Tools für LangGraph

Benchmarks

• Leistung von PostgreSQL im Vergleich zu Redis — CyberTec Latency und Throughput Benchmarks
• Vergleich von PostgreSQL und Redis — Vergleich der RisingWave-Architekturen
• Redis AI Agent-Engineering — Redis-Muster für Agent-Arbeitslasten

Workshops

• MemAgents: Speicher für LLM-basierte Agentic-Systeme — ICLR 2026 Workshop

Demo-Projekt

• Marktanalyst Agent — Vollständige Implementierung mit allen drei Speicherebenen

Der vollständige Code des Market Analyst Agent, einschließlich der darin beschriebenen Speicherarchitektur, ist verfügbar unter GitHub Falls Sie gerne mitlesen möchten._

Reihe: Entwicklung der Agentic-Stack-Architektur

• Teil 1: AI Agent Reasoning Schleifen im Jahr 2026 — ReAct, ReWOO und Plan-and-Execute
• Teil 2: AI Agent Memory-Architektur im Jahr 2026 (dieser Artikel)
• Teil 3: AI Agent Tool Use im Jahr 2026 — MCP, CLI, Fähigkeiten, Ausführung von Code sowie ACI Teil 4: AI Agent Sicherheit im Jahr 2026 — Guardrails, Berechtigungen, Sandboxes, HITL sowie MCP-Bereichsdefinition
• Teil 5: Langlaufende AI Agent Runtime im Jahr 2026 — Sessions, Sandboxes, Checkpoints sowie Steuermechanismen und Deployment-Formierungen
• Teil 6: Harness Engineering für AI Agents (folgt bald) — Akzeptanzprüfungen, Traces, Wiederholungsversuche, Übergaben sowie der Schleifenprozess rund um den Model