Cómo corregir la pérdida de memoria del agente LangChain en conversaciones largas

Si un agente de LangChain olvida detalles durante una conversación larga, corrige la arquitectura antes de aumentar la ventana de contexto del modelo. En los agentes actuales de estilo LangChain v1, la continuidad de la conversación se construye a partir de dos capas separadas: un checkpointer para el estado de corto alcance con ámbito de hilo y un store (almacén) para información de largo plazo que debe sobrevivir entre hilos. Las conversaciones largas requieren entonces una tercera consideración: la gestión del contexto, generalmente recortando o resumiendo mensajes antiguos antes de que abrumen al modelo.

Esta guía sigue la documentación oficial de LangChain verificada el 11 de septiembre de 2026. La documentación actual recomienda langchain.agents.create_agent para nuevos agentes y describe la persistencia de LangGraph como el sistema de memoria subyacente. Los ejemplos más antiguos basados en ConversationChain, ConversationBufferMemory o initialize_agent pueden seguir apareciendo en material heredado, pero la guía de migración de LangChain v1 movió las cadenas heredadas y otras funcionalidades obsoletas a langchain-classic. Consulta la guía oficial de migración de LangChain v1.

Qué significa realmente la "pérdida de memoria" en LangChain

Antes de cambiar el código, separa tres problemas que a menudo parecen idénticos desde el punto de vista del usuario.

La documentación de memoria de corto plazo de LangChain define la memoria de corto plazo como el estado dentro de un solo hilo. Su documentación de memoria de largo plazo define la memoria de largo plazo como información que persiste entre diferentes conversaciones y sesiones.

Qué necesitas antes de comenzar

Necesitas una aplicación LangChain/LangGraph actual, una integración de modelo y un lugar para persistir el estado. Para un experimento local, InMemorySaver es suficiente. Para producción, usa un checkpointer respaldado por una base de datos. La documentación oficial de LangChain muestra PostgreSQL a través del paquete separado langgraph-checkpoint-postgres.

Mantén claros cuatro identificadores:

• ID de conversación o chat: el identificador que tu aplicación expone a los usuarios.
• thread_id: la clave de persistencia de LangGraph utilizada para reanudar el estado de un hilo.
• ID de usuario: la identidad duradera utilizada para nombrar espacios de memoria de largo plazo.
• Clave de memoria: la clave para un elemento duradero dentro de un espacio de nombres de store.

No deberían ser automáticamente el mismo valor. Un usuario puede tener muchos hilos, y un hilo puede contener muchos hechos.

Paso 1: Reproduce el fallo con una prueba de dos solicitudes

Comienza con la prueba más pequeña posible. Pide al agente que recuerde un detalle único, luego invócalo de nuevo y pide ese detalle. No pruebes la memoria con una sola llamada a invoke() porque el modelo puede ver todo en esa única solicitud incluso cuando la persistencia está rota.

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

Si la segunda solicitud olvida "Juniper", inspecciona la configuración del checkpointer y el thread_id real antes de cambiar los prompts.

Paso 2: Añade un checkpointer para memoria del mismo hilo

Un checkpointer persiste instantáneas del estado del grafo del agente. LangGraph lo utiliza para memoria de corto plazo, recuperación de interrupciones, flujos con intervención humana y tolerancia a fallos. La guía de persistencia actual describe los checkpointers como de ámbito de hilo y dice que la aplicación accede al estado pasando un thread_id. Consulta la guía oficial de persistencia de LangGraph.

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 es excelente para confirmar que tu cableado de hilo funciona, pero almacena checkpoints en RAM. LangGraph advierte explícitamente que MemorySaver/InMemorySaver no persisten entre reinicios de proceso.

Paso 3: Mantén el mismo thread_id para la misma conversación

El error más común a nivel de aplicación es crear un nuevo thread_id en cada solicitud HTTP. La base de datos puede estar funcionando perfectamente mientras cada solicitud inicia un hilo de LangGraph diferente.

Por ejemplo, supongamos que tu frontend tiene el ID de chat chat_8bf4. Asigna ese valor determinísticamente al hilo de LangGraph y reutilízalo para cada turno en ese chat. Un nuevo chat debe recibir un nuevo ID de hilo.

No uses un thread_id permanente para todos los chats que pertenecen al mismo usuario. Eso fusiona conversaciones no relacionadas en un solo flujo de estado. Si usas PostgreSQL, la guía actual de resolución de problemas de LangGraph también dice que thread_id debe permanecer por debajo de 255 caracteres; un UUID o un hash determinístico es más seguro que un objeto serializado enorme.

Paso 4: Reemplaza la persistencia en memoria antes de producción

Una vez que la prueba de dos solicitudes pase, prueba un reinicio de proceso. Guarda un hecho, detén la aplicación, iníciala de nuevo, luego pide el hecho con el mismo ID de hilo. Si aún usas InMemorySaver, olvidar es el comportamiento esperado.

La documentación oficial de memoria de corto plazo muestra una configuración de producción respaldada por PostgreSQL usando 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,
    )

Para la configuración del paquete documentada actualmente por LangChain, consulta Memoria de corto plazo. No pongas credenciales reales de base de datos directamente en el código fuente; usa tu sistema normal de gestión de secretos.

Paso 5: Gestiona historiales largos en lugar de enviarlo todo para siempre

Una ventana de contexto es la cantidad de contexto de entrada y salida que un modelo puede manejar en una llamada al modelo. El checkpointing puede preservar una conversación muy larga en el almacenamiento, pero eso no significa que cada mensaje histórico deba enviarse de vuelta al modelo para siempre.

La guía de memoria de corto plazo de LangChain dice que los historiales largos pueden exceder la ventana de contexto del modelo y que incluso los modelos capaces de aceptar el historial completo pueden distraerse con contenido obsoleto o fuera de tema, con mayor latencia y costo. Las estrategias documentadas son recortar, eliminar, resumir o aplicar una política personalizada.

Usa resumen cuando los detalles antiguos aún importan

SummarizationMiddleware es la opción integrada actual para reemplazar el historial antiguo con un resumen compacto mientras retiene mensajes recientes. Su disparador puede basarse en el conteo de tokens, el conteo de mensajes o una fracción del contexto del modelo.

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

Los números anteriores son una política de ejemplo, no configuraciones universales. Elige umbrales después de medir tus propios prompts, salidas de herramientas, límites de contexto del modelo, latencia y calidad del resumen. Consulta la documentación de middleware integrado de LangChain para las opciones de disparador y retención actualmente soportadas.

No recortes mensajes de herramientas a ciegas

Si implementas eliminación o recorte personalizado, preserva una secuencia de mensajes válida. LangChain advierte que muchos proveedores requieren que un mensaje de asistente que contenga llamadas a herramientas sea seguido por los mensajes de resultado de herramientas correspondientes. Eliminar una mitad de ese par puede crear errores de proveedor o comportamiento confuso del modelo.

Paso 6: Mueve hechos duraderos a un store de largo plazo

Un store es la capa de persistencia de LangGraph para datos definidos por la aplicación fuera del estado del grafo de un hilo. La documentación actual de LangChain usa stores para información que debe estar disponible entre conversaciones, como preferencias de usuario, hechos o conocimiento compartido de la aplicación.

Los elementos del store de largo plazo son documentos JSON organizados por un espacio de nombres y una clave. Un espacio de nombres práctico a menudo contiene un identificador de usuario u organización:

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

Esto es diferente a guardar la transcripción completa. Almacena la información que tu producto trata intencionalmente como duradera. Si un hecho es privado o regulado, aplica tus políticas normales de retención, autorización, cifrado y eliminación en lugar de asumir que la "memoria del agente" está exenta de ellas.

Usa un store respaldado por base de datos en producción

La guía oficial de memoria de largo plazo muestra tanto InMemoryStore como PostgresStore, y nota explícitamente que la implementación en memoria debe ser reemplazada por un store respaldado por base de datos para producción. También enumera integraciones de store más allá de PostgreSQL. Usa el backend que se ajuste a tus requisitos de despliegue y operativos en lugar de seleccionar una base de datos vectorial simplemente porque la palabra "memoria" está involucrada.

Añade búsqueda semántica solo cuando necesites recuerdo difuso

Los stores de LangGraph pueden configurarse con un índice para que store.search() pueda recuperar elementos por similitud semántica. Eso es útil cuando tienes muchos recuerdos y no conoces la clave exacta. Para un pequeño conjunto de preferencias estructuradas, la búsqueda directa por espacio de nombres/clave suele ser más simple y determinística.

Paso 7: Haz explícitas las rutas de lectura y escritura de memoria

Persistir un elemento de largo plazo no garantiza que el agente lo use. La aplicación aún necesita una ruta de recuperación. Los agentes actuales de LangChain permiten que las herramientas accedan al store suministrado a través de 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"

También puedes construir prompts dinámicos o middleware que lea el estado y la memoria duradera antes de una llamada al modelo. La regla de diseño importante es que la ruta de recuperación debe ser observable y testeable. "La información existe en algún lugar de la base de datos" no es suficiente.

Paso 8: Prueba las cuatro fronteras de memoria por separado

Una suite de pruebas de memoria confiable debe cubrir más que "el modelo recordó mi nombre una vez". Usa al menos estos cuatro casos:

Luego añade una prueba de conversación larga que exceda tu umbral de resumen. Asegura que los hechos duraderos importantes sobrevivan, que las secuencias recientes de llamadas a herramientas permanezcan válidas y que el tamaño del prompt se mantenga dentro de tu presupuesto de contexto objetivo.

Una arquitectura de producción mínima

Para muchas aplicaciones de agentes, un diseño robusto se ve así:

1. La API recibe user_id, conversation_id y el nuevo mensaje del usuario.
2. La aplicación asigna conversation_id a un thread_id estable de LangGraph.
3. Un checkpointer persistente restaura el estado del hilo.
4. Un store de largo plazo recupera solo los hechos duraderos de usuario o aplicación necesarios para la solicitud.
5. El resumen o recorte mantiene el historial orientado al modelo dentro de un presupuesto de contexto medido.
6. El agente ejecuta herramientas y el modelo.
7. El checkpointer confirma el estado del hilo actualizado.
8. Solo los hechos aprobados se escriben en el store de largo plazo.

Si despliegas a través de LangGraph Agent Server, la guía de persistencia actual dice que el servidor maneja la infraestructura de persistencia automáticamente, así que no dupliques esa capa sin verificar el modelo de despliegue.

Errores comunes que hacen que la memoria parezca rota

Generar un nuevo thread_id para cada solicitud

Esto crea un nuevo estado de conversación cada turno. Registra el ID de hilo junto con el ID de chat de tu aplicación y verifica la reutilización.

Usar InMemorySaver en un servicio multi-worker o reiniciable

El estado local en RAM desaparece con el proceso y puede no compartirse entre workers. Usa un backend persistente para la continuidad en producción.

Asumir que un checkpointer resuelve el problema de la ventana de contexto

Un checkpointer preserva el estado; no garantiza que un transcripción en constante crecimiento sea útil para el modelo. Añade una política explícita de gestión de contexto.

Poner cada hecho histórico en el prompt

Más contexto no es automáticamente mejor contexto. Recupera información que sea relevante para el turno actual y preserva la continuidad conversacional reciente por separado.

Tratar los resúmenes como una base de datos perfecta

Los resúmenes son representaciones comprimidas generadas por el modelo. Si un hecho debe ser exacto—un identificador de cuenta, una restricción contractual, una preferencia aprobada por el usuario o un estado de flujo de trabajo—almacénalo como datos estructurados en lugar de esperar que sobreviva a resúmenes repetidos.

Mezclar alcances de corto y largo plazo

El historial de hilo no debería convertirse silenciosamente en un perfil global de usuario. Inversamente, una preferencia de usuario destinada a seguir al usuario entre chats no debería vivir solo en un hilo.

Copiar tutoriales de memoria pre-v1 sin verificar imports

Si un ejemplo comienza desde cadenas heredadas o viejas clases de memoria, compáralo con la migración v1 actual y la documentación de memoria antes de usarlo en una nueva aplicación.

Lista de verificación de depuración

• Confirma que el agente fue creado con un checkpointer.
• Registra y compara thread_id entre solicitudes consecutivas.
• Inspecciona el estado del hilo almacenado antes de culpar al modelo.
• Reinicia el proceso y repite la misma prueba de hilo.
• Reemplaza InMemorySaver con un checkpointer persistente para producción.
• Mide el crecimiento de mensajes/tokens en chats largos.
• Habilita resumen o recorte antes de que el historial se vuelva excesivo.
• Mantén las secuencias de llamada/resultado de herramientas válidas al eliminar mensajes.
• Mueve hechos entre hilos a un store de largo plazo con espacio de nombres.
• Prueba un nuevo hilo para el mismo usuario para verificar el recuerdo de largo plazo intencional.
• Prueba un usuario diferente para verificar el aislamiento de memoria.
• Rastrea qué elementos de memoria fueron recuperados para cada respuesta.

Conclusión

La pérdida de memoria del agente LangChain rara vez se resuelve con una ventana de contexto más grande. Primero haz que el estado del hilo sea persistente con un checkpointer y un thread_id estable. Luego controla los historiales largos con recorte o SummarizationMiddleware. Finalmente, coloca los hechos que deben sobrevivir entre conversaciones en un store de largo plazo con espacio de nombres y recupéralos deliberadamente.

Esa separación te da algo mucho más útil que "memoria": un sistema que puedes reiniciar, escalar, probar, auditar y analizar cuando un usuario pregunta, "¿Por qué el agente olvidó?"