Servicios
Contáctanos

Los 5 mejores frameworks de IA agéntica de código abierto

Cem Dilmegani
Cem Dilmegani
actualizado el 10 de ago. de 2026

Evaluamos 4 frameworks agénticos de código abierto populares en 2.000 ejecuciones (5 tareas, 100 ejecuciones por framework cada una), midiendo la latencia de extremo a extremo, el consumo de tokens y las diferencias arquitectónicas.

Benchmark de frameworks de IA agéntica

Examinamos cómo los propios frameworks influyen en el comportamiento del agente y el impacto resultante en la latencia y el consumo de tokens.

Loading Chart

LangGraph es el framework más rápido con los valores de latencia más bajos en todas las tareas, mientras que LangChain tiene la mayor latencia y el mayor uso de tokens.

En 5 tareas y 2.000 ejecuciones, LangChain resulta ser el framework más eficiente en tokens, mientras que AutoGen lidera en latencia; LangGraph y LangChain lo siguen de cerca. CrewAI presenta el perfil general más pesado.

Puede consultar la metodología del benchmark de frameworks de IA agéntica para obtener más detalles sobre las tareas.

Tarea 1: Agregación básica

Primero, medimos la sobrecarga de cada framework al llamar a una única herramienta y devolver el resultado, sin realizar ningún razonamiento complejo.

LangChain y LangGraph: Para tareas simples, se ejecutan casi tan rápido como el código no agéntico, ambos terminan en menos de 5 segundos con menos de 900 tokens de prompt. La arquitectura de máquina de estados de LangGraph no introduce una latencia notable en comparación con LangChain en este nivel de simplicidad; la sobrecarga de la gestión de estado se materializa a medida que crece la complejidad de la tarea.

AutoGen: Se sitúa ligeramente por encima de LangChain y LangGraph tanto en latencia como en uso de tokens, lo que refleja el coste base de su bucle de conversación multiagente, con dos agentes intercambiando mensajes incluso para una tarea de un solo paso.

CrewAI: Incluso cuando se le pide que realice una única llamada a una herramienta, muestra lo que podría denominarse “sobrecarga administrativa”, consumiendo casi 3 veces más tokens que LangChain y tardando casi 3 veces más. El proceso de verificación de varios pasos entre sus personajes Planner y Analyst ofrece un enfoque minucioso pero intensivo en recursos que prioriza la integridad sobre la velocidad. Este coste es estructural: aparece independientemente de la complejidad de la tarea.

Tarea 2: Análisis comparativo de ingresos (gestión de estado)

En la Tarea 2, queríamos ver la capacidad de los frameworks para mantener dos grupos de filtros diferentes en memoria (persistencia de estado) y combinarlos.

CrewAI

En nuestro análisis de registros, descubrimos que CrewAI ofrece el mayor nivel de transparencia de infraestructura entre los frameworks, pero a costa del mayor consumo de recursos.

En lugar de devolver inmediatamente los datos recuperados, CrewAI valida repetidamente sus propios procesos mediante un mecanismo de autorrevisión. Este comportamiento exploratorio hizo que alcanzara el límite configurado de max_iter=10, dejando algunas ejecuciones atascadas en un bucle continuo de pensamiento sin producir una salida JSON.

La causa raíz de este comportamiento es que CrewAI inyecta instrucciones de múltiples capas en el prompt del sistema, asignando a cada agente un rol, un objetivo y una historia de fondo, mientras impone un bucle de estilo ReAct de Pensamiento → Acción → Observación en cada paso. Incluso para tareas simples, el LLM no puede omitir esta ceremonia y produce diligentemente monólogos internos verbosos, lo que se agrava aún más en escenarios multiagente.

CrewAI consumió casi el doble de tokens que los demás frameworks y tardó más del triple que LangChain, lo que lo hace más adecuado para transiciones de estado complejas y toma de decisiones multifactorial en lugar de tareas sencillas de recuperación de datos.

LangChain

El framework más rápido y rentable. En nuestros registros, observamos que LangChain completa la tarea en 5-6 pasos sin desvíos: Cargar → Filtrar → Calcular → Filtrar → Calcular → Salida. Dado que su gestión de estado es muy simple, la sobrecarga es casi nula y la latencia es la más baja entre todos los frameworks.

AutoGen

Ofreció un rendimiento muy equilibrado. En la Tarea 2, igualó a LangGraph casi exactamente tanto en uso de tokens como en latencia, lo que demuestra que la sobrecarga del bucle de conversación no se acumula significativamente cuando la cadena de tareas permanece lineal.

Sin embargo, ocasionalmente añade un paso de verificación adicional para confirmar los parámetros durante el proceso de llamada a herramientas, lo que lo hace ligeramente más lento que LangChain. Cuando se encuentra con un error en una llamada a una herramienta o los datos no vuelven como se esperaba, actualiza inmediatamente su razonamiento en el siguiente paso y llega al JSON correcto. Debido a que gestiona las salidas de las herramientas como un flujo conversacional, es uno de los frameworks más resilientes frente a errores lógicos.

LangGraph

En esta tarea, LangGraph es el framework más estable gracias a su arquitectura basada en grafos. En sus registros, observamos que el estado se transporta de forma muy limpia durante toda la ejecución. El riesgo de contaminación de datos o de que los segmentos interfieran entre sí es el más bajo en este framework. En todas las 100 ejecuciones, produjo resultados casi con el mismo número de pasos y dentro del mismo rango de latencia.

Tarea 3: Análisis de umbrales (disciplina numérica)

En esta tarea, queríamos ver con qué precisión los frameworks traducen condiciones numéricas en lenguaje natural, como “menos de 1 año de antigüedad” y “más de $70 en cargos mensuales”, en parámetros de herramienta precisos como tenure_max=12 y charges_min=70.0.

El LLM sabe cómo hacer esta conversión; lo que realmente queríamos probar era si el framework puede proteger estos parámetros a lo largo de sus propios mecanismos de reintento, el contexto de re-prompt y los ciclos de gestión de estado.

LangChain y LangGraph

Ambos frameworks pasaron los parámetros (tenure_max=12, charges_min=70) directamente a la herramienta exactamente como el LLM los produjo, sin ninguna modificación ni bucle de re-prompt. Esta eficiencia se refleja en los números: ambos frameworks completaron la Tarea 3 en menos de 9 segundos con menos de 1.800 tokens de prompt, los más bajos de esta tarea.

Cuando quisimos medir si los umbrales numéricos se preservan sin que el framework interfiera, estos dos cumplieron nuestras expectativas: cualquier parámetro que se generara, eso es lo que se ejecutaba.

AutoGen

AutoGen es totalmente exitoso en corrección numérica. En algunas ejecuciones, se observó que el framework añadía un paso de verificación antes de pasar el parámetro generado por el LLM a la herramienta, lo que significa que el framework gastaba un paso adicional mientras preservaba el parámetro. Con 2.480 tokens y 8 segundos, igualó la latencia de LangChain a pesar del paso adicional, lo que confirma que la sobrecarga de verificación es real pero pequeña. Cumplió nuestras expectativas en términos de integridad de parámetros, y el paso de confirmación introdujo un coste de tokens marginal en lugar de una penalización de latencia significativa.

CrewAI

El comportamiento más notable se observó en CrewAI, que completó la Tarea 3 en 30 segundos con 4.360 tokens, los más altos de esta tarea. Surgieron dos patrones de fallo distintos del análisis de registros.

En algunas ejecuciones, un valor que debería haber sido 68.81 % se devolvió como 0.6878 (razón decimal). Esto indica que la serialización de salida del framework puede despojar la salida del LLM de su contexto original.

Los registros muestran que el LLM produjo inicialmente los parámetros correctos, tenure_max=12 y charges_min=70. Sin embargo, una vez que CrewAI entró en un bucle de “Error al analizar”, el framework empujó al LLM a reconsiderar. En el contexto de re-prompt, el LLM cambió el umbral a tenure_max=14 y desactivó por completo el filtro charges_min, produciendo una tasa de abandono del 46.84 %, que en realidad es la tasa de abandono de todos los clientes con antigüedad inferior a 14. Este era exactamente el escenario que queríamos observar: el mecanismo de reintento del framework puede corromper un parámetro que el LLM había acertado.

Tarea 4: Resiliencia ante errores y capacidad de pivote

En esta tarea, queríamos ver cómo cada framework maneja escenarios disruptivos y observar el impacto en la latencia y el consumo de tokens. La herramienta lanza 3 tipos diferentes de errores en sucesión (Red, Tiempo de espera, Límite de tasa), arrinconando al agente. Los dos primeros errores le indican al agente que reintente, y después de reintentar ambos, el error entrante de Límite de tasa le dice al agente que espere 10 segundos. Una vez que el agente espera y reintenta, la herramienta comienza a funcionar con normalidad.

LangGraph y Autogen

Estos dos frameworks encontraron soluciones alternativas de forma autónoma al enfrentarse a fallos de herramientas en esta tarea.

Cuando la herramienta devolvió una advertencia de límite de tasa, en lugar de pausar y esperar, estos agentes decidieron abandonar por completo la herramienta fallida y encontrar una ruta alternativa. Su enfoque fue: “Dado que esta herramienta no funciona, filtraré cada método de pago uno por uno, calcularé la tasa de abandono de cada uno por separado y luego combinaré los resultados yo mismo.”

Método: En lugar de realizar la tarea con una única llamada a una herramienta, la dividieron utilizando dos herramientas separadas, una para filtrar y otra para calcular, procesando cada PaymentMethod (Electronic check, Mailed check, etc.) individualmente.

Estos agentes operan con un razonamiento orientado a objetivos en lugar de dependencia de ruta. Si la ruta más corta no está disponible, pueden construir un plan de ejecución alternativo en cuestión de segundos.

LangGraph alcanzó 15.010 tokens de prompt en la Tarea 4, el recuento más alto de tokens en una sola tarea en todo el benchmark, porque su máquina de estados acumulaba el historial creciente de cada llamada manual a herramientas de vuelta al contexto en cada paso. AutoGen le siguió con 10.750 tokens, algo más contenido debido a su manejo conversacional de los resultados intermedios. A pesar de esto, ambos terminaron alrededor de 24-27 segundos, lo que confirma que el coste adicional de tokens no se tradujo en una latencia significativa porque el pivote en sí fue rápido.

CrewAI

A pesar de mostrar el mayor consumo de tokens en tareas anteriores, CrewAI exhibió el menor uso de tokens, pero los mayores valores de latencia en esta tarea.

¿Por qué el menor uso de tokens?

CrewAI no recurrió a una solución manual de 10-15 pasos como sus competidores. Cuando encontraba errores, en lugar de bombear repetidamente todo el historial y los datos intermedios complejos de vuelta al LLM en cada paso, construyó un bucle de razonamiento modular más enfocado. Al evitar la verbosidad innecesaria, se convirtió en el framework más rentable en esta tarea.

¿Por qué la alta latencia?

CrewAI pausa y reevalúa el plan cuando encuentra un error. Cuando recibió la advertencia de espera de 10 segundos, pasó más tiempo en la fase de “planificación estratégica”. Además, en lugar de pivotar hacia otra herramienta para filtrar, eligió persistentemente esperar a que la herramienta principal se recuperara o intentar con la herramienta estable, lo que prolongó la duración total.

LangChain

LangChain experimentó su transformación más significativa en esta tarea, lo que demuestra por qué la resiliencia depende de una configuración adecuada.

En nuestra ejecución inicial, LangChain falló en cada intento con un ConnectionError.

El AgentExecutor predeterminado de LangChain trata las excepciones de Python crudas lanzadas desde dentro de una herramienta como errores fatales y termina el proceso. A diferencia de sus competidores, no aplica una filosofía de “los errores son observaciones” por defecto. Dado que el agente nunca ve el error, no tiene oportunidad de razonar sobre él.

Envolvimos la llamada a la herramienta dentro de langchain_agent.py con un bloque try-except. Esto convirtió el error en un mensaje legible que el agente pudiera procesar.

Comportamiento tras la corrección: Después de aplicar la corrección, observamos en los registros de LangChain que exhibió exactamente el mismo razonamiento que LangGraph. Recibió 3 errores de la herramienta, cambió inmediatamente de estrategia y pivotó para utilizar dos herramientas separadas, una para filtrar y otra para calcular, procesó cada método de pago individualmente y combinó los resultados.

LangChain es en realidad tan capaz y adaptable como LangGraph, pero debido a que el manejo de errores del framework estaba desactivado por defecto, no tuvo oportunidad de demostrar esta capacidad. Una vez configurado correctamente, alcanzó el resultado correcto utilizando el mismo enfoque de ruta alternativa.

¿Por qué se produjeron estas diferencias? (análisis de la arquitectura de los frameworks)

Si el comportamiento del agente dependiera únicamente del LLM (GPT-5.2), todos los frameworks deberían haberse comportado de manera similar. Sin embargo, las claras diferencias en estas proporciones tienen su origen en los mecanismos de bucle interno de los propios frameworks:

1. LangGraph y AutoGen (90 % de pivote):

LangGraph opera con una arquitectura de máquina de estados, mientras que AutoGen trabaja con un modelo basado en conversación. En ambos sistemas, los errores se procesan como un bucle de retroalimentación. En LangGraph, el estado que recibe el error pasa al siguiente nodo; en AutoGen, el agente Proxy reenvía el error al asistente como un mensaje de chat. Este mecanismo de empuje constante obliga al agente a seguir buscando una solución. Debido a que el agente se enfrenta repetidamente a la pregunta “Recibí un error, ¿qué debo hacer?”, la probabilidad de que decida tomar una ruta manual alternativa aumenta al 90 %.

2. LangChain (65 % de pivote / 35 % de espera):

LangChain se ejecuta sobre una arquitectura secuencial de AgentExecutor. Incluso con el manejo de errores activo, su bucle de ejecución tiene una estructura más lineal y se centra principalmente en producir una Respuesta Final. Si la herramienta arroja errores durante 3-4 pasos, LangChain a veces prefiere esperar a que la herramienta tenga éxito en el siguiente intento o producir un resultado a partir del contexto existente, en lugar de pivotar a una estrategia alternativa. Debido a que el bloqueo de estado de LangChain es más flexible que el de LangGraph, su proporción de espera/solución directa se sitúa en torno al 35 %.

3. CrewAI (0 % de pivote):

CrewAI opera con una arquitectura de Proceso Administrativo. Sus agentes están envueltos en definiciones de Rol y Tarea. Cuando se producen errores, su arquitectura interna suele activar la lógica de Autocorrección o Reintento. Sin embargo, un cambio radical de estrategia como “desechemos todo el plan y hagamos filtrado manual en 5 pasos” entra en conflicto con la estructura de plan administrativo de CrewAI. Opera con la disciplina de “debo arreglar la herramienta que me dieron o usar la alternativa más cercana” en lugar de abandonar su plan por completo. Este es fundamentalmente un enfoque centrado en el plan, a diferencia de uno centrado en objetivos.

Tarea 5: Orquestación de datos no estructurados (enrutamiento de datos no estructurados)

En la tarea 5, observamos cómo se comportan los frameworks cuando se encuentran con columnas JSON y de texto largo (LongText) dentro de un CSV. Los agentes debían primero descubrir el tipo de datos de estas columnas y luego seleccionar las herramientas de procesamiento correctas, ya sea de forma secuencial o en paralelo.

En el mundo real, la gestión de datos no estructurados requiere que un agente vaya más allá de los datos tabulares estándar y trabaje con blobs JSON, párrafos de free-text u objetos anidados.

Para que un framework maneje correctamente este tipo de datos, debe hacer bien dos cosas:

1- una inteligencia de descubrimiento que comprenda qué herramienta se ajusta a qué tipo de dato

2- un mecanismo de orquestación que coordine múltiples llamadas a herramientas independientes.

Diseñamos la Tarea 5 específicamente para medir estas dos capacidades por separado.

AutoGen

AutoGen ofreció un rendimiento sólido en esta tarea, terminando con 8.170 tokens de prompt y una latencia media de 47 segundos, el resultado más rápido y eficiente en tokens de la Tarea 5.

El bucle de conversación en el núcleo de su arquitectura, la mensajería entre AssistantAgent y UserProxyAgent, suele considerarse una estructura que conduce a la verbosidad. Sin embargo, en la Tarea 5, esta estructura se convirtió en una ventaja.

Al observar el historial de conversación, el LLM reconoció que las columnas Metadata y SupportNotes eran independientes entre sí. Luego envió una única respuesta de LLAMADAS A HERRAMIENTAS enumerando 4 herramientas simultáneamente: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…) y summarize_text_column(…) se ejecutaron en paralelo. Esto le permitió completar la tarea en 3 turnos de LLM, con la menor cantidad de tokens y el menor número de pasos.

La razón técnica detrás de este comportamiento es clara: el motor de ejecución de herramientas de AutoGen ejecuta la lista tool_calls devuelta por el LLM de forma atómica y recopila los resultados en un único paso de conversación. La filosofía de “gestionar la conversación” del framework permite naturalmente abrir múltiples canales paralelos al mismo tiempo, y las cifras de tokens y latencia lo confirman directamente.

LangGraph

LangGraph terminó con 9.150 tokens de prompt y una mediana de 70 segundos, cerca de AutoGen en tokens pero más lento en tiempo. Su arquitectura de máquina de estados mostró simultáneamente su mayor fortaleza y su debilidad más notable en la Tarea 5.

En cada ejecución, el bucle de nodo LLM → nodo de herramientas → nodo LLM acumula todas las salidas de herramientas anteriores en el estado y las pasa al LLM. Esta estructura garantiza que el agente nunca olvida nada, lo que normalmente es una ventaja significativa.

Sin embargo, en la Tarea 5 esta fortaleza jugó en su contra. LangGraph encontraba las herramientas correctas y construía el segmento correcto. Pero incluso después de completar el análisis, detectaba ambigüedades en el estado acumulado, interpretando pasos completados como todavía pendientes, y disparaba repetidamente llamadas a herramientas adicionales. Aunque ya había recuperado los datos necesarios y estaba a punto de producir la respuesta correcta, la señal de “paso faltante” de la máquina de estados se activaba y el agente entraba en bucles innecesarios. Como resultado, el número de llamadas a herramientas por ejecución oscilaba entre 6 y 16. El poder del estado de “no olvidar nunca nada” a veces hacía que los pasos completados parecieran incompletos, arrastrando al agente de vuelta a ciclos redundantes y elevando la latencia 23 segundos por encima de AutoGen a pesar de un recuento de tokens comparable.

CrewAI

El rendimiento de CrewAI en la Tarea 5 produjo la mayor varianza de todo el benchmark. En algunas ejecuciones, siguió una secuencia impecable con 5 llamadas a herramientas, sin desvíos, ejecutándose como un script. En estas ejecuciones, la estructura administrativa definida por roles y tareas de CrewAI funcionó exactamente como se pretendía: cuando el agente entendía claramente su rol, se comportaba de manera predecible y con disciplina.

Sin embargo, en otras ejecuciones (p. ej., ejecución 16: 35 llamadas a herramientas), se produjo un caos total. La causa raíz fue el monólogo interno (Thought) que CrewAI genera en cada paso. Después de construir correctamente el segmento con el filtro adecuado, el monólogo interno del agente comenzó a cuestionar si también debían aplicarse filtros adicionales. Después de ver el resultado, dudó de si el segmento actual era válido o si el anterior debía tener prioridad. Esta duda lo empujó a recargar los datos desde cero. Luego filtró de nuevo, entró en otro bucle de verificación, volvió a dudar y repitió esta espiral 8 veces.

En CrewAI, cada Thought produce una evaluación independiente, y estas evaluaciones ocasionalmente invalidan pasos previamente verificados. El reflejo de “verificación continua” del Proceso Administrativo, en algunas ejecuciones, empujó al agente a volver a cuestionar sus propias decisiones correctas.

LangChain

La estructura AgentExecutor de LangChain es inherentemente secuencial, y la Tarea 5 es donde esa limitación fue más visible. Con 10.070 tokens de prompt y una mediana de 86 segundos, fue el framework más lento en esta tarea a pesar de no tener el mayor recuento de tokens.

Realiza una única llamada a una herramienta en cada paso, recibe el resultado y luego continúa, lo que significa que 4 herramientas independientes requirieron 4 turnos de LLM separados con 4 periodos de espera distintos. La mediana de 47 segundos de AutoGen frente a los 86 segundos de LangChain es una medición directa del coste de la ejecución secuencial frente a la paralela.

En la Tarea 5, el recuento de herramientas de LangChain se situó en 9 o 15. Estos dos grupos apuntan a dos estrategias típicas: en algunas ejecuciones, omitió el paso de inspección y pasó directamente al análisis y al resumen (9 herramientas), mientras que en otras inspeccionó primero cada columna antes de procesarla (15 herramientas). La identidad de ejecutor lineal de LangChain quedó clara aquí: no mostró ni la eficiencia paralela de AutoGen ni el caos de monólogos de CrewAI.

Gestión de datos no estructurados y arquitectura de frameworks

Los resultados de esta tarea revelan que la eficiencia con la que un framework puede gestionar datos no estructurados (JSON, LongText) está directamente vinculada a su mecanismo de bucle interno:

Los frameworks capaces de realizar llamadas a herramientas en paralelo (AutoGen) pueden procesar columnas de datos independientes en un solo paso. En escenarios del mundo real que involucran objetos JSON grandes y numerosas columnas de texto, esta diferencia se traduce en una enorme ventaja de coste y velocidad.

Los frameworks con bucles impulsados por estado (LangGraph) destacan en la consistencia de los datos, pero conllevan el riesgo de reevaluar pasos completados acumulados en el historial.

Los frameworks basados en monólogos (CrewAI) son muy capaces de comprender el tipo y el significado de los datos, pero esta profundidad a veces se convierte en un cuestionamiento excesivo y en bucles.

Los frameworks de ejecución lineal (LangChain) procesan diferentes ramas de datos no estructurados por separado, produciendo un resultado intermedio de ambos mundos.

GitHub crecimiento de estrellas de los frameworks agénticos

Comparar frameworks de IA agéntica

Los frameworks de IA agéntica varían en varias dimensiones clave, y comprender estas diferencias es esencial para hacer comparaciones significativas.

Orquestación multiagente

La orquestación multiagente coordina múltiples agentes de IA especializados para abordar flujos de trabajo complejos que superan las capacidades de un solo agente. En lugar de construir un agente monolítico, la orquestación divide el trabajo entre agentes con roles, herramientas y experiencia distintos. Cada framework ofrece diferentes enfoques para la coordinación de agentes.

LangGraph

Framework LangGraph

LangGraph es un framework relativamente conocido y destaca como una opción clave para los desarrolladores que construyen sistemas de agentes.

Coordinación multiagente explícita: Puedes modelar múltiples agentes como nodos o grupos individuales, cada uno con su propia lógica, memoria y rol en el sistema.

Crea flujos de trabajo de IA a través de APIs y herramientas. Por lo tanto, es una buena opción para RAG y pipelines personalizados.

AutoGen

Framework AutoGen1

AutoGen permite que múltiples agentes se comuniquen pasando mensajes en un bucle. Cada agente puede responder, reflexionar o llamar a herramientas según su lógica interna.

Tiene una colaboración asíncrona de agentes, lo que lo hace particularmente útil para escenarios de investigación y prototipado donde el comportamiento del agente requiere experimentación o refinamiento iterativo.

CrewAI

Crew IA1

CrewAI maneja la mayor parte de la lógica de bajo nivel por ti y proporciona orquestación multiagente:

  • Se integra con herramientas de monitoreo para el rastreo y la depuración
  • Control de ejecución integrado a través de Flows con lógica condicional, bucles y gestión de estado
  • Soporta coordinación multiagente jerárquica (manager-worker) y estructurada

OpenAI Swarm

Framework Swarm

Swarm es un framework multiagente ligero y experimental para prototipado. Los agentes trabajan secuencialmente mediante transferencias, pasando tareas mientras mantienen un contexto compartido. Utiliza rutinas en lenguaje natural y herramientas de Python para flujos de trabajo flexibles.

LangChain

LangChain es un framework para construir aplicaciones LLM de un solo agente con herramientas de RAG. Proporciona componentes modulares que incluyen cadenas, herramientas, memoria y recuperación para flujos de trabajo de procesamiento de documentos.

LangChain opera principalmente mediante patrones de ejecución de un solo agente donde un agente gestiona el flujo de trabajo.

Definición de agentes y funciones

LangGraph

LangGraph adopta un enfoque basado en grafos para el diseño de agentes, donde cada agente se representa como un nodo que mantiene su propio estado. Estos nodos están conectados a través de un grafo dirigido, lo que permite lógica condicional, coordinación entre múltiples equipos y control jerárquico. Esto permite construir y visualizar grafos multiagente con nodos supervisores para una orquestación escalable.

LangGraph utiliza funciones anotadas y estructuradas que adjuntan herramientas a los agentes. Puedes construir nodos, conectarlos a varios supervisores y visualizar cómo interactúan los diferentes equipos. Piénsalo como dar a cada miembro del equipo una descripción detallada del trabajo. Esto facilita la construcción y prueba de agentes que trabajan juntos.

AutoGen

AutoGen define a los agentes como unidades adaptativas capaces de enrutamiento flexible y comunicación asíncrona. Los agentes interactúan entre sí (y, opcionalmente, con humanos) mediante el intercambio de mensajes, lo que permite la resolución colaborativa de problemas. Al igual que LangGraph, utiliza funciones anotadas y estructuradas.

CrewAI

CrewAI adopta un enfoque de diseño basado en roles. A cada agente se le asigna un rol (por ejemplo, Researcher, Developer) y un conjunto de habilidades, funciones o herramientas a las que puede acceder. La definición de funciones se realiza mediante anotaciones estructuradas.

OpenAI Swarm

OpenAI Swarm utiliza un modelo basado en rutinas donde los agentes se definen mediante prompts y docstrings de funciones. No tiene orquestación formal ni modelos de estado, sino que se basa en flujos de trabajo estructurados manualmente. El comportamiento de las funciones lo infiere el LLM a través de docstrings (Swarm identifica lo que hace una función leyendo su descripción), lo que hace que esta configuración sea flexible pero menos precisa.

LangChain

LangChain utiliza una arquitectura basada en cadenas donde un único agente orquestador gestiona las llamadas a language models y a varias herramientas. Define funciones mediante interfaces explícitas como toolkits y plantillas de prompt.

Aunque se centra principalmente en flujos de trabajo centralizados, LangChain admite extensiones para configuraciones multiagente, pero carece de comunicación integrada entre agentes.

Memoria

Capacidades de memoria:

  • Con estado: Si el framework admite memoria persistente entre ejecuciones.
  • Contextual: Si admite memoria a corto plazo mediante historial de mensajes o paso de contexto.

Las características de memoria son una parte clave de la construcción de sistemas agénticos para recordar el contexto y adaptarse con el tiempo:

  • Memoria a corto plazo: Realiza un seguimiento de las interacciones recientes, lo que permite a los agentes manejar conversaciones de varios turnos o flujos de trabajo paso a paso.
  • Memoria a largo plazo: Almacena información persistente entre sesiones, como preferencias del usuario o historial de tareas.
  • Memoria de entidades: Rastrea y actualiza el conocimiento sobre objetos, personas o conceptos específicos mencionados durante las interacciones (por ejemplo, recordar el nombre de una empresa o el ID de un proyecto mencionado anteriormente).

LangGraph

LangGraph utiliza dos tipos de memoria: memoria dentro del hilo, que almacena información durante una sola tarea o conversación, y memoria entre hilos, que guarda datos entre sesiones. Los desarrolladores pueden usar MemorySaver para guardar el flujo de una tarea y vincularlo a un(a) thread_id específico(a). Para el almacenamiento a largo plazo, LangGraph admite herramientas como InMemoryStore u otras bases de datos. Esto proporciona un control flexible sobre cómo se delimita y retiene la memoria entre ejecuciones.

AutoGen

AutoGen utiliza un modelo de memoria contextual. Cada agente mantiene contexto a corto plazo a través de un objeto context_variables, que almacena el historial de interacciones. No tiene memoria persistente integrada.

CrewAI

CrewAI proporciona memoria en capas lista para usar. Almacena la memoria a corto plazo en un almacén vectorial ChromaDB, los resultados recientes de tareas en SQLite y la memoria a largo plazo en una tabla SQLite separada (basada en las descripciones de las tareas). Además, admite memoria de entidades mediante embeddings vectoriales. Esta configuración de memoria se activa automáticamente cuando memory=True está habilitado,

OpenAI Swarm

Swarm es sin estado y no gestiona la memoria de forma nativa. Los desarrolladores pueden pasar memoria a corto plazo a través de context_variables manualmente y, opcionalmente, integrar herramientas externas o capas de memoria de terceros (por ejemplo, mem0) para almacenar contexto a más largo plazo.

LangChain

LangChain admite memoria tanto a corto como a largo plazo mediante componentes flexibles. La memoria a corto plazo se gestiona normalmente mediante búferes en memoria que rastrean el historial de conversación dentro de una sesión. Para la memoria a largo plazo, LangChain se integra con almacenes vectoriales o bases de datos externos para persistir embeddings y datos de recuperación.

Los desarrolladores pueden personalizar los ámbitos y las estrategias de memoria utilizando clases de memoria integradas, lo que permite una gestión eficiente de la memoria contextual y específica de entidades a lo largo de las interacciones.

Deja que nuestro equipo automatice uno de tus procesos de negocio con agentes de IA, sin coste alguno.
Automatizar un proceso

Human-in-the-loop

LangGraph

LangGraph admite puntos de interrupción personalizados (interrupt_before) para pausar el grafo y esperar la entrada del usuario en mitad de la ejecución.

AutoGen

AutoGen admite de forma nativa agentes humanos a través de UserProxyAgent, lo que permite a los humanos revisar, aprobar o modificar pasos durante la colaboración de los agentes.

CrewAI:

CrewAI permite la retroalimentación después de cada tarea estableciendo human_input=True; el agente se pausa para recopilar la entrada en lenguaje natural del usuario.

OpenAI Swarm

OpenAI Swarm no ofrece HITL integrado.

LangChain

LangChain permite insertar puntos de interrupción personalizados dentro de cadenas o agentes para pausar la ejecución y solicitar la entrada humana. Esto admite revisión, retroalimentación o intervención manual en puntos definidos del flujo de trabajo.

Integración del Model Context Protocol (MCP) en los frameworks de IA agéntica

Los agentes de IA necesitan interactuar con herramientas externas como bases de datos, APIs, sistemas de archivos y aplicaciones empresariales. Sin un estándar, cada framework tenía que construir integraciones personalizadas para cada herramienta, creando un ecosistema fragmentado. MCP resuelve esto proporcionando un protocolo universal que permite a cualquier agente conectarse a cualquier herramienta a través de una única interfaz.

Cómo se integra cada framework con MCP

LangGraph
LangGraph se conecta a los servidores MCP a través de un adaptador que descubre automáticamente las herramientas disponibles y las convierte a un formato compatible con LangChain. Los agentes pueden utilizar estas herramientas sin fricciones junto con sus capacidades nativas.

AutoGen
AutoGen proporciona integración integrada de MCP a través de su módulo de extensión. Los desarrolladores pueden conectarse a los servidores MCP y poner todas sus herramientas a disposición de los agentes de AutoGen con solo unas pocas líneas de código.

CrewAI
Los agentes de CrewAI pueden hacer referencia directa a los servidores MCP en su configuración mediante URLs simples o ajustes estructurados. El framework gestiona automáticamente el ciclo de vida de la conexión y la gestión de errores.

OpenAI Swarm
Swarm se beneficia del soporte nativo de OpenAI para MCP en todo su ecosistema. Dado que OpenAI integró MCP en ChatGPT y su Agents SDK, Swarm puede aprovechar esta infraestructura directamente.

LangChain
LangChain ofrece capacidades de llamada a herramientas de MCP en las que las funciones de Python actúan como puentes hacia los servidores MCP. Esto permite extraer herramientas de diversas fuentes e integrarlas en cadenas, agentes y otros componentes de LangChain sin envoltorios personalizados.

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.
GoogleAñadir como fuente preferida

¿Qué hacen realmente los frameworks de IA agéntica?

Los frameworks de IA agéntica ayudan con la ingeniería de prompts y la gestión de cómo fluyen los datos hacia y desde los LLMs. A nivel básico, ayudan a estructurar prompts para que el LLM responda en un formato predecible y enruten las respuestas a la herramienta, API o documento correctos.

Si se construye desde cero, habría que definir manualmente el prompt, extraer la herramienta que el LLM quiere usar y activar la llamada API correspondiente. Los frameworks agilizan esto mediante:

  • Orquestación de prompts: Construir, gestionar y enrutar prompts complejos hacia LLMs
  • Integración de herramientas: Permitir que los agentes llamen a APIs externas, bases de datos, funciones de código, etc.
  • Memoria: Mantener el estado entre turnos o sesiones (a corto y largo plazo)
  • Integración de RAG: Permitir la recuperación de conocimiento de fuentes externas
  • Coordinación multiagente: Estructurar cómo los agentes colaboran o delegan tareas
Framework agéntico2

Frameworks de IA agéntica: casos de uso reales

LangGraph: planificador de viajes multiagente

Un proyecto de producción construido con LangGraph demuestra un asistente de viajes multiagente con estado que obtiene datos de vuelos y hoteles (utilizando las Google Flights & Hotels APIs) y genera recomendaciones de viaje.3

CrewAI: creador de contenido agéntico

El repositorio oficial de ejemplos de CrewAI incluye flujos como planificación de viajes, estrategia de marketing, análisis de acciones y asistentes de contratación, donde agentes con roles específicos (por ejemplo, “Researcher”, “Writer”) colaboran en tareas.4

CrewAI convierte un resumen de contenido de alto nivel en un artículo completo utilizando Groq.

Características principales de los frameworks de IA agéntica

Soporte de models:

  • La mayoría son model-agnostic, y admiten múltiples proveedores de LLM (p. ej., OpenAI, Anthropic, models de código abierto).
  • Sin embargo, las estructuras de prompts del sistema varían según el framework y pueden funcionar mejor con algunos models que con otros.
  • El acceso y la personalización de los prompts del sistema suelen ser esenciales para obtener resultados óptimos.

Herramientas:

  • Todos los frameworks admiten el uso de herramientas, una parte central para permitir las acciones de los agentes.
  • Ofrecen abstracciones simples para definir herramientas personalizadas.
  • La mayoría admite Model-Context-Protocol (MCP), ya sea de forma nativa o mediante extensiones de la comunidad.

Memoria / Estado:

  • Utilizan seguimiento de estado para mantener la memoria a corto plazo entre pasos o llamadas a LLM.
  • Algunos ayudan a los agentes a retener interacciones o contextos anteriores dentro de una sesión.

RAG (generación aumentada por recuperación):

  • La mayoría incluye opciones sencillas de configuración para RAG, integrando bases de datos vectoriales o almacenes de documentos.
  • Esto permite a los agentes hacer referencia a conocimiento externo durante la ejecución.

Otras características comunes

  • Soporte para ejecución asíncrona, que permite llamadas concurrentes a agentes o herramientas.
  • Gestión integrada de salidas estructuradas (p. ej., JSON).
  • Soporte para salidas en streaming donde el model genera resultados de forma incremental.
  • Características básicas de observabilidad para monitorear y depurar las ejecuciones de los agentes.

Metodología del benchmark

1. Estructura de las tareas

Tarea 1: Mide si se puede realizar una única llamada a una herramienta con el parámetro correcto. La sobrecarga de la infraestructura base del framework se revela con mayor claridad en este escenario sencillo.

Tarea 2: Requiere mantener en memoria los resultados de dos grupos de filtros separados y combinarlos en una única salida. Se ponen a prueba la gestión de estado y la coordinación de múltiples segmentos.

Tarea 3: Mide si las condiciones numéricas en lenguaje natural se traducen en parámetros de herramienta sin distorsión. La verdadera prueba es si los mecanismos de reintento y re-prompt del framework pueden preservar estos parámetros.

Tarea 4: Una herramienta lanza errores de Red, Tiempo de espera y Límite de tasa en sucesión. Se mide si el framework cambia de estrategia ante estos errores.

Tarea 5: El agente debe primero descubrir las columnas JSON y LongText y, a continuación, llamar a las herramientas correctas con los parámetros de alcance correctos. Se observa si el framework ejecuta herramientas independientes en paralelo o secuencialmente.

Cómo es realmente una tarea

Para hacer concreta la configuración, aquí está la Tarea 5, la tarea más compleja del benchmark de frameworks de IA agéntica. Cada framework recibió el mismo prompt y el mismo conjunto de herramientas; solo cambió el framework que envolvía al LLM.

Prompt entregado al agente:

Analiza a los clientes que se dieron de baja (Churn='Yes') que pagan más de 100 en MonthlyCharges.

  1. Filtra el dataset para Churn='Yes'.
  2. Inspecciona las columnas ‘Metadata’ y ‘SupportNotes’ para descubrir sus tipos de datos.
  3. Extrae la distribución de ‘device_type’ de la columna JSON ‘Metadata’.
  4. Cuenta las palabras clave de quejas de la columna free-text ‘SupportNotes’.
    Devuelve el resultado únicamente como JSON.

Salida JSON requerida:

Por qué esta tarea discrimina entre frameworks: el agente tiene que planificar una cadena de cuatro llamadas a herramientas, mantener el segmento filtrado en el estado a lo largo de cada llamada y reconocer que una columna es JSON mientras que la otra es gratis text. Un framework que ejecuta las columnas independientes en paralelo (AutoGen) termina mucho más rápido que uno que las ejecuta secuencialmente (LangChain), y un framework que reevalúa pasos completados (LangGraph, CrewAI) entra en bucles innecesarios. El esquema estricto de JSON nos permite puntuar la corrección automáticamente.

2. Configuración

Todos los frameworks utilizaron el mismo model de LLM (openai/gpt-5.2) y el mismo valor de temperatura (0.1). Para todas las tareas, cada agente recibió las mismas herramientas y los mismos prompts. Cada framework se configuró en su estructura nativa: LangChain con AgentExecutor, LangGraph con StateGraph, AutoGen con AssistantAgent + UserProxyAgent y CrewAI con Agent + Task + Crew.

Se utilizó el dataset Telco Customer Churn de IBM (7.032 clientes). El estado de las herramientas se restablecía antes de cada ejecución. Se ejecutaron 100 ejecuciones independientes para cada combinación de framework y tarea.

Los límites máximos de iteraciones se establecieron según la complejidad de la tarea: 10 para las Tareas 1, 2 y 3; 20 para la Tarea 4 debido al bucle inestable de la herramienta; y 20 para la Tarea 5 debido a la cadena de descubrimiento de 4 pasos.

Cita este benchmark

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

Cem Dilmegani and Nazlı Şipi (2026) - "Los 5 mejores frameworks de IA agéntica de código abierto". Publicado en línea en AIMultiple.com. Recuperado el 10 de Agosto de 2026, de: https://aimultiple.com/agentic-frameworks [Recurso en línea]

Dilmegani, C., & Şipi, N. (2026, 10 de Agosto). Los 5 mejores frameworks de IA agéntica de código abierto. AIMultiple. https://aimultiple.com/agentic-frameworks

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Şipi, Nazlı},
  title  = {{Los 5 mejores frameworks de IA agéntica de código abierto}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/agentic-frameworks}},
  note   = {AIMultiple. Recuperado el 10 de Agosto de 2026}
}
Descargar todos los datos

Resultados y marcas de tiempo de 25 puntos de datos. Descargue los datos utilizados en este artículo como un archivo ZIP que contiene 5 archivos CSV.

Última actualización: 17 de Agosto de 2026
Descargar

Registro de cambios

10 actualizaciones
  1. 2026

    Se reemplazaron los resultados y el análisis del benchmark en la sección "Agentic AI frameworks benchmark".

  2. Se eliminó un cambio metodológico que describía cómo se integraban las tareas en arquitecturas basadas en agentes.

  3. 2025

    Expandida la sección "Agentic frameworks benchmark" con una lista de frameworks evaluados.

  4. Se añadió un descargo de responsabilidad a los datos de la sección "Clasificación general".

  5. Actualizados los datos de resultados en la sección "Resultados".

  6. Eliminada la sección 'Agentic frameworks benchmark'.

  7. Se amplió la sección de evaluación comparativa de frameworks agenciales con una explicación detallada de las diferencias en el uso de tokens.

  8. Se amplió la sección "Agentic Frameworks Benchmark: CrewAI vs LangChain" para incluir OpenAI Swarm y LangGraph.

  9. Se añadió un benchmark comparando CrewAI y LangChain a la introducción.

  10. Se añadió una metodología de evaluación comparativa a la sección de metodología.

Cem Dilmegani
Cem Dilmegani
Analista Principal
Cem ha sido el analista principal en AIMultiple desde 2017.

El trabajo de Cem en AIMultiple ha sido citado por publicaciones líderes mundiales como Business Insider, Forbes, Morning Brew y Washington Post, empresas globales como Deloitte y HPE, ONG como World Economic Forum y organizaciones supranacionales como European Commission. [1], [2], [3], [4], [5]

A lo largo de su carrera, Cem trabajó como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.

Dirigió la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando al CEO. También lideró el crecimiento comercial de la empresa de deep tech Hypatos, que alcanzó unos ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.

Cem participa habitualmente en conferencias internacionales de tecnología. Se graduó en Bogazici University como ingeniero informático y tiene un MBA de Columbia Business School.
Ver perfil completo
Investigado por
Nazlı Şipi
Nazlı Şipi
Investigadora de IA
Nazlı es analista de datos en AIMultiple. Tiene experiencia previa en análisis de datos en diversas industrias, donde trabajó transformando datasets complejos en información procesable.
Ver perfil completo

Comentarios 1

Comparte tus ideas

Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.

0/450
Chaitanya
Chaitanya
Dec 19, 2025 at 01:47

Thank you for this informative and detailed article! It helped me get a reading on these frameworks.