Boas práticas de orquestração de agentes de IA: gerir falhas, aprovações e novas tentativas

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

Prevenir estas falhas exige uma engenharia cuidadosa dos fluxos de trabalho. Por isso, vamos analisar o que torna os fluxos de trabalho orquestrados pouco fiáveis e explorar as boas práticas de orquestração para garantir fiabilidade em produção.

O que é a 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 com vários passos. Mas alguém — ou algo — tem ainda de decidir que agente é executado primeiro, que informação recebe e o que acontece depois de terminar. Este é o papel do orquestrador — um agente de IA que atua como gestor ou uma camada de execução controlada por software.

Em termos simples, uma camada de orquestração divide um objetivo em tarefas mais pequenas, acompanha as dependências, delega a execução nos agentes certos, gere o contexto partilhado e reúne os resultados.

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

Expandir

Vejamos o que acontece depois de dar uma tarefa a um orquestrador.

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

1. Compreender o objetivo e planear o trabalho. O orquestrador parte do resultado pretendido e decompõe-no em tarefas com dependências explícitas. No nosso exemplo do painel, isso implica recolher informações de diferentes fontes e transformá-las num produto final. O planeador estabelece que passos dependem de outros e quais podem ser executados de forma independente.
2. Encaminhar as tarefas para os agentes adequados. O orquestrador identifica as tarefas cujas dependências estão satisfeitas e delega o trabalho em agentes ou modelos especializados. As tarefas dependentes aguardam pelos respetivos pré-requisitos. O Perplexity Computer utiliza vários modelos de fronteira e encaminha diferentes partes do fluxo de trabalho para os sistemas mais adequados a essas tarefas. Isto também permite executar trabalho independente em paralelo.
3. Executar chamadas de ferramentas em ambientes controlados. Os agentes interagem com o seu ambiente através de ferramentas, como pesquisa na web, APIs, aplicações ligadas, operações com ficheiros ou execução de código. A camada de execução executa estas ações e devolve os resultados aos agentes.
4. Passar resultados e contexto entre agentes. Quando um agente termina a sua tarefa, o agente seguinte a jusante precisa do resultado relevante para continuar. Um registo de transferência pode conter um ID de tarefa, uma referência ao resultado, uma versão do esquema e metadados de origem. O orquestrador coordena estas transferências e mantém o contexto necessário para os passos seguintes. É importante notar que os agentes não têm de guardar todo o histórico do trabalho de todos os outros agentes nas suas próprias janelas de contexto.
5. Registar o estado da execução separadamente do contexto dos agentes. À medida que os agentes iniciam, concluem ou falham tarefas, o motor de execução atualiza um registo persistente do fluxo de trabalho com os estados das tarefas, as tentativas de execução, as referências aos resultados e o trabalho restante. Este registo permite ao orquestrador acompanhar o progresso e retomar 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 a seguir. Quando uma tarefa termina, a camada de orquestração verifica se o seu resultado cumpre o contrato esperado e se as dependências da tarefa seguinte estão satisfeitas. Se for encontrado um problema, o fluxo de trabalho pode regressar a um passo anterior para correção ou ser colocado em pausa. Caso contrário, avança até à conclusão.

Por trás do que parece ser uma simples orquestração de agentes de IA, há muitas peças em movimento. A forma como organiza a coordenação dos agentes determina o grau de controlo que tem sobre a execução. E, claro, toda essa coordenação acrescenta custos adicionais. Por isso, nem sempre compensa.

Quando deve utilizar a orquestração de agentes de IA?

Considere a orquestração multiagente quando diferentes partes da tarefa exigem conhecimentos especializados distintos, quando o trabalho independente pode ser executado em paralelo ou quando não é possível determinar o passo seguinte à partida.

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

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

Fora destes casos, a orquestração é apenas uma tendência dispendiosa. Mais agentes significam também mais coordenação e, potencialmente, custos de tokens mais elevados.

«Normalmente, começo pela opção mais simples e vou construindo a partir daí. Se conhecemos os passos e estes são repetíveis, provavelmente trata-se de um fluxo de trabalho. Só vejo motivo para introduzir vários agentes quando têm responsabilidades, permissões ou utilizadores diferentes», afirma Josh Spilker, responsável de marketing de pesquisa na AirOps.

Mesmo assim, pondere os benefícios face às chamadas adicionais aos modelos, às transferências, à latência e aos pontos de falha.

Arquiteturas de orquestração de agentes de IA e respetivos compromissos

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

Orquestração centralizada

Na orquestração centralizada, um orquestrador gere o processo. Divide a tarefa, delega o trabalho em agentes especialistas, acompanha o progresso destes e reúne os respetivos resultados.

Expandir

A contrapartida: A coordenação centralizada facilita o acompanhamento da execução e a aplicação de regras comuns num único ponto de controlo. No entanto, o orquestrador pode tornar-se um ponto de estrangulamento e a sua falha pode interromper todo o fluxo de trabalho, a menos que o sistema permita a recuperação.

Orquestração descentralizada

Na orquestração descentralizada, os agentes coordenam-se de forma mais direta, em vez de dependerem de um único gestor para tomar todas as decisões. Podem trocar mensagens, ler o estado partilhado e determinar de forma independente os passos seguintes.

Expandir

O compromisso: Os agentes podem funcionar sem esperar por um planeador central, o que torna esta abordagem útil para trabalho exploratório e contribuições independentes. Mas a coordenação torna-se mais difícil quando os agentes discordam, atualizam informação partilhada ou precisam de chegar a um resultado consistente.

Orquestração hierárquica

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

Pense num fluxo de trabalho empresarial que envolva as equipas de vendas, finanças e jurídica. Um orquestrador de nível superior poderia delegar cada frente de trabalho num coordenador específico do domínio. Esses coordenadores geririam depois os seus próprios agentes especialistas e reportariam resultados consolidados.

Esta estrutura pode ajudar quando os fluxos de trabalho são demasiado amplos para um único orquestrador os gerir de forma eficaz.

Expandir

O compromisso: As hierarquias permitem às equipas dividir as responsabilidades de coordenação e, potencialmente, tratar as falhas dentro de ramos individuais. No entanto, introduzem transferências adicionais, uma gestão de estado mais complexa e maiores custos operacionais. A recuperação local depende também da forma como os checkpoints e o estado de execução são implementados.

Comparação entre estas arquiteturas:

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

Há mais uma distinção que vale a pena compreender. A arquitetura determina quem coordena os agentes. O padrão de execução determina como as suas tarefas progridem.

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

• Fluxos de trabalho sequenciais: Os agentes trabalham numa ordem predefinida, e o resultado de um agente torna-se a entrada de outro.
• Execução paralela: Agentes independentes trabalham em simultâneo.
• Execução baseada em transferências: O controlo passa entre agentes especializados à medida que a tarefa avança. Isto é útil quando outro agente está mais bem preparado para tratar do passo seguinte, embora cada transferência tenha de preservar a informação necessária para continuar.

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

Falhas comuns na orquestração de agentes de IA

Tudo pode correr mal na orquestração, desde simples descuidos a bloqueios complexos. Por vezes, um agente pode até parecer cumprir corretamente a sua função enquanto o fluxo de trabalho, no seu conjunto, falha. Com base na experiência de profissionais da área, reunimos alguns dos erros comuns por detrás de fluxos de trabalho orquestrados pouco fiáveis — esteja atento a eles:

• Transferências entre agentes com perda de informação. Um orquestrador passa um plano resumido a um agente especializado, mas o resumo omite restrições, dependências ou detalhes de implementação.
• Execução prematura de fan-in. Um agente a jusante começa a agregar resultados antes de todas as tarefas a montante terem terminado.
• Atualizações não determinísticas do estado partilhado. Agentes paralelos escrevem nas mesmas chaves de estado sem uma semântica de fusão bem definida. Consoante a forma como a framework trata as atualizações, isto pode resultar em escritas perdidas, dados duplicados, resultados dependentes da ordem ou alterações em conflito.
• Divergência entre checkpoints e efeitos secundários. Uma tarefa executa uma operação externa, mas a sua execução bem-sucedida não fica registada de forma duradoura antes de o worker falhar. Na recuperação, o orquestrador vê uma tarefa inacabada e volta a executá-la.
• Condições de corrida na retoma após aprovação humana. Pausar e retomar a execução introduz os seus próprios problemas de sincronização.
• Ciclos de delegação e amplificação de novas tentativas. Os agentes passam trabalho repetidamente uns aos outros porque as suas responsabilidades se sobrepõem, as dependências são circulares ou as condições de conclusão são ambíguas.
• Controlos ao nível das instruções confundidos com segurança de execução. Um orquestrador pode dizer aos agentes que não acedam a determinados recursos nem realizem ações sensíveis, mas as instruções dadas ao modelo não impõem permissões do sistema operativo, restrições de rede nem limites de autorização. A pesquisa de engenharia de segurança da Perplexity destaca por que razão os agentes podem ultrapassar limites de segurança enquanto perseguem objetivos legítimos, mesmo sem instruções maliciosas

Repare como estas falhas são diferentes. Uma transição prematura do agendador ou uma escrita externa ambígua podem ambas produzir um resultado incorreto, mas têm origem em partes diferentes do ciclo de vida da execução. É por isso que uma orquestração fiável exige mais do que melhorar prompts ou acrescentar novas tentativas.

7 boas práticas de orquestração de agentes de IA para fiabilidade em produção

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

Objetivos vagos e uma definição de concluído pouco clara conduzem frequentemente a resultados dececionantes gerados por agentes. A solução é um contrato de prompt (um âmbito de trabalho para um agente): acorde 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, eis como 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, registos de falhas da CI, commits recentes e código relevante da aplicação.
• Restrições: Não desativar testes, não flexibilizar asserções nem modificar comportamentos da aplicação não relacionados.
• Resultado esperado: Um patch de código, uma explicação da causa principal e os resultados da execução dos testes.
• Critérios de aceitação: O teste que falhava anteriormente passa em 10 execuções consecutivas e o conjunto de testes de regressão relevante passa.
• Condições de falha: Não é possível determinar a causa principal, a correção introduz regressões ou o ambiente de teste necessário não está disponível.

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

Um agente não deve continuar a iterar indefinidamente só porque ainda não produziu um resultado satisfatório. Defina o que constitui uma conclusão bem-sucedida, quando devolver uma tarefa parcialmente concluída e quando parar porque um requisito não pode ser cumprido. Defina uma profundidade máxima de delegação e limites de iteração ou orçamentos de execução, para que as tarefas por resolver não se tornem ciclos intermináveis.

Voltemos ao nosso exemplo de CI. Poderia definir as seguintes condições de paragem:

• 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 tem de parar ao fim de 60 minutos, mesmo que o problema continue por resolver.
• Limite de delegação: O agente pode delegar trabalho num agente especializado, sem mais delegação em subagentes.
• Conclusão parcial: Se ambas as tentativas falharem ou o limite de tempo expirar, o agente devolve as suas conclusões, as alterações tentadas e os resultados dos testes.
• Execução bloqueada: Se o ambiente de teste não estiver disponível, o agente para e comunica o bloqueio em vez de declarar sucesso.

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

Por vezes, os programadores atribuem demasiadas responsabilidades a um orquestrador e, em vez de coordenar agentes especializados, este começa a escrever código, a depurar ou a fazer revisões detalhadas por si próprio. Isto cria um estrangulamento: o orquestrador gasta o seu orçamento de contexto em detalhes de implementação, atrasa a delegação e torna difusa a responsabilidade pelos resultados.

Por isso, deixe os orquestradores fazer o seu trabalho e imponha transferências que referenciem artefactos concretos: a tarefa original, as entradas relevantes, os artefactos de saída, o estado da execução e quaisquer problemas por resolver.

Considere este exemplo: status: completed refere-se ao trabalho atribuído ao agente, não a todo o fluxo de trabalho. 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 registo fiável do progresso do fluxo de trabalho. Quando a sua janela de contexto fica cheia, a compactação automática pode descartar detalhes importantes. E, se um worker falhar, o agente seguinte precisa de saber que passos foram efetivamente concluídos.

Por exemplo, se o agente de programação gerar um patch e depois falhar, o worker seguinte deve obter o artefacto guardado e continuar a partir do estado registado do fluxo de trabalho. Mas, se o agente também tiver acionado uma execução externa de CI, o orquestrador tem de reconciliar essa execução separadamente antes de repetir a ação

Por isso, mantenha o estado de execução separado do contexto de trabalho do agente. Guarde os estados das tarefas, as tentativas de execução, os passos concluídos e as referências a artefactos em armazenamento persistente. Entretanto, carregue apenas as instruções, entradas e resultados relevantes para a tarefa atual do agente, em vez de encher a sua janela de contexto com todo o histórico de execução.

4. Conceba novas tentativas conscientes das falhas e uma execução de ferramentas recuperável

Imagine que o seu agente de CI aciona uma execução de testes, mas o pedido à API excede o tempo limite. A execução de testes não chegou a começar, ou o serviço de CI colocou-a em fila e perdeu a resposta?

Um tempo limite excedido não significa necessariamente que uma operação falhou. É por isso que tem de distinguir entre erros antes de decidir o que acontece a seguir:

• Erros transitórios (429, 503): Tente novamente com recuo 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 o mesmo pedido.
• Resultados ambíguos (tempo limite excedido após uma possível escrita): Verifique se a operação foi bem-sucedida antes de a tentar novamente.

Nota: Mesmo os erros que admitem nova tentativa precisam de limites. Defina um tempo limite para cada chamada de ferramenta, limite o número de novas tentativas e o tempo total de novas tentativas e imponha um prazo global ao fluxo de trabalho, para que os agentes aninhados não possam continuar a reiniciar a mesma operação. Se uma dependência falhar repetidamente, utilize um circuit breaker para interromper temporariamente os pedidos.

Para operações com efeitos secundários externos, atribua uma chave de idempotência estável a cada ação lógica e reutilize-a nas novas tentativas. Se a API suportar deduplicação do lado do servidor, pode reconhecer pedidos repetidos sem executar a ação duas vezes. Se não suportar, consulte o sistema externo através de um ID de correlação ou de outra referência fidedigna.

Quando não conseguir 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:

Nota sobre o código: O exemplo pressupõe que a API de CI permite procurar execuções por ID de pedido. O request_id só evita duplicados se o fornecedor garantir explicitamente a idempotência. bounded_retry() é 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) como pelo prazo global 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 passos posteriores falham. Lembre-se apenas de que a compensação nem sempre é uma reversão completa. Pode reverter uma atualização da base de dados, mas não pode anular o envio de um e-mail.

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

Há dois aspetos a equilibrar aqui: quanta capacidade de modelo cada tarefa exige e quantas tarefas pode executar em simultâneo. Se errar em qualquer um deles, arrisca-se a ter agentes a competir por quotas de API partilhadas ou a depender apenas de modelos de raciocínio dispendiosos.

Na seleção de modelos, ajuste a capacidade do modelo e o esforço de raciocínio à complexidade da tarefa — simples, mas muitas vezes negligenciado. Note que pode configurar regras de encaminhamento e avaliar os modelos por si próprio, ou utilizar uma plataforma de orquestração que trate da seleção de modelos por si.

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

A Perplexity avalia as configurações dos modelos em termos de qualidade e custo, privilegiando opções mais económicas que proporcionem resultados comparáveis. Também pode utilizar os controlos Custom se preferir escolher o modelo e o nível de raciocínio por si próprio.

No paralelismo, o limite deve ser determinado pela sua infraestrutura e pelas dependências externas. Valide os limites de taxa de pedidos e de tokens das APIs partilhadas e, depois, faça testes de carga ao seu fluxo de trabalho com uma concorrência crescente. Observe se o débito melhora ou se os pedidos começam a ficar em fila, a abrandar ou a devolver erros 429.

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

• Controle a concorrência e as taxas de pedidos: Limite as chamadas em curso por serviço e coloque em fila o trabalho excedente. Lembre-se de que um limite de concorrência, por si só, não impõe limites de pedidos por minuto nem de tokens por minuto.
• Acompanhe os orçamentos de tokens e de custos: Contabilize a utilização em todo o fluxo de trabalho, incluindo os subagentes, e deixe de lançar novo trabalho quando o orçamento restante for insuficiente.
• Imponha prazos de execução: Defina limites de tempo para as tarefas e para o fluxo de trabalho e propague o cancelamento aos agentes em execução, quando suportado.
• Respeite as dependências: Inicie as tarefas a jusante apenas quando as entradas de que necessitam estiverem disponíveis, em vez de lançar todos os agentes em simultâneo.

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

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

«Sou cético em relação a sistemas multiagente demasiado complicados, sobretudo quando os agentes reveem e aprovam o trabalho uns dos outros. Pode acabar com vários agentes a passar o mesmo erro adiante com toda a confiança, sem que ninguém o detete realmente», adverte Spilker.

Expandir

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

• os respetivos parâmetros
• o respetivo recurso de destino
• o respetivo 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 de ser escalada. Isto é essencial em frameworks retomáveis, uma vez que retomar um nó interrompido volta a executar o código desde o início desse nó. Quaisquer efeitos secundários anteriores à interrupção podem ser executados novamente.

Assim, se a aprovação for rejeitada ou expirar, o pedido é encerrado. 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 e de ponta a ponta vistos como o objetivo. «Para mim, a melhor abordagem é criar alguns agentes focados, com responsabilidades claras, permissões definidas e revisão humana nos pontos certos. Continua a ganhar eficiência sem abdicar do controlo total», conclui.

7. Verifique os resultados de forma independente e teste o comportamento de recuperação

Já teve um agente a reportar Success quando, na verdade, falhou? É irritante, se não mesmo exasperante, e a correção não é rápida, porque a mensagem final do agente não lhe dirá necessariamente onde as coisas correram mal.

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

Rastreie o fluxo de trabalho para identificar o que correu mal

Antes de depurar os prompts de um agente, capture todo o caminho de execução. Precisa de um trace que ligue invocações de agentes, chamadas de ferramentas, erros e novas tentativas na mesma execução do fluxo de trabalho.

As convenções semânticas de GenAI do OpenTelemetry fornecem uma forma padronizada de descrever estas 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 registada como um span com a respetiva duração, estado e metadados relevantes.

Este passo dá-lhe um trace do caminho de execução, para que possa identificar onde um agente teve um percalço.

Um exemplo ilustrativo de trace de execução.

Reveja o resultado de forma independente

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

Para resultados que exigem um juízo subjetivo — e que, por isso, não podem ser avaliados através de verificações programáticas —, introduza um agente revisor independente. Uma abordagem é um ciclo implementador–revisor–resolvedor, em que um agente produz um artefacto, um revisor com contexto novo identifica problemas e um resolvedor trata-os antes de a validação voltar a ser executada.

Continua a ser necessário validar as conclusões do revisor sempre que possível e, se estiver a utilizar avaliadores baseados em LLM para avaliações repetidas, calibre os respetivos juízos com base em exemplos revistos por humanos.

Injete falhas para testar a recuperação

Até agora, rastreou o que os agentes executaram e verificou se os respetivos resultados estavam corretos. Mas o que acontece quando um worker falha a meio de uma tarefa ou quando uma API excede o tempo limite depois de aceitar um pedido? Surpreendentemente, o seu fluxo de trabalho pode comportar-se perfeitamente bem em condições normais, mas falhar durante a recuperação.

Para testar isto, injete falhas deliberadamente num ambiente de teste:

• Simule tempos limite excedidos na API
• Provoque falhas nos workers entre escritas externas e pontos de controlo
• Devolva resultados de ferramentas malformados
• Faça expirar aprovações

Após cada teste, inspecione o rastreio de execução para ver que passos foram executados, onde o fluxo de trabalho foi retomado e se alguma ação foi repetida ou ignorada. Em seguida, analise os resultados reais.

Imagine que o seu agente de CI envia um pedido para iniciar uma execução de testes, mas a resposta da API excede o tempo limite. O agente tenta novamente, recebe uma resposta bem-sucedida e reporta Success. Tudo parece estar bem até verificar o serviço de CI e descobrir que foram criadas duas execuções de testes em vez de uma.

É por isso que deve verificar tanto o estado registado do fluxo de trabalho como as alterações reais nos sistemas externos. Um teste de recuperação só deve ser aprovado quando o fluxo de trabalho atinge o estado esperado sem efeitos secundários indesejados.

Adicione as falhas que descobrir aos seus testes de regressão, para que alterações futuras não as voltem a introduzir.

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

Perguntas frequentes sobre orquestração de agentes de IA

Porque é que os agentes de IA isolados falham à escala empresarial?

Os agentes isolados podem concluir corretamente as suas tarefas individuais, mas produzir resultados inconsistentes em conjunto. Imagine um agente de vendas a obter as condições do cliente às 10:00, um agente de preços a calcular um orçamento com preços atualizados às 10:05 e um agente jurídico a verificar um contrato que foi alterado às 10:07. Cada agente trabalha com um retrato diferente do negócio, pelo que os respetivos resultados podem contradizer-se.

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

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

Defina limites a 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 global para o fluxo de trabalho. Classifique as falhas antes de tentar novamente. Para respostas 429 transitórias, respeite Retry-After quando for fornecido. Caso contrário, utilize um backoff exponencial limitado com jitter.

Deixe de repetir pedidos inalterados após erros de validação ou de permissão. Se um serviço a jusante falhar repetidamente, um disjuntor (circuit breaker) pode impedir que os agentes gerem carga adicional.

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

O mecanismo de recuperação depende do seu ambiente de execução. Com o LangGraph, um checkpointer persistente, como o PostgresSaver, armazena o estado do grafo associado a 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 o respetivo histórico de eventos. Durante a reprodução, reutiliza os resultados de atividades registados anteriormente.

Se a aplicação for reimplementada enquanto os fluxos de trabalho ainda estão em execução, o estado guardado e os históricos de execução podem deixar de ser compatíveis. O Temporal resolve esta questão através do Worker Versioning e da aplicação de patches aos fluxos de trabalho. Em sistemas baseados em pontos de controlo, planeie as migrações de esquema e teste a recuperação com os estados guardados existentes antes de implementar alterações incompatíveis.

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

Execute as mesmas tarefas representativas várias vezes e distinga 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 à 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 requerem intervenção humana. Indique os tamanhos das amostras e os intervalos de incerteza das taxas de sucesso.