🇫🇷🇺🇸🇧🇷🇪🇸🇩🇪🇮🇹

Añadir una memoria de sesión como en OpenClaw

Se acabó tener que re-explicar el contexto en cada sesión. Claude recuerda automáticamente lo que hiciste, las decisiones tomadas, los problemas encontrados — por proyecto, en tu repo git, sin base de datos. Portable, versionable, menos de 1 $/mes. Así se pone en marcha este sistema en menos de una hora.


Info

Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.

Lunes por la mañana. Abres Claude Code sobre un bug complejo que habías dejado pendiente el viernes. Claude no recuerda nada. Re-explicas el contexto, re-describes la arquitectura, re-listas lo que se había intentado. Quince minutos perdidos antes de poder retomar donde lo dejaste.

Es exactamente el problema que resuelve la memoria de sesión — y es lo que OpenClaw resolvió primero.


¿Qué es OpenClaw?

OpenClaw es un framework open source diseñado para Claude Code. Su objetivo: transformar Claude de un asistente sin memoria en un agente autónomo persistente, capaz de recordar lo que ha hecho, lo que se ha decidido y lo que queda por hacer.

OpenClaw funciona íntegramente en Markdown y Python, sin base de datos, sin dependencias externas. Su filosofía: los archivos planos, versionables y legibles por humanos, son la mejor memoria a largo plazo.

Su arquitectura de memoria se apoya en tres niveles: - Memoria inmediata — el contexto cargado en la sesión actual - Logs diarios — lo que ocurrió hoy (y ayer) - Memoria a largo plazo — los hechos duraderos, condensados y mantenidos al día

He adaptado esta arquitectura para mis proyectos Claude Code: un Stop hook que se ejecuta automáticamente tras cada intercambio, dos archivos Markdown por proyecto (long_memory.md + un log por día), y dos skills para cargar y consolidar la memoria. Así es como funciona y cómo ponerlo en marcha.


Por qué supone una ventaja real respecto a Claude por defecto

Claude Code dispone de una memoria automática nativa — pero tiene dos limitaciones importantes:

Memoria auto Claude Code Sistema estilo OpenClaw
Ubicación ~/.claude/projects/... (máquina local) En el repo git del proyecto
Portabilidad No — ligada a la máquina Sí — sigue el repo en cualquier lugar
Versionado No Sí — git log sobre la memoria
Granularidad Global Por proyecto / subproyecto
Inspeccionable Con dificultad Markdown legible directamente

El CLAUDE.md es otra solución, pero es un archivo de reglas estáticas — no un diario de actividad. No registra lo que se ha hecho, los problemas encontrados, ni las decisiones tomadas durante la sesión.

La memoria de sesión cubre ese vacío: captura automáticamente, en cada intercambio, lo que ha ocurrido. Sin que tengas que pensar en ello.


Arquitectura

El sistema se apoya en dos tipos de archivos Markdown, un hook Stop y un modelo Haiku que realiza la extracción.

Estructura de archivos

projet/
  memory_sessions/
    long_memory.md          ← memoria a largo plazo (condensado permanente)
    logs/
      2026-03-22.md         ← log diario estructurado por secciones
      2026-03-21.md
      archives/             ← logs > 30 días
      .debug/               ← JSON bruto Haiku (gitignored)

En un workspace multi-proyecto, cada subproyecto tiene su propio directorio memory_sessions/ — la memoria de cmms_doc no se mezcla con la de competitors.


Plantilla 1 — El log diario (logs/2026-03-22.md)

Un archivo por día, estructurado en secciones fijas. Haiku añade bullets en cada intercambio — sin duplicar nunca lo que ya existe.

# Log session — 2026-03-22

## Contexto
- Refactorización del sistema de memoria de sesión para el workspace PRODUCT_AGENTS.

## Objetivo
- Probar el nuevo formato JSON estructurado devuelto por Haiku.

## Problemas encontrados
- La extracción del transcript fallaba: mensajes tool_result filtrados incorrectamente.

## Conocimientos adquiridos
- El transcript JSONL contiene muchos mensajes con contenido vacío (tool_use, thinking) — filtrar por `content[].type == "text"`.

## Trabajo producido
- Reescritura del parser de transcript en memory-session.sh.
- Añadido del directorio .debug/ para inspeccionar el JSON bruto de Haiku.

## Decisiones tomadas
- Llamar a `claude` desde `/tmp` para evitar que el CLAUDE.md del proyecto interfiera.

## A seguir
- Validar que el descubrimiento de skills funciona tras el parche.

## Finalizado
- ✅ Validar que el descubrimiento de skills funciona tras el parche.

Cada sección tiene un papel preciso. La sección Finalizado recibe los puntos resueltos de "A seguir" — activados cuando envías OK-done a Claude.


Plantilla 2 — La memoria a largo plazo (long_memory.md)

Un condensado permanente, limitado a 300 líneas. No es un log — es lo que Haiku considera duradero: hechos técnicos, reglas de negocio, decisiones estructurales.

# Memoria a largo plazo — cmms_doc

## 2026-03-09
- El hook memory-session.sh debe llamar a `claude` desde /tmp (no desde el proyecto) para evitar la inyección del CLAUDE.md anfitrión en la respuesta de Haiku.
- Formato intermedio elegido: JSON estructurado por secciones → Python formatea el Markdown.
- Deduplicación gestionada por Haiku, que relee el log existente antes de escribir.

Cuando long_memory.md supera las 300 líneas, el skill /memory_promotion consolida y archiva las entradas más antiguas.


El mecanismo: el log diario alimenta la memoria a largo plazo

Intercambio Claude
    ↓
Haiku analiza: ¿qué conservar en el log del día?
    ↓
Log diario actualizado (secciones en modo append, deduplicación)
    ↓
Si se detecta un hecho duradero → long_memory.md actualizado
    ↓
/memory_promotion (semanal/mensual) → archiva los logs antiguos,
    consolida long_memory.md si > 300 líneas

El flujo del hook (versión simplificada)

El disparador central es un Stop hook — un script Shell que Claude Code ejecuta automáticamente al final de cada turno de conversación.

Claude responde
    ↓
Stop hook activado (settings.json)
    ↓
[Anti-bucle] stop_hook_active = true ? → exit 0
    ↓
Parsear el transcript JSONL → extraer el último intercambio humano + asistente
    ↓
Leer los logs existentes del día (para no duplicar)
    ↓
Llamar a Haiku desde /tmp con el prompt estructurado
    ↓
Haiku devuelve un JSON por secciones (objetivo, problemas, trabajo…)
    ↓
Python fusiona en el log Markdown del día
    ↓
exit 0

El anti-bucle merece una explicación: cuando el hook llama a claude, esa invocación termina y vuelve a activar el Stop hook. Claude Code inyecta entonces stop_hook_active: true en el JSON stdin. El hook detecta este flag en primer lugar y sale inmediatamente, sin procesamiento.

¿Por qué llamar a claude desde /tmp? Si el hook se ejecuta desde el directorio del proyecto, el CLAUDE.md del proyecto se inyecta en el contexto de Haiku. Resultado: Haiku sigue tus reglas de negocio en lugar de devolver JSON puro. Llamar desde /tmp neutraliza este efecto.


Cómo poner en marcha el sistema

1. Los skills de memoria

Dos skills completan el hook:

  • /memory_load [proyecto] — a llamar al inicio de la sesión. Lee long_memory.md + los logs del día y del día anterior. Muestra un resumen consolidado. Esta carga es manual — la memoria se registra automáticamente, pero no se recarga sola.
  • /memory_promotion [proyecto] — consolida los logs recientes hacia long_memory.md y archiva los logs de más de 30 días. A ejecutar manualmente, una vez por semana o por mes según tu actividad.

Los skills son archivos Markdown en .claude/skills/{nombre}/SKILL.md. Claude Code los reconoce como comandos /nombre.

2. Conectar el hook Stop

El hook Stop se declara en .claude/settings.json:

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/memory-session.sh" }
        ]
      }
    ]
  }
}

¿Cuándo se activa el Stop hook? Claude Code activa Stop al final de cada turno — es decir, tras cada respuesta completa de Claude, ya sea simple (una frase) o compleja (con llamadas a herramientas). Es diferente al final de sesión: el hook se ejecuta tras cada intercambio, no solo cuando cierras Claude Code.

3. Adaptar la lista de proyectos

En el hook, una variable PROJECT_PATHS lista los directorios de memoria de cada subproyecto:

PROJECT_PATHS = {
    "root": "memory_sessions",
    "cmms_doc": "projects/cmms_doc/memory_sessions",
    "competitors": "projects/competitors/memory_sessions",
}

Haiku analiza el intercambio y determina los proyectos implicados — luego escribe en los archivos correctos.

4. Coste

Haiku 4.5 se elige deliberadamente: rápido (~1-2 segundos) y económico. Con un uso intensivo de 20 intercambios por día, el coste se mantiene por debajo de 1 $/mes. Es insignificante para lo que aporta.


Qué cambia en la práctica

Con este sistema en marcha:

  • Vuelta tras el fin de semana: /memory_load al inicio de la sesión → Claude conoce el estado del bug, las decisiones tomadas, lo que quedaba por hacer.
  • Multi-proyecto: cada subproyecto tiene su propia memoria. Trabajar en cmms_doc y luego en competitors en la misma sesión → los logs están separados.
  • Trazabilidad: el historial de decisiones técnicas está en el repo. git log memory_sessions/ narra la evolución del proyecto.
  • Portabilidad: clonar el repo en otra máquina, la memoria está ahí.

Limitación principal

/memory_load es manual. La memoria se captura automáticamente al final del turno, pero no se recarga sola al iniciar una nueva sesión. Hay que acordarse de ejecutar /memory_load al comienzo de la sesión para beneficiarse de ella.

Es una decisión deliberada — forzar la carga automática podría contaminar el contexto de sesiones cortas o sin relación con el proyecto.


Adjuntos

La especificación técnica completa (código completo del hook, formato JSON, decisiones de implementación, bugs conocidos) está disponible como adjunto:

spec_session_memory.md

Ejemplo concreto — log diario real: el archivo siguiente es el log de sesión generado automáticamente el día en que se redactó este artículo. Ilustra lo que el sistema captura realmente en cada intercambio: contexto, trabajo producido, decisiones tomadas, puntos a seguir.

session-log-exemple.md

Para saber más

Del archivo único al sistema de contextos: por qué la memoria de un LLM no cabe en un solo documento Un archivo, unas directrices, y Claude hace el resto — cómo estructuré 500 correos sin esfuerzo