Broadcast-Gruppen
Status: ExperimentellVersion: Hinzugefügt in 2026.1.9
Überblick
Broadcast-Gruppen ermöglichen es mehreren Agents, dieselbe Nachricht gleichzeitig zu verarbeiten und darauf zu antworten. So können Sie spezialisierte Agent-Teams erstellen, die in einer einzigen WhatsApp-Gruppe oder DM zusammenarbeiten — und dabei alle dieselbe Telefonnummer verwenden. Aktueller Umfang: nur WhatsApp (Web-Kanal). Broadcast-Gruppen werden nach Channel-Allowlisten und Gruppenaktivierungsregeln ausgewertet. In WhatsApp-Gruppen bedeutet das, dass Broadcasts dann stattfinden, wenn OpenClaw normalerweise antworten würde (zum Beispiel bei Erwähnung, abhängig von Ihren Gruppeneinstellungen).Anwendungsfälle
1. Spezialisierte Agent-Teams
Stellen Sie mehrere Agents mit atomaren, klar abgegrenzten Aufgaben bereit:2. Mehrsprachige Unterstützung
3. Qualitätssicherungs-Workflows
4. Aufgabenautomatisierung
Konfiguration
Grundlegende Einrichtung
Fügen Sie einenbroadcast-Abschnitt auf oberster Ebene hinzu (neben bindings). Die Schlüssel sind WhatsApp-Peer-IDs:
- Gruppenchats: Gruppen-JID (z. B.
120363403215116621@g.us) - DMs: E.164-Telefonnummer (z. B.
+15551234567)
Verarbeitungsstrategie
Steuern Sie, wie Agents Nachrichten verarbeiten:Parallel (Standard)
Alle Agents verarbeiten gleichzeitig:Sequenziell
Agents verarbeiten der Reihe nach (einer wartet, bis der vorherige fertig ist):Vollständiges Beispiel
So funktioniert es
Nachrichtenfluss
- Eingehende Nachricht trifft in einer WhatsApp-Gruppe ein
- Broadcast-Prüfung: Das System prüft, ob die Peer-ID in
broadcastenthalten ist - Wenn in der Broadcast-Liste:
- Alle aufgeführten Agents verarbeiten die Nachricht
- Jeder Agent hat seinen eigenen Sitzungsschlüssel und isolierten Kontext
- Agents verarbeiten parallel (Standard) oder sequenziell
- Wenn nicht in der Broadcast-Liste:
- Normales Routing wird angewendet (erste passende Bindung)
Sitzungsisolierung
Jeder Agent in einer Broadcast-Gruppe verwaltet vollständig getrennte:- Sitzungsschlüssel (
agent:alfred:whatsapp:group:120363...vsagent:baerbel:whatsapp:group:120363...) - Konversationsverlauf (der Agent sieht die Nachrichten anderer Agents nicht)
- Workspace (separate Sandboxes, falls konfiguriert)
- Tool-Zugriff (unterschiedliche Allow-/Deny-Listen)
- Speicher/Kontext (separate IDENTITY.md, SOUL.md usw.)
- Gruppenkontextpuffer (aktuelle Gruppennachrichten, die als Kontext verwendet werden) wird pro Peer gemeinsam genutzt, sodass alle Broadcast-Agents beim Auslösen denselben Kontext sehen
- Unterschiedliche Persönlichkeiten
- Unterschiedlichen Tool-Zugriff (z. B. schreibgeschützt vs. Lese-/Schreibzugriff)
- Unterschiedliche Modelle (z. B. opus vs. sonnet)
- Unterschiedliche installierte Skills
Beispiel: Isolierte Sitzungen
In Gruppe120363403215116621@g.us mit Agents ["alfred", "baerbel"]:
Alfreds Kontext:
Best Practices
1. Agents fokussiert halten
Entwerfen Sie jeden Agent mit einer einzelnen, klaren Aufgabe:❌ Schlecht: Ein allgemeiner „dev-helper“-Agent
2. Beschreibende Namen verwenden
Machen Sie klar, was jeder Agent tut:3. Unterschiedlichen Tool-Zugriff konfigurieren
Geben Sie Agents nur die Tools, die sie benötigen:4. Leistung überwachen
Bei vielen Agents sollten Sie Folgendes beachten:"strategy": "parallel"(Standard) für Geschwindigkeit verwenden- Broadcast-Gruppen auf 5–10 Agents begrenzen
- Schnellere Modelle für einfachere Agents verwenden
5. Fehler robust behandeln
Agents schlagen unabhängig voneinander fehl. Der Fehler eines Agents blockiert die anderen nicht:Kompatibilität
Provider
Broadcast-Gruppen funktionieren derzeit mit:- ✅ WhatsApp (implementiert)
- 🚧 Telegram (geplant)
- 🚧 Discord (geplant)
- 🚧 Slack (geplant)
Routing
Broadcast-Gruppen funktionieren zusammen mit bestehendem Routing:GROUP_A: Nur alfred antwortet (normales Routing)GROUP_B: agent1 UND agent2 antworten (Broadcast)
broadcast hat Vorrang vor bindings.
Fehlerbehebung
Agents antworten nicht
Prüfen Sie:- Agent-IDs existieren in
agents.list - Das Peer-ID-Format ist korrekt (z. B.
120363403215116621@g.us) - Agents sind nicht in Deny-Listen enthalten
Nur ein Agent antwortet
Ursache: Die Peer-ID befindet sich möglicherweise inbindings, aber nicht in broadcast.
Behebung: Zur Broadcast-Konfiguration hinzufügen oder aus bindings entfernen.
Leistungsprobleme
Wenn es mit vielen Agents langsam ist:- Anzahl der Agents pro Gruppe reduzieren
- Leichtere Modelle verwenden (sonnet statt opus)
- Startzeit der Sandbox prüfen
Beispiele
Beispiel 1: Code-Review-Team
Antworten:
- code-formatter: „Einrückung korrigiert und Typhinweise hinzugefügt“
- security-scanner: „⚠️ SQL-Injection-Schwachstelle in Zeile 12“
- test-coverage: „Abdeckung liegt bei 45 %, fehlende Tests für Fehlerfälle“
- docs-checker: „Fehlender Docstring für Funktion
process_data“
Beispiel 2: Mehrsprachige Unterstützung
API-Referenz
Konfigurationsschema
Felder
strategy(optional): Wie Agents verarbeitet werden"parallel"(Standard): Alle Agents verarbeiten gleichzeitig"sequential": Agents verarbeiten in der Reihenfolge des Arrays
[peerId]: WhatsApp-Gruppen-JID, E.164-Nummer oder andere Peer-ID- Wert: Array von Agent-IDs, die Nachrichten verarbeiten sollen
Einschränkungen
- Max. Agents: Keine harte Obergrenze, aber 10+ Agents können langsam sein
- Gemeinsamer Kontext: Agents sehen die Antworten der anderen nicht (absichtlich so)
- Nachrichtenreihenfolge: Parallele Antworten können in beliebiger Reihenfolge eintreffen
- Rate Limits: Alle Agents zählen zu den WhatsApp-Rate-Limits
Zukünftige Erweiterungen
Geplante Funktionen:- Modus für gemeinsamen Kontext (Agents sehen die Antworten der anderen)
- Agent-Koordination (Agents können sich gegenseitig Signale senden)
- Dynamische Agent-Auswahl (Agents basierend auf dem Nachrichteninhalt auswählen)
- Agent-Prioritäten (einige Agents antworten vor anderen)