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

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 cualquiera de ellos por separado. 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 única visión, normalmente 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 ángulos.

Un enjambre de agentes resuelve esto estructuralmente. Creas varios expertos, cada uno con un rol y un sesgo definidos: 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 de grupo 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 los 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 el análisis se compone de 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 los roles.

Los expertos trabajan en paralelo y de forma independiente. Cada uno ve la misma decisión pero a través de su propia lente. Es crucial que no vean las conclusiones de los demás, de lo contrario se instala 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. Utilizo 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 definas los roles de antemano, deja que el modelo los elija para la tarea específica, esto hace que el enjambre sea general. Solicita JSON estricto para poder analizarlo.

1ORCHESTRATOR_SYSTEM = """Eres el orquestador de un enjambre analítico.
2Para la tarea, define de 3 a 5 roles de experto que proporcionen visiones
3MÁXIMAMENTE DIFERENTES y conflictivas sobre la decisión. Los roles deben
4entrar en conflicto en sus intereses, no complementarse.
5
6Para cada rol, proporciona: nombre, enfoque (en qué se fija), sesgo (hacia
7qué está sesgado, qué tiende a sobrevalorar).
8
9Responde SOLO con un array 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    # extrae el JSON por si el modelo añadió 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 se pierde todo el sentido del enjambre.

Paso 3: Los Expertos Analizan en Paralelo y de Forma Independiente

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 la independencia: un experto físicamente no puede ajustarse 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 tener en cuenta otros puntos de vista, otros expertos harán eso.
7Tu trabajo es llevar tu ángulo al límite.
8
9Proporciona:
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 en 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 es el objetivo principal. Si cada experto intenta tener en cuenta todos los lados, obtienes cinco opiniones cautelosas idénticas. Al obligar 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 Reconcilia las Conclusiones

Ahora tenemos varias opiniones agudas y unilaterales. La fusión las recoge en un solo veredicto, pero no promediando. 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
2proporcionan las opiniones de varios expertos con diferentes sesgos sobre
3una misma decisión.
4
5Tu trabajo NO es promediar. Tu trabajo es:
61. Acuerdo: en qué coincidieron los expertos a pesar de sus diferentes
7   posiciones. Esta es la señal más fiable, destácala.
82. Conflicto: dónde los expertos se contradicen directamente. No lo
9   suavices, nombra el conflicto explícitamente y di qué cuesta cada lado.
103. Puntos ciegos: un riesgo que solo un experto nombró, pero que importa.
114. Veredicto final considerando todo: a favor / en contra / condicional, y
12   bajo qué condiciones cambia.
13
14Escribe de forma densa. Mantén el desacuerdo como información, no lo ocultes."""
15
16def merge_opinions(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 de los expertos:\n{block}"
21    return ask(MERGE_SYSTEM, user, temperature=0.4)   # temperatura más baja para una síntesis sobria

Reducimos 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 lo convierte todo en una papilla, "por un lado, por otro lado". Una buena fusión dice claramente: aquí todos están de acuerdo, y aquí hay un conflicto que 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 el 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
2proporcionan las opiniones de los expertos. Tu único trabajo: atacar su
3acuerdo.
4
5Si los expertos convergieron en algo, encuentra por qué podrían estar TODOS
6equivocados A LA VEZ. Busca un punto ciego compartido: una suposición que
7todos aceptaron sin verificar, un escenario que nadie consideró porque es
8incómodo.
9
10No seas educado. Tu valor está en que dices lo que el grupo no quiere oír.
11Proporciona:
12- qué suposición compartida de los expertos es la más peligrosa
13- un escenario en el que la opinión unánime del enjambre resulta fatalmente
14  errónea
15- una pregunta que el grupo evitó cuidadosamente
16Si no hay acuerdo y los expertos realmente discrepan, dila claramente
17y señala el conflicto no resuelto más agudo."""
18
19def run_devil(task, opinions):
20    block = "\n\n".join(
21        f"### {o['role']}\n{o['opinion']}" for o in opinions
22    )
23    user = f"Decisión:\n{task}\n\nOpiniones del enjambre:\n{block}"
24    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 se incorpora a la síntesis junto con las opiniones. La cuestión es que incluso un enjambre unánime tiene al menos un agente obligado a buscar una grieta. Esto es barato (una sola llamada) y rompe estructuralmente el pensamiento de grupo: 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 los expertos es independiente, y eso es correcto para la diversidad. Pero después de recopilar las opiniones, puedes dar una ronda de debate: muestra a cada experto un resumen de las opiniones de los demás y deja que se oponga. Esto agudiza los conflictos, los argumentos débiles se caen y 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 los argumentos sólidos. Proporciona:
7- dónde el argumento de otro golpea genuinamente tu posición, admítelo
8  honestamente
9- dónde mantienes tu postura y por qué su objeción es débil
10- si cambiaste tu veredicto después del debate, y si es así, cómo
11Corto. Esto no es una repetición de la primera opinión, sino una reacción
12a los oponentes."""
13
14def debate_round(roles, task, opinions):
15    others_map = {}
16    for o in opinions:
17        others = "\n\n".join(
18            f"### {x['role']}\n{x['opinion']}" for x in opinions if x is not o
19        )
20        others_map[o["role"]] = others
21
22    def rebut(o):
23        system = DEBATE_SYSTEM.format(name=o["role"], own_opinion=o["opinion"])
24        user = (f"Decisión:\n{task}\n\n"
25                f"Opiniones de los oponentes:\n{others_map[o['role']]}")
26        return {"role": o["role"], "opinion": ask(system, user, temperature=0.6)}
27
28    with ThreadPoolExecutor(max_workers=len(opinions)) as pool:
29        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, de nuevo sin conformidad en tiempo real. Después del debate, las opiniones suelen ser más agudas: puedes ver qué posiciones se mantuvieron bajo presión y cuáles se derrumbaron. Son estas opiniones endurecidas las que van a la fusión final.

Paso 5: Juntándolo Todo

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 se refutan entre sí
13    if debate:
14        print("\nRonda de debate, los expertos se refutan mutuamente...")
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[Abogado del diablo]\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": "Abogado del diablo", "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 "
32        "completamente de pago con una prueba de 14 días. ¿Deberíamos hacerlo?"
33    )

Al ejecutar esto, verás el pipeline completo: el orquestador selecciona los roles, los expertos cortan 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 que lo abarca todo, incluido el ataque. Un solo agente sobre esta misma pregunta daría un vago "depende de tu audiencia", el enjambre proporciona un desglose estructurado donde los conflictos son explícitos y el consenso está sometido a prueba de estrés.

Qué Hace que Este Enjambre Funcione

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

Los roles deben estar en conflicto, no complementarse. Si tus expertos son "un comercial, un especialista en SMM, un gestor de contenidos", darán respuestas casi idénticas, porque sus intereses coinciden. El valor real está cuando los intereses chocan: 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í. En cuanto 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 la proporciona de forma gratuita.

La fusión no promedia, preserva el conflicto. Una mala síntesis convierte cinco opiniones agudas en un resumen insípido. 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 arriesgada, no dónde todos asienten.

Dónde Ampliar

Este esqueleto se extiende en direcciones obvias. Puedes añadir una ronda de debate: después de la primera fusión, muestra a los expertos el resumen y deja que se opongan, lo que agudiza los conflictos. Puedes poner un juez en un modelo más potente que 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 se mantiene: lentes diferentes, 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 forma diferente y no se dejan arrastrar a un denominador común. Toma una decisión que estés dando vueltas en tu cabeza ahora mismo y pásala por un enjambre como este. Verás ángulos que no estabas considerando.