Top 5 Frameworks de IA Agêntica de Código Aberto
Avaliamos 4 frameworks agentic 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.
O LangGraph é o framework mais rápido com os menores valores de latência em todas as tarefas, enquanto o LangChain tem a maior latência e uso de tokens.
Em 5 tarefas e 2.000 execuções, o LangChain emerge como o framework mais eficiente em tokens, enquanto o AutoGen lidera em latência; LangGraph e LangChain seguem de perto. O CrewAI apresenta o perfil geral mais pesado.
Você pode ver nossa metodologia em detalhes aqui.
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-agêntico, 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 neste nível de simplicidade; a sobrecarga da gestão de estado se materializa conforme a complexidade da tarefa aumenta.
AutoGen: Fica ligeiramente acima do LangChain e LangGraph tanto em latência quanto em uso de tokens, refletindo o custo base do seu loop de conversação multi-agente, 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× mais tokens que o LangChain e levando quase 3× mais tempo. O processo de verificação em múltiplas etapas entre suas personas Planner e Analyst oferece uma abordagem minuciosa, mas intensiva em recursos, que prioriza a completude em vez da velocidade. Este custo é estrutural: aparece independentemente da complexidade da tarefa.
Tarefa 2: Análise comparativa de receita (gestão 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 fornece o maior 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 através de um mecanismo de auto-revisão. Este comportamento exploratório fez com que atingisse o limite configurado de max_iter=10, deixando algumas execuções presas em um loop contínuo de raciocínio sem produzir uma saída JSON.
A causa raiz deste comportamento é que o CrewAI injeta instruções em múltiplas camadas no prompt do sistema, atribuindo a cada agente um papel, objetivo e histórico, enquanto impõe um loop no estilo ReAct de Pensamento → Ação → Observação a cada etapa. Mesmo para tarefas simples, o LLM não pode ignorar este protocolo e produz obedientemente monólogos internos prolixos, que se agravam ainda mais em cenários multi-agente.
O CrewAI consumiu quase o dobro de 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 em vez de tarefas simples de recuperação de dados.
LangChain
O framework mais rápido e com melhor custo-benefício. Em nossos logs, observamos que o LangChain completa a tarefa em 5-6 etapas sem desvios: Carregar → Filtrar → Calcular → Filtrar → Calcular → Saída. Como sua gestão 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, igualou o LangGraph quase exatamente 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, ocasionalmente adiciona uma etapa extra de verificação para confirmar parâmetros durante o processo de chamada de ferramenta, tornando-o ligeiramente mais lento que o LangChain. Quando encontra um erro em uma chamada de ferramenta ou os dados não retornam como esperado, ele imediatamente atualiza seu raciocínio na próxima etapa e chega ao JSON correto. Por gerenciar as saídas 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 grafo. 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 interferirem entre si está no nível mais baixo neste framework. Em todas as 100 execuções, produziu resultados quase no 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 retry, contexto de re-prompt e ciclos de gestão 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 qualquer modificação ou loop de re-prompt. Essa eficiência se mostra nos números: ambos os frameworks completaram 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 parâmetro gerado, foi isso que executou.
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 enquanto preservava o parâmetro. Com 2.480 tokens e 8 segundos, igualou a latência do LangChain apesar da etapa extra, confirmando que a sobrecarga de verificação é real, mas pequena. Atendeu às nossas expectativas em termos de integridade dos parâmetros, com a etapa de confirmação introduzindo um custo marginal de tokens em vez de uma penalidade significativa de latência.
CrewAI
O comportamento mais notável foi observado no CrewAI, que completou a Tarefa 3 em 30 segundos com 4.360 tokens, o maior valor nesta tarefa. Dois padrões distintos de falha emergiram da análise de 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 de saída do framework pode remover a saída do LLM do seu contexto original.
Os logs mostram que o LLM inicialmente produziu os parâmetros corretos, tenure_max=12 e charges_min=70. No entanto, quando o CrewAI entrou em um loop de "Failed to parse", o framework pressionou o LLM a reconsiderar. No contexto de re-prompt, o LLM alterou 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. Este era exatamente o cenário que queríamos observar: o mecanismo de retry 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 (Network, Timeout, Rate Limit), encurralando o agente. Os dois primeiros erros instruem o agente a tentar novamente e, após tentar ambos, o erro de Rate Limit recebido informa ao agente para esperar 10 segundos. Uma vez que o agente espera e tenta novamente, a ferramenta começa a funcionar normalmente.
LangGraph & AutoGen
Estes 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 esta 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 (Electronic check, Mailed check, 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 está 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 etapa. O AutoGen seguiu com 10.750 tokens, um pouco mais contido devido ao seu tratamento conversacional dos resultados intermediários. Apesar disso, ambos terminaram em cerca 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 mostrar 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 uso de tokens?
O CrewAI não passou por uma solução alternativa manual de 10-15 etapas como seus concorrentes. Quando encontrou erros, em vez de bombear repetidamente todo o histórico e dados intermediários complexos de volta para o LLM a cada etapa, ele construiu um loop de raciocínio mais focado e modular. Ao evitar verbosidade desnecessária, tornou-se o framework com melhor custo-benefício nesta tarefa.
Por que 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, passou mais tempo na fase de "planejamento estratégico". Além disso, em vez de pivotar para outra ferramenta para filtrar, escolheu persistentemente esperar a ferramenta principal se recuperar ou tentar com a ferramenta estável, o que estendeu a duração geral.
LangChain
O LangChain passou por sua transformação mais significativa nesta tarefa, provando por que a resiliência depende da configuração adequada.
Em nossa execução inicial, o LangChain falhou 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 encerra 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 que o 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 desativado 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. Este 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 é focado principalmente em produzir uma Resposta Final. Se a ferramenta lança erros por 3-4 etapas, o LangChain às vezes prefere esperar a ferramenta ter sucesso na próxima tentativa ou produzir um resultado 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 Auto-Correção ou Retry. No entanto, uma mudança radical de estratégia como "vamos descartar todo o plano e fazer filtragem manual em 5 etapas" entra em conflito com a estrutura de 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. Esta é 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 de texto longo (LongText) dentro de um CSV. Os agentes precisavam primeiro descobrir o tipo de dados dessas colunas e depois selecionar as ferramentas de processamento corretas, seja sequencialmente ou em paralelo.
No mundo real, a gestão 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 free-text ou objetos aninhados.
Para um framework lidar com esse tipo de dados corretamente, ele precisa fazer duas coisas bem:
1- uma inteligência de descoberta que entenda qual ferramenta se adequa a qual tipo de dados
2- um mecanismo de orquestração que coordene múltiplas chamadas de ferramentas independentes.
Projetamos a Tarefa 5 especificamente para medir essas duas capacidades separadamente.
AutoGen
O AutoGen entregou um forte desempenho 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.
Ao observar o histórico da conversa, o LLM reconheceu que as colunas Metadata e SupportNotes eram independentes uma da outra. 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 todas executadas em paralelo. Isso permitiu completar 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 a lista tool_calls retornada pelo LLM atomicamente e coleta os resultados em uma única etapa de conversação. A filosofia de "gerenciar a conversa" do framework naturalmente permite que múltiplos 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 simultaneamente sua maior força e sua fraqueza mais notável na Tarefa 5.
Em cada execução, o loop nó llm → nó tools → nó llm acumula todas as saídas anteriores de 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 análise estar completa, ele detectava ambiguidades no estado acumulado, interpretando etapas concluídas como ainda pendentes, e acionava repetidamente chamadas adicionais de ferramentas. Mesmo tendo recuperado os dados necessários e estando prestes a produzir a resposta correta, o sinal de "etapa faltante" da máquina de estados entrava em ação e o agente entrava 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 etapas concluídas parecerem incompletas, puxando o agente de volta para ciclos redundantes e elevando a latência 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 entendia claramente seu papel, ele se comportava de forma previsível e com disciplina.
No entanto, em outras execuções (ex.: execução 16: 35 chamadas de ferramentas), o caos completo se instalou. A causa raiz foi o monólogo interno (Thought) que o CrewAI gera a cada etapa. Após construir corretamente o segmento com o filtro certo, o monólogo interno do agente começava a questionar se filtros adicionais também deveriam ser aplicados. Após ver o resultado, ele duvidava se o segmento atual era válido ou se o anterior deveria ter precedência. Essa dúvida o levava a recarregar os dados do zero. Depois filtrava novamente, entrava em outro loop de verificação, duvidava novamente e repetia essa espiral 8 vezes.
No CrewAI, cada Thought 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, empurrou o agente a questionar novamente suas próprias decisões corretas.
LangChain
A estrutura AgentExecutor do LangChain é inerentemente sequencial, e a Tarefa 5 é onde essa restrição foi 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 e depois segue em frente, 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 agrupamentos 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.
Gestão de dados não estruturados e arquitetura de framework
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 chamadas de ferramentas paralelas (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 a estado (LangGraph) se destacam na consistência de 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 loops.
Frameworks de execução linear (LangChain) processam diferentes ramos de dados não estruturados separadamente, produzindo um resultado intermediário de ambos os mundos.
Crescimento de estrelas no GitHub dos frameworks agentic
Compare 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 multi-agente
A orquestração multi-agente coordena múltiplos 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 expertise distintos. Cada framework oferece diferentes abordagens para coordenação de agentes.
LangGraph
O LangGraph é um framework relativamente bem conhecido e se destaca como uma opção chave para desenvolvedores que constroem sistemas de agentes.
Coordenação multi-agente 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
O AutoGen permite que múltiplos 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 de agentes, tornando-o 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 multi-agente:
- Integra-se com ferramentas de monitoramento para rastreamento e depuração
- Controle de execução nativo através de Flows com lógica condicional, loops e gestão de estado
- Suporta coordenação multi-agente hierárquica (gerente-trabalhador) e estruturada
OpenAI Swarm
Swarm é um framework multi-agente leve e experimental para prototipagem. Os agentes trabalham sequencialmente através de handoffs, transferindo tarefas enquanto mantêm o contexto compartilhado. Ele usa rotinas em linguagem natural e ferramentas Python para fluxos de trabalho flexíveis.
LangChain
O LangChain é um framework para construir aplicações LLM de agente único com ferramental RAG. Ele fornece componentes modulares incluindo chains, ferramentas, memória e recuperação para fluxos de trabalho de processamento de documentos.
O LangChain opera primariamente através 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 grafo para design de agentes, onde cada agente é representado como um nó que mantém seu próprio estado. Esses nós são conectados através de um grafo direcionado, permitindo lógica condicional, coordenação multi-equipe e controle hierárquico. Isso permite que você construa e visualize grafos multi-agente com nós supervisores para orquestração escalável.
O LangGraph usa funções anotadas e estruturadas 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
O 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 anotadas e estruturadas.
CrewAI
O CrewAI adota uma abordagem de design baseado em papéis. Cada agente recebe um papel (ex.: Pesquisador, Desenvolvedor) e um conjunto de habilidades, funções ou ferramentas que pode acessar. A definição de função é através de anotações estruturadas.
OpenAI Swarm
O OpenAI Swarm usa um modelo baseado em rotinas onde os agentes são definidos através 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 através 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
O LangChain usa uma arquitetura baseada em chain onde um único agente orquestrador gerencia chamadas para modelos de linguagem e várias ferramentas. Ele define funções através de interfaces explícitas como toolkits e templates de prompt.
Embora focado primariamente em fluxos de trabalho centralizados, o LangChain suporta extensões para configurações multi-agente, mas carece de comunicação nativa agente-para-agente.
Memória
Capacidades de memória:
- Com estado: 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.
Recursos de memória são uma parte chave 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 agentes lidem com conversas multi-turno 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 específicos, pessoas ou conceitos mencionados durante as interações (ex.: lembrar um nome de empresa ou ID de projeto mencionado anteriormente).
LangGraph
O LangGraph usa dois tipos de memória: memória intra-thread, que armazena informações durante uma única tarefa ou conversa, e memória 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 fornece controle flexível sobre como a memória é escopada e retida entre execuções.
AutoGen
O AutoGen usa um modelo de memória contextual. Cada agente mantém contexto de curto prazo através de um objeto context_variables, que armazena o histórico de interações. Ele não possui memória persistente nativa.
CrewAI
O CrewAI fornece memória em camadas pronta para uso. Ele armazena memória de curto prazo em um vector store ChromaDB, resultados recentes de tarefas em SQLite e memória de longo prazo em uma tabela SQLite separada (baseada em descrições de tarefas). Além disso, suporta memória de entidade usando embeddings vetoriais. Esta configuração de memória é automaticamente configurada quando memory=True está habilitado,
OpenAI Swarm
O Swarm é sem estado e não gerencia memória nativamente. Os desenvolvedores podem passar memória de curto prazo através de context_variables manualmente e, opcionalmente, integrar ferramentas externas ou camadas de memória de terceiros (ex.: mem0) para armazenar contexto de longo prazo.
LangChain
O LangChain suporta memória de curto e longo prazo através de componentes flexíveis. A memória de curto prazo é tipicamente gerenciada via buffers em memória que rastreiam o histórico de conversa dentro de uma sessão. Para memória de longo prazo, o LangChain integra-se com vector stores 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 nativas, permitindo uma gestão eficiente da memória contextual e específica de entidade entre interações.
Human-in-the-loop
LangGraph
O LangGraph suporta pontos de interrupção personalizados (interrupt_before) para pausar o grafo e aguardar entrada do usuário no meio da execução.
AutoGen
O AutoGen suporta nativamente agentes humanos via UserProxyAgent, permitindo que humanos revisem, aprovem ou modifiquem etapas durante a colaboração do agente.
CrewAI:
O 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
O OpenAI Swarm não oferece HITL nativo.
LangChain
O 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.
Adicionar como fonte preferencialIntegraçã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 através de uma única interface.
Como cada framework se integra com MCP
LangGraph
O LangGraph conecta-se a servidores MCP através de um adaptador que descobre automaticamente as ferramentas disponíveis e as converte para o formato compatível com LangChain. Os agentes podem então usar essas ferramentas perfeitamente junto com suas capacidades nativas.
AutoGen
O AutoGen fornece integração nativa com MCP através de seu módulo de extensão. Os desenvolvedores podem conectar-se a servidores MCP e disponibilizar todas as suas ferramentas 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 lida com o ciclo de vida da conexão e gestão de erros automaticamente.
OpenAI Swarm
O Swarm se beneficia do suporte nativo a MCP do OpenAI em todo o seu ecossistema. Como o OpenAI integrou o MCP no ChatGPT e em seu Agents SDK, o Swarm pode aproveitar essa infraestrutura diretamente.
LangChain
O LangChain oferece capacidades de chamada de ferramentas MCP onde funções Python atuam como pontes para servidores MCP. Isso permite extrair ferramentas de várias fontes e integrá-las em chains, agentes e outros componentes do LangChain sem wrappers personalizados.
O 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 de e para LLMs. Em um nível básico, eles ajudam a estruturar prompts para que o LLM responda em um formato previsível e roteie as respostas para a ferramenta, API ou documento correto.
Se construísse 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 através de:
- Orquestração de prompts: Construção, gestão e roteamento de prompts complexos para LLMs
- Integração de ferramentas: Permitindo que agentes chamem APIs externas, bancos de dados, funções de código, etc.
- Memória: Mantendo estado entre turnos ou sessões (curto e longo prazo)
- Integração RAG: Permitindo recuperação de conhecimento de fontes externas
- Coordenação multi-agente: Estruturando como os agentes colaboram ou delegam tarefas
Frameworks de IA agêntica: Casos de uso reais
LangGraph – Planejador de viagens multi-agente
Um projeto em produção construído com LangGraph demonstra um assistente de viagens multi-agente com estado que busca dados de voos e hotéis (usando Google Flights & Hotels APIs) e gera recomendações de viagem.4
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 com papéis específicos (ex.: "Pesquisador", "Redator") colaboram em tarefas.5
O CrewAI transforma um briefing de conteúdo de alto nível em um artigo completo usando Groq.
Funcionalidades principais dos frameworks de IA agêntica
Suporte a modelos:
- A maioria é agnóstica em relação ao modelo, suportando múltiplos provedores de LLM (ex.: OpenAI, Anthropic, modelos open-source).
- No entanto, as estruturas de prompt do sistema variam por framework e podem ter melhor desempenho com alguns modelos do que com outros.
- O acesso e a personalização dos prompts do sistema são frequentemente essenciais para resultados ideais.
Ferramental:
- Todos os frameworks suportam uso de ferramentas, uma parte central para habilitar ações do agente.
- Oferecem abstrações simples para definir ferramentas personalizadas.
- A maioria suporta Model-Context-Protocol (MCP), nativamente ou através de extensões da comunidade.
Memória / Estado:
- Usam rastreamento de estado para manter memória de curto prazo entre etapas ou chamadas ao LLM.
- Alguns ajudam os agentes a reter interações ou contexto anteriores dentro de uma sessão.
RAG (Retrieval-Augmented Generation):
- 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 referenciem conhecimento externo durante a execução.
Outras funcionalidades comuns
- Suporte para execução assíncrona, permitindo chamadas concorrentes de agentes ou ferramentas.
- Tratamento nativo para saídas estruturadas (ex.: JSON).
- Suporte para saídas em streaming onde o modelo gera resultados incrementalmente.
- Funcionalidades básicas 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 de 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. A gestão de estado e a coordenação de múltiplos segmentos são testadas.
Tarefa 3: Mede se as 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 retry e re-prompt do framework conseguem preservar esses parâmetros.
Tarefa 4: Uma ferramenta lança erros de Network, Timeout e RateLimit em sucessão. Mede-se se o framework muda de estratégia diante desses erros.
Tarefa 5: O agente deve primeiro descobrir as colunas JSON e LongText, depois chamar as ferramentas corretas com os parâmetros de escopo corretos. Observa-se se o framework executa ferramentas independentes em paralelo ou sequencialmente.
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 das ferramentas foi redefinido antes de cada execução. Foram executadas 100 execuções independentes 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 de ferramenta instável; 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 = mar,
howpublished = {\url{https://aimultiple.com/agentic-frameworks}},
note = {AIMultiple. Acessado em 30 Março 2026}
}Links de referência
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.