Lekcja 2212 min czytania

Konfiguracja kanałów: allowlisty, dmPolicy i wzmianki

Najczęstszy incydent z agentem w firmie nie polega na tym, że model coś zmyślił. Polega na tym, że odpowiedział komuś, kto nigdy nie powinien był dostać odpowiedzi — albo milczy wobec kogoś, kto miał prawo pytać.

Trzy kanały siedzą w rdzeniu, reszta to pluginy

Kto ma prawo rozmawiać z agentem i kto pilnuje listy — to lekcja trzynasta. Tutaj: w którym kluczu to zapisać i dlaczego „open” bez gwiazdki nic nie robi. Zaczynamy od tego, co w ogóle masz pod ręką. iMessage, Telegram i interfejs WebChat są częścią podstawowej instalacji OpenClaw i nie instalujesz do nich niczego. Każdy inny komunikator to osobny plugin, ładowany dopiero wtedy, gdy kanał jest faktycznie aktywny.

Pluginy dokładasz na trzy sposoby prowadzące do tego samego miejsca: komendą openclaw plugins install z identyfikatorem paczki, kreatorem openclaw onboard przy pierwszej konfiguracji albo komendą openclaw channels add, gdy Gateway już chodzi. Kreator prowadzi przez token, konto i politykę dostępu, więc przy pierwszym kanale jest wygodniejszy niż ręczna edycja pliku.

Po każdej instalacji pluginu Gateway trzeba zrestartować. To jedna z niewielu zmian, których nie łapie hot reload — obok portu i ustawień uwierzytelniania. Pominięcie restartu daje kanał, który widnieje w konfiguracji i nie odpowiada, co potrafi wyglądać jak problem z tokenem.

Podział na rdzeń i pluginy ma praktyczny skutek przy diagnozie. Jeśli Telegram milczy, plugin nie jest podejrzanym, bo go nie ma. Zostają token, polityka dostępu i tryb privacy bota ustawiany po stronie BotFathera — trzy miejsca zamiast czterech, a przy szukaniu w piątek po południu to realna różnica.

Instalacja pluginu kanału, kreator dokładający kanał do działającego Gateway i restart, bez którego nowy plugin nie wstanie.

openclaw plugins install @openclaw/slack
openclaw channels add
openclaw gateway restart

dmPolicy i groupPolicy: dwie polityki, które rozstrzygają wszystko

Model kontroli dostępu jest wspólny dla wszystkich kanałów i stoi na dwóch kluczach. dmPolicy przyjmuje wartości pairing, allowlist, open i disabled, z domyślnym pairing. groupPolicy przyjmuje open, allowlist i disabled, z domyślnym allowlist. Wszystko inne — listy nadawców, rejestr grup, wymóg wzmianki — jest doprecyzowaniem tych dwóch decyzji.

Domyślne pairing działa tak: nieznany nadawca dostaje kod parowania ważny godzinę, a agent ignoruje go do momentu zatwierdzenia. W WhatsAppie oczekujące żądania są limitowane do trzech na konto, więc gdy ktoś próbuje po raz trzeci i nic się nie dzieje, kolejka parowania jest pierwszym miejscem do sprawdzenia.

Zatwierdzasz z linii poleceń. openclaw pairing list wypisuje oczekujące żądania, openclaw pairing approve przepuszcza konkretny kod, a flaga --notify odsyła potwierdzenie do proszącego. Czego tu nie ma: dokumentacja nie opisuje komendy trwale blokującej nadawcę, a przycisk Dismiss w Control UI usuwa bieżące żądanie i nic poza tym.

Moja ocena po kilkunastu konfiguracjach: firmy uciekają od pairingu za wcześnie i niepotrzebnie. Allowlista pisana ręcznie z pamięci ma literówki w identyfikatorach i nikt tego nie zauważa, bo błąd objawia się ciszą. Kod parowania literówek nie ma.

Podgląd oczekujących żądań w formacie maszynowym i zatwierdzenie konkretnego kodu z powiadomieniem nadawcy.

openclaw pairing list <kanał> --json
openclaw pairing approve <kanał> <CODE> --notify

Dlaczego „open” bez gwiazdki nie robi nic

Ustawienie dmPolicy na open nie otwiera kanału samo z siebie. Wymaga jawnego wpisu „*” na allowliście kanału. Bez niego wiadomości dalej są odrzucane, a w logach zobaczysz wpis allowlist — nie awarię, nie błąd tokenu, po prostu decyzję polityki.

To myli, bo słowo open sugeruje, że lista przestaje mieć znaczenie. Jest odwrotnie. Polityka mówi, jak lista ma być interpretowana, a lista dalej musi istnieć. Ten sam wymóg wraca w Slacku na Enterprise Grid: DM-y z kontami enterprise działają wyłącznie przy dmPolicy ustawionym na open i allowFrom zawierającym „*”.

Dokumentacja nazywa dmPolicy „open” i groupPolicy „open” ustawieniami ostatniej szansy i radzi trzymać się parowania oraz allowlist, dopóki nie ufasz każdej osobie w pokoju. Przeczytaj to zdanie dwa razy, zanim ktoś w firmie otworzy kanał „na chwilę, do testów”.

Bo właśnie tak wygląda najczęstsza wersja incydentu z tytułu tej lekcji. Nic nie wybucha. Nie ma alertu, nie ma czerwonej lampki. Po prostu przez trzy tygodnie każdy, kto zna numer albo trafi na bota, rozmawia z agentem mającym dostęp do Waszych dokumentów i skrzynki.

Dwa odczyty, które trzeba zrobić razem. Sama polityka nic nie mówi, dopóki nie zobaczysz listy, do której się odnosi.

openclaw config get channels.telegram.dmPolicy
openclaw config get channels.telegram.allowFrom

allowFrom kontra groupAllowFrom: dwa różne klucze

allowFrom rządzi wyłącznie wiadomościami prywatnymi. W grupach obowiązuje groupAllowFrom, a allowFrom bywa tam jedynie zapasowym źródłem listy. Pomylenie tych dwóch kluczy daje agenta, który w DM-ach zachowuje się wzorowo, a w grupie odpowiada komuś, kogo nigdy nie zamierzałeś wpuścić.

Zatwierdzone parowanie też nie przenosi się na grupy. Kod parowania odblokowuje rozmowy prywatne i tyle — dostęp grupowy wymaga wpisu w konfiguracji. Odpowiedź na wiadomość bota nie omija groupAllowFrom, więc sztuczka z cytowaniem nie zadziała ani przypadkiem, ani celowo.

Przy kilku kontach w jednym kanale pierwszeństwo mają ustawienia z gałęzi channels.<kanał>.accounts.<accountId>. Jeśli zmieniasz politykę na poziomie kanału i nic się nie dzieje, sprawdź, czy nie nadpisuje jej wpis konkretnego konta. Ta warstwa jest łatwa do przeoczenia, bo w pliku konfiguracyjnym leży niżej niż to, co edytujesz.

Osobną warstwą jest contextVisibility, które nie decyduje o tym, kto może zawołać agenta, tylko o tym, co model w ogóle zobaczy. Przyjmuje „all”, „allowlist” i „allowlist_quote”, gdzie ostatnia wartość dopuszcza jedną zacytowaną wypowiedź spoza listy. To ustawienie ratuje kanały, w których agent ma odpowiadać wybranym osobom, a nie czytać całej rozmowy zespołu.

requireMention i rejestr groups: w jakiej kolejności to jest sprawdzane

Kolejność jest trzystopniowa i bez niej diagnoza sprowadza się do zgadywania. Najpierw sprawdzana jest groupPolicy. Potem allowlisty grup, czyli rejestr groups i groupAllowFrom. Na końcu bramka wzmianki — requireMention oraz komendy aktywacji.

requireMention domyślnie stoi na true w każdej grupie, dopóki nie nadpiszesz tego dla konkretnego pokoju. Poza natywnymi wzmiankami platformy działają wzorce regex z mentionPatterns, przydatne wtedy, gdy zespół woła agenta imieniem zamiast małpą. Zasięg zawężają allowIn i denyIn.

W rejestrze groups klucz „*” dopuszcza wszystkie grupy, zachowując domyślne zachowanie wzmianki. To rozsądny punkt startowy dla WhatsAppa i Signala: parowanie dla DM-ów, wszystkie grupy formalnie dopuszczone, ale agent odzywa się dopiero po zawołaniu. Ryzyko jest niskie, bo bez wzmianki i tak nic nie przechodzi.

W logach ta bramka wygląda jednoznacznie. Wpis „drop guild message (mention required)” znaczy, że wiadomość grupowa czeka na wzmiankę. Szukanie przyczyny w konfiguracji modelu ani w tokenie nic tu nie da.

Gateway tylko lokalnie, uwierzytelnianie tokenem, parowanie dla wiadomości prywatnych i wszystkie grupy z wymogiem wzmianki — układ na start.

// bezpieczna baza z dokumentacji
{
  gateway: { bind: "loopback", auth: { mode: "token" } },
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } }
    }
  }
}

Slack: identyfikatory C12345678 i wielosobowe DM-y

Slack ma pułapkę, która potrafi zjeść pół dnia. Allowlisty kanałów muszą używać stabilnych identyfikatorów w formacie C12345678. Klucze oparte na nazwie z hashem przy groupPolicy ustawionym na allowlist po prostu nie pasują — nic się nie wywala, wiadomości po cichu nie przechodzą, a Ty sprawdzasz scope'y i token.

Ustawienia dla pojedynczego kanału siedzą pod channels.slack.channels.<channelId>. Znajdziesz tam requireMention, domyślnie true dla kanałów, listę users z osobami dopuszczonymi akurat w tym pokoju oraz allowBots, które jest domyślnie ostrożne: wiadomości od botów przechodzą tylko wtedy, gdy nadawca figuruje na liście users albo obecny jest właściciel.

Wielosobowe DM-y, czyli MPIM, włącza się osobno kluczem channels.slack.dm.groupEnabled, domyślnie ustawionym na false. Zawężasz je opcjonalną listą channels.slack.dm.groupChannels. Obie rzeczy tylko filtrują to, co Slack już dostarczył — nie dodadzą agenta do istniejącej grupy. Sama polityka grup tu nie wystarczy i to bodaj najczęstsze nieporozumienie przy tym kanale.

Dwa drobiazgi na koniec. Gdy konfiguracja Slacka pochodzi wyłącznie ze zmiennych środowiskowych, system wraca do groupPolicy ustawionego na allowlist i zapisuje ostrzeżenie w logu — czyli dostajesz kanał, który domyślnie nic nie wpuszcza. Na Enterprise Grid przy instalacjach org-wide nie ma trybu relay, a na kontach enterprise nie działają slash commands, interakcje ani App Home. Te ograniczenia wynikają z platformy Slacka, nie z Twojej konfiguracji — szczegóły opisuje dokumentacja kanału Slack.

Polityka grup i przełącznik wielosobowych DM-ów. Drugi klucz odpowiada za większość zgłoszeń „agent nie widzi rozmowy w trójkę”.

openclaw config get channels.slack.groupPolicy
openclaw config get channels.slack.dm.groupEnabled

Zły allowlist to najczęstszy incydent — dlaczego akurat ten

Błąd w allowliście ma dwa oblicza i tylko jedno jest niegroźne. Lista za wąska daje agenta, który milczy: irytujące, kosztuje kwadrans, nikt nie ucierpiał. Lista za szeroka daje agenta odpowiadającego osobom spoza firmy, z pełnym dostępem do tego, co ma w kontekście.

Za szeroką listę produkuje się zwykle w jeden z czterech sposobów, a każdy widać w wyniku openclaw config get channels. Wpis „*” zostawiony po testach siedzi w allowFrom albo w rejestrze groups i rzuca się w oczy od razu — pod warunkiem, że ktoś tam zagląda. Kanał współdzielony z klientem wygląda w konfiguracji jak każdy inny identyfikator, więc rozpoznasz go tylko po tym, że go rozpoznajesz. Konto osoby, która odeszła, zostaje w groupAllowFrom jako identyfikator bez twarzy. Konfiguracja skopiowana z innego kanału przynosi ze sobą nadpisania z channels.<kanał>.accounts.<accountId>, które leżą niżej w pliku i wygrywają z tym, co edytujesz na górze.

Kanał współdzielony jest najgorszy, bo nie wygląda podejrzanie. Jeśli allowlista opiera się na obecności w pokoju zamiast na wymienionych identyfikatorach, agent odpowie tam wszystkim — łącznie z pytaniem o marżę albo warunki innego kontrahenta.

Kto ma być na której liście i kto ją czyści przy odejściu z firmy — to ustalenie organizacyjne z lekcji trzynastej; tutaj interesuje nas wyłącznie, w którym kluczu je zapisać.

Pełny zrzut polityk i osobno ustawienia pojedynczych kanałów Slacka — dwa miejsca, w których widać wpisy dodane kiedyś do testów.

openclaw config get channels
openclaw config get channels.slack.channels

Co warto zapamiętać

W rdzeniu instalacji siedzą trzy kanały: WebChat, Telegram i iMessage — do żadnego z nich niczego nie instalujesz. Reszta komunikatorów to pluginy wymagające restartu Gateway po instalacji.
dmPolicy przyjmuje pairing (domyślnie), allowlist, open i disabled; groupPolicy przyjmuje open, allowlist (domyślnie) i disabled. Tryb open wymaga jawnego wpisu „*” na allowliście, inaczej wiadomości dalej są blokowane.
W grupach obowiązuje groupAllowFrom, allowFrom dotyczy wyłącznie DM-ów. Zatwierdzone parowanie nie daje dostępu do grup, a odpowiedź na wiadomość bota nie omija groupAllowFrom.
Kolejność sprawdzania jest trzystopniowa: groupPolicy, potem allowlisty grup (groups i groupAllowFrom), na końcu bramka wzmianki z requireMention domyślnie ustawionym na true.
Allowlisty kanałów Slacka muszą używać identyfikatorów w formacie C12345678 — klucze po nazwie przy groupPolicy allowlist milczą zamiast błędu. Wielosobowe DM-y włącza osobno channels.slack.dm.groupEnabled, domyślnie false.
Kody parowania są ważne godzinę, a w WhatsAppie oczekujące żądania są limitowane do trzech na konto. Zatwierdzasz je komendą openclaw pairing approve, opcjonalnie z flagą --notify.

Częste pytania

Ustawiłem dmPolicy na open, a agent dalej nie odpowiada nieznanym osobom. Dlaczego?+

Bo tryb open wymaga jawnego wpisu „*” na allowliście kanału. Sama polityka mówi tylko, jak lista ma być interpretowana — lista nadal musi istnieć i zawierać gwiazdkę. W logach zobaczysz wtedy wpis allowlist, który wygląda niewinnie i bywa mylony z problemem tokenu. Zanim to ustawisz, sprawdź, czy naprawdę tego chcesz: dokumentacja traktuje open jako ustawienie ostatniej szansy i poleca parowanie z allowlistą.

Agent odpowiada w prywatnych wiadomościach, ale w grupie na Slacku milczy. Od czego zacząć?+

Od trzech rzeczy w tej kolejności. Po pierwsze groupPolicy — domyślnie stoi na allowlist, więc pokój musi być wymieniony. Po drugie format kluczy: Slack wymaga identyfikatorów w postaci C12345678, a klucze po nazwie kanału po cichu nie pasują. Po trzecie requireMention, które domyślnie jest włączone i wymaga zawołania agenta. W logach szukaj wpisu „drop guild message (mention required)”.

Czy zatwierdzenie parowania wystarczy, żeby agent działał też w grupach?+

Nie. Kod parowania odblokowuje wyłącznie rozmowy prywatne. Dostęp grupowy wymaga osobnych wpisów w konfiguracji — rejestru groups i listy groupAllowFrom. Odpowiedź na wiadomość bota również nie omija groupAllowFrom, więc nie da się obejść tego cytowaniem. To celowy podział: zgoda na rozmowę z Tobą to nie to samo co prawo wstępu do pokoju z trzydziestoma osobami.

Jak włączyć rozmowy w trójkę na Slacku?+

Kluczem channels.slack.dm.groupEnabled, który domyślnie stoi na false. Opcjonalnie zawężasz je listą channels.slack.dm.groupChannels. Obie opcje tylko filtrują to, co Slack już dostarczył — nie dodadzą agenta do istniejącej rozmowy grupowej, do której nie należy. Sama polityka grup tego nie załatwi, bo MPIM jest w Slacku osobnym typem konwersacji.

Źródła danych z tej lekcji

Krok 2Ćwiczenie do wykonaniaTeoria bez ćwiczenia zostaje wiedzą, której nie używasz.

Chcesz to przećwiczyć na żywo?

Uruchom własnego agenta i wypróbuj to, o czym przed chwilą przeczytałeś. Pierwsza subskrypcja pakietu Premium ma 5 dni za darmo, a kurs czytasz dalej niezależnie od tego.

Zobacz plany