Agente de IA preso em loop: condições de parada que funcionam

Um agente de IA fica preso em loop quando nada ao seu redor consegue perceber que repetir uma ação deixou de gerar progresso. A solução não é um prompt mais esperto. É um conjunto de condições de parada aplicadas fora do modelo: um limite de passos, um detector de repetição e um teto de custo e tempo, cada um encerrando a execução em um estado definido que uma pessoa possa revisar.

Principais pontos

• Aplique as paradas no código que executa o agente, não nas instruções que o agente lê. Um modelo instruído a se interromper pode simplesmente não fazê-lo.
• Use três camadas juntas: um limite de passos por execução, um detector de repetição para comportamento idêntico ou circular e um orçamento de custo e tempo.
• Meça o progresso pela mudança de estado (um registro atualizado, um fato novo encontrado), não pela atividade. Muitos loops parecem ocupados.
• Uma parada só é limpa se deixar um código de motivo, um resumo curto do estado e uma pessoa nomeada que decide o que acontece depois.
• Revise os limites com periodicidade. Fluxos, ferramentas e modelos mudam, e um limite que servia no trimestre passado pode estar apertado ou frouxo demais.

Como é um agente de IA preso em loop?

A versão óbvia é a mesma chamada de ferramenta repetida várias vezes com argumentos idênticos. Essa é fácil de pegar. As versões que custam mais caro são mais silenciosas.

Uma delas é a oscilação: o agente consulta um registro, edita um campo, consulta de novo, desfaz a edição e recomeça. Outra é a repetição reformulada, em que cada tentativa muda um pouco (uma busca escrita de cinco jeitos), mas nenhuma altera o resultado. Uma terceira é a tempestade de novas tentativas, em que uma ferramenta devolve um erro ambíguo e o agente o trata como motivo para tentar outra vez, sem fim. Em arranjos com mais de um agente, dois deles podem passar a tarefa de um para o outro, cada um convencido de que o outro deveria concluí-la.

As causas costumam ser comuns:

• Uma ferramenta devolve um resultado vazio ou um erro vago, e o agente não tem instrução sobre o que fazer em seguida.
• O critério de sucesso é pouco claro, então o agente não consegue saber que terminou.
• As tentativas anteriores saíram do contexto de trabalho, e o agente já não sabe que as fez.
• Um passo depende de algo que só uma pessoa pode fornecer, como uma aprovação pendente, e o agente fica procurando um atalho.

Nenhuma dessas causas se resolve pedindo ao modelo que se esforce mais. Resolvem-se tornando o loop visível e limitado. Orientações publicadas sobre design de agentes, como as notas da Anthropic sobre como construir agentes eficazes, recomendam condições de parada, como um número máximo de iterações, pelo mesmo motivo: autonomia precisa de uma fronteira que alguém escolheu de antemão.

Como definir um limite de passos que faça sentido?

O limite de passos é a parada mais simples e a que mais vezes é mal configurada. Baixo demais, corta trabalho legítimo. Alto demais, só limita o estrago depois que o loop já o causou.

Parta do comportamento observado, não de um palpite. Rode o fluxo em casos realistas (a abordagem do modo de observação é uma boa forma de reuni-los) e anote quantos turnos do modelo e quantas chamadas de ferramenta uma execução normal e bem-sucedida consome. Defina o teto confortavelmente acima da execução legítima mais lenta, não acima da média. Se o seu conjunto de testes de referência inclui casos difíceis, use-os para calibrar.

Em seguida, aplique limites em mais de um nível:

• Por execução: um máximo de turnos do modelo e um máximo de chamadas de ferramenta.
• Por ferramenta: um teto mais baixo de chamadas a qualquer ferramenta isolada, sobretudo as que gravam dados, enviam mensagens ou geram custo.
• Por tarefa: um limite que valha entre reinícios, para que uma execução que falhou e foi recolocada na fila automaticamente não comece uma contagem nova a cada vez.

O terceiro é o que mais falta. Um loop que reinicia a si mesmo continua sendo um loop, só que com o contador zerado.

Decida também o que acontece antes da parada rígida. Um limite brando, atingido bem antes do teto, pode disparar uma ação útil: pedir ao agente que escreva um resumo curto do que tentou e do que o está bloqueando. Esse resumo vira a nota de passagem se o limite rígido for atingido. Mantenha o limite rígido inegociável: o código encerra a execução, não importa o que o modelo diga.

Como detectar comportamento repetido?

Limites de passos pegam execuções longas. A detecção de repetição pega execuções que não vão a lugar nenhum, muitas vezes bem antes. Ela funciona criando uma assinatura do que o agente faz e observando padrões.

Uma assinatura útil combina o nome da ferramenta com os argumentos normalizados (em minúsculas, sem espaços sobrando, sem valores voláteis como carimbos de data e hora). Mantenha uma janela curta das assinaturas recentes da execução. Depois, procure estes sinais:

• Repetição exata: a mesma assinatura aparece de novo sem mudança de estado entre as duas chamadas.
• Repetição aproximada: os argumentos diferem só de forma trivial, como uma frase de busca com palavras reordenadas, e o resultado é o mesmo ou igualmente vazio.
• Oscilação: um padrão como A, B, A, B ao longo de alguns passos.
• Mesmo resultado por caminhos diferentes: várias chamadas distintas devolvem o mesmo conteúdo, o que sugere que o agente está rodando em torno do mesmo fato que falta.
• Eco de erro: a mesma categoria de erro devolvida repetidamente por uma ferramenta.

A escolha de projeto mais importante é o sinal de progresso. Uma chamada repetida não é problema se algo mudou entre uma e outra, por exemplo, se um registro foi atualizado e a consulta é uma verificação legítima. Por isso o detector deve perguntar: desde a última vez que essa ação rodou, algum estado relevante mudou? Se não, a segunda ocorrência é um aviso e a terceira é uma parada. Permita uma repetição antes de agir, porque uma nova tentativa depois de uma falha momentânea é razoável. Sua política de repetição deve definir exatamente quais erros merecem nova tentativa e quanto esperar, para que o detector e a política estejam de acordo.

Isso só funciona se você registrar as coisas certas. Nome da ferramenta, argumentos normalizados, categoria do resultado e um indicador de mudança de estado por passo bastam para montar o detector e investigar depois. O artigo sobre o que registrar na observabilidade de agentes cobre o quadro mais amplo.

Quais limites de custo e tempo encerram uma execução de forma limpa?

Limites de passos e detecção de repetição observam o comportamento. Orçamentos observam as consequências. Um agente em loop pode ficar abaixo do limite de passos e ainda assim sair caro, se cada passo for grande, ou pode sobrecarregar um sistema externo em pouco tempo.

Use orçamentos em três níveis:

• Por execução: um teto de uso do modelo e de tempo decorrido para uma tentativa. Relacione o limite de tempo ao orçamento de latência para o qual o fluxo foi desenhado, já que uma execução muito além dele raramente ainda é útil.
• Por tarefa ou cliente: um teto para todas as tentativas sobre o mesmo trabalho, de modo que reinícios repetidos somem em algo visível.
• Por agente por dia: um disjuntor que pausa o agente e avisa uma pessoa quando o uso total sai do normal. Ele pega o caso em que muitas execuções parecem ok, mas algo a montante está inundando a fila.

Limites externos também importam. Um agente em loop pode esgotar a cota de um parceiro ou provocar bloqueios que afetam outros sistemas, tema tratado em limites de taxa de API em agentes de IA. Defina um teto de chamadas por minuto para cada sistema conectado, separado do orçamento do modelo.

Para que os orçamentos façam sentido, compare-os com o que uma tarefa concluída normalmente custa. A abordagem de medir o custo por tarefa concluída dá uma linha de base, e o teto pode ser definido como um múltiplo do normal, não como um número arbitrário. O consumo ilimitado de recursos também é uma categoria de risco reconhecida na lista OWASP Top 10 para aplicações com LLMs, uma boa referência quando alguém perguntar por que esses tetos não são opcionais.

Para ações com efeito financeiro direto, os limites devem ser mais rígidos e ficar ao lado de limites específicos para pagamentos feitos por agentes.

O que deve acontecer quando uma condição de parada dispara?

Uma parada que simplesmente mata o processo pode deixar uma ação pela metade: um e-mail enviado mas não registrado, um registro atualizado mas não confirmado. Uma parada limpa é uma sequência curta e previsível. Construa-a uma vez e reutilize para todas as condições de parada.

• Primeiro, bloqueie novas ações. A camada que executa o agente (o harness) recusa novas chamadas de ferramenta no instante em que um limite é atingido.
• Segundo, resolva o que estava em andamento. Conclua ou desfaça a gravação atual usando operações idempotentes, para que uma nova tentativa posterior não gere duplicidade.
• Terceiro, registre um código de motivo. Use um conjunto pequeno e fixo, como limite de passos, repetição detectada, teto de custo, teto de tempo ou limite externo, para facilitar a contagem de padrões depois.
• Quarto, salve um resumo do estado: o que o agente foi pedido a fazer, o que fez, o que tentou por último e o que acredita estar bloqueando.
• Quinto, marque a tarefa como interrompida, para que nenhuma refila automática a execute de novo. Só uma pessoa ou uma regra explícita deve reiniciá-la.
• Sexto, avise o responsável nomeado com uma decisão a tomar, não com um despejo de logs. Vale o princípio do escalonamento humano em falhas de agentes de IA: envie a decisão, não a bagunça.
• Sétimo, revise a parada. O limite estava certo, a ferramenta era confusa ou a tarefa estava mal especificada? Devolva a resposta ao runbook.

Se as paradas começarem a se repetir em várias tarefas, trate isso como um incidente, não como uma série de eventos isolados, e siga o guia de resposta a incidentes com agentes de IA. Registrar os motivos de parada e a resposta usual do responsável em um runbook de operação poupa tempo na próxima ocorrência.

Cenário ilustrativo: um loop interrompido na terceira tentativa

Este é um cenário ilustrativo, não um caso real.

Um agente ajuda a equipe de contas a pagar a conciliar notas fiscais de fornecedores com pedidos de compra. Para um fornecedor específico, o número do pedido na nota traz um prefixo que a consulta ao ERP não reconhece. A consulta devolve resultado vazio. Sem uma parada, o agente poderia reformular a busca várias vezes, tentar uma busca pelo nome do fornecedor e depois voltar à consulta original.

Com condições de parada, a sequência é outra. O primeiro resultado vazio é permitido. O segundo, uma repetição aproximada sem mudança de estado, gera um aviso, e o agente é instruído a resumir o que já tentou. A terceira repetição aproximada aciona o detector. O harness bloqueia novas consultas, grava o código de motivo e envia ao responsável por contas a pagar uma nota curta: a nota fiscal, o número pesquisado, as três variações tentadas e o resultado vazio de cada uma.

O responsável reconhece o problema do prefixo em um minuto e concilia a nota manualmente ou adiciona uma regra de normalização à consulta. A tarefa permanece marcada como interrompida até lá, então nada a executa de novo sem que ninguém perceba. O custo do loop são três consultas, não uma busca sem fim, e a equipe aprende algo sobre os dados. Se o seu agente toca um ERP, as verificações para conectar um agente de IA ao ERP listam os tipos de comportamento de consulta que vale testar antes do lançamento.

Como a Be Human lida com loops descontrolados?

A Be Human trata as condições de parada como parte do primeiro ciclo de trabalho, junto com o papel do agente, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. Limites de passos, detecção de repetição, orçamentos e a sequência de parada são configurados na camada operacional do agente, não deixados para o prompt, e o responsável que recebe uma tarefa interrompida é nomeado com antecedência. Na operação gerenciada, os eventos de parada são monitorados, as avaliações recorrentes incluem cenários de loop e os limites são revistos nas revisões de permissões e integrações e depois de mudanças de modelo ou de ferramenta, seguindo a rotina do checklist semanal de manutenção. Mudanças nos limites passam pelo mesmo processo controlado descrito em ambiente de teste e produção para agentes de IA.

Perguntas frequentes

Por que meu agente de IA fica repetindo a mesma ação? Em geral porque o resultado da ferramenta não indicou um próximo passo claro, o critério de sucesso é vago ou as tentativas anteriores saíram do contexto de trabalho. Verifique as mensagens de erro da ferramenta e a definição de pronto antes de trocar o modelo ou o prompt.

Posso apenas instruir o agente a parar depois de algumas tentativas? Pode incluir a instrução, mas não dependa dela. O modelo pode contar errado, esquecer ou decidir que mais uma tentativa se justifica, então o limite rígido precisa ser aplicado pelo código que executa o agente.

Qual é uma boa primeira condição de parada se eu só puder adicionar uma? Um limite de chamadas de ferramenta por execução, aplicado em código, com um código de motivo e um aviso a uma pessoa nomeada quando disparar. É simples, limita o pior caso e gera os dados para adicionar depois a detecção de repetição e os orçamentos.

Com que frequência revisar as condições de parada? Revise com periodicidade definida e sempre que o fluxo, uma ferramenta conectada ou o modelo de base mudar. Os motivos de parada são o melhor insumo: se um limite dispara com frequência em trabalho legítimo, afrouxe-o com base em evidência, e se loops passam despercebidos, aperte o detector. Uma abordagem relacionada está em o que fazer quando o modelo de IA muda.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.