Criação de fluxos de trabalho de IA com quadros multi-agentes

Os agentes são registados como componentes chamáveis no sistema

Antes de um agente poder fazer qualquer coisa, a estrutura precisa de saber que ele existe. Isto significa dizer ao sistema o nome do agente, qual a sua responsabilidade e quais as ferramentas ou informações a que pode aceder.

Na maioria das estruturas, esta configuração é feita através de um ficheiro de configuração ou de algum código, onde se define a função de cada agente e a forma de o ativar. Por exemplo, pode dizer ao sistema:

"Este é o planeador. Lê as entradas do utilizador e decide o que fazer a seguir."
"Este é o verificador. Recebe as informações do utilizador e devolve booking_id e informações do utilizador."

Uma vez registada, a estrutura pode "chamar" estes agentes pelo nome, o que significa que sabe como executar cada um deles quando for a sua vez no fluxo de trabalho.

O agente de encaminhamento decide qual o agente a executar a seguir

Um agente planeador ou função de controlador trata do encaminhamento do agente de IA. Analisa o último resultado do bot, o histórico da conversa atual e, por vezes, a entrada original do utilizador para decidir o que tem de acontecer a seguir.

Alguns planeadores são baseados em mensagens - recebem uma mensagem do sistema e indicam o nome do próximo agente a executar.

Outros utilizam lógica codificada ou gráficos de fluxo, dependendo das estruturas de agentes de IA com que está a trabalhar.

A estrutura pega nesse resultado e utiliza-o para chamar o agente seguinte. O router decide quem deve realizar a tarefa em vez de a realizar.

Os dados são transmitidos entre agentes através de mensagens

Os agentes não partilham memória diretamente. Quando um termina a execução, a sua saída é empacotada numa mensagem - normalmente um dicionário ou um objeto JSON - e passada para o agente seguinte como entrada.

A estrutura trata da transferência. Ou armazena a mensagem num espaço de memória partilhada ou passa-a diretamente para a interface de entrada do agente seguinte, dependendo da forma como o sistema está estruturado.

As mensagens incluem frequentemente mais do que apenas o conteúdo:

• Quem o enviou (agente ou utilizador)
• De onde veio o fluxo de trabalho
• Como deve ser utilizado (por exemplo, acionador, entrada, decisão)
• Métricas opcionais como contagem de tokens ou carimbos de data/hora

Este contexto ajuda o sistema a encaminhar as tarefas de forma limpa e mantém os agentes desacoplados uns dos outros.

A execução é monitorizada através do estado do fluxo de trabalho e dos accionadores

A estrutura mantém um registo do que aconteceu até agora - que agentes foram executados, o que devolveram e o que ainda precisa de acontecer. Isso é armazenado em um objeto de estado, que é atualizado após cada etapa.

Os accionadores decidem o que vem a seguir. Utilizam valores de saída ou condições para ramificar o fluxo.

Isto permite que o sistema avance sem codificar a lógica em cada agente. O estado conduz o fluxo de trabalho, não os agentes em si.

Escalar a lógica sem sobrecarregar um único agente

Um único agente de IA não pode fazer muito antes de se transformar numa confusão de avisos, ferramentas e responsabilidades pouco claras. As estruturas multiagente permitem-lhe dividir essa lógica em agentes específicos, cada um deles com uma tarefa clara.

Em vez de sobrecarregar um único agente, pode atribuir passos específicos - como a recuperação, a validação ou a execução - a agentes separados e fazer crescer o sistema peça por peça.

Colaboração de agentes de depuração com visibilidade total

Quando os agentes de IA trabalham em conjunto, os problemas podem ser difíceis de localizar. As estruturas mostram-lhe o que cada agente obteve, o que devolveu e onde parou.

Não se adivinha o que falhou - inspecciona-se as transferências e corrige-se diretamente. Este tipo de visibilidade é o que torna a colaboração entre agentes de IA gerível.

Reutilizar agentes em fluxos de trabalho

Se um agente funciona, reutilize-o. As estruturas permitem-lhe ligar o mesmo agente a diferentes fluxos sem o reescrever. Isso mantém as coisas consistentes e torna os testes mais rápidos.

Por exemplo, um agente de validação que verifica as entradas do utilizador ou a autenticação pode ser utilizado tanto em chatbots de serviço ao cliente como em chatbots de reservas, sempre que se aplique a mesma lógica.

Tratar automaticamente as falhas e as novas tentativas

Quando um agente falha, a estrutura pode tentar novamente, ignorá-lo ou seguir em frente. Não é necessário escrever essa lógica.  

O fallback incorporado torna os fluxos de trabalho mais fiáveis sem trabalho extra, e é esse tipo de fiabilidade que alimenta os sistemas do mundo real.

Criar fluxos de agentes que sejam fáceis de alterar

Quando se dividem as tarefas pelos agentes, não é necessário reformular todo o sistema sempre que algo muda.

É possível atualizar um planeador sem tocar na execução ou alterar a forma como um agente responde sem reescrever o resto.

Essa facilidade de acesso compensa - a Salesforce informa que as equipas que utilizam a IA agêntica poupam 11 horas por funcionário todas as semanas, em parte graças à adaptabilidade dos fluxos de trabalho.

1. Botpress

Botpress é uma plataforma de desenvolvimento visual para a criação de agentes de IA que podem coordenar-se entre etapas, funções e canais.

Em vez de ligar a lógica em código, define-se como os agentes se comportam utilizando fluxos, memória, condições e chamadas de ferramentas.

O comportamento multiagente é construído em torno de instruções, fluxos de trabalho e ferramentas externas. Cada nó de um fluxo Botpress actua como uma unidade específica, com as suas próprias instruções e âmbito.

Pode dividir o raciocínio por vários nós autónomos e estáticos, adicionar camadas de validação ou encaminhar a entrada do utilizador através de uma lógica de decisão baseada em ferramentas, em vez de tratar tudo numa única etapa.

A memória é limitada a cada fluxo, para que os agentes utilizem apenas o que precisam. As entradas e saídas são claramente definidas e as chamadas de ferramentas podem ser adicionadas diretamente através de integrações incorporadas.

Caraterísticas principais

• Orquestração visual de agentes utilizando fluxos e nós
• Memória com escopo e controlo de variáveis entre nós
• Memória multi-voltas, lógica de recuo e novas tentativas
• Utilização de ferramentas através de chamadas API, webhooks e introdução de funções

2. Cadeia Lang

A LangChain é uma estrutura que dá prioridade ao programador para a criação de aplicações LLM, ligando cadeias de avisos, ferramentas e memória.

Começou como uma forma de estruturar as chamadas LLM com ferramentas como pesquisa e calculadoras, mas gradualmente expandiu-se para um ecossistema em expansão.

Uma versão deu prioridade aos "agentes", depois aos "assistentes" e depois aos "executáveis". O resultado é um poderoso kit de ferramentas que pode fazer quase tudo, mas muitas vezes leva tempo para navegar.

É possível atribuir kits de ferramentas e criar lógica de encaminhamento entre agentes. O ponto forte é a modularidade - os componentes são reutilizáveis, podem ser combinados e estão bem integrados com APIs externas.

Mas vai escrever mais código cola do que o esperado. E com as abstracções a mudar rapidamente, vale a pena verificar se o método que está a utilizar ainda é o preferido.

Caraterísticas principais

• Encadeamento modular de avisos, ferramentas e memória
• Integra-se com LLMs, armazenamentos vectoriais e APIs
• Rastreio e avaliações opcionais com LangSmith

3. TripulaçãoAI

O CrewAI facilita a criação de fluxos de trabalho multi-agente em que cada agente tem uma função e uma tarefa definidas. Cria-se uma equipa, atribuem-se objectivos e os agentes coordenam-se através de um gestor partilhado.

É uma das maneiras mais rápidas de modelar a colaboração de agentes sem escrever lógica de orquestração do zero.

Ideal para configurações como pares de planeador-executor, fluxos de investigador-revisor ou qualquer tarefa baseada em equipas em que as responsabilidades sejam divididas de forma clara.

Mas quando se começa a adicionar complexidade, a abstração torna-se mais apertada. Há menos flexibilidade em relação a como e quando os agentes são executados, e modificar o comportamento geralmente significa sair dos padrões da estrutura.

Caraterísticas principais

• Configuração de agentes baseada em funções com nomes, objectivos e memória
• Suporta a execução sequencial e paralela de agentes
• Memória partilhada da tripulação para colaboração entre agentes
• Fácil integração com ferramentas, funções e avisos personalizados

4. AutoGPT

O AutoGPT foi o primeiro projeto a mostrar o que acontece quando se dá um objetivo a um chatbotGPT e o deixamos funcionar - planear, pensar, pesquisar e executar sem a intervenção humana constante.

O utilizador define o objetivo e o AutoGPT percorre as etapas de raciocínio, cria sub-objectivos, chama ferramentas e ajusta a sua estratégia ao longo do percurso.

Foi um grande passo para fazer com que o comportamento do agente se sentisse autónomo e dinâmico. Mas não foi construído para ser preciso.

O ciclo de tarefas é frágil e os agentes tendem a ficar presos a reescrever o mesmo plano ou a perseguir subtarefas irrelevantes.

É possível ligar memória, ferramentas e APIs - mas juntar tudo leva muitas vezes a fluxos imprevisíveis que são difíceis de depurar ou controlar.

Caraterísticas principais

• Agente orientado para os objectivos, com auto-proclamação e planeamento de tarefas
• Geração automática de subtarefas e ciclo de execução
• Suporta a utilização de ferramentas através de plugins e chamadas API
• Extensível com scripts, funções e integrações personalizadas

5. Autogénico

O Autogen é uma estrutura de código aberto da Microsoft que se centra em conversações multi-agente, em que os agentes interagem através de mensagens estruturadas e baseadas em turnos.

É especialmente bom quando se pretende ter controlo sobre cada troca, como nos ciclos de planeamento - execução ou nos sistemas "human-in-the-loop".

O autogéneo brilha em transparência. Pode injetar funções a meio do discurso, encaminhar decisões através de uma lógica personalizada e rastrear exatamente o que cada agente disse e porquê.

Mas escalá-lo dá trabalho. A orquestração de mensagens é flexível, mas não é abstrata - continua a gerir históricos, configurações de agentes e lógica de passos.

Para configurações de pesquisa, testes controlados ou comportamento reproduzível de agentes, é uma das estruturas mais precisas que existem.

Caraterísticas principais

• Quadro de comunicação multi-agente baseado em turnos
• Suporta agentes humanos no circuito e agentes de chamada de função
• Rastreio transparente de mensagens e injeção de lógica personalizada

Passo 1: Identificar onde a sua lógica de agente único falha

Procure um local no seu bot ou sistema onde as coisas tenham começado a espalhar-se - prompts longos ou chamadas de ferramentas encadeadas que parecem aparafusadas. Esse é o seu ponto de entrada. Aqui estão alguns exemplos comuns que são fáceis de detetar:

1. Um fluxo de reembolso que analisa a entrada do utilizador, verifica a elegibilidade, emite o reembolso e envia a confirmação - tudo num único ciclo
2. Uma sequência de integração que recolhe dados, valida formulários, atribui tipos de utilizadores e dispara mensagens de correio eletrónico numa única cadeia de mensagens

Em vez de redesenhar todo o sistema, está apenas a isolar o fluxo de trabalho que já apresenta fissuras.

Etapa 2: Definir funções antes de tocar na estrutura

Depois de encontrar a lógica confusa, divida-a em responsabilidades reais.

Se algo está a validar um input, isso é um agente. Se algo está a tratar uma ação externa, é outro.

Escreva-o em linguagem simples - apenas o suficiente para expor onde se encontram as transferências.

E quando tudo estiver à sua frente, verá o que precisa realmente de ser separado e o que pode ser colapsado. Também lhe dá uma ideia do tipo de estrutura de que necessita.

Cada função deve parecer algo que se possa testar por si só.

Passo 3: Escolher o enquadramento

Escolha uma plataforma que se adapte ao seu estilo de fluxo de trabalho.

• Visual: Botpress, se quiser fluxos baseados em nós e memória com escopo.
• Código em primeiro lugar: LangChain ou CrewAI se se sentir confortável a ligar a lógica em Python.

A estrutura decide como os agentes são registados, acionados e ligados.

Passo 4: Criar o primeiro fluxo de trabalho

Agora, transforme essas funções em agentes. Defina-os dentro da sua estrutura - dê a cada um deles um nome, a sua função e qualquer ferramenta ou acesso à API de que necessite.

Quando estiverem no lugar, ligue-os. Utilize o encaminhamento fornecido pela estrutura para passar de um agente para outro.

O objetivo é ter um fluxo de trabalho completo a funcionar de ponta a ponta, com agentes que se mantêm na sua faixa.

Passo 5: Executar o sistema e inspecionar todas as transferências

Accione o fluxo de trabalho completo - do início ao fim - e acompanhe o que acontece. Deve observar o que cada agente recebe, o que devolve e se o fluxo se move corretamente entre eles.

Se um agente receber uma entrada confusa, é provável que o âmbito das coisas esteja errado. Se a lógica salta inesperadamente, o seu encaminhamento precisa de ser corrigido. 

Quando as transferências estiverem limpas, o sistema estará a funcionar.

Manter a lógica centralizada

Evite espalhar decisões críticas por vários agentes. É mais fácil de manter e testar quando o raciocínio chave acontece num único local em vez de ser dividido em partes pouco ligadas.

Definir antecipadamente as entradas e saídas do agente

Cada agente deve ter um contrato claramente definido: o que recebe e o que devolve. Isto facilita a troca de agentes ou a sua integração em novos fluxos de trabalho sem quebrar a lógica do fluxo.

Registar todas as mensagens transmitidas entre agentes

Se não conseguir ver o que os agentes estão a dizer uns aos outros, não pode depurar nada. Certifique-se de que todas as entradas e saídas sejam registradas com contexto suficiente para rastrear o fluxo.

Utilizar a memória com escopo para reduzir o ruído e os custos

Dê a cada agente apenas o contexto de que ele precisa. O acesso total à memória leva a prompts inchados, maior uso de token e comportamento imprevisível de agentes que deveriam estar focados.

Como posso saber se o meu projeto de IA precisa realmente de uma estrutura multiagente ou se um único agente é suficiente?

É provável que o seu projeto de IA precise de uma estrutura multiagente se os avisos ou fluxos de trabalho de um único agente se tornaram demasiado longos ou difíceis de depurar, especialmente quando se trata de várias tarefas distintas, ao passo que casos de utilização mais simples, como as perguntas e respostas básicas ou os bots de finalidade única, funcionam frequentemente bem com apenas um agente.

A construção com uma estrutura multi-agente destina-se apenas a projectos de grandes empresas ou também é adequada para pequenas empresas em fase de arranque?

Construir com uma estrutura multi-agente não é apenas para as grandes empresas - as pequenas empresas em fase de arranque também podem beneficiar, porque até os projectos mais modestos são mais fáceis de depurar quando as tarefas complexas são divididas por agentes especializados, em vez de se amontoar tudo num único ciclo grande e difícil de gerir.

A utilização de um sistema multiagente significa que tenho de dividir tudo em agentes separados ou posso misturar lógica de agente único e multiagente? 

Utilizar um sistema multiagente não significa que tenha de dividir tudo em agentes separados; pode misturar lógica de agente único para tarefas simples e reservar a orquestração multiagente para fluxos de trabalho complexos.

Em que é que um sistema multiagente difere da simples utilização de várias APIs ou microsserviços na minha aplicação?

Um sistema multiagente difere da utilização de várias API ou microsserviços porque coordena agentes de IA especializados com funções distintas e capacidades de raciocínio que passam mensagens estruturadas e estado, enquanto as API e os microsserviços tratam de funções discretas mas não orquestram independentemente fluxos de trabalho complexos.

Como é que o custo de funcionamento de sistemas multi-agentes se compara ao custo de funcionamento de um único grande LLM?

O custo da execução de sistemas multi-agentes pode ser inferior ao da execução de um único LLM de grandes dimensões, porque os agentes mais pequenos e especializados podem tratar de tarefas específicas de forma eficiente sem desperdiçar tokens em pedidos longos ou contextos repetidos, mas também introduz uma sobrecarga adicional para gerir a orquestração e a comunicação entre agentes, pelo que as poupanças dependem da complexidade do seu caso de utilização.