Análise comparativa de estruturas multiagentes: desafios e pontos fortes
Sistemas multiagentes utilizam agentes especializados que trabalham em conjunto para resolver tarefas complexas. Um desafio fundamental: o desempenho se degrada à medida que mais agentes e ferramentas são adicionados, ou os mecanismos de orquestração conseguem lidar com a crescente complexidade de forma eficiente?
Avaliamos 5 frameworks de agentes em 750 execuções com três tarefas. Medimos a latência, o consumo de tokens e a sobrecarga de orquestração para identificar quais padrões arquitetônicos mantêm a eficiência em grande escala e quais a degradam.
Avaliação comparativa de estrutura multiagente
Testamos como o uso de tokens e a latência escalam com o aumento do número de agentes e ferramentas. Em três tarefas com o mesmo problema, expandimos progressivamente a quantidade de agentes e a disponibilidade de ferramentas. Para LangChain e LangGraph, usamos configurações com um único agente para observar como suas arquiteturas sequenciais lidam com a mesma complexidade enfrentada por sistemas multiagentes.
Não incluímos no gráfico a estrutura com precisão inferior a 95% (Swarm). Você pode consultar nossa metodologia de avaliação comparativa.
Particularmente para o Swarm, observamos que a precisão variava em função dessa complexidade, impulsionada por diferenças arquitetônicas em vez de capacidades do modelo.
A precisão em frameworks agentivos geralmente pode ser melhorada por meio da seleção de LLM ( Modelo de Nível de Aprendizado) ou do ajuste de configuração. No entanto, examinar as causas arquitetônicas das variações de precisão em nosso benchmark revelou informações valiosas. Isso nos ajudou a entender as diferenças fundamentais de design entre os frameworks.
Resultados de benchmark da estrutura multiagente
O CrewAI força todos os agentes a executarem sequencialmente, causando um crescimento exponencial de tokens à medida que a saída de cada agente se acumula no contexto do próximo agente. Essa rigidez garante a completude, mas cria uma sobrecarga enorme.
O algoritmo Swarm prioriza a velocidade por meio de roteamento sem estado, mas sofre um colapso progressivo na precisão (84% → 0%) à medida que a complexidade da tarefa aumenta. Sem o rastreamento de estado global, os agentes terminam prematuramente, interrompendo cadeias de múltiplas etapas.
O LangChain utiliza um "superagente" de agente único com contexto unificado, evitando completamente a sobrecarga de coordenação. O desempenho permanece eficiente até que o tamanho da biblioteca de ferramentas (100 ferramentas) e a complexidade do raciocínio aumentem significativamente a latência.
O LangGraph iguala a confiabilidade do LangChain, mas adiciona sobrecarga de percurso no grafo. O custo de gerenciamento de estado torna-se pronunciado em alta complexidade, embora mantenha alta precisão.
O AutoGen gera um alto número de transferências de agentes por meio da coordenação baseada em chat, mas utiliza o GroupChatManager para remover dinamicamente agentes desnecessários. Isso impede o crescimento exponencial do CrewAI, mantendo alta precisão, embora o consumo de tokens permaneça maior do que o de agentes individuais devido ao reprocessamento do histórico de conversas.
CrewAI
O pipeline sequencial baseado em funções do CrewAI executava cada agente atribuído sem filtrar agentes irrelevantes ao longo do processo. Essa característica arquitetônica tem implicações significativas para sistemas de agentes, onde cada agente desempenha uma função crítica. Ela garante que a estrutura não ignore nenhuma etapa esperada e continue utilizando todos os agentes, em vez de tomar decisões de roteamento autônomas. No entanto, essa rigidez tem um custo elevado em termos de consumo de recursos e latência à medida que a complexidade da tarefa aumenta.
Crescimento exponencial de recursos em todas as tarefas
Da Tarefa 1 à Tarefa 3, observamos um aumento contínuo no consumo de tokens e na latência. A latência praticamente dobrou a cada aumento de tarefa, enquanto o consumo de tokens cresceu a uma taxa ainda mais drástica. O número de transferências de agentes aumentou naturalmente em paralelo com essa escalabilidade.
Por que o CrewAI consome mais tokens e tempo?
O pipeline sequencial da CrewAI alinhou-se naturalmente com ambos os fluxos de trabalho. Na Tarefa 1, o Analista de Dados coletou informações antes que o Árbitro tomasse decisões. Na Tarefa 2, esse padrão continuou com funções de agente expandidas. A CrewAI selecionou todas as ferramentas corretamente e demonstrou que a execução sequencial elimina a confusão de coordenação, com cada agente executando suas ferramentas designadas sem ambiguidade de roteamento.
No entanto, esse alinhamento natural veio acompanhado de custos indiretos substanciais e crescentes:
O mecanismo de composição do estado:
- Cada agente gera um relatório detalhado ao concluir sua tarefa.
- Este relatório é passado para o próximo agente na sequência.
- Quando o árbitro final recebe a transferência, ele lê um documento contendo o histórico e as saídas de todos os agentes anteriores, além de suas próprias instruções de sistema e metadados da ferramenta.
- O LLM gasta um tempo considerável lendo e regenerando grandes objetos de estado em Markdown entre tarefas.
Essa gestão de estado detalhada envolvia até mesmo pequenos pontos de dados em metadados de orquestração substanciais. O CrewAI prioriza a compreensão total do contexto em detrimento da eficiência.
Rigidez da tarefa 2-3:
- A estrutura executou todos os 5 agentes na sequência predefinida, mesmo quando apenas um subconjunto era estritamente necessário.
- Essa rigidez aumentou tanto os custos dos tokens quanto a latência, mantendo, ao mesmo tempo, alta precisão.
- A incapacidade da estrutura de ignorar agentes desnecessários tornou-se cada vez mais evidente como uma limitação arquitetônica fundamental.
- Cada agente adicional aumentava o contexto que os agentes subsequentes precisavam processar.
Enxame
O mecanismo de roteamento leve do Swarm demonstrou delegação multiagente genuína com sobrecarga mínima de orquestração. Um agente inicial coletava o contexto necessário, reconhecia ativamente quando sua tarefa estava concluída e transferia explicitamente a sessão para um agente de tomada de decisão distinto. Essa arquitetura sem estado priorizou velocidade e simplicidade, alcançando desempenho comparável a soluções de agente único em cenários simples. No entanto, à medida que a complexidade da tarefa aumentava, essa abordagem leve revelava limitações fundamentais de escalabilidade, onde a ausência de rastreamento de estado global e orquestração central causava um colapso progressivo da precisão.
Degradação progressiva da precisão ao longo das tarefas
Da Tarefa 1 à Tarefa 3, observamos um colapso drástico na precisão, apesar de mantermos altas velocidades de execução. A precisão caiu de 84% na Tarefa 1 para 22% na Tarefa 2, chegando finalmente a 0% na Tarefa 3. Essa degradação progressiva revelou que a arquitetura sem estado do Swarm, otimizada para velocidade em interações de curta duração, é fundamentalmente inviável para cadeias de raciocínio com múltiplas etapas.
Por que a precisão diminui à medida que aumentamos a complexidade?
O roteamento leve do Swarm manteve o consumo de tokens de conclusão extremamente baixo e a latência rápida em todas as tarefas. A estrutura operava como uma corrida de revezamento de agentes independentes sem estado global, onde cada agente tomava decisões autônomas de transferência sem supervisão central. Essa abordagem se destaca por minimizar o consumo de tokens e alcançar execução rápida, mas tem um custo elevado em confiabilidade e precisão à medida que os requisitos de persistência operacional aumentam.
O ponto cego arquitetônico:
Uma análise posterior dos registros revelou uma falha arquitetônica que não pôde ser resolvida apenas por meio de engenharia de prompts. Inicialmente, uma falha no prompt (ausência de instruções de transferência) foi identificada e corrigida. No entanto, mesmo com comandos de transferência explícitos, o Swarm não conseguiu completar a cadeia.
Como a estrutura é sem estado e não possui rastreamento global de intenções, o primeiro agente destinatário (por exemplo, Finanças) simplesmente emitiria um reconhecimento conversacional (por exemplo, "Dados recebidos, iniciando auditoria financeira") e encerraria a conversa. O Swarm interpreta qualquer fim de turno conversacional como conclusão da tarefa, levando aos resultados mais rápidos, porém menos eficazes. Sem um orquestrador central para manter o estado da tarefa e garantir que todas as etapas sejam executadas, a estrutura não consegue distinguir entre "o agente enviou um reconhecimento" e "a tarefa está totalmente concluída". Essa limitação fundamental significa que mesmo uma delegação multiagente genuína com transferências explícitas não pode garantir a conclusão da tarefa quando a cadeia se estende além de interações simples.
Tarefa 1-2: Problemas crescentes de precisão
Na Tarefa 1, onde o Swarm demonstrou um desempenho sólido com cadeias curtas de agentes, a estrutura ainda falhou em 16% das execuções devido à resolução incompleta da transferência de informações. Ao analisar os registros de conversas, descobrimos que o Árbitro tomou decisões com sucesso, mas o mecanismo de saída do Swarm exibiu a mensagem intermediária de transferência do Analista de Dados. Os usuários receberam a mensagem "Agora vou transferir esta informação para o Árbitro" em vez da decisão propriamente dita, revelando que os sistemas de roteamento dinâmico correm o risco de perder os resultados finais durante as transições de agentes.
Na Tarefa 2, com 5 opções de agentes e 20 ferramentas em escopo, a precisão diminuiu significativamente à medida que a estratégia de solicitação leve e com pouco contexto da estrutura começou a falhar sob o aumento da complexidade:
- A taxa de escolha da ferramenta correta caiu para 40%, representando uma queda de 20% em relação à Tarefa 1.
- Os agentes ocasionalmente acionavam ferramentas irrelevantes ou emitiam mensagens de roteamento quando se esperavam acionamentos de ferramentas reais.
- Os agentes às vezes tentavam usar ferramentas de um domínio incorreto ou repetiam chamadas que haviam falhado.
- Sem um controlador central, os agentes perdiam o controle do estado da execução ou eram transferidos para funções que pareciam conclusivas, mas que não haviam executado as chamadas de ferramentas necessárias.
Tarefa 3: O paradoxo da transferência de responsabilidade
A Tarefa 3 expôs a limitação arquitetônica fundamental do Swarm com 0% de precisão, apesar de manter a maior velocidade de execução. Essa falha completa revelou o que chamamos de "Paradoxo da Transferência": em uma cadeia de 10 agentes, o Swarm exige transferências 100% automatizadas em cada elo, mas sem um orquestrador central ou um grafo de estados (como o LangGraph), a cadeia se rompe no primeiro elo. Embora o Swarm se destaque em transferências ponto a ponto, ele falha em fluxos de trabalho com várias etapas que exigem persistência operacional em longas cadeias.
Esgotamento da cadeia de transferência:
Na Tarefa 1, com 1 transferência de informações, a cadeia era curta o suficiente para que o objetivo permanecesse dentro do contexto. No entanto, à medida que a cadeia se estendeu para 9 transferências na Tarefa 3, a probabilidade cumulativa de sucesso caiu para zero. Cada especialista adicional atuava como um "ponto de vazamento", onde uma resposta conversacional poderia encerrar o processo antes que o árbitro final fosse alcançado. Essa taxa de falha geométrica demonstra que o roteamento sem estado, embora otimizado para velocidade, não consegue ser escalado para maratonas de raciocínio em várias etapas.
LangChain
O LangChain executou tarefas como uma máquina de estados simples: receber o prompt, avaliar as ferramentas, executar e finalizar. Configuramos o LangChain como um executor de agente único, sem transições e com um único agente para todas as tarefas. Essa abordagem de contexto unificado manteve uma única entidade lógica durante toda a execução, sem saltos conversacionais e executando exatamente o que cada tarefa exigia, sem sobrecarga de orquestração. O modelo de execução linear da estrutura demonstrou que as tarefas que não exigem colaboração entre agentes se beneficiam significativamente da eliminação dos custos de coordenação inerentes aos sistemas multiagentes.
Escalabilidade eficiente até o limite de entropia da ferramenta
O LangChain manteve resultados corretos em todas as três tarefas. No entanto, a Tarefa 3 revelou a sensibilidade da estrutura ao tamanho da biblioteca de ferramentas e à complexidade do raciocínio, com a latência aumentando consideravelmente à medida que ambas as dimensões se expandiam.
Por que o LangChain continuou eficiente?
Tarefa 1-2: Vantagem de execução linear
Na Tarefa 1, o LangChain alcançou latência mínima e otimizou o uso de tokens com precisão na seleção de ferramentas. A estrutura evitou distrações com mecanismos de coordenação, processando apenas o necessário para concluir a tarefa. A arquitetura de agente único significou ausência de sobrecarga de comunicação entre agentes, geração de relatórios entre as etapas e conversas irrelevantes.
Na Tarefa 2, implementamos o LangChain usando uma arquitetura de "superagente", onde um único controlador tinha acesso direto a todas as 20 ferramentas. Ao consolidar as funções em uma única entidade lógica, a estrutura eliminou a necessidade de troca de dados entre agentes, geração de relatórios e preenchimento de diálogos. Esse modelo de execução linear garantiu que o LLM processasse apenas os resultados relevantes das ferramentas, evitando o crescimento exponencial do histórico de prompts observado em estruturas multiagentes.
A arquitetura de contexto unificada permitiu que a presença de 20 ferramentas na biblioteca não gerasse confusão na seleção. O agente único processava as chamadas de ferramentas sequencialmente, sem precisar coordenar ou negociar com outros agentes, mantendo a seleção correta das ferramentas apesar da biblioteca expandida. A ausência de transferências confirmou que nenhuma sobrecarga de orquestração foi introduzida com o aumento da complexidade.
Entropia da ferramenta e complexidade do raciocínio
A Tarefa 3 apresentou dois desafios significativos que impactaram o desempenho do LangChain:
Entropia da ferramenta:
Enquanto a Tarefa 1 tinha 5 ferramentas e a Tarefa 2 tinha 20 ferramentas, a Tarefa 3 apresentou 100 ferramentas disponíveis. Como o LangChain opera como um sistema de agente único, cada mensagem deve incluir as definições de todas as 100 ferramentas no prompt. Isso cria dois gargalos:
- O profissional de Direito deve avaliar 100 opções para selecionar a ferramenta correta, aumentando o tempo de processamento.
- O tamanho excessivo do prompt (contendo todas as definições de ferramentas) atrasa o tempo até o primeiro token do modelo, aumentando a latência geral.
Complexidade do raciocínio (10 funções de especialista):
Nas Tarefas 1 e 2, o agente simplesmente atuou como um árbitro, tomando uma decisão. Na Tarefa 3, o agente foi instruído a analisar sequencialmente 10 perspectivas de especialistas.
Essa instrução fez com que o modelo gerasse saídas significativamente mais longas, com um aumento substancial nos tokens de conclusão em comparação com a Tarefa 2. Mais texto gerado se traduz diretamente em um tempo de execução maior, já que o modelo precisa produzir cada token sequencialmente.
Apesar desses desafios, o LangChain manteve resultados corretos e nunca selecionou ferramentas incorretas. A estrutura de loop simples do framework (AgentExecutor) processou chamadas e respostas de ferramentas sem sobrecarga arquitetural adicional, mantendo os aumentos de latência proporcionais à complexidade inerente da tarefa, em vez de agravá-la com mecanismos de orquestração.
A abordagem arquitetônica do LangChain comprovou que a execução de contexto unificado pode manter a confiabilidade à medida que a complexidade aumenta, embora o desempenho se torne sensível ao tamanho da biblioteca de ferramentas e à profundidade do raciocínio. A capacidade da estrutura de produzir resultados corretos em todas as tarefas, evitando a explosão de tokens e a sobrecarga de coordenação de sistemas multiagentes, demonstrou o valor de modelos de execução linear para tarefas que não exigem colaboração entre agentes.
LangGraph
Conforme observado em nosso benchmark de frameworks agentivos, o LangGraph empregou uma arquitetura de máquina de estados com transições de estado explícitas e fluxo de controle baseado em grafos. Configuramos o LangGraph como um executor de agente único, sem transferências entre agentes e com um único agente para todas as tarefas. Essa abordagem eliminou completamente a comunicação entre agentes, ao mesmo tempo que forneceu um gerenciamento de estado estruturado que rastreava o progresso da execução por meio de nós e arestas definidos. O framework demonstrou que o rastreamento formal de estado pode coexistir com a execução de contexto unificado.
Confiabilidade consistente com sobrecarga de gerenciamento de gráficos
O LangGraph produziu resultados corretos em todas as três tarefas, sem erros. Nas Tarefas 1 e 2, o desempenho permaneceu praticamente idêntico ao do modelo de execução linear do LangChain. No entanto, a Tarefa 3 revelou aumentos de latência mais acentuados em comparação com o LangChain, expondo o custo computacional do gerenciamento de estado baseado em grafos sob alta entropia da ferramenta e complexidade de raciocínio.
Por que LangGraph correspondeu a LangChain?
O grafo de estados do LangGraph forneceu um fluxo de controle formal sem exigir múltiplos agentes. Em ambas as tarefas, a estrutura manteve zero transferências de responsabilidade, selecionando todas as ferramentas corretamente. O controlador único acessou todas as ferramentas necessárias diretamente, processando cada etapa por meio de transições de estado, em vez de transferências de responsabilidade entre agentes.
A implementação do "superagente" significou que a estrutura nunca dividiu a carga cognitiva entre múltiplas personas. A seleção de ferramentas permaneceu precisa mesmo com 20 ferramentas disponíveis na Tarefa 2, sem que o agente jamais selecionasse ferramentas incorretas ou irrelevantes. O contexto unificado impediu a confusão na seleção que afetava as estruturas que dependiam da coordenação entre agentes.
Por que o consumo de tokens coincidiu com o LangChain?
Ambas as estruturas utilizaram configuração LLM, definições de ferramentas e prompts do sistema idênticos. Ao contrário das estruturas multiagentes (AutoGen, CrewAI) que geram sobrecarga de coordenação por meio de conversas entre agentes e mensagens de coordenação intermediárias, ambas as estruturas de agente único consolidam toda a expertise em uma única chamada de modelo. Cada token gasto representa as instruções de entrada ou a saída direta, sem a sobrecarga intermediária de "Agente A falou com o Agente B". Além disso, ambas as estruturas invocam as mesmas ferramentas na mesma sequência para resolver a tarefa, recebendo dados idênticos do sistema subjacente, o que resulta em contagens de tokens de conclusão muito semelhantes. As diferenças de tokens entre as estruturas foram insignificantes porque o LLM realizou o mesmo trabalho de raciocínio em ambos os casos.
Tarefa 3: Sobrecarga de percurso em grafos amplificada
A Tarefa 3 apresentou os mesmos desafios enfrentados pelo LangChain (100 ferramentas e complexidade de raciocínio de 10 funções), mas a arquitetura baseada em grafos do LangGraph amplificou o impacto no desempenho:
Sobrecarga de entropia da ferramenta:
Assim como o LangChain, o LangGraph precisa incluir todas as 100 definições de ferramentas em cada solicitação devido à sua arquitetura de agente único. O LLM precisa avaliar toda a biblioteca de ferramentas para cada seleção, e o tamanho massivo das solicitações atrasa a geração da resposta.
Complexidade do raciocínio:
A instrução para analisar sequencialmente 10 perspectivas de especialistas fez com que o LangGraph gerasse resultados significativamente mais longos, assim como ocorreu com o LangChain. No entanto, a sobrecarga adicional do LangGraph tornou-se visível aqui.
Sobrecarga de gerenciamento de grafos:
Enquanto o LangChain usa uma estrutura de loop simples (AgentExecutor) que chama ferramentas e processa respostas, o LangGraph percorre toda a estrutura do grafo a cada passo. Para cada chamada de ferramenta:
- A estrutura deve percorrer o grafo completo do início ao fim.
- O histórico de mensagens (estado) é atualizado a cada transição de nó.
- O sistema valida as transições entre nós e mantém a consistência do estado.
Nas Tarefas 1 e 2, essa sobrecarga foi insignificante. Na Tarefa 3, com 100 ferramentas e requisitos complexos de raciocínio, essa sobrecarga de gerenciamento de grafos tornou-se substancial. A latência adicional em comparação com o LangChain refletiu diretamente o custo de manutenção e travessia da estrutura do grafo de estados sob alta complexidade.
Apesar dessa sobrecarga, o LangGraph nunca selecionou ferramentas incorretas, invocando consistentemente apenas as funções necessárias para concluir cada etapa. O rastreamento formal de estado da estrutura proporcionou um fluxo de controle estruturado, ao custo de um tempo de processamento maior.
A abordagem arquitetônica do LangGraph demonstrou que o gerenciamento explícito de estado pode manter sua confiabilidade à medida que a complexidade aumenta, embora a sobrecarga de percurso do grafo se torne mais pronunciada sob alta entropia da ferramenta e complexidade de raciocínio. Para aplicações que exigem auditabilidade, capacidade de reversão ou lógica de ramificação complexa, essa compensação pode valer a pena. Para execução sequencial direta, a estrutura adicional do LangGraph oferece valor limitado em comparação com modelos lineares mais simples, como o LangChain.
Autogen
O AutoGen consumiu consideravelmente mais recursos do que as soluções de agente único, embora não tenha atingido os níveis extremos do pipeline sequencial do CrewAI. A estrutura envolvia múltiplas conversas entre um UserProxy e agentes especializados. Cada interação nesse chat exigia uma passagem completa do LLM, que reprocessava todo o histórico da conversa até o momento.
No entanto, o AutoGen selecionou consistentemente as ferramentas corretas e produziu resultados precisos em todas as tarefas, sem recorrer a ferramentas irrelevantes. Isso introduziu uma sobrecarga de comunicação, na qual a estrutura gastou mais tempo coordenando do que executando. Para essa tarefa simples, a coordenação via chat do AutoGen tornou-se uma complexidade desnecessária, em vez de um benefício colaborativo.
A AutoGen empregou uma arquitetura baseada em chat, onde agentes especializados colaboram por meio de um UserProxy que gerencia a coordenação do fluxo de trabalho.
Configuramos o AutoGen usando o GroupChatManager em todas as três tarefas, permitindo a seleção dinâmica de agentes em vez de forçar a execução sequencial. Essa arquitetura demonstrou que a orquestração inteligente pode alcançar a colaboração multiagente sem os custos exponenciais de recursos de pipelines rígidos.
Alto número de transferências com desempenho competitivo
O AutoGen registrou o maior número de transferências entre todos os frameworks. Na Tarefa 1, o framework já atingiu níveis de transferência que o CrewAI só alcançou na Tarefa 3 (9 transferências). Isso refletiu a natureza conversacional do AutoGen: cada interação entre o UserProxy e os agentes especializados é registrada como uma transferência, mesmo quando se discute qual ferramenta utilizar.
No entanto, apesar do elevado número de transferências, a latência do AutoGen manteve-se competitiva com as estruturas sequenciais nas Tarefas 1 e 2. Na Tarefa 3, enquanto a sobrecarga da estrutura CrewAI atingiu 1,35 milhões de tokens, o AutoGen consumiu apenas 56.700 tokens (em comparação com os 13.500 e 13.600 tokens do LangChain e do LangGraph).
Por que o AutoGen consumiu mais tokens apesar da latência?
O AutoGen consumiu substancialmente mais tokens do que as soluções de agente único, embora não tenha atingido os níveis extremos do pipeline sequencial do CrewAI. A estrutura envolvia múltiplas conversas entre um UserProxy e agentes especializados. Cada interação nesse chat exigia uma passagem completa do LLM, que reprocessava todo o histórico da conversa até o momento.
Esse acúmulo recursivo de tokens explica por que o consumo de tokens do AutoGen permaneceu maior do que o do LangChain e do LangGraph, mesmo quando a latência se manteve competitiva. O histórico do chat cresce a cada interação, aumentando o tamanho das mensagens, mas o GroupChatManager do framework impede a explosão exponencial observada em pipelines sequenciais, eliminando agentes desnecessários.
No entanto, o AutoGen selecionou consistentemente as ferramentas corretas e produziu resultados precisos em todas as tarefas, sem acionar ferramentas irrelevantes. A sobrecarga de comunicação fez com que a estrutura gastasse mais tempo coordenando do que executando, mas essa coordenação garantiu que nenhum agente perdesse o foco ou acionasse ferramentas incorretas.
Gerenciador de bate-papo em grupo do AutoGen
O ponto forte da arquitetura do AutoGen: seleção dinâmica de agentes por meio do GroupChatManager. Ao contrário da orquestração sequencial da Tarefa 2, o modo GroupChat permitiu que a estrutura ativasse apenas os agentes necessários do conjunto disponível.
O Gerente removeu especialistas desnecessários, ativando apenas 5 ou 6 agentes do conjunto de 10 agentes. Assim que o Árbitro encontrou fundamentos suficientes para uma decisão, o Gerente encerrou o ciclo. Isso impediu o crescimento exponencial de tokens que ocorreria se o contexto fosse imposto sequencialmente a cada agente restante.
Essa poda dinâmica resultou em latência e consumo de tokens substancialmente menores em comparação com o pipeline sequencial rígido do CrewAI. Enquanto o CrewAI forçava todos os 10 agentes a executar a tarefa independentemente da necessidade, o GroupChat do AutoGen selecionava de forma adaptativa apenas os agentes necessários para chegar a uma decisão.
Apesar da sobrecarga de coordenação, o alto número de transferências refletiu uma deliberação minuciosa, na qual os agentes compararam as informações obtidas antes do encerramento. A capacidade do AutoGen de alternar entre os modos sequencial e de bate-papo em grupo oferece uma flexibilidade que arquiteturas rígidas não possuem, demonstrando que a orquestração baseada em bate-papo com seleção inteligente de agentes pode ser escalada de forma mais eficiente do que pipelines fixos para fluxos de trabalho complexos com múltiplos agentes.
Como funciona o AutoGen GroupChatManager:
- Em cada etapa, o Gerente decide “qual agente deve falar a seguir?” com base no contexto da conversa.
- Não é necessário que a estrutura execute todos os agentes sequencialmente.
- Se informações suficientes forem coletadas antecipadamente, o gerente poderá dispensar especialistas desnecessários.
- O gerente pode encerrar o ciclo assim que o agente tiver informações suficientes para tomar uma decisão.
O desafio "Por favor, continue": o comportamento padrão do AutoGen é manter as conversas ativas. Para testes de desempenho, sinais de término precisos são essenciais para evitar o "perda de tokens". Resolvemos isso garantindo que todos os agentes especializados incluam sinais explícitos de TERMINAR ao término da tarefa.
Sobrecarga do gerenciador: Mesmo com o GroupChatManager, o estado interno das mensagens do AutoGen é maior do que o do LangChain devido à orquestração multiagente. No entanto, isso proporciona registros e trilhas de deliberação significativamente mais estruturados do que frameworks mais simples.
Nota sobre sequencial vs. GroupChat: Executamos todas as tarefas usando o GroupChatManager. Em execuções experimentais com orquestração sequencial, observamos que o consumo de tokens e a latência dobraram em comparação com o modo GroupChat, confirmando que a seleção dinâmica de agentes proporciona ganhos substanciais de eficiência em relação aos pipelines fixos.
Metodologia de benchmark para frameworks multiagentes
Cada estrutura foi testada em 50 iterações (N=50) por tarefa.
Para eliminar a variabilidade no processo de raciocínio do modelo, todas as estruturas utilizaram a mesma configuração LLM. O modelo usado foi o openai/gpt-5.2 através da API OpenRouter. A temperatura foi definida como 0,0 .
Não foi imposto um limite máximo de tokens às respostas do LLM, permitindo que as estruturas utilizassem tanto contexto quanto sua arquitetura interna exigisse para resolver a tarefa.
As métricas coletadas incluem: número de chamadas à API LLM, transferências entre agentes, agentes únicos invocados, chamadas de ferramentas executadas e precisão das chamadas de ferramentas. Todas as métricas foram registradas por iteração e agregadas na amostra de 50 execuções.
Separamos as saídas brutas do LLM da sobrecarga adicional introduzida pela orquestração para medir a eficiência da orquestração. Os tokens de saída do LLM representam as respostas úteis reais geradas pelo modelo, enquanto a Sobrecarga da Estrutura engloba os comandos do sistema, as definições de ferramentas e os históricos de conversas que a estrutura deve fornecer ao LLM nos bastidores para obter essas respostas.
Essa métrica, calculada subtraindo os tokens de saída do total de tokens (Total – Tokens de saída), revela diretamente o “custo de gerenciamento” que a estrutura oculta do usuário. Graças a essa distinção, podemos ver quais estruturas permanecem eficientes e enxutas, em contraste com aquelas que carregam repetidamente grandes volumes de dados no LLM para cada etapa de orquestração. Baseamos nossa análise nos tokens de sobrecarga da estrutura como nossa principal métrica de eficiência.
Para garantir que as estruturas fossem avaliadas exclusivamente com base em sua lógica de coordenação, sincronizamos todas as outras variáveis. Isso eliminou fatores de confusão e isolou as diferenças arquitetônicas.
Os agentes foram definidos em um arquivo central. O wrapper de cada framework injetou a mesma string de persona em seu parâmetro nativo: `system_message` para AutoGen, `backstory` para CrewAI, `system prompts` para LangChain/LangGraph e `agent descriptions` para Swarm. Nenhuma engenharia de prompts específica do framework foi aplicada.
Cada framework utilizava as mesmas funções Python subjacentes. As definições das ferramentas, as docstrings e os esquemas de parâmetros foram padronizados. Nenhuma ferramenta pré-construída específica de cada framework foi utilizada. Isso garante que a lógica de execução das ferramentas seja consistente, diferindo apenas nos mecanismos de orquestração.
Em cada iteração, o conjunto de dados "DataCo Smart Supply Chain" foi fornecido aos agentes. Os dados de referência (status de envio, status de pagamento, margens de lucro) permaneceram constantes em todas as estruturas.
Mantendo as entradas idênticas, cada framework operou em seu modo estrutural nativo. Não forçamos os frameworks a adotarem arquiteturas não naturais. Em vez disso, implementamos cada framework de acordo com seu padrão de projeto pretendido para medir o desempenho no mundo real.
O AutoGen funciona como um sistema de bate-papo em grupo conversacional. Ele usa o comando `initiate_chats` com sinais `TERMINATE` para gerenciar as condições de saída. Os agentes se comunicam por meio de troca de mensagens, com um `UserProxy` coordenando o fluxo de trabalho.
CrewAI implementa um pipeline sequencial baseado em tarefas. Ele usa Process.sequential, onde os agentes executam em uma ordem fixa. Cada agente completa sua tarefa e gera um relatório antes que o próximo agente comece.
O LangChain segue uma arquitetura de cadeia linear. Ele usa um AgentExecutor padrão que encapsula o loop de chamada de ferramentas. O agente executa as ferramentas sequencialmente dentro de um único contexto.
O LangGraph estrutura a execução como um grafo de estados cíclico. Ele usa o StateGraph com nós representando etapas de processamento e arestas de roteamento condicional para determinar o fluxo.
O Swarm emprega rotinas baseadas em transferência de controle. Ele usa funções `transfer_to_agent` para transferir o controle dinamicamente entre agentes com base em decisões tomadas em tempo de execução.
As tarefas evoluíram em complexidade para testar diferentes capacidades de orquestração e modos de falha.
Tarefa 1 (2 Agentes / 5 Ferramentas): Testa a sobrecarga de orquestração básica para um fluxo de trabalho simples que requer a coleta de informações de pedidos e a tomada de decisões sobre reembolsos.
Tarefa 2 (5 Agentes / 20 Ferramentas): Testa a inteligência de roteamento em condições de ruído. Apenas 2 a 3 agentes e 3 a 5 ferramentas são necessários, mas 5 agentes e 20 ferramentas estão disponíveis.
Tarefa 3 (10 Agentes / 100 Ferramentas): Testa os limites de filtragem de alta entropia e escalabilidade. Apenas 2 a 3 agentes e 3 a 5 ferramentas são necessários, mas 10 agentes e 100 ferramentas estão disponíveis, incluindo 98 ferramentas de ruído irrelevantes projetadas para confundir o roteamento.
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios.