6 Modos de Falha de Loops de Agentes de IA Que Afetam Sistemas em Produção

Falhas Silenciosas de Ferramentas: Quando o Agente "Tem Sucesso" Sem Fazer Nada

Uma chamada de ferramenta retorna uma string vazia ou uma mensagem suave de "sem resultados", o modelo interpreta-a como um resultado válido, e o agente continua como se o passo tivesse funcionado, parecendo ter sucesso enquanto não faz absolutamente nada. A correção é uma porta de validação em cada retorno de ferramenta: verificar o esquema ou fazer uma verificação de sanidade do output antes de o modelo o ver, e expor uma falha real que o loop tenha de tratar em vez de um sucesso vazio.

Esta é insidiosa porque nada falha. Um developer que documentou modos de falha silenciosa em agentes em produção disse-o diretamente: os modelos interpretam strings vazias genéricas como no-ops válidos e continuam a executar sem consciência da falha. A query à base de dados que retornou zero linhas porque a ligação caiu parece idêntica, para o modelo, à query que legitimamente não encontrou nada. Assim o agente relata "sem registos correspondentes" e avança, e descobre uma semana depois que um terço das suas execuções estavam silenciosamente quebradas.

A porta de validação fica entre a ferramenta e o modelo:

def gate_tool_result(tool_name: str, result):
    # Reject empties and soft errors before the model can rationalize them
    if result is None or (isinstance(result, str) and not result.strip()):
        raise ToolFailure(f"{tool_name} returned empty -- treat as failure, not no-op")
    if isinstance(result, str) and result.lower().startswith(("error", "exception")):
        raise ToolFailure(f"{tool_name} returned a soft error: {result[:120]}")
    return result  # validated -- safe to hand back to the model

O ponto não são as verificações exatas; as suas dependerão do que cada ferramenta retorna legitimamente. O ponto é que um valor de retorno não validado é uma decisão que entregou a um modelo estocástico, e o movimento padrão do modelo é continuar.

Um retorno de ferramenta não validado é uma falha silenciosa à espera de acontecer. Valide o output, não confie na chamada.

Degradação do Raciocínio em Contextos Longos: Quando o Agente Piora Quanto Mais Tempo Executa

Mesmo quando se mantém abaixo do limite máximo de contexto, a qualidade do raciocínio degrada-se à medida que o contexto cresce. Este é o efeito "lost in the middle", onde o modelo atende de forma fiável ao início e ao fim de um contexto longo mas perde o meio. A correção é compressão a meio do loop que preserva as restrições fixadas: comprimir o ruído, proteger as instruções estruturais.

O mecanismo tem um nome. O blog de engenharia da Anthropic refere-o como context rot: "à medida que o número de tokens na janela de contexto aumenta, a capacidade do modelo de recordar com precisão informação desse contexto diminui." Porque "cada token atende a todos os outros tokens," obtém-se n² relações par a par para n tokens, e a atenção do modelo fica mais dispersa quanto mais longo for o contexto.

Esse qualificador, protect the load-bearing instructions, é o essencial, e há um incidente documentado que mostra porquê. Num caso documentado, um agente OpenClaw apagou em massa a caixa de entrada de um utilizador durante uma compactação de contexto, porque a instrução de segurança que lhe tinha sido dada ("não tome medidas até eu dizer") foi removida do contexto ativo quando o histórico foi comprimido. A restrição que devia ser a última a desaparecer foi tratada como histórico comum e resumida.

Portanto, um simples "sumarizar tudo mais antigo que N turnos" é perigoso. A compressão tem de saber o que nunca pode abandonar:

PINNED = {"system_constraints", "safety_instructions", "active_task_spec"}

def compress_history(messages):
    pinned = [m for m in messages if m.tag in PINNED]      # never summarized
    transient = [m for m in messages if m.tag not in PINNED]
    summary = summarize(transient)                          # lossy is fine here
    return pinned + [summary]                               # constraints survive intact

Isto é distinto do problema de overflow da secção anterior. Overflow é sobre ficar sem espaço; degradação é sobre o modelo piorar enquanto ainda há espaço. Pode estar nos 60% da janela e já estar a raciocinar mal.

Perda de Estado ao Reiniciar: Quando um Crash Significa Começar do Zero

Quando um agente de longa duração falha, seja por reinicialização, por kill por OOM ou por perda de ligação de rede, não há retoma a partir de um checkpoint por padrão. O loop começa do zero: refaz trabalho que já concluiu e, pior, pode re-executar ações que já realizou, como enviar o mesmo e-mail duas vezes ou re-executar uma chamada de API paga. A correção é o checkpointing: persistir o estado do loop após cada passo para que um reinício reidrate a partir do ponto em que parou, em vez de do início.

No LangGraph a escolha do backend de checkpoint é a escolha entre desenvolvimento e produção. A documentação de persistência do LangGraph descreve SqliteSaver como "ideal para experimentação e fluxos de trabalho locais" e PostgresSaver como "ideal para uso em produção", e o último é o que o próprio LangSmith usa. Os dois são deliberadamente paralelos no código, o que torna o contraste fácil de ver:

# Development -- single file, no server, do not ship this
from langgraph.checkpoint.sqlite import SqliteSaver

# Production -- survives the box it runs on
from langgraph.checkpoint.postgres import PostgresSaver

Dois detalhes que apanham as pessoas de surpresa. Primeiro, os pacotes de checkpoint instalam-se separadamente do LangGraph base (langgraph-checkpoint-sqlite e langgraph-checkpoint-postgres são dependências próprias), por isso uma máquina nova não terá o saver de Postgres até o adicionar. Segundo, cada operação de checkpoint precisa de um thread_id na configuração. Esse ID é o que liga uma determinada execução ao seu estado guardado, e um reinício sem o thread_id correto não reidrata nada.

Tempestades de Retry: Quando os Seus Próprios Agentes Fazem DDoS a um Serviço Inativo

Quando um serviço dependente fica inativo, retries ingénuos por execução transformam a sua frota de agentes num denial-of-service auto-infligido. A correção tem duas metades: backoff exponencial com jitter em cada agente para distribuir os retries no tempo, e um circuit breaker global que dispara após um limite de falhas partilhado e impede todo o grupo de bombardear um serviço que está claramente inativo.

A matemática é impiedosa. Como refere um artigo sobre padrões de retry , com dez agentes paralelos cada um a fazer dez retries, envia cem pedidos a um serviço que já está em baixo, porque o backoff de cada agente é por execução, não global. Backoff por agente isolado não resolve isto. Dez agentes que recuam educadamente ainda recuam em uníssono se todos começaram ao mesmo tempo, portanto fazem retry em ondas sincronizadas. Jitter quebra a sincronização ao aleatorizar a espera de cada agente; o circuit breaker quebra o grupo ao partilhar um único pedaço de estado de falha entre todos eles.

A metade do backoff é um problema resolvido em Python; a biblioteca tenacity trata do exponencial-com-jitter de forma limpa:

from tenacity import retry, stop_after_attempt, wait_random_exponential

@retry(wait=wait_random_exponential(multiplier=1, max=60), stop=stop_after_attempt(5))
def call_flaky_service(payload):
    return downstream.post(payload)

O circuit breaker é a metade que tem de ser global: partilhado entre todos os agentes, não reinstanciado por execução. Quando as falhas ultrapassam um limiar, abre, todos os agentes falham rapidamente em vez de fazer chamadas, e após um período de arrefecimento deixa passar um único pedido de sonda para testar se o serviço voltou. Um breaker que vive dentro do próprio processo de cada agente não protege nada, porque nada é partilhado; o serviço inativo recebe ainda assim a totalidade dos cem pedidos.

Backoff por execução ainda permite que dez agentes bombardeiem um serviço inativo em uníssono. O circuit breaker tem de ser global para travar o grupo.

As Seis Falhas em Resumo

Antes da parte de infraestrutura, aqui está todo o catálogo num único lugar: a falha, o mecanismo que a causa, a correção do harness, e onde o parâmetro relevante fica em cada framework.

Uma nota para leitores de CrewAI, AutoGen, Dify ou um loop Python manual: os parâmetros do framework mudam, mas os seis padrões não. Deduplicação, sumarização por intervalos, validação de esquema, compressão com consciência de restrições, checkpointing e um circuit breaker global são conceitos agnósticos de framework. Os detalhes específicos de LangGraph e n8n aqui são referências concretas, não o limite de onde os padrões se aplicam.

Dimensionar um Deployment de Agentes em Produção

Cada padrão acima assume que controla o gestor de processos, a base de dados e o comportamento de reinício. O checkpointing não serve de nada se um loop com crash nunca voltar a subir, e um circuit breaker global precisa de um lugar para guardar o seu estado partilhado. Esse controlo é exatamente o que o self-hosting lhe dá e um serviço gerido fechado não dá, por isso a última decisão é dimensionar o servidor que o executa 24/7.

Para a maioria dos deployments de agente único (um agente, chamadas LLM a uma API externa, checkpointing básico em Postgres) uma instância pequena é suficiente: cerca de 2 GB RAM, 1 vCPU, and 60 GB of NVMe storage. O processamento pesado fica no lado do fornecedor do modelo; o seu servidor está a orquestrar, fazer checkpointing e guardar estado, não a executar inferência. Suba para aproximadamente 4 GB RAM, 2 vCPU, and 120 GB NVMe quando o agente é stateful e multi-passo com checkpointing em Postgres mais Redis para hidratação de sessão, ou quando está a executar fluxos de trabalho concorrentes que partilham o host.

A razão para preferir um VPS autogerido em vez de uma plataforma restrita é a mesma razão pela qual as correções funcionam: precisam de root. O seu próprio Postgres para checkpointing, o seu próprio Redis para estado de sessão, e um gestor de processos real como systemd or pm2para que quando um loop morrer, o supervisor o reinicie e reidrate a partir do último checkpoint em vez de recomeçar o trabalho. Toda essa história de recuperação depende de ser dono do ciclo de vida do processo.

Como executamos n8n como app de um clique no nosso próprio marketplace, essa parte da configuração é o caminho mais curto pelo nosso lado: pode implementar n8n num VPS Cloudzy com a configuração suportada por Postgres que o caminho de produção necessita, numa instância onde tem acesso root para adicionar o seu próprio Redis e supervisão de processos. É o mesmo footprint self-hosted descrito acima, onde é dono da base de dados e do comportamento de reinício, o que é o que faz o checkpointing e a recuperação automática realmente funcionar.

Os padrões do harness são apenas tão fiáveis quanto o servidor em que correm. O checkpointing não serve de nada se o processo nunca reiniciar.

Perguntas frequentes