EN·ES·PT
Teste de agentes de IA · como testar LangGraph & sistemas agênticos

Teste de agentes de IA: o que quebra em produção.

Agentes não falham do jeito que funções falham. Um teste unitário verifica uma entrada contra uma saída; um agente planeja, chama ferramentas, lembra e faz loops — então os bugs se escondem entre os turnos, na fronteira das ferramentas e nas partes que não são determinísticas. Esta página mapeia a superfície de falha que os testes unitários não conseguem enxergar, e as sondas que capturam cada uma antes que seus usuários as descubram.

A lição · por que avaliações de turno único não bastam

Uma suíte de turno único verde escondia um 502 em cada mensagem seguinte.

Em um build, um chatbot de escopo passava suas verificações de turno único sem problemas: faça uma pergunta, receba uma boa resposta, verificação verde. Mas no momento em que um usuário enviava uma segunda mensagem na mesma conversa, o endpoint retornava um 502 — toda vez. O teste de turno único não consegue enxergar isso, porque nunca envia o turno dois. Uma golden probe multi-turno — uma conversa roteirizada que reproduz vários turnos e verifica toda a trajetória — pegou o problema na hora. Essa é a essência do teste de agentes: você testa a conversa e o loop, não uma única chamada.

Lição real de um build publicado · nenhuma métrica reivindicada além da própria falha
A superfície de falha

O que os testes unitários não pegam — e o que captura.

Cada linha é uma falha que um teste unitário de turno único é estruturalmente incapaz de observar, associada à sonda que a captura.

Superfície de falha do agente → como um teste unitário deixa passar → a sonda que captura
Falha Como um teste unitário deixa passar A sonda que captura
Desvio multi-turno Verifica um par entrada/saída; a conversa nunca chega ao turno dois, então o estado que só se corrompe entre turnos fica invisível. Golden probe multi-turno — uma conversa roteirizada de N turnos verificando toda a trajetória, não uma única resposta.
Erros de chamada de ferramenta Faz mock da ferramenta e verifica o caminho feliz; nunca exercita argumentos malformados, seleção errada de ferramenta ou uma ferramenta que retorna um erro. Verificações na fronteira das ferramentas — confirmam que o agente escolhe a ferramenta certa, com argumentos válidos, e se recupera quando a ferramenta falha.
Injeção de prompt entre turnos Testa apenas entradas confiáveis; conteúdo hostil plantado no turno um que sequestra o turno três fica fora de escopo. Bateria de red-team — payloads injetados na saída da ferramenta e no histórico, verificando que o agente recusa e permanece dentro da política.
Não-determinismo & instabilidade Uma única passagem parece verde; a mesma entrada silenciosamente produz um caminho diferente e errado na próxima execução. Execuções de repetição / robustez — a mesma sonda executada K vezes, pontuada pela taxa de aprovação, com verificações de paráfrase e retentativa.
Falhas de loop & terminação Nenhum loop é executado, então loops de ferramenta descontrolados, saídas prematuras e planos travados nunca aparecem. Limites de trajetória — verificam a contagem de etapas, a terminação e que o agente atinge um estado de parada válido.
Saída sem fundamentação / sem citação Verifica se o texto lê bem, não se cada afirmação remonta a uma fonte recuperada. Gate de cobertura de citações — cada afirmação gerada deve mapear para uma fonte, garantido por construção.

Método, não dependência de fornecedor. As mesmas três famílias — golden probes multi-turno, uma bateria de red-team e execuções de repetição/robustez — se aplicam ao LangGraph, a um loop personalizado ou a um framework de agente pronto.

O loop, instrumentado

Onde as sondas se conectam.

Um agente é um loop: receba a entrada, planeje, chame uma ferramenta, responda — e frequentemente repita. Cada aresta desse loop é um ponto onde uma sonda se conecta. O gate no final decide publicar ou bloquear.

Loop do agente com pontos de conexão de sondas A entrada flui para Planejar, depois para a Chamada de ferramenta, depois para Responder, voltando para Planejar no próximo turno. As golden probes multi-turno se conectam entre turnos, as verificações na fronteira das ferramentas se conectam na chamada de ferramenta, e uma bateria de red-team injeta na entrada e na saída da ferramenta. A trajetória é pontuada contra um gate de avaliação que publica ou bloqueia o release. Entrada turno do usuário Planejar escolher próxima etapa Chamada de ferramenta agir sobre o mundo Responder responder / continuar próximo turno — onde o desvio multi-turno se esconde verificações na fronteira das ferramentas injeção de red-team trajetória pontuada Gate de avaliação taxa de aprovação + red-team publicar gates aprovados bloquear — falha → de volta ao conserto
O loop é a unidade sob teste. As sondas se conectam a cada aresta; o gate de avaliação transforma uma trajetória pontuada em uma decisão de publicar ou bloquear — a mesma disciplina que fez meu QA OS bloquear seu próprio release quando encontrou 15 CVEs high/critical.
O método · três famílias de sonda

Golden probes multi-turno + uma bateria de red-team + robustez.

1 · Golden probes multi-turno

Conversas roteirizadas que reproduzem vários turnos e verificam toda a trajetória — escolha de ferramenta, estado e a resposta final. Esta é a camada que teria pegado o 502 do segundo turno logo no primeiro dia.

2 · Bateria de red-team
  • Injeção plantada na saída da ferramenta e no histórico, não apenas no prompt
  • Verifica que o agente recusa e permanece dentro da política
  • Casos de jailbreak, exfiltração e fuga de escopo rodam em cada build
3 · Retentativa / robustez
  • Rode cada sonda K vezes, pontue pela taxa de aprovação — instável ≠ aprovado
  • Parafraseie a mesma intenção; o agente precisa se manter firme
  • Limite as etapas do loop e verifique uma terminação limpa
A prova · não afirmações, recibos

Isso não é teoria — é como eu já trabalho.

Um gate que bloqueou seu próprio release

Meu QA OS capturou 15 CVEs high/critical, bloqueou o release e foi corrigido para 3.759 testes / 13-de-13 gates no mesmo dia. Um gate que não consegue dizer "não" não é um gate.

Fundamentado por construção

Um dashboard de pesquisa RAG com 100% de cobertura de citações — não existe caminho para gerar uma afirmação sem citação. O gate de citações é estrutural, não uma esperança.

Suítes determinísticas que se sustentam

Uma suíte pública de regressão SDET: 37/37 specs, 0 flakes, 15,3s. Em fluxos fintech reais, reduzi a taxa de instabilidade de 10% para menos de 1% em mais de 500 testes.

Números públicos ligam a um recibo; os números da HighStrike são de um cargo anterior, autorrelatados · este site roda seu próprio QA (mais de 100 verificações, limpo no axe)
Relacionado · mais sobre testar IA

Preocupado que um agente específico vá para produção quebrado?

Agende uma call e definiremos o escopo de uma suíte de sondas para o seu agente — ou cole a resposta da sua IA na demo de avaliação ao vivo e veja-a ser avaliada agora mesmo.

Agendar uma call → ▸ experimente a demo de avaliação ao vivo Avaliação de LLM & QA →
perguntas frequentes

Perguntas, respondidas.

Por que agentes são mais difíceis de testar do que um único prompt?
Eles tomam ações em várias etapas com ferramentas e memória, então as falhas se acumulam ao longo das etapas e a mesma entrada pode seguir caminhos diferentes. Você testa toda a trajetória, não apenas a resposta final.
O que você realmente verifica em um agente?
Correção das chamadas de ferramenta, comportamento de loop e terminação, aderência às guardrails, custo e latência, e recuperação de uma etapa ruim — além do resultado de ponta a ponta.
Isso funciona com LangGraph ou um loop personalizado?
Sim. As mesmas famílias de verificações se aplicam, seja LangGraph, um loop de agente personalizado ou outro framework; eu conecto o harness à sua implementação.
Você pode bloquear deploys com base em avaliações de agentes?
Sim. A avaliação do agente roda no CI e bloqueia um release que regride nas trajetórias que importam.
Quais frameworks de agente você suporta — LangGraph, CrewAI ou um loop personalizado?
Todos eles. As verificações têm como alvo a trajetória do agente, não o framework, então LangGraph, CrewAI e loops feitos à mão são conectados da mesma forma. Eu adapto o harness a qualquer runtime que você já use.
Como você bloqueia um deploy com base no comportamento do agente sem bloquear todo release?
A avaliação roda no CI contra um conjunto fixo de golden trajectories e só bloqueia quando o comportamento regride nelas. O não-determinismo é tratado com faixas de tolerância e execuções repetidas, então um release saudável é publicado e uma regressão real o interrompe.
Como é o cronograma típico de um engajamento?
Começa com uma etapa curta de escopo para mapear as trajetórias críticas do seu agente, depois uma fase de construção das golden probes e da bateria de red-team, e então a entrega com o harness conectado ao CI. O trabalho é concentrado no início; o harness continua rodando depois que eu saio.
O que eu realmente recebo ao final do engajamento?
Um harness de testes em execução no seu repositório — golden probes, uma bateria de red-team e o gating no CI — mais um relatório escrito das falhas encontradas e de como cada uma passa a ser capturada. Tudo é seu para rodar e estender sem mim.
Como você testa agentes que chamam ferramentas e APIs externas?
As chamadas de ferramenta são exercitadas contra fakes controlados e fixtures gravados para que os testes permaneçam determinísticos, e depois verificadas por amostragem contra a integração ao vivo. Isso captura chamadas malformadas, argumentos ruins e erros de ferramenta mal tratados antes que cheguem à produção.
Como o escopo e o preço de um engajamento de teste de agentes são definidos?
O escopo acompanha a superfície do seu agente — o número de trajetórias, ferramentas e guardrails que precisam de cobertura — e o preço é uma cotação fixa por escopo acordado. Você recebe a estimativa antes de qualquer trabalho começar, sem contador de horas em aberto.