Bucles de Agente Único vs. Sistemas Multiagente: Un Modelo Mental
Antes de recurrir a una arquitectura multiagente, un líder técnico necesita una prueba clara para saber cuándo está realmente justificada.
//
Busca en todas las páginas de la documentación
Antes de recurrir a una arquitectura multiagente, un líder técnico necesita una prueba clara para saber cuándo está realmente justificada.
La respuesta honesta para la mayoría de las tareas es que un solo agente, iterando sobre herramientas hasta que la tarea se complete, es más simple de construir, más barato de ejecutar y más fácil de depurar que cualquier diseño multiagente.
Esta página te proporciona el modelo mental para distinguir entre ambos: qué es realmente un bucle de agente único, qué añade un sistema multiagente sobre él, y las señales específicas que indican que una tarea ha superado las capacidades de un solo bucle.
Un solo agente es un bucle: el modelo decide qué hacer a continuación, se ejecuta una acción (normalmente una llamada a una herramienta), el resultado vuelve como una observación, y el modelo decide de nuevo.
Este bucle continúa, todo dentro de una única ventana de contexto, hasta que el modelo determina que la tarea está completada o alcanza una condición de parada.
Todo lo que el agente ha visto, cada archivo que ha leído, cada comando que ha ejecutado, cada error que ha cometido y corregido, vive en ese único contexto en crecimiento.
Esta es la forma por defecto de un agente, y es suficiente para la gran mayoría de las tareas: responder una pregunta, escribir un archivo, corregir un error, ejecutar un script e interpretar la salida.
Un sistema multiagente reemplaza ese bucle único con dos o más bucles, cada uno con su propia ventana de contexto, coordinados por código de aplicación que se sitúa fuera de cualquier agente individual.
La versión más simple es un orquestador y un trabajador: el agente orquestador (o código plano) decide pasar una subtarea a un agente trabajador, espera el resultado del trabajador y continúa su propio bucle con ese resultado incorporado.
Nada en un agente trabajador es arquitectónicamente diferente de un agente único por sí solo. Lo que es diferente es que se ejecuta en un contexto que el orquestador no puede ver, y su resultado cruza un límite de vuelta al padre.
La decisión de dividir una tarea entre agentes se reduce a una pregunta: ¿se descompone esta tarea en piezas que no necesitan ver los pasos intermedios de las otras?
Si la respuesta es no, un solo bucle con más herramientas es casi siempre la opción correcta. Añadir un límite de agente a una tarea que es fundamentalmente una línea continua de razonamiento solo añade un punto de serialización sin beneficio.
Si la respuesta es sí, un límite de agente te proporciona dos cosas específicas: paralelismo, ya que los trabajadores independientes pueden ejecutarse concurrentemente en lugar de uno tras otro, y aislamiento de contexto, ya que los intentos fallidos y las llamadas exploratorias a herramientas de un trabajador permanecen dentro de su propio contexto en lugar de acumularse en el del padre.
El aislamiento importa más de lo que parece inicialmente. Un solo agente que audita cinco archivos no relacionados acumula el razonamiento, los callejones sin salida y la salida de herramientas de los cinco en un solo contexto, y ese ruido sigue ahí cuando el modelo razona sobre el archivo tres, aunque nada sobre el archivo tres dependiera de ello.
Cinco subagentes aislados, uno por archivo, cada uno empieza limpio, y solo sus resultados finales cruzan de vuelta al orquestador, que ve cinco resúmenes limpios en lugar de una transcripción larga y ruidosa.
# La forma de la decisión, no una implementación completa.
# is_independent(a, b) pregunta si la subtarea b necesita algo
# que la subtarea a descubre a mitad de camino, no solo el resultado final de a.
if task_decomposes_into(subtasks) and all(
is_independent(a, b) for a, b in pairs(subtasks)
):
use_multi_agent(subtasks) # orquestador + un trabajador por subtarea
else:
use_single_agent(task) # un bucle, más herramientas si es necesarioLa coordinación no es gratuita. Cada límite de agente significa: un nuevo contexto tiene que ser reconstruido de nuevo (más tokens gastados restableciendo el estado relevante), el orquestador tiene que esperar a un trabajador síncrono o gestionar los concurrentes, y un fallo dentro de un trabajador se convierte en otra categoría de error que el propio bucle del orquestador tiene que interpretar y del que recuperarse, en lugar de que falle una llamada a herramienta en línea.
La prueba de descomposición se reduce a una regla general: si no puedes describir las subtareas como puntos de viñeta paralelos sin flechas entre ellos, no son independientes, y dividirlas entre agentes solo te obligará a reinventar la secuenciación con pasos adicionales.
La especialización es la otra razón legítima para dividir, separada del paralelismo. Una subtarea que necesita un alcance de herramientas más estrecho o diferente que el resto de la tarea, por ejemplo, una pieza que solo debería leer archivos y nunca escribirlos, es candidata para su propio agente, incluso si no se ejecuta concurrentemente con nada más, porque el acceso a herramientas en el SDK de Agente de Claude está limitado por agente, no compartido globalmente.
El coste se acumula con la profundidad. Una sola capa adicional de delegación, un orquestador que pasa el trabajo a un puñado de trabajadores, suele ser una sobrecarga modesta. Los trabajadores que a su vez delegan a sub-trabajadores multiplican esa sobrecarga y hacen que los fallos sean mucho más difíciles de rastrear hasta una causa raíz, por lo que la mayoría de los sistemas de producción limitan la delegación a uno o dos niveles.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Agente único, más herramientas | Más simple de construir, depurar y razonar | Sin paralelismo; un contexto largo acumula todo el razonamiento | Tareas secuenciales, o tareas que necesitan una capacidad adicional |
| Orquestador + trabajadores (un nivel) | Ejecución paralela; contexto limpio por subtarea | Código de coordinación, latencia por trabajador y coste de tokens | Tarea se descompone en subtareas independientes y de forma similar |
| Delegación multinivel profunda | Maneja descomposición genuinamente anidada | Difícil de depurar, el coste y la latencia se acumulan con la profundidad | Raro; solo cuando las subtareas necesitan delegar |
La latencia no es automáticamente mejor con múltiples agentes. Los trabajadores independientes que se ejecutan concurrentemente pueden terminar más rápido que un solo agente haciendo el mismo trabajo en serie, pero si el orquestador tiene que esperar a los trabajadores uno a uno, o si la tarea era secuencial desde el principio, un diseño multiagente es estrictamente más lento que un solo bucle, ya que añade la sobrecarga de iniciar y cerrar el contexto de cada trabajador además del trabajo real.
Dos o más de esos bucles, cada uno con su propio contexto, coordinados por código (un orquestador) que decide cuándo delegar trabajo y cómo combinar resultados.
Solo si las subtareas pueden ejecutarse realmente de forma concurrente. Las subtareas secuenciales divididas entre agentes suelen ejecutarse más lentamente que un solo agente manejándolas en orden, porque cada traspaso añade su propia sobrecarga de configuración y paso de resultados.
Normalmente no. El contexto de cada agente comienza de nuevo, por lo que cualquier fondo compartido tiene que ser restablecido por agente, y esa repetición cuesta tokens que un contexto compartido único no gastaría.
Puede ser tanto un agente completo que toma sus propias decisiones de llamada a herramientas (incluyendo cuándo invocar a un trabajador) como código de aplicación plano que llama a trabajadores en una secuencia fija; ambos patrones son comunes.
Una herramienta añade una capacidad más a un bucle existente sin un nuevo límite de contexto. Un subagente añade un segundo bucle completo con su propio contexto y su propio alcance de herramientas, cruzado solo al principio (el prompt) y al final (el resultado).
Sí. Amontonar muchas herramientas y responsabilidades no relacionadas en el contexto de un agente hace que su razonamiento sea más ruidoso en una tarea larga, incluso sin un problema de descomposición; en algún punto, la especialización en agentes separados se convierte en el diseño más legible, no solo el más paralelo.
Sí, en tres ejes: coste de tokens (contexto nuevo por agente), latencia (sobrecarga de configuración y traspaso), y depurabilidad (un fallo podría originarse en la lógica del orquestador o en cualquier trabajador, lo cual es más difícil de rastrear que una única llamada a herramienta fallida).
No. Empieza con un solo agente y el conjunto de herramientas más pequeño que resuelva la tarea. Pasa a un diseño multiagente solo cuando aparezca una necesidad específica y concreta de descomposición o especialización, no de forma preventiva.
Versiones de Stack: Escrito contra la línea de modelos Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado), y Claude Haiku 4.5 - y el SDK de Agente de Claude (última versión). Los nombres de los modelos, las versiones del SDK y los precios cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs antes de confiar en ellos.
Revisado por Chris St. John·Última actualización: 16 jul 2026