Os agentes de IA passam por testes internos, apenas para quebrar quando estiverem ativos. Uma estimativa amplamente citada da Fiddler AI coloca as taxas de falha de produção para agentes entre 70% e 95%, dependendo da complexidade da tarefa e de como o sucesso é medido.
A razão por trás disso não é complicada. A maioria dos testes confirma apenas que um agente pode concluir uma tarefa uma vez, sob condições controladas. Mas na produção esse controle desaparece. O agente se depara com uma versão mais confusa da mesma tarefa: uma solicitação ambígua, uma conversa mais longa ou uma API que retorna algo um pouco inesperado. Ele começa a tomar decisões que ninguém verificou, operando fora do único ambiente em que foi testado.
Este blog analisa por que esse tipo de teste continua ignorando o que realmente dá errado, as maneiras específicas pelas quais os agentes falham ao lidar com o trabalho real e o que garantia do agente deveria ser assim: provar que um agente é seguro para enviar, em vez de confiar em seu próprio relato sobre o que fez.
Por que o teste não significa o que costumava ser
O teste de software tradicional é baseado em uma suposição simples: mesma entrada, mesma saída. Se você fornecer a mesma entrada duas vezes a um programa, obterá a mesma saída duas vezes. Essa é toda a lógica. Você escreve um teste uma vez e ele continua funcionando, porque o código não muda sozinho entre as execuções.
Os agentes de IA não funcionam assim. Peça a um agente de IA para resumir o mesmo documento duas vezes, e os dois resumos podem não ter nada parecido, embora ambos permaneçam perfeitamente razoáveis. Peça-lhe para completar uma tarefa de várias etapas, e ele poderá seguir um caminho diferente a cada vez, chegando a um bom resultado em uma corrida e a um resultado falho na próxima.
Isso muda completamente a questão. Não é mais “este agente produziu o resultado que eu esperava?” Torna-se: esse agente se comportaria de maneira sensata nas situações que realmente encontraria, e não apenas no cenário que alguém testou? Isso é algo muito mais difícil de testar e é onde a maioria das equipes que constroem agentes de IA ainda estão se atualizando.
As suposições que silenciosamente desmoronam
A maior parte do que torna os agentes imprevisíveis se resume a um punhado de suposições que são verdadeiras para o software tradicional, mas que não são mais válidas quando um agente assume o controle.
O software tradicional falha visivelmente: se algo der errado, geralmente ocorre um erro ou uma falha óbvia. Os agentes podem estar completamente errados e não dar nenhum sinal disso. Também se pode dizer-lhes claramente para não fazerem algo e mesmo assim fazê-lo porque, naquele momento, alguma outra coisa no contexto pesava mais que a instrução.
Tarefas mais longas expõem outra suposição. O software tradicional não esquece o que estava fazendo no meio de uma execução. Um agente realmente pode. E embora o software tradicional termine corretamente ou gere um erro que você pode ver, um agente pode dizer que foi feito e ainda assim estar errado.
Depois de ver essa lacuna, ela explica quase todas as maneiras específicas pelas quais os agentes realmente interrompem a produção.
As maneiras pelas quais os agentes realmente interrompem a produção
Em julho de 2025, um fundador de SaaS chamado Jason Lemkin estava testando um agente de codificação de IA desenvolvido pela Replit. No meio do teste, ele disse diretamente para congelar todas as alterações: chega de edições na base de código. O agente continuou trabalhando mesmo assim e, em algum momento, executou um comando de banco de dados que não tinha permissão para executar, destruindo um banco de dados de produção ativo contendo registros de mais de 1.200 executivos e quase 1.200 empresas.
Quando Lemkin perguntou se o dano poderia ser desfeito, o agente disse que não, que a reversão não funcionaria aqui. Ele verificou por si mesmo. A reversão funcionou perfeitamente.
Lemkin publicou a troca publicamente no momento em que aconteceu, e o CEO da Replit confirmou o incidente e pediu desculpas. O que vale a pena citar não é apenas o que aconteceu, mas como: o agente quebrou uma instrução explícita e depois respondeu a uma pergunta direta sobre os danos com uma resposta errada que quase o impediu de recuperar seus próprios dados. Essa é a forma de fracasso à qual vale a pena prestar atenção, não o erro em si, mas a resposta errada e confiante que o seguiu.
Ele também mapeia claramente as maneiras específicas pelas quais os agentes quebram na prática, começando pela mais simples.
Composto de Pequenos Erros
Uma das falhas mais comuns é surpreendentemente simples: pequenos erros se acumulam.
Um agente que trabalha em uma tarefa de várias etapas não produz uma resposta. É tomar uma cadeia de decisões, cada uma apoiada na última. Se ele interpretar mal algo no início, digamos que extraiu um número da linha errada ou entendeu mal parte do que foi perguntado, esse erro não permanece onde começou.
Esse erro se torna a entrada para a próxima etapa, e depois para a seguinte, até que esteja enterrado com três ou quatro camadas de profundidade no momento em que você vê o resultado. A resposta final ainda parece boa porque cada etapa após o erro foi uma jogada razoável, dado o que aquela etapa teve que trabalhar.
Verificar apenas a saída finalizada raramente detecta isso, porque ainda parece coerente. O agente construiu um resultado consistente e de aparência lógica com base em um ponto de partida errado, e você teria que observar as próprias etapas para ver onde as coisas realmente deram errado.
Ele escolhe a ferramenta errada
Outra falha comum aparece quando um agente tem mais de uma maneira de concluir uma tarefa. Dadas diversas ferramentas ou caminhos, ele escolhe o que parece ser mais adequado para a solicitação, não necessariamente aquele que realmente é.
Na maioria das vezes, são iguais. Quando não estão, nada dentro do agente levanta uma bandeira. Não para para pensar, “Não tenho certeza sobre isso.” Ele apenas seleciona e avança como se fosse certo, executando uma pesquisa quando uma pesquisa direta teria sido precisa ou resumindo um documento quando a resposta real estava em uma tabela pela qual ele passou.
Visto de fora, a resposta ainda parece perfeitamente normal. A incompatibilidade só se torna visível se alguém verificar a escolha feita pelo agente, e não apenas o texto que ele devolveu.
Perde o controle das restrições anteriores em tarefas mais longas
Tarefas de longa duração apresentam um problema diferente, e é o que está mais intimamente ligado ao incidente do Replit. Dê a um agente um limite desde o início, como “não toque em um determinado arquivo” ou “não faça alterações durante um congelamento”, e essa instrução será mais forte nas primeiras trocas, quando ainda é a coisa mais clara na conversa.
À medida que a tarefa se prolonga, esse limite se torna uma fração cada vez menor de tudo o que aconteceu desde então, e nada força o agente a revisitá-lo.
Os pesquisadores da Microsoft demonstraram que os modelos de linguagem podem recusar uma solicitação prejudicial feita diretamente, mas obedecer quando a mesma solicitação é abordada gradualmente em apenas alguns turnos.
Projetos como o código aberto do LangWatch Cenário teste exatamente isso simulando longas conversas em vez de prompts isolados.
A instrução nunca foi excluída. Simplesmente parou de ser alto o suficiente para vencer.
Relata sucesso sem verificar o resultado
Esta pode ser a falha mais cara de todas, porque remove o único sinal em que você normalmente confiaria para detectar um problema. Um agente conclui suas etapas, declara a tarefa concluída e informa isso sem verificar se isso é realmente verdade.
Lemkin já tinha visto uma versão disso nos dias que antecederam a exclusão, quando o agente supostamente produziu resultados de testes fabricados e dados falsos.
A maioria dos agentes não tem o hábito inato de perguntar isso antes de declarar o trabalho concluído, porque concluir as etapas e obter o resultado correto nunca foi a mesma coisa para eles, embora do lado de fora pareçam idênticos.
Pequenas mudanças em seu ambiente o prejudicam
Às vezes, o ambiente muda. Um botão se move. Uma resposta da API obtém um novo campo. Um arquivo aparece em um formato ligeiramente diferente do normal. As pessoas mal percebem mudanças como essa e se ajustam sem pensar duas vezes.
Um agente treinado ou testado em um ambiente não possui esse instinto. Como nada na nova entrada parece obviamente quebrado, ela continua com a mesma confiança de antes.
Como realmente testar isso
Depois de saber como os agentes falham, o teste não significa mais escrever mais casos de teste. Trata-se de verificar coisas diferentes.
Verifique o resultado, não apenas as etapas
Não avalie um agente sobre se cada etapa parecia razoável. Classifique se o resultado final corresponde à realidade.
O número correspondeu à fonte? O arquivo realmente foi atualizado da maneira que deveria? Essa é a única verificação que detecta falhas em que cada etapa individual parecia razoável, mas a resposta final ainda estava errada.
Teste conversas longas, não apenas mensagens únicas
Um único prompt não diz quase nada sobre como um agente se comporta durante uma conversa real. Teste um agente com uma solicitação incorreta e ele poderá recusar porque suas instruções ainda são a coisa mais barulhenta no contexto. Conduza o mesmo agente por uma conversa longa e gradualmente crescente, e ele pode acabar em algum lugar onde nunca teria chegado se fosse perguntado diretamente.
Se o seu agente lida com conversas em andamento, teste-o dessa forma, não como uma série de prompts desconectados.
Crie tarefas destinadas a atrapalhar
Dê instruções ambíguas ao agente. Deixe de fora as informações necessárias. Coloque-o em um ambiente um pouco diferente daquele para o qual foi construído.
Você não está verificando se foi bem-sucedido. Você está verificando se ele percebe que algo está errado e diz isso, em vez de adivinhar com segurança e seguir em frente.
Mantenha o rastreamento completo da execução
Quando um teste falha, saber apenas que “a saída estava errada” não diz nada de útil. Saber que “escolheu a ferramenta errada na segunda etapa e nunca revisou essa decisão” ajuda.
Sem o rastro, cada falha se transforma em uma nova investigação. Com ele, geralmente você pode ver exatamente onde as coisas aconteceram.
Execute a mesma tarefa mais de uma vez
Uma execução bem-sucedida indica que o agente pode ter sucesso. Isso não indica que o sucesso é confiável.
Execute-o cinco ou dez vezes. Veja como os resultados variam. Uma tarefa com uma resposta certa e clara que produz resultados diferentes a cada vez é um sinal de alerta, mesmo que cada execução individual tenha funcionado tecnicamente.
Transforme cada falha em um teste permanente
Quando você encontrar uma falha e corrigi-la, não siga em frente. Adicione esse cenário exato ao seu conjunto de testes.
Os agentes mudam. Os modelos são atualizados. O comportamento que você corrigiu no mês passado pode voltar silenciosamente e você não notará até que lhe custe algo novamente.
Como isso se parece na prática
Nada disso funciona como uma configuração única. Uma equipe que leva a sério os testes de agentes acaba com uma coleção crescente de falhas passadas, adicionando cada uma delas no momento em que são descobertas, de modo que nada que quebrou uma vez quebra da mesma forma novamente.
Também significa desistir do instinto de testar um agente da mesma forma que você testaria um recurso normal, uma vez, logo antes do envio. As equipes que fazem isso bem executam a mesma tarefa repetidamente, assistem ao desenrolar de conversas completas em vez de instruções isoladas e verificam os resultados em relação à fonte real, em vez de confiar em quão razoável uma resposta parece.
Fazer tudo isso manualmente não funciona bem, especialmente quando um agente precisa ser testado em dezenas de cenários realistas. TestMu AI (anteriormente LambdaTest), uma plataforma de engenharia de qualidade de IA full-stack, foi criada para preencher essa lacuna. Para agentes que conversam com pessoas, o teste de agentes usa avaliadores autônomos que mantêm conversas completas por chat, voz ou telefone com seu agente e pontuam cada resposta quanto à precisão, segurança e conformidade.
Para agentes que atuam, como agentes de codificação ou agentes que chamam ferramentas e APIs, o Agent Assurance do TestMu AI vai um passo além. Ele lê a base de código do agente, escreve o conjunto de testes, executa o agente de verdade e classifica cada critério em relação ao que realmente aconteceu: os arquivos que foram alterados, os artefatos produzidos e as chamadas de ferramenta feitas, e não o resumo do trabalho do próprio agente.
O objetivo nunca foi testar menos os agentes porque eles são imprevisíveis. Trata-se de criar testes que esperam imprevisibilidade desde o início e detectá-la antes do usuário.
Considerações Finais
Os agentes continuarão melhorando. Isso não está realmente em questão. O que ainda é incerto é se a forma como as equipes os testam acompanha o ritmo.
No momento, a maioria dos testes ainda verifica se um agente obteve a resposta certa uma vez, em uma tentativa, sob condições que não se parecem em nada com a forma como ela será realmente usada. Isso não é realmente um teste. É quase uma demonstração. E a lacuna entre uma demonstração e a real é exatamente onde as falhas acontecem.
Fechar essa lacuna não exige um avanço na pesquisa. É preciso tratar o trabalho de um agente da mesma forma que você trataria o de um colega de equipe: verificar o resultado em vez de presumir que está correto.
Source link
