2026-07-31T11:30:19.137Z

OpenClaw Memoria de restablecimiento: compruebe el alcance antes de borrar el estado

Seleccione el límite de restablecimiento OpenClaw más estrecho, verifique la cobertura de copia de seguridad, preserve la memoria duradera y requiera pruebas de salud después de restablecer.

OpenClaw memoria de restablecimiento no es una operación. Un chat /new o /reset , una reconstrucción de índice de memoria, y el destructivo openclaw reset CLI actúan en diferentes capas. Si el problema es una conversación obsoleta, un restablecimiento completo de CLI es el defecto predeterminado: el alcance documentado de full elimina el directorio de estado, la base de datos compartida de SQLite y los directorios de espacio de trabajo, incluidos los archivos Markdown que contienen memoria duradera. El defecto seguro es: 1. identificar la primera capa fallida; 2. elegir la acción más estrecha que pueda repararla; 3. inspeccionar el plan de destrucción con una carrera seca; 4. Crear y verificar una copia de seguridad que cubra cada capa que pretenda preservar; 5. obtener una aprobación explícita; 6. verificar la configuración, los archivos de memoria, la disponibilidad de búsqueda y el resultado previsto después de la recuperación. Una carrera seca es evidencia del plan. No es una copia de seguridad, y completar el comando no es prueba de que la memoria deseada sobrevivió. Decide qué "reset" realmente quieres decir Documentación de memoria de OpenClaws dice que la memoria duradera vive en simples archivos Markdown en el espacio de trabajo del agente. USER.md contiene directrices de perfil estable, MEMORY.md contiene hechos y decisiones duraderas seleccionadas y los archivos memory/YYYY MM DD.md contienen notas de trabajo. Las herramientas de búsqueda indican esas fuentes, pero el índice no es la fuente de la verdad. Eso crea al menos cuatro síntomas diferentes que las personas comprimen en la memoria de restablecimiento: Síndrome Primera capa a inspeccionar Primero acto razonable La conversación actual se ha desviado Contexto de la sesión Guardar decisiones duraderas, luego comenzar una nueva sesión La búsqueda pierde un hecho conocido Markdown Indicador de memoria o proveedor Compruebe el estado de la memoria y reconstruye el índice MEMORY.md o notas diarias están equivocadas Espacio de trabajo Markdown Corregir o restaurar el archivo afectado, luego reindexar Configuración local, credenciales, sesiones o estado son irreparablemente inconsistentes Estado de instalación Planifique el alcance de restablecimiento de CLI documentado más estrecho Estas acciones no son intercambiables. El inicio de una nueva sesión no debe borrar el Markdown duradero. La reconstrucción de un índice derivado no debe requerir la eliminación del espacio de trabajo. La edición de una entrada de memoria mala no debe eliminar las credenciales. El destructivo CLI pertenece al final del diagnóstico, no al comienzo. El openclaw reset de referencia oficial define actualmente tres ámbitos: El ámbito de aplicación Límites de eliminación documentados La puerta se detuvo primero. config Sólo archivo de configuración No config+creds+sessions Config, directorio OAuth/credenciales y directorios de sesiones por agente Sí full Directorio de Estado, base de datos compartida SQLite y directorios del espacio de trabajo Sí El alcance correcto sigue la capa diagnosticada. Un síntoma de sesión no justifica la full . Una configuración malformada no justifica la eliminación de credenciales y sesiones. Si el operador no puede nombrar la capa rota, el estado es uncertain y el trabajo destructivo debe esperar. Antes incluso de considerar el CLI, recoger pruebas libres de contenido: Este recibo no almacena instrucciones, contenido de memoria, secretos o caminos privados absolutos. Graba el límite de la decisión. Lea la corriente seca, no sólo su código de salida El CLI expone el dry run . Utilice con el alcance exacto en consideración: Este comando no es destructivo, pero la salida todavía necesita interpretación. Registra la parada prevista en la puerta de entrada, cada objetivo de eliminación resuelto, cualquier rechazo y el paso de embarque esperado posteriormente. Un código de salida cero por sí solo es demasiado débil. Corrí la carrera en seco equivalente a todo alcance contra OpenClaw 2026.7.1 2 el 2026 07 30. Recomendó crear una copia de seguridad, planeó detener la puerta de entrada, luego informó que los caminos de estado y espacio de trabajo no eran seguros para eliminar en esa instalación. Esa observación es específica del host; no significa que todos los resets completos fallen. Se demuestra un punto más útil: el éxito de en la gestión seca y la resolución objetivo son hechos separados . Utilice un pequeño registro del plan: La clasificación correcta es reset plan blocked , no ready to reset . No trabaje en torno a una negativa de seguridad eliminando manualmente directorios amplios. Diagnosticar por qué se rechazó el objetivo o elegir una acción más estrecha. La misma regla se aplica cuando la carrera seca revela más de lo esperado. Si un operador quiere limpiar el estado de sesión pero el plan incluye el espacio de trabajo, deténgase. Un plan destructivo que alcanza una capa no aprobada es sobreestimado incluso si es técnicamente ejecutable. Verifique el artefacto de recuperación antes de borrar el estado La documentación de restablecimiento dice que ejecutar openclaw backup create primero. La regla de funcionamiento más fuerte es crear y verificar el archivo: Elija un destino privado con suficiente espacio, permisos adecuados, cifrado y controles de retención. Los archivos de OpenClaw pueden contener configuración, perfiles de autores, credenciales de canal o proveedor, sesiones, estado de plugin, bases de datos y espacios de trabajo. Trata con la misma sensibilidad que el estado vivo. El openclaw backup de referencia oficial documenta varios límites importantes: el archivo contiene un manifiesto con fuentes resueltas y un diseño; los archivos existentes no se supercriben; se rechazan las vías de salida dentro de los árboles de origen respaldados; controles de verificación de las cargas útiles declaradas y de la seguridad del camino de archivo; las bases de datos canónicas SQLite reciben controles de forma, integridad y función; se pueden omitir las transcripciones volátiles, el registro, el socket, PID y los archivos temporales; los esquemas de propiedad del plugin pueden permanecer opacos cuando sus capacidades definidas por el propietario no estén disponibles. Esa última limitación es importante. Un archivo verificado es mucho más fuerte de lo que existe un archivo, pero no es una prueba universal de que todos los complementos puedan ser restaurados en cada host objetivo. Cobertura de vista previa antes de escribir el archivo: En la misma instalación observada, el JSON enumeró el directorio estatal como el activo de archivo y marcó el espacio de trabajo anidado como covered en lugar de listarlo como un segundo activo. El conteo de activos habría dado la conclusión equivocada. Inspeccione sourcePath , archivePath , coveredBy , y omita las razones en su lugar. Para un restablecimiento que pueda eliminar espacios de trabajo, antes de la aprobación se requerirá: el comando de copia de seguridad completado; la verificación de archivos aprobada; el manifiesto cubre el estado previsto y el espacio de trabajo; los archivos volátiles omitidos son aceptables para el objetivo de recuperación; el archivo está fuera del límite de supresión; el operador podrá identificar el procedimiento de restauración; el destino de reserva está protegido. Porte el reset con nueve casos inconvenientes La fijación sin contenido que acompaña prueba la decisión en lugar de realizar cualquier restablecimiento. Su clasificador aplica esta prioridad: 1. rechazar un ámbito de aplicación desconocido; 2. rechazar un alcance más amplio que la capa diagnosticada; 3. Requieren una carrera en seco completada; 4. exigir que se resuelvan todos los objetivos previstos; 5. requerir una copia de seguridad verificada; 6. Requerir cobertura del espacio de trabajo para un restablecimiento completo; 7. esperar la aprobación explícita; 8. después de la ejecución, comprobar la configuración y la memoria; 9. verificar el resultado previsto de la tarea. Los resultados de los nueve encuentros fueron: Los nueve coincidieron con su estado esperado, y una afirmación separada demostró que un alcance destructivo desconocido no se cierra. La distinción entre los últimos tres estados evita el falso éxito. ready to reset significa el plan, respaldo, alcance y puertas de autoridad aprobadas. No significa que el restablecimiento ya haya ocurrido. memory unverified significa ejecución completada pero falta una o más comprobaciones posteriores al restablecimiento. Sólo verified reset también requiere el resultado previsto. Un recibo práctico después del restablecimiento puede permanecer libre de contenido: La presencia de archivos por sí sola es insuficiente. Compruebe los archivos duraderos esperados, luego prueba la preparación del índice y recupera un canario deliberadamente no sensible. Por último, ejecuta una tarea limitada cuyo resultado se puede comprobar en su destino. Una respuesta fluida no prueba que la memoria restaurada influyó correctamente en el trabajo previsto. Sabes lo que esta puerta no puede probar La fijación valida los campos y la prioridad. No ejecuta OpenClaw, inspecciona el contenido de la memoria privada, restaura un archivo en un segundo host o descubre efectos externos no documentados. Un simulacro de recuperación real debe restaurar periódicamente en un destino aislado y probar el tiempo de ejecución exacto y los plugins que importan. Tampoco convierte todas las quejas de memoria en un incidente. Una nueva sesión puede legítimamente carecer de contexto de conversación no salvado. Un resultado de búsqueda puede estar vacío porque el hecho nunca fue escrito. Un índice puede ser reconstructivo. Estos son diferentes de la eliminación de memoria duradera, y la incertidumbre debe permanecer visible hasta que se conozca la primera capa fallida. La regla de funcionamiento es simple: conservar la memoria fuente antes de reparar el estado derivado, preferir el límite más pequeño apoyado y exigir evidencia después de la acción. Nunca actualice el comando devuelto al agente recuperado. Sidewisp se encuentra actualmente en versión preliminar privada. Su adaptador de producción OpenClaw y ejecutor de recuperación generalmente no se envían. El método aquí es un patrón de funcionamiento inspectable, no una afirmación de que Sidewisp actualmente respalda, restablece o restaura las instalaciones OpenClaw en vivo. La dirección del producto de Sidewisp mantiene el diagnóstico, la autoridad humana y los resultados verificados separados por lo que una acción destructiva no puede resolver un problema simplemente porque se ejecutó.