Evaluación comparativa de marcos multiagente: desafíos y fortalezas
Los sistemas multiagente emplean agentes especializados que trabajan conjuntamente para resolver tareas complejas. Un desafío clave es: ¿disminuye el rendimiento a medida que se añaden más agentes y herramientas, o pueden los mecanismos de orquestación gestionar la creciente complejidad de forma eficiente?
Realizamos pruebas comparativas de 5 marcos de trabajo basados en agentes en 750 ejecuciones con tres tareas. Medimos la latencia, el consumo de tokens y la sobrecarga de orquestación para identificar qué patrones arquitectónicos mantienen la eficiencia a gran escala y cuáles se degradan.
Referencia de marco multiagente
Analizamos cómo el uso de tokens y la latencia aumentan con el número de agentes y herramientas. En tres tareas con el mismo problema, incrementamos progresivamente la cantidad de agentes y la disponibilidad de herramientas. Para LangChain y LangGraph, utilizamos configuraciones de un solo agente para observar cómo sus arquitecturas secuenciales manejan la misma complejidad que enfrentan los sistemas multiagente.
No incluimos en el gráfico el marco con una precisión inferior al 95 % (Swarm). Puede consultar nuestra metodología de evaluación comparativa.
En particular para Swarm, observamos que la precisión variaba a la par de esta complejidad, debido a diferencias arquitectónicas más que a las capacidades del modelo.
La precisión en los marcos de trabajo basados en agentes generalmente se puede mejorar mediante la selección de modelos de lógica descriptiva o el ajuste de la configuración. Sin embargo, el análisis de las causas arquitectónicas de las variaciones de precisión en nuestro conjunto de datos de referencia reveló información valiosa. Esto nos ayudó a comprender las diferencias fundamentales de diseño entre los marcos de trabajo.
Resultados de referencia del marco multiagente
CrewAI obliga a todos los agentes a ejecutarse secuencialmente, lo que provoca un crecimiento exponencial de los tokens a medida que la salida de cada agente se acumula en el contexto del siguiente. Esta rigidez garantiza la exhaustividad, pero genera una sobrecarga considerable.
El algoritmo Swarm prioriza la velocidad mediante el enrutamiento sin estado, pero sufre una disminución progresiva de la precisión (del 84 % al 0 %) a medida que aumenta la complejidad de la tarea. Sin un seguimiento global del estado, los agentes finalizan prematuramente, interrumpiendo las cadenas de varios pasos.
LangChain utiliza un agente único, un "superagente", con contexto unificado, evitando por completo la sobrecarga de coordinación. El rendimiento se mantiene eficiente hasta que el tamaño de la biblioteca de herramientas (100 herramientas) y la complejidad del razonamiento aumentan significativamente la latencia.
LangGraph iguala la fiabilidad de LangChain, pero añade la sobrecarga del recorrido del grafo. El coste de la gestión del estado se hace evidente en entornos de alta complejidad, aunque mantiene una alta precisión.
AutoGen genera un alto número de traspasos mediante la coordinación basada en chat, pero utiliza GroupChatManager para eliminar dinámicamente los agentes innecesarios. Esto evita el crecimiento exponencial de CrewAI a la vez que mantiene una alta precisión, aunque el consumo de tokens sigue siendo superior al de los sistemas de un solo agente debido al reprocesamiento del historial de conversaciones.
CrewAI
La arquitectura secuencial basada en roles de CrewAI ejecuta a cada agente asignado sin descartar agentes irrelevantes durante todo el proceso. Esta característica arquitectónica tiene implicaciones significativas para los sistemas basados en agentes, donde cada agente desempeña una función crítica. Garantiza que el sistema no omita ningún paso previsto y que continúe utilizando a todos los agentes en lugar de tomar decisiones de enrutamiento autónomas. Sin embargo, esta rigidez conlleva un alto costo en términos de consumo de recursos y latencia a medida que aumenta la complejidad de las tareas.
Crecimiento exponencial de los recursos en todas las tareas
Desde la Tarea 1 hasta la Tarea 3, observamos un aumento continuo en el consumo de tokens y la latencia. La latencia se duplicó aproximadamente con cada incremento de tarea, mientras que el consumo de tokens creció a un ritmo aún más drástico. El número de traspasos de agentes aumentó de forma natural en paralelo con este aumento.
¿Por qué CrewAI consume más tokens y tiempo?
El flujo de trabajo secuencial de CrewAI se alineó de forma natural con ambos flujos de trabajo. En la Tarea 1, el Analista de Datos recopiló información antes de que el Árbitro tomara decisiones. En la Tarea 2, este patrón continuó con roles de agente ampliados. CrewAI seleccionó todas las herramientas correctamente y demostró que la ejecución secuencial elimina la confusión en la coordinación, ya que cada agente ejecutó las herramientas designadas sin ambigüedad en el enrutamiento.
Sin embargo, esta alineación natural conllevó gastos generales sustanciales y crecientes:
El mecanismo de acumulación de estados:
- Cada agente genera un informe detallado al completar su tarea.
- Este informe se pasa al siguiente agente en la secuencia.
- Para cuando el árbitro final recibe la información, lee un documento que contiene el historial y los resultados de todos los agentes anteriores, además de sus propias instrucciones del sistema y metadatos de la herramienta.
- El LLM dedica una cantidad significativa de tiempo a leer y regenerar objetos de estado Markdown de gran tamaño entre tareas.
Esta gestión de estado detallada envolvía incluso los datos más pequeños en metadatos de orquestación sustanciales. CrewAI prioriza el conocimiento total del contexto sobre la eficiencia.
Rigidez de la tarea 2-3:
- El marco ejecutó los 5 agentes en la secuencia predefinida, incluso cuando solo un subconjunto era estrictamente necesario.
- Esta rigidez incrementó tanto los costos de los tokens como la latencia, al tiempo que mantenía una alta precisión.
- La incapacidad del marco para omitir agentes innecesarios se hizo cada vez más evidente como una limitación arquitectónica fundamental.
- Cada agente adicional complicó el contexto que los agentes subsiguientes deben procesar.
Enjambre
El mecanismo de enrutamiento ligero de Swarm demostró una auténtica delegación multiagente con una mínima sobrecarga de orquestación. Un agente inicial recogía el contexto necesario, reconocía activamente cuándo había terminado su tarea y transfería explícitamente la sesión a un agente de toma de decisiones distinto. Esta arquitectura sin estado priorizaba la velocidad y la simplicidad, logrando un rendimiento comparable al de los sistemas de un solo agente en escenarios sencillos. Sin embargo, a medida que aumentaba la complejidad de la tarea, este enfoque ligero reveló limitaciones fundamentales de escalabilidad, donde la ausencia de seguimiento del estado global y de orquestación centralizada provocaba un deterioro progresivo de la precisión.
Degradación progresiva de la precisión en todas las tareas
Desde la Tarea 1 hasta la Tarea 3, observamos un drástico descenso en la precisión a pesar de mantener velocidades de ejecución rápidas. La precisión cayó del 84 % en la Tarea 1 al 22 % en la Tarea 2, llegando finalmente al 0 % en la Tarea 3. Esta degradación progresiva reveló que la arquitectura sin estado de Swarm, optimizada para la velocidad en interacciones breves e intensas, es fundamentalmente inviable para cadenas de razonamiento de múltiples pasos.
¿Por qué disminuye la precisión a medida que aumentamos la complejidad?
El enrutamiento ligero de Swarm mantuvo los tokens de finalización extremadamente bajos y la latencia rápida en todas las tareas. El marco funcionaba como una carrera de relevos de agentes independientes sin estado global, donde cada agente tomaba decisiones de transferencia autónomas sin supervisión central. Este enfoque destaca por minimizar el consumo de tokens y lograr una ejecución rápida, pero conlleva un alto costo en confiabilidad y precisión a medida que aumentan los requisitos de persistencia operativa.
El punto ciego arquitectónico:
Un análisis posterior de los registros reveló un punto ciego arquitectónico que no pudo resolverse únicamente mediante una ingeniería rápida. Inicialmente, se identificó y corrigió un error en las instrucciones de transferencia (faltaban instrucciones de transferencia). Sin embargo, incluso con comandos de transferencia explícitos, Swarm no logró completar la cadena.
Debido a que el marco no tiene estado y carece de seguimiento global de intenciones, el primer agente receptor (por ejemplo, Finanzas) simplemente emitiría una confirmación conversacional (por ejemplo, «Datos recibidos, iniciando auditoría financiera») y finalizaría el hilo. Swarm interpreta cualquier finalización de turno conversacional como la finalización de la tarea, lo que conduce a los resultados más rápidos pero menos efectivos. Sin un orquestador central que mantenga el estado de la tarea y garantice la ejecución de todos los pasos, el marco no puede distinguir entre «el agente ha confirmado» y «la tarea está completamente finalizada». Esta limitación fundamental implica que incluso una delegación multiagente genuina con traspasos explícitos no puede garantizar la finalización de la tarea cuando la cadena se extiende más allá de interacciones simples.
Tarea 1-2: Problemas de precisión crecientes
En la Tarea 1, donde Swarm demostró un rendimiento sólido con cadenas de agentes cortas, el sistema falló en el 16 % de las ejecuciones debido a una resolución de transferencia incompleta. Al analizar los registros de conversación, descubrimos que el Árbitro tomó decisiones correctamente, pero el mecanismo de salida de Swarm mostró el mensaje de transferencia intermedio del Analista de Datos. Los usuarios recibieron el mensaje "Ahora transferiré esta información al Árbitro" en lugar de la decisión final, lo que revela que los sistemas de enrutamiento dinámico corren el riesgo de perder los resultados finales durante las transiciones entre agentes.
En la Tarea 2, con 5 opciones de agentes y 20 herramientas disponibles, la precisión se degradó significativamente a medida que la estrategia de indicaciones del marco, ligera y con poco contexto, comenzó a ceder ante la creciente complejidad:
- La tasa de elección correcta de la herramienta se redujo al 40%, lo que representa una disminución del 20% con respecto a la Tarea 1.
- En ocasiones, los agentes llamaban a herramientas irrelevantes o emitían mensajes de enrutamiento cuando se esperaban llamadas a herramientas reales.
- En ocasiones, los agentes intentaron usar herramientas del dominio incorrecto o volvieron a intentar realizar llamadas fallidas.
- Sin un controlador central, los agentes perdían el rastro del estado de ejecución o se transferían a roles que parecían concluyentes pero que no habían ejecutado las llamadas a herramientas necesarias.
Tarea 3: La paradoja del traspaso
La tarea 3 puso al descubierto la limitación arquitectónica fundamental de Swarm, con una precisión del 0% a pesar de mantener la máxima velocidad de ejecución. Este fallo total reveló lo que denominamos la «Paradoja de la Transferencia»: en una cadena de 10 agentes, Swarm requiere transferencias basadas en herramientas al 100% en cada enlace, pero sin un orquestador central o un grafo de estado (como LangGraph), la cadena se rompe en el primer enlace. Si bien Swarm destaca en las transferencias uno a uno, colapsa en flujos de trabajo de varios pasos que requieren persistencia operativa a lo largo de cadenas extensas.
Agotamiento de la cadena de traspaso:
En la Tarea 1, con una sola transferencia, la cadena era lo suficientemente corta como para que el objetivo se mantuviera en contexto. Sin embargo, a medida que la cadena se extendió a nueve transferencias en la Tarea 3, la probabilidad acumulada de éxito se redujo a cero. Cada especialista adicional actuaba como un punto de fuga donde una respuesta conversacional podía interrumpir el proceso antes de llegar al árbitro final. Esta tasa de fallo geométrica demuestra que el enrutamiento sin estado, si bien está optimizado para la velocidad, no puede escalar a procesos de razonamiento de varios pasos.
LangChain
LangChain ejecutaba las tareas como una máquina de estados simple: recibía la solicitud, evaluaba las herramientas, ejecutaba y finalizaba. Configuramos LangChain como un ejecutor de un solo agente, sin traspasos y con un único agente para todas las tareas. Este enfoque de contexto unificado mantenía una única entidad lógica durante toda la ejecución, sin saltos conversacionales y ejecutando exactamente lo que cada tarea requería, sin la sobrecarga de la orquestación. El modelo de ejecución lineal del marco demostró que las tareas que no requieren colaboración entre agentes se benefician significativamente al evitar los costos de coordinación inherentes a los sistemas multiagente.
Escalado eficiente hasta el umbral de entropía de la herramienta
LangChain mantuvo resultados correctos en las tres tareas. Sin embargo, la tarea 3 reveló la sensibilidad del sistema al tamaño de la biblioteca de herramientas y a la complejidad del razonamiento, observándose un aumento notable de la latencia a medida que se ampliaban ambas dimensiones.
Por qué LangChain siguió siendo eficiente
Tarea 1-2: Ventaja de ejecución lineal
En la Tarea 1, LangChain logró una latencia mínima y optimizó el uso de tokens con una selección precisa de herramientas. El sistema evitó distracciones con mecanismos de coordinación, procesando únicamente lo necesario para completar la tarea. La arquitectura de agente único eliminó la sobrecarga de comunicación entre agentes, la generación de informes entre pasos y el relleno conversacional.
En la Tarea 2, implementamos LangChain utilizando una arquitectura de "superagente" donde un único controlador tenía acceso directo a las 20 herramientas. Al consolidar los roles en una sola entidad lógica, el marco evitó la necesidad de intercambio de datos entre agentes, generación de informes y relleno de conversaciones. Este modelo de ejecución lineal garantizó que el LLM solo procesara los resultados relevantes de las herramientas, evitando el crecimiento exponencial del historial de solicitudes que se observa en los marcos multiagente.
La arquitectura de contexto unificada garantizó que la presencia de 20 herramientas en la biblioteca no generara confusión en la selección. El agente único procesó las llamadas a las herramientas de forma secuencial, sin necesidad de coordinarse ni negociar con otros agentes, manteniendo la selección correcta de herramientas a pesar de la ampliación de la biblioteca. La ausencia de traspasos confirmó que no se introdujo ninguna sobrecarga de orquestación a medida que aumentaba la complejidad.
Entropía de las herramientas y complejidad del razonamiento
La tarea 3 introdujo dos desafíos importantes que afectaron el rendimiento de LangChain:
Entropía de la herramienta:
Mientras que la Tarea 1 tenía 5 herramientas y la Tarea 2 tenía 20 herramientas, la Tarea 3 presentaba 100 herramientas disponibles. Dado que LangChain funciona como un sistema de agente único, cada mensaje debe incluir las definiciones de las 100 herramientas en la solicitud. Esto crea dos cuellos de botella:
- El LLM debe evaluar 100 opciones para seleccionar la herramienta correcta, lo que aumenta el tiempo de procesamiento.
- El enorme tamaño de la solicitud (que contiene todas las definiciones de herramientas) retrasa el tiempo del modelo hasta el primer token, lo que aumenta la latencia general.
Complejidad del razonamiento (10 roles de experto):
En las tareas 1 y 2, el agente simplemente actuó como árbitro tomando una decisión. En la tarea 3, se le indicó al agente que analizara secuencialmente 10 perspectivas de expertos.
Esta instrucción provocó que el modelo generara resultados significativamente más largos, con un aumento sustancial en la cantidad de tokens de finalización en comparación con la Tarea 2. Una mayor cantidad de texto generado se traduce directamente en un mayor tiempo de ejecución, ya que el modelo debe producir cada token de forma secuencial.
A pesar de estos desafíos, LangChain mantuvo resultados correctos y nunca seleccionó herramientas erróneas. La sencilla estructura de bucle del framework (AgentExecutor) procesó las llamadas y respuestas de las herramientas sin sobrecarga arquitectónica adicional, manteniendo los aumentos de latencia proporcionales a la complejidad inherente de la tarea en lugar de agravarlos con mecanismos de orquestación.
El enfoque arquitectónico de LangChain demostró que la ejecución de contexto unificado puede mantener la fiabilidad a medida que aumenta la complejidad, aunque el rendimiento se vuelve sensible al tamaño de la biblioteca de herramientas y a la profundidad del razonamiento. La capacidad del marco para producir resultados correctos en todas las tareas, evitando la explosión de tokens y la sobrecarga de coordinación de los sistemas multiagente, demostró el valor de los modelos de ejecución lineal para tareas que no requieren la colaboración de agentes.
LangGraph
Como se observó en nuestra evaluación comparativa de marcos de trabajo basados en agentes, LangGraph empleó una arquitectura de máquina de estados con transiciones de estado explícitas y flujo de control basado en grafos. Configuramos LangGraph como un ejecutor de agente único, sin traspasos y con un único agente para todas las tareas. Este enfoque eliminó por completo la comunicación entre agentes, a la vez que proporcionó una gestión de estado estructurada que registraba el progreso de la ejecución mediante nodos y aristas definidos. El marco de trabajo demostró que el seguimiento formal del estado puede coexistir con la ejecución de contexto unificado.
Fiabilidad constante con sobrecarga de gestión de gráficos
LangGraph generó resultados correctos en las tres tareas sin errores. En las tareas 1 y 2, el rendimiento fue prácticamente idéntico al del modelo de ejecución lineal de LangChain. Sin embargo, la tarea 3 mostró un aumento de latencia más pronunciado en comparación con LangChain, lo que evidencia el coste computacional de la gestión de estados basada en grafos bajo una alta entropía de la herramienta y una elevada complejidad de razonamiento.
Por qué LangGraph coincidió con LangChain
El grafo de estados de LangGraph proporcionó un flujo de control formal sin necesidad de múltiples agentes. En ambas tareas, el marco de trabajo mantuvo cero traspasos de información al seleccionar todas las herramientas correctamente. El controlador único accedió directamente a todas las herramientas necesarias, procesando cada paso mediante transiciones de estado en lugar de traspasos de información entre agentes.
La implementación del "superagente" garantizó que el sistema nunca dividiera la carga cognitiva entre múltiples perfiles. La selección de herramientas se mantuvo precisa incluso con 20 herramientas disponibles en la Tarea 2, y el agente nunca seleccionó herramientas incorrectas o irrelevantes. El contexto unificado evitó la confusión en la selección que afectaba a los sistemas que dependían de la coordinación entre agentes.
Por qué el consumo de tokens coincidió con LangChain
Ambos marcos de trabajo utilizaron la misma configuración LLM, definiciones de herramientas e indicaciones del sistema. A diferencia de los marcos de trabajo multiagente (AutoGen, CrewAI), que generan sobrecarga de coordinación mediante conversaciones entre agentes y mensajes de coordinación intermedios, ambos marcos de trabajo de un solo agente consolidan toda la experiencia en una sola llamada al modelo. Cada token gastado representa las instrucciones de entrada o la salida directa, sin sobrecarga intermedia del tipo "El agente A habló con el agente B". Además, ambos marcos de trabajo invocan las mismas herramientas en la misma secuencia para resolver la tarea, recibiendo datos idénticos del sistema subyacente, lo que resulta en recuentos de tokens de finalización muy similares. Las diferencias de tokens entre los marcos de trabajo fueron insignificantes porque el LLM realizó el mismo trabajo de razonamiento en ambos casos.
Tarea 3: Amplificación de la sobrecarga del recorrido del grafo
La tarea 3 presentó los mismos desafíos a los que se enfrentó LangChain (100 herramientas y una complejidad de razonamiento de 10 roles), pero la arquitectura basada en grafos de LangGraph amplificó el impacto en el rendimiento:
Carga de entropía de la herramienta:
Al igual que LangChain, LangGraph debe incluir las 100 definiciones de herramientas en cada solicitud debido a su arquitectura de agente único. El LLM debe evaluar la biblioteca completa de herramientas para cada selección, y el gran tamaño de la solicitud retrasa la generación de respuestas.
Complejidad del razonamiento:
La instrucción de razonar a través de 10 perspectivas de expertos de forma secuencial provocó que LangGraph generara resultados significativamente más largos, al igual que sucedió con LangChain. Sin embargo, la sobrecarga adicional de LangGraph se hizo evidente aquí.
Sobrecarga de gestión de gráficos:
Mientras que LangChain utiliza una estructura de bucle simple (AgentExecutor) que llama a herramientas y procesa respuestas, LangGraph recorre una estructura de grafo completa en cada paso. Para cada llamada a una herramienta:
- El marco debe recorrer el grafo completo de principio a fin.
- El historial de mensajes (estado) se actualiza en cada transición de nodo.
- El sistema valida las transiciones entre nodos y mantiene la coherencia del estado.
En las tareas 1 y 2, esta sobrecarga fue insignificante. En la tarea 3, con 100 herramientas y requisitos de razonamiento complejos, la gestión del grafo se volvió sustancial. La latencia adicional en comparación con LangChain reflejó directamente el costo de mantener y recorrer la estructura del grafo de estado bajo alta complejidad.
A pesar de esta sobrecarga, LangGraph nunca seleccionó herramientas incorrectas, invocando consistentemente solo las funciones necesarias para completar cada paso. El seguimiento formal del estado del marco proporcionó un flujo de control estructurado a costa de un mayor tiempo de procesamiento.
El enfoque arquitectónico de LangGraph demostró que la gestión explícita del estado puede mantener su fiabilidad a medida que aumenta la complejidad, aunque la sobrecarga del recorrido del grafo se acentúa con una alta entropía de la herramienta y una mayor complejidad de razonamiento. Para aplicaciones que requieren capacidad de auditoría, reversión o lógica de ramificación compleja, esta compensación puede resultar ventajosa. Para la ejecución secuencial directa, la estructura adicional de LangGraph ofrece un valor limitado en comparación con modelos lineales más simples como LangChain.
Autogen
AutoGen consumió muchos más recursos que las soluciones de un solo agente, aunque sin llegar a los niveles extremos del sistema secuencial de CrewAI. El marco de trabajo implicaba múltiples conversaciones entre un UserProxy y agentes especializados. Cada turno en este chat requería una pasada completa de LLM que reprocesaba todo el historial de la conversación hasta la fecha.
Sin embargo, AutoGen seleccionó sistemáticamente las herramientas correctas y generó resultados precisos en todas las tareas sin utilizar herramientas irrelevantes. Esto introdujo una sobrecarga conversacional, ya que el sistema dedicó más tiempo a la coordinación que a la ejecución. Para esta tarea sencilla, la coordinación mediante chat de AutoGen se convirtió en una complejidad innecesaria en lugar de una ventaja colaborativa.
AutoGen empleaba una arquitectura basada en chat donde agentes especializados colaboraban a través de un UserProxy que gestionaba la coordinación del flujo de trabajo.
Configuramos AutoGen usando GroupChatManager en las tres tareas, lo que permitió la selección dinámica de agentes en lugar de forzar la ejecución secuencial. Esta arquitectura demostró que la orquestación inteligente puede lograr la colaboración entre múltiples agentes sin los costos exponenciales de recursos que implican las arquitecturas rígidas.
Alto número de traspasos con rendimiento competitivo
AutoGen registró el mayor número de traspasos entre todos los marcos de trabajo. En la Tarea 1, el marco de trabajo ya alcanzó niveles de traspaso que CrewAI solo logró en la Tarea 3 (9 traspasos). Esto refleja la naturaleza conversacional de AutoGen: cada interacción entre UserProxy y los agentes especializados se registra como un traspaso, incluso al discutir qué herramienta usar.
Sin embargo, a pesar de la gran cantidad de traspasos, la latencia de AutoGen se mantuvo competitiva con los marcos secuenciales en las tareas 1 y 2. En la tarea 3, mientras que la sobrecarga del marco de CrewAI alcanzó 1,35 millones de tokens, AutoGen consumió solo 56.700 tokens (en comparación con los 13.500 y 13.600 de LangChain y LangGraph, respectivamente).
¿Por qué AutoGen consumió más tokens a pesar de su latencia?
AutoGen consumió muchos más tokens que las soluciones de un solo agente, aunque sin llegar a los niveles extremos del sistema secuencial de CrewAI. El marco implicaba múltiples conversaciones entre un UserProxy y agentes especializados. Cada turno en este chat requería una pasada completa de LLM que reprocesaba todo el historial de la conversación hasta la fecha.
Esta acumulación recursiva de tokens explica por qué el consumo de tokens de AutoGen se mantuvo más alto que el de LangChain y LangGraph incluso cuando la latencia era competitiva. El historial de chat crece con cada turno, aumentando el tamaño de las indicaciones, pero el GroupChatManager del framework evita la explosión exponencial que se observa en las canalizaciones secuenciales al eliminar los agentes innecesarios.
Sin embargo, AutoGen seleccionó sistemáticamente las herramientas correctas y generó resultados precisos en todas las tareas sin utilizar herramientas irrelevantes. La sobrecarga conversacional implicó que el sistema dedicara más tiempo a la coordinación que a la ejecución, pero esta coordinación garantizó que ningún agente perdiera el enfoque ni utilizara herramientas incorrectas.
Administrador de chat grupal de AutoGen
La principal fortaleza arquitectónica de AutoGen reside en la selección dinámica de agentes mediante GroupChatManager. A diferencia de la orquestación secuencial de la Tarea 2, el modo GroupChat permitía que el sistema activara únicamente los agentes necesarios del grupo disponible.
El administrador eliminó a los especialistas innecesarios, activando solo 5 o 6 agentes del grupo de 10. Tan pronto como el árbitro encontró motivos suficientes para tomar una decisión, el administrador finalizó el ciclo. Esto evitó el crecimiento exponencial de tokens que se produciría si el contexto se aplicara secuencialmente a todos los agentes restantes.
Esta poda dinámica resultó en una latencia y un consumo de tokens sustancialmente menores en comparación con el rígido proceso secuencial de CrewAI. Mientras que CrewAI obligaba a los 10 agentes a ejecutar tareas independientemente de la necesidad, GroupChat de AutoGen seleccionaba de forma adaptativa solo los agentes necesarios para llegar a una decisión.
A pesar de la sobrecarga de coordinación, el elevado número de traspasos reflejó una deliberación exhaustiva en la que los agentes contrastaron los hallazgos antes de finalizar la tarea. La capacidad de AutoGen para alternar entre los modos secuencial y de chat grupal proporciona una flexibilidad de la que carecen las arquitecturas rígidas, lo que demuestra que la orquestación basada en chat con selección inteligente de agentes puede escalar de forma más eficiente que las canalizaciones fijas para flujos de trabajo complejos con múltiples agentes.
Cómo funciona AutoGen GroupChatManager:
- En cada paso, el gerente decide "¿qué agente debe hablar a continuación?" basándose en el contexto de la conversación.
- El marco no requiere que todos los agentes se ejecuten de forma secuencial.
- Si se recopila suficiente información con anticipación, el gerente puede omitir especialistas innecesarios.
- El administrador puede finalizar el bucle tan pronto como el agente tenga suficiente información para tomar una decisión.
El desafío de "Continuar, por favor": el comportamiento predeterminado de AutoGen es mantener las conversaciones activas. Para las pruebas de rendimiento, las señales de terminación precisas son fundamentales para evitar la pérdida de tokens. Abordamos este problema asegurándonos de que todos los agentes especializados incluyan señales TERMINATE explícitas al finalizar la tarea.
Sobrecarga del administrador: Incluso con GroupChatManager, el estado interno de los mensajes de AutoGen es mayor que el de LangChain debido a la orquestación multiagente. Sin embargo, esto proporciona registros y rastros de deliberación significativamente más estructurados que los marcos de trabajo más simples.
Nota sobre la secuenciación frente al chat grupal: Ejecutamos todas las tareas con GroupChatManager. En las pruebas experimentales con orquestación secuencial, observamos que el consumo de tokens y la latencia se duplicaban como mínimo en comparación con el modo de chat grupal, lo que confirma que la selección dinámica de agentes ofrece mejoras sustanciales en la eficiencia con respecto a las canalizaciones fijas.
Metodología de evaluación comparativa de marcos multiagente
Cada marco de trabajo se probó durante 50 iteraciones (N=50) por tarea.
Para eliminar la variabilidad en el proceso de razonamiento del modelo, todos los marcos utilizaron la misma configuración LLM. El modelo utilizado fue openai/gpt-5.2 a través de la API OpenRouter. La temperatura se estableció en 0.0 .
No se impuso ningún límite máximo de tokens a las respuestas del LLM, lo que permitió a los marcos de trabajo utilizar todo el contexto que su arquitectura interna requiriera para resolver la tarea.
Las métricas registradas incluyen: número de llamadas a la API de LLM, traspasos entre agentes, agentes únicos invocados, llamadas a herramientas ejecutadas y precisión de las llamadas a herramientas. Todas las métricas se registraron por iteración y se agregaron en la muestra de 50 ejecuciones.
Separamos las salidas brutas del LLM de la sobrecarga adicional introducida por la orquestación para medir la eficiencia de esta última. Los tokens de salida del LLM representan las respuestas útiles reales generadas por el modelo, mientras que la sobrecarga del marco de trabajo abarca los comandos del sistema, las definiciones de herramientas y los historiales de conversación que el marco de trabajo debe proporcionar al LLM en segundo plano para obtener dichas respuestas.
Esta métrica, calculada restando los tokens de salida del total de tokens (Total – Tokens de salida), revela directamente el “costo de gestión” que el framework oculta al usuario. Gracias a esta distinción, podemos ver qué frameworks se mantienen eficientes y optimizados, frente a cuáles cargan repetidamente grandes volúmenes de datos en el LLM en cada paso de la orquestación. Basamos nuestro análisis en los tokens de sobrecarga del framework como nuestra principal métrica de eficiencia.
Para garantizar que los marcos de trabajo se midieran únicamente en función de su lógica de coordinación, sincronizamos todas las demás variables. Esto eliminó los factores de confusión y las diferencias arquitectónicas aisladas.
Los agentes se definieron en un archivo central. El envoltorio de cada marco de trabajo inyectó la misma cadena de perfil en su parámetro nativo: system_message para AutoGen, backstory para CrewAI, system prompts para LangChain/LangGraph y agent descriptions para Swarm. No se aplicó ingeniería de mensajes específica para cada marco de trabajo.
Todos los frameworks utilizaban las mismas funciones subyacentes de Python. Las definiciones de herramientas, las cadenas de documentación y los esquemas de parámetros estaban estandarizados. No se utilizaban herramientas predefinidas específicas de cada framework. Esto garantiza la coherencia de la lógica de ejecución de las herramientas, y solo difieren los mecanismos de orquestación.
En cada iteración, el conjunto de datos de "DataCo Smart Supply Chain" se alimentaba a los agentes. Los datos reales (estado del envío, estado del pago, márgenes de beneficio) se mantuvieron constantes en todos los marcos de trabajo.
Manteniendo las mismas entradas, cada framework operó en su modo estructural nativo. No forzamos los frameworks a adoptar arquitecturas artificiales. En cambio, implementamos cada framework según su patrón de diseño previsto para medir su rendimiento en condiciones reales.
AutoGen funciona como un sistema de chat grupal conversacional. Utiliza la función `initiate_chats` con señales `TERMINATE` para gestionar las condiciones de salida. Los agentes se comunican mediante el paso de mensajes, con un `UserProxy` que coordina el flujo de trabajo.
CrewAI implementa una arquitectura secuencial basada en tareas. Utiliza Process.sequential, donde los agentes se ejecutan en un orden fijo. Cada agente completa su tarea y genera un informe antes de que comience el siguiente.
LangChain sigue una arquitectura de cadena lineal. Utiliza un AgentExecutor estándar que encapsula el bucle de llamada a herramientas. El agente ejecuta las herramientas secuencialmente dentro de un único contexto.
LangGraph estructura la ejecución como un grafo de estados cíclico. Utiliza StateGraph con nodos que representan pasos de procesamiento y aristas de enrutamiento condicional para determinar el flujo.
Swarm emplea rutinas basadas en la transferencia de control. Utiliza funciones transfer_to_agent para cambiar el control dinámicamente entre agentes en función de decisiones tomadas en tiempo de ejecución.
Las tareas fueron aumentando en complejidad para poner a prueba las diferentes capacidades de orquestación y los modos de fallo.
Tarea 1 (2 agentes / 5 herramientas): Prueba la sobrecarga de orquestación básica para un flujo de trabajo simple que requiere la recopilación de información de pedidos y la toma de decisiones sobre reembolsos.
Tarea 2 (5 agentes / 20 herramientas): Prueba la inteligencia de enrutamiento en presencia de ruido. Solo se necesitan 2-3 agentes y 3-5 herramientas, pero se dispone de 5 agentes y 20 herramientas.
Tarea 3 (10 agentes / 100 herramientas): Prueba el filtrado de alta entropía y los límites de escalabilidad. Solo se necesitan 2-3 agentes y 3-5 herramientas, pero se dispone de 10 agentes y 100 herramientas, incluidas 98 herramientas de ruido irrelevante diseñadas para confundir el enrutamiento.
Siguiente para leer
Comparativa de plataformas de agentes de IA: Agentes gestionados por Claude frente a Vertex Agent Engine (Google)
El panorama de la evaluación de los másteres en Derecho (LLM) con sus respectivos marcos de referencia.
Marcos de trabajo RAG: LangChain vs LangGraph vs LlamaIndex
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios.