Práticas recomendadas de orquestração de agentes de IA: como lidar com falhas, aprovações e novas tentativas

Ter vários agentes trabalhando no mesmo projeto parece extremamente eficiente. Um planeja o trabalho, outro cuida do design e um terceiro escreve o código. Funciona até deixar de funcionar. E as falhas acontecem com mais frequência do que você gostaria.

Evitar essas falhas exige uma engenharia cuidadosa de fluxos de trabalho. Então, vamos analisar o que torna os fluxos de trabalho orquestrados pouco confiáveis e explorar as práticas recomendadas de orquestração para garantir confiabilidade em produção.

O que é orquestração de agentes de IA?

A orquestração de agentes de IA coordena vários agentes, modelos e ferramentas de IA para concluir uma tarefa de várias etapas. Mas alguém — ou algo — ainda precisa decidir qual agente é executado primeiro, que informações ele recebe e o que acontece depois que ele termina. Esse é o papel do orquestrador — um agente de IA que atua como gerente ou uma camada de execução controlada por software.

Em termos simples, uma camada de orquestração divide um objetivo em tarefas menores, acompanha dependências, delega a execução aos agentes certos, gerencia o contexto compartilhado e reúne os resultados.

Como funciona a orquestração de agentes de IA: por dentro do mecanismo de execução

Expandir

Vamos ver o que acontece depois que você dá uma tarefa a um orquestrador.

Considere um exemplo do workshop do Computer da Perplexity: a criação de um painel de inteligência de contas com informações do Salesforce, do Snowflake, de e-mail, do calendário e de notícias recentes.

1. Entender o objetivo e planejar o trabalho. O orquestrador começa pelo resultado solicitado e o decompõe em tarefas com dependências explícitas. No nosso exemplo do painel, isso envolve coletar informações de diferentes fontes e transformá-las em um entregável finalizado. O planejador estabelece quais etapas dependem de outras e quais podem ser executadas de forma independente.
2. Encaminhar as tarefas para os agentes adequados. O orquestrador identifica as tarefas cujas dependências foram atendidas e delega o trabalho a agentes ou modelos especializados. As tarefas dependentes aguardam seus pré-requisitos. O Perplexity Computer usa vários modelos de fronteira, encaminhando diferentes partes do fluxo de trabalho para sistemas adequados a essas tarefas. Isso também permite que trabalhos independentes sejam executados em paralelo.
3. Executar chamadas de ferramentas em ambientes controlados. Os agentes interagem com o ambiente por meio de ferramentas, como pesquisa na web, APIs, aplicativos conectados, operações com arquivos ou execução de código. A camada de execução realiza essas ações e retorna os resultados aos agentes.
4. Passar resultados e contexto entre agentes. Quando um agente termina sua tarefa, o próximo agente na sequência precisa do resultado relevante para continuar. Um registro de transferência pode conter um ID de tarefa, uma referência ao resultado, a versão do esquema e metadados de origem. O orquestrador coordena essas transferências enquanto mantém o contexto necessário para as etapas seguintes. É importante ressaltar que os agentes não precisam carregar todo o histórico do trabalho de todos os outros agentes em suas próprias janelas de contexto.
5. Registrar o estado de execução separadamente do contexto dos agentes. À medida que os agentes iniciam, concluem ou falham em tarefas, o mecanismo de execução atualiza um registro persistente do fluxo de trabalho com os status das tarefas, as tentativas de execução, as referências aos resultados e o trabalho restante. Esse registro permite que o orquestrador acompanhe o progresso e retome após interrupções sem depender de um LLM para reconstruir o fluxo de trabalho a partir do histórico da conversa.
6. Validar os resultados e decidir o que acontece em seguida. Quando uma tarefa retorna, a camada de orquestração verifica se o resultado atende ao contrato esperado e se as dependências da próxima tarefa foram satisfeitas. Se um problema for encontrado, o fluxo de trabalho pode voltar a uma etapa anterior para correção ou ser pausado. Caso contrário, ele avança até a conclusão.

Há muitas peças em movimento por trás do que parece ser uma simples orquestração de agentes de IA. A forma como você organiza a coordenação dos agentes determina quanto controle você tem sobre a execução. E, claro, toda essa coordenação gera sobrecarga. Por isso, nem sempre vale a pena.

Quando usar a orquestração de agentes de IA?

Considere a orquestração multiagente quando diferentes partes da tarefa exigirem conhecimentos distintos, quando trabalhos independentes puderem ser executados em paralelo ou quando não for possível determinar a próxima etapa com antecedência.

Portanto, a orquestração é útil em três cenários:

• As tarefas exigem especializações diferentes. Um projeto de programação, por exemplo, pode se beneficiar de agentes separados para planejamento, design, desenvolvimento e revisão.
• Tarefas independentes podem ser executadas em paralelo. Em vez de um único agente concluir tudo sequencialmente, vários agentes podem trabalhar simultaneamente e retornar seus resultados a um orquestrador.
• O problema é aberto. Os agentes podem precisar explorar abordagens diferentes, tomar decisões e colaborar em vez de seguir uma sequência predefinida.

Fora isso, a orquestração é apenas uma tendência cara. Mais agentes também significam mais coordenação e custos de tokens potencialmente mais altos.

“Costumo começar pela opção mais simples e evoluir a partir daí. Se conhecemos as etapas e elas são repetíveis, provavelmente é um fluxo de trabalho. Só vejo motivo para introduzir vários agentes quando eles têm responsabilidades, permissões ou usuários diferentes”, afirma Josh Spilker, líder de marketing de busca da AirOps.

Mesmo assim, pondere os benefícios em relação às chamadas adicionais de modelo, às transferências, à latência e aos pontos de falha.

Arquiteturas de orquestração de agentes de IA e suas contrapartidas

Há três formas comuns de estruturar a coordenação de agentes: orquestração centralizada, descentralizada e hierárquica. A escolha da arquitetura certa se resume a uma pergunta: quem controla o trabalho e como os agentes se coordenam entre si?

Orquestração centralizada

Na orquestração centralizada, um único orquestrador gerencia o processo. Ele divide a tarefa, delega o trabalho a agentes especialistas, acompanha o progresso deles e reúne seus resultados.

Expandir

A contrapartida: A coordenação centralizada facilita o acompanhamento da execução e a aplicação de regras comuns em um único ponto de controle. No entanto, o orquestrador pode se tornar um gargalo, e uma falha nele pode interromper todo o fluxo de trabalho, a menos que o sistema ofereça suporte à recuperação.

Orquestração descentralizada

Na orquestração descentralizada, os agentes se coordenam de forma mais direta, em vez de depender de um único gerente para tomar todas as decisões. Eles podem trocar mensagens, ler o estado compartilhado e determinar de forma independente suas próximas etapas.

Expandir

A contrapartida: Os agentes podem operar sem esperar por um planejador central, o que torna essa abordagem útil para trabalhos exploratórios e contribuições independentes. Mas a coordenação fica mais difícil quando os agentes discordam, atualizam informações compartilhadas ou precisam chegar a um resultado consistente.

Orquestração hierárquica

A orquestração hierárquica estende a abordagem do gerente a vários níveis. Um orquestrador de nível superior delega responsabilidades a orquestradores subordinados, que coordenam seus próprios grupos de agentes especialistas.

Pense em um fluxo de trabalho corporativo que envolva as equipes de vendas, finanças e jurídico. Um orquestrador de nível superior poderia delegar cada frente de trabalho a um coordenador específico do domínio. Esses coordenadores, então, gerenciariam seus próprios agentes especialistas e reportariam resultados consolidados.

Essa estrutura pode ajudar quando os fluxos de trabalho são amplos demais para que um único orquestrador os gerencie com eficácia.

Expandir

A contrapartida: As hierarquias permitem que as equipes dividam as responsabilidades de coordenação e, potencialmente, tratem falhas dentro de ramificações individuais. No entanto, elas introduzem transferências adicionais, um gerenciamento de estado mais complexo e uma sobrecarga operacional maior. A recuperação local também depende de como os checkpoints e o estado de execução são implementados.

Como essas arquiteturas se comparam:

Execução sequencial, paralela e baseada em transferências

Há mais uma distinção que vale a pena entender. A arquitetura determina quem coordena os agentes. O padrão de execução determina como as tarefas deles avançam.

Estes são três padrões de execução:

• Fluxos de trabalho sequenciais: Os agentes trabalham em uma ordem predefinida, e o resultado de um agente se torna a entrada de outro.
• Execução paralela: Agentes independentes trabalham simultaneamente.
• Execução baseada em transferências: O controle passa entre agentes especialistas à medida que a tarefa avança. Isso é útil quando outro agente está mais bem preparado para lidar com a próxima etapa, embora cada transferência precise preservar as informações necessárias para continuar.

Os padrões não são mutuamente exclusivos e não correspondem um a um às arquiteturas de orquestração. O objetivo é escolher a estrutura mais simples que atenda às dependências do seu fluxo de trabalho, aos requisitos de coordenação e a uma sobrecarga operacional aceitável.

Falhas comuns na orquestração de agentes de IA

Tudo pode dar errado na orquestração, de simples descuidos a bloqueios complexos. Às vezes, um agente pode até parecer fazer seu trabalho corretamente enquanto o fluxo de trabalho como um todo falha. Com base na experiência de profissionais da área, reunimos alguns dos erros comuns por trás de fluxos de trabalho orquestrados pouco confiáveis — fique atento a eles:

• Transferências entre agentes com perda de informações. Um orquestrador passa um plano resumido a um agente especialista, mas o resumo omite restrições, dependências ou detalhes de implementação.
• Execução de fan-in prematura. Um agente posterior começa a agregar resultados antes que todas as tarefas anteriores tenham terminado.
• Atualizações não determinísticas de estado compartilhado. Agentes paralelos gravam nas mesmas chaves de estado sem uma semântica de mesclagem bem definida. Dependendo de como o framework lida com as atualizações, isso pode resultar em gravações perdidas, dados duplicados, saídas dependentes da ordem ou alterações conflitantes.
• Divergência entre checkpoint e efeitos colaterais. Uma tarefa executa uma operação externa, mas a execução bem-sucedida não é registrada de forma durável antes de o worker falhar. Na recuperação, o orquestrador vê uma tarefa inacabada e a executa novamente.
• Condições de corrida ao retomar após aprovação humana. Pausar e retomar a execução introduz seus próprios problemas de sincronização.
• Loops de delegação e amplificação de novas tentativas. Os agentes repassam o trabalho uns aos outros repetidamente porque suas responsabilidades se sobrepõem, as dependências são circulares ou as condições de conclusão são ambíguas.
• Controles no nível de instruções confundidos com segurança de execução. Um orquestrador pode instruir os agentes a não acessar determinados recursos nem executar ações sensíveis, mas as instruções do modelo não impõem permissões do sistema operacional, restrições de rede nem limites de autorização. A pesquisa de engenharia de segurança da Perplexity destaca por que os agentes podem ultrapassar limites de segurança enquanto buscam objetivos legítimos, mesmo sem instruções maliciosas

Observe como essas falhas são diferentes. Uma transição prematura do agendador ou uma gravação externa ambígua podem produzir um resultado incorreto, mas elas se originam em partes diferentes do ciclo de vida da execução. É por isso que uma orquestração confiável exige mais do que melhorar prompts ou adicionar novas tentativas.

7 práticas recomendadas de orquestração de agentes de IA para confiabilidade em produção

1. Defina contratos de tarefa explícitos, critérios de aceitação e condições de parada

Objetivos vagos e uma definição de concluído pouco clara costumam levar a resultados decepcionantes gerados por agentes. A solução é um contrato de prompt (um escopo de trabalho para um agente): estabeleça em comum acordo o objetivo, as restrições, o formato de saída e as condições de falha antes de a execução começar.

Por exemplo, veja como você poderia definir um contrato para um agente responsável por corrigir um teste de integração que falha de forma intermitente:

• Objetivo: Identificar e corrigir a causa de um teste de integração instável da API de checkout.
• Entradas: Código-fonte do teste, logs de falha de CI, commits recentes e código relevante da aplicação.
• Restrições: Não desativar testes, afrouxar asserções nem modificar comportamentos não relacionados da aplicação.
• Saída esperada: Um patch de código, a explicação da causa raiz e os resultados da execução dos testes.
• Critérios de aceitação: O teste que falhava passa em 10 execuções consecutivas, e o conjunto de testes de regressão relevante é aprovado.
• Condições de falha: Não é possível determinar a causa raiz, a correção introduz regressões ou o ambiente de teste necessário está indisponível.

Mas há outra parte importante: quando o agente deve parar?

Um agente não deve continuar iterando indefinidamente só porque ainda não produziu um resultado satisfatório. Defina o que constitui uma conclusão bem-sucedida, quando retornar uma tarefa parcialmente concluída e quando parar porque um requisito não pode ser atendido. Defina uma profundidade máxima de delegação e limites de iteração ou orçamentos de execução para que tarefas não resolvidas não se tornem loops infinitos.

Voltando ao nosso exemplo de CI. Você poderia definir as seguintes condições de parada:

• Sucesso: A correção passa em 10 execuções de teste consecutivas e no conjunto de testes de regressão relevante.
• Limite de iterações: O agente pode tentar no máximo duas correções candidatas.
• Orçamento de execução: O agente deve parar após 60 minutos, mesmo que o problema continue sem solução.
• Limite de delegação: O agente pode delegar trabalho a um agente especialista, sem nenhuma outra delegação a subagentes.
• Conclusão parcial: Se as duas tentativas falharem ou o tempo limite se esgotar, o agente retorna suas descobertas, as alterações tentadas e os resultados dos testes.
• Execução bloqueada: Se o ambiente de teste estiver indisponível, o agente para e relata o bloqueio em vez de alegar sucesso.

2. Mantenha os orquestradores enxutos e imponha transferências estruturadas

Às vezes, os desenvolvedores atribuem responsabilidades demais a um orquestrador e, em vez de coordenar agentes especialistas, ele começa a escrever código, depurar ou fazer revisões detalhadas por conta própria. Isso cria um gargalo: o orquestrador gasta seu orçamento de contexto com detalhes de implementação, atrasa a delegação e torna difusa a responsabilidade pelos resultados.

Então, deixe os orquestradores fazerem seu trabalho e imponha transferências que façam referência a artefatos concretos: a tarefa original, as entradas relevantes, os artefatos de saída, o status da execução e quaisquer problemas não resolvidos.

Considere este exemplo: status: completed refere-se ao trabalho atribuído ao agente, não ao fluxo de trabalho inteiro. Como os testes ainda estão pending, o orquestrador não deve aprovar o resultado final.

3. Persista o estado do fluxo de trabalho e controle o crescimento do contexto

O histórico de conversa de um agente não é um registro confiável do progresso do fluxo de trabalho. Quando a janela de contexto fica cheia, a compactação automática pode descartar detalhes importantes. E, se um worker falhar, o próximo agente precisa saber quais etapas foram de fato concluídas.

Por exemplo, se o agente de programação gerar um patch e depois falhar, o próximo worker deve recuperar o artefato salvo e continuar a partir do estado registrado do fluxo de trabalho. Mas, se o agente também tiver disparado uma execução externa de CI, o orquestrador deve reconciliar essa execução separadamente antes de repetir a ação

Portanto, mantenha o estado de execução separado do contexto de trabalho do agente. Salve os status das tarefas, as tentativas de execução, as etapas concluídas e as referências a artefatos em armazenamento durável. Ao mesmo tempo, carregue apenas as instruções, entradas e resultados relevantes para a tarefa atual do agente, em vez de encher a janela de contexto dele com todo o histórico de execução.

4. Projete novas tentativas cientes de falhas e uma execução de ferramentas recuperável

Digamos que seu agente de CI dispare uma execução de testes, mas a solicitação à API exceda o tempo limite. A execução de testes não chegou a começar ou o serviço de CI a colocou na fila e perdeu a resposta?

Um tempo limite esgotado não significa necessariamente que uma operação falhou. É por isso que você precisa distinguir os tipos de erro antes de decidir o que acontece em seguida:

• Erros transitórios (429, 503): Tente novamente com backoff exponencial limitado e jitter, respeitando o Retry-After quando fornecido.
• Erros de validação ou de permissão (400, 403): Pare ou corrija o problema subjacente em vez de repetir a mesma solicitação.
• Resultados ambíguos (tempo limite após uma possível gravação): Verifique se a operação foi bem-sucedida antes de tentá-la novamente.

Observação: Até mesmo erros que permitem novas tentativas precisam de limites. Defina um tempo limite para cada chamada de ferramenta, limite o número de novas tentativas e o tempo total delas e imponha um prazo geral para o fluxo de trabalho, para que agentes aninhados não continuem reiniciando a mesma operação. Se uma dependência falhar repetidamente, use um circuit breaker para interromper temporariamente as solicitações.

Para operações com efeitos colaterais externos, atribua uma chave de idempotência estável a cada ação lógica e reutilize-a nas novas tentativas. Se a API oferecer suporte à desduplicação no servidor, ela poderá reconhecer solicitações repetidas sem executar a ação duas vezes. Caso contrário, consulte o sistema externo usando um ID de correlação ou outra referência autoritativa.

Quando não for possível determinar o que aconteceu, pare e escale o problema.

Um exemplo da lógica de novas tentativas do nosso agente de CI, expresso em pseudocódigo:

Observação sobre o código: O exemplo pressupõe que a API de CI permite consultar execuções por ID de solicitação. O request_id só evita duplicatas se o provedor garantir explicitamente a idempotência. bounded_retry() é um pseudocódigo ilustrativo. Em produção, as novas tentativas devem ser limitadas tanto por um orçamento de novas tentativas por operação (número máximo de tentativas ou tempo decorrido) quanto pelo prazo geral do fluxo de trabalho.

Para fluxos de trabalho mais longos que abrangem vários serviços, considere o padrão Saga para coordenar ações de compensação quando etapas posteriores falharem. Só lembre que a compensação nem sempre é uma reversão completa. É possível reverter uma atualização no banco de dados, mas não é possível desfazer o envio de um e-mail.

5. Direcione e paralelize o trabalho com orçamentos de recursos explícitos

Há duas coisas a equilibrar aqui: quanta capacidade de modelo cada tarefa exige e quantas tarefas você pode executar simultaneamente. Se errar em qualquer uma delas, você corre o risco de ter agentes disputando cotas de API compartilhadas ou dependendo apenas de modelos de raciocínio caros.

Para a seleção de modelos, ajuste a capacidade do modelo e o esforço de raciocínio à complexidade da tarefa — algo simples, mas bastante negligenciado. Observe que você pode configurar regras de roteamento e avaliar modelos por conta própria ou usar uma plataforma de orquestração que cuide da seleção de modelos para você.

Por exemplo, o Effort Mode do Perplexity Computer permite escolher quanto esforço uma tarefa merece sem selecionar um modelo manualmente. Escolha Light, Standard, High ou Ultra, e a Perplexity seleciona automaticamente o modelo orquestrador e o nível de raciocínio dele. Esse orquestrador então delega subtarefas a agentes de apoio, que podem usar modelos de diferentes provedores.

A Perplexity avalia as configurações de modelos em termos de qualidade e custo, favorecendo opções mais baratas que entregam resultados comparáveis. Você também pode usar os controles personalizados (Custom) se preferir escolher o modelo e o nível de raciocínio por conta própria.

Para o paralelismo, o limite deve vir da sua infraestrutura e das dependências externas. Verifique os limites de taxa de solicitações e de tokens das APIs compartilhadas e, em seguida, faça testes de carga do seu fluxo de trabalho com concorrência crescente. Observe se a taxa de transferência melhora ou se as solicitações começam a entrar em fila, ficar mais lentas ou retornar erros 429.

Para manter o consumo de recursos previsível, imponha limites de recursos e controles de agendamento:

• Controle a concorrência e as taxas de solicitação: Limite as chamadas em andamento por serviço e coloque o trabalho excedente em fila. Lembre-se de que um limite de concorrência, por si só, não impõe limites de solicitações por minuto nem de tokens por minuto.
• Acompanhe os orçamentos de tokens e de custos: Contabilize o uso em todo o fluxo de trabalho, incluindo subagentes, e pare de iniciar novos trabalhos quando o orçamento restante for insuficiente.
• Imponha prazos de execução: Defina limites de tempo para tarefas e fluxos de trabalho e propague o cancelamento para os agentes em execução, quando houver suporte.
• Respeite as dependências: Inicie tarefas posteriores apenas quando as entradas necessárias estiverem disponíveis, em vez de iniciar todos os agentes simultaneamente.

6. Imponha aprovações e isole a execução dos agentes

Nunca peça ao modelo que decida se as próprias ações são seguras. Em vez disso, conceda aos agentes permissões de privilégio mínimo e imponha regras de aprovação baseadas em risco no código da aplicação. Se os agentes executarem código, isole essa execução do seu ambiente host e restrinja o acesso a arquivos, redes e credenciais. Isso limita os danos se o agente cometer um erro ou executar código inseguro.

“Sou cético em relação a sistemas multiagente excessivamente complicados, especialmente quando os agentes revisam e aprovam o trabalho uns dos outros. Você pode acabar com vários agentes repassando o mesmo erro com toda a confiança, sem que ninguém realmente o perceba”, alerta Spilker.

Expandir

Para ações que exigem aprovação humana, pause a execução e salve exatamente a operação proposta:

• seus parâmetros
• seu recurso de destino
• seu commit ou versão de estado
• a decisão do revisor

Além disso, defina o que acontece se a aprovação for rejeitada, expirar ou precisar ser escalada. Isso é essencial em frameworks retomáveis, já que retomar um nó interrompido executa novamente o código desde o início desse nó. Quaisquer efeitos colaterais anteriores à interrupção podem ser executados de novo.

Portanto, se a aprovação for rejeitada ou expirar, a solicitação é encerrada. Se o commit de destino, os parâmetros ou as permissões mudarem antes da execução, invalide a aprovação e solicite uma nova.

Spilker também não apoia a ideia de agentes totalmente autônomos, de ponta a ponta, vistos como o objetivo final. “Para mim, a melhor abordagem é criar alguns agentes focados, com responsabilidades claras, permissões definidas e revisão humana nos momentos certos. Você continua ganhando eficiência sem abrir mão do controle total”, conclui.

7. Verifique as saídas de forma independente e teste o comportamento de recuperação

Já teve um agente informando Success quando, na verdade, ele falhou? É irritante, para não dizer enfurecedor, e a correção não é rápida, porque a mensagem final do agente não necessariamente vai dizer onde as coisas deram errado.

Para investigar, rastreie o que aconteceu durante a execução e verifique os resultados de forma independente. Então, vamos dedicar algum tempo a isolar e resolver o problema.

Rastreie o fluxo de trabalho para identificar o que deu errado

Antes de depurar os prompts de um agente, capture todo o caminho de execução. Você precisa de um rastreamento que conecte invocações de agentes, chamadas de ferramentas, erros e novas tentativas sob a mesma execução do fluxo de trabalho.

As convenções semânticas de GenAI do OpenTelemetry oferecem uma forma padronizada de descrever essas operações. Por exemplo, invoke_workflow identifica a execução de um fluxo de trabalho, invoke_agent, uma invocação de agente, e execute_tool, uma chamada de ferramenta. Cada operação pode ser registrada como um span com sua duração, status e metadados relevantes.

Esta etapa fornece um rastreamento do caminho de execução, para que você possa identificar onde um agente teve algum problema.

Um rastreamento de execução ilustrativo.

Revise a saída de forma independente

Use verificações programáticas sempre que possível. Valide as saídas com base em esquemas JSON, execute testes unitários e de integração, verifique se os artefatos necessários existem e consulte sistemas externos para confirmar que as ações realmente foram bem-sucedidas.

Para saídas que exigem julgamento subjetivo — e, portanto, não podem ser avaliadas por meio de verificações programáticas —, introduza um agente revisor independente. Uma abordagem é um loop implementador–revisor–solucionador, em que um agente produz um artefato, um revisor com contexto novo identifica problemas e um solucionador os resolve antes que a validação seja executada novamente.

Você ainda precisa validar as conclusões do revisor sempre que possível e, se estiver usando avaliadores baseados em LLM para avaliações repetidas, calibre os julgamentos deles com base em exemplos revisados por humanos.

Injete falhas para testar a recuperação

Até aqui, você rastreou o que os agentes executaram e verificou se as saídas deles estavam corretas. Mas o que acontece quando um worker trava no meio de uma tarefa ou uma API atinge o tempo limite depois de aceitar uma solicitação? Surpreendentemente, seu fluxo de trabalho pode se comportar perfeitamente bem em condições normais, mas falhar durante a recuperação.

Para testar isso, injete falhas deliberadamente em um ambiente de teste:

• Simule timeouts de API
• Provoque falhas nos workers entre gravações externas e checkpoints
• Retorne saídas de ferramentas malformadas
• Faça aprovações expirarem

Após cada teste, inspecione o rastreamento de execução para ver quais etapas foram executadas, onde o fluxo de trabalho foi retomado e se alguma ação foi repetida ou ignorada. Em seguida, revise os resultados reais.

Digamos que seu agente de CI envie uma solicitação para iniciar uma execução de testes, mas a resposta da API atinja o tempo limite. O agente tenta novamente, recebe uma resposta bem-sucedida e informa Success. Tudo parece certo até você verificar o serviço de CI e descobrir que foram criadas duas execuções de teste em vez de uma.

É por isso que você deve verificar tanto o estado registrado do fluxo de trabalho quanto as mudanças reais nos sistemas externos. Um teste de recuperação só deve passar quando o fluxo de trabalho atingir o estado esperado sem efeitos colaterais indesejados.

Adicione as falhas que você descobrir aos seus testes de regressão para que mudanças futuras não as reintroduzam.

Em última análise, sucesso significa que o fluxo de trabalho foi aprovado nas verificações obrigatórias e que seus resultados externos foram verificados.

Perguntas frequentes sobre orquestração de agentes de IA

Por que agentes de IA isolados falham em escala empresarial?

Agentes isolados podem concluir corretamente suas tarefas individuais, mas produzir resultados inconsistentes em conjunto. Imagine um agente de vendas que recupera as condições comerciais de um cliente às 10h00, um agente de preços que calcula uma cotação usando preços atualizados às 10h05 e um agente jurídico que verifica um contrato alterado às 10h07. Cada agente trabalha com um retrato diferente do negócio, então seus resultados podem se contradizer.

O problema se torna mais acentuado em escala empresarial porque os agentes interagem com vários sistemas que são atualizados de forma independente, operam com permissões diferentes e não necessariamente compartilham contexto ou estado de execução.

Como evitar loops infinitos de novas tentativas em agentes de IA?

Defina limites em vários níveis: número máximo de novas tentativas de chamadas de ferramentas, número máximo de iterações do agente, profundidade de delegação e um prazo geral para o fluxo de trabalho. Classifique as falhas antes de tentar novamente. Para respostas 429 transitórias, respeite o Retry-After quando ele for fornecido. Caso contrário, use backoff exponencial limitado com jitter.

Pare de repetir solicitações inalteradas após erros de validação ou de permissão. Se um serviço downstream falhar repetidamente, um circuit breaker pode impedir que os agentes gerem carga adicional.

Como retomar um fluxo de trabalho de agente de IA após uma falha?

O mecanismo de recuperação depende do seu runtime. Com o LangGraph, um checkpointer persistente como o PostgresSaver armazena o estado do grafo sob um thread_id, permitindo que a execução continue a partir do estado persistido. Com o Temporal, outro worker pode reconstruir um fluxo de trabalho reproduzindo seu histórico de eventos. Durante a reprodução, ele reutiliza os resultados de atividades registrados anteriormente.

Se a aplicação for reimplantada enquanto fluxos de trabalho ainda estiverem em execução, o estado salvo e os históricos de execução podem deixar de ser compatíveis. O Temporal resolve isso com o Worker Versioning e o patching de fluxos de trabalho. Em sistemas baseados em checkpoints, planeje as migrações de esquema e teste a recuperação com os estados salvos existentes antes de implantar alterações incompatíveis.

Como testar a confiabilidade da orquestração de agentes de IA?

Execute as mesmas tarefas representativas várias vezes e diferencie pass@k (se pelo menos uma de k tentativas é bem-sucedida) de pass^k (se todas as k tentativas são bem-sucedidas)

Meça os resultados por categoria de tarefa e versão do fluxo de trabalho, em vez de depender de uma única taxa de sucesso agregada. Acompanhe o sucesso na primeira tentativa, a consistência entre execuções repetidas, a latência p95, o custo por tarefa concluída e a proporção de tarefas que exigem intervenção humana. Informe os tamanhos de amostra e os intervalos de incerteza das taxas de sucesso.