Os 5 principais frameworks de IA agente de código aberto em 2026
Avaliamos o desempenho de 4 frameworks de agentes de código aberto populares em 2.000 execuções (5 tarefas, 100 execuções para cada framework), medindo a latência de ponta a ponta, o consumo de tokens e as diferenças arquitetônicas.
Análise comparativa de frameworks de IA agéticos
Analisamos como as próprias estruturas influenciam o comportamento do agente e o impacto resultante na latência e no consumo de tokens.
O LangGraph é o framework mais rápido, com os menores valores de latência em todas as tarefas, enquanto o LangChain apresenta a maior latência e o maior consumo de tokens.
Em 5 tarefas e 2.000 execuções, o LangChain se destaca como o framework mais eficiente em termos de tokens, enquanto o AutoGen lidera em latência; LangGraph e LangChain vêm logo em seguida. O CrewAI apresenta o perfil geral mais pesado.
Você pode ver nossa metodologia em detalhes aqui.
Tarefa 1: Agregação básica
Primeiramente, medimos a sobrecarga de cada framework ao simplesmente chamar uma única ferramenta e retornar o resultado, sem realizar nenhum raciocínio complexo.
LangChain e LangGraph: Para tarefas simples, eles têm um desempenho quase tão rápido quanto o código não-agente, ambos terminando em menos de 5 segundos com menos de 900 tokens de prompt. A arquitetura de máquina de estados do LangGraph não introduz latência perceptível em comparação com o LangChain nesse nível de simplicidade; a sobrecarga do gerenciamento de estado só se materializa à medida que a complexidade da tarefa aumenta.
AutoGen: Apresenta desempenho ligeiramente superior ao LangChain e ao LangGraph tanto em latência quanto em uso de tokens, refletindo o custo básico de seu loop de conversação multiagente, no qual dois agentes trocam mensagens mesmo para uma tarefa de etapa única.
CrewAI: Mesmo quando solicitada a fazer uma única chamada de ferramenta, apresenta o que poderia ser chamado de "sobrecarga gerencial", consumindo quase 3 vezes mais tokens que a LangChain e levando quase 3 vezes mais tempo. O processo de verificação em várias etapas entre suas personas de Planejador e Analista oferece uma abordagem completa, porém dispendiosa em recursos, que prioriza a completude em detrimento da velocidade. Esse custo é estrutural: ele se manifesta independentemente da complexidade da tarefa.
Tarefa 2: Análise comparativa de receitas (gestão estatal)
Na Tarefa 2, queríamos verificar a capacidade dos frameworks de manter dois grupos de filtros diferentes na memória (Persistência de Estado) e combiná-los.
CrewAI
Em nossa análise de logs, descobrimos que o CrewAI oferece o maior nível de transparência de infraestrutura entre as estruturas testadas, mas ao custo do maior consumo de recursos.
Em vez de retornar imediatamente os dados recuperados, o CrewAI valida repetidamente seus próprios processos por meio de um mecanismo de autoavaliação. Esse comportamento exploratório fez com que ele atingisse o limite configurado de max_iter=10, deixando algumas execuções presas em um loop de processamento contínuo sem produzir uma saída JSON.
A causa principal desse comportamento é que o CrewAI injeta instruções em múltiplas camadas no prompt do sistema, atribuindo a cada agente um papel, um objetivo e uma história de fundo, enquanto impõe um ciclo de Pensamento → Ação → Observação no estilo ReAct a cada etapa. Mesmo para tarefas simples, o LLM não consegue pular essa etapa e produz diligentemente monólogos internos prolixos, o que se agrava ainda mais em cenários com múltiplos agentes.
O CrewAI consumiu quase o dobro de tokens em comparação com os outros frameworks e levou mais de três vezes o tempo de execução do LangChain, tornando-o mais adequado para transições de estado complexas e tomada de decisões multifatoriais do que para tarefas simples de recuperação de dados.
LangChain
O framework mais rápido e econômico. Em nossos registros, observamos que o LangChain completa a tarefa em 5 a 6 etapas, sem desvios: Carregar → Filtrar → Calcular → Filtrar → Calcular → Exibir. Como seu gerenciamento de estado é muito simples, a sobrecarga é quase zero e a latência é a menor entre todos os frameworks.
Geração automática
Apresentou um desempenho muito equilibrado. Na Tarefa 2, igualou-se quase exatamente ao LangGraph tanto no uso de tokens quanto na latência, demonstrando que a sobrecarga do loop de conversação não aumenta significativamente quando a cadeia de tarefas permanece linear.
No entanto, ocasionalmente, adiciona uma etapa extra de verificação para confirmar os parâmetros durante o processo de chamada da ferramenta, tornando-o um pouco mais lento que o LangChain. Quando encontra um erro em uma chamada de ferramenta ou os dados não retornam como esperado, atualiza imediatamente seu raciocínio na próxima etapa e chega ao JSON correto. Como gerencia as saídas das ferramentas como um fluxo conversacional, é um dos frameworks mais resilientes a erros lógicos.
LangGraph
Nesta tarefa, o LangGraph se mostrou o framework mais estável graças à sua arquitetura baseada em grafos. Em seus registros, observamos que o estado é mantido de forma muito limpa durante toda a execução. O risco de contaminação de dados ou de segmentos interferindo uns nos outros é mínimo neste framework. Em todas as 100 execuções, ele produziu resultados em um número de passos praticamente igual e dentro da mesma faixa de latência.
Tarefa 3: Análise de limiar (disciplina numérica)
Nesta tarefa, queríamos verificar com que precisão as estruturas traduzem condições numéricas em linguagem natural, como "menos de 1 ano de permanência no cargo" e "mais de US$ 70 em encargos mensais", em parâmetros precisos da ferramenta, como tenure_max=12 e charges_min=70.0.
O LLM já sabe como fazer essa conversão; o que realmente queríamos testar era se a estrutura consegue proteger esses parâmetros em seus próprios mecanismos de repetição, contexto de nova solicitação e ciclos de gerenciamento de estado.
LangChain e LangGraph
Ambas as estruturas passaram os parâmetros (tenure_max=12, charges_min=70) diretamente para a ferramenta, exatamente como o LLM os gerou, sem qualquer modificação ou repetição de prompts. Essa eficiência se reflete nos números: ambas as estruturas concluíram a Tarefa 3 em menos de 9 segundos, com menos de 1.800 prompts, o menor número nessa tarefa.
Quando quisemos medir se os limites numéricos são preservados sem interferência da estrutura, estes dois parâmetros corresponderam às nossas expectativas: qualquer parâmetro gerado foi o que foi executado.
Geração automática
O Autogen obteve sucesso total na correção numérica. Em algumas execuções, observou-se que a estrutura adicionou uma etapa de verificação antes de passar o parâmetro gerado pelo LLM para a ferramenta, o que significa que a estrutura gastou uma etapa extra, preservando o parâmetro. Com 2.480 tokens e 8 segundos, a latência foi igual à do LangChain, apesar da etapa extra, confirmando que a sobrecarga de verificação é real, mas pequena. Atendeu às nossas expectativas em termos de integridade do parâmetro, com a etapa de confirmação introduzindo apenas um custo marginal em tokens, em vez de uma penalidade de latência significativa.
CrewAI
O comportamento mais notável foi observado no CrewAI, que concluiu a Tarefa 3 em 30 segundos com 4.360 tokens, o maior número nessa tarefa. Dois padrões distintos de falha emergiram da análise dos registros.
Em algumas execuções, um valor que deveria ser 68,81% foi retornado como 0,6878 (razão decimal). Isso indica que a serialização de saída da estrutura pode remover a saída do LLM de seu contexto original.
Os registros mostram que o LLM inicialmente gerou os parâmetros corretos, tenure_max=12 e charges_min=70. No entanto, quando o CrewAI entrou em um loop de "Falha ao analisar", a estrutura forçou o LLM a reconsiderar. No contexto de nova solicitação, o LLM alterou o limite para tenure_max=14 e desativou completamente o filtro charges_min, produzindo uma taxa de cancelamento de 46,84%, que é, na verdade, a taxa de cancelamento de todos os clientes com tempo de relacionamento inferior a 14 anos. Este era exatamente o cenário que queríamos observar: o mecanismo de repetição da estrutura pode corromper um parâmetro que o LLM já havia obtido corretamente.
Tarefa 4: Resiliência a erros e capacidade de pivotar
Nesta tarefa, queríamos ver como cada framework lida com cenários disruptivos e observar o impacto na latência e no consumo de tokens. A ferramenta gera 3 tipos diferentes de erros em sequência (Rede, Tempo Limite Excedido, Limite de Taxa), colocando o agente em uma situação crítica. Os dois primeiros erros instruem o agente a tentar novamente e, após ambas as tentativas, o erro de Limite de Taxa recebido instrui o agente a aguardar 10 segundos. Assim que o agente aguarda e tenta novamente, a ferramenta começa a funcionar normalmente.
LangGraph e Autogen
Essas duas estruturas encontraram soluções alternativas de forma autônoma quando confrontadas com falhas das ferramentas nessa tarefa.
Quando a ferramenta retornou um aviso de limite de taxa, em vez de pausar e esperar, esses agentes decidiram abandonar completamente a ferramenta com defeito e encontrar um caminho alternativo. A abordagem deles foi: “Já que essa ferramenta não está funcionando, vou filtrar cada método de pagamento individualmente, calcular a taxa de cancelamento para cada um separadamente e, em seguida, combinar os resultados eu mesmo.”
Método: Em vez de realizar a tarefa com uma única chamada de ferramenta, eles a dividiram usando duas ferramentas separadas, uma para filtragem e outra para cálculo, processando cada método de pagamento (cheque eletrônico, cheque enviado pelo correio, etc.) individualmente.
Esses agentes operam com raciocínio orientado a objetivos, em vez de dependência de trajetória. Se o caminho mais curto não estiver disponível, eles podem construir um plano de execução alternativo em segundos.
O LangGraph atingiu 15.010 tokens de prompt na Tarefa 4, a maior contagem de tokens em uma única tarefa em todo o benchmark, porque sua máquina de estados acumulou o histórico crescente de cada chamada manual de ferramenta de volta ao contexto a cada passo. O AutoGen veio em seguida com 10.750 tokens, ligeiramente mais contido devido ao seu tratamento conversacional de resultados intermediários. Apesar disso, ambos terminaram em torno de 24 a 27 segundos, confirmando que o custo adicional de tokens não se traduziu em latência significativa, pois a própria transição foi rápida.
CrewAI
Apesar de ter apresentado o maior consumo de tokens nas tarefas anteriores, a CrewAI exibiu o menor uso de tokens, mas os maiores valores de latência nesta tarefa.
Por que o token de menor valor?
Ao contrário de seus concorrentes, a CrewAI não recorreu a soluções manuais complexas de 10 a 15 etapas. Quando encontrava erros, em vez de inserir repetidamente todo o histórico e os dados intermediários complexos no LLM a cada passo, ela construiu um circuito de raciocínio mais focado e modular. Ao evitar verbosidade desnecessária, tornou-se a estrutura mais eficiente em termos de custo para essa tarefa.
Por que alta latência?
A estrutura gerencial do CrewAI pausa e reavalia o plano quando encontra um erro. Ao receber o aviso de espera de 10 segundos, o sistema dedicou mais tempo à fase de "planejamento estratégico". Além disso, em vez de recorrer a outra ferramenta de filtragem, optou persistentemente por aguardar a recuperação da ferramenta principal ou tentar novamente com a ferramenta estável, o que prolongou a duração total do processo.
LangChain
A LangChain passou por sua transformação mais significativa nessa tarefa, comprovando por que a resiliência depende de uma configuração adequada.
Em nosso teste inicial, o LangChain apresentou falha em todas as tentativas, com um erro de conexão (ConnectionError).
O AgentExecutor padrão do LangChain trata exceções Python brutas lançadas de dentro de uma ferramenta como erros fatais e encerra o processo. Ao contrário de seus concorrentes, ele não aplica, por padrão, a filosofia de que "erros são observações". Como o agente nunca vê o erro, ele não tem a chance de raciocinar sobre ele.
Envolvemos a chamada da ferramenta dentro de langchain_agent.py com um bloco try-except. Isso converteu o erro em uma mensagem legível que o agente pôde processar.
Comportamento pós-correção: Após a aplicação da correção, observamos nos registros do LangChain que ele apresentou exatamente o mesmo raciocínio que o LangGraph. Recebeu 3 erros da ferramenta, mudou imediatamente de estratégia e passou a usar duas ferramentas separadas, uma para filtragem e outra para cálculo, processando cada método de pagamento individualmente e combinando os resultados.
O LangChain é tão capaz e adaptável quanto o LangGraph, mas como o tratamento de erros do framework estava desativado por padrão, não teve a oportunidade de demonstrar essa capacidade. Uma vez configurado corretamente, alcançou o resultado correto usando a mesma abordagem de caminho alternativo.
Por que essas diferenças ocorreram? (análise da arquitetura da estrutura)
Se o comportamento do agente dependesse exclusivamente do LLM (GPT-5.2), todas as estruturas deveriam ter se comportado de maneira semelhante. No entanto, as diferenças claras nessas proporções estão enraizadas nos próprios mecanismos de loop interno das estruturas:
1. LangGraph e AutoGen (pivô de 90%):
O LangGraph opera em uma arquitetura de Máquina de Estados, enquanto o AutoGen funciona em um modelo baseado em Conversação. Em ambos os sistemas, os erros são processados como um ciclo de feedback. No LangGraph, o estado que recebe o erro passa para o próximo nó; no AutoGen, o agente Proxy encaminha o erro para o assistente como uma mensagem de chat. Esse mecanismo de incentivo constante força o agente a continuar buscando uma solução. Como o agente é repetidamente confrontado com a pergunta "Ocorreu um erro, o que devo fazer?", a probabilidade de ele decidir seguir um caminho manual alternativo aumenta para 90%.
2. LangChain (65% Pivô / 35% Espera):
O LangChain opera em uma arquitetura AgentExecutor sequencial. Mesmo com tratamento de erros implementado, seu loop de execução possui uma estrutura mais linear e está focado principalmente em produzir uma Resposta Final. Se a ferramenta gerar erros por 3 a 4 etapas, o LangChain às vezes prefere esperar que a ferramenta tenha sucesso na próxima tentativa ou produza um resultado a partir do contexto existente, em vez de recorrer a uma estratégia alternativa. Como o bloqueio de estado do LangChain é mais flexível do que o do LangGraph, sua proporção de espera/solução direta fica em torno de 35%.
3. CrewAI (0% de pivô):
A CrewAI opera com uma arquitetura de Processo Gerencial. Seus agentes são estruturados em definições de Funções e Tarefas. Quando ocorrem erros, sua arquitetura interna normalmente aciona a lógica de Autocorreção ou Repetição. No entanto, uma mudança radical de estratégia, como "vamos descartar todo o plano e fazer a filtragem manual em 5 etapas", entra em conflito com a estrutura de planejamento gerencial da CrewAI. Ela opera com a disciplina de "devo corrigir a ferramenta que me foi dada ou usar a alternativa mais próxima", em vez de abandonar o plano por completo. Essa é fundamentalmente uma abordagem centrada no plano, em oposição a uma abordagem centrada em objetivos.
Tarefa 5: Orquestração de dados não estruturados (roteamento de dados não estruturados)
Na tarefa 5, observamos como as estruturas se comportam ao encontrarem colunas JSON e de texto longo (LongText) em um arquivo CSV. Os agentes precisavam primeiro descobrir o tipo de dados dessas colunas e, em seguida, selecionar as ferramentas de processamento corretas, seja sequencialmente ou em paralelo.
No mundo real, o gerenciamento de dados não estruturados exige que um agente vá além dos dados tabulares padrão e trabalhe com blocos JSON, parágrafos de texto livre ou objetos aninhados.
Para que uma estrutura lide corretamente com esse tipo de dados, ela precisa fazer duas coisas bem:
1- Uma inteligência de descoberta que entende qual ferramenta se adequa a qual tipo de dados.
2- Um mecanismo de orquestração que coordena múltiplas chamadas de ferramentas independentes.
Concebemos a Tarefa 5 especificamente para medir essas duas capacidades separadamente.
Geração automática
O AutoGen apresentou um desempenho sólido nesta tarefa, terminando com 8.170 tokens de prompt e uma latência mediana de 47 segundos, o resultado mais rápido e com maior eficiência de tokens na Tarefa 5.
O ciclo de conversação no núcleo de sua arquitetura, a troca de mensagens entre o AssistantAgent e o UserProxyAgent, é normalmente visto como uma estrutura que leva à verbosidade. No entanto, na Tarefa 5, essa estrutura se tornou uma vantagem.
Ao analisar o histórico da conversa, o LLM reconheceu que as colunas Metadata e SupportNotes eram independentes entre si. Em seguida, enviou uma única resposta TOOL CALLS listando 4 ferramentas simultaneamente: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…) e summarize_text_column(…) foram executadas em paralelo. Isso permitiu que a tarefa fosse concluída em apenas 3 iterações do LLM, com o menor número de tokens e o menor número de etapas.
A razão técnica por trás desse comportamento é clara: o mecanismo de execução de ferramentas do AutoGen executa a lista `tool_calls` retornada pelo LLM de forma atômica e coleta os resultados em uma única etapa de conversa. A filosofia de "gerenciar a conversa" da estrutura permite naturalmente que vários canais paralelos sejam abertos simultaneamente, e os números de token e latência confirmam isso diretamente.
LangGraph
O LangGraph terminou com 9.150 tokens de prompt e uma mediana de 70 segundos, próximo ao AutoGen em número de tokens, mas mais lento em tempo. Sua arquitetura de Máquina de Estados exibiu simultaneamente sua maior força e sua fraqueza mais notável na Tarefa 5.
Em cada execução, o loop nó llm → nó de ferramentas → nó llm acumula todas as saídas anteriores das ferramentas no estado e as passa para o LLM. Essa estrutura garante que o agente nunca se esqueça de nada, o que normalmente é uma vantagem significativa.
No entanto, na Tarefa 5, essa mesma vantagem se voltou contra o LangGraph. O LangGraph encontrava as ferramentas corretas e construía o segmento correto. Mas, mesmo após a conclusão da análise, detectava ambiguidades no estado acumulado, interpretando etapas já concluídas como ainda pendentes e acionando repetidamente chamadas adicionais de ferramentas. Mesmo tendo recuperado os dados necessários e estando prestes a produzir a resposta correta, o sinal de "etapa ausente" da máquina de estados era acionado e o agente entrava em loops desnecessários. Como resultado, o número de chamadas de ferramentas por execução variava entre 6 e 16. A capacidade do estado de "nunca esquecer nada" às vezes fazia com que etapas concluídas parecessem incompletas, puxando o agente de volta para ciclos redundantes e aumentando a latência em 23 segundos acima do AutoGen, apesar de uma contagem de tokens comparável.
CrewAI
O desempenho da Tarefa 5 do CrewAI apresentou a maior variação em todo o benchmark. Em algumas execuções, seguiu uma sequência impecável com apenas 5 chamadas de ferramentas, sem desvios, executando como um script. Nessas execuções, a estrutura gerencial do CrewAI, definida por papéis e tarefas, funcionou exatamente como esperado: quando o agente compreendia claramente seu papel, comportava-se de forma previsível e disciplinada.
No entanto, em outras execuções (por exemplo, execução 16: 35 chamadas de ferramenta), o caos se instaurou. A causa principal foi o monólogo interno (Pensamento) gerado pelo CrewAI a cada passo. Após construir corretamente o segmento com o filtro adequado, o monólogo interno do agente começou a questionar se filtros adicionais também deveriam ser aplicados. Ao ver o resultado, ele duvidou se o segmento atual era válido ou se o anterior deveria ter precedência. Essa dúvida o levou a recarregar os dados do zero. Então, ele filtrou novamente, entrou em outro loop de verificação, duvidou novamente e repetiu essa espiral 8 vezes.
No CrewAI, cada Pensamento gera uma avaliação independente, e essas avaliações ocasionalmente invalidam etapas previamente verificadas. O reflexo de "verificação contínua" do Processo Gerencial, em algumas execuções, levou o agente a questionar novamente suas próprias decisões corretas.
LangChain
A estrutura AgentExecutor do LangChain é inerentemente sequencial, e a Tarefa 5 foi onde essa limitação se tornou mais evidente. Com 10.070 tokens de prompt e uma mediana de 86 segundos, foi o framework mais lento nessa tarefa, apesar de não ter o maior número de tokens.
Em cada etapa, o processo realiza uma única chamada de ferramenta, recebe o resultado e prossegue, o que significa que 4 ferramentas independentes exigiram 4 iterações separadas do LLM com 4 períodos de espera distintos. A mediana de 47 segundos do AutoGen, em comparação com os 86 segundos do LangChain, é uma medida direta do custo da execução sequencial versus a execução paralela.
Na Tarefa 5, o número de ferramentas do LangChain geralmente se estabilizava em 9 ou 15. Esses dois agrupamentos apontam para duas estratégias típicas: em algumas execuções, ele pulou a etapa de inspeção e foi diretamente para a análise sintática e o resumo (9 ferramentas), enquanto em outras inspecionou cada coluna primeiro antes do processamento (15 ferramentas). A identidade de executor linear do LangChain ficou clara aqui: ele não exibiu nem a eficiência paralela do AutoGen nem o caos monológico do CrewAI.
Gestão de dados não estruturados e arquitetura de framework
Os resultados desta tarefa revelam que a eficiência com que uma estrutura consegue gerir dados não estruturados (JSON, LongText) está diretamente ligada ao seu mecanismo de loop interno:
Frameworks capazes de realizar chamadas de ferramentas em paralelo (AutoGen) podem processar colunas de dados independentes em uma única etapa. Em cenários reais envolvendo grandes objetos JSON e inúmeras colunas de texto, essa diferença se traduz em uma enorme vantagem em termos de custo e velocidade.
Frameworks com loops orientados a estado (LangGraph) se destacam na consistência de dados, mas apresentam o risco de reavaliar etapas já concluídas e acumuladas no histórico.
As estruturas baseadas em monólogos (CrewAI) são profundamente capazes de compreender o tipo e o significado dos dados, mas essa profundidade às vezes se transforma em questionamentos excessivos e repetições.
Os frameworks de execução linear (LangChain) processam diferentes ramos de dados não estruturados separadamente, produzindo um resultado intermediário entre os dois mundos.
Crescimento exponencial de frameworks agentivos no GitHub
Comparar estruturas de IA agéticas
As estruturas de IA agente variam em diversas dimensões-chave, e compreender essas diferenças é essencial para fazer comparações significativas.
Orquestração multiagente
A orquestração multiagente coordena múltiplos agentes de IA especializados para lidar com fluxos de trabalho complexos que excedem as capacidades de um único agente. Em vez de construir um agente monolítico, a orquestração divide o trabalho entre agentes com funções, ferramentas e conhecimentos distintos. Cada framework oferece abordagens diferentes para a coordenação de agentes.
LangGraph
LangGraph é um framework relativamente conhecido e se destaca como uma opção fundamental para desenvolvedores que criam sistemas de agentes.
Coordenação explícita de múltiplos agentes: Você pode modelar múltiplos agentes como nós individuais ou grupos, cada um com sua própria lógica, memória e função no sistema.
Cria fluxos de trabalho de IA em diversas APIs e ferramentas. Portanto, é uma boa opção para arquiteturas RAG e pipelines personalizados.
Geração automática
O AutoGen permite que vários agentes se comuniquem passando mensagens em um loop. Cada agente pode responder, refletir ou chamar ferramentas com base em sua lógica interna.
Possui colaboração assíncrona entre agentes, o que a torna particularmente útil para cenários de pesquisa e prototipagem onde o comportamento do agente requer experimentação ou refinamento iterativo.
CrewAI
O CrewAI lida com a maior parte da lógica de baixo nível para você e fornece orquestração multiagente:
- Integra-se com ferramentas de monitoramento para rastreamento e depuração.
- Controle de execução integrado por meio de fluxos com lógica condicional, loops e gerenciamento de estado.
- Suporta coordenação multiagente hierárquica (gerente-operário) e estruturada.
OpenAI Enxame
Swarm é uma estrutura multiagente leve e experimental para prototipagem. Os agentes trabalham sequencialmente por meio de transferências, transferindo tarefas enquanto mantêm um contexto compartilhado. Utiliza rotinas de linguagem natural e ferramentas Python para fluxos de trabalho flexíveis.
LangChain
LangChain é uma estrutura para a construção de aplicações LLM de agente único com ferramentas RAG. Ela fornece componentes modulares, incluindo cadeias, ferramentas, memória e recuperação para fluxos de trabalho de processamento de documentos.
O LangChain opera principalmente por meio de padrões de execução de agente único, onde um agente gerencia o fluxo de trabalho.
Definição de agente e função
LangGraph
O LangGraph adota uma abordagem baseada em grafos para o design de agentes, onde cada agente é representado como um nó que mantém seu próprio estado. Esses nós são conectados por meio de um grafo direcionado, permitindo lógica condicional, coordenação entre múltiplas equipes e controle hierárquico. Isso possibilita a criação e visualização de grafos multiagentes com nós supervisores para orquestração escalável.
O LangGraph utiliza funções estruturadas e anotadas que associam ferramentas a agentes. Você pode criar nós, conectá-los a diversos supervisores e visualizar como diferentes equipes interagem. Imagine como se estivesse fornecendo a cada membro da equipe uma descrição de cargo detalhada. Isso facilita a criação e o teste de agentes que trabalham em conjunto.
Geração automática
O AutoGen define agentes como unidades adaptáveis capazes de roteamento flexível e comunicação assíncrona. Os agentes interagem entre si (e opcionalmente com humanos) trocando mensagens, permitindo a resolução colaborativa de problemas. Assim como o LangGraph usa funções estruturadas e anotadas .
CrewAI
A CrewAI adota uma abordagem de design baseada em funções . A cada agente é atribuída uma função (por exemplo, Pesquisador, Desenvolvedor) e um conjunto de habilidades, funções ou ferramentas às quais ele pode ter acesso. A definição de funções é feita por meio de anotações estruturadas .
OpenAI Enxame
O Swarm utiliza um modelo baseado em rotinas, onde os agentes são definidos por meio de prompts e docstrings de funções. Ele não possui orquestração formal ou modelos de estado, dependendo, em vez disso, de fluxos de trabalho estruturados manualmente. O comportamento das funções é inferido pelo LLM por meio de docstrings (o Swarm identifica o que uma função faz lendo sua descrição), tornando essa configuração flexível, porém menos precisa.
LangChain
O LangChain utiliza uma arquitetura baseada em cadeia, onde um único agente orquestrador gerencia as chamadas para modelos de linguagem e diversas ferramentas. Ele define funções por meio de interfaces explícitas, como kits de ferramentas e modelos de prompts.
Embora seja focado principalmente em fluxos de trabalho centralizados, o LangChain oferece suporte a extensões para configurações multiagentes, mas não possui comunicação integrada entre agentes.
Memória
Capacidade de memória :
- Com estado : Indica se a estrutura suporta memória persistente entre execuções.
- Contextual : Indica se o sistema suporta memória de curto prazo por meio do histórico de mensagens ou da passagem de contexto.
A capacidade de memorização é fundamental para a construção de sistemas agentes que conseguem lembrar o contexto e se adaptar ao longo do tempo:
- Memória de curto prazo : Mantém o controle das interações recentes, permitindo que os agentes lidem com conversas de várias etapas ou fluxos de trabalho passo a passo.
- Memória de longo prazo : Armazena informações persistentes entre sessões, como preferências do usuário ou histórico de tarefas.
- Memória de entidades : rastreia e atualiza o conhecimento sobre objetos, pessoas ou conceitos específicos mencionados durante as interações (por exemplo, lembrar o nome de uma empresa ou o ID de um projeto mencionado anteriormente).
LangGraph
O LangGraph utiliza dois tipos de memória: memória interna (in-thread) , que armazena informações durante uma única tarefa ou conversa, e memória entre threads (cross-thread) , que salva dados entre sessões. Os desenvolvedores podem usar MemorySaver para salvar o fluxo de uma tarefa e vinculá-lo a um thread_id específico. Para armazenamento de longo prazo, o LangGraph suporta ferramentas como InMemoryStore ou outros bancos de dados. Isso proporciona controle flexível sobre como a memória é alocada e retida entre as execuções.
Geração automática
O AutoGen utiliza um modelo de memória contextual . Cada agente mantém o contexto de curto prazo por meio de um objeto context_variables, que armazena o histórico de interações. Ele não possui memória persistente integrada.
CrewAI
CrewAI Oferece memória em camadas pronta para uso. Armazena memória de curto prazo em um repositório vetorial ChromaDB, resultados de tarefas recentes em SQLite e memória de longo prazo em uma tabela SQLite separada (com base nas descrições das tarefas). Além disso, suporta memória de entidades usando embeddings vetoriais. Essa configuração de memória é configurada automaticamente quando `memory=True` está habilitado.
OpenAI Enxame
O Swarm não mantém estado e não gerencia memória nativamente. Os desenvolvedores podem passar memória de curto prazo manualmente através de context_variables e, opcionalmente, integrar ferramentas externas ou camadas de memória de terceiros (por exemplo, mem0) para armazenar contexto de longo prazo.
LangChain
O LangChain oferece suporte a memória de curto e longo prazo por meio de componentes flexíveis. A memória de curto prazo é normalmente gerenciada por meio de buffers na memória que rastreiam o histórico da conversa dentro de uma sessão. Para memória de longo prazo, o LangChain se integra a armazenamentos vetoriais ou bancos de dados externos para persistir embeddings e dados de recuperação.
Os desenvolvedores podem personalizar os escopos e estratégias de memória usando classes de memória integradas, permitindo o gerenciamento eficiente da memória contextual e específica da entidade em todas as interações.
Intervenção humana
LangGraph
O LangGraph suporta pontos de interrupção personalizados (interrupt_before) para pausar o gráfico e aguardar a entrada do usuário durante a execução.
Geração automática
O AutoGen oferece suporte nativo a agentes humanos por meio do recurso UserProxyAgent, permitindo que humanos revisem, aprovem ou modifiquem etapas durante a colaboração entre agentes.
CrewAI :
O CrewA I permite o feedback após cada tarefa definindo human_input=True; o agente faz uma pausa para coletar entrada em linguagem natural do usuário.
OpenAI Enxame
OpenAI O Swarm não oferece HITL integrado.
LangChain
O LangChain permite inserir pontos de interrupção personalizados em cadeias ou agentes para pausar a execução e solicitar intervenção humana. Isso possibilita revisão, feedback ou intervenção manual em pontos definidos do fluxo de trabalho.
Integração do Protocolo de Contexto do Modelo (MCP) em estruturas de IA agéticas
Os agentes de IA precisam interagir com ferramentas externas como bancos de dados, APIs, sistemas de arquivos e aplicativos empresariais. Sem um padrão, cada framework tinha que criar integrações personalizadas para cada ferramenta, resultando em um ecossistema fragmentado. O MCP resolve esse problema ao fornecer um protocolo universal que permite que qualquer agente se conecte a qualquer ferramenta por meio de uma única interface.
Como cada estrutura se integra ao MCP
LangGraph
O LangGraph se conecta aos servidores MCP por meio de um adaptador que descobre automaticamente as ferramentas disponíveis e as converte para um formato compatível com o LangChain. Os agentes podem então usar essas ferramentas perfeitamente, juntamente com suas funcionalidades nativas.
Geração automática
O AutoGen oferece integração nativa com o MCP por meio de seu módulo de extensão. Os desenvolvedores podem se conectar aos servidores MCP e disponibilizar todas as suas ferramentas para os agentes do AutoGen com apenas algumas linhas de código.
CrewAI
Os agentes CrewAI podem referenciar diretamente os servidores MCP em sua configuração usando URLs simples ou configurações estruturadas. A estrutura gerencia o ciclo de vida da conexão e os erros automaticamente.
OpenAI Enxame
O Swarm se beneficia do suporte nativo ao MCP da OpenAI em todo o seu ecossistema. Como a OpenAI integrou o MCP ao ChatGPT e ao seu SDK de Agentes, o Swarm pode aproveitar essa infraestrutura diretamente.
LangChain
O LangChain oferece recursos de chamada de ferramentas MCP, onde funções Python atuam como pontes para servidores MCP. Isso permite obter ferramentas de diversas fontes e integrá-las em cadeias, agentes e outros componentes do LangChain sem a necessidade de wrappers personalizados.
O que fazem, de fato, as estruturas de IA baseadas em agentes?
As estruturas de IA agéticas auxiliam na engenharia de prompts e no gerenciamento do fluxo de dados de e para os LLMs (Learning Learning Machines). Em um nível básico, elas ajudam a estruturar os prompts para que o LLM responda em um formato previsível e direcione as respostas para a ferramenta, API ou documento correto.
Se você estivesse criando um projeto do zero, definiria manualmente o prompt, extrairia a ferramenta que o LLM deseja usar e acionaria a chamada de API correspondente. Os frameworks simplificam esse processo da seguinte forma:
- Orquestração de prompts : Criação, gerenciamento e roteamento de prompts complexos para LLMs (Locais de Aprendizagem Baseados em Nível).
- Integração de ferramentas : Permitir que os agentes acessem APIs externas, bancos de dados, funções de código, etc.
- Memória : Manter o estado entre turnos ou sessões (curto e longo prazo)
- Integração RAG : permitindo a recuperação de conhecimento de fontes externas.
- Coordenação multiagente : estruturar a forma como os agentes colaboram ou delegam tarefas.
Frameworks de IA agéticos: casos de uso na vida real
LangGraph – planejador de viagens multiagente
Um projeto de produção construído com LangGraph demonstra um assistente de viagens com estado e multiagente que extrai dados de voos e hotéis (usando as APIs Google Flights & Hotels) e gera recomendações de viagem. 4
CrewAI – Criador de conteúdo agético
O repositório oficial de exemplos da CrewAI inclui fluxos como planejamento de viagens , estratégia de marketing , análise de ações e assistentes de recrutamento , onde agentes com funções específicas (por exemplo, "Pesquisador", "Redator") colaboram em tarefas. 5
A CrewAI transforma um briefing de conteúdo de alto nível em um artigo completo usando o Groq.
Principais características das estruturas de IA agente
Suporte ao modelo :
- A maioria é agnóstica em relação ao modelo , suportando múltiplos provedores de LLM (por exemplo, OpenAI, Anthropic, modelos de código aberto).
- No entanto, as estruturas de prompts do sistema variam de acordo com a estrutura e podem ter um desempenho melhor com alguns modelos do que com outros.
- O acesso e a personalização das instruções do sistema são frequentemente essenciais para resultados ótimos.
Ferramentas :
- Todas as estruturas suportam o uso de ferramentas , uma parte essencial para habilitar as ações do agente.
- Ofereça abstrações simples para definir ferramentas personalizadas.
- A maioria oferece suporte ao protocolo Modelo-Contexto-Protocolo (MCP) , seja nativamente ou por meio de extensões da comunidade.
Memória/Estado :
- Utilize o rastreamento de estado para manter a memória de curto prazo entre etapas ou chamadas LLM.
- Algumas ferramentas ajudam os agentes a reter interações ou contexto anteriores dentro de uma sessão.
RAG (Geração Aumentada por Recuperação) :
- A maioria inclui opções de configuração fáceis para RAG , integrando bancos de dados vetoriais ou repositórios de documentos.
- Isso permite que os agentes consultem conhecimento externo durante a execução.
Outras características comuns
- Suporte para execução assíncrona , permitindo chamadas simultâneas de agentes ou ferramentas.
- Funcionamento integrado para lidar com saídas estruturadas (por exemplo, JSON).
- Suporte para fluxos de dados contínuos , onde o modelo gera resultados incrementalmente.
- Funcionalidades básicas de observabilidade para monitoramento e depuração de execuções de agentes.
Metodologia de referência
1. Estrutura da Tarefa
Tarefa 1: Avalia se uma única chamada de ferramenta pode ser feita com o parâmetro correto. A sobrecarga da infraestrutura básica da estrutura fica mais evidente neste cenário simples.
Tarefa 2: Requer manter os resultados de dois grupos de filtros separados na memória e combiná-los em uma única saída. O gerenciamento de estado e a coordenação de múltiplos segmentos são testados.
Tarefa 3: Avalia se as condições numéricas em linguagem natural são traduzidas em parâmetros da ferramenta sem distorção. O verdadeiro teste é se os mecanismos de repetição e nova solicitação do framework conseguem preservar esses parâmetros.
Tarefa 4: Uma ferramenta gera erros de Rede, Tempo Limite e Limite de Taxa em sequência. Avalia-se se a estrutura altera sua estratégia diante desses erros.
Tarefa 5: O agente deve primeiro descobrir as colunas JSON e LongText e, em seguida, chamar as ferramentas corretas com os parâmetros de escopo adequados. Observa-se se a estrutura executa ferramentas independentes em paralelo ou sequencialmente.
2. Configuração
Todas as estruturas utilizaram o mesmo modelo LLM (openai/gpt-5.2) e o mesmo valor de temperatura (0,1). Para todas as tarefas, cada agente recebeu as mesmas ferramentas e os mesmos comandos. Cada estrutura foi configurada em sua estrutura nativa: LangChain com AgentExecutor, LangGraph com StateGraph, AutoGen com AssistantAgent + UserProxyAgent e CrewAI com Agent + Task + Crew.
O conjunto de dados de cancelamento de clientes da Telco IBM (7.032 clientes) foi utilizado. O estado da ferramenta foi redefinido antes de cada execução. Cem execuções independentes foram realizadas para cada combinação de framework e tarefa.
Os limites máximos de iterações foram definidos de acordo com a complexidade da tarefa: 10 para as Tarefas 1, 2 e 3; 20 para a Tarefa 4 devido ao loop instável da ferramenta; e 20 para a Tarefa 5 devido à cadeia de descoberta de 4 etapas.
Links de referência
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios.