diff --git a/docs/pl/automation/tasks.md b/docs/pl/automation/tasks.md
index faec7718c..5a73a43a9 100644
--- a/docs/pl/automation/tasks.md
+++ b/docs/pl/automation/tasks.md
@@ -1,44 +1,48 @@
---
read_when:
- - Sprawdzanie zadań w tle będących w toku lub niedawno zakończonych
- - Debugowanie niepowodzeń dostarczania dla odłączonych uruchomień agenta
- - Zrozumienie, jak uruchomienia w tle odnoszą się do sesji, Cron i Heartbeat
-summary: Śledzenie zadań w tle dla uruchomień ACP, podagentów, izolowanych zadań Cron i operacji CLI
+ - Sprawdzanie zadań w tle będących w toku lub niedawno ukończonych
+ - Debugowanie niepowodzeń dostarczania dla odłączonych uruchomień agentów
+ - Zrozumienie, jak uruchomienia w tle są powiązane z sesjami, Cron i Heartbeat
+summary: Śledzenie zadań w tle dla uruchomień ACP, subagentów, izolowanych zadań Cron oraz operacji CLI
title: Zadania w tle
x-i18n:
- generated_at: "2026-04-21T09:51:53Z"
+ generated_at: "2026-04-21T19:20:46Z"
model: gpt-5.4
provider: openai
- source_hash: ba5511b1c421bdf505fc7d34f09e453ac44e85213fcb0f082078fa957aa91fe7
+ source_hash: a4cd666b3eaffde8df0b5e1533eb337e44a0824824af6f8a240f18a89f71b402
source_path: automation/tasks.md
workflow: 15
---
# Zadania w tle
-> **Szukasz harmonogramowania?** Zobacz [Automatyzacja i zadania](/pl/automation), aby wybrać właściwy mechanizm. Ta strona dotyczy **śledzenia** pracy w tle, a nie jej harmonogramowania.
+> **Szukasz harmonogramowania?** Zobacz [Automatyzacja i zadania](/pl/automation), aby wybrać właściwy mechanizm. Ta strona opisuje **śledzenie** pracy w tle, a nie jej planowanie.
-Zadania w tle śledzą pracę wykonywaną **poza główną sesją rozmowy**:
-uruchomienia ACP, uruchomienia podagentów, wykonywanie izolowanych zadań Cron i operacje inicjowane przez CLI.
+Zadania w tle śledzą pracę uruchamianą **poza główną sesją rozmowy**:
+uruchomienia ACP, uruchomienia subagentów, izolowane wykonania zadań Cron oraz operacje inicjowane przez CLI.
-Zadania **nie** zastępują sesji, zadań Cron ani Heartbeat — są **rejestrem aktywności**, który zapisuje, jaka odłączona praca została wykonana, kiedy i czy zakończyła się powodzeniem.
+Zadania **nie** zastępują sesji, zadań Cron ani Heartbeat — są **rejestrem aktywności**, który zapisuje, jaka odłączona praca miała miejsce, kiedy się odbyła i czy zakończyła się powodzeniem.
-Nie każde uruchomienie agenta tworzy zadanie. Tury Heartbeat i zwykły interaktywny czat tego nie robią. Wszystkie wykonania Cron, uruchomienia ACP, uruchomienia podagentów i polecenia agenta w CLI tworzą zadania.
+Nie każde uruchomienie agenta tworzy zadanie. Tury Heartbeat i zwykły interaktywny czat tego nie robią. Wszystkie wykonania Cron, uruchomienia ACP, uruchomienia subagentów i polecenia agenta z CLI — tak.
-## TL;DR
+## W skrócie
-- Zadania to **rekordy**, a nie harmonogramy — Cron i Heartbeat decydują, _kiedy_ praca ma się uruchomić, a zadania śledzą, _co się wydarzyło_.
-- ACP, podagenci, wszystkie zadania Cron i operacje CLI tworzą zadania. Tury Heartbeat tego nie robią.
-- Każde zadanie przechodzi przez `queued → running → terminal` (`succeeded`, `failed`, `timed_out`, `cancelled` albo `lost`).
-- Zadania Cron pozostają aktywne, dopóki środowisko uruchomieniowe Cron nadal jest właścicielem zadania; zadania CLI oparte na czacie pozostają aktywne tylko wtedy, gdy ich kontekst uruchomienia będący właścicielem nadal jest aktywny.
-- Zakończenie jest sterowane wypychaniem: odłączona praca może powiadomić bezpośrednio lub wybudzić sesję żądającą/Heartbeat po zakończeniu, więc pętle sondujące status zwykle nie są właściwym podejściem.
-- Izolowane uruchomienia Cron i zakończenia podagentów w miarę możliwości czyszczą śledzone karty/przetwarzania przeglądarki dla ich sesji potomnej przed końcowym księgowaniem czyszczenia.
-- Dostarczanie izolowanego Cron tłumi nieaktualne pośrednie odpowiedzi nadrzędne, gdy praca potomnych podagentów nadal się opróżnia, i preferuje końcowe dane wyjściowe potomka, jeśli dotrą przed dostarczeniem.
-- Powiadomienia o zakończeniu są dostarczane bezpośrednio do kanału lub kolejkowane na następny Heartbeat.
+- Zadania to **rekordy**, a nie planery — Cron i Heartbeat decydują, _kiedy_ praca ma się uruchomić, a zadania śledzą, _co się wydarzyło_.
+- ACP, subagenci, wszystkie zadania Cron i operacje CLI tworzą zadania. Tury Heartbeat nie.
+- Każde zadanie przechodzi przez `queued → running → terminal` (succeeded, failed, timed_out, cancelled lub lost).
+- Zadania Cron pozostają aktywne, dopóki środowisko wykonawcze Cron nadal jest właścicielem zadania; zadania CLI oparte na czacie pozostają aktywne tylko tak długo, jak aktywny jest ich kontekst uruchomienia.
+- Zakończenie jest sterowane zdarzeniami push: odłączona praca może powiadomić bezpośrednio lub wybudzić
+ sesję żądającą/Heartbeat po zakończeniu, więc pętle odpytywania statusu
+ zwykle nie są właściwym podejściem.
+- Izolowane uruchomienia Cron i zakończenia subagentów w miarę możliwości czyszczą śledzone karty/przetwarzania przeglądarki dla sesji potomnej przed końcową ewidencją czyszczenia.
+- Dostarczanie dla izolowanego Cron tłumi nieaktualne odpowiedzi pośrednie rodzica, gdy
+ praca potomnych subagentów nadal się opróżnia, i preferuje końcowy wynik potomny,
+ jeśli dotrze on przed dostarczeniem.
+- Powiadomienia o zakończeniu są dostarczane bezpośrednio do kanału lub kolejkowane do następnego Heartbeat.
- `openclaw tasks list` pokazuje wszystkie zadania; `openclaw tasks audit` ujawnia problemy.
-- Rekordy terminalne są przechowywane przez 7 dni, a następnie automatycznie usuwane.
+- Rekordy końcowe są przechowywane przez 7 dni, a następnie automatycznie usuwane.
## Szybki start
@@ -46,17 +50,17 @@ Nie każde uruchomienie agenta tworzy zadanie. Tury Heartbeat i zwykły interakt
# Wyświetl wszystkie zadania (od najnowszych)
openclaw tasks list
-# Filtruj według środowiska uruchomieniowego lub statusu
+# Filtruj według środowiska wykonawczego lub statusu
openclaw tasks list --runtime acp
openclaw tasks list --status running
# Pokaż szczegóły konkretnego zadania (według ID, ID uruchomienia lub klucza sesji)
openclaw tasks show
-# Anuluj uruchomione zadanie (zabija sesję potomną)
+# Anuluj uruchomione zadanie (kończy sesję potomną)
openclaw tasks cancel
-# Zmień zasady powiadamiania dla zadania
+# Zmień politykę powiadomień dla zadania
openclaw tasks notify state_changes
# Uruchom audyt kondycji
@@ -74,21 +78,21 @@ openclaw tasks flow cancel
## Co tworzy zadanie
-| Źródło | Typ środowiska uruchomieniowego | Kiedy tworzony jest rekord zadania | Domyślna polityka powiadomień |
-| ---------------------- | -------------------------------- | ------------------------------------------------------ | ----------------------------- |
-| Uruchomienia ACP w tle | `acp` | Uruchomienie potomnej sesji ACP | `done_only` |
-| Orkiestracja podagentów | `subagent` | Uruchomienie podagenta przez `sessions_spawn` | `done_only` |
-| Zadania Cron (wszystkie typy) | `cron` | Każde wykonanie Cron (sesja główna i izolowana) | `silent` |
-| Operacje CLI | `cli` | Polecenia `openclaw agent` uruchamiane przez Gateway | `silent` |
-| Zadania mediów agenta | `cli` | Uruchomienia `video_generate` oparte na sesji | `silent` |
+| Źródło | Typ środowiska wykonawczego | Kiedy tworzony jest rekord zadania | Domyślna polityka powiadomień |
+| ---------------------- | --------------------------- | ----------------------------------------------------- | ----------------------------- |
+| Uruchomienia ACP w tle | `acp` | Utworzenie potomnej sesji ACP | `done_only` |
+| Orkiestracja subagentów | `subagent` | Utworzenie subagenta przez `sessions_spawn` | `done_only` |
+| Zadania Cron (wszystkie typy) | `cron` | Każde wykonanie Cron (sesja główna i izolowana) | `silent` |
+| Operacje CLI | `cli` | Polecenia `openclaw agent`, które działają przez Gateway | `silent` |
+| Zadania multimedialne agenta | `cli` | Uruchomienia `video_generate` oparte na sesji | `silent` |
Zadania Cron w sesji głównej domyślnie używają polityki powiadomień `silent` — tworzą rekordy do śledzenia, ale nie generują powiadomień. Izolowane zadania Cron również domyślnie używają `silent`, ale są bardziej widoczne, ponieważ działają we własnej sesji.
-Uruchomienia `video_generate` oparte na sesji również używają domyślnie polityki powiadomień `silent`. Nadal tworzą rekordy zadań, ale zakończenie jest przekazywane z powrotem do oryginalnej sesji agenta jako wewnętrzne wybudzenie, aby agent mógł sam napisać wiadomość uzupełniającą i dołączyć gotowe wideo. Jeśli włączysz `tools.media.asyncCompletion.directSend`, asynchroniczne zakończenia `music_generate` i `video_generate` najpierw próbują bezpośredniego dostarczenia do kanału, a dopiero potem wracają do ścieżki wybudzenia sesji żądającej.
+Uruchomienia `video_generate` oparte na sesji również używają domyślnie polityki powiadomień `silent`. Nadal tworzą rekordy zadań, ale zakończenie jest przekazywane z powrotem do oryginalnej sesji agenta jako wewnętrzne wybudzenie, aby agent mógł sam napisać wiadomość uzupełniającą i dołączyć gotowy film. Jeśli włączysz `tools.media.asyncCompletion.directSend`, asynchroniczne zakończenia `music_generate` i `video_generate` najpierw próbują bezpośredniego dostarczenia do kanału, zanim wrócą do ścieżki wybudzenia sesji żądającej.
-Gdy zadanie `video_generate` oparte na sesji jest nadal aktywne, narzędzie działa również jako zabezpieczenie: powtórne wywołania `video_generate` w tej samej sesji zwracają status aktywnego zadania zamiast uruchamiać drugie równoległe generowanie. Użyj `action: "status"`, gdy chcesz uzyskać jawne wyszukanie postępu/statusu po stronie agenta.
+Dopóki zadanie `video_generate` oparte na sesji jest nadal aktywne, narzędzie działa też jako zabezpieczenie: powtórne wywołania `video_generate` w tej samej sesji zwracają status aktywnego zadania zamiast uruchamiać drugie współbieżne generowanie. Użyj `action: "status"`, jeśli chcesz jawnego sprawdzenia postępu/statusu po stronie agenta.
-**Co nie tworzy zadań:**
+**Czego nie tworzy zadań:**
- Tury Heartbeat — sesja główna; zobacz [Heartbeat](/pl/gateway/heartbeat)
- Zwykłe interaktywne tury czatu
@@ -108,38 +112,40 @@ stateDiagram-v2
running --> lost : session gone > 5 min
```
-| Status | Co oznacza |
-| ----------- | ------------------------------------------------------------------------ |
-| `queued` | Utworzone, oczekuje na uruchomienie przez agenta |
-| `running` | Tura agenta jest aktywnie wykonywana |
-| `succeeded` | Zakończone pomyślnie |
-| `failed` | Zakończone błędem |
-| `timed_out` | Przekroczono skonfigurowany limit czasu |
-| `cancelled` | Zatrzymane przez operatora za pomocą `openclaw tasks cancel` |
-| `lost` | Środowisko uruchomieniowe utraciło autorytatywny stan zaplecza po 5-minutowym okresie karencji |
+| Status | Co oznacza |
+| ----------- | ------------------------------------------------------------------------- |
+| `queued` | Utworzone, oczekuje na uruchomienie przez agenta |
+| `running` | Tura agenta jest aktywnie wykonywana |
+| `succeeded` | Zakończone pomyślnie |
+| `failed` | Zakończone błędem |
+| `timed_out` | Przekroczono skonfigurowany limit czasu |
+| `cancelled` | Zatrzymane przez operatora przez `openclaw tasks cancel` |
+| `lost` | Środowisko wykonawcze utraciło autorytatywny stan zaplecza po 5-minutowym okresie karencji |
-Przejścia zachodzą automatycznie — gdy powiązane uruchomienie agenta się kończy, status zadania jest aktualizowany odpowiednio do wyniku.
+Przejścia następują automatycznie — gdy powiązane uruchomienie agenta się kończy, status zadania jest aktualizowany odpowiednio do wyniku.
-`lost` zależy od środowiska uruchomieniowego:
+`lost` zależy od środowiska wykonawczego:
- Zadania ACP: zniknęły metadane potomnej sesji ACP w zapleczu.
-- Zadania podagentów: potomna sesja zniknęła z docelowego magazynu agenta.
-- Zadania Cron: środowisko uruchomieniowe Cron nie śledzi już zadania jako aktywnego.
-- Zadania CLI: zadania izolowanej sesji potomnej używają sesji potomnej; zadania CLI oparte na czacie używają zamiast tego kontekstu aktywnego uruchomienia, więc pozostające wiersze sesji kanału/grupy/bezpośredniej nie utrzymują ich przy życiu.
+- Zadania subagentów: potomna sesja zniknęła z docelowego magazynu agentów.
+- Zadania Cron: środowisko wykonawcze Cron nie śledzi już zadania jako aktywnego.
+- Zadania CLI: izolowane zadania potomnej sesji używają potomnej sesji; zadania CLI oparte na czacie używają zamiast tego aktywnego kontekstu uruchomienia, więc zalegające wiersze sesji kanału/grupy/bezpośredniej nie utrzymują ich przy życiu.
## Dostarczanie i powiadomienia
-Gdy zadanie osiąga stan terminalny, OpenClaw wysyła powiadomienie. Są dwie ścieżki dostarczania:
+Gdy zadanie osiąga stan końcowy, OpenClaw Cię powiadamia. Istnieją dwie ścieżki dostarczania:
-**Dostarczenie bezpośrednie** — jeśli zadanie ma docelowy kanał (`requesterOrigin`), wiadomość o zakończeniu trafia bezpośrednio do tego kanału (Telegram, Discord, Slack itd.). W przypadku zakończeń podagentów OpenClaw zachowuje również powiązane kierowanie wątkiem/tematem, gdy jest dostępne, i może uzupełnić brakujące `to` / konto ze ścieżki zapisanej w sesji żądającej (`lastChannel` / `lastTo` / `lastAccountId`) przed rezygnacją z bezpośredniego dostarczenia.
+**Dostarczenie bezpośrednie** — jeśli zadanie ma cel kanałowy (`requesterOrigin`), wiadomość o zakończeniu trafia bezpośrednio do tego kanału (Telegram, Discord, Slack itd.). W przypadku zakończeń subagentów OpenClaw zachowuje również powiązane kierowanie wątkiem/tematem, gdy jest dostępne, i może uzupełnić brakujące `to` / konto z zapisanej trasy sesji żądającej (`lastChannel` / `lastTo` / `lastAccountId`), zanim zrezygnuje z bezpośredniego dostarczenia.
-**Dostarczenie kolejkowane do sesji** — jeśli dostarczenie bezpośrednie się nie powiedzie lub nie ustawiono źródła, aktualizacja jest kolejkowana jako zdarzenie systemowe w sesji żądającego i pojawia się przy następnym Heartbeat.
+**Dostarczenie kolejkowane do sesji** — jeśli bezpośrednie dostarczenie się nie powiedzie lub nie ustawiono origin, aktualizacja jest kolejkowana jako zdarzenie systemowe w sesji żądającej i pojawia się przy następnym Heartbeat.
-Zakończenie zadania wywołuje natychmiastowe wybudzenie Heartbeat, dzięki czemu szybko widzisz wynik — nie musisz czekać na następny zaplanowany takt Heartbeat.
+Zakończenie zadania wyzwala natychmiastowe wybudzenie Heartbeat, dzięki czemu szybko widzisz wynik — nie musisz czekać na następny zaplanowany takt Heartbeat.
-Oznacza to, że typowy przepływ pracy jest oparty na wypychaniu: uruchom odłączoną pracę raz, a następnie pozwól środowisku uruchomieniowemu wybudzić Cię lub powiadomić po zakończeniu. Sonduj stan zadania tylko wtedy, gdy potrzebujesz debugowania, interwencji lub jawnego audytu.
+Oznacza to, że typowy przepływ pracy jest oparty na push: uruchom odłączoną pracę raz, a potem
+pozwól środowisku wykonawczemu wybudzić Cię lub powiadomić po zakończeniu. Odpytuj stan zadania tylko wtedy, gdy
+potrzebujesz debugowania, interwencji lub jawnego audytu.
### Polityki powiadomień
@@ -147,11 +153,11 @@ Kontroluj, ile informacji otrzymujesz o każdym zadaniu:
| Polityka | Co jest dostarczane |
| --------------------- | ------------------------------------------------------------------------ |
-| `done_only` (domyślnie) | Tylko stan terminalny (`succeeded`, `failed` itd.) — **to jest domyślne ustawienie** |
-| `state_changes` | Każda zmiana stanu i każda aktualizacja postępu |
+| `done_only` (domyślna) | Tylko stan końcowy (succeeded, failed itd.) — **to jest wartość domyślna** |
+| `state_changes` | Każda zmiana stanu i aktualizacja postępu |
| `silent` | Nic |
-Zmień politykę podczas działania zadania:
+Zmień politykę, gdy zadanie jest uruchomione:
```bash
openclaw tasks notify state_changes
@@ -165,7 +171,7 @@ openclaw tasks notify state_changes
openclaw tasks list [--runtime ] [--status ] [--json]
```
-Kolumny wyjściowe: ID zadania, rodzaj, status, dostarczenie, ID uruchomienia, sesja potomna, podsumowanie.
+Kolumny wyjściowe: ID zadania, rodzaj, status, dostarczanie, ID uruchomienia, sesja potomna, podsumowanie.
### `tasks show`
@@ -173,7 +179,7 @@ Kolumny wyjściowe: ID zadania, rodzaj, status, dostarczenie, ID uruchomienia, s
openclaw tasks show
```
-Token wyszukiwania akceptuje ID zadania, ID uruchomienia lub klucz sesji. Pokazuje pełny rekord, w tym czasy, stan dostarczenia, błąd i końcowe podsumowanie.
+Token lookup akceptuje ID zadania, ID uruchomienia lub klucz sesji. Pokazuje pełny rekord, w tym czasy, stan dostarczania, błąd i końcowe podsumowanie.
### `tasks cancel`
@@ -181,7 +187,7 @@ Token wyszukiwania akceptuje ID zadania, ID uruchomienia lub klucz sesji. Pokazu
openclaw tasks cancel
```
-W przypadku zadań ACP i podagentów powoduje to zakończenie sesji potomnej. W przypadku zadań śledzonych przez CLI anulowanie jest rejestrowane w rejestrze zadań (nie ma osobnego uchwytu środowiska uruchomieniowego potomka). Status przechodzi na `cancelled`, a gdy ma to zastosowanie, wysyłane jest powiadomienie o dostarczeniu.
+W przypadku zadań ACP i subagentów kończy to sesję potomną. W przypadku zadań śledzonych przez CLI anulowanie jest rejestrowane w rejestrze zadań (nie ma osobnego uchwytu potomnego środowiska wykonawczego). Status przechodzi do `cancelled`, a jeśli ma to zastosowanie, wysyłane jest powiadomienie o dostarczeniu.
### `tasks notify`
@@ -195,16 +201,16 @@ openclaw tasks notify
openclaw tasks audit [--json]
```
-Ujawnia problemy operacyjne. Wyniki pojawiają się również w `openclaw status`, gdy wykryte zostaną problemy.
+Ujawnia problemy operacyjne. Wykryte problemy pojawiają się również w `openclaw status`.
-| Wynik | Ważność | Wyzwalacz |
-| ------------------------- | ------- | --------------------------------------------------- |
-| `stale_queued` | warn | W kolejce dłużej niż 10 minut |
-| `stale_running` | error | Działa dłużej niż 30 minut |
-| `lost` | error | Zniknęła własność zadania oparta na środowisku uruchomieniowym |
-| `delivery_failed` | warn | Dostarczenie nie powiodło się, a polityka powiadomień nie jest `silent` |
-| `missing_cleanup` | warn | Zadanie terminalne bez znacznika czasu czyszczenia |
-| `inconsistent_timestamps` | warn | Naruszenie osi czasu (na przykład zakończono przed rozpoczęciem) |
+| Ustalenie | Poziom ważności | Wyzwalacz |
+| ------------------------- | --------------- | ---------------------------------------------------- |
+| `stale_queued` | warn | Oczekiwanie przez ponad 10 minut |
+| `stale_running` | error | Uruchomione przez ponad 30 minut |
+| `lost` | error | Zniknęła własność zadania oparta na środowisku wykonawczym |
+| `delivery_failed` | warn | Dostarczenie nie powiodło się, a polityka powiadomień nie jest `silent` |
+| `missing_cleanup` | warn | Zadanie końcowe bez sygnatury czasowej czyszczenia |
+| `inconsistent_timestamps` | warn | Naruszenie osi czasu (na przykład zakończenie przed rozpoczęciem) |
### `tasks maintenance`
@@ -213,20 +219,22 @@ openclaw tasks maintenance [--json]
openclaw tasks maintenance --apply [--json]
```
-Użyj tego, aby wyświetlić podgląd lub zastosować uzgadnianie, oznaczanie czyszczenia i usuwanie przestarzałych danych dla zadań oraz stanu Task Flow.
+Użyj tego, aby wyświetlić podgląd lub zastosować uzgadnianie, oznaczanie czyszczenia i przycinanie dla
+zadań oraz stanu Task Flow.
-Uzgadnianie zależy od środowiska uruchomieniowego:
+Uzgadnianie zależy od środowiska wykonawczego:
-- Zadania ACP/podagentów sprawdzają swoją potomną sesję zaplecza.
-- Zadania Cron sprawdzają, czy środowisko uruchomieniowe Cron nadal jest właścicielem zadania.
-- Zadania CLI oparte na czacie sprawdzają kontekst aktywnego uruchomienia będący właścicielem, a nie tylko wiersz sesji czatu.
+- Zadania ACP/subagentów sprawdzają swoją potomną sesję zaplecza.
+- Zadania Cron sprawdzają, czy środowisko wykonawcze Cron nadal jest właścicielem zadania.
+- Zadania CLI oparte na czacie sprawdzają aktywny kontekst uruchomienia będący właścicielem, a nie tylko wiersz sesji czatu.
-Czyszczenie po zakończeniu również zależy od środowiska uruchomieniowego:
+Czyszczenie po zakończeniu również zależy od środowiska wykonawczego:
-- Zakończenie podagenta w miarę możliwości zamyka śledzone karty/procesy przeglądarki dla sesji potomnej, zanim będzie kontynuowane ogłaszanie czyszczenia.
-- Zakończenie izolowanego Cron w miarę możliwości zamyka śledzone karty/procesy przeglądarki dla sesji Cron, zanim uruchomienie zostanie całkowicie zakończone.
-- Dostarczanie izolowanego Cron w razie potrzeby czeka na dalsze działania potomnych podagentów i tłumi nieaktualny tekst potwierdzenia nadrzędnego zamiast go ogłaszać.
-- Dostarczanie zakończenia podagenta preferuje najnowszy widoczny tekst asystenta; jeśli jest pusty, wraca do oczyszczonego najnowszego tekstu `tool`/`toolResult`, a uruchomienia wyłącznie wywołania narzędzia zakończone timeoutem mogą zostać zredukowane do krótkiego podsumowania częściowego postępu.
+- Zakończenie subagenta w miarę możliwości zamyka śledzone karty/procesy przeglądarki dla sesji potomnej, zanim będzie kontynuowane czyszczenie po ogłoszeniu.
+- Zakończenie izolowanego Cron w miarę możliwości zamyka śledzone karty/procesy przeglądarki dla sesji Cron, zanim uruchomienie zostanie całkowicie zamknięte.
+- Dostarczanie dla izolowanego Cron w razie potrzeby czeka na dalsze działania potomnych subagentów
+ i tłumi nieaktualny tekst potwierdzenia rodzica zamiast go ogłaszać.
+- Dostarczanie zakończenia subagenta preferuje najnowszy widoczny tekst asystenta; jeśli jest pusty, wraca do oczyszczonego najnowszego tekstu tool/toolResult, a uruchomienia zawierające wyłącznie wywołania narzędzia zakończone limitem czasu mogą zostać zredukowane do krótkiego podsumowania częściowego postępu. Końcowe nieudane uruchomienia ogłaszają status niepowodzenia bez odtwarzania przechwyconego tekstu odpowiedzi.
- Błędy czyszczenia nie maskują rzeczywistego wyniku zadania.
### `tasks flow list|show|cancel`
@@ -237,12 +245,13 @@ openclaw tasks flow show [--json]
openclaw tasks flow cancel
```
-Używaj tych poleceń, gdy interesuje Cię orkiestrujący TaskFlow, a nie pojedynczy rekord zadania w tle.
+Używaj tych poleceń, gdy interesuje Cię orkiestrujący TaskFlow, a nie
+pojedynczy rekord zadania w tle.
## Tablica zadań czatu (`/tasks`)
Użyj `/tasks` w dowolnej sesji czatu, aby zobaczyć zadania w tle powiązane z tą sesją. Tablica pokazuje
-aktywne i niedawno zakończone zadania wraz ze środowiskiem uruchomieniowym, statusem, czasem oraz szczegółami postępu lub błędu.
+aktywne i niedawno zakończone zadania wraz ze środowiskiem wykonawczym, statusem, czasem oraz szczegółami postępu lub błędu.
Gdy bieżąca sesja nie ma widocznych powiązanych zadań, `/tasks` przełącza się na lokalne dla agenta liczniki zadań,
dzięki czemu nadal otrzymujesz przegląd bez ujawniania szczegółów innych sesji.
@@ -251,7 +260,7 @@ Aby zobaczyć pełny rejestr operatora, użyj CLI: `openclaw tasks list`.
## Integracja statusu (obciążenie zadaniami)
-`openclaw status` zawiera podsumowanie zadań widoczne na pierwszy rzut oka:
+`openclaw status` zawiera krótkie podsumowanie zadań:
```
Tasks: 3 queued · 2 running · 1 issues
@@ -263,43 +272,43 @@ Podsumowanie raportuje:
- **failures** — liczba `failed` + `timed_out` + `lost`
- **byRuntime** — podział według `acp`, `subagent`, `cron`, `cli`
-Zarówno `/status`, jak i narzędzie `session_status` używają migawki zadań uwzględniającej czyszczenie: aktywne zadania są preferowane,
-nieaktualne ukończone wiersze są ukrywane, a niedawne błędy są pokazywane tylko wtedy, gdy nie pozostała żadna aktywna praca.
-Dzięki temu karta statusu skupia się na tym, co ma znaczenie w danej chwili.
+Zarówno `/status`, jak i narzędzie `session_status` używają uwzględniającej czyszczenie migawki zadań: aktywne zadania są
+preferowane, nieaktualne ukończone wiersze są ukrywane, a niedawne niepowodzenia są pokazywane tylko wtedy, gdy nie
+pozostała żadna aktywna praca. Dzięki temu karta statusu skupia się na tym, co ma znaczenie teraz.
## Przechowywanie i konserwacja
-### Gdzie znajdują się zadania
+### Gdzie przechowywane są zadania
-Rekordy zadań są trwale przechowywane w SQLite pod adresem:
+Rekordy zadań są trwale zapisywane w SQLite pod adresem:
```
$OPENCLAW_STATE_DIR/tasks/runs.sqlite
```
-Rejestr jest ładowany do pamięci przy uruchomieniu Gateway i synchronizuje zapisy do SQLite, aby zapewnić trwałość po restartach.
+Rejestr jest ładowany do pamięci przy starcie Gateway i synchronizuje zapisy do SQLite, aby zapewnić trwałość po restartach.
### Automatyczna konserwacja
-Mechanizm czyszczący uruchamia się co **60 sekund** i obsługuje trzy rzeczy:
+Co **60 sekund** uruchamiany jest proces czyszczący, który obsługuje trzy rzeczy:
-1. **Uzgadnianie** — sprawdza, czy aktywne zadania nadal mają autorytatywne zaplecze środowiska uruchomieniowego. Zadania ACP/podagentów używają stanu sesji potomnej, zadania Cron używają własności aktywnego zadania, a zadania CLI oparte na czacie używają kontekstu uruchomienia będącego właścicielem. Jeśli ten stan zaplecza zniknie na dłużej niż 5 minut, zadanie jest oznaczane jako `lost`.
-2. **Oznaczanie czyszczenia** — ustawia znacznik czasu `cleanupAfter` dla zadań terminalnych (`endedAt` + 7 dni).
-3. **Usuwanie przestarzałych danych** — usuwa rekordy po dacie `cleanupAfter`.
+1. **Uzgadnianie** — sprawdza, czy aktywne zadania nadal mają autorytatywne zaplecze środowiska wykonawczego. Zadania ACP/subagentów używają stanu sesji potomnej, zadania Cron używają własności aktywnego zadania, a zadania CLI oparte na czacie używają kontekstu uruchomienia będącego właścicielem. Jeśli ten stan zaplecza zniknie na ponad 5 minut, zadanie zostanie oznaczone jako `lost`.
+2. **Oznaczanie czyszczenia** — ustawia znacznik czasu `cleanupAfter` dla zadań końcowych (`endedAt` + 7 dni).
+3. **Przycinanie** — usuwa rekordy po dacie `cleanupAfter`.
-**Retencja**: rekordy zadań terminalnych są przechowywane przez **7 dni**, a następnie automatycznie usuwane. Nie jest wymagana żadna konfiguracja.
+**Retencja**: rekordy zadań końcowych są przechowywane przez **7 dni**, a następnie automatycznie przycinane. Nie jest wymagana żadna konfiguracja.
## Jak zadania odnoszą się do innych systemów
### Zadania i Task Flow
-[Task Flow](/pl/automation/taskflow) to warstwa orkiestracji przepływów ponad zadaniami w tle. Pojedynczy przepływ może w trakcie swojego cyklu życia koordynować wiele zadań przy użyciu zarządzanych lub lustrzanych trybów synchronizacji. Użyj `openclaw tasks`, aby sprawdzić poszczególne rekordy zadań, oraz `openclaw tasks flow`, aby sprawdzić przepływ orkiestrujący.
+[Task Flow](/pl/automation/taskflow) to warstwa orkiestracji przepływów ponad zadaniami w tle. Pojedynczy przepływ może w ciągu swojego życia koordynować wiele zadań, używając zarządzanych lub lustrzanych trybów synchronizacji. Użyj `openclaw tasks`, aby sprawdzić poszczególne rekordy zadań, oraz `openclaw tasks flow`, aby sprawdzić przepływ orkiestrujący.
Szczegóły znajdziesz w [Task Flow](/pl/automation/taskflow).
### Zadania i Cron
-**Definicja** zadania Cron znajduje się w `~/.openclaw/cron/jobs.json`; stan wykonania środowiska uruchomieniowego znajduje się obok niej w `~/.openclaw/cron/jobs-state.json`. **Każde** wykonanie Cron tworzy rekord zadania — zarówno w sesji głównej, jak i w trybie izolowanym. Zadania Cron w sesji głównej domyślnie używają polityki powiadomień `silent`, dzięki czemu są śledzone bez generowania powiadomień.
+**Definicja** zadania Cron znajduje się w `~/.openclaw/cron/jobs.json`; stan wykonania środowiska uruchomieniowego znajduje się obok w `~/.openclaw/cron/jobs-state.json`. **Każde** wykonanie Cron tworzy rekord zadania — zarówno w sesji głównej, jak i izolowane. Zadania Cron w sesji głównej domyślnie używają polityki powiadomień `silent`, dzięki czemu są śledzone bez generowania powiadomień.
Zobacz [Zadania Cron](/pl/automation/cron-jobs).
@@ -311,16 +320,16 @@ Zobacz [Heartbeat](/pl/gateway/heartbeat).
### Zadania i sesje
-Zadanie może odwoływać się do `childSessionKey` (gdzie wykonywana jest praca) oraz `requesterSessionKey` (kto ją uruchomił). Sesje to kontekst rozmowy; zadania to śledzenie aktywności ponad tym kontekstem.
+Zadanie może odwoływać się do `childSessionKey` (gdzie uruchamiana jest praca) oraz `requesterSessionKey` (kto ją uruchomił). Sesje to kontekst rozmowy; zadania to warstwa śledzenia aktywności ponad nim.
-### Zadania i uruchomienia agenta
+### Zadania i uruchomienia agentów
-`runId` zadania wskazuje na uruchomienie agenta wykonujące pracę. Zdarzenia cyklu życia agenta (start, koniec, błąd) automatycznie aktualizują status zadania — nie musisz ręcznie zarządzać cyklem życia.
+`runId` zadania łączy je z uruchomieniem agenta wykonującym pracę. Zdarzenia cyklu życia agenta (start, koniec, błąd) automatycznie aktualizują status zadania — nie musisz ręcznie zarządzać cyklem życia.
## Powiązane
- [Automatyzacja i zadania](/pl/automation) — przegląd wszystkich mechanizmów automatyzacji
- [Task Flow](/pl/automation/taskflow) — orkiestracja przepływów ponad zadaniami
-- [Zaplanowane zadania](/pl/automation/cron-jobs) — harmonogramowanie pracy w tle
+- [Zaplanowane zadania](/pl/automation/cron-jobs) — planowanie pracy w tle
- [Heartbeat](/pl/gateway/heartbeat) — okresowe tury sesji głównej
- [CLI: Tasks](/cli/index#tasks) — dokumentacja poleceń CLI
diff --git a/docs/pl/channels/synology-chat.md b/docs/pl/channels/synology-chat.md
index 4def97467..11d10f524 100644
--- a/docs/pl/channels/synology-chat.md
+++ b/docs/pl/channels/synology-chat.md
@@ -1,27 +1,27 @@
---
read_when:
- Konfigurowanie Synology Chat z OpenClaw
- - Debugowanie routingu webhooków Synology Chat
-summary: Konfiguracja webhooków Synology Chat i OpenClaw
+ - Debugowanie routingu webhooka Synology Chat
+summary: Konfiguracja webhooka Synology Chat i konfiguracja OpenClaw
title: Synology Chat
x-i18n:
- generated_at: "2026-04-05T13:45:55Z"
+ generated_at: "2026-04-21T19:20:44Z"
model: gpt-5.4
provider: openai
- source_hash: ddb25fc6b53f896f15f43b4936d69ea071a29a91838a5b662819377271e89d81
+ source_hash: 7288e2aa873ee1a1f57861d839cfb44ff324e3d40a7f36da07c6ba43cbe1e6e6
source_path: channels/synology-chat.md
workflow: 15
---
# Synology Chat
-Status: dołączony plugin kanału wiadomości bezpośrednich używający webhooków Synology Chat.
+Status: dołączony Plugin kanału wiadomości bezpośrednich używający webhooków Synology Chat.
Plugin przyjmuje wiadomości przychodzące z webhooków wychodzących Synology Chat i wysyła odpowiedzi
przez webhook przychodzący Synology Chat.
-## Dołączony plugin
+## Dołączony Plugin
-Synology Chat jest dostarczany jako dołączony plugin w bieżących wydaniach OpenClaw, więc zwykłe
+Synology Chat jest dostarczany jako dołączony Plugin w bieżących wydaniach OpenClaw, więc zwykłe
spakowane kompilacje nie wymagają osobnej instalacji.
Jeśli używasz starszej kompilacji lub niestandardowej instalacji, która nie zawiera Synology Chat,
@@ -33,25 +33,25 @@ Zainstaluj z lokalnego checkoutu:
openclaw plugins install ./path/to/local/synology-chat-plugin
```
-Szczegóły: [Plugins](/tools/plugin)
+Szczegóły: [Plugins](/pl/tools/plugin)
## Szybka konfiguracja
-1. Upewnij się, że plugin Synology Chat jest dostępny.
+1. Upewnij się, że Plugin Synology Chat jest dostępny.
- Bieżące spakowane wydania OpenClaw już go zawierają.
- Starsze/niestandardowe instalacje mogą dodać go ręcznie z checkoutu źródeł za pomocą powyższego polecenia.
- - `openclaw onboard` wyświetla teraz Synology Chat na tej samej liście konfiguracji kanałów co `openclaw channels add`.
+ - `openclaw onboard` pokazuje teraz Synology Chat na tej samej liście konfiguracji kanałów co `openclaw channels add`.
- Konfiguracja nieinteraktywna: `openclaw channels add --channel synology-chat --token --url `
2. W integracjach Synology Chat:
- Utwórz webhook przychodzący i skopiuj jego URL.
- - Utwórz webhook wychodzący z tajnym tokenem.
-3. Skieruj URL webhooka wychodzącego do swojej bramy OpenClaw:
+ - Utwórz webhook wychodzący ze swoim tajnym tokenem.
+3. Skieruj URL webhooka wychodzącego do swojego Gateway OpenClaw:
- Domyślnie `https://gateway-host/webhook/synology`.
- - Lub do niestandardowego `channels.synology-chat.webhookPath`.
+ - Albo do własnego `channels.synology-chat.webhookPath`.
4. Dokończ konfigurację w OpenClaw.
- Z przewodnikiem: `openclaw onboard`
- Bezpośrednio: `openclaw channels add --channel synology-chat --token --url `
-5. Uruchom ponownie bramę i wyślij DM do bota Synology Chat.
+5. Uruchom ponownie Gateway i wyślij wiadomość bezpośrednią do bota Synology Chat.
Szczegóły uwierzytelniania webhooka:
@@ -62,7 +62,7 @@ Szczegóły uwierzytelniania webhooka:
- `x-webhook-token`
- `x-openclaw-token`
- `Authorization: Bearer `
-- Puste lub brakujące tokeny są odrzucane w trybie fail-closed.
+- Puste lub brakujące tokeny powodują bezpieczne odrzucenie.
Minimalna konfiguracja:
@@ -94,16 +94,16 @@ Dla konta domyślnego możesz użyć zmiennych środowiskowych:
- `SYNOLOGY_RATE_LIMIT`
- `OPENCLAW_BOT_NAME`
-Wartości konfiguracyjne zastępują zmienne środowiskowe.
+Wartości konfiguracji mają pierwszeństwo przed zmiennymi środowiskowymi.
-## Zasady DM i kontrola dostępu
+## Polityka wiadomości bezpośrednich i kontrola dostępu
-- `dmPolicy: "allowlist"` to zalecana wartość domyślna.
-- `allowedUserIds` akceptuje listę (lub ciąg rozdzielany przecinkami) identyfikatorów użytkowników Synology.
+- `dmPolicy: "allowlist"` to zalecane ustawienie domyślne.
+- `allowedUserIds` przyjmuje listę (lub ciąg rozdzielany przecinkami) identyfikatorów użytkowników Synology.
- W trybie `allowlist` pusta lista `allowedUserIds` jest traktowana jako błędna konfiguracja i trasa webhooka nie zostanie uruchomiona (użyj `dmPolicy: "open"` dla zezwolenia wszystkim).
-- `dmPolicy: "open"` pozwala każdemu nadawcy.
-- `dmPolicy: "disabled"` blokuje DM.
-- Powiązanie odbiorcy odpowiedzi domyślnie pozostaje oparte na stabilnym numerycznym `user_id`. `channels.synology-chat.dangerouslyAllowNameMatching: true` to awaryjny tryb zgodności, który ponownie włącza wyszukiwanie po zmiennej nazwie użytkownika/pseudonimie na potrzeby dostarczania odpowiedzi.
+- `dmPolicy: "open"` zezwala każdemu nadawcy.
+- `dmPolicy: "disabled"` blokuje wiadomości bezpośrednie.
+- Powiązanie odbiorcy odpowiedzi domyślnie pozostaje oparte na stabilnym numerycznym `user_id`. `channels.synology-chat.dangerouslyAllowNameMatching: true` to awaryjny tryb zgodności, który ponownie włącza wyszukiwanie po zmiennej nazwie użytkownika/pseudonimie przy dostarczaniu odpowiedzi.
- Zatwierdzanie parowania działa z:
- `openclaw pairing list synology-chat`
- `openclaw pairing approve synology-chat `
@@ -120,18 +120,19 @@ openclaw message send --channel synology-chat --target synology-chat:123456 --te
```
Wysyłanie multimediów jest obsługiwane przez dostarczanie plików oparte na URL.
+Wychodzące URL-e plików muszą używać `http` lub `https`, a prywatne lub w inny sposób zablokowane cele sieciowe są odrzucane, zanim OpenClaw przekaże URL do webhooka NAS.
## Wiele kont
Wiele kont Synology Chat jest obsługiwanych w `channels.synology-chat.accounts`.
-Każde konto może nadpisać token, URL przychodzący, ścieżkę webhooka, zasady DM i limity.
-Sesje wiadomości bezpośrednich są izolowane dla każdego konta i użytkownika, więc ten sam numeryczny `user_id`
+Każde konto może nadpisywać token, URL przychodzący, ścieżkę webhooka, politykę wiadomości bezpośrednich i limity.
+Sesje wiadomości bezpośrednich są izolowane per konto i użytkownik, więc ten sam numeryczny `user_id`
na dwóch różnych kontach Synology nie współdzieli stanu transkrypcji.
-Nadaj każdemu włączonemu kontu odrębny `webhookPath`. OpenClaw odrzuca teraz zduplikowane dokładne ścieżki
-i odmawia uruchomienia nazwanych kont, które w konfiguracjach wielokontowych dziedziczą wyłącznie wspólną ścieżkę webhooka.
+Nadaj każdemu włączonemu kontu odrębny `webhookPath`. OpenClaw odrzuca teraz zduplikowane identyczne ścieżki
+i odmawia uruchomienia nazwanych kont, które dziedziczą tylko współdzieloną ścieżkę webhooka w konfiguracjach wielokontowych.
Jeśli celowo potrzebujesz starszego dziedziczenia dla nazwanego konta, ustaw
-`dangerouslyAllowInheritedWebhookPath: true` na tym koncie lub w `channels.synology-chat`,
-ale zduplikowane dokładne ścieżki nadal są odrzucane w trybie fail-closed. Preferuj jawne ścieżki dla każdego konta.
+`dangerouslyAllowInheritedWebhookPath: true` dla tego konta albo w `channels.synology-chat`,
+ale zduplikowane identyczne ścieżki nadal są odrzucane w trybie bezpiecznego domknięcia. Preferuj jawne ścieżki per konto.
```json5
{
@@ -159,25 +160,25 @@ ale zduplikowane dokładne ścieżki nadal są odrzucane w trybie fail-closed. P
## Uwagi dotyczące bezpieczeństwa
- Zachowaj `token` w tajemnicy i zmień go, jeśli wycieknie.
-- Pozostaw `allowInsecureSsl: false`, chyba że wyraźnie ufasz lokalnemu certyfikatowi self-signed NAS.
-- Żądania przychodzących webhooków są weryfikowane tokenem i ograniczane szybkością na nadawcę.
-- Kontrole nieprawidłowych tokenów używają porównywania sekretów w stałym czasie i działają w trybie fail-closed.
+- Zachowaj `allowInsecureSsl: false`, chyba że jawnie ufasz lokalnemu certyfikatowi NAS z podpisem własnym.
+- Przychodzące żądania webhooka są weryfikowane tokenem i ograniczane szybkościowo per nadawca.
+- Sprawdzanie nieprawidłowego tokena używa porównania sekretów w czasie stałym i bezpiecznie odrzuca.
- W środowisku produkcyjnym preferuj `dmPolicy: "allowlist"`.
-- Pozostaw `dangerouslyAllowNameMatching` wyłączone, chyba że wyraźnie potrzebujesz starszego dostarczania odpowiedzi opartego na nazwie użytkownika.
-- Pozostaw `dangerouslyAllowInheritedWebhookPath` wyłączone, chyba że wyraźnie akceptujesz ryzyko routingu współdzielonej ścieżki w konfiguracji wielokontowej.
+- Pozostaw `dangerouslyAllowNameMatching` wyłączone, chyba że jawnie potrzebujesz starszego dostarczania odpowiedzi opartego na nazwie użytkownika.
+- Pozostaw `dangerouslyAllowInheritedWebhookPath` wyłączone, chyba że jawnie akceptujesz ryzyko routingu po współdzielonej ścieżce w konfiguracji wielokontowej.
## Rozwiązywanie problemów
- `Missing required fields (token, user_id, text)`:
- w ładunku webhooka wychodzącego brakuje jednego z wymaganych pól
- - jeśli Synology wysyła token w nagłówkach, upewnij się, że brama/proxy zachowuje te nagłówki
+ - jeśli Synology wysyła token w nagłówkach, upewnij się, że Gateway/proxy zachowuje te nagłówki
- `Invalid token`:
- sekret webhooka wychodzącego nie pasuje do `channels.synology-chat.token`
- żądanie trafia do niewłaściwego konta/ścieżki webhooka
- reverse proxy usunęło nagłówek tokena, zanim żądanie dotarło do OpenClaw
- `Rate limit exceeded`:
- zbyt wiele prób z nieprawidłowym tokenem z tego samego źródła może tymczasowo zablokować to źródło
- - uwierzytelnieni nadawcy mają też oddzielny limit szybkości wiadomości na użytkownika
+ - uwierzytelnieni nadawcy mają też osobny limit szybkości wiadomości per użytkownik
- `Allowlist is empty. Configure allowedUserIds or use dmPolicy=open.`:
- `dmPolicy="allowlist"` jest włączone, ale nie skonfigurowano żadnych użytkowników
- `User not authorized`:
@@ -186,7 +187,7 @@ ale zduplikowane dokładne ścieżki nadal są odrzucane w trybie fail-closed. P
## Powiązane
- [Channels Overview](/pl/channels) — wszystkie obsługiwane kanały
-- [Pairing](/pl/channels/pairing) — uwierzytelnianie DM i przepływ parowania
+- [Pairing](/pl/channels/pairing) — uwierzytelnianie wiadomości bezpośrednich i przepływ parowania
- [Groups](/pl/channels/groups) — zachowanie czatów grupowych i bramkowanie wzmianek
-- [Channel Routing](/pl/channels/channel-routing) — routing sesji dla wiadomości
-- [Security](/gateway/security) — model dostępu i utwardzanie
+- [Channel Routing](/pl/channels/channel-routing) — routowanie sesji dla wiadomości
+- [Security](/pl/gateway/security) — model dostępu i utwardzanie
diff --git a/docs/pl/ci.md b/docs/pl/ci.md
index 61ac855f4..4ae2277dc 100644
--- a/docs/pl/ci.md
+++ b/docs/pl/ci.md
@@ -1,66 +1,66 @@
---
read_when:
- - Musisz zrozumieć, dlaczego zadanie CI uruchomiło się lub nie uruchomiło.
- - Debugujesz nieudane sprawdzenia GitHub Actions.
+ - Musisz zrozumieć, dlaczego zadanie CI zostało lub nie zostało uruchomione.
+ - Debugujesz nieudane kontrole GitHub Actions.
summary: Graf zadań CI, bramki zakresu i lokalne odpowiedniki poleceń
title: Potok CI
x-i18n:
- generated_at: "2026-04-21T09:52:56Z"
+ generated_at: "2026-04-21T19:20:44Z"
model: gpt-5.4
provider: openai
- source_hash: 88a98d777fd61be1603417b71779aaf42a24d602b2437ad549f0075f22494cec
+ source_hash: 4d01a178402976cdf7c3c864695e8a12d3f7d1d069a77ea1b02a8aef2a3497f7
source_path: ci.md
workflow: 15
---
# Potok CI
-CI uruchamia się przy każdym pushu do `main` i dla każdego pull requesta. Używa inteligentnego określania zakresu, aby pomijać kosztowne zadania, gdy zmieniły się tylko niepowiązane obszary.
+CI uruchamia się przy każdym wypchnięciu do `main` i dla każdego pull requesta. Używa inteligentnego zawężania zakresu, aby pomijać kosztowne zadania, gdy zmieniły się tylko niepowiązane obszary.
## Przegląd zadań
-| Zadanie | Cel | Kiedy się uruchamia |
-| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- |
-| `preflight` | Wykrywa zmiany tylko w dokumentacji, zmienione zakresy, zmienione rozszerzenia i buduje manifest CI | Zawsze przy pushach i PR-ach, które nie są draftami |
-| `security-scm-fast` | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor` | Zawsze przy pushach i PR-ach, które nie są draftami |
-| `security-dependency-audit` | Audyt produkcyjnego lockfile bez zależności względem ostrzeżeń npm | Zawsze przy pushach i PR-ach, które nie są draftami |
-| `security-fast` | Wymagany agregat dla szybkich zadań bezpieczeństwa | Zawsze przy pushach i PR-ach, które nie są draftami |
-| `build-artifacts` | Buduje `dist/` i Control UI jeden raz, przesyła artefakty wielokrotnego użytku dla zadań podrzędnych | Zmiany istotne dla Node |
-| `checks-fast-core` | Szybkie linie poprawności na Linuksie, takie jak sprawdzenia bundled/plugin-contract/protocol | Zmiany istotne dla Node |
-| `checks-fast-contracts-channels` | Szardowane sprawdzenia kontraktów kanałów ze stabilnym zagregowanym wynikiem | Zmiany istotne dla Node |
-| `checks-node-extensions` | Pełne szardy testów bundled plugins w całym zestawie rozszerzeń | Zmiany istotne dla Node |
-| `checks-node-core-test` | Szardy testów core Node, z wyłączeniem linii kanałów, bundled, kontraktów i rozszerzeń | Zmiany istotne dla Node |
-| `extension-fast` | Ukierunkowane testy tylko dla zmienionych bundled plugins | Gdy wykryto zmiany w rozszerzeniach |
-| `check` | Szardowany odpowiednik głównej lokalnej bramki: typy prod, lint, guardy, typy testów i strict smoke | Zmiany istotne dla Node |
-| `check-additional` | Szardy architektury, granic, guardów powierzchni rozszerzeń, granic pakietów i gateway-watch | Zmiany istotne dla Node |
-| `build-smoke` | Testy smoke zbudowanego CLI i smoke pamięci przy starcie | Zmiany istotne dla Node |
-| `checks` | Pozostałe linie Linux Node: testy kanałów i zgodność tylko dla pushy z Node 22 | Zmiany istotne dla Node |
-| `check-docs` | Formatowanie dokumentacji, lint i sprawdzanie uszkodzonych linków | Gdy zmieniła się dokumentacja |
-| `skills-python` | Ruff + pytest dla Skills opartych na Pythonie | Zmiany istotne dla Skills w Pythonie |
-| `checks-windows` | Linie testów specyficzne dla Windows | Zmiany istotne dla Windows |
-| `macos-node` | Linia testów TypeScript na macOS z użyciem współdzielonych zbudowanych artefaktów | Zmiany istotne dla macOS |
-| `macos-swift` | Swift lint, build i testy dla aplikacji macOS | Zmiany istotne dla macOS |
-| `android` | Macierz buildów i testów Androida | Zmiany istotne dla Androida |
+| Zadanie | Cel | Kiedy się uruchamia |
+| -------------------------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------- |
+| `preflight` | Wykrywanie zmian tylko w dokumentacji, zmienionych zakresów, zmienionych rozszerzeń oraz budowanie manifestu CI | Zawsze przy pushach i PR-ach, które nie są draftami |
+| `security-scm-fast` | Wykrywanie kluczy prywatnych i audyt workflowów przez `zizmor` | Zawsze przy pushach i PR-ach, które nie są draftami |
+| `security-dependency-audit` | Audyt produkcyjnego lockfile bez zależności względem ostrzeżeń npm | Zawsze przy pushach i PR-ach, które nie są draftami |
+| `security-fast` | Wymagane zadanie zbiorcze dla szybkich zadań bezpieczeństwa | Zawsze przy pushach i PR-ach, które nie są draftami |
+| `build-artifacts` | Jednorazowe budowanie `dist/` i interfejsu Control UI, przesyłanie artefaktów wielokrotnego użytku dla zadań podrzędnych | Zmiany istotne dla Node |
+| `checks-fast-core` | Szybkie ścieżki poprawności na Linuksie, takie jak sprawdzenia bundled/plugin-contract/protocol | Zmiany istotne dla Node |
+| `checks-fast-contracts-channels` | Szardowane sprawdzenia kontraktów kanałów ze stabilnym zbiorczym wynikiem sprawdzenia | Zmiany istotne dla Node |
+| `checks-node-extensions` | Pełne szardy testów bundled plugins dla całego zestawu rozszerzeń | Zmiany istotne dla Node |
+| `checks-node-core-test` | Szardy testów głównego Node, z wyłączeniem ścieżek kanałów, bundled, kontraktów i rozszerzeń | Zmiany istotne dla Node |
+| `extension-fast` | Ukierunkowane testy tylko dla zmienionych bundled plugins | Gdy wykryto zmiany rozszerzeń |
+| `check` | Szardowany odpowiednik głównej lokalnej bramki: typy prod, lint, guardy, typy testów i ścisły smoke | Zmiany istotne dla Node |
+| `check-additional` | Guardy architektury, granic, powierzchni rozszerzeń, granic pakietów i szardy gateway-watch | Zmiany istotne dla Node |
+| `build-smoke` | Testy smoke zbudowanego CLI i smoke pamięci przy uruchamianiu | Zmiany istotne dla Node |
+| `checks` | Pozostałe ścieżki Linux Node: testy kanałów i zgodność Node 22 tylko dla pushy | Zmiany istotne dla Node |
+| `check-docs` | Sprawdzanie formatowania dokumentacji, lint i niedziałających linków | Zmieniono dokumentację |
+| `skills-python` | Ruff + pytest dla Skills opartych na Pythonie | Zmiany istotne dla Skills w Pythonie |
+| `checks-windows` | Ścieżki testowe specyficzne dla Windows | Zmiany istotne dla Windows |
+| `macos-node` | Ścieżka testów TypeScript na macOS z użyciem współdzielonych zbudowanych artefaktów | Zmiany istotne dla macOS |
+| `macos-swift` | Lint, build i testy Swift dla aplikacji macOS | Zmiany istotne dla macOS |
+| `android` | Macierz buildów i testów Androida | Zmiany istotne dla Androida |
## Kolejność fail-fast
-Zadania są uporządkowane tak, aby tanie sprawdzenia kończyły się błędem, zanim uruchomią się drogie:
+Zadania są uporządkowane tak, aby tanie sprawdzenia kończyły się błędem, zanim uruchomią się droższe:
-1. `preflight` decyduje, które linie w ogóle istnieją. Logika `docs-scope` i `changed-scope` to kroki wewnątrz tego zadania, a nie osobne zadania.
-2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` i `skills-python` kończą się szybko bez czekania na cięższe zadania artefaktów i macierzy platform.
-3. `build-artifacts` nakłada się na szybkie linie Linuksa, aby odbiorcy podrzędni mogli wystartować, gdy tylko wspólny build będzie gotowy.
-4. Następnie rozgałęziają się cięższe linie platform i środowisk uruchomieniowych: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` i `android`.
+1. `preflight` decyduje, które ścieżki w ogóle istnieją. Logika `docs-scope` i `changed-scope` to kroki wewnątrz tego zadania, a nie osobne zadania.
+2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` i `skills-python` szybko kończą się błędem bez czekania na cięższe zadania artefaktów i macierzy platform.
+3. `build-artifacts` nakłada się na szybkie ścieżki Linux, aby zadania podrzędne mogły rozpocząć się, gdy współdzielony build będzie gotowy.
+4. Cięższe ścieżki platform i runtime rozgałęziają się potem: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` i `android`.
-Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest pokryta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`.
-Osobny workflow `install-smoke` używa ponownie tego samego skryptu zakresu przez własne zadanie `preflight`. Oblicza `run_install_smoke` na podstawie węższego sygnału changed-smoke, więc smoke Docker/install uruchamia się tylko dla zmian istotnych dla instalacji, pakowania i kontenerów.
+Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest objęta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`.
+Osobny workflow `install-smoke` ponownie używa tego samego skryptu zakresu przez własne zadanie `preflight`. Oblicza `run_install_smoke` na podstawie węższego sygnału changed-smoke, więc smoke Dockera/instalacji uruchamia się tylko przy zmianach istotnych dla instalacji, pakietowania i kontenerów.
-Lokalna logika zmienionych linii znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka jest bardziej rygorystyczna względem granic architektury niż szeroki zakres platform CI: zmiany produkcyjne core uruchamiają typecheck prod core plus testy core, zmiany tylko w testach core uruchamiają tylko typecheck/testy testowe core, zmiany produkcyjne rozszerzeń uruchamiają typecheck prod rozszerzeń plus testy rozszerzeń, a zmiany tylko w testach rozszerzeń uruchamiają tylko typecheck/testy testowe rozszerzeń. Zmiany w publicznym Plugin SDK lub plugin-contract rozszerzają walidację na rozszerzenia, ponieważ rozszerzenia zależą od tych kontraktów core. Nieznane zmiany w katalogu głównym/konfiguracji bezpiecznie rozszerzają się na wszystkie linie.
+Lokalna logika changed-lane znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka jest bardziej rygorystyczna względem granic architektury niż szeroki zakres platform CI: zmiany w produkcyjnym core uruchamiają typecheck prod core oraz testy core, zmiany tylko w testach core uruchamiają tylko typecheck/testy testów core, zmiany w produkcyjnych rozszerzeniach uruchamiają typecheck prod rozszerzeń oraz testy rozszerzeń, a zmiany tylko w testach rozszerzeń uruchamiają tylko typecheck/testy testów rozszerzeń. Zmiany w publicznym Plugin SDK lub plugin-contract rozszerzają walidację na rozszerzenia, ponieważ rozszerzenia zależą od tych kontraktów core. Nieznane zmiany w katalogu głównym lub konfiguracji bezpiecznie przechodzą do wszystkich ścieżek.
-Przy pushach macierz `checks` dodaje linię `compat-node22`, która uruchamia się tylko dla pushy. W pull requestach ta linia jest pomijana, a macierz pozostaje skupiona na zwykłych liniach testów/kanałów.
+Przy pushach macierz `checks` dodaje ścieżkę `compat-node22`, uruchamianą tylko dla pushy. W pull requestach ta ścieżka jest pomijana, a macierz pozostaje skupiona na zwykłych ścieżkach testów/kanałów.
-Najwolniejsze rodziny testów Node są dzielone na szardy według plików include, aby każde zadanie pozostawało małe: kontrakty kanałów dzielą pokrycie registry i core na osiem ważonych szardów każde, testy poleceń odpowiedzi auto-reply są dzielone na cztery szardy według wzorców include, a pozostałe duże grupy prefiksów odpowiedzi auto-reply są dzielone na dwa szardy każda. `check-additional` rozdziela także kompilację/canary granic pakietów od topologii runtime gateway/architektury.
+Najwolniejsze rodziny testów Node są dzielone na szardy według plików include, aby każde zadanie pozostało małe: kontrakty kanałów dzielą pokrycie rejestru i core na po osiem ważonych shardów, testy poleceń odpowiedzi auto-reply dzielą się na cztery szardy według wzorców include, a pozostałe duże grupy prefiksów odpowiedzi auto-reply dzielą się na po dwa szardy. `check-additional` również oddziela prace compile/canary na granicach pakietów od prac runtime topology gateway/architecture.
-GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowszy push trafi na ten sam PR lub ref `main`. Traktuj to jako szum CI, chyba że najnowsze uruchomienie dla tego samego refa również kończy się błędem. Zagregowane sprawdzenia szardów wyraźnie wskazują ten przypadek anulowania, aby łatwiej było odróżnić go od błędu testu.
+GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowszy push trafi na ten sam ref PR-a lub `main`. Traktuj to jako szum CI, chyba że najnowsze uruchomienie dla tego samego refa również kończy się błędem. Zbiorcze sprawdzenia shardów wyraźnie wskazują ten przypadek anulowania, aby łatwiej było odróżnić go od błędu testu.
## Runnery
@@ -68,22 +68,22 @@ GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowszy push tra
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `blacksmith-16vcpu-ubuntu-2404` | `preflight`, `security-scm-fast`, `security-dependency-audit`, `security-fast`, `build-artifacts`, sprawdzenia Linux, sprawdzenia dokumentacji, Skills w Pythonie, `android` |
| `blacksmith-32vcpu-windows-2025` | `checks-windows` |
-| `macos-latest` | `macos-node`, `macos-swift` |
+| `blacksmith-12vcpu-macos-latest` | `macos-node`, `macos-swift` w `openclaw/openclaw`; forki przechodzą awaryjnie na `macos-latest` |
## Lokalne odpowiedniki
```bash
-pnpm changed:lanes # sprawdź lokalny klasyfikator zmienionych linii dla origin/main...HEAD
-pnpm check:changed # inteligentna lokalna bramka: zmienione typecheck/lint/testy według linii granic
+pnpm changed:lanes # sprawdź lokalny klasyfikator changed-lane dla origin/main...HEAD
+pnpm check:changed # inteligentna lokalna bramka: typecheck/lint/testy dla zmienionych ścieżek według granic
pnpm check # szybka lokalna bramka: produkcyjny tsgo + szardowany lint + równoległe szybkie guardy
pnpm check:test-types
-pnpm check:timed # ta sama bramka z czasami dla poszczególnych etapów
+pnpm check:timed # ta sama bramka z czasami dla każdego etapu
pnpm build:strict-smoke
pnpm check:architecture
pnpm test:gateway:watch-regression
pnpm test # testy vitest
pnpm test:channels
pnpm test:contracts:channels
-pnpm check:docs # format + lint + sprawdzanie uszkodzonych linków w dokumentacji
-pnpm build # buduje dist, gdy mają znaczenie linie CI artifact/build-smoke
+pnpm check:docs # formatowanie dokumentacji + lint + niedziałające linki
+pnpm build # zbuduj dist, gdy mają znaczenie ścieżki CI artifact/build-smoke
```
diff --git a/docs/pl/gateway/multiple-gateways.md b/docs/pl/gateway/multiple-gateways.md
index b0e0ae40c..ac6c25d54 100644
--- a/docs/pl/gateway/multiple-gateways.md
+++ b/docs/pl/gateway/multiple-gateways.md
@@ -5,129 +5,145 @@ read_when:
summary: Uruchamianie wielu Gateway OpenClaw na jednym hoście (izolacja, porty i profile)
title: Wiele Gatewayów
x-i18n:
- generated_at: "2026-04-21T17:45:41Z"
+ generated_at: "2026-04-21T19:20:47Z"
model: gpt-5.4
provider: openai
- source_hash: 8c3fcb921bc6596040e9249467964bd9dcd40ea7c16e958bb378247b0f994a7b
+ source_hash: 36796da339d5baea1704a7f42530030ea6ef4fa4bde43452ffec946b917ed4a3
source_path: gateway/multiple-gateways.md
workflow: 15
---
# Wiele Gatewayów (ten sam host)
-W większości konfiguracji należy używać jednego Gateway, ponieważ pojedynczy Gateway może obsługiwać wiele połączeń komunikatorów i agentów. Jeśli potrzebujesz silniejszej izolacji lub nadmiarowości (np. rescue bot), uruchom osobne Gatewaye z odizolowanymi profilami/portami.
+W większości konfiguracji należy używać jednego Gateway, ponieważ pojedynczy Gateway może obsługiwać wiele połączeń komunikacyjnych i agentów. Jeśli potrzebujesz silniejszej izolacji lub redundancji (np. rescue bot), uruchom osobne Gatewaye z odizolowanymi profilami/portami.
-## Lista kontrolna izolacji (wymagana)
+## Najbardziej zalecana konfiguracja
-- `OPENCLAW_CONFIG_PATH` — plik konfiguracyjny dla każdej instancji
-- `OPENCLAW_STATE_DIR` — sesje, poświadczenia i cache dla każdej instancji
-- `agents.defaults.workspace` — główny katalog workspace dla każdej instancji
-- `gateway.port` (lub `--port`) — unikalny dla każdej instancji
-- Porty pochodne (browser/canvas) nie mogą się nakładać
+Dla większości użytkowników najprostsza konfiguracja rescue bot wygląda tak:
-Jeśli te elementy są współdzielone, wystąpią wyścigi konfiguracji i konflikty portów.
+- pozostaw głównego bota na domyślnym profilu
+- uruchom rescue bot z `--profile rescue`
+- użyj całkowicie osobnego bota Telegram dla konta rescue
+- pozostaw rescue bot na innym porcie bazowym, na przykład `19789`
-## Zalecane: użyj domyślnego profilu dla głównego Gateway, nazwanego profilu dla rescue
+Dzięki temu rescue bot pozostaje odizolowany od głównego bota, więc może diagnozować problemy lub wprowadzać zmiany konfiguracji, jeśli podstawowy bot przestanie działać. Zachowaj co najmniej 20 portów odstępu między portami bazowymi, aby pochodne porty przeglądarki/canvas/CDP nigdy się nie pokrywały.
-Profile automatycznie ograniczają `OPENCLAW_STATE_DIR` + `OPENCLAW_CONFIG_PATH` do swojego zakresu i dodają sufiksy do nazw usług. Dla większości konfiguracji rescue bota pozostaw głównego bota na profilu domyślnym, a tylko rescue botowi przypisz nazwany profil, taki jak `rescue`.
+## Szybki start rescue bot
+
+Użyj tego jako domyślnej ścieżki, chyba że masz ważny powód, by zrobić coś innego:
```bash
-# main (default profile)
-openclaw setup
-openclaw gateway --port 18789
-
-# rescue
-openclaw --profile rescue setup
-openclaw --profile rescue gateway --port 19001
-```
-
-Usługi:
-
-```bash
-openclaw gateway install
-openclaw --profile rescue gateway install
-```
-
-Jeśli chcesz, aby oba Gatewaye używały nazwanych profili, to również działa, ale nie jest to wymagane.
-
-## Przewodnik po rescue bocie
-
-Zalecana konfiguracja:
-
-- pozostaw głównego bota na profilu domyślnym
-- uruchom rescue bota na `--profile rescue`
-- użyj całkowicie oddzielnego bota Telegram dla konta rescue
-- pozostaw rescue bota na innym porcie bazowym, takim jak `19001`
-
-Dzięki temu rescue bot pozostaje odizolowany od głównego bota, dzięki czemu może diagnozować problemy lub stosować zmiany konfiguracji, jeśli główny bot nie działa. Pozostaw co najmniej 20 portów odstępu między portami bazowymi, aby pochodne porty browser/canvas/CDP nigdy się nie zderzyły.
-
-### Zalecany kanał/konto rescue
-
-W większości konfiguracji użyj całkowicie oddzielnego bota Telegram dla profilu rescue.
-
-Dlaczego Telegram:
-
-- łatwo ograniczyć go wyłącznie do operatora
-- oddzielny token bota i tożsamość
-- niezależność od instalacji kanału/aplikacji głównego bota
-- prosta ścieżka odzyskiwania oparta na wiadomościach DM, gdy główny bot jest uszkodzony
-
-Najważniejsza jest pełna niezależność: oddzielne konto bota, oddzielne poświadczenia, oddzielny profil OpenClaw, oddzielny workspace i oddzielny port.
-
-### Zalecany przebieg instalacji
-
-Użyj tego jako domyślnej konfiguracji, chyba że masz ważny powód, aby zrobić inaczej:
-
-```bash
-# Main bot (default profile, port 18789)
-openclaw onboard
-openclaw gateway install
-
-# Rescue bot (separate Telegram bot, separate profile, port 19001)
+# Rescue bot (osobny bot Telegram, osobny profil, port 19789)
openclaw --profile rescue onboard
-openclaw --profile rescue gateway install
+openclaw --profile rescue gateway install --port 19789
```
+Jeśli Twój główny bot już działa, zwykle to wszystko, czego potrzebujesz.
+
Podczas `openclaw --profile rescue onboard`:
-- użyj oddzielnego tokena bota Telegram
+- użyj osobnego tokena bota Telegram
- zachowaj profil `rescue`
-- użyj portu bazowego co najmniej o 20 wyższego niż dla głównego bota
-- zaakceptuj domyślny workspace rescue, chyba że już zarządzasz własnym
+- użyj portu bazowego co najmniej 20 wyższego niż główny bot
+- zaakceptuj domyślny workspace rescue, chyba że już samodzielnie nim zarządzasz
-Jeśli onboarding już zainstalował za Ciebie usługę rescue, końcowe `gateway install` nie jest potrzebne.
+Jeśli onboarding już zainstalował za Ciebie usługę rescue, końcowe polecenie `gateway install` nie jest potrzebne.
-### Co zmienia onboarding
+## Dlaczego to działa
-`openclaw --profile rescue onboard` używa normalnego przepływu onboardingu, ale zapisuje wszystko do oddzielnego profilu.
+Rescue bot pozostaje niezależny, ponieważ ma własne:
-W praktyce oznacza to, że rescue bot otrzymuje własne:
+- profil/konfigurację
+- katalog stanu
+- workspace
+- port bazowy (oraz porty pochodne)
+- token bota Telegram
-- plik konfiguracyjny
+W większości konfiguracji dla profilu rescue użyj całkowicie osobnego bota Telegram:
+
+- łatwo ograniczyć go wyłącznie do operatorów
+- osobny token bota i tożsamość
+- niezależność od instalacji kanału/aplikacji głównego bota
+- prosta ścieżka odzyskiwania oparta na wiadomościach DM, gdy główny bot jest uszkodzony
+
+## Co zmienia `--profile rescue onboard`
+
+`openclaw --profile rescue onboard` używa standardowego przepływu onboardingu, ale zapisuje wszystko w osobnym profilu.
+
+W praktyce oznacza to, że rescue bot dostaje własne:
+
+- plik konfiguracji
- katalog stanu
- workspace (domyślnie `~/.openclaw/workspace-rescue`)
- nazwę zarządzanej usługi
-Poza tym prompty są takie same jak przy normalnym onboardingu.
+Poza tym prompty są takie same jak przy zwykłym onboardingu.
+
+## Ogólna konfiguracja wielu Gatewayów
+
+Układ z rescue bot opisany powyżej to najprostsza opcja domyślna, ale ten sam wzorzec izolacji działa dla dowolnej pary lub grupy Gatewayów na jednym hoście.
+
+W bardziej ogólnej konfiguracji nadaj każdemu dodatkowemu Gatewayowi własny nazwany profil i własny port bazowy:
+
+```bash
+# główny (profil domyślny)
+openclaw setup
+openclaw gateway --port 18789
+
+# dodatkowy gateway
+openclaw --profile ops setup
+openclaw --profile ops gateway --port 19789
+```
+
+Jeśli chcesz, aby oba Gatewaye używały nazwanych profili, to również działa:
+
+```bash
+openclaw --profile main setup
+openclaw --profile main gateway --port 18789
+
+openclaw --profile ops setup
+openclaw --profile ops gateway --port 19789
+```
+
+Usługi działają według tego samego wzorca:
+
+```bash
+openclaw gateway install
+openclaw --profile ops gateway install --port 19789
+```
+
+Użyj szybkiego startu rescue bot, gdy chcesz mieć zapasowy kanał operatorski. Użyj ogólnego wzorca profili, gdy chcesz mieć wiele długotrwale działających Gatewayów dla różnych kanałów, tenantów, workspace'ów lub ról operacyjnych.
+
+## Lista kontrolna izolacji
+
+Zachowaj te elementy unikalne dla każdej instancji Gateway:
+
+- `OPENCLAW_CONFIG_PATH` — plik konfiguracji dla instancji
+- `OPENCLAW_STATE_DIR` — sesje, poświadczenia, cache dla instancji
+- `agents.defaults.workspace` — główny katalog workspace dla instancji
+- `gateway.port` (lub `--port`) — unikalny dla każdej instancji
+- pochodne porty przeglądarki/canvas/CDP
+
+Jeśli te elementy są współdzielone, pojawią się konflikty konfiguracji i portów.
## Mapowanie portów (pochodne)
Port bazowy = `gateway.port` (lub `OPENCLAW_GATEWAY_PORT` / `--port`).
-- port usługi sterowania przeglądarką = bazowy + 2 (tylko loopback)
-- host canvas jest udostępniany przez serwer HTTP Gateway (ten sam port co `gateway.port`)
+- port usługi sterowania przeglądarką = baza + 2 (tylko local loopback)
+- host canvas jest udostępniany na serwerze HTTP Gateway (ten sam port co `gateway.port`)
- porty CDP profilu przeglądarki są automatycznie przydzielane z zakresu `browser.controlPort + 9 .. + 108`
-Jeśli nadpisujesz którykolwiek z nich w konfiguracji lub zmiennych środowiskowych, musisz zachować ich unikalność dla każdej instancji.
+Jeśli nadpisujesz którykolwiek z tych parametrów w konfiguracji lub env, musisz zachować ich unikalność dla każdej instancji.
-## Uwagi o browser/CDP (częsty problem)
+## Uwagi o Browser/CDP (częsta pułapka)
- **Nie** przypinaj `browser.cdpUrl` do tych samych wartości w wielu instancjach.
-- Każda instancja potrzebuje własnego portu sterowania przeglądarką i własnego zakresu CDP (pochodnego od swojego portu Gateway).
+- Każda instancja potrzebuje własnego portu sterowania przeglądarką i własnego zakresu CDP (pochodnego od jej portu gateway).
- Jeśli potrzebujesz jawnych portów CDP, ustaw `browser.profiles..cdpPort` dla każdej instancji.
-- Zdalny Chrome: użyj `browser.profiles..cdpUrl` (dla każdego profilu, dla każdej instancji).
+- Zdalny Chrome: użyj `browser.profiles..cdpUrl` (dla profilu, dla instancji).
-## Przykład ręcznej konfiguracji env
+## Ręczny przykład env
```bash
OPENCLAW_CONFIG_PATH=~/.openclaw/main.json \
@@ -136,10 +152,10 @@ openclaw gateway --port 18789
OPENCLAW_CONFIG_PATH=~/.openclaw/rescue.json \
OPENCLAW_STATE_DIR=~/.openclaw-rescue \
-openclaw gateway --port 19001
+openclaw gateway --port 19789
```
-## Szybkie sprawdzenia
+## Szybkie kontrole
```bash
openclaw gateway status --deep
@@ -153,4 +169,4 @@ openclaw --profile rescue browser status
Interpretacja:
- `gateway status --deep` pomaga wykryć nieaktualne usługi launchd/systemd/schtasks pozostałe po starszych instalacjach.
-- Tekst ostrzeżenia `gateway probe`, taki jak `multiple reachable gateways detected`, jest oczekiwany tylko wtedy, gdy celowo uruchamiasz więcej niż jeden odizolowany Gateway.
+- Tekst ostrzeżenia `gateway probe`, taki jak `multiple reachable gateways detected`, jest oczekiwany tylko wtedy, gdy celowo uruchamiasz więcej niż jeden odizolowany gateway.
diff --git a/docs/pl/plugins/manifest.md b/docs/pl/plugins/manifest.md
index faf4ed36b..241d8ddae 100644
--- a/docs/pl/plugins/manifest.md
+++ b/docs/pl/plugins/manifest.md
@@ -1,80 +1,80 @@
---
read_when:
- - Tworzysz Plugin OpenClaw.
- - Musisz dostarczyć schemat konfiguracji Pluginu lub debugować błędy walidacji Pluginu.
-summary: Manifest Plugin + wymagania schematu JSON (ścisła walidacja konfiguracji)
-title: Manifest Pluginu
+ - Tworzysz plugin OpenClaw
+ - Musisz dostarczyć schemat konfiguracji pluginu lub debugować błędy walidacji pluginu
+summary: Wymagania dotyczące manifestu Plugin + schematu JSON (ścisła walidacja konfiguracji)
+title: Manifest Plugin
x-i18n:
- generated_at: "2026-04-19T01:11:04Z"
+ generated_at: "2026-04-21T19:20:47Z"
model: gpt-5.4
provider: openai
- source_hash: 2dfc00759108ddee7bfcda8c42acf7f2d47451676447ba3caf8b5950f8a1c181
+ source_hash: 304c08035724dfb1ce6349972729b621aafc00880d4d259db78c22b86e9056ba
source_path: plugins/manifest.md
workflow: 15
---
-# Manifest Pluginu (`openclaw.plugin.json`)
+# Manifest pluginu (`openclaw.plugin.json`)
-Ta strona dotyczy wyłącznie **natywnego manifestu Pluginu OpenClaw**.
+Ta strona dotyczy wyłącznie **natywnego manifestu pluginu OpenClaw**.
-Informacje o zgodnych układach bundli znajdziesz tutaj: [Bundle Pluginów](/pl/plugins/bundles).
+Informacje o zgodnych układach bundli znajdziesz w [Plugin bundles](/pl/plugins/bundles).
Zgodne formaty bundli używają innych plików manifestu:
- Bundle Codex: `.codex-plugin/plugin.json`
-- Bundle Claude: `.claude-plugin/plugin.json` lub domyślny układ komponentów Claude
+- Bundle Claude: `.claude-plugin/plugin.json` lub domyślny układ komponentu Claude
bez manifestu
- Bundle Cursor: `.cursor-plugin/plugin.json`
-OpenClaw automatycznie wykrywa również te układy bundli, ale nie są one walidowane
+OpenClaw również automatycznie wykrywa te układy bundli, ale nie są one walidowane
względem schematu `openclaw.plugin.json` opisanego tutaj.
W przypadku zgodnych bundli OpenClaw obecnie odczytuje metadane bundla oraz zadeklarowane
-korzenie Skills, korzenie poleceń Claude, domyślne wartości `settings.json` dla bundla Claude,
-domyślne wartości LSP dla bundla Claude oraz obsługiwane pakiety hooków, gdy układ odpowiada
+rooty umiejętności, rooty poleceń Claude, domyślne wartości `settings.json` bundla Claude,
+domyślne wartości LSP bundla Claude oraz obsługiwane pakiety hooków, gdy układ odpowiada
oczekiwaniom środowiska uruchomieniowego OpenClaw.
-Każdy natywny Plugin OpenClaw **musi** zawierać plik `openclaw.plugin.json` w
-**katalogu głównym Pluginu**. OpenClaw używa tego manifestu do walidacji konfiguracji
-**bez wykonywania kodu Pluginu**. Brakujące lub nieprawidłowe manifesty są traktowane jako
-błędy Pluginu i blokują walidację konfiguracji.
+Każdy natywny plugin OpenClaw **musi** dostarczać plik `openclaw.plugin.json` w
+**katalogu głównym pluginu**. OpenClaw używa tego manifestu do walidacji konfiguracji
+**bez wykonywania kodu pluginu**. Brakujące lub nieprawidłowe manifesty są traktowane jako
+błędy pluginu i blokują walidację konfiguracji.
-Zobacz pełny przewodnik po systemie Pluginów: [Pluginy](/pl/tools/plugin).
-Informacje o natywnym modelu capabilities i bieżące wskazówki dotyczące zewnętrznej kompatybilności:
-[Model capabilities](/pl/plugins/architecture#public-capability-model).
+Zobacz pełny przewodnik po systemie pluginów: [Plugins](/pl/tools/plugin).
+Informacje o natywnym modelu możliwości i aktualnych wskazówkach dotyczących zgodności zewnętrznej:
+[Capability model](/pl/plugins/architecture#public-capability-model).
## Do czego służy ten plik
`openclaw.plugin.json` to metadane, które OpenClaw odczytuje przed załadowaniem kodu
-Twojego Pluginu.
+Twojego pluginu.
Używaj go do:
-- tożsamości Pluginu
+- tożsamości pluginu
- walidacji konfiguracji
- metadanych uwierzytelniania i onboardingu, które powinny być dostępne bez uruchamiania
- runtime Pluginu
+ runtime pluginu
- tanich wskazówek aktywacji, które powierzchnie control-plane mogą sprawdzać przed załadowaniem runtime
-- tanich deskryptorów konfiguracji, które powierzchnie konfiguracji/onboardingu mogą sprawdzać przed
+- tanich deskryptorów konfiguracji, które powierzchnie setupu/onboardingu mogą sprawdzać przed
załadowaniem runtime
-- metadanych aliasów i automatycznego włączania, które powinny być rozwiązywane przed załadowaniem runtime Pluginu
+- metadanych aliasów i auto-enable, które powinny być rozstrzygane przed załadowaniem runtime pluginu
- skróconych metadanych własności rodziny modeli, które powinny automatycznie aktywować
- Plugin przed załadowaniem runtime
-- statycznych snapshotów własności capabilities używanych do wbudowanego okablowania zgodności i
- pokrycia kontraktów
+ plugin przed załadowaniem runtime
+- statycznych migawek własności możliwości używanych do dołączonego okablowania zgodności i
+ pokrycia kontraktu
- tanich metadanych runnera QA, które współdzielony host `openclaw qa` może sprawdzać
- przed załadowaniem runtime Pluginu
-- metadanych konfiguracji specyficznych dla kanału, które powinny być scalane z powierzchniami katalogu i walidacji
- bez ładowania runtime
-- wskazówek dla UI konfiguracji
+ przed załadowaniem runtime pluginu
+- metadanych konfiguracji specyficznych dla kanału, które powinny być scalane z powierzchniami
+ katalogu i walidacji bez ładowania runtime
+- wskazówek UI konfiguracji
Nie używaj go do:
-- rejestrowania zachowania runtime
+- rejestrowania zachowania w runtime
- deklarowania entrypointów kodu
- metadanych instalacji npm
-To należy do kodu Twojego Pluginu i `package.json`.
+To należy do kodu Twojego pluginu i `package.json`.
## Minimalny przykład
@@ -95,7 +95,7 @@ To należy do kodu Twojego Pluginu i `package.json`.
{
"id": "openrouter",
"name": "OpenRouter",
- "description": "Plugin providera OpenRouter",
+ "description": "OpenRouter provider plugin",
"version": "1.0.0",
"providers": ["openrouter"],
"modelSupport": {
@@ -123,19 +123,19 @@ To należy do kodu Twojego Pluginu i `package.json`.
"provider": "openrouter",
"method": "api-key",
"choiceId": "openrouter-api-key",
- "choiceLabel": "Klucz API OpenRouter",
+ "choiceLabel": "OpenRouter API key",
"groupId": "openrouter",
"groupLabel": "OpenRouter",
"optionKey": "openrouterApiKey",
"cliFlag": "--openrouter-api-key",
"cliOption": "--openrouter-api-key ",
- "cliDescription": "Klucz API OpenRouter",
+ "cliDescription": "OpenRouter API key",
"onboardingScopes": ["text-inference"]
}
],
"uiHints": {
"apiKey": {
- "label": "Klucz API",
+ "label": "API key",
"placeholder": "sk-or-v1-...",
"sensitive": true
}
@@ -156,64 +156,64 @@ To należy do kodu Twojego Pluginu i `package.json`.
| Pole | Wymagane | Typ | Co oznacza |
| ----------------------------------- | -------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `id` | Tak | `string` | Kanoniczny identyfikator Pluginu. To identyfikator używany w `plugins.entries.`. |
-| `configSchema` | Tak | `object` | Wbudowany schemat JSON Schema dla konfiguracji tego Pluginu. |
-| `enabledByDefault` | Nie | `true` | Oznacza, że wbudowany Plugin jest domyślnie włączony. Pomiń to pole lub ustaw dowolną wartość inną niż `true`, aby Plugin pozostał domyślnie wyłączony. |
-| `legacyPluginIds` | Nie | `string[]` | Starsze identyfikatory normalizowane do tego kanonicznego identyfikatora Pluginu. |
-| `autoEnableWhenConfiguredProviders` | Nie | `string[]` | Identyfikatory providerów, które powinny automatycznie włączyć ten Plugin, gdy uwierzytelnianie, konfiguracja lub odwołania do modeli o nich wspominają. |
-| `kind` | Nie | `"memory"` \| `"context-engine"` | Deklaruje wyłączny typ Pluginu używany przez `plugins.slots.*`. |
-| `channels` | Nie | `string[]` | Identyfikatory kanałów należących do tego Pluginu. Używane do wykrywania i walidacji konfiguracji. |
-| `providers` | Nie | `string[]` | Identyfikatory providerów należących do tego Pluginu. |
-| `modelSupport` | Nie | `object` | Skrócone metadane rodziny modeli zarządzane przez manifest, używane do automatycznego załadowania Pluginu przed uruchomieniem runtime. |
-| `providerEndpoints` | Nie | `object[]` | Metadane hosta/baseUrl endpointów zarządzane przez manifest dla tras providera, które rdzeń musi sklasyfikować przed załadowaniem runtime providera. |
-| `cliBackends` | Nie | `string[]` | Identyfikatory backendów inferencji CLI należących do tego Pluginu. Używane do automatycznej aktywacji przy starcie na podstawie jawnych odwołań w konfiguracji. |
-| `syntheticAuthRefs` | Nie | `string[]` | Odwołania do providerów lub backendów CLI, których zarządzany przez Plugin hook synthetic auth powinien zostać sprawdzony podczas zimnego wykrywania modeli przed załadowaniem runtime. |
-| `nonSecretAuthMarkers` | Nie | `string[]` | Wartości zastępczych kluczy API należące do wbudowanego Pluginu, które reprezentują niejawną lokalną, OAuth lub ambient credential state. |
-| `commandAliases` | Nie | `object[]` | Nazwy poleceń należące do tego Pluginu, które powinny generować diagnostykę konfiguracji i CLI uwzględniającą Plugin przed załadowaniem runtime. |
-| `providerAuthEnvVars` | Nie | `Record` | Lekkie metadane zmiennych środowiskowych uwierzytelniania providera, które OpenClaw może sprawdzić bez ładowania kodu Pluginu. |
-| `providerAuthAliases` | Nie | `Record` | Identyfikatory providerów, które powinny używać ponownie innego identyfikatora providera do wyszukiwania uwierzytelniania, na przykład provider kodowania współdzielący klucz API i profile auth bazowego providera. |
-| `channelEnvVars` | Nie | `Record` | Lekkie metadane zmiennych środowiskowych kanału, które OpenClaw może sprawdzić bez ładowania kodu Pluginu. Używaj tego dla konfiguracji kanału sterowanej przez env lub dla powierzchni auth, które powinny być widoczne dla ogólnych helperów startu/konfiguracji. |
-| `providerAuthChoices` | Nie | `object[]` | Lekkie metadane wyboru uwierzytelniania dla selektorów onboardingu, rozwiązywania preferowanego providera i prostego powiązania flag CLI. |
-| `activation` | Nie | `object` | Lekkie wskazówki aktywacji dla ładowania wyzwalanego przez providera, polecenie, kanał, trasę i capability. Tylko metadane; rzeczywiste zachowanie nadal należy do runtime Pluginu. |
-| `setup` | Nie | `object` | Lekkie deskryptory konfiguracji/onboardingu, które powierzchnie wykrywania i konfiguracji mogą sprawdzać bez ładowania runtime Pluginu. |
-| `qaRunners` | Nie | `object[]` | Lekkie deskryptory runnerów QA używane przez współdzielony host `openclaw qa` przed załadowaniem runtime Pluginu. |
-| `contracts` | Nie | `object` | Statyczny snapshot capabilities wbudowanego pakietu dla własności speech, realtime transcription, realtime voice, media-understanding, image-generation, music-generation, video-generation, web-fetch, web search oraz tools. |
-| `channelConfigs` | Nie | `Record` | Metadane konfiguracji kanału zarządzane przez manifest, scalane z powierzchniami wykrywania i walidacji przed załadowaniem runtime. |
-| `skills` | Nie | `string[]` | Katalogi Skills do załadowania, względne wobec katalogu głównego Pluginu. |
-| `name` | Nie | `string` | Czytelna dla człowieka nazwa Pluginu. |
-| `description` | Nie | `string` | Krótkie podsumowanie wyświetlane na powierzchniach Pluginu. |
-| `version` | Nie | `string` | Informacyjna wersja Pluginu. |
-| `uiHints` | Nie | `Record` | Etykiety UI, placeholdery i wskazówki dotyczące wrażliwości dla pól konfiguracji. |
+| `id` | Tak | `string` | Kanoniczny identyfikator pluginu. To identyfikator używany w `plugins.entries.`. |
+| `configSchema` | Tak | `object` | Wbudowany schemat JSON Schema dla konfiguracji tego pluginu. |
+| `enabledByDefault` | Nie | `true` | Oznacza dołączony plugin jako domyślnie włączony. Pomiń to pole lub ustaw dowolną wartość inną niż `true`, aby plugin pozostał domyślnie wyłączony. |
+| `legacyPluginIds` | Nie | `string[]` | Starsze identyfikatory normalizowane do tego kanonicznego identyfikatora pluginu. |
+| `autoEnableWhenConfiguredProviders` | Nie | `string[]` | Identyfikatory providerów, które powinny automatycznie włączać ten plugin, gdy uwierzytelnianie, konfiguracja lub odwołania do modeli je wskazują. |
+| `kind` | Nie | `"memory"` \| `"context-engine"` | Deklaruje wyłączny rodzaj pluginu używany przez `plugins.slots.*`. |
+| `channels` | Nie | `string[]` | Identyfikatory kanałów należących do tego pluginu. Używane do wykrywania i walidacji konfiguracji. |
+| `providers` | Nie | `string[]` | Identyfikatory providerów należących do tego pluginu. |
+| `modelSupport` | Nie | `object` | Należące do manifestu skrócone metadane rodziny modeli używane do automatycznego ładowania pluginu przed runtime. |
+| `providerEndpoints` | Nie | `object[]` | Należące do manifestu metadane hostów/baseUrl endpointów dla tras providera, które rdzeń musi klasyfikować przed załadowaniem runtime providera. |
+| `cliBackends` | Nie | `string[]` | Identyfikatory backendów inferencji CLI należących do tego pluginu. Używane do automatycznej aktywacji przy starcie na podstawie jawnych odwołań konfiguracyjnych. |
+| `syntheticAuthRefs` | Nie | `string[]` | Odwołania do providera lub backendu CLI, których należący do pluginu syntetyczny hook uwierzytelniania powinien być sprawdzany podczas zimnego wykrywania modeli przed załadowaniem runtime. |
+| `nonSecretAuthMarkers` | Nie | `string[]` | Należące do dołączonego pluginu przykładowe wartości kluczy API, które reprezentują niejawną lokalną, OAuth lub środowiskową tożsamość poświadczeń. |
+| `commandAliases` | Nie | `object[]` | Nazwy poleceń należące do tego pluginu, które powinny generować świadomą pluginu konfigurację i diagnostykę CLI przed załadowaniem runtime. |
+| `providerAuthEnvVars` | Nie | `Record` | Lekkie metadane zmiennych środowiskowych uwierzytelniania providera, które OpenClaw może sprawdzać bez ładowania kodu pluginu. |
+| `providerAuthAliases` | Nie | `Record` | Identyfikatory providerów, które powinny ponownie używać innego identyfikatora providera do wyszukiwania uwierzytelniania, na przykład provider kodowania współdzielący bazowy klucz API i profile auth. |
+| `channelEnvVars` | Nie | `Record` | Lekkie metadane zmiennych środowiskowych kanału, które OpenClaw może sprawdzać bez ładowania kodu pluginu. Używaj tego do powierzchni konfiguracji kanału lub auth sterowanych przez env, które powinny widzieć ogólne helpery startowe/konfiguracyjne. |
+| `providerAuthChoices` | Nie | `object[]` | Lekkie metadane wyboru auth dla selektorów onboardingu, rozstrzygania preferowanych providerów i prostego powiązania flag CLI. |
+| `activation` | Nie | `object` | Lekkie wskazówki aktywacji dla ładowania wyzwalanego przez providera, polecenie, kanał, trasę i możliwość. Tylko metadane; faktyczne zachowanie nadal należy do runtime pluginu. |
+| `setup` | Nie | `object` | Lekkie deskryptory setupu/onboardingu, które powierzchnie wykrywania i konfiguracji mogą sprawdzać bez ładowania runtime pluginu. |
+| `qaRunners` | Nie | `object[]` | Lekkie deskryptory runnerów QA używane przez współdzielony host `openclaw qa` przed załadowaniem runtime pluginu. |
+| `contracts` | Nie | `object` | Statyczna migawka dołączonych możliwości dla mowy, transkrypcji realtime, głosu realtime, rozumienia mediów, generowania obrazów, generowania muzyki, generowania wideo, web-fetch, wyszukiwania w sieci oraz własności narzędzi. |
+| `channelConfigs` | Nie | `Record` | Należące do manifestu metadane konfiguracji kanału scalane z powierzchniami wykrywania i walidacji przed załadowaniem runtime. |
+| `skills` | Nie | `string[]` | Katalogi Skills do załadowania, względne względem katalogu głównego pluginu. |
+| `name` | Nie | `string` | Czytelna dla człowieka nazwa pluginu. |
+| `description` | Nie | `string` | Krótkie podsumowanie wyświetlane na powierzchniach pluginu. |
+| `version` | Nie | `string` | Informacyjna wersja pluginu. |
+| `uiHints` | Nie | `Record` | Etykiety UI, placeholdery i wskazówki dotyczące wrażliwości dla pól konfiguracji. |
## Opis `providerAuthChoices`
-Każdy wpis `providerAuthChoices` opisuje jeden wybór onboardingu lub uwierzytelniania.
+Każdy wpis `providerAuthChoices` opisuje jeden wybór onboardingu lub auth.
OpenClaw odczytuje to przed załadowaniem runtime providera.
-| Pole | Wymagane | Typ | Co oznacza |
-| -------------------- | -------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
-| `provider` | Tak | `string` | Identyfikator providera, do którego należy ten wybór. |
-| `method` | Tak | `string` | Identyfikator metody auth, do której ma nastąpić przekazanie. |
-| `choiceId` | Tak | `string` | Stabilny identyfikator wyboru auth używany przez onboarding i przepływy CLI. |
-| `choiceLabel` | Nie | `string` | Etykieta widoczna dla użytkownika. Jeśli zostanie pominięta, OpenClaw użyje `choiceId`. |
-| `choiceHint` | Nie | `string` | Krótki tekst pomocniczy dla selektora. |
-| `assistantPriority` | Nie | `number` | Niższe wartości są sortowane wcześniej w interaktywnych selektorach sterowanych przez asystenta. |
-| `assistantVisibility`| Nie | `"visible"` \| `"manual-only"` | Ukrywa wybór w selektorach asystenta, nadal pozwalając na ręczny wybór w CLI. |
-| `deprecatedChoiceIds`| Nie | `string[]` | Starsze identyfikatory wyboru, które powinny przekierowywać użytkowników do tego zastępczego wyboru. |
-| `groupId` | Nie | `string` | Opcjonalny identyfikator grupy do grupowania powiązanych wyborów. |
-| `groupLabel` | Nie | `string` | Etykieta tej grupy widoczna dla użytkownika. |
-| `groupHint` | Nie | `string` | Krótki tekst pomocniczy dla grupy. |
-| `optionKey` | Nie | `string` | Wewnętrzny klucz opcji dla prostych przepływów auth z jedną flagą. |
-| `cliFlag` | Nie | `string` | Nazwa flagi CLI, na przykład `--openrouter-api-key`. |
-| `cliOption` | Nie | `string` | Pełny kształt opcji CLI, na przykład `--openrouter-api-key `. |
-| `cliDescription` | Nie | `string` | Opis używany w pomocy CLI. |
-| `onboardingScopes` | Nie | `Array<"text-inference" \| "image-generation">` | Na których powierzchniach onboardingu ten wybór powinien się pojawiać. Jeśli pole zostanie pominięte, domyślnie używane jest `["text-inference"]`. |
+| Pole | Wymagane | Typ | Co oznacza |
+| --------------------- | -------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
+| `provider` | Tak | `string` | Identyfikator providera, do którego należy ten wybór. |
+| `method` | Tak | `string` | Identyfikator metody auth, do której należy przekazać obsługę. |
+| `choiceId` | Tak | `string` | Stabilny identyfikator wyboru auth używany przez onboarding i przepływy CLI. |
+| `choiceLabel` | Nie | `string` | Etykieta widoczna dla użytkownika. Jeśli zostanie pominięta, OpenClaw użyje `choiceId`. |
+| `choiceHint` | Nie | `string` | Krótki tekst pomocniczy dla selektora. |
+| `assistantPriority` | Nie | `number` | Niższe wartości są sortowane wcześniej w interaktywnych selektorach sterowanych przez asystenta. |
+| `assistantVisibility` | Nie | `"visible"` \| `"manual-only"` | Ukrywa wybór w selektorach asystenta, nadal pozwalając na ręczny wybór w CLI. |
+| `deprecatedChoiceIds` | Nie | `string[]` | Starsze identyfikatory wyboru, które powinny przekierowywać użytkowników do tego zastępczego wyboru. |
+| `groupId` | Nie | `string` | Opcjonalny identyfikator grupy do grupowania powiązanych wyborów. |
+| `groupLabel` | Nie | `string` | Etykieta tej grupy widoczna dla użytkownika. |
+| `groupHint` | Nie | `string` | Krótki tekst pomocniczy dla grupy. |
+| `optionKey` | Nie | `string` | Wewnętrzny klucz opcji dla prostych przepływów auth opartych na jednej fladze. |
+| `cliFlag` | Nie | `string` | Nazwa flagi CLI, na przykład `--openrouter-api-key`. |
+| `cliOption` | Nie | `string` | Pełna postać opcji CLI, na przykład `--openrouter-api-key `. |
+| `cliDescription` | Nie | `string` | Opis używany w pomocy CLI. |
+| `onboardingScopes` | Nie | `Array<"text-inference" \| "image-generation">` | Na których powierzchniach onboardingu ten wybór powinien się pojawiać. Jeśli pole zostanie pominięte, domyślnie używane jest `["text-inference"]`. |
## Opis `commandAliases`
-Użyj `commandAliases`, gdy Plugin posiada nazwę polecenia runtime, którą użytkownicy
-mogą błędnie umieścić w `plugins.allow` lub próbować uruchomić jako główne polecenie CLI. OpenClaw
-używa tych metadanych do diagnostyki bez importowania kodu runtime Pluginu.
+Używaj `commandAliases`, gdy plugin posiada nazwę polecenia runtime, którą użytkownicy
+mogą przez pomyłkę umieścić w `plugins.allow` albo próbować uruchomić jako główne polecenie CLI. OpenClaw
+używa tych metadanych do diagnostyki bez importowania kodu runtime pluginu.
```json
{
@@ -227,44 +227,45 @@ używa tych metadanych do diagnostyki bez importowania kodu runtime Pluginu.
}
```
-| Pole | Wymagane | Typ | Co oznacza |
-| ------------ | -------- | ----------------- | -------------------------------------------------------------------------- |
-| `name` | Tak | `string` | Nazwa polecenia należącego do tego Pluginu. |
-| `kind` | Nie | `"runtime-slash"` | Oznacza alias jako polecenie slash czatu, a nie główne polecenie CLI. |
-| `cliCommand` | Nie | `string` | Powiązane główne polecenie CLI sugerowane do operacji CLI, jeśli istnieje. |
+| Pole | Wymagane | Typ | Co oznacza |
+| ------------ | -------- | ----------------- | ---------------------------------------------------------------------------- |
+| `name` | Tak | `string` | Nazwa polecenia należąca do tego pluginu. |
+| `kind` | Nie | `"runtime-slash"` | Oznacza alias jako polecenie slash czatu, a nie główne polecenie CLI. |
+| `cliCommand` | Nie | `string` | Powiązane główne polecenie CLI, które należy zasugerować przy operacjach CLI, jeśli istnieje. |
## Opis `activation`
-Użyj `activation`, gdy Plugin może w tani sposób zadeklarować, które zdarzenia control-plane
+Używaj `activation`, gdy plugin może w prosty sposób zadeklarować, które zdarzenia control-plane
powinny aktywować go później.
## Opis `qaRunners`
-Użyj `qaRunners`, gdy Plugin wnosi jeden lub więcej runnerów transportu pod współdzielony
-główny węzeł `openclaw qa`. Zachowaj te metadane jako lekkie i statyczne; rzeczywista rejestracja CLI nadal należy do runtime
-Pluginu poprzez lekką powierzchnię `runtime-api.ts`, która eksportuje `qaRunnerCliRegistrations`.
+Używaj `qaRunners`, gdy plugin wnosi jeden lub więcej runnerów transportu pod
+współdzielonym rootem `openclaw qa`. Zachowaj te metadane jako lekkie i statyczne; runtime
+pluginu nadal odpowiada za faktyczną rejestrację CLI przez lekką
+powierzchnię `runtime-api.ts`, która eksportuje `qaRunnerCliRegistrations`.
```json
{
"qaRunners": [
{
"commandName": "matrix",
- "description": "Uruchom opartą na Dockerze aktywną ścieżkę QA Matrix przeciwko tymczasowemu homeserverowi"
+ "description": "Run the Docker-backed Matrix live QA lane against a disposable homeserver"
}
]
}
```
-| Pole | Wymagane | Typ | Co oznacza |
-| ------------- | -------- | -------- | -------------------------------------------------------------------- |
-| `commandName` | Tak | `string` | Podpolecenie montowane pod `openclaw qa`, na przykład `matrix`. |
-| `description` | Nie | `string` | Zapasowy tekst pomocy używany, gdy współdzielony host potrzebuje polecenia zastępczego. |
+| Pole | Wymagane | Typ | Co oznacza |
+| ------------- | -------- | -------- | ------------------------------------------------------------------ |
+| `commandName` | Tak | `string` | Podpolecenie montowane pod `openclaw qa`, na przykład `matrix`. |
+| `description` | Nie | `string` | Zastępczy tekst pomocy używany, gdy współdzielony host potrzebuje polecenia stub. |
Ten blok zawiera wyłącznie metadane. Nie rejestruje zachowania runtime i nie
-zastępuje `register(...)`, `setupEntry` ani innych entrypointów runtime/Pluginu.
-Obecni konsumenci używają go jako wskazówki zawężającej przed szerszym ładowaniem Pluginu, więc
+zastępuje `register(...)`, `setupEntry` ani innych entrypointów runtime/pluginu.
+Obecni konsumenci używają go jako wskazówki zawężającej przed szerszym ładowaniem pluginu, więc
brak metadanych aktywacji zwykle wpływa tylko na wydajność; nie powinien
-zmieniać poprawności, dopóki nadal istnieją starsze mechanizmy własności w manifeście.
+zmieniać poprawności, dopóki nadal istnieją starsze fallbacki własności manifestu.
```json
{
@@ -278,26 +279,27 @@ zmieniać poprawności, dopóki nadal istnieją starsze mechanizmy własności w
}
```
-| Pole | Wymagane | Typ | Co oznacza |
-| ---------------- | -------- | ---------------------------------------------------- | -------------------------------------------------------------------- |
-| `onProviders` | Nie | `string[]` | Identyfikatory providerów, które powinny aktywować ten Plugin na żądanie. |
-| `onCommands` | Nie | `string[]` | Identyfikatory poleceń, które powinny aktywować ten Plugin. |
-| `onChannels` | Nie | `string[]` | Identyfikatory kanałów, które powinny aktywować ten Plugin. |
-| `onRoutes` | Nie | `string[]` | Rodzaje tras, które powinny aktywować ten Plugin. |
-| `onCapabilities` | Nie | `Array<"provider" \| "channel" \| "tool" \| "hook">` | Ogólne wskazówki capabilities używane przez planowanie aktywacji control-plane. |
+| Pole | Wymagane | Typ | Co oznacza |
+| ---------------- | -------- | ---------------------------------------------------- | ----------------------------------------------------------------- |
+| `onProviders` | Nie | `string[]` | Identyfikatory providerów, które powinny aktywować ten plugin po wywołaniu. |
+| `onCommands` | Nie | `string[]` | Identyfikatory poleceń, które powinny aktywować ten plugin. |
+| `onChannels` | Nie | `string[]` | Identyfikatory kanałów, które powinny aktywować ten plugin. |
+| `onRoutes` | Nie | `string[]` | Rodzaje tras, które powinny aktywować ten plugin. |
+| `onCapabilities` | Nie | `Array<"provider" \| "channel" \| "tool" \| "hook">` | Szerokie wskazówki możliwości używane przez planowanie aktywacji control-plane. |
-Obecni aktywni konsumenci:
+Obecni konsumenci produkcyjni:
-- planowanie CLI wyzwalane poleceniami wraca do starszych
+- planowanie CLI wyzwalane poleceniem wraca do starszego
`commandAliases[].cliCommand` lub `commandAliases[].name`
-- planowanie konfiguracji/kanału wyzwalane kanałem wraca do starszej własności `channels[]`,
- gdy brakuje jawnych metadanych aktywacji kanału
-- planowanie konfiguracji/runtime wyzwalane providerem wraca do starszej
- własności `providers[]` i najwyższego poziomu `cliBackends[]`, gdy brakuje jawnych metadanych aktywacji providera
+- planowanie setupu/kanału wyzwalane kanałem wraca do starszej własności
+ `channels[]`, gdy brakuje jawnych metadanych aktywacji kanału
+- planowanie setupu/runtime wyzwalane providerem wraca do starszej
+ własności `providers[]` oraz najwyższego poziomu `cliBackends[]`, gdy brakuje jawnych metadanych
+ aktywacji providera
## Opis `setup`
-Użyj `setup`, gdy powierzchnie konfiguracji i onboardingu potrzebują lekkich metadanych należących do Pluginu
+Używaj `setup`, gdy powierzchnie setupu i onboardingu potrzebują lekkich metadanych należących do pluginu
przed załadowaniem runtime.
```json
@@ -317,48 +319,48 @@ przed załadowaniem runtime.
}
```
-Najwyższego poziomu `cliBackends` pozostaje poprawne i nadal opisuje backendy
-inferencji CLI. `setup.cliBackends` to powierzchnia deskryptora specyficzna dla konfiguracji
-dla przepływów control-plane/konfiguracji, które powinny pozostać wyłącznie metadanymi.
+Pole najwyższego poziomu `cliBackends` pozostaje prawidłowe i nadal opisuje backendy
+inferencji CLI. `setup.cliBackends` to powierzchnia deskryptorów specyficzna dla setupu dla
+przepływów control-plane/setup, które powinny pozostać wyłącznie metadanymi.
Jeśli są obecne, `setup.providers` i `setup.cliBackends` są preferowaną
-powierzchnią wyszukiwania opartą najpierw na deskryptorze dla wykrywania konfiguracji. Jeśli deskryptor jedynie zawęża
-kandydujący Plugin, a konfiguracja nadal potrzebuje bogatszych hooków runtime działających w czasie konfiguracji,
+powierzchnią wyszukiwania opartą najpierw na deskryptorach dla wykrywania setupu. Jeśli deskryptor tylko
+zawęża kandydujący plugin, a setup nadal wymaga bogatszych hooków runtime czasu setupu,
ustaw `requiresRuntime: true` i pozostaw `setup-api` jako
-zapasową ścieżkę wykonania.
+zastępczą ścieżkę wykonania.
-Ponieważ wyszukiwanie konfiguracji może wykonywać należący do Pluginu kod `setup-api`,
-znormalizowane wartości `setup.providers[].id` i `setup.cliBackends[]` muszą pozostać unikalne globalnie
-we wszystkich wykrytych Pluginach. Niejednoznaczna własność kończy się bezpiecznym zamknięciem zamiast wybierania
-zwycięzcy na podstawie kolejności wykrywania.
+Ponieważ wyszukiwanie setupu może wykonywać należący do pluginu kod `setup-api`,
+znormalizowane wartości `setup.providers[].id` i `setup.cliBackends[]` muszą pozostać unikalne wśród
+wykrytych pluginów. Niejednoznaczna własność kończy się bezpieczną odmową zamiast wybierania
+zwycięzcy na podstawie kolejności wykrycia.
### Opis `setup.providers`
-| Pole | Wymagane | Typ | Co oznacza |
-| ------------- | -------- | ---------- | ------------------------------------------------------------------------------------------ |
-| `id` | Tak | `string` | Identyfikator providera ujawniany podczas konfiguracji lub onboardingu. Zachowaj globalną unikalność znormalizowanych identyfikatorów. |
-| `authMethods` | Nie | `string[]` | Identyfikatory metod konfiguracji/auth obsługiwane przez tego providera bez ładowania pełnego runtime. |
-| `envVars` | Nie | `string[]` | Zmienne środowiskowe, które ogólne powierzchnie konfiguracji/statusu mogą sprawdzać przed załadowaniem runtime Pluginu. |
+| Pole | Wymagane | Typ | Co oznacza |
+| ------------- | -------- | ---------- | ------------------------------------------------------------------------------------- |
+| `id` | Tak | `string` | Identyfikator providera ujawniany podczas setupu lub onboardingu. Znormalizowane identyfikatory muszą być globalnie unikalne. |
+| `authMethods` | Nie | `string[]` | Identyfikatory metod setupu/auth obsługiwane przez tego providera bez ładowania pełnego runtime. |
+| `envVars` | Nie | `string[]` | Zmienne środowiskowe, które ogólne powierzchnie setupu/statusu mogą sprawdzać przed załadowaniem runtime pluginu. |
### Pola `setup`
-| Pole | Wymagane | Typ | Co oznacza |
-| ------------------ | -------- | ---------- | --------------------------------------------------------------------------------------------------- |
-| `providers` | Nie | `object[]` | Deskryptory konfiguracji providera ujawniane podczas konfiguracji i onboardingu. |
-| `cliBackends` | Nie | `string[]` | Identyfikatory backendów używane w czasie konfiguracji do wyszukiwania najpierw po deskryptorze. Zachowaj globalną unikalność znormalizowanych identyfikatorów. |
-| `configMigrations` | Nie | `string[]` | Identyfikatory migracji konfiguracji należące do powierzchni konfiguracji tego Pluginu. |
-| `requiresRuntime` | Nie | `boolean` | Czy konfiguracja nadal wymaga wykonania `setup-api` po wyszukaniu po deskryptorze. |
+| Pole | Wymagane | Typ | Co oznacza |
+| ------------------ | -------- | ---------- | ---------------------------------------------------------------------------------------------------- |
+| `providers` | Nie | `object[]` | Deskryptory setupu providera ujawniane podczas setupu i onboardingu. |
+| `cliBackends` | Nie | `string[]` | Identyfikatory backendów czasu setupu używane do wyszukiwania setupu najpierw po deskryptorach. Znormalizowane identyfikatory muszą być globalnie unikalne. |
+| `configMigrations` | Nie | `string[]` | Identyfikatory migracji konfiguracji należące do powierzchni setupu tego pluginu. |
+| `requiresRuntime` | Nie | `boolean` | Czy setup nadal wymaga wykonania `setup-api` po wyszukaniu deskryptora. |
## Opis `uiHints`
-`uiHints` to mapa od nazw pól konfiguracji do niewielkich wskazówek renderowania.
+`uiHints` to mapa od nazw pól konfiguracji do małych wskazówek renderowania.
```json
{
"uiHints": {
"apiKey": {
- "label": "Klucz API",
- "help": "Używany do żądań OpenRouter",
+ "label": "API key",
+ "help": "Used for OpenRouter requests",
"placeholder": "sk-or-v1-...",
"sensitive": true
}
@@ -368,19 +370,19 @@ zwycięzcy na podstawie kolejności wykrywania.
Każda wskazówka pola może zawierać:
-| Pole | Typ | Co oznacza |
-| ------------- | ---------- | ----------------------------------------- |
-| `label` | `string` | Etykieta pola widoczna dla użytkownika. |
-| `help` | `string` | Krótki tekst pomocniczy. |
-| `tags` | `string[]` | Opcjonalne tagi UI. |
-| `advanced` | `boolean` | Oznacza pole jako zaawansowane. |
-| `sensitive` | `boolean` | Oznacza pole jako sekretne lub wrażliwe. |
-| `placeholder` | `string` | Tekst placeholdera dla pól formularza. |
+| Pole | Typ | Co oznacza |
+| ------------- | ---------- | ---------------------------------------- |
+| `label` | `string` | Etykieta pola widoczna dla użytkownika. |
+| `help` | `string` | Krótki tekst pomocniczy. |
+| `tags` | `string[]` | Opcjonalne tagi UI. |
+| `advanced` | `boolean` | Oznacza pole jako zaawansowane. |
+| `sensitive` | `boolean` | Oznacza pole jako sekretne lub wrażliwe. |
+| `placeholder` | `string` | Tekst placeholdera dla pól formularza. |
## Opis `contracts`
-Używaj `contracts` wyłącznie do statycznych metadanych własności capabilities, które OpenClaw może
-odczytać bez importowania runtime Pluginu.
+Używaj `contracts` wyłącznie dla statycznych metadanych własności możliwości, które OpenClaw może
+odczytać bez importowania runtime pluginu.
```json
{
@@ -402,19 +404,19 @@ Każda lista jest opcjonalna:
| Pole | Typ | Co oznacza |
| -------------------------------- | ---------- | ---------------------------------------------------------------- |
-| `speechProviders` | `string[]` | Identyfikatory providerów speech należących do tego Pluginu. |
-| `realtimeTranscriptionProviders` | `string[]` | Identyfikatory providerów realtime transcription należących do tego Pluginu. |
-| `realtimeVoiceProviders` | `string[]` | Identyfikatory providerów realtime voice należących do tego Pluginu. |
-| `mediaUnderstandingProviders` | `string[]` | Identyfikatory providerów media-understanding należących do tego Pluginu. |
-| `imageGenerationProviders` | `string[]` | Identyfikatory providerów image-generation należących do tego Pluginu. |
-| `videoGenerationProviders` | `string[]` | Identyfikatory providerów video-generation należących do tego Pluginu. |
-| `webFetchProviders` | `string[]` | Identyfikatory providerów web-fetch należących do tego Pluginu. |
-| `webSearchProviders` | `string[]` | Identyfikatory providerów web search należących do tego Pluginu. |
-| `tools` | `string[]` | Nazwy tools agenta należących do tego Pluginu do sprawdzania kontraktów wbudowanych. |
+| `speechProviders` | `string[]` | Identyfikatory providerów mowy należących do tego pluginu. |
+| `realtimeTranscriptionProviders` | `string[]` | Identyfikatory providerów transkrypcji realtime należących do tego pluginu. |
+| `realtimeVoiceProviders` | `string[]` | Identyfikatory providerów głosu realtime należących do tego pluginu. |
+| `mediaUnderstandingProviders` | `string[]` | Identyfikatory providerów rozumienia mediów należących do tego pluginu. |
+| `imageGenerationProviders` | `string[]` | Identyfikatory providerów generowania obrazów należących do tego pluginu. |
+| `videoGenerationProviders` | `string[]` | Identyfikatory providerów generowania wideo należących do tego pluginu. |
+| `webFetchProviders` | `string[]` | Identyfikatory providerów web-fetch należących do tego pluginu. |
+| `webSearchProviders` | `string[]` | Identyfikatory providerów wyszukiwania w sieci należących do tego pluginu. |
+| `tools` | `string[]` | Nazwy narzędzi agenta należących do tego pluginu na potrzeby kontroli kontraktów dołączonych pluginów. |
## Opis `channelConfigs`
-Użyj `channelConfigs`, gdy Plugin kanału potrzebuje lekkich metadanych konfiguracji przed
+Używaj `channelConfigs`, gdy plugin kanału potrzebuje lekkich metadanych konfiguracji przed
załadowaniem runtime.
```json
@@ -430,12 +432,12 @@ załadowaniem runtime.
},
"uiHints": {
"homeserverUrl": {
- "label": "URL homeservera",
+ "label": "Homeserver URL",
"placeholder": "https://matrix.example.com"
}
},
"label": "Matrix",
- "description": "Połączenie z homeserverem Matrix",
+ "description": "Matrix homeserver connection",
"preferOver": ["matrix-legacy"]
}
}
@@ -444,18 +446,18 @@ załadowaniem runtime.
Każdy wpis kanału może zawierać:
-| Pole | Typ | Co oznacza |
-| ------------- | ------------------------ | ------------------------------------------------------------------------------------------ |
+| Pole | Typ | Co oznacza |
+| ------------- | ------------------------ | -------------------------------------------------------------------------------------------- |
| `schema` | `object` | JSON Schema dla `channels.`. Wymagane dla każdego zadeklarowanego wpisu konfiguracji kanału. |
-| `uiHints` | `Record` | Opcjonalne etykiety UI/placeholdery/wskazówki dotyczące wrażliwości dla tej sekcji konfiguracji kanału. |
-| `label` | `string` | Etykieta kanału scalana z powierzchniami selektora i inspekcji, gdy metadane runtime nie są jeszcze gotowe. |
-| `description` | `string` | Krótki opis kanału dla powierzchni inspekcji i katalogu. |
-| `preferOver` | `string[]` | Starsze lub niżej priorytetyzowane identyfikatory Pluginów, które ten kanał powinien wyprzedzać na powierzchniach wyboru. |
+| `uiHints` | `Record` | Opcjonalne etykiety UI/placeholdery/wskazówki wrażliwości dla tej sekcji konfiguracji kanału. |
+| `label` | `string` | Etykieta kanału scalana z powierzchniami selektora i inspekcji, gdy metadane runtime nie są gotowe. |
+| `description` | `string` | Krótki opis kanału dla powierzchni inspekcji i katalogu. |
+| `preferOver` | `string[]` | Identyfikatory starszych lub niżej priorytetowych pluginów, które ten kanał powinien wyprzedzać na powierzchniach wyboru. |
## Opis `modelSupport`
-Użyj `modelSupport`, gdy OpenClaw ma wnioskować o Twoim Pluginie providera na podstawie
-skróconych identyfikatorów modeli takich jak `gpt-5.4` lub `claude-sonnet-4.6`, zanim runtime Pluginu
+Używaj `modelSupport`, gdy OpenClaw ma wnioskować o Twoim pluginie providera na podstawie
+skróconych identyfikatorów modeli, takich jak `gpt-5.4` lub `claude-sonnet-4.6`, zanim runtime pluginu
zostanie załadowany.
```json
@@ -471,68 +473,74 @@ OpenClaw stosuje następujący priorytet:
- jawne odwołania `provider/model` używają metadanych manifestu `providers` należących do właściciela
- `modelPatterns` mają pierwszeństwo przed `modelPrefixes`
-- jeśli pasują jednocześnie jeden Plugin niewbudowany i jeden wbudowany, wygrywa Plugin
- niewbudowany
-- pozostała niejednoznaczność jest ignorowana, dopóki użytkownik lub konfiguracja nie określi providera
+- jeśli pasują jednocześnie jeden plugin niedołączony i jeden plugin dołączony, wygrywa plugin
+ niedołączony
+- pozostała niejednoznaczność jest ignorowana, dopóki użytkownik lub konfiguracja nie wskaże providera
Pola:
-| Pole | Typ | Co oznacza |
-| --------------- | ---------- | ----------------------------------------------------------------------------------- |
-| `modelPrefixes` | `string[]` | Prefiksy dopasowywane za pomocą `startsWith` do skróconych identyfikatorów modeli. |
+| Pole | Typ | Co oznacza |
+| --------------- | ---------- | ----------------------------------------------------------------------------- |
+| `modelPrefixes` | `string[]` | Prefiksy dopasowywane przez `startsWith` do skróconych identyfikatorów modeli. |
| `modelPatterns` | `string[]` | Źródła regex dopasowywane do skróconych identyfikatorów modeli po usunięciu sufiksu profilu. |
-Starsze klucze capabilities najwyższego poziomu są przestarzałe. Użyj `openclaw doctor --fix`, aby
+Starsze klucze możliwości na najwyższym poziomie są przestarzałe. Użyj `openclaw doctor --fix`, aby
przenieść `speechProviders`, `realtimeTranscriptionProviders`,
`realtimeVoiceProviders`, `mediaUnderstandingProviders`,
`imageGenerationProviders`, `videoGenerationProviders`,
-`webFetchProviders` i `webSearchProviders` do `contracts`; zwykłe
+`webFetchProviders` i `webSearchProviders` pod `contracts`; zwykłe
ładowanie manifestu nie traktuje już tych pól najwyższego poziomu jako
-własności capabilities.
+własności możliwości.
## Manifest a package.json
-Te dwa pliki pełnią różne role:
+Te dwa pliki pełnią różne funkcje:
-| Plik | Używaj go do |
+| Plik | Używaj go do |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
-| `openclaw.plugin.json` | Wykrywania, walidacji konfiguracji, metadanych wyboru auth i wskazówek UI, które muszą istnieć przed uruchomieniem kodu Pluginu |
-| `package.json` | Metadanych npm, instalacji zależności oraz bloku `openclaw` używanego dla entrypointów, kontroli instalacji, konfiguracji lub metadanych katalogu |
+| `openclaw.plugin.json` | Wykrywania, walidacji konfiguracji, metadanych wyboru auth i wskazówek UI, które muszą istnieć przed uruchomieniem kodu pluginu |
+| `package.json` | Metadanych npm, instalacji zależności oraz bloku `openclaw` używanego dla entrypointów, ograniczeń instalacji, setupu lub metadanych katalogu |
-Jeśli nie masz pewności, gdzie powinien trafić dany fragment metadanych, zastosuj tę zasadę:
+Jeśli nie masz pewności, gdzie powinien należeć dany element metadanych, użyj tej zasady:
-- jeśli OpenClaw musi znać go przed załadowaniem kodu Pluginu, umieść go w `openclaw.plugin.json`
+- jeśli OpenClaw musi o nim wiedzieć przed załadowaniem kodu pluginu, umieść go w `openclaw.plugin.json`
- jeśli dotyczy pakowania, plików entry lub zachowania instalacji npm, umieść go w `package.json`
### Pola `package.json`, które wpływają na wykrywanie
-Część metadanych Pluginu używanych przed runtime celowo znajduje się w `package.json` w bloku
+Niektóre metadane pluginu sprzed uruchomienia runtime celowo znajdują się w `package.json` w bloku
`openclaw`, a nie w `openclaw.plugin.json`.
Ważne przykłady:
| Pole | Co oznacza |
-| ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| `openclaw.extensions` | Deklaruje natywne entrypointy Pluginu. |
-| `openclaw.setupEntry` | Lekki entrypoint tylko do konfiguracji, używany podczas onboardingu i opóźnionego uruchamiania kanału. |
-| `openclaw.channel` | Lekkie metadane katalogu kanałów, takie jak etykiety, ścieżki do dokumentacji, aliasy i teksty wyboru. |
-| `openclaw.channel.configuredState` | Lekkie metadane sprawdzania stanu konfiguracji, które mogą odpowiedzieć na pytanie „czy konfiguracja tylko z env już istnieje?” bez ładowania pełnego runtime kanału. |
-| `openclaw.channel.persistedAuthState` | Lekkie metadane sprawdzania utrwalonego stanu auth, które mogą odpowiedzieć na pytanie „czy coś jest już zalogowane?” bez ładowania pełnego runtime kanału. |
-| `openclaw.install.npmSpec` / `openclaw.install.localPath` | Wskazówki instalacji/aktualizacji dla Pluginów wbudowanych i publikowanych zewnętrznie. |
+| ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
+| `openclaw.extensions` | Deklaruje natywne entrypointy pluginu. |
+| `openclaw.setupEntry` | Lekki entrypoint tylko do setupu używany podczas onboardingu, odroczonego uruchamiania kanału oraz wykrywania statusu kanału/SecretRef tylko do odczytu. |
+| `openclaw.channel` | Lekkie metadane katalogu kanału, takie jak etykiety, ścieżki dokumentacji, aliasy i teksty wyboru. |
+| `openclaw.channel.configuredState` | Lekkie metadane sprawdzania stanu konfiguracji, które potrafią odpowiedzieć na pytanie „czy konfiguracja tylko z env już istnieje?” bez ładowania pełnego runtime kanału. |
+| `openclaw.channel.persistedAuthState` | Lekkie metadane sprawdzania utrwalonego stanu auth, które potrafią odpowiedzieć na pytanie „czy cokolwiek jest już zalogowane?” bez ładowania pełnego runtime kanału. |
+| `openclaw.install.npmSpec` / `openclaw.install.localPath` | Wskazówki instalacji/aktualizacji dla pluginów dołączonych i publikowanych zewnętrznie. |
| `openclaw.install.defaultChoice` | Preferowana ścieżka instalacji, gdy dostępnych jest wiele źródeł instalacji. |
-| `openclaw.install.minHostVersion` | Minimalna obsługiwana wersja hosta OpenClaw, z użyciem dolnego ograniczenia semver, na przykład `>=2026.3.22`. |
-| `openclaw.install.allowInvalidConfigRecovery` | Pozwala na wąską ścieżkę odzyskiwania przez ponowną instalację wbudowanego Pluginu, gdy konfiguracja jest nieprawidłowa. |
-| `openclaw.startup.deferConfiguredChannelFullLoadUntilAfterListen` | Umożliwia załadowanie powierzchni kanału tylko do konfiguracji przed pełnym Pluginem kanału podczas uruchamiania. |
+| `openclaw.install.minHostVersion` | Minimalna obsługiwana wersja hosta OpenClaw, z użyciem dolnego ograniczenia semver, takiego jak `>=2026.3.22`. |
+| `openclaw.install.allowInvalidConfigRecovery` | Pozwala na wąską ścieżkę odzyskiwania po ponownej instalacji dołączonego pluginu, gdy konfiguracja jest nieprawidłowa. |
+| `openclaw.startup.deferConfiguredChannelFullLoadUntilAfterListen` | Pozwala powierzchniom kanału tylko do setupu ładować się przed pełnym pluginem kanału podczas startu. |
-`openclaw.install.minHostVersion` jest egzekwowane podczas instalacji i ładowania rejestru
-manifestu. Nieprawidłowe wartości są odrzucane; nowsze, ale poprawne wartości powodują pominięcie
-Pluginu na starszych hostach.
+`openclaw.install.minHostVersion` jest wymuszane podczas instalacji i ładowania rejestru
+manifestów. Nieprawidłowe wartości są odrzucane; nowsze, ale prawidłowe wartości powodują pominięcie
+pluginu na starszych hostach.
+
+Pluginy kanałów powinny dostarczać `openclaw.setupEntry`, gdy status, lista kanałów
+lub skany SecretRef muszą identyfikować skonfigurowane konta bez ładowania pełnego
+runtime. Entry setupu powinno ujawniać metadane kanału wraz z bezpiecznymi dla setupu adapterami
+konfiguracji, statusu i sekretów; klientów sieciowych, listenerów Gateway i runtime transportu
+należy pozostawić w głównym entrypoincie rozszerzenia.
`openclaw.install.allowInvalidConfigRecovery` jest celowo wąskie. Nie
-sprawia, że dowolnie uszkodzone konfiguracje stają się instalowalne. Obecnie pozwala tylko przepływom instalacji
-odzyskać stan po określonych nieaktualnych błędach aktualizacji wbudowanego Pluginu, takich jak
-brakująca ścieżka wbudowanego Pluginu lub nieaktualny wpis `channels.` dla tego samego
-wbudowanego Pluginu. Niezwiązane błędy konfiguracji nadal blokują instalację i kierują operatorów
+sprawia, że dowolnie uszkodzone konfiguracje stają się instalowalne. Obecnie pozwala tylko
+przepływom instalacji odzyskać się po określonych nieaktualnych awariach aktualizacji dołączonego pluginu,
+takich jak brakująca ścieżka dołączonego pluginu albo nieaktualny wpis `channels.` dla tego samego
+dołączonego pluginu. Niezwiązane błędy konfiguracji nadal blokują instalację i kierują operatorów
do `openclaw doctor --fix`.
`openclaw.channel.persistedAuthState` to metadane pakietu dla małego modułu sprawdzającego:
@@ -551,13 +559,13 @@ do `openclaw doctor --fix`.
}
```
-Użyj tego, gdy przepływy konfiguracji, doctor lub configured-state potrzebują lekkiego
-sprawdzenia auth typu tak/nie przed załadowaniem pełnego Pluginu kanału. Eksport docelowy powinien być małą
-funkcją, która odczytuje wyłącznie stan utrwalony; nie kieruj go przez pełny
-barrel runtime kanału.
+Używaj tego, gdy przepływy setupu, doctora lub configured-state potrzebują lekkiego sprawdzenia
+auth typu tak/nie, zanim pełny plugin kanału zostanie załadowany. Eksport docelowy powinien być małą
+funkcją, która odczytuje wyłącznie utrwalony stan; nie kieruj go przez pełny barrel runtime
+kanału.
-`openclaw.channel.configuredState` ma ten sam kształt dla lekkich sprawdzeń
-skonfigurowania wyłącznie na podstawie env:
+`openclaw.channel.configuredState` ma tę samą postać dla lekkich kontroli
+configured-state opartych wyłącznie na env:
```json
{
@@ -573,75 +581,73 @@ skonfigurowania wyłącznie na podstawie env:
}
```
-Użyj tego, gdy kanał może odpowiedzieć o stanie konfiguracji na podstawie env lub innych małych
-wejść niezwiązanych z runtime. Jeśli sprawdzenie wymaga pełnego rozwiązywania konfiguracji lub rzeczywistego
-runtime kanału, pozostaw tę logikę w hooku Pluginu `config.hasConfiguredState`.
+Używaj tego, gdy kanał może odpowiedzieć o configured-state na podstawie env lub innych małych
+wejść niezwiązanych z runtime. Jeśli kontrola wymaga pełnego rozstrzygnięcia konfiguracji lub prawdziwego
+runtime kanału, pozostaw tę logikę zamiast tego w hooku pluginu `config.hasConfiguredState`.
-## Wymagania JSON Schema
+## Wymagania dotyczące JSON Schema
-- **Każdy Plugin musi dostarczać JSON Schema**, nawet jeśli nie przyjmuje żadnej konfiguracji.
+- **Każdy plugin musi dostarczać JSON Schema**, nawet jeśli nie przyjmuje żadnej konfiguracji.
- Pusty schemat jest akceptowalny (na przykład `{ "type": "object", "additionalProperties": false }`).
- Schematy są walidowane podczas odczytu/zapisu konfiguracji, a nie w runtime.
## Zachowanie walidacji
-- Nieznane klucze `channels.*` są **błędami**, chyba że identyfikator kanału jest zadeklarowany
- przez manifest Pluginu.
+- Nieznane klucze `channels.*` są **błędami**, chyba że identyfikator kanału został zadeklarowany przez
+ manifest pluginu.
- `plugins.entries.`, `plugins.allow`, `plugins.deny` i `plugins.slots.*`
- muszą odwoływać się do **wykrywalnych** identyfikatorów Pluginów. Nieznane identyfikatory są **błędami**.
-- Jeśli Plugin jest zainstalowany, ale ma uszkodzony lub brakujący manifest albo schemat,
- walidacja kończy się niepowodzeniem, a Doctor zgłasza błąd Pluginu.
-- Jeśli konfiguracja Pluginu istnieje, ale Plugin jest **wyłączony**, konfiguracja zostaje zachowana, a
- w Doctor + logach pojawia się **ostrzeżenie**.
+ muszą odwoływać się do **wykrywalnych** identyfikatorów pluginów. Nieznane identyfikatory są **błędami**.
+- Jeśli plugin jest zainstalowany, ale ma uszkodzony lub brakujący manifest albo schemat,
+ walidacja kończy się niepowodzeniem, a Doctor zgłasza błąd pluginu.
+- Jeśli konfiguracja pluginu istnieje, ale plugin jest **wyłączony**, konfiguracja jest zachowywana i
+ w Doctor + logach wyświetlane jest **ostrzeżenie**.
-Pełny schemat `plugins.*` znajdziesz w [Opisie konfiguracji](/pl/gateway/configuration).
+Pełny schemat `plugins.*` znajdziesz w [Configuration reference](/pl/gateway/configuration).
## Uwagi
-- Manifest jest **wymagany dla natywnych Pluginów OpenClaw**, w tym dla ładowania z lokalnego systemu plików.
-- Runtime nadal ładuje moduł Pluginu osobno; manifest służy wyłącznie do
+- Manifest jest **wymagany dla natywnych pluginów OpenClaw**, w tym dla ładowań z lokalnego systemu plików.
+- Runtime nadal ładuje moduł pluginu osobno; manifest służy wyłącznie do
wykrywania + walidacji.
-- Natywne manifesty są parsowane przy użyciu JSON5, więc komentarze, końcowe przecinki i
- klucze bez cudzysłowów są akceptowane, o ile wartość końcowa nadal jest obiektem.
-- Loader manifestu odczytuje wyłącznie udokumentowane pola manifestu. Unikaj dodawania
- tutaj własnych kluczy najwyższego poziomu.
-- `providerAuthEnvVars` to lekka ścieżka metadanych dla sprawdzeń auth, walidacji
- znaczników env i podobnych powierzchni auth providera, które nie powinny uruchamiać runtime Pluginu
- tylko po to, aby sprawdzić nazwy env.
-- `providerAuthAliases` pozwala wariantom providera ponownie używać zmiennych env auth,
+- Natywne manifesty są parsowane przez JSON5, więc komentarze, końcowe przecinki i
+ klucze bez cudzysłowów są akceptowane, o ile końcowa wartość nadal jest obiektem.
+- Loader manifestu odczytuje tylko udokumentowane pola manifestu. Unikaj dodawania
+ własnych kluczy najwyższego poziomu.
+- `providerAuthEnvVars` to lekka ścieżka metadanych dla kontroli auth, walidacji znaczników env
+ i podobnych powierzchni auth providera, które nie powinny uruchamiać runtime pluginu
+ tylko po to, by sprawdzić nazwy env.
+- `providerAuthAliases` pozwala wariantom providerów ponownie używać zmiennych środowiskowych auth,
profili auth, auth opartego na konfiguracji i wyboru onboardingu klucza API innego providera
- bez hardcodowania tej relacji w rdzeniu.
-- `providerEndpoints` pozwala Pluginom providera zarządzać prostymi metadanymi dopasowywania
- hosta/baseUrl endpointu. Używaj tego tylko dla klas endpointów, które rdzeń już obsługuje;
- zachowanie runtime nadal należy do Pluginu.
-- `syntheticAuthRefs` to lekka ścieżka metadanych dla należących do providera hooków
- synthetic auth, które muszą być widoczne dla zimnego wykrywania modeli, zanim rejestr runtime
- zacznie istnieć. Wypisuj tylko odwołania, których runtime provider lub backend CLI rzeczywiście
+ bez zakodowywania tej relacji na sztywno w rdzeniu.
+- `providerEndpoints` pozwala pluginom providerów posiadać proste metadane dopasowywania
+ hosta/baseUrl endpointów. Używaj tego tylko dla klas endpointów, które rdzeń już obsługuje;
+ zachowanie runtime nadal należy do pluginu.
+- `syntheticAuthRefs` to lekka ścieżka metadanych dla należących do providera syntetycznych
+ hooków auth, które muszą być widoczne dla zimnego wykrywania modeli, zanim rejestr runtime zacznie istnieć. Wymieniaj tylko te odwołania, których runtime provider lub backend CLI rzeczywiście
implementuje `resolveSyntheticAuth`.
-- `nonSecretAuthMarkers` to lekka ścieżka metadanych dla należących do wbudowanego Pluginu
- zastępczych kluczy API, takich jak znaczniki lokalne, OAuth lub ambient credential.
+- `nonSecretAuthMarkers` to lekka ścieżka metadanych dla należących do dołączonego pluginu
+ przykładowych kluczy API, takich jak znaczniki poświadczeń lokalnych, OAuth lub środowiskowych.
Rdzeń traktuje je jako niesekretne na potrzeby wyświetlania auth i audytów sekretów bez
- hardcodowania właściciela providera.
-- `channelEnvVars` to lekka ścieżka metadanych dla fallbacku shell-env, promptów konfiguracji
- i podobnych powierzchni kanału, które nie powinny uruchamiać runtime Pluginu
- tylko po to, aby sprawdzić nazwy env.
+ zakodowywania na sztywno właściciela providera.
+- `channelEnvVars` to lekka ścieżka metadanych dla fallbacku shell-env, promptów setupu
+ i podobnych powierzchni kanału, które nie powinny uruchamiać runtime pluginu
+ tylko po to, by sprawdzić nazwy env.
- `providerAuthChoices` to lekka ścieżka metadanych dla selektorów wyboru auth,
- rozwiązywania `--auth-choice`, mapowania preferowanego providera i prostej rejestracji
- flag CLI onboardingu przed załadowaniem runtime providera. Metadane kreatora runtime,
- które wymagają kodu providera, opisano tutaj:
- [Hooki runtime providera](/pl/plugins/architecture#provider-runtime-hooks).
-- Wyłączne typy Pluginów są wybierane przez `plugins.slots.*`.
- - `kind: "memory"` jest wybierane przez `plugins.slots.memory`.
- - `kind: "context-engine"` jest wybierane przez `plugins.slots.contextEngine`
- (domyślnie: wbudowane `legacy`).
-- `channels`, `providers`, `cliBackends` i `skills` można pominąć, jeśli
- Plugin ich nie potrzebuje.
-- Jeśli Twój Plugin zależy od modułów natywnych, opisz kroki budowania oraz wszelkie
- wymagania dotyczące allowlist menedżera pakietów (na przykład pnpm `allow-build-scripts`
+ rozstrzygania `--auth-choice`, mapowania preferowanego providera i prostej rejestracji
+ flag CLI onboardingu przed załadowaniem runtime providera. Informacje o metadanych kreatora runtime,
+ które wymagają kodu providera, znajdziesz w
+ [Provider runtime hooks](/pl/plugins/architecture#provider-runtime-hooks).
+- Wyłączne rodzaje pluginów są wybierane przez `plugins.slots.*`.
+ - `kind: "memory"` jest wybierany przez `plugins.slots.memory`.
+ - `kind: "context-engine"` jest wybierany przez `plugins.slots.contextEngine`
+ (domyślnie: wbudowany `legacy`).
+- `channels`, `providers`, `cliBackends` i `skills` można pominąć, gdy
+ plugin ich nie potrzebuje.
+- Jeśli Twój plugin zależy od modułów natywnych, udokumentuj kroki budowania oraz wszelkie wymagania listy dozwolonych menedżera pakietów (na przykład pnpm `allow-build-scripts`
- `pnpm rebuild `).
## Powiązane
-- [Tworzenie Pluginów](/pl/plugins/building-plugins) — pierwsze kroki z Pluginami
-- [Architektura Pluginów](/pl/plugins/architecture) — architektura wewnętrzna
-- [Przegląd SDK](/pl/plugins/sdk-overview) — opis Plugin SDK
+- [Building Plugins](/pl/plugins/building-plugins) — rozpoczęcie pracy z pluginami
+- [Plugin Architecture](/pl/plugins/architecture) — architektura wewnętrzna
+- [SDK Overview](/pl/plugins/sdk-overview) — dokumentacja referencyjna SDK Plugin
diff --git a/docs/pl/plugins/sdk-channel-plugins.md b/docs/pl/plugins/sdk-channel-plugins.md
index d8538e421..2bc0534fd 100644
--- a/docs/pl/plugins/sdk-channel-plugins.md
+++ b/docs/pl/plugins/sdk-channel-plugins.md
@@ -1,87 +1,87 @@
---
read_when:
- - Tworzysz nowy Plugin kanału wiadomości.
- - Chcesz połączyć OpenClaw z platformą wiadomości.
- - Musisz zrozumieć powierzchnię adaptera ChannelPlugin.
+ - Tworzysz nowy plugin kanału wiadomości
+ - Chcesz połączyć OpenClaw z platformą komunikacyjną
+ - Musisz zrozumieć powierzchnię adaptera ChannelPlugin
sidebarTitle: Channel Plugins
-summary: Przewodnik krok po kroku po tworzeniu Plugin kanału wiadomości dla OpenClaw
-title: Tworzenie Plugin kanałów wiadomości
+summary: Przewodnik krok po kroku dotyczący tworzenia pluginu kanału wiadomości dla OpenClaw
+title: Tworzenie pluginów kanałów
x-i18n:
- generated_at: "2026-04-21T09:57:38Z"
+ generated_at: "2026-04-21T19:20:51Z"
model: gpt-5.4
provider: openai
- source_hash: 569394aeefa0231ae3157a13406f91c97fe7eeff2b62df0d35a893f1ad4d5d05
+ source_hash: 35cae55c13b69f2219bd2f9bd3ee2f7d8c4075bd87f0be11c35a0fddb070fe1e
source_path: plugins/sdk-channel-plugins.md
workflow: 15
---
-# Tworzenie Plugin kanałów
+# Tworzenie pluginów kanałów
-Ten przewodnik prowadzi krok po kroku przez tworzenie Plugin kanału, który łączy OpenClaw z platformą wiadomości. Po jego ukończeniu będziesz mieć działający kanał z bezpieczeństwem DM, parowaniem, wątkowaniem odpowiedzi i wysyłaniem wiadomości wychodzących.
+Ten przewodnik krok po kroku opisuje tworzenie pluginu kanału, który łączy OpenClaw z platformą komunikacyjną. Po jego ukończeniu będziesz mieć działający kanał z zabezpieczeniami DM, parowaniem, wątkowaniem odpowiedzi i wiadomościami wychodzącymi.
- Jeśli nie tworzyłeś wcześniej żadnego Plugin OpenClaw, najpierw przeczytaj
+ Jeśli nie tworzono wcześniej żadnego pluginu OpenClaw, najpierw przeczytaj
[Pierwsze kroki](/pl/plugins/building-plugins), aby poznać podstawową strukturę
pakietu i konfigurację manifestu.
-## Jak działają Plugin kanałów
+## Jak działają pluginy kanałów
-Plugin kanałów nie potrzebują własnych narzędzi do wysyłania/edycji/reakcji. OpenClaw utrzymuje jedno współdzielone narzędzie `message` w core. Twój Plugin posiada:
+Pluginy kanałów nie potrzebują własnych narzędzi do wysyłania/edycji/reakcji. OpenClaw utrzymuje jedno współdzielone narzędzie `message` w rdzeniu. Twój plugin odpowiada za:
-- **Konfigurację** — rozwiązywanie kont i kreator konfiguracji
+- **Konfigurację** — rozpoznawanie kont i kreator konfiguracji
- **Bezpieczeństwo** — politykę DM i listy dozwolonych
- **Parowanie** — przepływ zatwierdzania DM
-- **Gramatykę sesji** — sposób, w jaki identyfikatory rozmów specyficzne dla dostawcy mapują się na czaty bazowe, identyfikatory wątków i fallbacki nadrzędne
-- **Ruch wychodzący** — wysyłanie tekstu, mediów i ankiet na platformę
+- **Gramatykę sesji** — sposób, w jaki identyfikatory rozmów specyficzne dla dostawcy są mapowane na bazowe czaty, identyfikatory wątków i zapasowe elementy nadrzędne
+- **Ruch wychodzący** — wysyłanie tekstu, multimediów i ankiet na platformę
- **Wątkowanie** — sposób wątkowania odpowiedzi
-Core posiada współdzielone narzędzie wiadomości, połączenie promptu, zewnętrzny kształt klucza sesji, ogólne księgowanie `:thread:` i dyspozycję.
+Rdzeń odpowiada za współdzielone narzędzie wiadomości, połączenia z promptami, zewnętrzny kształt klucza sesji, ogólne księgowanie `:thread:` oraz dyspozycję.
-Jeśli Twój kanał dodaje parametry narzędzia wiadomości, które przenoszą źródła mediów, udostępnij te nazwy parametrów przez `describeMessageTool(...).mediaSourceParams`. Core używa tej jawnej listy do normalizacji ścieżek sandbox i polityki dostępu do mediów wychodzących, więc Plugin nie potrzebują wyjątków współdzielonego core dla parametrów specyficznych dla dostawcy, takich jak awatar, załącznik lub obraz okładki.
-Preferuj zwracanie mapy kluczowanej akcją, takiej jak
-`{ "set-profile": ["avatarUrl", "avatarPath"] }`, aby niepowiązane akcje nie dziedziczyły argumentów mediów innej akcji. Płaska tablica nadal działa dla parametrów, które celowo są współdzielone przez każdą udostępnianą akcję.
+Jeśli Twój kanał dodaje parametry narzędzia wiadomości, które przenoszą źródła multimediów, ujawnij te nazwy parametrów przez `describeMessageTool(...).mediaSourceParams`. Rdzeń używa tej jawnej listy do normalizacji ścieżek w piaskownicy i polityki dostępu do multimediów wychodzących, więc pluginy nie potrzebują wyjątków w współdzielonym rdzeniu dla parametrów avatarów, załączników czy obrazów okładek specyficznych dla dostawcy.
+Zalecane jest zwracanie mapy indeksowanej kluczem akcji, na przykład
+`{ "set-profile": ["avatarUrl", "avatarPath"] }`, aby niepowiązane akcje nie dziedziczyły argumentów multimedialnych innej akcji. Płaska tablica nadal działa w przypadku parametrów, które mają być celowo współdzielone przez każdą ujawnioną akcję.
-Jeśli Twoja platforma przechowuje dodatkowy zakres w identyfikatorach rozmów, zachowaj to parsowanie w Plugin za pomocą `messaging.resolveSessionConversation(...)`. To kanoniczny hook do mapowania `rawId` na bazowy identyfikator rozmowy, opcjonalny identyfikator wątku, jawny `baseConversationId` i dowolne `parentConversationCandidates`.
-Gdy zwracasz `parentConversationCandidates`, zachowaj ich kolejność od najwęższego rodzica do najszerszej/bazowej rozmowy.
+Jeśli Twoja platforma przechowuje dodatkowy zakres w identyfikatorach rozmów, zachowaj to parsowanie w pluginie za pomocą `messaging.resolveSessionConversation(...)`. To kanoniczny hook do mapowania `rawId` na bazowy identyfikator rozmowy, opcjonalny identyfikator wątku, jawny `baseConversationId` oraz ewentualne `parentConversationCandidates`.
+Gdy zwracasz `parentConversationCandidates`, zachowaj ich kolejność od najbardziej zawężonego elementu nadrzędnego do najszerszej/bazowej rozmowy.
-Dołączone Plugin, które potrzebują tego samego parsowania, zanim uruchomi się rejestr kanałów, mogą także udostępnić plik najwyższego poziomu `session-key-api.ts` z pasującym eksportem `resolveSessionConversation(...)`. Core używa tej bezpiecznej przy bootstrap powierzchni tylko wtedy, gdy rejestr Plugin środowiska uruchomieniowego nie jest jeszcze dostępny.
+Dołączone pluginy, które potrzebują tego samego parsowania przed uruchomieniem rejestru kanałów, mogą również ujawnić plik najwyższego poziomu `session-key-api.ts` z pasującym eksportem `resolveSessionConversation(...)`. Rdzeń używa tej bezpiecznej dla bootstrapu powierzchni tylko wtedy, gdy rejestr pluginów środowiska uruchomieniowego nie jest jeszcze dostępny.
-`messaging.resolveParentConversationCandidates(...)` pozostaje dostępne jako starszy fallback zgodności, gdy Plugin potrzebuje tylko fallbacków nadrzędnych ponad ogólny/surowy identyfikator. Jeśli istnieją oba hooki, core najpierw używa `resolveSessionConversation(...).parentConversationCandidates`, a do `resolveParentConversationCandidates(...)` wraca tylko wtedy, gdy kanoniczny hook je pominie.
+`messaging.resolveParentConversationCandidates(...)` pozostaje dostępne jako starszy zapasowy mechanizm zgodności, gdy plugin potrzebuje tylko zapasowych elementów nadrzędnych ponad ogólny/surowy identyfikator. Jeśli oba hooki istnieją, rdzeń najpierw używa `resolveSessionConversation(...).parentConversationCandidates`, a do `resolveParentConversationCandidates(...)` wraca tylko wtedy, gdy hook kanoniczny je pomija.
## Zatwierdzenia i możliwości kanału
-Większość Plugin kanałów nie potrzebuje kodu specyficznego dla zatwierdzeń.
+Większość pluginów kanałów nie wymaga kodu specyficznego dla zatwierdzeń.
-- Core posiada zatwierdzenia `/approve` w tym samym czacie, współdzielone ładunki przycisków zatwierdzeń i ogólne dostarczanie fallback.
-- Gdy kanał potrzebuje zachowania specyficznego dla zatwierdzeń, preferuj jeden obiekt `approvalCapability` na Plugin kanału.
-- `ChannelPlugin.approvals` zostało usunięte. Umieść fakty dotyczące dostarczania/natywności/renderowania/uwierzytelniania zatwierdzeń w `approvalCapability`.
-- `plugin.auth` służy tylko do login/logout; core nie odczytuje już hooków uwierzytelniania zatwierdzeń z tego obiektu.
-- `approvalCapability.authorizeActorAction` i `approvalCapability.getActionAvailabilityState` to kanoniczna powierzchnia uwierzytelniania zatwierdzeń.
+- Rdzeń odpowiada za `/approve` w tym samym czacie, współdzielone ładunki przycisków zatwierdzeń i ogólne dostarczanie zapasowe.
+- Preferuj pojedynczy obiekt `approvalCapability` w pluginie kanału, gdy kanał wymaga zachowania specyficznego dla zatwierdzeń.
+- `ChannelPlugin.approvals` zostało usunięte. Umieść fakty o dostarczaniu/natywności/renderowaniu/uwierzytelnianiu zatwierdzeń w `approvalCapability`.
+- `plugin.auth` służy wyłącznie do logowania/wylogowania; rdzeń nie odczytuje już hooków uwierzytelniania zatwierdzeń z tego obiektu.
+- `approvalCapability.authorizeActorAction` i `approvalCapability.getActionAvailabilityState` są kanoniczną powierzchnią dla uwierzytelniania zatwierdzeń.
- Używaj `approvalCapability.getActionAvailabilityState` dla dostępności uwierzytelniania zatwierdzeń w tym samym czacie.
-- Jeśli Twój kanał udostępnia natywne zatwierdzenia exec, użyj `approvalCapability.getExecInitiatingSurfaceState` dla stanu powierzchni inicjującej/natywnego klienta, gdy różni się on od uwierzytelniania zatwierdzeń w tym samym czacie. Core używa tego hooka specyficznego dla exec do rozróżniania `enabled` vs `disabled`, decydowania, czy kanał inicjujący obsługuje natywne zatwierdzenia exec, i uwzględniania kanału we wskazówkach fallback dla natywnego klienta. `createApproverRestrictedNativeApprovalCapability(...)` wypełnia to dla typowego przypadku.
-- Używaj `outbound.shouldSuppressLocalPayloadPrompt` lub `outbound.beforeDeliverPayload` do zachowania cyklu życia ładunku specyficznego dla kanału, takiego jak ukrywanie zduplikowanych lokalnych promptów zatwierdzeń lub wysyłanie wskaźników pisania przed dostarczeniem.
-- `approvalCapability.delivery` używaj tylko do natywnego routingu zatwierdzeń lub tłumienia fallback.
-- `approvalCapability.nativeRuntime` używaj dla natywnych faktów zatwierdzeń należących do kanału. Utrzymuj je leniwe na gorących punktach wejścia kanału za pomocą `createLazyChannelApprovalNativeRuntimeAdapter(...)`, który może importować moduł środowiska uruchomieniowego na żądanie, jednocześnie pozwalając core złożyć cykl życia zatwierdzenia.
-- `approvalCapability.render` używaj tylko wtedy, gdy kanał naprawdę potrzebuje niestandardowych ładunków zatwierdzeń zamiast współdzielonego renderer.
-- Użyj `approvalCapability.describeExecApprovalSetup`, gdy kanał chce, aby odpowiedź ścieżki wyłączonej wyjaśniała dokładne klucze konfiguracji potrzebne do włączenia natywnych zatwierdzeń exec. Hook otrzymuje `{ channel, channelLabel, accountId }`; kanały z nazwanymi kontami powinny renderować ścieżki ograniczone do konta, takie jak `channels..accounts..execApprovals.*`, zamiast domyślnych ustawień najwyższego poziomu.
-- Jeśli kanał może wywnioskować stabilne tożsamości DM podobne do właściciela z istniejącej konfiguracji, użyj `createResolvedApproverActionAuthAdapter` z `openclaw/plugin-sdk/approval-runtime`, aby ograniczyć `/approve` w tym samym czacie bez dodawania logiki specyficznej dla zatwierdzeń do core.
-- Jeśli kanał potrzebuje natywnego dostarczania zatwierdzeń, utrzymuj kod kanału skupiony na normalizacji celu oraz faktach transportu/prezentacji. Użyj `createChannelExecApprovalProfile`, `createChannelNativeOriginTargetResolver`, `createChannelApproverDmTargetResolver` i `createApproverRestrictedNativeApprovalCapability` z `openclaw/plugin-sdk/approval-runtime`. Umieść fakty specyficzne dla kanału za `approvalCapability.nativeRuntime`, najlepiej przez `createChannelApprovalNativeRuntimeAdapter(...)` lub `createLazyChannelApprovalNativeRuntimeAdapter(...)`, aby core mógł złożyć handler i posiadać filtrowanie żądań, routing, deduplikację, wygasanie, subskrypcję Gateway oraz powiadomienia o przekierowaniu. `nativeRuntime` jest podzielone na kilka mniejszych powierzchni:
-- `availability` — czy konto jest skonfigurowane i czy żądanie powinno być obsłużone
-- `presentation` — mapowanie współdzielonego modelu widoku zatwierdzenia na oczekujące/rozwiązane/wygasłe natywne ładunki lub końcowe akcje
+- Jeśli Twój kanał udostępnia natywne zatwierdzenia exec, używaj `approvalCapability.getExecInitiatingSurfaceState` dla stanu powierzchni inicjującej/klienta natywnego, gdy różni się on od uwierzytelniania zatwierdzeń w tym samym czacie. Rdzeń używa tego hooka specyficznego dla exec do rozróżniania `enabled` i `disabled`, decydowania, czy kanał inicjujący obsługuje natywne zatwierdzenia exec, oraz uwzględniania kanału w wskazówkach awaryjnych dla klienta natywnego. `createApproverRestrictedNativeApprovalCapability(...)` wypełnia to w typowym przypadku.
+- Używaj `outbound.shouldSuppressLocalPayloadPrompt` lub `outbound.beforeDeliverPayload` dla zachowań cyklu życia ładunku specyficznych dla kanału, takich jak ukrywanie zduplikowanych lokalnych promptów zatwierdzeń lub wysyłanie wskaźników pisania przed dostarczeniem.
+- Używaj `approvalCapability.delivery` tylko do natywnego routingu zatwierdzeń lub tłumienia dostarczania zapasowego.
+- Używaj `approvalCapability.nativeRuntime` dla natywnych faktów o zatwierdzeniach będących własnością kanału. Zachowaj leniwe ładowanie na gorących punktach wejścia kanału za pomocą `createLazyChannelApprovalNativeRuntimeAdapter(...)`, który może importować moduł środowiska uruchomieniowego na żądanie, a jednocześnie pozwalać rdzeniowi składać cykl życia zatwierdzeń.
+- Używaj `approvalCapability.render` tylko wtedy, gdy kanał naprawdę potrzebuje własnych ładunków zatwierdzeń zamiast współdzielonego renderera.
+- Używaj `approvalCapability.describeExecApprovalSetup`, gdy kanał chce, aby odpowiedź w ścieżce wyłączonej wyjaśniała dokładne ustawienia konfiguracji potrzebne do włączenia natywnych zatwierdzeń exec. Hook otrzymuje `{ channel, channelLabel, accountId }`; kanały z nazwanymi kontami powinny renderować ścieżki zależne od konta, takie jak `channels..accounts..execApprovals.*`, zamiast domyślnych ścieżek najwyższego poziomu.
+- Jeśli kanał może wywnioskować stabilne tożsamości DM podobne do właściciela z istniejącej konfiguracji, użyj `createResolvedApproverActionAuthAdapter` z `openclaw/plugin-sdk/approval-runtime`, aby ograniczyć `/approve` w tym samym czacie bez dodawania logiki zatwierdzeń specyficznej dla rdzenia.
+- Jeśli kanał potrzebuje natywnego dostarczania zatwierdzeń, skoncentruj kod kanału na normalizacji celu oraz faktach o transporcie/prezentacji. Użyj `createChannelExecApprovalProfile`, `createChannelNativeOriginTargetResolver`, `createChannelApproverDmTargetResolver` i `createApproverRestrictedNativeApprovalCapability` z `openclaw/plugin-sdk/approval-runtime`. Umieść fakty specyficzne dla kanału za `approvalCapability.nativeRuntime`, najlepiej przez `createChannelApprovalNativeRuntimeAdapter(...)` lub `createLazyChannelApprovalNativeRuntimeAdapter(...)`, aby rdzeń mógł złożyć obsługę i przejąć filtrowanie żądań, routing, deduplikację, wygasanie, subskrypcję Gateway oraz powiadomienia o skierowaniu gdzie indziej. `nativeRuntime` jest podzielone na kilka mniejszych powierzchni:
+- `availability` — czy konto jest skonfigurowane i czy żądanie powinno zostać obsłużone
+- `presentation` — mapowanie współdzielonego modelu widoku zatwierdzeń na oczekujące/rozstrzygnięte/wygasłe natywne ładunki lub działania końcowe
- `transport` — przygotowanie celów oraz wysyłanie/aktualizowanie/usuwanie natywnych wiadomości zatwierdzeń
- `interactions` — opcjonalne hooki bind/unbind/clear-action dla natywnych przycisków lub reakcji
- `observe` — opcjonalne hooki diagnostyki dostarczania
-- Jeśli kanał potrzebuje obiektów należących do środowiska uruchomieniowego, takich jak klient, token, aplikacja Bolt lub odbiornik Webhook, zarejestruj je przez `openclaw/plugin-sdk/channel-runtime-context`. Ogólny rejestr kontekstu środowiska uruchomieniowego pozwala core bootstrapować handlery sterowane możliwościami ze stanu startowego kanału bez dodawania otoczki specyficznej dla zatwierdzeń.
-- Sięgaj po niższy poziom `createChannelApprovalHandler` lub `createChannelNativeApprovalRuntime` tylko wtedy, gdy powierzchnia oparta na możliwościach nie jest jeszcze wystarczająco ekspresyjna.
-- Kanały z natywnymi zatwierdzeniami muszą routować zarówno `accountId`, jak i `approvalKind` przez te pomocniki. `accountId` utrzymuje zakres polityki zatwierdzeń wielu kont dla właściwego konta bota, a `approvalKind` utrzymuje zachowanie zatwierdzeń exec vs Plugin dostępne dla kanału bez twardo zakodowanych rozgałęzień w core.
-- Core posiada teraz także powiadomienia o ponownym routingu zatwierdzeń. Plugin kanałów nie powinny wysyłać własnych wiadomości uzupełniających typu „zatwierdzenie trafiło do DM / innego kanału” z `createChannelNativeApprovalRuntime`; zamiast tego udostępniaj dokładny routing źródła + DM zatwierdzającego przez współdzielone pomocniki możliwości zatwierdzeń i pozwól core agregować rzeczywiste dostarczenia przed opublikowaniem jakiegokolwiek powiadomienia z powrotem do czatu inicjującego.
-- Zachowuj rodzaj dostarczonego identyfikatora zatwierdzenia od końca do końca. Klienci natywni nie powinni zgadywać ani przepisywać routingu zatwierdzeń exec vs Plugin na podstawie lokalnego stanu kanału.
-- Różne rodzaje zatwierdzeń mogą celowo udostępniać różne natywne powierzchnie.
+- Jeśli kanał potrzebuje obiektów będących własnością środowiska uruchomieniowego, takich jak klient, token, aplikacja Bolt lub odbiornik Webhook, zarejestruj je przez `openclaw/plugin-sdk/channel-runtime-context`. Ogólny rejestr kontekstu środowiska uruchomieniowego pozwala rdzeniowi uruchamiać handlery sterowane możliwościami na podstawie stanu uruchomienia kanału bez dodawania opakowującego kodu specyficznego dla zatwierdzeń.
+- Sięgaj po niższopoziomowe `createChannelApprovalHandler` lub `createChannelNativeApprovalRuntime` tylko wtedy, gdy powierzchnia sterowana możliwościami nie jest jeszcze wystarczająco ekspresyjna.
+- Kanały natywnych zatwierdzeń muszą przekazywać zarówno `accountId`, jak i `approvalKind` przez te pomocniki. `accountId` utrzymuje zakres polityki zatwierdzeń wielokontowych na właściwym koncie bota, a `approvalKind` utrzymuje zachowanie zatwierdzeń exec vs Plugin dostępne dla kanału bez zakodowanych na sztywno rozgałęzień w rdzeniu.
+- Rdzeń odpowiada teraz także za powiadomienia o ponownym skierowaniu zatwierdzeń. Pluginy kanałów nie powinny wysyłać własnych komunikatów uzupełniających typu „zatwierdzenie trafiło do DM / innego kanału” z `createChannelNativeApprovalRuntime`; zamiast tego ujawnij dokładny routing źródła + DM zatwierdzającego przez współdzielone pomocniki możliwości zatwierdzeń i pozwól rdzeniowi agregować rzeczywiste dostarczenia przed opublikowaniem jakiegokolwiek powiadomienia z powrotem na czacie inicjującym.
+- Zachowuj typ identyfikatora dostarczonego zatwierdzenia od początku do końca. Klienci natywni nie powinni zgadywać ani przepisywać routingu zatwierdzeń exec vs Plugin na podstawie stanu lokalnego kanału.
+- Różne rodzaje zatwierdzeń mogą celowo ujawniać różne powierzchnie natywne.
Obecne dołączone przykłady:
- - Slack utrzymuje natywny routing zatwierdzeń dostępny zarówno dla identyfikatorów exec, jak i Plugin.
- - Matrix utrzymuje ten sam natywny routing DM/kanał i UX reakcji dla zatwierdzeń exec i Plugin, jednocześnie nadal pozwalając, by uwierzytelnianie różniło się według rodzaju zatwierdzenia.
-- `createApproverRestrictedNativeApprovalAdapter` nadal istnieje jako wrapper zgodności, ale nowy kod powinien preferować builder możliwości i udostępniać `approvalCapability` w Plugin.
+ - Slack zachowuje dostępność natywnego routingu zatwierdzeń zarówno dla identyfikatorów exec, jak i Plugin.
+ - Matrix zachowuje ten sam natywny routing DM/kanału i UX reakcji dla zatwierdzeń exec i Plugin, jednocześnie nadal pozwalając, by uwierzytelnianie różniło się zależnie od rodzaju zatwierdzenia.
+- `createApproverRestrictedNativeApprovalAdapter` nadal istnieje jako opakowanie zgodności, ale nowy kod powinien preferować konstruktor możliwości i ujawniać `approvalCapability` w pluginie.
Dla gorących punktów wejścia kanału preferuj węższe podścieżki środowiska uruchomieniowego, gdy potrzebujesz tylko jednej części tej rodziny:
@@ -99,73 +99,87 @@ Podobnie preferuj `openclaw/plugin-sdk/setup-runtime`,
`openclaw/plugin-sdk/setup-adapter-runtime`,
`openclaw/plugin-sdk/reply-runtime`,
`openclaw/plugin-sdk/reply-dispatch-runtime`,
-`openclaw/plugin-sdk/reply-reference` i
+`openclaw/plugin-sdk/reply-reference` oraz
`openclaw/plugin-sdk/reply-chunking`, gdy nie potrzebujesz szerszej powierzchni parasolowej.
-Konkretnie dla konfiguracji:
+Konkretnie w przypadku konfiguracji:
- `openclaw/plugin-sdk/setup-runtime` obejmuje bezpieczne dla środowiska uruchomieniowego helpery konfiguracji:
- adaptery poprawek konfiguracji bezpieczne przy imporcie (`createPatchedAccountSetupAdapter`,
+ bezpieczne importowo adaptery łatek konfiguracji (`createPatchedAccountSetupAdapter`,
`createEnvPatchedAccountSetupAdapter`,
- `createSetupInputPresenceValidator`), wyjście lookup-note,
- `promptResolvedAllowFrom`, `splitSetupEntries` i delegowane buildery setup-proxy
-- `openclaw/plugin-sdk/setup-adapter-runtime` to wąska powierzchnia adaptera świadoma env dla `createEnvPatchedAccountSetupAdapter`
-- `openclaw/plugin-sdk/channel-setup` obejmuje buildery konfiguracji opcjonalnej instalacji oraz kilka prymitywów bezpiecznych dla konfiguracji:
+ `createSetupInputPresenceValidator`), wyjście notatek wyszukiwania,
+ `promptResolvedAllowFrom`, `splitSetupEntries` oraz delegowane
+ konstruktory proxy konfiguracji
+- `openclaw/plugin-sdk/setup-adapter-runtime` to wąska, świadoma env powierzchnia adaptera
+ dla `createEnvPatchedAccountSetupAdapter`
+- `openclaw/plugin-sdk/channel-setup` obejmuje konstruktory konfiguracji opcjonalnej instalacji
+ oraz kilka prymitywów bezpiecznych dla konfiguracji:
`createOptionalChannelSetupSurface`, `createOptionalChannelSetupAdapter`,
-Jeśli Twój kanał obsługuje konfigurację lub uwierzytelnianie sterowane env i ogólne przepływy startowe/konfiguracyjne powinny znać te nazwy env przed załadowaniem środowiska uruchomieniowego, zadeklaruj je w manifeście Plugin przez `channelEnvVars`. Zachowaj `envVars` środowiska uruchomieniowego kanału lub lokalne stałe tylko dla kopii skierowanej do operatora.
+Jeśli Twój kanał obsługuje konfigurację lub uwierzytelnianie sterowane przez env i ogólne przepływy uruchamiania/konfiguracji mają znać te nazwy env przed załadowaniem środowiska uruchomieniowego, zadeklaruj je w manifeście pluginu przez `channelEnvVars`. Zachowaj środowiskouruchomieniowe `envVars` kanału lub lokalne stałe tylko dla kopii skierowanej do operatora.
+
+Jeśli Twój kanał może pojawiać się w `status`, `channels list`, `channels status` lub skanach SecretRef przed uruchomieniem środowiska pluginu, dodaj `openclaw.setupEntry` w `package.json`. Ten punkt wejścia powinien być bezpieczny do importowania w ścieżkach poleceń tylko do odczytu i powinien zwracać metadane kanału, bezpieczny dla konfiguracji adapter konfiguracji, adapter statusu oraz metadane celu sekretów kanału potrzebne do tych podsumowań. Nie uruchamiaj klientów, listenerów ani środowisk transportowych z punktu wejścia konfiguracji.
+
`createOptionalChannelSetupWizard`, `DEFAULT_ACCOUNT_ID`,
-`createTopLevelChannelDmPolicy`, `setSetupChannelEnabled` i
+`createTopLevelChannelDmPolicy`, `setSetupChannelEnabled` oraz
`splitSetupEntries`
-- sięgaj po szerszą powierzchnię `openclaw/plugin-sdk/setup` tylko wtedy, gdy potrzebujesz także cięższych współdzielonych helperów konfiguracji, takich jak
+- używaj szerszej powierzchni `openclaw/plugin-sdk/setup` tylko wtedy, gdy potrzebujesz także
+ cięższych współdzielonych helperów konfiguracji/ustawień, takich jak
`moveSingleAccountChannelSectionToDefaultAccount(...)`
-Jeśli Twój kanał chce tylko reklamować „najpierw zainstaluj ten Plugin” na powierzchniach konfiguracji, preferuj `createOptionalChannelSetupSurface(...)`. Wygenerowany adapter/kreator domyślnie odmawia zapisów konfiguracji i finalizacji oraz ponownie używa tego samego komunikatu o wymaganej instalacji w walidacji, finalizacji i treści z linkiem do dokumentacji.
+Jeśli Twój kanał chce tylko informować w powierzchniach konfiguracji „najpierw zainstaluj ten plugin”, preferuj `createOptionalChannelSetupSurface(...)`. Wygenerowany adapter/kreator domyślnie odrzuca zapisy konfiguracji i finalizację oraz ponownie wykorzystuje ten sam komunikat o wymaganej instalacji w walidacji, finalizacji i treści linku do dokumentacji.
-Dla innych gorących ścieżek kanału preferuj wąskie helpery zamiast szerszych starszych powierzchni:
+W przypadku innych gorących ścieżek kanału preferuj wąskie helpery zamiast szerszych starszych powierzchni:
- `openclaw/plugin-sdk/account-core`,
`openclaw/plugin-sdk/account-id`,
- `openclaw/plugin-sdk/account-resolution` i
- `openclaw/plugin-sdk/account-helpers` dla konfiguracji wielu kont i fallback do konta domyślnego
-- `openclaw/plugin-sdk/inbound-envelope` i
- `openclaw/plugin-sdk/inbound-reply-dispatch` dla routingu/koperty ruchu przychodzącego oraz połączenia zapisu i dyspozycji
-- `openclaw/plugin-sdk/messaging-targets` dla parsowania/dopasowywania celów
-- `openclaw/plugin-sdk/outbound-media` i
- `openclaw/plugin-sdk/outbound-runtime` dla ładowania mediów oraz delegatów tożsamości/wysyłki wychodzącej i planowania ładunku
-- `openclaw/plugin-sdk/thread-bindings-runtime` dla cyklu życia powiązań wątków i rejestracji adapterów
-- `openclaw/plugin-sdk/agent-media-payload` tylko wtedy, gdy nadal wymagany jest starszy układ pól ładunku agent/media
-- `openclaw/plugin-sdk/telegram-command-config` dla normalizacji niestandardowych poleceń Telegram, walidacji duplikatów/konfliktów i stabilnego kontraktu konfiguracji poleceń jako fallback
+ `openclaw/plugin-sdk/account-resolution` oraz
+ `openclaw/plugin-sdk/account-helpers` do konfiguracji wielokontowej i
+ zapasowego przełączania na konto domyślne
+- `openclaw/plugin-sdk/inbound-envelope` oraz
+ `openclaw/plugin-sdk/inbound-reply-dispatch` do routingu/koperty wejściowej i
+ połączenia rejestrowania z dyspozycją
+- `openclaw/plugin-sdk/messaging-targets` do parsowania/dopasowywania celów
+- `openclaw/plugin-sdk/outbound-media` oraz
+ `openclaw/plugin-sdk/outbound-runtime` do ładowania multimediów oraz
+ delegatów tożsamości/wysyłania wychodzącego i planowania ładunków
+- `openclaw/plugin-sdk/thread-bindings-runtime` do cyklu życia powiązań wątków
+ i rejestracji adapterów
+- `openclaw/plugin-sdk/agent-media-payload` tylko wtedy, gdy nadal wymagany
+ jest starszy układ pól ładunku agenta/multimediów
+- `openclaw/plugin-sdk/telegram-command-config` do normalizacji własnych komend Telegram,
+ walidacji duplikatów/konfliktów oraz kontraktu konfiguracji komend
+ stabilnego wobec fallbacków
-Kanały tylko z uwierzytelnianiem zwykle mogą zatrzymać się na ścieżce domyślnej: core obsługuje zatwierdzenia, a Plugin jedynie udostępnia możliwości outbound/auth. Kanały z natywnymi zatwierdzeniami, takie jak Matrix, Slack, Telegram i niestandardowe transporty czatu, powinny używać współdzielonych natywnych helperów zamiast implementować własny cykl życia zatwierdzeń.
+Kanały wyłącznie uwierzytelniające zwykle mogą zakończyć na ścieżce domyślnej: rdzeń obsługuje zatwierdzenia, a plugin jedynie ujawnia możliwości wychodzące/uwierzytelniania. Kanały natywnych zatwierdzeń, takie jak Matrix, Slack, Telegram i własne transporty czatu, powinny używać współdzielonych helperów natywnych zamiast tworzyć własny cykl życia zatwierdzeń.
## Polityka wzmianek przychodzących
-Obsługę wzmianek przychodzących utrzymuj rozdzieloną na dwie warstwy:
+Obsługę wzmianek przychodzących zachowaj rozdzieloną na dwie warstwy:
-- zbieranie danych należące do Plugin
+- gromadzenie dowodów należące do pluginu
- współdzielona ocena polityki
-Do decyzji polityki wzmianek używaj `openclaw/plugin-sdk/channel-mention-gating`.
-Po `openclaw/plugin-sdk/channel-inbound` sięgaj tylko wtedy, gdy potrzebujesz szerszego
+Używaj `openclaw/plugin-sdk/channel-mention-gating` do decyzji dotyczących polityki wzmianek.
+Używaj `openclaw/plugin-sdk/channel-inbound` tylko wtedy, gdy potrzebujesz szerszego
barrela helperów przychodzących.
-Dobrze pasuje do lokalnej logiki Plugin:
+Dobrze pasuje do logiki lokalnej pluginu:
- wykrywanie odpowiedzi do bota
- wykrywanie cytatu bota
-- sprawdzanie uczestnictwa w wątku
-- wykluczanie wiadomości usługowych/systemowych
+- sprawdzanie uczestnictwa we wątku
+- wykluczanie wiadomości serwisowych/systemowych
- natywne dla platformy cache potrzebne do potwierdzenia udziału bota
Dobrze pasuje do współdzielonego helpera:
- `requireMention`
- jawny wynik wzmianki
-- lista dozwolonych ukrytych wzmianek
-- obejście dla poleceń
-- końcowa decyzja o pominięciu
+- lista dozwolonych dla niejawnych wzmianek
+- obejście dla komend
+- ostateczna decyzja o pominięciu
Preferowany przepływ:
@@ -210,8 +224,8 @@ const decision = resolveInboundMentionDecision({
if (decision.shouldSkip) return;
```
-`api.runtime.channel.mentions` udostępnia te same współdzielone helpery wzmianek
-dla dołączonych Plugin kanałów, które już zależą od wstrzykiwania środowiska uruchomieniowego:
+`api.runtime.channel.mentions` ujawnia te same współdzielone helpery wzmianek dla
+dołączonych pluginów kanałów, które już zależą od wstrzykiwania środowiska uruchomieniowego:
- `buildMentionRegexes`
- `matchesMentionPatterns`
@@ -219,23 +233,23 @@ dla dołączonych Plugin kanałów, które już zależą od wstrzykiwania środo
- `implicitMentionKindWhen`
- `resolveInboundMentionDecision`
-Jeśli potrzebujesz tylko `implicitMentionKindWhen` i
+Jeśli potrzebujesz tylko `implicitMentionKindWhen` oraz
`resolveInboundMentionDecision`, importuj z
-`openclaw/plugin-sdk/channel-mention-gating`, aby uniknąć ładowania
-niepowiązanych helperów środowiska uruchomieniowego ruchu przychodzącego.
+`openclaw/plugin-sdk/channel-mention-gating`, aby uniknąć ładowania niezwiązanych
+helperów środowiska uruchomieniowego dla ruchu przychodzącego.
Starsze helpery `resolveMentionGating*` pozostają w
`openclaw/plugin-sdk/channel-inbound` wyłącznie jako eksporty zgodności. Nowy kod
powinien używać `resolveInboundMentionDecision({ facts, policy })`.
-## Przewodnik krok po kroku
+## Omówienie krok po kroku
- Utwórz standardowe pliki Plugin. Pole `channel` w `package.json`
- sprawia, że jest to Plugin kanału. Pełną powierzchnię metadanych pakietu
- znajdziesz w [Plugin Setup and Config](/pl/plugins/sdk-setup#openclaw-channel):
+ Utwórz standardowe pliki pluginu. Pole `channel` w `package.json`
+ sprawia, że jest to plugin kanału. Pełny zakres metadanych pakietu
+ znajdziesz w [Konfiguracja i ustawienia pluginu](/pl/plugins/sdk-setup#openclaw-channel):
```json package.json
@@ -249,7 +263,7 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
"channel": {
"id": "acme-chat",
"label": "Acme Chat",
- "blurb": "Połącz OpenClaw z Acme Chat."
+ "blurb": "Connect OpenClaw to Acme Chat."
}
}
}
@@ -261,7 +275,7 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
"kind": "channel",
"channels": ["acme-chat"],
"name": "Acme Chat",
- "description": "Plugin kanału Acme Chat",
+ "description": "Acme Chat channel plugin",
"configSchema": {
"type": "object",
"additionalProperties": false,
@@ -284,9 +298,9 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
-
- Interfejs `ChannelPlugin` ma wiele opcjonalnych powierzchni adaptera. Zacznij od
- minimum — `id` i `setup` — i dodawaj adaptery w miarę potrzeb.
+
+ Interfejs `ChannelPlugin` ma wiele opcjonalnych powierzchni adapterów. Zacznij
+ od minimum — `id` i `setup` — i dodawaj adaptery w miarę potrzeb.
Utwórz `src/channel.ts`:
@@ -296,7 +310,7 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
createChannelPluginBase,
} from "openclaw/plugin-sdk/channel-core";
import type { OpenClawConfig } from "openclaw/plugin-sdk/channel-core";
- import { acmeChatApi } from "./client.js"; // klient API Twojej platformy
+ import { acmeChatApi } from "./client.js"; // your platform API client
type ResolvedAccount = {
accountId: string | null;
@@ -311,7 +325,7 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
): ResolvedAccount {
const section = (cfg.channels as Record)?.["acme-chat"];
const token = section?.token;
- if (!token) throw new Error("acme-chat: wymagany jest token");
+ if (!token) throw new Error("acme-chat: token is required");
return {
accountId: accountId ?? null,
token,
@@ -337,7 +351,7 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
},
}),
- // Bezpieczeństwo DM: kto może pisać do bota
+ // DM security: who can message the bot
security: {
dm: {
channelKey: "acme-chat",
@@ -347,21 +361,21 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
},
},
- // Parowanie: przepływ zatwierdzania dla nowych kontaktów DM
+ // Pairing: approval flow for new DM contacts
pairing: {
text: {
- idLabel: "nazwa użytkownika Acme Chat",
- message: "Wyślij ten kod, aby potwierdzić swoją tożsamość:",
+ idLabel: "Acme Chat username",
+ message: "Send this code to verify your identity:",
notify: async ({ target, code }) => {
- await acmeChatApi.sendDm(target, `Kod parowania: ${code}`);
+ await acmeChatApi.sendDm(target, `Pairing code: ${code}`);
},
},
},
- // Wątkowanie: jak dostarczane są odpowiedzi
+ // Threading: how replies are delivered
threading: { topLevelReplyToMode: "reply" },
- // Ruch wychodzący: wysyłanie wiadomości na platformę
+ // Outbound: send messages to the platform
outbound: {
attachedResults: {
sendText: async (params) => {
@@ -381,16 +395,16 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
});
```
-
+
Zamiast ręcznie implementować niskopoziomowe interfejsy adapterów,
- przekazujesz deklaratywne opcje, a builder je składa:
+ przekazujesz deklaratywne opcje, a konstruktor je składa:
| Opcja | Co podłącza |
| --- | --- |
- | `security.dm` | Ograniczony do zakresu resolver bezpieczeństwa DM z pól konfiguracji |
- | `pairing.text` | Tekstowy przepływ parowania DM z wymianą kodu |
- | `threading` | Resolver trybu reply-to (stały, ograniczony do konta lub niestandardowy) |
- | `outbound.attachedResults` | Funkcje wysyłania zwracające metadane wyniku (ID wiadomości) |
+ | `security.dm` | Ograniczony zakresem resolver bezpieczeństwa DM z pól konfiguracji |
+ | `pairing.text` | Tekstowy przepływ parowania DM z wymianą kodów |
+ | `threading` | Resolver trybu reply-to (stały, zależny od konta lub własny) |
+ | `outbound.attachedResults` | Funkcje wysyłania zwracające metadane wyniku (identyfikatory wiadomości) |
Możesz też przekazać surowe obiekty adapterów zamiast opcji deklaratywnych,
jeśli potrzebujesz pełnej kontroli.
@@ -408,20 +422,20 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
export default defineChannelPluginEntry({
id: "acme-chat",
name: "Acme Chat",
- description: "Plugin kanału Acme Chat",
+ description: "Acme Chat channel plugin",
plugin: acmeChatPlugin,
registerCliMetadata(api) {
api.registerCli(
({ program }) => {
program
.command("acme-chat")
- .description("Zarządzanie Acme Chat");
+ .description("Acme Chat management");
},
{
descriptors: [
{
name: "acme-chat",
- description: "Zarządzanie Acme Chat",
+ description: "Acme Chat management",
hasSubcommands: false,
},
],
@@ -434,22 +448,22 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
});
```
- Umieść deskryptory CLI należące do kanału w `registerCliMetadata(...)`, aby OpenClaw
- mógł pokazywać je w głównej pomocy bez aktywowania pełnego środowiska uruchomieniowego kanału,
- podczas gdy zwykłe pełne ładowania nadal pobiorą te same deskryptory do rzeczywistej rejestracji poleceń.
- `registerFull(...)` zachowaj dla pracy tylko w środowisku uruchomieniowym.
- Jeśli `registerFull(...)` rejestruje metody Gateway RPC, użyj
- prefiksu specyficznego dla Plugin. Przestrzenie nazw administracyjnych core (`config.*`,
+ Umieszczaj deskryptory CLI należące do kanału w `registerCliMetadata(...)`, aby OpenClaw
+ mógł pokazywać je w pomocy głównej bez aktywowania pełnego środowiska uruchomieniowego kanału,
+ podczas gdy zwykłe pełne ładowania nadal przejmują te same deskryptory do rzeczywistej
+ rejestracji komend. Zachowaj `registerFull(...)` dla pracy wykonywanej wyłącznie w środowisku uruchomieniowym.
+ Jeśli `registerFull(...)` rejestruje metody Gateway RPC, używaj
+ prefiksu specyficznego dla pluginu. Przestrzenie nazw administratora rdzenia (`config.*`,
`exec.approvals.*`, `wizard.*`, `update.*`) pozostają zarezerwowane i zawsze
są rozwiązywane do `operator.admin`.
- `defineChannelPluginEntry` automatycznie obsługuje podział trybów rejestracji. Zobacz
- [Entry Points](/pl/plugins/sdk-entrypoints#definechannelpluginentry), aby poznać wszystkie
+ `defineChannelPluginEntry` automatycznie obsługuje rozdzielenie trybów rejestracji. Zobacz
+ [Punkty wejścia](/pl/plugins/sdk-entrypoints#definechannelpluginentry), aby poznać wszystkie
opcje.
-
- Utwórz `setup-entry.ts` do lekkiego ładowania podczas wdrażania:
+
+ Utwórz `setup-entry.ts` do lekkiego ładowania podczas onboardingu:
```typescript setup-entry.ts
import { defineSetupPluginEntry } from "openclaw/plugin-sdk/channel-core";
@@ -460,31 +474,31 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
OpenClaw ładuje to zamiast pełnego punktu wejścia, gdy kanał jest wyłączony
lub nieskonfigurowany. Pozwala to uniknąć wciągania ciężkiego kodu środowiska uruchomieniowego podczas przepływów konfiguracji.
- Szczegóły znajdziesz w [Setup and Config](/pl/plugins/sdk-setup#setup-entry).
+ Szczegóły znajdziesz w [Konfiguracja i ustawienia](/pl/plugins/sdk-setup#setup-entry).
- Dołączone kanały workspace, które rozdzielają eksporty bezpieczne dla konfiguracji do modułów pomocniczych,
- mogą użyć `defineBundledChannelSetupEntry(...)` z
- `openclaw/plugin-sdk/channel-entry-contract`, gdy potrzebują także
+ Dołączone kanały obszaru roboczego, które dzielą eksporty bezpieczne dla konfiguracji do modułów pobocznych,
+ mogą używać `defineBundledChannelSetupEntry(...)` z
+ `openclaw/plugin-sdk/channel-entry-contract`, gdy potrzebują również
jawnego settera środowiska uruchomieniowego na etapie konfiguracji.
-
- Twój Plugin musi odbierać wiadomości z platformy i przekazywać je do
- OpenClaw. Typowym wzorcem jest Webhook, który weryfikuje żądanie i
+
+ Twój plugin musi odbierać wiadomości z platformy i przekazywać je do
+ OpenClaw. Typowy wzorzec to Webhook, który weryfikuje żądanie i
przekazuje je przez handler przychodzący Twojego kanału:
```typescript
registerFull(api) {
api.registerHttpRoute({
path: "/acme-chat/webhook",
- auth: "plugin", // uwierzytelnianie zarządzane przez Plugin (podpisy weryfikujesz samodzielnie)
+ auth: "plugin", // uwierzytelnianie zarządzane przez plugin (samodzielnie zweryfikuj sygnatury)
handler: async (req, res) => {
const event = parseWebhookPayload(req);
- // Twój handler przychodzący przekazuje wiadomość do OpenClaw.
- // Dokładne podłączenie zależy od SDK Twojej platformy —
- // zobacz rzeczywisty przykład w dołączonym pakiecie Plugin Microsoft Teams lub Google Chat.
+ // Twój handler ruchu przychodzącego przekazuje wiadomość do OpenClaw.
+ // Dokładne połączenie zależy od SDK Twojej platformy —
+ // rzeczywisty przykład znajdziesz w dołączonym pakiecie pluginu Microsoft Teams lub Google Chat.
await handleAcmeChatInbound(api, event);
res.statusCode = 200;
@@ -496,23 +510,23 @@ powinien używać `resolveInboundMentionDecision({ facts, policy })`.
```
- Obsługa wiadomości przychodzących jest specyficzna dla kanału. Każdy Plugin kanału posiada
- własny potok ruchu przychodzącego. Zobacz dołączone Plugin kanałów
- (na przykład pakiet Plugin Microsoft Teams lub Google Chat), aby zobaczyć rzeczywiste wzorce.
+ Obsługa wiadomości przychodzących jest specyficzna dla kanału. Każdy plugin kanału
+ odpowiada za własny potok ruchu przychodzącego. Sprawdź dołączone pluginy kanałów
+ (na przykład pakiet pluginu Microsoft Teams lub Google Chat), aby zobaczyć rzeczywiste wzorce.
-
-Napisz testy współlokowane w `src/channel.test.ts`:
+
+Napisz testy obok kodu w `src/channel.test.ts`:
```typescript src/channel.test.ts
import { describe, it, expect } from "vitest";
import { acmeChatPlugin } from "./channel.js";
- describe("plugin acme-chat", () => {
- it("rozwiązuje konto z konfiguracji", () => {
+ describe("acme-chat plugin", () => {
+ it("resolves account from config", () => {
const cfg = {
channels: {
"acme-chat": { token: "test-token", allowFrom: ["user1"] },
@@ -522,7 +536,7 @@ Napisz testy współlokowane w `src/channel.test.ts`:
expect(account.token).toBe("test-token");
});
- it("sprawdza konto bez materializowania sekretów", () => {
+ it("inspects account without materializing secrets", () => {
const cfg = {
channels: { "acme-chat": { token: "test-token" } },
} as any;
@@ -531,7 +545,7 @@ Napisz testy współlokowane w `src/channel.test.ts`:
expect(result.tokenStatus).toBe("available");
});
- it("zgłasza brakującą konfigurację", () => {
+ it("reports missing config", () => {
const cfg = { channels: {} } as any;
const result = acmeChatPlugin.setup!.inspectAccount!(cfg, undefined);
expect(result.configured).toBe(false);
@@ -543,7 +557,7 @@ Napisz testy współlokowane w `src/channel.test.ts`:
pnpm test -- /acme-chat/
```
- Współdzielone helpery testowe znajdziesz w [Testing](/pl/plugins/sdk-testing).
+ Współdzielone helpery testowe opisano w [Testowanie](/pl/plugins/sdk-testing).
@@ -553,45 +567,45 @@ Napisz testy współlokowane w `src/channel.test.ts`:
```
/acme-chat/
├── package.json # metadane openclaw.channel
-├── openclaw.plugin.json # Manifest ze schematem konfiguracji
+├── openclaw.plugin.json # manifest ze schematem konfiguracji
├── index.ts # defineChannelPluginEntry
├── setup-entry.ts # defineSetupPluginEntry
-├── api.ts # Eksporty publiczne (opcjonalnie)
-├── runtime-api.ts # Wewnętrzne eksporty środowiska uruchomieniowego (opcjonalnie)
+├── api.ts # eksporty publiczne (opcjonalnie)
+├── runtime-api.ts # wewnętrzne eksporty środowiska uruchomieniowego (opcjonalnie)
└── src/
├── channel.ts # ChannelPlugin przez createChatChannelPlugin
- ├── channel.test.ts # Testy
- ├── client.ts # Klient API platformy
- └── runtime.ts # Magazyn środowiska uruchomieniowego (w razie potrzeby)
+ ├── channel.test.ts # testy
+ ├── client.ts # klient API platformy
+ └── runtime.ts # magazyn środowiska uruchomieniowego (jeśli potrzebny)
```
## Tematy zaawansowane
- Stałe, ograniczone do konta lub niestandardowe tryby odpowiedzi
+ Stałe, zależne od konta lub własne tryby odpowiedzi
-
+
describeMessageTool i wykrywanie akcji
-
+
inferTargetChatType, looksLikeId, resolveTarget
- TTS, STT, media, podagent przez api.runtime
+ TTS, STT, multimedia, subagent przez api.runtime
Niektóre dołączone powierzchnie helperów nadal istnieją na potrzeby utrzymania
-i zgodności bundled plugins. Nie są zalecanym wzorcem dla nowych Plugin kanałów;
-preferuj ogólne podścieżki channel/setup/reply/runtime ze wspólnej powierzchni SDK,
-chyba że bezpośrednio utrzymujesz tę rodzinę bundled plugins.
+i zgodności dołączonych pluginów. Nie są zalecanym wzorcem dla nowych pluginów kanałów;
+preferuj ogólne podścieżki channel/setup/reply/runtime ze wspólnej
+powierzchni SDK, chyba że bezpośrednio utrzymujesz tę rodzinę dołączonych pluginów.
## Następne kroki
-- [Plugin dostawców](/pl/plugins/sdk-provider-plugins) — jeśli Twój Plugin udostępnia także modele
-- [Przegląd SDK](/pl/plugins/sdk-overview) — pełna dokumentacja importów subpath
-- [SDK Testing](/pl/plugins/sdk-testing) — narzędzia testowe i testy kontraktowe
-- [Manifest Plugin](/pl/plugins/manifest) — pełny schemat manifestu
+- [Pluginy dostawców](/pl/plugins/sdk-provider-plugins) — jeśli Twój plugin udostępnia także modele
+- [Przegląd SDK](/pl/plugins/sdk-overview) — pełne odniesienie do importów podścieżek
+- [Testowanie SDK](/pl/plugins/sdk-testing) — narzędzia testowe i testy kontraktowe
+- [Manifest pluginu](/pl/plugins/manifest) — pełny schemat manifestu
diff --git a/docs/pl/providers/github-copilot.md b/docs/pl/providers/github-copilot.md
index d67deefcb..e011fb26d 100644
--- a/docs/pl/providers/github-copilot.md
+++ b/docs/pl/providers/github-copilot.md
@@ -1,31 +1,27 @@
---
read_when:
- - Chcesz używać GitHub Copilot jako dostawcy modeli
+ - Chcesz używać GitHub Copilot jako dostawcy modelu
- Potrzebujesz przepływu `openclaw models auth login-github-copilot`.
-summary: Zaloguj się do GitHub Copilot z OpenClaw przy użyciu device flow
+summary: Zaloguj się do GitHub Copilot z OpenClaw za pomocą przepływu urządzenia
title: GitHub Copilot
x-i18n:
- generated_at: "2026-04-21T09:59:56Z"
+ generated_at: "2026-04-21T19:20:45Z"
model: gpt-5.4
provider: openai
- source_hash: f7faafbd3bdcd8886e75fb0d40c3eec66355df3fca6160ebbbb9a0018b7839fe
+ source_hash: b5169839322f64b24b194302b61c5bad67c6cb6595989f9a1ef65867d8b68659
source_path: providers/github-copilot.md
workflow: 15
---
# GitHub Copilot
-GitHub Copilot to asystent kodowania AI od GitHub. Zapewnia dostęp do modeli
-Copilot dla twojego konta i planu GitHub. OpenClaw może używać Copilot jako
-dostawcy modeli na dwa różne sposoby.
+GitHub Copilot to asystent kodowania AI od GitHub. Zapewnia dostęp do modeli Copilot dla Twojego konta i planu GitHub. OpenClaw może używać Copilot jako dostawcy modelu na dwa różne sposoby.
## Dwa sposoby używania Copilot w OpenClaw
- Użyj natywnego przepływu logowania device, aby uzyskać token GitHub, a następnie wymieniać go na
- tokeny API Copilot podczas działania OpenClaw. To **domyślna** i najprostsza ścieżka,
- ponieważ nie wymaga VS Code.
+ Użyj natywnego przepływu logowania urządzenia, aby uzyskać token GitHub, a następnie wymieniaj go na tokeny API Copilot podczas działania OpenClaw. To **domyślna** i najprostsza ścieżka, ponieważ nie wymaga VS Code.
@@ -33,20 +29,19 @@ dostawcy modeli na dwa różne sposoby.
openclaw models auth login-github-copilot
```
- Zostaniesz poproszony o odwiedzenie adresu URL i wpisanie jednorazowego kodu. Pozostaw
- terminal otwarty do czasu zakończenia.
+ Zostaniesz poproszony o odwiedzenie adresu URL i wpisanie jednorazowego kodu. Pozostaw terminal otwarty, aż proces się zakończy.
-
+
```bash
- openclaw models set github-copilot/claude-opus-4.6
+ openclaw models set github-copilot/claude-opus-4.7
```
- Albo w konfiguracji:
+ Lub w konfiguracji:
```json5
{
agents: {
- defaults: { model: { primary: "github-copilot/claude-opus-4.6" } },
+ defaults: { model: { primary: "github-copilot/claude-opus-4.7" } },
},
}
```
@@ -56,12 +51,10 @@ dostawcy modeli na dwa różne sposoby.
- Użyj rozszerzenia VS Code **Copilot Proxy** jako lokalnego mostka. OpenClaw komunikuje się z
- endpointem `/v1` proxy i używa listy modeli, którą tam skonfigurujesz.
+ Użyj rozszerzenia VS Code **Copilot Proxy** jako lokalnego mostu. OpenClaw komunikuje się z punktem końcowym `/v1` proxy i używa listy modeli, którą tam skonfigurujesz.
- Wybierz to, gdy już uruchamiasz Copilot Proxy w VS Code albo musisz kierować ruch
- przez niego. Musisz włączyć plugin i utrzymywać rozszerzenie VS Code uruchomione.
+ Wybierz tę opcję, jeśli masz już uruchomiony Copilot Proxy w VS Code lub musisz kierować ruch przez niego. Musisz włączyć plugin i utrzymywać uruchomione rozszerzenie VS Code.
@@ -69,77 +62,67 @@ dostawcy modeli na dwa różne sposoby.
## Opcjonalne flagi
-| Flag | Opis |
+| Flag | Opis |
| --------------- | --------------------------------------------------- |
-| `--yes` | Pomiń monit o potwierdzenie |
-| `--set-default` | Zastosuj także zalecany model domyślny dostawcy |
+| `--yes` | Pomiń monit o potwierdzenie |
+| `--set-default` | Zastosuj także zalecany domyślny model dostawcy |
```bash
# Pomiń potwierdzenie
openclaw models auth login-github-copilot --yes
-# Zaloguj się i ustaw model domyślny w jednym kroku
+# Zaloguj się i ustaw domyślny model w jednym kroku
openclaw models auth login --provider github-copilot --method device --set-default
```
- Przepływ logowania device wymaga interaktywnego TTY. Uruchom go bezpośrednio w
- terminalu, a nie w nieinteraktywnym skrypcie ani w pipeline CI.
+ Przepływ logowania urządzenia wymaga interaktywnego TTY. Uruchom go bezpośrednio w terminalu, a nie w nieinteraktywnym skrypcie lub potoku CI.
-
- Dostępność modeli Copilot zależy od twojego planu GitHub. Jeśli model zostanie
- odrzucony, spróbuj innego identyfikatora (na przykład `github-copilot/gpt-4.1`).
+
+ Dostępność modeli Copilot zależy od Twojego planu GitHub. Jeśli model zostanie odrzucony, wypróbuj inny identyfikator (na przykład `github-copilot/gpt-4.1`).
- Identyfikatory modeli Claude automatycznie używają transportu Anthropic Messages. Modele GPT,
- z serii o i Gemini zachowują transport OpenAI Responses. OpenClaw
- wybiera właściwy transport na podstawie model-ref.
+ Identyfikatory modeli Claude automatycznie używają transportu Anthropic Messages. Modele GPT, o-series i Gemini zachowują transport OpenAI Responses. OpenClaw wybiera właściwy transport na podstawie referencji modelu.
- OpenClaw rozwiązuje uwierzytelnianie Copilot ze zmiennych środowiskowych w następującej
- kolejności priorytetu:
+ OpenClaw rozwiązuje uwierzytelnianie Copilot na podstawie zmiennych środowiskowych w następującej kolejności priorytetów:
- | Priority | Variable | Notes |
- | -------- | --------------------- | --------------------------------- |
- | 1 | `COPILOT_GITHUB_TOKEN` | Najwyższy priorytet, specyficzne dla Copilot |
- | 2 | `GH_TOKEN` | Token GitHub CLI (zapasowy) |
- | 3 | `GITHUB_TOKEN` | Standardowy token GitHub (najniższy) |
+ | Priorytet | Zmienna | Uwagi |
+ | -------- | --------------------- | -------------------------------- |
+ | 1 | `COPILOT_GITHUB_TOKEN` | Najwyższy priorytet, specyficzna dla Copilot |
+ | 2 | `GH_TOKEN` | Token GitHub CLI (zapasowy) |
+ | 3 | `GITHUB_TOKEN` | Standardowy token GitHub (najniższy priorytet) |
Gdy ustawionych jest wiele zmiennych, OpenClaw używa tej o najwyższym priorytecie.
- Przepływ logowania device (`openclaw models auth login-github-copilot`) przechowuje
- swój token w magazynie profilu uwierzytelniania i ma pierwszeństwo przed wszystkimi zmiennymi
- środowiskowymi.
+ Przepływ logowania urządzenia (`openclaw models auth login-github-copilot`) zapisuje swój token w magazynie profili auth i ma pierwszeństwo przed wszystkimi zmiennymi środowiskowymi.
-
- Logowanie przechowuje token GitHub w magazynie profilu uwierzytelniania i wymienia go
- na token API Copilot podczas działania OpenClaw. Nie musisz ręcznie zarządzać
- tokenem.
+
+ Logowanie zapisuje token GitHub w magazynie profili auth i wymienia go na token API Copilot podczas działania OpenClaw. Nie musisz zarządzać tokenem ręcznie.
-Wymaga interaktywnego TTY. Uruchom polecenie logowania bezpośrednio w terminalu, a nie
-wewnątrz skryptu headless ani zadania CI.
+Wymaga interaktywnego TTY. Uruchom polecenie logowania bezpośrednio w terminalu, a nie wewnątrz skryptu bez interfejsu lub zadania CI.
-## Embeddingi wyszukiwania pamięci
+## Osadzenia wyszukiwania pamięci
-GitHub Copilot może także pełnić rolę dostawcy embeddingów dla
+GitHub Copilot może również służyć jako dostawca osadzeń dla
[wyszukiwania pamięci](/pl/concepts/memory-search). Jeśli masz subskrypcję Copilot i
-jesteś zalogowany, OpenClaw może używać go do embeddingów bez osobnego klucza API.
+jesteś zalogowany, OpenClaw może używać go do osadzeń bez osobnego klucza API.
### Automatyczne wykrywanie
-Gdy `memorySearch.provider` ma wartość `"auto"` (domyślnie), GitHub Copilot jest próbowany
-z priorytetem 15 — po embeddingach lokalnych, ale przed OpenAI i innymi płatnymi
+Gdy `memorySearch.provider` ma wartość `"auto"` (domyślną), GitHub Copilot jest sprawdzany
+z priorytetem 15 — po lokalnych osadzeniach, ale przed OpenAI i innymi płatnymi
dostawcami. Jeśli dostępny jest token GitHub, OpenClaw wykrywa dostępne
-modele embeddingów z API Copilot i automatycznie wybiera najlepszy.
+modele osadzeń z API Copilot i automatycznie wybiera najlepszy.
### Jawna konfiguracja
@@ -149,7 +132,7 @@ modele embeddingów z API Copilot i automatycznie wybiera najlepszy.
defaults: {
memorySearch: {
provider: "github-copilot",
- // Opcjonalnie: nadpisz model wykryty automatycznie
+ // Opcjonalnie: zastąp model wykryty automatycznie
model: "text-embedding-3-small",
},
},
@@ -159,22 +142,22 @@ modele embeddingów z API Copilot i automatycznie wybiera najlepszy.
### Jak to działa
-1. OpenClaw rozwiązuje twój token GitHub (ze zmiennych środowiskowych lub profilu uwierzytelniania).
+1. OpenClaw rozwiązuje Twój token GitHub (ze zmiennych środowiskowych lub profilu auth).
2. Wymienia go na krótkotrwały token API Copilot.
-3. Odpytuje endpoint Copilot `/models`, aby wykryć dostępne modele embeddingów.
+3. Odpytuje punkt końcowy Copilot `/models`, aby wykryć dostępne modele osadzeń.
4. Wybiera najlepszy model (preferuje `text-embedding-3-small`).
-5. Wysyła żądania embeddingów do endpointu Copilot `/embeddings`.
+5. Wysyła żądania osadzeń do punktu końcowego Copilot `/embeddings`.
-Dostępność modeli zależy od twojego planu GitHub. Jeśli żadne modele embeddingów nie są
+Dostępność modeli zależy od Twojego planu GitHub. Jeśli żadne modele osadzeń nie są
dostępne, OpenClaw pomija Copilot i próbuje następnego dostawcę.
## Powiązane
-
- Wybieranie dostawców, model-ref i zachowania failover.
+
+ Wybór dostawców, referencji modeli i zachowania failover.
-
- Szczegóły uwierzytelniania i zasady ponownego użycia poświadczeń.
+
+ Szczegóły auth i reguły ponownego użycia poświadczeń.
diff --git a/docs/pl/tools/subagents.md b/docs/pl/tools/subagents.md
index 9cd148028..907278e70 100644
--- a/docs/pl/tools/subagents.md
+++ b/docs/pl/tools/subagents.md
@@ -1,26 +1,26 @@
---
read_when:
- - Chcesz pracy w tle/równoległej przez agenta
- - Zmieniasz `sessions_spawn` lub politykę narzędzi subagentów
- - Implementujesz lub rozwiązujesz problemy z sesjami subagentów powiązanymi z wątkiem
-summary: 'Subagenci: uruchamianie izolowanych przebiegów agentów, które ogłaszają wyniki z powrotem na czacie żądającym'
-title: Subagenci
+ - Chcesz wykonywać pracę w tle/równolegle za pomocą agenta
+ - Zmieniasz zasady `sessions_spawn` lub narzędzia podagenta
+ - Implementujesz lub rozwiązujesz problemy z sesjami podagentów powiązanymi z wątkiem
+summary: 'Podagenci: uruchamianie izolowanych przebiegów agentów, które ogłaszają wyniki z powrotem na czacie żądającego'
+title: Podagenci
x-i18n:
- generated_at: "2026-04-05T14:10:13Z"
+ generated_at: "2026-04-21T19:20:47Z"
model: gpt-5.4
provider: openai
- source_hash: 9df7cc35a3069ce4eb9c92a95df3ce5365a00a3fae92ff73def75461b58fec3f
+ source_hash: 218913f0db88d40e1b5fdb0201b8d23e7af23df572c86ff4be2637cb62498281
source_path: tools/subagents.md
workflow: 15
---
-# Subagenci
+# Podagenci
-Subagenci to przebiegi agentów w tle uruchamiane z istniejącego przebiegu agenta. Działają we własnej sesji (`agent::subagent:`) i po zakończeniu **ogłaszają** swój wynik z powrotem na kanał czatu żądającego. Każdy przebieg subagenta jest śledzony jako [zadanie w tle](/pl/automation/tasks).
+Podagenci to uruchamiane w tle przebiegi agentów tworzone z istniejącego przebiegu agenta. Działają we własnej sesji (`agent::subagent:`) i po zakończeniu **ogłaszają** swój wynik z powrotem na kanale czatu żądającego. Każdy przebieg podagenta jest śledzony jako [zadanie w tle](/pl/automation/tasks).
-## Polecenie slash
+## Polecenie ukośnikowe
-Użyj `/subagents`, aby sprawdzać lub sterować przebiegami subagentów dla **bieżącej sesji**:
+Użyj `/subagents`, aby sprawdzić lub kontrolować przebiegi podagentów dla **bieżącej sesji**:
- `/subagents list`
- `/subagents kill `
@@ -30,9 +30,9 @@ Użyj `/subagents`, aby sprawdzać lub sterować przebiegami subagentów dla **b
- `/subagents steer `
- `/subagents spawn [--model ] [--thinking ]`
-Sterowanie powiązaniami z wątkiem:
+Elementy sterujące powiązaniem z wątkiem:
-Te polecenia działają na kanałach obsługujących trwałe powiązania z wątkami. Zobacz **Kanały obsługujące wątki** poniżej.
+Te polecenia działają na kanałach, które obsługują trwałe powiązania z wątkami. Zobacz **Kanały obsługujące wątki** poniżej.
- `/focus `
- `/unfocus`
@@ -40,128 +40,129 @@ Te polecenia działają na kanałach obsługujących trwałe powiązania z wątk
- `/session idle `
- `/session max-age `
-`/subagents info` pokazuje metadane przebiegu (status, znaczniki czasu, identyfikator sesji, ścieżkę transkryptu, cleanup).
-Użyj `sessions_history` do ograniczonego widoku przypominania filtrowanego pod kątem bezpieczeństwa; sprawdź
+`/subagents info` pokazuje metadane przebiegu (stan, znaczniki czasu, identyfikator sesji, ścieżkę transkryptu, czyszczenie).
+Użyj `sessions_history`, aby uzyskać ograniczony widok historii z filtrowaniem bezpieczeństwa; sprawdź
ścieżkę transkryptu na dysku, gdy potrzebujesz surowego pełnego transkryptu.
-### Zachowanie spawn
+### Zachowanie uruchamiania
-`/subagents spawn` uruchamia subagenta w tle jako polecenie użytkownika, a nie wewnętrzny relay, i wysyła jedną końcową aktualizację o ukończeniu z powrotem na czat żądającego po zakończeniu przebiegu.
+`/subagents spawn` uruchamia podagenta w tle jako polecenie użytkownika, a nie wewnętrzne przekazanie, i wysyła jedną końcową aktualizację ukończenia z powrotem na czat żądającego, gdy przebieg się zakończy.
-- Polecenie spawn jest nieblokujące; natychmiast zwraca identyfikator przebiegu.
-- Po ukończeniu subagent ogłasza wiadomość z podsumowaniem/wynikiem z powrotem na kanał czatu żądającego.
-- Dostarczenie ukończenia jest oparte na push. Po uruchomieniu nie należy odpytywać w pętli `/subagents list`,
- `sessions_list` ani `sessions_history` tylko po to, by czekać na zakończenie; sprawdzaj status wyłącznie na żądanie do debugowania lub interwencji.
-- Po ukończeniu OpenClaw w trybie best-effort zamyka śledzone karty/procesy przeglądarki otwarte przez tę sesję subagenta, zanim przepływ cleanup ogłoszenia będzie kontynuowany.
-- Dla ręcznych spawn dostarczanie jest odporne:
+- Polecenie uruchamiania nie blokuje; natychmiast zwraca identyfikator przebiegu.
+- Po zakończeniu podagent ogłasza wiadomość z podsumowaniem/wynikiem z powrotem na kanale czatu żądającego.
+- Dostarczenie ukończenia odbywa się w trybie push. Po uruchomieniu nie wykonuj zapętlonego odpytywania `/subagents list`,
+ `sessions_list` ani `sessions_history` tylko po to, aby czekać na zakończenie;
+ sprawdzaj stan wyłącznie na żądanie do debugowania lub interwencji.
+- Po zakończeniu OpenClaw w miarę możliwości zamyka śledzone karty/pr procesy przeglądarki otwarte przez sesję tego podagenta, zanim przepływ czyszczenia ogłoszenia będzie kontynuowany.
+- Dla ręcznych uruchomień dostarczanie jest odporne:
- OpenClaw najpierw próbuje bezpośredniego dostarczenia `agent` ze stabilnym kluczem idempotencji.
- - Jeśli bezpośrednie dostarczenie zawiedzie, wraca do routingu kolejki.
- - Jeśli routing kolejki nadal nie jest dostępny, ogłoszenie jest ponawiane z krótkim wykładniczym backoffem przed ostatecznym poddaniem się.
-- Dostarczanie ukończenia zachowuje rozwiązaną trasę żądającego:
- - trasy ukończenia powiązane z wątkiem lub konwersacją wygrywają, gdy są dostępne
- - jeśli źródło ukończenia dostarcza tylko kanał, OpenClaw uzupełnia brakujący target/konto z rozwiązanej trasy sesji żądającego (`lastChannel` / `lastTo` / `lastAccountId`), aby bezpośrednie dostarczenie nadal działało
-- Przekazanie ukończenia do sesji żądającego jest generowanym w runtime wewnętrznym kontekstem (a nie tekstem tworzonym przez użytkownika) i zawiera:
- - `Result` (najnowszy widoczny tekst odpowiedzi `assistant`, w przeciwnym razie oczyszczony najnowszy tekst `tool`/`toolResult`)
+ - Jeśli bezpośrednie dostarczenie się nie powiedzie, przechodzi do routingu przez kolejkę.
+ - Jeśli routing przez kolejkę nadal nie jest dostępny, ogłoszenie jest ponawiane z krótkim wykładniczym wycofaniem przed ostateczną rezygnacją.
+- Dostarczenie ukończenia zachowuje rozwiązaną trasę żądającego:
+ - trasy ukończenia powiązane z wątkiem lub rozmową mają pierwszeństwo, gdy są dostępne
+ - jeśli źródło ukończenia udostępnia tylko kanał, OpenClaw uzupełnia brakujący cel/konto z rozwiązanej trasy sesji żądającego (`lastChannel` / `lastTo` / `lastAccountId`), aby bezpośrednie dostarczenie nadal działało
+- Przekazanie ukończenia do sesji żądającego to wewnętrzny kontekst generowany w czasie działania (nie tekst napisany przez użytkownika) i obejmuje:
+ - `Result` (ostatni widoczny tekst odpowiedzi `assistant`, w przeciwnym razie oczyszczony ostatni tekst `tool`/`toolResult`; zakończone niepowodzeniem przebiegi terminalne nie używają ponownie przechwyconego tekstu odpowiedzi)
- `Status` (`completed successfully` / `failed` / `timed out` / `unknown`)
- - zwarte statystyki runtime/tokenów
- - instrukcję dostarczenia mówiącą agentowi żądającemu, aby przepisał wynik normalnym głosem asystenta (a nie przekazywał surowych wewnętrznych metadanych)
-- `--model` i `--thinking` nadpisują ustawienia domyślne tylko dla tego konkretnego przebiegu.
-- Użyj `info`/`log`, aby sprawdzić szczegóły i output po ukończeniu.
-- `/subagents spawn` to tryb jednorazowy (`mode: "run"`). Dla trwałych sesji powiązanych z wątkiem użyj `sessions_spawn` z `thread: true` i `mode: "session"`.
-- Dla sesji harness ACP (Codex, Claude Code, Gemini CLI) użyj `sessions_spawn` z `runtime: "acp"` i zobacz [Agenci ACP](/tools/acp-agents).
+ - zwięzłe statystyki środowiska wykonawczego/tokenów
+ - instrukcję dostarczenia mówiącą agentowi żądającemu, aby przepisał to zwykłym głosem asystenta (a nie przekazywał surowych wewnętrznych metadanych)
+- `--model` i `--thinking` zastępują ustawienia domyślne dla tego konkretnego przebiegu.
+- Użyj `info`/`log`, aby sprawdzić szczegóły i dane wyjściowe po zakończeniu.
+- `/subagents spawn` działa w trybie jednorazowym (`mode: "run"`). Dla trwałych sesji powiązanych z wątkiem użyj `sessions_spawn` z `thread: true` i `mode: "session"`.
+- W przypadku sesji uprzęży ACP (Codex, Claude Code, Gemini CLI) użyj `sessions_spawn` z `runtime: "acp"` i zobacz [Agenci ACP](/pl/tools/acp-agents).
Główne cele:
-- Zrównoleglić pracę typu „research / długie zadanie / wolne narzędzie” bez blokowania głównego przebiegu.
-- Domyślnie utrzymywać izolację subagentów (separacja sesji + opcjonalny sandboxing).
-- Utrzymać powierzchnię narzędzi trudną do niewłaściwego użycia: subagenci **nie** dostają domyślnie narzędzi sesji.
-- Obsługiwać konfigurowalną głębokość zagnieżdżenia dla wzorców orkiestratorów.
+- Równoleglenie pracy typu „research / długie zadanie / wolne narzędzie” bez blokowania głównego przebiegu.
+- Domyślna izolacja podagentów (rozdzielenie sesji + opcjonalny sandbox).
+- Utrzymanie powierzchni narzędzi trudnej do niewłaściwego użycia: podagenci domyślnie **nie** dostają narzędzi sesji.
+- Obsługa konfigurowalnej głębokości zagnieżdżenia dla wzorców orkiestracji.
-Uwaga o kosztach: każdy subagent ma **własny** kontekst i własne zużycie tokenów. Dla ciężkich lub powtarzalnych
-zadań ustaw tańszy model dla subagentów i pozostaw głównego agenta na modelu wyższej jakości.
-Można to skonfigurować przez `agents.defaults.subagents.model` albo nadpisania per agent.
+Uwaga o kosztach: każdy podagent ma **własny** kontekst i własne zużycie tokenów. W przypadku ciężkich lub powtarzalnych
+zadań ustaw tańszy model dla podagentów, a głównego agenta pozostaw na modelu wyższej jakości.
+Możesz to skonfigurować przez `agents.defaults.subagents.model` lub nadpisania dla konkretnego agenta.
## Narzędzie
Użyj `sessions_spawn`:
-- Uruchamia przebieg subagenta (`deliver: false`, globalna kolejka: `subagent`)
-- Następnie uruchamia krok announce i publikuje odpowiedź announce na kanale czatu żądającego
-- Model domyślny: dziedziczy z wywołującego, chyba że ustawisz `agents.defaults.subagents.model` (albo per-agent `agents.list[].subagents.model`); jawne `sessions_spawn.model` nadal ma pierwszeństwo.
-- Thinking domyślnie: dziedziczy z wywołującego, chyba że ustawisz `agents.defaults.subagents.thinking` (albo per-agent `agents.list[].subagents.thinking`); jawne `sessions_spawn.thinking` nadal ma pierwszeństwo.
-- Domyślny timeout przebiegu: jeśli `sessions_spawn.runTimeoutSeconds` jest pominięte, OpenClaw używa `agents.defaults.subagents.runTimeoutSeconds`, jeśli ustawione; w przeciwnym razie wraca do `0` (brak timeoutu).
+- Uruchamia przebieg podagenta (`deliver: false`, globalna ścieżka: `subagent`)
+- Następnie wykonuje krok ogłoszenia i publikuje odpowiedź ogłoszenia na kanale czatu żądającego
+- Model domyślny: dziedziczy po wywołującym, chyba że ustawisz `agents.defaults.subagents.model` (lub `agents.list[].subagents.model` dla konkretnego agenta); jawne `sessions_spawn.model` nadal ma pierwszeństwo.
+- Domyślny poziom myślenia: dziedziczy po wywołującym, chyba że ustawisz `agents.defaults.subagents.thinking` (lub `agents.list[].subagents.thinking` dla konkretnego agenta); jawne `sessions_spawn.thinking` nadal ma pierwszeństwo.
+- Domyślny limit czasu przebiegu: jeśli pominięto `sessions_spawn.runTimeoutSeconds`, OpenClaw używa `agents.defaults.subagents.runTimeoutSeconds`, jeśli jest ustawione; w przeciwnym razie wraca do `0` (bez limitu czasu).
Parametry narzędzia:
- `task` (wymagane)
- `label?` (opcjonalne)
-- `agentId?` (opcjonalne; uruchamia pod innym identyfikatorem agenta, jeśli dozwolone)
-- `model?` (opcjonalne; nadpisuje model subagenta; nieprawidłowe wartości są pomijane, a subagent działa na modelu domyślnym z ostrzeżeniem w wyniku narzędzia)
-- `thinking?` (opcjonalne; nadpisuje poziom thinking dla przebiegu subagenta)
-- `runTimeoutSeconds?` (domyślnie `agents.defaults.subagents.runTimeoutSeconds`, jeśli ustawione, w przeciwnym razie `0`; jeśli ustawione, przebieg subagenta jest przerywany po N sekundach)
-- `thread?` (domyślnie `false`; gdy `true`, żąda powiązania sesji subagenta z wątkiem kanału)
+- `agentId?` (opcjonalne; uruchom pod innym identyfikatorem agenta, jeśli jest to dozwolone)
+- `model?` (opcjonalne; zastępuje model podagenta; nieprawidłowe wartości są pomijane, a podagent uruchamia się na modelu domyślnym z ostrzeżeniem w wyniku narzędzia)
+- `thinking?` (opcjonalne; zastępuje poziom myślenia dla przebiegu podagenta)
+- `runTimeoutSeconds?` (domyślnie `agents.defaults.subagents.runTimeoutSeconds`, jeśli ustawione, w przeciwnym razie `0`; gdy ustawione, przebieg podagenta jest przerywany po N sekundach)
+- `thread?` (domyślnie `false`; gdy `true`, żąda powiązania z wątkiem kanału dla sesji tego podagenta)
- `mode?` (`run|session`)
- - domyślnie `run`
- - jeśli `thread: true` i `mode` pominięto, wartością domyślną staje się `session`
+ - domyślnie jest `run`
+ - jeśli `thread: true` i pominięto `mode`, domyślną wartością staje się `session`
- `mode: "session"` wymaga `thread: true`
- `cleanup?` (`delete|keep`, domyślnie `keep`)
-- `sandbox?` (`inherit|require`, domyślnie `inherit`; `require` odrzuca spawn, jeśli docelowy runtime potomny nie jest sandboxowany)
+- `sandbox?` (`inherit|require`, domyślnie `inherit`; `require` odrzuca uruchomienie, jeśli docelowe środowisko potomne nie jest sandboxowane)
- `sessions_spawn` **nie** akceptuje parametrów dostarczania kanałowego (`target`, `channel`, `to`, `threadId`, `replyTo`, `transport`). Do dostarczania użyj `message`/`sessions_send` z uruchomionego przebiegu.
## Sesje powiązane z wątkiem
-Gdy powiązania z wątkami są włączone dla kanału, subagent może pozostać powiązany z wątkiem, dzięki czemu kolejne wiadomości użytkownika w tym wątku nadal są kierowane do tej samej sesji subagenta.
+Gdy powiązania z wątkami są włączone dla kanału, podagent może pozostać powiązany z wątkiem, tak aby kolejne wiadomości użytkownika w tym wątku nadal trafiały do tej samej sesji podagenta.
### Kanały obsługujące wątki
-- Discord (obecnie jedyny obsługiwany kanał): obsługuje trwałe sesje subagentów powiązane z wątkiem (`sessions_spawn` z `thread: true`), ręczne sterowanie wątkami (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) oraz klucze adaptera `channels.discord.threadBindings.enabled`, `channels.discord.threadBindings.idleHours`, `channels.discord.threadBindings.maxAgeHours` i `channels.discord.threadBindings.spawnSubagentSessions`.
+- Discord (obecnie jedyny obsługiwany kanał): obsługuje trwałe sesje podagentów powiązane z wątkami (`sessions_spawn` z `thread: true`), ręczne sterowanie wątkami (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) oraz klucze adaptera `channels.discord.threadBindings.enabled`, `channels.discord.threadBindings.idleHours`, `channels.discord.threadBindings.maxAgeHours` i `channels.discord.threadBindings.spawnSubagentSessions`.
Szybki przepływ:
-1. Uruchom spawn przez `sessions_spawn`, używając `thread: true` (i opcjonalnie `mode: "session"`).
-2. OpenClaw tworzy lub wiąże wątek z tym celem sesji w aktywnym kanale.
+1. Uruchom za pomocą `sessions_spawn`, używając `thread: true` (i opcjonalnie `mode: "session"`).
+2. OpenClaw tworzy wątek lub wiąże go z celem tej sesji w aktywnym kanale.
3. Odpowiedzi i kolejne wiadomości w tym wątku są kierowane do powiązanej sesji.
-4. Użyj `/session idle`, aby sprawdzić/zaktualizować automatyczne rozwiązywanie fokusu po bezczynności, oraz `/session max-age`, aby sterować twardym limitem.
+4. Użyj `/session idle`, aby sprawdzić/zaktualizować automatyczne odpinanie po bezczynności, oraz `/session max-age`, aby sterować twardym limitem.
5. Użyj `/unfocus`, aby odłączyć ręcznie.
Sterowanie ręczne:
-- `/focus ` wiąże bieżący wątek (lub tworzy go) z celem subagenta/sesji.
+- `/focus ` wiąże bieżący wątek (lub tworzy nowy) z celem podagenta/sesji.
- `/unfocus` usuwa powiązanie dla bieżącego powiązanego wątku.
- `/agents` wyświetla aktywne przebiegi i stan powiązania (`thread:` lub `unbound`).
-- `/session idle` i `/session max-age` działają tylko dla sfokusowanych powiązanych wątków.
+- `/session idle` i `/session max-age` działają tylko dla skupionych powiązanych wątków.
-Przełączniki config:
+Przełączniki konfiguracji:
- Globalne ustawienia domyślne: `session.threadBindings.enabled`, `session.threadBindings.idleHours`, `session.threadBindings.maxAgeHours`
-- Nadpisania kanału i klucze automatycznego wiązania przy spawn są specyficzne dla adaptera. Zobacz **Kanały obsługujące wątki** powyżej.
+- Nadpisanie kanału i klucze automatycznego wiązania przy uruchamianiu są specyficzne dla adaptera. Zobacz **Kanały obsługujące wątki** powyżej.
-Szczegóły bieżących adapterów znajdziesz w [Referencja konfiguracji](/gateway/configuration-reference) i [Polecenia slash](/tools/slash-commands).
+Zobacz [Configuration Reference](/pl/gateway/configuration-reference) i [Slash commands](/pl/tools/slash-commands), aby sprawdzić bieżące szczegóły adapterów.
-Allowlista:
+Lista dozwolonych:
-- `agents.list[].subagents.allowAgents`: lista identyfikatorów agentów, które mogą być celem przez `agentId` (`["*"]`, aby zezwolić na dowolny). Domyślnie: tylko agent żądający.
-- `agents.defaults.subagents.allowAgents`: domyślna allowlista docelowych agentów używana, gdy agent żądający nie ustawia własnego `subagents.allowAgents`.
+- `agents.list[].subagents.allowAgents`: lista identyfikatorów agentów, które mogą być wskazywane przez `agentId` (`["*"]`, aby zezwolić na dowolny). Domyślnie: tylko agent żądający.
+- `agents.defaults.subagents.allowAgents`: domyślna lista dozwolonych agentów docelowych używana, gdy agent żądający nie ustawia własnego `subagents.allowAgents`.
- Ochrona dziedziczenia sandboxa: jeśli sesja żądającego jest sandboxowana, `sessions_spawn` odrzuca cele, które działałyby bez sandboxa.
-- `agents.defaults.subagents.requireAgentId` / `agents.list[].subagents.requireAgentId`: gdy `true`, blokuje wywołania `sessions_spawn`, które pomijają `agentId` (wymusza jawny wybór profilu). Domyślnie: false.
+- `agents.defaults.subagents.requireAgentId` / `agents.list[].subagents.requireAgentId`: gdy ustawione na true, blokuje wywołania `sessions_spawn`, które pomijają `agentId` (wymusza jawny wybór profilu). Domyślnie: false.
-Discovery:
+Odkrywanie:
-- Użyj `agents_list`, aby zobaczyć, które identyfikatory agentów są obecnie dozwolone dla `sessions_spawn`.
+- Użyj `agents_list`, aby sprawdzić, które identyfikatory agentów są obecnie dozwolone dla `sessions_spawn`.
-Autoarchiwizacja:
+Automatyczna archiwizacja:
-- Sesje subagentów są automatycznie archiwizowane po `agents.defaults.subagents.archiveAfterMinutes` (domyślnie: 60).
-- Archiwizacja używa `sessions.delete` i zmienia nazwę transkryptu na `*.deleted.` (ten sam folder).
-- `cleanup: "delete"` archiwizuje natychmiast po announce (transkrypt nadal zostaje zachowany przez zmianę nazwy).
-- Autoarchiwizacja działa best-effort; oczekujące timery są tracone przy restarcie gateway.
-- `runTimeoutSeconds` **nie** powoduje autoarchiwizacji; zatrzymuje tylko przebieg. Sesja pozostaje do autoarchiwizacji.
-- Autoarchiwizacja działa tak samo dla sesji głębokości 1 i głębokości 2.
-- Cleanup przeglądarki jest oddzielony od cleanupu archiwizacji: śledzone karty/procesy przeglądarki są zamykane best-effort po zakończeniu przebiegu, nawet jeśli rekord transkryptu/sesji zostaje zachowany.
+- Sesje podagentów są automatycznie archiwizowane po `agents.defaults.subagents.archiveAfterMinutes` (domyślnie: 60).
+- Archiwizacja używa `sessions.delete` i zmienia nazwę transkryptu na `*.deleted.` (w tym samym folderze).
+- `cleanup: "delete"` archiwizuje natychmiast po ogłoszeniu (transkrypt jest nadal zachowany przez zmianę nazwy).
+- Automatyczna archiwizacja działa w trybie best-effort; oczekujące timery są tracone, jeśli Gateway zostanie ponownie uruchomiony.
+- `runTimeoutSeconds` **nie** powoduje automatycznej archiwizacji; tylko zatrzymuje przebieg. Sesja pozostaje do czasu automatycznej archiwizacji.
+- Automatyczna archiwizacja dotyczy w równym stopniu sesji poziomu 1 i poziomu 2.
+- Czyszczenie przeglądarki jest oddzielne od czyszczenia archiwizacji: śledzone karty/procesy przeglądarki są zamykane w trybie best-effort po zakończeniu przebiegu, nawet jeśli zapis transkryptu/sesji zostaje zachowany.
-## Zagnieżdżeni subagenci
+## Zagnieżdżeni podagenci
-Domyślnie subagenci nie mogą uruchamiać własnych subagentów (`maxSpawnDepth: 1`). Możesz włączyć jeden poziom zagnieżdżenia przez ustawienie `maxSpawnDepth: 2`, co pozwala na **wzorzec orkiestratora**: main → subagent-orkiestrator → workerzy-subsubagenci.
+Domyślnie podagenci nie mogą uruchamiać własnych podagentów (`maxSpawnDepth: 1`). Możesz włączyć jeden poziom zagnieżdżenia, ustawiając `maxSpawnDepth: 2`, co pozwala na **wzorzec orkiestratora**: główny → podagent orkiestrator → pod-podagenci roboczy.
### Jak włączyć
@@ -170,10 +171,10 @@ Domyślnie subagenci nie mogą uruchamiać własnych subagentów (`maxSpawnDepth
agents: {
defaults: {
subagents: {
- maxSpawnDepth: 2, // pozwala subagentom uruchamiać dzieci (domyślnie: 1)
- maxChildrenPerAgent: 5, // maks. aktywnych dzieci na sesję agenta (domyślnie: 5)
- maxConcurrent: 8, // globalny limit współbieżności kolejki (domyślnie: 8)
- runTimeoutSeconds: 900, // domyślny timeout dla sessions_spawn, gdy pominięty (0 = brak timeoutu)
+ maxSpawnDepth: 2, // pozwól podagentom uruchamiać potomków (domyślnie: 1)
+ maxChildrenPerAgent: 5, // maks. liczba aktywnych potomków na sesję agenta (domyślnie: 5)
+ maxConcurrent: 8, // globalny limit współbieżności ścieżki (domyślnie: 8)
+ runTimeoutSeconds: 900, // domyślny limit czasu dla sessions_spawn, gdy pominięto (0 = bez limitu czasu)
},
},
},
@@ -182,123 +183,126 @@ Domyślnie subagenci nie mogą uruchamiać własnych subagentów (`maxSpawnDepth
### Poziomy głębokości
-| Depth | Session key shape | Role | Can spawn? |
-| ----- | -------------------------------------------- | --------------------------------------------- | ---------------------------- |
-| 0 | `agent::main` | Główny agent | Zawsze |
-| 1 | `agent::subagent:` | Subagent (orkiestrator, gdy dozwolona głębokość 2) | Tylko jeśli `maxSpawnDepth >= 2` |
-| 2 | `agent::subagent::subagent:` | Sub-subagent (pracownik-liść) | Nigdy |
+| Głębokość | Kształt klucza sesji | Rola | Może uruchamiać? |
+| --------- | -------------------------------------------- | --------------------------------------------- | ---------------------------- |
+| 0 | `agent::main` | Główny agent | Zawsze |
+| 1 | `agent::subagent:` | Podagent (orkiestrator, gdy dozwolona głębokość 2) | Tylko jeśli `maxSpawnDepth >= 2` |
+| 2 | `agent::subagent::subagent:` | Pod-podagent (liściowy worker) | Nigdy |
-### Łańcuch announce
+### Łańcuch ogłoszeń
-Wyniki przepływają z powrotem w górę łańcucha:
+Wyniki wracają w górę łańcucha:
-1. Worker głębokości 2 kończy → ogłasza do rodzica (orkiestratora głębokości 1)
-2. Orkiestrator głębokości 1 otrzymuje ogłoszenie, syntetyzuje wyniki, kończy → ogłasza do main
+1. Worker głębokości 2 kończy → ogłasza swojemu rodzicowi (orkiestratorowi głębokości 1)
+2. Orkiestrator głębokości 1 otrzymuje ogłoszenie, syntetyzuje wyniki, kończy → ogłasza do głównego
3. Główny agent otrzymuje ogłoszenie i dostarcza je użytkownikowi
-Każdy poziom widzi tylko ogłoszenia swoich bezpośrednich dzieci.
+Każdy poziom widzi tylko ogłoszenia od swoich bezpośrednich potomków.
Wskazówki operacyjne:
-- Uruchamiaj pracę dzieci raz i czekaj na zdarzenia ukończenia zamiast budować pętle odpytywania wokół `sessions_list`, `sessions_history`, `/subagents list` lub poleceń `exec` z `sleep`.
-- Jeśli zdarzenie ukończenia dziecka nadejdzie po tym, jak wysłano już końcową odpowiedź, poprawnym kolejnym działaniem jest dokładny cichy token `NO_REPLY` / `no_reply`.
+- Uruchamiaj pracę potomną jeden raz i czekaj na zdarzenia ukończenia, zamiast budować pętle
+ odpytywania wokół `sessions_list`, `sessions_history`, `/subagents list` lub
+ poleceń `exec` z `sleep`.
+- Jeśli zdarzenie ukończenia potomka nadejdzie po tym, jak wysłano już odpowiedź końcową,
+ poprawną odpowiedzią uzupełniającą jest dokładnie cichy token `NO_REPLY` / `no_reply`.
-### Polityka narzędzi według głębokości
+### Zasady narzędzi według głębokości
-- Rola i zakres sterowania są zapisywane w metadanych sesji w momencie spawn. Zapobiega to przypadkowemu odzyskaniu uprawnień orkiestratora przez płaskie lub przywrócone klucze sesji.
-- **Głębokość 1 (orkiestrator, gdy `maxSpawnDepth >= 2`)**: dostaje `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, aby mógł zarządzać swoimi dziećmi. Inne narzędzia sesji/systemu pozostają zablokowane.
-- **Głębokość 1 (liść, gdy `maxSpawnDepth == 1`)**: brak narzędzi sesji (obecne domyślne zachowanie).
-- **Głębokość 2 (worker-liść)**: brak narzędzi sesji — `sessions_spawn` jest zawsze blokowane na głębokości 2. Nie może uruchamiać dalszych dzieci.
+- Rola i zakres kontroli są zapisywane w metadanych sesji w momencie uruchomienia. Dzięki temu spłaszczone lub przywrócone klucze sesji nie odzyskują przypadkowo uprawnień orkiestratora.
+- **Poziom 1 (orkiestrator, gdy `maxSpawnDepth >= 2`)**: Otrzymuje `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, aby mógł zarządzać swoimi potomkami. Inne narzędzia sesji/systemowe pozostają zablokowane.
+- **Poziom 1 (liść, gdy `maxSpawnDepth == 1`)**: Brak narzędzi sesji (obecne domyślne zachowanie).
+- **Poziom 2 (worker liściowy)**: Brak narzędzi sesji — `sessions_spawn` jest zawsze blokowane na poziomie 2. Nie może uruchamiać kolejnych potomków.
-### Limit spawn per agent
+### Limit uruchomień na agenta
-Każda sesja agenta (na dowolnej głębokości) może mieć maksymalnie `maxChildrenPerAgent` (domyślnie: 5) aktywnych dzieci jednocześnie. Zapobiega to niekontrolowanemu fan-out z pojedynczego orkiestratora.
+Każda sesja agenta (na dowolnym poziomie) może mieć jednocześnie najwyżej `maxChildrenPerAgent` (domyślnie: 5) aktywnych potomków. Zapobiega to niekontrolowanemu rozgałęzianiu z pojedynczego orkiestratora.
-### Cascade stop
+### Kaskadowe zatrzymywanie
-Zatrzymanie orkiestratora głębokości 1 automatycznie zatrzymuje wszystkie jego dzieci głębokości 2:
+Zatrzymanie orkiestratora poziomu 1 automatycznie zatrzymuje wszystkie jego potomki poziomu 2:
-- `/stop` na głównym czacie zatrzymuje wszystkich agentów głębokości 1 i kaskadowo ich dzieci głębokości 2.
-- `/subagents kill ` zatrzymuje konkretnego subagenta i kaskadowo jego dzieci.
-- `/subagents kill all` zatrzymuje wszystkich subagentów dla żądającego i działa kaskadowo.
+- `/stop` na głównym czacie zatrzymuje wszystkich agentów poziomu 1 i kaskadowo ich potomków poziomu 2.
+- `/subagents kill ` zatrzymuje konkretnego podagenta i kaskadowo jego potomków.
+- `/subagents kill all` zatrzymuje wszystkich podagentów dla żądającego i działa kaskadowo.
## Uwierzytelnianie
-Uwierzytelnianie subagenta jest rozwiązywane według **identyfikatora agenta**, a nie według typu sesji:
+Uwierzytelnianie podagenta jest rozwiązywane według **identyfikatora agenta**, a nie typu sesji:
-- Klucz sesji subagenta to `agent::subagent:`.
-- Magazyn auth jest ładowany z `agentDir` tego agenta.
-- Profile auth głównego agenta są scalane jako **fallback**; profile agenta mają pierwszeństwo nad profilami głównego agenta przy konfliktach.
+- Klucz sesji podagenta to `agent::subagent:`.
+- Magazyn uwierzytelniania jest ładowany z `agentDir` tego agenta.
+- Profile uwierzytelniania głównego agenta są scalane jako **fallback**; profile agenta mają pierwszeństwo w przypadku konfliktów.
-Uwaga: scalanie jest addytywne, więc profile głównego agenta są zawsze dostępne jako fallbacki. W pełni izolowane uwierzytelnianie per agent nie jest jeszcze obsługiwane.
+Uwaga: scalanie jest addytywne, więc profile główne są zawsze dostępne jako fallbacki. W pełni izolowane uwierzytelnianie per agent nie jest jeszcze obsługiwane.
-## Announce
+## Ogłoszenie
-Subagenci raportują z powrotem przez krok announce:
+Podagenci raportują z powrotem przez krok ogłoszenia:
-- Krok announce działa wewnątrz sesji subagenta (a nie sesji żądającego).
-- Jeśli subagent odpowie dokładnie `ANNOUNCE_SKIP`, nic nie zostanie opublikowane.
-- Jeśli najnowszy tekst asystenta to dokładny cichy token `NO_REPLY` / `no_reply`,
- output announce jest tłumiony, nawet jeśli wcześniej istniał widoczny postęp.
-- W przeciwnym razie dostarczenie zależy od głębokości żądającego:
- - sesje żądające najwyższego poziomu używają kolejnego wywołania `agent` z zewnętrznym dostarczeniem (`deliver=true`)
- - zagnieżdżone sesje żądające subagentów otrzymują wewnętrzne wstrzyknięcie follow-up (`deliver=false`), aby orkiestrator mógł syntetyzować wyniki dzieci we własnej sesji
- - jeśli zagnieżdżona sesja żądająca subagenta już nie istnieje, OpenClaw wraca awaryjnie do żądającego tej sesji, gdy to możliwe
-- Dla sesji żądających najwyższego poziomu bezpośrednie dostarczenie w trybie completion najpierw rozwiązuje powiązaną trasę konwersacji/wątku i nadpisanie hooka, a następnie uzupełnia brakujące pola channel-target z zapisanej trasy sesji żądającego. Dzięki temu ukończenia trafiają na właściwy czat/temat, nawet gdy źródło ukończenia identyfikuje tylko kanał.
-- Agregacja ukończeń dzieci jest ograniczona do bieżącego przebiegu żądającego przy budowaniu zagnieżdżonych wyników ukończenia, co zapobiega wyciekaniu starych outputów dzieci z poprzednich przebiegów do bieżącego announce.
-- Odpowiedzi announce zachowują routing wątku/tematu, gdy jest dostępny w adapterach kanałów.
-- Kontekst announce jest normalizowany do stabilnego wewnętrznego bloku zdarzenia:
+- Krok ogłoszenia działa wewnątrz sesji podagenta (nie sesji żądającego).
+- Jeśli podagent odpowie dokładnie `ANNOUNCE_SKIP`, nic nie zostanie opublikowane.
+- Jeśli ostatni tekst asystenta to dokładnie cichy token `NO_REPLY` / `no_reply`,
+ dane wyjściowe ogłoszenia są tłumione, nawet jeśli wcześniej istniał widoczny postęp.
+- W przeciwnym razie dostarczenie zależy od poziomu żądającego:
+ - sesje żądającego najwyższego poziomu używają dalszego wywołania `agent` z zewnętrznym dostarczeniem (`deliver=true`)
+ - zagnieżdżone sesje podagentów żądającego otrzymują wewnętrzne wstrzyknięcie dalszego przebiegu (`deliver=false`), aby orkiestrator mógł syntetyzować wyniki potomków w ramach sesji
+ - jeśli zagnieżdżona sesja podagenta żądającego już nie istnieje, OpenClaw wraca do żądającego tej sesji, gdy to możliwe
+- Dla sesji żądającego najwyższego poziomu dostarczenie bezpośrednie w trybie ukończenia najpierw rozwiązuje każdą powiązaną trasę rozmowy/wątku i nadpisanie hooka, a następnie uzupełnia brakujące pola celu kanału z zapisanej trasy sesji żądającego. Dzięki temu ukończenia trafiają na właściwy czat/temat nawet wtedy, gdy źródło ukończenia identyfikuje tylko kanał.
+- Agregacja ukończeń potomków jest ograniczona do bieżącego przebiegu żądającego podczas budowania zagnieżdżonych wyników ukończenia, co zapobiega przedostawaniu się nieaktualnych wyników potomków z poprzednich przebiegów do bieżącego ogłoszenia.
+- Odpowiedzi ogłoszeń zachowują routowanie wątku/tematu, gdy jest dostępne w adapterach kanałów.
+- Kontekst ogłoszenia jest normalizowany do stabilnego wewnętrznego bloku zdarzenia:
- źródło (`subagent` lub `cron`)
- - klucz/id sesji dziecka
- - typ announce + etykieta zadania
- - linia statusu wyprowadzona z wyniku runtime (`success`, `error`, `timeout` lub `unknown`)
- - treść wyniku wybrana z najnowszego widocznego tekstu asystenta, w przeciwnym razie oczyszczonego najnowszego tekstu `tool`/`toolResult`
- - instrukcja follow-up opisująca, kiedy odpowiedzieć, a kiedy pozostać cicho
-- `Status` nie jest wywnioskowywany z outputu modelu; pochodzi z sygnałów wyniku runtime.
-- Przy timeout, jeśli dziecko przeszło tylko przez wywołania narzędzi, announce może zwinąć tę historię do krótkiego podsumowania częściowego postępu zamiast odtwarzać surowy output narzędzi.
+ - klucz/id sesji potomka
+ - typ ogłoszenia + etykieta zadania
+ - wiersz stanu pochodzący z wyniku środowiska wykonawczego (`success`, `error`, `timeout` lub `unknown`)
+ - treść wyniku wybrana z ostatniego widocznego tekstu asystenta, w przeciwnym razie oczyszczony ostatni tekst `tool`/`toolResult`; terminalne nieudane przebiegi raportują stan niepowodzenia bez odtwarzania przechwyconego tekstu odpowiedzi
+ - instrukcję dalszego działania opisującą, kiedy odpowiedzieć, a kiedy pozostać cicho
+- `Status` nie jest wnioskowany z danych wyjściowych modelu; pochodzi z sygnałów wyniku środowiska wykonawczego.
+- Przy przekroczeniu limitu czasu, jeśli potomek zdążył tylko z wywołaniami narzędzi, ogłoszenie może zwinąć tę historię do krótkiego podsumowania częściowego postępu zamiast odtwarzać surowe dane wyjściowe narzędzi.
-Payloady announce zawierają na końcu linię statystyk (nawet gdy są opakowane):
+Ładunki ogłoszeń zawierają na końcu wiersz statystyk (nawet gdy są opakowane):
- Runtime (np. `runtime 5m12s`)
-- Zużycie tokenów (input/output/total)
-- Szacowany koszt, gdy skonfigurowano ceny modeli (`models.providers.*.models[].cost`)
+- Zużycie tokenów (wejście/wyjście/łącznie)
+- Szacowany koszt, gdy skonfigurowano cennik modeli (`models.providers.*.models[].cost`)
- `sessionKey`, `sessionId` i ścieżkę transkryptu (aby główny agent mógł pobrać historię przez `sessions_history` lub sprawdzić plik na dysku)
-- Wewnętrzne metadane są przeznaczone wyłącznie do orkiestracji; odpowiedzi widoczne dla użytkownika powinny zostać przepisane normalnym głosem asystenta.
+- Wewnętrzne metadane są przeznaczone wyłącznie do orkiestracji; odpowiedzi skierowane do użytkownika powinny zostać przepisane zwykłym głosem asystenta.
-` sessions_history` jest bezpieczniejszą ścieżką orkiestracji:
+` sessions_history` to bezpieczniejsza ścieżka orkiestracji:
-- przypominanie asystenta jest najpierw normalizowane:
- - usuwane są tagi thinking
- - usuwane są bloki szkieletowe `` / ``
- - usuwane są bloki payloadów XML wywołań narzędzi w zwykłym tekście, takie jak `...`,
- `...`, `...` i
- `...`, w tym przycięte
- payloady, które nigdy nie zamknęły się poprawnie
- - usuwane są zdegradowane szkielety wywołań/wyników narzędzi i znaczniki kontekstu historycznego
- - usuwane są wyciekłe tokeny sterujące modelem, takie jak `<|assistant|>`, inne tokeny ASCII
- `<|...|>` oraz warianty full-width `<｜...｜>`
- - usuwany jest błędny XML wywołań narzędzi MiniMax
-- tekst przypominający poświadczenia/tokeny jest redagowany
-- długie bloki mogą być przycinane
-- bardzo duże historie mogą usuwać starsze wiersze albo zastępować zbyt duży wiersz
- tekstem `[sessions_history omitted: message too large]`
-- sprawdzanie surowego transkryptu na dysku jest fallbackiem, gdy potrzebujesz pełnego transkryptu byte-for-byte
+- najpierw normalizowane jest odtwarzanie odpowiedzi asystenta:
+ - usuwane są tagi myślenia
+ - usuwane są bloki rusztowania `` / ``
+ - usuwane są bloki ładunków XML wywołań narzędzi w zwykłym tekście, takie jak `...`,
+ `...`, `...` oraz
+ `...`, łącznie z uciętymi
+ ładunkami, które nigdy nie zamykają się poprawnie
+ - usuwane są zdegradowane rusztowania wywołań/wyników narzędzi oraz znaczniki kontekstu historycznego
+ - usuwane są wyciekłe tokeny sterujące modelu, takie jak `<|assistant|>`, inne tokeny ASCII
+ `<|...|>` oraz pełnoszerokie warianty `<｜...｜>`
+ - usuwany jest niepoprawny XML wywołań narzędzi MiniMax
+- tekst podobny do poświadczeń/tokenów jest redagowany
+- długie bloki mogą zostać obcięte
+- bardzo duże historie mogą pomijać starsze wiersze lub zastępować zbyt duży wiersz przez
+ `[sessions_history omitted: message too large]`
+- sprawdzanie surowego transkryptu na dysku jest rozwiązaniem awaryjnym, gdy potrzebujesz pełnego transkryptu bajt po bajcie
-## Polityka narzędzi (narzędzia subagenta)
+## Zasady narzędzi (narzędzia podagentów)
-Domyślnie subagenci dostają **wszystkie narzędzia poza narzędziami sesji** i narzędziami systemowymi:
+Domyślnie podagenci otrzymują **wszystkie narzędzia poza narzędziami sesji** i narzędziami systemowymi:
- `sessions_list`
- `sessions_history`
- `sessions_send`
- `sessions_spawn`
-` sessions_history` pozostaje tutaj również ograniczonym, oczyszczonym widokiem przypominania; nie
-jest surowym zrzutem transkryptu.
+` sessions_history` również tutaj pozostaje ograniczonym, oczyszczonym widokiem odtwarzania; nie jest
+surowym zrzutem transkryptu.
-Gdy `maxSpawnDepth >= 2`, subagenci-orkiestratorzy głębokości 1 otrzymują dodatkowo `sessions_spawn`, `subagents`, `sessions_list` i `sessions_history`, aby mogli zarządzać swoimi dziećmi.
+Gdy `maxSpawnDepth >= 2`, podagenci-orkiestratorzy poziomu 1 dodatkowo otrzymują `sessions_spawn`, `subagents`, `sessions_list` i `sessions_history`, aby mogli zarządzać swoimi potomkami.
-Nadpisanie przez config:
+Nadpisanie przez konfigurację:
```json5
{
@@ -314,7 +318,7 @@ Nadpisanie przez config:
tools: {
// deny ma pierwszeństwo
deny: ["gateway", "cron"],
- // jeśli ustawiono allow, staje się trybem tylko-allow (deny nadal wygrywa)
+ // jeśli ustawiono allow, staje się listą wyłącznie dozwolonych (deny nadal ma pierwszeństwo)
// allow: ["read", "exec", "process"]
},
},
@@ -324,21 +328,21 @@ Nadpisanie przez config:
## Współbieżność
-Subagenci używają dedykowanej kolejki wewnątrz procesu:
+Podagenci używają dedykowanej ścieżki kolejki w procesie:
-- Nazwa kolejki: `subagent`
+- Nazwa ścieżki: `subagent`
- Współbieżność: `agents.defaults.subagents.maxConcurrent` (domyślnie `8`)
## Zatrzymywanie
-- Wysłanie `/stop` na czacie żądającego przerywa sesję żądającego i zatrzymuje wszystkie aktywne przebiegi subagentów uruchomione z niej, działając kaskadowo na zagnieżdżone dzieci.
-- `/subagents kill ` zatrzymuje konkretnego subagenta i działa kaskadowo na jego dzieci.
+- Wysłanie `/stop` na czacie żądającego przerywa sesję żądającego i zatrzymuje wszystkie aktywne przebiegi podagentów uruchomione z niej, kaskadowo także zagnieżdżone potomki.
+- `/subagents kill ` zatrzymuje konkretnego podagenta i kaskadowo jego potomków.
## Ograniczenia
-- Announce subagenta działa **best-effort**. Jeśli gateway zostanie zrestartowany, oczekująca praca „announce back” zostanie utracona.
-- Subagenci nadal współdzielą zasoby tego samego procesu gateway; traktuj `maxConcurrent` jako zawór bezpieczeństwa.
+- Ogłoszenie podagenta działa w trybie **best-effort**. Jeśli Gateway zostanie ponownie uruchomiony, oczekująca praca „ogłoszenia z powrotem” zostanie utracona.
+- Podagenci nadal współdzielą zasoby tego samego procesu Gateway; traktuj `maxConcurrent` jako zawór bezpieczeństwa.
- `sessions_spawn` jest zawsze nieblokujące: natychmiast zwraca `{ status: "accepted", runId, childSessionKey }`.
-- Kontekst subagenta wstrzykuje tylko `AGENTS.md` + `TOOLS.md` (bez `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` ani `BOOTSTRAP.md`).
-- Maksymalna głębokość zagnieżdżenia to 5 (`maxSpawnDepth` w zakresie: 1–5). Dla większości przypadków użycia zalecana jest głębokość 2.
-- `maxChildrenPerAgent` ogranicza liczbę aktywnych dzieci na sesję (domyślnie: 5, zakres: 1–20).
+- Kontekst podagenta wstrzykuje tylko `AGENTS.md` + `TOOLS.md` (bez `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` ani `BOOTSTRAP.md`).
+- Maksymalna głębokość zagnieżdżenia to 5 (zakres `maxSpawnDepth`: 1–5). Poziom 2 jest zalecany dla większości zastosowań.
+- `maxChildrenPerAgent` ogranicza liczbę aktywnych potomków na sesję (domyślnie: 5, zakres: 1–20).
diff --git a/docs/pl/tools/thinking.md b/docs/pl/tools/thinking.md
index 7ec3eb785..5e3e93f2e 100644
--- a/docs/pl/tools/thinking.md
+++ b/docs/pl/tools/thinking.md
@@ -1,131 +1,131 @@
---
read_when:
- - Dostosowywanie analizowania lub wartości domyślnych dyrektyw myślenia, trybu szybkiego lub verbose
-summary: Składnia dyrektyw dla /think, /fast, /verbose, /trace i widoczności rozumowania
+ - Dostosowywanie analizowania dyrektyw myślenia, trybu szybkiego lub trybu szczegółowego albo wartości domyślnych
+summary: Składnia dyrektyw dla `/think`, `/fast`, `/verbose`, `/trace` oraz widoczności rozumowania
title: Poziomy myślenia
x-i18n:
- generated_at: "2026-04-21T10:02:16Z"
+ generated_at: "2026-04-21T19:21:09Z"
model: gpt-5.4
provider: openai
- source_hash: 1b0217f6e5a5cb3400090f31ad5271ca61848a40f77d3f942851e7c2f2352886
+ source_hash: c77f6f1318c428bbd21725ea5f32f8088506a10cbbf5b5cbca5973c72a5a81f9
source_path: tools/thinking.md
workflow: 15
---
-# Poziomy myślenia (/think dyrektywy)
+# Poziomy myślenia (dyrektywy `/think`)
## Co to robi
-- Dyrektywa inline w dowolnej treści przychodzącej: `/t `, `/think:` lub `/thinking `.
+- Dyrektywa w treści dowolnej wiadomości przychodzącej: `/t `, `/think:` lub `/thinking `.
- Poziomy (aliasy): `off | minimal | low | medium | high | xhigh | adaptive | max`
- minimal → „think”
- low → „think hard”
- medium → „think harder”
- high → „ultrathink” (maksymalny budżet)
- - xhigh → „ultrathink+” (GPT-5.2 + modele Codex oraz wysiłek Anthropic Claude Opus 4.7)
- - adaptive → zarządzane przez dostawcę myślenie adaptacyjne (obsługiwane dla Claude 4.6 na Anthropic/Bedrock oraz Anthropic Claude Opus 4.7)
+ - xhigh → „ultrathink+” (wysiłek GPT-5.2 + modeli Codex oraz Anthropic Claude Opus 4.7)
+ - adaptive → zarządzane przez dostawcę myślenie adaptacyjne (obsługiwane dla Claude 4.6 w Anthropic/Bedrock oraz Anthropic Claude Opus 4.7)
- max → maksymalne rozumowanie dostawcy (obecnie Anthropic Claude Opus 4.7)
- - `x-high`, `x_high`, `extra-high`, `extra high` i `extra_high` mapują się do `xhigh`.
- - `highest` mapuje się do `high`.
+ - `x-high`, `x_high`, `extra-high`, `extra high` oraz `extra_high` są mapowane na `xhigh`.
+ - `highest` jest mapowane na `high`.
- Uwagi dotyczące dostawców:
- - Menu i selektory myślenia są sterowane profilami dostawców. Pluginy dostawców deklarują dokładny zestaw poziomów dla wybranego modelu, w tym etykiety takie jak binarne `on`.
- - `adaptive`, `xhigh` i `max` są ogłaszane tylko dla profili dostawcy/modelu, które je obsługują. Wpisane dyrektywy dla nieobsługiwanych poziomów są odrzucane z poprawnymi opcjami dla tego modelu.
- - Istniejące zapisane nieobsługiwane poziomy, w tym stare wartości `max` po przełączeniu modelu, są mapowane ponownie do najwyższego obsługiwanego poziomu dla wybranego modelu.
+ - Menu i selektory myślenia są sterowane przez profile dostawców. Pluginy dostawców deklarują dokładny zestaw poziomów dla wybranego modelu, w tym etykiety takie jak binarne `on`.
+ - `adaptive`, `xhigh` i `max` są reklamowane tylko dla profili dostawcy/modelu, które je obsługują. Wpisane dyrektywy dla nieobsługiwanych poziomów są odrzucane wraz z poprawnymi opcjami dla tego modelu.
+ - Istniejące zapisane nieobsługiwane poziomy są mapowane ponownie według rangi profilu dostawcy. `adaptive` przechodzi awaryjnie na `medium` w modelach nieadaptacyjnych, a `xhigh` i `max` przechodzą awaryjnie na najwyższy obsługiwany poziom inny niż `off` dla wybranego modelu.
- Modele Anthropic Claude 4.6 domyślnie używają `adaptive`, gdy nie ustawiono jawnie poziomu myślenia.
- - Anthropic Claude Opus 4.7 nie domyślnie nie używa myślenia adaptacyjnego. Domyślny wysiłek jego API pozostaje zarządzany przez dostawcę, chyba że jawnie ustawisz poziom myślenia.
- - Anthropic Claude Opus 4.7 mapuje `/think xhigh` na myślenie adaptacyjne plus `output_config.effort: "xhigh"`, ponieważ `/think` jest dyrektywą myślenia, a `xhigh` to ustawienie wysiłku Opus 4.7.
- - Anthropic Claude Opus 4.7 udostępnia także `/think max`; mapuje się ono na tę samą ścieżkę maksymalnego wysiłku zarządzaną przez dostawcę.
- - Modele OpenAI GPT mapują `/think` przez obsługę wysiłku specyficzną dla modelu w Responses API. `/think off` wysyła `reasoning.effort: "none"` tylko wtedy, gdy model docelowy to obsługuje; w przeciwnym razie OpenClaw pomija wyłączony ładunek reasoning zamiast wysyłać nieobsługiwaną wartość.
- - MiniMax (`minimax/*`) na ścieżce strumieniowania zgodnej z Anthropic domyślnie używa `thinking: { type: "disabled" }`, chyba że jawnie ustawisz myślenie w parametrach modelu lub parametrach żądania. Pozwala to uniknąć wyciekających delt `reasoning_content` z nienatywnego formatu strumienia Anthropic MiniMax.
- - Z.AI (`zai/*`) obsługuje tylko binarne myślenie (`on`/`off`). Każdy poziom inny niż `off` jest traktowany jako `on` (mapowany do `low`).
+ - Anthropic Claude Opus 4.7 nie ma domyślnie włączonego myślenia adaptacyjnego. Domyślna wartość wysiłku API pozostaje po stronie dostawcy, dopóki jawnie nie ustawisz poziomu myślenia.
+ - Anthropic Claude Opus 4.7 mapuje `/think xhigh` na myślenie adaptacyjne plus `output_config.effort: "xhigh"`, ponieważ `/think` jest dyrektywą myślenia, a `xhigh` to ustawienie wysiłku w Opus 4.7.
+ - Anthropic Claude Opus 4.7 udostępnia także `/think max`; jest ono mapowane na tę samą ścieżkę maksymalnego wysiłku po stronie dostawcy.
+ - Modele OpenAI GPT mapują `/think` przez specyficzną dla modelu obsługę wysiłku API Responses. `/think off` wysyła `reasoning.effort: "none"` tylko wtedy, gdy model docelowy to obsługuje; w przeciwnym razie OpenClaw pomija ładunek wyłączonego rozumowania zamiast wysyłać nieobsługiwaną wartość.
+ - MiniMax (`minimax/*`) na ścieżce strumieniowania zgodnej z Anthropic domyślnie używa `thinking: { type: "disabled" }`, chyba że jawnie ustawisz myślenie w parametrach modelu lub żądania. Zapobiega to wyciekom delt `reasoning_content` z nienatywnego formatu strumienia Anthropic używanego przez MiniMax.
+ - Z.AI (`zai/*`) obsługuje tylko binarne myślenie (`on`/`off`). Każdy poziom inny niż `off` jest traktowany jako `on` (mapowany na `low`).
- Moonshot (`moonshot/*`) mapuje `/think off` na `thinking: { type: "disabled" }`, a każdy poziom inny niż `off` na `thinking: { type: "enabled" }`. Gdy myślenie jest włączone, Moonshot akceptuje tylko `tool_choice` `auto|none`; OpenClaw normalizuje niezgodne wartości do `auto`.
-## Kolejność rozwiązywania
+## Kolejność rozstrzygania
-1. Dyrektywa inline w wiadomości (dotyczy tylko tej wiadomości).
+1. Dyrektywa w treści wiadomości (dotyczy tylko tej wiadomości).
2. Nadpisanie sesji (ustawiane przez wysłanie wiadomości zawierającej tylko dyrektywę).
-3. Domyślna wartość per agent (`agents.list[].thinkingDefault` w konfiguracji).
+3. Wartość domyślna dla agenta (`agents.list[].thinkingDefault` w konfiguracji).
4. Globalna wartość domyślna (`agents.defaults.thinkingDefault` w konfiguracji).
-5. Zapasowo: wartość domyślna zadeklarowana przez dostawcę, gdy jest dostępna, `low` dla innych modeli katalogowych oznaczonych jako zdolne do rozumowania, w przeciwnym razie `off`.
+5. Zapasowo: domyślna wartość zadeklarowana przez dostawcę, gdy jest dostępna, `low` dla innych modeli katalogowych oznaczonych jako zdolne do rozumowania, w przeciwnym razie `off`.
## Ustawianie domyślnej wartości sesji
-- Wyślij wiadomość, która jest **tylko** dyrektywą (dozwolone są białe znaki), np. `/think:medium` lub `/t high`.
-- To utrzymuje się dla bieżącej sesji (domyślnie per nadawca); jest czyszczone przez `/think:off` lub reset bezczynności sesji.
-- Wysyłana jest odpowiedź potwierdzająca (`Thinking level set to high.` / `Thinking disabled.`). Jeśli poziom jest nieprawidłowy (np. `/thinking big`), polecenie jest odrzucane ze wskazówką, a stan sesji pozostaje bez zmian.
+- Wyślij wiadomość, która zawiera **wyłącznie** dyrektywę (dozwolone są białe znaki), np. `/think:medium` lub `/t high`.
+- To ustawienie utrzymuje się dla bieżącej sesji (domyślnie per nadawca); jest czyszczone przez `/think:off` lub reset bezczynności sesji.
+- Wysyłana jest odpowiedź potwierdzająca (`Thinking level set to high.` / `Thinking disabled.`). Jeśli poziom jest nieprawidłowy (np. `/thinking big`), polecenie zostaje odrzucone z podpowiedzią, a stan sesji pozostaje bez zmian.
- Wyślij `/think` (lub `/think:`) bez argumentu, aby zobaczyć bieżący poziom myślenia.
-## Zastosowanie przez agenta
+## Zastosowanie według agenta
-- **Osadzony Pi**: rozpoznany poziom jest przekazywany do runtime agenta Pi działającego w procesie.
+- **Osadzony Pi**: rozstrzygnięty poziom jest przekazywany do działającego w procesie środowiska uruchomieniowego agenta Pi.
## Tryb szybki (/fast)
- Poziomy: `on|off`.
-- Wiadomość zawierająca tylko dyrektywę przełącza nadpisanie trybu szybkiego dla sesji i odpowiada `Fast mode enabled.` / `Fast mode disabled.`.
+- Wiadomość zawierająca tylko dyrektywę przełącza nadpisanie trybu szybkiego w sesji i zwraca odpowiedź `Fast mode enabled.` / `Fast mode disabled.`.
- Wyślij `/fast` (lub `/fast status`) bez trybu, aby zobaczyć bieżący efektywny stan trybu szybkiego.
-- OpenClaw rozwiązuje tryb szybki w tej kolejności:
- 1. Inline/tylko-dyrektywa `/fast on|off`
+- OpenClaw rozstrzyga tryb szybki w następującej kolejności:
+ 1. Dyrektywa w treści/wiadomość zawierająca tylko dyrektywę `/fast on|off`
2. Nadpisanie sesji
- 3. Domyślna wartość per agent (`agents.list[].fastModeDefault`)
+ 3. Wartość domyślna dla agenta (`agents.list[].fastModeDefault`)
4. Konfiguracja per model: `agents.defaults.models["/"].params.fastMode`
5. Zapasowo: `off`
-- Dla `openai/*` tryb szybki mapuje się na przetwarzanie priorytetowe OpenAI przez wysyłanie `service_tier=priority` w obsługiwanych żądaniach Responses.
-- Dla `openai-codex/*` tryb szybki wysyła tę samą flagę `service_tier=priority` w Codex Responses. OpenClaw utrzymuje jeden wspólny przełącznik `/fast` dla obu ścieżek uwierzytelniania.
-- Dla bezpośrednich publicznych żądań `anthropic/*`, w tym ruchu uwierzytelnianego OAuth wysyłanego do `api.anthropic.com`, tryb szybki mapuje się na warstwy usług Anthropic: `/fast on` ustawia `service_tier=auto`, `/fast off` ustawia `service_tier=standard_only`.
-- Dla `minimax/*` na ścieżce zgodnej z Anthropic `/fast on` (lub `params.fastMode: true`) przepisuje `MiniMax-M2.7` na `MiniMax-M2.7-highspeed`.
-- Jawne parametry modelu Anthropic `serviceTier` / `service_tier` mają pierwszeństwo przed domyślnym trybem szybkim, gdy ustawione są oba. OpenClaw nadal pomija wstrzykiwanie warstwy usług Anthropic dla bazowych URL proxy innych niż Anthropic.
+- Dla `openai/*` tryb szybki jest mapowany na przetwarzanie priorytetowe OpenAI przez wysłanie `service_tier=priority` w obsługiwanych żądaniach Responses.
+- Dla `openai-codex/*` tryb szybki wysyła tę samą flagę `service_tier=priority` w Codex Responses. OpenClaw utrzymuje jeden wspólny przełącznik `/fast` dla obu ścieżek auth.
+- Dla bezpośrednich publicznych żądań `anthropic/*`, w tym ruchu uwierzytelnionego przez OAuth wysyłanego do `api.anthropic.com`, tryb szybki jest mapowany na poziomy usług Anthropic: `/fast on` ustawia `service_tier=auto`, a `/fast off` ustawia `service_tier=standard_only`.
+- Dla `minimax/*` na ścieżce zgodnej z Anthropic, `/fast on` (lub `params.fastMode: true`) przepisuje `MiniMax-M2.7` na `MiniMax-M2.7-highspeed`.
+- Jawne parametry modelu Anthropic `serviceTier` / `service_tier` zastępują domyślne ustawienie trybu szybkiego, gdy ustawione są oba. OpenClaw nadal pomija wstrzykiwanie poziomu usługi Anthropic dla bazowych adresów URL proxy innych niż Anthropic.
-## Dyrektywy verbose (/verbose lub /v)
+## Dyrektywy szczegółowości (/verbose lub /v)
- Poziomy: `on` (minimalny) | `full` | `off` (domyślnie).
-- Wiadomość zawierająca tylko dyrektywę przełącza verbose sesji i odpowiada `Verbose logging enabled.` / `Verbose logging disabled.`; nieprawidłowe poziomy zwracają wskazówkę bez zmiany stanu.
-- `/verbose off` zapisuje jawne nadpisanie sesji; wyczyść je przez Sessions UI, wybierając `inherit`.
-- Dyrektywa inline wpływa tylko na tę wiadomość; w pozostałych przypadkach stosowane są domyślne wartości sesji/globalne.
-- Wyślij `/verbose` (lub `/verbose:`) bez argumentu, aby zobaczyć bieżący poziom verbose.
-- Gdy verbose jest włączone, agenci emitujący uporządkowane wyniki narzędzi (Pi, inni agenci JSON) odsyłają każde wywołanie narzędzia jako osobną wiadomość tylko z metadanymi, z prefiksem ` : `, jeśli jest dostępny (ścieżka/polecenie). Te podsumowania narzędzi są wysyłane od razu po starcie każdego narzędzia (osobne bąbelki), a nie jako delty strumieniowania.
-- Podsumowania błędów narzędzi pozostają widoczne w trybie normalnym, ale surowe sufiksy szczegółów błędu są ukryte, chyba że verbose ma wartość `on` lub `full`.
-- Gdy verbose ma wartość `full`, wyjścia narzędzi są także przekazywane po zakończeniu (osobny bąbelek, obcięty do bezpiecznej długości). Jeśli przełączysz `/verbose on|full|off` w trakcie uruchomienia, kolejne bąbelki narzędzi uwzględnią nowe ustawienie.
+- Wiadomość zawierająca tylko dyrektywę przełącza szczegółowość sesji i zwraca odpowiedź `Verbose logging enabled.` / `Verbose logging disabled.`; nieprawidłowe poziomy zwracają podpowiedź bez zmiany stanu.
+- `/verbose off` zapisuje jawne nadpisanie sesji; wyczyść je w interfejsie Sessions, wybierając `inherit`.
+- Dyrektywa w treści dotyczy tylko tej wiadomości; w pozostałych przypadkach stosowane są wartości domyślne sesji/globalne.
+- Wyślij `/verbose` (lub `/verbose:`) bez argumentu, aby zobaczyć bieżący poziom szczegółowości.
+- Gdy szczegółowość jest włączona, agenci emitujący uporządkowane wyniki narzędzi (Pi, inne agenty JSON) odsyłają każde wywołanie narzędzia jako osobną wiadomość zawierającą tylko metadane, poprzedzoną ` : `, gdy to możliwe (ścieżka/polecenie). Te podsumowania narzędzi są wysyłane natychmiast po rozpoczęciu każdego narzędzia (osobne dymki), a nie jako delty strumieniowe.
+- Podsumowania błędów narzędzi pozostają widoczne w trybie normalnym, ale surowe sufiksy szczegółów błędu są ukryte, chyba że szczegółowość ma wartość `on` lub `full`.
+- Gdy szczegółowość ma wartość `full`, wyniki narzędzi są także przekazywane po zakończeniu (osobny dymek, obcięty do bezpiecznej długości). Jeśli przełączysz `/verbose on|full|off`, gdy uruchomienie jest w toku, kolejne dymki narzędzi uwzględnią nowe ustawienie.
-## Dyrektywy śledzenia pluginów (/trace)
+## Dyrektywy śledzenia Pluginów (/trace)
- Poziomy: `on` | `off` (domyślnie).
-- Wiadomość zawierająca tylko dyrektywę przełącza wyjście śledzenia pluginów dla sesji i odpowiada `Plugin trace enabled.` / `Plugin trace disabled.`.
-- Dyrektywa inline wpływa tylko na tę wiadomość; w pozostałych przypadkach stosowane są domyślne wartości sesji/globalne.
+- Wiadomość zawierająca tylko dyrektywę przełącza wyjście śledzenia pluginów w sesji i zwraca odpowiedź `Plugin trace enabled.` / `Plugin trace disabled.`.
+- Dyrektywa w treści dotyczy tylko tej wiadomości; w pozostałych przypadkach stosowane są wartości domyślne sesji/globalne.
- Wyślij `/trace` (lub `/trace:`) bez argumentu, aby zobaczyć bieżący poziom śledzenia.
-- `/trace` jest węższe niż `/verbose`: ujawnia tylko linie śledzenia/debug należące do pluginu, takie jak podsumowania debugowania Active Memory.
-- Linie śledzenia mogą pojawiać się w `/status` oraz jako dodatkowa wiadomość diagnostyczna po normalnej odpowiedzi asystenta.
+- `/trace` jest węższe niż `/verbose`: ujawnia tylko linie śledzenia/debugowania należące do pluginów, takie jak podsumowania debugowania Active Memory.
+- Linie śledzenia mogą pojawiać się w `/status` oraz jako następcza wiadomość diagnostyczna po zwykłej odpowiedzi asystenta.
## Widoczność rozumowania (/reasoning)
- Poziomy: `on|off|stream`.
- Wiadomość zawierająca tylko dyrektywę przełącza, czy bloki myślenia są pokazywane w odpowiedziach.
-- Gdy jest włączone, rozumowanie jest wysyłane jako **osobna wiadomość** z prefiksem `Reasoning:`.
-- `stream` (tylko Telegram): strumieniuje rozumowanie do bąbelka wersji roboczej Telegram podczas generowania odpowiedzi, a następnie wysyła końcową odpowiedź bez rozumowania.
+- Gdy jest włączona, rozumowanie jest wysyłane jako **osobna wiadomość** poprzedzona prefiksem `Reasoning:`.
+- `stream` (tylko Telegram): strumieniuje rozumowanie do roboczego dymka Telegram podczas generowania odpowiedzi, a następnie wysyła końcową odpowiedź bez rozumowania.
- Alias: `/reason`.
- Wyślij `/reasoning` (lub `/reasoning:`) bez argumentu, aby zobaczyć bieżący poziom rozumowania.
-- Kolejność rozwiązywania: dyrektywa inline, potem nadpisanie sesji, potem domyślna wartość per agent (`agents.list[].reasoningDefault`), a następnie wartość zapasowa (`off`).
+- Kolejność rozstrzygania: dyrektywa w treści, potem nadpisanie sesji, potem wartość domyślna dla agenta (`agents.list[].reasoningDefault`), a potem wartość zapasowa (`off`).
## Powiązane
-- Dokumentacja trybu podwyższonego znajduje się w [Tryb podwyższony](/pl/tools/elevated).
+- Dokumentacja trybu podwyższonego znajduje się w [Elevated mode](/pl/tools/elevated).
-## Heartbeats
+## Heartbeat
-- Treść sondy Heartbeat to skonfigurowany prompt Heartbeat (domyślnie: `Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`). Dyrektywy inline w wiadomości Heartbeat są stosowane normalnie (ale unikaj zmiany domyślnych wartości sesji z Heartbeatów).
-- Dostarczanie Heartbeat domyślnie obejmuje tylko końcowy ładunek. Aby wysyłać także osobną wiadomość `Reasoning:` (gdy jest dostępna), ustaw `agents.defaults.heartbeat.includeReasoning: true` lub per agent `agents.list[].heartbeat.includeReasoning: true`.
+- Treść próby Heartbeat to skonfigurowany prompt heartbeat (domyślnie: `Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`). Dyrektywy w treści wiadomości heartbeat są stosowane jak zwykle (ale unikaj zmiany ustawień domyślnych sesji przez heartbeat).
+- Dostarczanie Heartbeat domyślnie obejmuje tylko końcowy ładunek. Aby wysyłać również osobną wiadomość `Reasoning:` (gdy jest dostępna), ustaw `agents.defaults.heartbeat.includeReasoning: true` lub per agent `agents.list[].heartbeat.includeReasoning: true`.
-## Web chat UI
+## Interfejs czatu webowego
-- Selektor myślenia w web chat odzwierciedla zapisany poziom sesji z magazynu/configu sesji wejściowej podczas ładowania strony.
-- Wybranie innego poziomu natychmiast zapisuje nadpisanie sesji przez `sessions.patch`; nie czeka na następne wysłanie i nie jest jednorazowym nadpisaniem `thinkingOnce`.
-- Pierwsza opcja to zawsze `Default ()`, gdzie rozpoznana wartość domyślna pochodzi z profilu myślenia dostawcy aktywnego modelu sesji.
-- Selektor używa `thinkingOptions` zwracanych przez wiersz sesji Gateway. Interfejs przeglądarkowy nie utrzymuje własnej listy regex dostawców; pluginy zarządzają zestawami poziomów specyficznymi dla modelu.
+- Selektor myślenia w webowym interfejsie czatu odzwierciedla poziom zapisany dla sesji z magazynu sesji przychodzących/konfiguracji podczas ładowania strony.
+- Wybranie innego poziomu zapisuje nadpisanie sesji natychmiast przez `sessions.patch`; nie czeka na następne wysłanie i nie jest jednorazowym nadpisaniem `thinkingOnce`.
+- Pierwsza opcja to zawsze `Default ()`, gdzie rozstrzygnięta wartość domyślna pochodzi z profilu myślenia dostawcy dla aktywnego modelu sesji.
+- Selektor używa `thinkingOptions` zwracanego przez wiersz sesji Gateway. Interfejs przeglądarkowy nie utrzymuje własnej listy regexów dostawców; pluginy są właścicielami specyficznych dla modelu zestawów poziomów.
- `/think:` nadal działa i aktualizuje ten sam zapisany poziom sesji, więc dyrektywy czatu i selektor pozostają zsynchronizowane.
## Profile dostawców
-- Pluginy dostawców mogą udostępniać `resolveThinkingProfile(ctx)`, aby definiować obsługiwane poziomy modelu i wartość domyślną.
+- Pluginy dostawców mogą udostępniać `resolveThinkingProfile(ctx)`, aby zdefiniować obsługiwane poziomy i wartość domyślną modelu.
- Każdy poziom profilu ma zapisany kanoniczny `id` (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `adaptive` lub `max`) i może zawierać wyświetlaną `label`. Dostawcy binarni używają `{ id: "low", label: "on" }`.
-- Opublikowane starsze hooki (`supportsXHighThinking`, `isBinaryThinking` i `resolveDefaultThinkingLevel`) pozostają jako adaptery zgodności, ale nowe niestandardowe zestawy poziomów powinny używać `resolveThinkingProfile`.
-- Wiersze Gateway udostępniają `thinkingOptions` i `thinkingDefault`, aby klienci ACP/chat renderowali ten sam profil, którego używa walidacja runtime.
+- Opublikowane starsze hooki (`supportsXHighThinking`, `isBinaryThinking` oraz `resolveDefaultThinkingLevel`) pozostają adapterami zgodności, ale nowe niestandardowe zestawy poziomów powinny używać `resolveThinkingProfile`.
+- Wiersze Gateway udostępniają `thinkingOptions` i `thinkingDefault`, aby klienci ACP/czatu renderowali ten sam profil, którego używa walidacja w środowisku uruchomieniowym.