Gruppi di broadcast
Stato: SperimentaleVersione: Aggiunto nella 2026.1.9
Panoramica
I gruppi di broadcast consentono a più agenti di elaborare e rispondere allo stesso messaggio contemporaneamente. Questo permette di creare team di agenti specializzati che lavorano insieme in un singolo gruppo WhatsApp o DM, il tutto usando un solo numero di telefono. Ambito attuale: solo WhatsApp (canale web). I gruppi di broadcast vengono valutati dopo le allowlist del canale e le regole di attivazione del gruppo. Nei gruppi WhatsApp, questo significa che i broadcast avvengono quando OpenClaw normalmente risponderebbe (per esempio: su menzione, in base alle impostazioni del gruppo).Casi d’uso
1. Team di agenti specializzati
Distribuisci più agenti con responsabilità atomiche e mirate:2. Supporto multilingue
3. Flussi di lavoro di assurance della qualità
4. Automazione delle attività
Configurazione
Configurazione di base
Aggiungi una sezionebroadcast di primo livello (accanto a bindings). Le chiavi sono peer ID di WhatsApp:
- chat di gruppo: JID del gruppo (ad es.
120363403215116621@g.us) - DM: numero di telefono E.164 (ad es.
+15551234567)
Strategia di elaborazione
Controlla il modo in cui gli agenti elaborano i messaggi:Parallela (predefinita)
Tutti gli agenti elaborano simultaneamente:Sequenziale
Gli agenti elaborano in ordine (uno attende che il precedente finisca):Esempio completo
Come funziona
Flusso dei messaggi
- Un messaggio in arrivo arriva in un gruppo WhatsApp
- Controllo broadcast: il sistema controlla se il peer ID è in
broadcast - Se è nell’elenco broadcast:
- Tutti gli agenti elencati elaborano il messaggio
- Ogni agente ha la propria chiave di sessione e un contesto isolato
- Gli agenti elaborano in parallelo (predefinito) o in sequenza
- Se non è nell’elenco broadcast:
- Si applica il routing normale (primo binding corrispondente)
Isolamento della sessione
Ogni agente in un gruppo di broadcast mantiene completamente separati:- Chiavi di sessione (
agent:alfred:whatsapp:group:120363...vsagent:baerbel:whatsapp:group:120363...) - Cronologia della conversazione (l’agente non vede i messaggi degli altri agenti)
- Workspace (sandbox separati se configurati)
- Accesso agli strumenti (diverse allowlist/denylist)
- Memoria/contesto (
IDENTITY.md,SOUL.md, ecc. separati) - Buffer del contesto del gruppo (messaggi recenti del gruppo usati per il contesto) è condiviso per peer, quindi tutti gli agenti del broadcast vedono lo stesso contesto quando vengono attivati
- Personalità diverse
- Accesso agli strumenti diverso (ad es. sola lettura vs lettura-scrittura)
- Modelli diversi (ad es. opus vs sonnet)
- Skills diverse installate
Esempio: sessioni isolate
Nel gruppo120363403215116621@g.us con agenti ["alfred", "baerbel"]:
Contesto di Alfred:
Best practice
1. Mantieni gli agenti focalizzati
Progetta ogni agente con una responsabilità unica e chiara:❌ Cattivo: un agente generico “dev-helper”
2. Usa nomi descrittivi
Rendi chiaro cosa fa ogni agente:3. Configura accessi agli strumenti diversi
Concedi agli agenti solo gli strumenti di cui hanno bisogno:4. Monitora le prestazioni
Con molti agenti, considera di:- Usare
"strategy": "parallel"(predefinito) per la velocità - Limitare i gruppi di broadcast a 5-10 agenti
- Usare modelli più rapidi per agenti più semplici
5. Gestisci i guasti con eleganza
Gli agenti falliscono in modo indipendente. L’errore di un agente non blocca gli altri:Compatibilità
Provider
I gruppi di broadcast attualmente funzionano con:- ✅ WhatsApp (implementato)
- 🚧 Telegram (pianificato)
- 🚧 Discord (pianificato)
- 🚧 Slack (pianificato)
Routing
I gruppi di broadcast funzionano insieme al routing esistente:GROUP_A: risponde solo alfred (routing normale)GROUP_B: rispondono agent1 E agent2 (broadcast)
broadcast ha priorità rispetto a bindings.
Risoluzione dei problemi
Gli agenti non rispondono
Controlla:- Gli ID degli agenti esistono in
agents.list - Il formato del peer ID è corretto (ad es.
120363403215116621@g.us) - Gli agenti non sono in denylist
Risponde un solo agente
Causa: il peer ID potrebbe essere inbindings ma non in broadcast.
Correzione: aggiungilo alla configurazione broadcast o rimuovilo da bindings.
Problemi di prestazioni
Se è lento con molti agenti:- Riduci il numero di agenti per gruppo
- Usa modelli più leggeri (sonnet invece di opus)
- Controlla il tempo di avvio del sandbox
Esempi
Esempio 1: team di code review
Risposte:
- code-formatter: “Corretta l’indentazione e aggiunti i type hint”
- security-scanner: “⚠️ Vulnerabilità SQL injection alla riga 12”
- test-coverage: “La copertura è del 45%, mancano test per i casi di errore”
- docs-checker: “Manca il docstring per la funzione
process_data”
Esempio 2: supporto multilingue
Riferimento API
Schema di configurazione
Campi
strategy(opzionale): come elaborare gli agenti"parallel"(predefinito): tutti gli agenti elaborano simultaneamente"sequential": gli agenti elaborano nell’ordine dell’array
[peerId]: JID del gruppo WhatsApp, numero E.164 o altro peer ID- Valore: array di ID agente che devono elaborare i messaggi
Limitazioni
- Numero massimo di agenti: nessun limite rigido, ma oltre 10 agenti potrebbe essere lento
- Contesto condiviso: gli agenti non vedono le risposte reciproche (per scelta progettuale)
- Ordine dei messaggi: le risposte parallele possono arrivare in qualsiasi ordine
- Rate limit: tutti gli agenti contribuiscono ai rate limit di WhatsApp
Miglioramenti futuri
Funzionalità pianificate:- Modalità contesto condiviso (gli agenti vedono le risposte reciproche)
- Coordinamento tra agenti (gli agenti possono segnalarsi a vicenda)
- Selezione dinamica degli agenti (scegliere gli agenti in base al contenuto del messaggio)
- Priorità degli agenti (alcuni agenti rispondono prima degli altri)