So beheben Sie Gedächtnisverlust bei LangChain-Agenten in langen Konversationen

Wenn ein LangChain-Agent Details während einer langen Konversation vergisst, korrigieren Sie die Architektur, bevor Sie den Kontextfenster des Modells erhöhen. In aktuellen LangChain v1-Agenten wird die Konversationskontinuität aus zwei separaten Schichten aufgebaut: einem Checkpointer für kurzfristigen, threadbezogenen Zustand und einem Store für langfristige Informationen, die Threads überleben müssen. Lange Konversationen erfordern dann eine dritte Überlegung: das Kontextmanagement, normalerweise das Kürzen oder Zusammenfassen älterer Nachrichten, bevor sie das Modell überlasten.

Dieser Leitfaden folgt der offiziellen Dokumentation von LangChain, wie am 11. September 2026 überprüft. Die aktuellen Docs empfehlen langchain.agents.create_agent für neue Agenten und beschreiben LangGraph-Persistenz als das zugrunde liegende Speichersystem. Ältere Beispiele, die auf ConversationChain, ConversationBufferMemory oder initialize_agent basieren, können in Legacy-Materialien noch auftauchen, aber der v1-Migrationsleitfaden von LangChain hat Legacy-Chains und andere veraltete Funktionen in langchain-classic verschoben. Siehe den offiziellen LangChain v1-Migrationsleitfaden.

Was „Gedächtnisverlust“ in LangChain tatsächlich bedeutet

Trennen Sie drei Probleme, die aus Benutzersicht oft identisch aussehen, bevor Sie Code ändern.

Die Dokumentation zum Kurzzeitgedächtnis von LangChain definiert Kurzzeitgedächtnis als Zustand innerhalb eines einzelnen Threads. Die Dokumentation zum Langzeitgedächtnis definiert Langzeitgedächtnis als Informationen, die über verschiedene Konversationen und Sitzungen hinweg bestehen bleiben.

Was Sie vor dem Start benötigen

Sie benötigen eine aktuelle LangChain/LangGraph-Anwendung, eine Modellintegration und einen Ort zur Persistenz des Zustands. Für ein lokales Experiment ist InMemorySaver ausreichend. Für die Produktion verwenden Sie einen datenbankgestützten Checkpointer. Die offiziellen Docs von LangChain zeigen PostgreSQL über das separate Paket langgraph-checkpoint-postgres.

Halten Sie vier Kennungen klar:

• Konversations- oder Chat-ID: Die Kennung, die Ihre Anwendung Benutzern bereitstellt.
• thread_id: Der LangGraph-Persistenzschlüssel, der zum Fortsetzen des Zustands eines Threads verwendet wird.
• Benutzer-ID: Die dauerhafte Identität, die zum Namespace von Langzeitgedächtnissen verwendet wird.
• Speicherschlüssel: Der Schlüssel für ein dauerhaftes Element innerhalb eines Store-Namespace.

Sie sollten nicht automatisch denselben Wert haben. Ein Benutzer kann viele Threads haben, und ein Thread kann viele Fakten enthalten.

Schritt 1: Reproduzieren Sie den Fehler mit einem Zwei-Anfragen-Test

Beginnen Sie mit dem kleinstmöglichen Test. Bitten Sie den Agenten, sich ein eindeutiges Detail zu merken, rufen Sie ihn dann erneut auf und fragen Sie nach diesem Detail. Testen Sie das Gedächtnis nicht mit einem einzelnen invoke()-Aufruf, da das Modell alles in dieser einen Anfrage sehen kann, selbst wenn die Persistenz fehlerhaft ist.

config = {"configurable": {"thread_id": "debug-thread-001"}}

agent.invoke(
    {"messages": [{"role": "user", "content": "Remember that my project codename is Juniper."}]},
    config,
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "What is my project codename?"}]},
    config,
)

Wenn die zweite Anfrage „Juniper“ vergisst, überprüfen Sie die Checkpointer-Konfiguration und die tatsächliche thread_id, bevor Sie Prompts ändern.

Schritt 2: Fügen Sie einen Checkpointer für das Gedächtnis innerhalb desselben Threads hinzu

Ein Checkpointer speichert Momentaufnahmen des Graphenzustands des Agenten. LangGraph verwendet ihn für Kurzzeitgedächtnis, Unterbrechungswiederherstellung, Human-in-the-Loop-Flows und Fehlertoleranz. Der aktuelle Persistenzleitfaden beschreibt Checkpointer als threadbezogen und besagt, dass die Anwendung auf den Zustand zugreift, indem sie eine thread_id übergibt. Siehe den offiziellen LangGraph-Persistenzleitfaden.

from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

checkpointer = InMemorySaver()

agent = create_agent(
    model="your-provider:your-model",
    tools=[],
    checkpointer=checkpointer,
)

config = {"configurable": {"thread_id": "customer-42:case-7"}}

InMemorySaver ist hervorragend geeignet, um zu bestätigen, dass Ihre Thread-Verdrahtung funktioniert, aber er speichert Checkpoints im RAM. LangGraph warnt ausdrücklich, dass MemorySaver/InMemorySaver nicht über Prozessneustarts hinweg bestehen bleiben.

Schritt 3: Behalten Sie dieselbe thread_id für dieselbe Konversation bei

Der häufigste Anwendungsfehler ist die Erstellung einer neuen thread_id bei jeder HTTP-Anfrage. Die Datenbank funktioniert möglicherweise einwandfrei, während jede Anfrage einen anderen LangGraph-Thread startet.

Angenommen, Ihr Frontend hat die Chat-ID chat_8bf4. Ordnen Sie diesen Wert deterministisch dem LangGraph-Thread zu und verwenden Sie ihn für jede Runde in diesem Chat erneut. Ein neuer Chat sollte eine neue Thread-ID erhalten.

Verwenden Sie keine permanente thread_id für alle Chats, die demselben Benutzer gehören. Das führt dazu, dass nicht verwandte Konversationen in einem einzigen Zustandsstrom zusammengeführt werden. Wenn Sie PostgreSQL verwenden, besagt die aktuelle Fehlerbehebungsanleitung von LangGraph auch, dass thread_id unter 255 Zeichen bleiben sollte; eine UUID oder ein deterministischer Hash ist sicherer als ein riesiges serialisiertes Objekt.

Schritt 4: Ersetzen Sie die In-Memory-Persistenz vor der Produktion

Sobald der Zwei-Anfragen-Test bestanden ist, testen Sie einen Prozessneustart. Speichern Sie eine Tatsache, stoppen Sie die Anwendung, starten Sie sie erneut und fragen Sie dann nach der Tatsache mit derselben Thread-ID. Wenn Sie weiterhin InMemorySaver verwenden, ist das Vergessen erwartetes Verhalten.

Die offiziellen Docs zum Kurzzeitgedächtnis zeigen eine produktionsreife PostgreSQL-basierte Einrichtung unter Verwendung von PostgresSaver:

from langchain.agents import create_agent
from langgraph.checkpoint.postgres import PostgresSaver

DB_URI = "postgresql://user:password@db-host/app"

with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()
    agent = create_agent(
        model="your-provider:your-model",
        tools=[],
        checkpointer=checkpointer,
    )

Für die aktuelle Paketinstallation, die von LangChain dokumentiert wird, siehe Kurzzeitgedächtnis. Platzieren Sie keine echten Datenbankzugangsdaten direkt im Quellcode; verwenden Sie Ihr normales Geheimnisverwaltungssystem.

Schritt 5: Verwalten Sie lange Verläufe, anstatt alles für immer zu senden

Ein Kontextfenster ist die Menge an Eingabe- und Ausgabekontext, die ein Modell in einem Modellaufruf verarbeiten kann. Checkpointing kann einen sehr langen Konversationsverlauf im Speicher bewahren, aber das bedeutet nicht, dass jede historische Nachricht für immer an das Modell zurückgesendet werden sollte.

Der Leitfaden zum Kurzzeitgedächtnis von LangChain besagt, dass lange Verläufe das Modellkontextfenster überschreiten können und dass selbst Modelle, die den vollständigen Verlauf akzeptieren können, durch veraltete oder thematisch irrelevante Inhalte abgelenkt werden können, was zu höherer Latenz und Kosten führt. Die dokumentierten Strategien sind Kürzen, Löschen, Zusammenfassen oder Anwenden einer benutzerdefinierten Richtlinie.

Verwenden Sie Zusammenfassung, wenn alte Details noch wichtig sind

SummarizationMiddleware ist die aktuelle integrierte Option zum Ersetzen älterer Verläufe durch eine kompakte Zusammenfassung, während neuere Nachrichten beibehalten werden. Der Auslöser kann auf Tokenanzahl, Nachrichtenanzahl oder einem Bruchteil des Modellkontexts basieren.

from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware

agent = create_agent(
    model="your-provider:your-model",
    tools=[],
    checkpointer=checkpointer,
    middleware=[
        SummarizationMiddleware(
            model="your-provider:summary-model",
            trigger=("fraction", 0.8),
            keep=("fraction", 0.3),
        )
    ],
)

Die obigen Zahlen sind eine Beispielrichtlinie, keine universellen Einstellungen. Wählen Sie Schwellenwerte, nachdem Sie Ihre eigenen Prompts, Tool-Ausgaben, Modellkontextgrenzen, Latenz und Zusammenfassungsqualität gemessen haben. Siehe die Dokumentation zur integrierten Middleware von LangChain für die aktuell unterstützten Trigger- und Keep-Optionen.

Kürzen Sie Tool-Nachrichten nicht blind

Wenn Sie benutzerdefiniertes Löschen oder Kürzen implementieren, bewahren Sie eine gültige Nachrichtensequenz auf. LangChain warnt, dass viele Anbieter verlangen, dass eine Assistentennachricht, die Tool-Aufrufe enthält, von den entsprechenden Tool-Ergebnisnachrichten gefolgt wird. Das Entfernen einer Hälfte dieses Paares kann Anbieterfehler oder verwirrendes Modellverhalten verursachen.

Schritt 6: Verschieben Sie dauerhafte Fakten in einen Langzeit-Store

Ein Store ist die Persistenzschicht von LangGraph für anwendungsdefinierte Daten außerhalb des Graphenzustands eines Threads. Die aktuellen LangChain-Docs verwenden Stores für Informationen, die über Konversationen hinweg verfügbar sein sollten, wie Benutzerpräferenzen, Fakten oder gemeinsames Anwendungswissen.

Elemente im Langzeit-Store sind JSON-Dokumente, die nach einem Namespace und einem Schlüssel organisiert sind. Ein praktischer Namespace enthält oft eine Benutzer- oder Organisationskennung:

namespace = ("users", user_id, "preferences")
store.put(
    namespace,
    "response_style",
    {"value": "concise", "source": "explicit_user_request"},
)

Dies unterscheidet sich vom Speichern des gesamten Transkripts. Speichern Sie die Informationen, die Ihr Produkt absichtlich als dauerhaft behandelt. Wenn eine Tatsache privat oder reguliert ist, wenden Sie Ihre normalen Aufbewahrungs-, Autorisierungs-, Verschlüsselungs- und Löschrichtlinien an, anstatt anzunehmen, dass „Agentengedächtnis“ davon ausgenommen ist.

Verwenden Sie einen datenbankgestützten Store in der Produktion

Der offizielle Leitfaden zum Langzeitgedächtnis zeigt sowohl InMemoryStore als auch PostgresStore und weist ausdrücklich darauf hin, dass die In-Memory-Implementierung in der Produktion durch einen datenbankgestützten Store ersetzt werden sollte. Er listet auch Store-Integrationen über PostgreSQL hinaus auf. Verwenden Sie das Backend, das zu Ihrer Bereitstellung und Ihren betrieblichen Anforderungen passt, anstatt eine Vektordatenbank nur deshalb auszuwählen, weil das Wort „Gedächtnis“ involviert ist.

Fügen Sie semantische Suche nur hinzu, wenn Sie unscharfen Abruf benötigen

LangGraph-Stores können mit einem Index konfiguriert werden, damit store.search() Elemente nach semantischer Ähnlichkeit abrufen kann. Das ist nützlich, wenn Sie viele Gedächtnisse haben und den genauen Schlüssel nicht kennen. Für eine kleine Menge strukturierter Präferenzen ist die direkte Namespace/Schlüssel-Suche oft einfacher und deterministischer.

Schritt 7: Machen Sie Lese- und Schreibpfade für das Gedächtnis explizit

Das Speichern eines Langzeit-Elements garantiert nicht, dass der Agent es verwendet. Die Anwendung benötigt weiterhin einen Abrufpfad. Aktuelle LangChain-Agenten ermöglichen es Tools, über ToolRuntime auf den bereitgestellten Store zuzugreifen.

from dataclasses import dataclass
from langchain.tools import tool, ToolRuntime

@dataclass
class Context:
    user_id: str

@tool
def get_response_style(runtime: ToolRuntime[Context]) -> str:
    store = runtime.store
    if store is None:
        return "No memory store configured"

    namespace = ("users", runtime.context.user_id, "preferences")
    item = store.get(namespace, "response_style")
    return item.value["value"] if item else "default"

Sie können auch dynamische Prompts oder Middleware erstellen, die den Zustand und das dauerhafte Gedächtnis vor einem Modellaufruf liest. Die wichtige Designregel ist, dass der Abrufpfad beobachtbar und testbar sein sollte. „Die Information existiert irgendwo in der Datenbank“ reicht nicht aus.

Schritt 8: Testen Sie die vier Gedächtnisgrenzen separat

Eine zuverlässige Gedächtnistest-Suite sollte mehr abdecken als „das Modell hat sich einmal an meinen Namen erinnert“. Verwenden Sie mindestens diese vier Fälle:

Fügen Sie dann einen Langkonversationstest hinzu, der Ihre Zusammenfassungsschwelle überschreitet. Stellen Sie sicher, dass wichtige dauerhafte Fakten überleben, aktuelle Tool-Aufrufsequenzen gültig bleiben und die Prompt-Größe innerhalb Ihres Zielbudgets bleibt.

Eine minimale Produktionsarchitektur

Für viele Agentenanwendungen sieht ein robustes Design wie folgt aus:

1. Die API empfängt user_id, conversation_id und die neue Benutzernachricht.
2. Die Anwendung ordnet conversation_id einer stabilen LangGraph-thread_id zu.
3. Ein persistenter Checkpointer stellt den Thread-Zustand wieder her.
4. Ein Langzeit-Store ruft nur dauerhafte Benutzer- oder Anwendungsdaten ab, die für die Anfrage benötigt werden.
5. Zusammenfassung oder Kürzung halten den modellseitigen Verlauf innerhalb eines gemessenen Kontextbudgets.
6. Der Agent führt Tools und das Modell aus.
7. Der Checkpointer bestätigt den aktualisierten Thread-Zustand.
8. Nur genehmigte Fakten werden in den Langzeit-Store geschrieben.

Wenn Sie über den LangGraph Agent Server bereitstellen, besagt der aktuelle Persistenzleitfaden, dass der Server die Persistenzinfrastruktur automatisch verwaltet, duplizieren Sie diese Schicht also nicht, ohne das Bereitstellungsmodell zu überprüfen.

Häufige Fehler, die das Gedächtnis fehlerhaft erscheinen lassen

Generieren einer neuen thread_id für jede Anfrage

Dies erstellt bei jeder Runde einen neuen Konversationszustand. Protokollieren Sie die Thread-ID neben Ihrer Anwendungs-Chat-ID und überprüfen Sie die Wiederverwendung.

Verwenden von InMemorySaver in einem Multi-Worker- oder neustartbaren Dienst

Der RAM-lokale Zustand verschwindet mit dem Prozess und wird möglicherweise nicht über Worker hinweg geteilt. Verwenden Sie ein persistentes Backend für die Produktionskontinuität.

Annehmen, dass ein Checkpointer das Kontextfensterproblem löst

Ein Checkpointer bewahrt den Zustand; er garantiert nicht, dass ein ständig wachsender Transkript für das Modell nützlich ist. Fügen Sie eine explizite Kontextverwaltungsrichtlinie hinzu.

Setzen jedes historischen Faktums in den Prompt

Mehr Kontext ist nicht automatisch besserer Kontext. Rufen Sie Informationen ab, die für die aktuelle Runde relevant sind, und bewahren Sie die aktuelle Konversationskontinuität separat.

Behandeln von Zusammenfassungen als perfekte Datenbank

Zusammenfassungen sind komprimierte, modellgenerierte Darstellungen. Wenn eine Tatsache exakt sein muss – eine Kontokennung, eine vertragliche Einschränkung, eine benutzergenehmigte Präferenz oder ein Workflow-Zustand – speichern Sie sie als strukturierte Daten, anstatt zu hoffen, dass sie wiederholte Zusammenfassungen überlebt.

Mischen von Kurzzeit- und Langzeitbereichen

Der Thread-Verlauf sollte nicht stillschweigend zu einem globalen Benutzerprofil werden. Umgekehrt sollte eine Benutzerpräferenz, die den Benutzer über Chats hinweg begleiten soll, nicht nur in einem Thread leben.

Kopieren von v1-vorherigen Gedächtnis-Tutorials ohne Überprüfung der Importe

Wenn ein Beispiel mit Legacy-Chains oder alten Speicherklassen beginnt, vergleichen Sie es mit dem aktuellen v1-Migrations- und Gedächtnisdokumentation, bevor Sie es in einer neuen Anwendung verwenden.

Debugging-Checkliste

• Stellen Sie sicher, dass der Agent mit einem Checkpointer erstellt wurde.
• Protokollieren und vergleichen Sie thread_id über aufeinanderfolgende Anfragen hinweg.
• Untersuchen Sie den gespeicherten Thread-Zustand, bevor Sie das Modell beschuldigen.
• Starten Sie den Prozess neu und wiederholen Sie denselben Thread-Test.
• Ersetzen Sie InMemorySaver durch einen persistenten Checkpointer für die Produktion.
• Messen Sie das Wachstum von Nachrichten/Tokens über lange Chats hinweg.
• Aktivieren Sie Zusammenfassung oder Kürzung, bevor der Verlauf übermäßig wird.
• Halten Sie Tool-Aufruf/Ergebnis-Sequenzen gültig, wenn Nachrichten entfernt werden.
• Verschieben Sie Thread-übergreifende Fakten in einen namespace-basierten Langzeit-Store.
• Testen Sie einen neuen Thread für denselben Benutzer, um die beabsichtigte Langzeitabrufgenauigkeit zu überprüfen.
• Testen Sie einen anderen Benutzer, um die Gedächtnisisolation zu überprüfen.
• Verfolgen Sie, welche Gedächtniselemente für jede Antwort abgerufen wurden.

Fazit

Gedächtnisverlust bei LangChain-Agenten wird selten durch ein größeres Kontextfenster gelöst. Stellen Sie zunächst den Thread-Zustand mit einem Checkpointer und einer stabilen thread_id persistent her. Kontrollieren Sie dann lange Verläufe mit Kürzung oder SummarizationMiddleware. Platzieren Sie schließlich Fakten, die Konversationen überleben müssen, in einem namespace-basierten Langzeit-Store und rufen Sie sie absichtlich ab.

Diese Trennung gibt Ihnen etwas viel Nützlicheres als „Gedächtnis“: ein System, das Sie neu starten, skalieren, testen, auditieren und analysieren können, wenn ein Benutzer fragt: „Warum hat der Agent vergessen?“