Grupy rozgloszeniowe
Status: Eksperymentalny Wersja: Dodano w 2026.1.9
Przeglad
Grupy rozgloszeniowe umozliwiaja wielu agentom jednoczesne przetwarzanie i odpowiadanie na ta sama wiadomosc. Pozwala to tworzyc wyspecjalizowane zespoly agentow wspolpracujace w jednej grupie WhatsApp lub DM — wszystko z jednego numeru telefonu.
Aktualny zakres: tylko WhatsApp (kanal webowy).
Grupy rozgloszeniowe sa oceniane po listach dozwolonych kanalow i regulach aktywacji grup. W grupach WhatsApp oznacza to, ze rozgloszenia nastepuja gdy OpenClaw normalnie by odpowiedzial (na przyklad: przy wzmiance, w zaleznosci od ustawien grupy).
Przypadki uzycia
1. Wyspecjalizowane zespoly agentow
Wdrazaj wielu agentow z atomowymi, skoncentrowanymi odpowiedzialnosciami:
Grupa: "Development Team"
Agenci:
- CodeReviewer (recenzuje fragmenty kodu)
- DocumentationBot (generuje dokumentacje)
- SecurityAuditor (sprawdza podatnosci)
- TestGenerator (sugeruje przypadki testowe)
Kazdy agent przetwarza ta sama wiadomosc i dostarcza swoja wyspecjalizowana perspektywe.
2. Wsparcie wielojezyczne
Grupa: "International Support"
Agenci:
- Agent_EN (odpowiada po angielsku)
- Agent_DE (odpowiada po niemiecku)
- Agent_ES (odpowiada po hiszpansku)
3. Przeplywy zapewniania jakosci
Grupa: "Customer Support"
Agenci:
- SupportAgent (udziela odpowiedzi)
- QAAgent (ocenia jakosc, odpowiada tylko gdy znajdzie problemy)
4. Automatyzacja zadan
Grupa: "Project Management"
Agenci:
- TaskTracker (aktualizuje baze danych zadan)
- TimeLogger (rejestruje czas)
- ReportGenerator (tworzy podsumowania)
Konfiguracja
Podstawowa konfiguracja
Dodaj sekcje broadcast najwyzszego poziomu (obok bindings). Klucze to ID peerow WhatsApp:
- czaty grupowe: JID grupy (np.
[email protected]) - DM: numer telefonu E.164 (np.
+15551234567)
{
"broadcast": {
"[email protected]": ["alfred", "baerbel", "assistant3"]
}
}
Wynik: Gdy OpenClaw odpowiedalby w tym czacie, uruchomi wszystkich trzech agentow.
Strategia przetwarzania
Kontroluj jak agenci przetwarzaja wiadomosci:
Rownolegle (domyslnie)
Wszyscy agenci przetwarzaja jednoczesnie:
{
"broadcast": {
"strategy": "parallel",
"[email protected]": ["alfred", "baerbel"]
}
}
Sekwencyjnie
Agenci przetwarzaja po kolei (kazdy czeka na zakonczenie poprzedniego):
{
"broadcast": {
"strategy": "sequential",
"[email protected]": ["alfred", "baerbel"]
}
}
Kompletny przyklad
{
"agents": {
"list": [
{
"id": "code-reviewer",
"name": "Code Reviewer",
"workspace": "/path/to/code-reviewer",
"sandbox": { "mode": "all" }
},
{
"id": "security-auditor",
"name": "Security Auditor",
"workspace": "/path/to/security-auditor",
"sandbox": { "mode": "all" }
},
{
"id": "docs-generator",
"name": "Documentation Generator",
"workspace": "/path/to/docs-generator",
"sandbox": { "mode": "all" }
}
]
},
"broadcast": {
"strategy": "parallel",
"[email protected]": ["code-reviewer", "security-auditor", "docs-generator"],
"[email protected]": ["support-en", "support-de"],
"+15555550123": ["assistant", "logger"]
}
}
Jak dziala
Przeplyw wiadomosci
- Wiadomosc przychodzaca dociera do grupy WhatsApp
- Sprawdzenie rozgloszeniowe: system sprawdza, czy ID peera jest w
broadcast - Jesli na liscie rozgloszeniowej:
- Wszyscy wymienieni agenci przetwarzaja wiadomosc
- Kazdy agent ma wlasny klucz sesji i izolowany kontekst
- Agenci przetwarzaja rownolegle (domyslnie) lub sekwencyjnie
- Jesli nie na liscie rozgloszeniowej:
- Stosowany jest normalny routing (pierwszy pasujacy binding)
Uwaga: grupy rozgloszeniowe nie omijaja list dozwolonych kanalow ani regul aktywacji grup (wzmianki/polecenia/itp.). Zmieniaja jedynie ktorzy agenci sa uruchamiani gdy wiadomosc kwalifikuje sie do przetworzenia.
Izolacja sesji
Kazdy agent w grupie rozgloszeniowej utrzymuje calkowicie oddzielne:
- Klucze sesji (
agent:alfred:whatsapp:group:120363...vsagent:baerbel:whatsapp:group:120363...) - Historie rozmow (agent nie widzi wiadomosci innych agentow)
- Przestrzenie robocze (oddzielne sandboxe jesli skonfigurowane)
- Dostep do narzedzi (rozne listy allow/deny)
- Pamiec/kontekst (oddzielne IDENTITY.md, SOUL.md itp.)
- Bufor kontekstu grupy (ostatnie wiadomosci grupowe uzywane do kontekstu) jest wspoldzielony per peer, wiec wszyscy agenci rozgloszeniowi widza ten sam kontekst gdy sa wyzwalani
Pozwala to kazdemu agentowi miec:
- Rozne osobowosci
- Rozny dostep do narzedzi (np. tylko-odczyt vs. odczyt-zapis)
- Rozne modele (np. opus vs. sonnet)
- Rozne zainstalowane umiejetnosci
Przyklad: izolowane sesje
W grupie [email protected] z agentami ["alfred", "baerbel"]:
Kontekst Alfreda:
Sesja: agent:alfred:whatsapp:group:[email protected]
Historia: [wiadomosc uzytkownika, poprzednie odpowiedzi alfreda]
Przestrzen robocza: /Users/pascal/openclaw-alfred/
Narzedzia: read, write, exec
Kontekst Barbel:
Sesja: agent:baerbel:whatsapp:group:[email protected]
Historia: [wiadomosc uzytkownika, poprzednie odpowiedzi baerbel]
Przestrzen robocza: /Users/pascal/openclaw-baerbel/
Narzedzia: read only
Najlepsze praktyki
1. Utrzymuj agentow skoncentrowanych
Projektuj kazdego agenta z jedna, jasna odpowiedzialnoscia:
{
"broadcast": {
"DEV_GROUP": ["formatter", "linter", "tester"]
}
}
Dobrze: Kazdy agent ma jedno zadanie Zle: Jeden generyczny agent “dev-helper”
2. Uzywaj opisowych nazw
Jasno okreslaj, co robi kazdy agent:
{
"agents": {
"security-scanner": { "name": "Security Scanner" },
"code-formatter": { "name": "Code Formatter" },
"test-generator": { "name": "Test Generator" }
}
}
3. Konfiguruj rozny dostep do narzedzi
Dawaj agentom tylko narzedzia, ktorych potrzebuja:
{
"agents": {
"reviewer": {
"tools": { "allow": ["read", "exec"] }
},
"fixer": {
"tools": { "allow": ["read", "write", "edit", "exec"] }
}
}
}
4. Monitoruj wydajnosc
Przy wielu agentach rozwaz:
- Uzywanie
"strategy": "parallel"(domyslnie) dla szybkosci - Ograniczenie grup rozgloszeniowych do 5-10 agentow
- Uzywanie szybszych modeli dla prostszych agentow
5. Elegancko obsluguj awarie
Agenci zawodza niezaleznie. Blad jednego agenta nie blokuje innych:
Wiadomosc -> [Agent A ok, Agent B blad, Agent C ok]
Wynik: Agent A i C odpowiadaja, Agent B loguje blad
Kompatybilnosc
Dostawcy
Grupy rozgloszeniowe obecnie dzialaja z:
- WhatsApp (zaimplementowane)
- Telegram (planowane)
- Discord (planowane)
- Slack (planowane)
Routing
Grupy rozgloszeniowe dzialaja obok istniejacego routingu:
{
"bindings": [
{
"match": { "channel": "whatsapp", "peer": { "kind": "group", "id": "GROUP_A" } },
"agentId": "alfred"
}
],
"broadcast": {
"GROUP_B": ["agent1", "agent2"]
}
}
GROUP_A: Tylko alfred odpowiada (normalny routing)GROUP_B: agent1 I agent2 odpowiadaja (rozgloszenie)
Pierwszenstwo: broadcast ma priorytet nad bindings.
Rozwiazywanie problemow
Agenci nie odpowiadaja
Sprawdz:
- ID agentow istnieja w
agents.list - Format ID peera jest prawidlowy (np.
[email protected]) - Agenci nie sa na listach deny
Debugowanie:
tail -f ~/.openclaw/logs/gateway.log | grep broadcast
Tylko jeden agent odpowiada
Przyczyna: ID peera moze byc w bindings, ale nie w broadcast.
Rozwiazanie: Dodaj do konfiguracji broadcast lub usun z bindings.
Problemy z wydajnoscia
Jesli wolno z wieloma agentami:
- Zmniejsz liczbe agentow na grupe
- Uzyj lzejszych modeli (sonnet zamiast opus)
- Sprawdz czas uruchamiania sandboxa
Przyklady
Przyklad 1: Zespol przegladow kodu
{
"broadcast": {
"strategy": "parallel",
"[email protected]": [
"code-formatter",
"security-scanner",
"test-coverage",
"docs-checker"
]
},
"agents": {
"list": [
{
"id": "code-formatter",
"workspace": "~/agents/formatter",
"tools": { "allow": ["read", "write"] }
},
{
"id": "security-scanner",
"workspace": "~/agents/security",
"tools": { "allow": ["read", "exec"] }
},
{
"id": "test-coverage",
"workspace": "~/agents/testing",
"tools": { "allow": ["read", "exec"] }
},
{ "id": "docs-checker", "workspace": "~/agents/docs", "tools": { "allow": ["read"] } }
]
}
}
Uzytkownik wysyla: Fragment kodu Odpowiedzi:
- code-formatter: “Naprawiono wciecia i dodano podpowiedzi typow”
- security-scanner: “Podatnosc SQL injection w linii 12”
- test-coverage: “Pokrycie wynosi 45%, brakuje testow dla przypadkow bledow”
- docs-checker: “Brakuje docstringa dla funkcji
process_data”
Przyklad 2: Wsparcie wielojezyczne
{
"broadcast": {
"strategy": "sequential",
"+15555550123": ["detect-language", "translator-en", "translator-de"]
},
"agents": {
"list": [
{ "id": "detect-language", "workspace": "~/agents/lang-detect" },
{ "id": "translator-en", "workspace": "~/agents/translate-en" },
{ "id": "translator-de", "workspace": "~/agents/translate-de" }
]
}
}
Referencja API
Schemat konfiguracji
interface OpenClawConfig {
broadcast?: {
strategy?: "parallel" | "sequential";
[peerId: string]: string[];
};
}
Pola
strategy(opcjonalny): Jak przetwarzac agentow"parallel"(domyslnie): Wszyscy agenci przetwarzaja jednoczesnie"sequential": Agenci przetwarzaja w kolejnosci tablicy
[peerId]: JID grupy WhatsApp, numer E.164 lub inne ID peera- Wartosc: Tablica ID agentow, ktorzy powinni przetwarzac wiadomosci
Ograniczenia
- Max agentow: Brak twardego limitu, ale 10+ agentow moze byc wolne
- Wspolny kontekst: Agenci nie widza nawzajem swoich odpowiedzi (celowo)
- Kolejnosc wiadomosci: Rownolegle odpowiedzi moga przybywac w dowolnej kolejnosci
- Limity szybkosci: Wszyscy agenci licza sie do limitow szybkosci WhatsApp
Przyszle usprawnienia
Planowane funkcje:
- Tryb wspolnego kontekstu (agenci widza odpowiedzi innych)
- Koordynacja agentow (agenci moga sygnalizowac sobie nawzajem)
- Dynamiczny dobor agentow (wybor agentow na podstawie tresci wiadomosci)
- Priorytety agentow (niektore agenci odpowiadaja przed innymi)