Los 5 mejores frameworks de IA agenica de código abierto en 2026
Realizamos pruebas comparativas de 4 marcos de trabajo de agentes de código abierto populares en 2000 ejecuciones (5 tareas, 100 ejecuciones por marco de trabajo), midiendo la latencia de extremo a extremo, el consumo de tokens y las diferencias arquitectónicas.
Punto de referencia de los marcos de IA agencial
Analizamos cómo los propios marcos de trabajo influyen en el comportamiento de los agentes 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.
En 5 tareas y 2000 ejecuciones, LangChain se destaca como el framework más eficiente en cuanto a tokens, mientras que AutoGen lidera en latencia; LangGraph y LangChain le siguen de cerca. CrewAI genera el perfil general más pesado.
Aquí puede consultar nuestra metodología en detalle.
Tarea 1: Agregación básica
En primer lugar, medimos la sobrecarga de cada marco de trabajo al simplemente llamar a una sola herramienta y devolver el resultado, sin realizar ningún razonamiento complejo.
LangChain y LangGraph: Para tareas sencillas, su rendimiento es casi tan rápido como el del código no agente, ya que ambos finalizan en menos de 5 segundos con menos de 900 tokens de solicitud. La arquitectura de máquina de estados de LangGraph no introduce una latencia perceptible en comparación con LangChain a este nivel de simplicidad; la sobrecarga de la gestión de estados solo 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, lo que refleja el coste base de su bucle de conversación multiagente, donde dos agentes intercambian mensajes incluso para una tarea de un solo paso.
CrewAI: Incluso al realizar una sola llamada a una herramienta, muestra lo que podría denominarse "sobrecarga administrativa", consumiendo casi el triple de tokens que LangChain y tardando casi el triple de tiempo. El proceso de verificación en múltiples pasos entre sus perfiles de Planificador y Analista ofrece un enfoque exhaustivo pero que consume muchos recursos, priorizando la exhaustividad sobre la velocidad. Este coste es estructural: se presenta independientemente de la complejidad de la tarea.
Tarea 2: Análisis comparativo de ingresos (gestión estatal)
En la Tarea 2, queríamos comprobar la capacidad de los frameworks para mantener en memoria dos grupos de filtros diferentes (persistencia de estado) y combinarlos.
CrewAI
En nuestro análisis de registros, descubrimos que CrewAI proporciona el mayor nivel de transparencia de infraestructura entre los marcos de trabajo, 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 auto-revisión. Este comportamiento exploratorio provocó que alcanzara el límite configurado de max_iter=10, dejando algunas ejecuciones atascadas en un bucle de procesamiento continuo sin generar una salida JSON.
La causa principal de este comportamiento es que CrewAI inyecta instrucciones complejas en el sistema, asignando a cada agente un rol, un objetivo y una historia de fondo, al tiempo que impone un ciclo de Pensamiento → Acción → Observación al estilo ReAct en cada paso. Incluso para tareas sencillas, el LLM no puede omitir este proceso y genera monólogos internos extensos, lo que se agrava aún más en escenarios con múltiples agentes.
CrewAI consumió casi el doble de tokens que los otros marcos de trabajo y tardó más del triple 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 estado es muy sencilla, la sobrecarga es prácticamente nula y la latencia es la más baja entre todos los frameworks.
Generación automática
Ofreció un rendimiento muy equilibrado. En la Tarea 2, coincidió casi exactamente con LangGraph tanto en el uso de tokens como en la 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 la herramienta, lo que la hace ligeramente más lenta que LangChain. Cuando encuentra un error en una llamada a la herramienta o los datos no se reciben como se esperaba, actualiza inmediatamente su razonamiento en el siguiente paso y llega al JSON correcto. Dado que gestiona las salidas de las herramientas como un flujo conversacional, es uno de los marcos de trabajo más resistentes a los errores lógicos.
LangGraph
En esta tarea, LangGraph se presenta como el framework más estable gracias a su arquitectura basada en grafos. En sus registros, observamos que el estado se conserva de forma impecable durante toda la ejecución. El riesgo de contaminación de datos o interferencia entre segmentos es mínimo en este framework. En las 100 ejecuciones, se obtuvieron resultados prácticamente idénticos en número de pasos y con una latencia similar.
Tarea 3: Análisis de umbrales (disciplina numérica)
En esta tarea, queríamos comprobar con qué precisión los marcos de trabajo traducen condiciones numéricas del lenguaje natural, como "menos de 1 año de antigüedad" y "más de 70 dólares en cargos mensuales", en parámetros de herramientas precisos como tenure_max=12 y charges_min=70.0.
El LLM ya sabe cómo realizar esta conversión; lo que realmente queríamos probar era si el marco puede proteger estos parámetros a lo largo de sus propios mecanismos de reintento, contexto de solicitud de confirmación y ciclos de gestión de estado.
LangChain y LangGraph
Ambos marcos de trabajo pasaron los parámetros (tenure_max=12, charges_min=70) directamente a la herramienta tal como los generó el LLM, sin ninguna modificación ni bucle de solicitud de parámetros. Esta eficiencia se refleja en los resultados: ambos marcos de trabajo completaron la Tarea 3 en menos de 9 segundos con menos de 1800 tokens de solicitud, el menor tiempo registrado en esta tarea.
Cuando quisimos medir si los umbrales numéricos se conservaban sin la interferencia del marco de trabajo, estos dos cumplieron nuestras expectativas: cualquier parámetro que se generara, ese era el que se ejecutaba.
Generación automática
Autogen es totalmente preciso numéricamente. En algunas ejecuciones, se observó que el framework añadía un paso de verificación antes de pasar el parámetro generado por LLM a la herramienta, lo que significa que el framework invertía un paso adicional al preservar el parámetro. Con 2480 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ó con nuestras expectativas en términos de integridad de parámetros, ya que el paso de confirmación introdujo solo un coste marginal en tokens en lugar de una penalización de latencia significativa.
CrewAI
El comportamiento más destacable se observó en CrewAI, que completó la Tarea 3 en 30 segundos con 4360 tokens, la mayor cantidad en esta tarea. Del análisis de los registros surgieron dos patrones de fallo distintos.
En algunas ejecuciones, un valor que debería haber sido 68,81 % se devolvió como 0,6878 (relación decimal). Esto indica que la serialización de salida del marco de trabajo puede extraer 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", el marco de trabajo obligó al LLM a reconsiderar. En el contexto de la solicitud de confirmación, el LLM cambió el umbral a tenure_max=14 y deshabilitó por completo el filtro charges_min, lo que produjo una tasa de abandono del 46,84 %, que en realidad es la tasa de abandono de todos los clientes con una antigüedad inferior a 14 años. Este era precisamente el escenario que queríamos observar: el mecanismo de reintento del marco de trabajo puede corromper un parámetro que el LLM ya había configurado correctamente.
Tarea 4: Resiliencia ante errores y capacidad de adaptación
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 genera tres tipos de errores diferentes de forma consecutiva (Red, Tiempo de espera agotado, Límite de velocidad), lo que obliga al agente a esperar. Los dos primeros errores le indican al agente que vuelva a intentarlo, y después de ambos, el error de Límite de velocidad le indica que espere 10 segundos. Una vez que el agente espera y vuelve a intentarlo, la herramienta comienza a funcionar con normalidad.
LangGraph y Autogen
Estos dos marcos de trabajo encontraron soluciones alternativas de forma autónoma cuando se enfrentaron a fallos en las herramientas para realizar esta tarea.
Cuando la herramienta mostró una advertencia de límite de solicitudes, en lugar de esperar, estos agentes decidieron abandonar por completo la herramienta defectuosa y buscar una alternativa. Su estrategia fue: «Dado que esta herramienta no funciona, filtraré cada método de pago individualmente, 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 sola llamada a una herramienta, la dividieron utilizando dos herramientas separadas, una para filtrar y otra para calcular, procesando cada método de pago (cheque electrónico, cheque por correo, etc.) individualmente.
Estos agentes operan con un razonamiento orientado a objetivos, en lugar de basarse en la dependencia de la 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ó los 15 010 tokens de solicitud en la Tarea 4, el mayor número de tokens en una sola tarea de toda la evaluación comparativa, debido a que su máquina de estados acumulaba el historial creciente de cada llamada manual a la herramienta en contexto en cada paso. AutoGen le siguió con 10 750 tokens, un resultado ligeramente más contenido debido a su manejo conversacional de los resultados intermedios. A pesar de esto, ambos finalizaron en alrededor de 24-27 segundos, lo que confirma 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 haber mostrado 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 token más bajo?
CrewAI no recurrió a un proceso manual de 10 a 15 pasos como sus competidores. Cuando encontraba errores, en lugar de volver a introducir repetidamente todo el historial y los datos intermedios complejos en el LLM en cada paso, construyó un bucle de razonamiento modular y más específico. Al evitar la verbosidad innecesaria, se convirtió en el marco de trabajo más rentable para esta tarea.
¿Por qué una latencia alta?
La estructura de gestión de CrewAI se detiene y reevalúa el plan cuando encuentra un error. Al recibir la advertencia de espera de 10 segundos, dedicó más tiempo a la fase de "planificación estratégica". Además, en lugar de cambiar a otra herramienta de filtrado, optó persistentemente por 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, demostrando por qué la resiliencia depende de una configuración adecuada.
En nuestra prueba inicial, LangChain falló en cada intento con un ConnectionError.
El AgentExecutor predeterminado de LangChain trata las excepciones de Python generadas desde dentro de una herramienta como errores fatales y finaliza el proceso. A diferencia de sus competidores, no aplica por defecto la filosofía de que "los errores son observaciones". 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 pudo procesar.
Comportamiento posterior a la corrección: Tras aplicar la corrección, observamos en los registros de LangChain que presentaba el mismo razonamiento que LangGraph. Recibió 3 errores de la herramienta, cambió inmediatamente de estrategia y optó por 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 la 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 del marco)
Si el comportamiento del agente dependiera únicamente del LLM (GPT-5.2), todos los marcos 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 marcos:
1. LangGraph y AutoGen (90% de pivote):
LangGraph opera con una arquitectura de máquina de estados, mientras que AutoGen funciona con un modelo basado en conversaciones. En ambos sistemas, los errores se procesan mediante 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 retroalimentación constante obliga al agente a seguir buscando una solución. Dado que el agente se enfrenta repetidamente a la pregunta "¿He recibido un error, qué debo hacer?", la probabilidad de que decida tomar una ruta manual alternativa aumenta al 90 %.
2. LangChain (65% Pivote / 35% Espera):
LangChain se basa en una arquitectura secuencial de Agente-Ejecutor. Incluso con manejo de errores, su bucle de ejecución tiene una estructura más lineal y se centra principalmente en generar una Respuesta Final. Si la herramienta genera errores durante 3 o 4 pasos, LangChain a veces prefiere esperar a que la herramienta tenga éxito en el siguiente intento o genere un resultado a partir del contexto existente, en lugar de recurrir a una estrategia alternativa. Debido a que el bloqueo de estado de LangChain es más flexible que el de LangGraph, su relación entre espera y solución directa ronda el 35 %.
3. CrewAI (0% Pivote):
CrewAI opera con una arquitectura de proceso gerencial. Sus agentes están definidos mediante roles y tareas. Cuando se producen errores, su arquitectura interna suele activar la autocorrección o la lógica de reintento. Sin embargo, un cambio radical de estrategia, como «descartemos todo el plan y realicemos un filtrado manual en 5 pasos», entra en conflicto con la estructura de planificación gerencial de CrewAI. Esta opera con la disciplina de «debo corregir la herramienta que me dieron o usar la alternativa más cercana», en lugar de abandonar su plan por completo. Se trata, fundamentalmente, de un enfoque centrado en el plan, en contraposición a uno centrado en los 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 al encontrar columnas JSON y de texto largo (LongText) dentro de un archivo 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 bloques JSON, párrafos de texto libre u objetos anidados.
Para que un marco de trabajo maneje correctamente este tipo de datos, necesita hacer dos cosas bien:
1- Una inteligencia de descubrimiento que comprende qué herramienta se ajusta a cada tipo de datos.
2- un mecanismo de orquestación que coordina múltiples llamadas a herramientas independientes.
Diseñamos la Tarea 5 específicamente para medir estas dos capacidades por separado.
Generación automática
AutoGen ofreció un rendimiento excelente en esta tarea, finalizando con 8.170 tokens de solicitud y una latencia media de 47 segundos, el resultado más rápido y eficiente en cuanto a tokens en la Tarea 5.
El bucle de conversación que constituye el núcleo de su arquitectura, la comunicación entre AssistantAgent y UserProxyAgent, suele considerarse una estructura que genera verborrea. Sin embargo, en la Tarea 5, esta estructura se convirtió en una ventaja.
Al analizar el historial de la conversación, LLM reconoció que las columnas Metadata y SupportNotes eran independientes entre sí. A continuación, envió una única respuesta TOOL CALLS que enumeraba cuatro herramientas simultáneamente: inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…) y summarize_text_column(…), todas ejecutándose en paralelo. Esto le permitió completar la tarea en tan solo tres turnos de LLM, con el menor número de tokens y pasos.
La razón técnica de este comportamiento es clara: el motor de ejecución de herramientas de AutoGen procesa la lista tool_calls devuelta por LLM de forma atómica y recopila los resultados en un único paso de conversación. La filosofía del framework de "gestionar la conversación" permite, naturalmente, que se abran varios canales paralelos al mismo tiempo, y las cifras de tokens y latencia lo confirman directamente.
LangGraph
LangGraph finalizó con 9.150 tokens de solicitud 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 nodo llm → nodo 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 olvide nada, lo cual suele ser 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 que el análisis se completó, detectó ambigüedades en el estado acumulado, interpretando pasos ya completados como pendientes, y activó repetidamente llamadas adicionales a las herramientas. 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 activó y el agente entró en bucles innecesarios. Como resultado, el número de llamadas a las herramientas por ejecución osciló entre 6 y 16. La capacidad 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 aumentando 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 presentó la mayor variabilidad en toda la prueba comparativa. En algunas ejecuciones, siguió una secuencia impecable con solo 5 llamadas a herramientas, sin desvíos, ejecutándose como un guion. En estas ejecuciones, la estructura de gestión definida por roles y tareas de CrewAI funcionó exactamente como se esperaba: cuando el agente comprendía claramente su función, se comportaba de forma predecible y con disciplina.
Sin embargo, en otras ejecuciones (por ejemplo, ejecución 16: 35 llamadas a herramientas), se desató el caos total. La causa principal fue el monólogo interno (Pensamiento) que CrewAI genera en cada paso. Tras construir correctamente el segmento con el filtro adecuado, el monólogo interno del agente comenzó a cuestionar si debían aplicarse filtros adicionales. Al ver el resultado, dudó de la validez del segmento actual o si debía prevalecer el anterior. Esta duda lo impulsó a recargar los datos desde cero. Luego, volvió a filtrar, 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 a veces invalidan pasos previamente verificados. El reflejo de "verificación continua" del Proceso de Gestión, en algunas ejecuciones, llevó al agente a cuestionar nuevamente sus propias decisiones correctas.
LangChain
La estructura AgentExecutor de LangChain es inherentemente secuencial, y esta limitación se hizo más evidente en la Tarea 5. Con 10 070 tokens de solicitud y una mediana de 86 segundos, fue el framework más lento en esta tarea, a pesar de no tener el mayor número de tokens.
En cada paso, realiza una única llamada a la herramienta, recibe el resultado y continúa, lo que significa que cuatro herramientas independientes requieren cuatro ciclos de LLM distintos con cuatro periodos de espera separados. La mediana de 47 segundos de AutoGen frente a los 86 segundos de LangChain es una medida directa del coste de la ejecución secuencial frente a la paralela.
En la Tarea 5, el número de herramientas de LangChain se estabilizó generalmente 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 resumen (9 herramientas), mientras que en otras inspeccionó cada columna antes de procesarla (15 herramientas). Aquí quedó clara la naturaleza lineal del ejecutor de LangChain: no mostró ni la eficiencia paralela de AutoGen ni el caos monólogo de CrewAI.
Gestión de datos no estructurados y arquitectura del marco de trabajo
Los resultados de esta tarea revelan que la eficiencia con la que un marco de trabajo 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 reales que involucran objetos JSON grandes y numerosas columnas de texto, esta diferencia se traduce en una enorme ventaja en términos de costo y velocidad.
Los marcos de trabajo con bucles controlados por estado (LangGraph) destacan por su consistencia de datos, pero conllevan el riesgo de reevaluar pasos ya completados acumulados en el historial.
Los sistemas basados en monólogos (CrewAI) tienen una gran capacidad para comprender el tipo y el significado de los datos, pero esta profundidad a veces se traduce en un exceso de preguntas y bucles.
Los marcos de ejecución lineal (LangChain) procesan diferentes ramas de datos no estructurados por separado, produciendo un resultado intermedio entre ambos mundos.
Crecimiento estelar de GitHub de los frameworks basados en agentes
Comparar marcos de IA basados en agentes
Los marcos de IA agente varían en varias dimensiones clave, y comprender estas diferencias es esencial para realizar comparaciones significativas.
Orquestación multiagente
La orquestación multiagente coordina varios agentes de IA especializados para abordar flujos de trabajo complejos que superan las capacidades de un solo agente. En lugar de crear un agente monolítico, la orquestación distribuye el trabajo entre agentes con roles, herramientas y conocimientos especializados distintos. Cada marco de trabajo 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 crean sistemas de agentes.
Coordinación explícita entre múltiples agentes: Se pueden modelar varios agentes como nodos individuales o grupos, cada uno con su propia lógica, memoria y función en el sistema.
Crea flujos de trabajo de IA a través de API y herramientas. Por lo tanto, es ideal para RAG y pipelines personalizados.
Generación automática
AutoGen permite que varios agentes se comuniquen mediante el intercambio de mensajes en un bucle. Cada agente puede responder, reflejar o llamar a herramientas según su lógica interna.
Cuenta con una colaboración asíncrona entre agentes, lo que la hace particularmente útil para escenarios de investigación y creación de prototipos donde el comportamiento de los agentes requiere experimentación o refinamiento iterativo.
CrewAI
CrewAI se encarga de la mayor parte de la lógica de bajo nivel y proporciona orquestación multiagente:
- Se integra con herramientas de monitorización para el rastreo y la depuración.
- Control de ejecución integrado mediante flujos con lógica condicional, bucles y gestión de estado.
- Admite la coordinación jerárquica (gerente-trabajador) y estructurada de múltiples agentes.
OpenAI Enjambre
Swarm es un marco multiagente experimental y ligero para la creación de prototipos. Los agentes trabajan secuencialmente mediante traspasos, transfiriendo tareas y manteniendo un contexto compartido. Utiliza rutinas de lenguaje natural y herramientas de Python para flujos de trabajo flexibles.
LangChain
LangChain es un marco de trabajo para crear aplicaciones LLM de agente único con herramientas RAG. Proporciona componentes modulares que incluyen cadenas, herramientas, memoria y recuperación para flujos de trabajo de procesamiento de documentos.
LangChain funciona principalmente mediante patrones de ejecución de agente único, donde un solo 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 se conectan mediante un grafo dirigido, lo que permite la lógica condicional, la coordinación entre múltiples equipos y el control jerárquico. Esto posibilita la creación y visualización de grafos multiagente con nodos supervisores para una orquestación escalable.
LangGraph utiliza funciones estructuradas y anotadas que conectan herramientas con agentes. Puedes crear nodos, conectarlos a distintos supervisores y visualizar cómo interactúan los diferentes equipos. Imagina que le das a cada miembro del equipo una descripción detallada de su trabajo. Esto facilita la creación y prueba de agentes que trabajan juntos.
Generación automática
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 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 Enjambre
OpenAI Swarm utiliza un modelo basado en rutinas donde los agentes se definen mediante indicaciones y cadenas de documentación de funciones. No cuenta con modelos formales de orquestación o estado, sino que se basa en flujos de trabajo estructurados manualmente. El comportamiento de las funciones se infiere mediante el LLM a través de las cadenas de documentación (Swarm identifica la 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 a diversas herramientas. Define las funciones mediante interfaces explícitas, como kits de herramientas y plantillas de indicaciones.
Si bien LangChain se centra principalmente en flujos de trabajo centralizados, admite extensiones para configuraciones multiagente, pero carece de comunicación integrada entre agentes.
Memoria
Capacidades de memoria :
- Con estado : Indica si el marco de trabajo admite memoria persistente entre ejecuciones.
- Contextual : Si admite memoria a corto plazo mediante historial de mensajes o paso de contexto.
Las funciones de memoria son una parte clave para construir sistemas con capacidad de recordar el contexto y adaptarse con el tiempo:
- Memoria a corto plazo : Mantiene un registro de las interacciones recientes, lo que permite a los agentes gestionar 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 entidades : Registra y actualiza el conocimiento sobre objetos, personas o conceptos específicos mencionados durante las interacciones (por ejemplo, recordar el nombre de una empresa o la identificación de un proyecto mencionados anteriormente).
LangGraph
LangGraph utiliza dos tipos de memoria: memoria interna , que almacena información durante una única tarea o conversación, y memoria externa , 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 admite herramientas como InMemoryStore u otras bases de datos. Esto proporciona un control flexible sobre cómo se gestiona y retiene la memoria entre ejecuciones.
Generación automática
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 interacciones. No tiene memoria persistente integrada.
CrewAI
CrewAI Proporciona memoria en capas de forma predeterminada. 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 las descripciones de las tareas). Además, admite memoria de entidades mediante incrustaciones vectoriales. Esta configuración de memoria se configura automáticamente cuando memory=True está habilitado.
OpenAI Enjambre
Swarm no tiene estado y no gestiona la memoria de forma nativa. Los desarrolladores pueden pasar la memoria a corto plazo manualmente a través de context_variables y, opcionalmente, integrar herramientas externas o capas de memoria de terceros (por ejemplo, mem0) para almacenar el contexto a largo plazo.
LangChain
LangChain admite memoria a corto y largo plazo mediante componentes flexibles. La memoria a corto plazo se gestiona normalmente mediante búferes en memoria que registran el historial de conversaciones dentro de una sesión. Para la memoria a largo plazo, LangChain se integra con almacenes de vectores o bases de datos externas para conservar las incrustaciones y los 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 cada entidad en todas las interacciones.
Intervención humana
LangGraph
LangGraph admite puntos de interrupción personalizados (interrupt_before) para pausar el gráfico y esperar la entrada del usuario durante la ejecución.
Generación automática
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 del agente.
TripulaciónAI :
CrewA I habilita la retroalimentación después de cada tarea configurando human_input=True; el agente hace una pausa para recopilar la entrada en lenguaje natural del usuario.
OpenAI Enjambre
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 la intervención humana. Esto facilita la revisión, la retroalimentación o la intervención manual en puntos definidos del flujo de trabajo.
Integración del Protocolo de Contexto de Modelo (MCP) en marcos de IA basados en agentes
Los agentes de IA necesitan interactuar con herramientas externas como bases de datos, API, sistemas de archivos y aplicaciones empresariales. Sin un estándar, cada plataforma debía crear integraciones personalizadas para cada herramienta, lo que generaba un ecosistema fragmentado. MCP resuelve este problema al proporcionar un protocolo universal que permite a cualquier agente conectarse a cualquier herramienta a través de una única interfaz.
Cómo se integra cada marco con MCP
LangGraph
LangGraph se conecta a los servidores MCP mediante un adaptador que detecta automáticamente las herramientas disponibles y las convierte a un formato compatible con LangChain. De esta forma, los agentes pueden utilizar estas herramientas sin problemas junto con sus funcionalidades nativas.
Generación automática
AutoGen ofrece integración MCP integrada mediante 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 tan solo unas pocas líneas de código.
CrewAI
Los agentes de CrewAI pueden hacer referencia directamente a los servidores MCP en su configuración mediante URL sencillas o ajustes estructurados. El sistema gestiona automáticamente el ciclo de vida de la conexión y la gestión de errores.
OpenAI Enjambre
Swarm se beneficia de la compatibilidad nativa con MCP de OpenAI 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 para llamar a herramientas MCP, donde las funciones de Python actúan como puentes hacia los servidores MCP. Esto permite obtener herramientas de diversas fuentes e integrarlas en cadenas, agentes y otros componentes de LangChain sin necesidad de adaptadores personalizados.
¿Qué hacen realmente los marcos de IA basados en agentes?
Los marcos de IA agente ayudan a diseñar indicaciones y a gestionar el flujo de datos hacia y desde los LLM . En un nivel básico, ayudan a estructurar las indicaciones para que el LLM responda de forma predecible y a dirigir las respuestas a la herramienta, API o documento adecuados.
Si se construye desde cero, se definiría manualmente el mensaje, se extraería la herramienta que el LLM desea utilizar y se activaría la llamada a la API correspondiente. Los frameworks simplifican este proceso mediante:
- Orquestación de indicaciones : Creación, gestión y enrutamiento de indicaciones complejas a LLM.
- Integración de herramientas : Permite a los agentes llamar a API externas, bases de datos, funciones de código, etc.
- Memoria : Mantener el estado a lo largo de turnos o sesiones (a corto y largo plazo).
- Integración RAG : Permite la recuperación de conocimiento de fuentes externas.
- Coordinación multiagente : Estructuración de cómo los agentes colaboran o delegan tareas.
Marcos de IA agente: casos de uso reales
LangGraph – Planificador de viajes para múltiples agentes
Un proyecto de producción creado con LangGraph demuestra un asistente de viajes multiagente con estado que extrae datos de vuelos y hoteles (utilizando las API de Vuelos y Hoteles Google) y genera recomendaciones de viaje. 4
CrewAI – Creador de contenido agencial
El repositorio oficial de ejemplos de CrewAI incluye flujos de trabajo 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", "Redactor") colaboran en tareas. 5
CrewAI convierte un brief de contenido de alto nivel en un artículo completo utilizando Groq.
Características principales de los marcos de IA basados en agentes
Soporte del modelo :
- La mayoría son independientes del modelo y admiten múltiples proveedores de LLM (por ejemplo, OpenAI, Anthropic, modelos de código abierto).
- Sin embargo, las estructuras de las indicaciones del sistema varían según el marco de trabajo y pueden funcionar mejor con algunos modelos que con otros.
- El acceso a las indicaciones del sistema y su personalización suelen ser esenciales para obtener resultados óptimos.
Herramientas :
- Todos los marcos de trabajo admiten el uso de herramientas , una parte fundamental para habilitar las acciones de los agentes.
- Ofrecer abstracciones sencillas para definir herramientas personalizadas.
- La mayoría admite el protocolo Modelo-Contexto-Protocolo (MCP) , ya sea de forma nativa o mediante extensiones de la comunidad.
Memoria / Estado :
- Utilice el seguimiento de estado para mantener la memoria a corto plazo entre pasos o llamadas a LLM.
- Algunas funciones ayudan a los agentes a conservar las interacciones o el contexto previos dentro de una sesión.
RAG (Generación aumentada por recuperación) :
- La mayoría incluye opciones de configuración sencillas para RAG , que integran bases de datos vectoriales o almacenes de documentos.
- Esto permite a los agentes consultar conocimientos externos durante la ejecución.
Otras características comunes
- Compatibilidad con la ejecución asíncrona , lo que permite realizar llamadas simultáneas a agentes o herramientas.
- Manejo integrado para salidas estructuradas (por ejemplo, JSON).
- Compatibilidad con la transmisión de resultados en tiempo real , donde el modelo genera resultados de forma incremental.
- Funcionalidades básicas de observabilidad para la monitorización y depuración de ejecuciones de agentes.
Metodología de evaluación comparativa
1. Estructura de la tarea
Tarea 1: Mide si se puede realizar una única llamada a una herramienta con el parámetro correcto. La sobrecarga de la infraestructura básica del framework se evidencia con mayor claridad en este sencillo escenario.
Tarea 2: Requiere almacenar en memoria los resultados de dos grupos de filtros independientes y combinarlos en una única salida. Se evalúan la gestión de estados y la coordinación multisegmento.
Tarea 3: Mide si las condiciones numéricas en lenguaje natural se traducen en parámetros de la herramienta sin distorsión. La verdadera prueba consiste en comprobar si los mecanismos de reintento y solicitud de parámetros del sistema pueden preservar dichos parámetros.
Tarea 4: Una herramienta genera errores de red, tiempo de espera y límite de velocidad de forma consecutiva. Se evalúa si el sistema cambia de estrategia ante estos errores.
Tarea 5: El agente debe primero descubrir las columnas JSON y LongText, y luego llamar a las herramientas correctas con los parámetros de alcance adecuados. Se observa si el marco ejecuta las herramientas de forma independiente en paralelo o secuencial.
2. Configuración
Todos los frameworks utilizaron el mismo modelo LLM (openai/gpt-5.2) y el mismo valor de temperatura (0.1). Para todas las tareas, cada agente recibió las mismas herramientas y las mismas indicaciones. Cada framework se configuró con 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 (7032 clientes). El estado de la herramienta se restableció antes de cada ejecución. Se realizaron 100 ejecuciones independientes para cada combinación de marco 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 inestable de la herramienta; y 20 para la tarea 5 debido a la cadena de descubrimiento de 4 pasos.
Enlaces de referencia
Siguiente para leer
Evaluación comparativa de marcos multiagente: desafíos y fortalezas
Búsqueda basada en agentes en 2026: Evaluación comparativa de 8 API de búsqueda para agentes
El panorama de la evaluación de los másteres en Derecho (LLM) con sus respectivos marcos de referencia.
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios.