Grupy rozgłoszeniowe
Status: EksperymentalneWersja: Dodano w 2026.1.9
Przegląd
Grupy rozgłoszeniowe umożliwiają wielu agentom jednoczesne przetwarzanie i odpowiadanie na tę samą wiadomość. Pozwala to tworzyć wyspecjalizowane zespoły agentów, które współpracują w jednej grupie WhatsApp lub DM — wszystko przy użyciu jednego numeru telefonu. Aktualny zakres: tylko WhatsApp (kanał webowy). Grupy rozgłoszeniowe są oceniane po listach dozwolonych kanału i regułach aktywacji grup. W grupach WhatsApp oznacza to, że rozgłoszenia zachodzą wtedy, gdy OpenClaw normalnie by odpowiedział (na przykład po wzmiance, w zależności od ustawień grupy).Przypadki użycia
1. Wyspecjalizowane zespoły agentów
Wdrażaj wielu agentów z atomowymi, ściśle ukierunkowanymi odpowiedzialnościami:2. Obsługa wielu języków
3. Przepływy pracy zapewnienia jakości
4. Automatyzacja zadań
Konfiguracja
Podstawowa konfiguracja
Dodaj sekcję najwyższego poziomubroadcast (obok bindings). Kluczami są identyfikatory peer WhatsApp:
- czaty grupowe: JID grupy (np.
[email protected]) - DM-y: numer telefonu w formacie E.164 (np.
+15551234567)
Strategia przetwarzania
Kontroluj sposób przetwarzania wiadomości przez agentów:Równolegle (domyślnie)
Wszyscy agenci przetwarzają jednocześnie:Sekwencyjne
Agenci przetwarzają po kolei (jeden czeka, aż poprzedni zakończy):Kompletny przykład
Jak to działa
Przepływ wiadomości
- Wiadomość przychodząca trafia do grupy WhatsApp
- Sprawdzenie rozgłoszenia: system sprawdza, czy identyfikator peer znajduje się w
broadcast - Jeśli jest na liście rozgłoszeń:
- Wszyscy wymienieni agenci przetwarzają wiadomość
- Każdy agent ma własny klucz sesji i odizolowany kontekst
- Agenci przetwarzają równolegle (domyślnie) lub sekwencyjnie
- Jeśli nie jest na liście rozgłoszeń:
- Obowiązuje normalne trasowanie (pierwsze pasujące powiązanie)
Izolacja sesji
Każdy agent w grupie rozgłoszeniowej utrzymuje całkowicie odrębne:- Klucze sesji (
agent:alfred:whatsapp:group:120363...vsagent:baerbel:whatsapp:group:120363...) - Historię konwersacji (agent nie widzi wiadomości innych agentów)
- Obszar roboczy (oddzielne sandboxy, jeśli skonfigurowano)
- Dostęp do narzędzi (różne listy dozwolone/zabronione)
- Pamięć/kontekst (oddzielne IDENTITY.md, SOUL.md itp.)
- Bufor kontekstu grupy (ostatnie wiadomości grupowe używane jako kontekst) jest współdzielony per peer, więc wszyscy agenci rozgłoszeniowi widzą ten sam kontekst po wyzwoleniu
- Różne osobowości
- Różny dostęp do narzędzi (np. tylko do odczytu vs. odczyt-zapis)
- Różne modele (np. opus vs. sonnet)
- Różne zainstalowane umiejętności
Przykład: izolowane sesje
W grupie[email protected] z agentami ["alfred", "baerbel"]:
Kontekst Alfreda:
Najlepsze praktyki
1. Utrzymuj wąski zakres agentów
Projektuj każdego agenta z jedną, jasno określoną odpowiedzialnością:❌ Źle: Jeden ogólny agent „dev-helper”
2. Używaj opisowych nazw
Niech będzie jasne, co robi każdy agent:3. Skonfiguruj różny dostęp do narzędzi
Daj agentom tylko te narzędzia, których potrzebują:4. Monitoruj wydajność
Przy wielu agentach rozważ:- Używanie
"strategy": "parallel"(domyślnie) dla szybkości - Ograniczenie grup rozgłoszeniowych do 5–10 agentów
- Używanie szybszych modeli dla prostszych agentów
5. Obsługuj awarie w sposób łagodny
Agenci zawodzą niezależnie. Błąd jednego agenta nie blokuje pozostałych:Zgodność
Dostawcy
Grupy rozgłoszeniowe obecnie działają z:- ✅ WhatsApp (zaimplementowane)
- 🚧 Telegram (planowane)
- 🚧 Discord (planowane)
- 🚧 Slack (planowane)
Trasowanie
Grupy rozgłoszeniowe działają obok istniejącego trasowania:GROUP_A: Odpowiada tylko alfred (normalne trasowanie)GROUP_B: Odpowiadają agent1 ORAZ agent2 (rozgłoszenie)
broadcast ma pierwszeństwo przed bindings.
Rozwiązywanie problemów
Agenci nie odpowiadają
Sprawdź:- Identyfikatory agentów istnieją w
agents.list - Format identyfikatora peer jest poprawny (np.
[email protected]) - Agenci nie znajdują się na listach zabronionych
Odpowiada tylko jeden agent
Przyczyna: Identyfikator peer może znajdować się wbindings, ale nie w broadcast.
Naprawa: Dodaj do konfiguracji rozgłoszeń lub usuń z powiązań.
Problemy z wydajnością
Jeśli jest wolno przy wielu agentach:- Zmniejsz liczbę agentów na grupę
- Użyj lżejszych modeli (sonnet zamiast opus)
- Sprawdź czas uruchamiania sandboxa
Przykłady
Przykład 1: Zespół do przeglądu kodu
Odpowiedzi:
- code-formatter: „Poprawiono wcięcia i dodano podpowiedzi typów”
- security-scanner: „⚠️ Podatność na SQL injection w linii 12”
- test-coverage: „Pokrycie wynosi 45%, brakuje testów dla przypadków błędów”
- docs-checker: „Brak docstringa dla funkcji
process_data”
Przykład 2: Obsługa wielu języków
Referencja API
Schemat konfiguracji
Pola
strategy(opcjonalne): Sposób przetwarzania agentów"parallel"(domyślne): Wszyscy agenci przetwarzają jednocześnie"sequential": Agenci przetwarzają w kolejności tablicy
[peerId]: JID grupy WhatsApp, numer E.164 lub inny identyfikator peer- Wartość: Tablica identyfikatorów agentów, które powinny przetwarzać wiadomości
Ograniczenia
- Maks. liczba agentów: Brak twardego limitu, ale 10+ agentów może być wolne
- Współdzielony kontekst: Agenci nie widzą odpowiedzi innych agentów (celowo)
- Kolejność wiadomości: Odpowiedzi równoległe mogą docierać w dowolnej kolejności
- Limity szybkości: Wszyscy agenci wliczają się do limitów WhatsApp
Przyszłe ulepszenia
Planowane funkcje:- Tryb współdzielonego kontekstu (agenci widzą odpowiedzi innych)
- Koordynacja agentów (agenci mogą sygnalizować sobie nawzajem)
- Dynamiczny dobór agentów (wybór agentów na podstawie treści wiadomości)
- Priorytety agentów (niektórzy agenci odpowiadają przed innymi)