Agente de IA preso em loop: como detectar antes de gastar orçamento

Um agente de IA está preso em loop quando repete uma etapa que já falhou, ou uma variação próxima dela, e nada no estado compartilhado muda entre as tentativas. Os sinais mais cedo confiáveis são chamadas de ferramenta idênticas, o mesmo erro voltando a cada nova tentativa e o número de passos subindo enquanto o trabalho concluído continua parado. Para interromper o loop cedo, é preciso um limite rígido para cada tarefa, uma verificação de progresso que compare o estado entre as tentativas e uma regra de escalonamento que entregue a decisão a uma pessoa, em vez de deixar o agente tentar de novo.

Principais pontos

• Loop é repetição sem progresso, então detecte comparando o estado entre tentativas, e não contando mensagens.
• Defina limites de passos, tempo e novas tentativas antes da primeira execução real, e não depois do primeiro incidente.
• Toda ação que altera o mundo externo precisa de uma chave de idempotência, para que uma nova tentativa não envie uma segunda mensagem nem crie um registro duplicado.
• Quando a mesma falha se repete com o estado inalterado, pause a tarefa e escale com as evidências anexadas.
• Revise os eventos de loop toda semana, porque um loop que ninguém examina tende a voltar com outra forma.

Como um loop preso se parece na prática

Um loop preso raramente é dramático. O agente chama a mesma consulta com os mesmos argumentos, recebe o mesmo resultado vazio e reformula levemente a próxima mensagem antes de tentar de novo. Em outros casos, ele alterna entre duas ferramentas, por exemplo editando um rascunho e depois restaurando a versão anterior, ou relê o mesmo documento depois de cada gravação que falhou. Cada passo parece razoável isoladamente, e a falha só fica visível quando você compara o passo vinte com o passo cinco.

Por isso, a explicação do próprio agente é uma evidência fraca. Um modelo em loop pode descrever cada tentativa como uma ideia nova, e sua confiança não cai só porque já falhou três vezes. A verificação precisa vir de fora do modelo, nos registros e no estado que a camada de ferramentas grava. A distinção importa para a operação: uma nova tentativa após um timeout é algo comum, enquanto a quarta tentativa de um erro de validação que não mudou aponta para um defeito no fluxo de trabalho. Para um tratamento mais profundo das regras de parada, veja Agente de IA preso em loop: condições de parada que funcionam.

Quais sinais revelam uma etapa repetida que falhou?

Nenhum sinal isolado prova um loop. Uma ferramenta lenta ou um contexto longo podem parecer um agente travado, então trate os sinais como um conjunto e aja quando dois ou mais apontarem na mesma direção. Estes são os que valem a atenção primeiro:

• A mesma ferramenta é chamada com argumentos idênticos ou quase idênticos mais de uma vez seguida.
• Um código ou mensagem de erro volta após cada tentativa e não muda.
• O estado compartilhado, como o status de um registro, a posição em uma fila ou a versão de um rascunho, permanece igual ao longo de vários passos.
• O número de passos sobe enquanto a quantidade de subobjetivos concluídos continua igual.
• O agente alterna entre duas ações que desfazem uma à outra.
• O custo ou o consumo de tokens por tentativa aumenta, porque cada tentativa falha é acrescentada ao contexto.
• A saída repete a tentativa anterior com outras palavras e não acrescenta nenhum fato novo.

O último sinal é o mais difícil de perceber numa transcrição. Dois parágrafos podem parecer diferentes e descrever a mesma falha. Uma verificação simples de similaridade entre saídas consecutivas captura boa parte disso, mas o resultado deve disparar uma revisão, e não funcionar como veredito.

Quais limites impedem que o loop consuma o orçamento?

Os limites são a última linha de defesa e devem existir mesmo quando a detecção funciona. Defina-os por tipo de tarefa, e não uma única vez para o agente inteiro. Um conjunto útil cobre o número máximo de passos de uma tarefa, o tempo máximo decorrido, o número máximo de chamadas a uma mesma ferramenta, o número máximo de novas tentativas de uma mesma ação e um teto de gasto expresso na unidade que sua equipe já acompanha. As orientações da Anthropic sobre como construir agentes eficazes recomendam condições de parada como um número máximo de iterações, o que é um bom ponto de partida. Os materiais da FinOps Foundation sobre economia unitária levam a conversa para o custo por resultado concluído, e não por mensagem, o que facilita definir o teto de gasto.

Os limites funcionam melhor quando falham de forma segura. Ao atingir um deles, a tarefa deve parar em um estado conhecido, registrar o motivo e aguardar uma pessoa, em vez de abandonar o trabalho em silêncio ou seguir por um caminho alternativo que ninguém aprovou. Um loop que termina com um motivo de parada claro é um evento operacional que você pode revisar. Um loop que termina porque o orçamento acabou é um custo que você terá de explicar depois.

Como montar uma verificação de progresso que o agente não consiga contornar?

A verificação de progresso é o controle mais útil, porque não depende de como o agente descreve o próprio trabalho. Antes de a tarefa começar, defina os campos de estado que representam progresso para aquele tipo de tarefa, como o status de um registro, a contagem de itens verificados ou a última versão gravada com sucesso. Depois, monte a verificação nesta ordem:

• Liste os campos de estado que comprovam progresso em um tipo de tarefa e marque quais deles o agente consegue alterar.
• Capture um instantâneo desses campos antes do primeiro passo e depois de cada passo, guardado fora do contexto do modelo.
• Gere uma impressão digital de cada chamada de ferramenta pelo nome da ferramenta e pelos argumentos normalizados, para que as repetições continuem visíveis mesmo quando a redação muda.
• Defina uma regra de estagnação, como nenhuma mudança de estado em passos consecutivos ou a mesma impressão digital aparecendo duas vezes, e registre qual regra foi disparada.
• Encaminhe a regra disparada para o caminho de parada descrito na seção seguinte, para que o agente não decida sozinho se deve continuar.

Mantenha as regras simples o bastante para que um responsável de operações consiga lê-las. Uma verificação que ninguém entende será desligada na primeira vez que disparar numa tarefa legítima.

Como evitar duplicidades causadas por novas tentativas e efeitos colaterais?

Um loop fica caro quando mexe no mundo externo. Um agente que repete uma consulta desperdiça processamento. Um agente que repete o e-mail de confirmação pode enviar três cópias ao cliente, e um que repete um crédito pode emiti-lo três vezes. A solução não é um prompt melhor. É tornar idempotentes as ações com efeito colateral, de modo que a mesma ação pretendida carregue a mesma chave e o sistema receptor trate as repetições como uma única operação. A documentação da Stripe sobre requisições idempotentes mostra o padrão: o cliente fornece uma chave, e o provedor devolve o resultado original para uma requisição repetida, em vez de executar a ação de novo.

A sua camada de ferramentas deve seguir o mesmo princípio, mesmo quando o sistema de destino não o faz. Derive a chave a partir do identificador da tarefa e da ação pretendida, guarde-a junto com o resultado e rejeite qualquer segunda execução com a mesma chave. A política de novas tentativas fica mais fácil de raciocinar: ações somente de leitura podem ser repetidas dentro de um limite pequeno, e ações de escrita com chave podem ser repetidas com segurança, porque a duplicata é reconhecida. O padrão completo está em Ações idempotentes em agentes de IA: como evitar reembolsos duplicados.

Quando o agente deve parar e passar a tarefa adiante?

Detectar sem um próximo passo claro só gera alertas que ninguém lê. O guia de decisão a seguir transforma uma regra disparada em uma ação:

• Se a mesma falha se repete com o estado inalterado, pause a tarefa e abra um escalonamento com as evidências.
• Se o próximo passo exige uma permissão que o agente não possui, pare e entregue a decisão ao responsável nomeado.
• Se o loop envolveu dinheiro, clientes ou registros regulados, bloqueie aquela classe de ação para o agente até que alguém a revise.
• Se a causa for um limite externo ou uma indisponibilidade, mova a tarefa para uma fila ou um caminho alternativo, em vez de insistir com mais força.
• Se o loop chegou a um cliente ou deixou uma alteração parcial, execute os passos de incidente antes de qualquer outra coisa.

O escalonamento deve ser curto e útil. Envie a decisão necessária, o instantâneo do estado, as impressões digitais das chamadas repetidas e o que já foi tentado, e não uma transcrição de dezenas de tentativas. Orientações sobre isso estão em Escalonamento humano em IA: entregue a decisão necessária.

Cenário ilustrativo: um agente atualiza endereços de entrega em um sistema de pedidos. O sistema rejeita um CEP por causa de um espaço que o agente incluiu, então o agente tenta com o mesmo valor, depois com o espaço removido e depois com o valor original outra vez. A verificação de progresso percebe que o status do pedido não mudou em nenhuma tentativa e encontra a mesma impressão digital repetida. A regra de estagnação pausa a tarefa e abre um escalonamento com o identificador do pedido, o texto do erro e os valores testados. Um funcionário corrige o formato no registro de origem, e o agente retoma a partir do último ponto de controle, em vez de recomeçar. Sem a regra, o mesmo loop continuaria até atingir um limite de passos ou de gasto, com cada tentativa registrada como atividade comum.

A abordagem gerenciada da Be Human trata isso já na definição inicial do papel do agente: o responsável pela operação e a Be Human combinam os campos de estado que comprovam progresso, as condições de parada e as ações que exigem uma pessoa. Essas regras são implementadas na camada de ferramentas do agente, e não deixadas como instruções num prompt. Na operação gerenciada, os eventos de loop são revisados em avaliações recorrentes e em revisões de permissões, e qualquer loop que chegue a um cliente segue uma resposta a incidentes por escrito, com passos de parada e de reversão definidos antes.

O que um registro de loop deve conter?

Cada evento de loop deve deixar um registro que uma pessoa consiga ler sem reconstruir a transcrição inteira. Os campos mais importantes são o identificador da tarefa, o passo, o nome da ferramenta, a impressão digital dos argumentos, o erro retornado, o instantâneo do estado, o orçamento já consumido e o motivo da parada. Esse é o mínimo necessário para investigar um loop depois, e ele se sobrepõe ao que uma boa trilha de auditoria de agente de IA exige. O material introdutório do OpenTelemetry explica por que rastros, métricas e registros devem compartilhar um identificador, para que uma tarefa possa ser acompanhada em todos eles. Revise os eventos de loop no mesmo ritmo semanal das demais operações do agente, para que padrões recorrentes apareçam como tendências, e não como surpresas. Equipes que já trabalham com uma checklist semanal de manutenção de agentes de IA podem incluir os eventos de loop como um item fixo.

Se você não tem certeza de qual dos seus fluxos de trabalho se beneficiaria mais desses controles, faça o diagnóstico gratuito de IA da Be Human para encontrar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Quantas novas tentativas um agente de IA deve ter antes de parar? Não existe um número universal. Defina o limite por classe de ação, considerando se a ação é somente de leitura, se é idempotente e quanto custaria uma repetição errada. Duas falhas idênticas com o estado inalterado costumam ser o ponto em que o agente deve parar e escalar.

Uma tarefa longa é a mesma coisa que um loop preso? Não. Uma tarefa longa avança, o que aparece como campos de estado alterados e subobjetivos concluídos. Um loop repete trabalho sem alterar nada que importe, e é a verificação de progresso que separa os dois casos.

O modelo consegue detectar o próprio loop? Não de forma confiável. Um modelo pode descrever tentativas repetidas como raciocínio novo e não mostrar queda de confiança. A detecção deve se basear em chamadas de ferramenta registradas, erros e instantâneos de estado que o modelo não consegue editar.

O que devo registrar para investigar um loop depois? Registre o identificador da tarefa, o passo, o nome da ferramenta, a impressão digital dos argumentos, o erro, o instantâneo do estado, o orçamento consumido e o motivo da parada. Com esses campos, quem revisa consegue ver o que foi tentado e por que a tarefa parou, sem reler toda a conversa.

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