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