Top 5 Frameworks de IA Agêntica de Código Aberto
Comparamos 4 frameworks agênticos de código aberto populares em 2.000 execuções (5 tarefas, 100 execuções cada por framework), medindo latência de ponta a ponta, consumo de tokens e diferenças arquiteturais.
Benchmark de frameworks de IA agêntica
Examinamos como os próprios frameworks influenciam o comportamento do agente e o impacto resultante na latência e no consumo de tokens.
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 uso de tokens.
Em 5 tarefas e 2.000 execuções, o LangChain desponta como o framework mais eficiente em tokens, enquanto o AutoGen lidera em latência; LangGraph e LangChain seguem de perto. CrewAI apresenta o perfil mais pesado no geral.
Veja a metodologia do benchmark de frameworks de IA agêntica para mais detalhes sobre as tarefas.
Tarefa 1: Agregação básica
Primeiro, medimos a sobrecarga de cada framework ao chamar uma única ferramenta e retornar o resultado, sem realizar nenhum raciocínio complexo.
LangChain & LangGraph: Para tarefas simples, eles executam quase tão rápido quanto código não agentivo, 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 se materializa conforme a complexidade da tarefa aumenta.
AutoGen: Fica ligeiramente acima do LangChain e do LangGraph tanto em latência quanto em uso de tokens, refletindo o custo base do seu loop de conversação multiagente, com dois agentes trocando mensagens mesmo para uma tarefa de etapa única.
CrewAI: Mesmo quando solicitado a fazer uma única chamada de ferramenta, ele exibe o que poderia ser chamado de “sobrecarga gerencial”, consumindo quase 3× os tokens do LangChain e levando quase 3× mais tempo. O processo de verificação em várias etapas entre suas personas Planejador e Analista oferece uma abordagem completa, mas intensiva em recursos, que prioriza a completude em detrimento da velocidade. Esse custo é estrutural: aparece independentemente da complexidade da tarefa.
Tarefa 2: Análise comparativa de receita (gerenciamento de estado)
Na Tarefa 2, queríamos ver 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 mais alto nível de transparência de infraestrutura entre os frameworks, 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 auto-revisã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 contínuo de pensamento sem produzir uma saída JSON.
A causa raiz desse comportamento é que o CrewAI injeta instruções em várias camadas no prompt do sistema, atribuindo a cada agente um papel, objetivo e histórico, enquanto impõe um loop de Pensamento → Ação → Observação no estilo ReAct a cada etapa. Mesmo para tarefas simples, o LLM não pode pular essa cerimônia e produz obedientemente monólogos internos prolixos, o que se agrava ainda mais em cenários multiagente.
O CrewAI consumiu quase o dobro dos tokens dos outros frameworks e levou mais de três vezes o tempo do LangChain, tornando-o mais adequado para transições de estado complexas e tomada de decisão multifatorial do que para tarefas simples de recuperação de dados.
LangChain
O framework mais rápido e econômico. Em nossos logs, observamos que o LangChain conclui a tarefa em 5-6 etapas sem desvios: Carregar → Filtrar → Calcular → Filtrar → Calcular → Saída. Como seu gerenciamento de estado é muito simples, a sobrecarga é quase zero e a latência é a mais baixa entre todos os frameworks.
AutoGen
Entregou um desempenho muito equilibrado. Na Tarefa 2, equiparou-se quase exatamente ao LangGraph tanto no uso de tokens quanto na latência, mostrando que a sobrecarga do loop de conversação não se agrava significativamente quando a cadeia de tarefas permanece linear.
No entanto, ele ocasionalmente adiciona uma etapa extra de verificação para confirmar parâmetros durante o processo de chamada de ferramenta, tornando-o um pouco mais lento que o LangChain. Quando encontra um erro em uma chamada de ferramenta ou os dados não voltam como esperado, ele imediatamente atualiza seu raciocínio na próxima etapa e chega ao JSON correto. Por gerenciar as saídas ferramentas como um fluxo conversacional, é um dos frameworks mais resilientes contra erros lógicos.
LangGraph
Nesta tarefa, o LangGraph é o framework mais estável graças à sua arquitetura baseada em grafos. Em seus logs, observamos que o estado é transportado de forma muito limpa durante toda a execução. O risco de contaminação de dados ou de segmentos interferindo uns nos outros está no nível mais baixo neste framework. Em todas as 100 execuções, ele produziu resultados quase com o mesmo número de etapas e dentro da mesma faixa de latência.
Tarefa 3: Análise de limiares (disciplina numérica)
Nesta tarefa, queríamos ver com que precisão os frameworks traduzem condições numéricas em linguagem natural, como “menos de 1 ano de permanência” e “mais de $70 em cobranças mensais”, em parâmetros de ferramenta precisos como tenure_max=12 e charges_min=70.0.
O LLM sabe como fazer essa conversão; o que realmente queríamos testar era se o framework consegue proteger esses parâmetros ao longo de seus próprios mecanismos de repetição, contexto de re-prompt e ciclos de gerenciamento de estado.
LangChain & LangGraph
Ambos os frameworks passaram os parâmetros (tenure_max=12, charges_min=70) diretamente para a ferramenta exatamente como o LLM os produziu, sem nenhuma modificação ou loop de re-prompt. Essa eficiência se reflete nos números: ambos os frameworks concluíram a Tarefa 3 em menos de 9 segundos com menos de 1.800 tokens de prompt, o menor valor nesta tarefa.
Quando queríamos medir se os limiares numéricos são preservados sem interferência do framework, esses dois atenderam às nossas expectativas: qualquer que fosse o parâmetro gerado, era o que executava.
AutoGen
O AutoGen é totalmente bem-sucedido na correção numérica. Em algumas execuções, observou-se que o framework adicionou uma etapa de verificação antes de passar o parâmetro gerado pelo LLM para a ferramenta, o que significa que o framework gastou uma etapa extra preservando o parâmetro. Com 2.480 tokens e 8 segundos, ele igualou a latência do LangChain apesar da etapa extra, confirmando que a sobrecarga de verificação é real, mas pequena. Ele atendeu às nossas expectativas em termos de integridade dos parâmetros, com a etapa de confirmação introduzindo um custo marginal em tokens em vez de uma penalidade significativa de latência.
CrewAI
O comportamento mais notável foi observado no CrewAI, que concluiu a Tarefa 3 em 30 segundos com 4.360 tokens, o valor mais alto nesta tarefa. Dois padrões distintos de falha emergiram da análise dos logs.
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 da saída do framework pode retirar a saída do LLM de seu contexto original.
Os logs mostram que o LLM inicialmente produziu os parâmetros corretos, tenure_max=12 e charges_min=70. No entanto, uma vez que o CrewAI entrou em um loop “Falha ao analisar”, o framework forçou o LLM a reconsiderar. No contexto de re-prompt, o LLM mudou o limiar para tenure_max=14 e desativou completamente o filtro charges_min, produzindo uma taxa de churn de 46.84%, que é na verdade a taxa de churn de todos os clientes com permanência inferior a 14. Esse foi exatamente o cenário que queríamos observar: o mecanismo de repetição do framework pode corromper um parâmetro que o LLM havia acertado.
Tarefa 4: Resiliência a erros e capacidade de pivotagem
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 lança 3 tipos diferentes de erros em sucessão (Rede, Tempo Limite, Limite de Taxa), encurralando o agente. Os dois primeiros erros instruem o agente a repetir, e depois de repetir ambos, o erro de Limite de Taxa que chega diz ao agente para esperar 10 segundos. Depois que o agente espera e repete, a ferramenta começa a funcionar normalmente.
LangGraph & Autogen
Esses dois frameworks encontraram soluções alternativas de forma autônoma quando confrontados com falhas de ferramenta nesta 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 falha e encontrar um caminho alternativo. Sua abordagem foi: “Já que essa ferramenta não está funcionando, vou filtrar cada método de pagamento um por um, calcular a taxa de churn para cada um separadamente e depois 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 filtrar e outra para calcular, processando cada PaymentMethod (Cheque eletrônico, Cheque enviado por correio, etc.) individualmente.
Esses agentes operam com raciocínio orientado a objetivos em vez de dependência de caminho. 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 acumulava o histórico crescente de cada chamada manual de ferramenta de volta ao contexto a cada etapa. O AutoGen veio em seguida com 10.750 tokens, um pouco mais contido devido ao seu tratamento conversacional dos resultados intermediários. Apesar disso, ambos terminaram em torno de 24-27 segundos, confirmando que o custo adicional de tokens não se traduziu em latência significativa porque a pivotagem em si foi rápida.
CrewAI
Apesar de apresentar o maior consumo de tokens nas tarefas anteriores, o CrewAI exibiu o menor uso de tokens) mas os maiores valores de latência nesta tarefa.
Por que o menor token?
O CrewAI não passou por uma solução manual de 10-15 etapas como seus concorrentes. Quando encontrou erros, em vez de injetar repetidamente todo o histórico e dados intermediários complexos de volta no LLM a cada etapa, ele construiu um loop de raciocínio mais focado e modular. Ao evitar verbosidade desnecessária, tornou-se o framework mais econômico nesta tarefa.
Por que a alta latência?
A estrutura gerencial do CrewAI pausa e reavalia o plano quando encontra um erro. Quando recebeu o aviso de espera de 10 segundos, ele passou mais tempo na fase de “planejamento estratégico”. Além disso, em vez de pivotar para outra ferramenta para filtrar, escolheu persistentemente esperar que a ferramenta principal se recuperasse ou tentar com a ferramenta estável, o que estendeu a duração total.
LangChain
O LangChain passou por sua transformação mais significativa nesta tarefa, provando por que a resiliência depende de uma configuração adequada.
Em nossa execução inicial, o LangChain travou em todas as tentativas com um ConnectionError.
O AgentExecutor padrão do LangChain trata exceções Python brutas lançadas de dentro de uma ferramenta como erros fatais e termina o processo. Ao contrário de seus concorrentes, ele não aplica uma filosofia de “erros são observações” por padrão. Como o agente nunca vê o erro, ele não tem 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 aplicar a correção, observamos nos logs do LangChain que ele exibiu exatamente o mesmo raciocínio do LangGraph. Ele recebeu 3 erros da ferramenta, imediatamente mudou de estratégia e pivotou para usar duas ferramentas separadas, uma para filtrar e outra para calcular, processou cada método de pagamento individualmente e combinou os resultados.
O LangChain é, na verdade, tão capaz e adaptável quanto o LangGraph, mas como o tratamento de erros do framework estava desabilitado por padrão, ele não teve oportunidade de demonstrar essa capacidade. Uma vez configurado corretamente, ele alcançou o resultado correto usando a mesma abordagem de caminho alternativo.
Por que essas diferenças ocorreram? (análise da arquitetura dos frameworks)
Se o comportamento do agente dependesse apenas do LLM (GPT-5.2), todos os frameworks deveriam ter se comportado de forma semelhante. No entanto, as diferenças claras nessas proporções estão enraizadas nos próprios mecanismos de loop interno dos frameworks:
1. LangGraph & AutoGen (90% Pivot):
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 loop 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 constante de cutucada força o agente a continuar procurando uma solução. Como o agente é repetidamente confrontado com a pergunta “Recebi um erro, o que devo fazer?”, a probabilidade de ele decidir tomar um caminho manual alternativo sobe para 90%.
2. LangChain (65% Pivot / 35% Espera):
O LangChain executa em uma arquitetura AgentExecutor sequencial. Mesmo com tratamento de erros implementado, seu loop de execução tem uma estrutura mais linear e está focado principalmente em produzir uma Resposta Final. Se a ferramenta lança erros por 3-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 pivotar para uma estratégia alternativa. Como o bloqueio de estado do LangChain é mais flexível que o do LangGraph, sua proporção de espera/solução direta fica em torno de 35%.
3. CrewAI (0% Pivot):
O CrewAI opera em uma arquitetura de Processo Gerencial. Seus agentes são envolvidos em definições de Papel e Tarefa. Quando ocorrem erros, sua arquitetura interna normalmente aciona 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 filtragem manual em 5 etapas” conflita com a estrutura do plano gerencial do CrewAI. Ele opera com a disciplina de “devo consertar a ferramenta que me foi dada ou usar a alternativa mais próxima” em vez de abandonar completamente seu plano. Essa é fundamentalmente uma abordagem centrada no plano, em oposição a uma centrada no objetivo.
Tarefa 5: Orquestração de dados não estruturados (roteamento de dados não estruturados)
Na tarefa 5, observamos como os frameworks se comportam quando encontram colunas JSON e texto longo (LongText) dentro de um CSV. Os agentes precisavam primeiro descobrir o tipo de dados dessas colunas, depois 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 blobs JSON, parágrafos de gratuito-text ou objetos aninhados.
Para que um framework lide corretamente com esse tipo de dados, ele precisa fazer duas coisas bem:
1- uma inteligência de descoberta que entenda qual ferramenta se adequa a qual tipo de dado
2- um mecanismo de orquestração que coordene múltiplas chamadas de ferramentas independentes.
Nós projetamos a Tarefa 5 especificamente para medir essas duas capacidades separadamente.
AutoGen
O AutoGen entregou um desempenho forte nesta tarefa, terminando com 8.170 tokens de prompt e uma latência mediana de 47 segundos, o resultado mais rápido e eficiente em tokens na Tarefa 5.
O loop de conversação no núcleo de sua arquitetura, a troca de mensagens entre AssistantAgent e UserProxyAgent, é tipicamente visto como uma estrutura que leva à verbosidade. No entanto, na Tarefa 5, essa estrutura se transformou em uma vantagem.
Observando o histórico da conversa, o LLM reconheceu que as colunas Metadata e SupportNotes eram independentes uma da outra. Ele então enviou uma única resposta TOOL CALLS listando 4 ferramentas simultaneamente: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…), e summarize_text_column(…) todas executadas em paralelo. Isso permitiu que ele completasse a tarefa em 3 turnos 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 motor de execução de ferramentas do AutoGen executa atomicamente a lista tool_calls retornada pelo LLM e coleta os resultados em uma única etapa de conversação. A filosofia de “gerenciar a conversa” do framework naturalmente permite que vários canais paralelos sejam abertos ao mesmo tempo, e os números de tokens e latência confirmam isso diretamente.
LangGraph
O LangGraph terminou com 9.150 tokens de prompt e 70 segundos de mediana, próximo ao AutoGen em tokens, mas mais lento no tempo. Sua arquitetura de Máquina de Estados exibiu tanto seu maior ponto forte quanto sua fraqueza mais notável simultaneamente na Tarefa 5.
Em todas as execuções, o loop nó llm → nó tools → 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 esqueça nada, o que normalmente é uma vantagem significativa.
No entanto, na Tarefa 5, essa força jogou contra ele. O LangGraph estava encontrando as ferramentas corretas e construindo o segmento correto. Mas mesmo após a conclusão da análise, ele detectava ambiguidades no estado acumulado, interpretando etapas concluídas como ainda pendentes e disparava repetidamente chamadas de ferramentas adicionais. Embora já tivesse recuperado os dados necessários e estivesse prestes a produzir a resposta correta, o sinal de “etapa ausente” da máquina de estados entrou em ação e o agente entrou em loops desnecessários. Como resultado, o número de chamadas de ferramentas por execução variou entre 6 e 16. O poder 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 do CrewAI na Tarefa 5 produziu a maior variância em todo o benchmark. Em algumas execuções, ele seguiu uma sequência impecável com 5 chamadas de ferramentas, sem desvios, executando como um script. Nessas execuções, a estrutura gerencial definida por papel e tarefa do CrewAI funcionou exatamente como pretendido: quando o agente compreendia claramente seu papel, ele se comportava de forma previsível e disciplinada.
No entanto, em outras execuções (por exemplo, execução 16: 35 chamadas de ferramentas), o caos total se seguiu. A causa raiz foi o monólogo interno (Pensamento) que o CrewAI gera a cada etapa. Depois de construir corretamente o segmento com o filtro certo, o monólogo interno do agente começou a questionar se filtros adicionais também deveriam ser aplicados. Depois de ver o resultado, 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. Depois, filtrou novamente, entrou em outro loop de verificação, duvidou novamente e repetiu essa espiral 8 vezes.
No CrewAI, cada Pensamento produz 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 re-questionar suas próprias decisões corretas.
LangChain
A estrutura AgentExecutor do LangChain é inerentemente sequencial, e a Tarefa 5 é onde essa restrição ficou mais visível. Com 10.070 tokens de prompt e 86 segundos de mediana, foi o framework mais lento nesta tarefa, apesar de não ter a maior contagem de tokens.
Ele faz uma única chamada de ferramenta a cada etapa, recebe o resultado, depois prossegue, o que significa que 4 ferramentas independentes exigiram 4 turnos separados do LLM com 4 períodos de espera separados. A mediana de 47 segundos do AutoGen contra os 86 segundos do LangChain é uma medição direta do custo da execução sequencial versus paralela.
Na Tarefa 5, a contagem de ferramentas do LangChain se estabeleceu em 9 ou 15. Esses dois grupos apontam para duas estratégias típicas: em algumas execuções, ele pulou a etapa de inspeção e foi diretamente para análise e sumarização (9 ferramentas), enquanto em outras inspecionou cada coluna primeiro antes de processar (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 de monólogo do CrewAI.
Gerenciamento de dados não estruturados e arquitetura dos frameworks
Os resultados desta tarefa revelam que a eficiência com que um framework pode gerenciar 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 do mundo real envolvendo grandes objetos JSON e numerosas colunas de texto, essa diferença se traduz em uma enorme vantagem de custo e velocidade.
Frameworks com loops orientados por estado (LangGraph) se destacam na consistência dos dados, mas carregam o risco de reavaliar etapas concluídas acumuladas no histórico.
Frameworks baseados em monólogo (CrewAI) são profundamente capazes de entender o tipo e o significado dos dados, mas essa profundidade às vezes se transforma em questionamento excessivo e looping.
Frameworks de execução linear (LangChain) processam diferentes ramos de dados não estruturados separadamente, produzindo um resultado intermediário dos dois mundos.
GitHub crescimento de estrelas dos frameworks agênticos
Comparar frameworks de IA agêntica
Os frameworks de IA agêntica variam em várias dimensões-chave, e entender essas diferenças é essencial para fazer comparações significativas.
Orquestração multiagente
Orquestração multiagente coordena vários agentes de IA especializados para enfrentar 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 papéis, ferramentas e conhecimentos distintos. Cada framework oferece abordagens diferentes para a coordenação de agentes.
LangGraph
O LangGraph é um framework relativamente conhecido e se destaca como uma opção chave para desenvolvedores que constroem sistemas de agentes.
Coordenação multiagente explícita: Você pode modelar múltiplos agentes como nós individuais ou grupos, cada um com sua própria lógica, memória e papel no sistema.
Ele cria fluxos de trabalho de IA entre APIs e ferramentas. Assim, é uma boa opção para RAG e pipelines personalizados.
AutoGen
AutoGen permite que vários agentes se comuniquem trocando 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, tornando-o particularmente útil para cenários de pesquisa e prototipagem onde o comportamento do agente requer experimentação ou refinamento iterativo.
CrewAI
CrewAI cuida da 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 Flows com lógica condicional, loops e gerenciamento de estado
- Suporta coordenação multiagente hierárquica (gerente-trabalhador) e estruturada
OpenAI Swarm
Swarm é um framework multiagente leve e experimental para prototipagem. Os agentes trabalham sequencialmente por meio de handoffs, transferindo tarefas enquanto mantêm um contexto compartilhado. Ele usa rotinas em linguagem natural e ferramentas Python para fluxos de trabalho flexíveis.
LangChain
LangChain é um framework para construir aplicações LLM de agente único com ferramentas RAG. Ele fornece componentes modulares incluindo chains, ferramentas, memória e recuperação para fluxos de trabalho de processamento de documentos.
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
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 permite construir e visualizar grafos multiagente com nós supervisores para orquestração escalável.
O LangGraph usa funções estruturadas anotadas que anexam ferramentas aos agentes. Você pode construir nós, conectá-los a vários supervisores e visualizar como diferentes equipes interagem. Pense nisso como dar a cada membro da equipe uma descrição detalhada do trabalho. Isso facilita a construção e o teste de agentes que trabalham juntos.
AutoGen
AutoGen define agentes como unidades adaptativas 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 anotadas.
CrewAI
CrewAI adota uma abordagem de design baseado em papéis. Cada agente recebe um papel (por exemplo, Pesquisador, Desenvolvedor) e um conjunto de habilidades, funções ou ferramentas que pode acessar. A definição de função é feita por meio de anotações estruturadas.
OpenAI Swarm
OpenAI Swarm usa 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, mas menos precisa.
LangChain
LangChain usa uma arquitetura baseada em chains, onde um único agente orquestrador gerencia chamadas para modelos de linguagem e várias ferramentas. Ele define funções por meio de interfaces explícitas, como toolkits e modelos de prompt.
Embora focado principalmente em fluxos de trabalho centralizados, o LangChain oferece suporte a extensões para configurações multiagente, mas carece de comunicação integrada entre agentes.
Memória
Capacidades de memória:
- Stateful: Se o framework suporta memória persistente entre execuções.
- Contextual: Se suporta memória de curto prazo via histórico de mensagens ou passagem de contexto.
Os recursos de memória são uma parte essencial da construção de sistemas agênticos para lembrar o contexto e se adaptar ao longo do tempo:
- Memória de curto prazo: Acompanha interações recentes, permitindo que os agentes lidem com conversas de múltiplos turnos 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 entidade: Rastreia e atualiza conhecimento sobre objetos, pessoas ou conceitos específicos mencionados durante as interações (por exemplo, lembrar o nome de uma empresa ou ID de projeto mencionado anteriormente).
LangGraph
LangGraph usa dois tipos de memória: memória intra-thread, que armazena informações durante uma única tarefa ou conversa, e memória entre threads, 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 oferece suporte a ferramentas como InMemoryStore ou outros bancos de dados. Isso fornece controle flexível sobre como a memória é delimitada e retida entre execuções.
AutoGen
AutoGen usa 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 fornece memória em camadas pronta para uso. Ele armazena memória de curto prazo em um armazenamento vetorial ChromaDB, resultados recentes de tarefas em SQLite e memória de longo prazo em uma tabela SQLite separada (com base nas descrições das tarefas). Além disso, oferece suporte à memória de entidade usando embeddings vetoriais. Essa configuração de memória é automaticamente ativada quando memory=True é habilitado,
OpenAI Swarm
Swarm é stateless e não gerencia memória nativamente. Os desenvolvedores podem passar memória de curto prazo por meio de context_variables manualmente e, opcionalmente, integrar ferramentas externas ou camadas de memória de terceiros (por exemplo, mem0) para armazenar contexto de longo prazo.
LangChain
LangChain oferece suporte a memória de curto e longo prazo por meio de componentes flexíveis. A memória de curto prazo geralmente é gerenciada por buffers em memória que rastreiam o histórico de conversas dentro de uma sessão. Para memória de longo prazo, o LangChain integra-se com armazenamentos vetoriais externos ou bancos de dados para persistir embeddings e dados de recuperação.
Os desenvolvedores podem personalizar escopos e estratégias de memória usando classes de memória integradas, permitindo o gerenciamento eficiente de memória contextual e específica de entidades ao longo das interações.
Humano no circuito
LangGraph
LangGraph suporta pontos de interrupção personalizados (interrupt_before) para pausar o grafo e aguardar a entrada do usuário no meio da execução.
AutoGen
AutoGen suporta nativamente agentes humanos via UserProxyAgent, permitindo que humanos revisem, aprovem ou modifiquem etapas durante a colaboração do agente.
CrewAI:
CrewAI permite feedback após cada tarefa configurando human_input=True; o agente pausa para coletar entrada em linguagem natural do usuário.
OpenAI Swarm
OpenAI Swarm não oferece HITL integrado.
LangChain
LangChain permite inserir pontos de interrupção personalizados dentro de chains ou agentes para pausar a execução e solicitar entrada humana. Isso suporta revisão, feedback ou intervenção manual em pontos definidos no fluxo de trabalho.
Integração do Model Context Protocol (MCP) em frameworks de IA agêntica
Os agentes de IA precisam interagir com ferramentas externas como bancos de dados, APIs, sistemas de arquivos e aplicações de negócios. Sem um padrão, cada framework tinha que construir integrações personalizadas para cada ferramenta, criando um ecossistema fragmentado. O MCP resolve isso fornecendo um protocolo universal que permite que qualquer agente se conecte a qualquer ferramenta por meio de uma única interface.
Como cada framework integra-se com o MCP
LangGraph
LangGraph conecta-se a servidores MCP por meio de um adaptador que automaticamente descobre as ferramentas disponíveis e as converte em um formato compatível com o LangChain. Os agentes podem então usar essas ferramentas de forma transparente juntamente com suas capacidades nativas.
AutoGen
AutoGen fornece integração nativa com MCP por meio de seu módulo de extensão. Os desenvolvedores podem conectar-se a servidores MCP e tornar todas as suas ferramentas disponíveis para os agentes AutoGen com apenas algumas linhas de código.
CrewAI
Os agentes CrewAI podem referenciar diretamente servidores MCP em sua configuração usando URLs simples ou configurações estruturadas. O framework gerencia automaticamente o ciclo de vida da conexão e o gerenciamento de erros.
OpenAI Swarm
O Swarm se beneficia do suporte nativo ao MCP da OpenAI em todo o seu ecossistema. Como a OpenAI integrou o MCP no ChatGPT e em seu Agents SDK, o Swarm pode aproveitar essa infraestrutura diretamente.
LangChain
LangChain oferece capacidades de chamada de ferramentas MCP, onde funções Python atuam como pontes para servidores MCP. Isso permite obter ferramentas de várias fontes e integrá-las em chains, agentes e outros componentes do LangChain sem wrappers personalizados.
Adicionar como fonte preferencialO que os frameworks de IA agêntica realmente fazem?
Os frameworks de IA agêntica auxiliam na engenharia de prompts e no gerenciamento de como os dados fluem para e a partir dos LLMs. Em um nível básico, eles ajudam a estruturar prompts para que o LLM responda em um formato previsível e encaminhe as respostas para a ferramenta, API ou documento certos.
Se estiver construindo do zero, você definiria manualmente o prompt, extrairia a ferramenta que o LLM deseja usar e acionaria a chamada de API correspondente. Os frameworks simplificam isso ao:
- Orquestração de prompts: Construção, gerenciamento e roteamento de prompts complexos para LLMs
- Integração de ferramentas: Permitir que agentes chamem APIs externas, bancos de dados, funções de código, etc.
- Memória: Manter estado entre turnos ou sessões (curto e longo prazo)
- Integração RAG: Permitir a recuperação de conhecimento de fontes externas
- Coordenação multiagente: Estruturar como os agentes colaboram ou delegam tarefas
Frameworks de IA agêntica: 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 multiagente com estado que obtém dados de voos e hotéis (usando as Google Flights & Hotels APIs) e gera recomendações de viagem.3
CrewAI – Criador de conteúdo agêntico
O repositório de exemplos oficiais do CrewAI inclui fluxos como planejamento de viagens, estratégia de marketing, análise de ações e assistentes de recrutamento, onde agentes específicos para cada papel (por exemplo, “Pesquisador”, “Redator”) colaboram em tarefas.4
O CrewAI transforma um briefing de conteúdo de alto nível em um artigo completo usando Groq.
Principais recursos dos frameworks de IA agêntica
Suporte a modelos:
- A maioria é agnóstica a modelos, suportando vários provedores de LLM (por exemplo, OpenAI, Anthropic, modelos de código aberto).
- No entanto, as estruturas de prompt do sistema variam conforme o framework e podem ter melhor desempenho com alguns modelos do que com outros.
- O acesso e a personalização dos prompts do sistema costumam ser essenciais para obter resultados ideais.
Ferramentas:
- Todos os frameworks suportam uso de ferramentas, parte fundamental para viabilizar as ações dos agentes.
- Oferecem abstrações simples para definir ferramentas personalizadas.
- A maioria oferece suporte ao Model-Context-Protocol (MCP), seja nativamente ou por meio de extensões da comunidade.
Memória / Estado:
- Usam rastreamento de estado para manter memória de curto prazo entre etapas ou chamadas do LLM.
- Alguns 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 fáceis de configuração para RAG, integrando bancos de dados vetoriais ou armazenamentos de documentos.
- Isso permite que os agentes consultem conhecimento externo durante a execução.
Outros recursos comuns
- Suporte à execução assíncrona, permitindo chamadas concorrentes de agentes ou ferramentas.
- Tratamento integrado para saídas estruturadas (por exemplo, JSON).
- Suporte a saídas em streaming onde o modelo gera resultados incrementalmente.
- Recursos básicos de observabilidade para monitoramento e depuração de execuções de agentes.
Metodologia do benchmark
1. Estrutura das Tarefas
Tarefa 1: Mede se uma única chamada de ferramenta pode ser feita com o parâmetro correto. A sobrecarga da infraestrutura base do framework é revelada mais claramente 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: Mede se condições numéricas em linguagem natural são traduzidas em parâmetros de ferramenta sem distorção. O verdadeiro teste é se os mecanismos de repetição e re-prompt do framework conseguem preservar esses parâmetros.
Tarefa 4: Uma ferramenta lança erros de Rede, Timeout e RateLimit em sucessão. Mede-se o framework muda de estratégia diante desses erros.
Tarefa 5: O agente deve primeiro descobrir colunas JSON e LongText e, em seguida, chamar as ferramentas corretas com os parâmetros de escopo corretos. Observa-se o framework executa ferramentas independentes em paralelo ou sequencialmente.
Como é realmente uma tarefa
Para tornar a configuração concreta, aqui está a Tarefa 5, a tarefa mais complexa do benchmark de frameworks de IA agêntica. Todos os frameworks receberam o prompt idêntico e o mesmo conjunto de ferramentas; apenas o framework que envolvia o LLM mudou.
Prompt dado ao agente:
Analisar clientes que cancelaram (Churn=’Yes’) e pagam mais de 100 em MonthlyCharges.
- Filtrar o conjunto de dados para Churn=’Yes’.
- Inspecionar as colunas ‘Metadata’ e ‘SupportNotes’ para descobrir seus tipos de dados.
- Extrair a distribuição de ‘device_type’ da coluna JSON ‘Metadata’.
- Contar palavras-chave de reclamação da coluna de gratuito-text ‘SupportNotes’.
Retornar o resultado apenas em JSON.
Saída JSON necessária:
Por que esta tarefa diferencia os frameworks: o agente precisa planejar uma cadeia de quatro chamadas de ferramentas, manter o segmento filtrado no estado em cada chamada e reconhecer que uma coluna é JSON enquanto a outra é texto gratuito. Um framework que executa as colunas independentes em paralelo (AutoGen) termina muito mais rápido do que um que as executa sequencialmente (LangChain), e um framework que reavalia etapas concluídas (LangGraph, CrewAI) entra em loops desnecessários. O esquema JSON estrito nos permite pontuar a correção automaticamente.
2. Configuração
Todos os frameworks usaram o mesmo modelo de 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 prompts. Cada framework foi configurado em sua estrutura nativa: LangChain com AgentExecutor, LangGraph com StateGraph, AutoGen com AssistantAgent + UserProxyAgent, e CrewAI com Agent + Task + Crew.
O dataset IBM Telco Customer Churn (7.032 clientes) foi usado. O estado da ferramenta era redefinido antes de cada execução. 100 execuções independentes foram realizadas para cada combinação de framework e tarefa.
Os limites máximos de iteração 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.
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{Top 5 Frameworks de IA Agêntica de Código Aberto}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/agentic-frameworks}},
note = {AIMultiple. Acessado em 10 Agosto 2026}
}Links de referência
O trabalho de Cem foi citado por publicações globais de destaque, incluindo Business Insider, Forbes, Washington Post, empresas globais como Deloitte, HPE e ONGs como o Fórum Econômico Mundial e organizações supranacionais como a Comissão Europeia.
Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor de tecnologia. Ele aconselhou empresas em suas decisões de tecnologia na McKinsey & Company e na Altman Solon por mais de uma década. Ele também publicou um relatório da McKinsey sobre digitalização.
Ele liderou a estratégia de tecnologia e aquisições de uma empresa de telecomunicações, reportando-se ao CEO. Ele também liderou o crescimento comercial da empresa de tecnologia profunda Hypatos, que alcançou uma receita recorrente anual de 7 dígitos e uma avaliação de 9 dígitos partindo do zero em 2 anos. O trabalho de Cem na Hypatos foi coberto por publicações de tecnologia de destaque como TechCrunch e Business Insider.
Cem fala regularmente em conferências internacionais de tecnologia. Ele se formou na Universidade Bogazici como engenheiro de computação e possui um MBA pela Columbia Business School.
Comentários 1
Compartilhe suas ideias
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.
Thank you for this informative and detailed article! It helped me get a reading on these frameworks.