Status: Experimentell. Hinzugefügt in 2026.1.9. Nur WhatsApp (Webkanal).
Überblick
Broadcast-Gruppen führen mehrere Agenten für dieselbe eingehende Nachricht aus. Jeder Agent verarbeitet die Nachricht in seiner eigenen isolierten Sitzung und veröffentlicht seine eigene Antwort, sodass eine WhatsApp-Nummer ein Team spezialisierter Agenten in einem einzigen Gruppenchat oder einer DM bereitstellen kann. Broadcast-Gruppen werden nach Kanal-Zulassungslisten und Gruppenaktivierungsregeln ausgewertet. In WhatsApp-Gruppen erfolgen Broadcasts, wenn OpenClaw normalerweise antworten würde (beispielsweise bei einer Erwähnung, abhängig von Ihren Gruppeneinstellungen). Sie ändern nur, welche Agenten ausgeführt werden, niemals, ob eine Nachricht verarbeitet werden darf. Die aktive WhatsApp-QA-Lane umfasstwhatsapp-broadcast-group-fanout, wodurch überprüft wird, dass eine erwähnte Gruppennachricht unterschiedliche sichtbare Antworten von zwei konfigurierten Agenten erzeugen kann.
Konfiguration
Grundeinrichtung
Fügen Sie einenbroadcast-Abschnitt auf oberster Ebene hinzu (neben bindings). Die Schlüssel sind WhatsApp-Peer-IDs, die Werte sind Arrays von Agenten-IDs:
- Gruppenchats: Gruppen-JID (z. B.
120363403215116621@g.us) - DMs: Telefonnummer des Absenders im E.164-Format (z. B.
+15551234567)
agents.entries vorhanden sein: Die Konfigurationsvalidierung meldet unbekannte IDs, und die Laufzeit überspringt sie mit einer Broadcast agent <id> not found in agents.entries; skipping-Warnung.
Verarbeitungsstrategie
broadcast.strategy legt fest, wie Agenten die Nachricht verarbeiten:
Vollständiges Beispiel
Funktionsweise
Nachrichtenfluss
1
Eingehende Nachricht trifft ein
Eine WhatsApp-Gruppen- oder DM-Nachricht trifft ein.
2
Routing und Zulassung
OpenClaw wendet Kanal-Zulassungslisten, Gruppenaktivierungsregeln und die Eigentümerschaft konfigurierter ACP-Bindungen an.
3
Broadcast-Prüfung
Wenn keine konfigurierte ACP-Bindung für die Route zuständig ist, prüft OpenClaw, ob die Peer-ID in
broadcast enthalten ist.4
Wenn Broadcast angewendet wird
- Alle aufgeführten Agenten verarbeiten die Nachricht.
- Jeder Agent hat seinen eigenen Sitzungsschlüssel und isolierten Kontext.
- Agenten verarbeiten parallel (Standard) oder sequenziell.
- Audioanhänge werden vor der Verteilung einmal transkribiert, sodass die Agenten ein gemeinsames Transkript verwenden, anstatt separate STT-Aufrufe auszuführen.
5
Wenn Broadcast nicht angewendet wird
OpenClaw leitet an die gewöhnliche Route oder an die während des Routings ausgewählte konfigurierte ACP-Sitzungsroute weiter.
Broadcast-Gruppen umgehen weder Kanal-Zulassungslisten noch Gruppenaktivierungsregeln (Erwähnungen/Befehle/usw.). Sie ändern nur, welche Agenten ausgeführt werden, wenn eine Nachricht verarbeitet werden darf.
Sitzungsisolierung
Jeder Agent in einer Broadcast-Gruppe verwaltet vollständig getrennte:- Sitzungsschlüssel (
agent:alfred:whatsapp:group:120363...gegenüberagent:baerbel:whatsapp:group:120363...) - Konversationsverläufe (ein Agent sieht die Antworten anderer Agenten nicht)
- Arbeitsbereiche (separate Sandboxes, sofern konfiguriert)
- Werkzeugzugriffe (unterschiedliche Zulassungs-/Sperrlisten)
- Arbeitsspeicher/Kontexte (separate
IDENTITY.md,SOUL.mdusw.)
Beispiel: isolierte Sitzungen
In der Gruppe120363403215116621@g.us mit den Agenten ["alfred", "baerbel"]:
- Alfreds Kontext
- Baerbels Kontext
Anwendungsfälle
- Spezialisierte Agententeams: eine Entwicklungsgruppe, in der
code-reviewer,security-auditor,test-generatorunddocs-checkerdieselbe Nachricht jeweils aus ihrer eigenen Perspektive beantworten. - Mehrsprachiger Support: ein Support-Chat, in dem
support-en,support-deundsupport-esin ihren jeweiligen Sprachen antworten. - Qualitätssicherung:
support-agentantwortet, währendqa-agentdie Antwort prüft und nur reagiert, wenn Probleme gefunden werden. - Aufgabenautomatisierung:
task-tracker,time-loggerundreport-generatorverarbeiten alle dieselbe Statusaktualisierung.
Bewährte Vorgehensweisen
1. Agenten fokussiert halten
1. Agenten fokussiert halten
Weisen Sie jedem Agenten eine einzige, klar definierte Verantwortung zu (
formatter, linter, tester), statt einen allgemeinen „dev-helper“-Agenten zu verwenden.2. Aussagekräftige IDs und Namen verwenden
2. Aussagekräftige IDs und Namen verwenden
3. Unterschiedliche Werkzeugzugriffe konfigurieren
3. Unterschiedliche Werkzeugzugriffe konfigurieren
reviewer ist schreibgeschützt. fixer kann lesen und schreiben.4. Leistung überwachen
4. Leistung überwachen
Bevorzugen Sie bei vielen Agenten
"strategy": "parallel" (Standard), beschränken Sie Broadcast-Gruppen auf wenige Agenten und verwenden Sie schnellere Modelle für einfachere Agenten.5. Fehler bleiben isoliert
5. Fehler bleiben isoliert
Agenten schlagen unabhängig voneinander fehl. Der Fehler eines Agenten wird protokolliert (
Broadcast agent <id> failed: ...) und blockiert die anderen nicht.Kompatibilität
Provider
Broadcast-Gruppen sind derzeit nur für WhatsApp (Webkanal) implementiert. Andere Kanäle ignorieren diebroadcast-Konfiguration.
Routing
Broadcast-Gruppen funktionieren zusammen mit dem bestehenden Routing:GROUP_A: Nur Alfred antwortet (normales Routing).GROUP_B: Agent1 UND Agent2 antworten (Broadcast).
Priorität:
broadcast hat Vorrang vor gewöhnlichen Routenbindungen. Konfigurierte ACP-Bindungen (bindings[].type="acp") sind exklusiv: Wenn eine davon übereinstimmt, leitet OpenClaw an die konfigurierte ACP-Sitzung weiter, anstatt einen Broadcast an mehrere Agenten zu verteilen.Fehlerbehebung
Agenten antworten nicht
Agenten antworten nicht
Prüfen Sie Folgendes:Eine erfolgreiche Verteilung protokolliert
- Agenten-IDs sind in
agents.entriesvorhanden (die Konfigurationsvalidierung lehnt unbekannte IDs ab). - Das Peer-ID-Format ist korrekt (Gruppen-JID wie
120363403215116621@g.usoder E.164 wie+15551234567für DMs). - Die Nachricht hat die normale Zugangsprüfung bestanden (Erwähnungs-/Aktivierungsregeln gelten weiterhin).
Broadcasting message to <n> agents (<strategy>).Nur ein Agent antwortet
Nur ein Agent antwortet
Ursache: Die Peer-ID ist möglicherweise in gewöhnlichen Routenbindungen, aber nicht in
broadcast enthalten, oder sie stimmt möglicherweise mit einer exklusiven konfigurierten ACP-Bindung überein.Behebung: Fügen Sie an gewöhnliche Routen gebundene Peers zur Broadcast-Konfiguration hinzu oder entfernen/ändern Sie die konfigurierte ACP-Bindung, wenn die Broadcast-Verteilung gewünscht ist.Leistungsprobleme
Leistungsprobleme
Wenn die Verarbeitung bei vielen Agenten langsam ist: Reduzieren Sie die Anzahl der Agenten pro Gruppe, verwenden Sie weniger ressourcenintensive Modelle und prüfen Sie die Startzeit der Sandbox.
Beispiele
Beispiel 1: Code-Review-Team
Beispiel 1: Code-Review-Team
Beispiel 2: Mehrsprachige Pipeline
Beispiel 2: Mehrsprachige Pipeline
API-Referenz
Konfigurationsschema
Felder
"parallel" | "sequential"
Standard:"\"parallel\""
Legt fest, wie Agenten verarbeitet werden.
parallel führt alle Agenten gleichzeitig aus; sequential führt sie in Array-Reihenfolge aus.string[]
WhatsApp-Gruppen-JID oder Telefonnummer im E.164-Format. Der Wert ist das Array der Agenten-IDs, die alle Nachrichten dieses Peers verarbeiten sollen.
Einschränkungen
- Maximale Anzahl von Agenten: keine feste Begrenzung, aber viele Agenten (10+) können langsam sein.
- Gemeinsamer Kontext: Agenten sehen die Antworten der jeweils anderen nicht (beabsichtigtes Verhalten).
- Nachrichtenreihenfolge: Parallele Antworten können in beliebiger Reihenfolge eintreffen.
- Ratenbegrenzungen: Alle Antworten stammen von einem WhatsApp-Konto, sodass die Antwort jedes Agenten auf dieselben WhatsApp-Ratenbegrenzungen angerechnet wird.