N8n AI Mémoire de l'agent: prouver que la séance a survécu

n8n AI La mémoire de l'agent n'est fiable que lorsque quatre choses sont d'accord: le flux de travail utilise un backend de mémoire compatible avec son mode de déploiement, le même utilisateur atteint la même clé de session, l'historique attendu peut être lu depuis le magasin, et une exécution ultérieure utilise cette histoire correctement. Une réponse fluide ne prouve pas toutes ces conditions. Le défaut pratique est de tester la mémoire comme un contrat de routage et de persistance. Dans une expérience à un seul processus, la mémoire simple peut être suffisante. En mode file d'attente, utilisez un service de mémoire partagée tel que Postgres ou Redis, donnez à chaque conversation une clé de session opaque stable et vérifiez l'isolement avec deux sessions. Alors franchissez une véritable limite d'exécution. Ne dites pas que la mémoire est saine parce que deux messages dans une seule exécution semblent cohérents. Commencez par la limite de déploiement Le n8n vue d'ensemble de la mémoire officiel sépare les nœuds AI Agent, qui peuvent utiliser la mémoire, des chaînes AI, qui ne peuvent pas. Il énumère la mémoire simple et les services de mémoire externe, y compris Redis et Postgres, comme différents choix de mise en œuvre. C'est une carte de capacité, pas un verdict de santé. La première question opérationnelle est où vit l'histoire. n8n prévient explicitement dans son Documentation de mémoire simple de ne pas utiliser ce nœud pour un flux de travail de production actif en mode file d'attente. Les appels peuvent toucher différents travailleurs, de sorte que l'historique local des travailleurs ne peut pas être supposé suivre la conversation. Classifier ce cas avant d'examiner les indications ou les modèles: queue mode unsafe : le flux de travail se déroule en mode file d'attente et utilise la mémoire simple; store unavailable : un backend partagé est configuré mais le flux de travail ne peut pas y accéder; write unverified : le backend a accepté une connexion, mais le tournant de conversation attendu n'a pas été observé dans l'historique durable. Le passage à Postgres ou à Redis résout la localisation du travailleur; il ne résout pas l'identité. Un magasin partagé peut fidèlement préserver la mauvaise conversation sous la mauvaise clé. La disponibilité, la durabilité et le routage sont des propriétés distinctes. Pour chaque version du flux de travail, conservez un petit reçu de configuration: Le reçu doit décrire la règle et ne pas exposer l'identifiant d'utilisateur, l'identifiant de chat, les informations d'identification, la chaîne de connexion ou le texte du message. Si une clé stable doit être dérivée d'identifiants privés, calculer un HMAC sur l'hôte et exporter uniquement le résultat opaque ou une vérification d'égalité locale. Prouver l'identité de la session avant de tester le rappel La mémoire simple et le La mémoire de chat postgrés utilisent une clé de session. Le nœud Postgres vous permet également de choisir la table et la longueur de la fenêtre contextuelle. Sa documentation note que plusieurs nœuds de mémoire de chat Postgres utilisent la même instance de mémoire par défaut; les instances de mémoire séparées nécessitent des identifiants de session différents. Cela fait de la session une partie essentielle de la limite de correction. Il doit être: 1. stable pour la même conversation extérieure; 2. différent pour les conversations qui ne doivent pas partager l'histoire; 3. indépendamment d'un identifiant d'exécution transitoire; 4. généré avant que le sous node de mémoire ne résout ses paramètres; 5. sûre à enregistrer en tant qu'identifiant opaque. Il y a un piège spécifique à n8n ici. La documentation du nœud de mémoire indique que les expressions dans les sous nœuds résolvent contre le premier élément d'entrée, plutôt qu'une fois pour chaque élément. Si trois éléments entrants représentent trois conversations et que l'expression de clé de session est évaluée à l'intérieur du sous node de mémoire, les trois éléments peuvent être routés à l'aide de la valeur du premier élément. Ne le diagnostiquez pas comme un mauvais modèle de mémoire. Enregistrer le nombre d'identités de session attendues à la limite du nœud racine et le nombre observé par l'adaptateur de mémoire. Si trois étaient attendus et qu'un a été observé, retournez session key collapse . Divisez les éléments ou calculez et validez une clé de session par exécution avant la limite du sous node. Exécutez une sonde d'isolement avec deux séances synthétiques, pas un vrai texte client: La session A stocke un marqueur opaque dont la décision attendue est ROUTE ALPHA . La session B stocke un marqueur différent dont la décision attendue est ROUTE BETA . Une nouvelle exécution pour A ne doit renvoyer que ROUTE ALPHA . Une nouvelle exécution pour B ne doit renvoyer que ROUTE BETA . Le fait d'échanger les deux résultats est une erreur de confidentialité et d'exactitude, même si les deux réponses semblent plausibles. Ce test négatif compte. Un seul rappel réussi peut passer pendant que chaque utilisateur est mappé à la même histoire partagée. Lisez l'histoire, puis faites une nouvelle exécution. Un nombre de lignes de base de données est une preuve faible. Il peut augmenter pendant que la mauvaise session reçoit le message, pendant qu'une version précédente reste en haut de la fenêtre de contexte, ou pendant qu'une opération de mémoire destructrice remplace plus d'historique que prévu. Le Documentation du gestionnaire de mémoire de chat officiel expose les opérations de récupération, d'insertion, d'annulation et de suppression. Son mode de lecture simplifié renvoie l'expéditeur et le texte. Utilisez cette fonctionnalité dans un flux de travail de diagnostic protégé, ou consultez le magasin externe localement, pour vérifier trois faits: la clé de session opaque attendue existe; le dernier tour d'essai est présent dans l'ordre correcte; la séance voisine ne le contient pas. Gardez les conversations brutes hors de la surveillance de la télémétrie. Le flux de travail de diagnostic peut comparer le marqueur de test récupéré localement et émettre: Commencez maintenant une autre exécution du flux de travail à travers le même chemin de déclenchement de production. La réutilisation d'un autre nœud dans l'exécution actuelle n'est pas un test de persistance; la réponse peut toujours être présente dans le contexte de la charge utile ou du modèle de l'élément. L'exécution ultérieure ne devrait recevoir que l'identité opaque de la session et une question limitée dont la réponse attendue est un code de décision. Passez seulement quand le magasin vous répondra et que le comportement ultérieur s'accordera. Si l'historique est correct mais que la décision est erronée, retournez continuity failed . Si aucune nouvelle exécution n'a été observée, retournez continuity unverified . Aucun des deux états ne doit être transformé en erreur de mémoire vide. Répétez dix états de défaillance dans un ordre fixe L'appareil n8n memory health cases.json qui l'accompagne ne contient pas d'invitations ou de messages. Il fournit dix observations synthétiques à un petit classificateur: La course reproduite est retournée: L'ordre est délibéré: 1. confirmer qu'un nœud de mémoire est attaché; 2. rejeter la mémoire simple en mode file d'attente; 3. détecter l'effondrement de la clé de session du premier élément; 4. comparer la clé de session actuelle avec la clé stable attendue; 5. la facilité d'accès aux magasins d'essai; 6. prouver l'écriture; 7. comparer la lecture récurrente avec l'historique attendu; 8. exiger une exécution ultérieure; 9. comparer sa décision avec le résultat attendu. S'arrêter à la première couche défaillante donne à l'opérateur une réparation utile. La réécriture d'une requête ne peut pas corriger la localisation du mode de file d'attente. La reconstruction d'une table ne peut pas réparer la dérive des clés de session. Le changement d'un modèle ne peut pas corriger deux utilisateurs mappés à la même clé. Adaptez le fichier avec la révision de votre flux de travail, le type de backend, le drapeau de mode de file d'attente, le nombre de sessions distincts attendues et observées, les booleans de lecture locale et le résultat d'exécution fraîche. Préserver les états unknown lorsque les preuves sont absentes. Une réponse au modèle vert ne remplace pas une sonde manquante. Garder la mémoire de conversation séparée des résultats du flux de travail La réussite de cette vérification prouve une affirmation limitée: l'historique de conversation testé a été routé, stocké, récupéré et utilisé à travers la limite d'exécution testée. Cela ne prouve pas que l'ensemble du flux de travail a terminé son travail. Un agent peut se rappeler qu'une facture doit être envoyée et ne pas l'envoyer. Il peut rappeler le bon client et écrire à la mauvaise destination. Il peut conserver une instruction obsolète dont la condition d'expiration n'a jamais été modélisée. Gardez un reçu de résultat séparé pour le délivrable, l'effet externe ou la limite d'approbation que le flux de travail doit satisfaire. L'audit a également des limites pratiques. Il prélève les séances choisies et les fenêtres contextuelles. Une base de données peut échouer après la sonde. Un hôte compromis peut falsifier l'histoire et ses preuves. Un code de décision correct ne prouve pas que toutes les nuances d'une longue conversation ont survécu. La lecture des messages stockés peut exposer des contenus sensibles, de sorte que les contrôles de production devraient comparer des marqueurs opaques localement et exporter des booléens, des comptes, de la fraîcheur et des révisions de flux de travail. La règle de fonctionnement est concise: La mémoire de l'agent de marque n8n AI est vérifiée uniquement lorsque la compatibilité du déploiement, l'isolement des sessions, la lecture durable et le comportement d'exécution fraîche sont tous validés pour la même révision du flux de travail. Sidewisp est actuellement en préversion privée. Il est destiné à ajouter une couche de santé autour des temps d'exécution existants des agents, mais la collecte des agents de production santé, les adaptateurs n8n et la récupération automatisée ne sont pas expédiés dans le référentiel du site Web actuel. Il s'agit d'un modèle de vérification géré par l'opérateur et non d'une affirmation selon laquelle Sidewisp surveille actuellement n8n. Si cette distinction entre une conversation mémorable et un résultat vérifié correspond à la façon dont vous souhaitez utiliser les agents, rejoignez l'aperçu privé Sidewisp. En attendant, gardez les identifiants de session opaques, testez un cas d'isolement négatif et laissez les preuves manquantes rester non vertes.