Agente no n8n recebeu 200 OK, mas a cliente viu um chat vazio: análise do bug do silêncio

Nós verdes, 200 OK da Meta e um chat vazio para a cliente. É assim o segundo «bug do silêncio» em um agente de IA no n8n, tema de uma análise recente publicada no Habr. É a segunda história do tipo do mesmo autor, e a formulação deixa claro o essencial: o sistema achou que tinha cumprido o trabalho, mas a pessoa ficou sem resposta. O anúncio é curto, então abaixo está apenas o que ele afirma, além dos mecanismos gerais que causam esse tipo de problema em agentes para mensageiros.

O que se sabe da análise

Há poucos fatos no anúncio, mas eles são reveladores. O workflow no n8n rodou sem erros: todos os nós ficaram verdes. A requisição à API da Meta retornou 200 OK. Mesmo assim, a usuária não viu a resposta do agente, e o chat estava vazio. O anúncio não especifica qual canal foi usado nem em que ponto da cadeia o texto sumiu. Os detalhes ficam na versão completa do artigo no Habr.

Para agentes de IA, esse é o tipo de falha mais incômodo. Não há exceção, nenhum alerta dispara e os logs estão limpos. A única forma de descobrir o problema é pelo próprio cliente, se ele ainda não tiver ido embora.

Onde o silêncio costuma se esconder

Esse sintoma tem algumas causas típicas. Não se sabe qual delas ocorreu neste caso, mas todas produzem o mesmo quadro: «tudo verde, sem resposta».

• O código 200 significa recebimento, não entrega. As APIs de mensageiros costumam aceitar a mensagem em uma fila e informar o destino da entrega depois, por webhooks de status separados.
• Saída vazia ou corrompida do modelo. Um LLM pode devolver uma string vazia, um JSON truncado ou um marcador de serviço no lugar do texto. Para o n8n, são dados válidos, e o nó de envio roda normalmente.
• Restrições da plataforma. Os mensageiros têm janelas de resposta, exigências de templates e regras de moderação. A mensagem pode ser aceita e, ainda assim, não ser exibida ao usuário.
• Campo errado na expressão. Se o nó de envio busca o texto em um caminho que não existe nos dados, o n8n insere um valor vazio sem acusar erro.
• Condições de corrida e duplicidades. Webhooks repetidos, execuções paralelas e memória de conversa compartilhada podem sobrescrever a resposta antes de ela sair.

Todos os itens têm algo em comum: o sucesso é medido do lado da infraestrutura, e não do lado da pessoa.

Como pegar esses bugs

A primeira medida é adicionar uma verificação de conteúdo antes do envio. Um nó de filtro simples, que barre string vazia, texto curto demais ou texto com marcadores de serviço, elimina uma classe inteira de erros. Se a verificação falhar, o workflow deve seguir para o ramo de erro, em vez de continuar em verde.

Segunda: não tratar o 200 OK como ponto final. Os status de entrega recebidos por webhook precisam ser salvos e cruzados com as mensagens enviadas por identificador. Qualquer mensagem sem confirmação de «entregue» dentro de um prazo definido vira um incidente.

Terceira: criar uma métrica no nível da conversa. A proporção de mensagens recebidas para as quais nenhuma resposta não vazia saiu em N segundos mostra o estado real do agente melhor do que a estatística de execuções bem-sucedidas. Ela também serve de base para um alerta no chat de trabalho da equipe.

Quarta: configurar um Error Workflow no n8n e um fallback separado. Se o agente ficar mudo, o cliente recebe um curto «Recebemos sua mensagem e responderemos em breve», e o operador recebe uma notificação com o contexto da conversa.

Quinta: rodar conversas sintéticas. Uma conta de teste regular, que escreve para o agente e espera a resposta, detecta o silêncio antes das pessoas reais. Para um negócio em que o chat com o bot é o principal canal de vendas ou de suporte, essa verificação custa menos do que uma solicitação perdida.

A história do Habr ilustra bem uma lição geral sobre a operação de agentes: a confiabilidade é definida pelo que o usuário viu, e não pelo que o painel do orquestrador mostrou.