Memoria para agentes de IA con Redis: contexto entre sesiones

La memoria de agente de IA con Redis permite que tu aplicación guarde el contexto entre llamadas al modelo y lo cargue cuando el mismo usuario regresa. El modelo ve ese contexto en su siguiente solicitud. Redis almacena los datos; tu aplicación decide qué conservar, recuperar y olvidar.
En esta guía, un pequeño asistente en Python recuerda que Alice prefiere comidas vegetarianas. Detenemos un proceso de Python, iniciamos otro con un nuevo ID de sesión y le pedimos que recuerde su preferencia. Bob obtiene un perfil separado. Un comando para olvidar elimina los registros activos de Alice en Redis.
Puedes ejecutar el ejemplo localmente y luego conectar el mismo código a Managed Redis en Lizard. Utiliza comandos estándar de Hash y List de Redis, por lo que este tutorial no necesita un índice vectorial, RedisJSON ni un framework de agentes.
Probado el 25 de septiembre de 2026: Python 3.12.10, Redis 8.8.0, redis-py==5.2.1 y cuatro llamadas en vivo a openai/gpt-4.1-mini a través de OpenRouter. Las 16 comprobaciones pasaron. La prueba cubrió procesos de aplicación y sesiones separadas en una instancia local de Redis. No cubrió una instancia alojada, solicitudes concurrentes ni la recuperación tras una caída de Redis.
¿Qué debería recordar un agente de IA?
Comienza con dos tipos de datos. Necesitan claves y reglas de retención diferentes.
| Memoria | Qué contiene | Tipo en Redis | Retención en este ejemplo |
|---|---|---|---|
| Perfil de usuario | Una preferencia que el usuario guarda explícitamente | Hash | 30 días después de la última escritura en el perfil |
| Historial de sesión | Mensajes recientes del usuario y respuestas del asistente | List | Últimos 20 mensajes; expira 24 horas después del último turno completado |
El perfil pertenece al usuario, por lo que una nueva sesión puede leerlo. El historial de conversación pertenece a un usuario y a una sesión. Iniciar una segunda sesión no copia la transcripción de la primera sesión.
Esta distinción importa cuando el agente responde "¿Qué sabes sobre mí?". Un mensaje reciente puede desaparecer de una lista de historial limitada. Una preferencia guardada tiene su propio período de retención. Ninguno tiene que permanecer en el contexto del modelo para siempre.
Redis también ofrece un servicio separado de Redis Agent Memory. Este tutorial construye una pequeña capa de memoria en el código de la aplicación usando una conexión a Redis. No utiliza ese servicio ni sus funciones de extracción automática.
1. Configurar la demostración
Necesitas Python 3.10 o superior, una instancia desechable de Redis y una clave API de OpenRouter. Usa preferencias inventadas durante las pruebas: el perfil guardado y los mensajes de chat seleccionados se envían al proveedor del modelo en cada llamada.
Descarga el programa completo y probado, e instala su única dependencia de Python:
mkdir redis-memory-demo
cd redis-memory-demo
python3 -m venv .venv
. .venv/bin/activate
python -m pip install redis==5.2.1
curl -fsSLo memory_agent.py \
https://lizard.build/blog-examples/redis-agent-memory/memory_agent.pyPara una prueba local, ejecuta Redis en una terminal separada. Este comando lo vincula al loopback en el puerto 6387; mantén esa terminal en ejecución:
redis-server --bind 127.0.0.1 --port 6387 --save "" --appendonly noEste proceso local de Redis es deliberadamente desechable. Sus datos siguen disponibles cuando la aplicación de Python se cierra, pero detener Redis hace que se pierdan esos datos. La prueba a continuación reinicia la aplicación, no la base de datos.
Crea un archivo .env privado en el directorio de la demostración usando tu editor:
REDIS_URL=redis://127.0.0.1:6387/0
OPENROUTER_API_KEY=replace-with-your-key
OPENROUTER_MODEL=openai/gpt-4.1-miniMantén .env fuera de Git. Restringe el acceso y cárgalo en la shell actual:
chmod 600 .env
set -a
. ./.env
set +aEl ejemplo llama a la API de Chat Completions de OpenRouter. Redis maneja las mismas lecturas y escrituras de memoria si reemplazas la llamada al modelo con otro proveedor.
2. Dar a cada usuario y sesión sus propias claves
El programa crea claves como estas:
agentmem:v1:{alice}:profile
agentmem:v1:{alice}:session:session-1
agentmem:v1:{alice}:session:session-2
agentmem:v1:{bob}:profileEl prefijo de versión da a los futuros formatos de datos un espacio de nombres separado. El ID de usuario separa los perfiles. El ID de sesión separa las conversaciones. Las llaves son un hash tag de Redis; mantienen las claves de un usuario en el mismo hash slot si más adelante usas Redis Cluster. Esta guía prueba una única instancia de Redis.
La demostración valida los IDs antes de construir las claves. En una aplicación web, deriva el ID de usuario de la sesión autenticada del servidor. No aceptes el ID de otro usuario desde el cuerpo de una solicitud ni lo trates como prueba de identidad. Los nombres de las claves de Redis por sí solos no controlan quién puede acceder a los datos de un usuario.
3. Guardar una preferencia explícita
Guarda la elección de Alice:
python memory_agent.py remember --user alice --preference vegetarianEl comando imprime Preference saved. Internamente, escribe un campo en un Hash de Redis y establece la expiración del perfil en una transacción:
with client.pipeline(transaction=True) as tx:
tx.hset(profile, mapping={"dietary_preference": preference})
tx.expire(profile, 30 * 24 * 60 * 60)
tx.execute()Los únicos valores permitidos son vegetarian, vegan y no_preference. Ese pequeño esquema hace que el ejemplo sea fácil de inspeccionar. El modelo no puede escribir afirmaciones arbitrarias en el perfil. En un producto real, un control de "Recordar esto" puede hacer la misma escritura validada después de que el usuario lo confirme.
Esta guía no infiere preferencias de cada mensaje de chat. Cambiar o corregir una preferencia utiliza el mismo comando explícito, que sobrescribe ese campo y renueva su TTL de 30 días.
4. Cargar la memoria antes de llamar al modelo
Pide al asistente que recuerde la elección guardada:
python memory_agent.py chat --user alice --session session-1 \
--message "What dietary preference have I saved?"En nuestra prueba, el modelo respondió:
Your saved dietary preference is vegetarian.Para cada llamada, la aplicación lee el perfil del usuario y los mensajes recientes de la sesión actual. Construye la solicitud al modelo en este orden:
- Instrucciones que definen la tarea del asistente.
- Un mensaje de datos que contiene la preferencia guardada permitida.
- Los mensajes recientes del usuario y del asistente de esta sesión.
- La nueva pregunta del usuario.
El modelo no tiene credenciales directas de Redis ni una herramienta general de base de datos. Solo recibe el contexto seleccionado. Después de una respuesta exitosa, la aplicación almacena juntos los nuevos mensajes del usuario y del asistente:
with client.pipeline(transaction=True) as tx:
tx.rpush(history, *rows)
tx.ltrim(history, -20, -1)
tx.expire(history, 24 * 60 * 60)
tx.execute()Cada turno aporta dos mensajes, por lo que la lista mantiene los últimos diez turnos completos. La aplicación también limita cada mensaje a 2.000 caracteres. Un simple recuento de mensajes no limitaría el tamaño del contexto si un mensaje pudiera contener un libro entero.
En este ejemplo, leer la memoria no renueva su expiración. Las escrituras en el perfil renuevan el TTL del perfil; los turnos de chat completados renuevan el TTL de la sesión. Consulta la referencia de EXPIRE de Redis para ver cómo interactúa la expiración con las actualizaciones.
5. Iniciar un nuevo proceso y una nueva sesión
Cada comando de la CLI inicia y cierra su propio proceso de Python. Ejecuta un segundo comando de chat con un ID de sesión diferente:
python memory_agent.py chat --user alice --session session-2 \
--message "What dietary preference have I saved?"El modelo volvió a devolver Your saved dietary preference is vegetarian. La nueva sesión comenzó sin los mensajes de la primera conversación. Su solicitud contenía el perfil de usuario compartido, lo cual fue suficiente para responder.
Inspecciona los registros que lee la aplicación:
python memory_agent.py inspect --user alice --session session-2Deberías ver un perfil con dietary_preference y un historial con la pregunta del usuario y la respuesta del asistente de esa sesión. Este proceso no cambia los pesos del modelo ni le añade memoria interna permanente. La aplicación proporciona el contexto almacenado en cada solicitud.
6. Comprobar la separación de usuarios y el olvido
Primero, inspecciona el contexto de otro usuario:
python memory_agent.py inspect --user bob --session session-1Para un perfil nuevo de Bob, el resultado es:
{
"profile": {},
"history": []
}Hacerle al asistente de Bob la misma pregunta de preferencia produjo Your dietary preference is unknown. en nuestra prueba. El contexto vacío es la comprobación de aislamiento determinista; la redacción del modelo puede variar.
A continuación, detén cualquier solicitud para Alice y elimina su memoria activa en Redis:
python memory_agent.py forget-user --user alice
python memory_agent.py inspect --user alice --session session-1
python memory_agent.py inspect --user alice --session session-2Ambas inspecciones deberían devolver perfiles e historiales vacíos. El comando escanea solo el prefijo de clave validado de Alice y desvincula las claves coincidentes. Deja intactas las claves de Bob.
Para una aplicación desplegada, bloquea las nuevas escrituras para ese usuario mientras se ejecuta el borrado. De lo contrario, una respuesta que termine durante el escaneo podría recrear una sesión. Eliminar las claves de Redis tampoco elimina los registros del proveedor, las copias de seguridad o los registros en otra base de datos; esos almacenes necesitan sus propias reglas de retención y borrado.
Qué probamos
El script de verificación inicia un nuevo proceso de Redis en un puerto loopback disponible. Nunca se conecta a una base de datos existente. Sus resultados guardados registran las versiones, el alcance y cuatro respuestas del modelo.
| Comprobación | Resultado |
|---|---|
| Una preferencia guardada sobrevive a procesos separados de Python | Aprobado |
| Una nueva sesión carga el perfil sin la transcripción antigua | Aprobado |
| Otro usuario comienza con un contexto vacío | Aprobado |
| Las claves de perfil y sesión expiradas desaparecen | Aprobado |
| El historial se mantiene dentro de los 20 mensajes y conserva turnos completos | Aprobado |
| Olvidar elimina tanto las sesiones como el perfil, dejando intacto a otro usuario | Aprobado |
| Las llamadas en vivo al modelo recuerdan la preferencia antes del borrado y la reportan como desconocida después | Aprobado |
El entorno de pruebas ejecutó 16 comprobaciones en total. Estos resultados muestran que las lecturas y escrituras del ejemplo funcionan como se describe. No establecen una garantía de disponibilidad en producción ni de recuperación de datos.
Conectar el ejemplo a Managed Redis
Después de la prueba local, crea una instancia separada de Redis para tu proyecto. En un proyecto vinculado de Lizard, ejecuta:
lizard add redisPara un servicio desplegado llamado api, configura la referencia de conexión y vuelve a desplegar:
lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service api
lizard redeploy --service apiEstos comandos asumen que el servicio ya existe y tiene configurada su clave API del modelo. Conectan ese servicio a Redis; la demostración de la CLI en sí no es un servidor HTTP. Sigue la guía de conexión de Managed Redis para las variables de entorno y el acceso desde tu computadora.
Puedes inspeccionar las claves de la demostración en el navegador de Redis en el panel de control. Mantén las credenciales de Redis en el servidor y usa una conexión privada o TLS verificado cuando tu proveedor lo suministre. Una URL redis:// simple no añade cifrado de transporte.
Decidir qué recuerdos deben sobrevivir a la pérdida de datos
Que la memoria sobreviva al reinicio de una aplicación no significa que sobreviva a cualquier fallo de Redis. La expiración, la evicción de claves, la configuración de persistencia y las copias de seguridad son importantes.
Managed Redis documenta actualmente una política de evicción allkeys-lru: la presión de memoria puede eliminar cualquier clave, incluido un perfil cuyo TTL no ha transcurrido. Para las preferencias que no puedes permitirte perder, mantén el registro de origen en Managed Postgres y usa Redis para el contexto reciente o una copia que puedas volver a cargar. Revisa la guía de almacenamiento y recuperación antes de elegir una política de retención.
Antes de poner esto detrás de una API web
La CLI mantiene el ejemplo pequeño. Una aplicación compartida también necesita:
- Comprobaciones de autenticación y propiedad. Deriva los IDs de usuario en el servidor y comprueba que cada sesión pertenece a ese usuario.
- Un turno activo por sesión. Pon en cola o bloquea la secuencia completa de lectura → llamada al modelo → escritura. La transacción final de Redis por sí sola no impide que dos llamadas al modelo lean el mismo contexto antiguo.
- Un límite de uso de memoria. Limita los campos del perfil, el tamaño de los mensajes, la longitud del historial y el número de sesiones. Monitorea la memoria y las evicciones de Redis.
- Una política de fallos de Redis. Devuelve un error claro en la solicitud u ofrece un modo explícitamente sin estado. Nunca afirmes que se guardó una preferencia cuando la escritura falló.
- Separar los permisos del texto guardado. Un mensaje guardado puede contener instrucciones hostiles. Mantén los permisos y las decisiones de herramientas en el código de la aplicación; un prompt del sistema no es un límite de control de acceso.
Preguntas frecuentes
¿Necesito una base de datos vectorial para la memoria de un agente de IA?
Puedes cargar las preferencias explícitas y los mensajes recientes de un usuario conocido por clave, como hace este ejemplo. La búsqueda vectorial resulta útil cuando la aplicación debe encontrar hechos relevantes en un conjunto mucho mayor de recuerdos. Eso añade embeddings, configuración de índices y pruebas de recuperación.
¿Redis hace que un agente recuerde para siempre?
La retención depende de los TTLs, la evicción, la persistencia y las escrituras de tu aplicación. Este ejemplo expira los datos deliberadamente. Mantén registros duraderos en otro lugar cuando perderlos rompería el producto.
¿Es esto RAG o una caché semántica?
Este ejemplo recupera el contexto guardado de un usuario. RAG comúnmente recupera material de origen relevante para ayudar a responder una pregunta. Una caché semántica reutiliza una respuesta anterior para una consulta similar. Pueden compartir la infraestructura de Redis, pero necesitan modelos de datos y pruebas diferentes.
¿Puedo usar LangGraph más adelante?
Sí. LangGraph ofrece puntos de control para el estado de la conversación y almacenes para la memoria entre hilos. Su integración con Redis tiene sus propios requisitos; consulta la documentación del paquete de Redis para LangGraph antes de reemplazar este cliente simple con un backend de framework.
Dale a tu agente una memoria que puedas inspeccionar
Comienza con un hecho explícito, un historial de sesión separado y una prueba que lea los datos desde un proceso nuevo. Añade expiración, comprobaciones de propiedad y una forma de olvidar antes de añadir extracción automática o búsqueda vectorial.
Crea Managed Redis para el contexto compartido de la aplicación. Si tu agente también necesita consultar datos estructurados del proyecto, la guía de Postgres MCP cubre esa conexión con un rol de lector de base de datos separado.
Construye con IA. Publica con Lizard.
No necesitas un equipo de plataforma para publicar. Todo tu entorno está a un solo comando de Lizard CLI.
- Espacios de trabajo
- —
- Servicios
- —
- Add-ons
- —
- Despliegues
- —