diff --git a/docs/pl/concepts/model-providers.md b/docs/pl/concepts/model-providers.md index 3ae511728..029e5249b 100644 --- a/docs/pl/concepts/model-providers.md +++ b/docs/pl/concepts/model-providers.md @@ -1,41 +1,42 @@ --- read_when: - - Potrzebujesz referencyjnego przewodnika konfiguracji modeli dla każdego dostawcy. - - Chcesz przykładowe konfiguracje lub polecenia wdrażania CLI dla dostawców modeli. -summary: Przegląd dostawców modeli z przykładowymi konfiguracjami + przepływami CLI + - Potrzebujesz dokumentacji konfiguracji modeli dla każdego dostawcy z osobna + - Chcesz przykładowych konfiguracji lub poleceń wdrażania w CLI dla dostawców modeli +summary: Przegląd dostawcy modeli z przykładowymi konfiguracjami + przepływami CLI title: Dostawcy modeli x-i18n: - generated_at: "2026-04-11T02:44:26Z" + generated_at: "2026-04-13T08:50:47Z" model: gpt-5.4 provider: openai - source_hash: 910ea7895e74c03910757d9d3e02825754b779b204eca7275b28422647ed0151 + source_hash: 66ba688c4b4366eec07667571e835d4cfeee684896e2ffae11d601b5fa0a4b98 source_path: concepts/model-providers.md workflow: 15 --- # Dostawcy modeli -Ta strona obejmuje **dostawców LLM/modeli** (a nie kanały czatu, takie jak WhatsApp/Telegram). -Zasady wyboru modeli znajdziesz w [/concepts/models](/pl/concepts/models). +Ta strona dotyczy **dostawców LLM/modeli** (a nie kanałów czatu, takich jak WhatsApp/Telegram). +Reguły wyboru modeli znajdziesz tutaj: [/concepts/models](/pl/concepts/models). ## Szybkie zasady - Referencje modeli używają formatu `provider/model` (przykład: `opencode/claude-opus-4-6`). - Jeśli ustawisz `agents.defaults.models`, stanie się to listą dozwolonych modeli. - Pomocnicze polecenia CLI: `openclaw onboard`, `openclaw models list`, `openclaw models set `. -- Zasady działania środowiska wykonawczego fallback, sondy cooldown oraz trwałość nadpisywania sesji - są udokumentowane w [/concepts/model-failover](/pl/concepts/model-failover). +- Zasady awaryjnego działania w runtime, sondy cooldown oraz trwałość nadpisań sesji są + udokumentowane w [/concepts/model-failover](/pl/concepts/model-failover). - `models.providers.*.models[].contextWindow` to natywne metadane modelu; - `models.providers.*.models[].contextTokens` to efektywny limit środowiska wykonawczego. -- Pluginy dostawców mogą wstrzykiwać katalogi modeli przez `registerProvider({ catalog })`; - OpenClaw scala te dane z `models.providers` przed zapisaniem + `models.providers.*.models[].contextTokens` to skuteczny limit runtime. +- Provider plugins mogą wstrzykiwać katalogi modeli przez `registerProvider({ catalog })`; + OpenClaw scala to wyjście z `models.providers` przed zapisaniem `models.json`. - Manifesty dostawców mogą deklarować `providerAuthEnvVars` oraz - `providerAuthAliases`, dzięki czemu ogólne sondy uwierzytelniania oparte na zmiennych środowiskowych i warianty dostawców - nie muszą ładować środowiska wykonawczego pluginu. Pozostała podstawowa mapa zmiennych środowiskowych - służy teraz tylko dostawcom spoza pluginów / podstawowym dostawcom oraz kilku przypadkom ogólnego priorytetu, - takim jak wdrażanie Anthropic z kluczem API jako pierwszym wyborem. -- Pluginy dostawców mogą także zarządzać zachowaniem dostawcy w środowisku wykonawczym przez + `providerAuthAliases`, aby ogólne sondy uwierzytelniania oparte na zmiennych środowiskowych i warianty dostawców + nie musiały ładować runtime Plugin. + Pozostała mapa zmiennych środowiskowych w rdzeniu służy teraz + wyłącznie dostawcom spoza pluginów/rdzenia oraz kilku przypadkom ogólnego priorytetu, takim + jak wdrażanie Anthropic z priorytetem klucza API. +- Provider plugins mogą też zarządzać zachowaniem dostawcy w runtime przez `normalizeModelId`, `normalizeTransport`, `normalizeConfig`, `applyNativeStreamingUsageCompat`, `resolveConfigApiKey`, `resolveSyntheticAuth`, `shouldDeferSyntheticProfileAuth`, @@ -51,183 +52,183 @@ Zasady wyboru modeli znajdziesz w [/concepts/models](/pl/concepts/models). `isCacheTtlEligible`, `buildMissingAuthMessage`, `suppressBuiltInModel`, `augmentModelCatalog`, `isBinaryThinking`, `supportsXHighThinking`, `resolveDefaultThinkingLevel`, `applyConfigDefaults`, `isModernModelRef`, - `prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot` oraz + `prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot`, oraz `onModelSelected`. -- Uwaga: `capabilities` dostawcy w środowisku wykonawczym to współdzielone metadane runnera (rodzina dostawcy, - niuanse transkrypcji/narzędzi, wskazówki dotyczące transportu/pamięci podręcznej). To nie to - samo co [publiczny model możliwości](/pl/plugins/architecture#public-capability-model), - który opisuje, co rejestruje plugin (wnioskowanie tekstowe, mowa itd.). +- Uwaga: `capabilities` dostawcy w runtime to współdzielone metadane wykonawcze (rodzina dostawcy, + specyfika transkryptu/narzędzi, wskazówki dotyczące transportu/cache). To nie to samo co [publiczny model możliwości](/pl/plugins/architecture#public-capability-model), + który opisuje, co rejestruje Plugin (wnioskowanie tekstowe, mowa itd.). - Dołączony dostawca `codex` jest sparowany z dołączoną uprzężą agenta Codex. - Użyj `codex/gpt-*`, gdy chcesz korzystać z logowania zarządzanego przez Codex, wykrywania modeli, + Używaj `codex/gpt-*`, gdy chcesz korzystać z logowania zarządzanego przez Codex, wykrywania modeli, natywnego wznawiania wątków i wykonywania na serwerze aplikacji. Zwykłe referencje `openai/gpt-*` nadal używają dostawcy OpenAI i standardowego transportu dostawcy OpenClaw. - Wdrożenia tylko z Codex mogą wyłączyć automatyczny fallback PI przez + Wdrożenia wyłącznie z Codex mogą wyłączyć automatyczny fallback do PI przez `agents.defaults.embeddedHarness.fallback: "none"`; zobacz [Codex Harness](/pl/plugins/codex-harness). -## Zachowanie dostawcy zarządzane przez plugin +## Zachowanie dostawcy zarządzane przez Plugin -Pluginy dostawców mogą teraz zarządzać większością logiki specyficznej dla dostawcy, podczas gdy OpenClaw zachowuje +Provider plugins mogą teraz zarządzać większością logiki specyficznej dla dostawcy, podczas gdy OpenClaw zachowuje ogólną pętlę wnioskowania. Typowy podział: -- `auth[].run` / `auth[].runNonInteractive`: dostawca zarządza przepływami wdrażania/logowania - dla `openclaw onboard`, `openclaw models auth` i konfiguracji bez interakcji +- `auth[].run` / `auth[].runNonInteractive`: dostawca zarządza przepływami onboarding/logowania + dla `openclaw onboard`, `openclaw models auth` i konfiguracji bezobsługowej - `wizard.setup` / `wizard.modelPicker`: dostawca zarządza etykietami wyboru uwierzytelniania, - starszymi aliasami, wskazówkami listy dozwolonych modeli podczas wdrażania oraz wpisami konfiguracji w selektorach wdrażania/modeli + starszymi aliasami, wskazówkami listy dozwolonych modeli dla onboardingu oraz wpisami konfiguracji w selektorach onboardingu/modeli - `catalog`: dostawca pojawia się w `models.providers` - `normalizeModelId`: dostawca normalizuje starsze/poglądowe identyfikatory modeli przed - wyszukiwaniem lub kanonizacją + wyszukiwaniem lub kanonikalizacją - `normalizeTransport`: dostawca normalizuje `api` / `baseUrl` rodziny transportu przed ogólnym składaniem modelu; OpenClaw najpierw sprawdza dopasowanego dostawcę, - a następnie inne pluginy dostawców obsługujące hooki, dopóki któryś rzeczywiście nie zmieni - transportu -- `normalizeConfig`: dostawca normalizuje konfigurację `models.providers.` zanim - użyje jej środowisko wykonawcze; OpenClaw najpierw sprawdza dopasowanego dostawcę, a następnie inne - pluginy dostawców obsługujące hooki, dopóki któryś rzeczywiście nie zmieni konfiguracji. Jeśli żaden - hook dostawcy nie przepisze konfiguracji, dołączone helpery rodziny Google nadal + następnie inne provider plugins obsługujące hooki, aż któryś faktycznie zmieni + transport +- `normalizeConfig`: dostawca normalizuje konfigurację `models.providers.` przed + użyciem jej przez runtime; OpenClaw najpierw sprawdza dopasowanego dostawcę, a potem inne + provider plugins obsługujące hooki, aż któryś faktycznie zmieni konfigurację. Jeśli żaden + hook dostawcy nie przepisze konfiguracji, dołączone pomocnicze funkcje rodziny Google nadal normalizują obsługiwane wpisy dostawców Google. -- `applyNativeStreamingUsageCompat`: dostawca stosuje przepisania zgodności natywnego użycia streamingu oparte na endpointach dla dostawców konfiguracyjnych -- `resolveConfigApiKey`: dostawca rozwiązuje uwierzytelnianie znacznika środowiskowego dla dostawców konfiguracyjnych - bez wymuszania pełnego ładowania uwierzytelniania środowiska wykonawczego. `amazon-bedrock` ma tu również - wbudowany resolver znacznika środowiskowego AWS, mimo że uwierzytelnianie środowiska wykonawczego Bedrock używa +- `applyNativeStreamingUsageCompat`: dostawca stosuje zgodnościowe przepisania natywnego użycia streamingu sterowane przez endpoint dla dostawców konfiguracyjnych +- `resolveConfigApiKey`: dostawca rozwiązuje uwierzytelnianie znacznikami środowiskowymi dla dostawców konfiguracyjnych + bez wymuszania pełnego ładowania uwierzytelniania runtime. `amazon-bedrock` ma tu również + wbudowany mechanizm rozwiązywania znaczników środowiskowych AWS, mimo że uwierzytelnianie Bedrock w runtime używa domyślnego łańcucha AWS SDK. -- `resolveSyntheticAuth`: dostawca może udostępniać dostępność uwierzytelniania lokalnego/samohostowanego lub innego +- `resolveSyntheticAuth`: dostawca może ujawniać dostępność uwierzytelniania lokalnego/self-hosted lub innego opartego na konfiguracji bez utrwalania sekretów w postaci jawnego tekstu -- `shouldDeferSyntheticProfileAuth`: dostawca może oznaczać zapisane syntetyczne placeholdery profilu +- `shouldDeferSyntheticProfileAuth`: dostawca może oznaczać zapisane syntetyczne placeholdery profili jako mające niższy priorytet niż uwierzytelnianie oparte na środowisku/konfiguracji -- `resolveDynamicModel`: dostawca akceptuje identyfikatory modeli, których nie ma jeszcze - w lokalnym katalogu statycznym +- `resolveDynamicModel`: dostawca akceptuje identyfikatory modeli, które nie są jeszcze obecne w lokalnym + statycznym katalogu - `prepareDynamicModel`: dostawca wymaga odświeżenia metadanych przed ponowną próbą dynamicznego rozpoznania -- `normalizeResolvedModel`: dostawca wymaga przepisania transportu lub bazowego URL -- `contributeResolvedModelCompat`: dostawca dodaje flagi zgodności dla swoich - modeli producenta, nawet gdy docierają one przez inny zgodny transport -- `capabilities`: dostawca publikuje niuanse transkrypcji/narzędzi/rodziny dostawcy -- `normalizeToolSchemas`: dostawca porządkuje schematy narzędzi, zanim zobaczy je - osadzony runner -- `inspectToolSchemas`: dostawca ujawnia ostrzeżenia dotyczące schematów specyficzne dla transportu +- `normalizeResolvedModel`: dostawca wymaga przepisania transportu lub podstawowego URL +- `contributeResolvedModelCompat`: dostawca wnosi flagi zgodności dla swoich + modeli dostawcy, nawet gdy docierają one przez inny kompatybilny transport +- `capabilities`: dostawca publikuje specyfikę transkryptu/narzędzi/rodziny dostawcy +- `normalizeToolSchemas`: dostawca czyści schematy narzędzi, zanim zobaczy je osadzony + runner +- `inspectToolSchemas`: dostawca udostępnia ostrzeżenia dotyczące schematów specyficzne dla transportu po normalizacji -- `resolveReasoningOutputMode`: dostawca wybiera natywne lub tagowane +- `resolveReasoningOutputMode`: dostawca wybiera natywne lub oznaczane tagami kontrakty wyjścia rozumowania -- `prepareExtraParams`: dostawca ustawia wartości domyślne lub normalizuje parametry żądań dla poszczególnych modeli -- `createStreamFn`: dostawca zastępuje zwykłą ścieżkę streamingu całkowicie +- `prepareExtraParams`: dostawca ustawia wartości domyślne lub normalizuje parametry żądania dla poszczególnych modeli +- `createStreamFn`: dostawca zastępuje standardową ścieżkę strumieniowania całkowicie niestandardowym transportem -- `wrapStreamFn`: dostawca stosuje wrapery zgodności nagłówków/treści żądania/modelu -- `resolveTransportTurnState`: dostawca dostarcza natywne nagłówki transportu - lub metadane dla poszczególnych tur +- `wrapStreamFn`: dostawca stosuje opakowania zgodności nagłówków/ciała/modelu żądania +- `resolveTransportTurnState`: dostawca dostarcza natywne nagłówki lub metadane transportu + dla każdej tury - `resolveWebSocketSessionPolicy`: dostawca dostarcza natywne nagłówki sesji WebSocket lub zasady cooldown sesji -- `createEmbeddingProvider`: dostawca zarządza zachowaniem embeddingów pamięci, gdy - należy ono do pluginu dostawcy, a nie do podstawowego przełącznika embeddingów +- `createEmbeddingProvider`: dostawca zarządza zachowaniem osadzeń pamięci, gdy + powinno ono należeć do Plugin dostawcy zamiast do głównego przełącznika osadzeń rdzenia - `formatApiKey`: dostawca formatuje zapisane profile uwierzytelniania do postaci - ciągu `apiKey` oczekiwanego przez transport w środowisku wykonawczym + ciągu `apiKey` oczekiwanego przez transport w runtime - `refreshOAuth`: dostawca zarządza odświeżaniem OAuth, gdy współdzielone mechanizmy odświeżania `pi-ai` nie są wystarczające -- `buildAuthDoctorHint`: dostawca dołącza wskazówki naprawy, gdy odświeżanie OAuth +- `buildAuthDoctorHint`: dostawca dodaje wskazówki naprawcze, gdy odświeżenie OAuth się nie powiedzie -- `matchesContextOverflowError`: dostawca rozpoznaje błędy przepełnienia okna kontekstu - specyficzne dla dostawcy, które ogólne heurystyki mogłyby pominąć +- `matchesContextOverflowError`: dostawca rozpoznaje specyficzne dla dostawcy + błędy przepełnienia okna kontekstu, których ogólne heurystyki by nie wykryły - `classifyFailoverReason`: dostawca mapuje surowe błędy transportu/API specyficzne dla dostawcy - na przyczyny przełączenia awaryjnego, takie jak limit szybkości lub przeciążenie -- `isCacheTtlEligible`: dostawca decyduje, które nadrzędne identyfikatory modeli obsługują TTL pamięci podręcznej promptów + na powody przełączenia awaryjnego, takie jak limit szybkości lub przeciążenie +- `isCacheTtlEligible`: dostawca decyduje, które nadrzędne identyfikatory modeli obsługują TTL cache promptów - `buildMissingAuthMessage`: dostawca zastępuje ogólny błąd magazynu uwierzytelniania wskazówką odzyskiwania specyficzną dla dostawcy -- `suppressBuiltInModel`: dostawca ukrywa nieaktualne wiersze nadrzędne i może zwrócić - błąd zarządzany przez producenta przy bezpośrednich niepowodzeniach rozpoznania -- `augmentModelCatalog`: dostawca dołącza syntetyczne/końcowe wiersze katalogu po +- `suppressBuiltInModel`: dostawca ukrywa nieaktualne wiersze upstream i może zwracać + błąd zarządzany przez dostawcę przy bezpośrednich niepowodzeniach rozpoznania +- `augmentModelCatalog`: dostawca dopisuje syntetyczne/końcowe wiersze katalogu po wykryciu i scaleniu konfiguracji -- `isBinaryThinking`: dostawca zarządza UX binarnego włączania/wyłączania myślenia +- `isBinaryThinking`: dostawca zarządza binarnym UX myślenia włącz/wyłącz - `supportsXHighThinking`: dostawca włącza `xhigh` dla wybranych modeli - `resolveDefaultThinkingLevel`: dostawca zarządza domyślną polityką `/think` dla rodziny modeli - `applyConfigDefaults`: dostawca stosuje globalne wartości domyślne specyficzne dla dostawcy podczas materializacji konfiguracji na podstawie trybu uwierzytelniania, środowiska lub rodziny modeli -- `isModernModelRef`: dostawca zarządza dopasowaniem preferowanego modelu live/smoke -- `prepareRuntimeAuth`: dostawca przekształca skonfigurowane poświadczenie w krótkożyjący - token środowiska wykonawczego -- `resolveUsageAuth`: dostawca rozwiązuje poświadczenia użycia/limitów dla `/usage` - i powiązanych powierzchni statusu/raportowania -- `fetchUsageSnapshot`: dostawca zarządza pobieraniem/parsowaniem endpointu użycia, podczas gdy - podstawowy system nadal zarządza powłoką podsumowania i formatowaniem -- `onModelSelected`: dostawca uruchamia efekty uboczne po wyborze modelu, takie jak - telemetria lub księgowanie sesji zarządzane przez dostawcę +- `isModernModelRef`: dostawca zarządza dopasowaniem preferowanych modeli dla testów live/smoke +- `prepareRuntimeAuth`: dostawca przekształca skonfigurowane poświadczenie w krótkotrwały + token runtime +- `resolveUsageAuth`: dostawca rozwiązuje poświadczenia użycia/limitu dla `/usage` + oraz powiązanych powierzchni statusu/raportowania +- `fetchUsageSnapshot`: dostawca zarządza pobieraniem/parsingiem endpointu użycia, podczas gdy + rdzeń nadal zarządza powłoką podsumowania i formatowaniem +- `onModelSelected`: dostawca wykonuje działania uboczne po wyborze modelu, takie jak + telemetria lub zarządzane przez dostawcę prowadzenie księgowości sesji -Obecne dołączone przykłady: +Aktualne dołączone przykłady: -- `anthropic`: fallback zgodności w przód dla Claude 4.6, wskazówki naprawy uwierzytelniania, pobieranie - endpointu użycia, metadane TTL pamięci podręcznej/rodziny dostawcy oraz globalne - wartości domyślne konfiguracji zależne od uwierzytelniania -- `amazon-bedrock`: zarządzane przez dostawcę dopasowanie przepełnienia kontekstu oraz klasyfikacja - przyczyn przełączenia awaryjnego dla specyficznych dla Bedrock błędów throttlingu / not-ready, a także - współdzielona rodzina odtwarzania `anthropic-by-model` dla osłon zasad odtwarzania - tylko dla Claude w ruchu Anthropic -- `anthropic-vertex`: osłony zasad odtwarzania tylko dla Claude w ruchu +- `anthropic`: fallback zgodności do przodu dla Claude 4.6, wskazówki naprawy uwierzytelniania, pobieranie + endpointu użycia, metadane cache-TTL/rodziny dostawcy oraz globalne + domyślne ustawienia konfiguracji zależne od uwierzytelniania +- `amazon-bedrock`: zarządzane przez dostawcę dopasowywanie przepełnienia kontekstu i klasyfikacja + powodów failover dla błędów throttlingu/not-ready specyficznych dla Bedrock, a także + współdzielona rodzina odtwarzania `anthropic-by-model` dla ochrony polityki odtwarzania + tylko dla Claude na ruchu Anthropic +- `anthropic-vertex`: zabezpieczenia polityki odtwarzania tylko dla Claude na ruchu `anthropic-message` -- `openrouter`: przekazywane identyfikatory modeli, wrapery żądań, wskazówki dotyczące możliwości dostawcy, - sanityzacja podpisu myśli Gemini w ruchu proxy Gemini, wstrzykiwanie - rozumowania proxy przez rodzinę streamingu `openrouter-thinking`, przekazywanie - metadanych routingu oraz polityka TTL pamięci podręcznej -- `github-copilot`: wdrażanie/logowanie urządzenia, fallback modeli zgodny w przód, - wskazówki transkryptu Claude-thinking, wymiana tokenów środowiska wykonawczego oraz pobieranie endpointu użycia -- `openai`: fallback zgodności w przód dla GPT-5.4, bezpośrednia normalizacja - transportu OpenAI, wskazówki brakującego uwierzytelniania świadome Codex, wyciszanie Spark, syntetyczne - wiersze katalogu OpenAI/Codex, polityka myślenia/modeli live, normalizacja aliasów tokenów użycia +- `openrouter`: identyfikatory modeli pass-through, opakowania żądań, wskazówki dotyczące możliwości dostawcy, + sanityzacja sygnatur myśli Gemini na proxy ruchu Gemini, wstrzykiwanie rozumowania przez proxy + przez rodzinę strumieni `openrouter-thinking`, przekazywanie metadanych routingu + oraz polityka cache-TTL +- `github-copilot`: onboarding/logowanie urządzenia, fallback zgodności do przodu modeli, + wskazówki transkryptu Claude-thinking, wymiana tokenu runtime oraz pobieranie endpointu + użycia +- `openai`: fallback zgodności do przodu dla GPT-5.4, bezpośrednia normalizacja + transportu OpenAI, wskazówki brakującego uwierzytelniania uwzględniające Codex, wyciszenie Spark, syntetyczne + wiersze katalogu OpenAI/Codex, polityka thinking/live-model, normalizacja aliasów tokenów użycia (`input` / `output` oraz rodziny `prompt` / `completion`), współdzielona - rodzina streamingu `openai-responses-defaults` dla natywnych wrapperów OpenAI/Codex, + rodzina strumieni `openai-responses-defaults` dla natywnych opakowań OpenAI/Codex, metadane rodziny dostawcy, rejestracja dołączonego dostawcy generowania obrazów dla `gpt-image-1` oraz rejestracja dołączonego dostawcy generowania wideo dla `sora-2` -- `google` i `google-gemini-cli`: fallback zgodności w przód dla Gemini 3.1, - natywna walidacja odtwarzania Gemini, sanityzacja odtwarzania bootstrap, tagowany - tryb wyjścia rozumowania, dopasowanie nowoczesnych modeli, rejestracja dołączonego dostawcy generowania obrazów +- `google` i `google-gemini-cli`: fallback zgodności do przodu dla Gemini 3.1, + natywna walidacja odtwarzania Gemini, sanityzacja odtwarzania bootstrap, + tryb wyjścia rozumowania oznaczanego tagami, dopasowanie nowoczesnych modeli, rejestracja dołączonego dostawcy generowania obrazów dla modeli Gemini image-preview oraz dołączona - rejestracja dostawcy generowania wideo dla modeli Veo; Gemini CLI OAuth również - zarządza formatowaniem tokenów profilu uwierzytelniania, analizą tokenów użycia i pobieraniem - endpointu limitów dla powierzchni użycia -- `moonshot`: współdzielony transport, zarządzana przez plugin normalizacja ładunku myślenia -- `kilocode`: współdzielony transport, zarządzane przez plugin nagłówki żądań, normalizacja - ładunku rozumowania, sanityzacja podpisu myśli proxy Gemini oraz polityka TTL pamięci podręcznej -- `zai`: fallback zgodności w przód dla GLM-5, wartości domyślne `tool_stream`, polityka TTL pamięci podręcznej, - polityka myślenia binarnego/modeli live oraz uwierzytelnianie użycia + pobieranie limitów; + rejestracja dostawcy generowania wideo dla modeli Veo; OAuth Gemini CLI zarządza też + formatowaniem tokenów profilu uwierzytelniania, parsowaniem tokenów użycia oraz pobieraniem endpointu limitów + dla powierzchni użycia +- `moonshot`: współdzielony transport, zarządzana przez Plugin normalizacja payloadu thinking +- `kilocode`: współdzielony transport, zarządzane przez Plugin nagłówki żądań, normalizacja payloadu rozumowania, + sanityzacja sygnatur myśli proxy-Gemini oraz polityka cache-TTL +- `zai`: fallback zgodności do przodu dla GLM-5, domyślne `tool_stream`, polityka cache-TTL, + polityka binary-thinking/live-model oraz uwierzytelnianie użycia + pobieranie limitów; nieznane identyfikatory `glm-5*` są syntetyzowane z dołączonego szablonu `glm-4.7` -- `xai`: natywna normalizacja transportu Responses, przepisywanie aliasów `/fast` dla - szybkich wariantów Grok, domyślne `tool_stream`, czyszczenie schematu narzędzi / - ładunku rozumowania specyficzne dla xAI oraz dołączona rejestracja dostawcy generowania wideo +- `xai`: natywna normalizacja transportu Responses, przepisania aliasów `/fast` dla + szybkich wariantów Grok, domyślne `tool_stream`, czyszczenie schematów narzędzi / payloadów rozumowania + specyficzne dla xAI oraz dołączona rejestracja dostawcy generowania wideo dla `grok-imagine-video` -- `mistral`: metadane możliwości zarządzane przez plugin -- `opencode` i `opencode-go`: metadane możliwości zarządzane przez plugin oraz - sanityzacja podpisu myśli proxy Gemini -- `alibaba`: zarządzany przez plugin katalog generowania wideo dla bezpośrednich referencji modeli Wan +- `mistral`: metadane możliwości zarządzane przez Plugin +- `opencode` i `opencode-go`: metadane możliwości zarządzane przez Plugin oraz + sanityzacja sygnatur myśli proxy-Gemini +- `alibaba`: zarządzany przez Plugin katalog generowania wideo dla bezpośrednich referencji modeli Wan takich jak `alibaba/wan2.6-t2v` -- `byteplus`: katalogi zarządzane przez plugin oraz dołączona rejestracja dostawcy generowania wideo +- `byteplus`: katalogi zarządzane przez Plugin oraz dołączona rejestracja dostawcy generowania wideo dla modeli Seedance text-to-video/image-to-video -- `fal`: dołączona rejestracja dostawcy generowania wideo dla hostowanych modeli zewnętrznych, - rejestracja dostawcy generowania obrazów dla modeli FLUX oraz dołączona - rejestracja dostawcy generowania wideo dla hostowanych modeli zewnętrznych +- `fal`: dołączona rejestracja dostawcy generowania wideo dla hostowanych zewnętrznych modeli + oraz rejestracja dostawcy generowania obrazów dla modeli obrazów FLUX, a także dołączona + rejestracja dostawcy generowania wideo dla hostowanych zewnętrznych modeli wideo - `cloudflare-ai-gateway`, `huggingface`, `kimi`, `nvidia`, `qianfan`, `stepfun`, `synthetic`, `venice`, `vercel-ai-gateway` i `volcengine`: - tylko katalogi zarządzane przez plugin -- `qwen`: katalogi zarządzane przez plugin dla modeli tekstowych oraz współdzielone - rejestracje dostawców media-understanding i generowania wideo dla jego powierzchni multimodalnych; - generowanie wideo Qwen używa standardowych endpointów wideo DashScope ze - dołączonymi modelami Wan, takimi jak `wan2.6-t2v` i `wan2.7-r2v` -- `runway`: rejestracja dostawcy generowania wideo zarządzana przez plugin dla natywnych - modeli opartych na zadaniach Runway, takich jak `gen4.5` -- `minimax`: katalogi zarządzane przez plugin, dołączona rejestracja dostawcy generowania wideo + wyłącznie katalogi zarządzane przez Plugin +- `qwen`: katalogi zarządzane przez Plugin dla modeli tekstowych oraz współdzielone + rejestracje dostawców rozumienia mediów i generowania wideo dla ich + multimodalnych powierzchni; generowanie wideo Qwen używa standardowych endpointów wideo DashScope + z dołączonymi modelami Wan, takimi jak `wan2.6-t2v` i `wan2.7-r2v` +- `runway`: zarządzana przez Plugin rejestracja dostawcy generowania wideo dla natywnych + modeli Runway opartych na zadaniach, takich jak `gen4.5` +- `minimax`: katalogi zarządzane przez Plugin, dołączona rejestracja dostawcy generowania wideo dla modeli wideo Hailuo, dołączona rejestracja dostawcy generowania obrazów - dla `image-01`, hybrydowy wybór zasad odtwarzania Anthropic/OpenAI oraz logika - uwierzytelniania/migawki użycia -- `together`: katalogi zarządzane przez plugin oraz dołączona rejestracja dostawcy generowania wideo + dla `image-01`, hybrydowy wybór polityki odtwarzania Anthropic/OpenAI + oraz logika uwierzytelniania/migawek użycia +- `together`: katalogi zarządzane przez Plugin oraz dołączona rejestracja dostawcy generowania wideo dla modeli wideo Wan -- `xiaomi`: katalogi zarządzane przez plugin oraz logika uwierzytelniania/migawki użycia +- `xiaomi`: katalogi zarządzane przez Plugin oraz logika uwierzytelniania/migawek użycia -Dołączony plugin `openai` zarządza teraz oboma identyfikatorami dostawców: `openai` i +Dołączony Plugin `openai` obsługuje teraz oba identyfikatory dostawców: `openai` i `openai-codex`. To obejmuje dostawców, którzy nadal mieszczą się w standardowych transportach OpenClaw. Dostawca, -który potrzebuje całkowicie niestandardowego wykonawcy żądań, jest osobną, głębszą powierzchnią rozszerzeń. +który wymaga całkowicie niestandardowego wykonawcy żądań, to osobna, głębsza powierzchnia rozszerzeń. ## Rotacja kluczy API @@ -235,17 +236,16 @@ który potrzebuje całkowicie niestandardowego wykonawcy żądań, jest osobną, - Skonfiguruj wiele kluczy przez: - `OPENCLAW_LIVE__KEY` (pojedyncze nadpisanie live, najwyższy priorytet) - `_API_KEYS` (lista rozdzielana przecinkami lub średnikami) - - `_API_KEY` (klucz podstawowy) + - `_API_KEY` (klucz główny) - `_API_KEY_*` (lista numerowana, np. `_API_KEY_1`) -- Dla dostawców Google `GOOGLE_API_KEY` jest również uwzględniany jako fallback. +- Dla dostawców Google jako fallback uwzględniany jest także `GOOGLE_API_KEY`. - Kolejność wyboru kluczy zachowuje priorytet i usuwa duplikaty wartości. -- Żądania są ponawiane z następnym kluczem tylko przy odpowiedziach o przekroczeniu limitu szybkości (na +- Żądania są ponawiane z następnym kluczem tylko przy odpowiedziach z limitem szybkości (na przykład `429`, `rate_limit`, `quota`, `resource exhausted`, `Too many concurrent requests`, `ThrottlingException`, `concurrency limit reached`, - `workers_ai ... quota limit exceeded` lub okresowych komunikatach o limicie użycia). -- Błędy inne niż związane z limitem szybkości kończą się natychmiastowym niepowodzeniem; nie jest podejmowana - próba rotacji klucza. -- Gdy wszystkie kandydackie klucze zawiodą, zwracany jest końcowy błąd z ostatniej próby. + `workers_ai ... quota limit exceeded` lub okresowe komunikaty o limicie użycia). +- Błędy inne niż związane z limitem szybkości kończą się od razu niepowodzeniem; rotacja kluczy nie jest podejmowana. +- Gdy wszystkie klucze kandydackie zawiodą, zwracany jest końcowy błąd z ostatniej próby. ## Wbudowani dostawcy (katalog pi-ai) @@ -256,21 +256,21 @@ konfiguracji `models.providers`; wystarczy ustawić uwierzytelnianie i wybrać m - Dostawca: `openai` - Uwierzytelnianie: `OPENAI_API_KEY` -- Opcjonalna rotacja: `OPENAI_API_KEYS`, `OPENAI_API_KEY_1`, `OPENAI_API_KEY_2` oraz `OPENCLAW_LIVE_OPENAI_KEY` (pojedyncze nadpisanie) +- Opcjonalna rotacja: `OPENAI_API_KEYS`, `OPENAI_API_KEY_1`, `OPENAI_API_KEY_2`, oraz `OPENCLAW_LIVE_OPENAI_KEY` (pojedyncze nadpisanie) - Przykładowe modele: `openai/gpt-5.4`, `openai/gpt-5.4-pro` - CLI: `openclaw onboard --auth-choice openai-api-key` - Domyślny transport to `auto` (najpierw WebSocket, fallback do SSE) -- Nadpisanie dla modelu przez `agents.defaults.models["openai/"].params.transport` (`"sse"`, `"websocket"` lub `"auto"`) -- Rozgrzewka OpenAI Responses WebSocket jest domyślnie włączona przez `params.openaiWsWarmup` (`true`/`false`) +- Nadpisanie dla konkretnego modelu przez `agents.defaults.models["openai/"].params.transport` (`"sse"`, `"websocket"` lub `"auto"`) +- Rozgrzewanie WebSocket OpenAI Responses jest domyślnie włączone przez `params.openaiWsWarmup` (`true`/`false`) - Priorytetowe przetwarzanie OpenAI można włączyć przez `agents.defaults.models["openai/"].params.serviceTier` -- `/fast` i `params.fastMode` mapują bezpośrednie żądania Responses `openai/*` na `service_tier=priority` w `api.openai.com` -- Użyj `params.serviceTier`, gdy chcesz jawnie ustawić poziom zamiast współdzielonego przełącznika `/fast` +- `/fast` oraz `params.fastMode` mapują bezpośrednie żądania Responses `openai/*` na `service_tier=priority` na `api.openai.com` +- Używaj `params.serviceTier`, gdy chcesz jawnego poziomu zamiast współdzielonego przełącznika `/fast` - Ukryte nagłówki atrybucji OpenClaw (`originator`, `version`, - `User-Agent`) mają zastosowanie tylko do natywnego ruchu OpenAI do `api.openai.com`, a nie + `User-Agent`) są stosowane tylko w natywnym ruchu OpenAI do `api.openai.com`, a nie do ogólnych proxy zgodnych z OpenAI -- Natywne trasy OpenAI zachowują także `store` dla Responses, wskazówki pamięci podręcznej promptów oraz - kształtowanie ładunku zgodności rozumowania OpenAI; trasy proxy tego nie robią -- `openai/gpt-5.3-codex-spark` jest celowo wyciszony w OpenClaw, ponieważ aktywne API OpenAI go odrzuca; Spark jest traktowany jako tylko Codex +- Natywne trasy OpenAI zachowują też `store` dla Responses, wskazówki cache promptów oraz + kształtowanie payloadu zgodności rozumowania OpenAI; trasy proxy tego nie robią +- `openai/gpt-5.3-codex-spark` jest celowo wyciszony w OpenClaw, ponieważ aktywne API OpenAI go odrzuca; Spark jest traktowany wyłącznie jako Codex ```json5 { @@ -282,12 +282,12 @@ konfiguracji `models.providers`; wystarczy ustawić uwierzytelnianie i wybrać m - Dostawca: `anthropic` - Uwierzytelnianie: `ANTHROPIC_API_KEY` -- Opcjonalna rotacja: `ANTHROPIC_API_KEYS`, `ANTHROPIC_API_KEY_1`, `ANTHROPIC_API_KEY_2` oraz `OPENCLAW_LIVE_ANTHROPIC_KEY` (pojedyncze nadpisanie) +- Opcjonalna rotacja: `ANTHROPIC_API_KEYS`, `ANTHROPIC_API_KEY_1`, `ANTHROPIC_API_KEY_2`, oraz `OPENCLAW_LIVE_ANTHROPIC_KEY` (pojedyncze nadpisanie) - Przykładowy model: `anthropic/claude-opus-4-6` - CLI: `openclaw onboard --auth-choice apiKey` -- Bezpośrednie publiczne żądania Anthropic obsługują również współdzielony przełącznik `/fast` i `params.fastMode`, w tym ruch uwierzytelniany kluczem API i OAuth wysyłany do `api.anthropic.com`; OpenClaw mapuje to na Anthropic `service_tier` (`auto` vs `standard_only`) -- Uwaga dotycząca Anthropic: pracownicy Anthropic powiedzieli nam, ż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 zatwierdzone dla tej integracji, chyba że Anthropic opublikuje nową politykę. -- Token konfiguracji Anthropic pozostaje dostępną, obsługiwaną ścieżką tokenu OpenClaw, ale OpenClaw teraz preferuje ponowne użycie Claude CLI i `claude -p`, gdy są dostępne. +- Bezpośrednie publiczne żądania Anthropic obsługują też współdzielony przełącznik `/fast` i `params.fastMode`, w tym ruch uwierzytelniany kluczem API i OAuth wysyłany do `api.anthropic.com`; OpenClaw mapuje to na Anthropic `service_tier` (`auto` vs `standard_only`) +- Uwaga Anthropic: pracownicy Anthropic przekazali nam, że użycie Claude CLI w stylu OpenClaw jest znów dozwolone, więc OpenClaw traktuje ponowne użycie Claude CLI i użycie `claude -p` jako zatwierdzone dla tej integracji, chyba że Anthropic opublikuje nową politykę. +- Token konfiguracji Anthropic pozostaje dostępny jako obsługiwana ścieżka tokenu OpenClaw, ale OpenClaw preferuje teraz ponowne użycie Claude CLI i `claude -p`, gdy są dostępne. ```json5 { @@ -302,15 +302,15 @@ konfiguracji `models.providers`; wystarczy ustawić uwierzytelnianie i wybrać m - Przykładowy model: `openai-codex/gpt-5.4` - CLI: `openclaw onboard --auth-choice openai-codex` lub `openclaw models auth login --provider openai-codex` - Domyślny transport to `auto` (najpierw WebSocket, fallback do SSE) -- Nadpisanie dla modelu przez `agents.defaults.models["openai-codex/"].params.transport` (`"sse"`, `"websocket"` lub `"auto"`) -- `params.serviceTier` jest również przekazywane w natywnych żądaniach Codex Responses (`chatgpt.com/backend-api`) +- Nadpisanie dla konkretnego modelu przez `agents.defaults.models["openai-codex/"].params.transport` (`"sse"`, `"websocket"` lub `"auto"`) +- `params.serviceTier` jest też przekazywane w natywnych żądaniach Codex Responses (`chatgpt.com/backend-api`) - Ukryte nagłówki atrybucji OpenClaw (`originator`, `version`, - `User-Agent`) są dołączane tylko do natywnego ruchu Codex do + `User-Agent`) są dołączane tylko w natywnym ruchu Codex do `chatgpt.com/backend-api`, a nie do ogólnych proxy zgodnych z OpenAI -- Współdzieli ten sam przełącznik `/fast` i konfigurację `params.fastMode`, co bezpośrednie `openai/*`; OpenClaw mapuje to na `service_tier=priority` +- Współdzieli ten sam przełącznik `/fast` i konfigurację `params.fastMode` co bezpośrednie `openai/*`; OpenClaw mapuje to na `service_tier=priority` - `openai-codex/gpt-5.3-codex-spark` pozostaje dostępny, gdy katalog OAuth Codex go udostępnia; zależne od uprawnień -- `openai-codex/gpt-5.4` zachowuje natywne `contextWindow = 1050000` i domyślne środowisko wykonawcze `contextTokens = 272000`; nadpisz limit środowiska wykonawczego przez `models.providers.openai-codex.models[].contextTokens` -- Uwaga dotycząca polityki: OAuth OpenAI Codex jest jawnie obsługiwany dla zewnętrznych narzędzi/przepływów pracy, takich jak OpenClaw. +- `openai-codex/gpt-5.4` zachowuje natywne `contextWindow = 1050000` oraz domyślne runtime `contextTokens = 272000`; nadpisz limit runtime przez `models.providers.openai-codex.models[].contextTokens` +- Uwaga dotycząca polityki: OAuth OpenAI Codex jest oficjalnie obsługiwany dla zewnętrznych narzędzi/przepływów pracy, takich jak OpenClaw. ```json5 { @@ -333,14 +333,14 @@ konfiguracji `models.providers`; wystarczy ustawić uwierzytelnianie i wybrać m ### Inne hostowane opcje w stylu subskrypcyjnym - [Qwen Cloud](/pl/providers/qwen): powierzchnia dostawcy Qwen Cloud oraz mapowanie endpointów Alibaba DashScope i Coding Plan -- [MiniMax](/pl/providers/minimax): dostęp MiniMax Coding Plan przez OAuth lub klucz API +- [MiniMax](/pl/providers/minimax): OAuth MiniMax Coding Plan lub dostęp przez klucz API - [GLM Models](/pl/providers/glm): Z.AI Coding Plan lub ogólne endpointy API ### OpenCode - Uwierzytelnianie: `OPENCODE_API_KEY` (lub `OPENCODE_ZEN_API_KEY`) -- Dostawca środowiska wykonawczego Zen: `opencode` -- Dostawca środowiska wykonawczego Go: `opencode-go` +- Dostawca runtime Zen: `opencode` +- Dostawca runtime Go: `opencode-go` - Przykładowe modele: `opencode/claude-opus-4-6`, `opencode-go/kimi-k2.5` - CLI: `openclaw onboard --auth-choice opencode-zen` lub `openclaw onboard --auth-choice opencode-go` @@ -358,26 +358,26 @@ konfiguracji `models.providers`; wystarczy ustawić uwierzytelnianie i wybrać m - Przykładowe modele: `google/gemini-3.1-pro-preview`, `google/gemini-3-flash-preview` - Zgodność: starsza konfiguracja OpenClaw używająca `google/gemini-3.1-flash-preview` jest normalizowana do `google/gemini-3-flash-preview` - CLI: `openclaw onboard --auth-choice gemini-api-key` -- Bezpośrednie uruchomienia Gemini akceptują także `agents.defaults.models["google/"].params.cachedContent` +- Bezpośrednie uruchomienia Gemini akceptują też `agents.defaults.models["google/"].params.cachedContent` (lub starsze `cached_content`) do przekazania natywnego dla dostawcy - uchwytu `cachedContents/...`; trafienia pamięci podręcznej Gemini są widoczne jako OpenClaw `cacheRead` + uchwytu `cachedContents/...`; trafienia cache Gemini są ujawniane jako OpenClaw `cacheRead` ### Google Vertex i Gemini CLI - Dostawcy: `google-vertex`, `google-gemini-cli` - Uwierzytelnianie: Vertex używa gcloud ADC; Gemini CLI używa własnego przepływu OAuth -- Uwaga: OAuth Gemini CLI w OpenClaw to nieoficjalna integracja. Niektórzy użytkownicy zgłaszali ograniczenia kont Google po użyciu klientów zewnętrznych. Przejrzyj warunki Google i użyj niekrytycznego konta, jeśli zdecydujesz się kontynuować. -- OAuth Gemini CLI jest dostarczany jako część dołączonego pluginu `google`. +- Uwaga: OAuth Gemini CLI w OpenClaw jest nieoficjalną integracją. Niektórzy użytkownicy zgłaszali ograniczenia kont Google po użyciu klientów zewnętrznych. Zapoznaj się z warunkami Google i użyj niekrytycznego konta, jeśli zdecydujesz się kontynuować. +- OAuth Gemini CLI jest dostarczany jako część dołączonego Plugin `google`. - Najpierw zainstaluj Gemini CLI: - `brew install gemini-cli` - lub `npm install -g @google/gemini-cli` - Włącz: `openclaw plugins enable google` - Zaloguj się: `openclaw models auth login --provider google-gemini-cli --set-default` - - Model domyślny: `google-gemini-cli/gemini-3-flash-preview` + - Domyślny model: `google-gemini-cli/gemini-3-flash-preview` - Uwaga: **nie** wklejasz identyfikatora klienta ani sekretu do `openclaw.json`. Przepływ logowania CLI zapisuje - tokeny w profilach uwierzytelniania na hoście bramy. - - Jeśli żądania kończą się niepowodzeniem po zalogowaniu, ustaw `GOOGLE_CLOUD_PROJECT` lub `GOOGLE_CLOUD_PROJECT_ID` na hoście bramy. - - Odpowiedzi JSON Gemini CLI są analizowane z `response`; użycie wraca awaryjnie do + tokeny w profilach uwierzytelniania na hoście Gateway. + - Jeśli żądania kończą się niepowodzeniem po zalogowaniu, ustaw `GOOGLE_CLOUD_PROJECT` lub `GOOGLE_CLOUD_PROJECT_ID` na hoście Gateway. + - Odpowiedzi JSON Gemini CLI są parsowane z `response`; użycie przechodzi awaryjnie do `stats`, a `stats.cached` jest normalizowane do OpenClaw `cacheRead`. ### Z.AI (GLM) @@ -403,36 +403,36 @@ konfiguracji `models.providers`; wystarczy ustawić uwierzytelnianie i wybrać m - Przykładowy model: `kilocode/kilo/auto` - CLI: `openclaw onboard --auth-choice kilocode-api-key` - Bazowy URL: `https://api.kilo.ai/api/gateway/` -- Statyczny katalog fallback jest dostarczany z `kilocode/kilo/auto`; aktywne - wykrywanie `https://api.kilo.ai/api/gateway/models` może dalej rozszerzyć katalog - środowiska wykonawczego. -- Dokładny routing nadrzędny stojący za `kilocode/kilo/auto` jest zarządzany przez Kilo Gateway, +- Statyczny katalog fallback zawiera `kilocode/kilo/auto`; aktywne + wykrywanie `https://api.kilo.ai/api/gateway/models` może dalej rozszerzać + katalog runtime. +- Dokładny routing upstream za `kilocode/kilo/auto` jest zarządzany przez Kilo Gateway, a nie zakodowany na sztywno w OpenClaw. Szczegóły konfiguracji znajdziesz w [/providers/kilocode](/pl/providers/kilocode). -### Inne dołączone pluginy dostawców +### Inne dołączone provider plugins - OpenRouter: `openrouter` (`OPENROUTER_API_KEY`) - Przykładowy model: `openrouter/auto` -- OpenClaw stosuje udokumentowane nagłówki atrybucji aplikacji OpenRouter tylko wtedy, gdy +- OpenClaw stosuje udokumentowane przez OpenRouter nagłówki atrybucji aplikacji tylko wtedy, gdy żądanie faktycznie trafia do `openrouter.ai` - Specyficzne dla OpenRouter znaczniki Anthropic `cache_control` są podobnie ograniczone do zweryfikowanych tras OpenRouter, a nie dowolnych adresów proxy -- OpenRouter pozostaje na ścieżce proxy w stylu zgodnym z OpenAI, więc natywne - formatowanie żądań tylko dla OpenAI (`serviceTier`, `store` dla Responses, - wskazówki pamięci podręcznej promptów, ładunki zgodności rozumowania OpenAI) nie jest przekazywane -- Referencje OpenRouter oparte na Gemini zachowują tylko ścieżkę sanityzacji podpisu myśli proxy Gemini; - natywna walidacja odtwarzania Gemini i przepisywanie bootstrap pozostają wyłączone +- OpenRouter pozostaje na ścieżce proxy w stylu kompatybilnym z OpenAI, więc natywne + kształtowanie żądań tylko dla OpenAI (`serviceTier`, `store` dla Responses, + wskazówki cache promptów, payloady zgodności rozumowania OpenAI) nie jest przekazywane +- Referencje OpenRouter oparte na Gemini zachowują tylko sanityzację sygnatur myśli proxy-Gemini; + natywna walidacja odtwarzania Gemini i przepisania bootstrap pozostają wyłączone - Kilo Gateway: `kilocode` (`KILOCODE_API_KEY`) - Przykładowy model: `kilocode/kilo/auto` -- Referencje Kilo oparte na Gemini zachowują tę samą ścieżkę sanityzacji podpisu myśli proxy Gemini; - `kilocode/kilo/auto` i inne wskazówki nieobsługujące rozumowania przez proxy +- Referencje Kilo oparte na Gemini zachowują tę samą ścieżkę sanityzacji sygnatur myśli + proxy-Gemini; `kilocode/kilo/auto` i inne wskazówki proxy bez obsługi rozumowania pomijają wstrzykiwanie rozumowania przez proxy - MiniMax: `minimax` (klucz API) i `minimax-portal` (OAuth) - Uwierzytelnianie: `MINIMAX_API_KEY` dla `minimax`; `MINIMAX_OAUTH_TOKEN` lub `MINIMAX_API_KEY` dla `minimax-portal` - Przykładowy model: `minimax/MiniMax-M2.7` lub `minimax-portal/MiniMax-M2.7` -- Konfiguracja wdrażania / klucza API MiniMax zapisuje jawne definicje modeli M2.7 z +- Onboarding MiniMax/konfiguracja klucza API zapisuje jawne definicje modeli M2.7 z `input: ["text", "image"]`; dołączony katalog dostawcy zachowuje referencje czatu jako tylko tekstowe, dopóki konfiguracja tego dostawcy nie zostanie zmaterializowana - Moonshot: `moonshot` (`MOONSHOT_API_KEY`) @@ -461,35 +461,35 @@ Szczegóły konfiguracji znajdziesz w [/providers/kilocode](/pl/providers/kiloco - Przykładowy model: `byteplus-plan/ark-code-latest` - xAI: `xai` (`XAI_API_KEY`) - Natywne dołączone żądania xAI używają ścieżki xAI Responses - - `/fast` lub `params.fastMode: true` przepisuje `grok-3`, `grok-3-mini`, + - `/fast` lub `params.fastMode: true` przepisują `grok-3`, `grok-3-mini`, `grok-4` i `grok-4-0709` na ich warianty `*-fast` - `tool_stream` jest domyślnie włączone; ustaw `agents.defaults.models["xai/"].params.tool_stream` na `false`, aby - je wyłączyć + to wyłączyć - Mistral: `mistral` (`MISTRAL_API_KEY`) - Przykładowy model: `mistral/mistral-large-latest` - CLI: `openclaw onboard --auth-choice mistral-api-key` - Groq: `groq` (`GROQ_API_KEY`) - Cerebras: `cerebras` (`CEREBRAS_API_KEY`) - Modele GLM w Cerebras używają identyfikatorów `zai-glm-4.7` i `zai-glm-4.6`. - - Bazowy URL zgodny z OpenAI: `https://api.cerebras.ai/v1`. + - Bazowy URL kompatybilny z OpenAI: `https://api.cerebras.ai/v1`. - GitHub Copilot: `github-copilot` (`COPILOT_GITHUB_TOKEN` / `GH_TOKEN` / `GITHUB_TOKEN`) - Przykładowy model Hugging Face Inference: `huggingface/deepseek-ai/DeepSeek-R1`; CLI: `openclaw onboard --auth-choice huggingface-api-key`. Zobacz [Hugging Face (Inference)](/pl/providers/huggingface). -## Dostawcy przez `models.providers` (własny / bazowy URL) +## Dostawcy przez `models.providers` (niestandardowy/bazowy URL) -Użyj `models.providers` (lub `models.json`), aby dodać **niestandardowych** dostawców lub -proxy zgodne z OpenAI/Anthropic. +Użyj `models.providers` (lub `models.json`), aby dodać **niestandardowych** dostawców albo +proxy kompatybilne z OpenAI/Anthropic. -Wiele z poniższych dołączonych pluginów dostawców publikuje już domyślny katalog. -Używaj jawnych wpisów `models.providers.` tylko wtedy, gdy chcesz zastąpić +Wiele z dołączonych poniżej provider plugins publikuje już domyślny katalog. +Używaj jawnych wpisów `models.providers.` tylko wtedy, gdy chcesz nadpisać domyślny bazowy URL, nagłówki lub listę modeli. ### Moonshot AI (Kimi) -Moonshot jest dostarczany jako dołączony plugin dostawcy. Domyślnie używaj wbudowanego dostawcy, +Moonshot jest dostarczany jako dołączony Plugin dostawcy. Domyślnie używaj wbudowanego dostawcy, a jawny wpis `models.providers.moonshot` dodawaj tylko wtedy, gdy -musisz zastąpić bazowy URL lub metadane modelu: +musisz nadpisać bazowy URL lub metadane modelu: - Dostawca: `moonshot` - Uwierzytelnianie: `MOONSHOT_API_KEY` @@ -528,7 +528,7 @@ Identyfikatory modeli Kimi K2: ### Kimi Coding -Kimi Coding używa endpointu Moonshot AI zgodnego z Anthropic: +Kimi Coding używa endpointu Anthropic-compatible od Moonshot AI: - Dostawca: `kimi` - Uwierzytelnianie: `KIMI_API_KEY` @@ -543,7 +543,7 @@ Kimi Coding używa endpointu Moonshot AI zgodnego z Anthropic: } ``` -Starszy identyfikator modelu zgodności `kimi/k2p5` nadal jest akceptowany. +Starsze `kimi/k2p5` pozostaje akceptowanym identyfikatorem modelu zgodności. ### Volcano Engine (Doubao) @@ -562,12 +562,12 @@ Volcano Engine (火山引擎) zapewnia dostęp do Doubao i innych modeli w China } ``` -Wdrażanie domyślnie używa powierzchni coding, ale ogólny katalog `volcengine/*` +Onboarding domyślnie używa powierzchni coding, ale ogólny katalog `volcengine/*` jest rejestrowany w tym samym czasie. -W selektorach modeli wdrażania/konfiguracji wybór uwierzytelniania Volcengine preferuje zarówno +W selektorach modeli onboarding/configure wybór uwierzytelniania Volcengine preferuje zarówno wiersze `volcengine/*`, jak i `volcengine-plan/*`. Jeśli te modele nie są jeszcze załadowane, -OpenClaw wraca do niefiltrowanego katalogu zamiast pokazywać pusty +OpenClaw przechodzi awaryjnie do niefiltrowanego katalogu zamiast pokazywać pusty selektor ograniczony do dostawcy. Dostępne modele: @@ -588,7 +588,7 @@ Modele coding (`volcengine-plan`): ### BytePlus (międzynarodowy) -BytePlus ARK zapewnia użytkownikom międzynarodowym dostęp do tych samych modeli co Volcano Engine. +BytePlus ARK zapewnia międzynarodowym użytkownikom dostęp do tych samych modeli co Volcano Engine. - Dostawca: `byteplus` (coding: `byteplus-plan`) - Uwierzytelnianie: `BYTEPLUS_API_KEY` @@ -603,12 +603,12 @@ BytePlus ARK zapewnia użytkownikom międzynarodowym dostęp do tych samych mode } ``` -Wdrażanie domyślnie używa powierzchni coding, ale ogólny katalog `byteplus/*` +Onboarding domyślnie używa powierzchni coding, ale ogólny katalog `byteplus/*` jest rejestrowany w tym samym czasie. -W selektorach modeli wdrażania/konfiguracji wybór uwierzytelniania BytePlus preferuje zarówno +W selektorach modeli onboarding/configure wybór uwierzytelniania BytePlus preferuje zarówno wiersze `byteplus/*`, jak i `byteplus-plan/*`. Jeśli te modele nie są jeszcze załadowane, -OpenClaw wraca do niefiltrowanego katalogu zamiast pokazywać pusty +OpenClaw przechodzi awaryjnie do niefiltrowanego katalogu zamiast pokazywać pusty selektor ograniczony do dostawcy. Dostępne modele: @@ -627,7 +627,7 @@ Modele coding (`byteplus-plan`): ### Synthetic -Synthetic udostępnia modele zgodne z Anthropic za dostawcą `synthetic`: +Synthetic udostępnia modele kompatybilne z Anthropic za dostawcą `synthetic`: - Dostawca: `synthetic` - Uwierzytelnianie: `SYNTHETIC_API_KEY` @@ -666,23 +666,45 @@ MiniMax jest konfigurowany przez `models.providers`, ponieważ używa niestandar Szczegóły konfiguracji, opcje modeli i fragmenty konfiguracji znajdziesz w [/providers/minimax](/pl/providers/minimax). -Na ścieżce streamingu MiniMax zgodnej z Anthropic OpenClaw domyślnie wyłącza myślenie, -chyba że jawnie je ustawisz, a `/fast on` przepisuje +Na ścieżce streamingu kompatybilnej z Anthropic w MiniMax OpenClaw domyślnie wyłącza thinking, +chyba że ustawisz je jawnie, a `/fast on` przepisuje `MiniMax-M2.7` na `MiniMax-M2.7-highspeed`. -Podział możliwości zarządzanych przez plugin: +Podział możliwości zarządzanych przez Plugin: -- Domyślne ustawienia tekstu/czatu pozostają na `minimax/MiniMax-M2.7` +- Domyślne ustawienia tekst/czat pozostają przy `minimax/MiniMax-M2.7` - Generowanie obrazów to `minimax/image-01` lub `minimax-portal/image-01` -- Rozumienie obrazów to zarządzany przez plugin `MiniMax-VL-01` na obu ścieżkach uwierzytelniania MiniMax +- Rozumienie obrazów to zarządzany przez Plugin `MiniMax-VL-01` w obu ścieżkach uwierzytelniania MiniMax - Wyszukiwanie w sieci pozostaje przy identyfikatorze dostawcy `minimax` +### LM Studio + +LM Studio jest dostarczane jako dołączony Plugin dostawcy, który używa natywnego API: + +- Dostawca: `lmstudio` +- Uwierzytelnianie: `LM_API_TOKEN` +- Domyślny bazowy URL wnioskowania: `http://localhost:1234/v1` + +Następnie ustaw model (zastąp jednym z identyfikatorów zwróconych przez `http://localhost:1234/api/v1/models`): + +```json5 +{ + agents: { + defaults: { model: { primary: "lmstudio/openai/gpt-oss-20b" } }, + }, +} +``` + +OpenClaw używa natywnych endpointów LM Studio `/api/v1/models` i `/api/v1/models/load` +do wykrywania + automatycznego ładowania, a domyślnie do wnioskowania używa `/v1/chat/completions`. +Konfigurację i rozwiązywanie problemów znajdziesz w [/providers/lmstudio](/pl/providers/lmstudio). + ### Ollama -Ollama jest dostarczana jako dołączony plugin dostawcy i używa natywnego API Ollama: +Ollama jest dostarczana jako dołączony Plugin dostawcy i używa natywnego API Ollama: - Dostawca: `ollama` -- Uwierzytelnianie: nie jest wymagane (serwer lokalny) +- Uwierzytelnianie: niewymagane (serwer lokalny) - Przykładowy model: `ollama/llama3.3` - Instalacja: [https://ollama.com/download](https://ollama.com/download) @@ -700,17 +722,17 @@ ollama pull llama3.3 ``` Ollama jest wykrywana lokalnie pod adresem `http://127.0.0.1:11434`, gdy włączysz ją przez -`OLLAMA_API_KEY`, a dołączony plugin dostawcy dodaje Ollama bezpośrednio do -`openclaw onboard` i selektora modeli. Zobacz [/providers/ollama](/pl/providers/ollama), -aby poznać szczegóły wdrażania, trybu chmurowego/lokalnego i konfiguracji niestandardowej. +`OLLAMA_API_KEY`, a dołączony Plugin dostawcy dodaje Ollama bezpośrednio do +`openclaw onboard` oraz selektora modeli. Zobacz [/providers/ollama](/pl/providers/ollama), +aby poznać onboarding, tryb cloud/local oraz konfigurację niestandardową. ### vLLM -vLLM jest dostarczany jako dołączony plugin dostawcy dla lokalnych / samohostowanych -serwerów zgodnych z OpenAI: +vLLM jest dostarczany jako dołączony Plugin dostawcy dla lokalnych/self-hosted serwerów +kompatybilnych z OpenAI: - Dostawca: `vllm` -- Uwierzytelnianie: opcjonalne (zależy od serwera) +- Uwierzytelnianie: opcjonalne (zależy od Twojego serwera) - Domyślny bazowy URL: `http://127.0.0.1:8000/v1` Aby włączyć lokalne automatyczne wykrywanie (dowolna wartość działa, jeśli serwer nie wymusza uwierzytelniania): @@ -719,7 +741,7 @@ Aby włączyć lokalne automatyczne wykrywanie (dowolna wartość działa, jeśl export VLLM_API_KEY="vllm-local" ``` -Następnie ustaw model (zastąp jedną z wartości identyfikatorów zwracanych przez `/v1/models`): +Następnie ustaw model (zastąp jednym z identyfikatorów zwróconych przez `/v1/models`): ```json5 { @@ -733,11 +755,11 @@ Szczegóły znajdziesz w [/providers/vllm](/pl/providers/vllm). ### SGLang -SGLang jest dostarczany jako dołączony plugin dostawcy dla szybkich, samohostowanych -serwerów zgodnych z OpenAI: +SGLang jest dostarczany jako dołączony Plugin dostawcy dla szybkich samodzielnie hostowanych +serwerów kompatybilnych z OpenAI: - Dostawca: `sglang` -- Uwierzytelnianie: opcjonalne (zależy od serwera) +- Uwierzytelnianie: opcjonalne (zależy od Twojego serwera) - Domyślny bazowy URL: `http://127.0.0.1:30000/v1` Aby włączyć lokalne automatyczne wykrywanie (dowolna wartość działa, jeśli serwer nie @@ -747,7 +769,7 @@ wymusza uwierzytelniania): export SGLANG_API_KEY="sglang-local" ``` -Następnie ustaw model (zastąp jedną z wartości identyfikatorów zwracanych przez `/v1/models`): +Następnie ustaw model (zastąp jednym z identyfikatorów zwróconych przez `/v1/models`): ```json5 { @@ -759,9 +781,9 @@ Następnie ustaw model (zastąp jedną z wartości identyfikatorów zwracanych p Szczegóły znajdziesz w [/providers/sglang](/pl/providers/sglang). -### Lokalne proxy (LM Studio, vLLM, LiteLLM itd.) +### Lokalne proxy (LM Studio, vLLM, LiteLLM itp.) -Przykład (zgodny z OpenAI): +Przykład (kompatybilny z OpenAI): ```json5 { @@ -775,7 +797,7 @@ Przykład (zgodny z OpenAI): providers: { lmstudio: { baseUrl: "http://localhost:1234/v1", - apiKey: "LMSTUDIO_KEY", + apiKey: "${LM_API_TOKEN}", api: "openai-completions", models: [ { @@ -797,20 +819,19 @@ Przykład (zgodny z OpenAI): Uwagi: - Dla niestandardowych dostawców `reasoning`, `input`, `cost`, `contextWindow` i `maxTokens` są opcjonalne. - Jeśli je pominiesz, OpenClaw domyślnie używa: + Jeśli zostaną pominięte, OpenClaw domyślnie przyjmuje: - `reasoning: false` - `input: ["text"]` - `cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }` - `contextWindow: 200000` - `maxTokens: 8192` -- Zalecane: ustaw jawne wartości zgodne z limitami twojego proxy/modelu. +- Zalecane: ustaw jawne wartości zgodne z limitami Twojego proxy/modelu. - Dla `api: "openai-completions"` na nienatywnych endpointach (dowolny niepusty `baseUrl`, którego host nie jest `api.openai.com`) OpenClaw wymusza `compat.supportsDeveloperRole: false`, aby uniknąć błędów 400 od dostawcy dla nieobsługiwanych ról `developer`. -- Trasy proxy zgodne z OpenAI również pomijają natywne formatowanie żądań tylko dla OpenAI: - brak `service_tier`, brak `store` dla Responses, brak wskazówek pamięci podręcznej promptów, brak - formatowania ładunku zgodności rozumowania OpenAI i brak ukrytych nagłówków - atrybucji OpenClaw. -- Jeśli `baseUrl` jest pusty / pominięty, OpenClaw zachowuje domyślne zachowanie OpenAI (które wskazuje na `api.openai.com`). -- Dla bezpieczeństwa jawne `compat.supportsDeveloperRole: true` jest nadal nadpisywane na `false` na nienatywnych endpointach `openai-completions`. +- Trasy proxy w stylu kompatybilnym z OpenAI pomijają też natywne kształtowanie żądań tylko dla OpenAI: + bez `service_tier`, bez `store` dla Responses, bez wskazówek cache promptów, bez + kształtowania payloadu zgodności rozumowania OpenAI i bez ukrytych nagłówków atrybucji OpenClaw. +- Jeśli `baseUrl` jest pusty/pominięty, OpenClaw zachowuje domyślne zachowanie OpenAI (które wskazuje na `api.openai.com`). +- Dla bezpieczeństwa jawne `compat.supportsDeveloperRole: true` jest nadal nadpisywane na nienatywnych endpointach `openai-completions`. ## Przykłady CLI @@ -820,7 +841,7 @@ openclaw models set opencode/claude-opus-4-6 openclaw models list ``` -Zobacz także: [/gateway/configuration](/pl/gateway/configuration), aby uzyskać pełne przykłady konfiguracji. +Zobacz też: [/gateway/configuration](/pl/gateway/configuration), aby poznać pełne przykłady konfiguracji. ## Powiązane diff --git a/docs/pl/concepts/qa-e2e-automation.md b/docs/pl/concepts/qa-e2e-automation.md index 151b5e1b0..dd84e7edb 100644 --- a/docs/pl/concepts/qa-e2e-automation.md +++ b/docs/pl/concepts/qa-e2e-automation.md @@ -3,31 +3,32 @@ read_when: - Rozszerzanie qa-lab lub qa-channel - Dodawanie scenariuszy QA opartych na repozytorium - Tworzenie bardziej realistycznej automatyzacji QA wokół panelu Gateway -summary: Prywatny kształt automatyzacji QA dla qa-lab, qa-channel, scenariuszy seedowanych i raportów protokołu +summary: Prywatny kształt automatyzacji QA dla qa-lab, qa-channel, scenariuszy z ziarnem i raportów protokołu title: Automatyzacja QA E2E x-i18n: - generated_at: "2026-04-12T23:28:04Z" + generated_at: "2026-04-13T08:50:47Z" model: gpt-5.4 provider: openai - source_hash: b9fe27dc049823d5e3eb7ae1eac6aad21ed9e917425611fb1dbcb28ab9210d5e + source_hash: a4a4f5c765163565c95c2a071f201775fd9d8d60cad4ff25d71e4710559c1570 source_path: concepts/qa-e2e-automation.md workflow: 15 --- # Automatyzacja QA E2E -Prywatny stos QA ma na celu testowanie OpenClaw w bardziej realistyczny, -kanałowy sposób niż pojedynczy test jednostkowy. +Prywatny stos QA ma na celu testowanie OpenClaw w sposób bardziej realistyczny, +uformowany wokół kanałów, niż jest to możliwe w pojedynczym teście jednostkowym. Obecne elementy: -- `extensions/qa-channel`: syntetyczny kanał wiadomości z powierzchniami DM, kanału, wątku, +- `extensions/qa-channel`: syntetyczny kanał wiadomości z powierzchniami dla DM, kanału, wątku, reakcji, edycji i usuwania. - `extensions/qa-lab`: interfejs debuggera i magistrala QA do obserwowania transkryptu, wstrzykiwania wiadomości przychodzących i eksportowania raportu Markdown. -- `qa/`: zasoby seedowane oparte na repozytorium dla zadania startowego i bazowych scenariuszy QA. +- `qa/`: zasoby seed oparte na repozytorium dla zadania początkowego i bazowych + scenariuszy QA. -Obecny przepływ pracy operatora QA to dwupanelowa witryna QA: +Obecny przepływ pracy operatora QA to dwupanelowa strona QA: - Po lewej: panel Gateway (Control UI) z agentem. - Po prawej: QA Lab, pokazujący transkrypt w stylu Slacka i plan scenariusza. @@ -38,13 +39,13 @@ Uruchom za pomocą: pnpm qa:lab:up ``` -To buduje witrynę QA, uruchamia opartą na Dockerze ścieżkę gateway i udostępnia -stronę QA Lab, na której operator lub pętla automatyzacji może przydzielić agentowi +To buduje stronę QA, uruchamia ścieżkę Gateway opartą na Dockerze i udostępnia +stronę QA Lab, na której operator lub pętla automatyzacji może zlecić agentowi misję QA, obserwować rzeczywiste zachowanie kanału oraz zapisywać, co zadziałało, -co zawiodło lub co pozostało zablokowane. +co się nie udało lub co pozostało zablokowane. -Aby szybciej iterować nad interfejsem QA Lab bez każdorazowego przebudowywania obrazu Docker, -uruchom stos z bind-mountowanym bundle QA Lab: +Aby szybciej iterować nad interfejsem QA Lab bez przebudowywania obrazu Dockera za każdym razem, +uruchom stos z podmontowanym bundle QA Lab: ```bash pnpm openclaw qa docker-build-image @@ -53,52 +54,52 @@ pnpm qa:lab:up:fast pnpm qa:lab:watch ``` -`qa:lab:up:fast` utrzymuje usługi Docker na wcześniej zbudowanym obrazie i bind-mountuje +`qa:lab:up:fast` utrzymuje usługi Dockera na wcześniej zbudowanym obrazie i bind-mountuje `extensions/qa-lab/web/dist` do kontenera `qa-lab`. `qa:lab:watch` -przebudowuje ten bundle przy zmianach, a przeglądarka automatycznie odświeża się, -gdy zmieni się hash zasobu QA Lab. +przebudowuje ten bundle przy zmianach, a przeglądarka automatycznie przeładowuje się, +gdy zmienia się hash zasobów QA Lab. -Aby uruchomić ścieżkę smoke Matrix z rzeczywistym transportem, wykonaj: +Aby uruchomić ścieżkę smoke Matrix z rzeczywistym transportem, użyj: ```bash pnpm openclaw qa matrix ``` -Ta ścieżka provisionuje jednorazowy homeserver Tuwunel w Dockerze, rejestruje -tymczasowych użytkowników driver, SUT i observer, tworzy jeden prywatny pokój, -a następnie uruchamia prawdziwy Plugin Matrix wewnątrz potomnego procesu QA gateway. Ścieżka z żywym -transportem utrzymuje konfigurację potomną ograniczoną do testowanego transportu, -dzięki czemu Matrix działa bez `qa-channel` w konfiguracji potomnej. +Ta ścieżka udostępnia jednorazowy homeserver Tuwunel w Dockerze, rejestruje +tymczasowych użytkowników drivera, SUT i obserwatora, tworzy jeden prywatny pokój, +a następnie uruchamia rzeczywisty Plugin Matrix wewnątrz podrzędnego Gateway QA. Ścieżka z żywym transportem utrzymuje konfigurację +podrzędną ograniczoną do testowanego transportu, więc Matrix działa bez +`qa-channel` w konfiguracji podrzędnej. -Aby uruchomić ścieżkę smoke Telegram z rzeczywistym transportem, wykonaj: +Aby uruchomić ścieżkę smoke Telegram z rzeczywistym transportem, użyj: ```bash pnpm openclaw qa telegram ``` -Ta ścieżka kieruje ruch do jednej prawdziwej prywatnej grupy Telegram zamiast provisionować -jednorazowy serwer. Wymaga `OPENCLAW_QA_TELEGRAM_GROUP_ID`, +Ta ścieżka jest kierowana do jednej rzeczywistej prywatnej grupy Telegram zamiast +udostępniać jednorazowy serwer. Wymaga `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` oraz -`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, a także dwóch odrębnych botów w tej samej -prywatnej grupie. Bot SUT musi mieć nazwę użytkownika Telegram, a obserwacja bot-bot -działa najlepiej, gdy oba boty mają włączony tryb Bot-to-Bot Communication Mode +`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, a także dwóch różnych botów w tej samej +prywatnej grupie. Bot SUT musi mieć nazwę użytkownika Telegram, a obserwacja +bot-bot działa najlepiej, gdy oba boty mają włączony tryb Bot-to-Bot Communication Mode w `@BotFather`. Ścieżki z żywym transportem współdzielą teraz jeden mniejszy kontrakt zamiast tego, -by każda wymyślała własny kształt listy scenariuszy: +żeby każda definiowała własny kształt listy scenariuszy: -`qa-channel` pozostaje szerokim syntetycznym zestawem zachowań produktu i nie jest częścią -macierzy pokrycia żywego transportu. +`qa-channel` pozostaje szerokim syntetycznym zestawem testów zachowania produktu i nie jest częścią +macierzy pokrycia dla żywego transportu. -| Ścieżka | Canary | Bramka wzmianek | Blokada allowlisty | Odpowiedź najwyższego poziomu | Wznowienie po restarcie | Dalszy ciąg wątku | Izolacja wątku | Obserwacja reakcji | Komenda pomocy | -| -------- | ------ | --------------- | ------------------ | ----------------------------- | ----------------------- | ----------------- | -------------- | ------------------ | -------------- | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Ścieżka | Canary | Bramka wzmianek | Blokada allowlisty | Odpowiedź najwyższego poziomu | Wznowienie po restarcie | Dalszy ciąg w wątku | Izolacja wątku | Obserwacja reakcji | Polecenie help | +| -------- | ------ | --------------- | ------------------ | ----------------------------- | ----------------------- | ------------------- | -------------- | ------------------ | -------------- | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | -Dzięki temu `qa-channel` pozostaje szerokim zestawem zachowań produktu, podczas gdy Matrix, -Telegram i przyszłe żywe transporty współdzielą jedną jawną listę kontrolną kontraktu transportu. +Dzięki temu `qa-channel` pozostaje szerokim zestawem testów zachowania produktu, podczas gdy Matrix, +Telegram i przyszłe żywe transporty współdzielą jedną jawną checklistę kontraktu transportowego. -Aby uruchomić jednorazową ścieżkę Linux VM bez wprowadzania Dockera do ścieżki QA, wykonaj: +Aby uruchomić ścieżkę z jednorazową maszyną wirtualną Linux bez włączania Dockera do ścieżki QA, użyj: ```bash pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline @@ -108,18 +109,18 @@ To uruchamia świeżego gościa Multipass, instaluje zależności, buduje OpenCl wewnątrz gościa, uruchamia `qa suite`, a następnie kopiuje zwykły raport QA i podsumowanie z powrotem do `.artifacts/qa-e2e/...` na hoście. Ponownie wykorzystuje to samo zachowanie wyboru scenariuszy co `qa suite` na hoście. -Uruchomienia hosta i Multipass suite wykonują domyślnie wiele wybranych scenariuszy równolegle -z izolowanymi workerami gateway, maksymalnie do 64 workerów lub liczby wybranych +Uruchomienia hosta i pakietu Multipass domyślnie wykonują równolegle wiele wybranych scenariuszy +z izolowanymi workerami Gateway, maksymalnie do 64 workerów lub liczby wybranych scenariuszy. Użyj `--concurrency `, aby dostroić liczbę workerów, lub -`--concurrency 1` dla wykonania seryjnego. -Uruchomienia live przekazują obsługiwane wejścia uwierzytelniania QA, które są praktyczne dla +`--concurrency 1` do wykonywania sekwencyjnego. +Uruchomienia live przekazują obsługiwane wejścia autoryzacji QA, które są praktyczne dla gościa: klucze dostawcy oparte na env, ścieżkę konfiguracji dostawcy QA live oraz -`CODEX_HOME`, gdy jest obecne. Zachowaj `--output-dir` pod katalogiem głównym repozytorium, aby gość -mógł zapisywać z powrotem przez zamontowany workspace. +`CODEX_HOME`, jeśli jest obecne. Utrzymuj `--output-dir` w katalogu głównym repozytorium, aby gość +mógł zapisywać dane z powrotem przez zamontowany workspace. ## Seedy oparte na repozytorium -Zasoby seedowane znajdują się w `qa/`: +Zasoby seed znajdują się w `qa/`: - `qa/scenarios/index.md` - `qa/scenarios/*.md` @@ -127,15 +128,20 @@ Zasoby seedowane znajdują się w `qa/`: Są one celowo przechowywane w git, aby plan QA był widoczny zarówno dla ludzi, jak i dla agenta. -`qa-lab` powinien pozostać generycznym runnerem markdown. Każdy plik markdown scenariusza jest +`qa-lab` powinien pozostać generycznym runnerem Markdown. Każdy plik scenariusza Markdown jest źródłem prawdy dla jednego uruchomienia testu i powinien definiować: - metadane scenariusza - odwołania do dokumentacji i kodu -- opcjonalne wymagania Pluginów -- opcjonalną łatkę konfiguracji gateway +- opcjonalne wymagania Plugin +- opcjonalną poprawkę konfiguracji Gateway - wykonywalny `qa-flow` +Powierzchnia wielokrotnego użytku środowiska wykonawczego, która wspiera `qa-flow`, może pozostać +generyczna i przekrojowa. Na przykład scenariusze Markdown mogą łączyć pomocniki po stronie +transportu z pomocnikami po stronie przeglądarki, które sterują osadzonym Control UI przez +powierzchnię Gateway `browser.request`, bez dodawania runnera specjalnego przypadku. + Lista bazowa powinna pozostać wystarczająco szeroka, aby obejmować: - czat DM i kanałowy @@ -148,34 +154,34 @@ Lista bazowa powinna pozostać wystarczająco szeroka, aby obejmować: - czytanie repozytorium i dokumentacji - jedno małe zadanie build, takie jak Lobster Invaders -## Adaptery transportu +## Adaptery transportowe -`qa-lab` posiada generyczny seam transportowy dla scenariuszy QA w markdown. -`qa-channel` jest pierwszym adapterem na tym seamie, ale docelowy projekt jest szerszy: -przyszłe rzeczywiste lub syntetyczne kanały powinny podłączać się do tego samego runnera suite +`qa-lab` jest właścicielem generycznej powierzchni transportu dla scenariuszy QA w Markdown. +`qa-channel` jest pierwszym adapterem tej powierzchni, ale docelowy projekt jest szerszy: +przyszłe rzeczywiste lub syntetyczne kanały powinny podłączać się do tego samego runnera pakietu zamiast dodawać runner QA specyficzny dla transportu. -Na poziomie architektury podział jest następujący: +Na poziomie architektury podział wygląda następująco: -- `qa-lab` odpowiada za generyczne wykonywanie scenariuszy, współbieżność workerów, zapisywanie artefaktów i raportowanie. -- adapter transportu odpowiada za konfigurację gateway, gotowość, obserwację wejścia i wyjścia, akcje transportu oraz znormalizowany stan transportu. -- pliki markdown scenariuszy w `qa/scenarios/` definiują przebieg testu; `qa-lab` udostępnia wielokrotnego użytku powierzchnię runtime, która je wykonuje. +- `qa-lab` jest właścicielem generycznego wykonywania scenariuszy, współbieżności workerów, zapisu artefaktów i raportowania. +- adapter transportu jest właścicielem konfiguracji Gateway, gotowości, obserwacji wejścia i wyjścia, działań transportowych oraz znormalizowanego stanu transportu. +- pliki scenariuszy Markdown w `qa/scenarios/` definiują przebieg testu; `qa-lab` udostępnia powierzchnię środowiska wykonawczego wielokrotnego użytku, która je wykonuje. Wskazówki wdrożeniowe dla maintainerów dotyczące nowych adapterów kanałów znajdują się w [Testing](/pl/help/testing#adding-a-channel-to-qa). ## Raportowanie -`qa-lab` eksportuje raport protokołu Markdown na podstawie obserwowanej osi czasu magistrali. +`qa-lab` eksportuje raport protokołu Markdown z obserwowanej osi czasu magistrali. Raport powinien odpowiadać na pytania: - Co zadziałało -- Co zawiodło +- Co się nie udało - Co pozostało zablokowane -- Jakie scenariusze uzupełniające warto dodać +- Jakie scenariusze follow-up warto dodać -Aby przeprowadzić kontrole charakteru i stylu, uruchom ten sam scenariusz na wielu żywych referencjach modeli -i zapisz oceniony raport Markdown: +Aby przeprowadzić kontrole charakteru i stylu, uruchom ten sam scenariusz dla wielu żywych referencji modeli +i zapisz oceniany raport Markdown: ```bash pnpm openclaw qa character-eval \ @@ -194,36 +200,36 @@ pnpm openclaw qa character-eval \ --judge-concurrency 16 ``` -Komenda uruchamia lokalne potomne procesy QA gateway, a nie Docker. Scenariusze character eval -powinny ustawiać personę przez `SOUL.md`, a następnie wykonywać zwykłe tury użytkownika, -takie jak czat, pomoc dotycząca workspace i małe zadania na plikach. Kandydacki model -nie powinien być informowany, że jest oceniany. Komenda zachowuje każdy pełny -transkrypt, rejestruje podstawowe statystyki uruchomienia, a następnie prosi modele oceniające w trybie fast z -rozumowaniem `xhigh`, aby uszeregowały uruchomienia według naturalności, klimatu i humoru. -Użyj `--blind-judge-models` podczas porównywania dostawców: prompt oceniający nadal otrzymuje +Polecenie uruchamia lokalne podrzędne procesy Gateway QA, a nie Docker. Scenariusze +character eval powinny ustawiać personę przez `SOUL.md`, a następnie uruchamiać zwykłe tury użytkownika, +takie jak czat, pomoc dotycząca workspace i małe zadania plikowe. Kandydacki model +nie powinien być informowany, że jest oceniany. Polecenie zachowuje każdy pełny +transkrypt, zapisuje podstawowe statystyki uruchomienia, a następnie prosi modele sędziujące w trybie fast z +rozumowaniem `xhigh` o uszeregowanie uruchomień według naturalności, klimatu i humoru. +Użyj `--blind-judge-models` podczas porównywania dostawców: prompt sędziujący nadal otrzymuje każdy transkrypt i status uruchomienia, ale referencje kandydatów są zastępowane neutralnymi -etykietami, takimi jak `candidate-01`; raport mapuje rankingi z powrotem na prawdziwe referencje po +etykietami, takimi jak `candidate-01`; raport mapuje rankingi z powrotem na rzeczywiste referencje po parsowaniu. -Uruchomienia kandydatów domyślnie używają poziomu myślenia `high`, z `xhigh` dla modeli OpenAI, -które go obsługują. Zastąp określonego kandydata inline za pomocą +Uruchomienia kandydatów domyślnie używają poziomu myślenia `high`, a dla modeli OpenAI `xhigh`, +jeśli go obsługują. Zastąpienie dla konkretnego kandydata ustawiaj inline za pomocą `--model provider/model,thinking=`. `--thinking ` nadal ustawia globalny fallback, a starsza forma `--model-thinking ` jest zachowana dla kompatybilności. -Referencje kandydatów OpenAI domyślnie używają trybu fast, dzięki czemu wykorzystywane jest -przetwarzanie priorytetowe tam, gdzie dostawca je obsługuje. Dodaj inline `,fast`, `,no-fast` lub `,fast=false`, -gdy pojedynczy kandydat lub oceniający wymaga nadpisania. Przekaż `--fast` tylko wtedy, gdy chcesz -wymusić tryb fast dla każdego modelu kandydata. Czasy trwania kandydatów i oceniających są -rejestrowane w raporcie do analizy benchmarkowej, ale prompty oceniające wyraźnie mówią, -aby nie ustalać rankingu według szybkości. -Zarówno uruchomienia modeli kandydatów, jak i oceniających domyślnie używają współbieżności 16. Zmniejsz -`--concurrency` lub `--judge-concurrency`, gdy limity dostawcy lub obciążenie lokalnego gateway -sprawiają, że uruchomienie jest zbyt zaszumione. -Gdy nie zostanie przekazany żaden kandydat `--model`, character eval domyślnie używa +Referencje kandydatów OpenAI domyślnie używają trybu fast, tak aby priorytetowe przetwarzanie było używane tam, +gdzie dostawca to obsługuje. Dodaj inline `,fast`, `,no-fast` lub `,fast=false`, gdy +pojedynczy kandydat lub sędzia wymaga nadpisania. Przekaż `--fast` tylko wtedy, gdy chcesz +wymusić tryb fast dla każdego modelu kandydującego. Czasy trwania kandydatów i sędziów są +zapisywane w raporcie do analizy porównawczej, ale prompty sędziujące wyraźnie mówią, +aby nie tworzyć rankingu na podstawie szybkości. +Uruchomienia modeli kandydatów i sędziów domyślnie używają współbieżności 16. Obniż +`--concurrency` lub `--judge-concurrency`, gdy limity dostawcy lub obciążenie lokalnego Gateway +sprawiają, że uruchomienie staje się zbyt zaszumione. +Gdy nie zostanie przekazane żadne `--model` kandydata, character eval domyślnie używa `openai/gpt-5.4`, `openai/gpt-5.2`, `openai/gpt-5`, `anthropic/claude-opus-4-6`, `anthropic/claude-sonnet-4-6`, `zai/glm-5.1`, `moonshot/kimi-k2.5` oraz -`google/gemini-3.1-pro-preview`, jeśli nie przekazano `--model`. -Gdy nie zostanie przekazany żaden `--judge-model`, oceniający domyślnie używają +`google/gemini-3.1-pro-preview`, gdy nie zostanie przekazane `--model`. +Gdy nie zostanie przekazane żadne `--judge-model`, sędziowie domyślnie używają `openai/gpt-5.4,thinking=xhigh,fast` oraz `anthropic/claude-opus-4-6,thinking=high`. diff --git a/docs/pl/gateway/local-models.md b/docs/pl/gateway/local-models.md index 7066c986d..ca3c68f65 100644 --- a/docs/pl/gateway/local-models.md +++ b/docs/pl/gateway/local-models.md @@ -1,28 +1,28 @@ --- read_when: - - Chcesz udostępniać modele z własnej maszyny GPU + - Chcesz udostępniać modele z własnej maszyny z GPU - Konfigurujesz LM Studio lub proxy zgodne z OpenAI - Potrzebujesz najbezpieczniejszych wskazówek dotyczących modeli lokalnych -summary: Uruchamianie OpenClaw na lokalnych modelach LLM (LM Studio, vLLM, LiteLLM, niestandardowe endpointy OpenAI) +summary: Uruchom OpenClaw na lokalnych LLM-ach (LM Studio, vLLM, LiteLLM, niestandardowe endpointy OpenAI) title: Modele lokalne x-i18n: - generated_at: "2026-04-08T02:14:31Z" + generated_at: "2026-04-13T08:50:43Z" model: gpt-5.4 provider: openai - source_hash: d619d72b0e06914ebacb7e9f38b746caf1b9ce8908c9c6638c3acdddbaa025e8 + source_hash: 3ecb61b3e6e34d3666f9b688cd694d92c5fb211cf8c420fa876f7ccf5789154a source_path: gateway/local-models.md workflow: 15 --- # Modele lokalne -Uruchamianie lokalne jest możliwe, ale OpenClaw oczekuje dużego kontekstu oraz silnych zabezpieczeń przed prompt injection. Małe karty skracają kontekst i osłabiają bezpieczeństwo. Celuj wysoko: **≥2 w pełni wyposażone Mac Studio lub równoważny zestaw GPU (~30 tys. USD+)**. Pojedynczy procesor GPU **24 GB** sprawdzi się tylko przy lżejszych promptach i większych opóźnieniach. Używaj **największego / pełnowymiarowego wariantu modelu, jaki możesz uruchomić**; agresywnie kwantyzowane lub „małe” checkpointy zwiększają ryzyko prompt injection (zobacz [Bezpieczeństwo](/pl/gateway/security)). +Środowisko lokalne jest wykonalne, ale OpenClaw oczekuje dużego kontekstu + silnej ochrony przed prompt injection. Małe karty obcinają kontekst i osłabiają bezpieczeństwo. Celuj wysoko: **≥2 w pełni wyposażone Mac Studio lub równoważny zestaw GPU (~30 tys. USD+)**. Pojedynczy procesor graficzny **24 GB** działa tylko przy lżejszych promptach i z większym opóźnieniem. Używaj **największego / pełnowymiarowego wariantu modelu, jaki możesz uruchomić**; agresywnie kwantyzowane lub „małe” checkpointy zwiększają ryzyko prompt injection (zobacz [Bezpieczeństwo](/pl/gateway/security)). -Jeśli chcesz skonfigurować lokalne środowisko z jak najmniejszym tarciem, zacznij od [Ollama](/pl/providers/ollama) i `openclaw onboard`. Ta strona to opiniotwórczy przewodnik po bardziej zaawansowanych lokalnych stosach oraz niestandardowych lokalnych serwerach zgodnych z OpenAI. +Jeśli chcesz uzyskać lokalną konfigurację z najmniejszym tarciem, zacznij od [LM Studio](/pl/providers/lmstudio) lub [Ollama](/pl/providers/ollama) i `openclaw onboard`. Ta strona to praktyczny przewodnik dla bardziej zaawansowanych lokalnych stosów oraz niestandardowych lokalnych serwerów zgodnych z OpenAI. ## Zalecane: LM Studio + duży model lokalny (Responses API) -Obecnie najlepszy lokalny stos. Załaduj duży model do LM Studio (na przykład pełnowymiarową kompilację Qwen, DeepSeek lub Llama), włącz lokalny serwer (domyślnie `http://127.0.0.1:1234`) i użyj Responses API, aby oddzielić rozumowanie od tekstu końcowego. +Obecnie najlepszy lokalny stos. Załaduj duży model w LM Studio (na przykład pełnowymiarową kompilację Qwen, DeepSeek lub Llama), włącz lokalny serwer (domyślnie `http://127.0.0.1:1234`), a następnie użyj Responses API, aby oddzielić rozumowanie od końcowego tekstu. ```json5 { @@ -64,13 +64,13 @@ Obecnie najlepszy lokalny stos. Załaduj duży model do LM Studio (na przykład - Zainstaluj LM Studio: [https://lmstudio.ai](https://lmstudio.ai) - W LM Studio pobierz **największą dostępną kompilację modelu** (unikaj wariantów „small” / mocno kwantyzowanych), uruchom serwer i potwierdź, że `http://127.0.0.1:1234/v1/models` go wyświetla. - Zastąp `my-local-model` rzeczywistym identyfikatorem modelu widocznym w LM Studio. -- Utrzymuj model załadowany; zimne ładowanie zwiększa opóźnienie startu. -- Dostosuj `contextWindow`/`maxTokens`, jeśli Twoja kompilacja LM Studio się różni. -- W przypadku WhatsApp trzymaj się Responses API, aby wysyłany był tylko tekst końcowy. +- Utrzymuj model załadowany; zimne ładowanie zwiększa opóźnienie uruchamiania. +- Dostosuj `contextWindow`/`maxTokens`, jeśli Twoja kompilacja LM Studio różni się od tej przykładowej. +- W przypadku WhatsApp trzymaj się Responses API, aby wysyłany był tylko końcowy tekst. -Nawet przy uruchamianiu lokalnym pozostaw skonfigurowane modele hostowane; użyj `models.mode: "merge"`, aby fallbacki pozostały dostępne. +Utrzymuj skonfigurowane także modele hostowane, nawet jeśli działasz lokalnie; używaj `models.mode: "merge"`, aby fallbacki pozostawały dostępne. -### Konfiguracja hybrydowa: hostowany model podstawowy, lokalny fallback +### Konfiguracja hybrydowa: hostowany model główny, lokalny fallback ```json5 { @@ -113,16 +113,16 @@ Nawet przy uruchamianiu lokalnym pozostaw skonfigurowane modele hostowane; użyj ### Najpierw lokalnie, z hostowaną siatką bezpieczeństwa -Zamień kolejność modelu podstawowego i fallbacku; zachowaj ten sam blok providerów oraz `models.mode: "merge"`, aby móc przełączyć się awaryjnie na Sonnet lub Opus, gdy lokalna maszyna będzie niedostępna. +Zamień kolejność modelu głównego i fallbacku; pozostaw ten sam blok providers oraz `models.mode: "merge"`, aby w razie awarii lokalnej maszyny można było przełączyć się na Sonnet lub Opus. ### Hosting regionalny / routing danych -- Hostowane warianty MiniMax/Kimi/GLM są również dostępne w OpenRouter z endpointami przypiętymi do regionu (np. hostowanymi w USA). Wybierz tam wariant regionalny, aby utrzymać ruch w wybranej jurysdykcji, nadal używając `models.mode: "merge"` dla fallbacków Anthropic/OpenAI. -- Tryb wyłącznie lokalny pozostaje najmocniejszą ścieżką pod względem prywatności; hostowany routing regionalny to rozwiązanie pośrednie, gdy potrzebujesz funkcji dostawcy, ale chcesz zachować kontrolę nad przepływem danych. +- Hostowane warianty MiniMax/Kimi/GLM są także dostępne w OpenRouter z endpointami przypisanymi do regionu (np. hostowane w USA). Wybierz tam wariant regionalny, aby utrzymać ruch w wybranej jurysdykcji, nadal używając `models.mode: "merge"` dla fallbacków Anthropic/OpenAI. +- Tryb wyłącznie lokalny pozostaje najmocniejszą ścieżką prywatności; hostowany routing regionalny to rozwiązanie pośrednie, gdy potrzebujesz funkcji dostawcy, ale chcesz zachować kontrolę nad przepływem danych. ## Inne lokalne proxy zgodne z OpenAI -vLLM, LiteLLM, OAI-proxy lub niestandardowe bramy działają, jeśli udostępniają endpoint `/v1` w stylu OpenAI. Zastąp powyższy blok providera swoim endpointem i identyfikatorem modelu: +vLLM, LiteLLM, OAI-proxy lub niestandardowe Gateway działają, jeśli udostępniają endpoint `/v1` w stylu OpenAI. Zastąp powyższy blok provider własnym endpointem i identyfikatorem modelu: ```json5 { @@ -150,41 +150,43 @@ vLLM, LiteLLM, OAI-proxy lub niestandardowe bramy działają, jeśli udostępnia } ``` -Zachowaj `models.mode: "merge"`, aby hostowane modele nadal były dostępne jako fallbacki. +Utrzymuj `models.mode: "merge"`, aby hostowane modele nadal były dostępne jako fallbacki. -Uwagi dotyczące działania dla lokalnych / proxowanych backendów `/v1`: +Uwaga dotycząca działania lokalnych / proxy backendów `/v1`: -- OpenClaw traktuje je jako trasy proxy zgodne z OpenAI, a nie natywne endpointy OpenAI -- natywne kształtowanie żądań tylko dla OpenAI nie ma tu zastosowania: brak - `service_tier`, brak Responses `store`, brak kształtowania payloadu zgodności z rozumowaniem OpenAI - oraz brak wskazówek dotyczących cache promptów +- OpenClaw traktuje je jako trasy proxy zgodne z OpenAI, a nie natywne + endpointy OpenAI +- natywne formatowanie żądań przeznaczone wyłącznie dla OpenAI nie ma tu + zastosowania: brak `service_tier`, brak `store` dla Responses, brak + formatowania ładunku zgodności rozumowania OpenAI i brak wskazówek + dotyczących cache promptów - ukryte nagłówki atrybucji OpenClaw (`originator`, `version`, `User-Agent`) - nie są wstrzykiwane dla tych niestandardowych adresów URL proxy + nie są wstrzykiwane do tych niestandardowych URL-i proxy -Uwagi o zgodności dla bardziej rygorystycznych backendów zgodnych z OpenAI: +Uwagi o zgodności dla bardziej restrykcyjnych backendów zgodnych z OpenAI: -- Niektóre serwery akceptują w Chat Completions tylko string `messages[].content`, a nie +- Niektóre serwery akceptują w Chat Completions tylko ciąg znaków w `messages[].content`, a nie ustrukturyzowane tablice części treści. Ustaw `models.providers..models[].compat.requiresStringContent: true` dla takich endpointów. -- Niektóre mniejsze lub bardziej rygorystyczne lokalne backendy są niestabilne przy pełnym - kształcie promptu środowiska uruchomieniowego agenta OpenClaw, szczególnie gdy dołączone są schematy narzędzi. Jeśli - backend działa dla małych bezpośrednich wywołań `/v1/chat/completions`, ale nie działa przy zwykłych - turach agenta OpenClaw, najpierw spróbuj +- Niektóre mniejsze lub bardziej restrykcyjne lokalne backendy są niestabilne przy pełnym + kształcie promptu środowiska uruchomieniowego agenta OpenClaw, zwłaszcza gdy dołączone są + schematy narzędzi. Jeśli backend działa dla małych bezpośrednich wywołań `/v1/chat/completions`, + ale zawodzi przy normalnych turach agenta OpenClaw, najpierw spróbuj `models.providers..models[].compat.supportsTools: false`. - Jeśli backend nadal zawodzi tylko przy większych uruchomieniach OpenClaw, pozostały problem - zwykle leży po stronie przepustowości modelu/serwera upstream albo błędu backendu, a nie warstwy + zwykle leży po stronie pojemności modelu/serwera albo błędu backendu, a nie warstwy transportowej OpenClaw. ## Rozwiązywanie problemów -- Brama może połączyć się z proxy? `curl http://127.0.0.1:1234/v1/models`. -- Model LM Studio został wyładowany? Załaduj go ponownie; zimny start jest częstą przyczyną „zawieszania się”. -- Błędy kontekstu? Obniż `contextWindow` lub zwiększ limit serwera. +- Gateway może połączyć się z proxy? `curl http://127.0.0.1:1234/v1/models`. +- Model LM Studio został wyładowany? Załaduj go ponownie; zimny start to częsta przyczyna „zawieszania się”. +- Błędy kontekstu? Zmniejsz `contextWindow` lub zwiększ limit serwera. - Serwer zgodny z OpenAI zwraca `messages[].content ... expected a string`? - Dodaj `compat.requiresStringContent: true` do wpisu tego modelu. -- Bezpośrednie małe wywołania `/v1/chat/completions` działają, ale `openclaw infer model run` - nie działa na Gemma lub innym modelu lokalnym? Najpierw wyłącz schematy narzędzi za pomocą + Dodaj `compat.requiresStringContent: true` do tego wpisu modelu. +- Małe bezpośrednie wywołania `/v1/chat/completions` działają, ale `openclaw infer model run` + zawodzi na Gemma lub innym modelu lokalnym? Najpierw wyłącz schematy narzędzi przez `compat.supportsTools: false`, a następnie przetestuj ponownie. Jeśli serwer nadal ulega awarii tylko - przy większych promptach OpenClaw, traktuj to jako ograniczenie modelu/serwera upstream. -- Bezpieczeństwo: modele lokalne pomijają filtry po stronie dostawcy; utrzymuj agentów w wąskim zakresie i włącz kompaktowanie, aby ograniczyć zasięg prompt injection. + przy większych promptach OpenClaw, traktuj to jako ograniczenie modelu/serwera po stronie upstream. +- Bezpieczeństwo: modele lokalne pomijają filtry po stronie dostawcy; utrzymuj wąski zakres działania agentów i włączoną Compaction, aby ograniczyć promień rażenia prompt injection. diff --git a/docs/pl/help/testing.md b/docs/pl/help/testing.md index 147f5ac93..03cca89f2 100644 --- a/docs/pl/help/testing.md +++ b/docs/pl/help/testing.md @@ -3,99 +3,177 @@ read_when: - Uruchamianie testów lokalnie lub w CI - Dodawanie testów regresji dla błędów modeli/dostawców - Debugowanie zachowania Gateway i agenta -summary: 'Zestaw testowy: pakiety testów unit/e2e/live, uruchamianie w Dockerze oraz zakres każdego testu' +summary: 'Zestaw testowy: pakiety testów unit/e2e/live, uruchamiacze Docker i zakres pokrycia poszczególnych testów' title: Testowanie x-i18n: - generated_at: "2026-04-12T23:28:34Z" + generated_at: "2026-04-13T08:50:41Z" model: gpt-5.4 provider: openai - source_hash: a66ea672c386094ab4a8035a082c8a85d508a14301ad44b628d2a10d9cec3a52 + source_hash: 3db91b4bc36f626cd014958ec66b08b9cecd9faaa20a5746cd3a49ad4b0b1c38 source_path: help/testing.md workflow: 15 --- # Testowanie -OpenClaw ma trzy pakiety testów Vitest (unit/integration, e2e, live) oraz niewielki zestaw runnerów Dockera. +OpenClaw ma trzy pakiety Vitest (unit/integration, e2e, live) oraz niewielki zestaw uruchamiaczy Docker. -Ten dokument to przewodnik „jak testujemy”: +Ten dokument jest przewodnikiem „jak testujemy”: - Co obejmuje każdy pakiet testów (i czego celowo _nie_ obejmuje) - Jakie polecenia uruchamiać w typowych przepływach pracy (lokalnie, przed pushem, debugowanie) - Jak testy live wykrywają poświadczenia oraz wybierają modele/dostawców -- Jak dodawać testy regresji dla rzeczywistych problemów z modelami/dostawcami +- Jak dodawać testy regresji dla rzeczywistych problemów modeli/dostawców ## Szybki start -Na co dzień: +W większości dni: - Pełna bramka (oczekiwana przed pushem): `pnpm build && pnpm check && pnpm test` -- Szybsze lokalne uruchomienie pełnego pakietu na wydajnej maszynie: `pnpm test:max` -- Bezpośrednia pętla watch Vitest: `pnpm test:watch` -- Bezpośrednie wskazanie pliku obsługuje teraz także ścieżki rozszerzeń/kanałów: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Podczas iteracji nad pojedynczym błędem najpierw preferuj uruchomienia ukierunkowane. -- Witryna QA oparta na Dockerze: `pnpm qa:lab:up` -- Ścieżka QA oparta na VM z Linuxem: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- Szybsze lokalne uruchomienie całego pakietu na wydajnej maszynie: `pnpm test:max` +- Bezpośrednia pętla obserwacji Vitest: `pnpm test:watch` +- Bezpośrednie wskazanie pliku teraz obsługuje także ścieżki rozszerzeń/kanałów: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Gdy iterujesz nad pojedynczym błędem, najpierw preferuj uruchomienia ukierunkowane. +- Witryna QA oparta na Docker: `pnpm qa:lab:up` +- Linia QA oparta na Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -Gdy modyfikujesz testy lub chcesz mieć większą pewność: +Gdy modyfikujesz testy lub chcesz uzyskać większą pewność: - Bramka pokrycia: `pnpm test:coverage` -- Pakiet e2e: `pnpm test:e2e` +- Pakiet E2E: `pnpm test:e2e` Podczas debugowania rzeczywistych dostawców/modeli (wymaga prawdziwych poświadczeń): - Pakiet live (modele + sondy narzędzi/obrazów Gateway): `pnpm test:live` -- Ciche uruchomienie jednego pliku live: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Ciche uruchomienie pojedynczego pliku live: `pnpm test:live -- src/agents/models.profiles.live.test.ts` Wskazówka: gdy potrzebujesz tylko jednego nieudanego przypadku, zawężaj testy live za pomocą zmiennych środowiskowych allowlist opisanych poniżej. -## Runnery specyficzne dla QA +## Uruchamiacze specyficzne dla QA -Te polecenia działają obok głównych pakietów testów, gdy potrzebujesz realizmu QA-lab: +Te polecenia działają obok głównych pakietów testów, gdy potrzebujesz realizmu qa-lab: - `pnpm openclaw qa suite` - - Uruchamia scenariusze QA oparte na repozytorium bezpośrednio na hoście. - - Domyślnie uruchamia równolegle wiele wybranych scenariuszy z izolowanymi workerami Gateway, maksymalnie do 64 workerów albo liczby wybranych scenariuszy. Użyj `--concurrency `, aby dostroić liczbę workerów, lub `--concurrency 1`, aby wrócić do starszej ścieżki sekwencyjnej. + - Uruchamia scenariusze QA wspierane przez repozytorium bezpośrednio na hoście. + - Domyślnie uruchamia równolegle wiele wybranych scenariuszy z izolowanymi workerami Gateway, maksymalnie do 64 workerów lub liczby wybranych scenariuszy. Użyj `--concurrency `, aby dostroić liczbę workerów, albo `--concurrency 1` dla starszej linii sekwencyjnej. - `pnpm openclaw qa suite --runner multipass` - - Uruchamia ten sam pakiet QA wewnątrz jednorazowej maszyny wirtualnej Multipass z Linuxem. - - Zachowuje takie samo zachowanie wyboru scenariuszy jak `qa suite` na hoście. - - Ponownie używa tych samych flag wyboru dostawcy/modelu co `qa suite`. - - Uruchomienia live przekazują do gościa obsługiwane dane uwierzytelniające QA, które praktycznie da się tam przekazać: klucze dostawców oparte na env, ścieżkę konfiguracji dostawcy QA live oraz `CODEX_HOME`, jeśli jest obecne. - - Katalogi wyjściowe muszą pozostać w katalogu głównym repozytorium, aby gość mógł zapisywać dane z powrotem przez zamontowany obszar roboczy. - - Zapisuje zwykły raport QA + podsumowanie oraz logi Multipass w `.artifacts/qa-e2e/...`. + - Uruchamia ten sam pakiet QA wewnątrz jednorazowej maszyny wirtualnej Linux Multipass. + - Zachowuje ten sam sposób wyboru scenariuszy co `qa suite` na hoście. + - Używa tych samych flag wyboru dostawcy/modelu co `qa suite`. + - Uruchomienia live przekazują do gościa obsługiwane wejścia uwierzytelniania QA, które są praktyczne dla środowiska gościa: + klucze dostawców oparte na env, ścieżkę konfiguracji dostawcy QA live oraz `CODEX_HOME`, jeśli jest obecne. + - Katalogi wyjściowe muszą pozostawać pod korzeniem repozytorium, aby gość mógł zapisywać dane z powrotem przez zamontowany obszar roboczy. + - Zapisuje zwykły raport + podsumowanie QA oraz logi Multipass w `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Uruchamia witrynę QA opartą na Dockerze do operatorskiej pracy QA. + - Uruchamia witrynę QA opartą na Docker do pracy QA w stylu operatorskim. - `pnpm openclaw qa matrix` - - Uruchamia ścieżkę live QA dla Matrix względem jednorazowego homeserwera Tuwunel opartego na Dockerze. - - Tworzy trzy tymczasowe konta Matrix (`driver`, `sut`, `observer`) oraz jeden prywatny pokój, a następnie uruchamia podrzędny proces QA Gateway z rzeczywistym pluginem Matrix jako transportem SUT. - - Domyślnie używa przypiętego stabilnego obrazu Tuwunel `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Nadpisz go przez `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, gdy chcesz przetestować inny obraz. - - Zapisuje raport Matrix QA, podsumowanie i artefakt zaobserwowanych zdarzeń w `.artifacts/qa-e2e/...`. + - Uruchamia linię live QA Matrix na jednorazowym homeserverze Tuwunel opartym na Docker. + - Tworzy trzy tymczasowe konta użytkowników Matrix (`driver`, `sut`, `observer`) oraz jeden prywatny pokój, a następnie uruchamia podrzędny proces QA Gateway z rzeczywistym Plugin Matrix jako transportem SUT. + - Domyślnie używa przypiętego stabilnego obrazu Tuwunel `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Zastąp przez `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, gdy musisz przetestować inny obraz. + - Matrix obecnie obsługuje tylko `--credential-source env`, ponieważ linia tworzy tymczasowych użytkowników lokalnie. + - Zapisuje raport QA Matrix, podsumowanie oraz artefakt obserwowanych zdarzeń w `.artifacts/qa-e2e/...`. - `pnpm openclaw qa telegram` - - Uruchamia ścieżkę live QA dla Telegram względem rzeczywistej prywatnej grupy, używając tokenów bota driver i bota SUT z env. + - Uruchamia linię live QA Telegram na rzeczywistej prywatnej grupie przy użyciu tokenów botów driver i SUT z env. - Wymaga `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` oraz `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Identyfikator grupy musi być numerycznym identyfikatorem czatu Telegram. - - Wymaga dwóch różnych botów w tej samej prywatnej grupie, przy czym bot SUT musi mieć ujawnioną nazwę użytkownika Telegram. - - Aby zapewnić stabilną obserwację bot-do-bota, włącz Bot-to-Bot Communication Mode w `@BotFather` dla obu botów i upewnij się, że bot driver może obserwować ruch botów w grupie. - - Zapisuje raport Telegram QA, podsumowanie i artefakt zaobserwowanych wiadomości w `.artifacts/qa-e2e/...`. + - Obsługuje `--credential-source convex` dla współdzielonych poświadczeń z puli. Domyślnie używaj trybu env albo ustaw `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, aby włączyć dzierżawy z puli. + - Wymaga dwóch różnych botów w tej samej prywatnej grupie, przy czym bot SUT musi udostępniać nazwę użytkownika Telegram. + - Aby zapewnić stabilną obserwację bot-bot, włącz Bot-to-Bot Communication Mode w `@BotFather` dla obu botów i upewnij się, że bot driver może obserwować ruch botów w grupie. + - Zapisuje raport QA Telegram, podsumowanie oraz artefakt obserwowanych wiadomości w `.artifacts/qa-e2e/...`. -Ścieżki live transportu współdzielą jeden standardowy kontrakt, aby nowe transporty nie dryfowały: +Linie live dla transportów współdzielą jeden standardowy kontrakt, aby nowe transporty nie dryfowały. -`qa-channel` pozostaje szerokim syntetycznym pakietem QA i nie jest częścią macierzy pokrycia live transportów. +`qa-channel` pozostaje szerokim syntetycznym pakietem QA i nie jest częścią macierzy pokrycia live dla transportów. -| Ścieżka | Canary | Bramka mention | Blokada allowlist | Odpowiedź najwyższego poziomu | Wznowienie po restarcie | Dalszy ciąg wątku | Izolacja wątku | Obserwacja reakcji | Polecenie help | -| -------- | ------ | -------------- | ----------------- | ----------------------------- | ----------------------- | ----------------- | -------------- | ------------------ | -------------- | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Linia | Canary | Bramka wzmianek | Blokada allowlist | Odpowiedź najwyższego poziomu | Wznowienie po restarcie | Kontynuacja wątku | Izolacja wątku | Obserwacja reakcji | Polecenie pomocy | +| -------- | ------ | --------------- | ----------------- | ----------------------------- | ----------------------- | ----------------- | -------------- | ------------------ | ---------------- | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | + +### Współdzielone poświadczenia Telegram przez Convex (v1) + +Gdy `--credential-source convex` (lub `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) jest włączone dla +`openclaw qa telegram`, laboratorium QA pobiera wyłączną dzierżawę z puli opartej na Convex, wysyła Heartbeat +tej dzierżawy, gdy linia działa, i zwalnia dzierżawę przy zamykaniu. + +Referencyjny szkielet projektu Convex: + +- `qa/convex-credential-broker/` + +Wymagane zmienne środowiskowe: + +- `OPENCLAW_QA_CONVEX_SITE_URL` (na przykład `https://your-deployment.convex.site`) +- Jeden sekret dla wybranej roli: + - `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` dla `maintainer` + - `OPENCLAW_QA_CONVEX_SECRET_CI` dla `ci` +- Wybór roli poświadczeń: + - CLI: `--credential-role maintainer|ci` + - Domyślna wartość z env: `OPENCLAW_QA_CREDENTIAL_ROLE` (domyślnie `maintainer`) + +Opcjonalne zmienne środowiskowe: + +- `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (domyślnie `1200000`) +- `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (domyślnie `30000`) +- `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (domyślnie `90000`) +- `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (domyślnie `15000`) +- `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (domyślnie `/qa-credentials/v1`) +- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (opcjonalny identyfikator śledzenia) +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` pozwala na adresy URL Convex `http://` w local loopback wyłącznie do lokalnego developmentu. + +`OPENCLAW_QA_CONVEX_SITE_URL` powinien używać `https://` w normalnej pracy. + +Polecenia administracyjne maintainera (dodawanie/usuwanie/listowanie puli) wymagają +konkretnie `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. + +Pomocnicze polecenia CLI dla maintainerów: + +```bash +pnpm openclaw qa credentials add --kind telegram --payload-file qa/telegram-credential.json +pnpm openclaw qa credentials list --kind telegram +pnpm openclaw qa credentials remove --credential-id +``` + +Użyj `--json`, aby uzyskać wynik czytelny maszynowo w skryptach i narzędziach CI. + +Domyślny kontrakt endpointu (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): + +- `POST /acquire` + - Żądanie: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` + - Sukces: `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` + - Wyczerpanie/możliwość ponowienia: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` +- `POST /heartbeat` + - Żądanie: `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` + - Sukces: `{ status: "ok" }` (lub puste `2xx`) +- `POST /release` + - Żądanie: `{ kind, ownerId, actorRole, credentialId, leaseToken }` + - Sukces: `{ status: "ok" }` (lub puste `2xx`) +- `POST /admin/add` (tylko sekret maintainera) + - Żądanie: `{ kind, actorId, payload, note?, status? }` + - Sukces: `{ status: "ok", credential }` +- `POST /admin/remove` (tylko sekret maintainera) + - Żądanie: `{ credentialId, actorId }` + - Sukces: `{ status: "ok", changed, credential }` + - Ochrona aktywnej dzierżawy: `{ status: "error", code: "LEASE_ACTIVE", ... }` +- `POST /admin/list` (tylko sekret maintainera) + - Żądanie: `{ kind?, status?, includePayload?, limit? }` + - Sukces: `{ status: "ok", credentials, count }` + +Kształt payload dla rodzaju Telegram: + +- `{ groupId: string, driverToken: string, sutToken: string }` +- `groupId` musi być ciągiem znaków będącym numerycznym identyfikatorem czatu Telegram. +- `admin/add` waliduje ten kształt dla `kind: "telegram"` i odrzuca nieprawidłowy payload. ### Dodawanie kanału do QA Dodanie kanału do markdownowego systemu QA wymaga dokładnie dwóch rzeczy: 1. Adaptera transportu dla kanału. -2. Pakietu scenariuszy, który sprawdza kontrakt kanału. +2. Pakietu scenariuszy, który testuje kontrakt kanału. -Nie dodawaj runnera QA specyficznego dla kanału, gdy współdzielony runner `qa-lab` może obsłużyć ten przepływ. +Nie dodawaj uruchamiacza QA specyficznego dla kanału, jeśli wspólny uruchamiacz `qa-lab` +może obsłużyć ten przepływ. -`qa-lab` odpowiada za współdzieloną mechanikę: +`qa-lab` odpowiada za wspólną mechanikę: - uruchamianie i zamykanie pakietu - współbieżność workerów @@ -110,27 +188,27 @@ Adapter kanału odpowiada za kontrakt transportu: - jak sprawdzana jest gotowość - jak wstrzykiwane są zdarzenia przychodzące - jak obserwowane są wiadomości wychodzące -- jak udostępniane są transkrypty i znormalizowany stan transportu -- jak wykonywane są działania oparte na transporcie +- jak udostępniane są transkrypcje i znormalizowany stan transportu +- jak wykonywane są akcje oparte na transporcie - jak obsługiwany jest reset lub czyszczenie specyficzne dla transportu Minimalny próg wdrożenia dla nowego kanału to: -1. Zaimplementowanie adaptera transportu na współdzielonym łączu `qa-lab`. -2. Zarejestrowanie adaptera w rejestrze transportów. -3. Utrzymanie mechaniki specyficznej dla transportu wewnątrz adaptera lub harnessu kanału. -4. Utworzenie lub dostosowanie scenariuszy markdown w `qa/scenarios/`. -5. Używanie generycznych helperów scenariuszy dla nowych scenariuszy. -6. Utrzymanie działania istniejących aliasów zgodności, chyba że repozytorium przechodzi świadomą migrację. +1. Zaimplementować adapter transportu na wspólnej granicy `qa-lab`. +2. Zarejestrować adapter w rejestrze transportów. +3. Zachować mechanikę specyficzną dla transportu wewnątrz adaptera lub harnessu kanału. +4. Napisać lub dostosować scenariusze markdown w `qa/scenarios/`. +5. Używać ogólnych helperów scenariuszy dla nowych scenariuszy. +6. Zachować działanie istniejących aliasów zgodności, chyba że repozytorium przeprowadza zamierzoną migrację. -Reguła decyzyjna jest rygorystyczna: +Zasada decyzyjna jest ścisła: -- Jeśli dane zachowanie można wyrazić raz w `qa-lab`, umieść je w `qa-lab`. -- Jeśli zachowanie zależy od jednego transportu kanału, pozostaw je w tym adapterze lub harnessie pluginu. -- Jeśli scenariusz wymaga nowej możliwości, z której może skorzystać więcej niż jeden kanał, dodaj generyczny helper zamiast gałęzi specyficznej dla kanału w `suite.ts`. -- Jeśli dane zachowanie ma sens tylko dla jednego transportu, zachowaj scenariusz jako specyficzny dla transportu i wyraźnie zaznacz to w kontrakcie scenariusza. +- Jeśli zachowanie można wyrazić raz w `qa-lab`, umieść je w `qa-lab`. +- Jeśli zachowanie zależy od jednego transportu kanału, zachowaj je w tym adapterze lub harnessie Plugin. +- Jeśli scenariusz wymaga nowej możliwości, z której może skorzystać więcej niż jeden kanał, dodaj ogólny helper zamiast gałęzi specyficznej dla kanału w `suite.ts`. +- Jeśli zachowanie ma sens tylko dla jednego transportu, zachowaj scenariusz jako specyficzny dla tego transportu i zaznacz to wyraźnie w kontrakcie scenariusza. -Preferowane nazwy generycznych helperów dla nowych scenariuszy to: +Preferowane nazwy ogólnych helperów dla nowych scenariuszy to: - `waitForTransportReady` - `waitForChannelReady` @@ -153,64 +231,65 @@ Aliasy zgodności pozostają dostępne dla istniejących scenariuszy, w tym: - `formatConversationTranscript` - `resetBus` -Nowe prace nad kanałami powinny używać generycznych nazw helperów. -Aliasy zgodności istnieją po to, aby uniknąć migracji typu flag day, a nie jako model dla tworzenia nowych scenariuszy. +Nowa praca nad kanałami powinna używać ogólnych nazw helperów. +Aliasy zgodności istnieją po to, aby uniknąć migracji typu flag day, a nie jako model +tworzenia nowych scenariuszy. ## Pakiety testów (co uruchamia się gdzie) -Myśl o pakietach jak o „rosnącym realizmie” (i rosnącej zawodności/koszcie): +O pakietach warto myśleć jako o „rosnącym realizmie” (oraz rosnącej podatności na błędy/niestabilność i koszcie): -### Unit / integration (domyślnie) +### Unit / integration (domyślne) - Polecenie: `pnpm test` -- Konfiguracja: dziesięć sekwencyjnych uruchomień shardów (`vitest.full-*.config.ts`) na istniejących zakresowych projektach Vitest -- Pliki: podstawowe inwentarze unit w `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` oraz dopuszczone testy node w `ui`, objęte przez `vitest.unit.config.ts` +- Konfiguracja: dziesięć sekwencyjnych uruchomień shardów (`vitest.full-*.config.ts`) na istniejących zakresowanych projektach Vitest +- Pliki: inwentarze core/unit w `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` oraz umieszczone na allowliście testy node w `ui`, objęte przez `vitest.unit.config.ts` - Zakres: - Czyste testy unit - Testy integracyjne in-process (uwierzytelnianie Gateway, routing, narzędzia, parsowanie, konfiguracja) - - Deterministyczne regresje dla znanych błędów + - Deterministyczne testy regresji dla znanych błędów - Oczekiwania: - Uruchamia się w CI - Nie wymaga prawdziwych kluczy - Powinno być szybkie i stabilne - Uwaga o projektach: - - Niekierowane `pnpm test` uruchamia teraz jedenaście mniejszych konfiguracji shardów (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) zamiast jednego ogromnego natywnego procesu root-project. To zmniejsza szczytowe RSS na obciążonych maszynach i zapobiega temu, by prace `auto-reply`/rozszerzeń zagłodziły niezwiązane pakiety. - - `pnpm test --watch` nadal używa natywnego grafu projektów root `vitest.config.ts`, ponieważ pętla watch dla wielu shardów nie jest praktyczna. - - `pnpm test`, `pnpm test:watch` i `pnpm test:perf:imports` kierują jawne cele plików/katalogów najpierw przez zakresowe ścieżki, więc `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` unika kosztu pełnego uruchamiania root project. - - `pnpm test:changed` rozwija zmienione ścieżki git do tych samych zakresowych ścieżek, gdy diff dotyka tylko routowalnych plików źródłowych/testowych; edycje konfiguracji/setup nadal wracają do szerokiego ponownego uruchomienia root project. - - Lekkie importowo testy unit z obszarów agents, commands, plugins, helperów `auto-reply`, `plugin-sdk` i podobnych czysto użytkowych obszarów trafiają na ścieżkę `unit-fast`, która pomija `test/setup-openclaw-runtime.ts`; pliki stanowe/ciężkie runtime pozostają na istniejących ścieżkach. - - Wybrane pliki źródłowe helperów `plugin-sdk` i `commands` mapują też uruchomienia changed-mode na jawne sąsiednie testy w tych lekkich ścieżkach, dzięki czemu edycje helperów nie wymuszają ponownego uruchamiania pełnego ciężkiego pakietu dla tego katalogu. - - `auto-reply` ma teraz trzy dedykowane koszyki: pomocniki core najwyższego poziomu, testy integracyjne `reply.*` najwyższego poziomu oraz poddrzewo `src/auto-reply/reply/**`. Dzięki temu najcięższa praca harnessu reply jest odsunięta od tanich testów status/chunk/token. -- Uwaga o embedded runnerze: - - Gdy zmieniasz wejścia wykrywania message-tool albo kontekst runtime Compaction, + - Niekierunkowane `pnpm test` uruchamia teraz jedenaście mniejszych konfiguracji shardów (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) zamiast jednego ogromnego natywnego procesu root-project. Zmniejsza to szczytowe RSS na obciążonych maszynach i zapobiega temu, by prace `auto-reply`/rozszerzeń zagłodziły niezwiązane pakiety. + - `pnpm test --watch` nadal używa natywnego grafu projektów root `vitest.config.ts`, ponieważ wieloszardowa pętla watch nie jest praktyczna. + - `pnpm test`, `pnpm test:watch` i `pnpm test:perf:imports` kierują jawne cele plików/katalogów najpierw przez zakresowane linie, dzięki czemu `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` nie płaci kosztu uruchomienia pełnego root project. + - `pnpm test:changed` rozwija zmienione ścieżki git do tych samych zakresowanych linii, gdy diff dotyczy tylko routowalnych plików źródłowych/testowych; edycje konfiguracji/ustawień nadal przechodzą do szerokiego ponownego uruchomienia root project. + - Lekkie importowo testy unit z agentów, poleceń, pluginów, helperów `auto-reply`, `plugin-sdk` i podobnych czystych obszarów narzędziowych są kierowane przez linię `unit-fast`, która pomija `test/setup-openclaw-runtime.ts`; pliki stanowe/ciężkie runtime pozostają na istniejących liniach. + - Wybrane pliki źródłowe helperów `plugin-sdk` i `commands` również mapują uruchomienia trybu changed do jawnych sąsiednich testów w tych lekkich liniach, dzięki czemu edycje helperów nie wymuszają ponownego uruchamiania całego ciężkiego pakietu dla tego katalogu. + - `auto-reply` ma teraz trzy dedykowane koszyki: helpery core najwyższego poziomu, testy integracyjne najwyższego poziomu `reply.*` oraz poddrzewo `src/auto-reply/reply/**`. Dzięki temu najcięższa praca harnessu odpowiedzi nie trafia do tanich testów status/chunk/token. +- Uwaga o osadzonym uruchamiaczu: + - Gdy zmieniasz wejścia wykrywania message-tool lub kontekst runtime Compaction, utrzymuj oba poziomy pokrycia. - - Dodawaj ukierunkowane regresje helperów dla czystych granic routingu/normalizacji. - - Utrzymuj też w dobrej kondycji pakiety integracyjne embedded runnera: + - Dodawaj ukierunkowane testy regresji helperów dla czystych granic routingu/normalizacji. + - Utrzymuj też w dobrej kondycji pakiety integracyjne osadzonego uruchamiacza: `src/agents/pi-embedded-runner/compact.hooks.test.ts`, `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` oraz `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Te pakiety weryfikują, że zakresowe identyfikatory i zachowanie Compaction nadal przepływają + - Te pakiety weryfikują, że zakresowane identyfikatory i zachowanie Compaction nadal przepływają przez rzeczywiste ścieżki `run.ts` / `compact.ts`; same testy helperów nie są - wystarczającym substytutem dla tych ścieżek integracyjnych. + wystarczającym zamiennikiem dla tych ścieżek integracyjnych. - Uwaga o puli: - - Podstawowa konfiguracja Vitest domyślnie używa teraz `threads`. - - Współdzielona konfiguracja Vitest ustawia też `isolate: false` i używa nieizolowanego runnera we wszystkich projektach root, konfiguracjach e2e i live. - - Główna ścieżka UI zachowuje swoją konfigurację `jsdom` i optymalizator, ale teraz także działa na współdzielonym nieizolowanym runnerze. - - Każdy shard `pnpm test` dziedziczy te same ustawienia domyślne `threads` + `isolate: false` ze współdzielonej konfiguracji Vitest. - - Współdzielony launcher `scripts/run-vitest.mjs` dodaje teraz domyślnie także `--no-maglev` dla podrzędnych procesów Node Vitest, aby ograniczyć narzut kompilacji V8 podczas dużych lokalnych uruchomień. Ustaw `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, jeśli chcesz porównać zachowanie ze standardowym V8. -- Uwaga o szybkiej lokalnej iteracji: - - `pnpm test:changed` kieruje przez zakresowe ścieżki, gdy zmienione ścieżki da się czysto odwzorować na mniejszy pakiet. - - `pnpm test:max` i `pnpm test:changed:max` zachowują to samo routowanie, tylko z wyższym limitem workerów. - - Automatyczne skalowanie liczby lokalnych workerów jest teraz celowo konserwatywne i wycofuje się również wtedy, gdy średnie obciążenie hosta jest już wysokie, dzięki czemu wiele równoczesnych uruchomień Vitest domyślnie szkodzi mniej. - - Podstawowa konfiguracja Vitest oznacza projekty/pliki konfiguracji jako `forceRerunTriggers`, aby ponowne uruchomienia changed-mode pozostawały poprawne, gdy zmienia się okablowanie testów. - - Konfiguracja utrzymuje włączone `OPENCLAW_VITEST_FS_MODULE_CACHE` na obsługiwanych hostach; ustaw `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, jeśli chcesz jedną jawną lokalizację cache do bezpośredniego profilowania. + - Bazowa konfiguracja Vitest domyślnie używa teraz `threads`. + - Współdzielona konfiguracja Vitest ustawia również `isolate: false` i używa nieizolowanego uruchamiacza w projektach root, konfiguracjach e2e i live. + - Główna linia UI zachowuje konfigurację `jsdom` i optimizer, ale teraz również działa na współdzielonym nieizolowanym uruchamiaczu. + - Każdy shard `pnpm test` dziedziczy te same domyślne ustawienia `threads` + `isolate: false` ze współdzielonej konfiguracji Vitest. + - Współdzielony launcher `scripts/run-vitest.mjs` domyślnie dodaje teraz także `--no-maglev` dla podrzędnych procesów Node Vitest, aby ograniczyć narzut kompilacji V8 podczas dużych lokalnych uruchomień. Ustaw `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, jeśli chcesz porównać zachowanie z domyślnym V8. +- Uwaga o szybkiej iteracji lokalnej: + - `pnpm test:changed` kieruje przez zakresowane linie, gdy zmienione ścieżki czysto mapują się na mniejszy pakiet. + - `pnpm test:max` i `pnpm test:changed:max` zachowują to samo kierowanie, tylko z wyższym limitem workerów. + - Automatyczne skalowanie lokalnych workerów jest teraz celowo konserwatywne i dodatkowo zwalnia, gdy średnie obciążenie hosta jest już wysokie, dzięki czemu wiele równoczesnych uruchomień Vitest domyślnie powoduje mniej szkód. + - Bazowa konfiguracja Vitest oznacza projekty/pliki konfiguracyjne jako `forceRerunTriggers`, aby ponowne uruchomienia w trybie changed pozostawały poprawne, gdy zmienia się okablowanie testów. + - Konfiguracja utrzymuje włączone `OPENCLAW_VITEST_FS_MODULE_CACHE` na obsługiwanych hostach; ustaw `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, jeśli chcesz jeden jawny katalog cache do bezpośredniego profilowania. - Uwaga o debugowaniu wydajności: - - `pnpm test:perf:imports` włącza raportowanie czasu importu Vitest oraz wyjście z podziałem importów. - - `pnpm test:perf:imports:changed` zawęża ten sam widok profilowania do plików zmienionych względem `origin/main`. -- `pnpm test:perf:changed:bench -- --ref ` porównuje routowane `test:changed` z natywną ścieżką root project dla diffu z tego commita i wypisuje wall time oraz maksymalne RSS na macOS. -- `pnpm test:perf:changed:bench -- --worktree` benchmarkuje bieżące brudne drzewo, kierując listę zmienionych plików przez `scripts/test-projects.mjs` i konfigurację root Vitest. - - `pnpm test:perf:profile:main` zapisuje profil CPU głównego wątku dla kosztów startu i transformacji Vitest/Vite. - - `pnpm test:perf:profile:runner` zapisuje profile CPU+heap runnera dla pakietu unit z wyłączoną równoległością plików. + - `pnpm test:perf:imports` włącza raportowanie czasu importu Vitest oraz wynik z podziałem importów. + - `pnpm test:perf:imports:changed` zawęża ten sam widok profilowania do plików zmienionych od `origin/main`. +- `pnpm test:perf:changed:bench -- --ref ` porównuje kierowane `test:changed` z natywną ścieżką root-project dla tego zatwierdzonego diffu i wypisuje czas ścienny oraz maksymalne RSS na macOS. +- `pnpm test:perf:changed:bench -- --worktree` benchmarkuje bieżące brudne drzewo, kierując listę zmienionych plików przez `scripts/test-projects.mjs` oraz główną konfigurację Vitest. + - `pnpm test:perf:profile:main` zapisuje profil CPU głównego wątku dla narzutu uruchamiania i transformacji Vitest/Vite. + - `pnpm test:perf:profile:runner` zapisuje profile CPU+heap uruchamiacza dla pakietu unit z wyłączoną równoległością plików. ### E2E (smoke Gateway) @@ -220,13 +299,13 @@ Myśl o pakietach jak o „rosnącym realizmie” (i rosnącej zawodności/koszc - Domyślne ustawienia runtime: - Używa Vitest `threads` z `isolate: false`, zgodnie z resztą repozytorium. - Używa adaptacyjnej liczby workerów (CI: do 2, lokalnie: domyślnie 1). - - Domyślnie uruchamia się w trybie cichym, aby ograniczyć narzut I/O konsoli. + - Domyślnie działa w trybie cichym, aby ograniczyć narzut I/O konsoli. - Przydatne nadpisania: - - `OPENCLAW_E2E_WORKERS=`, aby wymusić liczbę workerów (limit do 16). - - `OPENCLAW_E2E_VERBOSE=1`, aby ponownie włączyć szczegółowe wyjście konsoli. + - `OPENCLAW_E2E_WORKERS=` aby wymusić liczbę workerów (maksymalnie 16). + - `OPENCLAW_E2E_VERBOSE=1` aby ponownie włączyć szczegółowy wynik konsoli. - Zakres: - - End-to-end zachowanie wieloinstancyjnego Gateway - - Powierzchnie WebSocket/HTTP, parowanie Node i cięższe scenariusze sieciowe + - Zachowanie end-to-end Gateway z wieloma instancjami + - Powierzchnie WebSocket/HTTP, parowanie Node oraz cięższa komunikacja sieciowa - Oczekiwania: - Uruchamia się w CI (gdy jest włączone w pipeline) - Nie wymaga prawdziwych kluczy @@ -237,19 +316,19 @@ Myśl o pakietach jak o „rosnącym realizmie” (i rosnącej zawodności/koszc - Polecenie: `pnpm test:e2e:openshell` - Plik: `test/openshell-sandbox.e2e.test.ts` - Zakres: - - Uruchamia izolowany Gateway OpenShell na hoście przez Docker + - Uruchamia na hoście izolowany Gateway OpenShell przez Docker - Tworzy sandbox z tymczasowego lokalnego Dockerfile - Testuje backend OpenShell w OpenClaw przez rzeczywiste `sandbox ssh-config` + wykonanie SSH - - Weryfikuje zdalne kanoniczne zachowanie systemu plików przez most fs sandboxa + - Weryfikuje zdalnie kanoniczne zachowanie systemu plików przez most fs sandboxa - Oczekiwania: - - Wyłącznie opt-in; nie jest częścią domyślnego uruchomienia `pnpm test:e2e` + - Tylko opt-in; nie jest częścią domyślnego uruchomienia `pnpm test:e2e` - Wymaga lokalnego CLI `openshell` oraz działającego demona Docker - Używa izolowanych `HOME` / `XDG_CONFIG_HOME`, a następnie niszczy testowy Gateway i sandbox - Przydatne nadpisania: - `OPENCLAW_E2E_OPENSHELL=1`, aby włączyć test przy ręcznym uruchamianiu szerszego pakietu e2e - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, aby wskazać niestandardowe binarium CLI lub skrypt wrappera + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, aby wskazać niestandardowy binarny plik CLI lub skrypt wrappera -### Live (prawdziwi dostawcy + prawdziwe modele) +### Live (rzeczywiści dostawcy + rzeczywiste modele) - Polecenie: `pnpm test:live` - Konfiguracja: `vitest.live.config.ts` @@ -257,112 +336,112 @@ Myśl o pakietach jak o „rosnącym realizmie” (i rosnącej zawodności/koszc - Domyślnie: **włączone** przez `pnpm test:live` (ustawia `OPENCLAW_LIVE_TEST=1`) - Zakres: - „Czy ten dostawca/model naprawdę działa _dzisiaj_ z prawdziwymi poświadczeniami?” - - Wykrywanie zmian formatu dostawcy, niuansów wywoływania narzędzi, problemów z uwierzytelnianiem i zachowania limitów szybkości + - Wychwytywanie zmian formatu dostawcy, niuansów wywołań narzędzi, problemów z uwierzytelnianiem oraz zachowania limitów szybkości - Oczekiwania: - - Z założenia nie jest stabilne w CI (prawdziwe sieci, rzeczywiste polityki dostawców, limity, awarie) - - Kosztuje pieniądze / zużywa limity szybkości + - Z założenia niestabilne w CI (rzeczywiste sieci, rzeczywiste polityki dostawców, limity, awarie) + - Kosztują pieniądze / zużywają limity szybkości - Lepiej uruchamiać zawężone podzbiory zamiast „wszystkiego” -- Uruchomienia live pobierają `~/.profile`, aby uzupełnić brakujące klucze API. -- Domyślnie uruchomienia live nadal izolują `HOME` i kopiują materiały config/auth do tymczasowego katalogu testowego, aby fixture unit nie mogły modyfikować Twojego rzeczywistego `~/.openclaw`. -- Ustaw `OPENCLAW_LIVE_USE_REAL_HOME=1` tylko wtedy, gdy świadomie chcesz, aby testy live używały Twojego rzeczywistego katalogu domowego. -- `pnpm test:live` domyślnie używa teraz cichszego trybu: zachowuje wyjście postępu `[live] ...`, ale ukrywa dodatkową informację o `~/.profile` i wycisza logi bootstrapu Gateway / szum Bonjour. Ustaw `OPENCLAW_LIVE_TEST_QUIET=0`, jeśli chcesz z powrotem pełne logi startowe. -- Rotacja kluczy API (specyficzna dla dostawcy): ustaw `*_API_KEYS` w formacie oddzielanym przecinkiem/średnikiem lub `*_API_KEY_1`, `*_API_KEY_2` (na przykład `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) albo nadpisanie per-live przez `OPENCLAW_LIVE_*_KEY`; testy ponawiają próby po odpowiedziach o ograniczeniu szybkości. -- Wyjście postępu/Heartbeat: - - Pakiety live emitują teraz linie postępu do stderr, dzięki czemu podczas długich wywołań dostawców wyraźnie widać aktywność nawet wtedy, gdy przechwytywanie konsoli Vitest jest ciche. - - `vitest.live.config.ts` wyłącza przechwytywanie konsoli przez Vitest, więc linie postępu dostawcy/Gateway są przesyłane natychmiast podczas uruchomień live. - - Dostosuj Heartbeat bezpośrednich modeli przez `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Dostosuj Heartbeat Gateway/sond przez `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. +- Uruchomienia live pobierają `~/.profile`, aby przejąć brakujące klucze API. +- Domyślnie uruchomienia live nadal izolują `HOME` i kopiują materiały konfiguracji/uwierzytelniania do tymczasowego katalogu testowego, aby fixture unit nie mogły modyfikować twojego rzeczywistego `~/.openclaw`. +- Ustaw `OPENCLAW_LIVE_USE_REAL_HOME=1` tylko wtedy, gdy celowo chcesz, by testy live używały twojego rzeczywistego katalogu domowego. +- `pnpm test:live` domyślnie działa teraz w cichszym trybie: zachowuje wynik postępu `[live] ...`, ale ukrywa dodatkowy komunikat o `~/.profile` i wycisza logi bootstrapu Gateway/hałas Bonjour. Ustaw `OPENCLAW_LIVE_TEST_QUIET=0`, jeśli chcesz z powrotem pełne logi startowe. +- Rotacja kluczy API (specyficzna dla dostawcy): ustaw `*_API_KEYS` w formacie rozdzielanym przecinkami/średnikami albo `*_API_KEY_1`, `*_API_KEY_2` (na przykład `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) lub nadpisanie per-live przez `OPENCLAW_LIVE_*_KEY`; testy ponawiają próby przy odpowiedziach z limitem szybkości. +- Wynik postępu/Heartbeat: + - Pakiety live emitują teraz linie postępu do stderr, dzięki czemu długie wywołania dostawców są widocznie aktywne, nawet gdy przechwytywanie konsoli Vitest jest wyciszone. + - `vitest.live.config.ts` wyłącza przechwytywanie konsoli przez Vitest, dzięki czemu linie postępu dostawcy/Gateway są strumieniowane natychmiast podczas uruchomień live. + - Dostosuj Heartbeat dla bezpośrednich modeli przez `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Dostosuj Heartbeat dla Gateway/sond przez `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. -## Który pakiet testów uruchomić? +## Który pakiet powinienem uruchomić? Użyj tej tabeli decyzyjnej: -- Edytujesz logikę/testy: uruchom `pnpm test` (oraz `pnpm test:coverage`, jeśli zmieniło się dużo) -- Dotykasz sieci Gateway / protokołu WS / parowania: dodaj `pnpm test:e2e` -- Debugujesz „mój bot nie działa” / awarie specyficzne dla dostawcy / wywoływanie narzędzi: uruchom zawężone `pnpm test:live` +- Edycja logiki/testów: uruchom `pnpm test` (oraz `pnpm test:coverage`, jeśli zmieniłeś dużo) +- Zmiany w komunikacji sieciowej Gateway / protokole WS / parowaniu: dodaj `pnpm test:e2e` +- Debugowanie „mój bot nie działa” / błędów specyficznych dla dostawcy / wywołań narzędzi: uruchom zawężone `pnpm test:live` -## Live: przegląd możliwości Node Android +## Live: przegląd możliwości Android Node - Test: `src/gateway/android-node.capabilities.live.test.ts` - Skrypt: `pnpm android:test:integration` -- Cel: wywołać **każde aktualnie ogłaszane polecenie** podłączonego Node Android i potwierdzić zachowanie kontraktu polecenia. +- Cel: wywołać **każde polecenie aktualnie ogłaszane** przez podłączony Android Node i sprawdzić zachowanie kontraktu poleceń. - Zakres: - Wstępnie przygotowana/ręczna konfiguracja (pakiet nie instaluje, nie uruchamia ani nie paruje aplikacji). - - Walidacja `node.invoke` Gateway polecenie po poleceniu dla wybranego Node Android. -- Wymagana wcześniejsza konfiguracja: - - Aplikacja Android jest już podłączona i sparowana z Gateway. + - Walidacja `node.invoke` Gateway polecenie po poleceniu dla wybranego Android Node. +- Wymagane przygotowanie: + - Aplikacja Android jest już połączona i sparowana z Gateway. - Aplikacja pozostaje na pierwszym planie. - - Uprawnienia/zgoda na przechwytywanie są przyznane dla możliwości, które mają przejść. + - Uprawnienia/zgody na przechwytywanie zostały przyznane dla możliwości, które mają przechodzić. - Opcjonalne nadpisania celu: - `OPENCLAW_ANDROID_NODE_ID` lub `OPENCLAW_ANDROID_NODE_NAME`. - `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`. -- Pełne szczegóły konfiguracji Android: [Aplikacja Android](/pl/platforms/android) +- Pełne szczegóły konfiguracji Android: [Android App](/pl/platforms/android) ## Live: smoke modeli (klucze profili) Testy live są podzielone na dwie warstwy, aby można było izolować błędy: -- „Model bezpośredni” mówi nam, czy dostawca/model w ogóle potrafi odpowiedzieć przy danym kluczu. -- „Smoke Gateway” mówi nam, czy pełny pipeline Gateway+agent działa dla tego modelu (sesje, historia, narzędzia, polityka sandboxa itd.). +- „Direct model” mówi nam, czy dostawca/model w ogóle potrafi odpowiedzieć przy danym kluczu. +- „Gateway smoke” mówi nam, czy pełny pipeline gateway+agent działa dla tego modelu (sesje, historia, narzędzia, polityka sandbox itd.). -### Warstwa 1: Bezpośrednie generowanie modelu (bez Gateway) +### Warstwa 1: bezpośrednie ukończenie modelu (bez Gateway) - Test: `src/agents/models.profiles.live.test.ts` - Cel: - - Wyliczyć wykryte modele - - Użyć `getApiKeyForModel` do wybrania modeli, do których masz poświadczenia - - Uruchomić małe completion dla każdego modelu (oraz ukierunkowane regresje tam, gdzie są potrzebne) + - Wyliczać wykryte modele + - Używać `getApiKeyForModel` do wyboru modeli, dla których masz poświadczenia + - Wykonywać małe ukończenie dla każdego modelu (oraz ukierunkowane testy regresji tam, gdzie to potrzebne) - Jak włączyć: - `pnpm test:live` (lub `OPENCLAW_LIVE_TEST=1`, jeśli wywołujesz Vitest bezpośrednio) -- Ustaw `OPENCLAW_LIVE_MODELS=modern` (lub `all`, alias dla modern), aby rzeczywiście uruchomić ten pakiet; w przeciwnym razie zostanie pominięty, aby `pnpm test:live` pozostało skupione na smoke Gateway +- Ustaw `OPENCLAW_LIVE_MODELS=modern` (lub `all`, alias dla modern), aby faktycznie uruchomić ten pakiet; w przeciwnym razie zostanie pominięty, aby `pnpm test:live` było skupione na smoke Gateway - Jak wybierać modele: - - `OPENCLAW_LIVE_MODELS=modern`, aby uruchomić nowoczesną allowlist (`Opus/Sonnet 4.6+`, `GPT-5.x + Codex`, `Gemini 3`, `GLM 4.7`, `MiniMax M2.7`, `Grok 4`) - - `OPENCLAW_LIVE_MODELS=all` jest aliasem dla nowoczesnej allowlist - - albo `OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..."` (allowlist oddzielana przecinkami) - - Przeglądy modern/all domyślnie używają dobranego limitu o wysokim sygnale; ustaw `OPENCLAW_LIVE_MAX_MODELS=0` dla wyczerpującego przeglądu modern albo liczbę dodatnią dla mniejszego limitu. + - `OPENCLAW_LIVE_MODELS=modern`, aby uruchomić nowoczesną allowlistę (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) + - `OPENCLAW_LIVE_MODELS=all` jest aliasem dla nowoczesnej allowlisty + - albo `OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..."` (allowlista rozdzielana przecinkami) + - Przeglądy modern/all domyślnie używają kuratorowanego limitu o wysokim sygnale; ustaw `OPENCLAW_LIVE_MAX_MODELS=0` dla wyczerpującego przeglądu modern albo dodatnią liczbę dla mniejszego limitu. - Jak wybierać dostawców: - - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (allowlist oddzielana przecinkami) + - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (allowlista rozdzielana przecinkami) - Skąd pochodzą klucze: - Domyślnie: magazyn profili i fallbacki env - Ustaw `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby wymusić wyłącznie **magazyn profili** -- Dlaczego to istnieje: +- Po co to istnieje: - Oddziela „API dostawcy jest zepsute / klucz jest nieprawidłowy” od „pipeline agenta Gateway jest zepsuty” - - Zawiera małe, izolowane regresje (przykład: odtwarzanie rozumowania OpenAI Responses/Codex Responses + przepływy wywołań narzędzi) + - Zawiera małe, izolowane testy regresji (przykład: replay rozumowania OpenAI Responses/Codex Responses + przepływy wywołań narzędzi) -### Warstwa 2: smoke Gateway + agenta deweloperskiego (to, co faktycznie robi „@openclaw”) +### Warstwa 2: smoke Gateway + agenta developerskiego (to, co faktycznie robi „@openclaw”) - Test: `src/gateway/gateway-models.profiles.live.test.ts` - Cel: - Uruchomić in-process Gateway - - Utworzyć lub spatchować sesję `agent:dev:*` (nadpisanie modelu dla każdego uruchomienia) - - Iterować po modelach z kluczami i potwierdzać: + - Utworzyć/spatchować sesję `agent:dev:*` (nadpisanie modelu dla każdego uruchomienia) + - Iterować po modelach-z-kluczami i sprawdzać: - „sensowną” odpowiedź (bez narzędzi) - - że działa rzeczywiste wywołanie narzędzia (sonda odczytu) + - że rzeczywiste wywołanie narzędzia działa (sonda odczytu) - opcjonalne dodatkowe sondy narzędzi (sonda exec+read) - że ścieżki regresji OpenAI (tylko tool-call → follow-up) nadal działają -- Szczegóły sond (aby dało się szybko wyjaśnić awarie): - - sonda `read`: test zapisuje plik nonce w obszarze roboczym i prosi agenta o jego `read`, a następnie o odesłanie nonce. - - sonda `exec+read`: test prosi agenta o zapisanie nonce do pliku tymczasowego przez `exec`, a następnie o odczytanie go przez `read`. - - sonda obrazu: test dołącza wygenerowany PNG (kot + zrandomizowany kod) i oczekuje, że model zwróci `cat `. - - Odniesienie implementacyjne: `src/gateway/gateway-models.profiles.live.test.ts` oraz `src/gateway/live-image-probe.ts`. +- Szczegóły sond (aby można było szybko wyjaśniać błędy): + - sonda `read`: test zapisuje plik nonce w obszarze roboczym i prosi agenta o jego `read` oraz odesłanie nonce. + - sonda `exec+read`: test prosi agenta o zapisanie nonce do pliku tymczasowego przez `exec`, a następnie o jego odczytanie przez `read`. + - sonda obrazu: test dołącza wygenerowany PNG (kot + losowy kod) i oczekuje, że model zwróci `cat `. + - Referencja implementacyjna: `src/gateway/gateway-models.profiles.live.test.ts` oraz `src/gateway/live-image-probe.ts`. - Jak włączyć: - `pnpm test:live` (lub `OPENCLAW_LIVE_TEST=1`, jeśli wywołujesz Vitest bezpośrednio) - Jak wybierać modele: - - Domyślnie: nowoczesna allowlist (`Opus/Sonnet 4.6+`, `GPT-5.x + Codex`, `Gemini 3`, `GLM 4.7`, `MiniMax M2.7`, `Grok 4`) - - `OPENCLAW_LIVE_GATEWAY_MODELS=all` to alias nowoczesnej allowlist - - Albo ustaw `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (lub listę oddzielaną przecinkami), aby zawęzić zakres - - Przeglądy Gateway modern/all domyślnie używają dobranego limitu o wysokim sygnale; ustaw `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` dla wyczerpującego przeglądu modern albo liczbę dodatnią dla mniejszego limitu. -- Jak wybierać dostawców (unikaj „wszystko z OpenRouter”): - - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (allowlist oddzielana przecinkami) -- Sondy narzędzi i obrazów są zawsze włączone w tym teście live: + - Domyślnie: nowoczesna allowlista (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4) + - `OPENCLAW_LIVE_GATEWAY_MODELS=all` jest aliasem dla nowoczesnej allowlisty + - Albo ustaw `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (lub listę rozdzielaną przecinkami), aby zawęzić + - Przeglądy gateway modern/all domyślnie używają kuratorowanego limitu o wysokim sygnale; ustaw `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` dla wyczerpującego przeglądu modern albo dodatnią liczbę dla mniejszego limitu. +- Jak wybierać dostawców (aby uniknąć „wszystkiego z OpenRouter”): + - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (allowlista rozdzielana przecinkami) +- Sondy narzędzi + obrazu są zawsze włączone w tym teście live: - sonda `read` + sonda `exec+read` (obciążenie narzędzi) - - sonda obrazu uruchamia się, gdy model deklaruje obsługę wejścia obrazowego + - sonda obrazu działa, gdy model deklaruje obsługę wejścia obrazowego - Przepływ (na wysokim poziomie): - - Test generuje mały PNG z napisem „CAT” + losowy kod (`src/gateway/live-image-probe.ts`) + - Test generuje mały PNG z napisem „CAT” + losowym kodem (`src/gateway/live-image-probe.ts`) - Wysyła go przez `agent` `attachments: [{ mimeType: "image/png", content: "" }]` - Gateway parsuje załączniki do `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) - - Embedded agent przekazuje do modelu multimodalną wiadomość użytkownika - - Asercja: odpowiedź zawiera `cat` + kod (tolerancja OCR: drobne pomyłki są dozwolone) + - Osadzony agent przekazuje do modelu multimodalną wiadomość użytkownika + - Asercja: odpowiedź zawiera `cat` + kod (tolerancja OCR: drobne błędy są dozwolone) Wskazówka: aby zobaczyć, co możesz testować na swojej maszynie (oraz dokładne identyfikatory `provider/model`), uruchom: @@ -374,22 +453,22 @@ openclaw models list --json ## Live: smoke backendu CLI (Claude, Codex, Gemini lub inne lokalne CLI) - Test: `src/gateway/gateway-cli-backend.live.test.ts` -- Cel: zweryfikować pipeline Gateway + agenta przy użyciu lokalnego backendu CLI, bez naruszania domyślnej konfiguracji. -- Domyślne ustawienia smoke specyficzne dla backendu znajdują się w definicji `cli-backend.ts` należącej do danego rozszerzenia. +- Cel: zweryfikować pipeline Gateway + agent przy użyciu lokalnego backendu CLI, bez naruszania domyślnej konfiguracji. +- Domyślne ustawienia smoke specyficzne dla backendu znajdują się w definicji `cli-backend.ts` należącej do odpowiedniego rozszerzenia. - Włączanie: - `pnpm test:live` (lub `OPENCLAW_LIVE_TEST=1`, jeśli wywołujesz Vitest bezpośrednio) - `OPENCLAW_LIVE_CLI_BACKEND=1` - Domyślne ustawienia: - Domyślny dostawca/model: `claude-cli/claude-sonnet-4-6` - - Zachowanie command/args/image pochodzi z metadanych pluginu właściciela backendu CLI. + - Zachowanie polecenia/argumentów/obrazu pochodzi z metadanych Plugin odpowiedzialnego za backend CLI. - Nadpisania (opcjonalne): - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.4"` - `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"` - `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'` - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1`, aby wysłać rzeczywisty załącznik obrazu (ścieżki są wstrzykiwane do promptu). - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, aby przekazywać ścieżki plików obrazów jako argumenty CLI zamiast przez wstrzyknięcie do promptu. - - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (lub `"list"`), aby kontrolować sposób przekazywania argumentów obrazów, gdy ustawione jest `IMAGE_ARG`. - - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, aby wysłać drugą turę i zweryfikować przepływ wznawiania. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, aby przekazywać ścieżki plików obrazów jako argumenty CLI zamiast przez wstrzykiwanie do promptu. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (lub `"list"`), aby sterować sposobem przekazywania argumentów obrazów, gdy ustawiono `IMAGE_ARG`. + - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, aby wysłać drugą turę i zweryfikować przepływ wznowienia. - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0`, aby wyłączyć domyślną sondę ciągłości tej samej sesji Claude Sonnet -> Opus (ustaw `1`, aby wymusić jej włączenie, gdy wybrany model obsługuje cel przełączenia). Przykład: @@ -417,26 +496,26 @@ pnpm test:docker:live-cli-backend:gemini Uwagi: -- Runner Docker znajduje się w `scripts/test-live-cli-backend-docker.sh`. -- Uruchamia smoke live backendu CLI wewnątrz obrazu Docker repozytorium jako użytkownik niebędący rootem `node`. -- Rozwiązuje metadane smoke CLI z rozszerzenia będącego właścicielem, a następnie instaluje pasujący pakiet CLI dla Linuxa (`@anthropic-ai/claude-code`, `@openai/codex` lub `@google/gemini-cli`) do cache’owanego zapisywalnego prefiksu w `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (domyślnie: `~/.cache/openclaw/docker-cli-tools`). -- `pnpm test:docker:live-cli-backend:claude-subscription` wymaga przenośnego OAuth subskrypcji Claude Code przez `~/.claude/.credentials.json` z `claudeAiOauth.subscriptionType` albo `CLAUDE_CODE_OAUTH_TOKEN` z `claude setup-token`. Najpierw potwierdza bezpośrednie `claude -p` w Dockerze, a następnie uruchamia dwie tury backendu CLI Gateway bez zachowywania zmiennych env klucza API Anthropic. Ta ścieżka subskrypcyjna domyślnie wyłącza sondy Claude MCP/tool oraz obrazu, ponieważ Claude obecnie kieruje użycie aplikacji zewnętrznych przez rozliczanie extra-usage zamiast zwykłych limitów planu subskrypcyjnego. -- Smoke live backendu CLI wykonuje teraz ten sam przepływ end-to-end dla Claude, Codex i Gemini: tura tekstowa, tura klasyfikacji obrazu, a następnie wywołanie narzędzia MCP `cron` zweryfikowane przez CLI Gateway. -- Domyślny smoke Claude dodatkowo patchuje sesję z Sonnet do Opus i weryfikuje, że wznowiona sesja nadal pamięta wcześniejszą notatkę. +- Uruchamiacz Docker znajduje się w `scripts/test-live-cli-backend-docker.sh`. +- Uruchamia smoke live backendu CLI wewnątrz obrazu Docker repozytorium jako użytkownik nieuprzywilejowany `node`. +- Rozwiązuje metadane smoke CLI z odpowiedniego rozszerzenia, a następnie instaluje pasujący pakiet Linux CLI (`@anthropic-ai/claude-code`, `@openai/codex` lub `@google/gemini-cli`) do cache’owanego zapisywalnego prefiksu w `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (domyślnie: `~/.cache/openclaw/docker-cli-tools`). +- `pnpm test:docker:live-cli-backend:claude-subscription` wymaga przenośnego OAuth subskrypcji Claude Code przez `~/.claude/.credentials.json` z `claudeAiOauth.subscriptionType` lub `CLAUDE_CODE_OAUTH_TOKEN` z `claude setup-token`. Najpierw potwierdza bezpośrednie `claude -p` w Docker, a następnie uruchamia dwie tury backendu CLI Gateway bez zachowywania zmiennych env z kluczem API Anthropic. Ta linia subskrypcyjna domyślnie wyłącza sondy Claude MCP/tool i obrazu, ponieważ Claude obecnie rozlicza użycie aplikacji zewnętrznych przez billing extra-usage zamiast zwykłych limitów planu subskrypcji. +- Smoke live backendu CLI testuje teraz ten sam przepływ end-to-end dla Claude, Codex i Gemini: tura tekstowa, tura klasyfikacji obrazu, a następnie wywołanie narzędzia MCP `cron` zweryfikowane przez CLI Gateway. +- Domyślny smoke Claude dodatkowo patchuje sesję z Sonnet do Opus i sprawdza, czy wznowiona sesja nadal pamięta wcześniejszą notatkę. -## Live: smoke bind ACP (`/acp spawn ... --bind here`) +## Live: smoke powiązania ACP (`/acp spawn ... --bind here`) - Test: `src/gateway/gateway-acp-bind.live.test.ts` -- Cel: zweryfikować rzeczywisty przepływ conversation-bind ACP z live agentem ACP: +- Cel: zweryfikować rzeczywisty przepływ powiązania rozmowy ACP z aktywnym agentem ACP: - wysłać `/acp spawn --bind here` - - związać syntetyczną rozmowę kanału wiadomości na miejscu + - powiązać syntetyczną rozmowę kanału wiadomości w miejscu - wysłać zwykły follow-up w tej samej rozmowie - - zweryfikować, że follow-up trafia do transkryptu związanej sesji ACP + - zweryfikować, że follow-up trafia do transkryptu powiązanej sesji ACP - Włączanie: - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts` - `OPENCLAW_LIVE_ACP_BIND=1` - Domyślne ustawienia: - - Agenci ACP w Dockerze: `claude,codex,gemini` + - Agenci ACP w Docker: `claude,codex,gemini` - Agent ACP dla bezpośredniego `pnpm test:live ...`: `claude` - Syntetyczny kanał: kontekst rozmowy w stylu Slack DM - Backend ACP: `acpx` @@ -447,8 +526,8 @@ Uwagi: - `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini` - `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@'` - Uwagi: - - Ta ścieżka używa powierzchni Gateway `chat.send` z polami syntetycznej trasy pochodzenia dostępnymi tylko dla administratora, dzięki czemu testy mogą dołączać kontekst kanału wiadomości bez udawania dostarczenia z zewnątrz. - - Gdy `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` nie jest ustawione, test używa wbudowanego rejestru agentów pluginu `acpx` dla wybranego agenta harnessu ACP. + - Ta linia używa powierzchni `chat.send` Gateway z polami synthetic originating-route dostępnymi tylko dla administratora, dzięki czemu testy mogą dołączać kontekst kanału wiadomości bez udawania zewnętrznego dostarczenia. + - Gdy `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` nie jest ustawione, test używa wbudowanego rejestru agentów Plugin `acpx` dla wybranego agenta harnessu ACP. Przykład: @@ -472,36 +551,36 @@ pnpm test:docker:live-acp-bind:codex pnpm test:docker:live-acp-bind:gemini ``` -Uwagi dotyczące Dockera: +Uwagi dotyczące Docker: -- Runner Docker znajduje się w `scripts/test-live-acp-bind-docker.sh`. -- Domyślnie uruchamia smoke bind ACP kolejno dla wszystkich obsługiwanych live agentów CLI: `claude`, `codex`, a następnie `gemini`. +- Uruchamiacz Docker znajduje się w `scripts/test-live-acp-bind-docker.sh`. +- Domyślnie uruchamia smoke powiązania ACP kolejno dla wszystkich obsługiwanych aktywnych agentów CLI: `claude`, `codex`, a następnie `gemini`. - Użyj `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex` lub `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini`, aby zawęzić macierz. -- Pobiera `~/.profile`, przygotowuje odpowiednie materiały uwierzytelniające CLI w kontenerze, instaluje `acpx` do zapisywalnego prefiksu npm, a następnie instaluje żądane live CLI (`@anthropic-ai/claude-code`, `@openai/codex` lub `@google/gemini-cli`), jeśli go brakuje. -- Wewnątrz Dockera runner ustawia `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, aby `acpx` zachowywało zmienne env dostawcy z pobranego profilu dostępne dla podrzędnego CLI harnessu. +- Pobiera `~/.profile`, przygotowuje pasujące materiały uwierzytelniające CLI w kontenerze, instaluje `acpx` do zapisywalnego prefiksu npm, a następnie instaluje żądane aktywne CLI (`@anthropic-ai/claude-code`, `@openai/codex` lub `@google/gemini-cli`), jeśli go brakuje. +- Wewnątrz Docker uruchamiacz ustawia `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, aby `acpx` zachował zmienne env dostawcy z pobranego profilu dostępne dla podrzędnego CLI harnessu. -## Live: smoke harnessu Codex app-server +## Live: smoke harnessu app-server Codex -- Cel: zweryfikować należący do pluginu harness Codex przez zwykłą metodę Gateway - `agent`: - - załadować bundlowany plugin `codex` +- Cel: zweryfikować należący do Plugin harness Codex przez normalną + metodę `agent` Gateway: + - załadować bundlowany Plugin `codex` - wybrać `OPENCLAW_AGENT_RUNTIME=codex` - - wysłać pierwszą turę Gateway agent do `codex/gpt-5.4` - - wysłać drugą turę do tej samej sesji OpenClaw i zweryfikować, że wątek app-server - może zostać wznowiony + - wysłać pierwszą turę agenta Gateway do `codex/gpt-5.4` + - wysłać drugą turę do tej samej sesji OpenClaw i zweryfikować, że wątek + app-server może zostać wznowiony - uruchomić `/codex status` oraz `/codex models` przez tę samą ścieżkę poleceń Gateway - Test: `src/gateway/gateway-codex-harness.live.test.ts` - Włączanie: `OPENCLAW_LIVE_CODEX_HARNESS=1` - Domyślny model: `codex/gpt-5.4` - Opcjonalna sonda obrazu: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` -- Opcjonalna sonda MCP/narzędzi: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` -- Smoke ustawia `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, aby zepsuty - harness Codex nie mógł przejść testu przez ciche przełączenie na PI. -- Auth: `OPENAI_API_KEY` z powłoki/profilu oraz opcjonalnie skopiowane +- Opcjonalna sonda MCP/tool: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` +- Ten smoke ustawia `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, aby uszkodzony + harness Codex nie mógł przejść przez cichy fallback do PI. +- Uwierzytelnianie: `OPENAI_API_KEY` z powłoki/profilu oraz opcjonalnie skopiowane `~/.codex/auth.json` i `~/.codex/config.toml` -Recepta lokalna: +Lokalna recepta: ```bash source ~/.profile @@ -519,16 +598,16 @@ source ~/.profile pnpm test:docker:live-codex-harness ``` -Uwagi dotyczące Dockera: +Uwagi dotyczące Docker: -- Runner Docker znajduje się w `scripts/test-live-codex-harness-docker.sh`. +- Uruchamiacz Docker znajduje się w `scripts/test-live-codex-harness-docker.sh`. - Pobiera zamontowane `~/.profile`, przekazuje `OPENAI_API_KEY`, kopiuje pliki - uwierzytelniające CLI Codex, jeśli są obecne, instaluje `@openai/codex` do zapisywalnego zamontowanego prefiksu npm, + uwierzytelniające CLI Codex, gdy są dostępne, instaluje `@openai/codex` do zapisywalnego zamontowanego prefiksu npm, przygotowuje drzewo źródłowe, a następnie uruchamia tylko test live harnessu Codex. -- Docker domyślnie włącza sondy obrazu oraz MCP/narzędzi. Ustaw +- Docker domyślnie włącza sondy obrazu oraz MCP/tool. Ustaw `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` lub `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0`, gdy potrzebujesz węższego uruchomienia debugowego. -- Docker eksportuje też `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, zgodnie z konfiguracją testu live, dzięki czemu fallback `openai-codex/*` lub PI nie może ukryć regresji harnessu Codex. +- Docker eksportuje również `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, zgodnie z konfiguracją testu live, aby fallback `openai-codex/*` lub PI nie mógł ukryć regresji harnessu Codex. ### Zalecane recepty live @@ -540,7 +619,7 @@ Wąskie, jawne allowlisty są najszybsze i najmniej podatne na niestabilność: - Pojedynczy model, smoke Gateway: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -- Wywoływanie narzędzi przez kilku dostawców: +- Wywoływanie narzędzi u kilku dostawców: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Skupienie na Google (klucz API Gemini + Antigravity): @@ -549,25 +628,25 @@ Wąskie, jawne allowlisty są najszybsze i najmniej podatne na niestabilność: Uwagi: -- `google/...` używa API Gemini (klucz API). +- `google/...` używa Gemini API (klucz API). - `google-antigravity/...` używa mostu OAuth Antigravity (endpoint agenta w stylu Cloud Code Assist). -- `google-gemini-cli/...` używa lokalnego CLI Gemini na Twojej maszynie (osobne uwierzytelnianie + niuanse narzędzi). -- API Gemini vs CLI Gemini: - - API: OpenClaw wywołuje hostowane API Gemini Google przez HTTP (uwierzytelnianie kluczem API / profilem); to właśnie większość użytkowników ma na myśli, mówiąc „Gemini”. - - CLI: OpenClaw wywołuje lokalne binarium `gemini`; ma ono własne uwierzytelnianie i może zachowywać się inaczej (streaming/obsługa narzędzi/rozjazd wersji). +- `google-gemini-cli/...` używa lokalnego Gemini CLI na twojej maszynie (osobne uwierzytelnianie + niuanse narzędzi). +- Gemini API vs Gemini CLI: + - API: OpenClaw wywołuje hostowane Gemini API Google przez HTTP (uwierzytelnianie kluczem API / profilem); to właśnie większość użytkowników ma na myśli, mówiąc „Gemini”. + - CLI: OpenClaw wywołuje lokalny binarny plik `gemini`; ma własne uwierzytelnianie i może zachowywać się inaczej (streaming/obsługa narzędzi/rozbieżność wersji). ## Live: macierz modeli (co obejmujemy) -Nie ma stałej „listy modeli CI” (live jest opt-in), ale to są **zalecane** modele do regularnego obejmowania testami na maszynie deweloperskiej z kluczami. +Nie ma stałej „listy modeli CI” (live jest opt-in), ale to są **zalecane** modele do regularnego pokrywania na maszynie deweloperskiej z kluczami. ### Nowoczesny zestaw smoke (wywoływanie narzędzi + obraz) -To jest uruchomienie „typowych modeli”, które oczekujemy utrzymywać w działaniu: +To jest uruchomienie „typowych modeli”, które oczekujemy utrzymać w działaniu: -- OpenAI (nie-Codex): `openai/gpt-5.4` (opcjonalnie: `openai/gpt-5.4-mini`) +- OpenAI (bez Codex): `openai/gpt-5.4` (opcjonalnie: `openai/gpt-5.4-mini`) - OpenAI Codex: `openai-codex/gpt-5.4` - Anthropic: `anthropic/claude-opus-4-6` (lub `anthropic/claude-sonnet-4-6`) -- Google (API Gemini): `google/gemini-3.1-pro-preview` oraz `google/gemini-3-flash-preview` (unikaj starszych modeli Gemini 2.x) +- Google (Gemini API): `google/gemini-3.1-pro-preview` oraz `google/gemini-3-flash-preview` (unikaj starszych modeli Gemini 2.x) - Google (Antigravity): `google-antigravity/claude-opus-4-6-thinking` oraz `google-antigravity/gemini-3-flash` - Z.AI (GLM): `zai/glm-4.7` - MiniMax: `minimax/MiniMax-M2.7` @@ -575,7 +654,7 @@ To jest uruchomienie „typowych modeli”, które oczekujemy utrzymywać w dzia Uruchom smoke Gateway z narzędziami + obrazem: `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,openai-codex/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` -### Podstawa: wywoływanie narzędzi (Read + opcjonalnie Exec) +### Linia bazowa: wywoływanie narzędzi (Read + opcjonalnie Exec) Wybierz co najmniej jeden model z każdej rodziny dostawców: @@ -585,44 +664,44 @@ Wybierz co najmniej jeden model z każdej rodziny dostawców: - Z.AI (GLM): `zai/glm-4.7` - MiniMax: `minimax/MiniMax-M2.7` -Opcjonalne dodatkowe pokrycie (dobrze mieć): +Opcjonalne dodatkowe pokrycie (warto mieć): - xAI: `xai/grok-4` (lub najnowszy dostępny) -- Mistral: `mistral/`… (wybierz jeden model z obsługą „tools”, który masz włączony) +- Mistral: `mistral/`… (wybierz jeden model z włączoną obsługą „tools”, do którego masz dostęp) - Cerebras: `cerebras/`… (jeśli masz dostęp) - LM Studio: `lmstudio/`… (lokalnie; wywoływanie narzędzi zależy od trybu API) ### Vision: wysyłanie obrazu (załącznik → wiadomość multimodalna) -Uwzględnij co najmniej jeden model obsługujący obrazy w `OPENCLAW_LIVE_GATEWAY_MODELS` (warianty Claude/Gemini/OpenAI z obsługą vision itd.), aby wykonać sondę obrazu. +Uwzględnij co najmniej jeden model z obsługą obrazu w `OPENCLAW_LIVE_GATEWAY_MODELS` (warianty Claude/Gemini/OpenAI z obsługą vision itd.), aby przetestować sondę obrazu. -### Agregatory / alternatywne bramy +### Agregatory / alternatywne Gateway -Jeśli masz włączone klucze, obsługujemy także testowanie przez: +Jeśli masz włączone klucze, obsługujemy też testowanie przez: -- OpenRouter: `openrouter/...` (setki modeli; użyj `openclaw models scan`, aby znaleźć kandydatów z obsługą narzędzi i obrazów) -- OpenCode: `opencode/...` dla Zen oraz `opencode-go/...` dla Go (uwierzytelnianie przez `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) +- OpenRouter: `openrouter/...` (setki modeli; użyj `openclaw models scan`, aby znaleźć kandydatów z obsługą narzędzi+obrazu) +- OpenCode: `opencode/...` dla Zen i `opencode-go/...` dla Go (uwierzytelnianie przez `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) Więcej dostawców, których możesz uwzględnić w macierzy live (jeśli masz poświadczenia/konfigurację): - Wbudowani: `openai`, `openai-codex`, `anthropic`, `google`, `google-vertex`, `google-antigravity`, `google-gemini-cli`, `zai`, `openrouter`, `opencode`, `opencode-go`, `xai`, `groq`, `cerebras`, `mistral`, `github-copilot` -- Przez `models.providers` (niestandardowe endpointy): `minimax` (chmura/API) oraz dowolny proxy zgodny z OpenAI/Anthropic (LM Studio, vLLM, LiteLLM itd.) +- Przez `models.providers` (własne endpointy): `minimax` (cloud/API), plus dowolny proxy zgodny z OpenAI/Anthropic (LM Studio, vLLM, LiteLLM itd.) -Wskazówka: nie próbuj na sztywno wpisywać „wszystkich modeli” w dokumentacji. Listą źródłową jest to, co zwraca `discoverModels(...)` na Twojej maszynie + jakie klucze są dostępne. +Wskazówka: nie próbuj wpisywać na stałe „wszystkich modeli” w dokumentacji. Autorytatywna lista to to, co `discoverModels(...)` zwraca na twojej maszynie + jakie klucze są dostępne. ## Poświadczenia (nigdy nie commituj) -Testy live wykrywają poświadczenia tak samo jak CLI. Konsekwencje praktyczne: +Testy live wykrywają poświadczenia w ten sam sposób, co CLI. Praktyczne konsekwencje: -- Jeśli CLI działa, testy live powinny znaleźć te same klucze. +- Jeśli działa CLI, testy live powinny znaleźć te same klucze. - Jeśli test live mówi „brak poświadczeń”, debuguj to tak samo, jak debugowałbyś `openclaw models list` / wybór modelu. -- Profile uwierzytelniania per agent: `~/.openclaw/agents//agent/auth-profiles.json` (to właśnie oznacza „profile keys” w testach live) +- Profile uwierzytelniania per agent: `~/.openclaw/agents//agent/auth-profiles.json` (to właśnie oznaczają „profile keys” w testach live) - Konfiguracja: `~/.openclaw/openclaw.json` (lub `OPENCLAW_CONFIG_PATH`) -- Starszy katalog stanu: `~/.openclaw/credentials/` (kopiowany do przygotowanego katalogu live, gdy istnieje, ale nie jest głównym magazynem kluczy profili) -- Lokalne uruchomienia live domyślnie kopiują aktywną konfigurację, pliki `auth-profiles.json` per agent, starszy katalog `credentials/` oraz obsługiwane zewnętrzne katalogi uwierzytelniania CLI do tymczasowego katalogu testowego; przygotowane katalogi live pomijają `workspace/` i `sandboxes/`, a nadpisania ścieżek `agents.*.workspace` / `agentDir` są usuwane, aby sondy nie działały na Twoim rzeczywistym obszarze roboczym hosta. +- Starszy katalog stanu: `~/.openclaw/credentials/` (kopiowany do przygotowanego katalogu domowego live, jeśli istnieje, ale nie jest głównym magazynem kluczy profili) +- Lokalne uruchomienia live domyślnie kopiują aktywną konfigurację, pliki `auth-profiles.json` per agent, starszy katalog `credentials/` oraz obsługiwane zewnętrzne katalogi uwierzytelniania CLI do tymczasowego katalogu domowego testu; przygotowane katalogi domowe live pomijają `workspace/` i `sandboxes/`, a nadpisania ścieżek `agents.*.workspace` / `agentDir` są usuwane, aby sondy nie działały w twoim rzeczywistym obszarze roboczym hosta. -Jeśli chcesz polegać na kluczach z env (np. wyeksportowanych w `~/.profile`), uruchamiaj testy lokalne po `source ~/.profile` albo użyj poniższych runnerów Docker (mogą zamontować `~/.profile` do kontenera). +Jeśli chcesz polegać na kluczach env (np. wyeksportowanych w `~/.profile`), uruchamiaj testy lokalne po `source ~/.profile` albo użyj poniższych uruchamiaczy Docker (mogą montować `~/.profile` do kontenera). ## Live: Deepgram (transkrypcja audio) @@ -640,9 +719,9 @@ Jeśli chcesz polegać na kluczach z env (np. wyeksportowanych w `~/.profile`), - Test: `extensions/comfy/comfy.live.test.ts` - Włączanie: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` - Zakres: - - Testuje bundlowane ścieżki obrazu, wideo i `music_generate` Comfy + - Testuje bundlowane ścieżki obrazu, wideo i `music_generate` comfy - Pomija każdą możliwość, jeśli `models.providers.comfy.` nie jest skonfigurowane - - Przydatne po zmianach w wysyłaniu workflow Comfy, odpytywaniu, pobieraniu lub rejestracji pluginu + - Przydatne po zmianach w wysyłaniu workflow comfy, odpytywaniu, pobieraniu lub rejestracji Plugin ## Live: generowanie obrazów @@ -650,10 +729,10 @@ Jeśli chcesz polegać na kluczach z env (np. wyeksportowanych w `~/.profile`), - Polecenie: `pnpm test:live src/image-generation/runtime.live.test.ts` - Harness: `pnpm test:live:media image` - Zakres: - - Wylicza każdy zarejestrowany plugin dostawcy generowania obrazów - - Przed sondowaniem doładowuje brakujące zmienne env dostawców z powłoki logowania (`~/.profile`) - - Domyślnie używa kluczy API live/env przed zapisanymi profilami auth, aby nieaktualne klucze testowe w `auth-profiles.json` nie maskowały rzeczywistych poświadczeń z powłoki - - Pomija dostawców bez używalnego uwierzytelnienia/profilu/modelu + - Wylicza każdy zarejestrowany Plugin dostawcy generowania obrazów + - Ładuje brakujące zmienne env dostawców z twojej powłoki logowania (`~/.profile`) przed sondowaniem + - Domyślnie używa aktywnych/env kluczy API przed zapisanymi profilami uwierzytelniania, aby nieaktualne klucze testowe w `auth-profiles.json` nie maskowały rzeczywistych poświadczeń powłoki + - Pomija dostawców bez użytecznego uwierzytelniania/profilu/modelu - Uruchamia standardowe warianty generowania obrazów przez współdzieloną możliwość runtime: - `google:flash-generate` - `google:pro-generate` @@ -675,15 +754,15 @@ Jeśli chcesz polegać na kluczach z env (np. wyeksportowanych w `~/.profile`), - Włączanie: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts` - Harness: `pnpm test:live:media music` - Zakres: - - Testuje współdzieloną bundlowaną ścieżkę dostawców generowania muzyki + - Testuje współdzieloną bundlowaną ścieżkę dostawcy generowania muzyki - Obecnie obejmuje Google i MiniMax - - Przed sondowaniem doładowuje zmienne env dostawców z powłoki logowania (`~/.profile`) - - Domyślnie używa kluczy API live/env przed zapisanymi profilami auth, aby nieaktualne klucze testowe w `auth-profiles.json` nie maskowały rzeczywistych poświadczeń z powłoki - - Pomija dostawców bez używalnego uwierzytelnienia/profilu/modelu + - Ładuje zmienne env dostawców z twojej powłoki logowania (`~/.profile`) przed sondowaniem + - Domyślnie używa aktywnych/env kluczy API przed zapisanymi profilami uwierzytelniania, aby nieaktualne klucze testowe w `auth-profiles.json` nie maskowały rzeczywistych poświadczeń powłoki + - Pomija dostawców bez użytecznego uwierzytelniania/profilu/modelu - Uruchamia oba zadeklarowane tryby runtime, gdy są dostępne: - - `generate` z wejściem zawierającym tylko prompt + - `generate` z wejściem opartym wyłącznie na prompcie - `edit`, gdy dostawca deklaruje `capabilities.edit.enabled` - - Bieżące pokrycie we współdzielonej ścieżce: + - Obecne pokrycie współdzielonej linii: - `google`: `generate`, `edit` - `minimax`: `generate` - `comfy`: osobny plik live Comfy, nie ten współdzielony przegląd @@ -699,25 +778,25 @@ Jeśli chcesz polegać na kluczach z env (np. wyeksportowanych w `~/.profile`), - Włączanie: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts` - Harness: `pnpm test:live:media video` - Zakres: - - Testuje współdzieloną bundlowaną ścieżkę dostawców generowania wideo - - Przed sondowaniem doładowuje zmienne env dostawców z powłoki logowania (`~/.profile`) - - Domyślnie używa kluczy API live/env przed zapisanymi profilami auth, aby nieaktualne klucze testowe w `auth-profiles.json` nie maskowały rzeczywistych poświadczeń z powłoki - - Pomija dostawców bez używalnego uwierzytelnienia/profilu/modelu + - Testuje współdzieloną bundlowaną ścieżkę dostawcy generowania wideo + - Ładuje zmienne env dostawców z twojej powłoki logowania (`~/.profile`) przed sondowaniem + - Domyślnie używa aktywnych/env kluczy API przed zapisanymi profilami uwierzytelniania, aby nieaktualne klucze testowe w `auth-profiles.json` nie maskowały rzeczywistych poświadczeń powłoki + - Pomija dostawców bez użytecznego uwierzytelniania/profilu/modelu - Uruchamia oba zadeklarowane tryby runtime, gdy są dostępne: - - `generate` z wejściem zawierającym tylko prompt - - `imageToVideo`, gdy dostawca deklaruje `capabilities.imageToVideo.enabled` i wybrany dostawca/model akceptuje w tym współdzielonym przeglądzie lokalne wejście obrazowe oparte na buforze - - `videoToVideo`, gdy dostawca deklaruje `capabilities.videoToVideo.enabled` i wybrany dostawca/model akceptuje w tym współdzielonym przeglądzie lokalne wejście wideo oparte na buforze - - Obecnie zadeklarowani, ale pomijani dostawcy `imageToVideo` we współdzielonym przeglądzie: - - `vydra`, ponieważ bundlowany `veo3` jest tylko tekstowy, a bundlowany `kling` wymaga zdalnego URL obrazu + - `generate` z wejściem opartym wyłącznie na prompcie + - `imageToVideo`, gdy dostawca deklaruje `capabilities.imageToVideo.enabled` i wybrany dostawca/model akceptuje wejście lokalnego obrazu oparte na buforze we współdzielonym przeglądzie + - `videoToVideo`, gdy dostawca deklaruje `capabilities.videoToVideo.enabled` i wybrany dostawca/model akceptuje wejście lokalnego wideo oparte na buforze we współdzielonym przeglądzie + - Obecni zadeklarowani, ale pomijani dostawcy `imageToVideo` we współdzielonym przeglądzie: + - `vydra`, ponieważ bundlowany `veo3` jest tylko tekstowy, a bundlowany `kling` wymaga zdalnego adresu URL obrazu - Pokrycie Vydra specyficzne dla dostawcy: - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts` - - ten plik uruchamia `veo3` text-to-video oraz ścieżkę `kling`, która domyślnie używa fixture zdalnego URL obrazu - - Bieżące pokrycie live `videoToVideo`: - - tylko `runway`, gdy wybranym modelem jest `runway/gen4_aleph` - - Obecnie zadeklarowani, ale pomijani dostawcy `videoToVideo` we współdzielonym przeglądzie: - - `alibaba`, `qwen`, `xai`, ponieważ te ścieżki obecnie wymagają zdalnych referencyjnych URL `http(s)` / MP4 - - `google`, ponieważ bieżąca współdzielona ścieżka Gemini/Veo używa lokalnego wejścia opartego na buforze i ta ścieżka nie jest akceptowana we współdzielonym przeglądzie - - `openai`, ponieważ bieżąca współdzielona ścieżka nie gwarantuje dostępu do funkcji org-specyficznych dla video inpaint/remix + - ten plik uruchamia `veo3` text-to-video oraz linię `kling`, która domyślnie używa fixture zdalnego adresu URL obrazu + - Obecne pokrycie live `videoToVideo`: + - tylko `runway`, gdy wybrany model to `runway/gen4_aleph` + - Obecni zadeklarowani, ale pomijani dostawcy `videoToVideo` we współdzielonym przeglądzie: + - `alibaba`, `qwen`, `xai`, ponieważ te ścieżki obecnie wymagają zdalnych referencyjnych adresów URL `http(s)` / MP4 + - `google`, ponieważ obecna współdzielona linia Gemini/Veo używa lokalnego wejścia opartego na buforze i ta ścieżka nie jest akceptowana we współdzielonym przeglądzie + - `openai`, ponieważ obecna współdzielona linia nie gwarantuje organizacyjnego dostępu do video inpaint/remix - Opcjonalne zawężanie: - `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="google,openai,runway"` - `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"` @@ -728,139 +807,138 @@ Jeśli chcesz polegać na kluczach z env (np. wyeksportowanych w `~/.profile`), - Polecenie: `pnpm test:live:media` - Cel: - - Uruchamia współdzielone pakiety live dla obrazów, muzyki i wideo przez jeden natywny dla repozytorium punkt wejścia - - Automatycznie doładowuje brakujące zmienne env dostawców z `~/.profile` - - Domyślnie automatycznie zawęża każdy pakiet do dostawców, którzy aktualnie mają używalne uwierzytelnianie - - Ponownie używa `scripts/test-live.mjs`, dzięki czemu zachowanie Heartbeat i trybu cichego pozostaje spójne + - Uruchamia współdzielone pakiety live dla obrazów, muzyki i wideo przez jedno natywne wejście repozytorium + - Automatycznie ładuje brakujące zmienne env dostawców z `~/.profile` + - Domyślnie automatycznie zawęża każdy pakiet do dostawców, którzy aktualnie mają użyteczne uwierzytelnianie + - Ponownie używa `scripts/test-live.mjs`, więc zachowanie Heartbeat i trybu cichego pozostaje spójne - Przykłady: - `pnpm test:live:media` - `pnpm test:live:media image video --providers openai,google,minimax` - `pnpm test:live:media video --video-providers openai,runway --all-providers` - `pnpm test:live:media music --quiet` -## Runnery Docker (opcjonalne testy typu „działa na Linuxie”) +## Uruchamiacze Docker (opcjonalne testy „działa w Linux”) -Te runnery Docker dzielą się na dwa koszyki: +Te uruchamiacze Docker dzielą się na dwie kategorie: -- Runnery live-modeli: `test:docker:live-models` i `test:docker:live-gateway` uruchamiają tylko odpowiadający im plik live z kluczami profili wewnątrz obrazu Docker repozytorium (`src/agents/models.profiles.live.test.ts` i `src/gateway/gateway-models.profiles.live.test.ts`), montując lokalny katalog konfiguracji i obszar roboczy (oraz wykonując `source ~/.profile`, jeśli jest zamontowany). Odpowiadające im lokalne punkty wejścia to `test:live:models-profiles` i `test:live:gateway-profiles`. -- Runnery live Docker domyślnie używają mniejszego limitu smoke, aby pełny przegląd w Dockerze pozostawał praktyczny: +- Uruchamiacze live-model: `test:docker:live-models` i `test:docker:live-gateway` uruchamiają tylko odpowiadający im plik live z kluczami profili wewnątrz obrazu Docker repozytorium (`src/agents/models.profiles.live.test.ts` i `src/gateway/gateway-models.profiles.live.test.ts`), montując lokalny katalog konfiguracji i obszar roboczy (oraz pobierając `~/.profile`, jeśli jest zamontowany). Odpowiadające im lokalne punkty wejścia to `test:live:models-profiles` i `test:live:gateway-profiles`. +- Uruchamiacze Docker live domyślnie używają mniejszego limitu smoke, aby pełny przegląd Docker pozostawał praktyczny: `test:docker:live-models` domyślnie ustawia `OPENCLAW_LIVE_MAX_MODELS=12`, a `test:docker:live-gateway` domyślnie ustawia `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` oraz - `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Nadpisz te zmienne env, jeśli - świadomie chcesz uruchomić większy, wyczerpujący skan. -- `test:docker:all` buduje obraz live Docker raz przez `test:docker:live-build`, a następnie ponownie używa go dla dwóch ścieżek live Docker. -- Runnery smoke kontenerów: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` oraz `test:docker:plugins` uruchamiają jeden lub więcej rzeczywistych kontenerów i weryfikują integrację na wyższym poziomie. + `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Nadpisz te zmienne env, gdy + celowo chcesz większego, wyczerpującego przeglądu. +- `test:docker:all` buduje obraz Docker live raz przez `test:docker:live-build`, a następnie ponownie używa go dla dwóch linii Docker live. +- Uruchamiacze smoke kontenerów: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` oraz `test:docker:plugins` uruchamiają jeden lub więcej rzeczywistych kontenerów i weryfikują ścieżki integracji wyższego poziomu. -Runnery Docker live-modeli montują też bindem tylko potrzebne katalogi uwierzytelniania CLI (albo wszystkie obsługiwane, gdy uruchomienie nie jest zawężone), a następnie kopiują je do katalogu domowego kontenera przed uruchomieniem, aby zewnętrzny OAuth CLI mógł odświeżać tokeny bez modyfikowania magazynu uwierzytelniania na hoście: +Uruchamiacze Docker live-model montują też tylko potrzebne katalogi domowe uwierzytelniania CLI (albo wszystkie obsługiwane, gdy uruchomienie nie jest zawężone), a następnie kopiują je do katalogu domowego kontenera przed uruchomieniem, aby zewnętrzny OAuth CLI mógł odświeżać tokeny bez modyfikowania magazynu uwierzytelniania hosta: -- Modele bezpośrednie: `pnpm test:docker:live-models` (skrypt: `scripts/test-live-models-docker.sh`) -- Smoke bind ACP: `pnpm test:docker:live-acp-bind` (skrypt: `scripts/test-live-acp-bind-docker.sh`) +- Bezpośrednie modele: `pnpm test:docker:live-models` (skrypt: `scripts/test-live-models-docker.sh`) +- Smoke powiązania ACP: `pnpm test:docker:live-acp-bind` (skrypt: `scripts/test-live-acp-bind-docker.sh`) - Smoke backendu CLI: `pnpm test:docker:live-cli-backend` (skrypt: `scripts/test-live-cli-backend-docker.sh`) -- Smoke harnessu Codex app-server: `pnpm test:docker:live-codex-harness` (skrypt: `scripts/test-live-codex-harness-docker.sh`) -- Gateway + agent deweloperski: `pnpm test:docker:live-gateway` (skrypt: `scripts/test-live-gateway-models-docker.sh`) +- Smoke harnessu app-server Codex: `pnpm test:docker:live-codex-harness` (skrypt: `scripts/test-live-codex-harness-docker.sh`) +- Gateway + agent developerski: `pnpm test:docker:live-gateway` (skrypt: `scripts/test-live-gateway-models-docker.sh`) - Smoke live Open WebUI: `pnpm test:docker:openwebui` (skrypt: `scripts/e2e/openwebui-docker.sh`) - Kreator onboardingu (TTY, pełne scaffoldowanie): `pnpm test:docker:onboard` (skrypt: `scripts/e2e/onboard-docker.sh`) - Sieć Gateway (dwa kontenery, uwierzytelnianie WS + health): `pnpm test:docker:gateway-network` (skrypt: `scripts/e2e/gateway-network-docker.sh`) -- Most kanałów MCP (zasiany Gateway + most stdio + smoke surowych ramek powiadomień Claude): `pnpm test:docker:mcp-channels` (skrypt: `scripts/e2e/mcp-channels-docker.sh`) +- Most kanałów MCP (seedowany Gateway + most stdio + smoke surowej ramki powiadomień Claude): `pnpm test:docker:mcp-channels` (skrypt: `scripts/e2e/mcp-channels-docker.sh`) - Pluginy (smoke instalacji + alias `/plugin` + semantyka restartu bundla Claude): `pnpm test:docker:plugins` (skrypt: `scripts/e2e/plugins-docker.sh`) -Runnery Docker live-modeli montują też bieżący checkout tylko do odczytu i -przygotowują go w tymczasowym katalogu roboczym wewnątrz kontenera. Dzięki temu -obraz runtime pozostaje smukły, a jednocześnie Vitest działa dokładnie na Twoim -lokalnym źródle/konfiguracji. -Etap przygotowania pomija duże lokalne cache i artefakty buildów aplikacji, takie jak -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` oraz lokalne dla aplikacji katalogi `.build` lub wyjścia Gradle, -dzięki czemu uruchomienia live w Dockerze nie tracą minut na kopiowanie +Uruchamiacze Docker live-model montują też bieżący checkout tylko do odczytu i +przygotowują go w tymczasowym katalogu roboczym wewnątrz kontenera. Dzięki temu obraz runtime +pozostaje lekki, a jednocześnie Vitest działa na dokładnie twojej lokalnej konfiguracji/źródłach. +Krok przygotowania pomija duże lokalne cache oraz wyniki buildów aplikacji, takie jak +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` oraz lokalne dla aplikacji katalogi `.build` lub +wyjścia Gradle, dzięki czemu uruchomienia Docker live nie tracą minut na kopiowanie artefaktów specyficznych dla maszyny. -Ustawiają też `OPENCLAW_SKIP_CHANNELS=1`, aby sondy Gateway live nie uruchamiały +Ustawiają też `OPENCLAW_SKIP_CHANNELS=1`, aby aktywne sondy Gateway nie uruchamiały rzeczywistych workerów kanałów Telegram/Discord/itd. wewnątrz kontenera. -`test:docker:live-models` nadal uruchamia `pnpm test:live`, więc przekazuj też -`OPENCLAW_LIVE_GATEWAY_*`, gdy musisz zawęzić lub wykluczyć pokrycie Gateway -live z tej ścieżki Dockera. -`test:docker:openwebui` to smoke zgodności na wyższym poziomie: uruchamia +`test:docker:live-models` nadal uruchamia `pnpm test:live`, więc przekazuj także +`OPENCLAW_LIVE_GATEWAY_*`, gdy chcesz zawęzić lub wykluczyć pokrycie Gateway +live z tej linii Docker. +`test:docker:openwebui` jest smoke zgodności wyższego poziomu: uruchamia kontener Gateway OpenClaw z włączonymi endpointami HTTP zgodnymi z OpenAI, -uruchamia przypięty kontener Open WebUI względem tego Gateway, loguje się przez +uruchamia przypięty kontener Open WebUI przeciwko temu Gateway, loguje się przez Open WebUI, weryfikuje, że `/api/models` udostępnia `openclaw/default`, a następnie wysyła rzeczywiste żądanie czatu przez proxy `/api/chat/completions` Open WebUI. Pierwsze uruchomienie może być zauważalnie wolniejsze, ponieważ Docker może potrzebować pobrać -obraz Open WebUI, a samo Open WebUI może potrzebować zakończyć własną konfigurację cold-start. -Ta ścieżka oczekuje używalnego klucza modelu live, a `OPENCLAW_PROFILE_FILE` -(domyślnie `~/.profile`) jest podstawowym sposobem jego dostarczenia w uruchomieniach w Dockerze. -Udane uruchomienia wypisują mały ładunek JSON, taki jak `{ "ok": true, "model": +obraz Open WebUI, a samo Open WebUI może potrzebować dokończyć własną konfigurację cold-start. +Ta linia oczekuje użytecznego klucza modelu live, a `OPENCLAW_PROFILE_FILE` +(domyślnie `~/.profile`) jest podstawowym sposobem jego dostarczenia w uruchomieniach konteneryzowanych. +Udane uruchomienia wypisują mały payload JSON, taki jak `{ "ok": true, "model": "openclaw/default", ... }`. -`test:docker:mcp-channels` jest celowo deterministyczne i nie wymaga -rzeczywistego konta Telegram, Discord ani iMessage. Uruchamia zasiany kontener Gateway, -startuje drugi kontener, który uruchamia `openclaw mcp serve`, a następnie -weryfikuje routowane wykrywanie rozmów, odczyty transkryptów, metadane załączników, -zachowanie kolejki zdarzeń live, routing wysyłki wychodzącej oraz powiadomienia kanału + -uprawnień w stylu Claude przez rzeczywisty most stdio MCP. Kontrola powiadomień -sprawdza bezpośrednio surowe ramki stdio MCP, więc smoke waliduje to, co most -faktycznie emituje, a nie tylko to, co akurat udostępnia określony SDK klienta. +`test:docker:mcp-channels` jest celowo deterministyczny i nie wymaga +rzeczywistego konta Telegram, Discord ani iMessage. Uruchamia seedowany kontener +Gateway, startuje drugi kontener uruchamiający `openclaw mcp serve`, a następnie +weryfikuje wykrywanie routowanych rozmów, odczyty transkryptów, metadane załączników, +zachowanie kolejki zdarzeń live, routing wysyłania wychodzącego oraz powiadomienia +w stylu Claude dla kanałów + uprawnień przez rzeczywisty most stdio MCP. Kontrola powiadomień +sprawdza bezpośrednio surowe ramki stdio MCP, dzięki czemu smoke weryfikuje to, co +most rzeczywiście emituje, a nie tylko to, co akurat ujawnia określony klient SDK. -Ręczny smoke wątku ACP w prostym języku (nie CI): +Ręczny smoke wątku ACP w plain language (nie w CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Zachowaj ten skrypt do przepływów pracy regresyjnych/debugowania. Może znów być potrzebny do walidacji routingu wątków ACP, więc go nie usuwaj. +- Zachowaj ten skrypt do przepływów pracy regresji/debugowania. Może być znów potrzebny do walidacji routingu wątków ACP, więc go nie usuwaj. Przydatne zmienne env: - `OPENCLAW_CONFIG_DIR=...` (domyślnie: `~/.openclaw`) montowane do `/home/node/.openclaw` - `OPENCLAW_WORKSPACE_DIR=...` (domyślnie: `~/.openclaw/workspace`) montowane do `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (domyślnie: `~/.profile`) montowane do `/home/node/.profile` i wykonywane przez `source` przed uruchomieniem testów -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (domyślnie: `~/.cache/openclaw/docker-cli-tools`) montowane do `/home/node/.npm-global` dla cache’owanych instalacji CLI wewnątrz Dockera -- Zewnętrzne katalogi/pliki uwierzytelniania CLI pod `$HOME` są montowane tylko do odczytu pod `/host-auth...`, a następnie kopiowane do `/home/node/...` przed startem testów +- `OPENCLAW_PROFILE_FILE=...` (domyślnie: `~/.profile`) montowane do `/home/node/.profile` i pobierane przed uruchomieniem testów +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (domyślnie: `~/.cache/openclaw/docker-cli-tools`) montowane do `/home/node/.npm-global` dla cache’owanych instalacji CLI wewnątrz Docker +- Zewnętrzne katalogi/pliki uwierzytelniania CLI pod `$HOME` są montowane tylko do odczytu pod `/host-auth...`, a następnie kopiowane do `/home/node/...` przed rozpoczęciem testów - Domyślne katalogi: `.minimax` - Domyślne pliki: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - Zawężone uruchomienia dostawców montują tylko potrzebne katalogi/pliki wywnioskowane z `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - - Ręczne nadpisanie przez `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` lub listę oddzielaną przecinkami, np. `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` + - Ręczne nadpisanie: `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` lub lista rozdzielana przecinkami, np. `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` - `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...`, aby zawęzić uruchomienie -- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, aby filtrować dostawców w kontenerze -- `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby ponownie użyć istniejącego obrazu `openclaw:local-live` do kolejnych uruchomień, które nie wymagają przebudowy +- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, aby filtrować dostawców wewnątrz kontenera +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby ponownie użyć istniejącego obrazu `openclaw:local-live` przy ponownych uruchomieniach, które nie wymagają przebudowy - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, aby upewnić się, że poświadczenia pochodzą z magazynu profili (a nie z env) - `OPENCLAW_OPENWEBUI_MODEL=...`, aby wybrać model udostępniany przez Gateway dla smoke Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...`, aby nadpisać prompt sprawdzający nonce używany przez smoke Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...`, aby nadpisać prompt sprawdzania nonce używany przez smoke Open WebUI - `OPENWEBUI_IMAGE=...`, aby nadpisać przypięty tag obrazu Open WebUI ## Kontrola poprawności dokumentacji -Po edycji dokumentacji uruchamiaj kontrolę dokumentacji: `pnpm check:docs`. -Uruchamiaj pełną walidację kotwic Mintlify, gdy potrzebujesz także kontroli nagłówków w obrębie strony: `pnpm docs:check-links:anchors`. +Po edycjach dokumentacji uruchom sprawdzenia dokumentacji: `pnpm check:docs`. +Uruchom pełną walidację anchorów Mintlify, gdy potrzebujesz także sprawdzania nagłówków w obrębie strony: `pnpm docs:check-links:anchors`. -## Regresja offline (bezpieczna dla CI) +## Regresje offline (bezpieczne dla CI) -To regresje „rzeczywistego pipeline’u” bez prawdziwych dostawców: +To regresje „rzeczywistego pipeline” bez rzeczywistych dostawców: -- Wywoływanie narzędzi Gateway (mock OpenAI, rzeczywista pętla Gateway + agent): `src/gateway/gateway.test.ts` (przypadek: "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Kreator Gateway (WS `wizard.start`/`wizard.next`, zapis konfiguracji + wymuszone auth): `src/gateway/gateway.test.ts` (przypadek: "runs wizard over ws and writes auth token config") +- Wywoływanie narzędzi Gateway (mock OpenAI, rzeczywisty Gateway + pętla agenta): `src/gateway/gateway.test.ts` (przypadek: "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Kreator Gateway (WS `wizard.start`/`wizard.next`, wymuszone zapisywanie konfiguracji + auth): `src/gateway/gateway.test.ts` (przypadek: "runs wizard over ws and writes auth token config") -## Ewalucje niezawodności agenta (Skills) +## Ewaluacje niezawodności agenta (Skills) -Mamy już kilka bezpiecznych dla CI testów, które zachowują się jak „ewaluacje niezawodności agenta”: +Mamy już kilka testów bezpiecznych dla CI, które zachowują się jak „ewaluacje niezawodności agenta”: -- Mockowane wywoływanie narzędzi przez rzeczywistą pętlę Gateway + agent (`src/gateway/gateway.test.ts`). -- End-to-end przepływy kreatora, które walidują połączenie sesji i efekty konfiguracji (`src/gateway/gateway.test.ts`). +- Mock wywoływania narzędzi przez rzeczywistą pętlę Gateway + agenta (`src/gateway/gateway.test.ts`). +- Przepływy kreatora end-to-end, które walidują okablowanie sesji i efekty konfiguracji (`src/gateway/gateway.test.ts`). Czego nadal brakuje dla Skills (zobacz [Skills](/pl/tools/skills)): -- **Decisioning:** gdy Skills są wymienione w prompcie, czy agent wybiera właściwe Skill (albo unika nieistotnych)? -- **Compliance:** czy agent odczytuje `SKILL.md` przed użyciem i przestrzega wymaganych kroków/argumentów? -- **Workflow contracts:** scenariusze wieloturowe, które potwierdzają kolejność narzędzi, przenoszenie historii sesji i granice sandboxa. +- **Decisioning:** gdy Skills są wymienione w prompcie, czy agent wybiera właściwy Skill (albo unika nieistotnych)? +- **Compliance:** czy agent odczytuje `SKILL.md` przed użyciem i wykonuje wymagane kroki/argumenty? +- **Workflow contracts:** scenariusze wieloturowe, które sprawdzają kolejność narzędzi, przenoszenie historii sesji i granice sandboxa. Przyszłe ewaluacje powinny najpierw pozostać deterministyczne: -- Runner scenariuszy używający mockowanych dostawców do potwierdzania wywołań narzędzi + ich kolejności, odczytów plików Skill i połączenia sesji. -- Mały pakiet scenariuszy skupionych na Skills (użyć vs unikać, bramkowanie, prompt injection). -- Opcjonalne ewaluacje live (opt-in, bramkowane przez env) dopiero po wdrożeniu pakietu bezpiecznego dla CI. +- Uruchamiacz scenariuszy używający mock dostawców do sprawdzania wywołań narzędzi + kolejności, odczytów plików Skill i okablowania sesji. +- Niewielki pakiet scenariuszy skupionych na Skills (użycie vs unikanie, bramkowanie, prompt injection). +- Opcjonalne ewaluacje live (opt-in, bramkowane env) dopiero po wdrożeniu pakietu bezpiecznego dla CI. -## Testy kontraktowe (kształt pluginów i kanałów) +## Testy kontraktowe (kształt Plugin i kanałów) -Testy kontraktowe weryfikują, że każdy zarejestrowany plugin i kanał jest zgodny ze swoim -kontraktem interfejsu. Iterują po wszystkich wykrytych pluginach i uruchamiają pakiet -asercji kształtu i zachowania. Domyślna ścieżka unit `pnpm test` celowo +Testy kontraktowe weryfikują, że każdy zarejestrowany Plugin i kanał jest zgodny ze swoim +kontraktem interfejsu. Iterują po wszystkich wykrytych Plugin i uruchamiają pakiet +asercji kształtu i zachowania. Domyślna linia unit `pnpm test` celowo pomija te współdzielone pliki seam i smoke; uruchamiaj polecenia kontraktowe jawnie, -gdy dotykasz współdzielonych powierzchni kanałów lub dostawców. +gdy modyfikujesz współdzielone powierzchnie kanałów lub dostawców. ### Polecenia @@ -872,41 +950,41 @@ gdy dotykasz współdzielonych powierzchni kanałów lub dostawców. Znajdują się w `src/channels/plugins/contracts/*.contract.test.ts`: -- **plugin** — podstawowy kształt pluginu (id, name, capabilities) -- **setup** — kontrakt kreatora konfiguracji -- **session-binding** — zachowanie wiązania sesji -- **outbound-payload** — struktura ładunku wiadomości -- **inbound** — obsługa wiadomości przychodzących -- **actions** — handlery działań kanału -- **threading** — obsługa ID wątków -- **directory** — API katalogu/listy -- **group-policy** — egzekwowanie polityki grupowej +- **plugin** - Podstawowy kształt Plugin (id, nazwa, capabilities) +- **setup** - Kontrakt kreatora konfiguracji +- **session-binding** - Zachowanie wiązania sesji +- **outbound-payload** - Struktura payload wiadomości +- **inbound** - Obsługa wiadomości przychodzących +- **actions** - Handlery akcji kanału +- **threading** - Obsługa identyfikatorów wątków +- **directory** - API katalogu/listy +- **group-policy** - Egzekwowanie zasad grup ### Kontrakty statusu dostawców Znajdują się w `src/plugins/contracts/*.contract.test.ts`. -- **status** — sondy statusu kanału -- **registry** — kształt rejestru pluginów +- **status** - Sondy statusu kanałów +- **registry** - Kształt rejestru Plugin ### Kontrakty dostawców Znajdują się w `src/plugins/contracts/*.contract.test.ts`: -- **auth** — kontrakt przepływu uwierzytelniania -- **auth-choice** — wybór/selekcja uwierzytelniania -- **catalog** — API katalogu modeli -- **discovery** — wykrywanie pluginów -- **loader** — ładowanie pluginów -- **runtime** — runtime dostawcy -- **shape** — kształt/interfejs pluginu -- **wizard** — kreator konfiguracji +- **auth** - Kontrakt przepływu uwierzytelniania +- **auth-choice** - Wybór/selekcja uwierzytelniania +- **catalog** - API katalogu modeli +- **discovery** - Wykrywanie Plugin +- **loader** - Ładowanie Plugin +- **runtime** - Runtime dostawcy +- **shape** - Kształt/interfejs Plugin +- **wizard** - Kreator konfiguracji ### Kiedy uruchamiać -- Po zmianie eksportów lub subścieżek Plugin SDK -- Po dodaniu lub modyfikacji pluginu kanału albo dostawcy -- Po refaktoryzacji rejestracji pluginów lub wykrywania +- Po zmianie eksportów lub subścieżek plugin-sdk +- Po dodaniu lub modyfikacji kanału albo Plugin dostawcy +- Po refaktoryzacji rejestracji lub wykrywania Plugin Testy kontraktowe uruchamiają się w CI i nie wymagają prawdziwych kluczy API. @@ -914,11 +992,11 @@ Testy kontraktowe uruchamiają się w CI i nie wymagają prawdziwych kluczy API. Gdy naprawiasz problem dostawcy/modelu wykryty w live: -- Jeśli to możliwe, dodaj regresję bezpieczną dla CI (mock/stub dostawcy albo uchwycenie dokładnej transformacji kształtu żądania) -- Jeśli z natury da się to sprawdzić tylko w live (limity szybkości, polityki auth), utrzymuj test live wąski i opt-in przez zmienne env +- Jeśli to możliwe, dodaj regresję bezpieczną dla CI (mock/stub dostawcy albo przechwycenie dokładnej transformacji kształtu żądania) +- Jeśli z natury jest to problem tylko live (limity szybkości, polityki uwierzytelniania), utrzymaj test live wąski i opt-in przez zmienne env - Preferuj celowanie w najmniejszą warstwę, która wychwytuje błąd: - - błąd konwersji/odtwarzania żądania dostawcy → test modeli bezpośrednich - - błąd pipeline’u sesji/historii/narzędzi Gateway → smoke Gateway live albo bezpieczny dla CI test mockowanego Gateway -- Guardrail przechodzenia SecretRef: - - `src/secrets/exec-secret-ref-id-parity.test.ts` wyprowadza jeden przykładowy cel dla każdej klasy SecretRef z metadanych rejestru (`listSecretTargetRegistryEntries()`), a następnie potwierdza, że identyfikatory exec segmentów przejścia są odrzucane. - - Jeśli dodasz nową rodzinę celów SecretRef `includeInPlan` w `src/secrets/target-registry-data.ts`, zaktualizuj `classifyTargetClass` w tym teście. Test celowo kończy się błędem dla niesklasyfikowanych identyfikatorów celów, aby nowych klas nie dało się pominąć po cichu. + - błąd konwersji/replay żądania dostawcy → test bezpośrednich modeli + - błąd pipeline sesji/historii/narzędzi Gateway → smoke Gateway live albo bezpieczny dla CI mock test Gateway +- Zabezpieczenie przechodzenia SecretRef: + - `src/secrets/exec-secret-ref-id-parity.test.ts` wyprowadza jeden przykładowy cel na klasę SecretRef z metadanych rejestru (`listSecretTargetRegistryEntries()`), a następnie sprawdza, że identyfikatory exec segmentów przechodzenia są odrzucane. + - Jeśli dodajesz nową rodzinę celów SecretRef `includeInPlan` w `src/secrets/target-registry-data.ts`, zaktualizuj `classifyTargetClass` w tym teście. Test celowo kończy się błędem przy niesklasyfikowanych identyfikatorach celów, aby nowe klasy nie mogły zostać pominięte po cichu. diff --git a/docs/pl/providers/index.md b/docs/pl/providers/index.md index e1c41c05a..31c9f60b0 100644 --- a/docs/pl/providers/index.md +++ b/docs/pl/providers/index.md @@ -1,14 +1,14 @@ --- read_when: - - Chcesz wybrać dostawcę modelu + - Chcesz wybrać dostawcę modeli - Potrzebujesz szybkiego przeglądu obsługiwanych backendów LLM -summary: Dostawcy modeli (LLM) obsługiwani przez OpenClaw +summary: Dostawcy modeli (LLM-y) obsługiwani przez OpenClaw title: Katalog dostawców x-i18n: - generated_at: "2026-04-08T02:17:13Z" + generated_at: "2026-04-13T08:50:40Z" model: gpt-5.4 provider: openai - source_hash: e7bee5528b7fc9a982b3d0eaa4930cb77f7bded19a47aec00572b6fcbd823a70 + source_hash: 3bc682d008119719826f71f74959ab32bedf14214459f5e6ac9cb70371d3c540 source_path: providers/index.md workflow: 15 --- @@ -18,7 +18,7 @@ x-i18n: OpenClaw może korzystać z wielu dostawców LLM. Wybierz dostawcę, uwierzytelnij się, a następnie ustaw domyślny model jako `provider/model`. -Szukasz dokumentacji kanałów czatu (WhatsApp/Telegram/Discord/Slack/Mattermost (plugin)/itp.)? Zobacz [Kanały](/pl/channels). +Szukasz dokumentacji kanałów czatu (WhatsApp/Telegram/Discord/Slack/Mattermost (Plugin)/itp.)? Zobacz [Kanały](/pl/channels). ## Szybki start @@ -47,16 +47,17 @@ Szukasz dokumentacji kanałów czatu (WhatsApp/Telegram/Discord/Slack/Mattermost - [GitHub Copilot](/pl/providers/github-copilot) - [Modele GLM](/pl/providers/glm) - [Google (Gemini)](/pl/providers/google) -- [Groq (inferencja LPU)](/pl/providers/groq) -- [Hugging Face (inferencja)](/pl/providers/huggingface) +- [Groq (wnioskowanie LPU)](/pl/providers/groq) +- [Hugging Face (Inference)](/pl/providers/huggingface) - [inferrs (modele lokalne)](/pl/providers/inferrs) - [Kilocode](/pl/providers/kilocode) - [LiteLLM (ujednolicona brama)](/pl/providers/litellm) +- [LM Studio (modele lokalne)](/pl/providers/lmstudio) - [MiniMax](/pl/providers/minimax) - [Mistral](/pl/providers/mistral) - [Moonshot AI (Kimi + Kimi Coding)](/pl/providers/moonshot) - [NVIDIA](/pl/providers/nvidia) -- [Ollama (chmura + modele lokalne)](/pl/providers/ollama) +- [Ollama (modele chmurowe i lokalne)](/pl/providers/ollama) - [OpenAI (API + Codex)](/pl/providers/openai) - [OpenCode](/pl/providers/opencode) - [OpenCode Go](/pl/providers/opencode-go) @@ -81,9 +82,9 @@ Szukasz dokumentacji kanałów czatu (WhatsApp/Telegram/Discord/Slack/Mattermost ## Wspólne strony przeglądowe - [Dodatkowe dołączone warianty](/pl/providers/models#additional-bundled-provider-variants) - Anthropic Vertex, Copilot Proxy i Gemini CLI OAuth -- [Generowanie obrazów](/pl/tools/image-generation) - Współdzielone narzędzie `image_generate`, wybór dostawcy i failover -- [Generowanie muzyki](/pl/tools/music-generation) - Współdzielone narzędzie `music_generate`, wybór dostawcy i failover -- [Generowanie wideo](/pl/tools/video-generation) - Współdzielone narzędzie `video_generate`, wybór dostawcy i failover +- [Generowanie obrazów](/pl/tools/image-generation) - Wspólne narzędzie `image_generate`, wybór dostawcy i failover +- [Generowanie muzyki](/pl/tools/music-generation) - Wspólne narzędzie `music_generate`, wybór dostawcy i failover +- [Generowanie wideo](/pl/tools/video-generation) - Wspólne narzędzie `video_generate`, wybór dostawcy i failover ## Dostawcy transkrypcji @@ -91,6 +92,7 @@ Szukasz dokumentacji kanałów czatu (WhatsApp/Telegram/Discord/Slack/Mattermost ## Narzędzia społeczności -- [Claude Max API Proxy](/pl/providers/claude-max-api-proxy) - Społecznościowy proxy dla poświadczeń subskrypcji Claude (przed użyciem zweryfikuj zasady/warunki Anthropic) +- [Claude Max API Proxy](/pl/providers/claude-max-api-proxy) - Społecznościowy proxy dla poświadczeń subskrypcji Claude (przed użyciem sprawdź zasady/warunki Anthropic) -Pełny katalog dostawców (xAI, Groq, Mistral itd.) oraz zaawansowaną konfigurację znajdziesz w [Dostawcy modeli](/pl/concepts/model-providers). +Pełny katalog dostawców (xAI, Groq, Mistral itp.) oraz zaawansowaną konfigurację +znajdziesz w sekcji [Dostawcy modeli](/pl/concepts/model-providers). diff --git a/docs/pl/providers/lmstudio.md b/docs/pl/providers/lmstudio.md new file mode 100644 index 000000000..725500457 --- /dev/null +++ b/docs/pl/providers/lmstudio.md @@ -0,0 +1,163 @@ +--- +read_when: + - Chcesz uruchomić OpenClaw z modelami open source za pośrednictwem LM Studio. + - Chcesz skonfigurować LM Studio. +summary: Uruchom OpenClaw z LM Studio +title: LM Studio +x-i18n: + generated_at: "2026-04-13T08:50:43Z" + model: gpt-5.4 + provider: openai + source_hash: 11264584e8277260d4215feb7c751329ce04f59e9228da1c58e147c21cd9ac2c + source_path: providers/lmstudio.md + workflow: 15 +--- + +# LM Studio + +LM Studio to przyjazna, a zarazem potężna aplikacja do uruchamiania modeli o otwartych wagach na własnym sprzęcie. Umożliwia uruchamianie modeli llama.cpp (GGUF) lub MLX (Apple Silicon). Jest dostępna jako pakiet GUI lub daemon bez interfejsu (`llmster`). Dokumentację produktu i konfiguracji znajdziesz na stronie [lmstudio.ai](https://lmstudio.ai/). + +## Szybki start + +1. Zainstaluj LM Studio (wersja desktopowa) lub `llmster` (wersja bez interfejsu), a następnie uruchom lokalny serwer: + +```bash +curl -fsSL https://lmstudio.ai/install.sh | bash +``` + +2. Uruchom serwer + +Upewnij się, że uruchamiasz aplikację desktopową albo daemon za pomocą następującego polecenia: + +```bash +lms daemon up +``` + +```bash +lms server start --port 1234 +``` + +Jeśli używasz aplikacji, upewnij się, że masz włączone JIT, aby zapewnić płynne działanie. Więcej informacji znajdziesz w [przewodniku LM Studio dotyczącym JIT i TTL](https://lmstudio.ai/docs/developer/core/ttl-and-auto-evict). + +3. OpenClaw wymaga wartości tokena LM Studio. Ustaw `LM_API_TOKEN`: + +```bash +export LM_API_TOKEN="your-lm-studio-api-token" +``` + +Jeśli uwierzytelnianie LM Studio jest wyłączone, użyj dowolnej niepustej wartości tokena: + +```bash +export LM_API_TOKEN="placeholder-key" +``` + +Szczegóły konfiguracji uwierzytelniania LM Studio znajdziesz w [LM Studio Authentication](https://lmstudio.ai/docs/developer/core/authentication). + +4. Uruchom onboarding i wybierz `LM Studio`: + +```bash +openclaw onboard +``` + +5. Podczas onboardingu użyj monitu `Default model`, aby wybrać model LM Studio. + +Możesz też ustawić go lub zmienić później: + +```bash +openclaw models set lmstudio/qwen/qwen3.5-9b +``` + +Klucze modeli LM Studio mają format `author/model-name` (na przykład `qwen/qwen3.5-9b`). Odwołania do modeli OpenClaw poprzedzają je nazwą dostawcy: `lmstudio/qwen/qwen3.5-9b`. Dokładny klucz modelu możesz znaleźć, uruchamiając `curl http://localhost:1234/api/v1/models` i sprawdzając pole `key`. + +## Onboarding nieinteraktywny + +Użyj nieinteraktywnego onboardingu, jeśli chcesz zautomatyzować konfigurację (CI, provisioning, zdalny bootstrap): + +```bash +openclaw onboard \ + --non-interactive \ + --accept-risk \ + --auth-choice lmstudio +``` + +Możesz też podać bazowy URL lub model wraz z kluczem API: + +```bash +openclaw onboard \ + --non-interactive \ + --accept-risk \ + --auth-choice lmstudio \ + --custom-base-url http://localhost:1234/v1 \ + --lmstudio-api-key "$LM_API_TOKEN" \ + --custom-model-id qwen/qwen3.5-9b +``` + +`--custom-model-id` przyjmuje klucz modelu zwracany przez LM Studio (na przykład `qwen/qwen3.5-9b`), bez prefiksu dostawcy `lmstudio/`. + +Nieinteraktywny onboarding wymaga `--lmstudio-api-key` (lub `LM_API_TOKEN` w zmiennych środowiskowych). +W przypadku nieuwierzytelnionych serwerów LM Studio działa dowolna niepusta wartość tokena. + +`--custom-api-key` nadal jest obsługiwane ze względu na zgodność, ale dla LM Studio zalecane jest `--lmstudio-api-key`. + +Spowoduje to zapisanie `models.providers.lmstudio`, ustawienie domyślnego modelu na +`lmstudio/` oraz zapisanie profilu uwierzytelniania `lmstudio:default`. + +Konfiguracja interaktywna może poprosić o opcjonalną preferowaną długość kontekstu ładowania i zastosuje ją do wykrytych modeli LM Studio zapisywanych w konfiguracji. + +## Konfiguracja + +### Jawna konfiguracja + +```json5 +{ + models: { + providers: { + lmstudio: { + baseUrl: "http://localhost:1234/v1", + apiKey: "${LM_API_TOKEN}", + api: "openai-completions", + models: [ + { + id: "qwen/qwen3-coder-next", + name: "Qwen 3 Coder Next", + reasoning: false, + input: ["text"], + cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }, + contextWindow: 128000, + maxTokens: 8192, + }, + ], + }, + }, + }, +} +``` + +## Rozwiązywanie problemów + +### Nie wykryto LM Studio + +Upewnij się, że LM Studio jest uruchomione i że ustawiono `LM_API_TOKEN` (w przypadku serwerów nieuwierzytelnionych działa dowolna niepusta wartość tokena): + +```bash +# Uruchom przez aplikację desktopową lub bez interfejsu: +lms server start --port 1234 +``` + +Sprawdź, czy API jest dostępne: + +```bash +curl http://localhost:1234/api/v1/models +``` + +### Błędy uwierzytelniania (HTTP 401) + +Jeśli podczas konfiguracji pojawia się HTTP 401, sprawdź swój klucz API: + +- Sprawdź, czy `LM_API_TOKEN` odpowiada kluczowi skonfigurowanemu w LM Studio. +- Szczegóły konfiguracji uwierzytelniania LM Studio znajdziesz w [LM Studio Authentication](https://lmstudio.ai/docs/developer/core/authentication). +- Jeśli serwer nie wymaga uwierzytelniania, użyj dowolnej niepustej wartości tokena dla `LM_API_TOKEN`. + +### Ładowanie modeli just-in-time + +LM Studio obsługuje ładowanie modeli just-in-time (JIT), w którym modele są ładowane przy pierwszym żądaniu. Upewnij się, że ta opcja jest włączona, aby uniknąć błędów „Model not loaded”. diff --git a/docs/pl/reference/api-usage-costs.md b/docs/pl/reference/api-usage-costs.md index e5d84a82d..8af9fbaa9 100644 --- a/docs/pl/reference/api-usage-costs.md +++ b/docs/pl/reference/api-usage-costs.md @@ -1,23 +1,22 @@ --- read_when: - - Chcesz zrozumieć, które funkcje mogą wywoływać płatne API - - Musisz sprawdzić klucze, koszty i widoczność zużycia - - Wyjaśniasz raportowanie kosztów w /status lub /usage -summary: Sprawdź, co może generować koszty, które klucze są używane i jak wyświetlać zużycie + - Chcesz zrozumieć, które funkcje mogą wywoływać płatne API. + - Musisz przeprowadzić audyt kluczy, kosztów i widoczności zużycia. + - Wyjaśniasz raportowanie kosztów w `/status` lub `/usage`. +summary: Sprawdź, co może generować koszty, które klucze są używane i jak wyświetlić zużycie. title: Zużycie API i koszty x-i18n: - generated_at: "2026-04-07T09:49:40Z" + generated_at: "2026-04-13T08:50:45Z" model: gpt-5.4 provider: openai - source_hash: ab6eefcde9ac014df6cdda7aaa77ef48f16936ab12eaa883d9fe69425a31a2dd + source_hash: f5077e74d38ef781ac7a72603e9f9e3829a628b95c5a9967915ab0f321565429 source_path: reference/api-usage-costs.md workflow: 15 --- # Zużycie API i koszty -Ten dokument wymienia **funkcje, które mogą wywoływać klucze API** oraz miejsca, w których pojawiają się ich koszty. Skupia się na -funkcjach OpenClaw, które mogą generować użycie dostawców lub płatne wywołania API. +Ten dokument zawiera listę **funkcji, które mogą wywoływać klucze API** oraz wskazuje, gdzie pojawiają się ich koszty. Skupia się na funkcjach OpenClaw, które mogą generować zużycie dostawców lub płatne wywołania API. ## Gdzie pojawiają się koszty (czat + CLI) @@ -25,111 +24,93 @@ funkcjach OpenClaw, które mogą generować użycie dostawców lub płatne wywo - `/status` pokazuje bieżący model sesji, użycie kontekstu i tokeny ostatniej odpowiedzi. - Jeśli model używa **uwierzytelniania kluczem API**, `/status` pokazuje także **szacowany koszt** ostatniej odpowiedzi. -- Jeśli metadane aktywnej sesji są ubogie, `/status` może odzyskać liczniki tokenów/cache - oraz etykietę aktywnego modelu runtime z najnowszego wpisu użycia w transkrypcie. - Istniejące niezerowe wartości aktywne nadal mają pierwszeństwo, a sumy z transkryptu wielkości promptu - mogą wygrać, gdy zapisane sumy nie istnieją lub są mniejsze. +- Jeśli metadane aktywnej sesji są ubogie, `/status` może odzyskać liczniki tokenów/pamięci podręcznej oraz etykietę aktywnego modelu środowiska uruchomieniowego z najnowszego wpisu użycia w transkrypcie. Istniejące niezerowe wartości na żywo nadal mają pierwszeństwo, a sumy z transkryptu o rozmiarze promptu mogą wygrać, gdy zapisane sumy są nieobecne lub mniejsze. -**Stopka kosztów dla wiadomości** +**Stopka kosztu dla wiadomości** -- `/usage full` dołącza stopkę użycia do każdej odpowiedzi, w tym **szacowany koszt** (tylko klucz API). -- `/usage tokens` pokazuje tylko tokeny; przepływy subskrypcyjne OAuth/token i CLI ukrywają koszt w dolarach. -- Uwaga dotycząca Gemini CLI: gdy CLI zwraca wyjście JSON, OpenClaw odczytuje użycie z - `stats`, normalizuje `stats.cached` do `cacheRead` i w razie potrzeby wyprowadza tokeny wejściowe - z `stats.input_tokens - stats.cached`. +- `/usage full` dodaje stopkę użycia do każdej odpowiedzi, w tym **szacowany koszt** (tylko klucz API). +- `/usage tokens` pokazuje tylko tokeny; przepływy OAuth/token w stylu subskrypcyjnym oraz przepływy CLI ukrywają koszt w dolarach. +- Uwaga dotycząca Gemini CLI: gdy CLI zwraca dane wyjściowe w formacie JSON, OpenClaw odczytuje użycie z `stats`, normalizuje `stats.cached` do `cacheRead` i w razie potrzeby wylicza tokeny wejściowe z `stats.input_tokens - stats.cached`. -Uwaga dotycząca Anthropic: pracownicy Anthropic poinformowali nas, że użycie Claude CLI w stylu OpenClaw jest -ponownie dozwolone, więc OpenClaw traktuje ponowne użycie Claude CLI i użycie `claude -p` jako -zatwierdzone dla tej integracji, chyba że Anthropic opublikuje nową politykę. -Anthropic nadal nie udostępnia oszacowania kosztu w dolarach dla pojedynczej wiadomości, które OpenClaw mógłby -pokazać w `/usage full`. +Uwaga dotycząca Anthropic: pracownicy Anthropic poinformowali nas, ż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 zatwierdzone dla tej integracji, chyba że Anthropic opublikuje nową politykę. +Anthropic nadal nie udostępnia szacunku kosztu w dolarach dla pojedynczej wiadomości, który OpenClaw mógłby pokazać w `/usage full`. **Okna użycia CLI (limity dostawców)** -- `openclaw status --usage` i `openclaw channels list` pokazują **okna użycia** dostawców - (migawki limitów, a nie koszty pojedynczych wiadomości). -- Wynik czytelny dla człowieka jest normalizowany do `X% left` dla wszystkich dostawców. -- Obecni dostawcy okien użycia: Anthropic, GitHub Copilot, Gemini CLI, - OpenAI Codex, MiniMax, Xiaomi i z.ai. -- Uwaga dotycząca MiniMax: jego surowe pola `usage_percent` / `usagePercent` oznaczają pozostały - limit, więc OpenClaw odwraca je przed wyświetleniem. Pola oparte na liczbie nadal mają - pierwszeństwo, gdy są obecne. Jeśli dostawca zwróci `model_remains`, OpenClaw preferuje wpis modelu czatu, - w razie potrzeby wyprowadza etykietę okna ze znaczników czasu - i dołącza nazwę modelu do etykiety planu. -- Uwierzytelnianie użycia dla tych okien limitów pochodzi z hooków specyficznych dla dostawcy, gdy - są dostępne; w przeciwnym razie OpenClaw wraca do dopasowywania poświadczeń OAuth/klucza API - z profili auth, env lub konfiguracji. +- `openclaw status --usage` i `openclaw channels list` pokazują **okna użycia** dostawcy (migawki limitów, a nie koszty pojedynczych wiadomości). +- Dane wyjściowe dla ludzi są normalizowane do postaci `X% left` dla wszystkich dostawców. +- Obecni dostawcy okien użycia: Anthropic, GitHub Copilot, Gemini CLI, OpenAI Codex, MiniMax, Xiaomi i z.ai. +- Uwaga dotycząca MiniMax: jego surowe pola `usage_percent` / `usagePercent` oznaczają pozostały limit, więc OpenClaw odwraca je przed wyświetleniem. Pola oparte na liczbie nadal mają pierwszeństwo, jeśli są obecne. Jeśli dostawca zwraca `model_remains`, OpenClaw preferuje wpis modelu czatu, w razie potrzeby wyprowadza etykietę okna z sygnatur czasowych i uwzględnia nazwę modelu w etykiecie planu. +- Uwierzytelnianie użycia dla tych okien limitów pochodzi z hooków specyficznych dla dostawcy, gdy są dostępne; w przeciwnym razie OpenClaw przechodzi do dopasowywania poświadczeń OAuth/kluczy API z profili uwierzytelniania, środowiska lub konfiguracji. -Szczegóły i przykłady znajdziesz w [Token use & costs](/pl/reference/token-use). +Szczegóły i przykłady znajdziesz w [Użycie tokenów i koszty](/pl/reference/token-use). ## Jak wykrywane są klucze OpenClaw może pobierać poświadczenia z: -- **Profili auth** (per agent, przechowywanych w `auth-profiles.json`). +- **Profili uwierzytelniania** (na agenta, przechowywanych w `auth-profiles.json`). - **Zmienne środowiskowe** (np. `OPENAI_API_KEY`, `BRAVE_API_KEY`, `FIRECRAWL_API_KEY`). - **Konfiguracja** (`models.providers.*.apiKey`, `plugins.entries.*.config.webSearch.apiKey`, `plugins.entries.firecrawl.config.webFetch.apiKey`, `memorySearch.*`, `talk.providers.*.apiKey`). -- **Skills** (`skills.entries..apiKey`), które mogą eksportować klucze do env procesu skill. +- **Skills** (`skills.entries..apiKey`), które mogą eksportować klucze do środowiska procesu Skill. -## Funkcje, które mogą generować koszty z użycia kluczy +## Funkcje, które mogą korzystać z kluczy -### 1) Główne odpowiedzi modelu (czat + narzędzia) +### 1) Odpowiedzi modelu podstawowego (czat + narzędzia) -Każda odpowiedź lub wywołanie narzędzia używa **bieżącego dostawcy modelu** (OpenAI, Anthropic itd.). To -główne źródło użycia i kosztów. +Każda odpowiedź lub wywołanie narzędzia używa **bieżącego dostawcy modelu** (OpenAI, Anthropic itd.). To podstawowe źródło użycia i kosztów. -Obejmuje to także hostowanych dostawców w stylu subskrypcyjnym, którzy nadal rozliczają się poza -lokalnym UI OpenClaw, takich jak **OpenAI Codex**, **Alibaba Cloud Model Studio -Coding Plan**, **MiniMax Coding Plan**, **Z.AI / GLM Coding Plan** oraz -ścieżka logowania Anthropic Claude w OpenClaw z włączonym **Extra Usage**. +Obejmuje to także hostowanych dostawców w stylu subskrypcyjnym, którzy nadal rozliczają poza lokalnym interfejsem OpenClaw, takich jak **OpenAI Codex**, **Alibaba Cloud Model Studio +Coding Plan**, **MiniMax Coding Plan**, **Z.AI / GLM Coding Plan** oraz ścieżka logowania Anthropic do Claude w OpenClaw z włączonym **Extra Usage**. -Informacje o konfiguracji cen znajdziesz w [Models](/pl/providers/models), a o wyświetlaniu w [Token use & costs](/pl/reference/token-use). +Zobacz [Modele](/pl/providers/models), aby poznać konfigurację cen, oraz [Użycie tokenów i koszty](/pl/reference/token-use), aby poznać sposób wyświetlania. ### 2) Rozumienie mediów (audio/obraz/wideo) -Przychodzące media mogą zostać podsumowane/przepisane przed uruchomieniem odpowiedzi. Wykorzystuje to API modeli/dostawców. +Media przychodzące mogą być streszczane/transkrybowane przed wygenerowaniem odpowiedzi. Wykorzystuje to interfejsy API modelu/dostawcy. - Audio: OpenAI / Groq / Deepgram / Google / Mistral. - Obraz: OpenAI / OpenRouter / Anthropic / Google / MiniMax / Moonshot / Qwen / Z.AI. - Wideo: Google / Qwen / Moonshot. -Zobacz [Media understanding](/pl/nodes/media-understanding). +Zobacz [Rozumienie mediów](/pl/nodes/media-understanding). ### 3) Generowanie obrazów i wideo -Współdzielone możliwości generowania również mogą zużywać klucze dostawców: +Współdzielone możliwości generowania również mogą wykorzystywać klucze dostawców: - Generowanie obrazów: OpenAI / Google / fal / MiniMax - Generowanie wideo: Qwen -Generowanie obrazów może wywnioskować domyślnego dostawcę obsługiwanego przez auth, gdy +Generowanie obrazów może wywnioskować domyślnego dostawcę opartego na uwierzytelnianiu, gdy `agents.defaults.imageGenerationModel` nie jest ustawione. Generowanie wideo obecnie wymaga jawnego `agents.defaults.videoGenerationModel`, takiego jak `qwen/wan2.6-t2v`. -Zobacz [Image generation](/pl/tools/image-generation), [Qwen Cloud](/pl/providers/qwen) -i [Models](/pl/concepts/models). +Zobacz [Generowanie obrazów](/pl/tools/image-generation), [Qwen Cloud](/pl/providers/qwen) +i [Modele](/pl/concepts/models). -### 4) Embeddingi pamięci + wyszukiwanie semantyczne +### 4) Osadzania pamięci + wyszukiwanie semantyczne -Semantyczne wyszukiwanie pamięci używa **API embeddingów**, gdy jest skonfigurowane dla zdalnych dostawców: +Semantyczne wyszukiwanie pamięci używa **interfejsów API osadzań**, gdy jest skonfigurowane dla zdalnych dostawców: -- `memorySearch.provider = "openai"` → embeddingi OpenAI -- `memorySearch.provider = "gemini"` → embeddingi Gemini -- `memorySearch.provider = "voyage"` → embeddingi Voyage -- `memorySearch.provider = "mistral"` → embeddingi Mistral -- `memorySearch.provider = "ollama"` → embeddingi Ollama (lokalne/self-hosted; zwykle bez rozliczania hostowanego API) -- Opcjonalny fallback do zdalnego dostawcy, jeśli lokalne embeddingi zawiodą +- `memorySearch.provider = "openai"` → osadzania OpenAI +- `memorySearch.provider = "gemini"` → osadzania Gemini +- `memorySearch.provider = "voyage"` → osadzania Voyage +- `memorySearch.provider = "mistral"` → osadzania Mistral +- `memorySearch.provider = "lmstudio"` → osadzania LM Studio (lokalne/self-hosted) +- `memorySearch.provider = "ollama"` → osadzania Ollama (lokalne/self-hosted; zwykle bez rozliczeń za hostowane API) +- Opcjonalny fallback do zdalnego dostawcy, jeśli lokalne osadzania zakończą się niepowodzeniem -Możesz pozostać lokalnie z `memorySearch.provider = "local"` (bez użycia API). +Możesz pozostać lokalnie, używając `memorySearch.provider = "local"` (bez użycia API). -Zobacz [Memory](/pl/concepts/memory). +Zobacz [Pamięć](/pl/concepts/memory). ### 5) Narzędzie wyszukiwania w sieci -`web_search` może generować opłaty zależnie od dostawcy: +`web_search` może generować opłaty za użycie w zależności od dostawcy: - **Brave Search API**: `BRAVE_API_KEY` lub `plugins.entries.brave.config.webSearch.apiKey` - **Exa**: `EXA_API_KEY` lub `plugins.entries.exa.config.webSearch.apiKey` @@ -138,20 +119,20 @@ Zobacz [Memory](/pl/concepts/memory). - **Grok (xAI)**: `XAI_API_KEY` lub `plugins.entries.xai.config.webSearch.apiKey` - **Kimi (Moonshot)**: `KIMI_API_KEY`, `MOONSHOT_API_KEY` lub `plugins.entries.moonshot.config.webSearch.apiKey` - **MiniMax Search**: `MINIMAX_CODE_PLAN_KEY`, `MINIMAX_CODING_API_KEY`, `MINIMAX_API_KEY` lub `plugins.entries.minimax.config.webSearch.apiKey` -- **Ollama Web Search**: domyślnie bez klucza, ale wymaga dostępnego hosta Ollama oraz `ollama signin`; może też ponownie używać zwykłego bearer auth dostawcy Ollama, gdy host tego wymaga +- **Ollama Web Search**: domyślnie bez klucza, ale wymaga osiągalnego hosta Ollama oraz `ollama signin`; może także ponownie używać zwykłego uwierzytelniania bearer dostawcy Ollama, gdy host tego wymaga - **Perplexity Search API**: `PERPLEXITY_API_KEY`, `OPENROUTER_API_KEY` lub `plugins.entries.perplexity.config.webSearch.apiKey` - **Tavily**: `TAVILY_API_KEY` lub `plugins.entries.tavily.config.webSearch.apiKey` -- **DuckDuckGo**: zapasowy fallback bez klucza (bez rozliczania API, ale nieoficjalny i oparty na HTML) -- **SearXNG**: `SEARXNG_BASE_URL` lub `plugins.entries.searxng.config.webSearch.baseUrl` (bez klucza/self-hosted; bez rozliczania hostowanego API) +- **DuckDuckGo**: fallback bez klucza (bez rozliczeń API, ale nieoficjalny i oparty na HTML) +- **SearXNG**: `SEARXNG_BASE_URL` lub `plugins.entries.searxng.config.webSearch.baseUrl` (bez klucza/self-hosted; bez rozliczeń za hostowane API) -Starsze ścieżki dostawców `tools.web.search.*` nadal są ładowane przez tymczasową warstwę zgodności, ale nie są już zalecaną powierzchnią konfiguracji. +Starsze ścieżki dostawcy `tools.web.search.*` są nadal wczytywane przez tymczasową warstwę zgodności, ale nie są już zalecaną powierzchnią konfiguracji. -**Darmowy kredyt Brave Search:** Każdy plan Brave obejmuje odnawialny darmowy -kredyt w wysokości \$5/miesiąc. Plan Search kosztuje \$5 za 1000 żądań, więc kredyt pokrywa +**Darmowy kredyt Brave Search:** Każdy plan Brave obejmuje odnawialny +darmowy kredyt w wysokości \$5/miesiąc. Plan Search kosztuje \$5 za 1000 żądań, więc ten kredyt pokrywa 1000 żądań/miesiąc bez opłat. Ustaw limit użycia w panelu Brave, -aby uniknąć nieoczekiwanych opłat. +aby uniknąć nieoczekiwanych kosztów. -Zobacz [Web tools](/pl/tools/web). +Zobacz [Narzędzia webowe](/pl/tools/web). ### 5) Narzędzie pobierania z sieci (Firecrawl) @@ -159,33 +140,33 @@ Zobacz [Web tools](/pl/tools/web). - `FIRECRAWL_API_KEY` lub `plugins.entries.firecrawl.config.webFetch.apiKey` -Jeśli Firecrawl nie jest skonfigurowany, narzędzie wraca do bezpośredniego pobierania + readability (bez płatnego API). +Jeśli Firecrawl nie jest skonfigurowany, narzędzie przechodzi do bezpośredniego pobierania + readability (bez płatnego API). -Zobacz [Web tools](/pl/tools/web). +Zobacz [Narzędzia webowe](/pl/tools/web). -### 6) Migawki użycia dostawcy (status/health) +### 6) Migawki użycia dostawcy (status/stan) -Niektóre polecenia statusu wywołują **endpointy użycia dostawców**, aby wyświetlić okna limitów lub stan auth. -Zwykle są to wywołania o niskiej częstotliwości, ale nadal trafiają do API dostawców: +Niektóre polecenia statusu wywołują **punkty końcowe użycia dostawcy**, aby wyświetlić okna limitów lub stan uwierzytelniania. +Są to zwykle wywołania o małej częstotliwości, ale nadal trafiają do API dostawcy: - `openclaw status --usage` - `openclaw models status --json` -Zobacz [Models CLI](/cli/models). +Zobacz [CLI modeli](/cli/models). -### 7) Podsumowanie zabezpieczające przy kompaktowaniu +### 7) Zabezpieczające podsumowywanie Compaction -Zabezpieczenie kompaktowania może podsumowywać historię sesji przy użyciu **bieżącego modelu**, co -wywołuje API dostawców podczas działania. +Zabezpieczenie Compaction może podsumowywać historię sesji przy użyciu **bieżącego modelu**, co +wywołuje interfejsy API dostawcy podczas działania. -Zobacz [Session management + compaction](/pl/reference/session-management-compaction). +Zobacz [Zarządzanie sesją + Compaction](/pl/reference/session-management-compaction). ### 8) Skanowanie / sondowanie modeli `openclaw models scan` może sondować modele OpenRouter i używa `OPENROUTER_API_KEY`, gdy sondowanie jest włączone. -Zobacz [Models CLI](/cli/models). +Zobacz [CLI modeli](/cli/models). ### 9) Talk (mowa) @@ -193,11 +174,11 @@ Tryb Talk może wywoływać **ElevenLabs**, gdy jest skonfigurowany: - `ELEVENLABS_API_KEY` lub `talk.providers.elevenlabs.apiKey` -Zobacz [Talk mode](/pl/nodes/talk). +Zobacz [Tryb Talk](/pl/nodes/talk). -### 10) Skills (API zewnętrzne) +### 10) Skills (API innych firm) -Skills mogą przechowywać `apiKey` w `skills.entries..apiKey`. Jeśli skill używa tego klucza dla zewnętrznych -API, może generować koszty zgodnie z dostawcą tego skill. +Skills mogą przechowywać `apiKey` w `skills.entries..apiKey`. Jeśli Skill używa tego klucza do zewnętrznych +API, może generować koszty zgodnie z dostawcą danego Skill. Zobacz [Skills](/pl/tools/skills).