openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(i18n): refresh pl translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-04-23 14:59:32 +00:00
parent cf0de77e79
commit 93aa12d496
4 changed files with 749 additions and 713 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

117
docs/pl/ci.md
View File

@ -1,100 +1,107 @@
---
read_when:
- Musisz zrozumieć, dlaczego zadanie CI uruchomiło się lub nie uruchomiło.
- Debugujesz nieudane kontrole GitHub Actions.
- Diagnozujesz nieudane kontrole GitHub Actions.
summary: Graf zadań CI, bramki zakresu i lokalne odpowiedniki poleceń
title: Potok CI
x-i18n:
generated_at: "2026-04-23T13:58:11Z"
generated_at: "2026-04-23T14:55:04Z"
model: gpt-5.4
provider: openai
source_hash: c5a8ea0d8e428826169b0e6aced1caeb993106fe79904002125ace86b48cae1f
source_hash: e9a03440ae28a15167fc08d9c66bb1fd719ddfa1517aaecb119c80f2ad826c0d
source_path: ci.md
workflow: 15
---
# Potok CI
CI uruchamia się przy każdym pushu do `main` oraz dla każdego pull requesta. Wykorzystuje inteligentne zawężanie zakresu, aby pomijać kosztowne zadania, gdy zmieniły się tylko niepowiązane obszary.
CI uruchamia się przy każdym wypchnięciu do `main` i przy każdym pull requeście. Używa inteligentnego zawężania zakresu, aby pomijać kosztowne zadania, gdy zmieniły się tylko niepowiązane obszary.
QA Lab ma dedykowane ścieżki CI poza głównym workflow z inteligentnym zawężaniem zakresu. Workflow `Parity gate` uruchamia się dla pasujących zmian w PR oraz ręcznie; buduje prywatne środowisko uruchomieniowe QA i porównuje agentowe pakiety mock GPT-5.4 oraz Opus 4.6. Workflow `QA-Lab - All Lanes` uruchamia się co noc na `main` oraz ręcznie; rozdziela równolegle zadania mock parity gate, żywą ścieżkę Matrix i żywą ścieżkę Telegram. Zadania live używają środowiska `qa-live-shared`, a ścieżka Telegram używa dzierżaw Convex. `OpenClaw Release Checks` uruchamia również te same ścieżki QA Lab przed zatwierdzeniem wydania.
QA Lab ma dedykowane ścieżki CI poza głównym workflow z inteligentnym zawężaniem zakresu. Workflow
`Parity gate` uruchamia się przy pasujących zmianach w PR oraz ręcznie; buduje
prywatne środowisko uruchomieniowe QA i porównuje agentowe pakiety mock GPT-5.4 i Opus 4.6. Workflow `QA-Lab - All Lanes` uruchamia się nocą na `main` oraz
ręcznie; rozdziela równolegle mock parity gate, aktywną ścieżkę Matrix i aktywną
ścieżkę Telegram. Zadania aktywne używają środowiska `qa-live-shared`,
a ścieżka Telegram używa dzierżaw Convex. `OpenClaw Release
Checks` uruchamia również te same ścieżki QA Lab przed zatwierdzeniem wydania.
## Przegląd zadań
| Zadanie | Cel | Kiedy się uruchamia |
| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- |
| `preflight` | Wykrywa zmiany tylko w dokumentacji, zmienione zakresy, zmienione rozszerzenia i buduje manifest CI | Zawsze dla pushy i PR, które nie są szkicami |
| `security-scm-fast` | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor` | Zawsze dla pushy i PR, które nie są szkicami |
| `security-dependency-audit` | Audyt produkcyjnego lockfile bez zależności względem ostrzeżeń npm | Zawsze dla pushy i PR, które nie są szkicami |
| `security-fast` | Wymagany agregat dla szybkich zadań bezpieczeństwa | Zawsze dla pushy i PR, które nie są szkicami |
| `build-artifacts` | Buduje `dist/`, Control UI, sprawdzenia zbudowanych artefaktów i współdzielone artefakty podrzędne | Zmiany istotne dla Node |
| `checks-fast-core` | Szybkie ścieżki poprawności na Linuxie, 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 pluginów w całym zestawie rozszerzeń | Zmiany istotne dla Node |
| `checks-node-core-test` | Szardy testów rdzenia 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 pluginów | Pull requesty ze zmianami w rozszerzeniach |
| `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 zużycia pamięci przy starcie | Zmiany istotne dla Node |
| `checks` | Weryfikator dla testów kanałów opartych na zbudowanych artefaktach oraz zgodności z Node 22 tylko dla pushy | Zmiany istotne dla Node |
| `check-docs` | Formatowanie dokumentacji, lint i sprawdzanie uszkodzonych linków | Zmieniona dokumentacja |
| `skills-python` | Ruff + pytest dla Skills opartych na Pythonie | Zmiany istotne dla Python Skills |
| `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` | Testy jednostkowe Androida dla obu wariantów oraz jeden build debug APK | Zmiany istotne dla Androida |
| Zadanie | Cel | Kiedy się uruchamia |
| -------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------- |
| `preflight` | Wykrywa zmiany tylko w dokumentacji, zmienione zakresy, zmienione rozszerzenia i buduje manifest CI | Zawsze przy niedraftowych pushach i PR |
| `security-scm-fast` | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor` | Zawsze przy niedraftowych pushach i PR |
| `security-dependency-audit` | Niezależny od zależności audyt produkcyjnego lockfile względem ostrzeżeń npm | Zawsze przy niedraftowych pushach i PR |
| `security-fast` | Wymagany agregat dla szybkich zadań bezpieczeństwa | Zawsze przy niedraftowych pushach i PR |
| `build-artifacts` | Buduje `dist/`, Control UI, kontrole zbudowanych artefaktów i artefakty wielokrotnego użytku dla zadań podrzędnych | Zmiany istotne dla Node |
| `checks-fast-core` | Szybkie linuksowe ścieżki poprawności, takie jak kontrole bundled/plugin-contract/protocol | Zmiany istotne dla Node |
| `checks-fast-contracts-channels` | Szardowane kontrole kontraktów kanałów ze stabilnym zagregowanym wynikiem kontroli | Zmiany istotne dla Node |
| `checks-node-extensions` | Pełne szardy testów bundled-plugin w całym zestawie rozszerzeń | Zmiany istotne dla Node |
| `checks-node-core-test` | Szardy testów rdzenia Node, z wyłączeniem kanałów, bundled, kontraktów i ścieżek rozszerzeń | Zmiany istotne dla Node |
| `extension-fast` | Ukierunkowane testy tylko dla zmienionych bundled plugins | Pull requesty ze zmianami w rozszerzeniach |
| `check` | Szardowany odpowiednik głównej lokalnej bramki: typy prod, lint, guardy, typy testowe i ścisły smoke | Zmiany istotne dla Node |
| `check-additional` | Architektura, granice, guardy powierzchni rozszerzeń, granice pakietów i szardy gateway-watch | Zmiany istotne dla Node |
| `build-smoke` | Smoke testy zbudowanego CLI i smoke pamięci przy uruchamianiu | Zmiany istotne dla Node |
| `checks` | Weryfikator dla testów kanałów na zbudowanych artefaktach oraz zgodności tylko dla pushy z Node 22 | Zmiany istotne dla Node |
| `check-docs` | Formatowanie dokumentacji, lint i kontrole niedziałających linków | Zmieniona dokumentacja |
| `skills-python` | Ruff + pytest dla Skills opartych na Pythonie | Zmiany istotne dla Python Skills |
| `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` | Testy jednostkowe Androida dla obu wariantów oraz jeden build debug APK | Zmiany istotne dla Androida |
## Kolejność Fail-Fast
## Kolejność fail-fast
Zadania są uporządkowane tak, aby tanie sprawdzenia kończyły się niepowodzeniem przed uruchomieniem drogich zadań:
Zadania są uporządkowane tak, aby tanie kontrole kończyły się niepowodzeniem przed uruchomieniem droższych:
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` kończą się szybko bez czekania na cięższe zadania artefaktów i macierzy platform.
3. `build-artifacts` nakłada się na szybkie ścieżki Linux, aby odbiorcy podrzędni mogli zacząć, gdy tylko współdzielony build będzie gotowy.
4. Cięższe ścieżki platformowe i uruchomieniowe rozgałęziają się potem: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, tylko-PR `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` i `android`.
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` i `skills-python` szybko kończą się niepowodzeniem bez czekania na cięższe zadania artefaktów i macierzy platform.
3. `build-artifacts` działa równolegle z szybkimi linuksowymi ścieżkami, aby zadania podrzędne mogły ruszyć, gdy tylko współdzielony build będzie gotowy.
4. Cięższe ścieżki platformowe i runtime rozdzielają się później: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, tylko-PR `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`.
Edycje workflow CI walidują graf Node CI oraz linting workflow, ale same nie wymuszają natywnych buildów Windows, Androida ani macOS; te ścieżki platformowe nadal są zawężane do zmian w kodzie danej platformy.
Sprawdzenia Windows Node są zawężane do wrapperów procesów/ścieżek specyficznych dla Windows, helperów uruchomieniowych npm/pnpm/UI, konfiguracji menedżera pakietów oraz powierzchni workflow CI, które uruchamiają tę ścieżkę; niepowiązane zmiany w kodzie źródłowym, pluginach, install-smoke oraz zmiany tylko w testach pozostają na ścieżkach Linux Node, aby nie rezerwować 16-vCPU workera Windows dla pokrycia, które i tak zapewniają normalne szardy testów.
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 Docker/install uruchamia się dla zmian związanych z instalacją, pakowaniem, kontenerami, produkcyjnymi zmianami bundled extension oraz powierzchniami rdzenia plugin/channel/gateway/Plugin SDK, które wykorzystują zadania Docker smoke. Edycje tylko testów i tylko dokumentacji nie rezerwują workerów Dockera. Jego smoke dla pakietu QR wymusza ponowne uruchomienie warstwy Docker `pnpm install`, zachowując jednocześnie cache BuildKit pnpm store, więc nadal testuje instalację bez ponownego pobierania zależności przy każdym uruchomieniu. Jego gateway-network e2e ponownie używa obrazu runtime zbudowanego wcześniej w zadaniu, więc dodaje rzeczywiste pokrycie WebSocket między kontenerami bez dokładania kolejnego buildu Dockera. Lokalnie `test:docker:all` wstępnie buduje jeden współdzielony obraz live-test i jeden współdzielony obraz built-app z `scripts/e2e/Dockerfile`, a następnie uruchamia równolegle ścieżki smoke live/E2E z `OPENCLAW_SKIP_DOCKER_BUILD=1`; domyślną współbieżność 4 można dostroić przez `OPENCLAW_DOCKER_ALL_PARALLELISM`. Lokalny agregat domyślnie przestaje planować nowe ścieżki z puli po pierwszym błędzie, a każda ścieżka ma limit czasu 120 minut, który można nadpisać przez `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Ścieżki wrażliwe na start lub providera uruchamiają się wyłącznie po puli równoległej. Workflow wielokrotnego użytku live/E2E odzwierciedla wzorzec współdzielonego obrazu, budując i wypychając jeden obraz Docker E2E z tagiem SHA do GHCR przed macierzą Dockera, a następnie uruchamiając macierz z `OPENCLAW_SKIP_DOCKER_BUILD=1`. Zaplanowany workflow live/E2E uruchamia codziennie pełny zestaw Dockera dla ścieżki wydaniowej. Testy Docker dla QR i instalatora zachowują własne Dockerfile skoncentrowane na instalacji. Osobne zadanie `docker-e2e-fast` uruchamia ograniczony profil bundled pluginów w Dockerze z limitem czasu polecenia 120 sekund: naprawa zależności setup-entry oraz izolacja syntetycznych awarii bundled-loader. Pełna macierz aktualizacji bundled i kanałów pozostaje ręczna/pełny zestaw, ponieważ wykonuje powtarzane rzeczywiste przebiegi npm update i napraw przez doctor.
Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest objęta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`.
Edycje workflow CI weryfikują graf Node CI oraz lint workflow, ale same w sobie nie wymuszają natywnych buildów Windows, Android ani macOS; te ścieżki platformowe nadal są zawężone do zmian w kodzie danej platformy.
Kontrole Node dla Windows są zawężone do wrapperów procesów/ścieżek specyficznych dla Windows, helperów uruchamiania npm/pnpm/UI, konfiguracji menedżera pakietów i powierzchni workflow CI, które uruchamiają tę ścieżkę; niepowiązane zmiany w kodzie źródłowym, plugin, install-smoke i samych testach pozostają w linuksowych ścieżkach Node, aby nie rezerwować 16-vCPU workera Windows dla pokrycia, które jest już wykonywane przez zwykłe szardy testowe.
Osobny workflow `install-smoke` używa ponownie tego samego skryptu zakresu przez własne zadanie `preflight`. Wylicza `run_install_smoke` z węższego sygnału changed-smoke, więc smoke Docker/install uruchamia się dla zmian związanych z instalacją, pakowaniem, kontenerami, zmian produkcyjnych bundled extension oraz głównych powierzchni plugin/channel/gateway/Plugin SDK, które wykonują zadania smoke Dockera. Edycje tylko testów i tylko dokumentacji nie rezerwują workerów Docker. Jego smoke pakietu QR wymusza ponowne uruchomienie warstwy Docker `pnpm install`, zachowując cache magazynu pnpm BuildKit, więc nadal wykonuje instalację bez ponownego pobierania zależności przy każdym uruchomieniu. Jego gateway-network e2e ponownie używa obrazu runtime zbudowanego wcześniej w zadaniu, więc dodaje rzeczywiste pokrycie WebSocket między kontenerami bez dodawania kolejnego builda Docker. Lokalne `test:docker:all` buduje wcześniej jeden współdzielony obraz live-test i jeden współdzielony obraz built-app z `scripts/e2e/Dockerfile`, a następnie uruchamia równolegle ścieżki smoke live/E2E z `OPENCLAW_SKIP_DOCKER_BUILD=1`; domyślną współbieżność 4 można dostroić przez `OPENCLAW_DOCKER_ALL_PARALLELISM`. Lokalny agregat domyślnie przestaje planować nowe ścieżki z puli po pierwszym niepowodzeniu, a każda ścieżka ma limit czasu 120 minut, który można nadpisać przez `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Ścieżki wrażliwe na uruchamianie lub dostawców działają wyłącznie po zakończeniu puli równoległej. Workflow live/E2E wielokrotnego użytku odwzorowuje wzorzec współdzielonego obrazu, budując i wypychając jeden obraz Docker E2E GHCR oznaczony SHA przed macierzą Docker, a następnie uruchamiając macierz z `OPENCLAW_SKIP_DOCKER_BUILD=1`. Zaplanowany workflow live/E2E uruchamia codziennie pełny zestaw Docker dla ścieżki wydaniowej. Testy Docker QR i instalatora zachowują własne Dockerfile skoncentrowane na instalacji. Osobne zadanie `docker-e2e-fast` uruchamia ograniczony profil Docker bundled-plugin z limitem czasu polecenia 120 sekund: naprawa zależności setup-entry oraz izolacja syntetycznej awarii bundled-loader. Pełna macierz aktualizacji bundled i kanałów pozostaje ręczna/pełnego zestawu, ponieważ wykonuje powtarzane rzeczywiste przebiegi npm update i naprawy doctor.
Lokalna logika zmienionych ścieżek 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: produkcyjne zmiany w rdzeniu uruchamiają typecheck prod rdzenia oraz testy rdzenia, zmiany tylko w testach rdzenia uruchamiają tylko typecheck/testy testowe rdzenia, produkcyjne zmiany rozszerzeń uruchamiają typecheck prod rozszerzeń oraz testy rozszerzeń, a zmiany tylko w testach rozszerzeń uruchamiają tylko typecheck/testy testowe rozszerzeń. Publiczne zmiany Plugin SDK lub plugin-contract rozszerzają walidację na rozszerzenia, ponieważ rozszerzenia zależą od tych kontraktów rdzenia. Podbicia wersji ograniczone wyłącznie do metadanych wydania uruchamiają ukierunkowane sprawdzenia wersji/konfiguracji/zależności głównych. Nieznane zmiany w root/config w trybie bezpiecznym uruchamiają wszystkie ścieżki.
Lokalna logika zmienionych ścieżek znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka jest bardziej rygorystyczna wobec granic architektury niż szeroki zakres platform CI: zmiany produkcyjne rdzenia uruchamiają typecheck prod rdzenia oraz testy rdzenia, zmiany tylko w testach rdzenia uruchamiają tylko typecheck/testy testowe rdzenia, zmiany produkcyjne rozszerzeń uruchamiają typecheck prod rozszerzeń oraz 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 rdzenia. Zmiany wyłącznie w metadanych wydania, takie jak podbicie wersji, uruchamiają ukierunkowane kontrole wersji/konfiguracji/zależności głównych. Nieznane zmiany w root/config w trybie bezpiecznym uruchamiają wszystkie ścieżki.
Przy pushach macierz `checks` dodaje ścieżkę `compat-node22` tylko dla pushy. Dla pull requestów ta ścieżka jest pomijana, a macierz pozostaje skupiona na zwykłych ścieżkach testów/kanałów.
Przy pushach macierz `checks` dodaje ścieżkę `compat-node22`, uruchamianą tylko przy pushach. Przy 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 lub równoważone tak, aby każde zadanie pozostawało małe: kontrakty kanałów dzielą pokrycie rejestru i rdzenia na łącznie sześć ważonych szardów, testy bundled pluginów są równoważone na sześciu workerach rozszerzeń, auto-reply działa jako trzech zrównoważonych workerów zamiast sześciu małych workerów, a agentowe konfiguracje gateway/plugin są rozkładane na istniejące zadania agentic Node tylko ze źródeł zamiast czekać na zbudowane artefakty. Szerokie testy przeglądarki, QA, mediów i różnych pluginów używają swoich dedykowanych konfiguracji Vitest zamiast współdzielonej ogólnej konfiguracji pluginów. Szeroka ścieżka agents używa współdzielonego planisty równoległości plików Vitest, ponieważ dominuje w niej import/schedulowanie, a nie pojedynczy wolny plik testowy. `runtime-config` działa z szardem infra core-runtime, aby współdzielony szard runtime nie był właścicielem końcowego ogona. `check-additional` utrzymuje razem prace compile/canary dla granic pakietów i oddziela architekturę topologii runtime od pokrycia gateway watch; szard boundary guard uruchamia swoje małe niezależne guardy współbieżnie w ramach jednego zadania. Gateway watch, testy kanałów i szard granicy wsparcia rdzenia uruchamiają się współbieżnie w `build-artifacts` po zbudowaniu `dist/` i `dist-runtime/`, zachowując swoje stare nazwy sprawdzeń jako lekkie zadania weryfikujące, a jednocześnie unikając dwóch dodatkowych workerów Blacksmith i drugiej kolejki odbiorców artefaktów.
Android CI uruchamia zarówno `testPlayDebugUnitTest`, jak i `testThirdPartyDebugUnitTest`, a następnie buduje debug APK dla Play. Wariant third-party nie ma osobnego zestawu źródeł ani manifestu; jego ścieżka testów jednostkowych nadal kompiluje ten wariant z flagami SMS/call-log w BuildConfig, jednocześnie unikając duplikowania zadania pakowania debug APK przy każdym pushu istotnym dla Androida.
`extension-fast` jest tylko dla PR, ponieważ przebiegi push i tak wykonują pełne szardy bundled pluginów. Dzięki temu recenzje dostają szybką informację zwrotną dla zmienionych pluginów bez rezerwowania dodatkowego workera Blacksmith na `main` dla pokrycia już obecnego w `checks-node-extensions`.
Najwolniejsze rodziny testów Node są dzielone lub równoważone, aby każde zadanie pozostawało małe bez nadmiernego rezerwowania runnerów: kontrakty kanałów działają jako trzy ważone szardy, testy bundled plugin są równoważone między sześcioma workerami rozszerzeń, małe ścieżki jednostkowe rdzenia są łączone w pary, auto-reply działa na trzech zrównoważonych workerach zamiast sześciu małych, a konfiguracje agentic gateway/plugin są rozłożone między istniejące zadania agentic Node tylko ze źródeł zamiast czekać na zbudowane artefakty. Szerokie testy przeglądarkowe, QA, mediów i różnych plugin używają swoich dedykowanych konfiguracji Vitest zamiast współdzielonego ogólnego zestawu pluginów. Szeroka ścieżka agents używa współdzielonego planisty równoległego plików Vitest, ponieważ dominuje w niej import/szeregowanie, a nie pojedynczy wolny plik testowy. `runtime-config` działa z szardem infra core-runtime, aby współdzielony szard runtime nie pozostawał właścicielem końcówki. `check-additional` trzyma razem kompilację/canary granic pakietów i oddziela architekturę topologii runtime od pokrycia gateway watch; szard boundary guard uruchamia swoje małe niezależne guardy współbieżnie w ramach jednego zadania. Gateway watch, testy kanałów i szard granicy wsparcia rdzenia działają współbieżnie wewnątrz `build-artifacts` po tym, jak `dist/` i `dist-runtime/` są już zbudowane, zachowując swoje stare nazwy kontroli jako lekkie zadania weryfikujące, a jednocześnie unikając dwóch dodatkowych workerów Blacksmith i drugiej kolejki konsumentów artefaktów.
Android CI uruchamia zarówno `testPlayDebugUnitTest`, jak i `testThirdPartyDebugUnitTest`, a następnie buduje Play debug APK. Wariant third-party nie ma osobnego zestawu źródeł ani manifestu; jego ścieżka testów jednostkowych nadal kompiluje ten wariant z flagami BuildConfig dla SMS/call-log, jednocześnie unikając zduplikowanego zadania pakowania debug APK przy każdym pushu istotnym dla Androida.
`extension-fast` jest tylko dla PR, ponieważ uruchomienia push już wykonują pełne szardy bundled plugin. Dzięki temu recenzje dostają szybki feedback dla zmienionych pluginów bez rezerwowania dodatkowego workera Blacksmith na `main` dla pokrycia już obecnego w `checks-node-extensions`.
GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowszy push trafi do tego samego PR lub refa `main`. Traktuj to jako szum CI, chyba że najnowszy przebieg dla tego samego refa również kończy się błędem. Zagregowane sprawdzenia szardów używają `!cancelled() && always()`, więc nadal zgłaszają zwykłe błędy szardów, ale nie ustawiają się w kolejce po tym, jak cały workflow został już zastąpiony.
Klucz współbieżności CI jest wersjonowany (`CI-v7-*`), aby zombie po stronie GitHub w starej grupie kolejki nie mogło bezterminowo blokować nowszych przebiegów na main.
GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowszy push trafi na ten sam ref PR lub `main`. Traktuj to jako szum CI, chyba że najnowsze uruchomienie dla tego samego ref również kończy się niepowodzeniem. Zagregowane kontrole shardów używają `!cancelled() && always()`, dzięki czemu nadal raportują zwykłe awarie shardów, ale nie ustawiają się w kolejce po tym, jak cały workflow został już zastąpiony.
Klucz współbieżności CI jest wersjonowany (`CI-v7-*`), aby zombie po stronie GitHub w starej grupie kolejki nie mogło bezterminowo blokować nowszych uruchomień na main.
## Runery
## Runnery
| Runner | Zadania |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ubuntu-24.04` | `preflight`, szybkie zadania bezpieczeństwa i agregaty (`security-scm-fast`, `security-dependency-audit`, `security-fast`), szybkie sprawdzenia protocol/contract/bundled, szardowane sprawdzenia kontraktów kanałów, szardy `check` z wyjątkiem lint, szardy i agregaty `check-additional`, zagregowane weryfikatory testów Node, sprawdzenia dokumentacji, Python Skills, workflow-sanity, labeler, auto-response; preflight dla install-smoke również używa Ubuntu hostowanego przez GitHub, aby macierz Blacksmith mogła wcześniej trafić do kolejki |
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, szardy testów Linux Node, szardy testów bundled pluginów, `android` |
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, które pozostaje na tyle wrażliwe na CPU, że 8 vCPU kosztowało więcej, niż oszczędzało; buildy Docker dla install-smoke, gdzie czas oczekiwania w kolejce dla 32 vCPU kosztował więcej, niż oszczędzał |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ubuntu-24.04` | `preflight`, szybkie zadania bezpieczeństwa i agregaty (`security-scm-fast`, `security-dependency-audit`, `security-fast`), szybkie kontrole protocol/contract/bundled, szardowane kontrole kontraktów kanałów, szardy `check` z wyjątkiem lint, szardy i agregaty `check-additional`, zagregowane weryfikatory testów Node, kontrole dokumentacji, Python Skills, workflow-sanity, labeler, auto-response; preflight install-smoke również używa Ubuntu hostowanego przez GitHub, aby macierz Blacksmith mogła wcześniej trafić do kolejki |
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, szardy testów Linux Node, szardy testów bundled plugin, `android` |
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, które nadal jest na tyle wrażliwe na CPU, że 8 vCPU kosztowało więcej, niż oszczędzało; buildy Docker dla install-smoke, gdzie czas oczekiwania w kolejce dla 32 vCPU kosztował więcej, niż oszczędzał |
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
| `blacksmith-6vcpu-macos-latest` | `macos-node` na `openclaw/openclaw`; forki przechodzą awaryjnie na `macos-latest` |
| `blacksmith-12vcpu-macos-latest` | `macos-swift` na `openclaw/openclaw`; forki przechodzą awaryjnie na `macos-latest` |
| `blacksmith-6vcpu-macos-latest` | `macos-node` w `openclaw/openclaw`; forki wracają do `macos-latest` |
| `blacksmith-12vcpu-macos-latest` | `macos-swift` w `openclaw/openclaw`; forki wracają do `macos-latest` |
## Lokalne odpowiedniki
```bash
pnpm changed:lanes # sprawdź lokalny klasyfikator zmienionych ścieżek dla origin/main...HEAD
pnpm check:changed # inteligentna lokalna bramka: zmienione typecheck/lint/testy według ścieżki granicznej
pnpm check # szybka lokalna bramka: produkcyjne tsgo + szardowany lint + równoległe szybkie guardy
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 każdego etapu
pnpm check:timed # ta sama bramka z pomiarami czasu 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 # formatowanie dokumentacji + lint + uszkodzone linki
pnpm build # zbuduj dist, gdy ścieżki CI artifact/build-smoke mają znaczenie
node scripts/ci-run-timings.mjs <run-id> # podsumuj czas wykonania, czas w kolejce i najwolniejsze zadania
pnpm check:docs # formatowanie dokumentacji + lint + niedziałające linki
pnpm build # zbuduj dist, gdy mają znaczenie ścieżki CI artifact/build-smoke
node scripts/ci-run-timings.mjs <run-id> # podsumuj czas całkowity, czas w kolejce i najwolniejsze zadania
node scripts/ci-run-timings.mjs --recent 10 # porównaj ostatnie udane uruchomienia CI na main
```

139
docs/pl/gateway/authentication.md
View File

@ -1,14 +1,14 @@
---
read_when:
- Debugujesz uwierzytelnianie modelu lub wygaśnięcie OAuth
- Dokumentujesz uwierzytelnianie lub przechowywanie poświadczeń
summary: 'Uwierzytelnianie modeli: OAuth, klucze API, ponowne użycie Claude CLI i setup-token Anthropic'
- Debugowanie uwierzytelniania modelu lub wygaśnięcia OAuth
- Dokumentowanie uwierzytelniania lub przechowywania poświadczeń
summary: 'Uwierzytelnianie modeli: OAuth, klucze API, ponowne użycie Claude CLI oraz token konfiguracji Anthropic'
title: Uwierzytelnianie
x-i18n:
generated_at: "2026-04-07T09:44:52Z"
generated_at: "2026-04-23T14:55:01Z"
model: gpt-5.4
provider: openai
source_hash: 9db0ad9eccd7e3e3ca328adaad260bc4288a8ccdbe2dc0c24d9fd049b7ab9231
source_hash: 37a7c20872b915d1d079f0578c933e43cbdb97eca1c60d8c4e6e5137ca83f8b2
source_path: gateway/authentication.md
workflow: 15
---
@ -16,35 +16,31 @@ x-i18n:
# Uwierzytelnianie (dostawcy modeli)
<Note>
Ta strona opisuje uwierzytelnianie **dostawców modeli** (klucze API, OAuth, ponowne użycie Claude CLI i setup-token Anthropic). W przypadku uwierzytelniania **połączenia z gateway** (token, hasło, trusted-proxy) zobacz [Configuration](/pl/gateway/configuration) i [Trusted Proxy Auth](/pl/gateway/trusted-proxy-auth).
Ta strona dotyczy uwierzytelniania **dostawcy modeli** (klucze API, OAuth, ponowne użycie Claude CLI oraz token konfiguracji Anthropic). Informacje o uwierzytelnianiu **połączenia z Gateway** (token, hasło, trusted-proxy) znajdziesz w [Configuration](/pl/gateway/configuration) oraz [Trusted Proxy Auth](/pl/gateway/trusted-proxy-auth).
</Note>
OpenClaw obsługuje OAuth i klucze API dla dostawców modeli. Dla stale działających
hostów gateway klucze API są zwykle najbardziej przewidywalną opcją. Obsługiwane są
również przepływy subskrypcyjne/OAuth, gdy pasują do modelu konta u danego dostawcy.
OpenClaw obsługuje OAuth i klucze API dla dostawców modeli. W przypadku hostów Gateway działających stale klucze API są zwykle najbardziej przewidywalną opcją. Obsługiwane są również przepływy subskrypcji/OAuth, gdy pasują do modelu konta u dostawcy.
Zobacz [/concepts/oauth](/pl/concepts/oauth), aby poznać pełny przepływ OAuth i układ
przechowywania.
W przypadku uwierzytelniania opartego na SecretRef (dostawcy `env`/`file`/`exec`) zobacz [Secrets Management](/pl/gateway/secrets).
Informacje o regułach kwalifikowalności poświadczeń i kodów powodów używanych przez `models status --probe` znajdziesz w
Pełny przebieg OAuth i układ przechowywania opisano w [/concepts/oauth](/pl/concepts/oauth).
Informacje o uwierzytelnianiu opartym na SecretRef (dostawcy `env`/`file`/`exec`) znajdziesz w [Secrets Management](/pl/gateway/secrets).
Informacje o zasadach kwalifikowalności poświadczeń i kodach przyczyn używanych przez `models status --probe` znajdziesz w
[Auth Credential Semantics](/pl/auth-credential-semantics).
## Zalecana konfiguracja (klucz API, dowolny dostawca)
Jeśli uruchamiasz długo działający gateway, zacznij od klucza API dla wybranego
Jeśli uruchamiasz długo działający Gateway, zacznij od klucza API dla wybranego
dostawcy.
W przypadku Anthropic uwierzytelnianie kluczem API nadal jest najbardziej przewidywalną konfiguracją serwerową,
ale OpenClaw obsługuje też ponowne użycie lokalnego logowania Claude CLI.
W przypadku Anthropic uwierzytelnianie kluczem API nadal jest najbardziej przewidywalną konfiguracją serwerową, ale OpenClaw obsługuje też ponowne użycie lokalnego logowania Claude CLI.
1. Utwórz klucz API w konsoli dostawcy.
2. Umieść go na **hoście gateway** (maszynie uruchamiającej `openclaw gateway`).
2. Umieść go na **hoście Gateway** (maszynie uruchamiającej `openclaw gateway`).
```bash
export <PROVIDER>_API_KEY="..."
openclaw models status
```
3. Jeśli Gateway działa pod systemd/launchd, lepiej umieścić klucz w
3. Jeśli Gateway działa pod systemd/launchd, najlepiej umieścić klucz w
`~/.openclaw/.env`, aby demon mógł go odczytać:
```bash
@ -53,50 +49,62 @@ cat >> ~/.openclaw/.env <<'EOF'
EOF
```
Następnie uruchom ponownie demona (lub zrestartuj proces Gateway) i sprawdź ponownie:
Następnie uruchom ponownie demona (lub proces Gateway) i sprawdź ponownie:
```bash
openclaw models status
openclaw doctor
```
Jeśli nie chcesz samodzielnie zarządzać zmiennymi env, onboarding może zapisać
Jeśli wolisz nie zarządzać samodzielnie zmiennymi środowiskowymi, onboarding może zapisać
klucze API do użycia przez demona: `openclaw onboard`.
Szczegóły o dziedziczeniu env (`env.shellEnv`,
Szczegóły dotyczące dziedziczenia środowiska (`env.shellEnv`,
`~/.openclaw/.env`, systemd/launchd) znajdziesz w [Help](/pl/help).
## Anthropic: zgodność Claude CLI i tokenów
Uwierzytelnianie setup-token Anthropic jest nadal dostępne w OpenClaw jako obsługiwana
ścieżka tokenu. Personel Anthropic poinformował nas później, że użycie Claude CLI w stylu OpenClaw
jest znowu dozwolone, więc OpenClaw traktuje ponowne użycie Claude CLI i użycie `claude -p` jako
zaakceptowane dla tej integracji, chyba że Anthropic opublikuje nowe zasady. Gdy
ponowne użycie Claude CLI jest dostępne na hoście, jest to obecnie preferowana ścieżka.
Uwierzytelnianie tokenem konfiguracji Anthropic jest nadal dostępne w OpenClaw jako obsługiwana ścieżka tokenu. Zespół Anthropic poinformował nas później, że użycie Claude CLI w stylu OpenClaw jest ponownie dozwolone, więc OpenClaw traktuje ponowne użycie Claude CLI oraz użycie `claude -p` jako usankcjonowane dla tej integracji, chyba że Anthropic opublikuje nową politykę. Gdy ponowne użycie Claude CLI jest dostępne na hoście, jest to obecnie preferowana ścieżka.
Dla długo działających hostów gateway klucz API Anthropic nadal jest najbardziej przewidywalną
konfiguracją. Jeśli chcesz ponownie użyć istniejącego logowania Claude na tym samym hoście,
użyj ścieżki Anthropic Claude CLI w onboardingu/konfiguracji.
W przypadku długo działających hostów Gateway klucz API Anthropic nadal jest najbardziej przewidywalną konfiguracją. Jeśli chcesz ponownie użyć istniejącego logowania Claude na tym samym hoście, użyj ścieżki Anthropic Claude CLI w onboarding/configure.
Ręczne wprowadzanie tokenu (dowolny dostawca; zapisuje `auth-profiles.json` i aktualizuje config):
Zalecana konfiguracja hosta do ponownego użycia Claude CLI:
```bash
# Run on the gateway host
claude auth login
claude auth status --text
openclaw models auth login --provider anthropic --method cli --set-default
```
Jest to konfiguracja dwuetapowa:
1. Zaloguj samo Claude Code do Anthropic na hoście Gateway.
2. Powiedz OpenClaw, aby przełączył wybór modelu Anthropic na lokalny backend `claude-cli`
i zapisał odpowiadający mu profil uwierzytelniania OpenClaw.
Jeśli `claude` nie jest w `PATH`, najpierw zainstaluj Claude Code albo ustaw
`agents.defaults.cliBackends.claude-cli.command` na rzeczywistą ścieżkę do pliku binarnego.
Ręczne wklejenie tokenu (dowolny dostawca; zapisuje `auth-profiles.json` + aktualizuje konfigurację):
```bash
openclaw models auth paste-token --provider openrouter
```
Obsługiwane są też odwołania do profili auth dla statycznych poświadczeń:
Odwołania do profili uwierzytelniania są też obsługiwane dla statycznych poświadczeń:
- poświadczenia `api_key` mogą używać `keyRef: { source, provider, id }`
- poświadczenia `token` mogą używać `tokenRef: { source, provider, id }`
- profile w trybie OAuth nie obsługują poświadczeń SecretRef; jeśli `auth.profiles.<id>.mode` jest ustawione na `"oauth"`, wejście `keyRef`/`tokenRef` oparte na SecretRef dla tego profilu zostanie odrzucone.
- Profile w trybie OAuth nie obsługują poświadczeń SecretRef; jeśli dla `auth.profiles.<id>.mode` ustawiono `"oauth"`, dane wejściowe `keyRef`/`tokenRef` oparte na SecretRef dla tego profilu są odrzucane.
Sprawdzenie przyjazne dla automatyzacji (kod wyjścia `1` przy wygaśnięciu/braku, `2` przy zbliżającym się wygaśnięciu):
Kontrola przyjazna automatyzacji (kod wyjścia `1`, gdy brak/wygaśnięcie, `2`, gdy wkrótce wygaśnie):
```bash
openclaw models status --check
```
Aktywne sondy auth:
Aktywne sondy uwierzytelniania:
```bash
openclaw models status --probe
@ -104,64 +112,63 @@ openclaw models status --probe
Uwagi:
- Wiersze sond mogą pochodzić z profili auth, poświadczeń env lub `models.json`.
- Wiersze sondy mogą pochodzić z profili uwierzytelniania, poświadczeń środowiskowych lub `models.json`.
- Jeśli jawne `auth.order.<provider>` pomija zapisany profil, sonda zgłasza
`excluded_by_auth_order` dla tego profilu zamiast próbować go użyć.
- Jeśli auth istnieje, ale OpenClaw nie może ustalić modelu kandydującego, który można sondować, dla
tego dostawcy, sonda zgłasza `status: no_model`.
- Ograniczenia czasowe po rate limicie mogą być przypisane do konkretnego modelu. Profil w stanie cooldown dla jednego
modelu nadal może nadawać się do użycia z modelami pokrewnymi u tego samego dostawcy.
dla tego profilu `excluded_by_auth_order` zamiast próbować go użyć.
- Jeśli uwierzytelnianie istnieje, ale OpenClaw nie może ustalić kandydata modelu nadającego się do sondowania dla tego dostawcy, sonda zgłasza `status: no_model`.
- Okresy ochłodzenia limitów szybkości mogą być przypisane do modelu. Profil objęty okresem ochłodzenia dla jednego
modelu może nadal nadawać się do użycia dla pokrewnego modelu u tego samego dostawcy.
Opcjonalne skrypty operacyjne (systemd/Termux) opisano tutaj:
[Skrypty monitorowania auth](/pl/help/scripts#auth-monitoring-scripts)
Opcjonalne skrypty operacyjne (systemd/Termux) są opisane tutaj:
[Skrypty monitorowania uwierzytelniania](/pl/help/scripts#auth-monitoring-scripts)
## Uwaga dotycząca Anthropic
Backend Anthropic `claude-cli` jest ponownie obsługiwany.
- Personel Anthropic poinformował nas, że ta ścieżka integracji OpenClaw jest ponownie dozwolona.
- Dlatego OpenClaw traktuje ponowne użycie Claude CLI i użycie `claude -p` jako zaakceptowane
dla uruchomień opartych na Anthropic, chyba że Anthropic opublikuje nowe zasady.
- Klucze API Anthropic pozostają najbardziej przewidywalnym wyborem dla długo działających hostów gateway
i jawnej kontroli rozliczeń po stronie serwera.
- Zespół Anthropic poinformował nas, że ta ścieżka integracji OpenClaw jest znów dozwolona.
- Dlatego OpenClaw traktuje ponowne użycie Claude CLI i użycie `claude -p` jako usankcjonowane
dla uruchomień opartych na Anthropic, chyba że Anthropic opublikuje nową politykę.
- Klucze API Anthropic pozostają najbardziej przewidywalnym wyborem dla długo działających hostów Gateway
oraz dla jawnej kontroli rozliczeń po stronie serwera.
## Sprawdzanie stanu auth modelu
## Sprawdzanie stanu uwierzytelniania modelu
```bash
openclaw models status
openclaw doctor
```
## Zachowanie przy rotacji kluczy API (gateway)
## Zachowanie podczas rotacji kluczy API (Gateway)
Niektórzy dostawcy obsługują ponawianie żądania z alternatywnymi kluczami, gdy wywołanie API
napotka rate limit po stronie dostawcy.
trafi na limit szybkości po stronie dostawcy.
- Kolejność priorytetów:
- `OPENCLAW_LIVE_<PROVIDER>_KEY` (pojedyncze nadpisanie)
- `<PROVIDER>_API_KEYS`
- `<PROVIDER>_API_KEY`
- `<PROVIDER>_API_KEY_*`
- Dostawcy Google uwzględniają też `GOOGLE_API_KEY` jako dodatkowy fallback.
- Ta sama lista kluczy jest deduplikowana przed użyciem.
- OpenClaw ponawia próbę z następnym kluczem tylko przy błędach rate limitu (na przykład
- Dostawcy Google uwzględniają też `GOOGLE_API_KEY` jako dodatkowy mechanizm awaryjny.
- Ta sama lista kluczy jest przed użyciem deduplikowana.
- OpenClaw ponawia próbę z następnym kluczem tylko przy błędach limitu szybkości (na przykład
`429`, `rate_limit`, `quota`, `resource exhausted`, `Too many concurrent
requests`, `ThrottlingException`, `concurrency limit reached` lub
`workers_ai ... quota limit exceeded`).
- Błędy inne niż rate limit nie są ponawiane z alternatywnymi kluczami.
- Błędy inne niż limit szybkości nie są ponawiane z alternatywnymi kluczami.
- Jeśli wszystkie klucze zawiodą, zwracany jest końcowy błąd z ostatniej próby.
## Sterowanie tym, które poświadczenie jest używane
## Sterowanie używanym poświadczeniem
### Dla sesji (polecenie czatu)
### Dla sesji (komenda czatu)
Użyj `/model <alias-or-id>@<profileId>`, aby przypiąć określone poświadczenie dostawcy dla bieżącej sesji (przykładowe identyfikatory profili: `anthropic:default`, `anthropic:work`).
Użyj `/model <alias-or-id>@<profileId>`, aby przypiąć konkretne poświadczenie dostawcy dla bieżącej sesji (przykładowe identyfikatory profili: `anthropic:default`, `anthropic:work`).
Użyj `/model` (lub `/model list`) dla zwartego selektora; użyj `/model status` dla pełnego widoku (kandydaci + następny profil auth oraz szczegóły endpointu dostawcy, jeśli są skonfigurowane).
Użyj `/model` (lub `/model list`) dla zwartego selektora; użyj `/model status` dla pełnego widoku (kandydaci + następny profil uwierzytelniania oraz szczegóły endpointu dostawcy, jeśli są skonfigurowane).
### Dla agenta (nadpisanie CLI)
Ustaw jawne nadpisanie kolejności profili auth dla agenta (zapisywane w `auth-state.json` tego agenta):
Ustaw jawne nadpisanie kolejności profili uwierzytelniania dla agenta (zapisywane w `auth-state.json` tego agenta):
```bash
openclaw models auth order get --provider anthropic
@ -169,10 +176,10 @@ openclaw models auth order set --provider anthropic anthropic:default
openclaw models auth order clear --provider anthropic
```
Użyj `--agent <id>`, aby wskazać konkretnego agenta; pomiń ten parametr, aby użyć skonfigurowanego agenta domyślnego.
Użyj `--agent <id>`, aby wskazać konkretnego agenta; pomiń tę opcję, aby użyć skonfigurowanego domyślnego agenta.
Podczas debugowania problemów z kolejnością `openclaw models status --probe` pokazuje pominięte
zapisane profile jako `excluded_by_auth_order` zamiast pomijać je po cichu.
Podczas debugowania problemów z cooldown pamiętaj, że ograniczenia czasowe po rate limicie mogą być powiązane
Podczas debugowania problemów z okresem ochłodzenia pamiętaj, że okresy ochłodzenia limitów szybkości mogą być powiązane
z jednym identyfikatorem modelu, a nie z całym profilem dostawcy.
## Rozwiązywanie problemów
@ -180,14 +187,14 @@ z jednym identyfikatorem modelu, a nie z całym profilem dostawcy.
### „Nie znaleziono poświadczeń”
Jeśli brakuje profilu Anthropic, skonfiguruj klucz API Anthropic na
**hoście gateway** albo ustaw ścieżkę setup-token Anthropic, a następnie sprawdź ponownie:
**hoście Gateway** albo skonfiguruj ścieżkę tokenu konfiguracji Anthropic, a następnie sprawdź ponownie:
```bash
openclaw models status
```
### Token wygasa/wygasł
### Token wkrótce wygasa/wygasł
Uruchom `openclaw models status`, aby potwierdzić, który profil wygasa. Jeśli
profil tokenu Anthropic jest nieobecny lub wygasł, odśwież tę konfigurację przez
setup-token albo przejdź na klucz API Anthropic.
Uruchom `openclaw models status`, aby potwierdzić, który profil wkrótce wygaśnie. Jeśli profil tokenu
Anthropic nie istnieje lub wygasł, odśwież tę konfigurację przez
token konfiguracji albo przejdź na klucz API Anthropic.

232
docs/pl/gateway/cli-backends.md
View File

@ -1,47 +1,47 @@
---
read_when:
- Chcesz mieć niezawodne rozwiązanie awaryjne, gdy providerzy API zawodzą
- Używasz Codex CLI lub innych lokalnych CLI AI i chcesz je ponownie wykorzystać
- Chcesz zrozumieć most MCP local loopback do dostępu narzędzi dla backendów CLI
summary: 'Backendy CLI: lokalne awaryjne przejście do CLI AI z opcjonalnym mostem narzędzi MCP'
- Potrzebujesz niezawodnego rozwiązania awaryjnego, gdy dostawcy API zawodzą.
- Używasz Codex CLI lub innych lokalnych CLI AI i chcesz używać ich ponownie.
- Chcesz zrozumieć most local loopback MCP do dostępu narzędzi backendu CLI.
summary: 'Backendy CLI: lokalny awaryjny CLI AI z opcjonalnym mostem narzędzi MCP'
title: Backendy CLI
x-i18n:
generated_at: "2026-04-23T10:00:34Z"
generated_at: "2026-04-23T14:55:10Z"
model: gpt-5.4
provider: openai
source_hash: 475923b36e4580d3e4e57014ff2e6b89e9eb52c11b0a0ab1fc8241655b07836e
source_hash: ff7458d18b8a5b716930579241177917fd3edffcf7f6e211c7d570cf76519316
source_path: gateway/cli-backends.md
workflow: 15
---
# Backendy CLI (środowisko awaryjne)
# Backendy CLI (awaryjne środowisko uruchomieniowe)
OpenClaw może uruchamiać **lokalne CLI AI** jako **awaryjne rozwiązanie tylko tekstowe**, gdy providerzy API są niedostępni,
objęci ograniczeniami szybkości lub tymczasowo działają nieprawidłowo. To podejście jest celowo zachowawcze:
OpenClaw może uruchamiać **lokalne CLI AI** jako **wyłącznie tekstowe rozwiązanie awaryjne**, gdy dostawcy API są niedostępni,
objęci limitami szybkości lub tymczasowo działają nieprawidłowo. Jest to celowo zachowawcze podejście:
- **Narzędzia OpenClaw nie są wstrzykiwane bezpośrednio**, ale backendy z `bundleMcp: true`
mogą otrzymywać narzędzia Gateway przez most MCP local loopback.
mogą otrzymywać narzędzia gateway przez most local loopback MCP.
- **Strumieniowanie JSONL** dla CLI, które je obsługują.
- **Sesje są obsługiwane** (dzięki czemu kolejne tury pozostają spójne).
- **Sesje są obsługiwane** (dzięki temu kolejne tury pozostają spójne).
- **Obrazy mogą być przekazywane dalej**, jeśli CLI akceptuje ścieżki do obrazów.
To rozwiązanie zostało zaprojektowane jako **siatka bezpieczeństwa**, a nie główna ścieżka. Używaj go, gdy
chcesz mieć „zawsze działające” odpowiedzi tekstowe bez polegania na zewnętrznych API.
To rozwiązanie zaprojektowano jako **siatkę bezpieczeństwa**, a nie główną ścieżkę. Używaj go, gdy
chcesz uzyskać odpowiedzi tekstowe typu „zawsze działa” bez polegania na zewnętrznych API.
Jeśli chcesz pełnego środowiska harness z kontrolą sesji ACP, zadaniami w tle,
wiązaniem wątku / rozmowy oraz trwałymi zewnętrznymi sesjami kodowania, użyj
[ACP Agents](/pl/tools/acp-agents). Backendy CLI to nie ACP.
Jeśli chcesz mieć pełne środowisko uruchomieniowe harness z kontrolą sesji ACP, zadaniami w tle,
powiązaniem wątku/konwersacji i trwałymi zewnętrznymi sesjami kodowania, użyj
[agentów ACP](/pl/tools/acp-agents). Backendy CLI nie są ACP.
## Szybki start dla początkujących
Możesz używać Codex CLI **bez żadnej konfiguracji** (dołączony plugin OpenAI
Możesz używać Codex CLI **bez żadnej konfiguracji** (dołączony Plugin OpenAI
rejestruje domyślny backend):
```bash
openclaw agent --message "hi" --model codex-cli/gpt-5.4
```
Jeśli Twój Gateway działa pod launchd/systemd, a PATH jest minimalny, dodaj tylko
Jeśli Twój gateway działa pod launchd/systemd i `PATH` jest minimalne, dodaj tylko
ścieżkę polecenia:
```json5
@ -58,16 +58,16 @@ Jeśli Twój Gateway działa pod launchd/systemd, a PATH jest minimalny, dodaj t
}
```
To wszystko. Nie są potrzebne żadne klucze ani dodatkowa konfiguracja uwierzytelniania poza samym CLI.
To wszystko. Żadne klucze ani dodatkowa konfiguracja uwierzytelniania nie są potrzebne poza samym CLI.
Jeśli używasz dołączonego backendu CLI jako **głównego providera wiadomości** na
hoście Gateway, OpenClaw automatycznie wczytuje teraz należący do niego dołączony plugin, gdy Twoja konfiguracja
jawnie odwołuje się do tego backendu w model ref lub pod
Jeśli używasz dołączonego backendu CLI jako **głównego dostawcy wiadomości** na
hoście gateway, OpenClaw teraz automatycznie ładuje należący do niego dołączony Plugin, gdy Twoja konfiguracja
jawnie odwołuje się do tego backendu w odwołaniu do modelu albo w
`agents.defaults.cliBackends`.
## Używanie jako rozwiązania awaryjnego
Dodaj backend CLI do listy awaryjnej, aby był uruchamiany tylko wtedy, gdy modele podstawowe zawiodą:
Dodaj backend CLI do listy rozwiązań awaryjnych, aby był uruchamiany tylko wtedy, gdy modele podstawowe zawiodą:
```json5
{
@ -88,9 +88,9 @@ Dodaj backend CLI do listy awaryjnej, aby był uruchamiany tylko wtedy, gdy mode
Uwagi:
- Jeśli używasz `agents.defaults.models` (lista dozwolonych), musisz uwzględnić tam również modele backendu CLI.
- Jeśli podstawowy provider zawiedzie (uwierzytelnianie, limity szybkości, timeouty), OpenClaw
spróbuje następnie backendu CLI.
- Jeśli używasz `agents.defaults.models` (listy dozwolonych), musisz uwzględnić tam również modele backendu CLI.
- Jeśli podstawowy dostawca zawiedzie (uwierzytelnianie, limity szybkości, przekroczenia czasu), OpenClaw
spróbuje następnie użyć backendu CLI.
## Przegląd konfiguracji
@ -100,8 +100,8 @@ Wszystkie backendy CLI znajdują się pod:
agents.defaults.cliBackends
```
Każdy wpis jest kluczowany przez **id providera** (np. `codex-cli`, `my-cli`).
Id providera staje się lewą stroną model ref:
Każdy wpis jest kluczowany przez **id dostawcy** (np. `codex-cli`, `my-cli`).
Id dostawcy staje się lewą stroną odwołania do modelu:
```
<provider>/<model>
@ -147,69 +147,82 @@ Id providera staje się lewą stroną model ref:
## Jak to działa
1. **Wybiera backend** na podstawie prefiksu providera (`codex-cli/...`).
2. **Buduje system prompt** przy użyciu tego samego promptu OpenClaw + kontekstu workspace.
3. **Wykonuje CLI** z id sesji (jeśli jest obsługiwane), dzięki czemu historia pozostaje spójna.
Dołączony backend `claude-cli` utrzymuje proces stdio Claude przy życiu dla każdej
1. **Wybiera backend** na podstawie prefiksu dostawcy (`codex-cli/...`).
2. **Buduje prompt systemowy** przy użyciu tego samego promptu OpenClaw i kontekstu workspace.
3. **Uruchamia CLI** z identyfikatorem sesji (jeśli jest obsługiwany), aby historia pozostała spójna.
Dołączony backend `claude-cli` utrzymuje proces Claude stdio aktywny dla każdej
sesji OpenClaw i wysyła kolejne tury przez stdin stream-json.
4. **Parsuje wyjście** (JSON lub zwykły tekst) i zwraca końcowy tekst.
5. **Utrwala id sesji** dla każdego backendu, dzięki czemu kolejne tury używają tej samej sesji CLI.
4. **Parsuje dane wyjściowe** (JSON albo zwykły tekst) i zwraca końcowy tekst.
5. **Utrwala identyfikatory sesji** dla każdego backendu, aby kolejne tury ponownie używały tej samej sesji CLI.
<Note>
Dołączony backend Anthropic `claude-cli` jest ponownie obsługiwany. Pracownicy Anthropic
powiedzieli nam, że użycie Claude CLI w stylu OpenClaw jest znów dozwolone, więc OpenClaw traktuje
użycie `claude -p` jako sankcjonowane dla tej integracji, chyba że Anthropic opublikuje
użycie `claude -p` jako usankcjonowane dla tej integracji, chyba że Anthropic opublikuje
nową politykę.
</Note>
Dołączony backend OpenAI `codex-cli` przekazuje system prompt OpenClaw przez
nadpisanie konfiguracji `model_instructions_file` Codex (`-c
Dołączony backend OpenAI `codex-cli` przekazuje prompt systemowy OpenClaw przez
nadpisanie konfiguracji `model_instructions_file` w Codex (`-c
model_instructions_file="..."`). Codex nie udostępnia flagi w stylu Claude
`--append-system-prompt`, więc OpenClaw zapisuje złożony prompt do pliku
tymczasowego dla każdej nowej sesji Codex CLI.
Dołączony backend Anthropic `claude-cli` otrzymuje migawkę Skills OpenClaw
na dwa sposoby: kompaktowy katalog Skills OpenClaw w dołączanym system prompt oraz
tymczasowy plugin Claude Code przekazywany przez `--plugin-dir`. Plugin zawiera
tylko Skills kwalifikujące się dla danego agenta / sesji, dzięki czemu natywny resolver Skills Claude Code
na dwa sposoby: kompaktowy katalog Skills OpenClaw w dołączonym prompcie systemowym oraz
tymczasowy Plugin Claude Code przekazywany przez `--plugin-dir`. Plugin zawiera
tylko Skills kwalifikujące się dla tego agenta/sesji, więc natywny mechanizm rozpoznawania Skills Claude Code
widzi ten sam przefiltrowany zestaw, który OpenClaw w przeciwnym razie reklamowałby w prompcie.
Nadpisania env / kluczy API dla Skills są nadal stosowane przez OpenClaw do środowiska procesu potomnego dla runu.
Nadpisania env/kluczy API dla Skills są nadal stosowane przez OpenClaw do środowiska procesu potomnego na czas uruchomienia.
Zanim OpenClaw będzie mógł użyć dołączonego backendu `claude-cli`, samo Claude Code
musi być już zalogowane na tym samym hoście:
```bash
claude auth login
claude auth status --text
openclaw models auth login --provider anthropic --method cli --set-default
```
Używaj `agents.defaults.cliBackends.claude-cli.command` tylko wtedy, gdy plik binarny `claude`
nie jest już dostępny w `PATH`.
## Sesje
- Jeśli CLI obsługuje sesje, ustaw `sessionArg` (np. `--session-id`) lub
`sessionArgs` (placeholder `{sessionId}`), gdy id trzeba wstawić
- Jeśli CLI obsługuje sesje, ustaw `sessionArg` (np. `--session-id`) albo
`sessionArgs` (placeholder `{sessionId}`), gdy identyfikator musi zostać wstawiony
do wielu flag.
- Jeśli CLI używa **podpolecenia resume** z innymi flagami, ustaw
- Jeśli CLI używa **podpolecenia wznowienia** z innymi flagami, ustaw
`resumeArgs` (zastępuje `args` przy wznawianiu) i opcjonalnie `resumeOutput`
(dla wznawiania niebędącego JSON).
(dla wznowień innych niż JSON).
- `sessionMode`:
- `always`: zawsze wysyła id sesji (nowe UUID, jeśli nic nie zapisano).
- `existing`: wysyła id sesji tylko wtedy, gdy wcześniej zostało zapisane.
- `none`: nigdy nie wysyła id sesji.
- `always`: zawsze wysyłaj identyfikator sesji (nowy UUID, jeśli nic nie zapisano).
- `existing`: wysyłaj identyfikator sesji tylko wtedy, gdy został wcześniej zapisany.
- `none`: nigdy nie wysyłaj identyfikatora sesji.
- `claude-cli` domyślnie używa `liveSession: "claude-stdio"`, `output: "jsonl"`
i `input: "stdin"`, dzięki czemu kolejne tury używają ponownie aktywnego procesu Claude,
dopóki jest aktywny. Ciepłe stdio jest teraz ustawieniem domyślnym, także dla konfiguracji niestandardowych,
które pomijają pola transportu. Jeśli Gateway uruchomi się ponownie lub bezczynny proces
zakończy działanie, OpenClaw wznowi pracę z zapisanego id sesji Claude. Zapisane id sesji
są weryfikowane względem istniejącej czytelnej transkrypcji projektu przed
wznowieniem, więc widmowe powiązania są czyszczone z `reason=transcript-missing`
zamiast po cichu uruchamiać nową sesję Claude CLI pod `--resume`.
- Zapisane sesje CLI to ciągłość należąca do providera. Niejawny codzienny
reset sesji ich nie przecina; `/reset` i jawne polityki `session.reset` nadal to robią.
i `input: "stdin"`, dzięki czemu kolejne tury ponownie używają aktywnego procesu Claude,
gdy jest on aktywny. Ciepłe stdio jest teraz ustawieniem domyślnym, także dla konfiguracji niestandardowych,
które pomijają pola transportu. Jeśli Gateway uruchomi się ponownie albo bezczynny proces
zakończy działanie, OpenClaw wznowi pracę na podstawie zapisanego identyfikatora sesji Claude. Zapisane identyfikatory sesji
są weryfikowane względem istniejącego, czytelnego transkryptu projektu przed
wznowieniem, więc fantomowe powiązania są czyszczone z `reason=transcript-missing`,
zamiast po cichu rozpoczynać nową sesję Claude CLI pod `--resume`.
- Zapisane sesje CLI są ciągłością należącą do dostawcy. Domyślne codzienne
resetowanie sesji ich nie przerywa; `/reset` i jawne polityki `session.reset` już tak.
Uwagi dotyczące serializacji:
- `serialize: true` utrzymuje kolejność uruchomień w tym samym pasie.
- Większość CLI serializuje na jednym pasie providera.
- OpenClaw odrzuca ponowne użycie zapisanej sesji CLI, gdy zmienia się wybrana tożsamość uwierzytelniania,
w tym zmienione id profilu uwierzytelniania, statyczny klucz API, statyczny token lub tożsamość konta OAuth,
gdy CLI ją udostępnia. Rotacja tokenów dostępu i odświeżania OAuth nie przecina zapisanej sesji CLI. Jeśli CLI nie udostępnia
stabilnego id konta OAuth, OpenClaw pozwala temu CLI samodzielnie egzekwować uprawnienia wznowienia.
- `serialize: true` utrzymuje kolejność uruchomień w tym samym lane.
- Większość CLI serializuje pracę w jednym lane dostawcy.
- OpenClaw porzuca ponowne użycie zapisanej sesji CLI, gdy zmienia się wybrana tożsamość uwierzytelniania,
w tym gdy zmienia się id profilu uwierzytelniania, statyczny klucz API, statyczny token
albo tożsamość konta OAuth, jeśli CLI ją udostępnia. Rotacja tokenów dostępu i odświeżania OAuth
nie przerywa zapisanej sesji CLI. Jeśli CLI nie udostępnia stabilnego id konta OAuth,
OpenClaw pozwala temu CLI samodzielnie egzekwować uprawnienia wznowienia.
## Obrazy (pass-through)
## Obrazy (przekazywanie dalej)
Jeśli Twoje CLI akceptuje ścieżki do obrazów, ustaw `imageArg`:
Jeśli Twój CLI akceptuje ścieżki do obrazów, ustaw `imageArg`:
```json5
imageArg: "--image",
@ -217,27 +230,28 @@ imageMode: "repeat"
```
OpenClaw zapisze obrazy base64 do plików tymczasowych. Jeśli ustawiono `imageArg`, te
ścieżki są przekazywane jako argumenty CLI. Jeśli `imageArg` nie istnieje, OpenClaw
dołącza ścieżki plików do promptu (wstrzyknięcie ścieżki), co wystarcza dla CLI, które automatycznie
wczytują pliki lokalne ze zwykłych ścieżek.
ścieżki są przekazywane jako argumenty CLI. Jeśli `imageArg` nie jest ustawione, OpenClaw dołącza
ścieżki plików do promptu (wstrzykiwanie ścieżek), co wystarcza dla CLI, które automatycznie
ładują pliki lokalne ze zwykłych ścieżek.
## Wejścia / wyjścia
- `output: "json"` (domyślnie) próbuje sparsować JSON i wyodrębnić tekst + id sesji.
- Dla wyjścia JSON Gemini CLI OpenClaw odczytuje tekst odpowiedzi z `response`, a
użycie z `stats`, gdy `usage` nie istnieje lub jest puste.
- `output: "jsonl"` parsuje strumienie JSONL (na przykład Codex CLI `--json`) i wyodrębnia końcową wiadomość agenta oraz identyfikatory sesji, gdy są obecne.
- `output: "json"` (domyślne) próbuje sparsować JSON i wyodrębnić tekst oraz identyfikator sesji.
- Dla danych wyjściowych Gemini CLI w formacie JSON OpenClaw odczytuje tekst odpowiedzi z `response` oraz
użycie z `stats`, gdy `usage` jest nieobecne lub puste.
- `output: "jsonl"` parsuje strumienie JSONL (na przykład Codex CLI `--json`) i wyodrębnia końcową wiadomość agenta oraz identyfikatory sesji,
jeśli są obecne.
- `output: "text"` traktuje stdout jako końcową odpowiedź.
Tryby wejścia:
- `input: "arg"` (domyślnie) przekazuje prompt jako ostatni argument CLI.
- `input: "arg"` (domyślne) przekazuje prompt jako ostatni argument CLI.
- `input: "stdin"` wysyła prompt przez stdin.
- Jeśli prompt jest bardzo długi i ustawiono `maxPromptArgChars`, używane jest stdin.
- Jeśli prompt jest bardzo długi i ustawiono `maxPromptArgChars`, używany jest stdin.
## Ustawienia domyślne (należące do pluginu)
## Ustawienia domyślne (należące do Pluginu)
Dołączony plugin OpenAI rejestruje również domyślne ustawienia dla `codex-cli`:
Dołączony Plugin OpenAI rejestruje również domyślne ustawienia dla `codex-cli`:
- `command: "codex"`
- `args: ["exec","--json","--color","never","--sandbox","workspace-write","--skip-git-repo-check"]`
@ -248,7 +262,7 @@ Dołączony plugin OpenAI rejestruje również domyślne ustawienia dla `codex-c
- `imageArg: "--image"`
- `sessionMode: "existing"`
Dołączony plugin Google rejestruje również domyślne ustawienia dla `google-gemini-cli`:
Dołączony Plugin Google rejestruje również domyślne ustawienia dla `google-gemini-cli`:
- `command: "gemini"`
- `args: ["--output-format", "json", "--prompt", "{prompt}"]`
@ -260,31 +274,31 @@ Dołączony plugin Google rejestruje również domyślne ustawienia dla `google-
- `sessionIdFields: ["session_id", "sessionId"]`
Wymaganie wstępne: lokalny Gemini CLI musi być zainstalowany i dostępny jako
`gemini` w `PATH` (`brew install gemini-cli` lub
`gemini` w `PATH` (`brew install gemini-cli` albo
`npm install -g @google/gemini-cli`).
Uwagi dotyczące JSON Gemini CLI:
- Tekst odpowiedzi jest odczytywany z pola JSON `response`.
- Użycie przechodzi awaryjnie do `stats`, gdy `usage` nie istnieje lub jest puste.
- Użycie wraca do `stats`, gdy `usage` jest nieobecne lub puste.
- `stats.cached` jest normalizowane do OpenClaw `cacheRead`.
- Jeśli `stats.input` nie istnieje, OpenClaw wyprowadza tokeny wejściowe z
- Jeśli `stats.input` jest nieobecne, OpenClaw wyprowadza tokeny wejściowe z
`stats.input_tokens - stats.cached`.
Nadpisuj tylko wtedy, gdy to potrzebne (najczęściej: bezwzględna ścieżka `command`).
Nadpisuj tylko wtedy, gdy to potrzebne (częsty przypadek: bezwzględna ścieżka `command`).
## Ustawienia domyślne należące do pluginu
## Ustawienia domyślne należące do Pluginu
Ustawienia domyślne backendów CLI są teraz częścią powierzchni pluginu:
Domyślne ustawienia backendu CLI są teraz częścią powierzchni Pluginu:
- Pluginy rejestrują je przez `api.registerCliBackend(...)`.
- `id` backendu staje się prefiksem providera w model ref.
- Konfiguracja użytkownika w `agents.defaults.cliBackends.<id>` nadal nadpisuje domyślne ustawienia pluginu.
- Czyszczenie konfiguracji specyficznej dla backendu pozostaje własnością pluginu dzięki opcjonalnemu
- Backend `id` staje się prefiksem dostawcy w odwołaniach do modeli.
- Konfiguracja użytkownika w `agents.defaults.cliBackends.<id>` nadal nadpisuje domyślne ustawienia Pluginu.
- Czyszczenie konfiguracji specyficznej dla backendu nadal pozostaje po stronie Pluginu dzięki opcjonalnemu
hookowi `normalizeConfig`.
Pluginy, które potrzebują drobnych shimów zgodności promptów / wiadomości, mogą deklarować
dwukierunkowe transformacje tekstu bez zastępowania providera ani backendu CLI:
Pluginy, które potrzebują drobnych shimów zgodności promptów/wiadomości, mogą deklarować
dwukierunkowe transformacje tekstu bez zastępowania dostawcy ani backendu CLI:
```typescript
api.registerTextTransforms({
@ -301,45 +315,45 @@ api.registerTextTransforms({
});
```
`input` przepisuje system prompt i prompt użytkownika przekazywane do CLI. `output`
przepisuje strumieniowane delty asystenta i sparsowany końcowy tekst, zanim OpenClaw obsłuży
własne markery sterujące i dostarczanie do kanału.
`input` przepisuje prompt systemowy i prompt użytkownika przekazywane do CLI. `output`
przepisuje strumieniowane delty asystenta i sparsowany tekst końcowy, zanim OpenClaw obsłuży
własne znaczniki sterujące i dostarczenie kanałowe.
Dla CLI, które emitują JSONL zgodny ze stream-json Claude Code, ustaw
Dla CLI, które emitują JSONL zgodny z Claude Code stream-json, ustaw
`jsonlDialect: "claude-stream-json"` w konfiguracji tego backendu.
## Nakładki Bundle MCP
## Nakładki MCP dla bundle
Backendy CLI **nie** otrzymują bezpośrednio wywołań narzędzi OpenClaw, ale backend może
włączyć wygenerowaną nakładkę konfiguracji MCP przez `bundleMcp: true`.
włączyć generowaną nakładkę konfiguracji MCP przez `bundleMcp: true`.
Bieżące dołączone zachowanie:
Obecne zachowanie dla dołączonych backendów:
- `claude-cli`: wygenerowany ścisły plik konfiguracji MCP
- `codex-cli`: inline nadpisania konfiguracji dla `mcp_servers`
- `codex-cli`: wbudowane nadpisania konfiguracji dla `mcp_servers`
- `google-gemini-cli`: wygenerowany plik ustawień systemowych Gemini
Gdy bundle MCP jest włączone, OpenClaw:
- uruchamia serwer HTTP MCP local loopback, który udostępnia narzędzia Gateway procesowi CLI
- uwierzytelnia most tokenem na sesję (`OPENCLAW_MCP_TOKEN`)
- uruchamia serwer HTTP MCP local loopback, który udostępnia narzędzia gateway procesowi CLI
- uwierzytelnia most przy użyciu tokenu na sesję (`OPENCLAW_MCP_TOKEN`)
- ogranicza dostęp do narzędzi do bieżącej sesji, konta i kontekstu kanału
- wczytuje włączone serwery bundle-MCP dla bieżącego workspace
- scala je z dowolnym istniejącym kształtem konfiguracji / ustawień MCP backendu
- przepisuje konfigurację uruchamiania przy użyciu należącego do backendu trybu integracji z rozszerzenia będącego właścicielem
- ładuje włączone serwery bundle-MCP dla bieżącego workspace
- scala je z dowolnym istniejącym kształtem konfiguracji/ustawień MCP backendu
- przepisuje konfigurację uruchomieniową przy użyciu trybu integracji należącego do backendu z rozszerzenia będącego jego właścicielem
Jeśli żaden serwer MCP nie jest włączony, OpenClaw nadal wstrzykuje ścisłą konfigurację, gdy
backend włącza bundle MCP, aby uruchomienia w tle pozostawały izolowane.
Jeśli żadne serwery MCP nie są włączone, OpenClaw nadal wstrzykuje ścisłą konfigurację, gdy
backend włącza bundle MCP, aby uruchomienia w tle pozostały odizolowane.
## Ograniczenia
- **Brak bezpośrednich wywołań narzędzi OpenClaw.** OpenClaw nie wstrzykuje wywołań narzędzi do
protokołu backendu CLI. Backendy widzą narzędzia Gateway tylko wtedy, gdy włączą
protokołu backendu CLI. Backendy widzą narzędzia gateway tylko wtedy, gdy włączą
`bundleMcp: true`.
- **Strumieniowanie jest specyficzne dla backendu.** Niektóre backendy strumieniują JSONL; inne buforują
aż do zakończenia.
- **Ustrukturyzowane wyjścia** zależą od formatu JSON CLI.
- **Sesje Codex CLI** są wznawiane przez wyjście tekstowe (bez JSONL), które jest mniej
do zakończenia.
- **Wyjścia strukturalne** zależą od formatu JSON danego CLI.
- **Sesje Codex CLI** są wznawiane przez dane wyjściowe tekstowe (bez JSONL), co jest mniej
ustrukturyzowane niż początkowe uruchomienie `--json`. Sesje OpenClaw nadal działają
normalnie.
@ -347,6 +361,6 @@ backend włącza bundle MCP, aby uruchomienia w tle pozostawały izolowane.
- **Nie znaleziono CLI**: ustaw `command` na pełną ścieżkę.
- **Nieprawidłowa nazwa modelu**: użyj `modelAliases`, aby mapować `provider/model` → model CLI.
- **Brak ciągłości sesji**: upewnij się, że ustawiono `sessionArg`, a `sessionMode` nie ma
wartości `none` (Codex CLI obecnie nie potrafi wznawiać z wyjściem JSON).
- **Brak ciągłości sesji**: upewnij się, że `sessionArg` jest ustawione, a `sessionMode` nie ma wartości
`none` (Codex CLI obecnie nie potrafi wznawiać z wyjściem JSON).
- **Obrazy są ignorowane**: ustaw `imageArg` (i sprawdź, czy CLI obsługuje ścieżki do plików).

974
docs/pl/help/testing.md
View File

File diff suppressed because it is too large Load Diff