Hoe je geheugenverlies van LangChain-agents bij lange gesprekken oplost

Als een LangChain-agent details vergeet tijdens een lang gesprek, repareer dan eerst de architectuur voordat je het contextvenster van het model vergroot. In huidige LangChain v1-stijl agents wordt gesprekscontinuïteit opgebouwd uit twee afzonderlijke lagen: een checkpointer voor korte-termijn, thread-gerichte status en een store voor langetermijninformatie die threads moet overleven. Lange gesprekken vereisen vervolgens een derde aandachtspunt: contextbeheer, meestal het inkorten of samenvatten van oudere berichten voordat ze het model overbelasten.

Deze gids volgt de officiële documentatie van LangChain zoals gecontroleerd op 11 september 2026. De huidige documentatie beveelt langchain.agents.create_agent aan voor nieuwe agents en beschrijft LangGraph-persistentie als het onderliggende geheugensysteem. Oudere voorbeelden gebaseerd op ConversationChain, ConversationBufferMemory of initialize_agent kunnen nog steeds voorkomen in legacy-materiaal, maar de migratiegids van LangChain v1 heeft legacy chains en andere verouderde functionaliteit verplaatst naar langchain-classic. Zie de officiële LangChain v1 migratiegids.

Wat "Geheugenverlies" eigenlijk betekent in LangChain

Scheid drie problemen die er vanuit het gebruikersperspectief vaak identiek uitzien, voordat je code wijzigt.

De documentatie over korte-termijngeheugen van LangChain definieert korte-termijngeheugen als status binnen één thread. De documentatie over langetermijngeheugen definieert langetermijngeheugen als informatie die persists over verschillende gesprekken en sessies heen.

Wat je nodig hebt voordat je begint

Je hebt een huidige LangChain/LangGraph-toepassing nodig, een modelintegratie en een plek om status te persisten. Voor een lokaal experiment is InMemorySaver voldoende. Voor productie gebruik je een database-gebaseerde checkpointer. De officiële documentatie van LangChain toont PostgreSQL via het aparte pakket langgraph-checkpoint-postgres.

Houd vier identificatoren duidelijk:

• Gespreks- of chat-ID: de identificator die je toepassing aan gebruikers exposeert.
• thread_id: de LangGraph-persistentiesleutel die wordt gebruikt om de status van één thread te hervatten.
• Gebruikers-ID: de duurzame identiteit die wordt gebruikt om langetermijnherinneringen te namespace.
• Geheugensleutel: de sleutel voor één duurzaam item binnen een store-namespace.

Ze moeten niet automatisch dezelfde waarde zijn. Eén gebruiker kan veel threads hebben, en één thread kan veel feiten bevatten.

Stap 1: Reproduceer de fout met een twee-verzoek test

Begin met de kleinst mogelijke test. Vraag de agent om een uniek detail te onthouden, roep hem dan opnieuw aan en vraag om dat detail. Test geheugen niet met een enkele invoke()-aanroep, omdat het model alles in die ene aanvraag kan zien, zelfs als persistentie defect is.

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,
)

Als het tweede verzoek "Juniper" vergeet, inspecteer dan de checkpointer-configuratie en de daadwerkelijke thread_id voordat je prompts wijzigt.

Stap 2: Voeg een checkpointer toe voor geheugen binnen dezelfde thread

Een checkpointer persisteert snapshots van de grafiekstatus van de agent. LangGraph gebruikt het voor korte-termijngeheugen, onderbrekingsherstel, human-in-the-loop flows en fouttolerantie. De huidige persistentiegids beschrijft checkpointers als thread-gericht en zegt dat de toepassing de status benadert door een thread_id door te geven. Zie de officiële LangGraph persistentiegids.

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 is uitstekend om te bevestigen dat je thread-bedrading werkt, maar het slaat checkpoints op in RAM. LangGraph waarschuwt expliciet dat MemorySaver/InMemorySaver niet persists over procesherstarts heen.

Stap 3: Houd dezelfde thread_id aan voor hetzelfde gesprek

De meest voorkomende applicatieniveau-bug is het aanmaken van een nieuwe thread_id bij elk HTTP-verzoek. De database kan perfect werken, terwijl elk verzoek een andere LangGraph-thread start.

Stel bijvoorbeeld dat je front-end chat-ID chat_8bf4 heeft. Map die waarde deterministisch naar de LangGraph-thread en hergebruik het voor elke beurt in die chat. Een nieuwe chat moet een nieuwe thread-ID ontvangen.

Gebruik niet één permanente thread_id voor alle chats die bij dezelfde gebruiker horen. Dat voegt ongerelateerde gesprekken samen in één statusstroom. Als je PostgreSQL gebruikt, zegt de huidige probleemoplossingsrichtlijn van LangGraph ook dat thread_id onder de 255 tekens moet blijven; een UUID of deterministische hash is veiliger dan een enorm geserialiseerd object.

Stap 4: Vervang in-memory persistentie voordat je naar productie gaat

Zodra de twee-verzoek test slaagt, test dan een procesherstart. Sla een feit op, stop de toepassing, start hem opnieuw, en vraag dan om het feit met dezelfde thread-ID. Als je nog steeds InMemorySaver gebruikt, is vergeten het verwachte gedrag.

De officiële documentatie over korte-termijngeheugen toont een PostgreSQL-ondersteunde productieopstelling met 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,
    )

Voor de pakketinstelling die momenteel door LangChain wordt gedocumenteerd, zie Korte-termijngeheugen. Zet geen echte databasegegevens direct in de broncode; gebruik je normale systeem voor geheimbeheer.

Stap 5: Beheer lange geschiedenissen in plaats van alles voor altijd te verzenden

Een contextvenster is de hoeveelheid invoer- en uitvoercontext die een model in één modelaanroep kan verwerken. Checkpointing kan een zeer lang gesprek in opslag bewaren, maar dat betekent niet dat elk historisch bericht voor altijd terug naar het model moet worden gestuurd.

De gids voor korte-termijngeheugen van LangChain zegt dat lange geschiedenissen het modelcontextvenster kunnen overschrijden en dat zelfs modellen die de volledige geschiedenis kunnen accepteren, afgeleid kunnen worden door verouderde of off-topic inhoud, met hogere latentie en kosten. De gedocumenteerde strategieën zijn inkorten, verwijderen, samenvatten of een aangepast beleid toepassen.

Gebruik samenvatting wanneer oude details nog steeds ertoe doen

SummarizationMiddleware is de huidige ingebouwde optie om oudere geschiedenis te vervangen door een compacte samenvatting terwijl recente berichten behouden blijven. De trigger kan gebaseerd zijn op tokenaantal, berichtaantal of een fractie van het modelcontext.

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),
        )
    ],
)

De bovenstaande cijfers zijn een voorbeeldbeleid, geen universele instellingen. Kies drempelwaarden na het meten van je eigen prompts, tool-uitkomsten, modelcontextlimieten, latentie en samenvattingskwaliteit. Zie de documentatie over ingebouwde middleware van LangChain voor de momenteel ondersteunde trigger- en keep-opties.

Kort toolberichten niet blind in

Als je aangepaste verwijdering of inkorten implementeert, behoud dan een geldige berichtsequentie. LangChain waarschuwt dat veel providers vereisen dat een assistentbericht met tool-aanroepen gevolgd wordt door de corresponderende tool-resultaatberichten. Het verwijderen van de ene helft van dat paar kan providerfouten of verwarrend modelgedrag veroorzaken.

Stap 6: Verplaats duurzame feiten naar een langetermijn store

Een store is de persistentielaag van LangGraph voor applicatiegedefinieerde gegevens buiten de grafiekstatus van één thread. Huidige LangChain-documentatie gebruikt stores voor informatie die beschikbaar moet zijn over gesprekken heen, zoals gebruikersvoorkeuren, feiten of gedeelde applicatiekennis.

Items in de langetermijn store zijn JSON-documenten georganiseerd door een namespace en een key. Een praktische namespace bevat vaak een gebruikers- of organisatie-identificator:

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

Dit verschilt van het opslaan van de hele transcriptie. Sla de informatie op die je product bewust als duurzaam beschouwt. Als een feit privé of gereguleerd is, pas dan je normale retentie-, autorisatie-, versleutelings- en verwijderingsbeleid toe in plaats van aan te nemen dat "agentgeheugen" daarop vrijstelling heeft.

Gebruik een database-gebaseerde store in productie

De officiële gids voor langetermijngeheugen toont zowel InMemoryStore als PostgresStore, en merkt expliciet op dat de in-memory implementatie vervangen moet worden door een database-gebaseerde store voor productie. Het noemt ook store-integraties buiten PostgreSQL. Gebruik de backend die past bij je implementatie- en operationele vereisten, in plaats van een vector database te kiezen alleen omdat het woord "geheugen" erbij betrokken is.

Voeg semantische zoekopdrachten alleen toe wanneer je fuzzy herroeping nodig hebt

LangGraph stores kunnen worden geconfigureerd met een index zodat store.search() items kan ophalen op semantische gelijkenis. Dat is nuttig wanneer je veel herinneringen hebt en de exacte sleutel niet kent. Voor een kleine set gestructureerde voorkeuren is directe namespace/sleutel-opzoeking vaak eenvoudiger en deterministischer.

Stap 7: Maak lees- en schrijfpaden voor geheugen expliciet

Het persisten van een langetermijnitem garandeert niet dat de agent het zal gebruiken. De toepassing heeft nog steeds een retrievalpad nodig. Huidige LangChain agents laten tools toegang krijgen tot de geleverde store via ToolRuntime.

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"

Je kunt ook dynamische prompts of middleware bouwen die status en duurzaam geheugen lezen voordat een modelaanroep plaatsvindt. De belangrijke ontwerpregel is dat het retrievalpad observeerbaar en testbaar moet zijn. "De informatie bestaat ergens in de database" is niet genoeg.

Stap 8: Test de vier geheugengrenzen afzonderlijk

Een betrouwbare geheugentest-suite moet meer dekken dan "het model herinnerde zich mijn naam één keer". Gebruik op zijn minst deze vier gevallen:

Voeg vervolgens een test voor lange gesprekken toe die je samenvattingsdrempel overschrijdt. Asserteer dat belangrijke duurzame feiten overleven, recente tool-aanroepsequenties geldig blijven, en de promptgrootte binnen je doelbudget blijft.

Een minimale productiearchitectuur

Voor veel agenttoepassingen ziet een robuust ontwerp er als volgt uit:

1. De API ontvangt user_id, conversation_id en het nieuwe gebruikersbericht.
2. De toepassing mapt conversation_id naar een stabiele LangGraph thread_id.
3. Een persistente checkpointer herstelt de threadstatus.
4. Een langetermijn store haalt alleen duurzame gebruikers- of applicatiefeiten op die nodig zijn voor het verzoek.
5. Samenvatting of inkorten houdt de modelgerichte geschiedenis binnen een gemeten contextbudget.
6. De agent voert tools en het model uit.
7. De checkpointer legt de bijgewerkte threadstatus vast.
8. Alleen goedgekeurde feiten worden naar de langetermijn store geschreven.

Als je implementeert via LangGraph Agent Server, zegt de huidige persistentiegids dat de server persistentie-infrastructuur automatisch afhandelt, dus dupliceer die laag niet zonder het implementatiemodel te controleren.

Veelvoorkomende fouten die geheugen kapot lijken te maken

Een nieuwe thread_id genereren voor elk verzoek

Dit creëert elke beurt een nieuwe gespreksstatus. Log de thread-ID naast je applicatie-chat-ID en verifieer hergebruik.

InMemorySaver gebruiken in een multi-worker of herstartbare service

RAM-lokale status verdwijnt met het proces en wordt mogelijk niet gedeeld over workers. Gebruik een persistente backend voor productiecontinuïteit.

Aannemen dat een checkpointer het contextvensterprobleem oplost

Een checkpointer bewaart status; het garandeert niet dat een steeds groeiende transcriptie nuttig is voor het model. Voeg een expliciet contextbeheerbeleid toe.

Elk historisch feit in de prompt plaatsen

Meer context is niet automatisch betere context. Haal informatie op die relevant is voor de huidige beurt en behoud recente gesprekscontinuïteit apart.

Samenvattingen behandelen als een perfecte database

Samenvattingen zijn gecomprimeerde, modelgegenereerde representaties. Als een feit exact moet zijn—een accountidentificator, contractuele beperking, door de gebruiker goedgekeurde voorkeur of workflowstatus—sla het dan op als gestructureerde gegevens in plaats van te hopen dat het herhaalde samenvattingen overleeft.

Korte-termijn en langetermijn scopes mengen

Threadgeschiedenis mag niet stilzwijgend een globaal gebruikersprofiel worden. Omgekeerd mag een gebruikersvoorkeur die de gebruiker over chats heen moet volgen, niet alleen in één thread leven.

Pre-v1 geheugentutorials kopiëren zonder imports te controleren

Als een voorbeeld begint met legacy chains of oude geheugenklassen, vergelijk het dan met de huidige v1-migratie- en geheugendocumentatie voordat je het in een nieuwe toepassing gebruikt.

Debugging Checklist

• Bevestig dat de agent is aangemaakt met een checkpointer.
• Log en vergelijk thread_id over opeenvolgende verzoeken.
• Inspecteer de opgeslagen threadstatus voordat je het model de schuld geeft.
• Start het proces opnieuw en herhaal dezelfde-thread test.
• Vervang InMemorySaver door een persistente checkpointer voor productie.
• Meet bericht/token groei over lange chats.
• Schakel samenvatting of inkorten in voordat de geschiedenis excessief wordt.
• Houd tool-aanroep/resultaatsequenties geldig bij het verwijderen van berichten.
• Verplaats cross-thread feiten naar een namespaced langetermijn store.
• Test een nieuwe thread voor dezelfde gebruiker om bewust langetermijnherroeping te verifiëren.
• Test een andere gebruiker om geheugenisolatie te verifiëren.
• Traceer welke geheugenitems zijn opgehaald voor elk antwoord.

Conclusie

Geheugenverlies van LangChain-agents wordt zelden opgelost door één groter contextvenster. Maak eerst threadstatus persistent met een checkpointer en een stabiele thread_id. Beheer vervolgens lange geschiedenissen met inkorten of SummarizationMiddleware. Plaats ten slotte feiten die over gesprekken heen moeten overleven in een namespaced langetermijn store en haal ze bewust op.

Die scheiding geeft je iets veel nuttigers dan "geheugen": een systeem dat je kunt herstarten, schalen, testen, auditen en over redeneren wanneer een gebruiker vraagt: "Waarom vergat de agent dat?"