chore(i18n): refresh pl translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
4650a84d1b
commit
c09c2eaea1
File diff suppressed because it is too large
Load Diff
@ -4,143 +4,145 @@ read_when:
|
||||
summary: Cykl życia pętli agenta, strumienie i semantyka oczekiwania
|
||||
title: Pętla agenta
|
||||
x-i18n:
|
||||
generated_at: "2026-04-05T13:50:05Z"
|
||||
generated_at: "2026-04-09T01:27:54Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 8e562e63c494881e9c345efcb93c5f972d69aaec61445afc3d4ad026b2d26883
|
||||
source_hash: 32d3a73df8dabf449211a6183a70dcfd2a9b6f584dc76d0c4c9147582b2ca6a1
|
||||
source_path: concepts/agent-loop.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Pętla agenta (OpenClaw)
|
||||
|
||||
Pętla agentowa to pełny „rzeczywisty” przebieg działania agenta: przyjęcie wejścia → złożenie kontekstu → inferencja modelu →
|
||||
wykonanie narzędzi → strumieniowanie odpowiedzi → utrwalenie. To autorytatywna ścieżka, która zamienia wiadomość
|
||||
Pętla agentowa to pełny „rzeczywisty” przebieg działania agenta: przyjęcie danych wejściowych → złożenie kontekstu → wnioskowanie modelu →
|
||||
wykonanie narzędzi → strumieniowanie odpowiedzi → utrwalenie. To autorytatywna ścieżka, która przekształca wiadomość
|
||||
w działania i końcową odpowiedź, jednocześnie utrzymując spójny stan sesji.
|
||||
|
||||
W OpenClaw pętla to pojedynczy, serializowany przebieg na sesję, który emituje zdarzenia cyklu życia i strumieni
|
||||
podczas myślenia modelu, wywoływania narzędzi i strumieniowania danych wyjściowych. Ten dokument wyjaśnia, jak ta autentyczna pętla jest połączona od początku do końca.
|
||||
gdy model myśli, wywołuje narzędzia i strumieniuje dane wyjściowe. Ten dokument wyjaśnia, jak ta rzeczywista pętla
|
||||
jest połączona od początku do końca.
|
||||
|
||||
## Punkty wejścia
|
||||
|
||||
- Gateway RPC: `agent` i `agent.wait`.
|
||||
- CLI: polecenie `agent`.
|
||||
|
||||
## Jak to działa (wysoki poziom)
|
||||
## Jak to działa (na wysokim poziomie)
|
||||
|
||||
1. RPC `agent` weryfikuje parametry, rozwiązuje sesję (sessionKey/sessionId), utrwala metadane sesji i natychmiast zwraca `{ runId, acceptedAt }`.
|
||||
2. `agentCommand` uruchamia agenta:
|
||||
- rozwiązuje model + domyślne ustawienia thinking/verbose
|
||||
- rozwiązuje domyślne wartości modelu + thinking/verbose
|
||||
- ładuje migawkę Skills
|
||||
- wywołuje `runEmbeddedPiAgent` (środowisko uruchomieniowe pi-agent-core)
|
||||
- emituje **lifecycle end/error**, jeśli osadzona pętla tego nie wyemituje
|
||||
- emituje **koniec/błąd cyklu życia**, jeśli osadzona pętla tego nie wyemituje
|
||||
3. `runEmbeddedPiAgent`:
|
||||
- serializuje przebiegi przez kolejki per sesja + globalne
|
||||
- rozwiązuje model + profil uwierzytelniania i buduje sesję pi
|
||||
- subskrybuje zdarzenia pi i strumieniuje delty assistant/tool
|
||||
- wymusza timeout -> przerywa przebieg po przekroczeniu
|
||||
- serializuje przebiegi przez kolejki per sesja i globalne
|
||||
- rozwiązuje profil modelu + auth i buduje sesję pi
|
||||
- subskrybuje zdarzenia pi i strumieniuje delty asystenta/narzędzi
|
||||
- wymusza limit czasu -> przerywa przebieg po jego przekroczeniu
|
||||
- zwraca ładunki + metadane użycia
|
||||
4. `subscribeEmbeddedPiSession` mostkuje zdarzenia pi-agent-core do strumienia OpenClaw `agent`:
|
||||
- zdarzenia narzędzi => `stream: "tool"`
|
||||
- delty asystenta => `stream: "assistant"`
|
||||
- zdarzenia cyklu życia => `stream: "lifecycle"` (`phase: "start" | "end" | "error"`)
|
||||
5. `agent.wait` używa `waitForAgentRun`:
|
||||
- czeka na **lifecycle end/error** dla `runId`
|
||||
- czeka na **koniec/błąd cyklu życia** dla `runId`
|
||||
- zwraca `{ status: ok|error|timeout, startedAt, endedAt, error? }`
|
||||
|
||||
## Kolejkowanie + współbieżność
|
||||
|
||||
- Przebiegi są serializowane per klucz sesji (pas sesji) i opcjonalnie przez pas globalny.
|
||||
- To zapobiega wyścigom narzędzi/sesji i utrzymuje spójną historię sesji.
|
||||
- Kanały wiadomości mogą wybierać tryby kolejkowania (collect/steer/followup), które zasilają ten system pasów.
|
||||
Zobacz [Command Queue](/concepts/queue).
|
||||
- Przebiegi są serializowane dla każdego klucza sesji (pas sesji) i opcjonalnie przez pas globalny.
|
||||
- Zapobiega to wyścigom narzędzi/sesji i utrzymuje spójną historię sesji.
|
||||
- Kanały wiadomości mogą wybierać tryby kolejki (collect/steer/followup), które zasilają ten system pasów.
|
||||
Zobacz [Kolejka poleceń](/pl/concepts/queue).
|
||||
|
||||
## Przygotowanie sesji + workspace
|
||||
## Przygotowanie sesji + przestrzeni roboczej
|
||||
|
||||
- Workspace jest rozwiązywany i tworzony; przebiegi w sandboxie mogą zostać przekierowane do głównego katalogu workspace sandboxa.
|
||||
- Przestrzeń robocza jest rozwiązywana i tworzona; przebiegi sandboxowane mogą przekierowywać do katalogu głównego przestrzeni roboczej sandboxa.
|
||||
- Skills są ładowane (lub ponownie używane z migawki) i wstrzykiwane do env oraz promptu.
|
||||
- Pliki bootstrap/kontekstu są rozwiązywane i wstrzykiwane do raportu system prompt.
|
||||
- Uzyskiwana jest blokada zapisu sesji; `SessionManager` jest otwierany i przygotowywany przed rozpoczęciem strumieniowania.
|
||||
- Pliki bootstrap/kontekstu są rozwiązywane i wstrzykiwane do raportu promptu systemowego.
|
||||
- Uzyskiwana jest blokada zapisu sesji; `SessionManager` jest otwierany i przygotowywany przed strumieniowaniem.
|
||||
|
||||
## Składanie promptu + system prompt
|
||||
## Składanie promptu + prompt systemowy
|
||||
|
||||
- System prompt jest budowany z promptu bazowego OpenClaw, promptu Skills, kontekstu bootstrap oraz nadpisań dla danego przebiegu.
|
||||
- Wymuszane są ograniczenia specyficzne dla modelu oraz tokeny rezerwowe dla kompaktowania.
|
||||
- Zobacz [System prompt](/concepts/system-prompt), aby sprawdzić, co widzi model.
|
||||
- Prompt systemowy jest budowany z bazowego promptu OpenClaw, promptu Skills, kontekstu bootstrap i nadpisań dla przebiegu.
|
||||
- Wymuszane są limity specyficzne dla modelu i tokeny rezerwowe dla kompaktowania.
|
||||
- Zobacz [Prompt systemowy](/pl/concepts/system-prompt), aby sprawdzić, co widzi model.
|
||||
|
||||
## Punkty hooków (gdzie można przechwytywać)
|
||||
## Punkty hooków (gdzie można przechwycić)
|
||||
|
||||
OpenClaw ma dwa systemy hooków:
|
||||
|
||||
- **Wewnętrzne hooki** (hooki Gateway): skrypty sterowane zdarzeniami dla poleceń i zdarzeń cyklu życia.
|
||||
- **Hooki pluginów**: punkty rozszerzeń wewnątrz pętli agenta/narzędzi i potoku gateway.
|
||||
- **Hooki wewnętrzne** (hooki Gateway): skrypty sterowane zdarzeniami dla poleceń i zdarzeń cyklu życia.
|
||||
- **Hooki pluginów**: punkty rozszerzeń wewnątrz cyklu życia agenta/narzędzi i potoku gateway.
|
||||
|
||||
### Wewnętrzne hooki (hooki Gateway)
|
||||
### Hooki wewnętrzne (hooki Gateway)
|
||||
|
||||
- **`agent:bootstrap`**: uruchamia się podczas budowania plików bootstrap, zanim system prompt zostanie sfinalizowany.
|
||||
- **`agent:bootstrap`**: uruchamia się podczas budowania plików bootstrap przed finalizacją promptu systemowego.
|
||||
Użyj tego, aby dodawać/usuwać pliki kontekstu bootstrap.
|
||||
- **Hooki poleceń**: `/new`, `/reset`, `/stop` i inne zdarzenia poleceń (zobacz dokumentację Hooków).
|
||||
- **Hooki poleceń**: `/new`, `/reset`, `/stop` i inne zdarzenia poleceń (zobacz dokumentację hooków).
|
||||
|
||||
Zobacz [Hooks](/pl/automation/hooks), aby poznać konfigurację i przykłady.
|
||||
Zobacz [Hooki](/pl/automation/hooks), aby sprawdzić konfigurację i przykłady.
|
||||
|
||||
### Hooki pluginów (cykl życia agenta + gateway)
|
||||
|
||||
Działają one wewnątrz pętli agenta lub potoku gateway:
|
||||
Uruchamiają się wewnątrz pętli agenta lub potoku gateway:
|
||||
|
||||
- **`before_model_resolve`**: uruchamia się przed sesją (bez `messages`), aby deterministycznie nadpisać provider/model przed rozstrzygnięciem modelu.
|
||||
- **`before_prompt_build`**: uruchamia się po załadowaniu sesji (z `messages`), aby wstrzyknąć `prependContext`, `systemPrompt`, `prependSystemContext` lub `appendSystemContext` przed wysłaniem promptu. Używaj `prependContext` dla dynamicznego tekstu na turę, a pól kontekstu systemowego dla stabilnych wskazówek, które powinny znajdować się w przestrzeni system prompt.
|
||||
- **`before_agent_start`**: przestarzały hook zgodności, który może uruchamiać się w obu fazach; preferuj powyższe jawne hooki.
|
||||
- **`before_agent_reply`**: uruchamia się po działaniach inline i przed wywołaniem LLM, pozwalając pluginowi przejąć turę i zwrócić syntetyczną odpowiedź albo całkowicie wyciszyć turę.
|
||||
- **`before_model_resolve`**: uruchamia się przed sesją (bez `messages`), aby deterministycznie nadpisać dostawcę/model przed rozwiązywaniem modelu.
|
||||
- **`before_prompt_build`**: uruchamia się po załadowaniu sesji (z `messages`), aby wstrzyknąć `prependContext`, `systemPrompt`, `prependSystemContext` lub `appendSystemContext` przed wysłaniem promptu. Używaj `prependContext` dla dynamicznego tekstu per tura, a pól kontekstu systemowego dla stabilnych wskazówek, które powinny znajdować się w przestrzeni promptu systemowego.
|
||||
- **`before_agent_start`**: hook zgodności wstecznej; może uruchamiać się w obu fazach; preferuj powyższe jawne hooki.
|
||||
- **`before_agent_reply`**: uruchamia się po działaniach inline i przed wywołaniem LLM, pozwalając pluginowi przejąć turę i zwrócić syntetyczną odpowiedź lub całkowicie wyciszyć turę.
|
||||
- **`agent_end`**: sprawdza końcową listę wiadomości i metadane przebiegu po zakończeniu.
|
||||
- **`before_compaction` / `after_compaction`**: obserwują lub adnotują cykle kompaktowania.
|
||||
- **`before_compaction` / `after_compaction`**: obserwują lub opisują cykle kompaktowania.
|
||||
- **`before_tool_call` / `after_tool_call`**: przechwytują parametry/wyniki narzędzi.
|
||||
- **`before_install`**: sprawdza wyniki skanowania wbudowanych elementów i opcjonalnie blokuje instalacje Skills lub pluginów.
|
||||
- **`tool_result_persist`**: synchronicznie przekształca wyniki narzędzi, zanim zostaną zapisane do transkryptu sesji.
|
||||
- **`before_install`**: sprawdza wbudowane wyniki skanowania i opcjonalnie blokuje instalacje skillów lub pluginów.
|
||||
- **`tool_result_persist`**: synchronicznie przekształca wyniki narzędzi przed zapisaniem ich do transkryptu sesji.
|
||||
- **`message_received` / `message_sending` / `message_sent`**: hooki wiadomości przychodzących i wychodzących.
|
||||
- **`session_start` / `session_end`**: granice cyklu życia sesji.
|
||||
- **`gateway_start` / `gateway_stop`**: zdarzenia cyklu życia gateway.
|
||||
|
||||
Zasady decyzji hooków dla ochrony wysyłania/narzędzi:
|
||||
Zasady decyzji hooków dla zabezpieczeń wychodzących/narzędzi:
|
||||
|
||||
- `before_tool_call`: `{ block: true }` jest terminalne i zatrzymuje handlery o niższym priorytecie.
|
||||
- `before_tool_call`: `{ block: false }` nic nie robi i nie czyści wcześniejszej blokady.
|
||||
- `before_install`: `{ block: true }` jest terminalne i zatrzymuje handlery o niższym priorytecie.
|
||||
- `before_install`: `{ block: false }` nic nie robi i nie czyści wcześniejszej blokady.
|
||||
- `message_sending`: `{ cancel: true }` jest terminalne i zatrzymuje handlery o niższym priorytecie.
|
||||
- `message_sending`: `{ cancel: false }` nic nie robi i nie czyści wcześniejszego anulowania.
|
||||
- `before_tool_call`: `{ block: true }` jest końcowe i zatrzymuje handlery o niższym priorytecie.
|
||||
- `before_tool_call`: `{ block: false }` nic nie robi i nie usuwa wcześniejszej blokady.
|
||||
- `before_install`: `{ block: true }` jest końcowe i zatrzymuje handlery o niższym priorytecie.
|
||||
- `before_install`: `{ block: false }` nic nie robi i nie usuwa wcześniejszej blokady.
|
||||
- `message_sending`: `{ cancel: true }` jest końcowe i zatrzymuje handlery o niższym priorytecie.
|
||||
- `message_sending`: `{ cancel: false }` nic nie robi i nie usuwa wcześniejszego anulowania.
|
||||
|
||||
Zobacz [Plugin hooks](/plugins/architecture#provider-runtime-hooks), aby poznać API hooków i szczegóły rejestracji.
|
||||
Zobacz [Hooki pluginów](/pl/plugins/architecture#provider-runtime-hooks), aby sprawdzić API hooków i szczegóły rejestracji.
|
||||
|
||||
## Strumieniowanie + odpowiedzi częściowe
|
||||
|
||||
- Delty asystenta są strumieniowane z pi-agent-core i emitowane jako zdarzenia `assistant`.
|
||||
- Strumieniowanie bloków może emitować odpowiedzi częściowe przy `text_end` albo `message_end`.
|
||||
- Strumieniowanie reasoning może być emitowane jako osobny strumień albo jako odpowiedzi blokowe.
|
||||
- Zobacz [Streaming](/concepts/streaming), aby poznać zachowanie chunkingu i odpowiedzi blokowych.
|
||||
- Strumieniowanie bloków może emitować odpowiedzi częściowe na `text_end` lub `message_end`.
|
||||
- Strumieniowanie rozumowania może być emitowane jako osobny strumień lub jako odpowiedzi blokowe.
|
||||
- Zobacz [Strumieniowanie](/pl/concepts/streaming), aby sprawdzić dzielenie na fragmenty i zachowanie odpowiedzi blokowych.
|
||||
|
||||
## Wykonywanie narzędzi + narzędzia wiadomości
|
||||
## Wykonanie narzędzi + narzędzia do wiadomości
|
||||
|
||||
- Zdarzenia rozpoczęcia/aktualizacji/zakończenia narzędzia są emitowane w strumieniu `tool`.
|
||||
- Wyniki narzędzi są oczyszczane pod kątem rozmiaru i ładunków obrazów przed logowaniem/emisją.
|
||||
- Wysłania przez narzędzia wiadomości są śledzone, aby tłumić zduplikowane potwierdzenia asystenta.
|
||||
- Zdarzenia start/aktualizacja/koniec narzędzi są emitowane w strumieniu `tool`.
|
||||
- Wyniki narzędzi są sanitizowane pod kątem rozmiaru i ładunków obrazów przed logowaniem/emisją.
|
||||
- Wysłania narzędzi do wiadomości są śledzone, aby wyeliminować zduplikowane potwierdzenia asystenta.
|
||||
|
||||
## Kształtowanie odpowiedzi + tłumienie
|
||||
## Kształtowanie odpowiedzi + wyciszanie
|
||||
|
||||
- Końcowe ładunki są składane z:
|
||||
- tekstu asystenta (oraz opcjonalnie reasoning)
|
||||
- tekstu asystenta (i opcjonalnie rozumowania)
|
||||
- podsumowań narzędzi inline (gdy verbose + dozwolone)
|
||||
- tekstu błędu asystenta, gdy model zwraca błąd
|
||||
- Dokładny cichy token `NO_REPLY` / `no_reply` jest filtrowany z wychodzących
|
||||
- Dokładny token wyciszenia `NO_REPLY` / `no_reply` jest odfiltrowywany z wychodzących
|
||||
ładunków.
|
||||
- Duplikaty z narzędzi wiadomości są usuwane z końcowej listy ładunków.
|
||||
- Jeśli nie pozostaną żadne renderowalne ładunki, a narzędzie zwróciło błąd, emitowana jest awaryjna odpowiedź o błędzie narzędzia
|
||||
(chyba że narzędzie wiadomości wysłało już odpowiedź widoczną dla użytkownika).
|
||||
- Duplikaty narzędzi do wiadomości są usuwane z końcowej listy ładunków.
|
||||
- Jeśli nie pozostaną żadne renderowalne ładunki, a narzędzie zwróciło błąd, emitowana jest
|
||||
zapasowa odpowiedź błędu narzędzia
|
||||
(chyba że narzędzie do wiadomości już wysłało widoczną dla użytkownika odpowiedź).
|
||||
|
||||
## Kompaktowanie + ponowne próby
|
||||
## Kompaktowanie + ponowienia
|
||||
|
||||
- Automatyczne kompaktowanie emituje zdarzenia strumienia `compaction` i może wywołać ponowną próbę.
|
||||
- Przy ponownej próbie bufory w pamięci i podsumowania narzędzi są resetowane, aby uniknąć zduplikowanego wyjścia.
|
||||
- Zobacz [Compaction](/concepts/compaction), aby poznać potok kompaktowania.
|
||||
- Automatyczne kompaktowanie emituje zdarzenia strumienia `compaction` i może wywołać ponowienie.
|
||||
- Przy ponowieniu bufory w pamięci i podsumowania narzędzi są resetowane, aby uniknąć zduplikowanego wyjścia.
|
||||
- Zobacz [Kompaktowanie](/pl/concepts/compaction), aby sprawdzić potok kompaktowania.
|
||||
|
||||
## Strumienie zdarzeń (obecnie)
|
||||
|
||||
@ -148,27 +150,28 @@ Zobacz [Plugin hooks](/plugins/architecture#provider-runtime-hooks), aby poznać
|
||||
- `assistant`: strumieniowane delty z pi-agent-core
|
||||
- `tool`: strumieniowane zdarzenia narzędzi z pi-agent-core
|
||||
|
||||
## Obsługa kanałów czatu
|
||||
## Obsługa kanału czatu
|
||||
|
||||
- Delty asystenta są buforowane jako wiadomości czatu `delta`.
|
||||
- `final` czatu jest emitowane przy **lifecycle end/error**.
|
||||
- Delty asystenta są buforowane do wiadomości czatu `delta`.
|
||||
- Końcowa wiadomość czatu `final` jest emitowana przy **końcu/błędzie cyklu życia**.
|
||||
|
||||
## Limity czasu
|
||||
|
||||
- Domyślnie `agent.wait`: 30 s (tylko samo oczekiwanie). Parametr `timeoutMs` nadpisuje.
|
||||
- Czas działania agenta: domyślnie `agents.defaults.timeoutSeconds` to 172800 s (48 godzin); wymuszane przez timer przerwania w `runEmbeddedPiAgent`.
|
||||
- Domyślnie `agent.wait`: 30 s (tylko oczekiwanie). Parametr `timeoutMs` nadpisuje tę wartość.
|
||||
- Czas działania agenta: domyślnie `agents.defaults.timeoutSeconds` to 172800 s (48 godzin); wymuszany przez licznik przerwania w `runEmbeddedPiAgent`.
|
||||
- Limit bezczynności LLM: `agents.defaults.llm.idleTimeoutSeconds` przerywa żądanie modelu, gdy przed upływem okna bezczynności nie nadejdą żadne fragmenty odpowiedzi. Ustaw tę wartość jawnie dla wolnych modeli lokalnych lub dostawców rozumowania/wywołań narzędzi; ustaw `0`, aby wyłączyć. Jeśli nie jest ustawiona, OpenClaw używa `agents.defaults.timeoutSeconds`, gdy jest skonfigurowane, w przeciwnym razie 60 s. Przebiegi wyzwalane przez cron bez jawnego limitu czasu LLM lub agenta wyłączają mechanizm bezczynności i polegają na zewnętrznym limicie czasu crona.
|
||||
|
||||
## Gdzie rzeczy mogą zakończyć się wcześniej
|
||||
## Gdzie wszystko może zakończyć się wcześniej
|
||||
|
||||
- Timeout agenta (przerwanie)
|
||||
- Limit czasu agenta (przerwanie)
|
||||
- AbortSignal (anulowanie)
|
||||
- Rozłączenie Gateway lub timeout RPC
|
||||
- Timeout `agent.wait` (dotyczy tylko oczekiwania, nie zatrzymuje agenta)
|
||||
- Rozłączenie gateway lub limit czasu RPC
|
||||
- Limit czasu `agent.wait` (tylko oczekiwanie, nie zatrzymuje agenta)
|
||||
|
||||
## Powiązane
|
||||
|
||||
- [Tools](/tools) — dostępne narzędzia agenta
|
||||
- [Hooks](/pl/automation/hooks) — skrypty sterowane zdarzeniami wywoływane przez zdarzenia cyklu życia agenta
|
||||
- [Compaction](/concepts/compaction) — jak długie rozmowy są podsumowywane
|
||||
- [Exec Approvals](/tools/exec-approvals) — bramki zatwierdzania dla poleceń powłoki
|
||||
- [Thinking](/tools/thinking) — konfiguracja poziomu thinking/reasoning
|
||||
- [Narzędzia](/pl/tools) — dostępne narzędzia agenta
|
||||
- [Hooki](/pl/automation/hooks) — skrypty sterowane zdarzeniami wyzwalane przez zdarzenia cyklu życia agenta
|
||||
- [Kompaktowanie](/pl/concepts/compaction) — jak podsumowywane są długie rozmowy
|
||||
- [Zgody exec](/pl/tools/exec-approvals) — bramki zatwierdzania dla poleceń powłoki
|
||||
- [Thinking](/pl/tools/thinking) — konfiguracja poziomu myślenia/rozumowania
|
||||
|
||||
@ -1,124 +1,138 @@
|
||||
---
|
||||
read_when:
|
||||
- Chcesz, aby promowanie pamięci uruchamiało się automatycznie
|
||||
- Chcesz zrozumieć, co robi każda faza śnienia
|
||||
- Chcesz zrozumieć, co robi każda faza dreaming
|
||||
- Chcesz dostroić konsolidację bez zaśmiecania `MEMORY.md`
|
||||
summary: Konsolidacja pamięci w tle z fazami lekką, głęboką i REM oraz Dziennikiem snów
|
||||
title: Śnienie (eksperymentalne)
|
||||
summary: Konsolidacja pamięci w tle z fazami light, deep i REM oraz Dream Diary
|
||||
title: Dreaming (eksperymentalne)
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T09:44:09Z"
|
||||
generated_at: "2026-04-09T01:27:48Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 0254f3b0949158264e583c12f36f2b1a83d1b44dc4da01a1b272422d38e8655d
|
||||
source_hash: 26476eddb8260e1554098a6adbb069cf7f5e284cf2e09479c6d9d8f8b93280ef
|
||||
source_path: concepts/dreaming.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Śnienie (eksperymentalne)
|
||||
# Dreaming (eksperymentalne)
|
||||
|
||||
Śnienie to system konsolidacji pamięci działający w tle w `memory-core`.
|
||||
Pomaga OpenClaw przenosić silne sygnały pamięci krótkoterminowej do trwałej pamięci,
|
||||
jednocześnie zachowując przejrzystość i możliwość przeglądu tego procesu.
|
||||
Dreaming to system konsolidacji pamięci w tle w `memory-core`.
|
||||
Pomaga OpenClaw przenosić silne krótkoterminowe sygnały do trwałej pamięci, jednocześnie
|
||||
zachowując przejrzystość i możliwość przeglądu procesu.
|
||||
|
||||
Śnienie jest **opcjonalne** i domyślnie wyłączone.
|
||||
Dreaming jest funkcją **opt-in** i domyślnie jest wyłączone.
|
||||
|
||||
## Co zapisuje śnienie
|
||||
## Co zapisuje dreaming
|
||||
|
||||
Śnienie przechowuje dwa rodzaje danych wyjściowych:
|
||||
Dreaming utrzymuje dwa rodzaje danych wyjściowych:
|
||||
|
||||
- **Stan maszyny** w `memory/.dreams/` (magazyn przywołań, sygnały faz, punkty kontrolne przetwarzania, blokady).
|
||||
- **Stan maszyny** w `memory/.dreams/` (magazyn przypomnień, sygnały faz, punkty kontrolne ingestii, blokady).
|
||||
- **Dane czytelne dla człowieka** w `DREAMS.md` (lub istniejącym `dreams.md`) oraz opcjonalne pliki raportów faz w `memory/dreaming/<phase>/YYYY-MM-DD.md`.
|
||||
|
||||
Promowanie do pamięci długoterminowej nadal zapisuje dane wyłącznie do `MEMORY.md`.
|
||||
Promowanie do pamięci długoterminowej nadal zapisuje wyłącznie do `MEMORY.md`.
|
||||
|
||||
## Model faz
|
||||
|
||||
Śnienie używa trzech współpracujących faz:
|
||||
Dreaming używa trzech współpracujących faz:
|
||||
|
||||
| Faza | Cel | Trwały zapis |
|
||||
| ----- | ---------------------------------------- | ----------------- |
|
||||
| Lekka | Sortowanie i przygotowywanie ostatnich materiałów krótkoterminowych | Nie |
|
||||
| Głęboka | Ocenianie i promowanie trwałych kandydatów | Tak (`MEMORY.md`) |
|
||||
| REM | Refleksja nad motywami i powracającymi pomysłami | Nie |
|
||||
| Faza | Cel | Trwały zapis |
|
||||
| ----- | ----------------------------------------- | ----------------- |
|
||||
| Light | Sortowanie i przygotowanie ostatnich materiałów krótkoterminowych | Nie |
|
||||
| Deep | Ocenianie i promowanie trwałych kandydatów | Tak (`MEMORY.md`) |
|
||||
| REM | Refleksja nad tematami i powracającymi ideami | Nie |
|
||||
|
||||
Te fazy są wewnętrznymi szczegółami implementacji, a nie osobnymi
|
||||
Te fazy są wewnętrznymi szczegółami implementacji, a nie oddzielnymi
|
||||
konfigurowanymi przez użytkownika „trybami”.
|
||||
|
||||
### Faza lekka
|
||||
### Faza light
|
||||
|
||||
Faza lekka przetwarza ostatnie sygnały dziennej pamięci i ślady przywołań, usuwa duplikaty
|
||||
i przygotowuje linie kandydatów.
|
||||
Faza light pobiera ostatnie dzienne sygnały pamięci i ślady przypomnień, usuwa duplikaty
|
||||
i przygotowuje wiersze kandydatów.
|
||||
|
||||
- Odczytuje stan przywołań krótkoterminowych, ostatnie dzienne pliki pamięci oraz zredagowane transkrypty sesji, jeśli są dostępne.
|
||||
- Zapisuje zarządzany blok `## Light Sleep`, gdy magazyn zawiera dane wyjściowe osadzone w pliku.
|
||||
- Rejestruje sygnały wzmocnienia do późniejszego rankingu głębokiego.
|
||||
- Odczytuje stan krótkoterminowych przypomnień, ostatnie dzienne pliki pamięci oraz zredagowane transkrypty sesji, gdy są dostępne.
|
||||
- Zapisuje zarządzany blok `## Light Sleep`, gdy magazyn zawiera dane wyjściowe inline.
|
||||
- Rejestruje sygnały wzmacniające na potrzeby późniejszego rankingu deep.
|
||||
- Nigdy nie zapisuje do `MEMORY.md`.
|
||||
|
||||
### Faza głęboka
|
||||
### Faza deep
|
||||
|
||||
Faza głęboka decyduje, co trafia do pamięci długoterminowej.
|
||||
Faza deep decyduje, co staje się pamięcią długoterminową.
|
||||
|
||||
- Ustala ranking kandydatów przy użyciu ważonej punktacji i progów.
|
||||
- Wymaga spełnienia `minScore`, `minRecallCount` oraz `minUniqueQueries`.
|
||||
- Przed zapisem ponownie pobiera fragmenty z bieżących plików dziennych, więc nieaktualne lub usunięte fragmenty są pomijane.
|
||||
- Wymaga spełnienia wartości `minScore`, `minRecallCount` i `minUniqueQueries`.
|
||||
- Przed zapisem ponownie pobiera fragmenty z aktywnych plików dziennych, więc nieaktualne/usunięte fragmenty są pomijane.
|
||||
- Dopisuje promowane wpisy do `MEMORY.md`.
|
||||
- Zapisuje podsumowanie `## Deep Sleep` w `DREAMS.md` i opcjonalnie zapisuje `memory/dreaming/deep/YYYY-MM-DD.md`.
|
||||
- Zapisuje podsumowanie `## Deep Sleep` do `DREAMS.md` i opcjonalnie zapisuje `memory/dreaming/deep/YYYY-MM-DD.md`.
|
||||
|
||||
### Faza REM
|
||||
|
||||
Faza REM wyodrębnia wzorce i sygnały refleksyjne.
|
||||
|
||||
- Buduje podsumowania motywów i refleksji na podstawie ostatnich śladów krótkoterminowych.
|
||||
- Zapisuje zarządzany blok `## REM Sleep`, gdy magazyn zawiera dane wyjściowe osadzone w pliku.
|
||||
- Rejestruje sygnały wzmocnienia REM używane przez ranking głęboki.
|
||||
- Buduje podsumowania tematów i refleksji na podstawie ostatnich krótkoterminowych śladów.
|
||||
- Zapisuje zarządzany blok `## REM Sleep`, gdy magazyn zawiera dane wyjściowe inline.
|
||||
- Rejestruje sygnały wzmacniające REM używane przez ranking deep.
|
||||
- Nigdy nie zapisuje do `MEMORY.md`.
|
||||
|
||||
## Przetwarzanie transkryptów sesji
|
||||
## Ingestia transkryptów sesji
|
||||
|
||||
Śnienie może przetwarzać zredagowane transkrypty sesji do korpusu śnienia. Gdy
|
||||
transkrypty są dostępne, są przekazywane do fazy lekkiej razem z dziennymi
|
||||
sygnałami pamięci i śladami przywołań. Treści osobiste i wrażliwe są redagowane
|
||||
przed przetworzeniem.
|
||||
Dreaming może pobierać zredagowane transkrypty sesji do korpusu dreaming. Gdy
|
||||
transkrypty są dostępne, są przekazywane do fazy light razem z dziennymi
|
||||
sygnałami pamięci i śladami przypomnień. Treści osobiste i wrażliwe są redagowane
|
||||
przed ingestą.
|
||||
|
||||
## Dziennik snów
|
||||
## Dream Diary
|
||||
|
||||
Śnienie prowadzi również narracyjny **Dziennik snów** w `DREAMS.md`.
|
||||
Gdy po każdej fazie zbierze się wystarczająco dużo materiału, `memory-core` uruchamia
|
||||
w tle, w trybie best-effort, turę podagenta (z użyciem domyślnego modelu runtime)
|
||||
Dreaming prowadzi także narracyjny **Dream Diary** w `DREAMS.md`.
|
||||
Gdy po każdej fazie zgromadzi się wystarczająco dużo materiału, `memory-core` uruchamia w tle
|
||||
podrzędny turn subagenta typu best-effort (przy użyciu domyślnego modelu runtime)
|
||||
i dopisuje krótki wpis do dziennika.
|
||||
|
||||
Ten dziennik służy do czytania przez człowieka w interfejsie Dreams, a nie jako źródło promocji.
|
||||
Ten dziennik jest przeznaczony do odczytu przez człowieka w interfejsie Dreams, a nie jako źródło promocji.
|
||||
|
||||
## Sygnały rankingu głębokiego
|
||||
Istnieje również ugruntowana ścieżka historycznego backfill dla przeglądu i odzyskiwania:
|
||||
|
||||
Ranking głęboki używa sześciu ważonych sygnałów bazowych oraz wzmocnienia faz:
|
||||
- `memory rem-harness --path ... --grounded` wyświetla podgląd ugruntowanych wpisów dziennika na podstawie historycznych notatek `YYYY-MM-DD.md`.
|
||||
- `memory rem-backfill --path ...` zapisuje odwracalne ugruntowane wpisy dziennika do `DREAMS.md`.
|
||||
- `memory rem-backfill --path ... --stage-short-term` przygotowuje ugruntowanych trwałych kandydatów w tym samym magazynie dowodów krótkoterminowych, którego używa już normalna faza deep.
|
||||
- `memory rem-backfill --rollback` i `--rollback-short-term` usuwają te przygotowane artefakty backfill bez naruszania zwykłych wpisów dziennika ani aktywnych krótkoterminowych przypomnień.
|
||||
|
||||
| Sygnał | Waga | Opis |
|
||||
Control UI udostępnia ten sam przepływ backfill/reset dziennika, dzięki czemu możesz sprawdzić
|
||||
wyniki w scenie Dreams przed podjęciem decyzji, czy ugruntowani kandydaci
|
||||
zasługują na promocję. Scena pokazuje też odrębny ugruntowany tor, aby było widać,
|
||||
które przygotowane wpisy krótkoterminowe pochodzą z historycznego odtworzenia, które promowane
|
||||
elementy były prowadzone przez grounded, oraz umożliwia wyczyszczenie tylko ugruntowanych przygotowanych wpisów bez
|
||||
naruszania zwykłego aktywnego stanu krótkoterminowego.
|
||||
|
||||
## Sygnały rankingu deep
|
||||
|
||||
Ranking deep używa sześciu ważonych sygnałów bazowych oraz wzmocnienia fazowego:
|
||||
|
||||
| Sygnał | Waga | Opis |
|
||||
| ------------------- | ------ | ------------------------------------------------- |
|
||||
| Częstotliwość | 0.24 | Ile sygnałów krótkoterminowych zgromadził wpis |
|
||||
| Trafność | 0.30 | Średnia jakość pobierania dla wpisu |
|
||||
| Różnorodność zapytań | 0.15 | Różne konteksty zapytań/dni, w których się pojawił |
|
||||
| Aktualność | 0.15 | Wynik świeżości z zanikiem w czasie |
|
||||
| Konsolidacja | 0.10 | Siła nawrotów w wielu dniach |
|
||||
| Bogactwo pojęciowe | 0.06 | Gęstość tagów pojęciowych z fragmentu/ścieżki |
|
||||
| Częstotliwość | 0.24 | Ile krótkoterminowych sygnałów zgromadził wpis |
|
||||
| Trafność | 0.30 | Średnia jakość odzyskiwania dla wpisu |
|
||||
| Różnorodność zapytań | 0.15 | Odrębne konteksty zapytania/dnia, które go ujawniły |
|
||||
| Aktualność | 0.15 | Wynik świeżości z zanikiem w czasie |
|
||||
| Konsolidacja | 0.10 | Siła nawrotów w wielu dniach |
|
||||
| Bogactwo pojęciowe | 0.06 | Gęstość tagów pojęciowych z fragmentu/ścieżki |
|
||||
|
||||
Trafienia fazy lekkiej i REM dodają niewielkie wzmocnienie z zanikiem aktualności z
|
||||
Trafienia w fazach light i REM dodają niewielkie wzmocnienie z zanikiem aktualności z
|
||||
`memory/.dreams/phase-signals.json`.
|
||||
|
||||
## Harmonogram
|
||||
|
||||
Po włączeniu `memory-core` automatycznie zarządza jednym zadaniem cron dla pełnego
|
||||
przebiegu śnienia. Każdy przebieg uruchamia fazy w kolejności: lekka -> REM -> głęboka.
|
||||
przebiegu dreaming. Każdy przebieg uruchamia fazy po kolei: light -> REM -> deep.
|
||||
|
||||
Domyślne zachowanie harmonogramu:
|
||||
Domyślne zachowanie kadencji:
|
||||
|
||||
| Ustawienie | Domyślna wartość |
|
||||
| -------------------- | ----------- |
|
||||
| Ustawienie | Domyślnie |
|
||||
| ------------------- | ---------- |
|
||||
| `dreaming.frequency` | `0 3 * * *` |
|
||||
|
||||
## Szybki start
|
||||
|
||||
Włącz śnienie:
|
||||
Włącz dreaming:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -136,7 +150,7 @@ Włącz śnienie:
|
||||
}
|
||||
```
|
||||
|
||||
Włącz śnienie z niestandardowym harmonogramem przebiegów:
|
||||
Włącz dreaming z niestandardową kadencją przebiegu:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -156,7 +170,7 @@ Włącz śnienie z niestandardowym harmonogramem przebiegów:
|
||||
}
|
||||
```
|
||||
|
||||
## Polecenie ukośnikowe
|
||||
## Komenda slash
|
||||
|
||||
```
|
||||
/dreaming status
|
||||
@ -167,7 +181,7 @@ Włącz śnienie z niestandardowym harmonogramem przebiegów:
|
||||
|
||||
## Przepływ pracy CLI
|
||||
|
||||
Użyj promocji w CLI do podglądu lub ręcznego zastosowania:
|
||||
Użyj promowania przez CLI do podglądu lub ręcznego zastosowania:
|
||||
|
||||
```bash
|
||||
openclaw memory promote
|
||||
@ -176,7 +190,7 @@ openclaw memory promote --limit 5
|
||||
openclaw memory status --deep
|
||||
```
|
||||
|
||||
Ręczne `memory promote` domyślnie używa progów fazy głębokiej, o ile nie zostaną nadpisane
|
||||
Ręczne `memory promote` domyślnie używa progów fazy deep, chyba że zostaną nadpisane
|
||||
flagami CLI.
|
||||
|
||||
Wyjaśnij, dlaczego konkretny kandydat zostałby lub nie zostałby promowany:
|
||||
@ -186,7 +200,7 @@ openclaw memory promote-explain "router vlan"
|
||||
openclaw memory promote-explain "router vlan" --json
|
||||
```
|
||||
|
||||
Wyświetl podgląd refleksji REM, prawd kandydatów i danych wyjściowych promocji głębokiej bez
|
||||
Wyświetl podgląd refleksji REM, prawd kandydatów i danych wyjściowych promocji deep bez
|
||||
zapisywania czegokolwiek:
|
||||
|
||||
```bash
|
||||
@ -198,29 +212,30 @@ openclaw memory rem-harness --json
|
||||
|
||||
Wszystkie ustawienia znajdują się w `plugins.entries.memory-core.config.dreaming`.
|
||||
|
||||
| Klucz | Domyślna wartość |
|
||||
| ----------- | ----------- |
|
||||
| Klucz | Domyślnie |
|
||||
| ---------- | ---------- |
|
||||
| `enabled` | `false` |
|
||||
| `frequency` | `0 3 * * *` |
|
||||
|
||||
Polityka faz, progi i zachowanie magazynu są wewnętrznymi szczegółami implementacji
|
||||
(i nie stanowią konfiguracji dostępnej dla użytkownika).
|
||||
(nie są to ustawienia dostępne dla użytkownika).
|
||||
|
||||
Pełną listę kluczy znajdziesz w [Dokumentacji konfiguracji pamięci](/pl/reference/memory-config#dreaming-experimental).
|
||||
Pełną listę kluczy znajdziesz w [Memory configuration reference](/pl/reference/memory-config#dreaming-experimental).
|
||||
|
||||
## Interfejs Dreams
|
||||
|
||||
Po włączeniu karta **Dreams** w Gateway pokazuje:
|
||||
|
||||
- bieżący stan włączenia śnienia
|
||||
- stan na poziomie faz i obecność zarządzanego przebiegu
|
||||
- liczbę elementów krótkoterminowych, długoterminowych i promowanych dzisiaj
|
||||
- bieżący stan włączenia dreaming
|
||||
- stan na poziomie faz oraz obecność zarządzanego przebiegu
|
||||
- liczby elementów krótkoterminowych, ugruntowanych, sygnałów i promowanych dzisiaj
|
||||
- czas następnego zaplanowanego uruchomienia
|
||||
- rozwijany czytnik Dziennika snów oparty na `doctor.memory.dreamDiary`
|
||||
- odrębny ugruntowany tor sceny dla przygotowanych wpisów historycznego odtworzenia
|
||||
- rozwijany czytnik Dream Diary oparty na `doctor.memory.dreamDiary`
|
||||
|
||||
## Powiązane
|
||||
|
||||
- [Pamięć](/pl/concepts/memory)
|
||||
- [Wyszukiwanie w pamięci](/pl/concepts/memory-search)
|
||||
- [CLI pamięci](/cli/memory)
|
||||
- [Dokumentacja konfiguracji pamięci](/pl/reference/memory-config)
|
||||
- [Memory](/pl/concepts/memory)
|
||||
- [Memory Search](/pl/concepts/memory-search)
|
||||
- [memory CLI](/cli/memory)
|
||||
- [Memory configuration reference](/pl/reference/memory-config)
|
||||
|
||||
@ -1,23 +1,23 @@
|
||||
---
|
||||
read_when:
|
||||
- Chcesz zrozumieć, jak działa pamięć
|
||||
- Chcesz wiedzieć, jakie pliki pamięci zapisywać
|
||||
- Chcesz wiedzieć, które pliki pamięci zapisywać
|
||||
summary: Jak OpenClaw zapamiętuje rzeczy między sesjami
|
||||
title: Przegląd pamięci
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T06:01:02Z"
|
||||
generated_at: "2026-04-09T01:27:50Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 3bb8552341b0b651609edaaae826a22fdc535d240aed4fad4af4b069454004af
|
||||
source_hash: 2fe47910f5bf1c44be379e971c605f1cb3a29befcf2a7ee11fb3833cbe3b9059
|
||||
source_path: concepts/memory.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Przegląd pamięci
|
||||
|
||||
OpenClaw zapamiętuje rzeczy, zapisując **zwykłe pliki Markdown** w przestrzeni
|
||||
roboczej Twojego agenta. Model „pamięta” tylko to, co zostanie zapisane na dysku —
|
||||
nie ma żadnego ukrytego stanu.
|
||||
OpenClaw zapamiętuje rzeczy, zapisując **zwykłe pliki Markdown** w obszarze roboczym
|
||||
Twojego agenta. Model „pamięta” tylko to, co zostanie zapisane na dysku — nie ma
|
||||
żadnego ukrytego stanu.
|
||||
|
||||
## Jak to działa
|
||||
|
||||
@ -26,77 +26,78 @@ Twój agent ma trzy pliki związane z pamięcią:
|
||||
- **`MEMORY.md`** — pamięć długoterminowa. Trwałe fakty, preferencje i
|
||||
decyzje. Wczytywany na początku każdej sesji DM.
|
||||
- **`memory/YYYY-MM-DD.md`** — codzienne notatki. Bieżący kontekst i obserwacje.
|
||||
Dzisiejsze i wczorajsze notatki są wczytywane automatycznie.
|
||||
- **`DREAMS.md`** (eksperymentalny, opcjonalny) — Dream Diary i podsumowania
|
||||
przebiegów śnienia do przeglądu przez człowieka.
|
||||
Notatki z dziś i z wczoraj są wczytywane automatycznie.
|
||||
- **`DREAMS.md`** (eksperymentalny, opcjonalny) — Dream Diary oraz podsumowania
|
||||
przebiegów dreaming do przeglądu przez człowieka, w tym ugruntowane wpisy
|
||||
historycznego backfill.
|
||||
|
||||
Te pliki znajdują się w przestrzeni roboczej agenta (domyślnie `~/.openclaw/workspace`).
|
||||
Te pliki znajdują się w obszarze roboczym agenta (domyślnie `~/.openclaw/workspace`).
|
||||
|
||||
<Tip>
|
||||
Jeśli chcesz, aby Twój agent coś zapamiętał, po prostu mu to powiedz: „Pamiętaj,
|
||||
że wolę TypeScript.” Zapisze to do odpowiedniego pliku.
|
||||
Jeśli chcesz, aby Twój agent coś zapamiętał, po prostu go o to poproś: „Zapamiętaj, że
|
||||
preferuję TypeScript.” Zapisze to do odpowiedniego pliku.
|
||||
</Tip>
|
||||
|
||||
## Narzędzia pamięci
|
||||
|
||||
Agent ma dwa narzędzia do pracy z pamięcią:
|
||||
|
||||
- **`memory_search`** — znajduje odpowiednie notatki za pomocą wyszukiwania semantycznego, nawet gdy
|
||||
sformułowanie różni się od oryginału.
|
||||
- **`memory_get`** — odczytuje konkretny plik pamięci lub zakres wierszy.
|
||||
- **`memory_search`** — znajduje odpowiednie notatki za pomocą wyszukiwania
|
||||
semantycznego, nawet gdy sformułowanie różni się od oryginału.
|
||||
- **`memory_get`** — odczytuje określony plik pamięci lub zakres wierszy.
|
||||
|
||||
Oba narzędzia są dostarczane przez aktywny plugin pamięci (domyślnie: `memory-core`).
|
||||
|
||||
## Plugin towarzyszący Memory Wiki
|
||||
## Towarzyszący plugin Memory Wiki
|
||||
|
||||
Jeśli chcesz, aby trwała pamięć działała bardziej jak utrzymywana baza wiedzy niż
|
||||
tylko surowe notatki, użyj dołączonego pluginu `memory-wiki`.
|
||||
|
||||
`memory-wiki` kompiluje trwałą wiedzę do skarbca wiki z:
|
||||
`memory-wiki` kompiluje trwałą wiedzę do wiki vault z:
|
||||
|
||||
- deterministyczną strukturą stron
|
||||
- uporządkowanymi twierdzeniami i dowodami
|
||||
- ustrukturyzowanymi twierdzeniami i dowodami
|
||||
- śledzeniem sprzeczności i aktualności
|
||||
- generowanymi pulpitami
|
||||
- skompilowanymi skrótami dla agentów/środowiska uruchomieniowego
|
||||
- narzędziami natywnymi dla wiki, takimi jak `wiki_search`, `wiki_get`, `wiki_apply` i `wiki_lint`
|
||||
- skompilowanymi skrótami dla konsumentów agent/runtime
|
||||
- natywnymi dla wiki narzędziami, takimi jak `wiki_search`, `wiki_get`, `wiki_apply` i `wiki_lint`
|
||||
|
||||
Nie zastępuje aktywnego pluginu pamięci. Aktywny plugin pamięci nadal
|
||||
odpowiada za przywoływanie, promowanie i śnienie. `memory-wiki` dodaje obok niego
|
||||
warstwę wiedzy bogatą w informacje o pochodzeniu.
|
||||
odpowiada za przypominanie, promowanie i dreaming. `memory-wiki` dodaje
|
||||
warstwę wiedzy bogatą w pochodzenie obok niego.
|
||||
|
||||
Zobacz [Memory Wiki](/pl/plugins/memory-wiki).
|
||||
|
||||
## Wyszukiwanie w pamięci
|
||||
|
||||
Gdy skonfigurowany jest dostawca osadzeń, `memory_search` używa **wyszukiwania
|
||||
hybrydowego** — łącząc podobieństwo wektorowe (znaczenie semantyczne) z dopasowaniem słów kluczowych
|
||||
(dokładne terminy, takie jak identyfikatory i symbole kodu). Działa to od razu po
|
||||
dodaniu klucza API dla dowolnego obsługiwanego dostawcy.
|
||||
Gdy skonfigurowany jest dostawca embeddingów, `memory_search` używa **wyszukiwania
|
||||
hybrydowego** — łączącego podobieństwo wektorowe (znaczenie semantyczne) z dopasowaniem
|
||||
słów kluczowych (dokładne terminy, takie jak identyfikatory i symbole kodu).
|
||||
Działa to od razu po skonfigurowaniu klucza API dla dowolnego obsługiwanego dostawcy.
|
||||
|
||||
<Info>
|
||||
OpenClaw automatycznie wykrywa dostawcę osadzeń na podstawie dostępnych kluczy API. Jeśli
|
||||
OpenClaw automatycznie wykrywa dostawcę embeddingów na podstawie dostępnych kluczy API. Jeśli
|
||||
masz skonfigurowany klucz OpenAI, Gemini, Voyage lub Mistral, wyszukiwanie w pamięci
|
||||
jest włączane automatycznie.
|
||||
</Info>
|
||||
|
||||
Szczegółowe informacje o działaniu wyszukiwania, opcjach dostrajania i konfiguracji dostawców znajdziesz w
|
||||
[Memory Search](/pl/concepts/memory-search).
|
||||
Szczegółowe informacje o działaniu wyszukiwania, opcjach dostrajania i konfiguracji
|
||||
dostawców znajdziesz w [Memory Search](/pl/concepts/memory-search).
|
||||
|
||||
## Backendy pamięci
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Wbudowany (domyślny)" icon="database" href="/pl/concepts/memory-builtin">
|
||||
Oparty na SQLite. Działa od razu z wyszukiwaniem po słowach kluczowych, podobieństwem wektorowym i
|
||||
Oparty na SQLite. Działa od razu z wyszukiwaniem słów kluczowych, podobieństwem wektorowym i
|
||||
wyszukiwaniem hybrydowym. Bez dodatkowych zależności.
|
||||
</Card>
|
||||
<Card title="QMD" icon="search" href="/pl/concepts/memory-qmd">
|
||||
Lokalny sidecar z rerankingiem, rozszerzaniem zapytań i możliwością indeksowania
|
||||
katalogów poza przestrzenią roboczą.
|
||||
katalogów poza obszarem roboczym.
|
||||
</Card>
|
||||
<Card title="Honcho" icon="brain" href="/pl/concepts/memory-honcho">
|
||||
Natywna dla AI pamięć między sesjami z modelowaniem użytkownika, wyszukiwaniem semantycznym i
|
||||
świadomością wielu agentów. Instalacja pluginu.
|
||||
świadomością wielu agentów. Wymaga instalacji pluginu.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
@ -104,48 +105,83 @@ Natywna dla AI pamięć między sesjami z modelowaniem użytkownika, wyszukiwani
|
||||
|
||||
<CardGroup cols={1}>
|
||||
<Card title="Memory Wiki" icon="book" href="/pl/plugins/memory-wiki">
|
||||
Kompiluje trwałą pamięć do skarbca wiki bogatego w informacje o pochodzeniu, z twierdzeniami,
|
||||
pulpitami, trybem bridge i przepływami pracy przyjaznymi dla Obsidian.
|
||||
Kompiluje trwałą pamięć do wiki vault bogatego w pochodzenie z twierdzeniami,
|
||||
pulpitami, trybem mostu i przepływami pracy przyjaznymi dla Obsidian.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Automatyczne opróżnianie pamięci
|
||||
|
||||
Zanim [kompaktowanie](/pl/concepts/compaction) podsumuje Twoją rozmowę, OpenClaw
|
||||
uruchamia cichą turę, która przypomina agentowi o zapisaniu ważnego kontekstu do plików
|
||||
pamięci. Jest to domyślnie włączone — nie musisz niczego konfigurować.
|
||||
uruchamia cichą turę, która przypomina agentowi o zapisaniu ważnego kontekstu w plikach
|
||||
pamięci. Jest to domyślnie włączone — nie musisz nic konfigurować.
|
||||
|
||||
<Tip>
|
||||
Opróżnianie pamięci zapobiega utracie kontekstu podczas kompaktowania. Jeśli Twój agent ma
|
||||
w rozmowie ważne fakty, które nie zostały jeszcze zapisane do pliku,
|
||||
zostaną zapisane automatycznie przed utworzeniem podsumowania.
|
||||
w rozmowie ważne fakty, które nie zostały jeszcze zapisane do pliku, zostaną one
|
||||
zapisane automatycznie, zanim nastąpi podsumowanie.
|
||||
</Tip>
|
||||
|
||||
## Śnienie (eksperymentalne)
|
||||
## Dreaming (eksperymentalne)
|
||||
|
||||
Śnienie to opcjonalny proces konsolidacji pamięci działający w tle. Zbiera
|
||||
sygnały krótkoterminowe, ocenia kandydatów i promuje tylko kwalifikujące się elementy do
|
||||
pamięci długoterminowej (`MEMORY.md`).
|
||||
Dreaming to opcjonalny przebieg konsolidacji pamięci w tle. Zbiera
|
||||
sygnały krótkoterminowe, ocenia kandydatów i promuje do pamięci
|
||||
długoterminowej (`MEMORY.md`) tylko elementy spełniające kryteria.
|
||||
|
||||
Zostało zaprojektowane tak, aby utrzymywać wysoki stosunek sygnału do szumu w pamięci długoterminowej:
|
||||
Został zaprojektowany tak, aby utrzymywać wysoki stosunek sygnału do szumu w pamięci długoterminowej:
|
||||
|
||||
- **Opt-in**: domyślnie wyłączone.
|
||||
- **Zaplanowane**: po włączeniu `memory-core` automatycznie zarządza jednym cyklicznym zadaniem cron
|
||||
dla pełnego przebiegu śnienia.
|
||||
- **Progowe**: promocje muszą przejść progi punktacji, częstotliwości przywołań i
|
||||
- **Harmonogram**: po włączeniu `memory-core` automatycznie zarządza jednym cyklicznym zadaniem cron
|
||||
dla pełnego przebiegu dreaming.
|
||||
- **Progowe**: promocje muszą przejść progi wyniku, częstotliwości przypominania i
|
||||
różnorodności zapytań.
|
||||
- **Możliwe do przeglądu**: podsumowania faz i wpisy dziennika są zapisywane do `DREAMS.md`
|
||||
do przeglądu przez człowieka.
|
||||
|
||||
Informacje o zachowaniu faz, sygnałach punktacji i szczegółach Dream Diary znajdziesz w
|
||||
Informacje o zachowaniu faz, sygnałach oceniania i szczegółach Dream Diary znajdziesz w
|
||||
[Dreaming (experimental)](/pl/concepts/dreaming).
|
||||
|
||||
## Ugruntowany backfill i promocja na żywo
|
||||
|
||||
System dreaming ma teraz dwa ściśle powiązane tory przeglądu:
|
||||
|
||||
- **Live dreaming** działa na podstawie krótkoterminowego magazynu dreaming w
|
||||
`memory/.dreams/` i to właśnie z niego korzysta normalna głęboka faza przy podejmowaniu decyzji, co
|
||||
może zostać przeniesione do `MEMORY.md`.
|
||||
- **Grounded backfill** odczytuje historyczne notatki `memory/YYYY-MM-DD.md` jako
|
||||
samodzielne pliki dzienne i zapisuje ustrukturyzowany wynik przeglądu do `DREAMS.md`.
|
||||
|
||||
Grounded backfill jest przydatny, gdy chcesz ponownie przeanalizować starsze notatki i sprawdzić,
|
||||
co system uważa za trwałe, bez ręcznego edytowania `MEMORY.md`.
|
||||
|
||||
Gdy użyjesz:
|
||||
|
||||
```bash
|
||||
openclaw memory rem-backfill --path ./memory --stage-short-term
|
||||
```
|
||||
|
||||
ugruntowani kandydaci trwałej pamięci nie są promowani bezpośrednio. Są etapowani do
|
||||
tego samego krótkoterminowego magazynu dreaming, z którego korzysta już normalna głęboka faza. To
|
||||
oznacza, że:
|
||||
|
||||
- `DREAMS.md` pozostaje powierzchnią przeglądu dla człowieka.
|
||||
- magazyn krótkoterminowy pozostaje powierzchnią rankingową dla maszyn.
|
||||
- `MEMORY.md` nadal jest zapisywany wyłącznie przez głęboką promocję.
|
||||
|
||||
Jeśli uznasz, że ponowne odtworzenie nie było przydatne, możesz usunąć etapowane artefakty
|
||||
bez naruszania zwykłych wpisów dziennika ani normalnego stanu przypominania:
|
||||
|
||||
```bash
|
||||
openclaw memory rem-backfill --rollback
|
||||
openclaw memory rem-backfill --rollback-short-term
|
||||
```
|
||||
|
||||
## CLI
|
||||
|
||||
```bash
|
||||
openclaw memory status # Sprawdź stan indeksu i dostawcę
|
||||
openclaw memory search "query" # Wyszukuj z wiersza poleceń
|
||||
openclaw memory index --force # Przebuduj indeks
|
||||
openclaw memory search "query" # Wyszukiwanie z wiersza poleceń
|
||||
openclaw memory index --force # Odbuduj indeks
|
||||
```
|
||||
|
||||
## Dalsza lektura
|
||||
@ -153,10 +189,10 @@ openclaw memory index --force # Przebuduj indeks
|
||||
- [Builtin Memory Engine](/pl/concepts/memory-builtin) — domyślny backend SQLite
|
||||
- [QMD Memory Engine](/pl/concepts/memory-qmd) — zaawansowany lokalny sidecar
|
||||
- [Honcho Memory](/pl/concepts/memory-honcho) — natywna dla AI pamięć między sesjami
|
||||
- [Memory Wiki](/pl/plugins/memory-wiki) — skompilowany skarbiec wiedzy i narzędzia natywne dla wiki
|
||||
- [Memory Wiki](/pl/plugins/memory-wiki) — skompilowany sejf wiedzy i narzędzia natywne dla wiki
|
||||
- [Memory Search](/pl/concepts/memory-search) — potok wyszukiwania, dostawcy i
|
||||
dostrajanie
|
||||
- [Dreaming (experimental)](/pl/concepts/dreaming) — promowanie w tle
|
||||
z krótkoterminowego przywoływania do pamięci długoterminowej
|
||||
- [Dreaming (experimental)](/pl/concepts/dreaming) — promocja w tle
|
||||
z krótkoterminowego przypominania do pamięci długoterminowej
|
||||
- [Memory configuration reference](/pl/reference/memory-config) — wszystkie opcje konfiguracji
|
||||
- [Compaction](/pl/concepts/compaction) — jak kompaktowanie współdziała z pamięcią
|
||||
|
||||
@ -1,14 +1,14 @@
|
||||
---
|
||||
read_when:
|
||||
- Potrzebujesz referencji konfiguracji modeli dla poszczególnych dostawców
|
||||
- Chcesz zobaczyć przykładowe konfiguracje lub polecenia wdrożeniowe CLI dla dostawców modeli
|
||||
summary: Przegląd dostawców modeli z przykładowymi konfiguracjami + przepływami CLI
|
||||
- Chcesz zobaczyć przykładowe konfiguracje lub polecenia CLI do onboardingu dostawców modeli
|
||||
summary: Przegląd dostawców modeli z przykładowymi konfiguracjami i przepływami CLI
|
||||
title: Dostawcy modeli
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T06:02:51Z"
|
||||
generated_at: "2026-04-09T01:29:30Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 558ac9e34b67fcc3dd6791a01bebc17e1c34152fa6c5611593d681e8cfa532d9
|
||||
source_hash: 53e3141256781002bbe1d7e7b78724a18d061fcf36a203baae04a091b8c9ea1b
|
||||
source_path: concepts/model-providers.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -16,25 +16,27 @@ x-i18n:
|
||||
# Dostawcy modeli
|
||||
|
||||
Ta strona opisuje **dostawców LLM/modeli** (a nie kanały czatu, takie jak WhatsApp/Telegram).
|
||||
Zasady wyboru modeli znajdziesz na stronie [/concepts/models](/pl/concepts/models).
|
||||
Zasady wyboru modeli znajdziesz w [/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.
|
||||
- Narzędzia pomocnicze CLI: `openclaw onboard`, `openclaw models list`, `openclaw models set <provider/model>`.
|
||||
- Zasady awaryjne środowiska uruchomieniowego, sondy cooldown oraz trwałość nadpisań sesji
|
||||
są udokumentowane na stronie [/concepts/model-failover](/pl/concepts/model-failover).
|
||||
- Pomocnicze polecenia CLI: `openclaw onboard`, `openclaw models list`, `openclaw models set <provider/model>`.
|
||||
- Zasady awaryjnego działania w runtime, sondy cooldown oraz trwałość nadpisywania 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 uruchomieniowego.
|
||||
`models.providers.*.models[].contextTokens` to efektywny limit runtime.
|
||||
- Wtyczki dostawców mogą wstrzykiwać katalogi modeli przez `registerProvider({ catalog })`;
|
||||
OpenClaw scala to wyjście z `models.providers` przed zapisaniem
|
||||
OpenClaw scala ten wynik z `models.providers` przed zapisaniem
|
||||
`models.json`.
|
||||
- Manifesty dostawców mogą deklarować `providerAuthEnvVars`, aby ogólne sondy
|
||||
uwierzytelniania oparte na zmiennych środowiskowych nie musiały ładować środowiska uruchomieniowego wtyczki. Pozostała mapowanie zmiennych środowiskowych w rdzeniu
|
||||
służy teraz tylko dostawcom spoza wtyczek/z rdzenia oraz kilku przypadkom
|
||||
ogólnego priorytetu, takim jak wdrażanie Anthropic z preferencją klucza API.
|
||||
- Wtyczki dostawców mogą również przejmować zachowanie dostawcy w środowisku uruchomieniowym przez
|
||||
- Manifesty dostawców mogą deklarować `providerAuthEnvVars` oraz
|
||||
`providerAuthAliases`, aby ogólne sondy uwierzytelniania opartego na env i warianty dostawców
|
||||
nie musiały ładować runtime wtyczki. Pozostała mapowanie zmiennych env po stronie core
|
||||
służy teraz tylko
|
||||
dostawcom niebędącym wtyczkami/core oraz kilku przypadkom ogólnego priorytetu, takim
|
||||
jak onboarding Anthropic z priorytetem klucza API.
|
||||
- Wtyczki dostawców mogą także przejmować zachowanie dostawcy w runtime przez
|
||||
`normalizeModelId`, `normalizeTransport`, `normalizeConfig`,
|
||||
`applyNativeStreamingUsageCompat`, `resolveConfigApiKey`,
|
||||
`resolveSyntheticAuth`, `shouldDeferSyntheticProfileAuth`,
|
||||
@ -52,8 +54,8 @@ Zasady wyboru modeli znajdziesz na stronie [/concepts/models](/pl/concepts/model
|
||||
`resolveDefaultThinkingLevel`, `applyConfigDefaults`, `isModernModelRef`,
|
||||
`prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot`, oraz
|
||||
`onModelSelected`.
|
||||
- Uwaga: środowiskowe `capabilities` dostawcy to współdzielone metadane wykonawcy (rodzina dostawcy,
|
||||
niuanse transkryptu/narzędzi, wskazówki dotyczące transportu/pamięci podręcznej). To nie jest
|
||||
- Uwaga: `capabilities` runtime dostawcy to współdzielone metadane runnera (rodzina dostawcy,
|
||||
specyfika transkryptu/narzędzi, wskazówki dotyczące transportu/cache). To nie jest
|
||||
to samo co [publiczny model możliwości](/pl/plugins/architecture#public-capability-model),
|
||||
który opisuje, co rejestruje wtyczka (wnioskowanie tekstowe, mowa itd.).
|
||||
|
||||
@ -64,204 +66,206 @@ ogólną pętlę wnioskowania.
|
||||
|
||||
Typowy podział:
|
||||
|
||||
- `auth[].run` / `auth[].runNonInteractive`: dostawca odpowiada za przepływy wdrożenia/logowania
|
||||
dla `openclaw onboard`, `openclaw models auth` i konfiguracji bezobsługowej
|
||||
- `wizard.setup` / `wizard.modelPicker`: dostawca odpowiada za etykiety wyboru uwierzytelniania,
|
||||
starsze aliasy, wskazówki dotyczące listy dozwolonych modeli podczas wdrażania oraz wpisy konfiguracji w selektorach wdrażania/modeli
|
||||
- `auth[].run` / `auth[].runNonInteractive`: dostawca obsługuje onboarding/logowanie
|
||||
dla `openclaw onboard`, `openclaw models auth` i konfiguracji bez interakcji
|
||||
- `wizard.setup` / `wizard.modelPicker`: dostawca obsługuje etykiety wyboru uwierzytelniania,
|
||||
stare aliasy, wskazówki dotyczące listy dozwolonych modeli podczas onboardingu oraz wpisy konfiguracji w selektorach onboardingu/modeli
|
||||
- `catalog`: dostawca pojawia się w `models.providers`
|
||||
- `normalizeModelId`: dostawca normalizuje starsze/poglądowe identyfikatory modeli przed
|
||||
- `normalizeModelId`: dostawca normalizuje stare/podglądowe identyfikatory modeli przed
|
||||
wyszukiwaniem lub kanonizacją
|
||||
- `normalizeTransport`: dostawca normalizuje rodzinę transportu `api` / `baseUrl`
|
||||
przed ogólnym składaniem modelu; OpenClaw sprawdza najpierw dopasowanego dostawcę,
|
||||
a następnie inne wtyczki dostawców obsługujące hooki, aż jedna rzeczywiście zmieni
|
||||
transport
|
||||
- `normalizeConfig`: dostawca normalizuje konfigurację `models.providers.<id>` zanim
|
||||
środowisko uruchomieniowe jej użyje; OpenClaw sprawdza najpierw dopasowanego dostawcę, a potem inne
|
||||
wtyczki dostawców obsługujące hooki, aż jedna rzeczywiście zmieni konfigurację. Jeśli żadna
|
||||
wtyczka dostawcy nie przepisze konfiguracji, dołączone helpery rodziny Google nadal
|
||||
- `normalizeTransport`: dostawca normalizuje `api` / `baseUrl` rodziny transportu
|
||||
przed ogólnym składaniem modelu; OpenClaw najpierw sprawdza dopasowanego dostawcę,
|
||||
a następnie inne wtyczki dostawców obsługujące hooki, dopóki jedna z nich rzeczywiście nie zmieni
|
||||
transportu
|
||||
- `normalizeConfig`: dostawca normalizuje konfigurację `models.providers.<id>` przed
|
||||
użyciem jej przez runtime; OpenClaw najpierw sprawdza dopasowanego dostawcę, a potem inne
|
||||
wtyczki dostawców obsługujące hooki, dopóki jedna z nich rzeczywiście nie zmieni konfiguracji. Jeśli żaden
|
||||
hook dostawcy nie przepisze konfiguracji, dołączone helpery rodziny Google nadal
|
||||
normalizują obsługiwane wpisy dostawców Google.
|
||||
- `applyNativeStreamingUsageCompat`: dostawca stosuje przepisania zgodności natywnego użycia strumieniowania oparte na punktach końcowych dla dostawców konfiguracyjnych
|
||||
- `resolveConfigApiKey`: dostawca rozwiązuje uwierzytelnianie znacznikami zmiennych środowiskowych dla dostawców konfiguracyjnych
|
||||
bez wymuszania pełnego ładowania uwierzytelniania w środowisku uruchomieniowym. `amazon-bedrock` ma tutaj również
|
||||
wbudowany resolver znaczników środowiskowych AWS, mimo że uwierzytelnianie środowiska uruchomieniowego Bedrock korzysta z
|
||||
- `applyNativeStreamingUsageCompat`: dostawca stosuje zgodnościowe przepisania natywnego zużycia strumieniowego oparte na endpointach dla dostawców konfiguracyjnych
|
||||
- `resolveConfigApiKey`: dostawca rozwiązuje uwierzytelnianie oparte na markerach env dla dostawców konfiguracyjnych
|
||||
bez wymuszania pełnego ładowania auth runtime. `amazon-bedrock` ma tu także
|
||||
wbudowany resolver markerów env AWS, mimo że uwierzytelnianie runtime Bedrock używa
|
||||
domyślnego łańcucha AWS SDK.
|
||||
- `resolveSyntheticAuth`: dostawca może ujawniać dostępność uwierzytelniania lokalnego/samohostowanego lub innego
|
||||
opartego na konfiguracji bez utrwalania jawnych sekretów
|
||||
- `shouldDeferSyntheticProfileAuth`: dostawca może oznaczać zapisane syntetyczne profile-zastępniki
|
||||
jako niższy priorytet niż uwierzytelnianie oparte na środowisku/konfiguracji
|
||||
- `resolveDynamicModel`: dostawca akceptuje identyfikatory modeli, których nie ma jeszcze w lokalnym
|
||||
statycznym katalogu
|
||||
- `prepareDynamicModel`: dostawca potrzebuje odświeżenia metadanych przed ponowną próbą
|
||||
dynamicznego rozwiązania modelu
|
||||
- `normalizeResolvedModel`: dostawca wymaga przepisania transportu lub bazowego URL
|
||||
- `contributeResolvedModelCompat`: dostawca wnosi flagi zgodności dla swoich
|
||||
modeli dostawcy, nawet gdy docierają one przez inny zgodny transport
|
||||
- `capabilities`: dostawca publikuje niuanse transkryptu/narzędzi/rodziny dostawcy
|
||||
- `normalizeToolSchemas`: dostawca czyści schematy narzędzi, zanim zobaczy je
|
||||
osadzony wykonawca
|
||||
- `inspectToolSchemas`: dostawca ujawnia ostrzeżenia dotyczące schematu specyficzne dla transportu
|
||||
- `resolveSyntheticAuth`: dostawca może ujawniać dostępność lokalnego/self-hosted lub innego
|
||||
uwierzytelniania opartego na konfiguracji bez utrwalania sekretów w postaci jawnego tekstu
|
||||
- `shouldDeferSyntheticProfileAuth`: dostawca może oznaczyć zapisane syntetyczne placeholdery profili
|
||||
jako mające niższy priorytet niż uwierzytelnianie oparte na env/konfiguracji
|
||||
- `resolveDynamicModel`: dostawca akceptuje identyfikatory modeli, których nie ma jeszcze
|
||||
w lokalnym statycznym katalogu
|
||||
- `prepareDynamicModel`: dostawca wymaga odświeżenia metadanych przed ponowną próbą
|
||||
dynamicznego rozpoznania
|
||||
- `normalizeResolvedModel`: dostawca wymaga przepisania transportu lub base URL
|
||||
- `contributeResolvedModelCompat`: dostawca dodaje flagi zgodności dla swoich
|
||||
modeli producenta nawet wtedy, gdy docierają przez inny zgodny transport
|
||||
- `capabilities`: dostawca publikuje specyfikę transkryptu/narzędzi/rodziny dostawców
|
||||
- `normalizeToolSchemas`: dostawca czyści schematy narzędzi, zanim zobaczy je osadzony
|
||||
runner
|
||||
- `inspectToolSchemas`: dostawca ujawnia ostrzeżenia dotyczące schematów specyficznych dla transportu
|
||||
po normalizacji
|
||||
- `resolveReasoningOutputMode`: dostawca wybiera natywne lub tagowane
|
||||
kontrakty wyjścia rozumowania
|
||||
- `prepareExtraParams`: dostawca ustawia domyślnie lub normalizuje parametry żądania dla poszczególnych modeli
|
||||
- `createStreamFn`: dostawca zastępuje zwykłą ścieżkę strumienia całkowicie
|
||||
- `resolveReasoningOutputMode`: dostawca wybiera natywne lub otagowane
|
||||
kontrakty wyjścia reasoning
|
||||
- `prepareExtraParams`: dostawca ustawia wartości domyślne lub normalizuje parametry żądań dla danego modelu
|
||||
- `createStreamFn`: dostawca zastępuje zwykłą ścieżkę strumieniowania całkowicie
|
||||
niestandardowym transportem
|
||||
- `wrapStreamFn`: dostawca stosuje opakowania zgodności nagłówków/treści/modelu żądania
|
||||
- `resolveTransportTurnState`: dostawca dostarcza natywne nagłówki lub metadane transportu
|
||||
dla poszczególnych tur
|
||||
- `wrapStreamFn`: dostawca stosuje opakowania zgodności żądania/nagłówków/body/modelu
|
||||
- `resolveTransportTurnState`: dostawca dostarcza natywne nagłówki transportu
|
||||
lub metadane dla pojedynczego turnu
|
||||
- `resolveWebSocketSessionPolicy`: dostawca dostarcza natywne nagłówki sesji WebSocket
|
||||
lub politykę cooldown sesji
|
||||
- `createEmbeddingProvider`: dostawca przejmuje zachowanie osadzeń pamięci, gdy
|
||||
należy ono do wtyczki dostawcy zamiast do przełącznika osadzeń rdzenia
|
||||
- `formatApiKey`: dostawca formatuje zapisane profile uwierzytelniania do postaci
|
||||
ciągu `apiKey` oczekiwanego przez transport w środowisku uruchomieniowym
|
||||
- `refreshOAuth`: dostawca przejmuje odświeżanie OAuth, gdy współdzielone
|
||||
mechanizmy odświeżania `pi-ai` nie wystarczają
|
||||
- `buildAuthDoctorHint`: dostawca dołącza wskazówki naprawcze, gdy odświeżanie OAuth
|
||||
kończy się niepowodzeniem
|
||||
- `matchesContextOverflowError`: dostawca rozpoznaje błędy przepełnienia
|
||||
okna kontekstu specyficzne dla dostawcy, których ogólne heurystyki by nie wykryły
|
||||
- `createEmbeddingProvider`: dostawca przejmuje zachowanie embeddingów pamięci, gdy
|
||||
powinno ono należeć do wtyczki dostawcy zamiast do przełącznika embeddingów w core
|
||||
- `formatApiKey`: dostawca formatuje zapisane profile auth do postaci ciągu
|
||||
`apiKey`, której oczekuje transport w runtime
|
||||
- `refreshOAuth`: dostawca obsługuje odświeżanie OAuth, gdy współdzielone
|
||||
refreshery `pi-ai` nie wystarczają
|
||||
- `buildAuthDoctorHint`: dostawca dopisuje 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 umknęłyby ogólnym heurystykom
|
||||
- `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 identyfikatory modeli upstream obsługują TTL pamięci podręcznej promptów
|
||||
- `buildMissingAuthMessage`: dostawca zastępuje ogólny błąd magazynu uwierzytelniania
|
||||
na przyczyny failover, takie jak limit szybkości lub przeciążenie
|
||||
- `isCacheTtlEligible`: dostawca decyduje, które identyfikatory modeli upstream obsługują TTL cache promptów
|
||||
- `buildMissingAuthMessage`: dostawca zastępuje ogólny błąd magazynu auth
|
||||
wskazówką odzyskiwania specyficzną dla dostawcy
|
||||
- `suppressBuiltInModel`: dostawca ukrywa nieaktualne wiersze upstream i może zwrócić
|
||||
błąd należący do dostawcy w przypadku bezpośrednich niepowodzeń rozwiązywania
|
||||
- `augmentModelCatalog`: dostawca dołącza syntetyczne/końcowe wiersze katalogu po
|
||||
wykryciu i scaleniu konfiguracji
|
||||
- `isBinaryThinking`: dostawca przejmuje UX binarnego myślenia włącz/wyłącz
|
||||
- `supportsXHighThinking`: dostawca włącza wybrane modele do `xhigh`
|
||||
- `resolveDefaultThinkingLevel`: dostawca przejmuje domyślną politykę `/think` dla
|
||||
błąd należący do producenta przy bezpośrednich niepowodzeniach rozpoznania
|
||||
- `augmentModelCatalog`: dostawca dopisuje syntetyczne/końcowe wiersze katalogu po
|
||||
odkryciu i scaleniu konfiguracji
|
||||
- `isBinaryThinking`: dostawca obsługuje UX binarnego thinking w trybie włącz/wyłącz
|
||||
- `supportsXHighThinking`: dostawca włącza `xhigh` dla wybranych modeli
|
||||
- `resolveDefaultThinkingLevel`: dostawca ustala domyślną politykę `/think` dla
|
||||
rodziny modeli
|
||||
- `applyConfigDefaults`: dostawca stosuje globalne domyślne wartości specyficzne dla dostawcy
|
||||
podczas materializacji konfiguracji na podstawie trybu uwierzytelniania, środowiska lub rodziny modeli
|
||||
- `isModernModelRef`: dostawca przejmuje dopasowywanie preferowanych modeli live/smoke
|
||||
- `applyConfigDefaults`: dostawca stosuje globalne wartości domyślne specyficzne dla dostawcy
|
||||
podczas materializacji konfiguracji na podstawie trybu auth, env lub rodziny modeli
|
||||
- `isModernModelRef`: dostawca obsługuje dopasowanie preferowanych modeli dla live/smoke
|
||||
- `prepareRuntimeAuth`: dostawca zamienia skonfigurowane poświadczenie na krótkożyjący
|
||||
token środowiska uruchomieniowego
|
||||
- `resolveUsageAuth`: dostawca rozwiązuje poświadczenia użycia/limitu dla `/usage`
|
||||
token runtime
|
||||
- `resolveUsageAuth`: dostawca rozwiązuje poświadczenia użycia/kwoty dla `/usage`
|
||||
i powiązanych powierzchni statusu/raportowania
|
||||
- `fetchUsageSnapshot`: dostawca przejmuje pobieranie/parsowanie punktu końcowego użycia, podczas gdy
|
||||
rdzeń nadal odpowiada za powłokę podsumowania i formatowanie
|
||||
- `onModelSelected`: dostawca uruchamia skutki uboczne po wyborze modelu, takie jak
|
||||
telemetria lub księgowanie sesji należące do dostawcy
|
||||
- `fetchUsageSnapshot`: dostawca obsługuje pobieranie/parsing endpointu użycia, podczas gdy
|
||||
core nadal obsługuje powłokę podsumowania i formatowanie
|
||||
- `onModelSelected`: dostawca uruchamia efekty uboczne po wyborze modelu, takie jak
|
||||
telemetria lub bookkeeping sesji należący do dostawcy
|
||||
|
||||
Aktualne dołączone przykłady:
|
||||
Obecne dołączone przykłady:
|
||||
|
||||
- `anthropic`: zgodne w przód przejście awaryjne dla Claude 4.6, wskazówki naprawy uwierzytelniania, pobieranie z
|
||||
punktu końcowego użycia, metadane TTL pamięci podręcznej/rodziny dostawcy oraz
|
||||
globalne domyślne wartości konfiguracji zależne od uwierzytelniania
|
||||
- `amazon-bedrock`: należące do dostawcy dopasowywanie przepełnienia kontekstu i klasyfikacja
|
||||
przyczyn przełączenia awaryjnego dla specyficznych dla Bedrock błędów throttling/not-ready, plus
|
||||
współdzielona rodzina odtwarzania `anthropic-by-model` dla ochrony zasad odtwarzania tylko-Claude
|
||||
- `anthropic`: fallback zgodności przyszłej dla Claude 4.6, wskazówki naprawy auth, pobieranie
|
||||
endpointu użycia, metadane cache-TTL/rodziny dostawców oraz globalne
|
||||
wartości domyślne konfiguracji zależne od auth
|
||||
- `amazon-bedrock`: należące do dostawcy dopasowanie przepełnienia kontekstu i klasyfikacja
|
||||
przyczyn failover dla błędów throttle/not-ready specyficznych dla Bedrock, a także
|
||||
współdzielona rodzina replay `anthropic-by-model` dla ochrony polityki replay wyłącznie dla Claude
|
||||
na ruchu Anthropic
|
||||
- `anthropic-vertex`: ochrona zasad odtwarzania tylko-Claude na ruchu
|
||||
- `anthropic-vertex`: zabezpieczenia polityki replay tylko dla Claude na ruchu
|
||||
`anthropic-message`
|
||||
- `openrouter`: przekazywane identyfikatory modeli, opakowania żądań, wskazówki dotyczące możliwości dostawcy,
|
||||
sanityzacja sygnatur myślenia Gemini na ruchu proxy Gemini, wstrzykiwanie rozumowania proxy przez rodzinę strumienia `openrouter-thinking`,
|
||||
przekazywanie metadanych routingu oraz polityka TTL pamięci podręcznej
|
||||
- `github-copilot`: wdrażanie/logowanie urządzenia, zgodne w przód przejście awaryjne modeli,
|
||||
wskazówki transkryptu myślenia Claude, wymiana tokenów środowiska uruchomieniowego oraz pobieranie z
|
||||
punktu końcowego użycia
|
||||
- `openai`: zgodne w przód przejście awaryjne dla GPT-5.4, bezpośrednia normalizacja transportu OpenAI,
|
||||
wskazówki brakującego uwierzytelniania uwzględniające Codex, tłumienie Spark, syntetyczne
|
||||
wiersze katalogu OpenAI/Codex, polityka myślenia/modeli live, normalizacja aliasów tokenów użycia
|
||||
(`input` / `output` oraz rodziny `prompt` / `completion`), współdzielona rodzina strumienia `openai-responses-defaults`
|
||||
dla natywnych opakowań OpenAI/Codex, metadane rodziny dostawcy, dołączona rejestracja dostawcy generowania obrazów
|
||||
sanityzacja podpisów thought Gemini na ruchu proxy Gemini, proxy
|
||||
wstrzykiwanie reasoning przez rodzinę strumienia `openrouter-thinking`, przekazywanie
|
||||
metadanych routingu oraz polityka cache-TTL
|
||||
- `github-copilot`: onboarding/logowanie urządzenia, fallback zgodności przyszłej modeli,
|
||||
wskazówki transkryptu Claude-thinking, wymiana tokena runtime oraz pobieranie endpointu
|
||||
użycia
|
||||
- `openai`: fallback zgodności przyszłej dla GPT-5.4, bezpośrednia normalizacja
|
||||
transportu OpenAI, wskazówki brakującego auth świadome Codex, tłumienie 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 strumienia `openai-responses-defaults` dla natywnych wrapperów OpenAI/Codex,
|
||||
metadane rodziny dostawcy, dołączona rejestracja dostawcy generowania obrazów
|
||||
dla `gpt-image-1` oraz dołączona rejestracja dostawcy generowania wideo
|
||||
dla `sora-2`
|
||||
- `google` i `google-gemini-cli`: zgodne w przód przejście awaryjne dla Gemini 3.1,
|
||||
natywna walidacja odtwarzania Gemini, sanityzacja odtwarzania rozruchowego, tagowany
|
||||
tryb wyjścia rozumowania, dopasowywanie nowoczesnych modeli, dołączona rejestracja dostawcy generowania obrazów
|
||||
- `google` i `google-gemini-cli`: fallback zgodności przyszłej dla Gemini 3.1,
|
||||
natywna walidacja replay Gemini, sanityzacja replay podczas bootstrapu, tryb
|
||||
otagowanego wyjścia reasoning, dopasowanie nowoczesnych modeli, dołączona rejestracja dostawcy generowania obrazów
|
||||
dla modeli Gemini image-preview oraz dołączona
|
||||
rejestracja dostawcy generowania wideo dla modeli Veo; OAuth Gemini CLI również
|
||||
przejmuje formatowanie tokenów profilu uwierzytelniania, parsowanie tokenów użycia oraz pobieranie z
|
||||
punktu końcowego limitów dla powierzchni użycia
|
||||
- `moonshot`: współdzielony transport, normalizacja ładunku myślenia należąca do wtyczki
|
||||
- `kilocode`: współdzielony transport, nagłówki żądań należące do wtyczki, normalizacja ładunku rozumowania,
|
||||
sanityzacja sygnatur myślenia proxy-Gemini oraz polityka TTL pamięci podręcznej
|
||||
- `zai`: zgodne w przód przejście awaryjne dla GLM-5, domyślne `tool_stream`, polityka TTL pamięci podręcznej,
|
||||
polityka binarnego myślenia/modeli live oraz uwierzytelnianie użycia + pobieranie limitów;
|
||||
nieznane identyfikatory `glm-5*` są syntetyzowane z dołączonego szablonu `glm-4.7`
|
||||
rejestracja dostawcy generowania wideo dla modeli Veo; Gemini CLI OAuth także
|
||||
obsługuje formatowanie tokenów profilu auth, parsowanie tokenów użycia oraz pobieranie endpointu kwot
|
||||
dla powierzchni użycia
|
||||
- `moonshot`: współdzielony transport, normalizacja payload thinking należąca do wtyczki
|
||||
- `kilocode`: współdzielony transport, nagłówki żądań należące do wtyczki, normalizacja payload
|
||||
reasoning, sanityzacja podpisów thought proxy-Gemini oraz polityka cache-TTL
|
||||
- `zai`: fallback zgodności przyszłej dla GLM-5, domyślne `tool_stream`, polityka cache-TTL,
|
||||
polityka binarnego thinking/live-model oraz auth użycia + pobieranie kwot;
|
||||
nieznane identyfikatory `glm-5*` są syntetyzowane na podstawie dołączonego szablonu `glm-4.7`
|
||||
- `xai`: natywna normalizacja transportu Responses, przepisania aliasów `/fast` dla
|
||||
szybkich wariantów Grok, domyślne `tool_stream`, porządkowanie schematu narzędzi /
|
||||
ładunku rozumowania specyficzne dla xAI oraz dołączona rejestracja dostawcy generowania wideo
|
||||
szybkich wariantów Grok, domyślne `tool_stream`, czyszczenie schematów narzędzi /
|
||||
payload reasoning specyficzne dla xAI oraz dołączona rejestracja dostawcy generowania wideo
|
||||
dla `grok-imagine-video`
|
||||
- `mistral`: metadane możliwości należące do wtyczki
|
||||
- `opencode` i `opencode-go`: metadane możliwości należące do wtyczki oraz
|
||||
sanityzacja sygnatur myślenia proxy-Gemini
|
||||
- `alibaba`: należący do wtyczki katalog generowania wideo dla bezpośrednich referencji modeli Wan
|
||||
sanityzacja podpisów thought proxy-Gemini
|
||||
- `alibaba`: katalog wideo należący do wtyczki dla bezpośrednich referencji modeli Wan
|
||||
takich jak `alibaba/wan2.6-t2v`
|
||||
- `byteplus`: katalogi należące do wtyczki 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 innych firm
|
||||
oraz rejestracja dostawcy generowania obrazów dla modeli FLUX, plus dołączona
|
||||
dla modeli text-to-video/image-to-video Seedance
|
||||
- `fal`: dołączona rejestracja dostawcy generowania wideo dla hostowanych modeli wideo innych firm
|
||||
oraz rejestracja dostawcy generowania obrazów dla modeli obrazów FLUX, a także dołączona
|
||||
rejestracja dostawcy generowania wideo dla hostowanych modeli wideo innych firm
|
||||
- `cloudflare-ai-gateway`, `huggingface`, `kimi`, `nvidia`, `qianfan`,
|
||||
`stepfun`, `synthetic`, `venice`, `vercel-ai-gateway` i `volcengine`:
|
||||
tylko katalogi należące do wtyczki
|
||||
- `qwen`: katalogi należące do wtyczki dla modeli tekstowych oraz współdzielone
|
||||
rejestracje dostawców rozumienia mediów i generowania wideo dla jego
|
||||
powierzchni multimodalnych; generowanie wideo Qwen korzysta ze standardowych punktów końcowych wideo DashScope
|
||||
rejestracje dostawców media-understanding i generowania wideo dla ich
|
||||
powierzchni multimodalnych; generowanie wideo Qwen używa standardowych endpointów DashScope video
|
||||
z dołączonymi modelami Wan, takimi jak `wan2.6-t2v` i `wan2.7-r2v`
|
||||
- `runway`: należąca do wtyczki rejestracja dostawcy generowania wideo dla natywnych
|
||||
modeli zadaniowych Runway, takich jak `gen4.5`
|
||||
- `runway`: rejestracja dostawcy generowania wideo należąca do wtyczki dla natywnych
|
||||
modeli opartych na zadaniach Runway, takich jak `gen4.5`
|
||||
- `minimax`: katalogi należące do wtyczki, dołączona rejestracja dostawcy generowania wideo
|
||||
dla modeli Hailuo, dołączona rejestracja dostawcy generowania obrazów
|
||||
dla `image-01`, hybrydowy wybór zasad odtwarzania Anthropic/OpenAI
|
||||
oraz logika uwierzytelniania/migawki użycia
|
||||
dla modeli wideo Hailuo, dołączona rejestracja dostawcy generowania obrazów
|
||||
dla `image-01`, hybrydowy wybór polityki replay Anthropic/OpenAI
|
||||
oraz logika auth/snapshot użycia
|
||||
- `together`: katalogi należące do wtyczki oraz dołączona rejestracja dostawcy generowania wideo
|
||||
dla modeli wideo Wan
|
||||
- `xiaomi`: katalogi należące do wtyczki oraz logika uwierzytelniania/migawki użycia
|
||||
- `xiaomi`: katalogi należące do wtyczki oraz logika auth/snapshot użycia
|
||||
|
||||
Dołączona wtyczka `openai` obsługuje teraz oba identyfikatory dostawców: `openai` i
|
||||
Dołączona wtyczka `openai` obsługuje teraz oba identyfikatory dostawcy: `openai` i
|
||||
`openai-codex`.
|
||||
|
||||
To obejmuje dostawców, którzy nadal mieszczą się w zwykłych transportach OpenClaw. Dostawca,
|
||||
który potrzebuje całkowicie niestandardowego wykonawcy żądań, to osobna, głębsza powierzchnia
|
||||
rozszerzeń.
|
||||
To obejmuje dostawców, którzy nadal mieszczą się w normalnych transportach OpenClaw. Dostawca,
|
||||
który potrzebuje całkowicie niestandardowego wykonawcy żądań, to osobna, głębsza
|
||||
powierzchnia rozszerzeń.
|
||||
|
||||
## Rotacja kluczy API
|
||||
|
||||
- Obsługuje ogólną rotację dostawcy dla wybranych dostawców.
|
||||
- Obsługuje ogólną rotację dla wybranych dostawców.
|
||||
- Skonfiguruj wiele kluczy przez:
|
||||
- `OPENCLAW_LIVE_<PROVIDER>_KEY` (pojedyncze aktywne nadpisanie, najwyższy priorytet)
|
||||
- `OPENCLAW_LIVE_<PROVIDER>_KEY` (pojedyncze nadpisanie live, najwyższy priorytet)
|
||||
- `<PROVIDER>_API_KEYS` (lista rozdzielana przecinkami lub średnikami)
|
||||
- `<PROVIDER>_API_KEY` (klucz podstawowy)
|
||||
- `<PROVIDER>_API_KEY` (główny klucz)
|
||||
- `<PROVIDER>_API_KEY_*` (lista numerowana, np. `<PROVIDER>_API_KEY_1`)
|
||||
- Dla dostawców Google `GOOGLE_API_KEY` jest również uwzględniany jako rozwiązanie awaryjne.
|
||||
- Kolejność wyboru kluczy zachowuje priorytet i usuwa zduplikowane wartości.
|
||||
- Żądania są ponawiane z następnym kluczem tylko w odpowiedzi na ograniczenia szybkości
|
||||
(na przykład `429`, `rate_limit`, `quota`, `resource exhausted`, `Too many
|
||||
- Dla dostawców Google jako fallback uwzględniany jest także `GOOGLE_API_KEY`.
|
||||
- Kolejność wyboru kluczy zachowuje priorytet i deduplikuje wartości.
|
||||
- Żą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 okresowe komunikaty o limicie użycia).
|
||||
- Błędy niezwiązane z limitem szybkości kończą się natychmiastowym niepowodzeniem; nie podejmuje się rotacji kluczy.
|
||||
`workers_ai ... quota limit exceeded` lub okresowych komunikatach o limicie użycia).
|
||||
- Błędy inne niż limit szybkości kończą się natychmiast; nie podejmuje się rotacji kluczy.
|
||||
- Gdy wszystkie kandydackie klucze zawiodą, zwracany jest końcowy błąd z ostatniej próby.
|
||||
|
||||
## Wbudowani dostawcy (katalog pi-ai)
|
||||
|
||||
OpenClaw jest dostarczany z katalogiem pi‑ai. Ci dostawcy nie wymagają
|
||||
konfiguracji `models.providers`; wystarczy ustawić uwierzytelnianie i wybrać model.
|
||||
konfiguracji `models.providers`; wystarczy ustawić auth i wybrać model.
|
||||
|
||||
### OpenAI
|
||||
|
||||
- Dostawca: `openai`
|
||||
- Uwierzytelnianie: `OPENAI_API_KEY`
|
||||
- Opcjonalna rotacja: `OPENAI_API_KEYS`, `OPENAI_API_KEY_1`, `OPENAI_API_KEY_2`, plus `OPENCLAW_LIVE_OPENAI_KEY` (pojedyncze nadpisanie)
|
||||
- Auth: `OPENAI_API_KEY`
|
||||
- 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, awaryjnie SSE)
|
||||
- Domyślny transport to `auto` (najpierw WebSocket, fallback do SSE)
|
||||
- Nadpisanie dla modelu przez `agents.defaults.models["openai/<model>"].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/<model>"].params.serviceTier`
|
||||
- `/fast` i `params.fastMode` mapują bezpośrednie żądania Responses `openai/*` na `service_tier=priority` w `api.openai.com`
|
||||
- Użyj `params.serviceTier`, jeśli chcesz jawnego poziomu zamiast współdzielonego przełącznika `/fast`
|
||||
- Rozgrzewanie OpenAI Responses WebSocket jest domyślnie włączone przez `params.openaiWsWarmup` (`true`/`false`)
|
||||
- Przetwarzanie priorytetowe OpenAI można włączyć przez `agents.defaults.models["openai/<model>"].params.serviceTier`
|
||||
- `/fast` i `params.fastMode` mapują bezpośrednie żądania Responses `openai/*` do `service_tier=priority` na `api.openai.com`
|
||||
- Użyj `params.serviceTier`, jeśli chcesz jawnie ustawić poziom zamiast używać współdzielonego przełącznika `/fast`
|
||||
- Ukryte nagłówki atrybucji OpenClaw (`originator`, `version`,
|
||||
`User-Agent`) są stosowane tylko do natywnego ruchu OpenAI do `api.openai.com`, a nie
|
||||
do ogólnych serwerów proxy zgodnych z OpenAI
|
||||
- Natywne trasy OpenAI zachowują również `store` w 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 ukryty w OpenClaw, ponieważ aktywne API OpenAI go odrzuca; Spark jest traktowany jako tylko-Codex
|
||||
do ogólnych proxy zgodnych z OpenAI
|
||||
- Natywne trasy OpenAI zachowują też `store` dla Responses, wskazówki cache promptów oraz
|
||||
kształtowanie payload zgodności reasoning OpenAI; trasy proxy tego nie robią
|
||||
- `openai/gpt-5.3-codex-spark` jest celowo ukryty w OpenClaw, ponieważ live API OpenAI go odrzuca; Spark jest traktowany wyłącznie jako Codex
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -272,13 +276,13 @@ konfiguracji `models.providers`; wystarczy ustawić uwierzytelnianie i wybrać m
|
||||
### Anthropic
|
||||
|
||||
- Dostawca: `anthropic`
|
||||
- Uwierzytelnianie: `ANTHROPIC_API_KEY`
|
||||
- Opcjonalna rotacja: `ANTHROPIC_API_KEYS`, `ANTHROPIC_API_KEY_1`, `ANTHROPIC_API_KEY_2`, plus `OPENCLAW_LIVE_ANTHROPIC_KEY` (pojedyncze nadpisanie)
|
||||
- Auth: `ANTHROPIC_API_KEY`
|
||||
- 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ą współdzielony przełącznik `/fast` i `params.fastMode`, w tym ruch uwierzytelniony 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 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ę.
|
||||
- Token konfiguracji Anthropic pozostaje dostępną obsługiwaną ścieżką tokena OpenClaw, ale OpenClaw preferuje teraz ponowne użycie Claude CLI i `claude -p`, gdy są dostępne.
|
||||
- Bezpośrednie publiczne żądania Anthropic obsługują współdzielony przełącznik `/fast` i `params.fastMode`, zarówno dla ruchu uwierzytelnionego kluczem API, jak i OAuth wysyłanego do `api.anthropic.com`; OpenClaw mapuje to na `service_tier` Anthropic (`auto` vs `standard_only`)
|
||||
- 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 dozwolone dla tej integracji, chyba że Anthropic opublikuje nową politykę.
|
||||
- Token konfiguracyjny Anthropic pozostaje dostępną i wspieraną ścieżką tokenu OpenClaw, ale OpenClaw teraz preferuje ponowne użycie Claude CLI i `claude -p`, gdy są dostępne.
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -289,19 +293,19 @@ konfiguracji `models.providers`; wystarczy ustawić uwierzytelnianie i wybrać m
|
||||
### OpenAI Code (Codex)
|
||||
|
||||
- Dostawca: `openai-codex`
|
||||
- Uwierzytelnianie: OAuth (ChatGPT)
|
||||
- Auth: OAuth (ChatGPT)
|
||||
- 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, awaryjnie SSE)
|
||||
- Domyślny transport to `auto` (najpierw WebSocket, fallback do SSE)
|
||||
- Nadpisanie dla modelu przez `agents.defaults.models["openai-codex/<model>"].params.transport` (`"sse"`, `"websocket"` lub `"auto"`)
|
||||
- `params.serviceTier` jest również przekazywane w natywnych żądaniach Codex Responses (`chatgpt.com/backend-api`)
|
||||
- `params.serviceTier` jest także 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
|
||||
`chatgpt.com/backend-api`, a nie do ogólnych serwerów proxy zgodnych z OpenAI
|
||||
`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`
|
||||
- `openai-codex/gpt-5.3-codex-spark` pozostaje dostępny, gdy katalog OAuth Codex go ujawnia; zależne od uprawnień
|
||||
- `openai-codex/gpt-5.4` zachowuje natywne `contextWindow = 1050000` i domyślne środowiskowe `contextTokens = 272000`; nadpisz limit środowiska przez `models.providers.openai-codex.models[].contextTokens`
|
||||
- Uwaga dotycząca zasad: OAuth OpenAI Codex jest jawnie obsługiwany dla zewnętrznych narzędzi/przepływów pracy, takich jak OpenClaw.
|
||||
- `openai-codex/gpt-5.3-codex-spark` pozostaje dostępny, gdy katalog OAuth Codex go udostępnia; zależy od uprawnień
|
||||
- `openai-codex/gpt-5.4` zachowuje natywne `contextWindow = 1050000` i domyślne runtime `contextTokens = 272000`; nadpisz limit runtime przez `models.providers.openai-codex.models[].contextTokens`
|
||||
- Uwaga dotycząca polityki: OAuth OpenAI Codex jest jawnie wspierany dla zewnętrznych narzędzi/przepływów pracy, takich jak OpenClaw.
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -323,15 +327,15 @@ 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 punktów końcowych Alibaba DashScope i Coding Plan
|
||||
- [MiniMax](/pl/providers/minimax): dostęp OAuth lub kluczem API do MiniMax Coding Plan
|
||||
- [GLM Models](/pl/providers/glm): Z.AI Coding Plan lub ogólne punkty końcowe API
|
||||
- [Qwen Cloud](/pl/providers/qwen): powierzchnia dostawcy Qwen Cloud oraz mapowanie endpointów Alibaba DashScope i Coding Plan
|
||||
- [MiniMax](/pl/providers/minimax): dostęp przez OAuth MiniMax Coding Plan lub 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 uruchomieniowego Zen: `opencode`
|
||||
- Dostawca środowiska uruchomieniowego Go: `opencode-go`
|
||||
- Auth: `OPENCODE_API_KEY` (lub `OPENCODE_ZEN_API_KEY`)
|
||||
- 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`
|
||||
|
||||
@ -344,88 +348,87 @@ konfiguracji `models.providers`; wystarczy ustawić uwierzytelnianie i wybrać m
|
||||
### Google Gemini (klucz API)
|
||||
|
||||
- Dostawca: `google`
|
||||
- Uwierzytelnianie: `GEMINI_API_KEY`
|
||||
- Opcjonalna rotacja: `GEMINI_API_KEYS`, `GEMINI_API_KEY_1`, `GEMINI_API_KEY_2`, rozwiązanie awaryjne `GOOGLE_API_KEY` oraz `OPENCLAW_LIVE_GEMINI_KEY` (pojedyncze nadpisanie)
|
||||
- Auth: `GEMINI_API_KEY`
|
||||
- Opcjonalna rotacja: `GEMINI_API_KEYS`, `GEMINI_API_KEY_1`, `GEMINI_API_KEY_2`, fallback `GOOGLE_API_KEY` oraz `OPENCLAW_LIVE_GEMINI_KEY` (pojedyncze nadpisanie)
|
||||
- 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ą również `agents.defaults.models["google/<model>"].params.cachedContent`
|
||||
- Bezpośrednie uruchomienia Gemini akceptują także `agents.defaults.models["google/<model>"].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 innych firm. Zapoznaj się z warunkami Google i użyj niekrytycznego konta, jeśli zdecydujesz się kontynuować.
|
||||
- OAuth Gemini CLI jest dostarczany jako część dołączonej wtyczki `google`.
|
||||
- Auth: Vertex używa gcloud ADC; Gemini CLI używa własnego przepływu OAuth
|
||||
- Ostrzeżenie: OAuth Gemini CLI w OpenClaw to nieoficjalna integracja. Niektórzy użytkownicy zgłaszali ograniczenia kont Google po używaniu klientów zewnętrznych. Zapoznaj się z warunkami Google i używaj konta niekrytycznego, jeśli zdecydujesz się kontynuować.
|
||||
- OAuth Gemini CLI jest dostarczane jako część dołączonej wtyczki `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`
|
||||
- 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 nie działają po zalogowaniu, ustaw `GOOGLE_CLOUD_PROJECT` lub `GOOGLE_CLOUD_PROJECT_ID` na hoście bramy.
|
||||
- Odpowiedzi JSON Gemini CLI są parsowane z `response`; użycie awaryjnie korzysta z
|
||||
- Zaloguj: `openclaw models auth login --provider google-gemini-cli --set-default`
|
||||
- Domyślny model: `google-gemini-cli/gemini-3-flash-preview`
|
||||
- Uwaga: **nie** wklejasz client id ani secret do `openclaw.json`. Przepływ logowania CLI zapisuje
|
||||
tokeny w profilach auth na hoście gateway.
|
||||
- Jeśli żądania nie działają 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 korzysta z fallback do
|
||||
`stats`, a `stats.cached` jest normalizowane do OpenClaw `cacheRead`.
|
||||
|
||||
### Z.AI (GLM)
|
||||
|
||||
- Dostawca: `zai`
|
||||
- Uwierzytelnianie: `ZAI_API_KEY`
|
||||
- Auth: `ZAI_API_KEY`
|
||||
- Przykładowy model: `zai/glm-5.1`
|
||||
- CLI: `openclaw onboard --auth-choice zai-api-key`
|
||||
- Aliasy: `z.ai/*` i `z-ai/*` są normalizowane do `zai/*`
|
||||
- `zai-api-key` automatycznie wykrywa pasujący punkt końcowy Z.AI; `zai-coding-global`, `zai-coding-cn`, `zai-global` i `zai-cn` wymuszają określoną powierzchnię
|
||||
- `zai-api-key` automatycznie wykrywa pasujący endpoint Z.AI; `zai-coding-global`, `zai-coding-cn`, `zai-global` i `zai-cn` wymuszają konkretną powierzchnię
|
||||
|
||||
### Vercel AI Gateway
|
||||
|
||||
- Dostawca: `vercel-ai-gateway`
|
||||
- Uwierzytelnianie: `AI_GATEWAY_API_KEY`
|
||||
- Auth: `AI_GATEWAY_API_KEY`
|
||||
- Przykładowy model: `vercel-ai-gateway/anthropic/claude-opus-4.6`
|
||||
- CLI: `openclaw onboard --auth-choice ai-gateway-api-key`
|
||||
|
||||
### Kilo Gateway
|
||||
|
||||
- Dostawca: `kilocode`
|
||||
- Uwierzytelnianie: `KILOCODE_API_KEY`
|
||||
- Auth: `KILOCODE_API_KEY`
|
||||
- Przykładowy model: `kilocode/kilo/auto`
|
||||
- CLI: `openclaw onboard --auth-choice kilocode-api-key`
|
||||
- Bazowy URL: `https://api.kilo.ai/api/gateway/`
|
||||
- Statyczny katalog awaryjny zawiera `kilocode/kilo/auto`; aktywne
|
||||
wykrywanie `https://api.kilo.ai/api/gateway/models` może dalej rozszerzyć katalog
|
||||
środowiska uruchomieniowego.
|
||||
- Base URL: `https://api.kilo.ai/api/gateway/`
|
||||
- Statyczny katalog fallback zawiera `kilocode/kilo/auto`; live
|
||||
odkrywanie pod `https://api.kilo.ai/api/gateway/models` może dalej rozszerzać katalog runtime.
|
||||
- Dokładny routing upstream za `kilocode/kilo/auto` należy do Kilo Gateway,
|
||||
a nie jest zakodowany na stałe w OpenClaw.
|
||||
a nie jest zakodowany na sztywno w OpenClaw.
|
||||
|
||||
Szczegóły konfiguracji znajdziesz na stronie [/providers/kilocode](/pl/providers/kilocode).
|
||||
Szczegóły konfiguracji znajdziesz w [/providers/kilocode](/pl/providers/kilocode).
|
||||
|
||||
### Inne dołączone wtyczki dostawców
|
||||
|
||||
- OpenRouter: `openrouter` (`OPENROUTER_API_KEY`)
|
||||
- Przykładowy model: `openrouter/auto`
|
||||
- OpenClaw stosuje udokumentowane nagłówki atrybucji aplikacji OpenRouter tylko wtedy, gdy
|
||||
żądanie rzeczywiście trafia do `openrouter.ai`
|
||||
żą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 zgodnej z OpenAI, więc natywne
|
||||
kształtowanie żądań tylko dla OpenAI (`serviceTier`, `store` w Responses,
|
||||
wskazówki pamięci podręcznej promptów, ładunki zgodności rozumowania OpenAI) nie jest przekazywane
|
||||
- Referencje OpenRouter oparte na Gemini zachowują tylko sanityzację sygnatur myślenia proxy-Gemini;
|
||||
natywna walidacja odtwarzania Gemini i przepisania rozruchowe pozostają wyłączone
|
||||
kształtowanie żądań tylko dla OpenAI (`serviceTier`, `store` dla Responses,
|
||||
wskazówki cache promptów, payloady zgodności reasoning OpenAI) nie jest przekazywane
|
||||
- Referencje OpenRouter oparte na Gemini zachowują tylko sanityzację podpisów thought proxy-Gemini;
|
||||
natywna walidacja replay 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 sygnatur myślenia
|
||||
proxy-Gemini; `kilocode/kilo/auto` i inne wskazówki proxy bez obsługi rozumowania
|
||||
pomijają wstrzykiwanie rozumowania proxy
|
||||
- Referencje Kilo oparte na Gemini zachowują tę samą ścieżkę sanityzacji podpisów thought
|
||||
proxy-Gemini; `kilocode/kilo/auto` i inne wskazówki proxy bez obsługi reasoning
|
||||
pomijają wstrzykiwanie reasoning do 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`
|
||||
- Auth: `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`
|
||||
- Wdrożenie 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 ta konfiguracja dostawcy nie zostanie zmaterializowana
|
||||
- Onboarding MiniMax/konfiguracja klucza API zapisuje jawne definicje modeli M2.7 z
|
||||
`input: ["text", "image"]`; dołączony katalog dostawcy utrzymuje referencje czatu
|
||||
jako tylko tekstowe, dopóki konfiguracja tego dostawcy nie zostanie zmaterializowana
|
||||
- Moonshot: `moonshot` (`MOONSHOT_API_KEY`)
|
||||
- Przykładowy model: `moonshot/kimi-k2.5`
|
||||
- Kimi Coding: `kimi` (`KIMI_API_KEY` lub `KIMICODE_API_KEY`)
|
||||
@ -453,7 +456,7 @@ Szczegóły konfiguracji znajdziesz na stronie [/providers/kilocode](/pl/provide
|
||||
- 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`,
|
||||
`grok-4` i `grok-4-0709` na ich warianty `*-fast`
|
||||
`grok-4` i `grok-4-0709` do ich wariantów `*-fast`
|
||||
- `tool_stream` jest domyślnie włączone; ustaw
|
||||
`agents.defaults.models["xai/<model>"].params.tool_stream` na `false`, aby
|
||||
je wyłączyć
|
||||
@ -463,27 +466,27 @@ Szczegóły konfiguracji znajdziesz na stronie [/providers/kilocode](/pl/provide
|
||||
- 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`.
|
||||
- Base URL zgodny 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` (niestandardowy/bazowy URL)
|
||||
## Dostawcy przez `models.providers` (własny/base URL)
|
||||
|
||||
Użyj `models.providers` (lub `models.json`), aby dodać **niestandardowych** dostawców lub
|
||||
Użyj `models.providers` (lub `models.json`), aby dodać **własnych** dostawców lub
|
||||
proxy zgodne z OpenAI/Anthropic.
|
||||
|
||||
Wiele z poniższych dołączonych wtyczek dostawców publikuje już domyślny katalog.
|
||||
Wiele dołączonych poniżej wtyczek dostawców publikuje już domyślny katalog.
|
||||
Używaj jawnych wpisów `models.providers.<id>` tylko wtedy, gdy chcesz nadpisać
|
||||
domyślny bazowy URL, nagłówki lub listę modeli.
|
||||
domyślny base URL, nagłówki lub listę modeli.
|
||||
|
||||
### Moonshot AI (Kimi)
|
||||
|
||||
Moonshot jest dostarczany jako dołączona wtyczka dostawcy. Domyślnie używaj wbudowanego dostawcy,
|
||||
a jawny wpis `models.providers.moonshot` dodawaj tylko wtedy, gdy
|
||||
musisz nadpisać bazowy URL lub metadane modelu:
|
||||
Moonshot jest dostarczany jako dołączona wtyczka dostawcy. Używaj wbudowanego dostawcy
|
||||
domyślnie i dodawaj jawny wpis `models.providers.moonshot` tylko wtedy, gdy
|
||||
musisz nadpisać base URL lub metadane modelu:
|
||||
|
||||
- Dostawca: `moonshot`
|
||||
- Uwierzytelnianie: `MOONSHOT_API_KEY`
|
||||
- Auth: `MOONSHOT_API_KEY`
|
||||
- Przykładowy model: `moonshot/kimi-k2.5`
|
||||
- CLI: `openclaw onboard --auth-choice moonshot-api-key` lub `openclaw onboard --auth-choice moonshot-api-key-cn`
|
||||
|
||||
@ -519,10 +522,10 @@ Identyfikatory modeli Kimi K2:
|
||||
|
||||
### Kimi Coding
|
||||
|
||||
Kimi Coding używa zgodnego z Anthropic punktu końcowego Moonshot AI:
|
||||
Kimi Coding używa endpointu Moonshot AI zgodnego z Anthropic:
|
||||
|
||||
- Dostawca: `kimi`
|
||||
- Uwierzytelnianie: `KIMI_API_KEY`
|
||||
- Auth: `KIMI_API_KEY`
|
||||
- Przykładowy model: `kimi/kimi-code`
|
||||
|
||||
```json5
|
||||
@ -534,14 +537,14 @@ Kimi Coding używa zgodnego z Anthropic punktu końcowego Moonshot AI:
|
||||
}
|
||||
```
|
||||
|
||||
Starszy `kimi/k2p5` pozostaje akceptowanym identyfikatorem modelu ze względów zgodności.
|
||||
Starszy `kimi/k2p5` pozostaje akceptowanym identyfikatorem modelu dla zgodności.
|
||||
|
||||
### Volcano Engine (Doubao)
|
||||
|
||||
Volcano Engine (火山引擎) zapewnia dostęp do Doubao i innych modeli w Chinach.
|
||||
|
||||
- Dostawca: `volcengine` (kodowanie: `volcengine-plan`)
|
||||
- Uwierzytelnianie: `VOLCANO_ENGINE_API_KEY`
|
||||
- Dostawca: `volcengine` (coding: `volcengine-plan`)
|
||||
- Auth: `VOLCANO_ENGINE_API_KEY`
|
||||
- Przykładowy model: `volcengine-plan/ark-code-latest`
|
||||
- CLI: `openclaw onboard --auth-choice volcengine-api-key`
|
||||
|
||||
@ -553,12 +556,12 @@ Volcano Engine (火山引擎) zapewnia dostęp do Doubao i innych modeli w China
|
||||
}
|
||||
```
|
||||
|
||||
Wdrożenie domyślnie używa powierzchni coding, ale ogólny katalog `volcengine/*`
|
||||
jest rejestrowany w tym samym czasie.
|
||||
Onboarding domyślnie używa powierzchni coding, ale ogólny katalog `volcengine/*`
|
||||
jest rejestrowany jednocześnie.
|
||||
|
||||
W selektorach modeli wdrażania/konfiguracji wybór uwierzytelniania Volcengine preferuje zarówno
|
||||
W selektorach modeli onboarding/configure model wybór auth Volcengine preferuje zarówno
|
||||
wiersze `volcengine/*`, jak i `volcengine-plan/*`. Jeśli te modele nie są jeszcze załadowane,
|
||||
OpenClaw wraca do nieprzefiltrowanego katalogu zamiast pokazywać pusty
|
||||
OpenClaw wraca do niefiltrowanego katalogu zamiast pokazywać pusty
|
||||
selektor ograniczony do dostawcy.
|
||||
|
||||
Dostępne modele:
|
||||
@ -577,12 +580,12 @@ Modele coding (`volcengine-plan`):
|
||||
- `volcengine-plan/kimi-k2-thinking`
|
||||
- `volcengine-plan/glm-4.7`
|
||||
|
||||
### BytePlus (międzynarodowy)
|
||||
### BytePlus (International)
|
||||
|
||||
BytePlus ARK zapewnia międzynarodowym użytkownikom dostęp do tych samych modeli co Volcano Engine.
|
||||
|
||||
- Dostawca: `byteplus` (kodowanie: `byteplus-plan`)
|
||||
- Uwierzytelnianie: `BYTEPLUS_API_KEY`
|
||||
- Dostawca: `byteplus` (coding: `byteplus-plan`)
|
||||
- Auth: `BYTEPLUS_API_KEY`
|
||||
- Przykładowy model: `byteplus-plan/ark-code-latest`
|
||||
- CLI: `openclaw onboard --auth-choice byteplus-api-key`
|
||||
|
||||
@ -594,12 +597,12 @@ BytePlus ARK zapewnia międzynarodowym użytkownikom dostęp do tych samych mode
|
||||
}
|
||||
```
|
||||
|
||||
Wdrożenie domyślnie używa powierzchni coding, ale ogólny katalog `byteplus/*`
|
||||
jest rejestrowany w tym samym czasie.
|
||||
Onboarding domyślnie używa powierzchni coding, ale ogólny katalog `byteplus/*`
|
||||
jest rejestrowany jednocześnie.
|
||||
|
||||
W selektorach modeli wdrażania/konfiguracji wybór uwierzytelniania BytePlus preferuje zarówno
|
||||
W selektorach modeli onboarding/configure model wybór auth BytePlus preferuje zarówno
|
||||
wiersze `byteplus/*`, jak i `byteplus-plan/*`. Jeśli te modele nie są jeszcze załadowane,
|
||||
OpenClaw wraca do nieprzefiltrowanego katalogu zamiast pokazywać pusty
|
||||
OpenClaw wraca do niefiltrowanego katalogu zamiast pokazywać pusty
|
||||
selektor ograniczony do dostawcy.
|
||||
|
||||
Dostępne modele:
|
||||
@ -621,7 +624,7 @@ Modele coding (`byteplus-plan`):
|
||||
Synthetic udostępnia modele zgodne z Anthropic za dostawcą `synthetic`:
|
||||
|
||||
- Dostawca: `synthetic`
|
||||
- Uwierzytelnianie: `SYNTHETIC_API_KEY`
|
||||
- Auth: `SYNTHETIC_API_KEY`
|
||||
- Przykładowy model: `synthetic/hf:MiniMaxAI/MiniMax-M2.5`
|
||||
- CLI: `openclaw onboard --auth-choice synthetic-api-key`
|
||||
|
||||
@ -646,39 +649,39 @@ Synthetic udostępnia modele zgodne z Anthropic za dostawcą `synthetic`:
|
||||
|
||||
### MiniMax
|
||||
|
||||
MiniMax jest konfigurowany przez `models.providers`, ponieważ używa niestandardowych punktów końcowych:
|
||||
MiniMax jest konfigurowany przez `models.providers`, ponieważ używa niestandardowych endpointów:
|
||||
|
||||
- MiniMax OAuth (globalny): `--auth-choice minimax-global-oauth`
|
||||
- MiniMax OAuth (Global): `--auth-choice minimax-global-oauth`
|
||||
- MiniMax OAuth (CN): `--auth-choice minimax-cn-oauth`
|
||||
- Klucz API MiniMax (globalny): `--auth-choice minimax-global-api`
|
||||
- Klucz API MiniMax (CN): `--auth-choice minimax-cn-api`
|
||||
- Uwierzytelnianie: `MINIMAX_API_KEY` dla `minimax`; `MINIMAX_OAUTH_TOKEN` lub
|
||||
- MiniMax klucz API (Global): `--auth-choice minimax-global-api`
|
||||
- MiniMax klucz API (CN): `--auth-choice minimax-cn-api`
|
||||
- Auth: `MINIMAX_API_KEY` dla `minimax`; `MINIMAX_OAUTH_TOKEN` lub
|
||||
`MINIMAX_API_KEY` dla `minimax-portal`
|
||||
|
||||
Szczegóły konfiguracji, opcje modeli i fragmenty konfiguracji znajdziesz na stronie [/providers/minimax](/pl/providers/minimax).
|
||||
Szczegóły konfiguracji, opcje modeli i fragmenty konfiguracji znajdziesz w [/providers/minimax](/pl/providers/minimax).
|
||||
|
||||
Na ścieżce strumieniowania MiniMax zgodnej z Anthropic OpenClaw domyślnie wyłącza myślenie,
|
||||
chyba że ustawisz je jawnie, a `/fast on` przepisuje
|
||||
Na ścieżce strumieniowania MiniMax zgodnej z Anthropic OpenClaw domyślnie wyłącza thinking,
|
||||
chyba że jawnie go ustawisz, a `/fast on` przepisuje
|
||||
`MiniMax-M2.7` na `MiniMax-M2.7-highspeed`.
|
||||
|
||||
Podział możliwości należących do wtyczki:
|
||||
|
||||
- Domyślne ustawienia tekstu/czatu pozostają na `minimax/MiniMax-M2.7`
|
||||
- Domyślne ustawienia tekst/czat pozostają na `minimax/MiniMax-M2.7`
|
||||
- Generowanie obrazów to `minimax/image-01` lub `minimax-portal/image-01`
|
||||
- Rozumienie obrazów to należący do wtyczki `MiniMax-VL-01` na obu ścieżkach uwierzytelniania MiniMax
|
||||
- Rozumienie obrazów to należący do wtyczki `MiniMax-VL-01` na obu ścieżkach auth MiniMax
|
||||
- Wyszukiwanie w sieci pozostaje przy identyfikatorze dostawcy `minimax`
|
||||
|
||||
### Ollama
|
||||
|
||||
Ollama jest dostarczana jako dołączona wtyczka dostawcy i używa natywnego API Ollama:
|
||||
Ollama jest dostarczany jako dołączona wtyczka dostawcy i używa natywnego API Ollama:
|
||||
|
||||
- Dostawca: `ollama`
|
||||
- Uwierzytelnianie: nie jest wymagane (serwer lokalny)
|
||||
- Auth: niewymagane (serwer lokalny)
|
||||
- Przykładowy model: `ollama/llama3.3`
|
||||
- Instalacja: [https://ollama.com/download](https://ollama.com/download)
|
||||
|
||||
```bash
|
||||
# Install Ollama, then pull a model:
|
||||
# Zainstaluj Ollama, a następnie pobierz model:
|
||||
ollama pull llama3.3
|
||||
```
|
||||
|
||||
@ -690,27 +693,27 @@ ollama pull llama3.3
|
||||
}
|
||||
```
|
||||
|
||||
Ollama jest wykrywana lokalnie pod adresem `http://127.0.0.1:11434`, gdy włączysz ją przez
|
||||
Ollama jest wykrywany lokalnie pod `http://127.0.0.1:11434`, gdy włączysz go przez
|
||||
`OLLAMA_API_KEY`, a dołączona wtyczka 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.
|
||||
aby poznać onboarding, tryb chmura/lokalny i konfigurację niestandardową.
|
||||
|
||||
### vLLM
|
||||
|
||||
vLLM jest dostarczane jako dołączona wtyczka dostawcy dla lokalnych/samohostowanych
|
||||
vLLM jest dostarczany jako dołączona wtyczka dostawcy dla lokalnych/self-hosted
|
||||
serwerów zgodnych z OpenAI:
|
||||
|
||||
- Dostawca: `vllm`
|
||||
- Uwierzytelnianie: opcjonalne (zależy od serwera)
|
||||
- Domyślny bazowy URL: `http://127.0.0.1:8000/v1`
|
||||
- Auth: opcjonalne (zależy od serwera)
|
||||
- Domyślny base URL: `http://127.0.0.1:8000/v1`
|
||||
|
||||
Aby lokalnie włączyć automatyczne wykrywanie (dowolna wartość działa, jeśli serwer nie wymusza uwierzytelniania):
|
||||
Aby włączyć lokalne auto-discovery (dowolna wartość działa, jeśli serwer nie wymusza auth):
|
||||
|
||||
```bash
|
||||
export VLLM_API_KEY="vllm-local"
|
||||
```
|
||||
|
||||
Następnie ustaw model (zamień na jeden z identyfikatorów zwróconych przez `/v1/models`):
|
||||
Następnie ustaw model (zamień na jeden z identyfikatorów zwracanych przez `/v1/models`):
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -720,25 +723,25 @@ Następnie ustaw model (zamień na jeden z identyfikatorów zwróconych przez `/
|
||||
}
|
||||
```
|
||||
|
||||
Szczegóły znajdziesz na stronie [/providers/vllm](/pl/providers/vllm).
|
||||
Szczegóły znajdziesz w [/providers/vllm](/pl/providers/vllm).
|
||||
|
||||
### SGLang
|
||||
|
||||
SGLang jest dostarczany jako dołączona wtyczka dostawcy dla szybkich, samohostowanych
|
||||
serwerów zgodnych z OpenAI:
|
||||
SGLang jest dostarczany jako dołączona wtyczka dostawcy dla szybkich serwerów self-hosted
|
||||
zgodnych z OpenAI:
|
||||
|
||||
- Dostawca: `sglang`
|
||||
- Uwierzytelnianie: opcjonalne (zależy od serwera)
|
||||
- Domyślny bazowy URL: `http://127.0.0.1:30000/v1`
|
||||
- Auth: opcjonalne (zależy od serwera)
|
||||
- Domyślny base URL: `http://127.0.0.1:30000/v1`
|
||||
|
||||
Aby lokalnie włączyć automatyczne wykrywanie (dowolna wartość działa, jeśli serwer nie
|
||||
wymusza uwierzytelniania):
|
||||
Aby włączyć lokalne auto-discovery (dowolna wartość działa, jeśli serwer nie
|
||||
wymusza auth):
|
||||
|
||||
```bash
|
||||
export SGLANG_API_KEY="sglang-local"
|
||||
```
|
||||
|
||||
Następnie ustaw model (zamień na jeden z identyfikatorów zwróconych przez `/v1/models`):
|
||||
Następnie ustaw model (zamień na jeden z identyfikatorów zwracanych przez `/v1/models`):
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -748,7 +751,7 @@ Następnie ustaw model (zamień na jeden z identyfikatorów zwróconych przez `/
|
||||
}
|
||||
```
|
||||
|
||||
Szczegóły znajdziesz na stronie [/providers/sglang](/pl/providers/sglang).
|
||||
Szczegóły znajdziesz w [/providers/sglang](/pl/providers/sglang).
|
||||
|
||||
### Lokalne proxy (LM Studio, vLLM, LiteLLM itd.)
|
||||
|
||||
@ -759,7 +762,7 @@ Przykład (zgodny z OpenAI):
|
||||
agents: {
|
||||
defaults: {
|
||||
model: { primary: "lmstudio/my-local-model" },
|
||||
models: { "lmstudio/my-local-model": { alias: "Local" } },
|
||||
models: { "lmstudio/my-local-model": { alias: "Lokalny" } },
|
||||
},
|
||||
},
|
||||
models: {
|
||||
@ -787,21 +790,21 @@ Przykład (zgodny z OpenAI):
|
||||
|
||||
Uwagi:
|
||||
|
||||
- W przypadku dostawców niestandardowych `reasoning`, `input`, `cost`, `contextWindow` i `maxTokens` są opcjonalne.
|
||||
Gdy zostaną pominięte, OpenClaw domyślnie przyjmuje:
|
||||
- Dla niestandardowych dostawców `reasoning`, `input`, `cost`, `contextWindow` i `maxTokens` są opcjonalne.
|
||||
Po pominięciu OpenClaw przyjmuje domyślnie:
|
||||
- `reasoning: false`
|
||||
- `input: ["text"]`
|
||||
- `cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }`
|
||||
- `contextWindow: 200000`
|
||||
- `maxTokens: 8192`
|
||||
- Zalecane: ustaw jawne wartości odpowiadające limitom Twojego proxy/modelu.
|
||||
- Dla `api: "openai-completions"` na nienatywnych punktach końcowych (dowolny niepusty `baseUrl`, którego host nie jest `api.openai.com`) OpenClaw wymusza `compat.supportsDeveloperRole: false`, aby uniknąć błędów 400 dostawcy dla nieobsługiwanych ról `developer`.
|
||||
- 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 dostawcy 400 dla nieobsługiwanych ról `developer`.
|
||||
- Trasy proxy zgodne z OpenAI również pomijają natywne kształtowanie żądań tylko dla OpenAI:
|
||||
brak `service_tier`, brak `store` w Responses, brak wskazówek pamięci podręcznej promptów, brak
|
||||
kształtowania ładunku zgodności rozumowania OpenAI i brak ukrytych nagłówków
|
||||
brak `service_tier`, brak `store` dla Responses, brak wskazówek cache promptów, brak
|
||||
kształtowania payload zgodności reasoning OpenAI i brak ukrytych nagłówków
|
||||
atrybucji OpenClaw.
|
||||
- Jeśli `baseUrl` jest pusty/pominięty, OpenClaw zachowuje domyślne zachowanie OpenAI (które rozwiązuje się do `api.openai.com`).
|
||||
- Dla bezpieczeństwa jawne `compat.supportsDeveloperRole: true` jest nadal nadpisywane na nienatywnych punktach końcowych `openai-completions`.
|
||||
- Jeśli `baseUrl` jest pusty/pominięty, OpenClaw zachowuje domyślne zachowanie OpenAI (które jest rozwiązywane do `api.openai.com`).
|
||||
- Dla bezpieczeństwa jawne `compat.supportsDeveloperRole: true` nadal jest nadpisywane na nienatywnych endpointach `openai-completions`.
|
||||
|
||||
## Przykłady CLI
|
||||
|
||||
@ -811,11 +814,11 @@ openclaw models set opencode/claude-opus-4-6
|
||||
openclaw models list
|
||||
```
|
||||
|
||||
Zobacz także: [/gateway/configuration](/pl/gateway/configuration), aby poznać pełne przykłady konfiguracji.
|
||||
Zobacz też: [/gateway/configuration](/pl/gateway/configuration), aby poznać pełne przykłady konfiguracji.
|
||||
|
||||
## Powiązane
|
||||
|
||||
- [Models](/pl/concepts/models) — konfiguracja modeli i aliasy
|
||||
- [Model Failover](/pl/concepts/model-failover) — łańcuchy przełączeń awaryjnych i zachowanie ponawiania prób
|
||||
- [Model Failover](/pl/concepts/model-failover) — łańcuchy fallback i zachowanie ponownych prób
|
||||
- [Configuration Reference](/pl/gateway/configuration-reference#agent-defaults) — klucze konfiguracji modeli
|
||||
- [Providers](/pl/providers) — przewodniki konfiguracji dla poszczególnych dostawców
|
||||
|
||||
@ -1,15 +1,15 @@
|
||||
---
|
||||
read_when:
|
||||
- Rozszerzanie qa-lab lub qa-channel
|
||||
- Dodawanie scenariuszy QA wspieranych przez repozytorium
|
||||
- Budowanie bardziej realistycznej automatyzacji QA wokół panelu Gateway
|
||||
summary: Prywatna struktura automatyzacji QA dla qa-lab, qa-channel, scenariuszy seedowanych i raportów protokołu
|
||||
- Dodawanie scenariuszy QA opartych na repozytorium
|
||||
- Tworzenie bardziej realistycznej automatyzacji QA wokół panelu Gateway
|
||||
summary: Prywatna struktura automatyzacji QA dla qa-lab, qa-channel, scenariuszy seed i raportów protokołu
|
||||
title: Automatyzacja QA E2E
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T06:00:49Z"
|
||||
generated_at: "2026-04-09T01:27:48Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 57da147dc06abf9620290104e01a83b42182db1806514114fd9e8467492cda99
|
||||
source_hash: c922607d67e0f3a2489ac82bc9f510f7294ced039c1014c15b676d826441d833
|
||||
source_path: concepts/qa-e2e-automation.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -17,35 +17,35 @@ x-i18n:
|
||||
# Automatyzacja QA E2E
|
||||
|
||||
Prywatny stos QA ma na celu testowanie OpenClaw w bardziej realistyczny,
|
||||
ukształtowany przez kanały sposób, niż może to zrobić pojedynczy test jednostkowy.
|
||||
zbliżony do kanałów sposób, niż może to zapewnić pojedynczy test jednostkowy.
|
||||
|
||||
Obecne elementy:
|
||||
|
||||
- `extensions/qa-channel`: syntetyczny kanał wiadomości z powierzchniami DM, kanału, wątku,
|
||||
- `extensions/qa-channel`: syntetyczny kanał wiadomości z obsługą DM, kanałów, wątków,
|
||||
reakcji, edycji i usuwania.
|
||||
- `extensions/qa-lab`: interfejs debugowania i magistrala QA do obserwowania transkryptu,
|
||||
wstrzykiwania wiadomości przychodzących oraz eksportowania raportu Markdown.
|
||||
- `qa/`: zasoby seedowane wspierane przez repozytorium dla zadania startowego i bazowych
|
||||
- `extensions/qa-lab`: interfejs debuggera i magistrala QA do obserwowania transkryptu,
|
||||
wstrzykiwania wiadomości przychodzących i eksportowania raportu Markdown.
|
||||
- `qa/`: zasoby seed oparte na repozytorium dla zadania startowego i bazowych
|
||||
scenariuszy QA.
|
||||
|
||||
Obecny przepływ pracy operatora QA to dwupanelowa strona QA:
|
||||
Obecny przepływ pracy operatora QA to dwupanelowa witryna QA:
|
||||
|
||||
- Po lewej: panel Gateway (Control UI) z agentem.
|
||||
- Po prawej: QA Lab, pokazujące transkrypt w stylu Slacka i plan scenariusza.
|
||||
- Lewy panel: panel Gateway (Control UI) z agentem.
|
||||
- Prawy panel: QA Lab, pokazujący transkrypt w stylu Slacka i plan scenariusza.
|
||||
|
||||
Uruchom to za pomocą:
|
||||
Uruchom za pomocą:
|
||||
|
||||
```bash
|
||||
pnpm qa:lab:up
|
||||
```
|
||||
|
||||
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 przydzielić agentowi misję QA,
|
||||
obserwować rzeczywiste zachowanie kanału oraz zapisywać, co zadziałało, co się nie udało lub
|
||||
co pozostało zablokowane.
|
||||
To buduje witrynę QA, uruchamia ścieżkę Gateway opartą na Dockerze i udostępnia
|
||||
stronę QA Lab, na której operator lub pętla automatyzacji może przekazać agentowi
|
||||
misję QA, obserwować rzeczywiste zachowanie kanału oraz zapisywać, co działało,
|
||||
co zawiodło lub co pozostało zablokowane.
|
||||
|
||||
Aby szybciej iterować nad interfejsem QA Lab bez przebudowywania obrazu Dockera za każdym razem,
|
||||
uruchom stos z bind-montowanym bundtem QA Lab:
|
||||
uruchom stos z bind-mountowanym bundlem QA Lab:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa docker-build-image
|
||||
@ -54,13 +54,14 @@ pnpm qa:lab:up:fast
|
||||
pnpm qa:lab:watch
|
||||
```
|
||||
|
||||
`qa:lab:up:fast` utrzymuje usługi Docker na wstępnie zbudowanym obrazie i bind-montuje
|
||||
`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 bundel przy zmianach, a przeglądarka automatycznie przeładowuje się, gdy hash zasobu QA Lab się zmieni.
|
||||
przebudowuje ten bundle po zmianach, a przeglądarka automatycznie przeładowuje się,
|
||||
gdy hash zasobu QA Lab ulegnie zmianie.
|
||||
|
||||
## Zasoby seedowane wspierane przez repozytorium
|
||||
## Seedy oparte na repozytorium
|
||||
|
||||
Zasoby seedowane znajdują się w `qa/`:
|
||||
Zasoby seed znajdują się w `qa/`:
|
||||
|
||||
- `qa/scenarios/index.md`
|
||||
- `qa/scenarios/*.md`
|
||||
@ -68,27 +69,80 @@ 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. Lista bazowa powinna pozostać na tyle szeroka, aby obejmować:
|
||||
|
||||
- czat DM i kanałowy
|
||||
- czat w DM i na kanałach
|
||||
- zachowanie wątków
|
||||
- cykl życia akcji wiadomości
|
||||
- cykl życia akcji na wiadomościach
|
||||
- wywołania cron
|
||||
- przywoływanie pamięci
|
||||
- przełączanie modeli
|
||||
- przekazanie do subagenta
|
||||
- odczyt repozytorium i dokumentacji
|
||||
- odczytywanie repozytorium i dokumentacji
|
||||
- jedno małe zadanie build, takie jak Lobster Invaders
|
||||
|
||||
## Raportowanie
|
||||
|
||||
`qa-lab` eksportuje raport protokołu Markdown na podstawie obserwowanej osi czasu magistrali.
|
||||
`qa-lab` eksportuje raport protokołu w Markdown na podstawie obserwowanej osi czasu magistrali.
|
||||
Raport powinien odpowiadać na pytania:
|
||||
|
||||
- Co zadziałało
|
||||
- Co się nie udało
|
||||
- Co działało
|
||||
- Co zawiodło
|
||||
- Co pozostało zablokowane
|
||||
- Jakie scenariusze uzupełniające warto dodać
|
||||
|
||||
## Powiązane dokumenty
|
||||
W przypadku kontroli charakteru i stylu uruchom ten sam scenariusz dla wielu aktywnych
|
||||
referencji modeli i zapisz oceniany raport Markdown:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa character-eval \
|
||||
--model openai/gpt-5.4,thinking=xhigh \
|
||||
--model openai/gpt-5.2,thinking=xhigh \
|
||||
--model openai/gpt-5,thinking=xhigh \
|
||||
--model anthropic/claude-opus-4-6,thinking=high \
|
||||
--model anthropic/claude-sonnet-4-6,thinking=high \
|
||||
--model zai/glm-5.1,thinking=high \
|
||||
--model moonshot/kimi-k2.5,thinking=high \
|
||||
--model google/gemini-3.1-pro-preview,thinking=high \
|
||||
--judge-model openai/gpt-5.4,thinking=xhigh,fast \
|
||||
--judge-model anthropic/claude-opus-4-6,thinking=high \
|
||||
--blind-judge-models \
|
||||
--concurrency 16 \
|
||||
--judge-concurrency 16
|
||||
```
|
||||
|
||||
Polecenie uruchamia lokalne podrzędne procesy QA Gateway, a nie Docker. Scenariusze
|
||||
oceny charakteru powinny ustawiać personę przez `SOUL.md`, a następnie wykonywać zwykłe
|
||||
tury użytkownika, takie jak czat, pomoc dotyczącą workspace i małe zadania na plikach. Modelowi
|
||||
kandydującemu nie należy mówić, że jest oceniany. Polecenie zachowuje każdy pełny
|
||||
transkrypt, rejestruje podstawowe statystyki uruchomienia, a następnie prosi modele oceniają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 providerów: prompt oceniają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 rzeczywiste referencje po
|
||||
parsowaniu.
|
||||
Uruchomienia kandydatów domyślnie używają poziomu myślenia `high`, a dla modeli OpenAI,
|
||||
które go obsługują, `xhigh`. Zastąp ustawienie dla konkretnego kandydata inline za pomocą
|
||||
`--model provider/model,thinking=<level>`. `--thinking <level>` nadal ustawia
|
||||
globalne ustawienie zapasowe, a starsza forma `--model-thinking <provider/model=level>` jest
|
||||
zachowana dla zgodności.
|
||||
Referencje kandydatów OpenAI domyślnie używają trybu fast, aby tam, gdzie provider to obsługuje,
|
||||
korzystać z przetwarzania priorytetowego. 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 dla kandydatów i modeli
|
||||
oceniających są zapisywane w raporcie do analizy benchmarków, ale prompty oceniające wyraźnie
|
||||
mówią, aby nie tworzyć rankingu na podstawie szybkości.
|
||||
Zarówno uruchomienia modeli kandydujących, jak i oceniających domyślnie używają współbieżności 16. Zmniejsz
|
||||
`--concurrency` lub `--judge-concurrency`, gdy limity providera lub obciążenie lokalnego Gateway
|
||||
powodują, że uruchomienie staje się zbyt zaszumione.
|
||||
Gdy nie zostanie przekazany żaden kandydat `--model`, ocena charakteru 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`, gdy nie zostanie przekazany parametr `--model`.
|
||||
Gdy nie zostanie przekazany żaden `--judge-model`, modele oceniające domyślnie używają
|
||||
`openai/gpt-5.4,thinking=xhigh,fast` oraz
|
||||
`anthropic/claude-opus-4-6,thinking=high`.
|
||||
|
||||
## Powiązana dokumentacja
|
||||
|
||||
- [Testing](/pl/help/testing)
|
||||
- [QA Channel](/pl/channels/qa-channel)
|
||||
|
||||
@ -1,38 +1,38 @@
|
||||
---
|
||||
read_when:
|
||||
- Chcesz mieć niezawodny fallback, gdy dostawcy API zawodzą
|
||||
- Chcesz mieć niezawodne rozwiązanie awaryjne, gdy dostawcy API zawodzą
|
||||
- Uruchamiasz Codex CLI lub inne lokalne AI CLI i chcesz używać ich ponownie
|
||||
- Chcesz zrozumieć most loopback MCP do dostępu narzędzi backendu CLI
|
||||
summary: 'Backendy CLI: lokalny awaryjny fallback AI CLI z opcjonalnym mostem narzędzi MCP'
|
||||
- Chcesz zrozumieć most local loopback MCP zapewniający dostęp backendu CLI do narzędzi
|
||||
summary: 'Backendy CLI: lokalne awaryjne przełączenie na AI CLI z opcjonalnym mostem narzędzi MCP'
|
||||
title: Backendy CLI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-07T09:44:57Z"
|
||||
generated_at: "2026-04-09T01:28:04Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: b0e8c41f5f5a8e34466f6b765e5c08585ef1788fa9e9d953257324bcc6cbc414
|
||||
source_hash: 9b458f9fe6fa64c47864c8c180f3dedfd35c5647de470a2a4d31c26165663c20
|
||||
source_path: gateway/cli-backends.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Backendy CLI (awaryjny runtime)
|
||||
# Backendy CLI (awaryjne środowisko uruchomieniowe)
|
||||
|
||||
OpenClaw może uruchamiać **lokalne AI CLI** jako **tekstowy fallback** gdy dostawcy API są niedostępni,
|
||||
ograniczani limitami lub tymczasowo działają nieprawidłowo. To podejście jest celowo zachowawcze:
|
||||
OpenClaw może uruchamiać **lokalne AI CLI** jako **awaryjne rozwiązanie tylko tekstowe**, gdy dostawcy API są niedostępni,
|
||||
ograniczani limitami lub tymczasowo działają nieprawidłowo. To rozwiązanie jest celowo zachowawcze:
|
||||
|
||||
- **Narzędzia OpenClaw nie są wstrzykiwane bezpośrednio**, ale backendy z `bundleMcp: true`
|
||||
mogą otrzymywać narzędzia gateway przez most loopback MCP.
|
||||
mogą otrzymywać narzędzia bramy przez most MCP typu loopback.
|
||||
- **Strumieniowanie JSONL** dla CLI, które je obsługują.
|
||||
- **Sesje są obsługiwane** (więc kolejne tury pozostają spójne).
|
||||
- **Sesje są obsługiwane** (dzięki temu kolejne tury pozostają spójne).
|
||||
- **Obrazy mogą być przekazywane dalej**, jeśli CLI akceptuje ścieżki do obrazów.
|
||||
|
||||
To rozwiązanie zostało zaprojektowane jako **siatka bezpieczeństwa**, a nie główna ścieżka. Używaj go, gdy
|
||||
chcesz mieć odpowiedzi tekstowe typu „zawsze działa” bez polegania na zewnętrznych API.
|
||||
To rozwiązanie pełni rolę **siatki bezpieczeństwa**, a nie głównej ścieżki. Używaj go, gdy
|
||||
chcesz uzyskiwać tekstowe odpowiedzi typu „zawsze działa” bez polegania na zewnętrznych API.
|
||||
|
||||
Jeśli chcesz mieć pełny runtime harness z kontrolą sesji ACP, zadaniami w tle,
|
||||
powiązaniem wątku/konwersacji i trwałymi zewnętrznymi sesjami kodowania, użyj
|
||||
Jeśli chcesz pełnego środowiska z kontrolą sesji ACP, zadaniami w tle,
|
||||
powiązaniem wątków/konwersacji i trwałymi zewnętrznymi sesjami kodowania, użyj
|
||||
[ACP Agents](/pl/tools/acp-agents). Backendy CLI nie są ACP.
|
||||
|
||||
## Przyjazny dla początkujących szybki start
|
||||
## Szybki start dla początkujących
|
||||
|
||||
Możesz używać Codex CLI **bez żadnej konfiguracji** (dołączona wtyczka OpenAI
|
||||
rejestruje domyślny backend):
|
||||
@ -41,8 +41,8 @@ rejestruje domyślny backend):
|
||||
openclaw agent --message "hi" --model codex-cli/gpt-5.4
|
||||
```
|
||||
|
||||
Jeśli Twój gateway działa pod launchd/systemd i PATH jest minimalny, dodaj tylko
|
||||
ścieżkę polecenia:
|
||||
Jeśli Twoja brama działa pod launchd/systemd, a `PATH` jest minimalne, dodaj tylko
|
||||
ścieżkę do polecenia:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -61,13 +61,13 @@ Jeśli Twój gateway działa pod launchd/systemd i PATH jest minimalny, dodaj ty
|
||||
To wszystko. Nie są potrzebne żadne klucze ani dodatkowa konfiguracja uwierzytelniania poza samym CLI.
|
||||
|
||||
Jeśli używasz dołączonego backendu CLI jako **głównego dostawcy wiadomości** na
|
||||
hoście gateway, OpenClaw teraz automatycznie ładuje odpowiednią dołączoną wtyczkę, gdy Twoja konfiguracja
|
||||
jawnie odwołuje się do tego backendu w odwołaniu do modelu lub w
|
||||
hoście bramy, OpenClaw teraz automatycznie ładuje odpowiednią dołączoną wtyczkę, gdy Twoja konfiguracja
|
||||
jawnie odwołuje się do tego backendu w odwołaniu do modelu albo w
|
||||
`agents.defaults.cliBackends`.
|
||||
|
||||
## Używanie jako fallback
|
||||
## Używanie jako rozwiązania awaryjnego
|
||||
|
||||
Dodaj backend CLI do listy fallbacków, aby był uruchamiany tylko wtedy, gdy modele podstawowe zawiodą:
|
||||
Dodaj backend CLI do listy awaryjnej, aby był uruchamiany tylko wtedy, gdy główne modele zawiodą:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -88,8 +88,8 @@ Dodaj backend CLI do listy fallbacków, aby był uruchamiany tylko wtedy, gdy mo
|
||||
|
||||
Uwagi:
|
||||
|
||||
- Jeśli używasz `agents.defaults.models` (listy dozwolonych), musisz uwzględnić tam również modele backendu CLI.
|
||||
- Jeśli podstawowy dostawca zawiedzie (uwierzytelnianie, limity, timeouty), OpenClaw
|
||||
- Jeśli używasz `agents.defaults.models` (lista dozwolonych), musisz uwzględnić tam także modele backendu CLI.
|
||||
- Jeśli główny dostawca zawiedzie (uwierzytelnianie, limity, limity czasu), OpenClaw
|
||||
spróbuje następnie użyć backendu CLI.
|
||||
|
||||
## Przegląd konfiguracji
|
||||
@ -100,8 +100,8 @@ Wszystkie backendy CLI znajdują się pod:
|
||||
agents.defaults.cliBackends
|
||||
```
|
||||
|
||||
Każdy wpis jest kluczowany przez **id dostawcy** (np. `codex-cli`, `my-cli`).
|
||||
Id dostawcy staje się lewą stroną odwołania do modelu:
|
||||
Każdy wpis jest kluczowany przez **identyfikator dostawcy** (na przykład `codex-cli`, `my-cli`).
|
||||
Identyfikator dostawcy staje się lewą stroną odwołania do modelu:
|
||||
|
||||
```
|
||||
<provider>/<model>
|
||||
@ -131,6 +131,9 @@ Id dostawcy staje się lewą stroną odwołania do modelu:
|
||||
sessionMode: "existing",
|
||||
sessionIdFields: ["session_id", "conversation_id"],
|
||||
systemPromptArg: "--system",
|
||||
// CLI w stylu Codex mogą zamiast tego wskazywać plik promptu:
|
||||
// systemPromptFileConfigArg: "-c",
|
||||
// systemPromptFileConfigKey: "model_instructions_file",
|
||||
systemPromptWhen: "first",
|
||||
imageArg: "--image",
|
||||
imageMode: "repeat",
|
||||
@ -145,38 +148,44 @@ Id dostawcy staje się lewą stroną odwołania do modelu:
|
||||
## Jak to działa
|
||||
|
||||
1. **Wybiera backend** na podstawie prefiksu dostawcy (`codex-cli/...`).
|
||||
2. **Buduje system prompt** przy użyciu tego samego promptu OpenClaw + kontekstu workspace.
|
||||
3. **Uruchamia CLI** z id sesji (jeśli jest obsługiwane), aby historia pozostała spójna.
|
||||
4. **Parsuje wyjście** (JSON lub zwykły tekst) i zwraca końcowy tekst.
|
||||
5. **Utrwala id sesji** dla każdego backendu, aby kolejne tury używały tej samej sesji CLI.
|
||||
2. **Buduje prompt systemowy** z użyciem tego samego promptu OpenClaw i kontekstu obszaru roboczego.
|
||||
3. **Uruchamia CLI** z identyfikatorem sesji (jeśli jest obsługiwany), aby zachować spójność historii.
|
||||
4. **Parsuje dane wyjściowe** (JSON lub zwykły tekst) i zwraca końcowy tekst.
|
||||
5. **Utrwala identyfikatory sesji** dla każdego backendu, dzięki czemu kolejne tury używają tej samej sesji CLI.
|
||||
|
||||
<Note>
|
||||
Dołączony backend Anthropic `claude-cli` jest ponownie obsługiwany. Pracownicy Anthropic
|
||||
powiedzieli nam, że użycie Claude CLI w stylu OpenClaw jest znowu dozwolone, więc OpenClaw traktuje
|
||||
użycie `claude -p` jako usankcjonowane dla tej integracji, chyba że Anthropic opublikuje
|
||||
poinformowali nas, że użycie Claude CLI w stylu OpenClaw jest znów dozwolone, więc OpenClaw traktuje
|
||||
użycie `claude -p` jako zatwierdzone dla tej integracji, chyba że Anthropic opublikuje
|
||||
nową politykę.
|
||||
</Note>
|
||||
|
||||
Dołączony backend OpenAI `codex-cli` przekazuje prompt systemowy OpenClaw przez
|
||||
nadpisanie konfiguracji `model_instructions_file` w Codex (`-c
|
||||
model_instructions_file="..."`). Codex nie udostępnia flagi w stylu Claude
|
||||
`--append-system-prompt`, więc OpenClaw zapisuje złożony prompt do
|
||||
pliku tymczasowego dla każdej nowej sesji Codex CLI.
|
||||
|
||||
## Sesje
|
||||
|
||||
- Jeśli CLI obsługuje sesje, ustaw `sessionArg` (np. `--session-id`) albo
|
||||
`sessionArgs` (placeholder `{sessionId}`), gdy ID trzeba wstawić
|
||||
- Jeśli CLI obsługuje sesje, ustaw `sessionArg` (na przykład `--session-id`) albo
|
||||
`sessionArgs` (symbol zastępczy `{sessionId}`), gdy identyfikator trzeba wstawić
|
||||
do wielu flag.
|
||||
- Jeśli CLI używa **podpolecenia resume** z innymi flagami, ustaw
|
||||
- Jeśli CLI używa **podpolecenia wznawiania** z innymi flagami, ustaw
|
||||
`resumeArgs` (zastępuje `args` przy wznawianiu) i opcjonalnie `resumeOutput`
|
||||
(dla wznowień innych niż JSON).
|
||||
- `sessionMode`:
|
||||
- `always`: zawsze wysyłaj id sesji (nowe UUID, jeśli nic nie zapisano).
|
||||
- `existing`: wysyłaj id sesji tylko wtedy, gdy było wcześniej zapisane.
|
||||
- `none`: nigdy nie wysyłaj id sesji.
|
||||
- `always`: zawsze wysyłaj identyfikator sesji (nowy UUID, jeśli nic nie zapisano).
|
||||
- `existing`: wysyłaj identyfikator sesji tylko wtedy, gdy został wcześniej zapisany.
|
||||
- `none`: nigdy nie wysyłaj identyfikatora sesji.
|
||||
|
||||
Uwagi dotyczące serializacji:
|
||||
|
||||
- `serialize: true` utrzymuje uporządkowaną kolejność uruchomień w tym samym przebiegu.
|
||||
- Większość CLI serializuje na jednym przebiegu dostawcy.
|
||||
- OpenClaw porzuca ponowne użycie zapisanej sesji CLI, gdy zmienia się stan uwierzytelnienia backendu, w tym po ponownym logowaniu, rotacji tokena lub zmianie poświadczeń profilu uwierzytelniania.
|
||||
- `serialize: true` utrzymuje uporządkowanie uruchomień w tym samym torze.
|
||||
- Większość CLI serializuje na jednym torze dostawcy.
|
||||
- OpenClaw porzuca ponowne użycie zapisanej sesji CLI, gdy stan uwierzytelnienia backendu się zmienia, w tym po ponownym logowaniu, rotacji tokena lub zmianie poświadczenia profilu uwierzytelniania.
|
||||
|
||||
## Obrazy (pass-through)
|
||||
## Obrazy (przekazywanie dalej)
|
||||
|
||||
Jeśli Twoje CLI akceptuje ścieżki do obrazów, ustaw `imageArg`:
|
||||
|
||||
@ -186,15 +195,15 @@ imageMode: "repeat"
|
||||
```
|
||||
|
||||
OpenClaw zapisze obrazy base64 do plików tymczasowych. Jeśli ustawiono `imageArg`, te
|
||||
ścieżki są przekazywane jako argumenty CLI. Jeśli brakuje `imageArg`, OpenClaw dopisuje
|
||||
ścieżki są przekazywane jako argumenty CLI. Jeśli `imageArg` nie jest ustawione, OpenClaw dołącza
|
||||
ścieżki plików do promptu (wstrzykiwanie ścieżek), co wystarcza dla CLI, które automatycznie
|
||||
ładują lokalne pliki ze zwykłych ścieżek.
|
||||
ładują pliki lokalne ze zwykłych ścieżek.
|
||||
|
||||
## Wejścia / wyjścia
|
||||
|
||||
- `output: "json"` (domyślnie) próbuje sparsować JSON i wyodrębnić tekst + id sesji.
|
||||
- Dla wyjścia JSON Gemini CLI OpenClaw odczytuje tekst odpowiedzi z `response`, a
|
||||
informacje o zużyciu z `stats`, gdy `usage` nie istnieje lub jest puste.
|
||||
- `output: "json"` (domyślnie) próbuje sparsować JSON i wyodrębnić tekst oraz identyfikator sesji.
|
||||
- Dla wyjścia JSON Gemini CLI OpenClaw odczytuje tekst odpowiedzi z `response` oraz
|
||||
użycie ze `stats`, gdy `usage` nie istnieje lub jest puste.
|
||||
- `output: "jsonl"` parsuje strumienie JSONL (na przykład Codex CLI `--json`) i wyodrębnia końcową wiadomość agenta oraz identyfikatory sesji,
|
||||
jeśli są obecne.
|
||||
- `output: "text"` traktuje stdout jako końcową odpowiedź.
|
||||
@ -203,11 +212,11 @@ Tryby wejścia:
|
||||
|
||||
- `input: "arg"` (domyślnie) przekazuje prompt jako ostatni argument CLI.
|
||||
- `input: "stdin"` wysyła prompt przez stdin.
|
||||
- Jeśli prompt jest bardzo długi i ustawiono `maxPromptArgChars`, używany jest stdin.
|
||||
- Jeśli prompt jest bardzo długi i ustawiono `maxPromptArgChars`, używane jest stdin.
|
||||
|
||||
## Wartości domyślne (należące do wtyczki)
|
||||
## Domyślne ustawienia (należące do wtyczki)
|
||||
|
||||
Dołączona wtyczka OpenAI rejestruje także wartość domyślną dla `codex-cli`:
|
||||
Dołączona wtyczka OpenAI rejestruje również ustawienia domyślne dla `codex-cli`:
|
||||
|
||||
- `command: "codex"`
|
||||
- `args: ["exec","--json","--color","never","--sandbox","workspace-write","--skip-git-repo-check"]`
|
||||
@ -218,7 +227,7 @@ Dołączona wtyczka OpenAI rejestruje także wartość domyślną dla `codex-cli
|
||||
- `imageArg: "--image"`
|
||||
- `sessionMode: "existing"`
|
||||
|
||||
Dołączona wtyczka Google rejestruje także wartość domyślną dla `google-gemini-cli`:
|
||||
Dołączona wtyczka Google rejestruje również ustawienia domyślne dla `google-gemini-cli`:
|
||||
|
||||
- `command: "gemini"`
|
||||
- `args: ["--output-format", "json", "--prompt", "{prompt}"]`
|
||||
@ -229,69 +238,69 @@ Dołączona wtyczka Google rejestruje także wartość domyślną dla `google-ge
|
||||
- `sessionMode: "existing"`
|
||||
- `sessionIdFields: ["session_id", "sessionId"]`
|
||||
|
||||
Wymaganie wstępne: lokalne Gemini CLI musi być zainstalowane i dostępne jako
|
||||
Wymaganie wstępne: lokalny Gemini CLI musi być zainstalowany i dostępny jako
|
||||
`gemini` w `PATH` (`brew install gemini-cli` lub
|
||||
`npm install -g @google/gemini-cli`).
|
||||
|
||||
Uwagi o JSON Gemini CLI:
|
||||
Uwagi dotyczące JSON Gemini CLI:
|
||||
|
||||
- Tekst odpowiedzi jest odczytywany z pola JSON `response`.
|
||||
- Zużycie korzysta z `stats` jako fallbacku, gdy `usage` nie istnieje lub jest puste.
|
||||
- Użycie przechodzi awaryjnie na `stats`, gdy `usage` jest nieobecne lub puste.
|
||||
- `stats.cached` jest normalizowane do OpenClaw `cacheRead`.
|
||||
- Jeśli brakuje `stats.input`, OpenClaw wyprowadza tokeny wejściowe z
|
||||
- Jeśli `stats.input` nie istnieje, OpenClaw wyprowadza tokeny wejściowe z
|
||||
`stats.input_tokens - stats.cached`.
|
||||
|
||||
Nadpisuj tylko wtedy, gdy to potrzebne (najczęściej: bezwzględna ścieżka `command`).
|
||||
|
||||
## Wartości domyślne należące do wtyczki
|
||||
## Ustawienia domyślne należące do wtyczki
|
||||
|
||||
Wartości domyślne backendu CLI są teraz częścią powierzchni wtyczki:
|
||||
Domyślne ustawienia backendów CLI są teraz częścią powierzchni wtyczki:
|
||||
|
||||
- Wtyczki rejestrują je przez `api.registerCliBackend(...)`.
|
||||
- Backend `id` staje się prefiksem dostawcy w odwołaniach do modeli.
|
||||
- Konfiguracja użytkownika w `agents.defaults.cliBackends.<id>` nadal nadpisuje wartość domyślną wtyczki.
|
||||
- Czyszczenie konfiguracji specyficznej dla backendu pozostaje po stronie wtyczki przez opcjonalny hook
|
||||
`normalizeConfig`.
|
||||
- `id` backendu staje się prefiksem dostawcy w odwołaniach do modeli.
|
||||
- Konfiguracja użytkownika w `agents.defaults.cliBackends.<id>` nadal nadpisuje ustawienie domyślne wtyczki.
|
||||
- Czyszczenie konfiguracji specyficznej dla backendu pozostaje po stronie wtyczki dzięki opcjonalnemu
|
||||
hookowi `normalizeConfig`.
|
||||
|
||||
## Nakładki bundle MCP
|
||||
## Nakładki Bundle MCP
|
||||
|
||||
Backendy CLI **nie** otrzymują bezpośrednio wywołań narzędzi OpenClaw, ale backend może
|
||||
włączyć wygenerowaną nakładkę konfiguracji MCP przez `bundleMcp: true`.
|
||||
|
||||
Obecne zachowanie dla dołączonych backendów:
|
||||
Bieżące dołączone zachowanie:
|
||||
|
||||
- `claude-cli`: wygenerowany ścisły plik konfiguracji MCP
|
||||
- `claude-cli`: wygenerowany ścisły plik konfiguracyjny MCP
|
||||
- `codex-cli`: wbudowane nadpisania konfiguracji dla `mcp_servers`
|
||||
- `google-gemini-cli`: wygenerowany plik ustawień systemowych Gemini
|
||||
|
||||
Gdy bundle MCP jest włączone, OpenClaw:
|
||||
|
||||
- uruchamia serwer HTTP MCP loopback, który udostępnia narzędzia gateway procesowi CLI
|
||||
- uwierzytelnia most tokenem na sesję (`OPENCLAW_MCP_TOKEN`)
|
||||
- uruchamia serwer HTTP MCP typu loopback, który udostępnia narzędzia bramy procesowi CLI
|
||||
- uwierzytelnia most za pomocą tokena per sesja (`OPENCLAW_MCP_TOKEN`)
|
||||
- ogranicza dostęp do narzędzi do bieżącej sesji, konta i kontekstu kanału
|
||||
- ładuje włączone serwery bundle-MCP dla bieżącego workspace
|
||||
- ładuje włączone serwery bundle-MCP dla bieżącego obszaru roboczego
|
||||
- scala je z dowolnym istniejącym kształtem konfiguracji/ustawień MCP backendu
|
||||
- przepisuje konfigurację uruchomienia przy użyciu trybu integracji należącego do backendu z odpowiedniego rozszerzenia
|
||||
- przepisuje konfigurację uruchamiania przy użyciu trybu integracji należącego do backendu z rozszerzenia będącego jego właścicielem
|
||||
|
||||
Jeśli nie są włączone żadne serwery MCP, OpenClaw nadal wstrzykuje ścisłą konfigurację, gdy
|
||||
backend włącza bundle MCP, aby uruchomienia w tle pozostały odizolowane.
|
||||
Jeśli żadne serwery MCP nie są włączone, OpenClaw nadal wstrzykuje ścisłą konfigurację, gdy
|
||||
backend korzysta z bundle MCP, aby uruchomienia w tle pozostawały odizolowane.
|
||||
|
||||
## Ograniczenia
|
||||
|
||||
- **Brak bezpośrednich wywołań narzędzi OpenClaw.** OpenClaw nie wstrzykuje wywołań narzędzi do
|
||||
protokołu backendu CLI. Backendy widzą narzędzia gateway tylko wtedy, gdy włączają
|
||||
protokołu backendu CLI. Backendy widzą narzędzia bramy tylko wtedy, gdy wybiorą
|
||||
`bundleMcp: true`.
|
||||
- **Strumieniowanie jest zależne od backendu.** Niektóre backendy strumieniują JSONL; inne buforują
|
||||
do zakończenia działania.
|
||||
- **Wyjścia strukturalne** zależą od formatu JSON danego CLI.
|
||||
- **Sesje Codex CLI** są wznawiane przez wyjście tekstowe (bez JSONL), co jest mniej
|
||||
ustrukturyzowane niż początkowe uruchomienie `--json`. Sesje OpenClaw nadal działają
|
||||
do momentu zakończenia.
|
||||
- **Ustrukturyzowane dane wyjściowe** zależą od formatu JSON danego CLI.
|
||||
- **Sesje Codex CLI** są wznawiane przez wyjście tekstowe (bez JSONL), co jest
|
||||
mniej ustrukturyzowane niż początkowe uruchomienie `--json`. Sesje OpenClaw nadal działają
|
||||
normalnie.
|
||||
|
||||
## Rozwiązywanie problemów
|
||||
|
||||
- **Nie znaleziono CLI**: ustaw `command` na pełną ścieżkę.
|
||||
- **Nieprawidłowa nazwa modelu**: użyj `modelAliases`, aby mapować `provider/model` → model CLI.
|
||||
- **Brak ciągłości sesji**: upewnij się, że ustawiono `sessionArg` i `sessionMode` nie jest
|
||||
`none` (Codex CLI obecnie nie potrafi wznawiać z wyjściem JSON).
|
||||
- **Obrazy są ignorowane**: ustaw `imageArg` (i sprawdź, czy CLI obsługuje ścieżki plików).
|
||||
- **Nieprawidłowa nazwa modelu**: użyj `modelAliases`, aby zmapować `provider/model` → model CLI.
|
||||
- **Brak ciągłości sesji**: upewnij się, że ustawiono `sessionArg`, a `sessionMode` nie ma wartości
|
||||
`none` (Codex CLI obecnie nie może wznawiać z wyjściem JSON).
|
||||
- **Obrazy są ignorowane**: ustaw `imageArg` (i sprawdź, czy CLI obsługuje ścieżki do plików).
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,23 +1,22 @@
|
||||
---
|
||||
read_when:
|
||||
- Dodawanie lub modyfikowanie migracji doctor
|
||||
- Wprowadzanie niekompatybilnych zmian konfiguracji
|
||||
summary: 'Polecenie Doctor: kontrole stanu, migracje konfiguracji i kroki naprawcze'
|
||||
- Dodajesz lub modyfikujesz migracje Doctor
|
||||
- Wprowadzasz niekompatybilne zmiany konfiguracji
|
||||
summary: 'Komenda Doctor: kontrole kondycji, migracje konfiguracji i kroki naprawcze'
|
||||
title: Doctor
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T02:15:39Z"
|
||||
generated_at: "2026-04-09T01:29:21Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 3761a222d9db7088f78215575fa84e5896794ad701aa716e8bf9039a4424dca6
|
||||
source_hash: 75d321bd1ad0e16c29f2382e249c51edfc3a8d33b55bdceea39e7dbcd4901fce
|
||||
source_path: gateway/doctor.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Doctor
|
||||
|
||||
`openclaw doctor` to narzędzie naprawy i migracji dla OpenClaw. Naprawia
|
||||
nieaktualną konfigurację i stan, sprawdza kondycję systemu oraz podaje
|
||||
konkretne kroki naprawcze.
|
||||
`openclaw doctor` to narzędzie naprawy i migracji dla OpenClaw. Naprawia nieaktualną
|
||||
konfigurację i stan, sprawdza kondycję oraz podaje konkretne kroki naprawcze.
|
||||
|
||||
## Szybki start
|
||||
|
||||
@ -31,13 +30,13 @@ openclaw doctor
|
||||
openclaw doctor --yes
|
||||
```
|
||||
|
||||
Akceptuje domyślne opcje bez pytań (w tym kroki naprawy restartu/usługi/sandboxa, gdy mają zastosowanie).
|
||||
Akceptuje wartości domyślne bez pytania (w tym kroki naprawy restartu/usługi/sandboxa, gdy mają zastosowanie).
|
||||
|
||||
```bash
|
||||
openclaw doctor --repair
|
||||
```
|
||||
|
||||
Stosuje zalecane naprawy bez pytań (naprawy + restarty tam, gdzie jest to bezpieczne).
|
||||
Stosuje zalecane naprawy bez pytania (naprawy + restarty tam, gdzie to bezpieczne).
|
||||
|
||||
```bash
|
||||
openclaw doctor --repair --force
|
||||
@ -49,14 +48,14 @@ Stosuje także agresywne naprawy (nadpisuje niestandardowe konfiguracje supervis
|
||||
openclaw doctor --non-interactive
|
||||
```
|
||||
|
||||
Uruchamia bez pytań i stosuje tylko bezpieczne migracje (normalizacja konfiguracji + przenoszenie stanu na dysku). Pomija działania restartu/usługi/sandboxa, które wymagają potwierdzenia człowieka.
|
||||
Migracje starszego stanu są uruchamiane automatycznie po ich wykryciu.
|
||||
Uruchamia bez monitów i stosuje tylko bezpieczne migracje (normalizacja konfiguracji + przenoszenie stanu na dysku). Pomija działania restartu/usługi/sandboxa wymagające potwierdzenia człowieka.
|
||||
Migracje starszego stanu uruchamiają się automatycznie po ich wykryciu.
|
||||
|
||||
```bash
|
||||
openclaw doctor --deep
|
||||
```
|
||||
|
||||
Skanuje usługi systemowe pod kątem dodatkowych instalacji gatewaya (launchd/systemd/schtasks).
|
||||
Skanuje usługi systemowe w poszukiwaniu dodatkowych instalacji gateway (launchd/systemd/schtasks).
|
||||
|
||||
Jeśli chcesz przejrzeć zmiany przed zapisaniem, najpierw otwórz plik konfiguracji:
|
||||
|
||||
@ -66,46 +65,79 @@ cat ~/.openclaw/openclaw.json
|
||||
|
||||
## Co robi (podsumowanie)
|
||||
|
||||
- Opcjonalna aktualizacja przed uruchomieniem dla instalacji z gita (tylko interaktywnie).
|
||||
- Sprawdzenie aktualności protokołu UI (przebudowuje Control UI, gdy schemat protokołu jest nowszy).
|
||||
- Kontrola stanu + monit o restart.
|
||||
- Podsumowanie stanu Skills (kwalifikujące się/brakujące/zablokowane) oraz stanu pluginów.
|
||||
- Opcjonalna aktualizacja przed uruchomieniem dla instalacji git (tylko interaktywnie).
|
||||
- Kontrola aktualności protokołu UI (przebudowuje Control UI, gdy schemat protokołu jest nowszy).
|
||||
- Kontrola kondycji + monit o restart.
|
||||
- Podsumowanie stanu Skills (kwalifikujące się/brakujące/zablokowane) i stanu pluginów.
|
||||
- Normalizacja konfiguracji dla starszych wartości.
|
||||
- Migracja konfiguracji Talk ze starszych płaskich pól `talk.*` do `talk.provider` + `talk.providers.<provider>`.
|
||||
- Kontrole migracji przeglądarki dla starszych konfiguracji rozszerzenia Chrome i gotowości Chrome MCP.
|
||||
- Ostrzeżenia o nadpisaniu dostawcy OpenCode (`models.providers.opencode` / `models.providers.opencode-go`).
|
||||
- Ostrzeżenia o przesłanianiu Codex OAuth (`models.providers.openai-codex`).
|
||||
- Sprawdzenie wymagań TLS OAuth dla profili OpenAI Codex OAuth.
|
||||
- Migracja starszego stanu na dysku (sesje/katalog agenta/uwierzytelnianie WhatsApp).
|
||||
- Migracja starszych kluczy kontraktu manifestu pluginu (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders` → `contracts`).
|
||||
- Migracja starszego magazynu cron (`jobId`, `schedule.cron`, pola delivery/payload na najwyższym poziomie, `provider` w payload, proste zadania zapasowe webhooka z `notify: true`).
|
||||
- Inspekcja plików blokady sesji i czyszczenie nieaktualnych blokad.
|
||||
- Kontrole integralności i uprawnień stanu (sesje, transkrypty, katalog stanu).
|
||||
- Kontrole uprawnień pliku konfiguracji (`chmod 600`) przy uruchomieniu lokalnym.
|
||||
- Kondycja uwierzytelniania modeli: sprawdza wygaśnięcie OAuth, może odświeżyć wygasające tokeny i raportuje stany cooldown/wyłączenia profilu uwierzytelniania.
|
||||
- Ostrzeżenia o nadpisaniach dostawcy OpenCode (`models.providers.opencode` / `models.providers.opencode-go`).
|
||||
- Ostrzeżenia o przysłanianiu OAuth Codex (`models.providers.openai-codex`).
|
||||
- Kontrola wymagań wstępnych TLS dla profili OAuth OpenAI Codex.
|
||||
- Migracja starszego stanu na dysku (sessions/agent dir/uwierzytelnianie WhatsApp).
|
||||
- Migracja starszych kluczy kontraktów manifestu pluginów (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders` → `contracts`).
|
||||
- Migracja starszego magazynu cron (`jobId`, `schedule.cron`, pola delivery/payload na najwyższym poziomie, `provider` w payload, proste zadania zapasowe webhook z `notify: true`).
|
||||
- Kontrola plików blokady sesji i czyszczenie przeterminowanych blokad.
|
||||
- Kontrole integralności i uprawnień stanu (sessions, transcripts, katalog stanu).
|
||||
- Kontrole uprawnień pliku konfiguracji (`chmod 600`) przy uruchamianiu lokalnie.
|
||||
- Kondycja uwierzytelniania modeli: sprawdza wygaśnięcie OAuth, może odświeżać tokeny bliskie wygaśnięcia i raportuje stany cooldown/wyłączenia profilów uwierzytelniania.
|
||||
- Wykrywanie dodatkowego katalogu workspace (`~/openclaw`).
|
||||
- Naprawa obrazu sandboxa, gdy sandboxing jest włączony.
|
||||
- Migracja starszych usług i wykrywanie dodatkowych gatewayów.
|
||||
- Migracja starszych usług i wykrywanie dodatkowych gateway.
|
||||
- Migracja starszego stanu kanału Matrix (w trybie `--fix` / `--repair`).
|
||||
- Kontrole środowiska uruchomieniowego gatewaya (usługa zainstalowana, ale nie działa; zapisany w pamięci podręcznej label launchd).
|
||||
- Ostrzeżenia o stanie kanałów (sondowane z działającego gatewaya).
|
||||
- Kontrole runtime gateway (usługa zainstalowana, ale nieuruchomiona; zapisany w pamięci podręcznej label launchd).
|
||||
- Ostrzeżenia o stanie kanałów (sprawdzane z działającego gateway).
|
||||
- Audyt konfiguracji supervisora (launchd/systemd/schtasks) z opcjonalną naprawą.
|
||||
- Kontrole dobrych praktyk środowiska uruchomieniowego gatewaya (Node vs Bun, ścieżki menedżera wersji).
|
||||
- Diagnostyka kolizji portu gatewaya (domyślnie `18789`).
|
||||
- Ostrzeżenia bezpieczeństwa dla otwartych zasad DM.
|
||||
- Kontrole uwierzytelniania gatewaya dla lokalnego trybu tokena (oferuje wygenerowanie tokena, gdy nie istnieje żadne źródło tokena; nie nadpisuje konfiguracji tokenów SecretRef).
|
||||
- Sprawdzenie `systemd linger` w systemie Linux.
|
||||
- Sprawdzenie rozmiaru plików bootstrap workspace (ostrzeżenia o obcięciu / zbliżaniu się do limitu dla plików kontekstowych).
|
||||
- Sprawdzenie stanu autouzupełniania powłoki i automatyczna instalacja/aktualizacja.
|
||||
- Sprawdzenie gotowości dostawcy embeddingów wyszukiwania pamięci (model lokalny, zdalny klucz API lub binarka QMD).
|
||||
- Kontrole dobrych praktyk runtime gateway (Node vs Bun, ścieżki menedżera wersji).
|
||||
- Diagnostyka konfliktów portu gateway (domyślnie `18789`).
|
||||
- Ostrzeżenia bezpieczeństwa dla otwartych polityk DM.
|
||||
- Kontrole uwierzytelniania gateway dla lokalnego trybu tokena (oferuje wygenerowanie tokena, gdy nie istnieje jego źródło; nie nadpisuje konfiguracji tokenów SecretRef).
|
||||
- Kontrola `systemd linger` w Linuxie.
|
||||
- Kontrola rozmiaru plików bootstrap workspace (ostrzeżenia o obcięciu / blisko limitu dla plików kontekstu).
|
||||
- Kontrola stanu shell completion oraz automatyczna instalacja/aktualizacja.
|
||||
- Kontrola gotowości dostawcy embeddingów do wyszukiwania pamięci (model lokalny, zdalny klucz API lub binarka QMD).
|
||||
- Kontrole instalacji ze źródeł (niezgodność workspace pnpm, brakujące zasoby UI, brakująca binarka tsx).
|
||||
- Zapisuje zaktualizowaną konfigurację + metadane kreatora.
|
||||
|
||||
## Szczegółowe działanie i uzasadnienie
|
||||
## Backfill i reset Dreams UI
|
||||
|
||||
### 0) Opcjonalna aktualizacja (instalacje z gita)
|
||||
Scena Dreams w Control UI zawiera działania **Backfill**, **Reset** i **Clear Grounded**
|
||||
dla ugruntowanego przepływu dreaming. Te działania używają metod RPC
|
||||
w stylu doctor gateway, ale **nie** są częścią naprawy/migracji w CLI `openclaw doctor`.
|
||||
|
||||
Jeśli jest to checkout z gita i doctor działa interaktywnie, oferuje
|
||||
Co robią:
|
||||
|
||||
- **Backfill** skanuje historyczne pliki `memory/YYYY-MM-DD.md` w aktywnym
|
||||
workspace, uruchamia ugruntowany przebieg dziennika REM i zapisuje odwracalne wpisy
|
||||
backfill do `DREAMS.md`.
|
||||
- **Reset** usuwa z `DREAMS.md` tylko te oznaczone wpisy dziennika backfill.
|
||||
- **Clear Grounded** usuwa tylko przygotowane wpisy krótkoterminowe typu grounded-only,
|
||||
które pochodzą z historycznego odtworzenia i nie zgromadziły jeszcze aktywnego wsparcia
|
||||
z przypomnień ani z dziennych danych.
|
||||
|
||||
Czego same z siebie **nie** robią:
|
||||
|
||||
- nie edytują `MEMORY.md`
|
||||
- nie uruchamiają pełnych migracji doctor
|
||||
- nie przygotowują automatycznie ugruntowanych kandydatów w aktywnym magazynie
|
||||
promocji krótkoterminowej, chyba że najpierw jawnie uruchomisz ścieżkę CLI z przygotowaniem
|
||||
|
||||
Jeśli chcesz, aby ugruntowane historyczne odtworzenie wpływało na zwykłą ścieżkę
|
||||
promocji deep, użyj zamiast tego przepływu CLI:
|
||||
|
||||
```bash
|
||||
openclaw memory rem-backfill --path ./memory --stage-short-term
|
||||
```
|
||||
|
||||
To przygotowuje ugruntowanych trwałych kandydatów w krótkoterminowym magazynie dreaming, pozostawiając
|
||||
`DREAMS.md` jako powierzchnię do przeglądu.
|
||||
|
||||
## Szczegółowe zachowanie i uzasadnienie
|
||||
|
||||
### 0) Opcjonalna aktualizacja (instalacje git)
|
||||
|
||||
Jeśli jest to checkout git, a doctor działa interaktywnie, oferuje
|
||||
aktualizację (fetch/rebase/build) przed uruchomieniem doctor.
|
||||
|
||||
### 1) Normalizacja konfiguracji
|
||||
@ -114,25 +146,24 @@ Jeśli konfiguracja zawiera starsze kształty wartości (na przykład `messages.
|
||||
bez nadpisania specyficznego dla kanału), doctor normalizuje je do bieżącego
|
||||
schematu.
|
||||
|
||||
Dotyczy to także starszych płaskich pól Talk. Obecna publiczna konfiguracja Talk to
|
||||
`talk.provider` + `talk.providers.<provider>`. Doctor przepisuje stare kształty
|
||||
`talk.voiceId` / `talk.voiceAliases` / `talk.modelId` / `talk.outputFormat` /
|
||||
`talk.apiKey` do mapy dostawców.
|
||||
Obejmuje to starsze płaskie pola Talk. Bieżąca publiczna konfiguracja Talk to
|
||||
`talk.provider` + `talk.providers.<provider>`. Doctor przepisuje stare
|
||||
kształty `talk.voiceId` / `talk.voiceAliases` / `talk.modelId` / `talk.outputFormat` /
|
||||
`talk.apiKey` do mapy dostawcy.
|
||||
|
||||
### 2) Migracje starszych kluczy konfiguracji
|
||||
|
||||
Gdy konfiguracja zawiera przestarzałe klucze, inne polecenia odmawiają działania i proszą,
|
||||
aby uruchomić `openclaw doctor`.
|
||||
Gdy konfiguracja zawiera przestarzałe klucze, inne polecenia odmawiają uruchomienia i proszą
|
||||
o uruchomienie `openclaw doctor`.
|
||||
|
||||
Doctor wykona wtedy:
|
||||
Doctor:
|
||||
|
||||
- Wyjaśni, które starsze klucze zostały znalezione.
|
||||
- Pokaże zastosowaną migrację.
|
||||
- Przepisze `~/.openclaw/openclaw.json` z użyciem zaktualizowanego schematu.
|
||||
- Wyjaśnia, które starsze klucze zostały znalezione.
|
||||
- Pokazuje zastosowaną migrację.
|
||||
- Przepisuje `~/.openclaw/openclaw.json` z użyciem zaktualizowanego schematu.
|
||||
|
||||
Gateway uruchamia także migracje doctor automatycznie przy starcie, gdy wykryje
|
||||
starszy format konfiguracji, dzięki czemu nieaktualne konfiguracje są naprawiane
|
||||
bez ręcznej interwencji.
|
||||
Gateway także automatycznie uruchamia migracje doctor przy starcie, gdy wykryje
|
||||
starszy format konfiguracji, więc nieaktualne konfiguracje są naprawiane bez ręcznej interwencji.
|
||||
Migracje magazynu zadań cron są obsługiwane przez `openclaw doctor --fix`.
|
||||
|
||||
Bieżące migracje:
|
||||
@ -157,7 +188,7 @@ Bieżące migracje:
|
||||
- `plugins.entries.voice-call.config.streaming.openaiApiKey|sttModel|silenceDurationMs|vadThreshold`
|
||||
→ `plugins.entries.voice-call.config.streaming.providers.openai.*`
|
||||
- `bindings[].match.accountID` → `bindings[].match.accountId`
|
||||
- Dla kanałów z nazwanymi `accounts`, ale z pozostałymi jednokontowymi wartościami kanału na najwyższym poziomie, przenieś te wartości przypisane do konta do wybranego promowanego konta dla tego kanału (`accounts.default` dla większości kanałów; Matrix może zachować istniejący pasujący nazwany/domyslny cel)
|
||||
- Dla kanałów z nazwanymi `accounts`, ale z pozostawionymi na najwyższym poziomie wartościami kanału dla pojedynczego konta, przenieś te wartości ograniczone do konta do promowanego konta wybranego dla tego kanału (`accounts.default` dla większości kanałów; Matrix może zachować istniejący pasujący nazwany/domyślny cel)
|
||||
- `identity` → `agents.list[].identity`
|
||||
- `agent.*` → `agents.defaults` + `tools.*` (tools/elevated/exec/sandbox/subagents)
|
||||
- `agent.model`/`allowedModels`/`modelAliases`/`modelFallbacks`/`imageModelFallbacks`
|
||||
@ -166,77 +197,77 @@ Bieżące migracje:
|
||||
- `browser.profiles.*.driver: "extension"` → `"existing-session"`
|
||||
- usuń `browser.relayBindHost` (starsze ustawienie relay rozszerzenia)
|
||||
|
||||
Ostrzeżenia doctor obejmują też wskazówki dotyczące domyślnego konta dla kanałów wielokontowych:
|
||||
Ostrzeżenia doctor obejmują także wskazówki dotyczące domyślnego konta dla kanałów wielokontowych:
|
||||
|
||||
- Jeśli skonfigurowano dwa lub więcej wpisów `channels.<channel>.accounts` bez `channels.<channel>.defaultAccount` lub `accounts.default`, doctor ostrzega, że routing zapasowy może wybrać nieoczekiwane konto.
|
||||
- Jeśli ustawiono `channels.<channel>.defaultAccount` na nieznany identyfikator konta, doctor ostrzega i wyświetla listę skonfigurowanych identyfikatorów kont.
|
||||
- Jeśli skonfigurowano co najmniej dwa wpisy `channels.<channel>.accounts` bez `channels.<channel>.defaultAccount` lub `accounts.default`, doctor ostrzega, że routowanie zapasowe może wybrać nieoczekiwane konto.
|
||||
- Jeśli `channels.<channel>.defaultAccount` jest ustawione na nieznany identyfikator konta, doctor ostrzega i wypisuje skonfigurowane identyfikatory kont.
|
||||
|
||||
### 2b) Nadpisania dostawcy OpenCode
|
||||
|
||||
Jeśli ręcznie dodano `models.providers.opencode`, `opencode-zen` lub `opencode-go`,
|
||||
nadpisuje to wbudowany katalog OpenCode z `@mariozechner/pi-ai`.
|
||||
Może to wymusić użycie niewłaściwego API dla modeli albo wyzerować koszty. Doctor ostrzega, aby
|
||||
można było usunąć nadpisanie i przywrócić routing API oraz koszty dla każdego modelu.
|
||||
Może to wymusić przypisanie modeli do niewłaściwego API albo wyzerować koszty. Doctor ostrzega, aby można było
|
||||
usunąć nadpisanie i przywrócić routowanie API oraz koszty per model.
|
||||
|
||||
### 2c) Migracja przeglądarki i gotowość Chrome MCP
|
||||
|
||||
Jeśli konfiguracja przeglądarki nadal wskazuje na usuniętą ścieżkę rozszerzenia Chrome, doctor
|
||||
normalizuje ją do obecnego modelu dołączania Chrome MCP lokalnego dla hosta:
|
||||
Jeśli konfiguracja przeglądarki nadal wskazuje usuniętą ścieżkę rozszerzenia Chrome, doctor
|
||||
normalizuje ją do obecnego modelu dołączania Chrome MCP host-local:
|
||||
|
||||
- `browser.profiles.*.driver: "extension"` zmienia się na `"existing-session"`
|
||||
- `browser.relayBindHost` jest usuwane
|
||||
|
||||
Doctor audytuje też lokalną dla hosta ścieżkę Chrome MCP, gdy używasz `defaultProfile:
|
||||
"user"` albo skonfigurowanego profilu `existing-session`:
|
||||
Doctor audytuje też ścieżkę Chrome MCP host-local, gdy używasz `defaultProfile:
|
||||
"user"` lub skonfigurowanego profilu `existing-session`:
|
||||
|
||||
- sprawdza, czy Google Chrome jest zainstalowany na tym samym hoście dla domyślnych
|
||||
profili automatycznego łączenia
|
||||
- sprawdza, czy Google Chrome jest zainstalowane na tym samym hoście dla domyślnych
|
||||
profili auto-connect
|
||||
- sprawdza wykrytą wersję Chrome i ostrzega, gdy jest niższa niż Chrome 144
|
||||
- przypomina o włączeniu zdalnego debugowania na stronie inspekcji przeglądarki (na
|
||||
- przypomina o włączeniu zdalnego debugowania na stronie inspect przeglądarki (na
|
||||
przykład `chrome://inspect/#remote-debugging`, `brave://inspect/#remote-debugging`,
|
||||
lub `edge://inspect/#remote-debugging`)
|
||||
|
||||
Doctor nie może włączyć ustawienia po stronie Chrome za Ciebie. Lokalny dla hosta Chrome MCP
|
||||
Doctor nie może włączyć za Ciebie ustawienia po stronie Chrome. Chrome MCP host-local
|
||||
nadal wymaga:
|
||||
|
||||
- przeglądarki opartej na Chromium 144+ na hoście gatewaya/noda
|
||||
- przeglądarki opartej na Chromium 144+ na hoście gateway/node
|
||||
- lokalnie uruchomionej przeglądarki
|
||||
- włączonego zdalnego debugowania w tej przeglądarce
|
||||
- zatwierdzenia pierwszego monitu o zgodę na dołączenie w przeglądarce
|
||||
- zatwierdzenia pierwszego monitu o zgodę na połączenie w przeglądarce
|
||||
|
||||
Gotowość w tym miejscu dotyczy wyłącznie wymagań wstępnych lokalnego dołączania. Existing-session zachowuje
|
||||
obecne ograniczenia tras Chrome MCP; zaawansowane trasy, takie jak `responsebody`, eksport PDF,
|
||||
Gotowość tutaj dotyczy wyłącznie lokalnych wymagań wstępnych dołączenia. Existing-session zachowuje
|
||||
bieżące ograniczenia tras Chrome MCP; zaawansowane trasy, takie jak `responsebody`, eksport PDF,
|
||||
przechwytywanie pobierania i działania wsadowe, nadal wymagają zarządzanej
|
||||
przeglądarki lub surowego profilu CDP.
|
||||
|
||||
To sprawdzenie **nie** dotyczy Docker, sandbox, remote-browser ani innych
|
||||
przepływów bezgłowych. One nadal używają surowego CDP.
|
||||
Ta kontrola **nie** dotyczy Docker, sandbox, remote-browser ani innych
|
||||
przepływów bezgłowych. Nadal używają one surowego CDP.
|
||||
|
||||
### 2d) Wymagania TLS OAuth
|
||||
### 2d) Wymagania wstępne OAuth TLS
|
||||
|
||||
Gdy skonfigurowany jest profil OpenAI Codex OAuth, doctor sonduje punkt końcowy
|
||||
Gdy skonfigurowany jest profil OAuth OpenAI Codex, doctor sonduje endpoint
|
||||
autoryzacji OpenAI, aby sprawdzić, czy lokalny stos TLS Node/OpenSSL potrafi
|
||||
zweryfikować łańcuch certyfikatów. Jeśli sonda zakończy się błędem certyfikatu (na
|
||||
przykład `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, wygasły certyfikat lub certyfikat własny),
|
||||
doctor wyświetla wskazówki naprawcze specyficzne dla platformy. W systemie macOS z Node z Homebrew
|
||||
naprawą jest zwykle `brew postinstall ca-certificates`. Z `--deep` sonda działa
|
||||
nawet wtedy, gdy gateway jest zdrowy.
|
||||
zweryfikować łańcuch certyfikatów. Jeśli sonda kończy się błędem certyfikatu (na
|
||||
przykład `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, wygasły certyfikat lub certyfikat samopodpisany),
|
||||
doctor wypisuje wskazówki naprawy specyficzne dla platformy. W macOS z Node z Homebrew
|
||||
naprawą jest zwykle `brew postinstall ca-certificates`. Z `--deep` sonda uruchamia się
|
||||
nawet wtedy, gdy gateway jest w dobrym stanie.
|
||||
|
||||
### 2c) Nadpisania dostawcy Codex OAuth
|
||||
### 2c) Nadpisania dostawcy OAuth Codex
|
||||
|
||||
Jeśli wcześniej dodano starsze ustawienia transportu OpenAI w
|
||||
`models.providers.openai-codex`, mogą one przesłaniać wbudowaną ścieżkę
|
||||
dostawcy Codex OAuth, której nowsze wydania używają automatycznie. Doctor ostrzega, gdy wykryje
|
||||
te stare ustawienia transportu razem z Codex OAuth, aby można było usunąć lub przepisać
|
||||
nieaktualne nadpisanie transportu i odzyskać wbudowane zachowanie routingu/fallbacku.
|
||||
Niestandardowe proxy i nadpisania samych nagłówków są nadal obsługiwane i nie
|
||||
`models.providers.openai-codex`, mogą one przysłaniać wbudowaną ścieżkę dostawcy
|
||||
Codex OAuth, której nowsze wydania używają automatycznie. Doctor ostrzega, gdy widzi
|
||||
te stare ustawienia transportu obok Codex OAuth, aby można było usunąć lub przepisać
|
||||
nieaktualne nadpisanie transportu i odzyskać wbudowane zachowanie routingu/fallbacków.
|
||||
Niestandardowe proxy i nadpisania tylko nagłówków są nadal wspierane i nie
|
||||
wywołują tego ostrzeżenia.
|
||||
|
||||
### 3) Migracje starszego stanu (układ na dysku)
|
||||
|
||||
Doctor może migrować starsze układy na dysku do bieżącej struktury:
|
||||
|
||||
- Magazyn sesji + transkrypty:
|
||||
- Magazyn sessions + transcripts:
|
||||
- z `~/.openclaw/sessions/` do `~/.openclaw/agents/<agentId>/sessions/`
|
||||
- Katalog agenta:
|
||||
- z `~/.openclaw/agent/` do `~/.openclaw/agents/<agentId>/agent/`
|
||||
@ -244,13 +275,13 @@ Doctor może migrować starsze układy na dysku do bieżącej struktury:
|
||||
- ze starszego `~/.openclaw/credentials/*.json` (z wyjątkiem `oauth.json`)
|
||||
- do `~/.openclaw/credentials/whatsapp/<accountId>/...` (domyślny identyfikator konta: `default`)
|
||||
|
||||
Te migracje są realizowane w trybie best-effort i są idempotentne; doctor wyemituje ostrzeżenia, gdy
|
||||
pozostawi jakiekolwiek starsze foldery jako kopie zapasowe. Gateway/CLI również automatycznie migruje
|
||||
starsze sesje + katalog agenta przy starcie, dzięki czemu historia/uwierzytelnianie/modele trafiają do
|
||||
ścieżki per-agent bez ręcznego uruchamiania doctor. Uwierzytelnianie WhatsApp jest celowo
|
||||
migrowane tylko przez `openclaw doctor`. Normalizacja dostawcy/mapy dostawców Talk porównuje teraz
|
||||
Te migracje są wykonywane w trybie best-effort i są idempotentne; doctor będzie emitować ostrzeżenia, gdy
|
||||
pozostawi jakiekolwiek starsze foldery jako kopie zapasowe. Gateway/CLI także automatycznie migruje
|
||||
starsze sessions + katalog agenta przy starcie, dzięki czemu historia/uwierzytelnianie/modele trafiają do
|
||||
ścieżki per agent bez ręcznego uruchamiania doctor. Uwierzytelnianie WhatsApp jest celowo migrowane wyłącznie
|
||||
przez `openclaw doctor`. Normalizacja Talk provider/provider-map porównuje teraz
|
||||
według równości strukturalnej, więc różnice wyłącznie w kolejności kluczy nie wywołują już
|
||||
powtarzanych zmian bez efektu przez `doctor --fix`.
|
||||
powtarzających się, pustych zmian `doctor --fix`.
|
||||
|
||||
### 3a) Migracje starszych manifestów pluginów
|
||||
|
||||
@ -259,15 +290,15 @@ możliwości na najwyższym poziomie (`speechProviders`, `realtimeTranscriptionP
|
||||
`realtimeVoiceProviders`, `mediaUnderstandingProviders`,
|
||||
`imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`,
|
||||
`webSearchProviders`). Gdy je znajdzie, oferuje przeniesienie ich do obiektu `contracts`
|
||||
i przepisanie pliku manifestu w miejscu. Ta migracja jest idempotentna;
|
||||
jeśli klucz `contracts` ma już te same wartości, starszy klucz jest usuwany
|
||||
i przepisanie pliku manifestu na miejscu. Ta migracja jest idempotentna;
|
||||
jeśli klucz `contracts` zawiera już te same wartości, starszy klucz jest usuwany
|
||||
bez duplikowania danych.
|
||||
|
||||
### 3b) Migracje starszego magazynu cron
|
||||
|
||||
Doctor sprawdza także magazyn zadań cron (`~/.openclaw/cron/jobs.json` domyślnie,
|
||||
lub `cron.store`, jeśli został nadpisany) pod kątem starych kształtów zadań, które harmonogram
|
||||
nadal akceptuje ze względów kompatybilności.
|
||||
Doctor sprawdza też magazyn zadań cron (`~/.openclaw/cron/jobs.json` domyślnie,
|
||||
lub `cron.store`, jeśli został nadpisany) pod kątem starych kształtów zadań, które scheduler nadal
|
||||
akceptuje dla zgodności.
|
||||
|
||||
Bieżące porządki cron obejmują:
|
||||
|
||||
@ -276,66 +307,71 @@ Bieżące porządki cron obejmują:
|
||||
- pola payload na najwyższym poziomie (`message`, `model`, `thinking`, ...) → `payload`
|
||||
- pola delivery na najwyższym poziomie (`deliver`, `channel`, `to`, `provider`, ...) → `delivery`
|
||||
- aliasy delivery `provider` w payload → jawne `delivery.channel`
|
||||
- proste starsze zadania zapasowe webhooka `notify: true` → jawne `delivery.mode="webhook"` z `delivery.to=cron.webhook`
|
||||
- proste starsze zadania zapasowe webhook z `notify: true` → jawne `delivery.mode="webhook"` z `delivery.to=cron.webhook`
|
||||
|
||||
Doctor automatycznie migruje zadania `notify: true` tylko wtedy, gdy może to zrobić bez
|
||||
zmiany zachowania. Jeśli zadanie łączy starszy zapasowy mechanizm notify z istniejącym
|
||||
zmiany zachowania. Jeśli zadanie łączy starszy fallback notify z istniejącym
|
||||
trybem delivery innym niż webhook, doctor ostrzega i pozostawia to zadanie do ręcznego przeglądu.
|
||||
|
||||
### 3c) Czyszczenie blokad sesji
|
||||
|
||||
Doctor skanuje każdy katalog sesji agenta w poszukiwaniu nieaktualnych plików blokady zapisu — plików
|
||||
pozostawionych po nieprawidłowym zakończeniu sesji. Dla każdego znalezionego pliku blokady raportuje:
|
||||
ścieżkę, PID, czy PID nadal żyje, wiek blokady i czy jest
|
||||
uznawana za nieaktualną (martwy PID lub więcej niż 30 minut). W trybie `--fix` / `--repair`
|
||||
automatycznie usuwa nieaktualne pliki blokady; w przeciwnym razie wyświetla notatkę i
|
||||
instrukcję, aby uruchomić ponownie z `--fix`.
|
||||
Doctor skanuje każdy katalog sesji agenta w poszukiwaniu przeterminowanych plików blokad zapisu — plików pozostawionych
|
||||
po nienormalnym zakończeniu sesji. Dla każdego znalezionego pliku blokady raportuje:
|
||||
ścieżkę, PID, czy PID nadal żyje, wiek blokady oraz czy jest
|
||||
uznawana za przeterminowaną (martwy PID lub starsza niż 30 minut). W trybie `--fix` / `--repair`
|
||||
automatycznie usuwa przeterminowane pliki blokad; w przeciwnym razie wypisuje uwagę i
|
||||
poleca ponowne uruchomienie z `--fix`.
|
||||
|
||||
### 4) Kontrole integralności stanu (trwałość sesji, routing i bezpieczeństwo)
|
||||
|
||||
Katalog stanu to operacyjny pień mózgu systemu. Jeśli zniknie, stracisz
|
||||
sesje, poświadczenia, logi i konfigurację (chyba że masz kopie zapasowe gdzie indziej).
|
||||
Katalog stanu to operacyjny pień mózgu. Jeśli zniknie, tracisz
|
||||
sessions, credentials, logi i konfigurację (chyba że masz kopie zapasowe gdzie indziej).
|
||||
|
||||
Doctor sprawdza:
|
||||
|
||||
- **Brak katalogu stanu**: ostrzega o katastrofalnej utracie stanu, proponuje odtworzenie
|
||||
- **Brak katalogu stanu**: ostrzega o katastrofalnej utracie stanu, prosi o odtworzenie
|
||||
katalogu i przypomina, że nie może odzyskać brakujących danych.
|
||||
- **Uprawnienia katalogu stanu**: weryfikuje możliwość zapisu; oferuje naprawę uprawnień
|
||||
(i wyświetla wskazówkę `chown`, gdy wykryje niezgodność właściciela/grupy).
|
||||
- **Katalog stanu synchronizowany z chmurą w macOS**: ostrzega, gdy stan znajduje się pod iCloud Drive
|
||||
(i emituje wskazówkę `chown`, gdy wykryje niezgodność właściciela/grupy).
|
||||
- **Katalog stanu synchronizowany przez chmurę w macOS**: ostrzega, gdy stan rozwiązuje się do iCloud Drive
|
||||
(`~/Library/Mobile Documents/com~apple~CloudDocs/...`) lub
|
||||
`~/Library/CloudStorage/...`, ponieważ ścieżki oparte na synchronizacji mogą powodować wolniejsze I/O
|
||||
oraz wyścigi blokad/synchronizacji.
|
||||
- **Katalog stanu na Linux na SD lub eMMC**: ostrzega, gdy stan znajduje się na źródle montowania `mmcblk*`,
|
||||
i wyścigi blokad/synchronizacji.
|
||||
- **Katalog stanu na SD lub eMMC w Linuxie**: ostrzega, gdy stan rozwiązuje się do źródła montowania `mmcblk*`,
|
||||
ponieważ losowe I/O na nośnikach SD lub eMMC może być wolniejsze i szybciej zużywać nośnik
|
||||
przy zapisie sesji i poświadczeń.
|
||||
przy zapisach sesji i credentials.
|
||||
- **Brak katalogów sesji**: `sessions/` i katalog magazynu sesji są
|
||||
wymagane do trwałego zapisywania historii i unikania awarii `ENOENT`.
|
||||
- **Niezgodność transkryptu**: ostrzega, gdy ostatnie wpisy sesji mają brakujące
|
||||
pliki transkryptu.
|
||||
- **Główna sesja „1-wierszowy JSONL”**: sygnalizuje, gdy główny transkrypt ma tylko jeden
|
||||
wiersz (historia się nie gromadzi).
|
||||
wymagane do utrwalenia historii i unikania awarii `ENOENT`.
|
||||
- **Niezgodność transcript**: ostrzega, gdy ostatnie wpisy sesji mają brakujące
|
||||
pliki transcript.
|
||||
- **Główna sesja „1-line JSONL”**: oznacza sytuację, gdy główny transcript ma tylko jedną
|
||||
linię (historia się nie kumuluje).
|
||||
- **Wiele katalogów stanu**: ostrzega, gdy istnieje wiele folderów `~/.openclaw` w różnych
|
||||
katalogach domowych lub gdy `OPENCLAW_STATE_DIR` wskazuje inne miejsce (historia może się
|
||||
rozdzielać między instalacjami).
|
||||
- **Przypomnienie o trybie zdalnym**: jeśli `gateway.mode=remote`, doctor przypomina, aby uruchomić
|
||||
go na zdalnym hoście (tam znajduje się stan).
|
||||
katalogach domowych lub gdy `OPENCLAW_STATE_DIR` wskazuje inne miejsce (historia może
|
||||
zostać rozdzielona między instalacje).
|
||||
- **Przypomnienie o trybie zdalnym**: jeśli `gateway.mode=remote`, doctor przypomina o jego uruchomieniu
|
||||
na zdalnym hoście (tam znajduje się stan).
|
||||
- **Uprawnienia pliku konfiguracji**: ostrzega, jeśli `~/.openclaw/openclaw.json` jest
|
||||
czytelny dla grupy/świata i oferuje zaostrzenie do `600`.
|
||||
czytelny dla grupy/świata, i oferuje zaostrzenie do `600`.
|
||||
|
||||
### 5) Kondycja uwierzytelniania modeli (wygaśnięcie OAuth)
|
||||
|
||||
Doctor sprawdza profile OAuth w magazynie uwierzytelniania, ostrzega, gdy tokeny
|
||||
wygasają lub wygasły, i może je odświeżyć, gdy jest to bezpieczne. Jeśli profil
|
||||
OAuth/token Anthropic jest nieaktualny, sugeruje użycie klucza API Anthropic albo
|
||||
ścieżki setup-token Anthropic.
|
||||
OAuth/token Anthropic jest nieaktualny, sugeruje klucz API Anthropic lub
|
||||
ścieżkę setup-token Anthropic.
|
||||
Monity o odświeżenie pojawiają się tylko w trybie interaktywnym (TTY); `--non-interactive`
|
||||
pomija próby odświeżenia.
|
||||
pomija próby odświeżania.
|
||||
|
||||
Doctor raportuje też profile uwierzytelniania, które są tymczasowo nieużywalne z powodu:
|
||||
Gdy odświeżenie OAuth kończy się trwałym niepowodzeniem (na przykład `refresh_token_reused`,
|
||||
`invalid_grant` lub dostawca informuje, że trzeba zalogować się ponownie), doctor zgłasza,
|
||||
że wymagana jest ponowna autoryzacja, i wypisuje dokładną komendę `openclaw models auth login --provider ...`,
|
||||
którą należy uruchomić.
|
||||
|
||||
- krótkich cooldownów (rate limits/timeouts/błędy uwierzytelniania)
|
||||
- dłuższych wyłączeń (problemy z rozliczeniami/kredytem)
|
||||
Doctor raportuje także profile uwierzytelniania, które są tymczasowo nieużywalne z powodu:
|
||||
|
||||
- krótkich cooldownów (limity szybkości/timeouty/błędy uwierzytelniania)
|
||||
- dłuższych wyłączeń (problemy z rozliczeniami/kredytami)
|
||||
|
||||
### 6) Walidacja modelu hooks
|
||||
|
||||
@ -345,36 +381,35 @@ katalogu i listy dozwolonych modeli oraz ostrzega, gdy nie będzie się rozwiąz
|
||||
### 7) Naprawa obrazu sandboxa
|
||||
|
||||
Gdy sandboxing jest włączony, doctor sprawdza obrazy Docker i oferuje ich zbudowanie lub
|
||||
przełączenie na starsze nazwy, jeśli obecny obraz nie istnieje.
|
||||
przełączenie na starsze nazwy, jeśli bieżący obraz jest niedostępny.
|
||||
|
||||
### 7b) Zależności uruchomieniowe bundlowanych pluginów
|
||||
### 7b) Zależności runtime bundlowanych pluginów
|
||||
|
||||
Doctor weryfikuje, czy zależności uruchomieniowe bundlowanych pluginów (na przykład
|
||||
pakiety uruchomieniowe pluginu Discord) są obecne w katalogu głównym instalacji OpenClaw.
|
||||
Jeśli którychś brakuje, doctor raportuje pakiety i instaluje je w trybie
|
||||
`openclaw doctor --fix` / `openclaw doctor --repair`.
|
||||
Doctor weryfikuje, czy zależności runtime bundlowanych pluginów (na przykład
|
||||
pakiety runtime pluginu Discord) są obecne w katalogu głównym instalacji OpenClaw.
|
||||
Jeśli którychkolwiek brakuje, doctor raportuje pakiety i instaluje je w
|
||||
trybie `openclaw doctor --fix` / `openclaw doctor --repair`.
|
||||
|
||||
### 8) Migracje usług gatewaya i wskazówki dotyczące czyszczenia
|
||||
### 8) Migracje usług gateway i wskazówki czyszczenia
|
||||
|
||||
Doctor wykrywa starsze usługi gatewaya (launchd/systemd/schtasks) i
|
||||
oferuje ich usunięcie oraz instalację usługi OpenClaw z użyciem bieżącego portu gatewaya.
|
||||
Może też skanować w poszukiwaniu dodatkowych usług podobnych do gatewaya i wyświetlać wskazówki porządkowe.
|
||||
Usługi gatewaya OpenClaw nazwane według profilu są traktowane jako pełnoprawne i nie są
|
||||
Doctor wykrywa starsze usługi gateway (launchd/systemd/schtasks) i
|
||||
oferuje ich usunięcie oraz instalację usługi OpenClaw z użyciem bieżącego portu gateway.
|
||||
Może też skanować w poszukiwaniu dodatkowych usług podobnych do gateway i wypisywać wskazówki czyszczenia.
|
||||
Usługi gateway OpenClaw nazwane profilem są traktowane jako pełnoprawne i nie są
|
||||
oznaczane jako „dodatkowe”.
|
||||
|
||||
### 8b) Migracja Matrix przy starcie
|
||||
### 8b) Migracja Matrix przy uruchamianiu
|
||||
|
||||
Gdy konto kanału Matrix ma oczekującą lub możliwą do wykonania migrację starszego stanu,
|
||||
doctor (w trybie `--fix` / `--repair`) tworzy snapshot przed migracją, a następnie
|
||||
uruchamia kroki migracji w trybie best-effort: migrację starszego stanu Matrix oraz przygotowanie starszego
|
||||
stanu szyfrowanego. Oba kroki nie są krytyczne; błędy są logowane, a
|
||||
uruchamianie jest kontynuowane. W trybie tylko do odczytu (`openclaw doctor` bez `--fix`) to sprawdzenie
|
||||
jest całkowicie pomijane.
|
||||
uruchamia kroki migracji w trybie best-effort: migrację starszego stanu Matrix i przygotowanie starszego stanu szyfrowanego. Oba kroki nie są krytyczne; błędy są logowane i
|
||||
uruchamianie trwa dalej. W trybie tylko do odczytu (`openclaw doctor` bez `--fix`) ta kontrola
|
||||
jest całkowicie pomijana.
|
||||
|
||||
### 9) Ostrzeżenia bezpieczeństwa
|
||||
|
||||
Doctor emituje ostrzeżenia, gdy dostawca jest otwarty na DM bez listy dozwolonych,
|
||||
albo gdy zasada jest skonfigurowana w niebezpieczny sposób.
|
||||
lub gdy polityka jest skonfigurowana w niebezpieczny sposób.
|
||||
|
||||
### 10) systemd linger (Linux)
|
||||
|
||||
@ -383,80 +418,80 @@ gateway pozostał aktywny po wylogowaniu.
|
||||
|
||||
### 11) Stan workspace (Skills, pluginy i starsze katalogi)
|
||||
|
||||
Doctor wyświetla podsumowanie stanu workspace dla domyślnego agenta:
|
||||
Doctor wypisuje podsumowanie stanu workspace dla domyślnego agenta:
|
||||
|
||||
- **Stan Skills**: liczba skills kwalifikujących się, z brakującymi wymaganiami i zablokowanych przez allowlistę.
|
||||
- **Stan Skills**: liczba Skills kwalifikujących się, z brakującymi wymaganiami i zablokowanych przez allowlist.
|
||||
- **Starsze katalogi workspace**: ostrzega, gdy `~/openclaw` lub inne starsze katalogi workspace
|
||||
istnieją obok bieżącego workspace.
|
||||
- **Stan pluginów**: liczba załadowanych/wyłączonych/pluginów z błędami; wyświetla identyfikatory pluginów dla wszystkich
|
||||
błędów; raportuje możliwości bundlowanych pluginów.
|
||||
- **Ostrzeżenia o zgodności pluginów**: oznacza pluginy, które mają problemy ze zgodnością z
|
||||
bieżącym środowiskiem uruchomieniowym.
|
||||
- **Stan pluginów**: liczby pluginów załadowanych/wyłączonych/z błędami; wypisuje identyfikatory pluginów dla
|
||||
błędów; raportuje możliwości bundle plugin.
|
||||
- **Ostrzeżenia o zgodności pluginów**: oznacza pluginy, które mają problemy zgodności z
|
||||
bieżącym runtime.
|
||||
- **Diagnostyka pluginów**: pokazuje wszelkie ostrzeżenia lub błędy z czasu ładowania emitowane przez
|
||||
rejestr pluginów.
|
||||
|
||||
### 11b) Rozmiar pliku bootstrap
|
||||
|
||||
Doctor sprawdza, czy pliki bootstrap workspace (na przykład `AGENTS.md`,
|
||||
`CLAUDE.md` lub inne wstrzykiwane pliki kontekstowe) są blisko skonfigurowanego
|
||||
limitu znaków lub go przekraczają. Raportuje dla każdego pliku liczbę surowych i wstrzykniętych znaków,
|
||||
procent obcięcia, przyczynę obcięcia (`max/file` lub `max/total`) oraz łączną liczbę wstrzykniętych
|
||||
znaków jako ułamek całkowitego budżetu. Gdy pliki są obcięte lub blisko limitu,
|
||||
doctor wyświetla wskazówki dotyczące dostrojenia `agents.defaults.bootstrapMaxChars`
|
||||
`CLAUDE.md` lub inne wstrzykiwane pliki kontekstowe) są blisko lub powyżej skonfigurowanego
|
||||
budżetu znaków. Raportuje dla każdego pliku liczbę znaków surowych vs. wstrzykniętych, procent
|
||||
obcięcia, przyczynę obcięcia (`max/file` lub `max/total`) oraz łączną liczbę wstrzykniętych
|
||||
znaków jako ułamek całkowitego budżetu. Gdy pliki są obcięte lub blisko limitu, doctor wypisuje wskazówki
|
||||
dotyczące dostrajania `agents.defaults.bootstrapMaxChars`
|
||||
i `agents.defaults.bootstrapTotalMaxChars`.
|
||||
|
||||
### 11c) Autouzupełnianie powłoki
|
||||
### 11c) Shell completion
|
||||
|
||||
Doctor sprawdza, czy autouzupełnianie tabulatorem jest zainstalowane dla bieżącej powłoki
|
||||
Doctor sprawdza, czy autouzupełnianie jest zainstalowane dla bieżącej powłoki
|
||||
(zsh, bash, fish lub PowerShell):
|
||||
|
||||
- Jeśli profil powłoki używa wolnego dynamicznego wzorca autouzupełniania
|
||||
- Jeśli profil powłoki używa wolnego wzorca dynamic completion
|
||||
(`source <(openclaw completion ...)`), doctor aktualizuje go do szybszego
|
||||
wariantu z plikiem cache.
|
||||
- Jeśli autouzupełnianie jest skonfigurowane w profilu, ale brakuje pliku cache,
|
||||
doctor automatycznie odtwarza cache.
|
||||
- Jeśli autouzupełnianie nie jest w ogóle skonfigurowane, doctor proponuje jego instalację
|
||||
(tylko w trybie interaktywnym; pomijane z `--non-interactive`).
|
||||
wariantu z buforowanym plikiem.
|
||||
- Jeśli completion jest skonfigurowane w profilu, ale brakuje pliku cache,
|
||||
doctor automatycznie regeneruje cache.
|
||||
- Jeśli completion w ogóle nie jest skonfigurowane, doctor pyta o instalację
|
||||
(tylko w trybie interaktywnym; pomijane przy `--non-interactive`).
|
||||
|
||||
Uruchom `openclaw completion --write-state`, aby ręcznie odtworzyć cache.
|
||||
Uruchom `openclaw completion --write-state`, aby ręcznie zregenerować cache.
|
||||
|
||||
### 12) Kontrole uwierzytelniania gatewaya (lokalny token)
|
||||
### 12) Kontrole uwierzytelniania gateway (lokalny token)
|
||||
|
||||
Doctor sprawdza gotowość lokalnego uwierzytelniania tokenem gatewaya.
|
||||
Doctor sprawdza gotowość uwierzytelniania lokalnego tokena gateway.
|
||||
|
||||
- Jeśli tryb tokena potrzebuje tokena i nie istnieje żadne źródło tokena, doctor proponuje jego wygenerowanie.
|
||||
- Jeśli tryb tokena wymaga tokena, a nie istnieje jego źródło, doctor oferuje jego wygenerowanie.
|
||||
- Jeśli `gateway.auth.token` jest zarządzany przez SecretRef, ale niedostępny, doctor ostrzega i nie nadpisuje go jawnym tekstem.
|
||||
- `openclaw doctor --generate-gateway-token` wymusza generowanie tylko wtedy, gdy nie skonfigurowano tokena SecretRef.
|
||||
- `openclaw doctor --generate-gateway-token` wymusza generowanie tylko wtedy, gdy nie skonfigurowano SecretRef tokena.
|
||||
|
||||
### 12b) Naprawy świadome SecretRef w trybie tylko do odczytu
|
||||
### 12b) Naprawy tylko do odczytu uwzględniające SecretRef
|
||||
|
||||
Niektóre ścieżki naprawy muszą sprawdzać skonfigurowane poświadczenia bez osłabiania zachowania fail-fast w runtime.
|
||||
Niektóre przepływy naprawcze muszą sprawdzać skonfigurowane credentials bez osłabiania zachowania fail-fast w runtime.
|
||||
|
||||
- `openclaw doctor --fix` używa teraz tego samego modelu podsumowania SecretRef tylko do odczytu co polecenia z rodziny status dla ukierunkowanych napraw konfiguracji.
|
||||
- Przykład: naprawa Telegram `allowFrom` / `groupAllowFrom` `@username` próbuje użyć skonfigurowanych poświadczeń bota, jeśli są dostępne.
|
||||
- Jeśli token bota Telegram jest skonfigurowany przez SecretRef, ale niedostępny w bieżącej ścieżce polecenia, doctor zgłasza, że poświadczenie jest skonfigurowane-ale-niedostępne, i pomija automatyczne rozwiązywanie zamiast kończyć się awarią lub błędnie raportować brak tokena.
|
||||
- `openclaw doctor --fix` używa teraz tego samego modelu podsumowania SecretRef tylko do odczytu, co polecenia z rodziny status, do ukierunkowanych napraw konfiguracji.
|
||||
- Przykład: naprawa `allowFrom` / `groupAllowFrom` Telegram z `@username` próbuje użyć skonfigurowanych credentials bota, gdy są dostępne.
|
||||
- Jeśli token bota Telegram jest skonfigurowany przez SecretRef, ale niedostępny w bieżącej ścieżce polecenia, doctor zgłasza, że credential jest skonfigurowany, ale niedostępny, i pomija automatyczne rozwiązywanie zamiast kończyć się awarią lub błędnie raportować brak tokena.
|
||||
|
||||
### 13) Kontrola stanu gatewaya + restart
|
||||
### 13) Kontrola kondycji gateway + restart
|
||||
|
||||
Doctor uruchamia kontrolę stanu i oferuje restart gatewaya, gdy wygląda on na
|
||||
niezdrowy.
|
||||
Doctor uruchamia kontrolę kondycji i oferuje restart gateway, gdy wygląda
|
||||
na niezdrowy.
|
||||
|
||||
### 13b) Gotowość wyszukiwania pamięci
|
||||
|
||||
Doctor sprawdza, czy skonfigurowany dostawca embeddingów wyszukiwania pamięci jest gotowy
|
||||
Doctor sprawdza, czy skonfigurowany dostawca embeddingów do wyszukiwania pamięci jest gotowy
|
||||
dla domyślnego agenta. Zachowanie zależy od skonfigurowanego backendu i dostawcy:
|
||||
|
||||
- **Backend QMD**: sonduje, czy binarka `qmd` jest dostępna i daje się uruchomić.
|
||||
Jeśli nie, wyświetla wskazówki naprawcze, w tym pakiet npm i opcję ręcznej ścieżki do binarki.
|
||||
- **Jawny dostawca lokalny**: sprawdza istnienie lokalnego pliku modelu lub rozpoznanego
|
||||
- **Backend QMD**: sonduje, czy binarka `qmd` jest dostępna i da się ją uruchomić.
|
||||
Jeśli nie, wypisuje wskazówki naprawy, w tym pakiet npm i opcję ręcznej ścieżki do binarki.
|
||||
- **Jawny dostawca lokalny**: sprawdza obecność lokalnego pliku modelu lub rozpoznawanego
|
||||
zdalnego/pobieralnego URL modelu. Jeśli go brakuje, sugeruje przełączenie na zdalnego dostawcę.
|
||||
- **Jawny dostawca zdalny** (`openai`, `voyage` itd.): weryfikuje, czy klucz API jest
|
||||
obecny w środowisku lub magazynie uwierzytelniania. Jeśli go brakuje, wyświetla praktyczne wskazówki naprawcze.
|
||||
- **Dostawca automatyczny**: najpierw sprawdza dostępność modelu lokalnego, a następnie próbuje każdego zdalnego
|
||||
dostawcę w kolejności automatycznego wyboru.
|
||||
- **Jawny dostawca zdalny** (`openai`, `voyage` itp.): sprawdza, czy klucz API jest
|
||||
obecny w środowisku lub magazynie uwierzytelniania. W razie braku wypisuje konkretne wskazówki naprawy.
|
||||
- **Dostawca auto**: najpierw sprawdza dostępność modelu lokalnego, a następnie próbuje każdego zdalnego
|
||||
dostawcy w kolejności automatycznego wyboru.
|
||||
|
||||
Gdy wynik sondy gatewaya jest dostępny (gateway był zdrowy w momencie
|
||||
sprawdzenia), doctor porównuje go z konfiguracją widoczną z CLI i odnotowuje
|
||||
Gdy wynik sondy gateway jest dostępny (gateway był zdrowy w momencie
|
||||
kontroli), doctor porównuje go z konfiguracją widoczną dla CLI i odnotowuje
|
||||
wszelkie rozbieżności.
|
||||
|
||||
Użyj `openclaw memory status --deep`, aby zweryfikować gotowość embeddingów w runtime.
|
||||
@ -464,51 +499,51 @@ Użyj `openclaw memory status --deep`, aby zweryfikować gotowość embeddingów
|
||||
### 14) Ostrzeżenia o stanie kanałów
|
||||
|
||||
Jeśli gateway jest zdrowy, doctor uruchamia sondę stanu kanałów i zgłasza
|
||||
ostrzeżenia wraz z sugerowanymi poprawkami.
|
||||
ostrzeżenia wraz z proponowanymi poprawkami.
|
||||
|
||||
### 15) Audyt konfiguracji supervisora + naprawa
|
||||
|
||||
Doctor sprawdza zainstalowaną konfigurację supervisora (launchd/systemd/schtasks) pod kątem
|
||||
brakujących lub nieaktualnych ustawień domyślnych (np. zależności systemd od network-online i
|
||||
opóźnienia restartu). Gdy wykryje niezgodność, rekomenduje aktualizację i może
|
||||
przepisać plik usługi/zadanie do bieżących ustawień domyślnych.
|
||||
brakujących lub nieaktualnych wartości domyślnych (np. zależności systemd od network-online oraz
|
||||
opóźnienia restartu). Gdy znajdzie niezgodność, zaleca aktualizację i może
|
||||
przepisać plik usługi/zadanie do bieżących wartości domyślnych.
|
||||
|
||||
Uwagi:
|
||||
|
||||
- `openclaw doctor` pyta przed przepisaniem konfiguracji supervisora.
|
||||
- `openclaw doctor --yes` akceptuje domyślne monity naprawy.
|
||||
- `openclaw doctor --repair` stosuje zalecane poprawki bez pytań.
|
||||
- `openclaw doctor --repair` stosuje zalecane poprawki bez monitów.
|
||||
- `openclaw doctor --repair --force` nadpisuje niestandardowe konfiguracje supervisora.
|
||||
- Jeśli uwierzytelnianie tokenem wymaga tokena, a `gateway.auth.token` jest zarządzany przez SecretRef, doctor podczas instalacji/naprawy usługi waliduje SecretRef, ale nie zapisuje rozwiązanych jawnych wartości tokena do metadanych środowiska usługi supervisora.
|
||||
- Jeśli uwierzytelnianie tokenem wymaga tokena, a skonfigurowany token SecretRef nie jest rozwiązany, doctor blokuje ścieżkę instalacji/naprawy z konkretnymi wskazówkami.
|
||||
- Jeśli skonfigurowano zarówno `gateway.auth.token`, jak i `gateway.auth.password`, a `gateway.auth.mode` nie jest ustawione, doctor blokuje instalację/naprawę, dopóki tryb nie zostanie ustawiony jawnie.
|
||||
- W przypadku jednostek user-systemd w Linux, kontrole dryfu tokena w doctor obejmują teraz zarówno źródła `Environment=`, jak i `EnvironmentFile=` przy porównywaniu metadanych uwierzytelniania usługi.
|
||||
- Jeśli uwierzytelnianie tokenem wymaga tokena, a `gateway.auth.token` jest zarządzany przez SecretRef, doctor przy instalacji/naprawie usługi waliduje SecretRef, ale nie zapisuje rozwiązanych wartości tokena w jawnym tekście w metadanych środowiska usługi supervisora.
|
||||
- Jeśli uwierzytelnianie tokenem wymaga tokena, a skonfigurowany SecretRef tokena nie jest rozwiązany, doctor blokuje ścieżkę instalacji/naprawy i podaje konkretne wskazówki.
|
||||
- Jeśli skonfigurowano zarówno `gateway.auth.token`, jak i `gateway.auth.password`, a `gateway.auth.mode` nie jest ustawione, doctor blokuje instalację/naprawę do czasu jawnego ustawienia trybu.
|
||||
- W przypadku jednostek user-systemd w Linuxie kontrole dryfu tokena w doctor obejmują teraz zarówno źródła `Environment=`, jak i `EnvironmentFile=` przy porównywaniu metadanych uwierzytelniania usługi.
|
||||
- Zawsze możesz wymusić pełne przepisanie przez `openclaw gateway install --force`.
|
||||
|
||||
### 16) Diagnostyka środowiska uruchomieniowego gatewaya + portu
|
||||
### 16) Diagnostyka runtime gateway i portu
|
||||
|
||||
Doctor sprawdza środowisko uruchomieniowe usługi (PID, ostatni status zakończenia) i ostrzega, gdy
|
||||
usługa jest zainstalowana, ale faktycznie nie działa. Sprawdza też kolizje portu
|
||||
gatewaya (domyślnie `18789`) i raportuje prawdopodobne przyczyny (gateway już
|
||||
Doctor sprawdza runtime usługi (PID, ostatni status wyjścia) i ostrzega, gdy
|
||||
usługa jest zainstalowana, ale faktycznie nie działa. Sprawdza też konflikty portu
|
||||
na porcie gateway (domyślnie `18789`) i raportuje prawdopodobne przyczyny (gateway już
|
||||
działa, tunel SSH).
|
||||
|
||||
### 17) Najlepsze praktyki środowiska uruchomieniowego gatewaya
|
||||
### 17) Dobre praktyki runtime gateway
|
||||
|
||||
Doctor ostrzega, gdy usługa gatewaya działa na Bun lub na ścieżce Node zarządzanej przez menedżer wersji
|
||||
(`nvm`, `fnm`, `volta`, `asdf` itd.). Kanały WhatsApp + Telegram wymagają Node,
|
||||
a ścieżki menedżerów wersji mogą przestać działać po aktualizacjach, ponieważ usługa nie
|
||||
Doctor ostrzega, gdy usługa gateway działa na Bun lub na ścieżce Node zarządzanej przez menedżer wersji
|
||||
(`nvm`, `fnm`, `volta`, `asdf` itd.). Kanały WhatsApp i Telegram wymagają Node,
|
||||
a ścieżki menedżera wersji mogą przestać działać po aktualizacjach, ponieważ usługa nie
|
||||
ładuje inicjalizacji powłoki. Doctor oferuje migrację do systemowej instalacji Node, gdy
|
||||
jest dostępna (Homebrew/apt/choco).
|
||||
|
||||
### 18) Zapis konfiguracji + metadane kreatora
|
||||
|
||||
Doctor utrwala wszystkie zmiany konfiguracji i zapisuje metadane kreatora, aby odnotować
|
||||
Doctor zapisuje wszelkie zmiany konfiguracji i oznacza metadane kreatora, aby zarejestrować
|
||||
uruchomienie doctor.
|
||||
|
||||
### 19) Wskazówki dotyczące workspace (kopia zapasowa + system pamięci)
|
||||
### 19) Wskazówki dotyczące workspace (backup + system pamięci)
|
||||
|
||||
Doctor sugeruje system pamięci workspace, jeśli go brakuje, i wyświetla wskazówkę dotyczącą kopii zapasowej,
|
||||
jeśli workspace nie jest już pod kontrolą gita.
|
||||
Doctor sugeruje system pamięci workspace, jeśli go brakuje, i wypisuje wskazówkę dotyczącą backupu,
|
||||
jeśli workspace nie jest już pod kontrolą git.
|
||||
|
||||
Zobacz [/concepts/agent-workspace](/pl/concepts/agent-workspace), aby przeczytać pełny przewodnik po
|
||||
strukturze workspace i kopiach zapasowych w git (zalecane prywatne GitHub lub GitLab).
|
||||
strukturze workspace i backupie git (zalecany prywatny GitHub lub GitLab).
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,579 +0,0 @@
|
||||
---
|
||||
date: 2026-04-05T00:00:00Z
|
||||
status: active
|
||||
title: 'refactor: Stopniowe przekształcenie plugin-sdk w rzeczywisty pakiet workspace'
|
||||
type: refactor
|
||||
x-i18n:
|
||||
generated_at: "2026-04-07T09:47:02Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: ea1ca41846363c506a0db6dbca746e840d7c71ca82bbfc5277af9e2ae7f6b070
|
||||
source_path: plans/2026-04-05-002-refactor-real-plugin-sdk-workspace-plan.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# refactor: Stopniowe przekształcenie plugin-sdk w rzeczywisty pakiet workspace
|
||||
|
||||
## Przegląd
|
||||
|
||||
Ten plan wprowadza rzeczywisty pakiet workspace dla SDK wtyczek w
|
||||
`packages/plugin-sdk` i używa go do objęcia małej pierwszej fali rozszerzeń
|
||||
wymuszanymi przez kompilator granicami pakietów. Celem jest sprawienie, aby
|
||||
niedozwolone importy względne kończyły się błędem przy zwykłym `tsc` dla
|
||||
wybranego zestawu dołączonych rozszerzeń dostawców, bez wymuszania migracji w
|
||||
całym repozytorium ani tworzenia ogromnej powierzchni konfliktów merge.
|
||||
|
||||
Kluczowym ruchem przyrostowym jest przez pewien czas równoległe uruchamianie dwóch trybów:
|
||||
|
||||
| Tryb | Kształt importu | Kto go używa | Wymuszanie |
|
||||
| ----------- | ------------------------ | ------------------------------------- | -------------------------------------------- |
|
||||
| Tryb starszy | `openclaw/plugin-sdk/*` | wszystkie istniejące rozszerzenia nieobjęte migracją | obecne permisywne zachowanie pozostaje |
|
||||
| Tryb opt-in | `@openclaw/plugin-sdk/*` | tylko rozszerzenia z pierwszej fali | lokalny dla pakietu `rootDir` + referencje projektów |
|
||||
|
||||
## Ramy problemu
|
||||
|
||||
Obecne repozytorium eksportuje dużą publiczną powierzchnię SDK wtyczek, ale nie jest to rzeczywisty
|
||||
pakiet workspace. Zamiast tego:
|
||||
|
||||
- główny `tsconfig.json` mapuje `openclaw/plugin-sdk/*` bezpośrednio na
|
||||
`src/plugin-sdk/*.ts`
|
||||
- rozszerzenia, które nie zostały objęte poprzednim eksperymentem, nadal współdzielą
|
||||
to globalne zachowanie aliasów źródła
|
||||
- dodanie `rootDir` działa tylko wtedy, gdy dozwolone importy SDK przestają rozwiązywać się do surowego
|
||||
źródła repozytorium
|
||||
|
||||
To oznacza, że repozytorium może opisywać pożądaną politykę granic, ale TypeScript
|
||||
nie wymusza jej w czysty sposób dla większości rozszerzeń.
|
||||
|
||||
Potrzebujesz ścieżki przyrostowej, która:
|
||||
|
||||
- uczyni `plugin-sdk` rzeczywistym
|
||||
- przeniesie SDK w kierunku pakietu workspace o nazwie `@openclaw/plugin-sdk`
|
||||
- zmieni tylko około 10 rozszerzeń w pierwszym PR
|
||||
- pozostawi resztę drzewa rozszerzeń przy starym schemacie do czasu późniejszego porządkowania
|
||||
- uniknie przepływu pracy `tsconfig.plugin-sdk.dts.json` + deklaracji generowanych po instalacji jako podstawowego mechanizmu dla wdrożenia pierwszej fali
|
||||
|
||||
## Ślad wymagań
|
||||
|
||||
- R1. Utworzyć rzeczywisty pakiet workspace dla SDK wtyczek w `packages/`.
|
||||
- R2. Nazwać nowy pakiet `@openclaw/plugin-sdk`.
|
||||
- R3. Nadać nowemu pakietowi SDK własne `package.json` i `tsconfig.json`.
|
||||
- R4. Zachować działanie starszych importów `openclaw/plugin-sdk/*` dla rozszerzeń nieobjętych migracją
|
||||
w czasie okna migracyjnego.
|
||||
- R5. W pierwszym PR objąć tylko małą pierwszą falę rozszerzeń.
|
||||
- R6. Rozszerzenia z pierwszej fali muszą być fail-closed dla importów względnych, które wychodzą
|
||||
poza katalog główny ich pakietu.
|
||||
- R7. Rozszerzenia z pierwszej fali muszą korzystać z SDK przez zależność pakietu
|
||||
i referencję projektu TS, a nie przez główne aliasy `paths`.
|
||||
- R8. Plan musi unikać obowiązkowego, ogólnorepozytoryjnego kroku generowania po instalacji dla
|
||||
poprawności w edytorze.
|
||||
- R9. Wdrożenie pierwszej fali musi nadawać się do przeglądu i scalenia jako umiarkowany PR,
|
||||
a nie refaktor obejmujący ponad 300 plików w całym repozytorium.
|
||||
|
||||
## Granice zakresu
|
||||
|
||||
- Brak pełnej migracji wszystkich dołączonych rozszerzeń w pierwszym PR.
|
||||
- Brak wymogu usunięcia `src/plugin-sdk` w pierwszym PR.
|
||||
- Brak wymogu natychmiastowego przełączenia każdej głównej ścieżki build/test na użycie nowego pakietu.
|
||||
- Brak próby wymuszenia podkreśleń błędów w VS Code dla każdego rozszerzenia nieobjętego migracją.
|
||||
- Brak szerokiego porządkowania lint dla reszty drzewa rozszerzeń.
|
||||
- Brak dużych zmian zachowania w czasie wykonywania poza rozwiązywaniem importów, własnością pakietów
|
||||
i wymuszaniem granic dla rozszerzeń objętych migracją.
|
||||
|
||||
## Kontekst i badania
|
||||
|
||||
### Istotny kod i wzorce
|
||||
|
||||
- `pnpm-workspace.yaml` już zawiera `packages/*` i `extensions/*`, więc nowy
|
||||
pakiet workspace w `packages/plugin-sdk` pasuje do istniejącego układu
|
||||
repozytorium.
|
||||
- Istniejące pakiety workspace, takie jak `packages/memory-host-sdk/package.json`
|
||||
i `packages/plugin-package-contract/package.json`, już używają lokalnych dla pakietu
|
||||
map `exports` zakorzenionych w `src/*.ts`.
|
||||
- Główny `package.json` obecnie publikuje powierzchnię SDK przez `./plugin-sdk`
|
||||
i eksporty `./plugin-sdk/*` oparte na `dist/plugin-sdk/*.js` oraz
|
||||
`dist/plugin-sdk/*.d.ts`.
|
||||
- `src/plugin-sdk/entrypoints.ts` i `scripts/lib/plugin-sdk-entrypoints.json`
|
||||
już działają jako kanoniczny spis punktów wejścia dla powierzchni SDK.
|
||||
- Główny `tsconfig.json` obecnie mapuje:
|
||||
- `openclaw/plugin-sdk` -> `src/plugin-sdk/index.ts`
|
||||
- `openclaw/plugin-sdk/*` -> `src/plugin-sdk/*.ts`
|
||||
- Poprzedni eksperyment z granicami pokazał, że lokalny dla pakietu `rootDir` działa w przypadku
|
||||
niedozwolonych importów względnych dopiero wtedy, gdy dozwolone importy SDK przestają rozwiązywać się do surowego
|
||||
źródła spoza pakietu rozszerzenia.
|
||||
|
||||
### Zestaw rozszerzeń pierwszej fali
|
||||
|
||||
Ten plan zakłada, że pierwszą falą jest zestaw cięższych od strony dostawców, który z najmniejszym prawdopodobieństwem
|
||||
wciągnie złożone przypadki brzegowe związane z runtime kanałów:
|
||||
|
||||
- `extensions/anthropic`
|
||||
- `extensions/exa`
|
||||
- `extensions/firecrawl`
|
||||
- `extensions/groq`
|
||||
- `extensions/mistral`
|
||||
- `extensions/openai`
|
||||
- `extensions/perplexity`
|
||||
- `extensions/tavily`
|
||||
- `extensions/together`
|
||||
- `extensions/xai`
|
||||
|
||||
### Spis powierzchni SDK dla pierwszej fali
|
||||
|
||||
Rozszerzenia z pierwszej fali obecnie importują możliwy do opanowania podzbiór ścieżek podrzędnych SDK.
|
||||
Początkowy pakiet `@openclaw/plugin-sdk` musi pokrywać tylko te:
|
||||
|
||||
- `agent-runtime`
|
||||
- `cli-runtime`
|
||||
- `config-runtime`
|
||||
- `core`
|
||||
- `image-generation`
|
||||
- `media-runtime`
|
||||
- `media-understanding`
|
||||
- `plugin-entry`
|
||||
- `plugin-runtime`
|
||||
- `provider-auth`
|
||||
- `provider-auth-api-key`
|
||||
- `provider-auth-login`
|
||||
- `provider-auth-runtime`
|
||||
- `provider-catalog-shared`
|
||||
- `provider-entry`
|
||||
- `provider-http`
|
||||
- `provider-model-shared`
|
||||
- `provider-onboard`
|
||||
- `provider-stream-family`
|
||||
- `provider-stream-shared`
|
||||
- `provider-tools`
|
||||
- `provider-usage`
|
||||
- `provider-web-fetch`
|
||||
- `provider-web-search`
|
||||
- `realtime-transcription`
|
||||
- `realtime-voice`
|
||||
- `runtime-env`
|
||||
- `secret-input`
|
||||
- `security-runtime`
|
||||
- `speech`
|
||||
- `testing`
|
||||
|
||||
### Wnioski instytucjonalne
|
||||
|
||||
- W tym drzewie roboczym nie było istotnych wpisów `docs/solutions/`.
|
||||
|
||||
### Referencje zewnętrzne
|
||||
|
||||
- Do tego planu nie były potrzebne badania zewnętrzne. Repozytorium już zawiera
|
||||
odpowiednie wzorce pakietów workspace i eksportów SDK.
|
||||
|
||||
## Kluczowe decyzje techniczne
|
||||
|
||||
- Wprowadzić `@openclaw/plugin-sdk` jako nowy pakiet workspace przy jednoczesnym zachowaniu
|
||||
starszej powierzchni głównej `openclaw/plugin-sdk/*` podczas migracji.
|
||||
Uzasadnienie: pozwala to przenieść zestaw rozszerzeń z pierwszej fali na rzeczywiste
|
||||
rozwiązywanie pakietów bez wymuszania jednoczesnych zmian we wszystkich rozszerzeniach i wszystkich głównych ścieżkach budowania.
|
||||
|
||||
- Użyć dedykowanej bazowej konfiguracji granic opt-in, takiej jak
|
||||
`extensions/tsconfig.package-boundary.base.json`, zamiast zastępować
|
||||
istniejącą bazę rozszerzeń dla wszystkich.
|
||||
Uzasadnienie: repozytorium musi jednocześnie wspierać starszy i opt-in tryb rozszerzeń podczas migracji.
|
||||
|
||||
- Użyć referencji projektów TS z rozszerzeń pierwszej fali do
|
||||
`packages/plugin-sdk/tsconfig.json` i ustawić
|
||||
`disableSourceOfProjectReferenceRedirect` dla trybu granic opt-in.
|
||||
Uzasadnienie: daje to `tsc` rzeczywisty graf pakietów, jednocześnie zniechęcając edytor i kompilator
|
||||
do przechodzenia z powrotem do surowego źródła.
|
||||
|
||||
- Zachować `@openclaw/plugin-sdk` jako prywatny w pierwszej fali.
|
||||
Uzasadnienie: bezpośrednim celem jest wewnętrzne wymuszanie granic i bezpieczeństwo migracji,
|
||||
a nie publikowanie drugiego zewnętrznego kontraktu SDK, zanim powierzchnia stanie się stabilna.
|
||||
|
||||
- Przenieść w pierwszym wycinku implementacji tylko ścieżki podrzędne SDK z pierwszej fali i
|
||||
zachować mosty zgodności dla reszty.
|
||||
Uzasadnienie: fizyczne przeniesienie wszystkich 315 plików `src/plugin-sdk/*.ts` w jednym PR to
|
||||
dokładnie ta powierzchnia konfliktów merge, której ten plan próbuje uniknąć.
|
||||
|
||||
- Nie polegać na `scripts/postinstall-bundled-plugins.mjs` przy budowaniu deklaracji SDK
|
||||
dla pierwszej fali.
|
||||
Uzasadnienie: jawne przepływy build/reference są łatwiejsze do zrozumienia i sprawiają, że zachowanie repozytorium jest bardziej przewidywalne.
|
||||
|
||||
## Otwarte pytania
|
||||
|
||||
### Rozstrzygnięte podczas planowania
|
||||
|
||||
- Które rozszerzenia powinny wejść do pierwszej fali?
|
||||
Użyć wymienionych wyżej 10 rozszerzeń dostawców/wyszukiwania w sieci, ponieważ są
|
||||
strukturalnie bardziej odizolowane niż cięższe pakiety kanałów.
|
||||
|
||||
- Czy pierwszy PR powinien zastąpić całe drzewo rozszerzeń?
|
||||
Nie. Pierwszy PR powinien wspierać dwa tryby równolegle i objąć migracją tylko
|
||||
pierwszą falę.
|
||||
|
||||
- Czy pierwsza fala powinna wymagać budowania deklaracji po instalacji?
|
||||
Nie. Graf pakietów/referencji powinien być jawny, a CI powinno celowo uruchamiać
|
||||
odpowiednie lokalne dla pakietu sprawdzanie typów.
|
||||
|
||||
### Odłożone do implementacji
|
||||
|
||||
- Czy pakiet pierwszej fali może wskazywać bezpośrednio na lokalne dla pakietu `src/*.ts`
|
||||
wyłącznie przez referencje projektów, czy też nadal potrzebny jest mały krok emisji deklaracji
|
||||
dla pakietu `@openclaw/plugin-sdk`.
|
||||
To należące do implementacji pytanie dotyczące walidacji grafu TS.
|
||||
|
||||
- Czy główny pakiet `openclaw` powinien natychmiast pośredniczyć w ścieżkach podrzędnych SDK pierwszej fali do
|
||||
wyników `packages/plugin-sdk`, czy nadal używać generowanych
|
||||
shimów zgodności w `src/plugin-sdk`.
|
||||
To szczegół zgodności i kształtu builda zależny od minimalnej
|
||||
ścieżki implementacji, która utrzyma zielony stan CI.
|
||||
|
||||
## Projekt techniczny wysokiego poziomu
|
||||
|
||||
> To ilustruje zamierzone podejście i stanowi wskazówki kierunkowe do przeglądu, a nie specyfikację implementacji. Agent implementujący powinien traktować to jako kontekst, a nie kod do odtworzenia.
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
subgraph Legacy["Starsze rozszerzenia (bez zmian)"]
|
||||
L1["extensions/*\nopenclaw/plugin-sdk/*"]
|
||||
L2["główne ścieżki tsconfig"]
|
||||
L1 --> L2
|
||||
L2 --> L3["src/plugin-sdk/*"]
|
||||
end
|
||||
|
||||
subgraph OptIn["Rozszerzenia pierwszej fali"]
|
||||
O1["10 rozszerzeń objętych migracją"]
|
||||
O2["extensions/tsconfig.package-boundary.base.json"]
|
||||
O3["rootDir = '.'\nreferencja projektu"]
|
||||
O4["@openclaw/plugin-sdk"]
|
||||
O1 --> O2
|
||||
O2 --> O3
|
||||
O3 --> O4
|
||||
end
|
||||
|
||||
subgraph SDK["Nowy pakiet workspace"]
|
||||
P1["packages/plugin-sdk/package.json"]
|
||||
P2["packages/plugin-sdk/tsconfig.json"]
|
||||
P3["packages/plugin-sdk/src/<first-wave-subpaths>.ts"]
|
||||
P1 --> P2
|
||||
P2 --> P3
|
||||
end
|
||||
|
||||
O4 --> SDK
|
||||
```
|
||||
|
||||
## Jednostki implementacyjne
|
||||
|
||||
- [ ] **Jednostka 1: Wprowadzenie rzeczywistego pakietu workspace `@openclaw/plugin-sdk`**
|
||||
|
||||
**Cel:** Utworzyć rzeczywisty pakiet workspace dla SDK, który może być właścicielem
|
||||
powierzchni ścieżek podrzędnych pierwszej fali bez wymuszania migracji całego repozytorium.
|
||||
|
||||
**Wymagania:** R1, R2, R3, R8, R9
|
||||
|
||||
**Zależności:** Brak
|
||||
|
||||
**Pliki:**
|
||||
|
||||
- Utwórz: `packages/plugin-sdk/package.json`
|
||||
- Utwórz: `packages/plugin-sdk/tsconfig.json`
|
||||
- Utwórz: `packages/plugin-sdk/src/index.ts`
|
||||
- Utwórz: `packages/plugin-sdk/src/*.ts` dla ścieżek podrzędnych SDK z pierwszej fali
|
||||
- Zmodyfikuj: `pnpm-workspace.yaml` tylko jeśli potrzebne są korekty globów pakietów
|
||||
- Zmodyfikuj: `package.json`
|
||||
- Zmodyfikuj: `src/plugin-sdk/entrypoints.ts`
|
||||
- Zmodyfikuj: `scripts/lib/plugin-sdk-entrypoints.json`
|
||||
- Test: `src/plugins/contracts/plugin-sdk-workspace-package.contract.test.ts`
|
||||
|
||||
**Podejście:**
|
||||
|
||||
- Dodaj nowy pakiet workspace o nazwie `@openclaw/plugin-sdk`.
|
||||
- Zacznij tylko od ścieżek podrzędnych SDK z pierwszej fali, a nie od całego drzewa 315 plików.
|
||||
- Jeśli bezpośrednie przeniesienie punktu wejścia z pierwszej fali stworzyłoby zbyt duży diff,
|
||||
pierwszy PR może najpierw wprowadzić tę ścieżkę podrzędną w `packages/plugin-sdk/src` jako cienki
|
||||
wrapper pakietu, a następnie przełączyć źródło prawdy na pakiet w kolejnym PR dla tego klastra ścieżek podrzędnych.
|
||||
- Użyj ponownie istniejącej mechaniki spisu punktów wejścia, aby powierzchnia pakietu pierwszej fali
|
||||
była zadeklarowana w jednym kanonicznym miejscu.
|
||||
- Zachowaj eksporty głównego pakietu dla starszych użytkowników, podczas gdy pakiet workspace
|
||||
stanie się nowym kontraktem opt-in.
|
||||
|
||||
**Wzorce do naśladowania:**
|
||||
|
||||
- `packages/memory-host-sdk/package.json`
|
||||
- `packages/plugin-package-contract/package.json`
|
||||
- `src/plugin-sdk/entrypoints.ts`
|
||||
|
||||
**Scenariusze testowe:**
|
||||
|
||||
- Ścieżka szczęśliwa: pakiet workspace eksportuje każdą ścieżkę podrzędną pierwszej fali wymienioną
|
||||
w planie i nie brakuje żadnego wymaganego eksportu pierwszej fali.
|
||||
- Przypadek brzegowy: metadane eksportu pakietu pozostają stabilne, gdy lista wpisów pierwszej fali
|
||||
jest ponownie generowana lub porównywana z kanonicznym spisem.
|
||||
- Integracja: starsze eksporty SDK głównego pakietu pozostają obecne po wprowadzeniu nowego
|
||||
pakietu workspace.
|
||||
|
||||
**Weryfikacja:**
|
||||
|
||||
- Repozytorium zawiera prawidłowy pakiet workspace `@openclaw/plugin-sdk` z
|
||||
stabilną mapą eksportów pierwszej fali i bez regresji starszych eksportów w głównym
|
||||
`package.json`.
|
||||
|
||||
- [ ] **Jednostka 2: Dodanie trybu granic TS opt-in dla rozszerzeń z wymuszaniem pakietowym**
|
||||
|
||||
**Cel:** Zdefiniować tryb konfiguracji TS, którego będą używać rozszerzenia objęte migracją,
|
||||
przy pozostawieniu istniejącego zachowania TS dla rozszerzeń bez zmian dla wszystkich pozostałych.
|
||||
|
||||
**Wymagania:** R4, R6, R7, R8, R9
|
||||
|
||||
**Zależności:** Jednostka 1
|
||||
|
||||
**Pliki:**
|
||||
|
||||
- Utwórz: `extensions/tsconfig.package-boundary.base.json`
|
||||
- Utwórz: `tsconfig.boundary-optin.json`
|
||||
- Zmodyfikuj: `extensions/xai/tsconfig.json`
|
||||
- Zmodyfikuj: `extensions/openai/tsconfig.json`
|
||||
- Zmodyfikuj: `extensions/anthropic/tsconfig.json`
|
||||
- Zmodyfikuj: `extensions/mistral/tsconfig.json`
|
||||
- Zmodyfikuj: `extensions/groq/tsconfig.json`
|
||||
- Zmodyfikuj: `extensions/together/tsconfig.json`
|
||||
- Zmodyfikuj: `extensions/perplexity/tsconfig.json`
|
||||
- Zmodyfikuj: `extensions/tavily/tsconfig.json`
|
||||
- Zmodyfikuj: `extensions/exa/tsconfig.json`
|
||||
- Zmodyfikuj: `extensions/firecrawl/tsconfig.json`
|
||||
- Test: `src/plugins/contracts/extension-package-project-boundaries.test.ts`
|
||||
- Test: `test/extension-package-tsc-boundary.test.ts`
|
||||
|
||||
**Podejście:**
|
||||
|
||||
- Pozostaw `extensions/tsconfig.base.json` dla starszych rozszerzeń.
|
||||
- Dodaj nową bazową konfigurację opt-in, która:
|
||||
- ustawia `rootDir: "."`
|
||||
- referuje `packages/plugin-sdk`
|
||||
- włącza `composite`
|
||||
- wyłącza przekierowanie źródła referencji projektu, gdy to potrzebne
|
||||
- Dodaj dedykowaną konfigurację rozwiązania dla grafu sprawdzania typów pierwszej fali zamiast
|
||||
przebudowywania głównego projektu TS repozytorium w tym samym PR.
|
||||
|
||||
**Uwaga wykonawcza:** Zacznij od nieprzechodzącego lokalnego dla pakietu kontrolnego sprawdzania typów dla jednego
|
||||
rozszerzenia objętego migracją, zanim zastosujesz wzorzec do wszystkich 10.
|
||||
|
||||
**Wzorce do naśladowania:**
|
||||
|
||||
- Istniejący wzorzec lokalnego dla pakietu `tsconfig.json` dla rozszerzeń z wcześniejszych
|
||||
prac nad granicami
|
||||
- Wzorzec pakietu workspace z `packages/memory-host-sdk`
|
||||
|
||||
**Scenariusze testowe:**
|
||||
|
||||
- Ścieżka szczęśliwa: każde rozszerzenie objęte migracją pomyślnie przechodzi sprawdzanie typów przez
|
||||
konfigurację TS granic pakietu.
|
||||
- Ścieżka błędu: kontrolny import względny z `../../src/cli/acp-cli.ts` kończy się
|
||||
`TS6059` dla rozszerzenia objętego migracją.
|
||||
- Integracja: rozszerzenia nieobjęte migracją pozostają nietknięte i nie muszą
|
||||
uczestniczyć w nowej konfiguracji rozwiązania.
|
||||
|
||||
**Weryfikacja:**
|
||||
|
||||
- Istnieje dedykowany graf sprawdzania typów dla 10 rozszerzeń objętych migracją i błędne
|
||||
importy względne z jednego z nich kończą się błędem przez zwykłe `tsc`.
|
||||
|
||||
- [ ] **Jednostka 3: Migracja rozszerzeń pierwszej fali do `@openclaw/plugin-sdk`**
|
||||
|
||||
**Cel:** Przestawić rozszerzenia pierwszej fali na korzystanie z rzeczywistego pakietu SDK
|
||||
przez metadane zależności, referencje projektów i importy po nazwie pakietu.
|
||||
|
||||
**Wymagania:** R5, R6, R7, R9
|
||||
|
||||
**Zależności:** Jednostka 2
|
||||
|
||||
**Pliki:**
|
||||
|
||||
- Zmodyfikuj: `extensions/anthropic/package.json`
|
||||
- Zmodyfikuj: `extensions/exa/package.json`
|
||||
- Zmodyfikuj: `extensions/firecrawl/package.json`
|
||||
- Zmodyfikuj: `extensions/groq/package.json`
|
||||
- Zmodyfikuj: `extensions/mistral/package.json`
|
||||
- Zmodyfikuj: `extensions/openai/package.json`
|
||||
- Zmodyfikuj: `extensions/perplexity/package.json`
|
||||
- Zmodyfikuj: `extensions/tavily/package.json`
|
||||
- Zmodyfikuj: `extensions/together/package.json`
|
||||
- Zmodyfikuj: `extensions/xai/package.json`
|
||||
- Zmodyfikuj: importy produkcyjne i testowe w każdym z 10 katalogów głównych rozszerzeń, które
|
||||
obecnie odwołują się do `openclaw/plugin-sdk/*`
|
||||
|
||||
**Podejście:**
|
||||
|
||||
- Dodaj `@openclaw/plugin-sdk: workspace:*` do `devDependencies` rozszerzeń
|
||||
z pierwszej fali.
|
||||
- Zamień w tych pakietach importy `openclaw/plugin-sdk/*` na
|
||||
`@openclaw/plugin-sdk/*`.
|
||||
- Zachowaj lokalne importy wewnętrzne rozszerzeń przy lokalnych barrelach, takich jak `./api.ts` i
|
||||
`./runtime-api.ts`.
|
||||
- Nie zmieniaj rozszerzeń nieobjętych migracją w tym PR.
|
||||
|
||||
**Wzorce do naśladowania:**
|
||||
|
||||
- Istniejące lokalne barrele importów rozszerzeń (`api.ts`, `runtime-api.ts`)
|
||||
- Kształt zależności pakietów używany przez inne pakiety workspace `@openclaw/*`
|
||||
|
||||
**Scenariusze testowe:**
|
||||
|
||||
- Ścieżka szczęśliwa: każde zmigrowane rozszerzenie nadal rejestruje się/ładuje przez swoje istniejące
|
||||
testy wtyczek po przepisaniu importów.
|
||||
- Przypadek brzegowy: importy SDK tylko testowe w zestawie rozszerzeń objętych migracją nadal rozwiązują się
|
||||
poprawnie przez nowy pakiet.
|
||||
- Integracja: zmigrowane rozszerzenia nie wymagają głównych aliasów `openclaw/plugin-sdk/*`
|
||||
do sprawdzania typów.
|
||||
|
||||
**Weryfikacja:**
|
||||
|
||||
- Rozszerzenia z pierwszej fali budują się i testują względem `@openclaw/plugin-sdk`
|
||||
bez potrzeby używania starszej ścieżki aliasu głównego SDK.
|
||||
|
||||
- [ ] **Jednostka 4: Zachowanie starszej zgodności podczas częściowej migracji**
|
||||
|
||||
**Cel:** Utrzymać działanie reszty repozytorium, gdy SDK istnieje równocześnie w postaci starszej
|
||||
i nowego pakietu podczas migracji.
|
||||
|
||||
**Wymagania:** R4, R8, R9
|
||||
|
||||
**Zależności:** Jednostki 1-3
|
||||
|
||||
**Pliki:**
|
||||
|
||||
- Zmodyfikuj: `src/plugin-sdk/*.ts` pod kątem shimów zgodności pierwszej fali w razie potrzeby
|
||||
- Zmodyfikuj: `package.json`
|
||||
- Zmodyfikuj: elementy builda lub eksportu składające artefakty SDK
|
||||
- Test: `src/plugins/contracts/plugin-sdk-runtime-api-guardrails.test.ts`
|
||||
- Test: `src/plugins/contracts/plugin-sdk-index.bundle.test.ts`
|
||||
|
||||
**Podejście:**
|
||||
|
||||
- Zachowaj główne `openclaw/plugin-sdk/*` jako powierzchnię zgodności dla starszych
|
||||
rozszerzeń i dla zewnętrznych użytkowników, którzy jeszcze nie przechodzą migracji.
|
||||
- Użyj albo generowanych shimów, albo pośredniczącego routingu eksportów głównych dla
|
||||
ścieżek podrzędnych pierwszej fali, które zostały przeniesione do `packages/plugin-sdk`.
|
||||
- Nie próbuj wycofywać głównej powierzchni SDK na tym etapie.
|
||||
|
||||
**Wzorce do naśladowania:**
|
||||
|
||||
- Istniejące generowanie eksportów głównego SDK przez `src/plugin-sdk/entrypoints.ts`
|
||||
- Istniejąca zgodność eksportów pakietu w głównym `package.json`
|
||||
|
||||
**Scenariusze testowe:**
|
||||
|
||||
- Ścieżka szczęśliwa: starszy import głównego SDK nadal rozwiązuje się dla rozszerzenia
|
||||
nieobjętego migracją po wprowadzeniu nowego pakietu.
|
||||
- Przypadek brzegowy: ścieżka podrzędna pierwszej fali działa zarówno przez starszą powierzchnię główną, jak i
|
||||
przez nową powierzchnię pakietu podczas okna migracyjnego.
|
||||
- Integracja: testy kontraktowe indeksu/bundle plugin-sdk nadal widzą spójną
|
||||
publiczną powierzchnię.
|
||||
|
||||
**Weryfikacja:**
|
||||
|
||||
- Repozytorium wspiera zarówno starszy, jak i opt-in tryb korzystania z SDK bez
|
||||
psucia niezmienionych rozszerzeń.
|
||||
|
||||
- [ ] **Jednostka 5: Dodanie ograniczonego wymuszania i udokumentowanie kontraktu migracji**
|
||||
|
||||
**Cel:** Wdrożyć w CI i wskazówkach dla współtwórców nowe zachowanie dla
|
||||
pierwszej fali, bez udawania, że całe drzewo rozszerzeń zostało zmigrowane.
|
||||
|
||||
**Wymagania:** R5, R6, R8, R9
|
||||
|
||||
**Zależności:** Jednostki 1-4
|
||||
|
||||
**Pliki:**
|
||||
|
||||
- Zmodyfikuj: `package.json`
|
||||
- Zmodyfikuj: pliki workflow CI, które powinny uruchamiać sprawdzanie typów granic opt-in
|
||||
- Zmodyfikuj: `AGENTS.md`
|
||||
- Zmodyfikuj: `docs/plugins/sdk-overview.md`
|
||||
- Zmodyfikuj: `docs/plugins/sdk-entrypoints.md`
|
||||
- Zmodyfikuj: `docs/plans/2026-04-05-001-refactor-extension-package-resolution-boundary-plan.md`
|
||||
|
||||
**Podejście:**
|
||||
|
||||
- Dodaj jawny gate pierwszej fali, taki jak dedykowane uruchomienie `tsc -b` dla rozwiązania
|
||||
`packages/plugin-sdk` plus 10 rozszerzeń objętych migracją.
|
||||
- Udokumentuj, że repozytorium wspiera teraz zarówno starszy, jak i opt-in tryb rozszerzeń,
|
||||
oraz że nowe prace nad granicami rozszerzeń powinny preferować nową ścieżkę pakietową.
|
||||
- Zapisz regułę migracji kolejnych fal, aby późniejsze PR-y mogły dodawać więcej rozszerzeń
|
||||
bez ponownego rozstrzygania kwestii architektury.
|
||||
|
||||
**Wzorce do naśladowania:**
|
||||
|
||||
- Istniejące testy kontraktowe w `src/plugins/contracts/`
|
||||
- Istniejące aktualizacje dokumentacji wyjaśniające etapowe migracje
|
||||
|
||||
**Scenariusze testowe:**
|
||||
|
||||
- Ścieżka szczęśliwa: nowy gate sprawdzania typów dla pierwszej fali przechodzi dla pakietu workspace
|
||||
i rozszerzeń objętych migracją.
|
||||
- Ścieżka błędu: wprowadzenie nowego niedozwolonego importu względnego w rozszerzeniu objętym migracją
|
||||
powoduje błąd w ograniczonym gate sprawdzania typów.
|
||||
- Integracja: CI nie wymaga jeszcze od rozszerzeń nieobjętych migracją spełniania nowego
|
||||
trybu granic pakietu.
|
||||
|
||||
**Weryfikacja:**
|
||||
|
||||
- Ścieżka wymuszania dla pierwszej fali jest udokumentowana, przetestowana i możliwa do uruchomienia bez
|
||||
wymuszania migracji całego drzewa rozszerzeń.
|
||||
|
||||
## Wpływ na cały system
|
||||
|
||||
- **Graf interakcji:** ta praca dotyka źródła prawdy SDK, eksportów głównego pakietu,
|
||||
metadanych pakietów rozszerzeń, układu grafu TS i weryfikacji CI.
|
||||
- **Propagacja błędów:** głównym zamierzonym trybem błędu stają się błędy TS czasu kompilacji
|
||||
(`TS6059`) w rozszerzeniach objętych migracją zamiast niestandardowych błędów tylko skryptowych.
|
||||
- **Ryzyka cyklu życia stanu:** migracja z dwiema powierzchniami wprowadza ryzyko dryfu między
|
||||
eksportami zgodności w głównym pakiecie a nowym pakietem workspace.
|
||||
- **Parzystość powierzchni API:** ścieżki podrzędne pierwszej fali muszą pozostać semantycznie identyczne
|
||||
zarówno przez `openclaw/plugin-sdk/*`, jak i `@openclaw/plugin-sdk/*` podczas
|
||||
przejścia.
|
||||
- **Pokrycie integracyjne:** testy jednostkowe nie wystarczą; potrzebne są ograniczone
|
||||
sprawdzania typów grafu pakietów, aby udowodnić granicę.
|
||||
- **Niezmienione niezmienniki:** rozszerzenia nieobjęte migracją zachowują swoje obecne zachowanie
|
||||
w PR 1. Ten plan nie twierdzi, że zapewnia wymuszanie granic importu w całym repozytorium.
|
||||
|
||||
## Ryzyka i zależności
|
||||
|
||||
| Ryzyko | Ograniczenie |
|
||||
| -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Pakiet pierwszej fali nadal rozwiązuje się z powrotem do surowego źródła i `rootDir` faktycznie nie działa fail-closed | Uczyń pierwszym krokiem implementacji kontrolę referencji pakietu na jednym rozszerzeniu objętym migracją przed rozszerzeniem na cały zestaw |
|
||||
| Przeniesienie zbyt dużej części źródła SDK naraz odtwarza pierwotny problem konfliktów merge | Przenieś tylko ścieżki podrzędne pierwszej fali w pierwszym PR i zachowaj mosty zgodności głównego pakietu |
|
||||
| Starsza i nowa powierzchnia SDK dryfują semantycznie | Zachowaj jeden spis punktów wejścia, dodaj testy kontraktu zgodności i jawnie wymagaj parzystości dwóch powierzchni |
|
||||
| Główne ścieżki build/test repozytorium przypadkowo zaczynają zależeć od nowego pakietu w niekontrolowany sposób | Użyj dedykowanej konfiguracji rozwiązania opt-in i nie wprowadzaj zmian w ogólnym grafie TS repozytorium w pierwszym PR |
|
||||
|
||||
## Dostarczanie etapowe
|
||||
|
||||
### Faza 1
|
||||
|
||||
- Wprowadzić `@openclaw/plugin-sdk`
|
||||
- Zdefiniować powierzchnię ścieżek podrzędnych pierwszej fali
|
||||
- Udowodnić, że jedno rozszerzenie objęte migracją może działać fail-closed przez `rootDir`
|
||||
|
||||
### Faza 2
|
||||
|
||||
- Objąć migracją 10 rozszerzeń z pierwszej fali
|
||||
- Zachować główną zgodność dla wszystkich pozostałych
|
||||
|
||||
### Faza 3
|
||||
|
||||
- Dodawać kolejne rozszerzenia w późniejszych PR-ach
|
||||
- Przenosić więcej ścieżek podrzędnych SDK do pakietu workspace
|
||||
- Wycofać główną zgodność dopiero po zniknięciu zestawu starszych rozszerzeń
|
||||
|
||||
## Uwagi dokumentacyjne / operacyjne
|
||||
|
||||
- Pierwszy PR powinien wyraźnie opisywać siebie jako migrację w dwóch trybach, a nie
|
||||
jako ukończenie wymuszania w całym repozytorium.
|
||||
- Przewodnik migracji powinien ułatwiać późniejszym PR-om dodawanie kolejnych rozszerzeń
|
||||
według tego samego wzorca pakiet/zależność/referencja.
|
||||
|
||||
## Źródła i referencje
|
||||
|
||||
- Poprzedni plan: `docs/plans/2026-04-05-001-refactor-extension-package-resolution-boundary-plan.md`
|
||||
- Konfiguracja workspace: `pnpm-workspace.yaml`
|
||||
- Istniejący spis punktów wejścia SDK: `src/plugin-sdk/entrypoints.ts`
|
||||
- Istniejące eksporty głównego SDK: `package.json`
|
||||
- Istniejące wzorce pakietów workspace:
|
||||
- `packages/memory-host-sdk/package.json`
|
||||
- `packages/plugin-package-contract/package.json`
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,75 +1,75 @@
|
||||
---
|
||||
read_when:
|
||||
- Tworzysz plugin OpenClaw
|
||||
- Musisz dostarczyć schemat konfiguracji pluginu lub debugujesz błędy walidacji pluginu
|
||||
- Musisz dostarczyć schemat konfiguracji pluginu lub debugować błędy walidacji pluginu
|
||||
summary: Manifest pluginu + wymagania schematu JSON (ścisła walidacja konfiguracji)
|
||||
title: Manifest pluginu
|
||||
x-i18n:
|
||||
generated_at: "2026-04-07T09:47:43Z"
|
||||
generated_at: "2026-04-09T01:29:09Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 22d41b9f8748b1b1b066ee856be4a8f41e88b9a8bc073d74fc79d2bb0982f01a
|
||||
source_hash: 9a7ee4b621a801d2a8f32f8976b0e1d9433c7810eb360aca466031fc0ffb286a
|
||||
source_path: plugins/manifest.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Manifest pluginu (`openclaw.plugin.json`)
|
||||
# Manifest pluginu (openclaw.plugin.json)
|
||||
|
||||
Ta strona dotyczy wyłącznie **natywnego manifestu pluginu OpenClaw**.
|
||||
|
||||
Informacje o zgodnych układach bundle znajdziesz w [Plugin bundles](/pl/plugins/bundles).
|
||||
Informacje o zgodnych układach bundli znajdziesz w [Bundlach pluginów](/pl/plugins/bundles).
|
||||
|
||||
Zgodne formaty bundle używają innych plików manifestu:
|
||||
Zgodne formaty bundli używają innych plików manifestu:
|
||||
|
||||
- Bundle Codex: `.codex-plugin/plugin.json`
|
||||
- Bundle Claude: `.claude-plugin/plugin.json` lub domyślny układ komponentu Claude
|
||||
- Bundel Codex: `.codex-plugin/plugin.json`
|
||||
- Bundel Claude: `.claude-plugin/plugin.json` lub domyślny układ komponentu Claude
|
||||
bez manifestu
|
||||
- Bundle Cursor: `.cursor-plugin/plugin.json`
|
||||
- Bundel Cursor: `.cursor-plugin/plugin.json`
|
||||
|
||||
OpenClaw automatycznie wykrywa także te układy bundle, ale nie są one walidowane
|
||||
OpenClaw automatycznie wykrywa również te układy bundli, ale nie są one walidowane
|
||||
względem schematu `openclaw.plugin.json` opisanego tutaj.
|
||||
|
||||
W przypadku zgodnych bundle OpenClaw obecnie odczytuje metadane bundle oraz zadeklarowane
|
||||
korzenie Skills, korzenie poleceń Claude, domyślne wartości `settings.json` bundle Claude,
|
||||
domyślne wartości LSP bundle Claude oraz obsługiwane pakiety hooków, gdy układ jest zgodny
|
||||
z oczekiwaniami runtime OpenClaw.
|
||||
Dla zgodnych bundli OpenClaw obecnie odczytuje metadane bundla oraz zadeklarowane
|
||||
korzenie skillów, korzenie poleceń Claude, domyślne wartości `settings.json` bundla Claude,
|
||||
domyślne wartości LSP bundla Claude oraz obsługiwane zestawy hooków, gdy układ odpowiada
|
||||
oczekiwaniom środowiska uruchomieniowego OpenClaw.
|
||||
|
||||
Każdy natywny plugin OpenClaw **musi** dostarczać plik `openclaw.plugin.json` w
|
||||
**katalogu głównym pluginu**. OpenClaw używa tego manifestu do walidacji konfiguracji
|
||||
**bez wykonywania kodu pluginu**. Brakujące lub nieprawidłowe manifesty są traktowane jako
|
||||
błędy pluginu i blokują walidację konfiguracji.
|
||||
|
||||
Zobacz pełny przewodnik po systemie pluginów: [Plugins](/pl/tools/plugin).
|
||||
Aby poznać natywny model możliwości i bieżące wskazówki dotyczące zgodności zewnętrznej:
|
||||
[Capability model](/pl/plugins/architecture#public-capability-model).
|
||||
Pełny przewodnik po systemie pluginów znajdziesz tutaj: [Pluginy](/pl/tools/plugin).
|
||||
Informacje o natywnym modelu możliwości i aktualnych wskazówkach dotyczących zgodności zewnętrznej:
|
||||
[Model możliwości](/pl/plugins/architecture#public-capability-model).
|
||||
|
||||
## Do czego służy ten plik
|
||||
|
||||
`openclaw.plugin.json` to metadane, które OpenClaw odczytuje, zanim załaduje kod
|
||||
Twojego pluginu.
|
||||
`openclaw.plugin.json` to metadane, które OpenClaw odczytuje przed załadowaniem
|
||||
kodu Twojego pluginu.
|
||||
|
||||
Używaj go do:
|
||||
|
||||
- tożsamości pluginu
|
||||
- walidacji konfiguracji
|
||||
- metadanych uwierzytelniania i onboardingu, które powinny być dostępne bez uruchamiania
|
||||
runtime pluginu
|
||||
- metadanych aliasów i automatycznego włączania, które powinny być rozstrzygane przed załadowaniem runtime pluginu
|
||||
- metadanych auth i onboardingu, które powinny być dostępne bez uruchamiania
|
||||
środowiska uruchomieniowego pluginu
|
||||
- metadanych aliasów i automatycznego włączania, które powinny być rozstrzygane przed załadowaniem środowiska uruchomieniowego pluginu
|
||||
- skróconych metadanych własności rodzin modeli, które powinny automatycznie aktywować
|
||||
plugin przed załadowaniem runtime
|
||||
- statycznych migawek własności możliwości używanych do bundlowanego okablowania zgodności i
|
||||
plugin przed załadowaniem środowiska uruchomieniowego
|
||||
- statycznych migawek własności możliwości używanych do zgodnego okablowania bundli i
|
||||
pokrycia kontraktów
|
||||
- metadanych konfiguracji specyficznych dla kanału, które powinny być scalane z powierzchniami katalogu i walidacji
|
||||
bez ładowania runtime
|
||||
- wskazówek dla UI konfiguracji
|
||||
bez ładowania środowiska uruchomieniowego
|
||||
- wskazówek UI konfiguracji
|
||||
|
||||
Nie używaj go do:
|
||||
|
||||
- rejestrowania zachowania runtime
|
||||
- deklarowania entrypointów kodu
|
||||
- rejestrowania zachowań środowiska uruchomieniowego
|
||||
- deklarowania punktów wejścia kodu
|
||||
- metadanych instalacji npm
|
||||
|
||||
Te elementy należą do kodu pluginu i `package.json`.
|
||||
To należy do kodu pluginu i `package.json`.
|
||||
|
||||
## Minimalny przykład
|
||||
|
||||
@ -90,7 +90,7 @@ Te elementy należą do kodu pluginu i `package.json`.
|
||||
{
|
||||
"id": "openrouter",
|
||||
"name": "OpenRouter",
|
||||
"description": "OpenRouter provider plugin",
|
||||
"description": "Plugin dostawcy OpenRouter",
|
||||
"version": "1.0.0",
|
||||
"providers": ["openrouter"],
|
||||
"modelSupport": {
|
||||
@ -100,6 +100,9 @@ Te elementy należą do kodu pluginu i `package.json`.
|
||||
"providerAuthEnvVars": {
|
||||
"openrouter": ["OPENROUTER_API_KEY"]
|
||||
},
|
||||
"providerAuthAliases": {
|
||||
"openrouter-coding": "openrouter"
|
||||
},
|
||||
"channelEnvVars": {
|
||||
"openrouter-chatops": ["OPENROUTER_CHATOPS_TOKEN"]
|
||||
},
|
||||
@ -108,19 +111,19 @@ Te elementy należą do kodu pluginu i `package.json`.
|
||||
"provider": "openrouter",
|
||||
"method": "api-key",
|
||||
"choiceId": "openrouter-api-key",
|
||||
"choiceLabel": "OpenRouter API key",
|
||||
"choiceLabel": "Klucz API OpenRouter",
|
||||
"groupId": "openrouter",
|
||||
"groupLabel": "OpenRouter",
|
||||
"optionKey": "openrouterApiKey",
|
||||
"cliFlag": "--openrouter-api-key",
|
||||
"cliOption": "--openrouter-api-key <key>",
|
||||
"cliDescription": "OpenRouter API key",
|
||||
"cliDescription": "Klucz API OpenRouter",
|
||||
"onboardingScopes": ["text-inference"]
|
||||
}
|
||||
],
|
||||
"uiHints": {
|
||||
"apiKey": {
|
||||
"label": "API key",
|
||||
"label": "Klucz API",
|
||||
"placeholder": "sk-or-v1-...",
|
||||
"sensitive": true
|
||||
}
|
||||
@ -137,65 +140,66 @@ Te elementy należą do kodu pluginu i `package.json`.
|
||||
}
|
||||
```
|
||||
|
||||
## Opis pól najwyższego poziomu
|
||||
## Dokumentacja pól najwyższego poziomu
|
||||
|
||||
| Pole | Wymagane | Typ | Znaczenie |
|
||||
| Field | Required | Type | What it means |
|
||||
| ----------------------------------- | -------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `id` | Tak | `string` | Kanoniczny identyfikator pluginu. To identyfikator używany w `plugins.entries.<id>`. |
|
||||
| `configSchema` | Tak | `object` | Wbudowany schemat JSON Schema dla konfiguracji tego pluginu. |
|
||||
| `enabledByDefault` | Nie | `true` | Oznacza bundlowany plugin jako domyślnie włączony. Pomiń to pole lub ustaw dowolną wartość inną niż `true`, aby pozostawić plugin domyślnie wyłączony. |
|
||||
| `id` | Tak | `string` | Kanoniczny identyfikator pluginu. To identyfikator używany w `plugins.entries.<id>`. |
|
||||
| `configSchema` | Tak | `object` | Wbudowany schemat JSON dla konfiguracji tego pluginu. |
|
||||
| `enabledByDefault` | Nie | `true` | Oznacza bundlowany plugin jako domyślnie włączony. Pomiń to pole albo ustaw dowolną wartość inną niż `true`, aby pozostawić plugin domyślnie wyłączony. |
|
||||
| `legacyPluginIds` | Nie | `string[]` | Starsze identyfikatory normalizowane do tego kanonicznego identyfikatora pluginu. |
|
||||
| `autoEnableWhenConfiguredProviders` | Nie | `string[]` | Identyfikatory dostawców, które powinny automatycznie włączać ten plugin, gdy uwierzytelnianie, konfiguracja lub odwołania do modeli o nich wspominają. |
|
||||
| `kind` | Nie | `"memory"` \| `"context-engine"` | Deklaruje wyłączny rodzaj pluginu używany przez `plugins.slots.*`. |
|
||||
| `autoEnableWhenConfiguredProviders` | Nie | `string[]` | Identyfikatory dostawców, które powinny automatycznie włączać ten plugin, gdy auth, konfiguracja lub odwołania do modeli o nich wspominają. |
|
||||
| `kind` | Nie | `"memory"` \| `"context-engine"` | Deklaruje wyłączny rodzaj pluginu używany przez `plugins.slots.*`. |
|
||||
| `channels` | Nie | `string[]` | Identyfikatory kanałów należących do tego pluginu. Używane do wykrywania i walidacji konfiguracji. |
|
||||
| `providers` | Nie | `string[]` | Identyfikatory dostawców należących do tego pluginu. |
|
||||
| `modelSupport` | Nie | `object` | Należące do manifestu skrócone metadane rodzin modeli używane do automatycznego ładowania pluginu przed runtime. |
|
||||
| `cliBackends` | Nie | `string[]` | Identyfikatory backendów inferencji CLI należących do tego pluginu. Używane do automatycznej aktywacji przy starcie na podstawie jawnych odwołań w konfiguracji. |
|
||||
| `providerAuthEnvVars` | Nie | `Record<string, string[]>` | Lekkie metadane środowiskowe uwierzytelniania dostawcy, które OpenClaw może sprawdzić bez ładowania kodu pluginu. |
|
||||
| `channelEnvVars` | Nie | `Record<string, string[]>` | Lekkie metadane środowiskowe kanału, które OpenClaw może sprawdzić bez ładowania kodu pluginu. Używaj ich dla konfiguracji kanałów sterowanych przez env lub powierzchni uwierzytelniania, które powinny być widoczne dla ogólnych helperów startu/konfiguracji. |
|
||||
| `providerAuthChoices` | Nie | `object[]` | Lekkie metadane opcji uwierzytelniania dla selektorów onboardingu, rozstrzygania preferowanego dostawcy i prostego okablowania flag CLI. |
|
||||
| `contracts` | Nie | `object` | Statyczna migawka bundlowanych możliwości dla mowy, transkrypcji realtime, głosu realtime, rozumienia mediów, generowania obrazów, generowania muzyki, generowania wideo, web-fetch, web search i własności narzędzi. |
|
||||
| `channelConfigs` | Nie | `Record<string, object>` | Należące do manifestu metadane konfiguracji kanału scalane z powierzchniami wykrywania i walidacji przed załadowaniem runtime. |
|
||||
| `skills` | Nie | `string[]` | Katalogi Skills do załadowania, względne względem katalogu głównego pluginu. |
|
||||
| `modelSupport` | Nie | `object` | Należące do manifestu skrócone metadane rodzin modeli używane do automatycznego ładowania pluginu przed środowiskiem uruchomieniowym. |
|
||||
| `cliBackends` | Nie | `string[]` | Identyfikatory backendów inferencji CLI należących do tego pluginu. Używane do automatycznej aktywacji przy uruchomieniu na podstawie jawnych odwołań w konfiguracji. |
|
||||
| `providerAuthEnvVars` | Nie | `Record<string, string[]>` | Tanie metadane env dla auth dostawcy, które OpenClaw może sprawdzać bez ładowania kodu pluginu. |
|
||||
| `providerAuthAliases` | Nie | `Record<string, string>` | Identyfikatory dostawców, które powinny ponownie używać innego identyfikatora dostawcy do wyszukiwania auth, na przykład dostawca do kodowania współdzielący bazowy klucz API dostawcy i profile auth. |
|
||||
| `channelEnvVars` | Nie | `Record<string, string[]>` | Tanie metadane env kanału, które OpenClaw może sprawdzać bez ładowania kodu pluginu. Używaj tego dla konfiguracji kanału opartej na env lub powierzchni auth, które powinny być widoczne dla ogólnych pomocników uruchamiania/konfiguracji. |
|
||||
| `providerAuthChoices` | Nie | `object[]` | Tanie metadane wyboru auth dla selektorów onboardingu, rozstrzygania preferowanych dostawców i prostego mapowania flag CLI. |
|
||||
| `contracts` | Nie | `object` | Statyczna migawka możliwości bundli dla mowy, transkrypcji czasu rzeczywistego, głosu czasu rzeczywistego, rozumienia mediów, generowania obrazów, generowania muzyki, generowania wideo, web-fetch, wyszukiwania w sieci i własności narzędzi. |
|
||||
| `channelConfigs` | Nie | `Record<string, object>` | Należące do manifestu metadane konfiguracji kanałów scalane z powierzchniami wykrywania i walidacji przed załadowaniem środowiska uruchomieniowego. |
|
||||
| `skills` | Nie | `string[]` | Katalogi Skills do załadowania, względem katalogu głównego pluginu. |
|
||||
| `name` | Nie | `string` | Czytelna dla człowieka nazwa pluginu. |
|
||||
| `description` | Nie | `string` | Krótkie podsumowanie pokazywane na powierzchniach pluginu. |
|
||||
| `description` | Nie | `string` | Krótkie podsumowanie wyświetlane na powierzchniach pluginu. |
|
||||
| `version` | Nie | `string` | Informacyjna wersja pluginu. |
|
||||
| `uiHints` | Nie | `Record<string, object>` | Etykiety UI, placeholdery i wskazówki dotyczące wrażliwości pól konfiguracji. |
|
||||
| `uiHints` | Nie | `Record<string, object>` | Etykiety UI, placeholdery i wskazówki dotyczące wrażliwości dla pól konfiguracji. |
|
||||
|
||||
## Opis `providerAuthChoices`
|
||||
## Dokumentacja `providerAuthChoices`
|
||||
|
||||
Każdy wpis `providerAuthChoices` opisuje jedną opcję onboardingu lub uwierzytelniania.
|
||||
OpenClaw odczytuje to przed załadowaniem runtime dostawcy.
|
||||
Każdy wpis `providerAuthChoices` opisuje jeden wybór onboardingu lub auth.
|
||||
OpenClaw odczytuje to przed załadowaniem środowiska uruchomieniowego dostawcy.
|
||||
|
||||
| Pole | Wymagane | Typ | Znaczenie |
|
||||
| --------------------- | -------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
|
||||
| `provider` | Tak | `string` | Identyfikator dostawcy, do którego należy ta opcja. |
|
||||
| `method` | Tak | `string` | Identyfikator metody uwierzytelniania, do której należy przekazać sterowanie. |
|
||||
| `choiceId` | Tak | `string` | Stabilny identyfikator opcji uwierzytelniania używany przez onboarding i przepływy CLI. |
|
||||
| `choiceLabel` | Nie | `string` | Etykieta widoczna dla użytkownika. Jeśli zostanie pominięta, OpenClaw użyje `choiceId`. |
|
||||
| `choiceHint` | Nie | `string` | Krótki tekst pomocniczy dla selektora. |
|
||||
| `assistantPriority` | Nie | `number` | Niższe wartości są sortowane wcześniej w interaktywnych selektorach sterowanych przez asystenta. |
|
||||
| `assistantVisibility` | Nie | `"visible"` \| `"manual-only"` | Ukrywa opcję w selektorach asystenta, nadal pozwalając na ręczny wybór w CLI. |
|
||||
| `deprecatedChoiceIds` | Nie | `string[]` | Starsze identyfikatory opcji, które powinny przekierowywać użytkowników do tej opcji zastępczej. |
|
||||
| `groupId` | Nie | `string` | Opcjonalny identyfikator grupy do grupowania powiązanych opcji. |
|
||||
| `groupLabel` | Nie | `string` | Etykieta widoczna dla użytkownika dla tej grupy. |
|
||||
| `groupHint` | Nie | `string` | Krótki tekst pomocniczy dla grupy. |
|
||||
| `optionKey` | Nie | `string` | Wewnętrzny klucz opcji dla prostych przepływów uwierzytelniania z jedną flagą. |
|
||||
| `cliFlag` | Nie | `string` | Nazwa flagi CLI, na przykład `--openrouter-api-key`. |
|
||||
| `cliOption` | Nie | `string` | Pełny kształt opcji CLI, na przykład `--openrouter-api-key <key>`. |
|
||||
| `cliDescription` | Nie | `string` | Opis używany w pomocy CLI. |
|
||||
| `onboardingScopes` | Nie | `Array<"text-inference" \| "image-generation">` | Na których powierzchniach onboardingu ta opcja powinna się pojawiać. Jeśli pole zostanie pominięte, domyślnie używane jest `["text-inference"]`. |
|
||||
| Field | Required | Type | What it means |
|
||||
| --------------------- | -------- | ----------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
|
||||
| `provider` | Tak | `string` | Identyfikator dostawcy, do którego należy ten wybór. |
|
||||
| `method` | Tak | `string` | Identyfikator metody auth, do której należy przekierować. |
|
||||
| `choiceId` | Tak | `string` | Stabilny identyfikator wyboru auth używany przez onboarding i przepływy CLI. |
|
||||
| `choiceLabel` | Nie | `string` | Etykieta widoczna dla użytkownika. Jeśli zostanie pominięta, OpenClaw użyje `choiceId`. |
|
||||
| `choiceHint` | Nie | `string` | Krótki tekst pomocniczy dla selektora. |
|
||||
| `assistantPriority` | Nie | `number` | Niższe wartości są sortowane wcześniej w interaktywnych selektorach sterowanych przez asystenta. |
|
||||
| `assistantVisibility` | Nie | `"visible"` \| `"manual-only"` | Ukrywa wybór w selektorach asystenta, nadal pozwalając na ręczny wybór w CLI. |
|
||||
| `deprecatedChoiceIds` | Nie | `string[]` | Starsze identyfikatory wyborów, które powinny przekierowywać użytkowników do tego wyboru zastępczego. |
|
||||
| `groupId` | Nie | `string` | Opcjonalny identyfikator grupy do grupowania powiązanych wyborów. |
|
||||
| `groupLabel` | Nie | `string` | Etykieta tej grupy widoczna dla użytkownika. |
|
||||
| `groupHint` | Nie | `string` | Krótki tekst pomocniczy dla grupy. |
|
||||
| `optionKey` | Nie | `string` | Wewnętrzny klucz opcji dla prostych przepływów auth opartych na jednej fladze. |
|
||||
| `cliFlag` | Nie | `string` | Nazwa flagi CLI, np. `--openrouter-api-key`. |
|
||||
| `cliOption` | Nie | `string` | Pełny kształt opcji CLI, np. `--openrouter-api-key <key>`. |
|
||||
| `cliDescription` | Nie | `string` | Opis używany w pomocy CLI. |
|
||||
| `onboardingScopes` | Nie | `Array<"text-inference" \| "image-generation">` | Na których powierzchniach onboardingu ten wybór powinien się pojawiać. Jeśli pole zostanie pominięte, domyślnie używane jest `["text-inference"]`. |
|
||||
|
||||
## Opis `uiHints`
|
||||
## Dokumentacja `uiHints`
|
||||
|
||||
`uiHints` to mapa z nazw pól konfiguracji na małe wskazówki renderowania.
|
||||
`uiHints` to mapa od nazw pól konfiguracji do małych wskazówek renderowania.
|
||||
|
||||
```json
|
||||
{
|
||||
"uiHints": {
|
||||
"apiKey": {
|
||||
"label": "API key",
|
||||
"help": "Used for OpenRouter requests",
|
||||
"label": "Klucz API",
|
||||
"help": "Używany do żądań OpenRouter",
|
||||
"placeholder": "sk-or-v1-...",
|
||||
"sensitive": true
|
||||
}
|
||||
@ -203,9 +207,9 @@ OpenClaw odczytuje to przed załadowaniem runtime dostawcy.
|
||||
}
|
||||
```
|
||||
|
||||
Każda wskazówka dla pola może zawierać:
|
||||
Wskazówka dla każdego pola może zawierać:
|
||||
|
||||
| Pole | Typ | Znaczenie |
|
||||
| Field | Type | What it means |
|
||||
| ------------- | ---------- | --------------------------------------- |
|
||||
| `label` | `string` | Etykieta pola widoczna dla użytkownika. |
|
||||
| `help` | `string` | Krótki tekst pomocniczy. |
|
||||
@ -214,10 +218,10 @@ Każda wskazówka dla pola może zawierać:
|
||||
| `sensitive` | `boolean` | Oznacza pole jako sekretne lub wrażliwe. |
|
||||
| `placeholder` | `string` | Tekst placeholdera dla pól formularza. |
|
||||
|
||||
## Opis `contracts`
|
||||
## Dokumentacja `contracts`
|
||||
|
||||
Używaj `contracts` tylko do statycznych metadanych własności możliwości, które OpenClaw może
|
||||
odczytać bez importowania runtime pluginu.
|
||||
Używaj `contracts` tylko dla statycznych metadanych własności możliwości, które OpenClaw może
|
||||
odczytać bez importowania środowiska uruchomieniowego pluginu.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -237,22 +241,22 @@ odczytać bez importowania runtime pluginu.
|
||||
|
||||
Każda lista jest opcjonalna:
|
||||
|
||||
| Pole | Typ | Znaczenie |
|
||||
| -------------------------------- | ---------- | ---------------------------------------------------------- |
|
||||
| `speechProviders` | `string[]` | Identyfikatory dostawców mowy należące do tego pluginu. |
|
||||
| `realtimeTranscriptionProviders` | `string[]` | Identyfikatory dostawców transkrypcji realtime należące do tego pluginu. |
|
||||
| `realtimeVoiceProviders` | `string[]` | Identyfikatory dostawców głosu realtime należące do tego pluginu. |
|
||||
| `mediaUnderstandingProviders` | `string[]` | Identyfikatory dostawców rozumienia mediów należące do tego pluginu. |
|
||||
| `imageGenerationProviders` | `string[]` | Identyfikatory dostawców generowania obrazów należące do tego pluginu. |
|
||||
| `videoGenerationProviders` | `string[]` | Identyfikatory dostawców generowania wideo należące do tego pluginu. |
|
||||
| `webFetchProviders` | `string[]` | Identyfikatory dostawców web-fetch należące do tego pluginu. |
|
||||
| `webSearchProviders` | `string[]` | Identyfikatory dostawców web search należące do tego pluginu. |
|
||||
| `tools` | `string[]` | Nazwy narzędzi agenta należących do tego pluginu dla bundlowanych kontroli kontraktów. |
|
||||
| Field | Type | What it means |
|
||||
| -------------------------------- | ---------- | -------------------------------------------------------------- |
|
||||
| `speechProviders` | `string[]` | Identyfikatory dostawców mowy należących do tego pluginu. |
|
||||
| `realtimeTranscriptionProviders` | `string[]` | Identyfikatory dostawców transkrypcji czasu rzeczywistego należących do tego pluginu. |
|
||||
| `realtimeVoiceProviders` | `string[]` | Identyfikatory dostawców głosu czasu rzeczywistego należących do tego pluginu. |
|
||||
| `mediaUnderstandingProviders` | `string[]` | Identyfikatory dostawców rozumienia mediów należących do tego pluginu. |
|
||||
| `imageGenerationProviders` | `string[]` | Identyfikatory dostawców generowania obrazów należących do tego pluginu. |
|
||||
| `videoGenerationProviders` | `string[]` | Identyfikatory dostawców generowania wideo należących do tego pluginu. |
|
||||
| `webFetchProviders` | `string[]` | Identyfikatory dostawców web-fetch należących do tego pluginu. |
|
||||
| `webSearchProviders` | `string[]` | Identyfikatory dostawców wyszukiwania w sieci należących do tego pluginu. |
|
||||
| `tools` | `string[]` | Nazwy narzędzi agenta należących do tego pluginu do sprawdzania kontraktów bundli. |
|
||||
|
||||
## Opis `channelConfigs`
|
||||
## Dokumentacja `channelConfigs`
|
||||
|
||||
Używaj `channelConfigs`, gdy plugin kanału potrzebuje lekkich metadanych konfiguracji przed
|
||||
załadowaniem runtime.
|
||||
Używaj `channelConfigs`, gdy plugin kanału potrzebuje tanich metadanych konfiguracji przed
|
||||
załadowaniem środowiska uruchomieniowego.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -267,12 +271,12 @@ załadowaniem runtime.
|
||||
},
|
||||
"uiHints": {
|
||||
"homeserverUrl": {
|
||||
"label": "Homeserver URL",
|
||||
"label": "URL homeservera",
|
||||
"placeholder": "https://matrix.example.com"
|
||||
}
|
||||
},
|
||||
"label": "Matrix",
|
||||
"description": "Matrix homeserver connection",
|
||||
"description": "Połączenie z homeserverem Matrix",
|
||||
"preferOver": ["matrix-legacy"]
|
||||
}
|
||||
}
|
||||
@ -281,18 +285,18 @@ załadowaniem runtime.
|
||||
|
||||
Każdy wpis kanału może zawierać:
|
||||
|
||||
| Pole | Typ | Znaczenie |
|
||||
| ------------- | ------------------------ | ------------------------------------------------------------------------------------------ |
|
||||
| `schema` | `object` | JSON Schema dla `channels.<id>`. Wymagane dla każdego zadeklarowanego wpisu konfiguracji kanału. |
|
||||
| `uiHints` | `Record<string, object>` | Opcjonalne etykiety UI/placeholdery/wskazówki wrażliwości dla tej sekcji konfiguracji kanału. |
|
||||
| `label` | `string` | Etykieta kanału scalana z powierzchniami selektora i inspekcji, gdy metadane runtime nie są gotowe. |
|
||||
| `description` | `string` | Krótki opis kanału dla powierzchni inspekcji i katalogu. |
|
||||
| `preferOver` | `string[]` | Starsze lub mniej priorytetowe identyfikatory pluginów, które ten kanał powinien wyprzedzać na powierzchniach wyboru. |
|
||||
| Field | Type | What it means |
|
||||
| ------------- | ------------------------ | ----------------------------------------------------------------------------------------- |
|
||||
| `schema` | `object` | Schemat JSON dla `channels.<id>`. Wymagany dla każdego zadeklarowanego wpisu konfiguracji kanału. |
|
||||
| `uiHints` | `Record<string, object>` | Opcjonalne etykiety UI/placeholdery/wskazówki dotyczące wrażliwości dla tej sekcji konfiguracji kanału. |
|
||||
| `label` | `string` | Etykieta kanału scalana z powierzchniami selektora i inspekcji, gdy metadane środowiska uruchomieniowego nie są gotowe. |
|
||||
| `description` | `string` | Krótki opis kanału dla powierzchni inspekcji i katalogu. |
|
||||
| `preferOver` | `string[]` | Starsze lub niższe priorytetowo identyfikatory pluginów, które ten kanał powinien wyprzedzać na powierzchniach wyboru. |
|
||||
|
||||
## Opis `modelSupport`
|
||||
## Dokumentacja `modelSupport`
|
||||
|
||||
Używaj `modelSupport`, gdy OpenClaw ma wywnioskować plugin dostawcy na podstawie
|
||||
skróconych identyfikatorów modeli, takich jak `gpt-5.4` lub `claude-sonnet-4.6`, zanim załaduje się runtime pluginu.
|
||||
Używaj `modelSupport`, gdy OpenClaw powinien wywnioskować plugin Twojego dostawcy na podstawie
|
||||
skrótowych identyfikatorów modeli, takich jak `gpt-5.4` lub `claude-sonnet-4.6`, przed załadowaniem środowiska uruchomieniowego pluginu.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -305,73 +309,73 @@ skróconych identyfikatorów modeli, takich jak `gpt-5.4` lub `claude-sonnet-4.6
|
||||
|
||||
OpenClaw stosuje następujący priorytet:
|
||||
|
||||
- jawne odwołania `provider/model` używają metadanych `providers` należących do manifestu właściciela
|
||||
- jawne odwołania `provider/model` używają należących do manifestu metadanych `providers`
|
||||
- `modelPatterns` mają pierwszeństwo przed `modelPrefixes`
|
||||
- jeśli pasują jednocześnie jeden plugin zewnętrzny i jeden bundlowany, wygrywa
|
||||
plugin zewnętrzny
|
||||
- pozostała niejednoznaczność jest ignorowana, dopóki użytkownik lub konfiguracja nie wskażą dostawcy
|
||||
- jeśli jeden plugin niebundlowany i jeden plugin bundlowany pasują jednocześnie, wygrywa plugin niebundlowany
|
||||
- pozostała niejednoznaczność jest ignorowana, dopóki użytkownik lub konfiguracja nie określi dostawcy
|
||||
|
||||
Pola:
|
||||
|
||||
| Pole | Typ | Znaczenie |
|
||||
| --------------- | ---------- | ---------------------------------------------------------------------------- |
|
||||
| `modelPrefixes` | `string[]` | Prefiksy dopasowywane przez `startsWith` do skróconych identyfikatorów modeli. |
|
||||
| `modelPatterns` | `string[]` | Źródła wyrażeń regularnych dopasowywane do skróconych identyfikatorów modeli po usunięciu sufiksu profilu. |
|
||||
| Field | Type | What it means |
|
||||
| --------------- | ---------- | ------------------------------------------------------------------------------- |
|
||||
| `modelPrefixes` | `string[]` | Prefiksy dopasowywane przez `startsWith` do skrótowych identyfikatorów modeli. |
|
||||
| `modelPatterns` | `string[]` | Źródła regex dopasowywane do skrótowych identyfikatorów modeli po usunięciu sufiksu profilu. |
|
||||
|
||||
Starsze klucze możliwości na najwyższym poziomie są przestarzałe. Użyj `openclaw doctor --fix`, aby
|
||||
przenieść `speechProviders`, `realtimeTranscriptionProviders`,
|
||||
`realtimeVoiceProviders`, `mediaUnderstandingProviders`,
|
||||
`imageGenerationProviders`, `videoGenerationProviders`,
|
||||
`webFetchProviders` i `webSearchProviders` do `contracts`; zwykłe
|
||||
`webFetchProviders` i `webSearchProviders` do `contracts`; standardowe
|
||||
ładowanie manifestu nie traktuje już tych pól najwyższego poziomu jako
|
||||
własności możliwości.
|
||||
|
||||
## Manifest a package.json
|
||||
|
||||
Te dwa pliki służą do różnych zadań:
|
||||
Te dwa pliki pełnią różne role:
|
||||
|
||||
| Plik | Zastosowanie |
|
||||
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `openclaw.plugin.json` | Wykrywanie, walidacja konfiguracji, metadane opcji uwierzytelniania i wskazówki UI, które muszą istnieć przed uruchomieniem kodu pluginu |
|
||||
| `package.json` | Metadane npm, instalacja zależności i blok `openclaw` używany dla entrypointów, kontroli instalacji, konfiguracji lub metadanych katalogu |
|
||||
| File | Use it for |
|
||||
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `openclaw.plugin.json` | Wykrywanie, walidacja konfiguracji, metadane wyboru auth i wskazówki UI, które muszą istnieć przed uruchomieniem kodu pluginu |
|
||||
| `package.json` | Metadane npm, instalacja zależności i blok `openclaw` używany dla punktów wejścia, bramkowania instalacji, konfiguracji lub metadanych katalogu |
|
||||
|
||||
Jeśli nie masz pewności, gdzie powinien trafić dany element metadanych, kieruj się tą zasadą:
|
||||
Jeśli nie masz pewności, gdzie powinien trafić dany element metadanych, użyj tej zasady:
|
||||
|
||||
- jeśli OpenClaw musi wiedzieć o nim przed załadowaniem kodu pluginu, umieść go w `openclaw.plugin.json`
|
||||
- jeśli dotyczy pakowania, plików wejściowych lub zachowania instalacji npm, umieść go w `package.json`
|
||||
- jeśli OpenClaw musi znać tę informację przed załadowaniem kodu pluginu, umieść ją w `openclaw.plugin.json`
|
||||
- jeśli dotyczy pakowania, plików wejściowych lub zachowania instalacji npm, umieść ją w `package.json`
|
||||
|
||||
### Pola `package.json`, które wpływają na wykrywanie
|
||||
### Pola package.json wpływające na wykrywanie
|
||||
|
||||
Część metadanych pluginu sprzed uruchomienia runtime celowo znajduje się w `package.json` w bloku
|
||||
Niektóre metadane pluginu sprzed uruchomienia celowo znajdują się w `package.json` w bloku
|
||||
`openclaw`, a nie w `openclaw.plugin.json`.
|
||||
|
||||
Ważne przykłady:
|
||||
|
||||
| Pole | Znaczenie |
|
||||
| Field | What it means |
|
||||
| ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `openclaw.extensions` | Deklaruje natywne entrypointy pluginów. |
|
||||
| `openclaw.setupEntry` | Lekki entrypoint tylko do konfiguracji używany podczas onboardingu i odroczonego uruchamiania kanału. |
|
||||
| `openclaw.channel` | Lekkie metadane katalogu kanału, takie jak etykiety, ścieżki dokumentacji, aliasy i tekst wyboru. |
|
||||
| `openclaw.channel.configuredState` | Lekkie metadane sprawdzania stanu konfiguracji, które mogą odpowiedzieć na pytanie „czy konfiguracja tylko z env już istnieje?” bez ładowania pełnego runtime kanału. |
|
||||
| `openclaw.channel.persistedAuthState` | Lekkie metadane sprawdzania zapisanego stanu auth, które mogą odpowiedzieć na pytanie „czy cokolwiek jest już zalogowane?” bez ładowania pełnego runtime kanału. |
|
||||
| `openclaw.install.npmSpec` / `openclaw.install.localPath` | Wskazówki instalacji/aktualizacji dla bundlowanych i zewnętrznie publikowanych pluginów. |
|
||||
| `openclaw.install.defaultChoice` | Preferowana ścieżka instalacji, gdy dostępnych jest wiele źródeł instalacji. |
|
||||
| `openclaw.install.minHostVersion` | Minimalna obsługiwana wersja hosta OpenClaw, z dolną granicą semver, taką jak `>=2026.3.22`. |
|
||||
| `openclaw.install.allowInvalidConfigRecovery` | Umożliwia wąską ścieżkę odzyskiwania przez ponowną instalację bundlowanego pluginu, gdy konfiguracja jest nieprawidłowa. |
|
||||
| `openclaw.startup.deferConfiguredChannelFullLoadUntilAfterListen` | Umożliwia ładowanie powierzchni kanału tylko do konfiguracji przed pełnym pluginem kanału podczas startu. |
|
||||
| `openclaw.extensions` | Deklaruje punkty wejścia natywnych pluginów. |
|
||||
| `openclaw.setupEntry` | Lekki punkt wejścia tylko do konfiguracji używany podczas onboardingu i odroczonego uruchamiania kanału. |
|
||||
| `openclaw.channel` | Tanie metadane katalogu kanałów, takie jak etykiety, ścieżki dokumentacji, aliasy i teksty wyboru. |
|
||||
| `openclaw.channel.configuredState` | Lekkie metadane sprawdzania stanu konfiguracji, które mogą odpowiedzieć na pytanie „czy konfiguracja oparta tylko na env już istnieje?” bez ładowania pełnego środowiska uruchomieniowego kanału. |
|
||||
| `openclaw.channel.persistedAuthState` | Lekkie metadane sprawdzania utrwalonego stanu auth, które mogą odpowiedzieć na pytanie „czy coś jest już zalogowane?” bez ładowania pełnego środowiska uruchomieniowego kanału. |
|
||||
| `openclaw.install.npmSpec` / `openclaw.install.localPath` | Wskazówki instalacji/aktualizacji dla bundlowanych i zewnętrznie publikowanych pluginów. |
|
||||
| `openclaw.install.defaultChoice` | Preferowana ścieżka instalacji, gdy dostępnych jest wiele źródeł instalacji. |
|
||||
| `openclaw.install.minHostVersion` | Minimalna obsługiwana wersja hosta OpenClaw, z użyciem dolnej granicy semver, np. `>=2026.3.22`. |
|
||||
| `openclaw.install.allowInvalidConfigRecovery` | Pozwala na wąską ścieżkę odzyskiwania przez ponowną instalację bundlowanego pluginu, gdy konfiguracja jest nieprawidłowa. |
|
||||
| `openclaw.startup.deferConfiguredChannelFullLoadUntilAfterListen` | Pozwala na ładowanie powierzchni kanału tylko do konfiguracji przed pełnym pluginem kanału podczas uruchamiania. |
|
||||
|
||||
`openclaw.install.minHostVersion` jest egzekwowane podczas instalacji i ładowania rejestru
|
||||
manifestów. Nieprawidłowe wartości są odrzucane; poprawne, ale nowsze wartości powodują pominięcie
|
||||
`openclaw.install.minHostVersion` jest wymuszane podczas instalacji i ładowania rejestru
|
||||
manifestów. Nieprawidłowe wartości są odrzucane; nowsze, ale poprawne wartości powodują pominięcie
|
||||
pluginu na starszych hostach.
|
||||
|
||||
`openclaw.install.allowInvalidConfigRecovery` jest celowo wąskie. Nie
|
||||
sprawia, że dowolnie uszkodzone konfiguracje stają się instalowalne. Obecnie pozwala jedynie ścieżkom instalacji
|
||||
odzyskać działanie po określonych błędach aktualizacji nieaktualnych bundlowanych pluginów, takich jak
|
||||
sprawia, że dowolnie uszkodzone konfiguracje stają się możliwe do zainstalowania. Dziś pozwala tylko przepływom instalacji
|
||||
odzyskać sprawność po określonych nieaktualnych błędach aktualizacji bundlowanego pluginu, takich jak
|
||||
brakująca ścieżka bundlowanego pluginu lub nieaktualny wpis `channels.<id>` dla tego samego
|
||||
bundlowanego pluginu. Niezwiązane błędy konfiguracji nadal blokują instalację i kierują operatorów
|
||||
do `openclaw doctor --fix`.
|
||||
|
||||
`openclaw.channel.persistedAuthState` to metadane pakietu dla małego modułu sprawdzającego:
|
||||
`openclaw.channel.persistedAuthState` to metadane pakietu dla małego modułu
|
||||
sprawdzającego:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -387,12 +391,13 @@ do `openclaw doctor --fix`.
|
||||
}
|
||||
```
|
||||
|
||||
Używaj go, gdy konfiguracja, doctor lub przepływy configured-state potrzebują lekkiej sondy auth typu tak/nie
|
||||
przed załadowaniem pełnego pluginu kanału. Docelowy eksport powinien być małą
|
||||
funkcją odczytującą wyłącznie zapisany stan; nie kieruj jej przez pełny barrel runtime kanału.
|
||||
Używaj tego, gdy konfiguracja, doctor lub przepływy stanu skonfigurowania potrzebują taniego sprawdzenia auth typu tak/nie
|
||||
przed załadowaniem pełnego pluginu kanału. Eksport docelowy powinien być małą
|
||||
funkcją, która odczytuje wyłącznie stan utrwalony; nie kieruj tego przez pełny
|
||||
barrel środowiska uruchomieniowego kanału.
|
||||
|
||||
`openclaw.channel.configuredState` ma ten sam kształt dla lekkich kontroli
|
||||
stanu konfiguracji opartych wyłącznie na env:
|
||||
`openclaw.channel.configuredState` ma ten sam kształt dla tanich sprawdzeń
|
||||
stanu skonfigurowania opartych wyłącznie na env:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -408,61 +413,63 @@ stanu konfiguracji opartych wyłącznie na env:
|
||||
}
|
||||
```
|
||||
|
||||
Używaj go, gdy kanał może odpowiedzieć na pytanie o stan konfiguracji na podstawie env lub innych małych
|
||||
wejść niezwiązanych z runtime. Jeśli kontrola wymaga pełnego rozstrzygania konfiguracji lub rzeczywistego
|
||||
runtime kanału, pozostaw tę logikę w hooku pluginu `config.hasConfiguredState`.
|
||||
Używaj tego, gdy kanał może odpowiedzieć na pytanie o stan skonfigurowania na podstawie env lub innych małych
|
||||
wejść niezwiązanych ze środowiskiem uruchomieniowym. Jeśli sprawdzenie wymaga pełnego rozstrzygania konfiguracji lub rzeczywistego
|
||||
środowiska uruchomieniowego kanału, pozostaw tę logikę w hooku pluginu `config.hasConfiguredState`.
|
||||
|
||||
## Wymagania JSON Schema
|
||||
## Wymagania schematu JSON
|
||||
|
||||
- **Każdy plugin musi dostarczać JSON Schema**, nawet jeśli nie akceptuje żadnej konfiguracji.
|
||||
- **Każdy plugin musi dostarczać schemat JSON**, nawet jeśli nie akceptuje żadnej konfiguracji.
|
||||
- Pusty schemat jest akceptowalny (na przykład `{ "type": "object", "additionalProperties": false }`).
|
||||
- Schematy są walidowane podczas odczytu/zapisu konfiguracji, a nie w runtime.
|
||||
- Schematy są walidowane podczas odczytu/zapisu konfiguracji, a nie w czasie działania.
|
||||
|
||||
## Zachowanie walidacji
|
||||
|
||||
- Nieznane klucze `channels.*` są **błędami**, chyba że identyfikator kanału jest zadeklarowany przez
|
||||
- Nieznane klucze `channels.*` są **błędami**, chyba że identyfikator kanału jest deklarowany przez
|
||||
manifest pluginu.
|
||||
- `plugins.entries.<id>`, `plugins.allow`, `plugins.deny` i `plugins.slots.*`
|
||||
muszą wskazywać **wykrywalne** identyfikatory pluginów. Nieznane identyfikatory są **błędami**.
|
||||
muszą odwoływać się do **wykrywalnych** identyfikatorów pluginów. Nieznane identyfikatory są **błędami**.
|
||||
- Jeśli plugin jest zainstalowany, ale ma uszkodzony lub brakujący manifest albo schemat,
|
||||
walidacja kończy się niepowodzeniem, a Doctor raportuje błąd pluginu.
|
||||
- Jeśli konfiguracja pluginu istnieje, ale plugin jest **wyłączony**, konfiguracja jest zachowywana i
|
||||
walidacja kończy się niepowodzeniem, a Doctor zgłasza błąd pluginu.
|
||||
- Jeśli konfiguracja pluginu istnieje, ale plugin jest **wyłączony**, konfiguracja zostaje zachowana i
|
||||
w Doctor + logach pojawia się **ostrzeżenie**.
|
||||
|
||||
Pełny schemat `plugins.*` znajdziesz w [Configuration reference](/pl/gateway/configuration).
|
||||
Pełny schemat `plugins.*` znajdziesz w [Dokumentacji konfiguracji](/pl/gateway/configuration).
|
||||
|
||||
## Uwagi
|
||||
|
||||
- Manifest jest **wymagany dla natywnych pluginów OpenClaw**, w tym ładowanych z lokalnego systemu plików.
|
||||
- Runtime nadal ładuje moduł pluginu osobno; manifest służy wyłącznie do
|
||||
- Manifest jest **wymagany dla natywnych pluginów OpenClaw**, także przy ładowaniu z lokalnego systemu plików.
|
||||
- Środowisko uruchomieniowe nadal ładuje moduł pluginu osobno; manifest służy wyłącznie do
|
||||
wykrywania + walidacji.
|
||||
- Natywne manifesty są parsowane jako JSON5, więc komentarze, końcowe przecinki i
|
||||
- Natywne manifesty są parsowane przy użyciu JSON5, więc komentarze, końcowe przecinki i
|
||||
klucze bez cudzysłowów są akceptowane, o ile końcowa wartość nadal jest obiektem.
|
||||
- Loader manifestu odczytuje wyłącznie udokumentowane pola manifestu. Unikaj dodawania
|
||||
tutaj własnych kluczy najwyższego poziomu.
|
||||
- `providerAuthEnvVars` to lekka ścieżka metadanych dla sond auth, walidacji znaczników env
|
||||
i podobnych powierzchni uwierzytelniania dostawcy, które nie powinny uruchamiać runtime pluginu
|
||||
- Loader manifestu odczytuje tylko udokumentowane pola manifestu. Unikaj dodawania
|
||||
tutaj niestandardowych kluczy najwyższego poziomu.
|
||||
- `providerAuthEnvVars` to tania ścieżka metadanych dla sond auth, walidacji znaczników env
|
||||
i podobnych powierzchni auth dostawców, które nie powinny uruchamiać środowiska uruchomieniowego pluginu tylko po to, aby sprawdzić nazwy env.
|
||||
- `providerAuthAliases` pozwala wariantom dostawców ponownie używać zmiennych env auth
|
||||
innego dostawcy, profili auth, auth opartych na konfiguracji oraz wyboru onboardingu klucza API
|
||||
bez kodowania tej relacji na sztywno w rdzeniu.
|
||||
- `channelEnvVars` to tania ścieżka metadanych dla fallbacku shell-env, promptów konfiguracji
|
||||
i podobnych powierzchni kanałów, które nie powinny uruchamiać środowiska uruchomieniowego pluginu
|
||||
tylko po to, aby sprawdzić nazwy env.
|
||||
- `channelEnvVars` to lekka ścieżka metadanych dla rezerwowego użycia shell-env, promptów konfiguracji
|
||||
i podobnych powierzchni kanału, które nie powinny uruchamiać runtime pluginu
|
||||
tylko po to, aby sprawdzić nazwy env.
|
||||
- `providerAuthChoices` to lekka ścieżka metadanych dla selektorów opcji uwierzytelniania,
|
||||
rozstrzygania `--auth-choice`, mapowania preferowanego dostawcy i prostego rejestrowania flag CLI
|
||||
podczas onboardingu przed załadowaniem runtime dostawcy. Metadane kreatora runtime,
|
||||
które wymagają kodu dostawcy, znajdziesz w
|
||||
[Provider runtime hooks](/pl/plugins/architecture#provider-runtime-hooks).
|
||||
- `providerAuthChoices` to tania ścieżka metadanych dla selektorów wyboru auth,
|
||||
rozstrzygania `--auth-choice`, mapowania preferowanych dostawców i prostej rejestracji
|
||||
flag CLI onboardingu przed załadowaniem środowiska uruchomieniowego dostawcy. Dla metadanych
|
||||
kreatora środowiska uruchomieniowego, które wymagają kodu dostawcy, zobacz
|
||||
[Hooki środowiska uruchomieniowego dostawcy](/pl/plugins/architecture#provider-runtime-hooks).
|
||||
- Wyłączne rodzaje pluginów są wybierane przez `plugins.slots.*`.
|
||||
- `kind: "memory"` jest wybierane przez `plugins.slots.memory`.
|
||||
- `kind: "context-engine"` jest wybierane przez `plugins.slots.contextEngine`
|
||||
(domyślnie: wbudowany `legacy`).
|
||||
- `channels`, `providers`, `cliBackends` i `skills` mogą zostać pominięte, jeśli
|
||||
(domyślnie: wbudowane `legacy`).
|
||||
- `channels`, `providers`, `cliBackends` i `skills` można pominąć, gdy
|
||||
plugin ich nie potrzebuje.
|
||||
- Jeśli Twój plugin zależy od modułów natywnych, udokumentuj kroki budowania oraz wszelkie
|
||||
wymagania dotyczące allowlisty menedżera pakietów (na przykład pnpm `allow-build-scripts`
|
||||
- Jeśli Twój plugin zależy od modułów natywnych, udokumentuj kroki budowania i wszelkie
|
||||
wymagania dotyczące listy dozwolonych menedżera pakietów (na przykład pnpm `allow-build-scripts`
|
||||
- `pnpm rebuild <package>`).
|
||||
|
||||
## Powiązane
|
||||
|
||||
- [Building Plugins](/pl/plugins/building-plugins) — rozpoczęcie pracy z pluginami
|
||||
- [Plugin Architecture](/pl/plugins/architecture) — architektura wewnętrzna
|
||||
- [SDK Overview](/pl/plugins/sdk-overview) — dokumentacja Plugin SDK
|
||||
- [Tworzenie pluginów](/pl/plugins/building-plugins) — rozpoczęcie pracy z pluginami
|
||||
- [Architektura pluginów](/pl/plugins/architecture) — architektura wewnętrzna
|
||||
- [Przegląd SDK](/pl/plugins/sdk-overview) — dokumentacja Plugin SDK
|
||||
|
||||
@ -2,111 +2,106 @@
|
||||
read_when:
|
||||
- Widzisz ostrzeżenie OPENCLAW_PLUGIN_SDK_COMPAT_DEPRECATED
|
||||
- Widzisz ostrzeżenie OPENCLAW_EXTENSION_API_DEPRECATED
|
||||
- Aktualizujesz plugin do nowoczesnej architektury pluginów
|
||||
- Utrzymujesz zewnętrzny plugin OpenClaw
|
||||
- Aktualizujesz wtyczkę do nowoczesnej architektury wtyczek OpenClaw
|
||||
- Utrzymujesz zewnętrzną wtyczkę OpenClaw
|
||||
sidebarTitle: Migrate to SDK
|
||||
summary: Przejdź ze starszej warstwy zgodności wstecznej na nowoczesny Plugin SDK
|
||||
summary: Migracja ze starszej warstwy zgodności wstecznej do nowoczesnego Plugin SDK
|
||||
title: Migracja Plugin SDK
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T09:45:41Z"
|
||||
generated_at: "2026-04-09T01:29:55Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: d9a2ce7f5553563516a549ca87e776a6a71e8dd8533a773c5ddbecfae43e7b77
|
||||
source_hash: 60cbb6c8be30d17770887d490c14e3a4538563339a5206fb419e51e0558bbc07
|
||||
source_path: plugins/sdk-migration.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Migracja Plugin SDK
|
||||
|
||||
OpenClaw przeszedł od szerokiej warstwy zgodności wstecznej do nowoczesnej
|
||||
architektury pluginów z ukierunkowanymi, udokumentowanymi importami. Jeśli
|
||||
Twój plugin powstał przed wprowadzeniem nowej architektury, ten przewodnik
|
||||
pomoże Ci przeprowadzić migrację.
|
||||
OpenClaw przeszedł z szerokiej warstwy zgodności wstecznej na nowoczesną
|
||||
architekturę wtyczek z ukierunkowanymi, udokumentowanymi importami. Jeśli Twoja wtyczka została zbudowana przed
|
||||
wprowadzeniem nowej architektury, ten przewodnik pomoże Ci przeprowadzić migrację.
|
||||
|
||||
## Co się zmienia
|
||||
|
||||
Stary system pluginów udostępniał dwie szeroko otwarte powierzchnie, które
|
||||
pozwalały pluginom importować wszystko, czego potrzebowały, z jednego punktu
|
||||
wejścia:
|
||||
Stary system wtyczek udostępniał dwie bardzo szerokie powierzchnie, które pozwalały wtyczkom importować
|
||||
wszystko, czego potrzebowały, z jednego punktu wejścia:
|
||||
|
||||
- **`openclaw/plugin-sdk/compat`** — pojedynczy import, który reeksportował
|
||||
dziesiątki helperów. Został wprowadzony po to, aby starsze pluginy oparte na
|
||||
hookach nadal działały, podczas gdy budowano nową architekturę pluginów.
|
||||
- **`openclaw/extension-api`** — most, który dawał pluginom bezpośredni dostęp
|
||||
do helperów po stronie hosta, takich jak osadzony runner agenta.
|
||||
- **`openclaw/plugin-sdk/compat`** — pojedynczy import, który reeksportował dziesiątki
|
||||
pomocniczych elementów. Został wprowadzony po to, aby starsze wtyczki oparte na hookach nadal działały, gdy
|
||||
budowana była nowa architektura wtyczek.
|
||||
- **`openclaw/extension-api`** — pomost, który dawał wtyczkom bezpośredni dostęp do
|
||||
pomocników po stronie hosta, takich jak osadzony runner agenta.
|
||||
|
||||
Obie te powierzchnie są teraz **przestarzałe**. Nadal działają w runtime, ale
|
||||
nowe pluginy nie mogą już z nich korzystać, a istniejące pluginy powinny
|
||||
przeprowadzić migrację, zanim kolejna główna wersja je usunie.
|
||||
Obie powierzchnie są teraz **przestarzałe**. Nadal działają w środowisku uruchomieniowym, ale nowe
|
||||
wtyczki nie mogą z nich korzystać, a istniejące wtyczki powinny przeprowadzić migrację przed kolejnym
|
||||
głównym wydaniem, które je usunie.
|
||||
|
||||
<Warning>
|
||||
Warstwa zgodności wstecznej zostanie usunięta w jednej z przyszłych głównych wersji.
|
||||
Pluginy, które nadal importują z tych powierzchni, przestaną działać, gdy to nastąpi.
|
||||
Warstwa zgodności wstecznej zostanie usunięta w jednym z przyszłych głównych wydań.
|
||||
Wtyczki, które nadal importują z tych powierzchni, przestaną działać, gdy to nastąpi.
|
||||
</Warning>
|
||||
|
||||
## Dlaczego to się zmieniło
|
||||
|
||||
Stare podejście powodowało problemy:
|
||||
|
||||
- **Powolne uruchamianie** — zaimportowanie jednego helpera ładowało dziesiątki
|
||||
niepowiązanych modułów
|
||||
- **Wolne uruchamianie** — zaimportowanie jednego pomocnika ładowało dziesiątki niepowiązanych modułów
|
||||
- **Zależności cykliczne** — szerokie reeksporty ułatwiały tworzenie cykli importu
|
||||
- **Niejasna powierzchnia API** — nie było sposobu, by stwierdzić, które eksporty
|
||||
są stabilne, a które wewnętrzne
|
||||
- **Niejasna powierzchnia API** — nie było sposobu, aby rozróżnić, które eksporty były stabilne, a które wewnętrzne
|
||||
|
||||
Nowoczesny Plugin SDK rozwiązuje ten problem: każda ścieżka importu (`openclaw/plugin-sdk/\<subpath\>`)
|
||||
to mały, samodzielny moduł z jasnym przeznaczeniem i udokumentowanym kontraktem.
|
||||
Nowoczesne Plugin SDK to naprawia: każda ścieżka importu (`openclaw/plugin-sdk/\<subpath\>`)
|
||||
jest małym, samodzielnym modułem o jasno określonym celu i udokumentowanym kontrakcie.
|
||||
|
||||
Starsze wygodne powierzchnie providerów dla wbudowanych kanałów również zostały usunięte. Importy
|
||||
Starsze wygodne punkty integracji dostawców dla dołączonych kanałów również zniknęły. Importy
|
||||
takie jak `openclaw/plugin-sdk/slack`, `openclaw/plugin-sdk/discord`,
|
||||
`openclaw/plugin-sdk/signal`, `openclaw/plugin-sdk/whatsapp`,
|
||||
powierzchnie helperów oznaczone marką kanału oraz
|
||||
pomocnicze punkty integracji oznaczone marką kanału oraz
|
||||
`openclaw/plugin-sdk/telegram-core` były prywatnymi skrótami mono-repo, a nie
|
||||
stabilnymi kontraktami pluginów. Zamiast nich używaj wąskich, ogólnych podścieżek SDK. Wewnątrz
|
||||
workspace wbudowanych pluginów przechowuj helpery należące do providera we własnym
|
||||
`api.ts` lub `runtime-api.ts` tego pluginu.
|
||||
stabilnymi kontraktami wtyczek. Zamiast tego używaj wąskich, ogólnych podścieżek SDK. W obrębie
|
||||
dołączonego obszaru roboczego wtyczek trzymaj pomocniki należące do dostawcy we własnym
|
||||
`api.ts` lub `runtime-api.ts` tej wtyczki.
|
||||
|
||||
Bieżące przykłady wbudowanych providerów:
|
||||
Bieżące przykłady dołączonych dostawców:
|
||||
|
||||
- Anthropic przechowuje helpery strumieni specyficzne dla Claude we własnej powierzchni `api.ts` /
|
||||
- Anthropic trzyma pomocniki strumieni specyficzne dla Claude we własnym punkcie integracji `api.ts` /
|
||||
`contract-api.ts`
|
||||
- OpenAI przechowuje buildery providerów, helpery modeli domyślnych i buildery providerów
|
||||
realtime we własnym `api.ts`
|
||||
- OpenRouter przechowuje builder providera oraz helpery onboardingu/konfiguracji we własnym
|
||||
- OpenAI trzyma konstruktory dostawców, pomocniki modeli domyślnych i konstruktory dostawców realtime
|
||||
we własnym `api.ts`
|
||||
- OpenRouter trzyma konstruktor dostawcy oraz pomocniki onboardingu/konfiguracji we własnym
|
||||
`api.ts`
|
||||
|
||||
## Jak przeprowadzić migrację
|
||||
|
||||
<Steps>
|
||||
<Step title="Przenieś handlery natywnych zatwierdzeń do capability facts">
|
||||
Pluginy kanałów obsługujące zatwierdzanie udostępniają teraz natywne zachowanie zatwierdzania przez
|
||||
`approvalCapability.nativeRuntime` oraz współdzielony rejestr runtime-context.
|
||||
<Step title="Przenieś handlery approval-native do faktów o możliwościach">
|
||||
Wtyczki kanałów obsługujące zatwierdzanie udostępniają teraz natywne zachowanie zatwierdzania przez
|
||||
`approvalCapability.nativeRuntime` oraz współdzielony rejestr kontekstu runtime.
|
||||
|
||||
Najważniejsze zmiany:
|
||||
|
||||
- Zastąp `approvalCapability.handler.loadRuntime(...)` przez
|
||||
`approvalCapability.nativeRuntime`
|
||||
- Przenieś uwierzytelnianie i dostarczanie specyficzne dla zatwierdzeń ze starszego powiązania `plugin.auth` /
|
||||
- Przenieś uwierzytelnianie/dostarczanie specyficzne dla zatwierdzeń z przestarzałego połączenia `plugin.auth` /
|
||||
`plugin.approvals` do `approvalCapability`
|
||||
- `ChannelPlugin.approvals` zostało usunięte z publicznego kontraktu
|
||||
pluginu kanału; przenieś pola delivery/native/render do `approvalCapability`
|
||||
- `plugin.auth` pozostaje wyłącznie dla przepływów logowania/wylogowania kanału; hooki
|
||||
wtyczek kanałów; przenieś pola delivery/native/render do `approvalCapability`
|
||||
- `plugin.auth` pozostaje tylko dla przepływów logowania/wylogowania kanału; hooki
|
||||
uwierzytelniania zatwierdzeń w tym miejscu nie są już odczytywane przez core
|
||||
- Rejestruj obiekty runtime należące do kanału, takie jak klienci, tokeny lub aplikacje
|
||||
- Rejestruj obiekty runtime należące do kanału, takie jak klienci, tokeny czy aplikacje
|
||||
Bolt, przez `openclaw/plugin-sdk/channel-runtime-context`
|
||||
- Nie wysyłaj komunikatów o przekierowaniu należących do pluginu z natywnych handlerów zatwierdzeń;
|
||||
core zarządza teraz komunikatami o dostarczeniu w inne miejsce na podstawie rzeczywistych wyników delivery
|
||||
- Nie wysyłaj komunikatów o przekierowaniu należących do wtyczki z natywnych handlerów zatwierdzeń;
|
||||
komunikaty o dostarczeniu gdzie indziej na podstawie rzeczywistych wyników dostarczenia są teraz obsługiwane przez core
|
||||
- Przy przekazywaniu `channelRuntime` do `createChannelManager(...)` podaj
|
||||
rzeczywistą powierzchnię `createPluginRuntime().channel`. Częściowe stuby są odrzucane.
|
||||
|
||||
Aktualny układ capability zatwierdzeń znajdziesz w
|
||||
`/plugins/sdk-channel-plugins`.
|
||||
Zobacz `/plugins/sdk-channel-plugins`, aby poznać bieżący układ możliwości zatwierdzania.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Sprawdź zachowanie zapasowe wrapperów Windows">
|
||||
Jeśli Twój plugin używa `openclaw/plugin-sdk/windows-spawn`, nierozwiązane wrappery Windows
|
||||
`.cmd`/`.bat` teraz kończą się bezpieczną porażką, chyba że jawnie przekażesz
|
||||
<Step title="Sprawdź zachowanie awaryjne wrappera Windows">
|
||||
Jeśli Twoja wtyczka używa `openclaw/plugin-sdk/windows-spawn`, nierozwiązane wrappery Windows
|
||||
`.cmd`/`.bat` kończą się teraz zamknięciem awaryjnym, chyba że jawnie przekażesz
|
||||
`allowShellFallback: true`.
|
||||
|
||||
```typescript
|
||||
@ -116,19 +111,19 @@ Bieżące przykłady wbudowanych providerów:
|
||||
// Po
|
||||
const program = applyWindowsSpawnProgramPolicy({
|
||||
candidate,
|
||||
// Ustaw to tylko dla zaufanych wywołujących zgodności, którzy świadomie
|
||||
// akceptują zapasowe wywołanie przez shell.
|
||||
// Ustawiaj to tylko dla zaufanych wywołań zgodności, które celowo
|
||||
// akceptują awaryjne przejście przez powłokę.
|
||||
allowShellFallback: true,
|
||||
});
|
||||
```
|
||||
|
||||
Jeśli Twój kod wywołujący nie polega świadomie na zapasowym wywołaniu przez shell, nie ustawiaj
|
||||
`allowShellFallback` i zamiast tego obsłuż zgłaszany błąd.
|
||||
Jeśli Twój kod wywołujący nie polega celowo na awaryjnym przejściu przez powłokę, nie ustawiaj
|
||||
`allowShellFallback` i zamiast tego obsłuż wyrzucany błąd.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Znajdź przestarzałe importy">
|
||||
Przeszukaj plugin pod kątem importów z którejkolwiek z przestarzałych powierzchni:
|
||||
Wyszukaj w swojej wtyczce importy z którejkolwiek z przestarzałych powierzchni:
|
||||
|
||||
```bash
|
||||
grep -r "plugin-sdk/compat" my-plugin/
|
||||
@ -137,8 +132,8 @@ Bieżące przykłady wbudowanych providerów:
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Zastąp je ukierunkowanymi importami">
|
||||
Każdy eksport ze starej powierzchni odpowiada konkretnej nowoczesnej ścieżce importu:
|
||||
<Step title="Zastąp ukierunkowanymi importami">
|
||||
Każdy eksport ze starej powierzchni ma odpowiednik w konkretnej nowoczesnej ścieżce importu:
|
||||
|
||||
```typescript
|
||||
// Przed (przestarzała warstwa zgodności wstecznej)
|
||||
@ -148,17 +143,17 @@ Bieżące przykłady wbudowanych providerów:
|
||||
resolveControlCommandGate,
|
||||
} from "openclaw/plugin-sdk/compat";
|
||||
|
||||
// Po (nowoczesne ukierunkowane importy)
|
||||
// Po (nowoczesne, ukierunkowane importy)
|
||||
import { createChannelReplyPipeline } from "openclaw/plugin-sdk/channel-reply-pipeline";
|
||||
import { createPluginRuntimeStore } from "openclaw/plugin-sdk/runtime-store";
|
||||
import { resolveControlCommandGate } from "openclaw/plugin-sdk/command-auth";
|
||||
```
|
||||
|
||||
W przypadku helperów po stronie hosta używaj wstrzykniętego runtime pluginu zamiast importować je
|
||||
bezpośrednio:
|
||||
W przypadku pomocników po stronie hosta użyj wstrzykniętego runtime wtyczki zamiast importować
|
||||
je bezpośrednio:
|
||||
|
||||
```typescript
|
||||
// Przed (przestarzały most extension-api)
|
||||
// Przed (przestarzały pomost extension-api)
|
||||
import { runEmbeddedPiAgent } from "openclaw/extension-api";
|
||||
const result = await runEmbeddedPiAgent({ sessionId, prompt });
|
||||
|
||||
@ -166,7 +161,7 @@ Bieżące przykłady wbudowanych providerów:
|
||||
const result = await api.runtime.agent.runEmbeddedPiAgent({ sessionId, prompt });
|
||||
```
|
||||
|
||||
Ten sam wzorzec dotyczy innych starszych helperów mostu:
|
||||
Ten sam wzorzec dotyczy innych starszych pomocników pomostu:
|
||||
|
||||
| Stary import | Nowoczesny odpowiednik |
|
||||
| --- | --- |
|
||||
@ -176,7 +171,7 @@ Bieżące przykłady wbudowanych providerów:
|
||||
| `resolveThinkingDefault` | `api.runtime.agent.resolveThinkingDefault` |
|
||||
| `resolveAgentTimeoutMs` | `api.runtime.agent.resolveAgentTimeoutMs` |
|
||||
| `ensureAgentWorkspace` | `api.runtime.agent.ensureAgentWorkspace` |
|
||||
| helpery magazynu sesji | `api.runtime.agent.session.*` |
|
||||
| pomocniki magazynu sesji | `api.runtime.agent.session.*` |
|
||||
|
||||
</Step>
|
||||
|
||||
@ -193,204 +188,205 @@ Bieżące przykłady wbudowanych providerów:
|
||||
<Accordion title="Tabela typowych ścieżek importu">
|
||||
| Ścieżka importu | Przeznaczenie | Kluczowe eksporty |
|
||||
| --- | --- | --- |
|
||||
| `plugin-sdk/plugin-entry` | Kanoniczny helper punktu wejścia pluginu | `definePluginEntry` |
|
||||
| `plugin-sdk/core` | Starszy zbiorczy reeksport definicji/builderów wejść kanałów | `defineChannelPluginEntry`, `createChatChannelPlugin` |
|
||||
| `plugin-sdk/config-schema` | Eksport schematu głównej konfiguracji | `OpenClawSchema` |
|
||||
| `plugin-sdk/provider-entry` | Helper punktu wejścia pojedynczego providera | `defineSingleProviderPluginEntry` |
|
||||
| `plugin-sdk/channel-core` | Ukierunkowane definicje i buildery wejść kanałów | `defineChannelPluginEntry`, `defineSetupPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase` |
|
||||
| `plugin-sdk/setup` | Współdzielone helpery kreatora konfiguracji | Prompty allowlist i buildery statusu konfiguracji |
|
||||
| `plugin-sdk/setup-runtime` | Helpery runtime dla konfiguracji | Bezpieczne przy imporcie adaptery poprawek konfiguracji, helpery notatek lookup, `promptResolvedAllowFrom`, `splitSetupEntries`, delegowane proxy konfiguracji |
|
||||
| `plugin-sdk/setup-adapter-runtime` | Helpery adaptera konfiguracji | `createEnvPatchedAccountSetupAdapter` |
|
||||
| `plugin-sdk/setup-tools` | Helpery narzędzi konfiguracji | `formatCliCommand`, `detectBinary`, `extractArchive`, `resolveBrewExecutable`, `formatDocsLink`, `CONFIG_DIR` |
|
||||
| `plugin-sdk/account-core` | Helpery wielu kont | Helpery listy kont/konfiguracji/bramek akcji |
|
||||
| `plugin-sdk/account-id` | Helpery account-id | `DEFAULT_ACCOUNT_ID`, normalizacja account-id |
|
||||
| `plugin-sdk/account-resolution` | Helpery wyszukiwania kont | Helpery wyszukiwania kont i domyślnego fallbacku |
|
||||
| `plugin-sdk/account-helpers` | Wąskie helpery kont | Helpery listy kont/akcji na kontach |
|
||||
| `plugin-sdk/plugin-entry` | Kanoniczny pomocnik punktu wejścia wtyczki | `definePluginEntry` |
|
||||
| `plugin-sdk/core` | Starszy zbiorczy reeksport definicji/budowniczych wejść kanałów | `defineChannelPluginEntry`, `createChatChannelPlugin` |
|
||||
| `plugin-sdk/config-schema` | Eksport głównego schematu konfiguracji | `OpenClawSchema` |
|
||||
| `plugin-sdk/provider-entry` | Pomocnik punktu wejścia pojedynczego dostawcy | `defineSingleProviderPluginEntry` |
|
||||
| `plugin-sdk/channel-core` | Ukierunkowane definicje i konstruktory wejść kanałów | `defineChannelPluginEntry`, `defineSetupPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase` |
|
||||
| `plugin-sdk/setup` | Współdzielone pomocniki kreatora konfiguracji | Prompty listy dozwolonych, konstruktory statusu konfiguracji |
|
||||
| `plugin-sdk/setup-runtime` | Pomocniki runtime dla czasu konfiguracji | Bezpieczne importowo adaptery łatek konfiguracji, pomocniki notatek wyszukiwania, `promptResolvedAllowFrom`, `splitSetupEntries`, delegowane proxy konfiguracji |
|
||||
| `plugin-sdk/setup-adapter-runtime` | Pomocniki adaptera konfiguracji | `createEnvPatchedAccountSetupAdapter` |
|
||||
| `plugin-sdk/setup-tools` | Pomocniki narzędzi konfiguracji | `formatCliCommand`, `detectBinary`, `extractArchive`, `resolveBrewExecutable`, `formatDocsLink`, `CONFIG_DIR` |
|
||||
| `plugin-sdk/account-core` | Pomocniki wielu kont | Pomocniki listy kont/konfiguracji/bramek akcji |
|
||||
| `plugin-sdk/account-id` | Pomocniki identyfikatora konta | `DEFAULT_ACCOUNT_ID`, normalizacja identyfikatora konta |
|
||||
| `plugin-sdk/account-resolution` | Pomocniki wyszukiwania kont | Wyszukiwanie kont + pomocniki awaryjnego użycia wartości domyślnej |
|
||||
| `plugin-sdk/account-helpers` | Wąskie pomocniki kont | Pomocniki listy kont/akcji na koncie |
|
||||
| `plugin-sdk/channel-setup` | Adaptery kreatora konfiguracji | `createOptionalChannelSetupSurface`, `createOptionalChannelSetupAdapter`, `createOptionalChannelSetupWizard`, plus `DEFAULT_ACCOUNT_ID`, `createTopLevelChannelDmPolicy`, `setSetupChannelEnabled`, `splitSetupEntries` |
|
||||
| `plugin-sdk/channel-pairing` | Prymitywy parowania DM | `createChannelPairingController` |
|
||||
| `plugin-sdk/channel-reply-pipeline` | Powiązanie prefiksu odpowiedzi i wskaźnika pisania | `createChannelReplyPipeline` |
|
||||
| `plugin-sdk/channel-pairing` | Podstawy parowania DM | `createChannelPairingController` |
|
||||
| `plugin-sdk/channel-reply-pipeline` | Prefiks odpowiedzi + logika wpisywania | `createChannelReplyPipeline` |
|
||||
| `plugin-sdk/channel-config-helpers` | Fabryki adapterów konfiguracji | `createHybridChannelConfigAdapter` |
|
||||
| `plugin-sdk/channel-config-schema` | Buildery schematu konfiguracji | Typy schematu konfiguracji kanału |
|
||||
| `plugin-sdk/telegram-command-config` | Helpery konfiguracji poleceń Telegram | Normalizacja nazw poleceń, przycinanie opisów, walidacja duplikatów/konfliktów |
|
||||
| `plugin-sdk/channel-policy` | Rozwiązywanie polityk grup/DM | `resolveChannelGroupRequireMention` |
|
||||
| `plugin-sdk/channel-lifecycle` | Śledzenie statusu kont | `createAccountStatusSink` |
|
||||
| `plugin-sdk/inbound-envelope` | Helpery kopert wejściowych | Współdzielone helpery routingu i budowania kopert |
|
||||
| `plugin-sdk/inbound-reply-dispatch` | Helpery odpowiedzi wejściowych | Współdzielone helpery zapisu i dispatch |
|
||||
| `plugin-sdk/messaging-targets` | Parsowanie celów wiadomości | Helpery parsowania/dopasowania celów |
|
||||
| `plugin-sdk/outbound-media` | Helpery mediów wychodzących | Współdzielone ładowanie mediów wychodzących |
|
||||
| `plugin-sdk/outbound-runtime` | Helpery runtime dla wyjścia | Helpery tożsamości wychodzącej/delegatów wysyłki |
|
||||
| `plugin-sdk/thread-bindings-runtime` | Helpery powiązań wątków | Helpery cyklu życia powiązań wątków i adapterów |
|
||||
| `plugin-sdk/agent-media-payload` | Starsze helpery payloadu mediów | Builder payloadu mediów agenta dla starszych układów pól |
|
||||
| `plugin-sdk/channel-config-schema` | Konstruktory schematów konfiguracji | Typy schematów konfiguracji kanału |
|
||||
| `plugin-sdk/telegram-command-config` | Pomocniki konfiguracji poleceń Telegram | Normalizacja nazw poleceń, przycinanie opisów, walidacja duplikatów/konfliktów |
|
||||
| `plugin-sdk/channel-policy` | Rozstrzyganie polityki grup/DM | `resolveChannelGroupRequireMention` |
|
||||
| `plugin-sdk/channel-lifecycle` | Śledzenie statusu konta | `createAccountStatusSink` |
|
||||
| `plugin-sdk/inbound-envelope` | Pomocniki kopert wejściowych | Współdzielone pomocniki trasy + konstruktora koperty |
|
||||
| `plugin-sdk/inbound-reply-dispatch` | Pomocniki odpowiedzi wejściowych | Współdzielone pomocniki zapisu i wysyłki |
|
||||
| `plugin-sdk/messaging-targets` | Parsowanie celów wiadomości | Pomocniki parsowania/dopasowywania celów |
|
||||
| `plugin-sdk/outbound-media` | Pomocniki mediów wychodzących | Współdzielone ładowanie mediów wychodzących |
|
||||
| `plugin-sdk/outbound-runtime` | Pomocniki runtime dla ruchu wychodzącego | Pomocniki tożsamości wychodzącej/delegata wysyłki |
|
||||
| `plugin-sdk/thread-bindings-runtime` | Pomocniki powiązań wątków | Cykl życia powiązań wątków i pomocniki adapterów |
|
||||
| `plugin-sdk/agent-media-payload` | Starsze pomocniki ładunku mediów | Konstruktor ładunku mediów agenta dla starszych układów pól |
|
||||
| `plugin-sdk/channel-runtime` | Przestarzały shim zgodności | Tylko starsze narzędzia runtime kanału |
|
||||
| `plugin-sdk/channel-send-result` | Typy wyników wysyłki | Typy wyników odpowiedzi |
|
||||
| `plugin-sdk/runtime-store` | Trwałe przechowywanie pluginu | `createPluginRuntimeStore` |
|
||||
| `plugin-sdk/runtime` | Szerokie helpery runtime | Helpery runtime/logowania/backupu/instalacji pluginów |
|
||||
| `plugin-sdk/runtime-env` | Wąskie helpery środowiska runtime | Logger/runtime env, helpery timeoutów, retry i backoff |
|
||||
| `plugin-sdk/plugin-runtime` | Współdzielone helpery runtime pluginów | Helpery poleceń/hooków/http/interaktywnych funkcji pluginu |
|
||||
| `plugin-sdk/hook-runtime` | Helpery pipeline hooków | Współdzielone helpery pipeline webhooków/wewnętrznych hooków |
|
||||
| `plugin-sdk/lazy-runtime` | Helpery lazy runtime | `createLazyRuntimeModule`, `createLazyRuntimeMethod`, `createLazyRuntimeMethodBinder`, `createLazyRuntimeNamedExport`, `createLazyRuntimeSurface` |
|
||||
| `plugin-sdk/process-runtime` | Helpery procesów | Współdzielone helpery exec |
|
||||
| `plugin-sdk/cli-runtime` | Helpery runtime CLI | Formatowanie poleceń, oczekiwania, helpery wersji |
|
||||
| `plugin-sdk/gateway-runtime` | Helpery Gateway | Klient Gateway i helpery poprawek statusu kanału |
|
||||
| `plugin-sdk/config-runtime` | Helpery konfiguracji | Helpery ładowania/zapisu konfiguracji |
|
||||
| `plugin-sdk/telegram-command-config` | Helpery poleceń Telegram | Stabilne fallbackowe helpery walidacji poleceń Telegram, gdy powierzchnia kontraktu wbudowanego Telegrama jest niedostępna |
|
||||
| `plugin-sdk/approval-runtime` | Helpery promptów zatwierdzania | Payload zatwierdzeń exec/pluginu, helpery capability/profile zatwierdzeń, natywny routing/runtime zatwierdzeń |
|
||||
| `plugin-sdk/approval-auth-runtime` | Helpery uwierzytelniania zatwierdzeń | Rozwiązywanie approvera, autoryzacja akcji w tym samym czacie |
|
||||
| `plugin-sdk/approval-client-runtime` | Helpery klienta zatwierdzeń | Helpery profilu/filtra natywnych zatwierdzeń exec |
|
||||
| `plugin-sdk/approval-delivery-runtime` | Helpery dostarczania zatwierdzeń | Adaptery capability/delivery natywnych zatwierdzeń |
|
||||
| `plugin-sdk/approval-gateway-runtime` | Helpery Gateway dla zatwierdzeń | Współdzielony helper rozwiązywania approval gateway |
|
||||
| `plugin-sdk/approval-handler-adapter-runtime` | Helpery adaptera zatwierdzeń | Lekkie helpery ładowania natywnych adapterów zatwierdzeń dla gorących punktów wejścia kanałów |
|
||||
| `plugin-sdk/approval-handler-runtime` | Helpery handlerów zatwierdzeń | Szersze helpery runtime handlerów zatwierdzeń; preferuj węższe powierzchnie adaptera/gateway, gdy są wystarczające |
|
||||
| `plugin-sdk/approval-native-runtime` | Helpery celu zatwierdzeń | Helpery natywnego celu zatwierdzeń/powiązania kont |
|
||||
| `plugin-sdk/approval-reply-runtime` | Helpery odpowiedzi zatwierdzeń | Helpery payloadu odpowiedzi zatwierdzeń exec/pluginu |
|
||||
| `plugin-sdk/channel-runtime-context` | Helpery runtime-context kanału | Ogólne helpery register/get/watch dla runtime-context kanału |
|
||||
| `plugin-sdk/security-runtime` | Helpery bezpieczeństwa | Współdzielone helpery zaufania, bramek DM, treści zewnętrznych i zbierania sekretów |
|
||||
| `plugin-sdk/ssrf-policy` | Helpery polityki SSRF | Helpery allowlist hostów i polityki sieci prywatnych |
|
||||
| `plugin-sdk/ssrf-runtime` | Helpery runtime SSRF | Pinned-dispatcher, guarded fetch, helpery polityki SSRF |
|
||||
| `plugin-sdk/collection-runtime` | Helpery ograniczonego cache | `pruneMapToMaxSize` |
|
||||
| `plugin-sdk/diagnostic-runtime` | Helpery bramkowania diagnostyki | `isDiagnosticFlagEnabled`, `isDiagnosticsEnabled` |
|
||||
| `plugin-sdk/error-runtime` | Helpery formatowania błędów | `formatUncaughtError`, `isApprovalNotFoundError`, helpery grafu błędów |
|
||||
| `plugin-sdk/fetch-runtime` | Opakowane helpery fetch/proxy | `resolveFetch`, helpery proxy |
|
||||
| `plugin-sdk/host-runtime` | Helpery normalizacji hosta | `normalizeHostname`, `normalizeScpRemoteHost` |
|
||||
| `plugin-sdk/retry-runtime` | Helpery retry | `RetryConfig`, `retryAsync`, executory polityk |
|
||||
| `plugin-sdk/allow-from` | Formatowanie allowlist | `formatAllowFromLowercase` |
|
||||
| `plugin-sdk/allowlist-resolution` | Mapowanie danych wejściowych allowlist | `mapAllowlistResolutionInputs` |
|
||||
| `plugin-sdk/command-auth` | Bramkowanie poleceń i helpery powierzchni poleceń | `resolveControlCommandGate`, helpery autoryzacji nadawcy, helpery rejestru poleceń |
|
||||
| `plugin-sdk/secret-input` | Parsowanie wejścia sekretów | Helpery wejścia sekretów |
|
||||
| `plugin-sdk/webhook-ingress` | Helpery żądań webhook | Narzędzia celu webhook |
|
||||
| `plugin-sdk/webhook-request-guards` | Helpery guardów treści webhook | Helpery odczytu/limitów treści żądania |
|
||||
| `plugin-sdk/reply-runtime` | Współdzielony runtime odpowiedzi | Dispatch wejściowy, heartbeat, planer odpowiedzi, chunking |
|
||||
| `plugin-sdk/reply-dispatch-runtime` | Wąskie helpery dispatch odpowiedzi | Helpery finalize i dispatch providera |
|
||||
| `plugin-sdk/reply-history` | Helpery historii odpowiedzi | `buildHistoryContext`, `buildPendingHistoryContextFromMap`, `recordPendingHistoryEntry`, `clearHistoryEntriesIfEnabled` |
|
||||
| `plugin-sdk/reply-reference` | Planowanie referencji odpowiedzi | `createReplyReferencePlanner` |
|
||||
| `plugin-sdk/reply-chunking` | Helpery chunków odpowiedzi | Helpery chunkingu tekstu/markdown |
|
||||
| `plugin-sdk/session-store-runtime` | Helpery magazynu sesji | Helpery ścieżki magazynu i updated-at |
|
||||
| `plugin-sdk/state-paths` | Helpery ścieżek stanu | Helpery katalogów stanu i OAuth |
|
||||
| `plugin-sdk/routing` | Helpery routingu/kluczy sesji | `resolveAgentRoute`, `buildAgentSessionKey`, `resolveDefaultAgentBoundAccountId`, helpery normalizacji kluczy sesji |
|
||||
| `plugin-sdk/status-helpers` | Helpery statusu kanału | Buildery podsumowania statusu kanału/konta, domyślne wartości stanu runtime, helpery metadanych problemów |
|
||||
| `plugin-sdk/target-resolver-runtime` | Helpery rozwiązywania celu | Współdzielone helpery target resolver |
|
||||
| `plugin-sdk/string-normalization-runtime` | Helpery normalizacji ciągów | Helpery normalizacji slugów/ciągów |
|
||||
| `plugin-sdk/request-url` | Helpery URL żądania | Wyodrębnianie URL-i jako stringów z danych wejściowych podobnych do request |
|
||||
| `plugin-sdk/run-command` | Helpery poleceń z limitem czasu | Uruchamianie poleceń z limitem czasu i znormalizowanym stdout/stderr |
|
||||
| `plugin-sdk/runtime-store` | Trwałe przechowywanie wtyczek | `createPluginRuntimeStore` |
|
||||
| `plugin-sdk/runtime` | Szerokie pomocniki runtime | Pomocniki runtime/logowania/kopii zapasowej/instalacji wtyczek |
|
||||
| `plugin-sdk/runtime-env` | Wąskie pomocniki środowiska runtime | Logger/pomocniki środowiska runtime, timeout, retry i backoff |
|
||||
| `plugin-sdk/plugin-runtime` | Współdzielone pomocniki runtime wtyczek | Pomocniki poleceń/hooków/http/interaktywnych dla wtyczek |
|
||||
| `plugin-sdk/hook-runtime` | Pomocniki potoku hooków | Współdzielone pomocniki potoku webhooków/wewnętrznych hooków |
|
||||
| `plugin-sdk/lazy-runtime` | Pomocniki leniwego runtime | `createLazyRuntimeModule`, `createLazyRuntimeMethod`, `createLazyRuntimeMethodBinder`, `createLazyRuntimeNamedExport`, `createLazyRuntimeSurface` |
|
||||
| `plugin-sdk/process-runtime` | Pomocniki procesów | Współdzielone pomocniki `exec` |
|
||||
| `plugin-sdk/cli-runtime` | Pomocniki runtime CLI | Formatowanie poleceń, oczekiwania, pomocniki wersji |
|
||||
| `plugin-sdk/gateway-runtime` | Pomocniki bramy | Klient bramy i pomocniki łatek statusu kanału |
|
||||
| `plugin-sdk/config-runtime` | Pomocniki konfiguracji | Pomocniki ładowania/zapisu konfiguracji |
|
||||
| `plugin-sdk/telegram-command-config` | Pomocniki poleceń Telegram | Pomocniki walidacji poleceń Telegram ze stabilnym fallbackiem, gdy powierzchnia kontraktu dołączonego Telegrama jest niedostępna |
|
||||
| `plugin-sdk/approval-runtime` | Pomocniki promptów zatwierdzania | Ładunek zatwierdzania exec/wtyczki, pomocniki możliwości/profili zatwierdzania, natywne pomocniki routingu/runtime zatwierdzania |
|
||||
| `plugin-sdk/approval-auth-runtime` | Pomocniki uwierzytelniania zatwierdzeń | Rozstrzyganie zatwierdzających, uwierzytelnianie akcji w tym samym czacie |
|
||||
| `plugin-sdk/approval-client-runtime` | Pomocniki klienta zatwierdzeń | Pomocniki profilu/filtrów natywnego zatwierdzania exec |
|
||||
| `plugin-sdk/approval-delivery-runtime` | Pomocniki dostarczania zatwierdzeń | Adaptery możliwości/dostarczania natywnych zatwierdzeń |
|
||||
| `plugin-sdk/approval-gateway-runtime` | Pomocniki bramy zatwierdzeń | Współdzielony pomocnik rozstrzygania bramy zatwierdzeń |
|
||||
| `plugin-sdk/approval-handler-adapter-runtime` | Pomocniki adaptera zatwierdzeń | Lekkie pomocniki ładowania natywnych adapterów zatwierdzania dla gorących punktów wejścia kanału |
|
||||
| `plugin-sdk/approval-handler-runtime` | Pomocniki handlera zatwierdzeń | Szersze pomocniki runtime handlera zatwierdzeń; preferuj węższe punkty integracji adaptera/bramy, gdy są wystarczające |
|
||||
| `plugin-sdk/approval-native-runtime` | Pomocniki celu zatwierdzeń | Pomocniki natywnego wiązania celu/konta dla zatwierdzeń |
|
||||
| `plugin-sdk/approval-reply-runtime` | Pomocniki odpowiedzi zatwierdzeń | Pomocniki ładunku odpowiedzi zatwierdzeń exec/wtyczki |
|
||||
| `plugin-sdk/channel-runtime-context` | Pomocniki kontekstu runtime kanału | Ogólne pomocniki register/get/watch dla kontekstu runtime kanału |
|
||||
| `plugin-sdk/security-runtime` | Pomocniki bezpieczeństwa | Współdzielone pomocniki zaufania, bramek DM, treści zewnętrznych i zbierania sekretów |
|
||||
| `plugin-sdk/ssrf-policy` | Pomocniki polityki SSRF | Pomocniki listy dozwolonych hostów i polityki sieci prywatnej |
|
||||
| `plugin-sdk/ssrf-runtime` | Pomocniki runtime SSRF | Przypięty dispatcher, strzeżony fetch, pomocniki polityki SSRF |
|
||||
| `plugin-sdk/collection-runtime` | Pomocniki ograniczonego cache | `pruneMapToMaxSize` |
|
||||
| `plugin-sdk/diagnostic-runtime` | Pomocniki bramek diagnostycznych | `isDiagnosticFlagEnabled`, `isDiagnosticsEnabled` |
|
||||
| `plugin-sdk/error-runtime` | Pomocniki formatowania błędów | `formatUncaughtError`, `isApprovalNotFoundError`, pomocniki grafu błędów |
|
||||
| `plugin-sdk/fetch-runtime` | Pomocniki opakowanego fetch/proxy | `resolveFetch`, pomocniki proxy |
|
||||
| `plugin-sdk/host-runtime` | Pomocniki normalizacji hosta | `normalizeHostname`, `normalizeScpRemoteHost` |
|
||||
| `plugin-sdk/retry-runtime` | Pomocniki ponawiania | `RetryConfig`, `retryAsync`, uruchamiacze polityk |
|
||||
| `plugin-sdk/allow-from` | Formatowanie listy dozwolonych | `formatAllowFromLowercase` |
|
||||
| `plugin-sdk/allowlist-resolution` | Mapowanie wejść listy dozwolonych | `mapAllowlistResolutionInputs` |
|
||||
| `plugin-sdk/command-auth` | Bramkowanie poleceń i pomocniki powierzchni poleceń | `resolveControlCommandGate`, pomocniki autoryzacji nadawcy, pomocniki rejestru poleceń |
|
||||
| `plugin-sdk/command-status` | Renderery statusu/pomocy poleceń | `buildCommandsMessage`, `buildCommandsMessagePaginated`, `buildHelpMessage` |
|
||||
| `plugin-sdk/secret-input` | Parsowanie wejść sekretów | Pomocniki wejść sekretów |
|
||||
| `plugin-sdk/webhook-ingress` | Pomocniki żądań webhooków | Narzędzia celu webhooka |
|
||||
| `plugin-sdk/webhook-request-guards` | Pomocniki guardów żądań webhooków | Pomocniki odczytu/limitów treści żądania |
|
||||
| `plugin-sdk/reply-runtime` | Współdzielony runtime odpowiedzi | Wysyłka wejściowa, heartbeat, planista odpowiedzi, dzielenie na części |
|
||||
| `plugin-sdk/reply-dispatch-runtime` | Wąskie pomocniki wysyłki odpowiedzi | Pomocniki finalizacji + wysyłki dostawcy |
|
||||
| `plugin-sdk/reply-history` | Pomocniki historii odpowiedzi | `buildHistoryContext`, `buildPendingHistoryContextFromMap`, `recordPendingHistoryEntry`, `clearHistoryEntriesIfEnabled` |
|
||||
| `plugin-sdk/reply-reference` | Planowanie odwołań odpowiedzi | `createReplyReferencePlanner` |
|
||||
| `plugin-sdk/reply-chunking` | Pomocniki dzielenia odpowiedzi | Pomocniki dzielenia tekstu/markdownu |
|
||||
| `plugin-sdk/session-store-runtime` | Pomocniki magazynu sesji | Ścieżka magazynu + pomocniki `updated-at` |
|
||||
| `plugin-sdk/state-paths` | Pomocniki ścieżek stanu | Pomocniki katalogów stanu i OAuth |
|
||||
| `plugin-sdk/routing` | Pomocniki routingu/klucza sesji | `resolveAgentRoute`, `buildAgentSessionKey`, `resolveDefaultAgentBoundAccountId`, pomocniki normalizacji klucza sesji |
|
||||
| `plugin-sdk/status-helpers` | Pomocniki statusu kanału | Konstruktory podsumowań statusu kanału/konta, domyślne wartości stanu runtime, pomocniki metadanych problemów |
|
||||
| `plugin-sdk/target-resolver-runtime` | Pomocniki rozstrzygania celu | Współdzielone pomocniki rozstrzygania celu |
|
||||
| `plugin-sdk/string-normalization-runtime` | Pomocniki normalizacji ciągów | Pomocniki normalizacji slugów/ciągów |
|
||||
| `plugin-sdk/request-url` | Pomocniki URL żądania | Wyodrębnianie tekstowych URL z danych wejściowych podobnych do żądania |
|
||||
| `plugin-sdk/run-command` | Pomocniki poleceń z limitem czasu | Uruchamiacz poleceń z znormalizowanym stdout/stderr |
|
||||
| `plugin-sdk/param-readers` | Odczyt parametrów | Typowe odczyty parametrów narzędzi/CLI |
|
||||
| `plugin-sdk/tool-payload` | Wyodrębnianie payloadu narzędzi | Wyodrębnianie znormalizowanych payloadów z obiektów wyników narzędzi |
|
||||
| `plugin-sdk/tool-send` | Wyodrębnianie wysyłki narzędzi | Wyodrębnianie kanonicznych pól celu wysyłki z argumentów narzędzi |
|
||||
| `plugin-sdk/temp-path` | Helpery ścieżek tymczasowych | Współdzielone helpery ścieżek tymczasowego pobierania |
|
||||
| `plugin-sdk/logging-core` | Helpery logowania | Logger podsystemu i helpery redakcji |
|
||||
| `plugin-sdk/markdown-table-runtime` | Helpery tabel Markdown | Helpery trybu tabel Markdown |
|
||||
| `plugin-sdk/reply-payload` | Typy odpowiedzi wiadomości | Typy payloadu odpowiedzi |
|
||||
| `plugin-sdk/provider-setup` | Kuratorowane helpery konfiguracji lokalnych/samohostowanych providerów | Helpery wykrywania/konfiguracji samohostowanych providerów |
|
||||
| `plugin-sdk/self-hosted-provider-setup` | Ukierunkowane helpery konfiguracji samohostowanych providerów zgodnych z OpenAI | Te same helpery wykrywania/konfiguracji samohostowanych providerów |
|
||||
| `plugin-sdk/provider-auth-runtime` | Helpery uwierzytelniania providera w runtime | Helpery rozwiązywania kluczy API w runtime |
|
||||
| `plugin-sdk/provider-auth-api-key` | Helpery konfiguracji klucza API providera | Helpery onboardingu/zapisu profilu klucza API |
|
||||
| `plugin-sdk/provider-auth-result` | Helpery wyniku uwierzytelniania providera | Standardowy builder wyniku uwierzytelniania OAuth |
|
||||
| `plugin-sdk/provider-auth-login` | Helpery interaktywnego logowania providera | Współdzielone helpery interaktywnego logowania |
|
||||
| `plugin-sdk/provider-env-vars` | Helpery zmiennych środowiskowych providera | Helpery wyszukiwania zmiennych środowiskowych do uwierzytelniania providera |
|
||||
| `plugin-sdk/provider-model-shared` | Współdzielone helpery modeli/odtwarzania providera | `ProviderReplayFamily`, `buildProviderReplayFamilyHooks`, `normalizeModelCompat`, współdzielone buildery polityki replay, helpery endpointów providera i helpery normalizacji model-id |
|
||||
| `plugin-sdk/provider-catalog-shared` | Współdzielone helpery katalogu providera | `findCatalogTemplate`, `buildSingleProviderApiKeyCatalog`, `supportsNativeStreamingUsageCompat`, `applyProviderNativeStreamingUsageCompat` |
|
||||
| `plugin-sdk/provider-onboard` | Poprawki onboardingu providera | Helpery konfiguracji onboardingu |
|
||||
| `plugin-sdk/provider-http` | Helpery HTTP providera | Ogólne helpery HTTP/zdolności endpointów providera |
|
||||
| `plugin-sdk/provider-web-fetch` | Helpery web-fetch providera | Helpery rejestracji/cache providera web-fetch |
|
||||
| `plugin-sdk/provider-web-search-config-contract` | Helpery konfiguracji web-search providera | Wąskie helpery konfiguracji/poświadczeń web-search dla providerów, które nie wymagają powiązania włączania pluginu |
|
||||
| `plugin-sdk/provider-web-search-contract` | Helpery kontraktu web-search providera | Wąskie helpery kontraktu konfiguracji/poświadczeń web-search, takie jak `createWebSearchProviderContractFields`, `enablePluginInConfig`, `resolveProviderWebSearchPluginConfig` oraz zakresowe settery/gettery poświadczeń |
|
||||
| `plugin-sdk/provider-web-search` | Helpery web-search providera | Helpery rejestracji/cache/runtime providera web-search |
|
||||
| `plugin-sdk/provider-tools` | Helpery zgodności narzędzi/schematów providera | `ProviderToolCompatFamily`, `buildProviderToolCompatFamilyHooks`, czyszczenie schematów Gemini + diagnostyka oraz helpery zgodności xAI, takie jak `resolveXaiModelCompatPatch` / `applyXaiModelCompat` |
|
||||
| `plugin-sdk/provider-usage` | Helpery użycia providera | `fetchClaudeUsage`, `fetchGeminiUsage`, `fetchGithubCopilotUsage` i inne helpery użycia providera |
|
||||
| `plugin-sdk/provider-stream` | Helpery opakowań strumienia providera | `ProviderStreamFamily`, `buildProviderStreamFamilyHooks`, `composeProviderStreamWrappers`, typy opakowań strumienia oraz współdzielone helpery opakowań Anthropic/Bedrock/Google/Kilocode/Moonshot/OpenAI/OpenRouter/Z.A.I/MiniMax/Copilot |
|
||||
| `plugin-sdk/tool-payload` | Wyodrębnianie ładunku narzędzia | Wyodrębnianie znormalizowanych ładunków z obiektów wyników narzędzi |
|
||||
| `plugin-sdk/tool-send` | Wyodrębnianie wysyłki narzędzia | Wyodrębnianie kanonicznych pól celu wysyłki z argumentów narzędzia |
|
||||
| `plugin-sdk/temp-path` | Pomocniki ścieżek tymczasowych | Współdzielone pomocniki ścieżek tymczasowego pobierania |
|
||||
| `plugin-sdk/logging-core` | Pomocniki logowania | Logger podsystemu i pomocniki redakcji danych |
|
||||
| `plugin-sdk/markdown-table-runtime` | Pomocniki tabel markdown | Pomocniki trybów tabel markdown |
|
||||
| `plugin-sdk/reply-payload` | Typy odpowiedzi wiadomości | Typy ładunku odpowiedzi |
|
||||
| `plugin-sdk/provider-setup` | Kuratorowane pomocniki konfiguracji lokalnych/samohostowanych dostawców | Pomocniki wykrywania/konfiguracji samohostowanych dostawców |
|
||||
| `plugin-sdk/self-hosted-provider-setup` | Ukierunkowane pomocniki konfiguracji samohostowanych dostawców zgodnych z OpenAI | Te same pomocniki wykrywania/konfiguracji samohostowanych dostawców |
|
||||
| `plugin-sdk/provider-auth-runtime` | Pomocniki uwierzytelniania runtime dostawców | Pomocniki runtime rozstrzygania klucza API |
|
||||
| `plugin-sdk/provider-auth-api-key` | Pomocniki konfiguracji klucza API dostawcy | Pomocniki onboardingu/zapisu profilu dla klucza API |
|
||||
| `plugin-sdk/provider-auth-result` | Pomocniki wyniku uwierzytelnienia dostawcy | Standardowy konstruktor wyniku uwierzytelnienia OAuth |
|
||||
| `plugin-sdk/provider-auth-login` | Pomocniki interaktywnego logowania dostawcy | Współdzielone pomocniki logowania interaktywnego |
|
||||
| `plugin-sdk/provider-env-vars` | Pomocniki zmiennych środowiskowych dostawcy | Pomocniki wyszukiwania zmiennych środowiskowych uwierzytelniania dostawcy |
|
||||
| `plugin-sdk/provider-model-shared` | Współdzielone pomocniki modeli/odtwarzania dostawców | `ProviderReplayFamily`, `buildProviderReplayFamilyHooks`, `normalizeModelCompat`, współdzielone konstruktory polityk odtwarzania, pomocniki endpointów dostawców oraz normalizacja identyfikatorów modeli |
|
||||
| `plugin-sdk/provider-catalog-shared` | Współdzielone pomocniki katalogu dostawców | `findCatalogTemplate`, `buildSingleProviderApiKeyCatalog`, `supportsNativeStreamingUsageCompat`, `applyProviderNativeStreamingUsageCompat` |
|
||||
| `plugin-sdk/provider-onboard` | Łatki onboardingu dostawców | Pomocniki konfiguracji onboardingu |
|
||||
| `plugin-sdk/provider-http` | Pomocniki HTTP dostawców | Ogólne pomocniki HTTP/zdolności endpointów dostawców |
|
||||
| `plugin-sdk/provider-web-fetch` | Pomocniki web-fetch dostawców | Pomocniki rejestracji/cache dostawcy web-fetch |
|
||||
| `plugin-sdk/provider-web-search-config-contract` | Pomocniki konfiguracji wyszukiwania w sieci dla dostawców | Wąskie pomocniki konfiguracji/poświadczeń wyszukiwania w sieci dla dostawców, którzy nie potrzebują logiki włączania wtyczki |
|
||||
| `plugin-sdk/provider-web-search-contract` | Pomocniki kontraktu wyszukiwania w sieci dla dostawców | Wąskie pomocniki kontraktu konfiguracji/poświadczeń wyszukiwania w sieci, takie jak `createWebSearchProviderContractFields`, `enablePluginInConfig`, `resolveProviderWebSearchPluginConfig` oraz funkcje ustawiania/pobierania poświadczeń o ograniczonym zakresie |
|
||||
| `plugin-sdk/provider-web-search` | Pomocniki wyszukiwania w sieci dla dostawców | Pomocniki rejestracji/cache/runtime dostawcy wyszukiwania w sieci |
|
||||
| `plugin-sdk/provider-tools` | Pomocniki zgodności narzędzi/schematów dostawców | `ProviderToolCompatFamily`, `buildProviderToolCompatFamilyHooks`, czyszczenie schematu Gemini + diagnostyka oraz pomocniki zgodności xAI, takie jak `resolveXaiModelCompatPatch` / `applyXaiModelCompat` |
|
||||
| `plugin-sdk/provider-usage` | Pomocniki użycia dostawców | `fetchClaudeUsage`, `fetchGeminiUsage`, `fetchGithubCopilotUsage` i inne pomocniki użycia dostawców |
|
||||
| `plugin-sdk/provider-stream` | Pomocniki opakowań strumieni dostawców | `ProviderStreamFamily`, `buildProviderStreamFamilyHooks`, `composeProviderStreamWrappers`, typy opakowań strumieni oraz współdzielone opakowania Anthropic/Bedrock/Google/Kilocode/Moonshot/OpenAI/OpenRouter/Z.A.I/MiniMax/Copilot |
|
||||
| `plugin-sdk/keyed-async-queue` | Uporządkowana kolejka async | `KeyedAsyncQueue` |
|
||||
| `plugin-sdk/media-runtime` | Współdzielone helpery mediów | Helpery pobierania/przekształcania/przechowywania mediów oraz buildery payloadów mediów |
|
||||
| `plugin-sdk/media-generation-runtime` | Współdzielone helpery generowania mediów | Współdzielone helpery failover, wybór kandydatów i komunikaty o brakującym modelu dla generowania obrazów/wideo/muzyki |
|
||||
| `plugin-sdk/media-understanding` | Helpery rozumienia mediów | Typy providerów rozumienia mediów oraz eksporty helperów obrazów/audio dla providerów |
|
||||
| `plugin-sdk/text-runtime` | Współdzielone helpery tekstowe | Usuwanie tekstu widocznego dla asystenta, helpery renderowania/chunkingu/tabel markdown, helpery redakcji, helpery tagów dyrektyw, narzędzia bezpiecznego tekstu i pokrewne helpery tekstu/logowania |
|
||||
| `plugin-sdk/text-chunking` | Helpery chunkingu tekstu | Helper chunkingu tekstu wychodzącego |
|
||||
| `plugin-sdk/speech` | Helpery mowy | Typy providerów mowy oraz eksporty helperów dyrektyw, rejestru i walidacji dla providerów |
|
||||
| `plugin-sdk/speech-core` | Współdzielony rdzeń mowy | Typy providerów mowy, rejestr, dyrektywy, normalizacja |
|
||||
| `plugin-sdk/realtime-transcription` | Helpery transkrypcji realtime | Typy providerów i helpery rejestru |
|
||||
| `plugin-sdk/realtime-voice` | Helpery głosu realtime | Typy providerów i helpery rejestru |
|
||||
| `plugin-sdk/image-generation-core` | Współdzielony rdzeń generowania obrazów | Typy generowania obrazów, failover, uwierzytelnianie i helpery rejestru |
|
||||
| `plugin-sdk/music-generation` | Helpery generowania muzyki | Typy providera/żądania/wyniku generowania muzyki |
|
||||
| `plugin-sdk/music-generation-core` | Współdzielony rdzeń generowania muzyki | Typy generowania muzyki, helpery failover, wyszukiwanie providera i parsowanie model-ref |
|
||||
| `plugin-sdk/video-generation` | Helpery generowania wideo | Typy providera/żądania/wyniku generowania wideo |
|
||||
| `plugin-sdk/video-generation-core` | Współdzielony rdzeń generowania wideo | Typy generowania wideo, helpery failover, wyszukiwanie providera i parsowanie model-ref |
|
||||
| `plugin-sdk/interactive-runtime` | Helpery interaktywnych odpowiedzi | Normalizacja/redukcja payloadu interaktywnych odpowiedzi |
|
||||
| `plugin-sdk/channel-config-primitives` | Prymitywy konfiguracji kanału | Wąskie prymitywy channel config-schema |
|
||||
| `plugin-sdk/channel-config-writes` | Helpery zapisu konfiguracji kanału | Helpery autoryzacji zapisu konfiguracji kanału |
|
||||
| `plugin-sdk/channel-plugin-common` | Współdzielone preludium kanału | Współdzielone eksporty preludium pluginu kanału |
|
||||
| `plugin-sdk/channel-status` | Helpery statusu kanału | Współdzielone helpery snapshotu/podsumowania statusu kanału |
|
||||
| `plugin-sdk/allowlist-config-edit` | Helpery konfiguracji allowlist | Helpery edycji/odczytu konfiguracji allowlist |
|
||||
| `plugin-sdk/group-access` | Helpery dostępu do grup | Współdzielone helpery decyzji dostępu do grup |
|
||||
| `plugin-sdk/direct-dm` | Helpery bezpośrednich DM | Współdzielone helpery autoryzacji/guardów bezpośrednich DM |
|
||||
| `plugin-sdk/extension-shared` | Współdzielone helpery rozszerzeń | Prymitywy helperów kanałów pasywnych/statusu i ambient proxy |
|
||||
| `plugin-sdk/webhook-targets` | Helpery celów webhook | Rejestr celów webhook i helpery instalacji rout |
|
||||
| `plugin-sdk/webhook-path` | Helpery ścieżek webhook | Helpery normalizacji ścieżek webhook |
|
||||
| `plugin-sdk/web-media` | Współdzielone helpery web media | Helpery ładowania mediów zdalnych/lokalnych |
|
||||
| `plugin-sdk/zod` | Reeksport zod | Reeksportowany `zod` dla użytkowników Plugin SDK |
|
||||
| `plugin-sdk/memory-core` | Helpery wbudowanego memory-core | Powierzchnia helperów menedżera pamięci/konfiguracji/plików/CLI |
|
||||
| `plugin-sdk/memory-core-engine-runtime` | Fasada runtime silnika pamięci | Fasada runtime indeksu/wyszukiwania pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-foundation` | Silnik hosta foundation dla pamięci | Eksporty silnika hosta foundation dla pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-embeddings` | Silnik embeddingów hosta dla pamięci | Eksporty silnika embeddingów hosta dla pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-qmd` | Silnik QMD hosta dla pamięci | Eksporty silnika QMD hosta dla pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-storage` | Silnik storage hosta dla pamięci | Eksporty silnika storage hosta dla pamięci |
|
||||
| `plugin-sdk/memory-core-host-multimodal` | Helpery multimodalnego hosta pamięci | Helpery multimodalnego hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-query` | Helpery zapytań hosta pamięci | Helpery zapytań hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-secret` | Helpery sekretów hosta pamięci | Helpery sekretów hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-events` | Helpery dziennika zdarzeń hosta pamięci | Helpery dziennika zdarzeń hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-status` | Helpery statusu hosta pamięci | Helpery statusu hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-cli` | Runtime CLI hosta pamięci | Helpery runtime CLI hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-core` | Główny runtime hosta pamięci | Helpery głównego runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-files` | Helpery plików/runtime hosta pamięci | Helpery plików/runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-host-core` | Alias głównego runtime hosta pamięci | Neutralny wobec dostawcy alias helperów głównego runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-host-events` | Alias dziennika zdarzeń hosta pamięci | Neutralny wobec dostawcy alias helperów dziennika zdarzeń hosta pamięci |
|
||||
| `plugin-sdk/memory-host-files` | Alias plików/runtime hosta pamięci | Neutralny wobec dostawcy alias helperów plików/runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-host-markdown` | Helpery zarządzanego markdown | Współdzielone helpery zarządzanego markdown dla pluginów sąsiadujących z pamięcią |
|
||||
| `plugin-sdk/media-runtime` | Współdzielone pomocniki mediów | Pomocniki pobierania/przekształcania/przechowywania mediów oraz konstruktory ładunków mediów |
|
||||
| `plugin-sdk/media-generation-runtime` | Współdzielone pomocniki generowania mediów | Współdzielone pomocniki failover, wyboru kandydatów i komunikatów o brakujących modelach dla generowania obrazów/wideo/muzyki |
|
||||
| `plugin-sdk/media-understanding` | Pomocniki media-understanding | Typy dostawców media-understanding oraz eksporty pomocników obrazów/audio dla dostawców |
|
||||
| `plugin-sdk/text-runtime` | Współdzielone pomocniki tekstowe | Usuwanie tekstu widocznego dla asystenta, renderowanie/dzielenie/tabele markdown, pomocniki redakcji, pomocniki tagów dyrektyw, bezpieczny tekst i powiązane pomocniki tekstu/logowania |
|
||||
| `plugin-sdk/text-chunking` | Pomocniki dzielenia tekstu | Pomocnik dzielenia tekstu wychodzącego |
|
||||
| `plugin-sdk/speech` | Pomocniki mowy | Typy dostawców mowy oraz eksporty pomocników dyrektyw, rejestru i walidacji dla dostawców |
|
||||
| `plugin-sdk/speech-core` | Współdzielony rdzeń mowy | Typy dostawców mowy, rejestr, dyrektywy, normalizacja |
|
||||
| `plugin-sdk/realtime-transcription` | Pomocniki transkrypcji realtime | Typy dostawców i pomocniki rejestru |
|
||||
| `plugin-sdk/realtime-voice` | Pomocniki głosu realtime | Typy dostawców i pomocniki rejestru |
|
||||
| `plugin-sdk/image-generation-core` | Współdzielony rdzeń generowania obrazów | Typy generowania obrazów, failover, uwierzytelnianie i pomocniki rejestru |
|
||||
| `plugin-sdk/music-generation` | Pomocniki generowania muzyki | Typy dostawcy/żądania/wyniku generowania muzyki |
|
||||
| `plugin-sdk/music-generation-core` | Współdzielony rdzeń generowania muzyki | Typy generowania muzyki, pomocniki failover, wyszukiwanie dostawcy i parsowanie model-ref |
|
||||
| `plugin-sdk/video-generation` | Pomocniki generowania wideo | Typy dostawcy/żądania/wyniku generowania wideo |
|
||||
| `plugin-sdk/video-generation-core` | Współdzielony rdzeń generowania wideo | Typy generowania wideo, pomocniki failover, wyszukiwanie dostawcy i parsowanie model-ref |
|
||||
| `plugin-sdk/interactive-runtime` | Pomocniki odpowiedzi interaktywnych | Normalizacja/redukcja ładunku odpowiedzi interaktywnych |
|
||||
| `plugin-sdk/channel-config-primitives` | Prymitywy konfiguracji kanału | Wąskie prymitywy schematu konfiguracji kanału |
|
||||
| `plugin-sdk/channel-config-writes` | Pomocniki zapisów konfiguracji kanału | Pomocniki autoryzacji zapisu konfiguracji kanału |
|
||||
| `plugin-sdk/channel-plugin-common` | Współdzielone preludium kanału | Eksporty współdzielonego preludium wtyczki kanału |
|
||||
| `plugin-sdk/channel-status` | Pomocniki statusu kanału | Współdzielone pomocniki migawek/podsumowań statusu kanału |
|
||||
| `plugin-sdk/allowlist-config-edit` | Pomocniki konfiguracji listy dozwolonych | Pomocniki edycji/odczytu konfiguracji listy dozwolonych |
|
||||
| `plugin-sdk/group-access` | Pomocniki dostępu grupowego | Współdzielone pomocniki decyzji o dostępie grupowym |
|
||||
| `plugin-sdk/direct-dm` | Pomocniki bezpośrednich DM | Współdzielone pomocniki uwierzytelniania/guardów bezpośrednich DM |
|
||||
| `plugin-sdk/extension-shared` | Współdzielone pomocniki rozszerzeń | Prymitywy pomocników pasywnego kanału/statusu i proxy otoczenia |
|
||||
| `plugin-sdk/webhook-targets` | Pomocniki celów webhooków | Rejestr celów webhooków i pomocniki instalacji tras |
|
||||
| `plugin-sdk/webhook-path` | Pomocniki ścieżek webhooków | Pomocniki normalizacji ścieżek webhooków |
|
||||
| `plugin-sdk/web-media` | Współdzielone pomocniki mediów webowych | Pomocniki ładowania mediów zdalnych/lokalnych |
|
||||
| `plugin-sdk/zod` | Reeksport zod | Reeksport `zod` dla odbiorców Plugin SDK |
|
||||
| `plugin-sdk/memory-core` | Pomocniki dołączonego memory-core | Powierzchnia pomocników menedżera pamięci/konfiguracji/plików/CLI |
|
||||
| `plugin-sdk/memory-core-engine-runtime` | Fasada runtime silnika pamięci | Fasada runtime indeksowania/wyszukiwania pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-foundation` | Hostowy silnik podstawowy pamięci | Eksporty hostowego silnika podstawowego pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-embeddings` | Hostowy silnik embeddingów pamięci | Eksporty hostowego silnika embeddingów pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-qmd` | Hostowy silnik QMD pamięci | Eksporty hostowego silnika QMD pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-storage` | Hostowy silnik przechowywania pamięci | Eksporty hostowego silnika przechowywania pamięci |
|
||||
| `plugin-sdk/memory-core-host-multimodal` | Pomocniki multimodalne hosta pamięci | Pomocniki multimodalne hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-query` | Pomocniki zapytań hosta pamięci | Pomocniki zapytań hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-secret` | Pomocniki sekretów hosta pamięci | Pomocniki sekretów hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-events` | Pomocniki dziennika zdarzeń hosta pamięci | Pomocniki dziennika zdarzeń hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-status` | Pomocniki statusu hosta pamięci | Pomocniki statusu hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-cli` | Runtime CLI hosta pamięci | Pomocniki runtime CLI hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-core` | Główny runtime hosta pamięci | Pomocniki głównego runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-files` | Pomocniki plików/runtime hosta pamięci | Pomocniki plików/runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-host-core` | Alias głównego runtime hosta pamięci | Neutralny względem dostawcy alias pomocników głównego runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-host-events` | Alias dziennika zdarzeń hosta pamięci | Neutralny względem dostawcy alias pomocników dziennika zdarzeń hosta pamięci |
|
||||
| `plugin-sdk/memory-host-files` | Alias plików/runtime hosta pamięci | Neutralny względem dostawcy alias pomocników plików/runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-host-markdown` | Pomocniki zarządzanego markdownu | Współdzielone pomocniki zarządzanego markdownu dla wtyczek powiązanych z pamięcią |
|
||||
| `plugin-sdk/memory-host-search` | Fasada wyszukiwania aktywnej pamięci | Leniwa fasada runtime menedżera wyszukiwania aktywnej pamięci |
|
||||
| `plugin-sdk/memory-host-status` | Alias statusu hosta pamięci | Neutralny wobec dostawcy alias helperów statusu hosta pamięci |
|
||||
| `plugin-sdk/memory-lancedb` | Helpery wbudowanego memory-lancedb | Powierzchnia helperów memory-lancedb |
|
||||
| `plugin-sdk/testing` | Narzędzia testowe | Helpery testowe i mocki |
|
||||
| `plugin-sdk/memory-host-status` | Alias statusu hosta pamięci | Neutralny względem dostawcy alias pomocników statusu hosta pamięci |
|
||||
| `plugin-sdk/memory-lancedb` | Pomocniki dołączonego memory-lancedb | Powierzchnia pomocników memory-lancedb |
|
||||
| `plugin-sdk/testing` | Narzędzia testowe | Pomocniki testowe i mocki |
|
||||
</Accordion>
|
||||
|
||||
Ta tabela celowo zawiera typowy podzbiór migracyjny, a nie pełną
|
||||
powierzchnię SDK. Pełna lista ponad 200 punktów wejścia znajduje się w
|
||||
Ta tabela celowo obejmuje typowy podzbiór do migracji, a nie pełną powierzchnię
|
||||
SDK. Pełna lista ponad 200 punktów wejścia znajduje się w
|
||||
`scripts/lib/plugin-sdk-entrypoints.json`.
|
||||
|
||||
Ta lista nadal zawiera niektóre powierzchnie helperów wbudowanych pluginów, takie jak
|
||||
Ta lista nadal zawiera niektóre pomocnicze punkty integracji dołączonych wtyczek, takie jak
|
||||
`plugin-sdk/feishu`, `plugin-sdk/feishu-setup`, `plugin-sdk/zalo`,
|
||||
`plugin-sdk/zalo-setup` i `plugin-sdk/matrix*`. Pozostają one eksportowane na potrzeby
|
||||
utrzymania i zgodności wbudowanych pluginów, ale celowo
|
||||
pominięto je w typowej tabeli migracyjnej i nie są zalecanym celem dla
|
||||
nowego kodu pluginów.
|
||||
`plugin-sdk/zalo-setup` oraz `plugin-sdk/matrix*`. Nadal są one eksportowane na potrzeby
|
||||
utrzymania dołączonych wtyczek i zgodności, ale celowo
|
||||
pominięto je w tabeli typowej migracji i nie są zalecanym celem dla
|
||||
nowego kodu wtyczek.
|
||||
|
||||
Ta sama zasada dotyczy innych rodzin helperów wbudowanych pluginów, takich jak:
|
||||
Ta sama zasada dotyczy innych rodzin dołączonych pomocników, takich jak:
|
||||
|
||||
- helpery obsługi przeglądarki: `plugin-sdk/browser-cdp`, `plugin-sdk/browser-config-runtime`, `plugin-sdk/browser-config-support`, `plugin-sdk/browser-control-auth`, `plugin-sdk/browser-node-runtime`, `plugin-sdk/browser-profiles`, `plugin-sdk/browser-security-runtime`, `plugin-sdk/browser-setup-tools`, `plugin-sdk/browser-support`
|
||||
- pomocniki obsługi przeglądarki: `plugin-sdk/browser-cdp`, `plugin-sdk/browser-config-runtime`, `plugin-sdk/browser-config-support`, `plugin-sdk/browser-control-auth`, `plugin-sdk/browser-node-runtime`, `plugin-sdk/browser-profiles`, `plugin-sdk/browser-security-runtime`, `plugin-sdk/browser-setup-tools`, `plugin-sdk/browser-support`
|
||||
- Matrix: `plugin-sdk/matrix*`
|
||||
- LINE: `plugin-sdk/line*`
|
||||
- IRC: `plugin-sdk/irc*`
|
||||
- powierzchnie wbudowanych helperów/pluginów, takie jak `plugin-sdk/googlechat`,
|
||||
- powierzchnie dołączonych pomocników/wtyczek, takie jak `plugin-sdk/googlechat`,
|
||||
`plugin-sdk/zalouser`, `plugin-sdk/bluebubbles*`,
|
||||
`plugin-sdk/mattermost*`, `plugin-sdk/msteams`,
|
||||
`plugin-sdk/nextcloud-talk`, `plugin-sdk/nostr`, `plugin-sdk/tlon`,
|
||||
`plugin-sdk/twitch`,
|
||||
`plugin-sdk/github-copilot-login`, `plugin-sdk/github-copilot-token`,
|
||||
`plugin-sdk/diagnostics-otel`, `plugin-sdk/diffs`, `plugin-sdk/llm-task`,
|
||||
`plugin-sdk/thread-ownership` i `plugin-sdk/voice-call`
|
||||
`plugin-sdk/thread-ownership` oraz `plugin-sdk/voice-call`
|
||||
|
||||
`plugin-sdk/github-copilot-token` obecnie udostępnia wąską
|
||||
powierzchnię helperów tokenów `DEFAULT_COPILOT_API_BASE_URL`,
|
||||
`deriveCopilotApiBaseUrlFromToken` i `resolveCopilotApiToken`.
|
||||
powierzchnię pomocników tokenów `DEFAULT_COPILOT_API_BASE_URL`,
|
||||
`deriveCopilotApiBaseUrlFromToken` oraz `resolveCopilotApiToken`.
|
||||
|
||||
Używaj najwęższego importu, który pasuje do zadania. Jeśli nie możesz znaleźć eksportu,
|
||||
sprawdź źródło w `src/plugin-sdk/` lub zapytaj na Discord.
|
||||
sprawdź źródło w `src/plugin-sdk/` albo zapytaj na Discord.
|
||||
|
||||
## Harmonogram usunięcia
|
||||
|
||||
| Kiedy | Co się dzieje |
|
||||
| ---------------------- | ---------------------------------------------------------------------- |
|
||||
| **Teraz** | Przestarzałe powierzchnie emitują ostrzeżenia w runtime |
|
||||
| **Następna główna wersja** | Przestarzałe powierzchnie zostaną usunięte; pluginy nadal z nich korzystające przestaną działać |
|
||||
| Kiedy | Co się stanie |
|
||||
| ---------------------- | ----------------------------------------------------------------------- |
|
||||
| **Teraz** | Przestarzałe powierzchnie emitują ostrzeżenia runtime |
|
||||
| **Następne główne wydanie** | Przestarzałe powierzchnie zostaną usunięte; wtyczki, które nadal z nich korzystają, przestaną działać |
|
||||
|
||||
Wszystkie podstawowe pluginy zostały już zmigrowane. Zewnętrzne pluginy powinny
|
||||
przeprowadzić migrację przed następną główną wersją.
|
||||
Wszystkie główne wtyczki zostały już zmigrowane. Zewnętrzne wtyczki powinny przeprowadzić
|
||||
migrację przed następnym głównym wydaniem.
|
||||
|
||||
## Tymczasowe wyciszanie ostrzeżeń
|
||||
|
||||
@ -401,13 +397,13 @@ OPENCLAW_SUPPRESS_PLUGIN_SDK_COMPAT_WARNING=1 openclaw gateway run
|
||||
OPENCLAW_SUPPRESS_EXTENSION_API_WARNING=1 openclaw gateway run
|
||||
```
|
||||
|
||||
To tymczasowa furtka awaryjna, a nie trwałe rozwiązanie.
|
||||
To tymczasowe wyjście awaryjne, a nie trwałe rozwiązanie.
|
||||
|
||||
## Powiązane
|
||||
|
||||
- [Pierwsze kroki](/pl/plugins/building-plugins) — zbuduj swój pierwszy plugin
|
||||
- [Pierwsze kroki](/pl/plugins/building-plugins) — zbuduj swoją pierwszą wtyczkę
|
||||
- [Przegląd SDK](/pl/plugins/sdk-overview) — pełne odniesienie do importów podścieżek
|
||||
- [Pluginy kanałów](/pl/plugins/sdk-channel-plugins) — tworzenie pluginów kanałów
|
||||
- [Pluginy providerów](/pl/plugins/sdk-provider-plugins) — tworzenie pluginów providerów
|
||||
- [Wnętrze pluginów](/pl/plugins/architecture) — szczegółowe omówienie architektury
|
||||
- [Manifest pluginu](/pl/plugins/manifest) — odniesienie do schematu manifestu
|
||||
- [Wtyczki kanałów](/pl/plugins/sdk-channel-plugins) — tworzenie wtyczek kanałów
|
||||
- [Wtyczki dostawców](/pl/plugins/sdk-provider-plugins) — tworzenie wtyczek dostawców
|
||||
- [Wewnętrzne elementy wtyczek](/pl/plugins/architecture) — szczegółowe omówienie architektury
|
||||
- [Manifest wtyczki](/pl/plugins/manifest) — odniesienie do schematu manifestu
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
---
|
||||
read_when:
|
||||
- Musisz wiedzieć, z której ścieżki podrzędnej SDK importować
|
||||
- Chcesz uzyskać dokumentację referencyjną wszystkich metod rejestracji w `OpenClawPluginApi`
|
||||
- Chcesz mieć dokumentację wszystkich metod rejestracji w OpenClawPluginApi
|
||||
- Szukasz konkretnego eksportu SDK
|
||||
sidebarTitle: SDK Overview
|
||||
summary: Mapa importów, dokumentacja referencyjna API rejestracji i architektura SDK
|
||||
summary: Mapa importów, dokumentacja API rejestracji i architektura SDK
|
||||
title: Przegląd Plugin SDK
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T09:45:54Z"
|
||||
generated_at: "2026-04-09T01:30:58Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 6e7b420eb0f3faa8916357d52df949f6c9a46f1c843a1e6a0c0b8bb26db6cbff
|
||||
source_hash: bf205af060971931df97dca4af5110ce173d2b7c12f56ad7c62d664a402f2381
|
||||
source_path: plugins/sdk-overview.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -22,7 +22,7 @@ dokumentacją referencyjną dla **tego, co importować** i **co można rejestrow
|
||||
|
||||
<Tip>
|
||||
**Szukasz przewodnika krok po kroku?**
|
||||
- Pierwszy plugin? Zacznij od [Wprowadzenia](/pl/plugins/building-plugins)
|
||||
- Pierwszy plugin? Zacznij od [Pierwsze kroki](/pl/plugins/building-plugins)
|
||||
- Plugin kanału? Zobacz [Pluginy kanałów](/pl/plugins/sdk-channel-plugins)
|
||||
- Plugin dostawcy? Zobacz [Pluginy dostawców](/pl/plugins/sdk-provider-plugins)
|
||||
</Tip>
|
||||
@ -36,269 +36,268 @@ import { definePluginEntry } from "openclaw/plugin-sdk/plugin-entry";
|
||||
import { defineChannelPluginEntry } from "openclaw/plugin-sdk/channel-core";
|
||||
```
|
||||
|
||||
Każda ścieżka podrzędna to mały, samodzielny moduł. Dzięki temu uruchamianie
|
||||
jest szybkie i można uniknąć problemów z cyklicznymi zależnościami. W przypadku
|
||||
pomocników wejścia/budowania specyficznych dla kanałów preferuj
|
||||
`openclaw/plugin-sdk/channel-core`; zachowaj `openclaw/plugin-sdk/core` dla
|
||||
szerszej powierzchni parasolowej i współdzielonych helperów, takich jak
|
||||
Każda ścieżka podrzędna jest małym, samowystarczalnym modułem. Dzięki temu uruchamianie pozostaje szybkie i
|
||||
zapobiega to problemom z zależnościami cyklicznymi. W przypadku helperów wejścia/budowania specyficznych dla kanałów
|
||||
preferuj `openclaw/plugin-sdk/channel-core`; `openclaw/plugin-sdk/core` zachowaj dla
|
||||
szerszej powierzchni zbiorczej i współdzielonych helperów, takich jak
|
||||
`buildChannelConfigSchema`.
|
||||
|
||||
Nie dodawaj ani nie polegaj na wygodnych warstwach nazwanych od dostawców, takich jak
|
||||
`openclaw/plugin-sdk/slack`, `openclaw/plugin-sdk/discord`,
|
||||
`openclaw/plugin-sdk/signal`, `openclaw/plugin-sdk/whatsapp` ani
|
||||
warstwach helperów markowanych kanałem. Zestawione pluginy powinny składać
|
||||
ogólne ścieżki podrzędne SDK we własnych barrelach `api.ts` lub `runtime-api.ts`, a rdzeń
|
||||
powinien albo używać tych lokalnych barrelów pluginu, albo dodać wąski ogólny
|
||||
kontrakt SDK, gdy potrzeba jest rzeczywiście międzykanałowa.
|
||||
helperowych warstwach oznaczonych marką kanału. Bundlowane pluginy powinny składać ogólne
|
||||
ścieżki podrzędne SDK we własnych barrelach `api.ts` lub `runtime-api.ts`, a rdzeń
|
||||
powinien albo używać tych lokalnych barrelów pluginu, albo dodać wąski ogólny kontrakt SDK,
|
||||
gdy potrzeba rzeczywiście dotyczy wielu kanałów.
|
||||
|
||||
Wygenerowana mapa eksportów nadal zawiera mały zestaw warstw helperów
|
||||
zestawionych pluginów, takich jak `plugin-sdk/feishu`, `plugin-sdk/feishu-setup`,
|
||||
Wygenerowana mapa eksportów nadal zawiera mały zestaw helperowych warstw bundlowanych pluginów,
|
||||
takich jak `plugin-sdk/feishu`, `plugin-sdk/feishu-setup`,
|
||||
`plugin-sdk/zalo`, `plugin-sdk/zalo-setup` i `plugin-sdk/matrix*`. Te
|
||||
ścieżki podrzędne istnieją wyłącznie na potrzeby utrzymania i zgodności zestawionych pluginów;
|
||||
celowo pominięto je w typowej tabeli poniżej i nie są zalecaną
|
||||
ścieżką importu dla nowych pluginów zewnętrznych.
|
||||
ścieżki podrzędne istnieją wyłącznie dla utrzymania i zgodności bundlowanych pluginów; celowo pominięto je
|
||||
w standardowej tabeli poniżej i nie są zalecaną ścieżką importu dla nowych pluginów zewnętrznych.
|
||||
|
||||
## Dokumentacja referencyjna ścieżek podrzędnych
|
||||
## Dokumentacja ścieżek podrzędnych
|
||||
|
||||
Najczęściej używane ścieżki podrzędne, pogrupowane według przeznaczenia. Wygenerowana pełna lista
|
||||
ponad 200 ścieżek podrzędnych znajduje się w `scripts/lib/plugin-sdk-entrypoints.json`.
|
||||
|
||||
Zarezerwowane ścieżki podrzędne helperów zestawionych pluginów nadal pojawiają się na tej wygenerowanej liście.
|
||||
Traktuj je jako szczegół implementacyjny/powierzchnie zgodności, chyba że dana strona dokumentacji
|
||||
Zarezerwowane helperowe ścieżki podrzędne bundlowanych pluginów nadal pojawiają się na tej wygenerowanej liście.
|
||||
Traktuj je jako szczegóły implementacyjne/powierzchnie zgodności, chyba że strona dokumentacji
|
||||
wyraźnie promuje którąś z nich jako publiczną.
|
||||
|
||||
### Wejście pluginu
|
||||
|
||||
| Ścieżka podrzędna | Kluczowe eksporty |
|
||||
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `plugin-sdk/plugin-entry` | `definePluginEntry` |
|
||||
| Subpath | Key exports |
|
||||
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `plugin-sdk/plugin-entry` | `definePluginEntry` |
|
||||
| `plugin-sdk/core` | `defineChannelPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase`, `defineSetupPluginEntry`, `buildChannelConfigSchema` |
|
||||
| `plugin-sdk/config-schema` | `OpenClawSchema` |
|
||||
| `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry` |
|
||||
| `plugin-sdk/config-schema` | `OpenClawSchema` |
|
||||
| `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry` |
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Ścieżki podrzędne kanałów">
|
||||
| Ścieżka podrzędna | Kluczowe eksporty |
|
||||
| Subpath | Key exports |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/channel-core` | `defineChannelPluginEntry`, `defineSetupPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase` |
|
||||
| `plugin-sdk/config-schema` | Eksport głównego schematu Zod `openclaw.json` (`OpenClawSchema`) |
|
||||
| `plugin-sdk/channel-setup` | `createOptionalChannelSetupSurface`, `createOptionalChannelSetupAdapter`, `createOptionalChannelSetupWizard`, plus `DEFAULT_ACCOUNT_ID`, `createTopLevelChannelDmPolicy`, `setSetupChannelEnabled`, `splitSetupEntries` |
|
||||
| `plugin-sdk/setup` | Współdzielone helpery kreatora konfiguracji, prompty allowlist i kreatory statusu konfiguracji |
|
||||
| `plugin-sdk/channel-setup` | `createOptionalChannelSetupSurface`, `createOptionalChannelSetupAdapter`, `createOptionalChannelSetupWizard`, a także `DEFAULT_ACCOUNT_ID`, `createTopLevelChannelDmPolicy`, `setSetupChannelEnabled`, `splitSetupEntries` |
|
||||
| `plugin-sdk/setup` | Współdzielone helpery kreatora konfiguracji, prompty allowlist i konstruktory statusu konfiguracji |
|
||||
| `plugin-sdk/setup-runtime` | `createPatchedAccountSetupAdapter`, `createEnvPatchedAccountSetupAdapter`, `createSetupInputPresenceValidator`, `noteChannelLookupFailure`, `noteChannelLookupSummary`, `promptResolvedAllowFrom`, `splitSetupEntries`, `createAllowlistSetupWizardProxy`, `createDelegatedSetupWizardProxy` |
|
||||
| `plugin-sdk/setup-adapter-runtime` | `createEnvPatchedAccountSetupAdapter` |
|
||||
| `plugin-sdk/setup-tools` | `formatCliCommand`, `detectBinary`, `extractArchive`, `resolveBrewExecutable`, `formatDocsLink`, `CONFIG_DIR` |
|
||||
| `plugin-sdk/account-core` | Helpery konfiguracji/wielu kont/bramki akcji oraz helpery awaryjnego wyboru konta domyślnego |
|
||||
| `plugin-sdk/account-core` | Helpery konfiguracji/wymuszania działań dla wielu kont oraz helpery zapasowego użycia konta domyślnego |
|
||||
| `plugin-sdk/account-id` | `DEFAULT_ACCOUNT_ID`, helpery normalizacji identyfikatora konta |
|
||||
| `plugin-sdk/account-resolution` | Helpery wyszukiwania kont i awaryjnego wyboru domyślnego |
|
||||
| `plugin-sdk/account-helpers` | Wąskie helpery list kont/akcji na kontach |
|
||||
| `plugin-sdk/account-resolution` | Helpery wyszukiwania konta i zapasowego użycia wartości domyślnej |
|
||||
| `plugin-sdk/account-helpers` | Wąskie helpery list działań/kont |
|
||||
| `plugin-sdk/channel-pairing` | `createChannelPairingController` |
|
||||
| `plugin-sdk/channel-reply-pipeline` | `createChannelReplyPipeline` |
|
||||
| `plugin-sdk/channel-config-helpers` | `createHybridChannelConfigAdapter` |
|
||||
| `plugin-sdk/channel-config-schema` | Typy schematu konfiguracji kanału |
|
||||
| `plugin-sdk/telegram-command-config` | Helpery normalizacji/walidacji niestandardowych poleceń Telegram z awaryjną obsługą kontraktu zestawionego |
|
||||
| `plugin-sdk/telegram-command-config` | Helpery normalizacji/walidacji niestandardowych poleceń Telegram z zapasową obsługą kontraktu bundlowanego |
|
||||
| `plugin-sdk/channel-policy` | `resolveChannelGroupRequireMention` |
|
||||
| `plugin-sdk/channel-lifecycle` | `createAccountStatusSink` |
|
||||
| `plugin-sdk/inbound-envelope` | Współdzielone helpery budowania tras przychodzących i kopert |
|
||||
| `plugin-sdk/inbound-reply-dispatch` | Współdzielone helpery zapisu i dyspozycji wiadomości przychodzących |
|
||||
| `plugin-sdk/inbound-envelope` | Współdzielone helpery tras przychodzących i konstruktora kopert |
|
||||
| `plugin-sdk/inbound-reply-dispatch` | Współdzielone helpery zapisu i wysyłania odpowiedzi przychodzących |
|
||||
| `plugin-sdk/messaging-targets` | Helpery parsowania/dopasowywania celów |
|
||||
| `plugin-sdk/outbound-media` | Współdzielone helpery ładowania mediów wychodzących |
|
||||
| `plugin-sdk/outbound-runtime` | Helpery tożsamości wychodzącej/delegowania wysyłki |
|
||||
| `plugin-sdk/thread-bindings-runtime` | Helpery cyklu życia i adapterów powiązań wątków |
|
||||
| `plugin-sdk/agent-media-payload` | Starszy kreator payloadów mediów agenta |
|
||||
| `plugin-sdk/conversation-runtime` | Powiązania konwersacji/wątków, parowanie i helpery skonfigurowanych powiązań |
|
||||
| `plugin-sdk/runtime-config-snapshot` | Helper migawki konfiguracji środowiska wykonawczego |
|
||||
| `plugin-sdk/runtime-group-policy` | Helpery rozstrzygania zasad grupowych środowiska wykonawczego |
|
||||
| `plugin-sdk/outbound-runtime` | Helpery tożsamości wychodzącej i delegowania wysyłki |
|
||||
| `plugin-sdk/thread-bindings-runtime` | Helpery cyklu życia i adapterów wiązań wątków |
|
||||
| `plugin-sdk/agent-media-payload` | Starszy konstruktor ładunku multimediów agenta |
|
||||
| `plugin-sdk/conversation-runtime` | Helpery wiązania rozmów/wątków, parowania i skonfigurowanych wiązań |
|
||||
| `plugin-sdk/runtime-config-snapshot` | Helper migawki konfiguracji runtime |
|
||||
| `plugin-sdk/runtime-group-policy` | Helpery rozstrzygania polityki grup runtime |
|
||||
| `plugin-sdk/channel-status` | Współdzielone helpery migawek/podsumowań statusu kanału |
|
||||
| `plugin-sdk/channel-config-primitives` | Wąskie prymitywy schematu konfiguracji kanału |
|
||||
| `plugin-sdk/channel-config-writes` | Helpery autoryzacji zapisu konfiguracji kanału |
|
||||
| `plugin-sdk/channel-plugin-common` | Współdzielone eksporty preludium pluginów kanałów |
|
||||
| `plugin-sdk/channel-plugin-common` | Współdzielone eksporty preludium pluginu kanału |
|
||||
| `plugin-sdk/allowlist-config-edit` | Helpery odczytu/edycji konfiguracji allowlist |
|
||||
| `plugin-sdk/group-access` | Współdzielone helpery decyzji o dostępie grupowym |
|
||||
| `plugin-sdk/direct-dm` | Współdzielone helpery uwierzytelniania/ochrony bezpośrednich DM |
|
||||
| `plugin-sdk/interactive-runtime` | Helpery normalizacji/redukcji payloadów odpowiedzi interaktywnych |
|
||||
| `plugin-sdk/channel-inbound` | Pomocniki debounce dla ruchu przychodzącego, dopasowywania wzmianek, zasad wzmianek i helpery kopert |
|
||||
| `plugin-sdk/group-access` | Współdzielone helpery decyzji dostępu do grup |
|
||||
| `plugin-sdk/direct-dm` | Współdzielone helpery auth i ochrony direct-DM |
|
||||
| `plugin-sdk/interactive-runtime` | Helpery normalizacji/redukcji ładunków odpowiedzi interaktywnych |
|
||||
| `plugin-sdk/channel-inbound` | Helpery debounce wiadomości przychodzących, dopasowania mention, polityki mention i kopert |
|
||||
| `plugin-sdk/channel-send-result` | Typy wyników odpowiedzi |
|
||||
| `plugin-sdk/channel-actions` | `createMessageToolButtonsSchema`, `createMessageToolCardSchema` |
|
||||
| `plugin-sdk/channel-targets` | Helpery parsowania/dopasowywania celów |
|
||||
| `plugin-sdk/channel-contract` | Typy kontraktu kanału |
|
||||
| `plugin-sdk/channel-feedback` | Łączenie informacji zwrotnych/reakcji |
|
||||
| `plugin-sdk/channel-secret-runtime` | Wąskie helpery kontraktu sekretów, takie jak `collectSimpleChannelFieldAssignments`, `getChannelSurface`, `pushAssignment` oraz typy celów sekretów |
|
||||
| `plugin-sdk/channel-feedback` | Okablowanie feedbacku/reakcji |
|
||||
| `plugin-sdk/channel-secret-runtime` | Wąskie helpery kontraktu sekretów, takie jak `collectSimpleChannelFieldAssignments`, `getChannelSurface`, `pushAssignment`, oraz typy celów sekretów |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Ścieżki podrzędne dostawców">
|
||||
| Ścieżka podrzędna | Kluczowe eksporty |
|
||||
| Subpath | Key exports |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry` |
|
||||
| `plugin-sdk/provider-setup` | Kuratorowane helpery konfiguracji lokalnych/samohostowanych dostawców |
|
||||
| `plugin-sdk/self-hosted-provider-setup` | Skoncentrowane helpery konfiguracji samohostowanych dostawców zgodnych z OpenAI |
|
||||
| `plugin-sdk/cli-backend` | Domyślne ustawienia backendu CLI + stałe watchdog |
|
||||
| `plugin-sdk/provider-auth-runtime` | Helpery rozstrzygania kluczy API w czasie działania dla pluginów dostawców |
|
||||
| `plugin-sdk/provider-setup` | Wyselekcjonowane helpery konfiguracji lokalnych/samohostowanych dostawców |
|
||||
| `plugin-sdk/self-hosted-provider-setup` | Ukierunkowane helpery konfiguracji samohostowanego dostawcy zgodnego z OpenAI |
|
||||
| `plugin-sdk/cli-backend` | Domyślne wartości backendu CLI i stałe watchdog |
|
||||
| `plugin-sdk/provider-auth-runtime` | Helpery runtime do rozstrzygania kluczy API dla pluginów dostawców |
|
||||
| `plugin-sdk/provider-auth-api-key` | Helpery onboardingu/zapisu profilu klucza API, takie jak `upsertApiKeyProfile` |
|
||||
| `plugin-sdk/provider-auth-result` | Standardowy kreator wyniku uwierzytelniania OAuth |
|
||||
| `plugin-sdk/provider-auth-result` | Standardowy konstruktor wyniku auth OAuth |
|
||||
| `plugin-sdk/provider-auth-login` | Współdzielone interaktywne helpery logowania dla pluginów dostawców |
|
||||
| `plugin-sdk/provider-env-vars` | Helpery wyszukiwania zmiennych środowiskowych uwierzytelniania dostawców |
|
||||
| `plugin-sdk/provider-env-vars` | Helpery wyszukiwania zmiennych env auth dostawcy |
|
||||
| `plugin-sdk/provider-auth` | `createProviderApiKeyAuthMethod`, `ensureApiKeyFromOptionEnvOrPrompt`, `upsertAuthProfile`, `upsertApiKeyProfile`, `writeOAuthCredentials` |
|
||||
| `plugin-sdk/provider-model-shared` | `ProviderReplayFamily`, `buildProviderReplayFamilyHooks`, `normalizeModelCompat`, współdzielone kreatory zasad powtórzeń, helpery punktów końcowych dostawców oraz helpery normalizacji identyfikatorów modeli, takie jak `normalizeNativeXaiModelId` |
|
||||
| `plugin-sdk/provider-model-shared` | `ProviderReplayFamily`, `buildProviderReplayFamilyHooks`, `normalizeModelCompat`, współdzielone konstruktory polityki replay, helpery endpointów dostawców oraz helpery normalizacji identyfikatorów modeli, takie jak `normalizeNativeXaiModelId` |
|
||||
| `plugin-sdk/provider-catalog-shared` | `findCatalogTemplate`, `buildSingleProviderApiKeyCatalog`, `supportsNativeStreamingUsageCompat`, `applyProviderNativeStreamingUsageCompat` |
|
||||
| `plugin-sdk/provider-http` | Ogólne helpery HTTP/możliwości punktów końcowych dostawców |
|
||||
| `plugin-sdk/provider-http` | Ogólne helpery możliwości HTTP/endpointów dostawców |
|
||||
| `plugin-sdk/provider-web-fetch-contract` | Wąskie helpery kontraktu konfiguracji/wyboru web-fetch, takie jak `enablePluginInConfig` i `WebFetchProviderPlugin` |
|
||||
| `plugin-sdk/provider-web-fetch` | Helpery rejestracji/pamięci podręcznej dostawców web-fetch |
|
||||
| `plugin-sdk/provider-web-search-config-contract` | Wąskie helpery konfiguracji/danych uwierzytelniających web-search dla dostawców, którzy nie potrzebują mechanizmu włączania pluginu |
|
||||
| `plugin-sdk/provider-web-search-contract` | Wąskie helpery kontraktu konfiguracji/danych uwierzytelniających web-search, takie jak `createWebSearchProviderContractFields`, `enablePluginInConfig`, `resolveProviderWebSearchPluginConfig` oraz zakresowane settery/gettery danych uwierzytelniających |
|
||||
| `plugin-sdk/provider-web-search` | Helpery rejestracji/pamięci podręcznej/środowiska wykonawczego dostawców web-search |
|
||||
| `plugin-sdk/provider-tools` | `ProviderToolCompatFamily`, `buildProviderToolCompatFamilyHooks`, czyszczenie schematów Gemini + diagnostyka oraz helpery zgodności xAI, takie jak `resolveXaiModelCompatPatch` / `applyXaiModelCompat` |
|
||||
| `plugin-sdk/provider-web-fetch` | Helpery rejestracji/cache dostawców web-fetch |
|
||||
| `plugin-sdk/provider-web-search-config-contract` | Wąskie helpery konfiguracji/poświadczeń web search dla dostawców, którzy nie potrzebują okablowania włączania pluginu |
|
||||
| `plugin-sdk/provider-web-search-contract` | Wąskie helpery kontraktu konfiguracji/poświadczeń web search, takie jak `createWebSearchProviderContractFields`, `enablePluginInConfig`, `resolveProviderWebSearchPluginConfig` oraz zakresowane settery/gettery poświadczeń |
|
||||
| `plugin-sdk/provider-web-search` | Helpery rejestracji/cache/runtime dostawców web search |
|
||||
| `plugin-sdk/provider-tools` | `ProviderToolCompatFamily`, `buildProviderToolCompatFamilyHooks`, czyszczenie schematu Gemini + diagnostyka oraz helpery zgodności xAI, takie jak `resolveXaiModelCompatPatch` / `applyXaiModelCompat` |
|
||||
| `plugin-sdk/provider-usage` | `fetchClaudeUsage` i podobne |
|
||||
| `plugin-sdk/provider-stream` | `ProviderStreamFamily`, `buildProviderStreamFamilyHooks`, `composeProviderStreamWrappers`, typy opakowań strumieni oraz współdzielone helpery opakowań Anthropic/Bedrock/Google/Kilocode/Moonshot/OpenAI/OpenRouter/Z.A.I/MiniMax/Copilot |
|
||||
| `plugin-sdk/provider-stream` | `ProviderStreamFamily`, `buildProviderStreamFamilyHooks`, `composeProviderStreamWrappers`, typy wrapperów strumieni oraz współdzielone helpery wrapperów Anthropic/Bedrock/Google/Kilocode/Moonshot/OpenAI/OpenRouter/Z.A.I/MiniMax/Copilot |
|
||||
| `plugin-sdk/provider-onboard` | Helpery łatania konfiguracji onboardingu |
|
||||
| `plugin-sdk/global-singleton` | Helpery singletonów/map/pamięci podręcznej lokalnych dla procesu |
|
||||
| `plugin-sdk/global-singleton` | Helpery singletonów/map/cache lokalnych dla procesu |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Ścieżki podrzędne uwierzytelniania i bezpieczeństwa">
|
||||
| Ścieżka podrzędna | Kluczowe eksporty |
|
||||
<Accordion title="Ścieżki podrzędne auth i bezpieczeństwa">
|
||||
| Subpath | Key exports |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/command-auth` | `resolveControlCommandGate`, helpery rejestru poleceń, helpery autoryzacji nadawcy |
|
||||
| `plugin-sdk/approval-auth-runtime` | Helpery rozstrzygania zatwierdzających i uwierzytelniania akcji w tym samym czacie |
|
||||
| `plugin-sdk/approval-client-runtime` | Helpery profili/filtrów zatwierdzania dla natywnego wykonania |
|
||||
| `plugin-sdk/approval-delivery-runtime` | Adaptery możliwości/dostarczania natywnego zatwierdzania |
|
||||
| `plugin-sdk/approval-gateway-runtime` | Współdzielony helper rozstrzygania bramy zatwierdzania |
|
||||
| `plugin-sdk/approval-handler-adapter-runtime` | Lekkie helpery ładowania adapterów natywnego zatwierdzania dla gorących punktów wejścia kanałów |
|
||||
| `plugin-sdk/approval-handler-runtime` | Szersze helpery środowiska wykonawczego obsługi zatwierdzeń; gdy to wystarcza, preferuj węższe warstwy adapter/gateway |
|
||||
| `plugin-sdk/approval-native-runtime` | Helpery celów natywnego zatwierdzania + powiązań kont |
|
||||
| `plugin-sdk/approval-reply-runtime` | Helpery payloadów odpowiedzi zatwierdzeń exec/pluginów |
|
||||
| `plugin-sdk/command-auth-native` | Natywne helpery uwierzytelniania poleceń + helpery celów sesji natywnych |
|
||||
| `plugin-sdk/command-status` | Konstruktory wiadomości poleceń/pomocy, takie jak `buildCommandsMessagePaginated` i `buildHelpMessage` |
|
||||
| `plugin-sdk/approval-auth-runtime` | Helpery rozstrzygania approvera i auth działań w tym samym czacie |
|
||||
| `plugin-sdk/approval-client-runtime` | Natywne helpery profili/filtrów zatwierdzania exec |
|
||||
| `plugin-sdk/approval-delivery-runtime` | Natywne adaptery możliwości/dostarczania zatwierdzeń |
|
||||
| `plugin-sdk/approval-gateway-runtime` | Współdzielony helper rozstrzygania gateway zatwierdzeń |
|
||||
| `plugin-sdk/approval-handler-adapter-runtime` | Lekkie helpery ładowania natywnych adapterów zatwierdzeń dla gorących punktów wejścia kanałów |
|
||||
| `plugin-sdk/approval-handler-runtime` | Szersze helpery runtime obsługi zatwierdzeń; gdy wystarczą, preferuj węższe warstwy adapter/gateway |
|
||||
| `plugin-sdk/approval-native-runtime` | Natywne helpery celów zatwierdzeń i wiązania kont |
|
||||
| `plugin-sdk/approval-reply-runtime` | Helpery ładunku odpowiedzi zatwierdzeń exec/pluginów |
|
||||
| `plugin-sdk/command-auth-native` | Natywne helpery auth poleceń i natywnych celów sesji |
|
||||
| `plugin-sdk/command-detection` | Współdzielone helpery wykrywania poleceń |
|
||||
| `plugin-sdk/command-surface` | Normalizacja treści poleceń i helpery powierzchni poleceń |
|
||||
| `plugin-sdk/command-surface` | Helpery normalizacji treści poleceń i powierzchni poleceń |
|
||||
| `plugin-sdk/allow-from` | `formatAllowFromLowercase` |
|
||||
| `plugin-sdk/channel-secret-runtime` | Wąskie helpery zbierania kontraktu sekretów dla powierzchni sekretów kanału/pluginu |
|
||||
| `plugin-sdk/secret-ref-runtime` | Wąskie helpery `coerceSecretRef` i typowania SecretRef do parsowania kontraktów sekretów/konfiguracji |
|
||||
| `plugin-sdk/security-runtime` | Współdzielone helpery zaufania, ograniczania DM, treści zewnętrznych i zbierania sekretów |
|
||||
| `plugin-sdk/ssrf-policy` | Helpery allowlist hostów i zasad SSRF dla sieci prywatnych |
|
||||
| `plugin-sdk/ssrf-runtime` | Helpery pinned-dispatcher, fetch chronionego przez SSRF i zasad SSRF |
|
||||
| `plugin-sdk/channel-secret-runtime` | Wąskie helpery zbierania kontraktów sekretów dla powierzchni sekretów kanałów/pluginów |
|
||||
| `plugin-sdk/secret-ref-runtime` | Wąskie helpery `coerceSecretRef` i typowania SecretRef dla parsowania kontraktów sekretów/konfiguracji |
|
||||
| `plugin-sdk/security-runtime` | Współdzielone helpery zaufania, bramkowania DM, treści zewnętrznych i zbierania sekretów |
|
||||
| `plugin-sdk/ssrf-policy` | Helpery allowlist hostów i polityki SSRF dla sieci prywatnych |
|
||||
| `plugin-sdk/ssrf-runtime` | Helpery pinned-dispatcher, fetch chronionego przez SSRF i polityki SSRF |
|
||||
| `plugin-sdk/secret-input` | Helpery parsowania wejść sekretów |
|
||||
| `plugin-sdk/webhook-ingress` | Helpery żądań/celów webhooków |
|
||||
| `plugin-sdk/webhook-request-guards` | Helpery rozmiaru treści/timeoutów żądań |
|
||||
| `plugin-sdk/webhook-request-guards` | Helpery rozmiaru ciała żądania/timeoutu |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Ścieżki podrzędne środowiska wykonawczego i przechowywania">
|
||||
| Ścieżka podrzędna | Kluczowe eksporty |
|
||||
<Accordion title="Ścieżki podrzędne runtime i przechowywania">
|
||||
| Subpath | Key exports |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/runtime` | Szerokie helpery środowiska wykonawczego/logowania/kopii zapasowych/instalacji pluginów |
|
||||
| `plugin-sdk/runtime-env` | Wąskie helpery środowiska wykonawczego env, loggera, timeoutów, ponowień i backoff |
|
||||
| `plugin-sdk/channel-runtime-context` | Ogólne helpery rejestracji i wyszukiwania kontekstu środowiska wykonawczego kanału |
|
||||
| `plugin-sdk/runtime` | Szerokie helpery runtime/logowania/kopii zapasowych/instalacji pluginów |
|
||||
| `plugin-sdk/runtime-env` | Wąskie helpery env runtime, loggera, timeoutu, retry i backoff |
|
||||
| `plugin-sdk/channel-runtime-context` | Ogólne helpery rejestracji i wyszukiwania kontekstu runtime kanałów |
|
||||
| `plugin-sdk/runtime-store` | `createPluginRuntimeStore` |
|
||||
| `plugin-sdk/plugin-runtime` | Współdzielone helpery poleceń/hooków/HTTP/interaktywne pluginu |
|
||||
| `plugin-sdk/plugin-runtime` | Współdzielone helpery poleceń/hooków/http/interaktywności pluginów |
|
||||
| `plugin-sdk/hook-runtime` | Współdzielone helpery potoku webhooków/wewnętrznych hooków |
|
||||
| `plugin-sdk/lazy-runtime` | Helpery opóźnionego importu/powiązań środowiska wykonawczego, takie jak `createLazyRuntimeModule`, `createLazyRuntimeMethod` i `createLazyRuntimeSurface` |
|
||||
| `plugin-sdk/lazy-runtime` | Helpery leniwego importu/powiązań runtime, takie jak `createLazyRuntimeModule`, `createLazyRuntimeMethod` i `createLazyRuntimeSurface` |
|
||||
| `plugin-sdk/process-runtime` | Helpery wykonywania procesów |
|
||||
| `plugin-sdk/cli-runtime` | Helpery formatowania CLI, oczekiwania i wersji |
|
||||
| `plugin-sdk/gateway-runtime` | Helpery klienta gateway i łatania statusu kanału |
|
||||
| `plugin-sdk/gateway-runtime` | Helpery klienta Gateway i łatania statusu kanałów |
|
||||
| `plugin-sdk/config-runtime` | Helpery ładowania/zapisu konfiguracji |
|
||||
| `plugin-sdk/telegram-command-config` | Normalizacja nazw/opisów poleceń Telegram oraz sprawdzanie duplikatów/konfliktów, nawet gdy powierzchnia kontraktu zestawionego Telegram jest niedostępna |
|
||||
| `plugin-sdk/approval-runtime` | Helpery zatwierdzeń exec/pluginów, kreatory możliwości zatwierdzania, helpery auth/profili, helpery natywnego routingu/środowiska wykonawczego |
|
||||
| `plugin-sdk/reply-runtime` | Współdzielone helpery środowiska wykonawczego ruchu przychodzącego/odpowiedzi, dzielenia, dyspozycji, heartbeat, planisty odpowiedzi |
|
||||
| `plugin-sdk/reply-dispatch-runtime` | Wąskie helpery dyspozycji/finalizacji odpowiedzi |
|
||||
| `plugin-sdk/reply-history` | Współdzielone helpery historii odpowiedzi dla krótkiego okna, takie jak `buildHistoryContext`, `recordPendingHistoryEntry` i `clearHistoryEntriesIfEnabled` |
|
||||
| `plugin-sdk/telegram-command-config` | Helpery normalizacji nazw/opisów poleceń Telegram oraz sprawdzania duplikatów/konfliktów, nawet gdy bundlowana powierzchnia kontraktu Telegram jest niedostępna |
|
||||
| `plugin-sdk/approval-runtime` | Helpery zatwierdzeń exec/pluginów, konstruktory możliwości zatwierdzeń, helpery auth/profili, natywne helpery routingu/runtime |
|
||||
| `plugin-sdk/reply-runtime` | Współdzielone helpery runtime dla wejścia/odpowiedzi, chunking, wysyłka, heartbeat, planer odpowiedzi |
|
||||
| `plugin-sdk/reply-dispatch-runtime` | Wąskie helpery wysyłki/finalizacji odpowiedzi |
|
||||
| `plugin-sdk/reply-history` | Współdzielone helpery krótkookresowej historii odpowiedzi, takie jak `buildHistoryContext`, `recordPendingHistoryEntry` i `clearHistoryEntriesIfEnabled` |
|
||||
| `plugin-sdk/reply-reference` | `createReplyReferencePlanner` |
|
||||
| `plugin-sdk/reply-chunking` | Wąskie helpery dzielenia tekstu/Markdown |
|
||||
| `plugin-sdk/session-store-runtime` | Helpery ścieżek magazynu sesji + `updated-at` |
|
||||
| `plugin-sdk/reply-chunking` | Wąskie helpery chunkingu tekstu/Markdown |
|
||||
| `plugin-sdk/session-store-runtime` | Helpery ścieżek updated-at i magazynu sesji |
|
||||
| `plugin-sdk/state-paths` | Helpery ścieżek katalogów stanu/OAuth |
|
||||
| `plugin-sdk/routing` | Helpery tras/kluczy sesji/powiązań kont, takie jak `resolveAgentRoute`, `buildAgentSessionKey` i `resolveDefaultAgentBoundAccountId` |
|
||||
| `plugin-sdk/status-helpers` | Współdzielone helpery podsumowań statusu kanałów/kont, domyślne stany środowiska wykonawczego i helpery metadanych problemów |
|
||||
| `plugin-sdk/routing` | Helpery tras/kluczy sesji/wiązania kont, takie jak `resolveAgentRoute`, `buildAgentSessionKey` i `resolveDefaultAgentBoundAccountId` |
|
||||
| `plugin-sdk/status-helpers` | Współdzielone helpery podsumowania statusu kanału/konta, domyślne stany runtime i helpery metadanych problemów |
|
||||
| `plugin-sdk/target-resolver-runtime` | Współdzielone helpery rozstrzygania celów |
|
||||
| `plugin-sdk/string-normalization-runtime` | Helpery normalizacji slugów/ciągów |
|
||||
| `plugin-sdk/request-url` | Wyodrębnianie URL-i tekstowych z danych wejściowych typu fetch/request |
|
||||
| `plugin-sdk/request-url` | Wyodrębniaj URL-e tekstowe z danych wejściowych podobnych do fetch/request |
|
||||
| `plugin-sdk/run-command` | Uruchamianie poleceń z limitem czasu i znormalizowanymi wynikami stdout/stderr |
|
||||
| `plugin-sdk/param-readers` | Typowe czytniki parametrów narzędzi/CLI |
|
||||
| `plugin-sdk/tool-payload` | Wyodrębnianie znormalizowanych payloadów z obiektów wyników narzędzi |
|
||||
| `plugin-sdk/tool-send` | Wyodrębnianie kanonicznych pól celu wysyłki z argumentów narzędzi |
|
||||
| `plugin-sdk/tool-payload` | Wyodrębnia znormalizowane ładunki z obiektów wyników narzędzi |
|
||||
| `plugin-sdk/tool-send` | Wyodrębnia kanoniczne pola celu wysyłki z argumentów narzędzi |
|
||||
| `plugin-sdk/temp-path` | Współdzielone helpery ścieżek tymczasowego pobierania |
|
||||
| `plugin-sdk/logging-core` | Helpery loggera podsystemu i redakcji |
|
||||
| `plugin-sdk/logging-core` | Helpery loggera subsystemu i redakcji |
|
||||
| `plugin-sdk/markdown-table-runtime` | Helpery trybu tabel Markdown |
|
||||
| `plugin-sdk/json-store` | Małe helpery odczytu/zapisu stanu JSON |
|
||||
| `plugin-sdk/file-lock` | Helpery re-entrant file-lock |
|
||||
| `plugin-sdk/persistent-dedupe` | Helpery pamięci podręcznej deduplikacji na dysku |
|
||||
| `plugin-sdk/acp-runtime` | Helpery środowiska wykonawczego/sesji ACP i dyspozycji odpowiedzi |
|
||||
| `plugin-sdk/agent-config-primitives` | Wąskie prymitywy schematu konfiguracji środowiska wykonawczego agenta |
|
||||
| `plugin-sdk/boolean-param` | Czytnik parametrów luźnych wartości logicznych |
|
||||
| `plugin-sdk/dangerous-name-runtime` | Helpery rozstrzygania dopasowań niebezpiecznych nazw |
|
||||
| `plugin-sdk/file-lock` | Helpery reentrant file-lock |
|
||||
| `plugin-sdk/persistent-dedupe` | Helpery cache deduplikacji opartej na dysku |
|
||||
| `plugin-sdk/acp-runtime` | Helpery ACP runtime/sesji i wysyłki odpowiedzi |
|
||||
| `plugin-sdk/agent-config-primitives` | Wąskie prymitywy schematu konfiguracji runtime agenta |
|
||||
| `plugin-sdk/boolean-param` | Luźny czytnik parametrów boolean |
|
||||
| `plugin-sdk/dangerous-name-runtime` | Helpery rozstrzygania dopasowania niebezpiecznych nazw |
|
||||
| `plugin-sdk/device-bootstrap` | Helpery bootstrapu urządzenia i tokenów parowania |
|
||||
| `plugin-sdk/extension-shared` | Współdzielone prymitywy helperów kanałów pasywnych, statusu i ambient proxy |
|
||||
| `plugin-sdk/models-provider-runtime` | Helpery odpowiedzi polecenia `/models` i dostawców |
|
||||
| `plugin-sdk/models-provider-runtime` | Helpery odpowiedzi dostawcy/polecenia `/models` |
|
||||
| `plugin-sdk/skill-commands-runtime` | Helpery listowania poleceń Skills |
|
||||
| `plugin-sdk/native-command-registry` | Helpery rejestru/budowania/serializacji natywnych poleceń |
|
||||
| `plugin-sdk/provider-zai-endpoint` | Helpery wykrywania punktów końcowych Z.AI |
|
||||
| `plugin-sdk/native-command-registry` | Natywne helpery rejestracji/budowy/serializacji poleceń |
|
||||
| `plugin-sdk/provider-zai-endpoint` | Helpery wykrywania endpointu Z.A.I |
|
||||
| `plugin-sdk/infra-runtime` | Helpery zdarzeń systemowych/heartbeat |
|
||||
| `plugin-sdk/collection-runtime` | Małe helpery ograniczonej pamięci podręcznej |
|
||||
| `plugin-sdk/collection-runtime` | Małe helpery cache z ograniczonym rozmiarem |
|
||||
| `plugin-sdk/diagnostic-runtime` | Helpery flag i zdarzeń diagnostycznych |
|
||||
| `plugin-sdk/error-runtime` | Graf błędów, formatowanie, współdzielone helpery klasyfikacji błędów, `isApprovalNotFoundError` |
|
||||
| `plugin-sdk/fetch-runtime` | Opakowany fetch, proxy i helpery pinned lookup |
|
||||
| `plugin-sdk/error-runtime` | Helpery grafu błędów, formatowania, współdzielonej klasyfikacji błędów, `isApprovalNotFoundError` |
|
||||
| `plugin-sdk/fetch-runtime` | Opakowane helpery fetch, proxy i pinned lookup |
|
||||
| `plugin-sdk/host-runtime` | Helpery normalizacji nazw hostów i hostów SCP |
|
||||
| `plugin-sdk/retry-runtime` | Helpery konfiguracji ponowień i uruchamiania ponowień |
|
||||
| `plugin-sdk/agent-runtime` | Helpery katalogów/tożsamości/obszarów roboczych agenta |
|
||||
| `plugin-sdk/directory-runtime` | Zapytania/deduplikacja katalogów na podstawie konfiguracji |
|
||||
| `plugin-sdk/retry-runtime` | Helpery konfiguracji retry i wykonawcy retry |
|
||||
| `plugin-sdk/agent-runtime` | Helpery katalogu/tożsamości/przestrzeni roboczej agenta |
|
||||
| `plugin-sdk/directory-runtime` | Zapytania/deduplikacja katalogów opartych na konfiguracji |
|
||||
| `plugin-sdk/keyed-async-queue` | `KeyedAsyncQueue` |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Ścieżki podrzędne możliwości i testowania">
|
||||
| Ścieżka podrzędna | Kluczowe eksporty |
|
||||
| Subpath | Key exports |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/media-runtime` | Współdzielone helpery pobierania/przekształcania/przechowywania mediów oraz kreatory payloadów mediów |
|
||||
| `plugin-sdk/media-generation-runtime` | Współdzielone helpery failover generowania mediów, wybór kandydatów i komunikaty o brakujących modelach |
|
||||
| `plugin-sdk/media-understanding` | Typy dostawców rozumienia mediów oraz eksporty helperów obrazu/audio skierowane do dostawców |
|
||||
| `plugin-sdk/text-runtime` | Współdzielone helpery tekstu/Markdown/logowania, takie jak usuwanie tekstu widocznego dla asystenta, renderowanie/dzielenie/tabele Markdown, helpery redakcji, helpery tagów dyrektyw i narzędzia bezpiecznego tekstu |
|
||||
| `plugin-sdk/text-chunking` | Helper dzielenia tekstu wychodzącego |
|
||||
| `plugin-sdk/speech` | Typy dostawców mowy oraz helpery dyrektyw, rejestru i walidacji skierowane do dostawców |
|
||||
| `plugin-sdk/speech-core` | Współdzielone typy dostawców mowy, rejestr, dyrektywy i helpery normalizacji |
|
||||
| `plugin-sdk/realtime-transcription` | Typy dostawców transkrypcji w czasie rzeczywistym i helpery rejestru |
|
||||
| `plugin-sdk/realtime-voice` | Typy dostawców głosu w czasie rzeczywistym i helpery rejestru |
|
||||
| `plugin-sdk/media-runtime` | Współdzielone helpery pobierania/przekształcania/przechowywania mediów oraz konstruktory ładunków mediów |
|
||||
| `plugin-sdk/media-generation-runtime` | Współdzielone helpery failover generowania mediów, wybór kandydatów i komunikaty o brakującym modelu |
|
||||
| `plugin-sdk/media-understanding` | Typy dostawców rozumienia mediów oraz eksporty helperów obrazów/audio po stronie dostawcy |
|
||||
| `plugin-sdk/text-runtime` | Współdzielone helpery tekstu/Markdown/logowania, takie jak usuwanie tekstu widocznego dla asystenta, helpery renderowania/chunkingu/tabel Markdown, helpery redakcji, helpery tagów dyrektyw i bezpieczne narzędzia tekstowe |
|
||||
| `plugin-sdk/text-chunking` | Helper chunkingu tekstu wychodzącego |
|
||||
| `plugin-sdk/speech` | Typy dostawców mowy oraz helpery dyrektyw, rejestru i walidacji po stronie dostawcy |
|
||||
| `plugin-sdk/speech-core` | Współdzielone typy dostawców mowy, rejestru, dyrektyw i helpery normalizacji |
|
||||
| `plugin-sdk/realtime-transcription` | Typy dostawców transkrypcji czasu rzeczywistego i helpery rejestru |
|
||||
| `plugin-sdk/realtime-voice` | Typy dostawców głosu czasu rzeczywistego i helpery rejestru |
|
||||
| `plugin-sdk/image-generation` | Typy dostawców generowania obrazów |
|
||||
| `plugin-sdk/image-generation-core` | Współdzielone typy generowania obrazów, helpery failover, auth i rejestru |
|
||||
| `plugin-sdk/music-generation` | Typy dostawców/żądań/wyników generowania muzyki |
|
||||
| `plugin-sdk/music-generation-core` | Współdzielone typy generowania muzyki, helpery failover, wyszukiwanie dostawców i parsowanie model-ref |
|
||||
| `plugin-sdk/video-generation` | Typy dostawców/żądań/wyników generowania wideo |
|
||||
| `plugin-sdk/video-generation-core` | Współdzielone typy generowania wideo, helpery failover, wyszukiwanie dostawców i parsowanie model-ref |
|
||||
| `plugin-sdk/image-generation-core` | Współdzielone typy generowania obrazów, failover, auth i helpery rejestru |
|
||||
| `plugin-sdk/music-generation` | Typy żądań/wyników/dostawców generowania muzyki |
|
||||
| `plugin-sdk/music-generation-core` | Współdzielone typy generowania muzyki, helpery failover, wyszukiwania dostawców i parsowania model-ref |
|
||||
| `plugin-sdk/video-generation` | Typy żądań/wyników/dostawców generowania wideo |
|
||||
| `plugin-sdk/video-generation-core` | Współdzielone typy generowania wideo, helpery failover, wyszukiwania dostawców i parsowania model-ref |
|
||||
| `plugin-sdk/webhook-targets` | Rejestr celów webhooków i helpery instalacji tras |
|
||||
| `plugin-sdk/webhook-path` | Helpery normalizacji ścieżek webhooków |
|
||||
| `plugin-sdk/web-media` | Współdzielone helpery ładowania zdalnych/lokalnych mediów |
|
||||
| `plugin-sdk/zod` | Reeksport `zod` dla odbiorców Plugin SDK |
|
||||
| `plugin-sdk/zod` | Ponownie eksportowany `zod` dla użytkowników Plugin SDK |
|
||||
| `plugin-sdk/testing` | `installCommonResolveTargetErrorCases`, `shouldAckReaction` |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Ścieżki podrzędne pamięci">
|
||||
| Ścieżka podrzędna | Kluczowe eksporty |
|
||||
| Subpath | Key exports |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/memory-core` | Powierzchnia helperów zestawionego memory-core dla helperów managera/konfiguracji/plików/CLI |
|
||||
| `plugin-sdk/memory-core-engine-runtime` | Fasada środowiska wykonawczego indeksowania/wyszukiwania pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-foundation` | Eksporty silnika fundamentów hosta pamięci |
|
||||
| `plugin-sdk/memory-core` | Powierzchnia helperów bundlowanego memory-core dla helperów managera/konfiguracji/plików/CLI |
|
||||
| `plugin-sdk/memory-core-engine-runtime` | Fasada runtime indeksowania/wyszukiwania pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-foundation` | Eksporty silnika foundation hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-embeddings` | Eksporty silnika embeddingów hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-qmd` | Eksporty silnika QMD hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-engine-storage` | Eksporty silnika przechowywania hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-multimodal` | Helpery multimodalne hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-multimodal` | Wielomodalne helpery hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-query` | Helpery zapytań hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-secret` | Helpery sekretów hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-events` | Helpery dziennika zdarzeń hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-status` | Helpery statusu hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-cli` | Helpery środowiska wykonawczego CLI hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-core` | Helpery głównego środowiska wykonawczego hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-files` | Helpery plików/środowiska wykonawczego hosta pamięci |
|
||||
| `plugin-sdk/memory-host-core` | Neutralny wobec dostawcy alias dla helperów głównego środowiska wykonawczego hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-cli` | Helpery runtime CLI hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-core` | Helpery głównego runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-core-host-runtime-files` | Helpery plików/runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-host-core` | Neutralny wobec dostawcy alias dla helperów głównego runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-host-events` | Neutralny wobec dostawcy alias dla helperów dziennika zdarzeń hosta pamięci |
|
||||
| `plugin-sdk/memory-host-files` | Neutralny wobec dostawcy alias dla helperów plików/środowiska wykonawczego hosta pamięci |
|
||||
| `plugin-sdk/memory-host-markdown` | Współdzielone helpery managed-markdown dla pluginów powiązanych z pamięcią |
|
||||
| `plugin-sdk/memory-host-search` | Aktywna fasada środowiska wykonawczego pamięci do dostępu do search-manager |
|
||||
| `plugin-sdk/memory-host-files` | Neutralny wobec dostawcy alias dla helperów plików/runtime hosta pamięci |
|
||||
| `plugin-sdk/memory-host-markdown` | Współdzielone helpery zarządzanego Markdown dla pluginów sąsiadujących z pamięcią |
|
||||
| `plugin-sdk/memory-host-search` | Aktywna fasada runtime pamięci do dostępu do menedżera wyszukiwania |
|
||||
| `plugin-sdk/memory-host-status` | Neutralny wobec dostawcy alias dla helperów statusu hosta pamięci |
|
||||
| `plugin-sdk/memory-lancedb` | Powierzchnia helperów zestawionego memory-lancedb |
|
||||
| `plugin-sdk/memory-lancedb` | Powierzchnia helperów bundlowanego memory-lancedb |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Zarezerwowane ścieżki podrzędne zestawionych helperów">
|
||||
| Rodzina | Bieżące ścieżki podrzędne | Zamierzone użycie |
|
||||
<Accordion title="Zarezerwowane ścieżki podrzędne helperów bundlowanych">
|
||||
| Family | Current subpaths | Intended use |
|
||||
| --- | --- | --- |
|
||||
| Browser | `plugin-sdk/browser-cdp`, `plugin-sdk/browser-config-runtime`, `plugin-sdk/browser-config-support`, `plugin-sdk/browser-control-auth`, `plugin-sdk/browser-node-runtime`, `plugin-sdk/browser-profiles`, `plugin-sdk/browser-security-runtime`, `plugin-sdk/browser-setup-tools`, `plugin-sdk/browser-support` | Helpery wsparcia zestawionego pluginu browser (`browser-support` pozostaje barrelem zgodności) |
|
||||
| Matrix | `plugin-sdk/matrix`, `plugin-sdk/matrix-helper`, `plugin-sdk/matrix-runtime-heavy`, `plugin-sdk/matrix-runtime-shared`, `plugin-sdk/matrix-runtime-surface`, `plugin-sdk/matrix-surface`, `plugin-sdk/matrix-thread-bindings` | Powierzchnia helperów/środowiska wykonawczego zestawionego Matrix |
|
||||
| Line | `plugin-sdk/line`, `plugin-sdk/line-core`, `plugin-sdk/line-runtime`, `plugin-sdk/line-surface` | Powierzchnia helperów/środowiska wykonawczego zestawionego LINE |
|
||||
| IRC | `plugin-sdk/irc`, `plugin-sdk/irc-surface` | Powierzchnia helperów zestawionego IRC |
|
||||
| Helpery specyficzne dla kanałów | `plugin-sdk/googlechat`, `plugin-sdk/zalouser`, `plugin-sdk/bluebubbles`, `plugin-sdk/bluebubbles-policy`, `plugin-sdk/mattermost`, `plugin-sdk/mattermost-policy`, `plugin-sdk/feishu-conversation`, `plugin-sdk/msteams`, `plugin-sdk/nextcloud-talk`, `plugin-sdk/nostr`, `plugin-sdk/tlon`, `plugin-sdk/twitch` | Warstwy zgodności/helperów zestawionych kanałów |
|
||||
| Helpery specyficzne dla auth/pluginów | `plugin-sdk/github-copilot-login`, `plugin-sdk/github-copilot-token`, `plugin-sdk/diagnostics-otel`, `plugin-sdk/diffs`, `plugin-sdk/llm-task`, `plugin-sdk/thread-ownership`, `plugin-sdk/voice-call` | Warstwy helperów zestawionych funkcji/pluginów; `plugin-sdk/github-copilot-token` obecnie eksportuje `DEFAULT_COPILOT_API_BASE_URL`, `deriveCopilotApiBaseUrlFromToken` i `resolveCopilotApiToken` |
|
||||
| Browser | `plugin-sdk/browser-cdp`, `plugin-sdk/browser-config-runtime`, `plugin-sdk/browser-config-support`, `plugin-sdk/browser-control-auth`, `plugin-sdk/browser-node-runtime`, `plugin-sdk/browser-profiles`, `plugin-sdk/browser-security-runtime`, `plugin-sdk/browser-setup-tools`, `plugin-sdk/browser-support` | Helpery wsparcia bundlowanego pluginu przeglądarki (`browser-support` pozostaje barrelem zgodności) |
|
||||
| Matrix | `plugin-sdk/matrix`, `plugin-sdk/matrix-helper`, `plugin-sdk/matrix-runtime-heavy`, `plugin-sdk/matrix-runtime-shared`, `plugin-sdk/matrix-runtime-surface`, `plugin-sdk/matrix-surface`, `plugin-sdk/matrix-thread-bindings` | Powierzchnia helperów/runtime bundlowanego Matrix |
|
||||
| Line | `plugin-sdk/line`, `plugin-sdk/line-core`, `plugin-sdk/line-runtime`, `plugin-sdk/line-surface` | Powierzchnia helperów/runtime bundlowanego LINE |
|
||||
| IRC | `plugin-sdk/irc`, `plugin-sdk/irc-surface` | Powierzchnia helperów bundlowanego IRC |
|
||||
| Channel-specific helpers | `plugin-sdk/googlechat`, `plugin-sdk/zalouser`, `plugin-sdk/bluebubbles`, `plugin-sdk/bluebubbles-policy`, `plugin-sdk/mattermost`, `plugin-sdk/mattermost-policy`, `plugin-sdk/feishu-conversation`, `plugin-sdk/msteams`, `plugin-sdk/nextcloud-talk`, `plugin-sdk/nostr`, `plugin-sdk/tlon`, `plugin-sdk/twitch` | Warstwy zgodności/helperów bundlowanych kanałów |
|
||||
| Auth/plugin-specific helpers | `plugin-sdk/github-copilot-login`, `plugin-sdk/github-copilot-token`, `plugin-sdk/diagnostics-otel`, `plugin-sdk/diffs`, `plugin-sdk/llm-task`, `plugin-sdk/thread-ownership`, `plugin-sdk/voice-call` | Warstwy helperów bundlowanych funkcji/pluginów; `plugin-sdk/github-copilot-token` obecnie eksportuje `DEFAULT_COPILOT_API_BASE_URL`, `deriveCopilotApiBaseUrlFromToken` i `resolveCopilotApiToken` |
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@ -309,57 +308,57 @@ metodami:
|
||||
|
||||
### Rejestracja możliwości
|
||||
|
||||
| Metoda | Co rejestruje |
|
||||
| ------------------------------------------------ | ------------------------------ |
|
||||
| `api.registerProvider(...)` | Wnioskowanie tekstowe (LLM) |
|
||||
| Method | What it registers |
|
||||
| ------------------------------------------------ | -------------------------------- |
|
||||
| `api.registerProvider(...)` | Wnioskowanie tekstowe (LLM) |
|
||||
| `api.registerCliBackend(...)` | Lokalny backend wnioskowania CLI |
|
||||
| `api.registerChannel(...)` | Kanał wiadomości |
|
||||
| `api.registerSpeechProvider(...)` | Synteza text-to-speech / STT |
|
||||
| `api.registerRealtimeTranscriptionProvider(...)` | Strumieniowa transkrypcja w czasie rzeczywistym |
|
||||
| `api.registerRealtimeVoiceProvider(...)` | Dwukierunkowe sesje głosowe w czasie rzeczywistym |
|
||||
| `api.registerMediaUnderstandingProvider(...)` | Analiza obrazu/audio/wideo |
|
||||
| `api.registerImageGenerationProvider(...)` | Generowanie obrazów |
|
||||
| `api.registerMusicGenerationProvider(...)` | Generowanie muzyki |
|
||||
| `api.registerVideoGenerationProvider(...)` | Generowanie wideo |
|
||||
| `api.registerWebFetchProvider(...)` | Dostawca web fetch / scrapingu |
|
||||
| `api.registerWebSearchProvider(...)` | Web search |
|
||||
| `api.registerChannel(...)` | Kanał wiadomości |
|
||||
| `api.registerSpeechProvider(...)` | Synteza text-to-speech / STT |
|
||||
| `api.registerRealtimeTranscriptionProvider(...)` | Strumieniowa transkrypcja czasu rzeczywistego |
|
||||
| `api.registerRealtimeVoiceProvider(...)` | Dwukierunkowe sesje głosu czasu rzeczywistego |
|
||||
| `api.registerMediaUnderstandingProvider(...)` | Analiza obrazów/audio/wideo |
|
||||
| `api.registerImageGenerationProvider(...)` | Generowanie obrazów |
|
||||
| `api.registerMusicGenerationProvider(...)` | Generowanie muzyki |
|
||||
| `api.registerVideoGenerationProvider(...)` | Generowanie wideo |
|
||||
| `api.registerWebFetchProvider(...)` | Dostawca web fetch / scrape |
|
||||
| `api.registerWebSearchProvider(...)` | Wyszukiwanie w sieci |
|
||||
|
||||
### Narzędzia i polecenia
|
||||
|
||||
| Metoda | Co rejestruje |
|
||||
| Method | What it registers |
|
||||
| ------------------------------- | --------------------------------------------- |
|
||||
| `api.registerTool(tool, opts?)` | Narzędzie agenta (wymagane lub `{ optional: true }`) |
|
||||
| `api.registerCommand(def)` | Niestandardowe polecenie (omija LLM) |
|
||||
|
||||
### Infrastruktura
|
||||
|
||||
| Metoda | Co rejestruje |
|
||||
| ---------------------------------------------- | -------------------------------- |
|
||||
| `api.registerHook(events, handler, opts?)` | Hook zdarzeń |
|
||||
| `api.registerHttpRoute(params)` | Punkt końcowy HTTP gateway |
|
||||
| `api.registerGatewayMethod(name, handler)` | Metoda RPC gateway |
|
||||
| `api.registerCli(registrar, opts?)` | Podpolecenie CLI |
|
||||
| `api.registerService(service)` | Usługa działająca w tle |
|
||||
| `api.registerInteractiveHandler(registration)` | Handler interaktywny |
|
||||
| `api.registerMemoryPromptSupplement(builder)` | Dodatkowa sekcja promptu związana z pamięcią |
|
||||
| `api.registerMemoryCorpusSupplement(adapter)` | Dodatkowy korpus wyszukiwania/odczytu pamięci |
|
||||
| Method | What it registers |
|
||||
| ---------------------------------------------- | --------------------------------------- |
|
||||
| `api.registerHook(events, handler, opts?)` | Hook zdarzenia |
|
||||
| `api.registerHttpRoute(params)` | Punkt końcowy HTTP Gateway |
|
||||
| `api.registerGatewayMethod(name, handler)` | Metoda RPC Gateway |
|
||||
| `api.registerCli(registrar, opts?)` | Podpolecenie CLI |
|
||||
| `api.registerService(service)` | Usługa w tle |
|
||||
| `api.registerInteractiveHandler(registration)` | Handler interaktywny |
|
||||
| `api.registerMemoryPromptSupplement(builder)` | Addytywna sekcja promptu sąsiadująca z pamięcią |
|
||||
| `api.registerMemoryCorpusSupplement(adapter)` | Addytywny korpus wyszukiwania/odczytu pamięci |
|
||||
|
||||
Zarezerwowane przestrzenie nazw administracyjnych rdzenia (`config.*`, `exec.approvals.*`, `wizard.*`,
|
||||
`update.*`) zawsze pozostają `operator.admin`, nawet jeśli plugin próbuje przypisać
|
||||
węższy zakres metod gateway. Dla metod należących do pluginu preferuj
|
||||
węższy zakres metody gateway. Dla metod należących do pluginu preferuj
|
||||
prefiksy specyficzne dla pluginu.
|
||||
|
||||
### Metadane rejestracji CLI
|
||||
|
||||
`api.registerCli(registrar, opts?)` przyjmuje dwa rodzaje metadanych najwyższego poziomu:
|
||||
`api.registerCli(registrar, opts?)` akceptuje dwa rodzaje metadanych najwyższego poziomu:
|
||||
|
||||
- `commands`: jawne korzenie poleceń należące do rejestratora
|
||||
- `descriptors`: deskryptory poleceń w czasie parsowania używane dla głównej pomocy CLI,
|
||||
- `commands`: jawne korzenie poleceń należące do registrara
|
||||
- `descriptors`: deskryptory poleceń używane na etapie parsowania dla głównej pomocy CLI,
|
||||
routingu i leniwej rejestracji CLI pluginów
|
||||
|
||||
Jeśli chcesz, aby polecenie pluginu pozostało ładowane leniwie w normalnej ścieżce głównego CLI,
|
||||
podaj `descriptors`, które obejmują każdy korzeń polecenia najwyższego poziomu udostępniany przez ten
|
||||
rejestrator.
|
||||
Jeśli chcesz, aby polecenie pluginu pozostawało ładowane leniwie w normalnej ścieżce głównego CLI,
|
||||
podaj `descriptors`, które obejmują każdy korzeń polecenia najwyższego poziomu udostępniany przez tego
|
||||
registrara.
|
||||
|
||||
```typescript
|
||||
api.registerCli(
|
||||
@ -380,133 +379,132 @@ api.registerCli(
|
||||
```
|
||||
|
||||
Używaj samego `commands` tylko wtedy, gdy nie potrzebujesz leniwej rejestracji głównego CLI.
|
||||
Ta ścieżka zgodności z eager loading pozostaje wspierana, ale nie instaluje
|
||||
placeholderów opartych na descriptorach dla leniwego ładowania w czasie parsowania.
|
||||
Ta zgodna ścieżka eager nadal jest obsługiwana, ale nie instaluje
|
||||
placeholderów opartych na deskryptorach dla leniwego ładowania na etapie parsowania.
|
||||
|
||||
### Rejestracja backendu CLI
|
||||
|
||||
`api.registerCliBackend(...)` pozwala pluginowi posiadać domyślną konfigurację lokalnego
|
||||
backendu CLI AI, takiego jak `codex-cli`.
|
||||
`api.registerCliBackend(...)` pozwala pluginowi zarządzać domyślną konfiguracją lokalnego
|
||||
backendu AI CLI, takiego jak `codex-cli`.
|
||||
|
||||
- `id` backendu staje się prefiksem dostawcy w odwołaniach do modeli, takich jak `codex-cli/gpt-5`.
|
||||
- `id` backendu staje się prefiksem dostawcy w odwołaniach do modeli takich jak `codex-cli/gpt-5`.
|
||||
- `config` backendu używa tego samego kształtu co `agents.defaults.cliBackends.<id>`.
|
||||
- Konfiguracja użytkownika nadal ma pierwszeństwo. OpenClaw scala `agents.defaults.cliBackends.<id>` z
|
||||
domyślną konfiguracją pluginu przed uruchomieniem CLI.
|
||||
- Użyj `normalizeConfig`, gdy backend potrzebuje przekształceń zgodności po scaleniu
|
||||
domyślną wartością pluginu przed uruchomieniem CLI.
|
||||
- Używaj `normalizeConfig`, gdy backend potrzebuje przekształceń zgodności po scaleniu
|
||||
(na przykład normalizacji starych kształtów flag).
|
||||
|
||||
### Sloty wyłączne
|
||||
### Wyłączne sloty
|
||||
|
||||
| Metoda | Co rejestruje |
|
||||
| ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `api.registerContextEngine(id, factory)` | Silnik kontekstu (aktywny tylko jeden naraz). Callback `assemble()` otrzymuje `availableTools` i `citationsMode`, aby silnik mógł dostosować dodatki do promptu. |
|
||||
| `api.registerMemoryCapability(capability)` | Ujednolicona możliwość pamięci |
|
||||
| `api.registerMemoryPromptSection(builder)` | Kreator sekcji promptu pamięci |
|
||||
| `api.registerMemoryFlushPlan(resolver)` | Resolver planu opróżniania pamięci |
|
||||
| `api.registerMemoryRuntime(runtime)` | Adapter środowiska wykonawczego pamięci |
|
||||
| Method | What it registers |
|
||||
| ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `api.registerContextEngine(id, factory)` | Silnik kontekstu (aktywny może być tylko jeden naraz). Callback `assemble()` otrzymuje `availableTools` i `citationsMode`, aby silnik mógł dostosować dodatki do promptu. |
|
||||
| `api.registerMemoryCapability(capability)` | Ujednolicona możliwość pamięci |
|
||||
| `api.registerMemoryPromptSection(builder)` | Konstruktor sekcji promptu pamięci |
|
||||
| `api.registerMemoryFlushPlan(resolver)` | Resolver planu opróżniania pamięci |
|
||||
| `api.registerMemoryRuntime(runtime)` | Adapter runtime pamięci |
|
||||
|
||||
### Adaptery embeddingów pamięci
|
||||
|
||||
| Metoda | Co rejestruje |
|
||||
| ---------------------------------------------- | ------------------------------------------ |
|
||||
| Method | What it registers |
|
||||
| ---------------------------------------------- | ---------------------------------------------- |
|
||||
| `api.registerMemoryEmbeddingProvider(adapter)` | Adapter embeddingów pamięci dla aktywnego pluginu |
|
||||
|
||||
- `registerMemoryCapability` to preferowane wyłączne API pluginów pamięci.
|
||||
- `registerMemoryCapability` może także udostępniać `publicArtifacts.listArtifacts(...)`,
|
||||
aby pluginy towarzyszące mogły korzystać z eksportowanych artefaktów pamięci przez
|
||||
`openclaw/plugin-sdk/memory-host-core` zamiast sięgać do prywatnego
|
||||
układu konkretnego pluginu pamięci.
|
||||
- `registerMemoryCapability` to preferowane API wyłącznego pluginu pamięci.
|
||||
- `registerMemoryCapability` może również udostępniać `publicArtifacts.listArtifacts(...)`,
|
||||
aby pluginy towarzyszące mogły używać eksportowanych artefaktów pamięci przez
|
||||
`openclaw/plugin-sdk/memory-host-core` zamiast sięgać do prywatnego układu konkretnego
|
||||
pluginu pamięci.
|
||||
- `registerMemoryPromptSection`, `registerMemoryFlushPlan` i
|
||||
`registerMemoryRuntime` to starsze, nadal zgodne wyłączne API pluginów pamięci.
|
||||
`registerMemoryRuntime` to starsze, zgodne wstecz API wyłącznych pluginów pamięci.
|
||||
- `registerMemoryEmbeddingProvider` pozwala aktywnemu pluginowi pamięci zarejestrować jeden
|
||||
lub więcej identyfikatorów adapterów embeddingów (na przykład `openai`, `gemini` lub własny identyfikator zdefiniowany przez plugin).
|
||||
lub więcej identyfikatorów adapterów embeddingów (na przykład `openai`, `gemini` lub niestandardowy identyfikator zdefiniowany przez plugin).
|
||||
- Konfiguracja użytkownika, taka jak `agents.defaults.memorySearch.provider` i
|
||||
`agents.defaults.memorySearch.fallback`, jest rozstrzygana względem tych zarejestrowanych
|
||||
identyfikatorów adapterów.
|
||||
|
||||
### Zdarzenia i cykl życia
|
||||
|
||||
| Metoda | Co robi |
|
||||
| Method | What it does |
|
||||
| -------------------------------------------- | ----------------------------- |
|
||||
| `api.on(hookName, handler, opts?)` | Typowany hook cyklu życia |
|
||||
| `api.onConversationBindingResolved(handler)` | Callback rozwiązania powiązania konwersacji |
|
||||
| `api.onConversationBindingResolved(handler)` | Callback rozstrzygnięcia wiązania rozmowy |
|
||||
|
||||
### Semantyka decyzji hooków
|
||||
|
||||
- `before_tool_call`: zwrócenie `{ block: true }` jest końcowe. Gdy którykolwiek handler to ustawi, handlery o niższym priorytecie są pomijane.
|
||||
- `before_tool_call`: zwrócenie `{ block: true }` jest końcowe. Gdy dowolny handler to ustawi, handlery o niższym priorytecie są pomijane.
|
||||
- `before_tool_call`: zwrócenie `{ block: false }` jest traktowane jako brak decyzji (tak samo jak pominięcie `block`), a nie jako nadpisanie.
|
||||
- `before_install`: zwrócenie `{ block: true }` jest końcowe. Gdy którykolwiek handler to ustawi, handlery o niższym priorytecie są pomijane.
|
||||
- `before_install`: zwrócenie `{ block: true }` jest końcowe. Gdy dowolny handler to ustawi, handlery o niższym priorytecie są pomijane.
|
||||
- `before_install`: zwrócenie `{ block: false }` jest traktowane jako brak decyzji (tak samo jak pominięcie `block`), a nie jako nadpisanie.
|
||||
- `reply_dispatch`: zwrócenie `{ handled: true, ... }` jest końcowe. Gdy którykolwiek handler przejmie dyspozycję, handlery o niższym priorytecie i domyślna ścieżka dyspozycji modelu są pomijane.
|
||||
- `message_sending`: zwrócenie `{ cancel: true }` jest końcowe. Gdy którykolwiek handler to ustawi, handlery o niższym priorytecie są pomijane.
|
||||
- `reply_dispatch`: zwrócenie `{ handled: true, ... }` jest końcowe. Gdy dowolny handler przejmie wysyłkę, handlery o niższym priorytecie i domyślna ścieżka wysyłki modelu są pomijane.
|
||||
- `message_sending`: zwrócenie `{ cancel: true }` jest końcowe. Gdy dowolny handler to ustawi, handlery o niższym priorytecie są pomijane.
|
||||
- `message_sending`: zwrócenie `{ cancel: false }` jest traktowane jako brak decyzji (tak samo jak pominięcie `cancel`), a nie jako nadpisanie.
|
||||
|
||||
### Pola obiektu API
|
||||
|
||||
| Pole | Typ | Opis |
|
||||
| ------------------------ | ------------------------- | ------------------------------------------------------------------------------------------ |
|
||||
| `api.id` | `string` | Identyfikator pluginu |
|
||||
| `api.name` | `string` | Nazwa wyświetlana |
|
||||
| `api.version` | `string?` | Wersja pluginu (opcjonalna) |
|
||||
| `api.description` | `string?` | Opis pluginu (opcjonalny) |
|
||||
| `api.source` | `string` | Ścieżka źródłowa pluginu |
|
||||
| `api.rootDir` | `string?` | Katalog główny pluginu (opcjonalny) |
|
||||
| `api.config` | `OpenClawConfig` | Bieżąca migawka konfiguracji (aktywna migawka środowiska wykonawczego w pamięci, gdy jest dostępna) |
|
||||
| `api.pluginConfig` | `Record<string, unknown>` | Konfiguracja specyficzna dla pluginu z `plugins.entries.<id>.config` |
|
||||
| `api.runtime` | `PluginRuntime` | [Helpery środowiska wykonawczego](/pl/plugins/sdk-runtime) |
|
||||
| `api.logger` | `PluginLogger` | Logger z zakresem (`debug`, `info`, `warn`, `error`) |
|
||||
| `api.registrationMode` | `PluginRegistrationMode` | Bieżący tryb ładowania; `"setup-runtime"` to lekkie okno uruchamiania/konfiguracji przed pełnym wejściem |
|
||||
| `api.resolvePath(input)` | `(string) => string` | Rozwiązywanie ścieżki względem katalogu głównego pluginu |
|
||||
| Field | Type | Description |
|
||||
| ------------------------ | ------------------------- | ------------------------------------------------------------------------------------------- |
|
||||
| `api.id` | `string` | Identyfikator pluginu |
|
||||
| `api.name` | `string` | Nazwa wyświetlana |
|
||||
| `api.version` | `string?` | Wersja pluginu (opcjonalnie) |
|
||||
| `api.description` | `string?` | Opis pluginu (opcjonalnie) |
|
||||
| `api.source` | `string` | Ścieżka źródłowa pluginu |
|
||||
| `api.rootDir` | `string?` | Katalog główny pluginu (opcjonalnie) |
|
||||
| `api.config` | `OpenClawConfig` | Bieżąca migawka konfiguracji (aktywny migawkowy stan runtime w pamięci, gdy jest dostępny) |
|
||||
| `api.pluginConfig` | `Record<string, unknown>` | Konfiguracja specyficzna dla pluginu z `plugins.entries.<id>.config` |
|
||||
| `api.runtime` | `PluginRuntime` | [Helpery runtime](/pl/plugins/sdk-runtime) |
|
||||
| `api.logger` | `PluginLogger` | Logger z zakresem (`debug`, `info`, `warn`, `error`) |
|
||||
| `api.registrationMode` | `PluginRegistrationMode` | Bieżący tryb ładowania; `"setup-runtime"` to lekki etap uruchamiania/konfiguracji przed pełnym wejściem |
|
||||
| `api.resolvePath(input)` | `(string) => string` | Rozstrzyga ścieżkę względem katalogu głównego pluginu |
|
||||
|
||||
## Wewnętrzna konwencja modułów
|
||||
## Konwencja modułów wewnętrznych
|
||||
|
||||
Wewnątrz pluginu używaj lokalnych plików barrel dla importów wewnętrznych:
|
||||
Wewnątrz swojego pluginu używaj lokalnych plików barrel dla importów wewnętrznych:
|
||||
|
||||
```
|
||||
my-plugin/
|
||||
api.ts # Public exports for external consumers
|
||||
runtime-api.ts # Internal-only runtime exports
|
||||
index.ts # Plugin entry point
|
||||
setup-entry.ts # Lightweight setup-only entry (optional)
|
||||
api.ts # Eksporty publiczne dla zewnętrznych użytkowników
|
||||
runtime-api.ts # Eksporty runtime tylko do użytku wewnętrznego
|
||||
index.ts # Punkt wejścia pluginu
|
||||
setup-entry.ts # Lekki punkt wejścia tylko do konfiguracji (opcjonalnie)
|
||||
```
|
||||
|
||||
<Warning>
|
||||
Nigdy nie importuj własnego pluginu przez `openclaw/plugin-sdk/<your-plugin>`
|
||||
z kodu produkcyjnego. Kieruj importy wewnętrzne przez `./api.ts` lub
|
||||
w kodzie produkcyjnym. Kieruj importy wewnętrzne przez `./api.ts` lub
|
||||
`./runtime-api.ts`. Ścieżka SDK jest wyłącznie kontraktem zewnętrznym.
|
||||
</Warning>
|
||||
|
||||
Powierzchnie publiczne zestawionych pluginów ładowane przez fasady (`api.ts`, `runtime-api.ts`,
|
||||
Ładowane przez fasadę publiczne powierzchnie bundlowanych pluginów (`api.ts`, `runtime-api.ts`,
|
||||
`index.ts`, `setup-entry.ts` i podobne publiczne pliki wejściowe) teraz preferują
|
||||
aktywną migawkę konfiguracji środowiska wykonawczego, gdy OpenClaw już działa. Jeśli migawka środowiska
|
||||
wykonawczego jeszcze nie istnieje, wracają do rozstrzygniętego pliku konfiguracji na dysku.
|
||||
aktywną migawkę konfiguracji runtime, gdy OpenClaw już działa. Jeśli migawka runtime jeszcze nie istnieje,
|
||||
używają w zamian rozstrzygniętego pliku konfiguracji z dysku.
|
||||
|
||||
Pluginy dostawców mogą również udostępniać wąski lokalny barrel kontraktu pluginu, gdy helper
|
||||
jest celowo specyficzny dla dostawcy i jeszcze nie należy do ogólnej ścieżki podrzędnej SDK.
|
||||
Bieżący zestawiony przykład: dostawca Anthropic przechowuje helpery strumieni Claude
|
||||
we własnej publicznej warstwie `api.ts` / `contract-api.ts`, zamiast promować logikę
|
||||
nagłówków beta Anthropic i `service_tier` do ogólnego kontraktu
|
||||
`plugin-sdk/*`.
|
||||
Pluginy dostawców mogą także udostępniać wąski, lokalny barrel kontraktu pluginu, gdy helper jest
|
||||
celowo specyficzny dla dostawcy i jeszcze nie należy do ogólnej ścieżki podrzędnej SDK.
|
||||
Obecny bundlowany przykład: dostawca Anthropic przechowuje helpery strumieni Claude we
|
||||
własnej publicznej warstwie `api.ts` / `contract-api.ts` zamiast promować logikę nagłówków beta Anthropic i `service_tier`
|
||||
do ogólnego kontraktu `plugin-sdk/*`.
|
||||
|
||||
Inne bieżące zestawione przykłady:
|
||||
Inne obecne bundlowane przykłady:
|
||||
|
||||
- `@openclaw/openai-provider`: `api.ts` eksportuje kreatory dostawców,
|
||||
helpery modeli domyślnych i kreatory dostawców realtime
|
||||
- `@openclaw/openrouter-provider`: `api.ts` eksportuje kreator dostawcy oraz
|
||||
- `@openclaw/openai-provider`: `api.ts` eksportuje konstruktory dostawców,
|
||||
helpery domyślnych modeli i konstruktory dostawców realtime
|
||||
- `@openclaw/openrouter-provider`: `api.ts` eksportuje konstruktor dostawcy oraz
|
||||
helpery onboardingu/konfiguracji
|
||||
|
||||
<Warning>
|
||||
Kod produkcyjny rozszerzeń powinien również unikać importów `openclaw/plugin-sdk/<other-plugin>`.
|
||||
Kod produkcyjny rozszerzeń powinien także unikać importów `openclaw/plugin-sdk/<other-plugin>`.
|
||||
Jeśli helper jest rzeczywiście współdzielony, przenieś go do neutralnej ścieżki podrzędnej SDK,
|
||||
takiej jak `openclaw/plugin-sdk/speech`, `.../provider-model-shared` lub innej
|
||||
powierzchni zorientowanej na możliwości, zamiast wiązać dwa pluginy ze sobą.
|
||||
powierzchni zorientowanej na możliwości, zamiast łączyć ze sobą dwa pluginy.
|
||||
</Warning>
|
||||
|
||||
## Powiązane
|
||||
|
||||
- [Punkty wejścia](/pl/plugins/sdk-entrypoints) — opcje `definePluginEntry` i `defineChannelPluginEntry`
|
||||
- [Helpery środowiska wykonawczego](/pl/plugins/sdk-runtime) — pełna dokumentacja referencyjna przestrzeni nazw `api.runtime`
|
||||
- [Helpery runtime](/pl/plugins/sdk-runtime) — pełna dokumentacja przestrzeni nazw `api.runtime`
|
||||
- [Konfiguracja i config](/pl/plugins/sdk-setup) — pakowanie, manifesty, schematy konfiguracji
|
||||
- [Testowanie](/pl/plugins/sdk-testing) — narzędzia testowe i reguły lint
|
||||
- [Migracja SDK](/pl/plugins/sdk-migration) — migracja z przestarzałych powierzchni
|
||||
- [Migracja SDK](/pl/plugins/sdk-migration) — migracja ze starszych powierzchni
|
||||
- [Wnętrze pluginów](/pl/plugins/architecture) — szczegółowa architektura i model możliwości
|
||||
|
||||
@ -1,33 +1,33 @@
|
||||
---
|
||||
read_when:
|
||||
- Tworzysz nowy plugin dostawcy modeli
|
||||
- Chcesz dodać do OpenClaw proxy zgodne z OpenAI lub niestandardowy LLM
|
||||
- Musisz zrozumieć uwierzytelnianie dostawcy, katalogi i hooki runtime
|
||||
- Chcesz dodać do OpenClaw proxy zgodne z OpenAI lub własny LLM
|
||||
- Musisz zrozumieć uwierzytelnianie dostawców, katalogi i hooki runtime
|
||||
sidebarTitle: Provider Plugins
|
||||
summary: Przewodnik krok po kroku po tworzeniu pluginu dostawcy modeli dla OpenClaw
|
||||
title: Tworzenie pluginów dostawców
|
||||
x-i18n:
|
||||
generated_at: "2026-04-07T09:49:08Z"
|
||||
generated_at: "2026-04-09T01:30:52Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 4da82a353e1bf4fe6dc09e14b8614133ac96565679627de51415926014bd3990
|
||||
source_hash: 38d9af522dc19e49c81203a83a4096f01c2398b1df771c848a30ad98f251e9e1
|
||||
source_path: plugins/sdk-provider-plugins.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Tworzenie pluginów dostawców
|
||||
|
||||
Ten przewodnik przeprowadza przez tworzenie pluginu dostawcy, który dodaje do OpenClaw dostawcę modeli
|
||||
(LLM). Na końcu będziesz mieć dostawcę z katalogiem modeli,
|
||||
uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
Ten przewodnik prowadzi przez tworzenie pluginu dostawcy, który dodaje dostawcę modeli
|
||||
(LLM) do OpenClaw. Na końcu będziesz mieć dostawcę z katalogiem modeli,
|
||||
uwierzytelnianiem kluczem API i dynamicznym rozwiązywaniem modeli.
|
||||
|
||||
<Info>
|
||||
Jeśli nie tworzono wcześniej żadnego pluginu OpenClaw, najpierw przeczytaj
|
||||
Jeśli nie tworzyłeś wcześniej żadnego pluginu OpenClaw, najpierw przeczytaj
|
||||
[Getting Started](/pl/plugins/building-plugins), aby poznać podstawową strukturę
|
||||
pakietu i konfigurację manifestu.
|
||||
</Info>
|
||||
|
||||
## Instrukcja krok po kroku
|
||||
## Przewodnik
|
||||
|
||||
<Steps>
|
||||
<a id="step-1-package-and-manifest"></a>
|
||||
@ -65,6 +65,9 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
"providerAuthEnvVars": {
|
||||
"acme-ai": ["ACME_AI_API_KEY"]
|
||||
},
|
||||
"providerAuthAliases": {
|
||||
"acme-ai-coding": "acme-ai"
|
||||
},
|
||||
"providerAuthChoices": [
|
||||
{
|
||||
"provider": "acme-ai",
|
||||
@ -87,16 +90,17 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
</CodeGroup>
|
||||
|
||||
Manifest deklaruje `providerAuthEnvVars`, aby OpenClaw mógł wykrywać
|
||||
poświadczenia bez ładowania runtime Twojego pluginu. `modelSupport` jest opcjonalne
|
||||
i pozwala OpenClaw automatycznie ładować plugin dostawcy na podstawie skróconych identyfikatorów modeli,
|
||||
takich jak `acme-large`, zanim pojawią się hooki runtime. Jeśli publikujesz
|
||||
poświadczenia bez ładowania runtime Twojego pluginu. Dodaj `providerAuthAliases`,
|
||||
gdy wariant dostawcy ma ponownie używać uwierzytelniania innego identyfikatora dostawcy. `modelSupport`
|
||||
jest opcjonalne i pozwala OpenClaw automatycznie ładować plugin dostawcy na podstawie skróconych
|
||||
identyfikatorów modeli, takich jak `acme-large`, zanim hooki runtime zaczną istnieć. Jeśli publikujesz
|
||||
dostawcę w ClawHub, pola `openclaw.compat` i `openclaw.build`
|
||||
są wymagane w `package.json`.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Zarejestruj dostawcę">
|
||||
Minimalny dostawca potrzebuje pól `id`, `label`, `auth` i `catalog`:
|
||||
Minimalny dostawca potrzebuje `id`, `label`, `auth` i `catalog`:
|
||||
|
||||
```typescript index.ts
|
||||
import { definePluginEntry } from "openclaw/plugin-sdk/plugin-entry";
|
||||
@ -167,13 +171,13 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
});
|
||||
```
|
||||
|
||||
To jest działający dostawca. Użytkownicy mogą teraz użyć
|
||||
`openclaw onboard --acme-ai-api-key <key>` i wybrać
|
||||
To jest działający dostawca. Użytkownicy mogą teraz
|
||||
użyć `openclaw onboard --acme-ai-api-key <key>` i wybrać
|
||||
`acme-ai/acme-large` jako swój model.
|
||||
|
||||
Dla bundlowanych dostawców, którzy rejestrują tylko jednego dostawcę tekstowego z
|
||||
uwierzytelnianiem kluczem API oraz pojedynczym runtime opartym na katalogu, preferuj węższy
|
||||
helper `defineSingleProviderPluginEntry(...)`:
|
||||
W przypadku bundlowanych dostawców, którzy rejestrują tylko jednego dostawcę tekstowego z
|
||||
uwierzytelnianiem kluczem API oraz pojedynczym runtime opartym na katalogu, wybierz raczej
|
||||
węższy helper `defineSingleProviderPluginEntry(...)`:
|
||||
|
||||
```typescript
|
||||
import { defineSingleProviderPluginEntry } from "openclaw/plugin-sdk/provider-entry";
|
||||
@ -208,8 +212,8 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
});
|
||||
```
|
||||
|
||||
Jeśli przepływ uwierzytelniania musi także modyfikować `models.providers.*`, aliasy i
|
||||
domyślny model agenta podczas onboardingu, użyj helperów presetów z
|
||||
Jeśli przepływ uwierzytelniania wymaga także modyfikacji `models.providers.*`, aliasów oraz
|
||||
domyślnego modelu agenta podczas onboardingu, użyj preset helperów z
|
||||
`openclaw/plugin-sdk/provider-onboard`. Najwęższe helpery to
|
||||
`createDefaultModelPresetAppliers(...)`,
|
||||
`createDefaultModelsPresetAppliers(...)` oraz
|
||||
@ -217,15 +221,15 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
|
||||
Gdy natywny endpoint dostawcy obsługuje strumieniowane bloki użycia na
|
||||
zwykłym transporcie `openai-completions`, preferuj współdzielone helpery katalogu z
|
||||
`openclaw/plugin-sdk/provider-catalog-shared` zamiast hardkodować sprawdzenia identyfikatorów
|
||||
dostawców. `supportsNativeStreamingUsageCompat(...)` i
|
||||
`openclaw/plugin-sdk/provider-catalog-shared` zamiast wpisywania na sztywno kontroli identyfikatora
|
||||
dostawcy. `supportsNativeStreamingUsageCompat(...)` i
|
||||
`applyProviderNativeStreamingUsageCompat(...)` wykrywają obsługę na podstawie mapy możliwości endpointu,
|
||||
więc natywne endpointy w stylu Moonshot/DashScope nadal optują się do tego mechanizmu,
|
||||
nawet gdy plugin używa niestandardowego identyfikatora dostawcy.
|
||||
dzięki czemu natywne endpointy w stylu Moonshot/DashScope nadal się kwalifikują, nawet jeśli
|
||||
plugin używa niestandardowego identyfikatora dostawcy.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Dodaj dynamiczne rozpoznawanie modeli">
|
||||
<Step title="Dodaj dynamiczne rozwiązywanie modeli">
|
||||
Jeśli dostawca akceptuje dowolne identyfikatory modeli (jak proxy lub router),
|
||||
dodaj `resolveDynamicModel`:
|
||||
|
||||
@ -248,17 +252,17 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
});
|
||||
```
|
||||
|
||||
Jeśli rozpoznanie wymaga wywołania sieciowego, użyj `prepareDynamicModel` do asynchronicznego
|
||||
rozgrzania — po jego zakończeniu `resolveDynamicModel` uruchamia się ponownie.
|
||||
Jeśli rozwiązywanie wymaga wywołania sieciowego, użyj `prepareDynamicModel` do asynchronicznego
|
||||
warm-upu — `resolveDynamicModel` uruchomi się ponownie po jego zakończeniu.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Dodaj hooki runtime (w razie potrzeby)">
|
||||
Większość dostawców potrzebuje tylko `catalog` + `resolveDynamicModel`. Dodawaj hooki
|
||||
stopniowo, zależnie od wymagań dostawcy.
|
||||
stopniowo, w miarę jak dostawca ich wymaga.
|
||||
|
||||
Współdzielone buildery helperów obejmują teraz najczęstsze rodziny zgodności replay/tool,
|
||||
więc pluginy zwykle nie muszą ręcznie okablowywać każdego hooka jeden po drugim:
|
||||
więc pluginy zwykle nie muszą ręcznie podłączać każdego hooka osobno:
|
||||
|
||||
```typescript
|
||||
import { buildProviderReplayFamilyHooks } from "openclaw/plugin-sdk/provider-model-shared";
|
||||
@ -278,17 +282,17 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
});
|
||||
```
|
||||
|
||||
Obecnie dostępne rodziny replay:
|
||||
Dostępne dziś rodziny replay:
|
||||
|
||||
| Rodzina | Co okablowuje |
|
||||
| Family | Co podłącza |
|
||||
| --- | --- |
|
||||
| `openai-compatible` | Współdzielona polityka replay w stylu OpenAI dla transportów zgodnych z OpenAI, w tym sanityzację `tool-call-id`, poprawki kolejności assistant-first oraz ogólną walidację tur Gemini tam, gdzie transport tego wymaga |
|
||||
| `anthropic-by-model` | Świadoma Claude polityka replay wybierana według `modelId`, dzięki czemu transporty wiadomości Anthropic dostają czyszczenie bloków thinking specyficzne dla Claude tylko wtedy, gdy rozpoznany model jest rzeczywiście identyfikatorem Claude |
|
||||
| `google-gemini` | Natywna polityka replay Gemini plus sanityzacja replay bootstrap i oznaczony tryb wyjścia reasoning |
|
||||
| `passthrough-gemini` | Sanityzacja sygnatur thought Gemini dla modeli Gemini uruchamianych przez transporty proxy zgodne z OpenAI; nie włącza natywnej walidacji replay Gemini ani przepisywania bootstrap |
|
||||
| `hybrid-anthropic-openai` | Hybrydowa polityka dla dostawców, którzy mieszają powierzchnie modeli wiadomości Anthropic i transportów zgodnych z OpenAI w jednym pluginie; opcjonalne usuwanie bloków thinking tylko dla Claude pozostaje ograniczone do strony Anthropic |
|
||||
| `openai-compatible` | Współdzielona polityka replay w stylu OpenAI dla transportów zgodnych z OpenAI, w tym sanityzacja `tool-call-id`, poprawki kolejności assistant-first oraz ogólna walidacja tur Gemini tam, gdzie transport tego wymaga |
|
||||
| `anthropic-by-model` | Polityka replay świadoma Claude, wybierana według `modelId`, dzięki czemu transporty wiadomości Anthropic dostają czyszczenie bloków thinking specyficzne dla Claude tylko wtedy, gdy rozwiązany model rzeczywiście ma identyfikator Claude |
|
||||
| `google-gemini` | Natywna polityka replay Gemini oraz sanityzacja replay bootstrap i tryb oznaczonego wyjścia reasoning |
|
||||
| `passthrough-gemini` | Sanityzacja sygnatur myśli Gemini dla modeli Gemini uruchamianych przez transporty proxy zgodne z OpenAI; nie włącza natywnej walidacji replay Gemini ani przepisania bootstrap |
|
||||
| `hybrid-anthropic-openai` | Hybrydowa polityka dla dostawców, którzy łączą powierzchnie modeli wiadomości Anthropic i kompatybilnych z OpenAI w jednym pluginie; opcjonalne usuwanie bloków thinking tylko dla Claude pozostaje ograniczone do strony Anthropic |
|
||||
|
||||
Rzeczywiste bundlowane przykłady:
|
||||
Rzeczywiste przykłady bundlowane:
|
||||
|
||||
- `google` i `google-gemini-cli`: `google-gemini`
|
||||
- `openrouter`, `kilocode`, `opencode` i `opencode-go`: `passthrough-gemini`
|
||||
@ -296,19 +300,19 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
- `minimax`: `hybrid-anthropic-openai`
|
||||
- `moonshot`, `ollama`, `xai` i `zai`: `openai-compatible`
|
||||
|
||||
Obecnie dostępne rodziny stream:
|
||||
Dostępne dziś rodziny stream:
|
||||
|
||||
| Rodzina | Co okablowuje |
|
||||
| Family | Co podłącza |
|
||||
| --- | --- |
|
||||
| `google-thinking` | Normalizację ładunku thinking Gemini we współdzielonej ścieżce stream |
|
||||
| `kilocode-thinking` | Wrapper reasoning Kilo we współdzielonej ścieżce stream proxy, przy czym `kilo/auto` i nieobsługiwane identyfikatory reasoning proxy pomijają wstrzykiwane thinking |
|
||||
| `moonshot-thinking` | Mapowanie natywnego binarnego ładunku thinking Moonshot na podstawie konfiguracji + poziomu `/think` |
|
||||
| `minimax-fast-mode` | Przepisywanie modelu MiniMax fast-mode we współdzielonej ścieżce stream |
|
||||
| `openai-responses-defaults` | Współdzielone natywne wrappery OpenAI/Codex Responses: nagłówki atrybucji, `/fast`/`serviceTier`, szczegółowość tekstu, natywne wyszukiwanie w sieci Codex, kształtowanie ładunku zgodności reasoning oraz zarządzanie kontekstem Responses |
|
||||
| `openrouter-thinking` | Wrapper reasoning OpenRouter dla tras proxy, z centralnie obsługiwanym pomijaniem dla nieobsługiwanych modeli/`auto` |
|
||||
| `tool-stream-default-on` | Wrapper domyślnie włączający `tool_stream` dla dostawców takich jak Z.AI, którzy chcą strumieniowania narzędzi, o ile nie zostanie ono jawnie wyłączone |
|
||||
| `google-thinking` | Normalizacja payload thinking Gemini na współdzielonej ścieżce stream |
|
||||
| `kilocode-thinking` | Opakowanie reasoning Kilo na współdzielonej ścieżce stream proxy, z pomijaniem wstrzykiwanego thinking dla `kilo/auto` i nieobsługiwanych identyfikatorów reasoning proxy |
|
||||
| `moonshot-thinking` | Mapowanie natywnego binarnego payload thinking Moonshot z konfiguracji + poziomu `/think` |
|
||||
| `minimax-fast-mode` | Przepisanie modelu MiniMax fast-mode na współdzielonej ścieżce stream |
|
||||
| `openai-responses-defaults` | Współdzielone natywne opakowania OpenAI/Codex Responses: nagłówki atrybucji, `/fast`/`serviceTier`, szczegółowość tekstu, natywne wyszukiwanie w sieci Codex, kształtowanie payload zgodności reasoning oraz zarządzanie kontekstem Responses |
|
||||
| `openrouter-thinking` | Opakowanie reasoning OpenRouter dla tras proxy, z centralnie obsługiwanym pomijaniem modeli nieobsługiwanych/`auto` |
|
||||
| `tool-stream-default-on` | Domyślnie włączone opakowanie `tool_stream` dla dostawców takich jak Z.AI, którzy chcą strumieniowania narzędzi, chyba że zostanie to jawnie wyłączone |
|
||||
|
||||
Rzeczywiste bundlowane przykłady:
|
||||
Rzeczywiste przykłady bundlowane:
|
||||
|
||||
- `google` i `google-gemini-cli`: `google-thinking`
|
||||
- `kilocode`: `kilocode-thinking`
|
||||
@ -318,7 +322,7 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
- `openrouter`: `openrouter-thinking`
|
||||
- `zai`: `tool-stream-default-on`
|
||||
|
||||
`openclaw/plugin-sdk/provider-model-shared` eksportuje też enum rodziny replay
|
||||
`openclaw/plugin-sdk/provider-model-shared` eksportuje także enum rodziny replay
|
||||
oraz współdzielone helpery, z których te rodziny są zbudowane. Typowe publiczne
|
||||
eksporty obejmują:
|
||||
|
||||
@ -335,7 +339,7 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
`normalizeNativeXaiModelId(...)`
|
||||
|
||||
`openclaw/plugin-sdk/provider-stream` udostępnia zarówno builder rodziny, jak i
|
||||
publiczne helpery wrapperów, których te rodziny używają ponownie. Typowe publiczne eksporty
|
||||
publiczne helpery wrapperów ponownie używane przez te rodziny. Typowe publiczne eksporty
|
||||
obejmują:
|
||||
|
||||
- `ProviderStreamFamily`
|
||||
@ -348,51 +352,51 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
`createOpenAIResponsesContextManagementWrapper(...)` oraz
|
||||
`createCodexNativeWebSearchWrapper(...)`
|
||||
- współdzielone wrappery proxy/dostawców, takie jak `createOpenRouterWrapper(...)`,
|
||||
`createToolStreamWrapper(...)` oraz `createMinimaxFastModeWrapper(...)`
|
||||
`createToolStreamWrapper(...)` i `createMinimaxFastModeWrapper(...)`
|
||||
|
||||
Niektóre helpery stream celowo pozostają lokalne dla dostawcy. Obecny bundlowany
|
||||
przykład: `@openclaw/anthropic-provider` eksportuje
|
||||
Niektóre helpery stream celowo pozostają lokalne dla dostawcy. Obecny
|
||||
bundlowany przykład: `@openclaw/anthropic-provider` eksportuje
|
||||
`wrapAnthropicProviderStream`, `resolveAnthropicBetas`,
|
||||
`resolveAnthropicFastMode`, `resolveAnthropicServiceTier` oraz
|
||||
buildery wrapperów Anthropic niższego poziomu przez publiczny interfejs `api.ts` /
|
||||
wrappery Anthropic niższego poziomu przez swój publiczny punkt styku `api.ts` /
|
||||
`contract-api.ts`. Te helpery pozostają specyficzne dla Anthropic, ponieważ
|
||||
kodują też obsługę beta dla Claude OAuth i bramkowanie `context1m`.
|
||||
kodują także obsługę beta Claude OAuth i bramkowanie `context1m`.
|
||||
|
||||
Inni bundlowani dostawcy również trzymają wrappery specyficzne dla transportu lokalnie, gdy
|
||||
zachowanie nie daje się czysto współdzielić między rodzinami. Obecny przykład: bundlowany
|
||||
plugin xAI przechowuje natywne kształtowanie xAI Responses we własnym
|
||||
`wrapStreamFn`, w tym przepisywanie aliasów `/fast`, domyślne `tool_stream`,
|
||||
czyszczenie nieobsługiwanych strict-tool oraz usuwanie
|
||||
ładunku reasoning specyficznego dla xAI.
|
||||
Inni bundlowani dostawcy także zachowują wrappery specyficzne dla transportu lokalnie, gdy
|
||||
zachowanie nie jest współdzielone w czysty sposób między rodzinami. Obecny przykład: bundlowany
|
||||
plugin xAI zachowuje natywne kształtowanie xAI Responses we własnym
|
||||
`wrapStreamFn`, w tym przepisania aliasów `/fast`, domyślne `tool_stream`,
|
||||
czyszczenie nieobsługiwanych strict-tool oraz usuwanie payload reasoning
|
||||
specyficznego dla xAI.
|
||||
|
||||
`openclaw/plugin-sdk/provider-tools` obecnie udostępnia jedną współdzieloną
|
||||
rodzinę schematów narzędzi oraz współdzielone helpery schematów/zgodności:
|
||||
`openclaw/plugin-sdk/provider-tools` udostępnia obecnie jedną współdzieloną
|
||||
rodzinę schematu narzędzi oraz współdzielone helpery schematów/zgodności:
|
||||
|
||||
- `ProviderToolCompatFamily` dokumentuje obecny zestaw współdzielonych rodzin.
|
||||
- `buildProviderToolCompatFamilyHooks("gemini")` okablowuje czyszczenie
|
||||
schematów Gemini + diagnostykę dla dostawców, którzy potrzebują schematów narzędzi bezpiecznych dla Gemini.
|
||||
- `ProviderToolCompatFamily` dokumentuje dzisiejszy współdzielony zbiór rodzin.
|
||||
- `buildProviderToolCompatFamilyHooks("gemini")` podłącza czyszczenie schematów Gemini
|
||||
+ diagnostykę dla dostawców, którzy potrzebują schematów narzędzi bezpiecznych dla Gemini.
|
||||
- `normalizeGeminiToolSchemas(...)` i `inspectGeminiToolSchemas(...)`
|
||||
to bazowe publiczne helpery schematów Gemini.
|
||||
- `resolveXaiModelCompatPatch()` zwraca bundlowaną łatkę zgodności xAI:
|
||||
`toolSchemaProfile: "xai"`, nieobsługiwane słowa kluczowe schematu, natywne wsparcie
|
||||
`web_search` oraz dekodowanie argumentów wywołań narzędzi z encji HTML.
|
||||
- `applyXaiModelCompat(model)` stosuje tę samą łatkę zgodności xAI do rozpoznanego
|
||||
modelu, zanim trafi on do runnera.
|
||||
to bazowe publiczne helpery schematu Gemini.
|
||||
- `resolveXaiModelCompatPatch()` zwraca bundlowany patch zgodności xAI:
|
||||
`toolSchemaProfile: "xai"`, nieobsługiwane słowa kluczowe schematu, natywne
|
||||
wsparcie `web_search` oraz dekodowanie argumentów wywołań narzędzi z encjami HTML.
|
||||
- `applyXaiModelCompat(model)` stosuje ten sam patch zgodności xAI do
|
||||
rozwiązanego modelu, zanim trafi on do runnera.
|
||||
|
||||
Rzeczywisty bundlowany przykład: plugin xAI używa `normalizeResolvedModel` oraz
|
||||
`contributeResolvedModelCompat`, aby zachować metadane zgodności po stronie dostawcy
|
||||
zamiast hardkodować reguły xAI w rdzeniu.
|
||||
`contributeResolvedModelCompat`, aby zachować metadane zgodności po stronie
|
||||
dostawcy zamiast wpisywać reguły xAI na sztywno w core.
|
||||
|
||||
Ten sam wzorzec katalogu głównego pakietu wspiera też innych bundlowanych dostawców:
|
||||
Ten sam wzorzec katalogu głównego pakietu stanowi też podstawę dla innych bundlowanych dostawców:
|
||||
|
||||
- `@openclaw/openai-provider`: `api.ts` eksportuje buildery dostawców,
|
||||
helpery modeli domyślnych i buildery dostawców realtime
|
||||
helpery modeli domyślnych oraz buildery dostawców realtime
|
||||
- `@openclaw/openrouter-provider`: `api.ts` eksportuje builder dostawcy
|
||||
oraz helpery onboardingu/konfiguracji
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Wymiana tokenu">
|
||||
Dla dostawców, którzy potrzebują wymiany tokenu przed każdym wywołaniem inferencji:
|
||||
<Tab title="Wymiana tokena">
|
||||
Dla dostawców, którzy wymagają wymiany tokena przed każdym wywołaniem inferencji:
|
||||
|
||||
```typescript
|
||||
prepareRuntimeAuth: async (ctx) => {
|
||||
@ -406,7 +410,7 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="Niestandardowe nagłówki">
|
||||
Dla dostawców, którzy potrzebują niestandardowych nagłówków żądania lub modyfikacji body:
|
||||
Dla dostawców, którzy wymagają niestandardowych nagłówków żądań lub modyfikacji treści żądania:
|
||||
|
||||
```typescript
|
||||
// wrapStreamFn returns a StreamFn derived from ctx.streamFn
|
||||
@ -424,8 +428,8 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
```
|
||||
</Tab>
|
||||
<Tab title="Tożsamość natywnego transportu">
|
||||
Dla dostawców, którzy potrzebują natywnych nagłówków lub metadanych żądania/sesji
|
||||
przy ogólnych transportach HTTP lub WebSocket:
|
||||
Dla dostawców, którzy potrzebują natywnych nagłówków lub metadanych żądania/sesji w
|
||||
ogólnych transportach HTTP lub WebSocket:
|
||||
|
||||
```typescript
|
||||
resolveTransportTurnState: (ctx) => ({
|
||||
@ -461,7 +465,7 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
</Tabs>
|
||||
|
||||
<Accordion title="Wszystkie dostępne hooki dostawcy">
|
||||
OpenClaw wywołuje hooki w tej kolejności. Większość dostawców używa tylko 2–3:
|
||||
OpenClaw wywołuje hooki w tej kolejności. Większość dostawców używa tylko 2-3:
|
||||
|
||||
| # | Hook | Kiedy używać |
|
||||
| --- | --- | --- |
|
||||
@ -469,64 +473,65 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
| 2 | `applyConfigDefaults` | Globalne wartości domyślne należące do dostawcy podczas materializacji konfiguracji |
|
||||
| 3 | `normalizeModelId` | Czyszczenie aliasów starszych/podglądowych identyfikatorów modeli przed wyszukiwaniem |
|
||||
| 4 | `normalizeTransport` | Czyszczenie `api` / `baseUrl` dla rodziny dostawców przed ogólnym składaniem modelu |
|
||||
| 5 | `normalizeConfig` | Normalizuje konfigurację `models.providers.<id>` |
|
||||
| 6 | `applyNativeStreamingUsageCompat` | Przepisania zgodności natywnego użycia strumieniowego dla dostawców konfiguracyjnych |
|
||||
| 7 | `resolveConfigApiKey` | Rozpoznawanie auth z markerów env należące do dostawcy |
|
||||
| 8 | `resolveSyntheticAuth` | Syntetyczne auth lokalne/self-hosted lub oparte na konfiguracji |
|
||||
| 9 | `shouldDeferSyntheticProfileAuth` | Obniża priorytet syntetycznych placeholderów zapisanych profili względem auth z env/konfiguracji |
|
||||
| 10 | `resolveDynamicModel` | Akceptuje dowolne identyfikatory modeli upstream |
|
||||
| 11 | `prepareDynamicModel` | Asynchroniczne pobieranie metadanych przed rozpoznaniem |
|
||||
| 5 | `normalizeConfig` | Normalizacja konfiguracji `models.providers.<id>` |
|
||||
| 6 | `applyNativeStreamingUsageCompat` | Przepisania zgodności natywnego strumieniowanego użycia dla dostawców konfiguracyjnych |
|
||||
| 7 | `resolveConfigApiKey` | Rozwiązywanie uwierzytelniania markerów środowiska należące do dostawcy |
|
||||
| 8 | `resolveSyntheticAuth` | Syntetyczne uwierzytelnianie lokalne/self-hosted lub oparte na konfiguracji |
|
||||
| 9 | `shouldDeferSyntheticProfileAuth` | Obniżanie priorytetu syntetycznych placeholderów profili zapisanych względem uwierzytelniania env/config |
|
||||
| 10 | `resolveDynamicModel` | Akceptowanie dowolnych nadrzędnych identyfikatorów modeli |
|
||||
| 11 | `prepareDynamicModel` | Asynchroniczne pobieranie metadanych przed rozwiązaniem |
|
||||
| 12 | `normalizeResolvedModel` | Przepisania transportu przed runnerem |
|
||||
|
||||
Uwagi o fallback runtime:
|
||||
Uwagi o fallbacku runtime:
|
||||
|
||||
- `normalizeConfig` najpierw sprawdza dopasowanego dostawcę, a potem inne
|
||||
pluginy dostawców z hookami, dopóki któryś rzeczywiście nie zmieni konfiguracji.
|
||||
- `normalizeConfig` najpierw sprawdza dopasowanego dostawcę, a potem innych
|
||||
dostawców z hookami, aż któryś faktycznie zmieni konfigurację.
|
||||
Jeśli żaden hook dostawcy nie przepisze obsługiwanego wpisu konfiguracji rodziny Google,
|
||||
nadal zostanie zastosowany bundlowany normalizator konfiguracji Google.
|
||||
- `resolveConfigApiKey` używa hooka dostawcy, gdy jest on udostępniony. Bundlowana
|
||||
ścieżka `amazon-bedrock` ma też tutaj wbudowany resolver auth z markerów env AWS,
|
||||
mimo że auth runtime Bedrock nadal używa domyślnego łańcucha AWS SDK.
|
||||
| 13 | `contributeResolvedModelCompat` | Flagi zgodności dla modeli dostawców działających za innym zgodnym transportem |
|
||||
| 14 | `capabilities` | Starszy statyczny zestaw możliwości; tylko zgodność |
|
||||
nadal zastosowany zostanie bundlowany normalizator konfiguracji Google.
|
||||
- `resolveConfigApiKey` używa hooka dostawcy, gdy jest udostępniony. Bundlowana
|
||||
ścieżka `amazon-bedrock` ma tutaj również wbudowany resolver markerów środowiska AWS,
|
||||
mimo że samo uwierzytelnianie runtime Bedrock nadal używa domyślnego
|
||||
łańcucha AWS SDK.
|
||||
| 13 | `contributeResolvedModelCompat` | Flagi zgodności dla modeli dostawców działających przez inny zgodny transport |
|
||||
| 14 | `capabilities` | Starszy statyczny zbiór możliwości; tylko dla zgodności |
|
||||
| 15 | `normalizeToolSchemas` | Czyszczenie schematów narzędzi należące do dostawcy przed rejestracją |
|
||||
| 16 | `inspectToolSchemas` | Diagnostyka schematów narzędzi należąca do dostawcy |
|
||||
| 17 | `resolveReasoningOutputMode` | Kontrakt oznaczonego vs natywnego wyjścia reasoning |
|
||||
| 18 | `prepareExtraParams` | Domyślne parametry żądań |
|
||||
| 18 | `prepareExtraParams` | Domyślne parametry żądania |
|
||||
| 19 | `createStreamFn` | W pełni niestandardowy transport StreamFn |
|
||||
| 20 | `wrapStreamFn` | Wrappery niestandardowych nagłówków/body na zwykłej ścieżce stream |
|
||||
| 21 | `resolveTransportTurnState` | Natywne nagłówki/metadane dla każdej tury |
|
||||
| 22 | `resolveWebSocketSessionPolicy` | Natywne nagłówki sesji WS/cool-down |
|
||||
| 23 | `formatApiKey` | Niestandardowy kształt tokenu runtime |
|
||||
| 20 | `wrapStreamFn` | Wrappery niestandardowych nagłówków/treści na zwykłej ścieżce stream |
|
||||
| 21 | `resolveTransportTurnState` | Natywne nagłówki/metadane per turn |
|
||||
| 22 | `resolveWebSocketSessionPolicy` | Natywne nagłówki sesji WS / cooldown |
|
||||
| 23 | `formatApiKey` | Niestandardowy kształt tokena runtime |
|
||||
| 24 | `refreshOAuth` | Niestandardowe odświeżanie OAuth |
|
||||
| 25 | `buildAuthDoctorHint` | Wskazówki naprawy auth |
|
||||
| 26 | `matchesContextOverflowError` | Wykrywanie przepełnienia należące do dostawcy |
|
||||
| 25 | `buildAuthDoctorHint` | Wskazówki naprawy uwierzytelniania |
|
||||
| 26 | `matchesContextOverflowError` | Wykrywanie overflow należące do dostawcy |
|
||||
| 27 | `classifyFailoverReason` | Klasyfikacja rate-limit/overload należąca do dostawcy |
|
||||
| 28 | `isCacheTtlEligible` | Bramka TTL cache promptów |
|
||||
| 29 | `buildMissingAuthMessage` | Niestandardowa wskazówka braku auth |
|
||||
| 30 | `suppressBuiltInModel` | Ukrywa nieaktualne wiersze upstream |
|
||||
| 28 | `isCacheTtlEligible` | Bramka TTL dla cache promptów |
|
||||
| 29 | `buildMissingAuthMessage` | Niestandardowa wskazówka brakującego uwierzytelniania |
|
||||
| 30 | `suppressBuiltInModel` | Ukrywanie nieaktualnych wierszy upstream |
|
||||
| 31 | `augmentModelCatalog` | Syntetyczne wiersze forward-compat |
|
||||
| 32 | `isBinaryThinking` | Binarne włączanie/wyłączanie thinking |
|
||||
| 33 | `supportsXHighThinking` | Obsługa reasoning `xhigh` |
|
||||
| 34 | `resolveDefaultThinkingLevel` | Domyślna polityka `/think` |
|
||||
| 35 | `isModernModelRef` | Dopasowanie modeli live/smoke |
|
||||
| 36 | `prepareRuntimeAuth` | Wymiana tokenu przed inferencją |
|
||||
| 36 | `prepareRuntimeAuth` | Wymiana tokena przed inferencją |
|
||||
| 37 | `resolveUsageAuth` | Niestandardowe parsowanie poświadczeń użycia |
|
||||
| 38 | `fetchUsageSnapshot` | Niestandardowy endpoint użycia |
|
||||
| 39 | `createEmbeddingProvider` | Adapter embeddingów należący do dostawcy dla memory/search |
|
||||
| 40 | `buildReplayPolicy` | Niestandardowa polityka replay/kompaktowania transkryptu |
|
||||
| 41 | `sanitizeReplayHistory` | Przepisania replay specyficzne dla dostawcy po ogólnym czyszczeniu |
|
||||
| 42 | `validateReplayTurns` | Ścisła walidacja tur replay przed osadzonym runnerem |
|
||||
| 43 | `onModelSelected` | Callback po wyborze modelu (np. telemetria) |
|
||||
| 43 | `onModelSelected` | Callback po wyborze modelu (np. telemetry) |
|
||||
|
||||
Uwaga o dostrajaniu promptów:
|
||||
|
||||
- `resolveSystemPromptContribution` pozwala dostawcy wstrzykiwać świadome cache
|
||||
wskazówki do promptu systemowego dla rodziny modeli. Preferuj to zamiast
|
||||
- `resolveSystemPromptContribution` pozwala dostawcy wstrzykiwać wskazówki
|
||||
do system promptu świadome cache dla rodziny modeli. Preferuj je zamiast
|
||||
`before_prompt_build`, gdy zachowanie należy do jednej rodziny dostawcy/modeli
|
||||
i powinno zachować stabilny/dynamiczny podział cache.
|
||||
|
||||
Szczegółowe opisy i rzeczywiste przykłady znajdziesz w
|
||||
Szczegółowe opisy i przykłady z rzeczywistego użycia znajdziesz w
|
||||
[Internals: Provider Runtime Hooks](/pl/plugins/architecture#provider-runtime-hooks).
|
||||
</Accordion>
|
||||
|
||||
@ -534,9 +539,9 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
|
||||
<Step title="Dodaj dodatkowe możliwości (opcjonalnie)">
|
||||
<a id="step-5-add-extra-capabilities"></a>
|
||||
Plugin dostawcy może rejestrować mowę, transkrypcję realtime, głos realtime,
|
||||
rozumienie mediów, generowanie obrazów, generowanie wideo, web fetch
|
||||
i web search obok inferencji tekstowej:
|
||||
Plugin dostawcy może rejestrować dostawców speech, realtime transcription, realtime
|
||||
voice, media understanding, image generation, video generation, web fetch
|
||||
i web search równolegle z inferencją tekstową:
|
||||
|
||||
```typescript
|
||||
register(api) {
|
||||
@ -644,20 +649,20 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
}
|
||||
```
|
||||
|
||||
OpenClaw klasyfikuje to jako plugin **hybrid-capability**. Jest to
|
||||
OpenClaw klasyfikuje to jako plugin **hybrid-capability**. To
|
||||
zalecany wzorzec dla pluginów firmowych (jeden plugin na dostawcę). Zobacz
|
||||
[Internals: Capability Ownership](/pl/plugins/architecture#capability-ownership-model).
|
||||
|
||||
Dla generowania wideo preferuj pokazany wyżej kształt możliwości świadomy trybów:
|
||||
`generate`, `imageToVideo` i `videoToVideo`. Płaskie pola zagregowane, takie
|
||||
W przypadku generowania wideo preferuj pokazany powyżej kształt możliwości świadomy trybu:
|
||||
`generate`, `imageToVideo` i `videoToVideo`. Płaskie pola zbiorcze, takie
|
||||
jak `maxInputImages`, `maxInputVideos` i `maxDurationSeconds`, nie
|
||||
wystarczają, aby czytelnie reklamować obsługę trybów transformacji lub wyłączonych trybów.
|
||||
wystarczają, aby w czytelny sposób reklamować obsługę trybów transformacji lub tryby wyłączone.
|
||||
|
||||
Dostawcy generowania muzyki powinni stosować ten sam wzorzec:
|
||||
`generate` dla generowania wyłącznie z promptu oraz `edit` dla
|
||||
generowania na podstawie obrazu referencyjnego. Płaskie pola zagregowane, takie jak `maxInputImages`,
|
||||
`supportsLyrics` i `supportsFormat`, nie wystarczają do reklamowania obsługi
|
||||
edycji; oczekiwanym kontraktem są jawne bloki `generate` / `edit`.
|
||||
`generate` dla generowania tylko z promptu oraz `edit` dla generowania
|
||||
opartego na obrazie referencyjnym. Płaskie pola zbiorcze, takie jak `maxInputImages`,
|
||||
`supportsLyrics` i `supportsFormat`, nie wystarczają do reklamowania obsługi edycji;
|
||||
oczekiwanym kontraktem są jawne bloki `generate` / `edit`.
|
||||
|
||||
</Step>
|
||||
|
||||
@ -696,7 +701,7 @@ uwierzytelnianiem kluczem API i dynamicznym rozpoznawaniem modeli.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Publikacja w ClawHub
|
||||
## Publikowanie w ClawHub
|
||||
|
||||
Pluginy dostawców publikuje się tak samo jak każdy inny zewnętrzny plugin kodu:
|
||||
|
||||
@ -705,36 +710,36 @@ clawhub package publish your-org/your-plugin --dry-run
|
||||
clawhub package publish your-org/your-plugin
|
||||
```
|
||||
|
||||
Nie używaj tutaj starszego aliasu publikacji tylko dla Skills; pakiety pluginów powinny używać
|
||||
Nie używaj tutaj starszego aliasu publikowania tylko dla Skills; pakiety pluginów powinny używać
|
||||
`clawhub package publish`.
|
||||
|
||||
## Struktura plików
|
||||
|
||||
```
|
||||
<bundled-plugin-root>/acme-ai/
|
||||
├── package.json # openclaw.providers metadata
|
||||
├── openclaw.plugin.json # Manifest with providerAuthEnvVars
|
||||
├── package.json # metadane openclaw.providers
|
||||
├── openclaw.plugin.json # Manifest z metadanymi uwierzytelniania dostawcy
|
||||
├── index.ts # definePluginEntry + registerProvider
|
||||
└── src/
|
||||
├── provider.test.ts # Tests
|
||||
└── usage.ts # Usage endpoint (optional)
|
||||
├── provider.test.ts # Testy
|
||||
└── usage.ts # Endpoint użycia (opcjonalnie)
|
||||
```
|
||||
|
||||
## Opis kolejności katalogu
|
||||
## Informacje o kolejności katalogu
|
||||
|
||||
`catalog.order` określa, kiedy katalog jest scalany względem wbudowanych
|
||||
`catalog.order` kontroluje, kiedy katalog jest scalany względem wbudowanych
|
||||
dostawców:
|
||||
|
||||
| Kolejność | Kiedy | Przypadek użycia |
|
||||
| --------- | ------------ | --------------------------------------------- |
|
||||
| `simple` | Pierwsze przejście | Prości dostawcy z kluczem API |
|
||||
| `profile` | Po `simple` | Dostawcy zależni od profili auth |
|
||||
| `paired` | Po `profile` | Syntetyzowanie wielu powiązanych wpisów |
|
||||
| Order | Kiedy | Przypadek użycia |
|
||||
| --------- | ------------ | ----------------------------------------------- |
|
||||
| `simple` | Pierwsze przejście | Zwykli dostawcy z kluczem API |
|
||||
| `profile` | Po `simple` | Dostawcy zależni od profili uwierzytelniania |
|
||||
| `paired` | Po `profile` | Syntezowanie wielu powiązanych wpisów |
|
||||
| `late` | Ostatnie przejście | Nadpisywanie istniejących dostawców (wygrywa przy kolizji) |
|
||||
|
||||
## Kolejne kroki
|
||||
|
||||
- [Channel Plugins](/pl/plugins/sdk-channel-plugins) — jeśli plugin dostarcza także kanał
|
||||
- [Channel Plugins](/pl/plugins/sdk-channel-plugins) — jeśli plugin udostępnia także kanał
|
||||
- [SDK Runtime](/pl/plugins/sdk-runtime) — helpery `api.runtime` (TTS, search, subagent)
|
||||
- [SDK Overview](/pl/plugins/sdk-overview) — pełne odniesienie do importów subpath
|
||||
- [SDK Overview](/pl/plugins/sdk-overview) — pełne odwołanie do importów podścieżek
|
||||
- [Plugin Internals](/pl/plugins/architecture#provider-runtime-hooks) — szczegóły hooków i bundlowane przykłady
|
||||
|
||||
@ -3,13 +3,13 @@ read_when:
|
||||
- Chcesz uruchomić OpenClaw z lokalnym serwerem inferrs
|
||||
- Udostępniasz Gemma lub inny model przez inferrs
|
||||
- Potrzebujesz dokładnych flag zgodności OpenClaw dla inferrs
|
||||
summary: Uruchamianie OpenClaw przez inferrs (lokalny serwer zgodny z OpenAI)
|
||||
summary: Uruchamiaj OpenClaw przez inferrs (lokalny serwer zgodny z OpenAI)
|
||||
title: inferrs
|
||||
x-i18n:
|
||||
generated_at: "2026-04-08T02:17:28Z"
|
||||
generated_at: "2026-04-09T01:29:49Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: d84f660d49a682d0c0878707eebe1bc1e83dd115850687076ea3938b9f9c86c6
|
||||
source_hash: 03b9d5a9935c75fd369068bacb7807a5308cd0bd74303b664227fb664c3a2098
|
||||
source_path: providers/inferrs.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -20,8 +20,8 @@ x-i18n:
|
||||
interfejsem API `/v1` zgodnym z OpenAI. OpenClaw współpracuje z `inferrs` przez ogólną
|
||||
ścieżkę `openai-completions`.
|
||||
|
||||
`inferrs` najlepiej obecnie traktować jako niestandardowy, samodzielnie hostowany backend
|
||||
zgodny z OpenAI, a nie dedykowaną wtyczkę dostawcy OpenClaw.
|
||||
`inferrs` najlepiej obecnie traktować jako niestandardowy, self-hosted
|
||||
backend zgodny z OpenAI, a nie dedykowaną wtyczkę dostawcy OpenClaw.
|
||||
|
||||
## Szybki start
|
||||
|
||||
@ -30,7 +30,7 @@ zgodny z OpenAI, a nie dedykowaną wtyczkę dostawcy OpenClaw.
|
||||
Przykład:
|
||||
|
||||
```bash
|
||||
inferrs serve gg-hf-gg/gemma-4-E2B-it \
|
||||
inferrs serve google/gemma-4-E2B-it \
|
||||
--host 127.0.0.1 \
|
||||
--port 8080 \
|
||||
--device metal
|
||||
@ -43,7 +43,7 @@ curl http://127.0.0.1:8080/health
|
||||
curl http://127.0.0.1:8080/v1/models
|
||||
```
|
||||
|
||||
3. Dodaj jawny wpis dostawcy OpenClaw i skieruj na niego swój model domyślny.
|
||||
3. Dodaj jawny wpis dostawcy OpenClaw i skieruj na niego swój domyślny model.
|
||||
|
||||
## Pełny przykład konfiguracji
|
||||
|
||||
@ -53,9 +53,9 @@ Ten przykład używa Gemma 4 na lokalnym serwerze `inferrs`.
|
||||
{
|
||||
agents: {
|
||||
defaults: {
|
||||
model: { primary: "inferrs/gg-hf-gg/gemma-4-E2B-it" },
|
||||
model: { primary: "inferrs/google/gemma-4-E2B-it" },
|
||||
models: {
|
||||
"inferrs/gg-hf-gg/gemma-4-E2B-it": {
|
||||
"inferrs/google/gemma-4-E2B-it": {
|
||||
alias: "Gemma 4 (inferrs)",
|
||||
},
|
||||
},
|
||||
@ -70,7 +70,7 @@ Ten przykład używa Gemma 4 na lokalnym serwerze `inferrs`.
|
||||
api: "openai-completions",
|
||||
models: [
|
||||
{
|
||||
id: "gg-hf-gg/gemma-4-E2B-it",
|
||||
id: "google/gemma-4-E2B-it",
|
||||
name: "Gemma 4 E2B (inferrs)",
|
||||
reasoning: false,
|
||||
input: ["text"],
|
||||
@ -90,8 +90,8 @@ Ten przykład używa Gemma 4 na lokalnym serwerze `inferrs`.
|
||||
|
||||
## Dlaczego `requiresStringContent` ma znaczenie
|
||||
|
||||
Niektóre ścieżki Chat Completions w `inferrs` akceptują tylko ciąg znaków w
|
||||
`messages[].content`, a nie strukturalne tablice części treści.
|
||||
Niektóre trasy Chat Completions w `inferrs` akceptują tylko ciąg znaków w
|
||||
`messages[].content`, a nie ustrukturyzowane tablice części treści.
|
||||
|
||||
Jeśli uruchomienia OpenClaw kończą się błędem takim jak:
|
||||
|
||||
@ -107,13 +107,13 @@ compat: {
|
||||
}
|
||||
```
|
||||
|
||||
OpenClaw spłaszczy części treści zawierające wyłącznie tekst do zwykłych ciągów znaków przed wysłaniem
|
||||
żądania.
|
||||
OpenClaw spłaszczy części treści zawierające wyłącznie tekst do zwykłych ciągów
|
||||
przed wysłaniem żądania.
|
||||
|
||||
## Zastrzeżenie dotyczące Gemma i schematu narzędzi
|
||||
|
||||
Niektóre obecne kombinacje `inferrs` + Gemma akceptują małe, bezpośrednie
|
||||
żądania `/v1/chat/completions`, ale nadal kończą się niepowodzeniem przy pełnych turach
|
||||
żądania do `/v1/chat/completions`, ale nadal kończą się błędem przy pełnych turnach
|
||||
runtime agenta OpenClaw.
|
||||
|
||||
Jeśli tak się dzieje, najpierw spróbuj tego:
|
||||
@ -125,55 +125,56 @@ compat: {
|
||||
}
|
||||
```
|
||||
|
||||
To wyłącza powierzchnię schematu narzędzi OpenClaw dla modelu i może zmniejszyć presję promptu
|
||||
To wyłącza powierzchnię schematu narzędzi OpenClaw dla modelu i może zmniejszyć nacisk promptu
|
||||
na bardziej restrykcyjnych lokalnych backendach.
|
||||
|
||||
Jeśli małe bezpośrednie żądania nadal działają, ale zwykłe tury agenta OpenClaw wciąż
|
||||
powodują awarie wewnątrz `inferrs`, pozostały problem zwykle leży po stronie zachowania modelu/serwera upstream, a nie warstwy transportowej OpenClaw.
|
||||
Jeśli małe bezpośrednie żądania nadal działają, ale zwykłe turny agenta OpenClaw dalej
|
||||
powodują awarie wewnątrz `inferrs`, pozostały problem zwykle dotyczy zachowania
|
||||
upstream modelu/serwera, a nie warstwy transportu OpenClaw.
|
||||
|
||||
## Ręczny test smoke
|
||||
|
||||
Po konfiguracji przetestuj obie warstwy:
|
||||
Po skonfigurowaniu przetestuj obie warstwy:
|
||||
|
||||
```bash
|
||||
curl http://127.0.0.1:8080/v1/chat/completions \
|
||||
-H 'content-type: application/json' \
|
||||
-d '{"model":"gg-hf-gg/gemma-4-E2B-it","messages":[{"role":"user","content":"What is 2 + 2?"}],"stream":false}'
|
||||
-d '{"model":"google/gemma-4-E2B-it","messages":[{"role":"user","content":"What is 2 + 2?"}],"stream":false}'
|
||||
|
||||
openclaw infer model run \
|
||||
--model inferrs/gg-hf-gg/gemma-4-E2B-it \
|
||||
--model inferrs/google/gemma-4-E2B-it \
|
||||
--prompt "What is 2 + 2? Reply with one short sentence." \
|
||||
--json
|
||||
```
|
||||
|
||||
Jeśli pierwsze polecenie działa, ale drugie kończy się niepowodzeniem, skorzystaj z poniższych uwag
|
||||
dotyczących rozwiązywania problemów.
|
||||
Jeśli pierwsze polecenie działa, ale drugie kończy się błędem, skorzystaj z poniższych
|
||||
wskazówek rozwiązywania problemów.
|
||||
|
||||
## Rozwiązywanie problemów
|
||||
|
||||
- `curl /v1/models` kończy się niepowodzeniem: `inferrs` nie działa, nie jest osiągalny lub nie
|
||||
jest powiązany z oczekiwanym hostem/portem.
|
||||
- `curl /v1/models` kończy się błędem: `inferrs` nie działa, nie jest osiągalny lub nie
|
||||
jest zbindowany do oczekiwanego hosta/portu.
|
||||
- `messages[].content ... expected a string`: ustaw
|
||||
`compat.requiresStringContent: true`.
|
||||
- Bezpośrednie małe wywołania `/v1/chat/completions` przechodzą, ale `openclaw infer model run`
|
||||
kończy się niepowodzeniem: spróbuj `compat.supportsTools: false`.
|
||||
kończy się błędem: spróbuj `compat.supportsTools: false`.
|
||||
- OpenClaw nie dostaje już błędów schematu, ale `inferrs` nadal ulega awarii przy większych
|
||||
turach agenta: potraktuj to jako ograniczenie `inferrs` lub modelu upstream i zmniejsz
|
||||
presję promptu albo zmień lokalny backend/model.
|
||||
turnach agenta: potraktuj to jako ograniczenie `inferrs` lub modelu upstream i zmniejsz
|
||||
nacisk promptu albo zmień lokalny backend/model.
|
||||
|
||||
## Zachowanie w stylu proxy
|
||||
|
||||
`inferrs` jest traktowany jako backend `/v1` zgodny z OpenAI w stylu proxy, a nie
|
||||
natywny endpoint OpenAI.
|
||||
|
||||
- natywne kształtowanie żądań tylko dla OpenAI nie ma tu zastosowania
|
||||
- brak `service_tier`, brak `store` dla Responses, brak wskazówek prompt-cache i brak
|
||||
kształtowania ładunku zgodności reasoning OpenAI
|
||||
- natywne kształtowanie żądań wyłącznie dla OpenAI nie ma tu zastosowania
|
||||
- brak `service_tier`, brak `store` dla Responses, brak wskazówek cache promptów i brak
|
||||
kształtowania payload zgodności reasoning OpenAI
|
||||
- ukryte nagłówki atrybucji OpenClaw (`originator`, `version`, `User-Agent`)
|
||||
nie są wstrzykiwane do niestandardowych adresów `inferrs` base URLs
|
||||
nie są wstrzykiwane dla niestandardowych base URL `inferrs`
|
||||
|
||||
## Zobacz też
|
||||
|
||||
- [Modele lokalne](/pl/gateway/local-models)
|
||||
- [Rozwiązywanie problemów z gatewayem](/pl/gateway/troubleshooting#local-openai-compatible-backend-passes-direct-probes-but-agent-runs-fail)
|
||||
- [Dostawcy modeli](/pl/concepts/model-providers)
|
||||
- [Local models](/pl/gateway/local-models)
|
||||
- [Gateway troubleshooting](/pl/gateway/troubleshooting#local-openai-compatible-backend-passes-direct-probes-but-agent-runs-fail)
|
||||
- [Model providers](/pl/concepts/model-providers)
|
||||
|
||||
@ -2,13 +2,13 @@
|
||||
read_when:
|
||||
- Chcesz używać Qwen z OpenClaw
|
||||
- Wcześniej używałeś OAuth Qwen
|
||||
summary: Używaj Qwen Cloud przez wbudowanego providera qwen w OpenClaw
|
||||
summary: Używaj Qwen Cloud przez dołączonego dostawcę qwen w OpenClaw
|
||||
title: Qwen
|
||||
x-i18n:
|
||||
generated_at: "2026-04-06T03:12:03Z"
|
||||
generated_at: "2026-04-09T01:30:16Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: f175793693ab6a4c3f1f4d42040e673c15faf7603a500757423e9e06977c989d
|
||||
source_hash: 4786df2cb6ec1ab29d191d012c61dcb0e5468bf0f8561fbbb50eed741efad325
|
||||
source_path: providers/qwen.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -17,25 +17,25 @@ x-i18n:
|
||||
|
||||
<Warning>
|
||||
|
||||
**OAuth Qwen został usunięty.** Integracja OAuth w warstwie darmowej
|
||||
**OAuth Qwen został usunięty.** Integracja OAuth w bezpłatnym planie
|
||||
(`qwen-portal`), która używała endpointów `portal.qwen.ai`, nie jest już dostępna.
|
||||
Szczegóły znajdziesz w [Issue #49557](https://github.com/openclaw/openclaw/issues/49557).
|
||||
Kontekst znajdziesz w [Issue #49557](https://github.com/openclaw/openclaw/issues/49557).
|
||||
|
||||
</Warning>
|
||||
|
||||
## Zalecane: Qwen Cloud
|
||||
|
||||
OpenClaw traktuje teraz Qwen jako pełnoprawnego wbudowanego providera z kanonicznym identyfikatorem
|
||||
`qwen`. Wbudowany provider kieruje ruch do endpointów Qwen Cloud / Alibaba DashScope oraz
|
||||
Coding Plan i zachowuje starsze identyfikatory `modelstudio` jako alias
|
||||
zgodności.
|
||||
OpenClaw traktuje teraz Qwen jako pełnoprawnego dołączonego dostawcę z kanonicznym identyfikatorem
|
||||
`qwen`. Dołączony dostawca obsługuje endpointy Qwen Cloud / Alibaba DashScope oraz
|
||||
Coding Plan i zachowuje działanie starszych identyfikatorów `modelstudio` jako
|
||||
aliasu zgodności.
|
||||
|
||||
- Provider: `qwen`
|
||||
- Preferowana zmienna środowiskowa: `QWEN_API_KEY`
|
||||
- Akceptowane również dla zgodności: `MODELSTUDIO_API_KEY`, `DASHSCOPE_API_KEY`
|
||||
- Dostawca: `qwen`
|
||||
- Preferowana zmienna env: `QWEN_API_KEY`
|
||||
- Akceptowane także dla zgodności: `MODELSTUDIO_API_KEY`, `DASHSCOPE_API_KEY`
|
||||
- Styl API: zgodny z OpenAI
|
||||
|
||||
Jeśli chcesz używać `qwen3.6-plus`, preferuj endpoint **Standard (pay-as-you-go)**.
|
||||
Jeśli chcesz używać `qwen3.6-plus`, wybierz endpoint **Standard (pay-as-you-go)**.
|
||||
Obsługa Coding Plan może być opóźniona względem publicznego katalogu.
|
||||
|
||||
```bash
|
||||
@ -52,9 +52,9 @@ openclaw onboard --auth-choice qwen-standard-api-key
|
||||
openclaw onboard --auth-choice qwen-standard-api-key-cn
|
||||
```
|
||||
|
||||
Starsze identyfikatory `modelstudio-*` dla `auth-choice` oraz odwołania do modeli `modelstudio/...` nadal
|
||||
działają jako aliasy zgodności, ale nowe przepływy konfiguracji powinny preferować kanoniczne
|
||||
identyfikatory `qwen-*` dla `auth-choice` oraz odwołania do modeli `qwen/...`.
|
||||
Starsze identyfikatory `auth-choice` `modelstudio-*` oraz referencje modeli `modelstudio/...`
|
||||
nadal działają jako aliasy zgodności, ale nowe przepływy konfiguracji powinny preferować kanoniczne
|
||||
identyfikatory `auth-choice` z rodziny `qwen-*` oraz referencje modeli `qwen/...`.
|
||||
|
||||
Po onboardingu ustaw model domyślny:
|
||||
|
||||
@ -70,22 +70,22 @@ Po onboardingu ustaw model domyślny:
|
||||
|
||||
## Typy planów i endpointy
|
||||
|
||||
| Plan | Region | Auth choice | Endpoint |
|
||||
| Plan | Region | Wybór auth | Endpoint |
|
||||
| -------------------------- | ------ | -------------------------- | ------------------------------------------------ |
|
||||
| Standard (pay-as-you-go) | Chiny | `qwen-standard-api-key-cn` | `dashscope.aliyuncs.com/compatible-mode/v1` |
|
||||
| Standard (pay-as-you-go) | China | `qwen-standard-api-key-cn` | `dashscope.aliyuncs.com/compatible-mode/v1` |
|
||||
| Standard (pay-as-you-go) | Global | `qwen-standard-api-key` | `dashscope-intl.aliyuncs.com/compatible-mode/v1` |
|
||||
| Coding Plan (subskrypcja) | Chiny | `qwen-api-key-cn` | `coding.dashscope.aliyuncs.com/v1` |
|
||||
| Coding Plan (subskrypcja) | Global | `qwen-api-key` | `coding-intl.dashscope.aliyuncs.com/v1` |
|
||||
| Coding Plan (subscription) | China | `qwen-api-key-cn` | `coding.dashscope.aliyuncs.com/v1` |
|
||||
| Coding Plan (subscription) | Global | `qwen-api-key` | `coding-intl.dashscope.aliyuncs.com/v1` |
|
||||
|
||||
Provider automatycznie wybiera endpoint na podstawie Twojego wyboru auth. Kanoniczne
|
||||
wybory używają rodziny `qwen-*`; `modelstudio-*` pozostaje wyłącznie warstwą zgodności.
|
||||
Dostawca automatycznie wybiera endpoint na podstawie wybranego auth. Kanoniczne
|
||||
opcje używają rodziny `qwen-*`; `modelstudio-*` pozostaje wyłącznie dla zgodności.
|
||||
Możesz nadpisać to własnym `baseUrl` w konfiguracji.
|
||||
|
||||
Natywne endpointy Model Studio sygnalizują zgodność użycia streamingu na
|
||||
współdzielonym transporcie `openai-completions`. OpenClaw opiera to teraz na możliwościach endpointu, więc
|
||||
niestandardowe identyfikatory providerów zgodne z DashScope, kierujące ruch na te same
|
||||
natywne hosty, dziedziczą to samo zachowanie użycia streamingu zamiast
|
||||
wymagać konkretnie wbudowanego identyfikatora providera `qwen`.
|
||||
Natywne endpointy Model Studio deklarują zgodność użycia strumieniowego na
|
||||
współdzielonym transporcie `openai-completions`. OpenClaw opiera to teraz na możliwościach endpointu,
|
||||
więc niestandardowe identyfikatory dostawców zgodnych z DashScope, kierujące na te same
|
||||
natywne hosty, dziedziczą to samo zachowanie użycia strumieniowego zamiast
|
||||
wymagać konkretnie wbudowanego identyfikatora dostawcy `qwen`.
|
||||
|
||||
## Pobierz swój klucz API
|
||||
|
||||
@ -94,24 +94,26 @@ wymagać konkretnie wbudowanego identyfikatora providera `qwen`.
|
||||
|
||||
## Wbudowany katalog
|
||||
|
||||
OpenClaw obecnie dostarcza ten wbudowany katalog Qwen:
|
||||
OpenClaw obecnie dostarcza ten dołączony katalog Qwen. Skonfigurowany katalog jest
|
||||
świadomy endpointu: konfiguracje Coding Plan pomijają modele, o których wiadomo, że działają
|
||||
tylko na endpointach Standard.
|
||||
|
||||
| Model ref | Input | Context | Notes |
|
||||
| --------------------------- | ----------- | --------- | -------------------------------------------------- |
|
||||
| `qwen/qwen3.5-plus` | text, image | 1,000,000 | Model domyślny |
|
||||
| `qwen/qwen3.6-plus` | text, image | 1,000,000 | Preferuj endpointy Standard, jeśli potrzebujesz tego modelu |
|
||||
| `qwen/qwen3-max-2026-01-23` | text | 262,144 | Linia Qwen Max |
|
||||
| `qwen/qwen3-coder-next` | text | 262,144 | Coding |
|
||||
| `qwen/qwen3-coder-plus` | text | 1,000,000 | Coding |
|
||||
| `qwen/MiniMax-M2.5` | text | 1,000,000 | Reasoning włączony |
|
||||
| `qwen/glm-5` | text | 202,752 | GLM |
|
||||
| `qwen/glm-4.7` | text | 202,752 | GLM |
|
||||
| `qwen/kimi-k2.5` | text, image | 262,144 | Moonshot AI przez Alibaba |
|
||||
| Referencja modelu | Wejście | Kontekst | Uwagi |
|
||||
| -------------------------- | ----------- | --------- | -------------------------------------------------- |
|
||||
| `qwen/qwen3.5-plus` | text, image | 1,000,000 | Model domyślny |
|
||||
| `qwen/qwen3.6-plus` | text, image | 1,000,000 | Przy tym modelu preferuj endpointy Standard |
|
||||
| `qwen/qwen3-max-2026-01-23`| text | 262,144 | Linia Qwen Max |
|
||||
| `qwen/qwen3-coder-next` | text | 262,144 | Coding |
|
||||
| `qwen/qwen3-coder-plus` | text | 1,000,000 | Coding |
|
||||
| `qwen/MiniMax-M2.5` | text | 1,000,000 | Reasoning włączony |
|
||||
| `qwen/glm-5` | text | 202,752 | GLM |
|
||||
| `qwen/glm-4.7` | text | 202,752 | GLM |
|
||||
| `qwen/kimi-k2.5` | text, image | 262,144 | Moonshot AI przez Alibaba |
|
||||
|
||||
Dostępność może nadal różnić się w zależności od endpointu i planu rozliczeń, nawet jeśli model
|
||||
jest obecny we wbudowanym katalogu.
|
||||
Dostępność może nadal zależeć od endpointu i planu rozliczeniowego, nawet jeśli model
|
||||
jest obecny w dołączonym katalogu.
|
||||
|
||||
Zgodność użycia native-streaming dotyczy zarówno hostów Coding Plan, jak i
|
||||
Zgodność użycia natywnego strumieniowania dotyczy zarówno hostów Coding Plan, jak i
|
||||
hostów Standard zgodnych z DashScope:
|
||||
|
||||
- `https://coding.dashscope.aliyuncs.com/v1`
|
||||
@ -123,31 +125,31 @@ hostów Standard zgodnych z DashScope:
|
||||
|
||||
`qwen3.6-plus` jest dostępny na endpointach Model Studio Standard (pay-as-you-go):
|
||||
|
||||
- Chiny: `dashscope.aliyuncs.com/compatible-mode/v1`
|
||||
- China: `dashscope.aliyuncs.com/compatible-mode/v1`
|
||||
- Global: `dashscope-intl.aliyuncs.com/compatible-mode/v1`
|
||||
|
||||
Jeśli endpointy Coding Plan zwracają błąd „unsupported model” dla
|
||||
`qwen3.6-plus`, przełącz się na Standard (pay-as-you-go) zamiast używać pary
|
||||
endpoint/klucz dla Coding Plan.
|
||||
endpoint/klucz Coding Plan.
|
||||
|
||||
## Plan możliwości
|
||||
|
||||
Rozszerzenie `qwen` jest pozycjonowane jako docelowe miejsce dostawcy dla całej powierzchni Qwen
|
||||
Rozszerzenie `qwen` jest pozycjonowane jako dom producenta dla pełnej powierzchni Qwen
|
||||
Cloud, a nie tylko modeli coding/text.
|
||||
|
||||
- Modele text/chat: już wbudowane
|
||||
- Tool calling, structured output, thinking: dziedziczone z transportu zgodnego z OpenAI
|
||||
- Image generation: planowane na warstwie pluginu providera
|
||||
- Image/video understanding: już wbudowane na endpointach Standard
|
||||
- Speech/audio: planowane na warstwie pluginu providera
|
||||
- Embeddingi/reranking pamięci: planowane przez powierzchnię adaptera embeddingów
|
||||
- Video generation: już wbudowane przez współdzieloną możliwość generowania wideo
|
||||
- Modele text/chat: dołączone już teraz
|
||||
- Wywoływanie narzędzi, output strukturalny, thinking: dziedziczone z transportu zgodnego z OpenAI
|
||||
- Generowanie obrazów: planowane na warstwie wtyczki dostawcy
|
||||
- Rozumienie obrazów/wideo: dołączone już teraz na endpointach Standard
|
||||
- Speech/audio: planowane na warstwie wtyczki dostawcy
|
||||
- Embeddingi pamięci/reranking: planowane przez powierzchnię adaptera embeddingów
|
||||
- Generowanie wideo: dołączone już teraz przez współdzieloną możliwość generowania wideo
|
||||
|
||||
## Dodatki multimodalne
|
||||
|
||||
Rozszerzenie `qwen` udostępnia teraz także:
|
||||
|
||||
- Video understanding przez `qwen-vl-max-latest`
|
||||
- Rozumienie wideo przez `qwen-vl-max-latest`
|
||||
- Generowanie wideo Wan przez:
|
||||
- `wan2.6-t2v` (domyślnie)
|
||||
- `wan2.6-i2v`
|
||||
@ -158,20 +160,20 @@ Rozszerzenie `qwen` udostępnia teraz także:
|
||||
Te powierzchnie multimodalne używają endpointów DashScope **Standard**, a nie
|
||||
endpointów Coding Plan.
|
||||
|
||||
- Globalny/międzynarodowy podstawowy URL Standard: `https://dashscope-intl.aliyuncs.com/compatible-mode/v1`
|
||||
- Chiński podstawowy URL Standard: `https://dashscope.aliyuncs.com/compatible-mode/v1`
|
||||
- Global/Intl Standard base URL: `https://dashscope-intl.aliyuncs.com/compatible-mode/v1`
|
||||
- China Standard base URL: `https://dashscope.aliyuncs.com/compatible-mode/v1`
|
||||
|
||||
Dla generowania wideo OpenClaw mapuje skonfigurowany region Qwen na odpowiadający mu
|
||||
host DashScope AIGC przed wysłaniem zadania:
|
||||
Dla generowania wideo OpenClaw mapuje skonfigurowany region Qwen na odpowiadający
|
||||
mu host DashScope AIGC przed wysłaniem zadania:
|
||||
|
||||
- Global/Intl: `https://dashscope-intl.aliyuncs.com`
|
||||
- Chiny: `https://dashscope.aliyuncs.com`
|
||||
- China: `https://dashscope.aliyuncs.com`
|
||||
|
||||
Oznacza to, że zwykłe `models.providers.qwen.baseUrl` wskazujące na hosty Qwen
|
||||
Coding Plan lub Standard nadal utrzymuje generowanie wideo na poprawnym
|
||||
regionalnym endpointzie wideo DashScope.
|
||||
regionalnym endpointcie wideo DashScope.
|
||||
|
||||
Dla generowania wideo ustaw model domyślny jawnie:
|
||||
Dla generowania wideo ustaw jawnie model domyślny:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -183,22 +185,22 @@ Dla generowania wideo ustaw model domyślny jawnie:
|
||||
}
|
||||
```
|
||||
|
||||
Bieżące ograniczenia wbudowanego generowania wideo Qwen:
|
||||
Obecne limity generowania wideo dla dołączonego Qwen:
|
||||
|
||||
- Maksymalnie **1** wyjściowe wideo na żądanie
|
||||
- Maksymalnie **1** obraz wejściowy
|
||||
- Maksymalnie **4** wejściowe wideo
|
||||
- Maksymalnie **10 sekund** czasu trwania
|
||||
- Maksymalny czas trwania **10 sekund**
|
||||
- Obsługuje `size`, `aspectRatio`, `resolution`, `audio` i `watermark`
|
||||
- Tryb obrazu/wideo referencyjnego obecnie wymaga **zdalnych URL `http(s)`**. Lokalne
|
||||
- Tryb obrazu/wideo referencyjnego obecnie wymaga **zdalnych adresów URL http(s)**. Lokalne
|
||||
ścieżki plików są odrzucane od razu, ponieważ endpoint wideo DashScope nie
|
||||
akceptuje przesyłanych lokalnych buforów dla tych referencji.
|
||||
akceptuje przesyłanych lokalnych buforów dla takich referencji.
|
||||
|
||||
Zobacz [Generowanie wideo](/tools/video-generation), aby poznać współdzielone
|
||||
parametry narzędzia, wybór providera i zachowanie failover.
|
||||
Zobacz [Video Generation](/pl/tools/video-generation), aby poznać współdzielone parametry
|
||||
narzędzia, wybór dostawcy i zachowanie failover.
|
||||
|
||||
## Uwaga dotycząca środowiska
|
||||
|
||||
Jeśli Gateway działa jako daemon (launchd/systemd), upewnij się, że `QWEN_API_KEY` jest
|
||||
dostępny dla tego procesu (na przykład w `~/.openclaw/.env` lub przez
|
||||
Jeśli Gateway działa jako demon (launchd/systemd), upewnij się, że `QWEN_API_KEY` jest
|
||||
dostępne dla tego procesu (na przykład w `~/.openclaw/.env` lub przez
|
||||
`env.shellEnv`).
|
||||
|
||||
Loading…
Reference in New Issue
Block a user