Patrones de orquestación multiagente con OpenClaw

Un único agente de IA puede automatizar un proceso. Un sistema de agentes bien orquestado puede automatizar una función empresarial. La diferencia radica en cómo los agentes coordinan, se comunican y manejan las fallas a través de fronteras. La orquestación multiagente es la disciplina de ingeniería que marca la diferencia entre un conjunto de robots independientes y un sistema autónomo coherente y confiable.

OpenClaw proporciona las primitivas para la orquestación de múltiples agentes: un bus de mensajes escritos, un registro de agentes, protocolos de transferencia, espacios de nombres de memoria compartida y seguimiento distribuido que sigue las solicitudes a través de los límites de los agentes. Esta guía cubre los cuatro patrones de orquestación fundamentales, cuándo usar cada uno, cómo implementarlos en OpenClaw y los modos de falla contra los cuales diseñar.

Conclusiones clave

• El patrón Supervisor-Trabajador es la arquitectura más común: un agente orquestador descompone los objetivos y los delega en trabajadores especializados.
• El patrón Pipeline es mejor para el procesamiento secuencial de documentos o la transformación de datos de varios pasos donde cada etapa produce información para la siguiente.
• El patrón de consenso permite que varios agentes independientes evalúen la misma pregunta, lo que reduce el riesgo de errores de un solo agente en decisiones de alto riesgo.
• El patrón Market-Maker asigna tareas dinámicamente al agente disponible más capaz, lo que permite el equilibrio de carga y la degradación elegante.
• La comunicación entre agentes utiliza el bus de mensajes escrito de OpenClaw: sin paso de cadenas sin formato, sin estados mutables compartidos entre agentes.
• El seguimiento distribuido es esencial para la depuración de múltiples agentes: cada mensaje lleva una identificación de correlación que abarca los límites de los agentes.
• Los disyuntores en el límite del agente evitan fallas en cascada cuando un agente del sistema deja de estar disponible.
• ECOSIRE diseña e implementa arquitecturas multiagente para flujos de trabajo complejos de automatización empresarial.

---

La Fundación: Modelo de comunicación con agentes de OpenClaw

Antes de cubrir los patrones, es importante comprender cómo se comunican los agentes de OpenClaw. Hay tres mecanismos, cada uno con diferentes compensaciones:

El Bus de mensajes es el canal de comunicación principal entre agentes en el mismo sistema. Los agentes publican mensajes escritos en canales nombrados; otros agentes se suscriben a esos canales. El agente de bus persiste los mensajes (Redis Streams o Kafka, configurable), por lo que los mensajes no se pierden si el agente receptor no está disponible temporalmente.

Invocación directa permite a un agente llamar directamente a las habilidades expuestas de otro agente y esperar una respuesta. Esto es sincrónico desde la perspectiva de la persona que llama y adecuado para flujos de trabajo de baja latencia donde el agente que llama no puede continuar hasta tener el resultado. Úselo con moderación: crea un estrecho acoplamiento entre los agentes.

Espacios de nombres de memoria compartida permiten a los agentes dentro del mismo sistema leer y escribir en una región compartida del almacén de memoria. Esto es apropiado para pasar objetos de contexto grandes (un documento que se procesa, un perfil de cliente que se enriquece en varias etapas) sin serializarlos a través de cargas útiles de mensajes.

// Publishing a message
await messageBus.publish("document.classified", {
  documentId: "DOC-4521",
  type: "vendor-invoice",
  confidence: 0.94,
  storageKey: "incoming/doc-4521.pdf",
});

// Subscribing to messages
messageBus.subscribe("document.classified", async (message) => {
  await extractionAgent.handle(message);
});

Todos los mensajes incluyen un ID de correlación, una marca de tiempo, un ID del agente de origen y una versión del esquema. La versión del esquema permite que el bus de mensajes valide los mensajes con su contrato declarado y rechace los mensajes con formato incorrecto antes de que lleguen al agente receptor.

---

Patrón 1: Supervisor-Trabajador

El patrón Supervisor-Trabajador es la arquitectura multiagente más aplicable. Un agente supervisor recibe el objetivo de nivel superior, lo descompone en subtareas, asigna cada subtarea a un agente trabajador especializado, monitorea el progreso y sintetiza los resultados.

User/System Goal
      ↓
[ Supervisor Agent ]
  ├─ task 1 → [ Worker Agent A ]
  ├─ task 2 → [ Worker Agent B ]
  └─ task 3 → [ Worker Agent C ]
      ↓
[ Supervisor Agent ] ← results from all workers
      ↓
Synthesized Response

Cuándo usarlo: cuando un objetivo complejo requiere experiencia heterogénea. El supervisor maneja la lógica de coordinación; Los trabajadores son especialistas en un dominio que hacen bien una cosa.

Implementación de OpenClaw:

export const SupervisorAgent = defineAgent({
  name: "due-diligence-supervisor",
  skills: ["decompose-goal", "assign-workers", "synthesize-results"],
  async run({ goal, workerRegistry, messageBus }) {
    // Decompose goal into tasks
    const tasks = await decomposeGoal(goal);

    // Assign to appropriate workers
    const assignments = tasks.map((task) => ({
      task,
      worker: workerRegistry.findBestMatch(task.type),
    }));

    // Publish tasks and wait for results
    const results = await Promise.allSettled(
      assignments.map(({ task, worker }) =>
        messageBus.requestReply(`worker.${worker.id}.tasks`, task, { timeoutMs: 60_000 })
      )
    );

    // Synthesize
    const successfulResults = results
      .filter((r) => r.status === "fulfilled")
      .map((r) => r.value);

    return synthesize(goal, successfulResults);
  },
});

Decisiones clave de diseño:

• El supervisor no debe contener lógica de dominio; sólo debe coordinar.
• Los trabajadores deben ser apátridas y escalables de forma independiente.
• Las tareas fallidas del trabajador son reintentadas por el supervisor, no por el trabajador internamente.
• Los tiempos de espera de las tareas a nivel de supervisor evitan que un trabajador lento bloquee todo el flujo de trabajo.

Ejemplo del mundo real: un sistema de automatización de debida diligencia en el que el supervisor descompone una revisión de la empresa en tareas paralelas asignadas a un trabajador de análisis financiero, un trabajador de revisión de documentos legales, un trabajador de investigación de mercado y un trabajador de verificación de referencias. El supervisor combina todos los hallazgos en un informe de diligencia debida unificado.

---

Patrón 2: Tubería

El patrón Pipeline secuencia a los agentes de modo que la salida de cada agente se convierta en la entrada del siguiente agente. Es ideal para el procesamiento de documentos, el enriquecimiento de datos y cualquier flujo de trabajo en el que cada paso transforme o enriquezca la carga útil en un orden definido.

Input Document
    ↓
[ Stage 1: Ingestion Agent ]
    ↓
[ Stage 2: Classification Agent ]
    ↓
[ Stage 3: Extraction Agent ]
    ↓
[ Stage 4: Validation Agent ]
    ↓
[ Stage 5: Integration Agent ]
    ↓
Output: ERP Record

Cuándo usarlo: flujos de trabajo secuenciales con límites de etapa claros y transformación en cada paso. Excelente para el procesamiento de documentos de alto rendimiento.

Implementación de OpenClaw:

La primitiva Pipeline de OpenClaw administra la cadena de etapas, maneja fallas y admite bifurcaciones en cualquier etapa según el contenido de la carga útil.

import { definePipeline } from "@openclaw/orchestration";

export const InvoicePipeline = definePipeline({
  name: "invoice-processing",
  stages: [
    { agent: "document-ingester", timeout: 30_000 },
    {
      agent: "document-classifier",
      timeout: 15_000,
      branch: {
        "vendor-invoice": "invoice-extractor",
        "credit-memo": "credit-memo-extractor",
        "unknown": "human-review-queue", // Branch to exception handling
      },
    },
    { agent: "invoice-validator", timeout: 20_000 },
    { agent: "invoice-enricher", timeout: 10_000 },
    { agent: "erp-integrator", timeout: 30_000, retries: 3 },
  ],
  onFailure: {
    agent: "exception-handler",
    preservePartialState: true,
  },
});

Decisiones clave de diseño:

• Cada etapa debe ser idempotente: si se ejecuta dos veces con la misma entrada, produce la misma salida.
• El controlador onFailure recibe el estado de canalización parcial para que pueda reanudarse desde la última etapa exitosa en lugar de comenzar de nuevo.
• La ramificación permite que diferentes tipos de documentos sigan diferentes subcanales después de la clasificación.
• Utilice el espacio de nombres de memoria compartida para pasar cargas útiles grandes (búferes de documentos) entre etapas en lugar de serializarlas a través del bus de mensajes.

Manejo de fallas: cuando la etapa N falla después de M etapas exitosas, el estado de la canalización se controla en la etapa M. Una vez resuelta la falla (corrección manual, reintento después de que se recupere la dependencia), la canalización se reanuda desde la etapa M+1 con la misma carga útil.

---

Patrón 3: Consenso

El patrón de consenso ejecuta múltiples agentes independientes contra la misma entrada y les exige que estén de acuerdo (dentro de un umbral) antes de que el sistema actúe. Es el equivalente de una segunda opinión con múltiples agentes y es más valioso en decisiones de alto riesgo donde un error de un solo agente sería costoso.

Input
  ├─ → [ Evaluator Agent A ] → assessment A
  ├─ → [ Evaluator Agent B ] → assessment B
  └─ → [ Evaluator Agent C ] → assessment C
          ↓
  [ Consensus Resolver ]
    ├── unanimous or majority? → act
    └── no consensus? → escalate to human

Cuándo usarlo: decisiones de alto riesgo (aprobaciones de préstamos, detección de fraude, análisis de registros médicos, revisión de cláusulas contractuales), entradas contradictorias en las que un solo agente podría ser manipulado o situaciones en las que diferentes modelos tienen fortalezas complementarias.

Implementación de OpenClaw:

export const FraudConsensusCheck = defineAgent({
  name: "fraud-consensus",
  async run({ transaction, evaluators }) {
    // Run all evaluators in parallel
    const assessments = await Promise.all(
      evaluators.map((evaluator) =>
        evaluator.assess(transaction)
      )
    );

    const fraudVotes = assessments.filter((a) => a.isFraud).length;
    const totalVotes = assessments.length;
    const agreementRatio = fraudVotes / totalVotes;

    if (agreementRatio >= 0.67) { // Supermajority fraud detection
      return { decision: "block", confidence: agreementRatio, assessments };
    } else if (agreementRatio === 0) { // Unanimous clear
      return { decision: "allow", confidence: 1 - agreementRatio, assessments };
    } else {
      // Disagreement — escalate with all assessments for human review
      return { decision: "escalate", confidence: null, assessments };
    }
  },
});

Decisiones clave de diseño:

• Los agentes evaluadores deben utilizar diferentes modelos o diferentes estrategias de incitación para minimizar los fallos correlacionados. Dos agentes que utilizan el mismo modelo con el mismo mensaje normalmente estarán de acuerdo, lo que frustra el propósito.
• El umbral de consenso es configurable. El acuerdo unánime es apropiado para acciones irreversibles; La mayoría simple es suficiente para decisiones reversibles.
• Las rutas de escalamiento necesitan planificación de capacidad: si su tasa de escalamiento es alta, es necesario ajustar los criterios del evaluador.

---

Patrón 4: Creador de mercado

El patrón Market-Maker mantiene un grupo de agentes trabajadores y asigna tareas dinámicamente al trabajador disponible más apropiado en el momento en que llega la tarea. Los trabajadores registran sus capacidades y carga actual; El creador de mercado encamina cada tarea hacia la mejor opción.

Task Queue
    ↓
[ Market-Maker Agent ]
    ├── Worker A: [language-translation] load: 30%
    ├── Worker B: [language-translation] load: 80%
    └── Worker C: [language-translation] load: 10%  ← assigned

Cuándo usarlo: sistemas de alto rendimiento donde el volumen de tareas varía significativamente. Permite el escalamiento horizontal de agentes trabajadores sin cambiar la lógica de enrutamiento. También permite una degradación elegante: si un trabajador especializado no está disponible, el creador de mercado puede dirigirse a un trabajador generalista con menor rendimiento en lugar de fallar en la tarea.

export const TranslationMarketMaker = defineAgent({
  name: "translation-market-maker",
  tools: ["worker-registry", "task-queue"],
  async run({ tools }) {
    while (true) {
      const task = await tools.taskQueue.dequeue("translation.pending");
      if (!task) { await sleep(100); continue; }

      const workers = await tools.workerRegistry.getAvailable({
        capability: "language-translation",
        targetLanguage: task.targetLanguage,
      });

      if (workers.length === 0) {
        // No specialist available — try generalist
        const generalists = await tools.workerRegistry.getAvailable({ capability: "general-translation" });
        if (generalists.length === 0) {
          await tools.taskQueue.requeueWithDelay(task, { delayMs: 5000 });
          continue;
        }
        workers.push(...generalists);
      }

      // Select worker with lowest load
      const selected = workers.sort((a, b) => a.currentLoad - b.currentLoad)[0];
      await selected.dispatch(task);
    }
  },
});

Decisiones clave de diseño:

• Los informes de carga de trabajadores deben ser precisos y de baja latencia. Los datos de carga obsoletos provocan una distribución desigual.
• La cadena alternativa (especialista → generalista → cola con retraso) evita la pérdida de tareas durante la escasez de capacidad.
• Los trabajadores se registran automáticamente al iniciar y se dan de baja cuando se cierra correctamente. El sondeo de control de estado elimina automáticamente a los trabajadores accidentados.

---

Patrón cruzado: seguimiento distribuido

Independientemente del patrón de orquestación que utilice, el seguimiento distribuido no es negociable para los sistemas multiagente de producción. Cada mensaje lleva un correlationId y un spanId. Cuando un agente crea una tarea secundaria (en el patrón Supervisor) o pasa el trabajo a la siguiente etapa (en el patrón Pipeline), crea un nuevo intervalo como hijo del intervalo actual.

// Middleware that injects tracing into all agent message handlers
agent.useHook("preRun", (ctx) => {
  ctx.span = tracer.startSpan(ctx.skill, { childOf: ctx.message.parentSpan });
  ctx.span.setTag("agent.id", ctx.agentId);
  ctx.span.setTag("correlation.id", ctx.message.correlationId);
});

agent.useHook("postRun", (ctx) => {
  ctx.span.finish();
});

Con el seguimiento distribuido, puede visualizar el árbol de ejecución completo de cualquier tarea en todos los límites de los agentes, lo que resulta invaluable para depurar problemas de latencia y comportamientos inesperados.

---

Antipatrones a evitar

Estado mutable compartido: varios agentes que escriben en el mismo registro del almacén de datos sin coordinación provocan la pérdida de actualizaciones y condiciones de carrera. Utilice el bus de mensajes para la coordinación; Los agentes son dueños de su propio Estado.

Cadenas sincrónicas de más de tres agentes: si el agente A llama a B, que llama a C, que llama a D sincrónicamente, la latencia se agrava y el radio de explosión de falla es grande. Divida largas cadenas sincrónicas en etapas de canalización asincrónicas con puntos de control.

Agentes supervisores con lógica de dominio: los supervisores deben orquestar, no ejecutar, el trabajo del dominio. Cuando un supervisor comienza a contener lógica de extracción o reglas de validación, se convierte en un monolito disfrazado.

Contratos implícitos entre agentes: los esquemas de mensajes deben versionarse y validarse a nivel de bus. Los agentes que asumen la estructura del mensaje en lugar de validarla fallan silenciosamente cuando el remitente cambia su formato de salida.

---

Preguntas frecuentes

¿Cómo se manejan las fallas parciales en un sistema supervisor-trabajador donde algunos trabajadores tienen éxito y otros fracasan?

El Supervisor recibe los resultados de todas las tareas de los trabajadores como una mezcla de éxitos y fracasos. La habilidad de síntesis decide cómo manejar los resultados parciales en función del objetivo: para algunos objetivos, los resultados parciales son suficientes para producir un resultado útil; para otros, todos los resultados son obligatorios. Configure el Supervisor con un umbral de éxito mínimo: si menos de esa proporción de trabajadores tienen éxito, incremente en lugar de producir un resultado parcial potencialmente engañoso.

¿Puede el mismo agente participar en múltiples patrones de orquestación simultáneamente?

Sí. Un agente es solo un servicio: puede ser un trabajador en un sistema supervisor-trabajador y al mismo tiempo ser una etapa en un proceso y participar como evaluador en una verificación de consenso. Cada invocación es independiente. El requisito crítico es que los agentes no tengan estado entre invocaciones (los datos con estado van a los almacenes de memoria, no a las variables de instancia del agente), de modo que múltiples invocaciones simultáneas no interfieran.

¿Cuál es la sobrecarga del bus de mensajes para sistemas de alto rendimiento?

Con Redis Streams como backend del bus de mensajes, la latencia de publicación/suscripción de mensajes suele ser inferior a 2 ms para mensajes de menos de 64 KB. Para canales de alto rendimiento que procesan miles de documentos por minuto, esto es insignificante en comparación con el trabajo de procesamiento en cada etapa. Para sistemas de rendimiento extremadamente alto (millones de mensajes por día), Kafka proporciona un rendimiento sostenido más alto a costa de una mayor complejidad operativa.

¿Cómo se versionan los sistemas multiagente cuando los agentes individuales evolucionan?

Agentes de versiones que utilizan de forma independiente el control de versiones semántico en sus manifiestos. El bus de mensajes valida los mensajes con respecto a su versión de esquema declarada. Cuando un agente cambia su esquema de salida (cambio importante), cambia la versión principal y el bus enruta los mensajes del esquema antiguo a la versión anterior. Ambas versiones se ejecutan simultáneamente durante la ventana de migración. La configuración de Supervisor o Pipeline especifica qué versión de cada trabajador requiere, lo que le brinda control total sobre el tiempo de implementación.

¿Cómo maneja el patrón Market-Maker el orden de tareas cuando las tareas tienen dependencias?

El Market-Maker es apropiado para tareas independientes: tareas que pueden ejecutarse en cualquier orden. Para tareas con dependencias, utilice el patrón Pipeline o Supervisor, que impone el orden de forma explícita. Si tiene una combinación de tareas independientes y dependientes, el patrón Supervisor funciona bien: el Supervisor envía tareas independientes al grupo de creadores de mercado y gestiona los pedidos de dependencia para el resto.

---

Próximos pasos

La orquestación de múltiples agentes desbloquea la complejidad de la automatización que los agentes individuales no pueden manejar. Los patrones de esta guía (Supervisor-Trabajador, Canalización, Consenso y Creador de mercado) cubren la gran mayoría de los casos de uso de automatización empresarial. La clave es elegir el patrón correcto para la estructura de comunicación del problema, no forzar cada problema a una sola arquitectura.

El [servicio de orquestación multiagente OpenClaw] (/services/openclaw/multi-agent-orchestration) de ECOSIRE proporciona diseño de arquitectura, implementación y optimización continua para sistemas complejos multiagente. Nuestro equipo ha diseñado arquitecturas de orquestación para sistemas de procesamiento de documentos que manejan millones de documentos mensualmente, canales de análisis financiero que funcionan las 24 horas del día, los 7 días de la semana y sistemas de automatización de recursos humanos que se coordinan entre una docena de agentes especializados.

Comuníquese con ECOSIRE para analizar sus requisitos de arquitectura multiagente.