Sistema operativo de memoria del agente AI: audite cada transición de nivel

Un sistema operativo de memoria para un agente de IA está en buen estado solo cuando el operador puede seguir una versión de la memoria a través del almacenamiento, la actualización, la recuperación y la generación bajo el mismo alcance de usuario y asistente. Una respuesta coherente es un resultado útil, pero no es prueba de que todas las transiciones anteriores se hayan cometido. Por lo tanto, la opción práctica por defecto es simple: adjuntar un recibo de linaje sin contenido a cada límite. Mantenga el contenido de la memoria en el host. Registre solo los identificadores estables, el alcance, la versión de origen, el nivel de destino, las marcas de tiempo, el estado de transición y la versión utilizada para la generación. Si falta un límite o es contradictorio, informe waiting , at risk , stale o uncertain en lugar de verde. Esa regla es importante para la arquitectura específica detrás de la consulta de búsqueda memoria del sistema operativo de ai agent . El documento MemoryOS define tres niveles de almacenamiento y cuatro módulos funcionales. Su implementación también expone una estrecha ventana de falla que un punto de referencia de calidad de respuesta no puede identificar. Lo que establece MemoryOS El Papel MemoryOS describe cuatro módulos: 1. Almacenamiento organiza la memoria a corto plazo (STM), la memoria a medio plazo (MTM) y la memoria personal a largo plazo (LPM). 2. Actualización mueve las páginas de diálogo de STM a MTM y luego deriva un perfil de mayor duración o material de conocimiento de MTM. 3. Recuperación selecciona material relevante de los niveles. 4. Generación crea una respuesta a partir del contexto actual y recuperado. El documento es inusualmente concreto sobre el movimiento entre niveles. La actualización de STM a MTM utiliza un proceso FIFO de cadena de diálogo. La actualización de MTM a LPM utiliza páginas segmentadas con selección basada en calor. Esa es una estructura suficiente para definir límites de transición observables en lugar de tratar la “memoria” como una base de datos opaca. Los autores informan mejoras promedio del 49,11% en F1 y del 46,18% en BLEU 1 con respecto a sus líneas de base en LoCoMo con GPT 4o mini. Esos son los resultados de referencia de los autores; No volví a ejecutar LoCoMo para esta auditoría. Más importante aún, la corrección y la coherencia de la respuesta responden a una cuestión diferente a la de la integridad operativa. Una puntuación alta no prueba que: un registro STM estaba presente de forma duradera antes del desalojo; un destino MTM comprometido antes de que desapareciera la fuente; el mismo usuario y asistente sobrevivió a cada transición; la recuperación devolvió la versión más reciente esperada; La generación final en realidad dependió de esa versión. La arquitectura del periódico marca los límites. El operador todavía necesita recibos por ellos. El intervalo de riesgo aparece antes de la confirmación del destino. Inspeccioné el proyecto en la confirmación fijada 587ed7755c7aed179965792830ff1b5ad9a6fa92 . La fijación es importante: el repositorio está activo y una conclusión operativa sin una versión fuente se volverá ambigua después del próximo cambio. La ruta actual add memory comprueba si la cola de corto plazo está llena y ejecuta la promoción antes de agregar otro elemento. La fuente etiqueta explícitamente esto como una solución para evitar el desalojo automático de deque silencioso ( memoryos.py , líneas 226–244). Se trata de una salvaguarda útil, pero no convierte la promoción en algo transaccional. La secuencia de promoción importa: 1. process short term to mid term llama a pop oldest mientras STM está lleno ( updater.py , líneas 100–105). 2. pop oldest elimina el registro e inmediatamente guarda el deque STM más corto ( short term.py , líneas 33–37). 3. Luego, el actualizador llama a las funciones de resumen y continuidad respaldadas por LLM. 4. La inserción de MTM y su guardado final se producen más tarde ( updater.py , líneas 130–207). Este flujo de control crea un intervalo de fuente en riesgo. Si el proceso sale o una operación posterior no detectada falla después de guardar STM pero antes de la confirmación de MTM, el operador no tiene prueba de promoción completa. Esta es una ventana de falla derivada del origen, no una afirmación de que cada implementación de MemoryOS pierda datos. El estado de salud correcto simplemente no es verde hasta que exista el recibo de destino o se demuestre que la fuente sigue siendo recuperable. Hay un segundo límite de continuidad, más estrecho. last evicted page for continuity comienza como un valor None en memoria, se transfiere al siguiente lote y se actualiza después del procesamiento ( updater.py , líneas 35 y 115–158). Un reinicio del proceso restablece esa pista de transferencia en particular. Otra lógica de similitud de MTM aún puede reconectar material, por lo que esto no es prueba de una pérdida total de continuidad. Es una razón para registrar la página anterior o la versión fuente en el recibo de transición en lugar de asumir que el proceso la recordó. Utilice un recibo sin contenido en todos los niveles El recibo no necesita indicaciones, respuestas, resúmenes, incrustaciones ni datos personales. Un evento mínimo puede verse así: Lleva seis campos a través de cada etapa: runId se suma a un intento de almacenamiento a generación sin revelar contenido. userScope y assistantScope detectan errores entre inquilinos o asistentes compartidos. version identifica el estado de memoria esperado. sourceVersion fija el contrato de implementación o adaptador. status separa started , waiting , committed , verified y el trabajo fallido. atUtc permite que el verificador caduque las pruebas obsoletas. MemoryOS ya crea archivos a corto, mediano y largo plazo específicos del usuario y un archivo a largo plazo específico del asistente independiente ( memoryos.py , líneas 71–78). El recibo debe conservar ambas dimensiones porque "usuario correcto, asistente compartido incorrecto" sigue siendo un conflicto de alcance. Para la generación, agregue dependsOnVersion y un outcomeReceipt . dependsOnVersion dice qué versión de memoria recuperada ingresó al mensaje final. outcomeReceipt debe identificar una verificación de resultados determinista siempre que sea posible: un hash de archivo, un identificador de fila, un resultado de prueba, una búsqueda de destino u otra prueba de que existe el trabajo previsto. No debe ser una mezcla de contenido de conversación sensible simplemente para que el registro parezca riguroso. Repita estados inconvenientes antes de confiar en el verde Construí y ejecuté un dispositivo de ocho cajas sin contenido. El clasificador devolvió los ocho estados esperados: Caso Evidencia Estado Linaje completo Acuerdo de alcance, versión, actualización, confirmaciones de niveles, recuperación y recibo de generación healthy Umbral de capacidad no alcanzado STM es duradero y la ventana de espera declarada está abierta waiting STM eliminado, MTM no comprometido La fuente desapareció antes de la prueba del destino source at risk STM retenido, sin evento de promoción La esperada transición MTM nunca apareció promotion missing Cambios de usuario durante la promoción Un evento pertenece a un ámbito diferente scope conflict La recuperación devuelve v21 , se esperaba v22 Un recuerdo real existe, pero está rancio stale retrieval Respuesta fluida, sin recibo de dependencia Generación completada sin linaje verificado generation unverified Sin versión de implementación La evidencia no se puede interpretar con seguridad uncertain La distinción importante es entre esperar y faltar . Un registro STM que sigue siendo duradero mientras no se haya alcanzado un umbral de capacidad documentado no está estancado. Una fuente eliminada sin confirmación de destino no está esperando; está en riesgo. Los campos de marca de tiempo y presencia de fuente hacen que esa diferencia sea inspeccionable. Utilice una precedencia explícita para que un éxito posterior no pueda ocultar un conflicto anterior: Este orden es deliberadamente conservador. El conflicto de alcance supera a una respuesta exitosa. El riesgo de origen supera a la actividad posterior. Una recuperación obsoleta no se redime con una generación fluida. La evidencia faltante sigue siendo incierta en lugar de convertirse en saludable. Convierta el recibo en una puerta operativa Comience con un recuerdo canario que no contenga contenido personal o de producción. Déle un identificador aleatorio y una versión esperada, luego ejerza la ruta real de almacenamiento, promoción, recuperación y generación. Antes de la adopción o después de una actualización del sistema de memoria: 1. Fije la implementación. Registre la versión del paquete o la confirmación del repositorio y la configuración que cambia los límites de capacidad, calor, similitud o recuperación. 2. Demuestre el aislamiento del alcance. Ejecute dos alcances de usuario y, si corresponde, dos alcances de asistente. Cruce cada consulta deliberadamente y no requiera recuperación en el carril equivocado. 3. Forzar transiciones de capacidad. Llene STM hasta el límite configurado. Verifique que cada eliminación de fuente tenga una confirmación MTM coincidente. 4. Ejerce el respaldo. El actualizador tiene un respaldo de resumen general cuando la salida de resumen múltiple no está disponible. Etiquete esa ruta como degradada y verifique la recuperación por separado en lugar de tratar la finalización del respaldo como una calidad normal. 5. Reinicio entre lotes. Verifique la continuidad después del reinicio del proceso porque el traspaso en memoria no es una prueba duradera. 6. Caducar recibos. Una promoción que estuvo en buen estado ayer no establece que el proceso, índice o archivos actuales estén en buen estado ahora. 7. Verifique el resultado. La recuperación exitosa indica que se devolvió un recuerdo. No dice que el agente utilizó la versión correcta o completó la tarea prevista. No vuelva a intentar automáticamente una promoción de fuente en riesgo si es posible que la actualización ya se haya confirmado parcialmente. Primero concilie el origen y el destino mediante runId y la versión. La repetición a ciegas puede convertir la incertidumbre en páginas duplicadas o en hechos contradictorios a largo plazo. La limitación es igualmente importante: este recibo demuestra el linaje de la transición, el alcance, la frescura y las comprobaciones deterministas de los resultados. No prueba que un resumen escrito por un LLM sea semánticamente correcto. Eso requiere una evaluación separada, una revisión humana de hechos personales de alto impacto o una comparación determinista de una tarea específica. El límite de salud de Sidewisp Esta auditoría se ajusta al modelo de salud contextual y de memoria de Sidewisp: las lecturas o escrituras faltantes, la persistencia fallida, la sincronización obsoleta, los reinicios inesperados y las decisiones perdidas deben ser visibles en lugar de inferirse a partir de un proceso ecológico. Sidewisp se encuentra actualmente en versión preliminar privada. Su sitio público y su sistema de artículos están activos, mientras que la recopilación de estado del agente de producción, los adaptadores de tiempo de ejecución y la ejecución de recuperación generalmente no se envían. El recibo anterior es un patrón de operador que puede implementar ahora; No es una afirmación de que Sidewisp monitoree actualmente MemoryOS. La regla resuelta es estricta pero utilizable: confíe en el sistema de memoria solo cuando la misma versión con alcance se almacene, promueva, recupere, use y verifique de manera duradera. Una respuesta fluida puede resultar alentadora. No puede sustituir el recibo faltante.