Grupos de difusión
Estado: ExperimentalVersión: Añadido en 2026.1.9
Descripción general
Los grupos de difusión permiten que varios agentes procesen y respondan al mismo mensaje simultáneamente. Esto te permite crear equipos especializados de agentes que trabajan juntos en un solo grupo o MD de WhatsApp, todo usando un único número de teléfono. Alcance actual: solo WhatsApp (canal web). Los grupos de difusión se evalúan después de las listas de permitidos del canal y las reglas de activación del grupo. En los grupos de WhatsApp, esto significa que las difusiones ocurren cuando OpenClaw normalmente respondería (por ejemplo, al recibir una mención, según la configuración de tu grupo).Casos de uso
1. Equipos especializados de agentes
Implementa múltiples agentes con responsabilidades atómicas y centradas:2. Soporte multilingüe
3. Flujos de trabajo de aseguramiento de calidad
4. Automatización de tareas
Configuración
Configuración básica
Añade una secciónbroadcast de nivel superior (junto a bindings). Las claves son los ID de pares de WhatsApp:
- chats de grupo: JID del grupo (por ejemplo,
120363403215116621@g.us) - MD: número de teléfono en formato E.164 (por ejemplo,
+15551234567)
Estrategia de procesamiento
Controla cómo los agentes procesan los mensajes:Paralelo (predeterminado)
Todos los agentes procesan simultáneamente:Secuencial
Los agentes procesan en orden (uno espera a que termine el anterior):Ejemplo completo
Cómo funciona
Flujo de mensajes
- Llega un mensaje entrante a un grupo de WhatsApp
- Comprobación de difusión: el sistema comprueba si el ID del par está en
broadcast - Si está en la lista de difusión:
- Todos los agentes listados procesan el mensaje
- Cada agente tiene su propia clave de sesión y contexto aislado
- Los agentes procesan en paralelo (predeterminado) o secuencialmente
- Si no está en la lista de difusión:
- Se aplica el enrutamiento normal (primer
bindingcoincidente)
- Se aplica el enrutamiento normal (primer
Aislamiento de sesiones
Cada agente de un grupo de difusión mantiene completamente separados:- Claves de sesión (
agent:alfred:whatsapp:group:120363...frente aagent:baerbel:whatsapp:group:120363...) - Historial de conversación (el agente no ve los mensajes de otros agentes)
- Espacio de trabajo (sandboxes separados si están configurados)
- Acceso a herramientas (distintas listas de permitidos/denegados)
- Memoria/contexto (
IDENTITY.md,SOUL.md, etc. por separado) - Búfer de contexto del grupo (mensajes recientes del grupo usados como contexto), que se comparte por par, por lo que todos los agentes de difusión ven el mismo contexto cuando se activan
- Personalidades diferentes
- Acceso a herramientas diferente (por ejemplo, solo lectura frente a lectura-escritura)
- Modelos diferentes (por ejemplo, opus frente a sonnet)
- Skills diferentes instaladas
Ejemplo: sesiones aisladas
En el grupo120363403215116621@g.us con agentes ["alfred", "baerbel"]:
Contexto de Alfred:
Buenas prácticas
1. Mantén a los agentes centrados
Diseña cada agente con una responsabilidad única y clara:❌ Malo: Un agente genérico “dev-helper”
2. Usa nombres descriptivos
Haz que quede claro qué hace cada agente:3. Configura distinto acceso a herramientas
Da a los agentes solo las herramientas que necesitan:4. Supervisa el rendimiento
Con muchos agentes, considera lo siguiente:- Usar
"strategy": "parallel"(predeterminado) para mayor velocidad - Limitar los grupos de difusión a 5-10 agentes
- Usar modelos más rápidos para agentes más simples
5. Gestiona los fallos correctamente
Los agentes fallan de forma independiente. El error de un agente no bloquea a los demás:Compatibilidad
Proveedores
Los grupos de difusión actualmente funcionan con:- ✅ WhatsApp (implementado)
- 🚧 Telegram (planificado)
- 🚧 Discord (planificado)
- 🚧 Slack (planificado)
Enrutamiento
Los grupos de difusión funcionan junto con el enrutamiento existente:GROUP_A: solo responde alfred (enrutamiento normal)GROUP_B: responden agent1 Y agent2 (difusión)
broadcast tiene prioridad sobre bindings.
Solución de problemas
Los agentes no responden
Comprueba lo siguiente:- Los ID de agentes existen en
agents.list - El formato del ID del par es correcto (por ejemplo,
120363403215116621@g.us) - Los agentes no están en listas de denegación
Solo responde un agente
Causa: Es posible que el ID del par esté enbindings, pero no en broadcast.
Solución: Añádelo a la configuración de difusión o elimínalo de bindings.
Problemas de rendimiento
Si va lento con muchos agentes:- Reduce la cantidad de agentes por grupo
- Usa modelos más ligeros (
sonneten lugar deopus) - Comprueba el tiempo de inicio del sandbox
Ejemplos
Ejemplo 1: Equipo de revisión de código
Respuestas:
- code-formatter: “Corregí la indentación y añadí sugerencias de tipo”
- security-scanner: “⚠️ Vulnerabilidad de inyección SQL en la línea 12”
- test-coverage: “La cobertura es del 45 %, faltan pruebas para casos de error”
- docs-checker: “Falta el docstring para la función
process_data”
Ejemplo 2: Soporte multilingüe
Referencia de API
Esquema de configuración
Campos
strategy(opcional): cómo procesar agentes"parallel"(predeterminado): todos los agentes procesan simultáneamente"sequential": los agentes procesan en el orden del array
[peerId]: JID de grupo de WhatsApp, número E.164 u otro ID de par- Valor: array de ID de agentes que deben procesar mensajes
Limitaciones
- Máximo de agentes: No hay un límite estricto, pero 10 o más agentes pueden ir lentos
- Contexto compartido: Los agentes no ven las respuestas de los demás (por diseño)
- Orden de mensajes: Las respuestas en paralelo pueden llegar en cualquier orden
- Límites de frecuencia: Todos los agentes cuentan para los límites de frecuencia de WhatsApp
Mejoras futuras
Funciones planificadas:- Modo de contexto compartido (los agentes ven las respuestas de los demás)
- Coordinación entre agentes (los agentes pueden enviarse señales entre sí)
- Selección dinámica de agentes (elegir agentes según el contenido del mensaje)
- Prioridades de agentes (algunos agentes responden antes que otros)