N8n AI Memória do Agente: Prove que a sessão sobreviveu

n8n AI Memória do agente é confiável somente quando quatro coisas concordam: o fluxo de trabalho usa um backend de memória compatível com o seu modo de implantação, o mesmo usuário atinge a mesma chave de sessão, o histórico esperado pode ser lido de volta da loja, e uma execução posterior usa esse histórico corretamente. Uma resposta de acompanhamento fluente não prova nenhuma dessas condições por si só. O padrão prático é testar a memória como um contrato de roteamento e persistência. Em um experimento de processo único, a Memória simples pode ser adequada. No modo de fila, use um serviço de memória compartilhada como Postgres ou Redis, dê a cada conversa uma chave de sessão estável e opaca e verifique o isolamento com duas sessões. Então cruza um limite real de execução. Não chame a memória saudável porque duas mensagens em uma execução parecem coerentes. Comece com o limite de implantação O n8n visão geral da memória oficial separa os nós AI Agente, que podem usar memória, das cadeias AI, que não podem. Ele lista Memória simples e serviços de memória externa, incluindo Redis e Postgres, como diferentes opções de implementação. É um mapa de capacidade, não um veredicto de saúde. A primeira questão operacional é onde a história vive. O n8n adverte explicitamente no seu Documentação de memória simples que não deve utilizar esse nó para um fluxo de trabalho de produção ativo em modo de fila. As chamadas podem ser recebidas por diferentes trabalhadores, por isso não se pode assumir que o histórico local dos trabalhadores acompanhe a conversa. Classificar esse caso antes de analisar as indicações ou os modelos: queue mode unsafe : o fluxo de trabalho é executado em modo de fila e utiliza Memória simples; store unavailable : um backend compartilhado é configurado, mas o fluxo de trabalho não pode alcançá lo; write unverified : o backend aceitou uma conexão, mas a expectativa de conversão não foi observada no histórico duradouro. A transição para Postgres ou Redis resolve a localidade do trabalhador; não resolve a identidade. Uma loja compartilhada pode manter fielmente a conversa errada sob a chave errada. Disponibilidade, durabilidade e roteamento são propriedades separadas. Para cada versão do fluxo de trabalho, mantenha um pequeno recibo de configuração: O recibo deve descrever a regra, não expor o ID do usuário, o ID do bate papo, as credenciais, a cadeia de conexão ou o texto da mensagem. Se uma chave estável for derivada de identificadores privados, calcular um HMAC no host e exportar apenas o resultado opaco ou uma verificação de igualdade local. Verifique a identidade da sessão antes de testar o recall Tanto a memória simples quanto o Memória de chat pós grado usam uma chave de sessão. O nó Postgres também permite que você escolha a tabela e o comprimento da janela de contexto. Sua documentação observa que múltiplos nós de memória de chat Postgres usam a mesma instância de memória por padrão; instâncias de memória separadas exigem IDs de sessão diferentes. Isso faz da sessão uma parte fundamental do limite de correcção. Deve ser: 1. Estabilidade para a mesma conversação externa; 2. Diferentes para conversas que não devem partilhar história; 3. independentemente de uma identificação de execução transitória; 4. gerado antes que o subnodo de memória resolva os seus parâmetros; 5. Segura para registar como identificador opaco. Há uma armadilha específica aqui. A documentação do nó de memória diz que as expressões em sub nodos resolvem se contra o primeiro item de entrada, em vez de uma vez para cada item. Se três itens recebidos representam três conversas e a expressão de chave de sessão é avaliada dentro do subnodo de memória, todos os três podem ser encaminhados usando o valor do primeiro item. Não diagnose isso como memória de modelo pobre. Registrar o número de identidades de sessão esperadas no limite do nó raiz e o número observado pelo adaptador de memória. Se três foram esperadas e uma foi observada, devolver session key collapse . Dividir os itens ou calcular e validar uma chave de sessão por execução antes do limite do subnodo. Execute uma sonda de isolamento com duas sessões sintéticas, não texto real do cliente: A sessão A armazena um marcador opaco cuja decisão esperada é ROUTE ALPHA . A sessão B armazena um marcador diferente cuja decisão esperada é ROUTE BETA . Uma nova execução para A deve devolver apenas o ROUTE ALPHA . Uma nova execução para B deve devolver apenas o ROUTE BETA . A troca de qualquer um dos resultados é uma falha de privacidade e correção, mesmo que ambas as respostas pareçam plausíveis. Este teste negativo importa. Um único recall bem sucedido pode passar enquanto cada usuário é mapeado para o mesmo histórico compartilhado. Leia a história e depois uma nova execução. Uma contagem de filas de banco de dados é uma prova fraca. Pode aumentar enquanto a sessão errada recebe a mensagem, enquanto uma versão anterior permanece no topo da janela de contexto, ou enquanto uma operação de memória destrutiva substitui mais histórico do que pretendido. O Documentação do gerenciador de memória do chat oficial expõe as operações de obter, inserir, substituir e excluir. Seu modo de leitura simplificado retorna o remetente e o texto. Use essa capacidade dentro de um fluxo de trabalho de diagnóstico protegido, ou consulta a loja externa localmente, para verificar três fatos: a chave de sessão opaca prevista existe; A última curva de ensaio está presente na ordem correta; A sessão vizinha não o contém. Mantenha as conversas crudas fora do monitoramento telemétrico. O fluxo de trabalho de diagnóstico pode comparar localmente o marcador de ensaio recuperado e emitir: Agora inicie outra execução do fluxo de trabalho através do mesmo caminho de desencadeamento de produção. Reutilizar outro nó na execução atual não é um teste de persistência; a resposta pode ainda estar presente no contexto da carga útil do item ou modelo. A execução posterior deve receber apenas a identidade opaca da sessão e uma pergunta limitada cuja resposta esperada seja um código de decisão. Passe apenas quando a loja ler e o comportamento posterior concordarem. Se o histórico for correto mas a decisão for errada, devolva o continuity failed . Se não houver uma execução genuinamente nova, devolver o continuity unverified . Nenhum dos estados deve ser derrubado em um erro de memória vazia. Repete dez estados de falha em ordem fixa O dispositivo n8n memory health cases.json que acompanha não contém instruções ou mensagens. Fornece dez observações sintéticas a um pequeno classificador: A corrida reproduzida retornou: A ordem é deliberada: 1. confirmar que um nó de memória está ligado; 2. rejeitar Memória simples no modo fila; 3. Detectar o colapso da chave de sessão do primeiro item; 4. Comparar a chave de sessão atual com a chave estável esperada; 5. A disponibilidade das lojas de ensaio; 6. comprovar a escrita; 7. Comparar a leitura de volta com o histórico esperado; 8. exigir uma execução posterior; 9. Comparar a sua decisão com o resultado esperado. A parada na primeira camada falhada dá ao operador uma reparação útil. Reescrever um prompt não pode corrigir a localização do modo de fila. Reconstruir uma mesa não pode corrigir a deriva da chave de sessão. Mudar um modelo não pode corrigir dois usuários mapeados para a mesma chave. Adapte o ajuste com a revisão do fluxo de trabalho, tipo de backend, bandeira do modo de fila, contagens de sessões distintas esperadas e observadas, booleans de leitura local e resultado de execução nova. Preservar os estados de unknown quando as provas estiverem ausentes. Uma resposta de modelo verde não substitui uma sonda de armazenamento faltante. Mantenha a memória de conversação separada dos resultados do fluxo de trabalho Passar esta auditoria prova uma alegação limitada: o histórico de conversação testado foi encaminhado, armazenado, recuperado e usado além do limite de execução testado. Não prova que todo o fluxo de trabalho tenha concluído o seu trabalho. Um agente pode lembrar que uma fatura deve ser enviada e ainda não a enviar. Pode chamar o cliente correto e escrever para o destino errado. Pode preservar uma instrução obsoleta cuja condição de expiração nunca foi modelada. Manter um recibo de resultado separado para o limite de entrega, efeito externo ou aprovação que o fluxo de trabalho deve satisfazer. A auditoria tem também limites práticos. Ele mostra sessões escolhidas e janelas de contexto. Uma base de dados pode falhar depois da sonda. Um anfitrião comprometido pode falsificar a história e as suas evidências. Um código de decisão correto não prova que todas as nuances de uma longa conversa sobreviveram. A leitura de mensagens armazenadas pode expor conteúdo sensível, por isso as verificações de produção devem comparar marcadores opacos localmente e exportar booleanos, contagens, frescura e revisões de fluxo de trabalho. A regra de funcionamento é concisa: Mark n8n AI Memória do agente verificada somente quando a compatibilidade de implantação, isolamento de sessão, leitura de volta duradoura e comportamento de execução nova todos passam para a mesma revisão de fluxo de trabalho. A Sidewisp está atualmente em prévia privada. Pretende se adicionar uma camada de saúde em torno dos tempos de execução dos agentes existentes, mas a coleta de agentes de produção saúde, os adaptadores n8n e a recuperação automatizada não são enviados no repositório atual do site. Este é um padrão de verificação administrado pelo operador, não uma alegação de que o Sidewisp atualmente monitora o n8n. Se esta distinção entre uma conversa lembrada e um resultado verificado coincidir com a forma como você deseja operar agentes, junte se à pré visualização privada Sidewisp. Até lá, mantenha as identidades das sessões opacas, teste um caso de isolamento negativo e deixe que a evidência faltante permaneça não verde.