Servicios
Contáctanos

Los 5 mejores frameworks de IA agentiva de código abierto

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

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

Benchmark de frameworks de IA agentiva

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 latencia y el uso de tokens más altos.

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

Puede ver la metodología del benchmark de frameworks de IA agentiva para más detalles sobre las tareas.

Tarea 1: Agregación básica

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

LangChain y LangGraph: Para tareas simples, funcionan casi tan rápido como el código no agentivo, ambos terminando 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 a este nivel de simplicidad; la sobrecarga de la gestión del estado se materializa a medida que aumenta la complejidad de la tarea.

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

CrewAI: Incluso cuando se le pide una sola llamada a herramienta, exhibe lo que podría llamarse “sobrecarga gerencial”, consumiendo casi 3 veces los tokens de LangChain y tardando casi 3 veces más. El proceso de verificación de múltiples pasos entre sus personas de Planificador y Analista ofrece un enfoque exhaustivo 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 del estado)

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

CrewAI

En nuestro análisis de logs, descubrimos que CrewAI proporciona 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 max_iter=10, dejando algunas ejecuciones atascadas en un bucle de pensamiento continuo sin producir una salida JSON.

La causa raíz de este comportamiento es que CrewAI inyecta instrucciones multicapa en el prompt del sistema, asignando a cada agente un rol, objetivo y trasfondo, mientras aplica un bucle de Pensamiento → Acción → Observación estilo ReAct en cada paso. Incluso para tareas simples, el LLM no puede saltarse este ceremonial y genera diligentemente monólogos internos extensos, lo que se agrava aún más en escenarios multiagente.

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

LangChain

El framework más rápido y rentable. En nuestros logs, observamos que LangChain completa la tarea en 5-6 pasos sin desvíos: Cargar → Filtrar → Calcular → Filtrar → Calcular → Salida. Dado que su gestión del 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 agrava 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 encuentra un error en una llamada a herramienta o los datos no se devuelven 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 resistentes 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 logs, observamos que el estado se transporta de manera muy limpia a lo largo de la ejecución. El riesgo de contaminación de datos o de que los segmentos interfieran entre sí está en el nivel más bajo en este framework. En todas las 100 ejecuciones, produjo resultados en casi 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 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, contexto de re-prompt y ciclos de gestión del estado.

LangChain y LangGraph

Ambos frameworks pasaron los parámetros (tenure_max=12, charges_min=70) directamente a la herramienta exactamente como los produjo el LLM, sin ninguna modificación ni bucle de re-prompt. Esta eficiencia se refleja en las cifras: ambos frameworks completaron la Tarea 3 en menos de 9 segundos con menos de 1.800 tokens de prompt, el más bajo en 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 generó, eso fue lo que se ejecutó.

AutoGen

AutoGen tiene un éxito total en la 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 gastó un paso extra preservando el parámetro. Con 2.480 tokens y 8 segundos, igualó la latencia de LangChain a pesar del paso extra, confirmando que la sobrecarga de verificación es real pero pequeña. Cumplió nuestras expectativas en términos de integridad de parámetros, con el paso de confirmación introduciendo un coste marginal de tokens en lugar de una penalización significativa de latencia.

CrewAI

El comportamiento más notable se observó en CrewAI, que completó la Tarea 3 en 30 segundos con 4.360 tokens, el más alto en esta tarea. Del análisis de logs surgieron dos patrones de fallo distintos.

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

Los logs 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 deshabilitó completamente 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 pivotar

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, Timeout, Límite de velocidad), acorralando al agente. Los dos primeros errores instruyen al agente para que reintente, y después de reintentar ambos, el error entrante de Límite de velocidad le dice al agente que espere 10 segundos. Una vez que el agente espera y reintenta, la herramienta comienza a funcionar normalmente.

LangGraph y AutoGen

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

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

Método: En lugar de realizar la tarea con una sola llamada a herramienta, la desglosaron usando 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 del camino. Si el camino más corto no está disponible, pueden construir un plan de ejecución alternativo en 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 herramienta de nuevo en el contexto en cada paso. AutoGen le siguió con 10.750 tokens, ligeramente más contenido debido a su manejo conversacional de los resultados intermedios. A pesar de esto, ambos terminaron alrededor de 24-27 segundos, confirmando que el coste adicional de tokens no se tradujo en una latencia significativa porque el pivotaje 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 valores de latencia más altos) en esta tarea.

¿Por qué el menor uso de tokens?

CrewAI no siguió una solución manual de 10-15 pasos como sus competidores. Cuando encontró 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 más enfocado y modular. Al evitar la verbosidad innecesaria, se convirtió en el framework más rentable en esta tarea.

¿Por qué alta latencia?

La estructura gerencial de 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 a otra herramienta para filtrar, eligió persistentemente esperar a que la herramienta principal se recuperara o intentarlo con la herramienta estable, lo que extendió la duración total.

LangChain

LangChain experimentó su transformación más significativa en esta tarea, demostrando 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 por defecto 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 podía procesar.

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

LangChain es de hecho 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 camino alternativo.

¿Por qué ocurrieron estas diferencias? (análisis de la arquitectura del framework)

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 propios mecanismos de bucle interno de los frameworks:

1. LangGraph y AutoGen (90 % Pivot):

LangGraph opera con una arquitectura de Máquina de Estados, mientras que AutoGen funciona 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 un camino manual alternativo aumenta al 90 %.

2. LangChain (65 % Pivot / 35 % Esperar):

LangChain se ejecuta con una arquitectura AgentExecutor secuencial. Incluso con el manejo de errores implementado, su bucle de ejecución tiene una estructura más lineal y está principalmente enfocado 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 produzca 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 alrededor del 35 %.

3. CrewAI (0 % Pivot):

CrewAI opera con una arquitectura de Proceso Gerencial. Sus agentes están envueltos en definiciones de Rol y Tarea. Cuando ocurren errores, su arquitectura interna generalmente desencadena lógica de Autocorrección o Reintento. Sin embargo, un cambio radical de estrategia como “desechemos todo el plan y hagamos un filtrado manual en 5 pasos” entra en conflicto con la estructura del plan gerencial de CrewAI. Opera con la disciplina de “debería arreglar la herramienta que me dieron o usar la alternativa más cercana” en lugar de abandonar su plan por completo. Esto es fundamentalmente un enfoque centrado en el plan en contraposición a uno centrado en el objetivo.

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 encuentran columnas JSON y texto largo (LongText) dentro de un CSV. Los agentes necesitaban primero descubrir el tipo de dato de estas columnas y luego seleccionar las herramientas de procesamiento correctas, ya sea secuencialmente 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 texto libre u objetos anidados.

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

1- una inteligencia de descubrimiento que entienda qué herramienta se ajusta a cada 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, finalizando con 8.170 tokens de prompt y una latencia mediana 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, se ve típicamente como 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 la conversación, el LLM reconoció que las columnas Metadata y SupportNotes eran independientes entre sí. Luego envió una única respuesta TOOL CALLS listando 4 herramientas simultáneamente: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…), y summarize_text_column(…) se ejecutaron todas en paralelo. Esto le permitió completar la tarea en 3 turnos del 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 solo paso de la conversación. La filosofía de “gestionar la conversación” del framework permite naturalmente que se abran múltiples canales paralelos al mismo tiempo, y las cifras de tokens y latencia lo confirman directamente.

LangGraph

LangGraph finalizó con 9.150 tokens de prompt y 70 segundos de mediana, 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 nodo llm → nodo tools → nodo llm acumula todas las salidas de herramientas anteriores en el estado y las pasa al LLM. Esta estructura garantiza que el agente nunca olvide nada, lo cual normalmente es una ventaja significativa.

Sin embargo, en la Tarea 5 esta fortaleza jugó en su contra. LangGraph estaba encontrando las herramientas correctas y construyendo el segmento correcto. Pero incluso después de que el análisis estuviera completo, detectaba ambigüedades en el estado acumulado, interpretando pasos completados como aún pendientes, y activaba 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 osciló entre 6 y 16. El poder del estado de “nunca olvidar 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 en 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 gerencial 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 (por ejemplo, ejecución 16: 35 llamadas a herramientas), se produjo un caos total. La causa raíz fue el monólogo interno (Pensamiento) 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 deberían aplicarse filtros adicionales. Después de ver el resultado, dudó sobre 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, dudó otra vez y repitió esta espiral 8 veces.

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

LangChain

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

Realiza una sola llamada a herramienta en cada paso, recibe el resultado y luego avanza, lo que significa que 4 herramientas independientes requirieron 4 turnos separados del LLM con 4 períodos de espera separados. 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 estabilizó en 9 o 15. Estos dos grupos apuntan a dos estrategias típicas: en algunas ejecuciones, se saltó el paso de inspección y fue directamente a analizar y resumir (9 herramientas), mientras que en otras inspeccionó cada columna primero antes de procesar (15 herramientas). La identidad del ejecutor lineal de LangChain quedó clara aquí: no exhibió ni la eficiencia paralela de AutoGen ni el caos de monólogo de CrewAI.

Gestión de datos no estructurados y arquitectura del framework

Los resultados de esta tarea revelan que la eficiencia con la que un framework puede gestionar datos no estructurados (JSON, LongText) está directamente ligada 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 grandes objetos JSON y numerosas columnas de texto, esta diferencia se traduce en una enorme ventaja de coste y velocidad.

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

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

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

Crecimiento de estrellas en GitHub de los frameworks agentivos

Comparar frameworks de IA agentiva

Los frameworks de IA agentiva 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

LangGraph framework

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

Coordinación multiagente explícita: Puede 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

AutoGen Framework1

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

Tiene una colaboración de agentes asíncrona, 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 usted y proporciona orquestación multiagente:

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

OpenAI Swarm

Swarm framework

Swarm es un framework multiagente experimental y ligero para prototipado. Los agentes trabajan secuencialmente a través de traspasos, transfiriendo 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 con 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 a través de 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 equipos y control jerárquico. Esto le permite construir y visualizar grafos multiagente con nodos supervisores para una orquestación escalable.

LangGraph utiliza funciones estructuradas y anotadas que adjuntan herramientas a los agentes. Puede construir nodos, conectarlos a varios supervisores y visualizar cómo interactúan los diferentes equipos. Piense en ello como darle 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) intercambiando mensajes, lo que permite la resolución colaborativa de problemas. Al igual que LangGraph, utiliza funciones estructuradas y anotadas.

CrewAI

CrewAI adopta un enfoque de diseño basado en roles. A cada agente se le asigna un rol (por ejemplo, Investigador, Desarrollador) 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, confiando en cambio en flujos de trabajo estructurados manualmente. El comportamiento de las funciones es inferido por 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 los modelos de lenguaje y varias herramientas. Define funciones a través de 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 agente a agente incorporada.

Memoria

Capacidades de memoria:

  • Con estado: Si el framework soporta memoria persistente entre ejecuciones.
  • Contextual: Si soporta 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 agentivos para recordar el contexto y adaptarse con el tiempo:

  • Memoria a corto plazo: Realiza un seguimiento de las interacciones recientes, permitiendo a los agentes manejar conversaciones de múltiples 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 entidad: Rastrea y actualiza el conocimiento sobre objetos, personas o conceptos específicos mencionados durante las interacciones (por ejemplo, recordar un nombre de empresa o ID de proyecto mencionado anteriormente).

LangGraph

LangGraph utiliza dos tipos de memoria: memoria en hilo, que almacena información durante una sola tarea o conversación, y memoria entre hilos, que guarda datos a través de sesiones. Los desarrolladores pueden usar MemorySaver para guardar el flujo de una tarea y vincularlo a un thread_id específico. Para almacenamiento a largo plazo, LangGraph soporta herramientas como InMemoryStore u otras bases de datos. Esto proporciona un control flexible sobre cómo se limita y retiene la memoria a través de las 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 incorporada.

CrewAI

CrewAI proporciona memoria en capas lista para usar. Almacena la memoria a corto plazo en un almacén vectorial ChromaDB, los resultados de tareas recientes en SQLite y la memoria a largo plazo en una tabla SQLite separada (basada en descripciones de tareas). Además, soporta memoria de entidad utilizando embeddings vectoriales. Esta configuración de memoria se configura 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 ej., mem0) para almacenar contexto a más largo plazo.

LangChain

LangChain soporta tanto memoria a corto como a largo plazo a través de componentes flexibles. La memoria a corto plazo se gestiona generalmente mediante buffers en memoria que rastrean el historial de la conversación dentro de una sesión. Para la memoria a largo plazo, LangChain se integra con almacenes vectoriales externos o bases de datos para persistir los embeddings y los datos de recuperación.

Los desarrolladores pueden personalizar los alcances y estrategias de memoria utilizando clases de memoria incorporadas, lo que permite una gestión eficiente de la memoria contextual y específica de entidad a través de las interacciones.

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

Humano en el bucle

LangGraph

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

AutoGen

AutoGen soporta de forma nativa agentes humanos vía UserProxyAgent, permitiendo a los humanos revisar, aprobar o modificar pasos durante la colaboración de los agentes.

CrewAI:

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

OpenAI Swarm

OpenAI Swarm no ofrece HITL incorporado.

LangChain

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

Integración del Model Context Protocol (MCP) en frameworks de IA agentiva

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 usar estas herramientas sin problemas junto con sus capacidades nativas.

AutoGen
AutoGen proporciona integración MCP incorporada a través de su módulo de extensión. Los desarrolladores pueden conectarse a 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 directamente a servidores MCP en su configuración utilizando URLs simples o configuraciones estructuradas. El framework maneja el ciclo de vida de la conexión y la gestión de errores automáticamente.

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 MCP donde las funciones de Python actúan como puentes hacia los servidores MCP. Esto permite extraer herramientas de varias 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 agentiva?

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

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

  • Orquestación de prompts: Construir, gestionar y enrutar prompts complejos a los 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 a través de turnos o sesiones (corto y largo plazo)
  • Integración de RAG: Habilitar la recuperación de conocimiento de fuentes externas
  • Coordinación multiagente: Estructurar cómo los agentes colaboran o delegan tareas
Agentic framework2

Frameworks de IA agentiva: Casos de uso en la vida real

LangGraph – Planificador de viajes multiagente

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

CrewAI – Creador de contenido agentivo

El repositorio de ejemplos oficial de CrewAI incluye flujos como planificación de viajes, estrategia de marketing, análisis de acciones y asistentes de reclutamiento, donde agentes con roles específicos (por ejemplo, “Investigador”, “Escritor”) 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 agentiva

Soporte de modelos:

  • La mayoría son agnósticos al modelo, soportando múltiples proveedores de LLM (por ej., OpenAI, Anthropic, modelos de código abierto).
  • Sin embargo, las estructuras de los prompts del sistema varían según el framework y pueden funcionar mejor con algunos modelos que con otros.
  • El acceso y la personalización de los prompts del sistema son a menudo esenciales para obtener resultados óptimos.

Herramientas:

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

Memoria / Estado:

  • Utilizan seguimiento de estado para mantener la memoria a corto plazo a través de pasos o llamadas al LLM.
  • Algunos ayudan a los agentes a retener interacciones o contexto previos dentro de una sesión.

RAG (Generación Aumentada por Recuperación):

  • La mayoría incluye opciones de configuración sencilla 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, permitiendo llamadas concurrentes a agentes o herramientas.
  • Manejo incorporado para salidas estructuradas (por ej., JSON).
  • Soporte para salidas en streaming donde el modelo 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 herramienta con el parámetro correcto. La sobrecarga de infraestructura base del framework se revela más claramente en este escenario simple.

Tarea 2: Requiere mantener en memoria los resultados de dos grupos de filtros separados y combinarlos en una sola salida. Se prueban la gestión del 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, Timeout y Límite de Velocidad en sucesión. Se mide si el framework cambia de estrategia frente a estos errores.

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

Cómo es realmente una tarea

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

Prompt dado al agente:

Analiza a los clientes que abandonaron (Churn=’Yes’) que pagan más de 100 en MonthlyCharges.

  1. Filtra el conjunto de datos a 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 queja de la columna de texto libre ‘SupportNotes’.
    Devuelve el resultado solo 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 texto libre. Un framework que ejecuta las columnas independientes en paralelo (AutoGen) finaliza mucho más rápido que uno que las ejecuta secuencialmente (LangChain), y un framework que reevalúa los pasos completados (LangGraph, CrewAI) realiza bucles innecesarios. El esquema JSON estricto nos permite puntuar la corrección automáticamente.

2. Configuración

Todos los frameworks utilizaron el mismo modelo 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 conjunto de datos IBM Telco Customer Churn (7.032 clientes). El estado de la herramienta se restableció antes de cada ejecución. Se ejecutaron 100 ejecuciones independientes para cada combinación de framework y tarea.

Los límites máximos de iteración 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 de herramienta inestable; 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 agentiva 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 agentiva 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 agentiva de código abierto}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/agentic-frameworks}},
  note   = {AIMultiple. Recuperado el 10 de Agosto de 2026}
}
Cem Dilmegani
Cem Dilmegani
Analista Principal
Cem ha sido el analista principal en AIMultiple desde 2017. AIMultiple informa a cientos de miles de empresas (según similarWeb), incluido el 60% de Fortune 500 cada mes.

El trabajo de Cem ha sido citado por publicaciones globales líderes como Business Insider, Forbes, Washington Post, firmas globales como Deloitte, HPE y ONG como el Foro Económico Mundial y organizaciones supranacionales como la Comisión Europea.

A lo largo de su carrera, Cem se ha desempeñado 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.

Lideró la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando directamente al CEO. También lideró el crecimiento comercial de la empresa de tecnología profunda Hypatos, que alcanzó 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 habla regularmente en conferencias internacionales de tecnología. Se graduó de la Universidad de Bogazici 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 varias industrias, donde trabajó transformando conjuntos de datos 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.