Explicación de la memoria OpenClaw: arquitectura, configuración y por qué se olvida — EasyClaw

La arquitectura de memoria OpenClaw completa (explicación de 3 capas)

La memoria OpenClaw opera en tres capas distintas, cada una con diferentes características de persistencia y modos de falla.

Ciclo de vida completo de la memoria:

Write → Embed/Index → Search → Compact → Recover
  ↓          ↓           ↓         ↓         ↓
.md file   sqlite-vec  semantic  summary   MEMORY.md
created    indexes it  query     replaces  re-read at
           on save     returns   context   session start
                       chunks    window

Cada etapa de esta cadena puede fallar de forma independiente. La mayoría de los problemas de olvido se remontan exactamente a una etapa rota.

Layer 1: la ventana de contexto activo

Esta es la memoria de trabajo del modelo: todo lo que está actualmente cargado en la ventana contextual de la conversación activa. Incluye el mensaje del sistema, el historial de conversaciones y cualquier fragmento de memoria recuperado por la herramienta de búsqueda.

Qué lo llena:

• Aviso del sistema (a menudo grande)
• Extractos de memoria recuperados
• Historial de llamadas de herramientas
• La conversación gira

Límite práctico: suponga que tiene aproximadamente entre el 60% y el 70% de la ventana de contexto anunciada del modelo disponible para la conversación real después del aviso del sistema y la sobrecarga de memoria.

Layer 2 — Notas diarias (la ventana móvil de dos días)

Las notas diarias son archivos Markdown de solo anexar nombrados en formato YYYY-MM-DD almacenados dentro de su directorio memory/. Cargas OpenClaw el de hoy y el de ayer archivos automáticamente al inicio de cada sesión.

• Aquí se adjuntan datos sobre el trabajo actual, las decisiones tomadas y las tareas activas.
• No están destinados a ser editados; trátelos como un registro.
• Después de dos días, quedan fuera de la ventana de carga automática y solo se pueden buscar mediante búsqueda semántica.

Layer 3: memoria duradera (MEMORY.md y Memory-wiki)

Los datos a largo plazo que deberían sobrevivir a través de las sesiones (su nombre, contexto del proyecto, preferencias de codificación, decisiones arquitectónicas) pertenecen a MEMORY.md o a la bóveda de complementos estructurada memory-wiki.

El problema de la compactación: por qué sus instrucciones desaparecen a mitad de la tarea

La compactación es el modo de falla menos documentado en OpenClaw. La mayoría de los artículos cubren el olvido posterior a la sesión. Casi ninguna dirección Compactación a mitad de tarea en flujos de trabajo autónomos de larga duración. — cuando el agente está ejecutando una tarea de varios pasos, la compactación se activa silenciosamente en el paso 7 de 12 y las instrucciones de comportamiento del paso 1 desaparecen.

Qué hace la compactación:

1. Detecta la ventana de contexto acercándose a su capacidad
2. Resume la conversación actual en un bloque condensado.
3. Reemplaza el contexto original con el resumen.
4. Continúa la ejecución

Cuando se desencadena: No hay un umbral configurable en el complemento memory-core predeterminado. Se activa según el recuento de tokens, no la etapa de la tarea. En un funcionamiento autónomo de 2 horas, se pueden esperar entre 3 y 5 ciclos de compactación.

Cómo construir una arquitectura de archivos resistente a la compactación

Fije instrucciones de comportamiento en MEMORY.md, no en la conversación. Todo lo que deba sobrevivir a múltiples ciclos de compactación debe estar en un archivo duradero que se pueda volver a leer después de cada compactación.

Patrón de fijación recomendado:

## Agent Behavioral Rules (always active)
- Never overwrite files without showing a diff first
- Write tests before implementation (TDD mode: on)
- Use TypeScript strict mode in all new files

## Project Context
- Stack: Node.js 22, Fastify, PostgreSQL 16
- Repo root: /home/user/project
- Active sprint goal: migrate auth to Clerk

Convenciones de nomenclatura que sobreviven a la compactación:

• Prefije las secciones críticas con ## [PINNED]: el resumidor trata los encabezados en mayúsculas como de alta prioridad.
• Mantenga cada hecho fijado en una línea siempre que sea posible: los párrafos densos se resumen, los hechos de una sola línea tienden a sobrevivir palabra por palabra.
• Repita las 3 a 5 reglas de comportamiento más importantes tanto en MEMORY.md como en la nota diaria de hoy: la redundancia es su protección de compactación

Configuración de cero a memoria en 10 minutos (estructura de archivos completa)

Esta es la guía de configuración que no existe en ningún otro lugar. Copie esta estructura, complete su contexto y estará corriendo.

Árbol de directorios:

memory/
├── MEMORY.md
├── 2026-04-27.md          ← today's daily note (create manually)
└── wiki/                  ← only if using memory-wiki plugin
    ├── index.md
    ├── project-context.md
    └── decisions.md

Arrancador MEMORY.md:

# Persistent Memory

## Identity & Preferences
- Name: [your name]
- Role: [your role]
- Preferred response style: concise, no preamble

## Project: [Project Name]
- Stack: [your stack]
- Key constraints: [e.g., no external APIs, TypeScript only]
- Current focus: [active task or sprint goal]

## Behavioral Rules
- [Rule 1]
- [Rule 2]

## Decisions Made
- [YYYY-MM-DD] Decided to use X because Y

Nota diaria inicial (2026-04-27.md):

# 2026-04-27

## Session Goals
- [ ] Task 1
- [ ] Task 2

## Notes

Configuración de ranura de complemento (sintaxis 2026):

{
  "plugins": {
    "slots": {
      "memory": "memory-core"
    }
  }
}

Para desactivar la memoria por completo:

{
  "plugins": {
    "slots": {
      "memory": false
    }
  }
}

Pasos de verificación:

1. Ejecute una sesión y pídale al agente que recuerde algo que le dijo en una sesión anterior.
2. Verifique que memory/YYYY-MM-DD.md esté escrito (debe tener contenido nuevo)
3. Pregúntale directamente al agente: "¿Qué sabes de mí?" — debería extraerse de MEMORY.md

Configuring memory-wiki para una base de conocimientos de producción

Habilítelo intercambiando la ranura del complemento:

{
  "plugins": {
    "slots": {
      "memory": "memory-wiki"
    }
  }
}

Memory-wiki genera una bóveda estructurada en memory/wiki/. Cada tema tiene su propia página. El complemento compila un digest.md que agrega hechos no contradictorios y de alta confianza para que el agente los cargue al inicio de la sesión.

Estructura de bóveda práctica para un agente de producción:

memory/wiki/
├── index.md              ← vault table of contents
├── digest.md             ← auto-generated; agent reads this
├── project-context.md    ← stack, goals, constraints
├── decisions.md          ← architectural decisions log
├── team.md               ← stakeholders, contacts
└── domain-knowledge.md   ← business rules, glossary

Semantic Search and Embeddings: SQLite, sqlite-vec y JS Fallback

OpenClaw indexa sus archivos de memoria usando SQLite with the sqlite-vec extension para búsqueda de similitud de vectores. Cuando usted o el agente realizan una búsqueda de memoria, ésta incorpora la consulta y recupera los fragmentos semánticamente más relevantes.

Verifique que su tienda de vectores esté en buen estado:

# Check that the memory index exists
ls memory/.index/

# Reset a corrupted index (safe to run — it rebuilds from .md files)
rm -rf memory/.index/ && OpenClaw reindex

Si sqlite-vec no está disponible (común en ARM Linux y algunas configuraciones de Windows), OpenClaw recurre a una extensión vectorial puramente JS. Forzar el retroceso explícitamente:

{
  "memory": {
    "vectorBackend": "js"
  }
}

Segment-Specific Memory Strategies

Solo Developer: gastos generales mínimos, recuperación máxima

Configuración recomendada: complemento memory-core, MEMORY.md + solo notas diarias, sin bóveda wiki.

• Mantenga MEMORY.md por debajo de 200 líneas: los archivos más largos ralentizan el inicio de la sesión
• Agregue agresivamente notas diarias; no intentes mantenerlos limpios
• Revise y elimine MEMORY.md semanalmente: los datos obsoletos degradan la calidad de la búsqueda

Canalización de múltiples agentes: memoria compartida entre agentes

Cuando varios agentes leen y escriben en el mismo directorio memory/, necesita reglas de propiedad explícitas.

• One agent owns writes to each file — las escrituras simultáneas en el mismo archivo .md producirán conflictos
• Utilice subdirectorios por agente: memory/agent-a/, memory/agent-b/, con un memory/shared/MEMORY.md compartido
• Utilice Memory-wiki para la bóveda compartida: su compilación resumida maneja la actualización entre varios escritores mejor que los archivos sin formato.

Long-Running Autonomous Tasks — Sobrevivir a las horas de ejecución

Para agentes que ejecutan tareas medidas en horas:

• Force memory writes at checkpoints — después de cada etapa importante de la tarea, indique al agente que agregue su estado actual a la nota diaria de hoy
• Pre-load compaction-resistant context — coloque la especificación completa de la tarea en MEMORY.md antes de que comience la ejecución, no solo en el mensaje inicial
• Set explicit continuation markers en notas diarias: <!-- RESUME POINT: completed steps 1-4, next: step 5 --> para que el agente pueda autoorientarse después de un ciclo de compactación

Troubleshooting OpenClaw Memory: diagnostica cualquier problema de olvido en 2 minutos

Siga estos pasos en orden:

Frequently Asked Questions

Veredicto final: la configuración de la memoria que realmente se mantiene

Recommended baseline para la mayoría de los usuarios: Complemento memory-core, directorio memory/ creado antes de la primera sesión, MEMORY.md con reglas de comportamiento en una sección fijada claramente etiquetada, notas diarias adjuntas a lo largo de cada sesión.

Su lista de verificación de acciones:

• Cree el directorio memory/ en la raíz de su proyecto
• Copie la plantilla inicial MEMORY.md anterior y complete su contexto
• Verifique que plugins.slots.memory esté configurado en "memory-core" (o el complemento elegido)
• Agregue entre 3 y 5 reglas de comportamiento más importantes en ## [PINNED] en MEMORY.md
• Después de su primera sesión, confirme que se escribió una nota diaria con fecha.
• Si la búsqueda semántica no funciona, ejecute OpenClaw reindex para reconstruir el índice vectorial

La arquitectura es sólida una vez que la entiendes. La mayoría de los problemas de olvido se resuelven dentro de los 10 minutos siguientes a seguir esta lista de verificación.