Los 5 mejores frameworks de IA agéntica de código abierto
Evaluamos 4 frameworks agénticos de código abierto populares a través de 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 agéntica
Examinamos cómo los frameworks mismos influyen en el comportamiento del agente y el impacto resultante en la latencia y el consumo de tokens.
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.
A través de 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 general más pesado.
Puede ver nuestra metodología en detalle aquí.
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 & LangGraph: Para tareas simples, funcionan casi tan rápido como el código no agéntico, 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 perceptible en comparación con LangChain en este nivel de simplicidad; la sobrecarga de la gestión de estados 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, reflejando el costo base de su bucle de conversación multi-agente, con dos agentes intercambiando mensajes incluso para una tarea de un solo paso.
CrewAI: Incluso cuando se le pide realizar una sola llamada a una 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 completitud sobre la velocidad. Este costo es estructural: aparece independientemente de la complejidad de la tarea.
Tarea 2: Análisis comparativo de ingresos (gestión de estados)
En la Tarea 2, quisimos 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, encontramos que CrewAI proporciona el mayor nivel de transparencia de infraestructura entre los frameworks, pero al costo del mayor consumo de recursos.
En lugar de devolver inmediatamente los datos recuperados, CrewAI valida repetidamente sus propios procesos a través de un mecanismo de autorevisión. Este comportamiento exploratorio causó que alcanzara el límite configurado de max_iter=10, dejando algunas ejecuciones atrapadas en un bucle de pensamiento continuo 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, una meta y una historia, mientras impone un bucle de estilo ReAct de Pensamiento → Acción → Observación en cada paso. Incluso para tareas simples, el LLM no puede saltarse esta ceremonia y produce diligentemente monólogos internos verbosos, lo que se agrava aún más en escenarios multi-agente.
CrewAI consumió casi el doble de tokens que los otros frameworks y tardó más de tres veces más que LangChain, lo que lo hace más adecuado para transiciones de estado complejas y toma de decisiones multifactoriales que para 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 estados 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 el uso de tokens como en la latencia, demostrando 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 extra para confirmar los parámetros durante el proceso de llamada a la herramienta, lo que lo hace ligeramente más lento que LangChain. Cuando encuentra un error en una llamada a la herramienta o los datos no regresan 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 contra 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 manera muy limpia durante toda 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 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, quisimos 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 precisos de herramientas 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 través de sus propios mecanismos de reintento, contexto de re-prompt y ciclos de gestión de estado.
LangChain & 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, el valor 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 generado fue el que se ejecutó.
AutoGen
Autogen tuvo é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 mientras preservaba 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 costo 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, el más alto en esta tarea. Dos patrones de falla distintos surgieron del análisis de registros.
En algunas ejecuciones, un valor que debería haber sido 68.81% fue devuelto como 0.6878 (relació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 inicialmente produjo 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” (Failed to parse), el framework presionó al LLM para reconsiderar. En el contexto del re-prompt, el LLM cambió el umbral a tenure_max=14 y desactivó completamente el filtro charges_min, produciendo una tasa de deserción del 46.84%, que es en realidad la tasa de deserción de todos los clientes con antigüedad menor a 14. Este fue exactamente el escenario que queríamos observar: el mecanismo de reintento del framework puede corromper un parámetro que el LLM había obtenido correctamente.
Tarea 4: Resiliencia ante errores y capacidad de pivote
En esta tarea, quisimos ver cómo maneja cada framework los 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), acorralando al agente. Los dos primeros errores instruyen al agente a reintentar, y después de reintentar ambos, el error de Límite de tasa entrante le dice al agente que espere 10 segundos. Una vez que el agente espera y reintenta, la herramienta comienza a funcionar normalmente.
LangGraph & Autogen
Estos dos frameworks encontraron soluciones alternativas autónomamente al enfrentarse a fallas 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 la herramienta fallida por completo y buscar un camino alternativo. Su enfoque fue: “Dado que esta herramienta no funciona, filtraré cada método de pago uno por uno, calcularé la tasa de deserción para cada uno por separado y luego combinaré los resultados yo mismo”.
Método: En lugar de lograr la tarea con una sola llamada a la herramienta, la desglosaron utilizando dos herramientas separadas, una para filtrar y otra para calcular, procesando cada PaymentMethod (Cheque electrónico, Cheque enviado por correo, etc.) individualmente.
Estos agentes operan con un razonamiento orientado a metas en lugar de una dependencia de la ruta. Si la ruta más corta 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 de tokens de tarea única más alto en todo el benchmark, porque su máquina de estados acumuló el historial creciente de cada llamada manual a la herramienta nuevamente 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 costo 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 valores de latencia más altos en esta tarea.
¿Por qué el menor token?
CrewAI no pasó por 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 nuevamente 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 de estrategia”. Además, en lugar de pivotar a otra herramienta para filtrar, eligió persistentemente esperar a que la herramienta principal se recuperara o intentar con la herramienta estable, lo que extendió la duración general.
LangChain
LangChain pasó por 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 predeterminado de LangChain trata las excepciones crudas de Python lanzadas desde 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 registros de LangChain que exhibió exactamente el mismo razonamiento que LangGraph. Recibió 3 errores de la herramienta, cambió inmediatamente de estrategia y pivotó al uso de 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é 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 están arraigadas en los propios mecanismos de bucle interno de los frameworks:
1. LangGraph & AutoGen (90% Pivote):
LangGraph opera en una arquitectura de Máquina de Estados, mientras que AutoGen trabaja en 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 impulso constante obliga al agente a seguir buscando una solución. Debido a que el agente se enfrenta repetidamente a la pregunta “obtuve un error, ¿qué debo hacer?”, la probabilidad de que decida tomar una ruta manual alternativa sube al 90%.
2. LangChain (65% Pivote / 35% Espera):
LangChain se ejecuta en una arquitectura de AgentExecutor secuencial. Incluso con el manejo de errores implementado, su bucle de ejecución tiene una estructura más lineal y se enfoca principalmente en producir una Respuesta Final. Si la herramienta lanza 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 alrededor del 35%.
3. CrewAI (0% Pivote):
CrewAI opera en una arquitectura de Proceso Gerencial. Sus agentes están envueltos en definiciones de Rol y Tarea. Cuando ocurren errores, su arquitectura interna normalmente activa una lógica de Autocorrección o Reintento. Sin embargo, un cambio de estrategia radical como “descartemos todo el plan y hagamos el filtrado manual en 5 pasos” entra en conflicto con la estructura del plan gerencial de CrewAI. Opera con la disciplina de “debo arreglar la herramienta que se me dio o usar la alternativa más cercana” en lugar de abandonar su plan por completo. Este es fundamentalmente un enfoque centrado en el plan, en contraposición a uno centrado en la meta.
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 de texto largo (LongText) dentro de un CSV. Los agentes necesitaban primero descubrir el tipo de datos de estas columnas y luego seleccionar las herramientas de procesamiento correctas, ya sea de forma secuencial o paralela.
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 dos cosas bien:
1- una inteligencia de descubrimiento que entienda qué herramienta se ajusta a qué tipo de datos
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 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, el intercambio de mensajes 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 mirar el historial de la conversación, el LLM reconoció que las columnas Metadata y SupportNotes eran independientes entre sí. Luego envió una única respuesta de TOOL CALLS enumerando 4 herramientas simultáneamente: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…) y summarize_text_column(…) todas se ejecutaron en paralelo. Esto le permitió completar la tarea en 3 turnos de LLM, con la menor cantidad de tokens y 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 atómicamente y recopila los resultados en un solo paso de 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 los números de tokens y latencia confirman esto directamente.
LangGraph
LangGraph terminó 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 herramientas → nodo llm acumula todas las salidas previas de las herramientas en el estado y las pasa al LLM. Esta estructura garantiza que el agente nunca olvide nada, lo cual es normalmente una ventaja significativa.
Sin embargo, en la Tarea 5 esta fortaleza trabajó en su contra. LangGraph estaba encontrando las herramientas correctas y construyendo el segmento correcto. Pero incluso después de que el análisis se completó, detectó ambigüedades en el estado acumulado, interpretando pasos completados como aún pendientes, y activó repetidamente llamadas a herramientas adicionales. Aunque 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 activó y el agente entró 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 “no olvidar nunca nada” a veces hizo 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 rol y tarea 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ó si el segmento actual era válido o si el anterior debía tener prioridad. Esta duda lo impulsó a recargar los datos desde cero. Luego filtró de nuevo, entró en otro bucle de verificación, dudó de nuevo 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 cuestionar nuevamente sus propias decisiones correctas.
LangChain
La estructura 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 la herramienta en cada paso, recibe el resultado y luego avanza, lo que significa que 4 herramientas independientes requirieron 4 turnos de LLM separados con 4 períodos de espera distintos. La mediana de 47 segundos de AutoGen frente a los 86 segundos de LangChain es una medida directa del costo 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 pasó directamente al análisis y resumen (9 herramientas), mientras que en otras inspeccionó cada columna primero antes de procesar (15 herramientas). La identidad de ejecutor lineal de LangChain quedó clara aquí: no exhibió ni la eficiencia paralela de AutoGen ni el caos de monólogos 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 objetos JSON grandes y numerosas columnas de texto, esta diferencia se traduce en una ventaja masiva de costo y velocidad.
Los frameworks con bucles impulsados por el 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ólogos (CrewAI) son profundamente capaces de comprender el tipo y el significado de los datos, pero esta profundidad a veces se convierte en cuestionamientos y bucles excesivos.
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 de GitHub 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 realizar comparaciones significativas.
Orquestación multi-agente
La orquestación multi-agente 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 único 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 es un framework relativamente conocido y destaca como una opción clave para los desarrolladores que construyen sistemas de agentes.
Coordinación multi-agente 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 adecuado para RAG y pipelines personalizados.
AutoGen
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
CrewAI maneja la mayor parte de la lógica de bajo nivel por usted y proporciona orquestación multi-agente:
- 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 multi-agente jerárquica (gerente-trabajador) y estructurada
OpenAI Swarm
Swarm es un framework multi-agente ligero y experimental para prototipado. Los agentes trabajan secuencialmente a través de traspasos (handoffs), transfiriendo tareas mientras mantienen un contexto compartido. Utiliza rutinas de lenguaje natural y herramientas de Python para flujos de trabajo flexibles.
LangChain
LangChain es un framework para construir aplicaciones de 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 agente y función
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 la lógica condicional, la coordinación de múltiples equipos y el control jerárquico. Esto le permite construir y visualizar grafos multi-agente 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 de su trabajo. Esto facilita la construcción y prueba de agentes que trabajan juntos.
AutoGen
AutoGen define a los agentes como unidades adaptativas capaces de un 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 a través de anotaciones estructuradas.
OpenAI Swarm
OpenAI Swarm utiliza un modelo basado en rutinas donde los agentes se definen a través de prompts y docstrings de funciones. No tiene modelos formales de orquestación o estado, basándose en su lugar 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 diversas herramientas. Define las 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 multi-agente, pero carece de comunicación integrada de agente a agente.
Memoria
Capacidades de memoria>:
- Con estado (Stateful): Si el framework soporta memoria persistente entre ejecuciones.
- Contextual: Si soporta memoria a corto plazo a través del historial de mensajes o el 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, permitiendo que los agentes manejen conversaciones de varios turnos o flujos de trabajo paso a paso.
- Memoria a largo plazo: Almacena información persistente entre sesiones, como las preferencias del usuario o el 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 el nombre de una empresa o el ID de un proyecto mencionado anteriormente).
LangGraph
LangGraph utiliza dos tipos de memoria: memoria intra-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 thread_id específico. Para el almacenamiento a largo plazo, LangGraph soporta herramientas como InMemoryStore u otras bases de datos. Esto proporciona un control flexible sobre cómo se define el alcance de la memoria y cómo se retiene entre ejecuciones.
AutoGen
AutoGen utiliza un modelo de memoria contextual. Cada agente mantiene un contexto a corto plazo a través de un objeto context_variables, que almacena el historial de interacción. No tiene memoria persistente integrada.
CrewAI
CrewAI proporciona memoria por capas de forma nativa. Almacena la memoria a corto plazo en un almacén de vectores 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 la memoria de entidad utilizando embeddings vectoriales. Esta configuración de memoria se configura automáticamente cuando se habilita memory=True,
OpenAI Swarm
Swarm es sin estado (stateless) y no gestiona la memoria de forma nativa. Los desarrolladores pueden pasar la memoria a corto plazo a través de context_variables manualmente, e integrar opcionalmente herramientas externas o capas de memoria de terceros (por ejemplo, mem0) para almacenar el contexto a más largo plazo.
LangChain
LangChain soporta memoria tanto a corto como a largo plazo a través de componentes flexibles. La memoria a corto plazo se gestiona normalmente 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 de vectores externos o bases de datos para persistir embeddings y datos de recuperación.
Los desarrolladores pueden personalizar los alcances y estrategias de memoria utilizando clases de memoria integradas, permitiendo una gestión eficiente de la memoria contextual y específica de la entidad a través de las interacciones.
Humano en el bucle (Human-in-the-loop)
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 nativamente agentes humanos a través de UserProxyAgent, permitiendo que los humanos revisen, aprueben o modifiquen pasos durante la colaboración de agentes.
CrewAI:
CrewAI permite la retroalimentación después de cada tarea configurando 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 las cadenas o agentes para pausar la ejecución y solicitar la entrada humana. Esto admite la revisión, la retroalimentación o la intervención manual en puntos definidos del flujo de trabajo.
Añadir como fuente preferidaIntegración del Model Context Protocol (MCP) en 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 que cualquier agente se conecte a cualquier herramienta a través de una única interfaz.
Cómo se integra cada framework con MCP
LangGraph
LangGraph se conecta a 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 entonces utilizar estas herramientas a la perfección junto con sus capacidades nativas.
AutoGen
AutoGen proporciona integración MCP integrada 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 directa a servidores MCP en su configuración utilizando URLs simples o ajustes estructurados. El framework gestiona 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 SDK de Agentes, 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 diversas fuentes e integrarlas en cadenas, agentes y otros componentes de LangChain sin envoltorios personalizados.
¿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 un nivel básico, ayudan a estructurar los prompts para que el LLM responda en un formato predecible y enruten las respuestas a la herramienta, API o documento correcto.
Si construyera desde cero, definiría manualmente el prompt, extraería la herramienta que el LLM quiere usar y activaría la llamada a la API correspondiente. Los frameworks optimizan esto mediante:
- Orquestación de prompts: Construcción, gestión y enrutamiento de prompts complejos a LLMs
- Integración de herramientas: Permitir que los agentes llamen a APIs externas, bases de datos, funciones de código, etc.
- Memoria: Mantenimiento del estado entre turnos o sesiones (corto y largo plazo)
- Integración de RAG: Permitir la recuperación de conocimientos de fuentes externas
- Coordinación multi-agente: Estructurar cómo los agentes colaboran o delegan tareas
Frameworks de IA agéntica: Casos de uso de la vida real
LangGraph – Planificador de viajes multi-agente
Un proyecto de producción construido con LangGraph demuestra un asistente de viajes multi-agente con estado que extrae datos de vuelos y hoteles (utilizando Google Flights & Hotels APIs) y genera recomendaciones de viaje.4
CrewAI – Creador de contenido agéntico
El repositorio de ejemplos oficiales de CrewAI incluye flujos como planificación de viajes, estrategia de marketing, análisis de acciones y asistentes de reclutamiento, donde agentes específicos de rol (por ejemplo, “Investigador”, “Escritor”) colaboran en tareas.5
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 modelos>:
- La mayoría son agnósticos al modelo, soportando múltiples proveedores de LLM (por ejemplo, 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 suelen ser esenciales para obtener resultados óptimos.
Herramientas>:
- Todos los frameworks soportan el uso de herramientas, una parte central para habilitar las acciones del agente.
- Ofrecen abstracciones simples para definir herramientas personalizadas.
- La mayoría soporta el Model-Context-Protocol (MCP), ya sea de forma nativa o a través de extensiones de la comunidad.
Memoria / Estado>:
- Utilizan el seguimiento de estado para mantener la memoria a corto plazo entre pasos o llamadas al LLM.
- Algunos ayudan a los agentes a retener interacciones o contextos 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 que los agentes hagan referencia a conocimientos externos durante la ejecución.
Otras características comunes
- Soporte para ejecución asíncrona, permitiendo llamadas concurrentes de agentes o herramientas.
- Manejo integrado de salidas estructuradas (por ejemplo, JSON).
- Soporte para salidas en streaming donde el modelo genera resultados incrementalmente.
- Características básicas de observabilidad para el monitoreo y la depuración de las ejecuciones de los agentes.
Metodología del benchmark
1. Estructura de la Tarea
Tarea 1: Mide si se puede realizar una sola llamada a la herramienta con el parámetro correcto. La sobrecarga de la infraestructura base del framework se revela más claramente en este escenario simple.
Tarea 2: Requiere mantener los resultados de dos grupos de filtros separados en memoria y combinarlos en una sola salida. Se ponen a prueba la gestión de estados 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 herramientas 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 columnas JSON y LongText, y luego llamar a las herramientas correctas con los parámetros de alcance correctos. Se observa si el framework ejecuta herramientas independientes en paralelo o secuencialmente.
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, a cada agente se le dieron 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 de Deserción de Clientes de Telco de IBM (7,032 clientes). El estado de la herramienta se reinició antes de cada ejecución. Se realizaron 100 ejecuciones independientes para cada combinación de framework y tarea.
Los límites de iteración máxima 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.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{Los 5 mejores frameworks de IA agéntica de código abierto}},
year = {2026},
month = mar,
howpublished = {\url{https://aimultiple.com/agentic-frameworks}},
note = {AIMultiple. Recuperado el 30 de Marzo de 2026}
}Enlaces de referencia
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.
Thank you for this informative and detailed article! It helped me get a reading on these frameworks.