Agentes Que Erram Com Confiança: O Padrão Que Pesquisadores Encontraram Em Falhas Silenciosas

Semana passada eu estava revisando o output de um agente numa tarefa de refatoração razoavelmente simples — trocar uma dependência de serialização por outra em um serviço pequeno. O agente rodou, editou os arquivos certos, escreveu um resumo confiante do que tinha feito e declarou a tarefa concluída. Só que não tinha. Faltava um ponto de conversão que quebrava silenciosamente em produção sob uma condição específica, e o agente nunca chegou perto de testar esse caminho. O que me incomodou não foi o erro — erro acontece — foi o tom. Não havia hesitação nenhuma no resumo. Nenhum "não tenho certeza se cobri todos os casos". Era a linguagem de quem tinha terminado.

Essa cena ficou na cabeça porque, na mesma semana, cruzei com um conjunto de pesquisas recentes tratando exatamente desse fenômeno — agentes que erram, mas erram com a mesma confiança de quando acertam, sem nenhum sinal externo de que algo deu errado. Não testei nada disso pessoalmente nem reproduzi os experimentos; o que segue é uma leitura do que esses estudos descrevem, não um relato de bancada. Mas o achado central de um deles me pareceu contraintuitivo o suficiente para valer a pena destrinchar aqui.

A intuição mais comum sobre erro de agente é que ele é aleatório — o modelo tropeça em lugares diferentes, de jeitos diferentes, cada falha com a sua própria cara. Se fosse assim, detectar falha silenciosa seria basicamente impossível sem rodar a suíte de testes inteira, porque não haveria padrão a procurar. O que a pesquisa mais recente sugere é o oposto: quando um agente falha silenciosamente, ele não erra de qualquer jeito — ele converge, repetidamente, para o mesmo tipo de conserto errado. E essa convergência, por mais estranha que pareça à primeira vista, é o tipo de sinal que dá para detectar sem rodar teste nenhum.

Este post cobre o que muda quando se entende falha silenciosa como um padrão estruturado em vez de ruído aleatório: o que exatamente esse achado central diz, por que ele faz sentido do ponto de vista de como um agente processa um problema, quais técnicas de detecção sem teste ele já viabilizou e com que taxa de acerto, o tamanho do problema de falso sucesso em benchmarks mais amplos de agentes, e o que isso sugere na prática para quem precisa decidir se aceita ou rejeita o output de um agente antes de rodar qualquer coisa.

---

O Que É Falha Silenciosa E Por Que Ela É Diferente De Um Erro Óbvio

Um erro óbvio se anuncia. O agente tenta compilar e a build quebra. O teste roda e falha. O comando retorna um stack trace. Nesses casos, o problema é chato de resolver, mas não é difícil de perceber — existe um sinal externo, direto, que aponta exatamente para onde a coisa deu errado. Falha silenciosa é outra categoria de problema: o agente entrega uma solução, declara a tarefa como concluída, tudo aparenta estar em ordem, e a lacuna só aparece depois — em produção, numa revisão de código mais cuidadosa, ou nunca, se ninguém checar.

A diferença não é cosmética. Um erro óbvio custa o tempo de investigar e corrigir. Uma falha silenciosa custa a confiança de quem aceitou o resultado sem desconfiar, porque não havia motivo aparente para desconfiar. É o mesmo problema, em essência, que já tratei quando escrevi sobre os quatro problemas que quebram agentes reais em produção: a diferença entre demo e produção não é a inteligência do modelo, é o quanto o sistema em volta dele aguenta e sinaliza quando algo sai do esperado. Falha silenciosa é o caso extremo dessa lacuna — o próprio agente afirma que está tudo bem.

Um ponto que vale separar logo de cara: falha silenciosa não é o agente mentindo no sentido de saber a verdade e escondê-la. É mais estrutural do que isso. O agente não tem, embutido no seu processo, um mecanismo confiável de verificar se o que ele entende como "resolvido" bate com o estado real do sistema que estava tentando mudar. Ele produz uma resposta que parece completa segundo os próprios critérios internos — sintaxe correta, arquivos editados, resumo coerente — e declara sucesso porque, do ponto de vista dele, os sinais de sucesso estão todos presentes. O problema é que sinal interno não é a mesma coisa que verificação externa contra a realidade.

Isso também ajuda a explicar por que revisão de código tradicional, sozinha, não resolve o problema. Um revisor humano lendo um patch de agente julga se o código parece razoável, sem necessariamente rodar o cenário exato que expõe a lacuna — e um patch de falha silenciosa, por definição, foi desenhado sem intenção para parecer razoável. É a mesma tensão que aparece na discussão sobre agentes editando a própria suíte de testes em vez da implementação: quando o agente controla os dois lados — a solução e o critério que valida a solução — a aparência de sucesso fica descolada do sucesso de fato.

---

O Achado Central: Patches Errados Convergem, Não São Aleatórios

Aqui entra o ponto mais interessante da pesquisa "Confident and Wrong: Silent Semantic Failures in Coding Agents". O estudo analisou casos em que agentes de código submetiam uma solução sem de fato resolver a tarefa — falha silenciosa, no sentido que descrevi acima — e comparou os patches produzidos nessas falhas entre si. O resultado: quando o agente falha silenciosamente, os patches que ele produz para a mesma tarefa se parecem muito mais entre si do que patches de tarefas diferentes e não relacionadas. Em outras palavras, o agente não está errando de um jeito diferente a cada tentativa. Ele está convergindo, de forma consistente, para o mesmo conserto errado.

Isso contraria a intuição de que erro de modelo generativo tende a ser disperso, já que o processo de geração envolve amostragem, e amostragem sugere variação. Mas o padrão observado é o oposto: convergência, não dispersão. A explicação é razoavelmente intuitiva quando se olha de perto o mecanismo. O problema não está na geração de texto em si, está numa etapa anterior — a leitura que o agente faz do problema logo no início da execução. Quando essa leitura inicial já está errada, tudo que vem depois — investigação, hipótese de causa, conserto proposto — herda esse erro de base e o refina em vez de corrigi-lo. O agente não explora alternativas depois que trava numa leitura errada; ele otimiza dentro dela, como se fosse verdadeira.

Essa observação vem acompanhada de outro detalhe relevante: modelos que "travam" numa interpretação equivocada do problema logo no começo tendem a produzir execuções curtas — poucos passos, pouca investigação adicional, conclusão rápida — e ao mesmo tempo confiantes. Se o agente já "decidiu" mentalmente o que o problema é, ele não sente necessidade de investigar mais, porque, do ponto de vista dele, não há mais nada a investigar. A confiança na resposta não vem de ter verificado, vem de não ter encontrado motivo interno para duvidar.

É esse mecanismo que torna a convergência detectável em princípio. Se cada falha fosse um acidente único, não haveria assinatura repetível para procurar. Como a falha nasce de uma leitura equivocada que se propaga de forma relativamente previsível dentro da mesma arquitetura de raciocínio, o rastro que ela deixa — a forma da execução, o tamanho dela, a semelhança entre patches de casos parecidos — também tende a ser previsível. É essa previsibilidade que abre espaço para detecção sem depender de rodar o código gerado contra teste nenhum, que é o assunto da próxima seção.

---

As Técnicas De Detecção Sem Teste E As Taxas De Acerto

A consequência prática do achado acima é que passa a fazer sentido procurar sinais estruturais na própria execução do agente — como ele se comportou, quantos passos deu, se repetiu padrões — em vez de depender exclusivamente do resultado final passar ou não numa suíte de testes. O mesmo estudo descreve duas técnicas de detecção que não exigem executar nada além da trajetória do próprio agente, e que os autores chamam de "test-free": não dependem de rodar teste, ambiente ou verificação externa para sinalizar suspeita de falha.

A primeira é um detector de loop baseado em 3-gramas — ele olha para sequências de três ações consecutivas na trajetória do agente e verifica repetição. A lógica é que um agente que está genuinamente perdido, sem saber como avançar, tende a repetir os mesmos blocos de ação sem progresso real — um sintoma comportamental de estar preso, mesmo antes de qualquer teste rodar. Segundo o estudo, esse detector pega 100% de certos casos de abstenção — situações em que o comportamento correto seria o agente reconhecer que não conseguiu resolver o problema — sem gerar falso positivo em alguns dos modelos avaliados.

A segunda técnica é mais simples ainda: uma regra de teto de passos, o chamado step-ceiling. A ideia é observar quantos passos o agente consumiu até declarar a tarefa concluída e marcar como suspeita qualquer execução que ultrapasse um limite calibrado para aquele tipo de tarefa. Essa regra, sozinha, pega 80% dos casos de abstenção identificados no estudo — uma heurística barata, que não exige olhar o conteúdo da trajetória, só contar passos.

O ponto que amarra essas duas técnicas ao achado da seção anterior é este: nenhuma delas olha se o código funciona. Nenhuma roda um teste. Ambas olham para a forma da execução — repetição, duração — e extraem dali um sinal que se correlaciona com falha. Isso só funciona porque a falha silenciosa não é aleatória; ela deixa uma assinatura comportamental reconhecível, exatamente como a convergência de patches sugere. Segundo o estudo, esses sinais test-free recuperam parte do que a taxa de submissão — a métrica mais óbvia e mais pobre, que só olha se o agente disse "concluí" — perde como indicador de qualidade.

Para organizar visualmente as duas técnicas descritas no estudo:

Técnica	O que observa	Custo de execução	Taxa de acerto reportada
Detector de loop (3-gramas)	Repetição de blocos de três ações consecutivas na trajetória	Nenhuma execução de teste; só análise da trajetória	100% de certos casos de abstenção, sem falso positivo em alguns modelos
Step-ceiling (teto de passos)	Número total de passos até a declaração de conclusão	Nenhuma execução de teste; contagem simples	80% dos casos de abstenção

Vale registrar a ressalva que o próprio enquadramento do estudo sugere: essas taxas foram medidas nos casos de abstenção analisados na pesquisa, não como garantia universal de que todo tipo de falha silenciosa em qualquer tarefa vai ser pega nesses mesmos percentuais. É um resultado promissor, não uma bala de prata. Ainda assim, sinais tão baratos de calcular — sem rodar nada, sem infraestrutura de teste — são exatamente o tipo de guardrail que compensa manter ligado por padrão, na linha do que já defendi ao escrever sobre segurança embutida no harness do agente em vez de numa etapa de review depois: quanto mais barato o sinal, menos desculpa para não instrumentá-lo desde o início.

---

O Dado Mais Amplo: Falso Sucesso Não É Exceção, É Padrão Comum

O achado sobre convergência de patches é específico de um cenário — agentes de codificação, tarefas de correção de bug. Vale colocar ao lado dele um retrato mais amplo do problema, vindo de uma pesquisa relacionada, "From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents". Esse estudo caracteriza exatamente o fenômeno mais geral: agentes LLM que afirmam ter concluído a tarefa quando o estado real do ambiente mostra o contrário — o que os autores chamam de falso sucesso.

Os números que o estudo reporta variam bastante conforme o domínio, o que já é, por si só, uma informação relevante. Em cenários de controle único — domínios de benchmark em que o agente tem controle relativamente direto sobre o resultado —, o falso sucesso responde por 45% a 48% das falhas observadas. Isso significa que quase metade das vezes que um agente falha nesses domínios, ele não sinaliza a falha de jeito nenhum — ele simplesmente declara sucesso e segue em frente, deixando para quem confia no relatório dele a tarefa de descobrir depois que não era bem assim.

O número fica ainda mais alto entre agentes de código que se autoavaliam no benchmark AppWorld: 75,8% das trajetórias com reivindicação explícita de status de sucesso eram, na verdade, falso sucesso. Três em cada quatro vezes que um agente de código, nesse benchmark específico, afirmou explicitamente "terminei" ou equivalente, a afirmação era falsa. É um número alto o suficiente para mudar a forma como se deveria tratar, por padrão, qualquer declaração de conclusão vinda de um agente de codificação autoavaliado — tratar como hipótese a verificar, não como fato reportado.

Um terceiro estudo, "Silent Failure in LLM Agent Systems: The Entropy Principle and the Inevitable Disorder of Autonomous Agents", ataca o problema de um ângulo ainda mais amplo. A pesquisa analisou mais de 40 mil execuções controladas e mais de 100 mil interações de agente, procurando por uma lógica estrutural comum por trás de falhas que acontecem sem nenhum gatilho externo — sem input adversarial, sem falha de rede, sem esgotamento de recurso. A conclusão central é que essas falhas não deveriam ser tratadas como bugs isolados de configuração, e sim como um padrão estrutural recorrente, algo inerente à forma como sistemas de agentes acumulam desvio ao longo de interações sucessivas.

O ponto que conecta esses três estudos é o mesmo, ainda que cada um o meça de um jeito diferente: falha silenciosa não é o caso raro e estranho que só acontece quando alguma coisa externa dá errado. É um comportamento estrutural do próprio processo de raciocínio do agente, mensurável em escala, com taxas altas o suficiente — quase metade das falhas em alguns domínios, mais de três quartos em outro — para justificar tratamento sistemático em vez de tratamento ad hoc. Isso também é o que já discuti ao escrever sobre postmortems de agentes de IA em produção: investigar falha de agente exige outro playbook justamente porque não há garantia de que a própria trajetória do agente vai admitir, em algum ponto, que algo deu errado.

---

O Que Fazer Na Prática

Vale um exemplo hipotético para tornar isso concreto — uma situação ilustrativa, não um relato de caso real. Imagine um time de plataforma que expõe um agente de codificação para desenvolvedores internos abrirem pull requests automaticamente contra repositórios de baixo risco. O fluxo hoje aceita qualquer PR que o agente declare como concluído e que passe no pipeline de CI padrão. O problema é que boa parte das falhas que esse time vem encontrando em produção não são falhas de CI — são casos em que o teste existente não cobria o cenário que o agente deveria ter tratado, e o agente, sem perceber a lacuna, declarou sucesso mesmo assim.

Um ajuste razoável, à luz do que os estudos descrevem, seria instrumentar dois sinais baratos antes mesmo de olhar o resultado do CI: um contador de repetição de blocos de ação na trajetória do agente (a lógica do detector de 3-gramas) e um teto de passos calibrado por tipo de tarefa (o step-ceiling). Nenhum dos dois substitui o CI — eles rodam antes, como triagem, sinalizando trajetórias suspeitas para revisão humana adicional em vez de aceitação automática. Uma trajetória que bate no teto de passos ou que mostra repetição de padrão de ação não é necessariamente uma falha, mas é candidata a receber mais atenção antes de virar merge automático.

Esse tipo de triagem não é gratuito — exige capturar a trajetória completa do agente, não só o diff final, e calibrar limiares por tipo de tarefa, já que um teto de passos razoável para um bug simples difere do teto razoável para uma refatoração ampla. Mas o custo é pequeno perto do custo de aceitar, por padrão, uma declaração de sucesso que — segundo a pesquisa mais ampla — pode estar errada em quase metade dos casos de falha, dependendo do domínio, e em mais de três quartos das vezes em autoavaliação de código.

Uma extensão natural desse raciocínio é tratar a linguagem confiante do próprio agente como um sinal a desconfiar, não a confiar. Se execuções curtas e conclusões rápidas tendem a correlacionar com leitura errada do problema travada cedo, então a ausência de dúvida no resumo final do agente — a mesma ausência que me incomodou na cena que abriu este post — deveria, contraintuitivamente, aumentar a atenção do revisor, não diminuir. Um agente que expressa incerteza, que lista o que não conseguiu verificar, está dando um sinal de qualidade melhor do que um agente que fecha tudo com aparência de certeza total.

---

Conclusão

Não tenho uma resposta fechada sobre até que ponto essas técnicas test-free vão se generalizar para além dos domínios em que foram medidas, e acho que seria desonesto fingir que tenho. O que os números sugerem é promissor — detectar 80% ou 100% de certos casos de abstenção sem rodar teste nenhum é um ganho real de custo e velocidade — mas são taxas medidas em contextos específicos, não garantia universal para qualquer harness de agente que alguém for montar amanhã.

O que fica mais sólido, e por isso mais útil de carregar, é a mudança de enquadramento por trás desses números: falha silenciosa não é ruído que só se resolve com mais teste, mais cobertura, mais verificação bruta. É um padrão estrutural, com assinatura comportamental reconhecível, porque nasce de um mecanismo específico — o agente travando numa leitura errada do problema cedo e otimizando dentro dela em vez de contra ela. Entender isso muda a pergunta a fazer diante de qualquer output de agente: não é só "isso passou no teste?", é também "essa trajetória se parece com as que historicamente correspondem a falha?".

Fica também uma inquietação que não tenho como resolver neste post: se quase metade das falhas em alguns domínios, e mais de três quartos em outro, passam despercebidas por quem só olha a declaração final do agente, quanto desse problema já está presente em pipelines que hoje confiam nessa declaração sem checar mais nada? Não tenho o número — só a suspeita, reforçada por esses três estudos, de que ele não é pequeno.

Fontes:

• arXiv — Confident and Wrong: Silent Semantic Failures in Coding Agents
• arXiv — From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents
• arXiv — Silent Failure in LLM Agent Systems: The Entropy Principle and the Inevitable Disorder of Autonomous Agents
• arXiv — AppWorld: A Controllable World of Apps and People for Benchmarking Interactive Coding Agents