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.
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.
Resumen
- Idea Central: Un solo agente es un bucle de decidir-actuar-observar sobre una única ventana de contexto; un sistema multiagente son múltiples bucles de este tipo coordinados por código que tú escribes.
- Por Qué Importa: Elegir multiagente por defecto añade latencia, complejidad de coordinación y coste a tareas que un solo bucle habría manejado igual de bien.
- Conceptos Clave: el bucle de llamada a herramientas, ventana de contexto, descomposición de tareas, paralelismo, aislamiento de contexto, orquestador/trabajador.
- Cuándo Usar: Recurre a múltiples agentes cuando una tarea se descompone en subtareas genuinamente independientes, cuando diferentes piezas necesitan acceso a herramientas distintas, o cuando una pieza de lo contrario inundaría un contexto compartido con exploración irrelevante.
- Limitaciones / Compensaciones: Los sistemas multiagente son más difíciles de depurar, más lentos de extremo a extremo cuando las subtareas son secuenciales, y cuestan más tokens ya que cada límite de agente inicia un nuevo contexto.
- Temas Relacionados: patrones de orquestador/trabajador, delegación a subagentes, encadenamiento de prompts vs. enrutamiento, barreras de seguridad para sistemas multiagente.
Fundamentos
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.
Mecánicas e Interacciones
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.
Consideraciones Avanzadas y Aplicaciones
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.
Conceptos Erróneos Comunes
- "Los sistemas multiagente son siempre más capaces." Un sistema multiagente solo puede hacer lo que sus agentes individuales pueden hacer; no añade capacidad de razonamiento, solo paralelismo y aislamiento de contexto. Un solo agente con las herramientas adecuadas resuelve la misma clase de problemas.
- "Más agentes significa más exhaustividad." Dividir una tarea entre agentes cambia cómo se organiza el trabajo, no cuán cuidadosamente se hace. Un subagente mal definido no es más exhaustivo que una llamada a herramienta mal definida.
- "Los agentes deberían delegar por defecto, ya que es más escalable." La delegación es una elección arquitectónica deliberada que se toma cuando la forma de la tarea lo justifica, no una postura por defecto; la mayoría de las tareas son más baratas y fiables como un solo bucle.
- "Un subagente ve todo lo que ve el orquestador." Un subagente normalmente comienza con un contexto nuevo; el orquestador tiene que pasarle lo que el subagente realmente necesita, no se hereda automáticamente.
- "Los subagentes paralelos son gratuitos solo porque se ejecutan concurrentemente." La concurrencia ahorra tiempo de reloj, no coste de tokens; cada trabajador paralelo todavía paga por su propio contexto y su propio razonamiento.
Preguntas Frecuentes
¿Cuál es la definición más simple de un bucle de agente único?
- Un modelo, una ventana de contexto, que decide repetidamente una acción, la ejecuta (normalmente una llamada a herramienta) y observa el resultado hasta que la tarea se completa.
¿Cuál es la definición más simple de un sistema multiagente?
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.
¿Cómo sé si mi tarea debe dividirse entre agentes?
- Pregúntate si las subtareas son independientes: ¿necesita alguna subtarea ver el razonamiento intermedio de otra, no solo su resultado final?
- Si es así, mantenlo en un solo agente. Si no, y hay suficientes subtareas para que el paralelismo valga la pena, dividir es razonable.
¿Dividir una tarea entre agentes la hace más rápida?
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.
¿Dividir una tarea entre agentes la hace más barata?
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.
¿Qué es el aislamiento de contexto y por qué es importante?
- Significa que el razonamiento exploratorio, los intentos fallidos y las llamadas a herramientas intermedias de un trabajador permanecen dentro del propio contexto de ese trabajador y nunca aparecen en el contexto del orquestador.
- Es importante porque mantiene el razonamiento del orquestador sobre el resultado combinado libre de ruido de cómo se resolvió cada pieza.
¿Es un orquestador en sí mismo un agente?
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.
¿Cuál es la diferencia entre añadir una herramienta y añadir un subagente?
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).
¿Puede un solo agente usar demasiadas herramientas en lugar de delegar?
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.
¿Hay un coste por usar multiagente innecesariamente?
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).
¿Debería empezar los nuevos proyectos por defecto con una arquitectura multiagente "para estar seguro"?
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.
Relacionados
- Fundamentos de Orquestación de Agentes - un orquestador mínimo que pasa una tarea a un subagente
- Patrones de Orquestador/Trabajador con el SDK de Agente de Claude - el patrón al que conduce este modelo mental
- Barreras de Seguridad para Sistemas Multiagente: Limitando Coste y Alcance - controlando la sobrecarga que describe esta página
- El Modelo Mental del SDK de Agente de Claude - cómo funciona el bucle de llamada a herramientas subyacente
- Delegar Trabajo a Subagentes en el SDK de Agente de Claude - las mecánicas del SDK de un límite de subagente
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.