Top 5 Frameworks Agentic IA de Código Aberto
Avaliámos 4 frameworks agênticos de código aberto populares em 2.000 execuções (5 tarefas, 100 execuções cada por framework), medindo a latência de ponta a ponta, o consumo de tokens e as diferenças arquiteturais.
Benchmark de frameworks de IA agêntica
Examinámos como os próprios frameworks influenciam o comportamento dos agentes 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 utilização de tokens.
Em 5 tarefas e 2.000 execuções, o LangChain revela-se o framework mais eficiente em termos de tokens, enquanto o AutoGen lidera em latência; o LangGraph e o LangChain seguem logo atrás. O CrewAI apresenta o perfil geral mais pesado.
Tarefa 1: Agregação básica
Primeiro, medimos a sobrecarga de cada framework ao chamar uma única ferramenta e devolver o resultado, sem realizar qualquer raciocínio complexo.
LangChain & LangGraph: Para tarefas simples, têm um desempenho quase tão rápido como o código não agêntico, terminando ambos 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 percetível em comparação com o LangChain neste nível de simplicidade; a sobrecarga da gestão de estado materializa-se à medida que a complexidade da tarefa aumenta.
AutoGen: Situa-se ligeiramente acima do LangChain e do LangGraph tanto na latência como na utilização de tokens, refletindo o custo de base do seu ciclo de conversação multiagente, com dois agentes a trocar mensagens mesmo para uma tarefa de passo único.
CrewAI: Mesmo quando lhe é pedido que faça uma única chamada de ferramenta, exibe o que se pode chamar de “sobrecarga de gestão”, consumindo quase 3× os tokens do LangChain e demorando quase 3× mais tempo. O processo de verificação em várias etapas entre as suas personas Planner e Analyst oferece uma abordagem minuciosa, mas intensiva em recursos, que prioriza a completude em detrimento da velocidade. Este custo é estrutural: surge independentemente da complexidade da tarefa.
Tarefa 2: Análise comparativa de receitas (gestão de estado)
Na Tarefa 2, queríamos ver a capacidade dos frameworks de manter dois grupos de filtros diferentes em memória (persistência de estado) e combiná-los.
CrewAI
Na nossa análise de logs, constatámos que o CrewAI proporciona o nível mais elevado de transparência de infraestrutura entre os frameworks, mas ao custo do maior consumo de recursos.
Em vez de devolver imediatamente os dados obtidos, o CrewAI valida repetidamente os seus próprios processos através de um mecanismo de auto-revisão. Este comportamento exploratório levou-o a atingir o limite configurado max_iter=10, deixando algumas execuções presas num ciclo contínuo de pensamento sem produzir uma saída JSON.
A causa raiz deste comportamento é que o CrewAI injeta instruções em várias camadas no prompt do sistema, atribuindo a cada agente uma função, um objetivo e uma história de fundo, ao mesmo tempo que impõe um ciclo ReAct-style Thought → Action → Observation a cada passo. Mesmo para tarefas simples, o LLM não pode saltar este cerimonial e produz obedientemente monólogos internos prolixos, que se agravam ainda mais em cenários multiagente.
O CrewAI consumiu quase o dobro dos tokens dos outros frameworks e demorou mais de três vezes mais tempo do que o 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. Nos nossos logs, observámos que o LangChain conclui a tarefa em 5 a 6 passos sem desvios: Load → Filter → Calculate → Filter → Calculate → Output. Como a sua gestão de estado é muito simples, a sobrecarga é quase nula e a latência é a mais baixa entre todos os frameworks.
AutoGen
Apresentou um desempenho muito equilibrado. Na Tarefa 2, igualou o LangGraph quase exatamente tanto na utilização de tokens como na latência, mostrando que a sobrecarga do ciclo de conversação não se agrava significativamente quando a cadeia de tarefas permanece linear.
Contudo, acrescenta ocasionalmente um passo de verificação extra para confirmar parâmetros durante o processo de chamada de ferramenta, tornando-o ligeiramente mais lento do que o LangChain. Quando encontra um erro numa chamada de ferramenta ou os dados não voltam como esperado, atualiza imediatamente o seu raciocínio no passo seguinte e chega ao JSON correto. Como gere 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. Nos seus logs, observámos que o estado é transportado de forma muito limpa ao longo da 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 passos e dentro do mesmo intervalo 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 antiguidade” 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 esta conversão; o que realmente queríamos testar era se o framework consegue proteger estes parâmetros ao longo dos seus próprios mecanismos de repetição, 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 ciclo de re-prompt. Esta eficiência reflete-se 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 valor mais baixo nesta tarefa.
Quando queríamos medir se os limiares numéricos são preservados sem interferência do framework, estes dois corresponderam às nossas expectativas: qualquer parâmetro gerado foi exatamente o que foi executado.
AutoGen
O Autogen é totalmente bem-sucedido na correção numérica. Em algumas execuções, observou-se que o framework acrescentou um passo de verificação antes de passar o parâmetro gerado pelo LLM à ferramenta, o que significa que o framework gastou um passo extra preservando o parâmetro. Com 2.480 tokens e 8 segundos, igualou a latência do LangChain apesar do passo extra, confirmando que a sobrecarga de verificação é real mas pequena. Correspondeu às nossas expectativas em termos de integridade dos parâmetros, com o passo de confirmação a introduzir um custo de token marginal em vez de uma penalização 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 valor mais alto nesta tarefa. Da análise dos logs surgiram dois padrões de falha distintos.
Em algumas execuções, um valor que deveria ter sido 68.81% foi devolvido como 0.6878 (razão decimal). Isto indica que a serialização da saída do framework pode retirar o resultado do LLM do seu contexto original.
Os logs mostram que o LLM produziu inicialmente os parâmetros corretos, tenure_max=12 e charges_min=70. No entanto, quando o CrewAI entrou num ciclo “Failed to parse”, o framework levou 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 antiguidade inferior a 14. Este foi exatamente o cenário que queríamos observar: o mecanismo de repetição do framework pode corromper um parâmetro que o LLM tinha acertado.
Tarefa 4: Resiliência a erros e capacidade de pivot
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 sucessivamente (Network, Timeout, Rate Limit), empurrando o agente para um beco sem saída. Os dois primeiros erros instruem o agente a tentar novamente, e após tentar ambos, o erro Rate Limit que chega diz ao agente para aguardar 10 segundos. Assim que o agente aguarda 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 devolveu um aviso de limite de taxa, em vez de pausar e aguardar, estes agentes decidiram abandonar completamente a ferramenta com falha e encontrar um caminho alternativo. A sua abordagem foi: “Uma vez que esta ferramenta não está a funcionar, vou filtrar cada método de pagamento um a um, calcular a taxa de churn para cada um separadamente e depois combinar eu próprio os resultados.”
Método: Em vez de realizar a tarefa com uma única chamada de ferramenta, dividiram-na usando duas ferramentas separadas, uma para filtrar e outra para calcular, processando cada PaymentMethod (Electronic check, Mailed check, etc.) individualmente.
Estes agentes operam com um raciocínio orientado a objetivos em vez de dependência de caminho. Se o caminho mais curto não estiver disponível, podem construir um plano de execução alternativo em segundos.
O LangGraph atingiu 15.010 tokens de prompt na Tarefa 4, a contagem de tokens mais alta de uma única tarefa em todo o benchmark, porque a sua máquina de estados acumulou o histórico crescente de cada chamada de ferramenta manual de volta ao contexto em cada passo. O AutoGen seguiu com 10.750 tokens, ligeiramente mais contido devido ao seu tratamento conversacional dos resultados intermédios. Apesar disso, ambos terminaram em cerca de 24 a 27 segundos, confirmando que o custo adicional de tokens não se traduziu em latência significativa porque o pivot em si foi rápido.
CrewAI
Apesar de ter apresentado o maior consumo de tokens nas tarefas anteriores, o CrewAI exibiu o menor consumo de tokens) mas os valores de latência mais altos nesta tarefa.
Porquê o menor número de tokens?
O CrewAI não passou por uma solução manual de 10 a 15 passos como os seus concorrentes. Quando encontrou erros, em vez de introduzir repetidamente todo o histórico e dados intermédios complexos no LLM a cada passo, construiu um ciclo de raciocínio mais focado e modular. Ao evitar verbosidade desnecessária, tornou-se o framework mais económico nesta tarefa.
Porquê a alta latência?
A estrutura de gestão 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 “planeamento estratégico”. Além disso, em vez de pivotar para outra ferramenta para filtragem, optou persistentemente por aguardar que a ferramenta principal recuperasse ou tentar com a ferramenta estável, o que prolongou a duração total.
LangChain
O LangChain passou pela sua transformação mais significativa nesta tarefa, provando por que razão a resiliência depende de uma configuração adequada.
Na nossa primeira execução, o LangChain falhou em todas as tentativas com um ConnectionError.
O AgentExecutor predefinido do LangChain trata as exceções Python puras lançadas a partir de uma ferramenta como erros fatais e termina o processo. Ao contrário dos seus concorrentes, não aplica por predefinição uma filosofia de “erros são observações”. Como o agente nunca vê o erro, não tem hipótese de raciocinar sobre ele.
Envolvemos a chamada de ferramenta dentro de langchain_agent.py com um bloco try-except. Isto converteu o erro numa mensagem legível que o agente pôde processar.
Comportamento pós-correção: Depois de aplicar a correção, observámos nos logs do LangChain que este exibiu exatamente o mesmo raciocínio que o LangGraph. Recebeu 3 erros da ferramenta, mudou imediatamente de estratégia e pivotou para a utilização de 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 como o LangGraph, mas, como o tratamento de erros do framework estava desativado por predefinição, não teve oportunidade de demonstrar essa capacidade. Depois de devidamente configurado, chegou ao resultado correto utilizando a mesma abordagem de caminho alternativo.
Porque ocorreram estas diferenças? (análise da arquitetura do framework)
Se o comportamento dos agentes dependesse apenas do LLM (GPT-5.2), todos os frameworks deveriam ter-se comportado de forma semelhante. No entanto, as diferenças claras nestas proporções estão enraizadas nos próprios mecanismos de ciclo interno dos frameworks:
1. LangGraph & AutoGen (90% Pivot):
O LangGraph opera numa arquitetura de Máquina de Estados, enquanto o AutoGen funciona num 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 nó seguinte; no AutoGen, o agente Proxy encaminha o erro para o assistente como uma mensagem de chat. Este mecanismo de estímulo constante força o agente a continuar a procurar uma solução. Como o agente é repetidamente confrontado com a pergunta “Obtive um erro, o que devo fazer?”, a probabilidade de decidir tomar um caminho manual alternativo sobe para 90%.
2. LangChain (65% Pivot / 35% Espera):
O LangChain funciona numa arquitetura sequencial AgentExecutor. Mesmo com o tratamento de erros em vigor, o seu ciclo de execução tem uma estrutura mais linear e está principalmente focado em produzir uma Resposta Final. Se a ferramenta lançar erros durante 3-4 passos, o LangChain por vezes prefere esperar que a ferramenta tenha sucesso na tentativa seguinte ou produzir 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 do que o do LangGraph, a sua relação espera/solução direta situa-se em cerca de 35%.
3. CrewAI (0% Pivot):
O CrewAI opera numa arquitetura de Processo de Gestão. Os seus agentes estão envolvidos em definições de Função e Tarefa. Quando ocorrem erros, a sua arquitetura interna normalmente aciona lógica de Autocorreção ou de Repetição. No entanto, uma mudança radical de estratégia como “vamos descartar todo o plano e fazer filtragem manual em 5 passos” entra em conflito com a estrutura de plano de gestão do CrewAI. Opera com a disciplina de “devo corrigir a ferramenta que me foi dada ou usar a alternativa mais próxima” em vez de abandonar totalmente o seu plano. Esta é fundamentalmente uma abordagem centrada no plano, por oposição a uma centrada no objetivo.
Tarefa 5: Orquestração de dados não estruturados (encaminhamento de dados não estruturados)
Na tarefa 5, observámos como os frameworks se comportam quando encontram colunas JSON e de texto longo (LongText) dentro de um CSV. Os agentes precisavam de primeiro descobrir o tipo de dados destas colunas e, em seguida, selecionar as ferramentas de processamento corretas, 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-texto ou objetos aninhados.
Para que um framework lide corretamente com este tipo de dados, precisa de fazer bem duas coisas:
1- uma inteligência de descoberta que compreenda qual ferramenta se adequa a que tipo de dados
2- um mecanismo de orquestração que coordene múltiplas chamadas de ferramentas independentes.
Concebemos a Tarefa 5 especificamente para medir estas duas capacidades separadamente.
AutoGen
O AutoGen apresentou 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 mais eficiente em tokens na Tarefa 5.
O ciclo de conversação no núcleo da sua arquitetura, a troca de mensagens entre AssistantAgent e UserProxyAgent, é tipicamente visto como uma estrutura que conduz a verbosidade. No entanto, na Tarefa 5, esta estrutura transformou-se numa vantagem.
Ao olhar para o histórico de conversação, 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(…) todas executadas em paralelo. Isto permitiu-lhe concluir a tarefa em 3 turnos do LLM, com o menor número de tokens e o menor número de passos.
A razão técnica por detrás deste comportamento é clara: o motor de execução de ferramentas do AutoGen executa a lista tool_calls devolvida pelo LLM atomicamente e recolhe os resultados num único passo de conversação. A filosofia do framework de “gerir a conversação” permite naturalmente que vários canais paralelos sejam abertos ao mesmo tempo, e os números de tokens e latência confirmam-no diretamente.
LangGraph
O LangGraph terminou com 9.150 tokens de prompt e 70 segundos de mediana, próximo do AutoGen em tokens mas mais lento no tempo. A sua arquitetura de Máquina de Estados exibiu simultaneamente a sua maior força e a sua fraqueza mais notável na Tarefa 5.
Em cada execução, o ciclo nó LLM → nó de ferramentas → LLM acumula todas as saídas de ferramentas anteriores no estado e passa-as ao LLM. Esta estrutura garante que o agente nunca se esquece de nada, o que normalmente é uma vantagem significativa.
No entanto, na Tarefa 5 esta força jogou contra si. O LangGraph estava a encontrar as ferramentas corretas e a construir o segmento correto. Mas, mesmo depois de a análise estar concluída, detetou ambiguidades no estado acumulado, interpretando passos concluídos como ainda pendentes, e acionou repetidamente chamadas de ferramenta adicionais. Embora já tivesse recuperado os dados necessários e estivesse prestes a produzir a resposta correta, o sinal de “passo em falta” da máquina de estados entrou em ação e o agente entrou em ciclos desnecessários. Como resultado, o número de chamadas de ferramenta por execução variou entre 6 e 16. O poder do estado de “nunca esquecer nada” por vezes fez com que passos concluídos parecessem incompletos, 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, seguiu uma sequência impecável com 5 chamadas de ferramenta, sem desvios, executando como um script. Nestas execuções, a estrutura de gestão definida por funções e tarefas do CrewAI funcionou exatamente como pretendido: quando o agente compreendeu claramente a sua função, comportou-se de forma previsível e com disciplina.
No entanto, noutras execuções (por exemplo, execução 16: 35 chamadas de ferramenta), instalou-se o caos total. A causa raiz foi o monólogo interno (Thought) que o CrewAI gera a cada passo. 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. Esta dúvida levou-o a recarregar os dados do zero. Depois filtrou novamente, entrou noutro ciclo de verificação, duvidou novamente e repetiu esta espiral 8 vezes.
No CrewAI, cada Thought produz uma avaliação independente, e estas avaliações ocasionalmente invalidam passos previamente verificados. O reflexo de “verificação contínua” do Processo de Gestão, em algumas execuções, levou o agente a questionar novamente as suas próprias decisões corretas.
LangChain
A estrutura AgentExecutor do LangChain é inerentemente sequencial, e a Tarefa 5 foi 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 contagem de tokens mais alta.
Faz uma única chamada de ferramenta a cada passo, recebe o resultado e depois avança, 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 versus 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 fixou-se em 9 ou 15. Estes dois grupos apontam para duas estratégias típicas: em algumas execuções, saltou o passo de inspeção e foi diretamente para a análise e sumarização (9 ferramentas), enquanto noutras inspecionou primeiro cada coluna antes de processar (15 ferramentas). A identidade de executor linear do LangChain tornou-se clara aqui: não exibiu nem a eficiência paralela do AutoGen nem o caos de monólogos do CrewAI.
Gestão de dados não estruturados e arquitetura do framework
Os resultados desta tarefa revelam que a eficiência com que um framework consegue gerir dados não estruturados (JSON, LongText) está diretamente ligada ao seu mecanismo de ciclo interno:
Frameworks capazes de chamadas de ferramentas paralelas (AutoGen) podem processar colunas de dados independentes num único passo. Em cenários do mundo real que envolvem grandes objetos JSON e numerosas colunas de texto, esta diferença traduz-se numa enorme vantagem de custo e velocidade.
Frameworks com ciclos orientados por estado (LangGraph) destacam-se na consistência dos dados, mas correm o risco de reavaliar passos concluídos acumulados no histórico.
Frameworks baseados em monólogos (CrewAI) são profundamente capazes de compreender o tipo e o significado dos dados, mas esta profundidade transforma-se por vezes em questionamento excessivo e ciclos.
Frameworks de execução linear (LangChain) processam diferentes ramos de dados não estruturados separadamente, produzindo um resultado intermédio de ambos os 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 compreender estas diferenças é essencial para fazer comparações significativas.
Orquestração multiagente
A orquestração multiagente 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 funções, ferramentas e especializações distintas. Cada framework oferece abordagens diferentes à coordenação de agentes.
LangGraph
O LangGraph é um framework relativamente bem conhecido e destaca-se como uma opção fundamental para programadores que constroem sistemas de agentes.
Coordenação multiagente explícita: Pode modelar vários agentes como nós ou grupos individuais, cada um com a sua própria lógica, memória e função no sistema.
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 vários agentes comuniquem passando mensagens num ciclo. Cada agente pode responder, refletir ou chamar ferramentas com base na sua lógica interna.
Tem uma colaboração assíncrona entre agentes, o que o torna particularmente útil para cenários de investigação e prototipagem onde o comportamento do agente exige experimentação ou refinamento iterativo.
CrewAI
O CrewAI trata da maior parte da lógica de baixo nível por si e fornece orquestração multiagente:
- Integra-se com ferramentas de monitorização para rastreamento e depuração
- Controlo de execução integrado através de Flows com lógica condicional, ciclos e gestão de estado
- Suporta coordenação hierárquica (gestor-trabalhador) e estruturada de múltiplos agentes
OpenAI Swarm
Swarm é um framework multiagente leve e experimental para prototipagem. Os agentes trabalham sequencialmente através de handoffs, transferindo tarefas enquanto mantêm um contexto partilhado. Utiliza 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 ferramentas de RAG. Fornece componentes modulares, incluindo cadeias, ferramentas, memória e recuperação para fluxos de trabalho de processamento de documentos.
O LangChain opera principalmente através de padrões de execução de agente único, onde um agente gere 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 o seu próprio estado. Estes nós estão ligados através de um grafo dirigido, permitindo lógica condicional, coordenação entre equipas e controlo hierárquico. Isto permite-lhe construir e visualizar grafos multiagente com nós supervisores para orquestração escalável.
O LangGraph utiliza funções anotadas e estruturadas que associam ferramentas a agentes. Pode construir nós, ligá-los a vários supervisores e visualizar como diferentes equipas interagem. Pense nisso como dar a cada membro da equipa uma descrição detalhada do cargo. Isto facilita a construção e teste de agentes que trabalham em conjunto.
AutoGen
O AutoGen define os agentes como unidades adaptativas capazes de encaminhamento 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. Tal como o LangGraph, utiliza funções anotadas e estruturadas.
CrewAI
O CrewAI adota uma abordagem de design baseado em funções. A cada agente é atribuída uma função (por exemplo, Investigador, Programador) e um conjunto de competências, funções ou ferramentas a que pode aceder. A definição de funções é feita através de anotações estruturadas.
OpenAI Swarm
O OpenAI Swarm utiliza um modelo baseado em rotinas onde os agentes são definidos através de prompts e docstrings de funções. Não possui modelos formais de orquestração ou 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 a sua descrição), tornando esta configuração flexível mas menos precisa.
LangChain
O LangChain utiliza uma arquitetura baseada em cadeias onde um único agente orquestrador gere chamadas a modelos de linguagem e a várias ferramentas. Define funções através de interfaces explícitas, como toolkits e modelos de prompt.
Embora se concentre principalmente em fluxos de trabalho centralizados, o LangChain suporta extensões para configurações multiagente, mas carece de comunicação nativa entre agentes.
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 através do histórico de mensagens ou passagem de contexto.
Funcionalidades de memória são uma parte fundamental da construção de sistemas agênticos para recordar contexto e adaptar-se ao longo do tempo:
- Memória de curto prazo: Acompanha as 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 utilizador ou histórico de tarefas.
- Memória de entidades: Rastreia e atualiza conhecimento sobre objetos, pessoas ou conceitos específicos mencionados durante as interações (por exemplo, recordar o nome de uma empresa ou um ID de projeto mencionado anteriormente).
LangGraph
O LangGraph utiliza 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 guarda dados entre sessões. Os programadores podem usar MemorySaver para guardar o fluxo de uma tarefa e ligá-lo a um thread_id específico. Para armazenamento de longo prazo, o LangGraph suporta ferramentas como InMemoryStore ou outras bases de dados. Isto proporciona um controlo flexível sobre o âmbito e a retenção da memória entre execuções.
AutoGen
O AutoGen utiliza 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. Não tem memória persistente integrada.
CrewAI
O CrewAI fornece memória em camadas de imediato. Armazena memória de curto prazo num armazenamento vetorial ChromaDB, resultados de tarefas recentes em SQLite e memória de longo prazo numa tabela SQLite separada (com base nas descrições das tarefas). Além disso, suporta memória de entidades usando embeddings vetoriais. Esta configuração de memória é automaticamente configurada quando memory=True está ativado,
OpenAI Swarm
O Swarm é sem estado e não gere memória de forma nativa. Os programadores 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 (por exemplo, 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 gerida através de buffers em memória que rastreiam o histórico de conversação dentro de uma sessão. Para memória de longo prazo, o LangChain integra-se com armazenamentos vetoriais externos ou bases de dados para persistir embeddings e dados de recuperação.
Os programadores podem personalizar âmbitos e estratégias de memória usando classes de memória integradas, permitindo uma gestão eficiente da memória contextual e específica de entidades ao longo das interações.
Human-in-the-loop
LangGraph
O LangGraph suporta pontos de interrupção personalizados (interrupt_before) para pausar o grafo e aguardar pela entrada do utilizador a meio da execução.
AutoGen
O AutoGen suporta nativamente agentes humanos via UserProxyAgent, permitindo que os humanos revejam, aprovem ou modifiquem passos durante a colaboração entre agentes.
CrewAI:
CrewAI permite feedback após cada tarefa definindo human_input=True; o agente pausa para recolher entradas em linguagem natural do utilizador.
OpenAI Swarm
O OpenAI Swarm não oferece HITL integrado.
LangChain
O LangChain permite inserir pontos de interrupção personalizados dentro de cadeias ou agentes para pausar a execução e solicitar a entrada humana. Isto suporta revisão, feedback ou intervenção manual em pontos definidos do fluxo de trabalho.
Integração do Model Context Protocol (MCP) em frameworks de IA agêntica
Os agentes de IA precisam de interagir com ferramentas externas, como bases de dados, APIs, sistemas de ficheiros e aplicações empresariais. Sem um padrão, cada framework tinha de criar integrações personalizadas para cada ferramenta, criando um ecossistema fragmentado. O MCP resolve isto fornecendo um protocolo universal que permite a qualquer agente ligar-se a qualquer ferramenta através de uma única interface.
Como cada framework se integra com o MCP
LangGraph
O LangGraph liga-se a servidores MCP através de um adaptador que descobre automaticamente as ferramentas disponíveis e converte-as num formato compatível com o LangChain. Os agentes podem depois utilizar estas ferramentas de forma transparente juntamente com as suas capacidades nativas.
AutoGen
O AutoGen fornece integração nativa com MCP através do seu módulo de extensão. Os programadores podem ligar-se a servidores MCP e disponibilizar todas as suas ferramentas aos agentes AutoGen com apenas algumas linhas de código.
CrewAI
Os agentes CrewAI podem referenciar diretamente servidores MCP na sua configuração usando URLs simples ou definições estruturadas. O framework gere automaticamente o ciclo de vida da ligação e a gestão de erros.
OpenAI Swarm
O Swarm beneficia do suporte nativo ao MCP do OpenAI em todo o seu ecossistema. Uma vez que o OpenAI integrou o MCP no ChatGPT e no seu Agents SDK, o Swarm pode tirar partido diretamente desta infraestrutura.
LangChain
O LangChain oferece capacidades de chamada de ferramentas MCP, onde funções Python atuam como pontes para servidores MCP. Isto permite extrair ferramentas de várias fontes e integrá-las em cadeias, agentes e outros componentes do LangChain sem wrappers personalizados.
Adicionar como fonte preferencialO que fazem realmente os frameworks de IA agêntica?
Os frameworks de IA agêntica ajudam na engenharia de prompts e na gestão de como os dados fluem de e para LLMs. A um nível básico, ajudam a estruturar prompts para que o LLM responda num formato previsível e encaminhem as respostas para a ferramenta, API ou documento corretos.
Se construir de raiz, teria de definir manualmente o prompt, extrair a ferramenta que o LLM quer utilizar e acionar a chamada de API correspondente. Os frameworks simplificam isto ao:
- Orquestração de prompts: Construir, gerir e encaminhar prompts complexos para LLMs
- Integração de ferramentas: Permitir que os agentes chamem APIs externas, bases 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 – Planeador 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 Google Flights & Hotels APIs) e gera recomendações de viagem.3
CrewAI – Criador de conteúdo agêntico
O repositório oficial de exemplos do CrewAI inclui fluxos como planeamento de viagens, estratégia de marketing, análise de ações e assistentes de recrutamento, onde agentes com funções específicas (por exemplo, “Investigador”, “Redator”) colaboram em tarefas.4
O CrewAI transforma um briefing de conteúdo de alto nível num artigo completo usando Groq.
Características principais dos frameworks de IA agêntica
Suporte de modelos:
- A maioria é agnóstica em relação ao modelo, suportando múltiplos fornecedores de LLM (por exemplo, OpenAI, Anthropic, modelos de código aberto).
- No entanto, as estruturas de prompt do sistema variam consoante o framework e podem ter melhor desempenho com alguns modelos do que com outros.
- O acesso e a personalização dos prompts do sistema é frequentemente essencial para obter resultados ótimos.
Ferramentas:
- Todos os frameworks suportam uso de ferramentas, uma parte central para permitir ações dos agentes.
- Oferecem abstrações simples para definir ferramentas personalizadas.
- A maioria suporta Model-Context-Protocol (MCP), quer nativamente, quer através de extensões da comunidade.
Memória / Estado:
- Usam rastreamento de estado para manter memória de curto prazo entre passos ou chamadas a 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 de configuração fáceis para RAG, integrando bases de dados vetoriais ou armazenamentos de documentos.
- Isto permite que os agentes referenciem conhecimento externo durante a execução.
Outras características comuns
- Suporte para execução assíncrona, permitindo chamadas concorrentes a agentes ou ferramentas.
- Tratamento integrado para saídas estruturadas (por exemplo, JSON).
- Suporte para saídas em streaming, onde o modelo gera resultados incrementalmente.
- Características básicas de observabilidade para monitorização 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 em memória os resultados de dois grupos de filtros separados e combiná-los numa única saída. São testadas a gestão de estado e a coordenação entre vários segmentos.
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 repetição e re-prompt do framework conseguem preservar estes parâmetros.
Tarefa 4: Uma ferramenta lança erros de Network, Timeout e RateLimit sucessivamente. É medido se o framework muda de estratégia face a estes erros.
Tarefa 5: O agente tem de primeiro descobrir colunas JSON e LongText e, em seguida, chamar as ferramentas corretas com os parâmetros de âmbito corretos. É observado 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 no benchmark de frameworks de IA agêntica. Todos os frameworks receberam o prompt idêntico e o conjunto idêntico de ferramentas; apenas o framework que envolve o LLM mudou.
Prompt dado ao agente:
Analise os clientes que rescindiram (Churn=’Yes’) que pagam mais de 100 em MonthlyCharges.
- Filtre o dataset para Churn=’Yes’.
- Inspecione as colunas ‘Metadata’ e ‘SupportNotes’ para descobrir os seus tipos de dados.
- Extraia a distribuição de ‘device_type’ da coluna JSON ‘Metadata’.
- Conte palavras-chave de reclamações da coluna free-texto ‘SupportNotes’.
Devolva o resultado apenas como JSON.
Saída JSON necessária:
Porque é que esta tarefa discrimina entre frameworks: o agente tem de planear uma cadeia de quatro chamadas de ferramenta, manter o segmento filtrado no estado em cada chamada e reconhecer que uma coluna é JSON enquanto a outra é gratuito texto. Um framework que executa as colunas independentes em paralelo (AutoGen) termina muito mais rapidamente do que um que as executa sequencialmente (LangChain), e um framework que reavalia passos concluídos (LangGraph, CrewAI) entra em ciclos desnecessários. O esquema JSON rigoroso permite-nos pontuar a correção automaticamente.
2. Configuração
Todos os frameworks utilizaram o mesmo modelo LLM (openai/gpt-5.2) e o mesmo valor de temperatura (0.1). Para todas as tarefas, foi dado a cada agente as mesmas ferramentas e os mesmos prompts. Cada framework foi configurado na 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 utilizado. O estado das ferramentas foi reposto 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 ciclo de ferramenta instável; e 20 para a Tarefa 5 devido à cadeia de descoberta de 4 passos.
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 Agentic IA de Código Aberto}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/agentic-frameworks}},
note = {AIMultiple. Acessado em 10 Agosto 2026}
}Resultados e carimbos de data/hora de 25 pontos de dados. Baixe os dados utilizados neste artigo como um arquivo ZIP contendo 5 arquivos CSV.
Registro de alterações
10 atualizações- 2026
Substituídos os resultados e a análise do benchmark na seção "Agentic AI frameworks benchmark".
Removida uma mudança de metodologia que descrevia como as tarefas eram integradas em arquiteturas baseadas em agentes.
- 2025
Expandida a seção "Agentic frameworks benchmark" com uma lista de frameworks avaliados.
Adicionado um aviso legal aos dados de "Classificação geral".
Atualizados os dados de resultados na seção "Resultados".
Removida a seção 'Agentic frameworks benchmark'.
Expandida a seção de benchmark de frameworks agênticos com uma explicação detalhada das diferenças de uso de token.
Expandida a seção "Agentic Frameworks Benchmark: CrewAI vs LangChain" para incluir OpenAI Swarm e LangGraph.
Adicionado um benchmark comparando CrewAI e LangChain à introdução.
Adicionada uma metodologia de benchmark à seção de metodologia.
Links de referência
O trabalho de Cem na AIMultiple foi citado por publicações globais líderes, incluindo Business Insider, Forbes, Morning Brew e Washington Post, por empresas globais como Deloitte e HPE, ONGs como o World Economic Forum e organizações supranacionais como a European Commission. [1], [2], [3], [4], [5]
Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor de tecnologia. Ele aconselhou empresas sobre 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 as compras de uma operadora de telecomunicações, reportando-se ao CEO. Ele também liderou o crescimento comercial da empresa de deep tech Hypatos, que atingiu 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 líderes como TechCrunch e Business Insider.
Cem fala regularmente em conferências internacionais de tecnologia. Ele se formou como engenheiro da computação pela Bogazici University e possui um MBA pela Columbia Business School.
A seguir, leia
Best AliExpress Scrapers: Decodo, Nimble & Zyte
Arquivo da web APIs: 4 principais fornecedores testados e comparados
Os 6 principais raspadores da Apple App Store: Bright Data, SerpAPI & Zyte
Benchmark de MFT: Files.com, Diplomat MFT, Cerberus e Serv-U Testados
Top 6 LLM Scrapers: ChatGPT, Perplexity e Gemini
Melhores Scrapers do Glassdoor: Bright Data, Oxylabs & Decodo
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.