Resumen central
El reciente lanzamiento de GraphWorkflow por parte del equipo Swarms ha acelerado la programación de tareas con múltiples agentes, pero el verdadero valor de este artículo no reside en el número en sí (“un 62.5% de aceleración”), sino que revela una señal clave: los sistemas de múltiples agentes (comúnmente conocidos como “enjambres”) han pasado de competir en la inteligencia de los modelos a una etapa de ingeniería basada en la capacidad de colaboración organizativa. No es cuestión de tener tantos agentes como sea posible, sino de resolver cómo lograr que un grupo de agentes inteligentes no desperdicie tiempo, no cometa errores colectivamente y pueda entregar tareas de manera estable.
I. No se dejen engañar por el término “enjambre”: no se trata simplemente de reunir agentes al azar
Muchos productos denominan “enjambre” a la ejecución simultánea de varios agentes, pero en realidad, un verdadero enjambre es un sistema en el que “no hay control central y cada individuo actúa basándose en información local, formando un comportamiento colectivo” (como cuando las hormigas encuentran el camino). Los sistemas de múltiples agentes que se utilizan actualmente son más similares a “equipos de proyecto temporales”:
- Agente único: similar a un empleado experto que trabaja por su cuenta, adecuado para tareas lineales y cortas (como escribir un correo electrónico).
- Supervisor/Trabajador: un gerente de proyecto que dirige a varios asistentes (como el sistema de Anthropic, donde el agente principal divide las tareas y los subagentes buscan información).
- Flujo de trabajo gráfico: procesos estandarizados (como revisiones de cumplimiento o pruebas en masa); tanto GraphWorkflow como LangGraph pertenecen a esta categoría.
- Enjambre dinámico: los agentes deciden en el proceso si dividir las tareas o con quién trabajar (por ejemplo, el Kimi Agent Swarm puede coordinar dinámicamente a 300 subagentes).
- Enjambre completamente descentralizado: todavía en fase de investigación (como la simulación del vuelo de las aves), lejos de su uso práctico.
Por lo tanto, el enjambre es esencialmente un problema organizativo: cómo hacer que varios agentes trabajen juntos a través de la división del trabajo, la comunicación y el intercambio de información para lograr lo que un solo agente no podría.
II. ¿Por qué usar múltiples agentes? Hay tareas que un solo agente no puede manejar
Los modelos individuales se vuelven cada vez más inteligentes, pero hay tareas que no se pueden resolver simplemente dando más tiempo:
- Ámbito de trabajo demasiado amplio: por ejemplo, encontrar hechos que se corroboran entre 100 informes; un solo agente tendría que revisarlos uno por uno, lo que puede ser lento. Múltiples agentes pueden buscar en direcciones diferentes al mismo tiempo.
- Limitaciones del pensamiento lineal: un solo agente se enfoca en una dirección y ignora otras opciones; múltiples agentes pueden trabajar en múltiples frentes (algunos buscan información pública, otros documentos originales, y otros proporcionan verificación).
El ejemplo de Anthropic es ilustrativo: usar un agente principal para coordinar y subagentes para trabajar resulta en un 90% más de eficiencia que usar el modelo más potente, pero el costo en tokens (dinero) es 15 veces mayor. No todas las tareas son adecuadas para este enfoque; por ejemplo, las tareas de programación que pueden ser paralelas son pocas, y usar múltiples agentes puede aumentar las pérdidas de comunicación.
III. Detrás de la aceleración en la programación: la organización comienza a consumir recursos de cálculo
La aceleración de GraphWorkflow se debe a la optimización del “flujo de trabajo de tareas”: se compila primero un diagrama de flujo de tareas fijo y luego se ejecuta repetidamente, reduciendo el tiempo necesario para coordinar quién espera a quién y quién entrega los resultados. Sin embargo, solo se midió el costo de programación de tareas estáticas en una sola máquina, no la velocidad del modelo en sí; la optimización del flujo de trabajo tiene un impacto limitado (unos pocos milisegundos).
Esto indica que cuando hay decenas o cientos de agentes, los costos organizativos pasan a ser un factor importante. Es como en una empresa: se necesita tiempo para coordinar qué hace cada uno, quién espera a quién y cómo reintentar si hay errores. Es por esta razón que, cuando se habla de enjambres, se mencionan más términos técnicos como “flujo de trabajo”, “programadores de tareas” y “combinación de estados”.
IV. Tres desafíos principales de los enjambres: dividir tareas, recordar información y verificar errores
Dividir tareas entre múltiples agentes parece una cuestión de gestión, pero en realidad son problemas técnicos difíciles de resolver:
1. Asignación de tareas: ¿Qué tareas deben dividirse? ¿A quién se deben asignar? ¿Cuándo no es necesario dividirlas y qué debe hacer cada agente? Por ejemplo, SearchSwarm enseña al agente principal a decidir si asignar tareas, y los subagentes solo envían resultados comprimidos para evitar la pérdida de contexto.
2. Memoria: no se trata de recordar las preferencias del usuario, sino de mantener un registro claro de las tareas (quién es responsable de qué, de qué fuente provienen las conclusiones y qué hipótesis se han rechazado). Si cada agente reenvía largas conversaciones, el sistema se vería sobrecargado de información innecesaria.
3. Verificación: tener múltiples agentes no significa necesariamente mayor confiabilidad; pueden cometer errores colectivamente (por ejemplo, si todos usan la misma información, pueden reforzar sesgos mutuamente). Los experimentos demuestran que las arquitecturas con verificación central reducen la tasa de errores en un 4.4%, en comparación con un 17.2% en los sistemas sin verificación. En el futuro, los roles más escasos no serán los agentes que trabajan, sino los verificadores que aseguran la calidad.
V. El enjambre del futuro: no será una “pequeña empresa”, sino un “equipo de asalto” temporal
Muchas demostraciones presentan los enjambres como estructuras organizativas similares a las de una empresa (CEO, marketing, producto), pero el modelo futuro será más parecido a equipos temporales:
- Cuando llega una tarea, se evalúan primero los riesgos, el presupuesto y la posibilidad de ejecución en paralelo.
- Se crean agentes temporales para diferentes partes de la tarea y se disuelven al final.
- Un centro coordina los objetivos y el presupuesto, mientras que las partes locales tienen libertad para explorar dinámicamente; los verificadores se encargan de asegurar que todo funcione correctamente.
Por ejemplo, el enjambre recursivo de WebSwarm permite que los agentes decidan en el proceso si trabajan por su cuenta o generan subagentes; la estructura organizativa se forma dinámicamente durante la ejecución. Sin embargo, esto conlleva riesgos (pérdida de control del presupuesto, dificultades para rastrear errores), por lo que los sistemas de producción buscarán un equilibrio entre “libertad” y “control”.
Consejo para los emprendedores
No obsesionarse con el número de agentes: primero, pregúntese si hay 100 caminos diferentes para explorar el problema del usuario. Si no, un solo agente, herramientas adecuadas y un mecanismo de aceptación son más económicos y fiables. Los enjambres solo son útiles cuando las tareas se pueden dividir, cada rama contiene información nueva y los resultados se pueden verificar entre sí.
Las competiciones de modelos continuarán, pero la próxima vez, la diferencia no estará en cuál modelo es más inteligente, sino en quién puede organizar a los agentes de manera eficiente, sin desperdicios y sin errores.
(Nota: Los datos de investigación de 2026 provienen de prepublicaciones o revelaciones de fabricantes y no son estándares del sector; deben considerarse con objetividad.)