Un enjambre de agentes para un análisis multiángulo: construyendo un equipo de expertos a partir de LLMs

No se trata de velocidad. Se trata de hacer que varios agentes con diferentes puntos de vista discutan una decisión y lleguen a una conclusión mejor que la de cualquiera de ellos por sí solos. Con el código completo para el orquestador, los expertos y la fusión.

Cuando le pides a un solo modelo que evalúe una decisión, da una visión única, generalmente promediada y cautelosa. Tiende a estar de acuerdo, a suavizar, a buscar el equilibrio. Ese es el problema: una decisión importante no puede ser evaluada por una sola visión promediada, debe ser atacada desde diferentes lados.

Un enjambre de agentes resuelve esto estructuralmente. Creas varios expertos, cada uno con un rol y sesgo fijo: uno piensa solo en el dinero, otro solo en el riesgo técnico, un tercero solo en el usuario. Analizan una decisión de forma independiente, llegan a conclusiones diferentes, y luego fuerzas una reconciliación de esas conclusiones. El valor aquí no es la velocidad, sino que el desacuerdo está integrado en la estructura. Un solo agente tiende al pensamiento grupal consigo mismo; un enjambre de roles no.

Este artículo muestra cómo construir tal enjambre, con código. Cubrimos tres partes: el orquestador que asigna roles, los expertos que analizan de forma independiente, y la fusión que los reconcilia en una sola conclusión.

Arquitectura: Orquestador, Expertos, Fusión

Un enjambre para análisis tiene tres componentes. El orquestador toma la tarea y decide qué roles de expertos se necesitan. Para evaluar el lanzamiento de un producto, estos podrían ser un inversor, un ingeniero, un especialista en producto, una persona de seguridad. El orquestador no analiza por sí mismo, asigna roles.

Los expertos trabajan en paralelo e independientemente. Cada uno ve la misma decisión pero a través de su propio lente. Fundamentalmente, no ven las conclusiones de los demás, de lo contrario se produce la conformidad. La independencia es lo que produce diferentes puntos de vista.

La fusión recoge las conclusiones de los expertos y las reconcilia: dónde están de acuerdo, dónde se contradicen, cuál es el veredicto final desde todos los ángulos. Esto no es un promedio, sino una síntesis que mantiene el desacuerdo como una señal.

Paso 1: El Cliente Básico

Comienza con un cliente simple para el modelo. Uso un formato de mensaje compatible con OpenAI, funciona con la mayoría de los proveedores y con Ollama local.

1import requests
2import json
3from concurrent.futures import ThreadPoolExecutor
4
5API = "http://localhost:11434/api/chat"   # Ollama, o un endpoint de proveedor
6MODEL = "qwen2.5:32b"
7
8def ask(system, user, temperature=0.7):
9    resp = requests.post(API, json={
10        "model": MODEL,
11        "messages": [
12            {"role": "system", "content": system},
13            {"role": "user", "content": user},
14        ],
15        "temperature": temperature,
16        "stream": False,
17    }, timeout=120)
18    resp.raise_for_status()
19    return resp.json()["message"]["content"]

Paso 2: El Orquestador Asigna Roles

El orquestador recibe la tarea y decide qué expertos se necesitan. No codifiques los roles de antemano, deja que el modelo los elija para la tarea específica, esto hace que el enjambre sea general. Pide JSON estricto para analizar.

1ORCHESTRATOR_SYSTEM = """Eres el orquestador de un enjambre analítico.
2Para la tarea, define de 3 a 5 roles de expertos que den puntos de vista MÁXIMAMENTE DIFERENTES
3y conflictivos sobre la decisión. Los roles deben entrar en conflicto en sus
4intereses, no complementarse entre sí.
5
6Para cada rol da: nombre, enfoque (en qué se fija), sesgo (hacia qué está
7sesgado, qué tiende a sobrevalorar).
8
9Responde SOLO con un arreglo JSON, sin explicaciones:
10[{"name": "...", "focus": "...", "bias": "..."}, ...]
11"""
12
13def plan_roles(task):
14    raw = ask(ORCHESTRATOR_SYSTEM, f"Tarea a analizar:\n{task}",
15              temperature=0.9)   # temperatura más alta para diversidad de roles
16    # recorta el JSON por si el modelo agregó texto alrededor
17    start, end = raw.find("["), raw.rfind("]") + 1
18    return json.loads(raw[start:end])

Mantenemos la temperatura alta aquí a propósito: queremos roles diversos, no obvios. El requisito de "los roles deben estar en conflicto" en el prompt es la clave, sin él el modelo da tres roles casi idénticos y todo el propósito del enjambre se pierde.

Paso 3: Los Expertos Analizan en Paralelo e Independientemente

Cada experto recibe su rol y la misma decisión. Críticamente: se ejecutan en paralelo y no ven las conclusiones de los demás. El paralelismo aquí no es solo por velocidad, garantiza independencia, un experto no puede ajustarse físicamente a la opinión de otro.

1EXPERT_SYSTEM = """Eres un experto con el rol: {name}.
2Tu enfoque: {focus}.
3Tu sesgo: {bias}. No luches contra él, es tu valor para el análisis.
4
5Analiza la decisión ESTRICTAMENTE desde tu posición. No seas equilibrado,
6no intentes considerar otros puntos de vista, otros expertos lo harán.
7Tu trabajo es llevar tu ángulo al límite.
8
9Da:
10- un veredicto desde tu posición (a favor / en contra / condicional)
11- 2-3 argumentos principales desde tu ángulo específicamente
12- 1 riesgo que sea más visible desde tu posición y que otros pasarán por alto
13Corto y directo, sin rodeos."""
14
15def run_expert(role, task):
16    system = EXPERT_SYSTEM.format(**role)
17    opinion = ask(system, f"Decisión a analizar:\n{task}", temperature=0.7)
18    return {"role": role["name"], "opinion": opinion}
19
20def run_swarm(roles, task):
21    # lanzamiento paralelo: independencia más velocidad
22    with ThreadPoolExecutor(max_workers=len(roles)) as pool:
23        futures = [pool.submit(run_expert, role, task) for role in roles]
24        return [f.result() for f in futures]

Observa el prompt del experto: le prohibimos explícitamente ser equilibrado. Esto es contraintuitivo, pero ese es el punto. Si cada experto intenta considerar todos los lados, obtienes cinco opiniones cautelosas idénticas. Al forzar a cada uno a llevar su ángulo al límite, obtienes un espectro real, que luego la fusión reconcilia.

Paso 4: La Fusión Reconcilla las Conclusiones

Ahora tenemos varias opiniones agudas y unilaterales. La fusión las reúne en un solo veredicto, pero no mediante un promedio. Busca dónde los expertos están de acuerdo (una señal fuerte), dónde se contradicen (una zona de riesgo que requiere una decisión), y qué pesa más que qué.

1MERGE_SYSTEM = """Eres el sintetizador de un enjambre analítico. Se te
2dan las opiniones de varios expertos con diferentes sesgos sobre una decisión.
3
4Tu trabajo NO es promediarlas. Tu trabajo es:
51. Acuerdo: en qué estuvieron de acuerdo los expertos a pesar de sus diferentes posiciones.
6   Esta es la señal más confiable, destácala.
72. Conflicto: dónde los expertos se contradicen directamente. No lo suavices,
8   nombra el conflicto explícitamente y di qué cuesta cada lado.
93. Puntos ciegos: un riesgo que solo un experto mencionó, pero que importa.
104. Veredicto final sobre todo: a favor / en contra / condicional, y bajo
11   qué condiciones cambia.
12
13Escribe densamente. Mantén el desacuerdo como información, no lo ocultes."""
14
15def merge_opinions(task, opinions):
16    block = "\n\n".join(
17        f"### Experto: {o['role']}\n{o['opinion']}" for o in opinions
18    )
19    user = f"Decisión:\n{task}\n\nOpiniones de los expertos:\n{block}"
20    return ask(MERGE_SYSTEM, user, temperature=0.4)   # temperatura más baja para síntesis sobria

Bajamos la temperatura en la fusión: si los expertos deben ser diversos (T alta), el sintetizador debe ser sobrio y consistente (T baja). La instrucción clave aquí es "no promedies, mantén el desacuerdo como información". Una fusión normal colapsa todo en una papilla, "por un lado, por el otro lado". Una buena fusión dice claramente: aquí todos están de acuerdo, y aquí hay un conflicto y cuesta esto.

Paso 4.5: Un Abogado del Diablo Contra el Falso Acuerdo

Hay un peligro silencioso: a veces los expertos están de acuerdo no porque la decisión sea buena, sino porque todos miran en la misma dirección por inercia. Esto es un falso acuerdo, y es más peligroso que un conflicto abierto, porque parece confianza.

Contra esto añadimos un agente especial, el abogado del diablo. Su único trabajo es atacar el consenso. Ve todas las opiniones de los expertos y está obligado a encontrar por qué podrían estar todos equivocados a la vez. Si el enjambre votó unánimemente "a favor", el abogado busca un escenario en el que sea una catástrofe.

1DEVIL_SYSTEM = """Eres el abogado del diablo en un enjambre analítico. Se te
2dan las opiniones de los expertos. Tu único trabajo: atacar su acuerdo.
3
4Si los expertos convergieron en algo, encuentra por qué podrían estar TODOS equivocados A LA
5VEZ. Busca un punto ciego compartido: una suposición que todos aceptaron sin
6verificar, un escenario que nadie consideró porque es inconveniente.
7
8No seas educado. Tu valor es que dices lo que el grupo no quiere
9escuchar. Da:
10- cuál suposición compartida de los expertos es la más peligrosa
11- un escenario en el que la opinión unánime del enjambre resulta fatalmente equivocada
12- una pregunta que el grupo evitó cuidadosamente
13Si no hay acuerdo y los expertos realmente discrepan, dilo claramente
14y señala el conflicto no resuelto más agudo."""
15
16def run_devil(task, opinions):
17    block = "\n\n".join(
18        f"### Experto: {o['role']}\n{o['opinion']}" for o in opinions
19    )
20    user = f"Decisión:\n{task}\n\nOpiniones del enjambre:\n{block}"
21    return ask(DEVIL_SYSTEM, user, temperature=0.8)

El abogado se ejecuta después de los expertos pero antes de la fusión, y su ataque va a la síntesis junto con las opiniones. El punto es que incluso un enjambre unánime tiene al menos un agente obligado a buscar una grieta. Esto es barato (una llamada) y rompe estructuralmente el pensamiento grupal: el consenso ahora tiene que sobrevivir a un ataque, no solo ocurrir.

Paso 4.6: Una Ronda de Debate para Agudizar el Conflicto

La primera pasada de expertos es independiente, y eso está bien para la diversidad. Pero después de recopilar las opiniones, puedes dar una ronda de debate: muéstrale a cada experto un resumen de las opiniones de los demás y deja que objete. Esto agudiza los conflictos, los argumentos débiles caen, los fuertes se consolidan.

1DEBATE_SYSTEM = """Eres el experto {name} en la segunda ronda de análisis.
2Tu posición original:
3{own_opinion}
4
5Ahora ves las opiniones de los otros expertos. No cedas bajo presión, pero
6tampoco ignores argumentos sólidos. Da:
7- dónde un argumento de otro realmente afecta tu posición, admítelo honestamente
8- dónde mantienes tu postura y por qué su objeción es débil
9- si cambiaste tu veredicto después del debate, y si es así, cómo
10Corto. Esto no es una repetición de la primera opinión, sino una reacción a los oponentes."""
11
12def debate_round(roles, task, opinions):
13    others_map = {}
14    for o in opinions:
15        others = "\n\n".join(
16            f"### Experto: {x['role']}\n{x['opinion']}" for x in opinions if x is not o
17        )
18        others_map[o["role"]] = others
19
20    def rebut(o):
21        system = DEBATE_SYSTEM.format(name=o["role"], own_opinion=o["opinion"])
22        user = (f"Decisión:\n{task}\n\n"
23                f"Opiniones de los oponentes:\n{others_map[o['role']]}")
24        return {"role": o["role"], "opinion": ask(system, user, temperature=0.6)}
25
26    with ThreadPoolExecutor(max_workers=len(opinions)) as pool:
27        return list(pool.map(rebut, opinions))

La ronda de debate también es en paralelo: cada experto reacciona a todos los demás a la vez, nuevamente sin conformidad en tiempo real. Después del debate, las opiniones suelen ser más agudas: puedes ver qué posiciones resistieron el fuego y cuáles colapsaron. Son estas opiniones endurecidas las que van a la fusión final.

Paso 5: Poniéndolo Todo Junto

1def analyze(task, debate=True):
2    print("El orquestador está seleccionando roles...")
3    roles = plan_roles(task)
4    for r in roles:
5        print(f"  - {r['name']}: {r['focus']}")
6
7    print(f"\nLanzando {len(roles)} expertos en paralelo...")
8    opinions = run_swarm(roles, task)
9    for o in opinions:
10        print(f"\n[{o['role']}]\n{o['opinion']}")
11
12    # ronda de debate opcional: los expertos reaccionan entre sí
13    if debate:
14        print("\nRonda de debate, los expertos se refutan entre sí...")
15        opinions = debate_round(roles, task, opinions)
16
17    # el abogado del diablo ataca el acuerdo del enjambre
18    print("\nEl abogado del diablo busca una grieta en el acuerdo...")
19    devil = run_devil(task, opinions)
20    print(f"\n[Devil's advocate]\n{devil}")
21
22    # la fusión reconcilia las conclusiones más el ataque del abogado
23    print("\nLa fusión está reconciliando las conclusiones...")
24    opinions_plus = opinions + [{"role": "Devil's advocate", "opinion": devil}]
25    verdict = merge_opinions(task, opinions_plus)
26    print(f"\n=== VEREDICTO FINAL ===\n{verdict}")
27    return verdict
28
29if __name__ == "__main__":
30    analyze(
31        "Queremos eliminar el nivel gratuito y hacer que el producto sea completamente pago "
32        "con una prueba de 14 días. ¿Deberíamos hacerlo?"
33    )

Al ejecutar esto, verás el pipeline completo: el orquestador selecciona roles, los expertos recortan la verdad desde sus ángulos, discuten entre sí en la ronda de debate, el abogado ataca su acuerdo, y la fusión entrega un veredicto sobre todo, incluido el ataque. Un solo agente sobre esta misma pregunta daría un vago "depende de tu audiencia", el enjambre da un desglose estructurado donde los conflictos son explícitos y el consenso se pone a prueba.

Qué Hace que Este Enjambre Funcione

Tres cosas separan un enjambre útil de un teatro hecho de agentes.

Los roles deben estar en conflicto, no complementarse. Si tus expertos son "un mercadólogo, un especialista en SMM, un gerente de contenido", darán respuestas casi idénticas, porque sus intereses coinciden. El valor real está cuando los intereses entran en conflicto: crecimiento vs sostenibilidad, velocidad vs calidad, dinero ahora vs confianza después. Un conflicto de intereses es lo que abre la decisión.

Los expertos no deben verse entre sí. Tan pronto como un experto ve la opinión de otro, comienza la conformidad, se ajusta. La independencia no es un detalle de implementación, es una condición de trabajo. El lanzamiento en paralelo lo da gratis.

La fusión no promedia, preserva el conflicto. Una mala síntesis convierte cinco opiniones agudas en un resumen sin dientes. Una buena síntesis deja el conflicto visible, porque el conflicto es la información más valiosa: muestra dónde la decisión es genuinamente riesgosa, no dónde todos asienten.

Dónde Extenderlo

Este esqueleto se extiende en direcciones obvias. Puedes agregar una ronda de debate: después de la primera fusión, muéstrales a los expertos el resumen y deja que objeten, lo que agudiza los conflictos. Puedes poner un juez en un modelo más fuerte sobre los expertos para sopesar los argumentos. Puedes hacer que los roles sean permanentes para un tipo de decisión recurrente, para no generarlos cada vez.

Pero el principio base permanece: diferentes lentes, análisis independiente, una síntesis que respeta el desacuerdo. Un enjambre es útil para el análisis no porque haya muchos agentes, sino porque miran de manera diferente y no se dejan caer en un denominador común. Toma una decisión que estés dando vueltas en tu cabeza solo ahora, y pásala por un enjambre así. Verás ángulos que no estabas considerando.