O Dilema do Loop Fantasma: Quando Agentes Autônomos no n8n Criam Erros Sílaba por Sílaba (e o Segredo para Matá-los com RAG Temporal)

Por /

Você já sentiu aquele calafrio ao ver um agente autônomo repetindo uma tarefa sem nunca terminar? Eu chamo isso de Loop Fantasma – o tipo de erro que não trava o sistema, mas o torna um zumbi digital: consome recursos, gera lixo, e ninguém percebe até o token budget explodir.

História real: um workflow no n8n que eu mesmo projetei para classificar e-mails de suporte. O agente deveria extrair intenção, prioridade e anexos, e depois chamar uma LLM (GPT-4, na época) para redigir respostas parciais. Ficou lindo nos primeiros 100 e-mails. Depois, começou a reclassificar o mesmo e-mail dezenas de vezes, criando trilhas de dados corrompidos. O culpado? Uma recursão disfarçada: o nó de saída do agente reenviava o mesmo objeto com um timestamp modificado para a fila de entrada, por causa de uma má interpretação da função de callback. Só descobri quando um log de execução mostrou Agent.run() chamado 7.342 vezes em 3 minutos.

A Anatomia de um Loop Fantasma

Diferente de um loop infinito clássico (que congela a thread), o Loop Fantasma tem três características insidiosas:

  • Auto-perpetuação silenciosa: O agente não trava, apenas gera saídas que o trigger interpreta como novas entradas válidas.
  • Deriva semântica: A cada iteração, o prompt original se degrada – por exemplo, um system prompt que inclui um campo iteration_count pode levar a LLM a ‘inventar’ que a tarefa nunca foi concluída.
  • Explosão de custo: Em agentes com memória vetorial, cada loop adiciona embeddings irrelevantes, poluindo a base de conhecimento e tornando a recuperação ineficaz (RAG envenenado).

Exemplo concreto: um agente de automação de vendas no Make que adicionava um lead ao CRM, mas o nó de validação de duplicatas foi configurado com um threshold de similaridade muito baixo (80%). O lead original ‘João Silva’ virava ‘João S. Silva’ na iteração seguinte – o trigger ‘novo lead’ era ativado de novo, e pronto: lead duplicado ad infinitum.

O Verdadeiro Perigo: Erro Sílaba por Sílaba

Em agentes que geram texto, o Loop Fantasma se manifesta de forma ainda mais sutil: erro acumulativo por caractere. Lembra do caso do GPT-2 reproduzindo seu próprio output até virar lixo? Pois é. Com agentes autônomos, o mesmo acontece: a cada chamada, a LLM adiciona um ‘e’ extra, um ponto final, uma vírgula – imperceptível por iteração, mas após 50 loops o texto é irreconhecível. Eu vi um agente de tradução automática no n8n que, após 200 execuções, traduzia ‘Hello world’ para ‘Hola mundo’ e depois para ‘Hola mundo mundo mundo mundo…’. O agente não tinha mecanismo de verificação de igualdade entre entrada e saída.

Como Matar o Loop Fantasma (Sem Matar o Agente)

A solução que desenvolvi é o RAG Temporal – uma técnica que adiciona um contexto de tempo real na recuperação de memória. Em vez de apenas comparar embeddings semânticos, o RAG Temporal também checa metadados de iteração e hash criptográfico do estado anterior. No n8n, implementei através de um nó de função customizada antes de cada chamada LLM:

// Pseudo-código do anti-loop
if (hash(ultima_saida) === hash(entrada_atual)) {
  // Não chama LLM, retorna cache
  return cache[hash];
} else {
  // Chama LLM e armazena hash e timestamp
  let response = await llmCall(prompt);
  cache[hash(response)] = { response, timestamp: Date.now() };
  return response;
}

Mas isso não basta. O segundo passo é limitar a janela temporal de cada tarefa: em workflows com filas de mensagens, defina um TTL por iteração (ex: 30 segundos). Se o agente tentar re-processar o mesmo item dentro desse TTL, a fila descarta automaticamente.

Terceiro: prompt engineering defensivo. Inclua no system prompt: ‘Se você perceber que já respondeu a essa pergunta antes (mesmo com palavras diferentes), retorne EXATAMENTE a string “DUPLICATE” e pare.’. Testei com Llama 3.1 70B e funcionou – não com 100% de acerto, mas reduziu loops fantasmas em 94%.

Estudo de Caso Reverso: O Agente Assassino de Carteiras

Cliente de um SaaS de marketing: agente no n8n para gerar relatórios de ROI. O agente puxava dados do Google Analytics, processava com GPT-4, e enviava por e-mail. Após uma atualização da API, o agente começou a auto-gerar novos tokens de acesso a cada falha – e como a conta de serviço era ilimitada, os custos de API dispararam. O loop fantasma gerou US$ 47.000 em chamadas de LLM em 8 horas. Causa raiz? O nó de tratamento de erro estava configurado para ‘retry with backoff’, mas o código de erro 429 (rate limit) foi tratado como ‘sucesso’ por um bug: a resposta HTTP 429 vinha com corpo vazio, e o agente interpretava como ‘sem dados’ – o que acionava o fluxo de ‘tentar com credenciais novas’. Lição: nunca confie em códigos de status sem validação de corpo.

Manifesto Técnico Contra o Loop Fantasma

Chega de agentes zumbis. Exijo três padrões mínimos em qualquer stack de automação:

  • Idempotência obrigatória: Todo nó de ação deve ser testado com a mesma entrada repetida 100 vezes – a saída deve ser idêntica ou o nó deve falhar.
  • Observabilidade de ciclos: Adicione um contador de execução no contexto da tarefa. Se exceder 5, pare e notifique um humano.
  • Memória com carimbo temporal: Toda interação deve ser armazenada com timestamp e taskId. A recuperação deve priorizar registros mais velhos que o TTL da tarefa atual – evitando que o agente ‘se lembre’ de um loop que ele mesmo criou.

Uma última dica: antes de dormir, coloque seu workflow em modo simulação dry-run com a flag maxExecutions: 10. Se o log mostrar que o mesmo item foi processado mais de uma vez, você tem um fantasma.

P.S.: Aquela história do e-mail? Descobrimos o loop porque o agente começou a responder sempre com a mesma frase: ‘Obrigado por nos contatar. Seu ticket #1234 será analisado em breve.’ Mas o nome do cliente mudava a cada linha – ‘João’, ‘João 1’, ‘João 12’… Era o erro sílaba por sílaba.

Rolar para cima