Recuperação de falhas em agentes de IA: quando retomar, desfazer ou parar

A falha de uma chamada não equivale à falha da tarefa

Um agente pode precisar consultar informações, alterar um registro e, em seguida, comunicar o resultado. Se a resposta de uma ferramenta falhar no meio desse fluxo, não basta decidir se a última chamada deve ser repetida. Talvez a ação não tenha chegado ao sistema externo; talvez tenha sido executada e apenas a confirmação tenha se perdido; ou talvez a alteração tenha sido aplicada parcialmente. Cada situação exige uma decisão diferente.

Neste guia, recuperar significa reconciliar o objetivo e o progresso registrados pelo agente com o estado verificável do ambiente e escolher uma continuação segura ou uma interrupção explícita. A unidade de análise é a tarefa composta por várias etapas, não uma solicitação isolada. Repetir uma chamada pode fazer parte da recuperação, mas não a define.

A recomendação central é simples: antes de repetir uma ação cujo resultado é desconhecido, verifique o que aconteceu fora do agente. Se não houver uma maneira confiável de verificar, não transforme a incerteza em uma segunda alteração. Limite as ações subsequentes e encaminhe o caso a uma pessoa quando o custo de errar superar o custo de esperar.

Mapa de falhas: primeiro, classifique o que você sabe

Um erro explícito nem sempre prova que o sistema externo permaneceu intacto. Da mesma forma, um timeout apenas indica que o agente não recebeu uma resposta a tempo; por si só, não demonstra se a operação foi concluída. Por isso, classifique o episódio de acordo com as evidências disponíveis, não com o rótulo de erro que o agente recebeu.

Diferencie cinco situações. Em uma falha confirmada, a resposta permite concluir que a ação não foi executada. Em um resultado ambíguo, a solicitação pode ter chegado, mas não há confirmação confiável. Em uma resposta inválida, há uma resposta, mas seu formato ou conteúdo não permite usá-la com segurança. Em um estado externo inesperado, o sistema informa algo que não corresponde à suposição do plano. Em uma interrupção entre etapas, a tarefa parou depois de um ou mais efeitos confirmados, mas antes de o fluxo ser concluído.

Essas categorias orientam a próxima verificação, mas não determinam uma resposta automática. Se a falha estiver confirmada e for seguro repetir a operação, pode fazer sentido tentar novamente. Se o resultado for ambíguo, procure primeiro evidências no sistema afetado. Se a resposta for inválida ou o estado observado contrariar o plano, suspenda as ações dependentes até esclarecer a discrepância.

Antes de continuar: preserve o necessário para reconstruir a tarefa

Um checkpoint ou ponto de controle é útil quando permite reconstituir o que o agente pretendia fazer e o que sabe sobre cada etapa. Não é necessário guardar todo o raciocínio ou todos os dados disponíveis. Convém preservar o mínimo necessário para a operação: identificador da tarefa, objetivo, restrições relevantes, sequência das etapas, ferramenta e operação solicitadas, parâmetros necessários para identificar a operação, resultado recebido, estado da confirmação e última observação do ambiente.

Registre cada etapa com uma condição explícita, por exemplo: pendente, solicitada, confirmada, falha com evidências ou resultado desconhecido. Evite condensar esses estados em uma única anotação como “ação concluída”, pois isso pode apagar a diferença entre intenção e confirmação. Se o sistema externo oferecer uma forma de consultar o objeto alterado, preserve a chave necessária para localizá-lo e anote quando ele foi observado pela última vez.

O checkpoint não prova que o mundo externo continua igual. Ele é um instantâneo do que o processo salvou; entre a interrupção e a retomada, outra pessoa ou sistema pode ter alterado o registro. Ao restaurá-lo, valide novamente as condições necessárias antes de fazer novas alterações. A documentação da Microsoft sobre checkpoints de workflows trata do armazenamento e da restauração de checkpoints; em uma implementação específica, a equipe deve verificar qual estado é preservado e como ele é reidratado.

O projeto também deve preservar os limites da tarefa: qual resultado conta como sucesso, quais operações não devem ser repetidas e quais condições exigem escalonamento. Sem esses limites, um agente pode reconstruir as etapas técnicas e, ainda assim, continuar em uma direção que deixou de ser segura.

Árvore de decisão: retomar, verificar, reformular, compensar ou parar

A decisão pode ser expressa como um processo breve. Primeiro, identifique a última etapa confirmada e a primeira que ficou incerta. Em seguida, pergunte se existe uma consulta confiável que revele o estado externo. Se sim, consulte antes de agir. Se não, avalie o impacto potencial de repetir a ação e se há uma maneira segura de resolver a ambiguidade. Se também não houver essa possibilidade, pare e solicite intervenção humana.

Retomar significa continuar a partir de um ponto conhecido, sem executar novamente etapas já confirmadas. É apropriado quando o estado salvo é suficiente, as condições relevantes continuam válidas e as etapas pendentes são seguras. Verificar significa consultar o ambiente para descobrir o que aconteceu, não enviar novamente a mesma ordem. Reformular significa mudar o plano porque o estado atual já não atende às suas suposições. Compensar significa executar uma ação diferente para contrabalançar um efeito anterior. Parar significa não fazer mais alterações até obter uma decisão ou evidências suficientes.

O guia da AWS sobre checkpoints para sistemas de agentes alerta que retomar sem garantias de idempotência pode duplicar efeitos ou corromper dados. Esse alerta reforça uma distinção prática: salvar o estado de execução ajuda a reconstruir o fluxo, mas não torna automaticamente segura a repetição de uma operação.

Efeitos parciais: desfazer nem sempre significa voltar ao estado anterior

Em uma tarefa composta, algumas etapas podem ter sido concluídas antes de a seguinte falhar. Se o agente atualizar um registro e depois não conseguir enviar uma notificação, repetir o fluxo inteiro pode aplicar a alteração novamente, criar registros duplicados ou enviar mensagens repetidas. A recuperação deve partir dos efeitos confirmados e decidir separadamente o que fazer com cada um.

Quando uma operação for reversível, identifique com antecedência o que significa revertê-la e como verificar se a reversão teve efeito. Não presuma que “desfazer” apaga todos os rastros nem que o sistema oferece um retorno exato ao estado anterior. Em alguns processos, a resposta apropriada é uma ação compensatória: por exemplo, corrigir um registro por meio de uma nova operação, em vez de apagar o histórico da operação. Essa compensação também pode falhar e, por isso, exige confirmação e limites próprios.

O padrão saga, descrito pela AWS para fluxos com várias etapas, diferencia a recuperação para a frente — continuar ou tentar novamente — da recuperação para trás, por meio de transações compensatórias. É uma referência útil para estruturar processos distribuídos, mas não significa que todo efeito de um agente tenha uma compensação disponível ou segura. A escolha depende das regras do sistema e do impacto da ação.

Se uma ação não puder ser revertida de modo confiável, o agente deve tratá-la como um limite de risco. Ele pode registrar o efeito, impedir etapas adicionais que o agravem e solicitar uma revisão. Não deve improvisar uma compensação que não esteja definida para aquele caso.

Limites e escalonamento: sinais para parar o agente

Uma política de recuperação precisa de condições explícitas para parar. Entre os sinais práticos estão: não conseguir consultar o estado que determina se uma ação ocorreu; observar alterações incompatíveis com o plano; receber respostas inválidas repetidamente; acumular tentativas sem progresso confirmado; exceder o impacto ou o escopo autorizado; ou não dispor de uma compensação confiável para um efeito indesejado. Esses sinais são critérios de projeto propostos, não garantias automáticas de segurança.

Defina também quem receberá o caso, de quais informações essa pessoa precisa e quais ações poderá autorizar. Um escalonamento útil deve incluir o objetivo da tarefa, as etapas confirmadas, o ponto incerto, as verificações realizadas, os efeitos externos observados e a opção que o agente teria escolhido. Evite apresentar como fato uma causa que não foi possível determinar.

Parar não precisa significar abandonar a tarefa sem aviso. O agente pode preservar o checkpoint, marcar a tarefa como bloqueada e comunicar claramente o que falta verificar. Se a interface oferecer uma ação de retomada, ela deverá verificar novamente as condições relevantes, em vez de presumir que o ambiente continua no mesmo estado.

Teste a recuperação com interrupções controladas

Não basta testar o fluxo ideal nem verificar se o processo consegue restaurar um checkpoint. Simule interrupções em diferentes pontos: antes de enviar uma operação, depois de enviá-la mas antes de receber uma resposta, depois de confirmar um efeito e antes da etapa seguinte, e depois de observar uma alteração inesperada. Acrescente respostas atrasadas, inválidas ou repetidas se elas puderem ocorrer no ambiente avaliado.

Para cada cenário, defina antecipadamente o comportamento esperado: o que deve ser preservado, qual consulta deve ser feita, quando é seguro retomar e qual condição exige escalonamento. Depois, compare o resultado real com esse critério. A avaliação deve incluir erros por excesso de iniciativa — por exemplo, uma duplicata — e por cautela excessiva — por exemplo, uma tarefa interrompida que poderia ser retomada com segurança.

Como medidas de acompanhamento, considere a proporção de tarefas concluídas corretamente, os efeitos duplicados, os estados inconsistentes, as tarefas bloqueadas, o tempo até resolver uma ambiguidade e a proporção de escalonamentos adequados. Interprete as métricas junto com a gravidade de cada caso: uma taxa baixa de duplicatas não prova que uma operação irreversível seja segura.

Use os resultados para ajustar checkpoints, consultas de verificação, limites de novas tentativas e condições de parada. Mantenha separados os erros do agente, da ferramenta e do sistema externo quando as evidências permitirem essa distinção; quando não permitirem, registre a causa como indeterminada em vez de forçar uma atribuição.

O que este guia não resolve

Este guia trata da recuperação de uma tarefa de agente que atravessa várias etapas e pode alterar sistemas externos. Ele não substitui o projeto de novas tentativas de uma API, as garantias de idempotência de uma solicitação específica nem a recuperação da infraestrutura. Esses temas continuam importantes: um protocolo de tarefa pode se apoiar neles, mas não deve presumir garantias que não estejam documentadas.

Neste contexto, a idempotência é uma propriedade que precisa ser verificada para a operação específica antes de se presumir que repeti-la é seguro; não basta classificar a tarefa inteira como idempotente. Da mesma forma, um checkpoint permite preservar e restaurar informações do workflow, mas não confirma, por si só, que o sistema externo aplicou uma alteração. A tese sobre arquitetura multiagente tolerante a falhas é uma referência de escopo diferente: estuda o controle de um robô móvel e não constitui uma receita direta para agentes conectados a serviços empresariais.

Como critério prático final, pergunte nesta ordem: o que está confirmado? O que pode ser verificado fora do agente? Quais efeitos já ocorreram? Quais etapas continuam válidas? Existe uma compensação segura? Que condição exige parar? Se uma resposta essencial for desconhecida e agir puder piorar o resultado, preserve o estado, pare e encaminhe o caso.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.