Memoria OpenClaw: Verifique la escritura, el índice, la búsqueda y el reinicio

La memoria OpenClaw sólo es saludable cuando cuatro afirmaciones diferentes son ciertas: el registro previsto fue escrito para almacenamiento duradero, el índice actual cubre lo que escribe, la recuperación devuelve el anclaje de origen correcto, y una sesión nueva todavía aplica la decisión correctamente. Un archivo Markdown en el disco prueba sólo la primera afirmación. Una búsqueda exitosa sólo prueba que alguna pieza indexada coincidió. Utilice una auditoría de contenido minimizado que mantiene el texto de memoria en el host. Registra ID opacos, resultados de comparación locales, sellos de tiempo y anclajes de origen; no exporta instrucciones, contenido de notas, trayectos absolutos o fragmentos de búsqueda crudos. El operador debe ser capaz de distinguir una escritura faltante, índice obsoleto, recuperación incorrecta, y decisión perdida en lugar de colapsar los cuatro en memoria se rompe. Tratar la memoria OpenClaw como cuatro pruebas separadas El OpenClaw de la memoria de visión general actual describe la memoria como Markdown en el espacio de trabajo del agente. MEMORY.md es la capa curada a largo plazo, mientras que los archivos fechados bajo memory/ contienen un contexto diario detallado. El modelo recuerda lo que llega al disco; no hay estado duradero oculto que rescate una escritura omitida. Este diseño crea puntos de inspección útiles: 1. Escribe prueba: el archivo esperado existe y su contenido local coincide con la versión que se pretendía que persistiera. 2. Index proof: el backend de la memoria ha indexado la instantánea fuente actual en lugar de una anterior. 3. D prueba de recuperación: una consulta devuelve el archivo esperado y el rango de líneas, no simplemente una frase plausible de otro lugar. 4. Probe de decisión: después de un límite de sesión real, el agente sigue la decisión guardada y su límite de acción. Estas pruebas fallan de forma independiente. Una nota puede existir mientras el índice permanece sucio. El índice puede ser actual mientras una consulta cae por debajo del puntaje configurado. La recuperación puede encontrar el pasaje correcto mientras que una sesión nueva ignora su condición de vencimiento o propietario. Por el contrario, una sesión puede responder correctamente porque el mismo hecho todavía existe en su contexto de conversación, a pesar de que la escritura duradera nunca sucedió. El incumplimiento razonable es, por tanto, un veredicto en etapas. Deténgase en la primera capa fallida y repara sólo esa capa. No vuelva a escribir la memoria cuando el índice esté obsoleto, y no vuelva a construir un índice cuando el registro nunca haya persistido. Prueba la escritura sin exportar la memoria Dar a cada registro sensible a la acción una identificación opaca como decision 7f3b , más los campos necesarios para actuar de manera segura más adelante: propietario, condición efectiva, condición de vencimiento o desbloqueo, y acción prohibida. La identificación no es un secreto y no revela la decisión. En la fuente, calcular si el registro actual coincide con la versión local esperada. Exporta sólo la comparación: No envíe un resumen crudo de una nota corta o sensible a un servicio de salud remoto. El texto de baja entropía se puede adivinar y hash. Mantenga la digestión en el host, use un HMAC con teclado cuando una huella digital estable debe salir del límite del proceso, o informe solo la comparación booleana y un ID de registro opaco. Un sistema de archivos de escritura que devuelva el éxito no es suficiente. Lea el registro de nuevo del archivo duradero, luego compara los bytes que se almacenaron realmente. Si se espera que la escritura sobreviva a un reinicio del host, confirme que la ubicación de almacenamiento es persistente para esa implementación; un espacio de trabajo local del contenedor puede desaparecer a pesar de que la llamada de escritura tuvo éxito. La misma regla se aplica a la truncada de MEMORY.md . OpenClaw mantiene un archivo de gran tamaño intacto mientras que la copia inyectada en el contexto de arranque puede ser truncada. La presencia del archivo aún pasa, pero la prueba de decisión puede fallar porque la entrada requerida no llegó a la nueva sesión. La visión general de la memoria recomienda comprobar los detalles de contexto o la salida del médico cuando se involucran los límites de arranque. Prueba la frescura del índice antes de confiar en la recuperación OpenClaws documentación de búsqueda de memoria explica que el backend incorporado puede combinar la similitud vectorial con la coincidencia de palabras clave BM25. También documenta la sincronización automática al inicio de la sesión, en la búsqueda y a través de un monitor de archivos. Estos mecanismos reducen las ventanas obsoletas; no hacen que la frescura sea inobservable. Comienza con el estado: La sonda deep verifica el proveedor de incorporación y la ruta de búsqueda semántica, para que pueda hacer una llamada al proveedor. Inspeccionar al menos: si la tienda está sucia; los archivos indexados y los recuentos de piezas; proveedor y modelo seleccionados; Disponibilidad del sistema de transporte aéreo; disponibilidad de almacenamiento vectorial y búsqueda semántica; problemas de exploración e identidad de índice. En OpenClaw 2026.7.1 2 , una sonda en vivo de lectura única durante esta investigación informó de una identidad de índice incorporada válida y de las vías léxicas y semánticas disponibles, pero también de dirty: true . Esa combinación es importante: una sonda de incorporación en funcionamiento no prueba que la nota más reciente esté indexada. Cuando la fuente es correcta pero la tienda está sucia, ejecuta una sincronización incremental con: Reserva una reconstrucción forzada para una identidad inválida, una configuración cambiada de fragmentación o incorporación, corrupción o una sincronización incremental que no puede converger: El memoria OpenClaw memoria CLI referencia distingue estas operaciones: status index reindexa cuando está sucio, mientras que index force realiza una reconstrucción completa. Tratar una interrupción del proveedor como search unavailable , no como una memoria vacía. El comportamiento documentado es deliberadamente explícito cuando un proveedor de integración configurado falla; no debe convertirse silenciosamente en prueba de que no existe ningún registro relevante. Cruza el límite de reinicio con una sonda de decisión Busque una clave de recuperación opaca que sea única para el registro de ensayo, luego requiera un resultado anclado: Una prueba de recuperación de paso contiene el tipo de fuente esperado, la referencia de archivo y el rango de líneas. No pase porque el texto del resultado suena correcto. La búsqueda híbrida puede devolver notas semánticamente relacionadas, y las entradas diarias repetidas pueden colocar una versión más antigua por encima de la decisión actual. Ahora cruza un límite de sesión real. Una segunda invitación en la misma conversación no es una prueba de reinicio porque la instrucción original puede estar todavía en contexto. Comience una nueva sesión a través del mecanismo normal de la sesión runtime, solicite una sonda de decisión limitada y compare el comportamiento con el contrato guardado. Por ejemplo, si la nota duradera dice que una migración permanece solo de diseño hasta la aprobación de A 42 , la sonda debe preguntar si la implementación puede comenzar ahora. El resultado esperado es un código de decisión como WAIT FOR A 42 , no una cotización literal de la nota privada. Registro: Esto prueba la continuidad útil en lugar de un teatro de recuerdos. Un modelo puede parafrasear una nota mientras deja caer el límite de autoridad que la hace segura. También puede producir la decisión correcta accidentalmente. Mantenga la sonda estrecha, repitala después de los cambios de configuración pertinentes e incluya un caso negativo cuya condición de desbloqueo no se haya cumplido. Reproduce una auditoría sin contenido en nueve casos La fijación memory health cases.json que acompaña no contiene texto de memoria. Proporciona nueve observaciones sintéticas a evaluate openclaw memory health.mjs , una para cada estado terminal: El resumen reproducido es el siguiente: El clasificador utiliza un orden estricto. Verifica la existencia duradera y la igualdad local antes del estado del índice; el estado del índice antes de la disponibilidad de búsqueda; la disponibilidad de búsqueda antes de la recuperación; y la recuperación antes de una decisión de nueva sesión. Esto evita reparaciones engañosas. La reindexación no puede crear un registro faltante. Reescribir un registro no puede restaurar un proveedor de incorporación fallido. Un golpe de puntaje alto no puede demostrar la continuidad de reinicio. Adaptar la fijación con IDs opacos reales y booleanos locales. Añadir casos para un espacio de trabajo solo para lectura, un índice construido a partir de un diestro más antiguo, un resultado de la nota de fecha incorrecta, un archivo de arranque truncado, un proveedor de incorporación no disponible, una retroceso solo para palabras clave y una decisión cuya aprobación expiró. Mantenga la nota cruda y el resultado de búsqueda cruda fuera de la telemetría compartida. Utilice un estado desconocido explícito La regla de operación compacta es: La memoria de marca OpenClaw solo se verifica cuando el registro duradero coincide localmente, el índice actual lo cubre, la recuperación se ancla a la fuente esperada y una nueva sesión produce la decisión limitada esperada. Todo lo demás debe mantener un estado específico no verde. search unavailable no es retrieval miss . restart unverified no es continuity failed . Un desconocido explícito es más útil que un estado rojo genérico porque identifica la próxima prueba segura sin invitar al agente a inventar el contexto que falta. Esta auditoría todavía tiene límites. Una comparación local sólo puede validar los registros incluidos en el conjunto de ensayos. Un anfitrión comprometido puede falsificar tanto la nota como la evidencia. Una sonda de recuperación mide una consulta y una configuración de clasificación. Un código de decisión coincidente no prueba que todos los matices sobrevivieron, y las repetidas sondas consumen el modelo y el presupuesto de incorporación. Utilice controles deterministas para almacenamiento e indexación, luego gasee llamadas de modelo solo en el comportamiento que no se puede verificar desde archivos y estado de base de datos. Sidewisp se encuentra actualmente en versión preliminar privada. Está destinado a proporcionar una capa de salud alrededor de los tiempos de ejecución de los agentes existentes, pero los adaptadores de producción OpenClaw, la recopilación de agentes en vivo y la recuperación automática no se envían en el repositorio actual del sitio web. La auditoría de cuatro pruebas es un patrón administrado por el operador que puede implementar ahora, no una afirmación de que Sidewisp actualmente monitorea o repara la memoria OpenClaw. Si esta separación entre almacenamiento, recuperación y salud de decisión coincide con la forma en que desea operar agentes, únete a la vista previa privada de Sidewisp. Hasta entonces, mantenga la comparación local, haga real el reinicio, y deje que la evidencia que falta permanezca desconocida.