2026-08-01T05:02:21.583Z
OpenClaw Memoria QMD: Captura caída silenciosa
Pruebe la disponibilidad de QMD, la identidad de backend efectiva, la disponibilidad específica del modo, la frescura del índice y la recuperación canaria antes de confiar en la memoria.
La respuesta segura es: No trate una búsqueda de memoria exitosa de OpenClaw como prueba de que QMD es saludable . Primero demuestra que la puerta de entrada puede resolver el binario de QMD y que QMD no fue el fallback construido que sirvió para la búsqueda. Luego aplica las comprobaciones de preparación requeridas por el modo de búsqueda configurado, confirma que el índice está fresco y recupera un canario sintético. Esa distinción es importante porque OpenClaw cae deliberadamente de nuevo a su motor de memoria incorporada si QMD falla. El fallback conserva el comportamiento útil de la memoria, pero cambia el hecho que se está probando. Un resultado puede ser válido ya que OpenClaw encontró una memoria mientras que es inválido ya que el backend QMD configurado está listo. La regla de funcionamiento de la presente guía es la siguiente: QMD es saludable solo cuando la disponibilidad ejecutable, el backend efectivo, la actualización de la actualización, la preparación específica para el modo y la recuperación de canarios coinciden. Esto es más estrecho que probar que un agente recordaba lo correcto en cada situación. Se trata de un recibo de salud de backend: prueba de que la ruta de recuperación prevista está disponible y lo suficientemente actual para el siguiente paso dependiente de la memoria. Una consulta verde puede ocultar el backend equivocado Documentación QMD de OpenClaw describe a QMD como un sidecar local primero que combina BM25, búsqueda vectorial y relanzamiento. OpenClaw crea colecciones administradas, ejecuta actualizaciones y, cuando los modos semánticos los requieren, mantiene las incorporaciones. También documenta el retroceso automático al motor SQLite construido cuando QMD no puede abrirse. El retroceso es una característica de disponibilidad sensata. No es evidencia de QMD. Considere dos recorridos que recogen la misma oración sintética: Observación Corre A La carrera B Configurar el backend qmd qmd Query devuelve el canario Sí , sí . Sí , sí . Un retroceso efectivo qmd builtin El veredicto de QMD candidato saludable activas para el retroceso El texto devuelto no puede distinguir esas carreras. La identidad de retroceso debe tener mayor prioridad que el éxito de recuperación. Comience en el entorno que en realidad lanza la puerta de entrada. Una cáscara interactiva puede tener un PATH diferente de un servicio: El primer comando debe resolver un ejecutable. El segundo graba una versión. El tercero pide a OpenClaw que sondee el estado de la memoria en lugar de confiar en un fallo de conversión de chat almacenado en caché. Si qmd version solo funciona en su shell de inicio de sesión, la guía oficial de resolución de problemas recomienda fijar un memory.qmd.command absoluto y volver a comprobar desde el entorno de la puerta de entrada. No registre todo el entorno de servicio para demostrar esto. Un recibo útil sólo necesita: La versión anterior es un ejemplo de la investigación actual, no un requisito mínimo. La última versión de QMD GitHub observada para este artículo fue V2.5.3, publicada el 29 de mayo de 2026. OpenClaw mantiene las vías de compatibilidad para las formas de colección QMD y MCP más antiguas, por lo que no más reciente no es automáticamente no saludable. Graba la versión porque cambian los campos de compatibilidad, diagnóstico y salida. En el ejecutor de publicaciones utilizado para este artículo, OpenClaw 2026.7.1 2 fue instalado y su almacén de memoria configurada se informó listo, mientras que qmd version devolvió command not found . Eso no fue una prueba de interrupción de QMD. El corredor no estaba configurado como un despliegue de QMD. Fue una observación útil de los límites: un sano comando de memoria OpenClaw y la disponibilidad de QMD son hechos separados. La preparación depende de searchMode QMD dispone de tres modos de búsqueda pertinentes en el actual contrato OpenClaw: search es BM25 léxico. vsearch utiliza evidencia vectorial. query utiliza el camino híbrido/modelo respaldado y puede incluir una nueva clasificación. El referencia de configuración de memoria indica explícitamente que el search es solo BM25. OpenClaw omite las sondas semánticas de preparación vectorial y el mantenimiento integrado en ese modo. Por lo tanto, una regla general como embedings pendientes significa que la memoria es insalubre es incorrecta. Utilice esta puerta de control de modo: Modo de búsqueda Requiere recogida fresca No se requieren embarcaciones pendientes Requiere el canario search Sí , sí . No es así. Sí , sí . vsearch Sí , sí . Sí , sí . Sí , sí . query Sí , sí . Sí , sí . Sí , sí . Este no es un argumento para la búsqueda léxica sobre la búsqueda semántica. Impide que un controlador de salud imponga una dependencia que el modo seleccionado no utilice. El intervalo de actualización QMD por defecto documentado de OpenClaw es de cinco minutos, mientras que el intervalo de incorporación por defecto es de sesenta minutos. Estos valores describen la programación, no un umbral de salud universal. Construye un contrato de alquiler de frescura a partir de su configuración y tolerancia operativa: Por ejemplo, un intervalo de cinco minutos, una actualización normal de noventa y dos segundos y un margen de treinta y dos segundos da un contrato de arrendamiento de siete minutos. En virtud de esta política, la edad de actualización de 421 segundos está obsoleta; 419 segundos todavía están dentro del contrato de arrendamiento. No extienda silenciosamente el contrato de arrendamiento después de una alerta. Si las actualizaciones lo superan regularmente, fije la carga de trabajo o revise la política con pruebas registradas. De lo contrario, un índice obsoleto se vuelve permanente verde. La primera consulta semántica puede ser inusualmente lenta porque QMD puede descargar aproximadamente 2 GB de modelos GGUF para la expansión de la consulta y la re clasificación. Eso hace que la espera de la dependencia documentada de la primera ejecución sea diferente de la permanencia. Coloque una instalación limitada o una ventana de calentamiento alrededor de la primera sonda, y luego requiera evidencia de progreso o parada. Construir un canario que demuestre el camino gestionado Un canario debe ser sintético, único y seguro de conservar. No debe contener un hecho de cliente, una solicitud, una clave de API, una dirección de correo electrónico o una decisión de tarea real. Crear un archivo Markdown bajo una colección que OpenClaw realmente gestionapara la colección de espacio de trabajo predeterminado, es decir, MEMORY.md o el árbol memory/ . Utilice un símbolo como: Graba su ruta de origen relativa y hash de contenido, permita que el ciclo de actualización configurado se complete, luego busca el token exacto a través de OpenClaw: En el recibo deberá establecerse: 1. el archivo fuente pertenece a la colección gestionada prevista; 2. la última actualización exitosa se realice dentro del contrato de arrendamiento de fresquedad; 3. los vectores semánticos están listos si el modo los necesita; 4. el backend efectivo es QMD; 5. el canario exacto se devuelve de la fuente esperada. Un resultado vacío no demuestra inmediatamente que QMD está roto. El contrato oficial nombra varias explicaciones más estrechas: se ignoran los caminos ocultos, la raíz en minúscula memory.md no es la misma que MEMORY.md , el alcance del grupo/canal se niega por defecto y los patrones de caminos adicionales pueden excluir un archivo. Mantenga esas distinciones para que la reparación se mantenga limitada. Evite invocar qmd update manualmente con directorios XDG arbitrarios. OpenClaw otorga a cada agente un hogar QMD administrado por sí mismo. Un comando directo en el entorno equivocado puede probar un índice diferente y producir un resultado verde convincente pero irrelevante. Del mismo modo, no utilice un canario exitoso para reclamar una amplia calidad de recuerdo. El canario demuestra que un documento conocido cruzó el camino actual de ingestión y recuperación. Los resultados de la evaluación de los resultados de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de los resultados de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación de la evaluación Repite el veredicto antes de enviar una alerta El artefacto creado para este artículo acepta un recibo normalizado JSON y devuelve un estado. Su precedencia es intencional: 1. config drift 2. qmd unavailable 3. fallback active 4. stale index 5. vector not ready 6. retrieval failed 7. healthy Aquí está la decisión central: La repetición de seis casos produjo seis veredictos esperados: El caso Evidencias importantes El veredicto BM25 con 27 incorporados pendientes el modo es search , canario encontrado healthy Queda el binario QMD comando no resuelto qmd unavailable Canario encontrado a través de la construcción el backend efectivo es construido fallback active Edad de cobro 721 años, alquiler 420 años actualización obsoleta stale index Modo de consulta con 14 incorporaciones pendientes vectores incompletos vector not ready Modo de vector fresco, sin canario la recuperación está ausente retrieval failed Esta repetición añade dos controles útiles. En primer lugar, el fallback de construcción no puede pedir un resultado verde de la capa de recuperación. En segundo lugar, la búsqueda BM25 no hereda una falsa dependencia del mantenimiento de vectores. Cada estado no saludable recibe una acción siguiente: QMD no disponible: resuelva el binario desde el entorno de la puerta de entrada y vuelve a sondear. Fallback activo: inspeccionar la falla abierta de QMD; no deshabilitar la fallback solo para hacer rojo el comprobador. Stale índice: esperar o ejecutar la ruta de actualización gestionada, luego verificar un nuevo tiempo de éxito. Vectores no listos: acabado de incorporación para el modelo activo y comprobar la consistencia de las huellas dactilares con los diagnósticos QMD actuales. Retrieval falló: inspeccionar el alcance de la recopilación, el patrón de archivo, la evidencia de actualización y el token exacto antes de reconstruir cualquier cosa. Reconstruir cada índice no es la reparación predeterminada. Aumenta el costo y destruye la evidencia que podría distinguir un error de ruta de un error de frescura. Expirar el recibo y mantener la conclusión estrecha Un recibo saludable está limitado en el tiempo. Almacenar el tiempo de verificación, el modo configurado, la versión QMD, el backend efectivo, la última actualización exitosa, el recuento de vectores pendientes cuando corresponda, el hash de fuente canaria y el veredicto. Expirará cuando finalice el contrato de arrendamiento de frescosidad o cualquiera de esos insumos cambie. El recibo demuestra: el ejecutable QMD previsto era accesible; OpenClaw estaba utilizando QMD en el momento del control; el índice gestionado fue lo suficientemente fresco; las dependencias del modo seleccionado estaban listas; un elemento seguro conocido era recuperable. Znot prueba que cada memoria es relevante, que cada decisión sobrevivió a la compactación, que los datos privados se clasifican correctamente o que un agente produjo el producto entregado previsto. Esos necesitan pruebas separadas. La dirección del producto de Sidewisp es hacer que los límites de salud como estos sean visibles a través de los tiempos de funcionamiento de los agentes: identificar lo que está funcionando, exponer las pruebas, distinguir la espera del fracaso y preservar la autoridad humana sobre las reparaciones. Sidewisp se encuentra actualmente en versión preliminar privada. El adaptador y motor de monitoreo OpenClaw de producción no se envían generalmente, por lo que esta guía es un patrón de funcionamiento que puede implementar hoyno es una afirmación de que Sidewisp ya realice estos controles de QMD. Si una tarea dependiente de la memoria es importante, solicite el recibo antes de que comience la tarea y verifique el resultado real de la tarea después. Eso cierra las dos lagunas falsas: memoria funcionó sin QMD, y QMD funcionó sin que se realizara el trabajo.