Arquitecturas multiagente

Al terminar esta lección sabrás reconocer las tres arquitecturas multiagente que cubren casi todos los casos reales, qué forma de tarea encaja con cada una y qué precio pagas por ellas. Tendrás un esqueleto de código de cada una para empezar.

La idea

Un sistema multiagente reparte una tarea entre varias llamadas al modelo con roles, instrucciones y a veces herramientas distintas. La pregunta de diseño es cómo fluye la información entre ellas: quién decide qué se hace, quién ve qué y quién tiene la última palabra.

Antes de elegir, recuerda la regla del roadmap: cada agente adicional multiplica coste, latencia y puntos de fallo (Cuándo NO usar multiagente). Una arquitectura multiagente se justifica cuando la tarea tiene una de estas tres formas: partes independientes que se pueden hacer a la vez, etapas con entradas y salidas distintas, o un resultado que mejora con crítica independiente.

Orquestador y trabajadores

Un agente principal analiza la tarea, la divide en subtareas que decide en tiempo de ejecución, lanza un subagente por cada una y sintetiza los resultados. Es el patrón Orquestador y trabajadores llevado a agentes completos, cada uno con su propio bucle y herramientas.

flowchart TD
  U[Tarea] --> O[Orquestador]
  O --> S1[Subagente 1]
  O --> S2[Subagente 2]
  O --> S3[Subagente 3]
  S1 --> O
  S2 --> O
  S3 --> O
  O --> R[Síntesis]

Es la arquitectura del sistema de investigación que describe Anthropic en How we built our multi-agent research system: un agente líder planifica la investigación y lanza subagentes que buscan en paralelo, cada uno con su propia ventana de contexto. El artículo explica que la ventaja viene de ahí: cada subagente explora una parte con un contexto limpio y devuelve solo lo importante, así que el sistema en conjunto procesa mucha más información de la que cabría en un solo contexto.

Encaja con tareas amplias y paralelizables: investigar un tema desde varios ángulos, revisar muchos documentos, comparar opciones. Falla cuando las subtareas dependen mucho unas de otras o necesitan compartir contexto en todo momento. El propio artículo señala que la mayoría de tareas de programación encajan peor que la investigación por este motivo: hay menos trabajo realmente paralelizable y los agentes necesitan coordinarse sobre el mismo código.

Pipeline

Una cadena fija de agentes especializados: la salida de uno es la entrada del siguiente. Extraer, luego clasificar, luego redactar. Es el encadenado con agentes en cada etapa y comprobaciones entre ellas.

flowchart LR
  E[Extractor] -- datos --> C{Validación}
  C -- ok --> A[Analista]
  A -- informe --> R[Redactor]
  C -- error --> E

Encaja cuando las etapas son conocidas de antemano y cada una se beneficia de instrucciones, herramientas o incluso modelo propios. Su gran ventaja es que se depura etapa a etapa: puedes evaluar cada salida intermedia por separado. Falla cuando el orden de los pasos depende de lo que se encuentre; ahí necesitas un orquestador que decida. Y los errores se propagan: si la primera etapa se equivoca, las demás trabajan sobre algo falso, así que valida entre etapas.

Evaluador y debate

Un agente genera y otro critica con un criterio explícito; el primero corrige y se repite hasta pasar o agotar intentos. Es Evaluador-optimizador. La variante de debate pone a dos o más agentes a defender posiciones o soluciones distintas y a un tercero a decidir.

flowchart LR
  G[Generador] -- borrador --> E[Evaluador]
  E -- crítica --> G
  E -- aprobado --> R[Resultado]

Encaja cuando hay un criterio de calidad claro que se puede comprobar mejor de lo que se puede cumplir a la primera: una traducción con glosario obligatorio, código que debe pasar una revisión de seguridad, un texto con requisitos. Falla con criterios vagos («mejóralo»), porque el evaluador aprueba todo o critica sin fin. Un evaluador del mismo modelo con el mismo contexto tiende a compartir los puntos ciegos del generador; dale un contexto distinto (solo el resultado y la rúbrica) y, si puedes, una comprobación con código.

Comparación

Se combinan: un orquestador cuyos trabajadores son pipelines, o un pipeline con un evaluador al final. Empieza por la más simple que resuelva el problema y añade piezas cuando una medida te diga que hacen falta (Qué patrón elegir).

Los tres esqueletos

Las tres arquitecturas sobre una misma función llamar. En la vida real cada llamar sería un agente con su bucle y herramientas; aquí se simplifica para ver la topología.

import asyncio, json
import anthropic

MODEL = "claude-sonnet-5-5"
client = anthropic.AsyncAnthropic()

async def llamar(system: str, prompt: str, max_tokens: int = 2048) -> str:
    resp = await client.messages.create(model=MODEL, max_tokens=max_tokens, system=system,
                                        messages=[{"role": "user", "content": prompt}])
    if resp.stop_reason not in ("end_turn", "stop_sequence"):
        raise RuntimeError(f"stop_reason {resp.stop_reason}")
    return "".join(b.text for b in resp.content if b.type == "text")

async def orquestador(pregunta: str) -> str:
    plan = await llamar("Divide la pregunta en 2-4 subpreguntas independientes. "
                        'Responde solo con JSON: {"subtareas": ["..."]}', pregunta)
    subtareas = json.loads(plan)["subtareas"]  # en producción: salida estructurada y validación
    hallazgos = await asyncio.gather(*[
        llamar("Investiga solo esta subpregunta. Devuelve hallazgos con su fuente.", s)
        for s in subtareas])
    bloques = "\n".join(f"<hallazgo>{h}</hallazgo>" for h in hallazgos)
    return await llamar("Sintetiza una respuesta a partir de los hallazgos.",
                        f"<pregunta>{pregunta}</pregunta>\n{bloques}")

async def pipeline(documento: str) -> str:
    datos = await llamar("Extrae fechas, importes y partes en JSON.", documento)
    json.loads(datos)  # validación entre etapas: falla pronto si no es JSON
    analisis = await llamar("Señala riesgos en estos datos.", datos)
    return await llamar("Redacta un informe de media página para dirección.", analisis)

async def evaluador(encargo: str, rubrica: str, max_rondas: int = 3) -> str:
    borrador = await llamar("Redacta según el encargo.", encargo)
    for _ in range(max_rondas):
        veredicto = await llamar(
            f"Evalúa con esta rúbrica:\n{rubrica}\nPrimera línea: APROBADO o RECHAZADO. "
            "Después, solo los fallos concretos.", borrador)
        if veredicto.startswith("APROBADO"):
            return borrador
        borrador = await llamar("Corrige el borrador según la crítica.",
                                f"<borrador>{borrador}</borrador>\n<critica>{veredicto}</critica>")
    return borrador  # sin aprobar: márcalo para revisión humana

if __name__ == "__main__":
    print(asyncio.run(orquestador("¿Qué opciones hay para cachear respuestas de un LLM?")))

Observa que el evaluador solo ve el borrador y la rúbrica, nunca el razonamiento del generador. Y que cada esqueleto tiene un límite: número de subtareas, validación entre etapas, número de rondas. Sin límites, un sistema multiagente puede gastar sin parar.

Errores frecuentes

• Elegir por moda. Varios agentes no son más inteligentes que uno; solo reparten contexto y trabajo.
• Pipeline sin validación entre etapas. El error de la etapa 1 aparece en la etapa 3 y parece culpa de la 3.
• Evaluador sin criterio. Si no puedes escribir la rúbrica, no hay evaluador posible.

Ejercicio

Resumen

• Tres arquitecturas cubren casi todo: orquestador-trabajadores, pipeline y evaluador o debate.
• Elige por la forma de la tarea: partes independientes, etapas fijas o calidad verificable.
• El orquestador gana con tareas amplias y paralelizables; pierde cuando todo depende de todo.
• Valida entre etapas y da al evaluador un contexto distinto y una rúbrica concreta.
• Pon límites en cada arquitectura y mide el coste frente a un solo agente.

Para seguir

• Diseñar subagentes
• Sistema multiagente de investigación
• El coste de multiplicar agentes