N8n AI Memoria del agente: demuestra que la sesión sobrevivió

n8n AI La memoria del agente es confiable solo cuando cuatro cosas coinciden: el flujo de trabajo utiliza un backend de memoria compatible con su modo de implementación, el mismo usuario llega a la misma tecla de sesión, el historial esperado se puede leer de nuevo desde la tienda, y una ejecución posterior utiliza ese historial correctamente. Una respuesta de seguimiento fluida no prueba ninguna de esas condiciones por sí sola. El defecto práctico es probar la memoria como un contrato de enrutamiento y persistencia. En un experimento de un solo proceso, la memoria simple puede ser adecuada. En el modo de cola, utilice un servicio de memoria compartida como Postgres o Redis, dé a cada conversación una clave de sesión opaca estable y verifique el aislamiento con dos sesiones. Entonces cruza un límite de ejecución real. No llames a la memoria sana porque dos mensajes en una ejecución parecen coherentes. Comience con el límite de despliegue El n8n vista general de la memoria oficial separa los nodos del agente AI, que pueden usar memoria, de las cadenas AI, que no pueden. En él se enumeran la memoria simple y los servicios de memoria externa, incluidos Redis y Postgres, como diferentes opciones de implementación. Ese es un mapa de capacidad, no un veredicto de salud. La primera pregunta operativa es dónde vive la historia. n8n advierte explícitamente en su Documentación de memoria simple no utilizar ese nodo para un flujo de trabajo de producción activo en modo cola. Las llamadas pueden llegar a diferentes trabajadores, por lo que no se puede suponer que la historia local del trabajador siga la conversación. Clasificar ese caso antes de examinar las instrucciones o modelos: queue mode unsafe : el flujo de trabajo se ejecuta en modo cola y utiliza Memoria simple; store unavailable : se configura un backend compartido pero el flujo de trabajo no puede alcanzarlo; write unverified : el backend aceptó una conexión, pero el giro de conversación esperado no se observó en la historia duradera. Cambiar a Postgres o Redis resuelve la localidad del trabajador; no resuelve la identidad. Una tienda compartida puede guardar fielmente la conversación equivocada bajo la llave equivocada. Disponibilidad, durabilidad y enrutamiento son propiedades separadas. Para cada versión del flujo de trabajo, mantenga un pequeño recibo de configuración: El recibo debe describir la regla, no exponer el ID del usuario, el ID del chat, las credenciales, la cadena de conexión o el texto del mensaje. Si una clave estable debe derivarse de identificadores privados, calcular un HMAC en el host y exportar solo el resultado opaco o una verificación de igualdad local. Prueba la identidad de la sesión antes de probar el recuerdo Tanto Simple Memory como Memoria de chat después de graduarse utilizan una clave de sesión. El nodo Postgres también le permite elegir la tabla y la longitud de la ventana de contexto. Su documentación señala que varios nodos de memoria de chat Postgres usan la misma instancia de memoria por defecto; instancias de memoria separadas requieren ID de sesión diferentes. Eso hace que la sesión sea parte clave del límite de corrección. Debe ser: 1. estable para la misma conversación externa; 2. diferentes para conversaciones que no deben compartir historia; 3. independientes de una identificación de ejecución transitorio; 4. generados antes de que el subnodo de memoria resuelva sus parámetros; 5. seguro para registrarse como identificador opaco. Hay una trampa específica de N8N aquí. La documentación del nodo de memoria dice que las expresiones en subnodos se resuelven contra el primer elemento de entrada, en lugar de una vez por cada elemento. Si tres elementos entrantes representan tres conversaciones y la expresión de llave de sesión se evalúa dentro del subnodo de memoria, se pueden enrutar los tres utilizando el valor del primer elemento. No lo diagnostices como un modelo de memoria pobre. Registrar el número de identidades de sesión esperadas en el límite del nodo raíz y el número observado por el adaptador de memoria. Si se esperaban tres y se observó uno, devuelva session key collapse . Dividir los elementos o calcular y validar una clave de sesión por ejecución antes del límite del subnodo. Ejecutar una sonda de aislamiento con dos sesiones sintéticas, no texto real del cliente: En la sesión A se almacena un marcador opaco cuya decisión esperada es ROUTE ALPHA . La sesión B almacena un marcador diferente cuya decisión esperada es ROUTE BETA . Una nueva ejecución para A debe devolver sólo ROUTE ALPHA . Una nueva ejecución para B debe devolver sólo ROUTE BETA . Cambiar cualquiera de los resultados es un fallo de privacidad y corrección, incluso si ambas respuestas parecen plausibles. Esta prueba negativa es importante. Un solo retiro exitoso puede pasar mientras cada usuario se asigna al mismo historial compartido. Lea la historia y luego cruza una nueva ejecución. Un recuento de filas de base de datos es evidencia débil. Puede aumentar mientras la sesión incorrecta recibe el mensaje, mientras una versión anterior permanece en la parte superior de la ventana de contexto, o mientras una operación de memoria destructiva reemplaza más historia de la prevista. El Documentación del administrador de memoria de chat oficial expone las operaciones de obtener, insertar, anotar y eliminar. Su modo de lectura simplificado devuelve el remitente y el texto. Utilice esa capacidad dentro de un flujo de trabajo de diagnóstico protegido, o consulta la tienda externa localmente, para verificar tres hechos: existe la clave de sesión opaca esperada; el último giro de ensayo está presente en el orden correcto; la sesión vecina no lo contiene. Mantenga las conversaciones crudas fuera del control de la telemetría. El flujo de trabajo de diagnóstico puede comparar el marcador de prueba recuperado localmente y emitir: Ahora comience otra ejecución del flujo de trabajo a través del mismo camino de activación de producción. Reutilizar otro nodo en la ejecución actual no es una prueba de persistencia; la respuesta puede estar presente en la carga útil del elemento o en el contexto del modelo. La ejecución posterior debe recibir únicamente la identidad opaca de la sesión y una pregunta limitada cuya respuesta esperada sea un código de decisión. Pasen sólo cuando la tienda repite y el comportamiento posterior coincida. Si el historial es correcto pero la decisión es incorrecta, devuelva continuity failed . Si no se ha observado ninguna nueva ejecución real, devuelva continuity unverified . Ninguno de los dos estados debe colapsar en un error de memoria vacía. Reproduce diez estados de falla en un orden fijo La fijación n8n memory health cases.json que acompaña no contiene instrucciones ni texto de mensaje. Proporciona diez observaciones sintéticas a un pequeño clasificador: La carrera reproducida regresó: La orden es deliberada: 1. confirmar que está conectado un nodo de memoria; 2. rechazar la memoria simple en modo cola; 3. detectar el colapso de la clave de sesión del primer elemento; 4. comparar la clave de sesión actual con la clave estable esperada; 5. la accesibilidad de las tiendas de ensayo; 6. comprobar la escritura; 7. comparar la lectura de la información con el historial esperado; 8. exigir una ejecución posterior; 9. comparar su decisión con el resultado esperado. Detenerse en la primera capa fallida le da al operador una reparación útil. Reescribir una solicitud no puede arreglar la ubicación del modo de cola. La reconstrucción de una mesa no puede arreglar la deriva de la clave de sesión. Cambiar un modelo no puede fijar a dos usuarios asignados a la misma clave. Adapte la fijación con su revisión de flujo de trabajo, tipo de backend, bandera de modo de cola, recuentos de sesiones distintas esperadas y observadas, booleanos locales de lectura y resultado de ejecución reciente. Preservar los estados de unknown cuando las pruebas no estén presentes. Una respuesta de modelo verde no es un sustituto de una sonda de almacén faltante. Mantenga la memoria de conversación separada de los resultados del flujo de trabajo Pasar esta auditoría demuestra una afirmación limitada: el historial de conversación probado fue enrutado, almacenado, recuperado y utilizado a través del límite de ejecución probado. No demuestra que todo el flujo de trabajo haya completado su trabajo. Un agente puede recordar que una factura debe ser enviada y aún así no la envíe. Puede recordar al cliente correcto y escribir al destino equivocado. Puede conservar una instrucción obsoleta cuya condición de vencimiento nunca fue modelada. Mantenga un recibo de resultado por separado para el límite de entregable, efecto externo o aprobación que el flujo de trabajo debe satisfacer. La auditoría también tiene límites prácticos. Se muestran las sesiones elegidas y ventanas de contexto. Una base de datos puede fallar después de la sonda. Un anfitrión comprometido puede falsificar tanto la historia como sus pruebas. Un código de decisión correcto no prueba que todos los matices de una larga conversación sobrevivieron. La lectura de los mensajes almacenados puede exponer contenido sensible, por lo que los controles de producción deben comparar marcadores opacos localmente y exportar booleanos, recuentos, frescura y revisiones de flujo de trabajo. La regla de funcionamiento es concisa: Marca n8n AI Memoria de agente verificada sólo cuando la compatibilidad de implementación, aislamiento de sesión, lectura de retroalimentación duradera y comportamiento de ejecución nueva todos pasan por la misma revisión del flujo de trabajo. Sidewisp se encuentra actualmente en versión preliminar privada. Está destinado a agregar una capa de salud alrededor de los tiempos de ejecución de los agentes existentes, pero la recopilación de agentes de producción salud, los adaptadores n8n y la recuperación automática no se envían en el repositorio actual del sitio web. Se trata de un patrón de verificación administrado por el operador, no de una afirmación de que Sidewisp actualmente monitoree n8n. Si esta distinción entre una conversación recordada y un resultado verificado coincide con la forma en que desea operar a los agentes, únete a la vista previa privada de Sidewisp. Hasta entonces, mantenga las identidades de la sesión opacas, prueba un caso de aislamiento negativo, y deje que la evidencia que falta permanezca no verde.