Um agente de IA pode parecer ocupado enquanto repete a mesma ferramenta, volta para o mesmo subagente ou recebe o mesmo erro em cada rodada. O problema não é apenas o custo da API. O loop também aumenta o contexto, atrasa a resposta e torna difícil saber se a tarefa terminou ou apenas parou de caber no orçamento.

A correção é tratar a parada como parte do runtime. Combine uma condição de conclusão, um limite de passos, um orçamento de tempo ou tokens e um sinal de progresso. Quando uma dessas barreiras encerra o run, grave um motivo terminal que outra execução possa entender. O modelo pode sugerir que terminou, mas o código precisa conferir a condição.

Este texto mostra a política em TypeScript, sem chamar um provedor real. O trecho é ilustrativo e usa adapters abstratos. A implementação de produção precisa conectar os limites ao SDK, às ferramentas e ao armazenamento do seu sistema.

Diagrama mostra um loop de agente de IA passando por ferramenta, progresso e orçamento antes de parar.

Resposta curta

  • Pare por conclusão válida, por falta de progresso, por orçamento esgotado ou por erro que não pode ser recuperado.
  • Um limite de passos impede o loop infinito, mas não identifica repetição nem garante que a resposta esteja correta.
  • Conte passos do run e chamadas por ferramenta. Compartilhe o mesmo deadline e orçamento entre tentativas.
  • Registre completed, budget_exceeded, no_progress ou failed como estados diferentes.

O que caracteriza um loop infinito em um agente?

Em 2026, o estudo "When Agents Do Not Stop" analisou 6.549 repositórios de agentes e confirmou 68 falhas de loop infinito em 47 projetos, com precisão manual de 91,9% para os achados reportados (arXiv, "When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents", 2026). O resultado não diz que toda execução longa é defeituosa. Ele mostra por que o caminho de retorno também precisa de um limite verificável.

Uma execução longa pode estar fazendo progresso. Um agente que consulta páginas novas, espera uma operação ou corrige um teste pode precisar de várias rodadas. O loop fica suspeito quando o estado não muda, o resultado não acrescenta evidência ou a mesma transição volta a acontecer sem uma nova decisão.

Observe três sinais juntos:

  1. A ferramenta recebe o mesmo nome e argumentos, ou argumentos diferentes que produzem o mesmo estado.
  2. O histórico cresce, mas a tarefa continua sem um critério verificável de conclusão.
  3. O runtime repete a operação depois de um erro sem mudar contexto, política ou recurso consultado.

Um teste de repetição não deve bloquear todo polling. Consultar o status de um job pode ser correto quando o estado externo ainda está running. A pergunta é se cada consulta pode mudar a decisão do próximo passo. Se a resposta for não, o run precisa parar ou pedir intervenção.

Por que um limite de passos sozinho não basta?

Em 2026, o OpenAI Agents SDK documenta maxTurns com padrão de 10 e lança MaxTurnsExceededError quando o limite é alcançado (OpenAI Agents SDK, "Running Agents", consultado em 2026-08-28). No mesmo período, a documentação do AI SDK descreve stopWhen e stepCountIs, com 20 passos como padrão no ToolLoopAgent (Vercel AI SDK, "Agents: Loop Control", consultado em 2026-08-28). Esses números são defaults de bibliotecas, não recomendações universais.

O limite duro é a última cerca. Ele protege contra uma condição de conclusão que nunca fica verdadeira, mas pode cortar uma tarefa que ainda avançava. Ele também não impede uma ferramenta cara de ser chamada várias vezes dentro de uma rodada, nem distingue progresso real de uma nova resposta com o mesmo conteúdo.

Separe pelo menos estes orçamentos:

  • Passos do run: quantas decisões do agente podem acontecer.
  • Chamadas por ferramenta: quantas vezes uma ferramenta específica pode ser executada na mesma tarefa.
  • Tempo restante: quanto do deadline compartilhado ainda existe.
  • Tokens ou custo: quanto pode ser gasto antes de uma nova chamada.

O orçamento deve ser consumido pela execução inteira. Se cada retry cria um contador novo, o agente pode respeitar todos os limites locais e ainda exceder o limite global. O resultado do limite também precisa ser explícito. failed é diferente de budget_exceeded, que é diferente de completed.

Quais condições devem encerrar o loop?

Em 2026, o guia de arquitetura de agentes da Google Cloud descreve duas formas de saída para um padrão de loop: um número máximo de iterações ou um estado personalizado; a mesma documentação alerta que uma condição mal definida pode deixar o loop infinito (Google Cloud, "Choose a design pattern for your agentic AI system", consultado em 2026-08-28). Use as duas camadas juntas.

Uma política pequena pode avaliar as condições nesta ordem:

  1. Conclusão: a resposta contém o resultado esperado e passou na validação da aplicação?
  2. Segurança: a próxima chamada é permitida para esta fase e este recurso?
  3. Progresso: o estado, a evidência ou a decisão mudou desde a última volta?
  4. Orçamento: ainda há passos, tempo, tokens e chamadas de ferramenta?

Se a conclusão for válida, termine com sucesso. Se o estado não avançar, grave no_progress e guarde a última evidência. Se o orçamento acabar, grave budget_exceeded sem transformar um resultado parcial em resposta final. Se a próxima ação violar a política, encerre com blocked.

O modelo pode devolver uma palavra como DONE, mas isso é um sinal de entrada, não uma prova. Valide o formato, a presença dos campos obrigatórios e o efeito que a tarefa deveria ter produzido. Para uma arquitetura com fases e transições mais explícitas, use a máquina de estados para agentes de IA.

Como detectar falta de progresso sem quebrar polling?

Em 2026, o Microsoft Agent Framework documenta um predicado de continuação que pode retornar continuar, parar ou enviar feedback para a próxima iteração, mas mantém max_iterations como limite independente (Microsoft Learn, "Agent looping", consultado em 2026-08-28). A separação é útil: o predicado observa progresso, enquanto o limite protege o processo quando a observação falha.

Comece com uma impressão simples do estado que o runtime controla. Inclua o nome da ferramenta, argumentos normalizados, identificador do recurso, versão do estado e uma pequena assinatura do resultado. Não inclua segredo nem todo o conteúdo de uma resposta apenas para criar um hash.

type StopReason =
  | "completed"
  | "no_progress"
  | "budget_exceeded"
  | "blocked"
  | "failed";

type RunState = {
  step: number;
  lastFingerprint?: string;
  repeatedSteps: number;
  reason?: StopReason;
};

function shouldStop(
  state: RunState,
  nextFingerprint: string,
  maxSteps: number,
): StopReason | undefined {
  if (state.step + 1 >= maxSteps) return "budget_exceeded";
  if (state.lastFingerprint === nextFingerprint && state.repeatedSteps >= 1) {
    return "no_progress";
  }
  return undefined;
}

Esse trecho é ilustrativo. Ele não conhece o significado do recurso externo e não prova que duas respostas semanticamente iguais são inúteis. Em produção, combine a assinatura com uma regra por ferramenta. Um pollJob pode permitir repetição enquanto o status muda. Um sendMessage deve parar depois da primeira intenção aceita, mesmo que a confirmação demore.

Não use um juiz de linguagem como única condição. Um avaliador pode aprovar a mesma resposta duas vezes ou pedir refinamento indefinidamente. Use-o para avaliar qualidade dentro de um limite que o runtime controla.

Como separar conclusão, retry e parada?

Em 2026, o SDK do Claude Code descreve o loop como a repetição entre resposta do modelo e execução de ferramentas até surgir uma resposta sem novas chamadas (Anthropic, "How the agent loop works", consultado em 2026-08-28). Essa regra encerra o ciclo, mas não substitui uma política da aplicação para resposta incompleta, erro de ferramenta ou falta de progresso.

Modele a decisão fora do prompt. Um adapter pode devolver uma destas saídas:

type Decision =
  | { kind: "continue"; fingerprint: string }
  | { kind: "complete"; output: string }
  | { kind: "stop"; reason: StopReason; detail: string };

async function runBoundedAgent(input: string): Promise<Decision> {
  const state: RunState = { step: 0, repeatedSteps: 0 };

  while (true) {
    const attempt = await modelAndTools(input, state);
    const decision = classifyAttempt(attempt, state);

    if (decision.kind !== "continue") return decision;

    const reason = shouldStop(state, decision.fingerprint, 8);
    if (reason) {
      return { kind: "stop", reason, detail: "termination policy reached" };
    }

    state.repeatedSteps = state.lastFingerprint === decision.fingerprint
      ? state.repeatedSteps + 1
      : 0;
    state.lastFingerprint = decision.fingerprint;
    state.step += 1;
  }
}

O exemplo é ilustrativo e não foi executado contra um provedor. A função classifyAttempt deve distinguir uma resposta final válida, uma tool call que pode continuar, uma falha retryable e uma falha que exige parada. O valor 8 é um exemplo de política local, não um limite recomendado.

Retry é adequado quando uma nova tentativa ainda pode produzir informação ou resultado sem repetir um efeito externo. Parada é adequada quando o estado é ambíguo, o erro é permanente, a capacidade da ferramenta não está disponível ou a tarefa já não tem orçamento. A política fica mais segura quando o agente recebe o motivo, não apenas a mensagem genérica try again.

Como registrar o estado terminal e recuperar o run?

Em 2026, a documentação do OpenAI Agents SDK informa que uma execução pode carregar RunState e que uma falha de maxTurns pode ser tratada por um handler específico, sem repetir automaticamente efeitos de ferramentas (OpenAI Agents SDK, "Running Agents", consultado em 2026-08-28). O princípio é separar o resultado parcial da autorização para retomar.

Grave, no mínimo:

  • runId e parentRunId, quando houver handoff;
  • contador de passos e chamadas por ferramenta;
  • orçamento restante e deadline;
  • último estado conhecido e sua versão;
  • motivo terminal e a evidência que o produziu;
  • referências de efeitos externos que precisam de reconciliação.

Uma execução interrompida por no_progress pode ser retomada depois de uma mudança de contexto. Uma execução blocked pode precisar de aprovação. Uma execução budget_exceeded pode exigir uma tarefa menor. Nenhuma delas deve voltar automaticamente ao primeiro passo sem carregar o motivo anterior.

Para manter o custo de contexto sob controle, resumo e estado persistido devem ser tratados como partes diferentes. O resumo ajuda a próxima decisão. O estado terminal diz por que a decisão parou. A execução durável para agentes de IA aprofundará checkpoints e retomada; aqui, o limite é a política de encerramento.

Quando o loop atravessa várias sessões, uso o RemoteCode como minha ferramenta para manter o contexto operacional e as decisões de agentes visíveis. Essa é uma descrição do meu uso, não um resultado medido deste artigo.

Como testar se o agente realmente para?

Em 2026, o OpenAI Agents SDK documenta test doubles determinísticos para exercitar workflows multi-turn sem fazer chamadas ao modelo ou ao provedor de sandbox (OpenAI Agents SDK, "Testing", consultado em 2026-08-28). Mesmo sem essa biblioteca, use fakes para provar a política antes de ligar o agente a serviços externos.

Teste pelo menos estes caminhos:

Cenário Resultado esperado
O modelo devolve uma resposta final válida completed, sem nova tool call
A mesma ferramenta retorna o mesmo estado duas vezes no_progress ou uma regra específica de polling
O contador global chega ao limite budget_exceeded, com o último estado preservado
Uma ferramenta pede permissão fora da fase atual blocked, sem executar o efeito
O modelo retorna erro retryable dentro do prazo nova tentativa dentro do orçamento
Uma tool inicia efeito e a resposta some estado ambíguo, reconciliação antes de repetir

Verifique também o que não deve acontecer. O agente não pode transformar budget_exceeded em completed, reiniciar o contador ao trocar de provedor, zerar o histórico ao fazer handoff ou confundir um resultado parcial com a resposta final.

O teste de trajetória de um agente de IA ajuda a verificar a sequência completa. Este artigo adiciona a pergunta de parada: qual evidência fez o runtime encerrar e o próximo run consegue entender esse motivo?

Perguntas frequentes

Qual é um limite seguro de iterações para um agente de IA?

Não existe um valor universal. O OpenAI Agents SDK usa maxTurns: 10 como padrão e o AI SDK documenta 20 passos como padrão para seu ToolLoopAgent, mas esses valores refletem bibliotecas diferentes (OpenAI Agents SDK, "Running Agents"; Vercel AI SDK, "Agents: Loop Control", consultados em 2026-08-28). Meça a tarefa e mantenha um limite global.

Detectar a mesma tool call evita todo loop infinito?

Não. Uma ferramenta pode receber argumentos diferentes e produzir o mesmo estado, ou alternar entre duas chamadas. Combine fingerprint com progresso, tempo, custo e uma condição de conclusão. Para polling legítimo, permita repetição enquanto o estado externo muda e defina um deadline independente.

O que fazer quando o limite termina antes da resposta?

Registre budget_exceeded com o último estado conhecido, o motivo e as evidências disponíveis. Não apresente o resultado parcial como sucesso. Se a tarefa puder continuar, crie uma nova execução com contexto resumido; se houver efeito externo ambíguo, consulte o estado antes de repetir.

Conclusão

Um loop de agente fica seguro quando parar é uma decisão do sistema, não um pedido escondido no prompt. Use conclusão validada, limite de passos, orçamento compartilhado e detecção de falta de progresso. Essas barreiras têm funções diferentes. Juntas, elas evitam que uma tarefa sem saída pareça autonomia.

O agente ainda pode falhar. Isso é melhor do que continuar sem saber por quê. Grave o motivo terminal, preserve o estado e faça o próximo passo ser retry, reconciliação, aprovação ou uma nova execução menor.

Nota de produção

Samuel Fajreldines é o responsável editorial por este texto. A pesquisa usou documentação pública do OpenAI Agents SDK, AI SDK, Microsoft Agent Framework, Claude Code, LangChain, Google Cloud e um artigo técnico no arXiv, além de discussões públicas de praticantes. A assistência de IA ajudou na descoberta, comparação, primeira redação, tradução e revisão; o código é ilustrativo e não houve benchmark com provedor real, teste em cliente ou métrica própria.

Fontes consultadas