Conteúdo da trilha
8 minNarração em inglês, legenda em portuguêsPodcast (RSS)
Capítulos
  1. 0:00Abertura
  2. 0:54O diagnóstico
  3. 2:08Por que acontece
  4. 2:50Quanto custa
  5. 3:49Um desafio
  6. 4:27O tratamento
  7. 6:21Parentes próximos
  8. 7:00Quando ignorar
  9. 7:17Fechamento
Transcrição

Abertura

Um agente de navegador baixa faturas do portal de um fornecedor. Toda noite ele entra, percorre as páginas e salva cada fatura.

Uma noite, o portal mudou o botão de próxima página. Ele continuava na tela, mas não carregava nada.

Aqui está o trace da manhã seguinte. Passo quatrocentos e doze, clicar em próxima página. Ok. Ler a página. Faturas um a vinte, de trezentas e quarenta. Clicar de novo. Ok. Ler de novo. Faturas um a vinte.

Até o passo dois mil trezentos e dezoito.

Ninguém escreveu um bug naquele loop. Ele só não tinha fim, além de quando o modelo acha que terminou. E o modelo nunca achou. Nesta aula, você vai aprender a achar esse smell antes da fatura, e como é um fim de verdade.

O diagnóstico

Repare em dois detalhes daquele trace.

O clique responde ok, mesmo quando nada muda.

E a leitura da página sempre mostra as mesmas vinte primeiras faturas. A prova de que o agente estava preso estava ali. Mas nenhum código olhava para ela.

O formato do smell é este. O modelo pede uma ação que parece sensata.

A ferramenta responde sem erro, mesmo sem progresso nenhum.

Cada turno reenvia o histórico inteiro, que cresce a cada passo.

A única saída do loop é o modelo decidir parar.

E quando ele não decide, quem para a execução é a fatura do provedor.

Como identificar? O código do agente diz while true, ou while not done, sem contador de passos.

Não há limite de tempo, de tokens nem de dinheiro por execução.

Ninguém sabe dizer o que acontece se o modelo nunca der a resposta final. E a execução mais cara do mês custou dezenas de vezes a mediana.

O trace mostra a mesma ferramenta, com os mesmos argumentos, várias vezes seguidas.

E o único alarme que toca é o do cartão de crédito.

Por que acontece

O protótipo nasceu assim. Os exemplos mais simples de agente usam while true, e o loop foi para produção do jeito que estava.

Funciona no teste. Nas tarefas de demo, o modelo termina em cinco passos. Ninguém testou o portal com o botão quebrado.

Ferramentas que mentem por omissão. Ok, como resultado de um clique, não diz se algo mudou. O modelo não tem como perceber que está preso.

E o provedor parece um limite. As pessoas acham que a janela de contexto uma hora vai parar o agente. Mas muitos frameworks cortam o histórico antigo para caber. E aí o loop roda para sempre.

Quanto custa

Agora, o custo, com números ilustrativos. Digamos que o prompt de sistema e as descrições das ferramentas somam três mil tokens, e cada turno acrescenta uns quatrocentos. Uma execução normal de dez turnos manda uns cinquenta e dois mil tokens no total. Uma presa, de duzentos turnos, manda uns oito milhões e seiscentos mil.

Vinte vezes mais turnos, e mais de cento e sessenta vezes mais tokens. O custo cresce com o quadrado do número de passos, porque cada turno paga de novo tudo o que veio antes. Uma única execução presa pode custar mais que um dia inteiro de uso normal.

E o dinheiro é a parte menor. O loop come a cota de requisições da conta e derruba outras execuções que dividem a mesma chave.

Se a ferramenta presa tem efeito colateral, como enviar, criar ou pagar, cada turno repete o efeito.

E um trace com milhares de passos é quase impossível de ler.

Um desafio

Uma pergunta para você. Um agente roda em while true. Mas a ferramenta dele tem limite de dez chamadas por minuto, então ele nunca gasta muito por minuto. Isso é um unbounded loop?

Sim. Limite de taxa controla velocidade, não o total. Um loop preso a dez chamadas por minuto ainda faz mais de catorze mil chamadas por dia. Ele só espalha o custo no tempo. E a janela de contexto também não é um freio confiável. Muitos frameworks descartam mensagens antigas para caber, e o loop continua pagando uma janela cheia, em todo turno.

O tratamento

O tratamento é uma refatoração chamada add loop budget. E o orçamento tem quatro partes. A última é a que todo mundo esquece.

Um limite de passos. Escolha pelos seus traces. Se 99% das execuções terminam em até quinze passos, um limite de quarenta dá folga, sem permitir uma noite inteira.

Limites de tempo e de custo. Passos podem ser baratos ou caros. Um limite de dinheiro por execução pega o caso em que poucos passos mandam contextos enormes.

Um detector de repetição. A mesma ferramenta, com os mesmos argumentos, três vezes seguidas, quer dizer que o agente está preso. Pare antes do limite.

E o comportamento no limite. Devolva o que foi feito, explique onde parou e registre o caso. Um agente que para com uma exceção silenciosa, e faz a tarefa sumir, ainda deixa o usuário sem resposta. O limite existe, mas o tratamento não terminou.

A maioria dos frameworks de agente já te dá a primeira peça, como um número máximo de turnos, ou um limite de recursão. O resto você escreve. E junto com o orçamento, revise as suas ferramentas. Um resultado que diz o que mudou, como página dois de dezessete carregada, ajuda o modelo a perceber quando está preso. O padrão de destino se chama stop conditions, e está a duas aulas daqui.

E uma semana depois de colocar o limite, digamos que 2% das execuções terminam nele. Não suba o limite para quatrocentos. Sem ler os traces, você só deixa as execuções presas gastarem dez vezes mais antes de parar. E não ignore também. Leia esses traces, ache a causa, como um resultado vago de ferramenta ou uma página que mudou, e transforme cada um num caso de eval. Eles são a melhor fonte de casos difíceis que você tem.

Parentes próximos

Dois casos para afiar o olho. Um job percorre trezentas notas, chamando o modelo uma vez por nota, sem contador de passos. Isso é esse smell? Não. A lista é finita, e quem decide o próximo turno é o código, não o modelo. O loop termina na nota trezentos, de qualquer jeito.

E um agente com limite de trinta passos, em que cada passo pode criar subagentes, que também têm trinta passos e também criam subagentes. Cada nível tem limite. O total, não. Esse é um smell parente, subagent recursion. O orçamento precisa cobrir a árvore inteira, não cada nó.

Quando ignorar

Quando dá para relaxar? Um assistente de código no seu terminal, com você olhando e podendo interromper a qualquer hora, tolera um limite alto. Coloque um mesmo assim. E nenhum agente de produção, rodando sem uma pessoa olhando, deveria rodar sem limite.

Fechamento

Então, a ideia para levar. O modelo pode dizer que terminou, mas não pode ser o único freio. Passos, tempo e dinheiro pertencem ao seu código, junto com uma checagem de repetição e uma resposta clara quando o limite chega. Aí a execução mais cara do mês é um número que você escolheu.

Na próxima aula, a gente monta esse orçamento passo a passo: add loop budget. Até lá.

SmellAbusos de controle

Loop Sem Fim

Unbounded Loop

Loop Sem Fim (Unbounded Loop) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Abusos de controle. O agente pode chamar ferramentas para sempre; o único limite é o cartão de crédito.

Elemento
09/37
Nível
Intermediário
Leitura
5 min
Atualizado
Nesta página 7
  1. 01Como reconhecer
  2. 02Por que acontece
  3. 03Quanto custa ignorar
  4. 04Tratamento
  5. 05O que você ganha
  6. 06Quando ignorar
  7. 07É esse smell?
  8. ··Perguntas rápidas

Como reconhecer

Um agente de navegador baixa boletos de um portal de fornecedores. Numa noite, o portal mudou o botão “Próxima página”: ele continuava na tela, mas não carregava nada. O trace da manhã seguinte (trecho anonimizado):

step 412  tool=click        args={"selector": "a.next-page"}   result="ok"
step 413  tool=read_page    args={}                             result="Faturas 1 a 20 de 340 ..."
step 414  tool=click        args={"selector": "a.next-page"}   result="ok"
step 415  tool=read_page    args={}                             result="Faturas 1 a 20 de 340 ..."
...
step 2318 tool=click        args={"selector": "a.next-page"}   result="ok"

Ninguém escreveu um bug no loop. O loop só não tinha fim definido além de “quando o modelo achar que terminou”. O modelo nunca achou.

Repare em dois detalhes do trace. O clique responde “ok” mesmo sem mudar nada. E a leitura da página mostra sempre “Faturas 1 a 20”. A informação de que o agente estava parado existia, mas nenhum código olhava para ela.

Sinais de Loop Sem Fim:

  • O código do agente tem while True ou while not done sem contador de passos.
  • Não existe limite de tempo, de tokens ou de dinheiro por execução.
  • Ninguém sabe dizer o que acontece se o modelo nunca der a resposta final.
  • A maior execução do mês custou dezenas de vezes a mediana.
  • O trace mostra a mesma ferramenta, com os mesmos argumentos, várias vezes seguidas.
  • O único alarme que dispara é o do cartão de crédito.
flowchart TD
  M(["1. Modelo escolhe ferramenta"]):::llm --> T["2. Ferramenta responde ok"]:::tool
  T --> O[("3. Histórico cresce")]:::store
  O --> D{"4. Modelo acha que terminou?"}
  D -->|não| M
  D -->|nunca| X(["5. Fatura do provedor"]):::io
  1. O modelo pede uma ação que parece fazer sentido.
  2. A ferramenta responde sem erro, mesmo sem progresso real.
  3. Cada volta reenvia o histórico inteiro, que fica maior a cada passo.
  4. A única saída do loop é o modelo decidir parar.
  5. Quando ele não decide, a conta é quem para a execução.
Checagem +20 XP de primeiraSeu agente de suporte chama a ferramenta buscar_pedido com o mesmo número 30 vezes seguidas, e o loop é while not done. Qual é a falha de desenho que deixa isso continuar?

Por que acontece

  • O protótipo nasceu assim. Os exemplos de agente mais simples usam while True, e o loop foi para produção sem mudar.
  • Funciona no teste. Em tarefas de demonstração o modelo termina em cinco passos. Ninguém testou o portal com o botão quebrado.
  • Ferramentas que mentem por omissão. “ok” como resultado de um clique não diz se algo mudou. O modelo não tem como notar que está parado.
  • Medo de cortar no meio. Um limite parece arriscado: “e se a tarefa precisar de mais passos?”. Sem resposta para isso, ninguém põe limite.
  • O provedor parece um teto. Muita gente supõe que a janela de contexto ou o limite de requisições vai interromper o agente. Muitos frameworks cortam o histórico antigo para caber na janela, e aí o loop segue para sempre.

Quanto custa ignorar

  • Dinheiro. Cada passo reenvia o histórico, então a volta 2.000 custa muito mais que a volta 10. Uma única execução presa pode custar mais que um dia inteiro de uso normal.
  • Cota. O loop consome o limite de requisições da conta e derruba as outras execuções que dividem a mesma chave.
  • Efeitos repetidos. Se a ferramenta presa tem efeito (enviar, criar, pagar), cada volta repete o efeito.
  • Diagnóstico. Um trace com milhares de passos é quase impossível de ler.

Uma conta para ver a curva

Os números abaixo são ilustrativos. Suponha um system prompt com descrição das ferramentas de 3.000 tokens. Cada volta acrescenta uma chamada e um resultado, uns 400 tokens. Na volta n, o agente envia cerca de 3.000 + 400 × n tokens.

Execução Voltas Tokens enviados no total
Normal 10 cerca de 52 mil
Presa 200 cerca de 8,6 milhões

Vinte vezes mais voltas custam mais de 160 vezes mais tokens. O custo cresce com o quadrado do número de passos, porque cada volta paga de novo tudo o que veio antes.

Perto da volta 500, cada chamada já passa de 200 mil tokens. Se o framework começa a descartar mensagens antigas para caber, o custo por volta fica alto e constante, e nada mais força o fim. Cache de prompt barateia o prefixo repetido, mas não cria um fim.

Tratamento

Refatoração Escolha quando
Adicionar Orçamento ao Loop Sempre. Teto de passos, tempo e custo, com um comportamento definido para quando o teto é atingido.

O orçamento tem quatro partes, e a última é a que mais gente esquece:

  1. Teto de passos. Escolha olhando os traces: se 99% das execuções terminam em até 15 passos, um teto de 40 deixa folga sem permitir a noite inteira.
  2. Teto de tempo e de custo. Passos podem ser baratos ou caros. Um limite em dinheiro por execução pega o caso em que poucos passos enviam contextos enormes.
  3. Detector de repetição. A mesma ferramenta com os mesmos argumentos três vezes seguidas é sinal de que o agente está parado. Pare antes do teto.
  4. Comportamento no teto. Devolva o que já foi feito, explique onde parou e registre o caso. Parar com uma exceção muda deixa o usuário sem resposta.

Frameworks já oferecem a primeira peça: o OpenAI Agents SDK tem max_turns, e o LangGraph tem recursion_limit. O guia “Building effective agents”, da Anthropic (dez. 2024), também recomenda condições de parada como número máximo de iterações. O resto você escreve.

Junto com o orçamento, revise as ferramentas. Um retorno que diz o que mudou (“página 2 de 17 carregada”) ajuda o modelo a perceber que está parado. O padrão de destino é Condições de Parada, que define também quando o agente desiste ou pede ajuda.

Checagem +20 XP de primeiraVocê colocou um teto de 40 passos e um detector de repetição. Uma semana depois, 2% das execuções terminam no teto. Qual é o próximo passo mais útil?

O que você ganha

  • Toda execução termina, com estado conhecido: sucesso, resposta parcial, desistência ou pedido de ajuda.
  • O custo máximo de uma tarefa é um número que você escolheu.
  • Execuções que batem no teto viram casos de eval, em vez de surpresas na fatura.
  • Ferramentas presas são detectadas em minutos, não no fim do mês.

Quando ignorar

  • Loop sob supervisão constante. Um assistente de código no terminal, com uma pessoa olhando e podendo interromper a qualquer momento, tolera um teto alto. Mesmo assim, defina um.
  • Tarefas com fim garantido pelo código. Se o loop percorre uma lista finita em código e o modelo só processa cada item, o limite já existe. Confira se é mesmo o código que controla o fim.

Nenhum agente em produção, sem uma pessoa olhando, deve rodar sem teto.

É esse smell?

Checagem +20 XP de primeiraO agente tem um limite de 50 passos. Quando atinge o limite, o código lança uma exceção e a tarefa some, sem registro e sem aviso ao usuário. É Loop Sem Fim?

Checagem +20 XP de primeiraO agente tem limite de 30 passos, mas cada passo pode disparar subagentes, que também têm limite de 30 passos e também podem disparar subagentes. Qual é o diagnóstico?

Checagem +20 XP de primeiraUm agente roda em while True, mas a ferramenta que ele usa tem rate limit de 10 chamadas por minuto, então ele nunca gasta muito por minuto. É Loop Sem Fim?

Checagem +20 XP de primeiraUm job percorre 300 notas fiscais com for nota in notas: e chama o modelo uma vez por nota para extrair o total. Não há contador de passos. É Loop Sem Fim?

Perguntas rápidas

O que é Loop Sem Fim?

Loop Sem Fim (Unbounded Loop) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Abusos de controle. O agente pode chamar ferramentas para sempre; o único limite é o cartão de crédito.

Como corrigir Loop Sem Fim?

Com Adicionar Orçamento ao Loop. Cada refatoração traz o passo a passo seguro, com eval antes e depois.

Onde Loop Sem Fim aparece na prática?

Nos cenários reais Agente de código, Migração de código legado, Agente de navegador para tarefas repetitivas e Automação de back-office com execução durável.

Para ir além

Relações

Refatorações que tratam 1
Aparece nas trilhas 1
Buscar