Skip to main content

Broadcast-grupper

Status: Experimentell
Version: Tillagd i 2026.1.9

Översikt

Sändningsgrupper gör det möjligt för flera agenter att bearbeta och svara på samma meddelande samtidigt. Detta gör att du kan skapa specialiserade agentgrupper som arbetar tillsammans i en enda WhatsApp grupp eller DM — alla med ett telefonnummer. Nuvarande omfattning: endast WhatsApp (webbkanal). Sändningsgrupper utvärderas efter kanaltillåtna listor och gruppaktiveringsregler. I WhatsApp-grupper innebär detta att sändningar sker när OpenClaw normalt skulle svara (till exempel: omnämnande, beroende på dina gruppinställningar).

Användningsfall

1. Specialiserade agentteam

Driftsätt flera agenter med atomära, fokuserade ansvarsområden:
Varje agent bearbetar samma meddelande och bidrar med sitt specialiserade perspektiv.

2. Stöd för flera språk

3. Arbetsflöden för kvalitetssäkring

4. Automatiserad Uppgift

Konfiguration

Grundläggande konfigurering

Lägg till en toppnivå broadcast-sektion (bredvid bindings). Nycklar är WhatsApp kamrat-ids:
  • grupp chattar: grupp JID (t.ex. [email protected])
  • DMs: E.164 telefonnummer (t.ex. +15551234567)
Resultat: När OpenClaw skulle svara i denna chatt körs alla tre agenterna.

Bearbetningsstrategi

Styr hur agenter bearbetar meddelanden:

Parallellt (standard)

Alla agenter bearbetar samtidigt:

Sekventiellt

Agenter bearbetar i ordning (en väntar tills föregående är klar):

Fullständigt exempel

Hur det fungerar

Meddelandeflöde

  1. Inkommande meddelande anländer i en WhatsApp-grupp
  2. Broadcast-kontroll: Systemet kontrollerar om peer-ID finns i broadcast
  3. Om i broadcast-listan:
    • Alla listade agenter bearbetar meddelandet
    • Varje agent har sin egen sessionsnyckel och isolerad kontext
    • Agenter bearbetar parallellt (standard) eller sekventiellt
  4. Om inte i broadcast-listan:
    • Normal routning gäller (första matchande bindning)
Obs: sändningsgrupper förbigår inte kanaltillåtna listor eller gruppaktiveringsregler (omnämnande/kommandon/etc). De ändrar bara _vilka agenter som kör _ när ett meddelande är berättigat till behandling.

Sessionsisolering

Varje agent i en broadcast-grupp upprätthåller helt separata:
  • Sessionsnycklar (agent:alfred:whatsapp:group:120363... vs agent:baerbel:whatsapp:group:120363...)
  • Konversationshistorik (agenten ser inte andra agenters meddelanden)
  • Arbetsyta (separata sandboxar om konfigurerat)
  • Verktygsåtkomst (olika tillåt-/nekalistor)
  • Minne/kontext (separata IDENTITY.md, SOUL.md, etc.)
  • Gruppkontextbuffert (senaste gruppmeddelanden som används som kontext) delas per peer, så alla broadcast-agenter ser samma kontext när de triggas
Detta gör att varje agent kan ha:
  • Olika personligheter
  • Olika verktygsåtkomst (t.ex. skrivskyddad vs. läs–skriv)
  • Olika modeller (t.ex. opus vs. sonnet)
  • Olika Skills installerade

Exempel: Isolerade sessioner

I grupp [email protected] med agenterna ["alfred", "baerbel"]: Alfreds kontext:
Bärbels kontext:

Bästa praxis

1. Håll agenter fokuserade

Designa varje agent med ett enda, tydligt ansvar:
Bra: Varje agent har ett jobb
Dåligt: En generisk ”dev-helper”-agent

2. Använd beskrivande namn

Gör det tydligt vad varje agent gör:

3. Konfigurera olika verktyg tillgång

Ge agenter bara de verktyg de behöver:

4. Övervaka prestanda

Med många agenter, överväg:
  • Att använda "strategy": "parallel" (standard) för hastighet
  • Att begränsa broadcast-grupper till 5–10 agenter
  • Att använda snabbare modeller för enklare agenter

5. Hantera misslyckanden Gracfully

Agenter misslyckas självständigt. Ett agentfel blockerar inte andra:

Kompatibilitet

Leverantörer

Broadcast-grupper fungerar för närvarande med:
  • ✅ WhatsApp (implementerat)
  • 🚧 Telegram (planerat)
  • 🚧 Discord (planerat)
  • 🚧 Slack (planerat)

Routning

Broadcast-grupper fungerar sida vid sida med befintlig routning:
  • GROUP_A: Endast alfred svarar (normal routning)
  • GROUP_B: agent1 OCH agent2 svarar (broadcast)
Företräde: broadcast har prioritet över bindings.

Felsökning

Agenter svarar inte

Kontrollera:
  1. Agent-ID:n finns i agents.list
  2. Det andra ID-formatet är korrekt (t.ex., ‘[email protected]’)
  3. Agenterna finns inte i nekalistor
Debugga:

Endast en agent svarar

Orsak: Peer-ID kan finnas i bindings men inte i broadcast. Åtgärd: Lägg till i broadcast-konfigen eller ta bort från bindningar.

Prestandaproblem

Om det är långsamt med många agenter:
  • Minska antalet agenter per grupp
  • Använd lättare modeller (sonnet i stället för opus)
  • Kontrollera starttiden för sandbox

Exempel

Exempel 1: Team för kodgranskning

Användaren skickar: Kodsnutt
Svar:
  • code-formatter: ”Fixade indrag och lade till typanvisningar”
  • security-scanner: ”⚠️ SQL-injektionssårbarhet på rad 12”
  • test-coverage: ”Täckningen är 45 %, saknar tester för felhanteringsfall”
  • docs-checker: ”Saknar docstring för funktionen process_data

Exempel 2: Flerspråksstöd

API-referens

Konfigschema

Fält

  • strategy (valfritt): Hur agenter ska bearbetas
    • "parallel" (standard): Alla agenter bearbetar samtidigt
    • "sequential": Agenter bearbetar i array-ordning
  • [peerId]: WhatsApp-grupp-JID, E.164-nummer eller annat peer-ID
    • Värde: Array av agent-ID:n som ska bearbeta meddelanden

Begränsningar

  1. Max antal agenter: Ingen hård gräns, men 10+ agenter kan vara långsamt
  2. Delad kontext: Agenter ser inte varandras svar (avsiktligt)
  3. Meddelandeordning: Parallella svar kan komma i valfri ordning
  4. Hastighetsbegränsningar: Alla agenter räknas mot WhatsApps rate limits

Framtida förbättringar

Planerade funktioner:
  • Delat kontextläge (agenter ser varandras svar)
  • Agentkoordination (agenter kan signalera till varandra)
  • Dynamiskt agentval (välj agenter baserat på meddelandets innehåll)
  • Agentprioriteter (vissa agenter svarar före andra)

Se även