clawhub:, gdy chcesz rozwiązywania przez
ClawHub.
Wymagania
- Użyj Node 22.19+, Node 23.11+ albo Node 24+ oraz menedżera pakietów, takiego jak
npmlubpnpm. - Znajomość modułów TypeScript ESM.
- Przy pracy nad wbudowanym pluginem w repozytorium sklonuj repozytorium i uruchom
pnpm install. Tworzenie pluginów w checkoutcie źródłowym obsługuje wyłącznie pnpm, ponieważ OpenClaw ładuje wbudowane pluginy z pakietów workspaceextensions/*.
Wybierz kształt pluginu
Plugin kanału
Połącz OpenClaw z platformą wiadomości.
Plugin dostawcy
Dodaj dostawcę modelu, mediów, wyszukiwania, pobierania, mowy albo czasu rzeczywistego.
Plugin backendu CLI
Uruchamiaj lokalne AI CLI przez fallback modelu OpenClaw.
Plugin narzędziowy
Zarejestruj narzędzia agenta.
Szybki start
Zbuduj minimalny plugin narzędziowy, rejestrując jedno wymagane narzędzie agenta. To najkrótszy użyteczny kształt pluginu i pokazuje pakiet, manifest, punkt wejścia oraz lokalny dowód.Utwórz metadane pakietu
contracts.tools, aby OpenClaw mógł wykryć własność bez
zachłannego ładowania każdego runtime pluginu. Ustaw activation.onStartup
celowo. Ten przykład uruchamia się przy starcie Gateway.Powierzchnie pluginów zaufane przez hosta są także bramkowane manifestem i wymagają jawnego
włączenia dla zainstalowanych pluginów. Jeśli zainstalowany plugin rejestruje
api.registerAgentToolResultMiddleware(...), zadeklaruj każdy docelowy runtime w
contracts.agentToolResultMiddleware. Jeśli rejestruje
api.registerTrustedToolPolicy(...), zadeklaruj każdy identyfikator polityki w
contracts.trustedToolPolicies. Te deklaracje utrzymują zgodność kontroli podczas instalacji
z rejestracją runtime.Każde pole manifestu opisuje manifest Pluginu.Zarejestruj narzędzie
index.ts
definePluginEntry dla pluginów niebędących kanałami. Pluginy kanałów używają
defineChannelPluginEntry.Przetestuj runtime
Dla zainstalowanego lub zewnętrznego pluginu sprawdź załadowany runtime:Jeśli plugin rejestruje polecenie CLI, uruchom również to polecenie. Na przykład
polecenie demonstracyjne powinno mieć dowód wykonania, taki jak
openclaw demo-plugin ping.Dla wbudowanego pluginu w tym repozytorium OpenClaw wykrywa pakiety pluginów
w checkoutcie źródłowym z workspace extensions/*. Uruchom najbliższy test docelowy:Przetestuj instalację pakietu
Przed opublikowaniem pluginu gotowego jako pakiet przetestuj ten sam kształt instalacji, który
otrzymają użytkownicy. Najpierw dodaj krok budowania, wskaż wpisy runtime, takie jak
openclaw.extensions, na zbudowany JavaScript, np. ./dist/index.js, i upewnij się,
że npm pack obejmuje wynik dist/. Wpisy źródłowe TypeScript są
tylko dla checkoutów źródłowych i lokalnych ścieżek programistycznych.Następnie spakuj plugin i zainstaluj tarball za pomocą npm-pack::npm-pack: używa zarządzanego przez OpenClaw projektu npm przypisanego do pluginu, więc wychwytuje
błędy zależności runtime, które testowanie checkoutu źródłowego może ukryć. Dowodzi
kształtu pakietu i zależności, a nie oficjalnego zaufania powiązanego z katalogiem.
Importy runtime muszą znajdować się w dependencies albo optionalDependencies;
zależności pozostawione tylko w devDependencies nie zostaną zainstalowane dla
zarządzanego projektu runtime.Nie używaj surowej instalacji archiwum/ścieżki jako końcowego dowodu dla oficjalnego lub
uprzywilejowanego zachowania pluginu. Surowe źródła są przydatne do lokalnego debugowania, ale
nie dowodzą tej samej ścieżki zależności co instalacje npm albo ClawHub. Jeśli
Twój plugin polega na statusie zaufanego oficjalnego pluginu, dodaj drugi dowód
przez oficjalną instalację opartą na katalogu albo opublikowaną ścieżkę pakietu, która
zapisuje oficjalne zaufanie. Zobacz
rozwiązywanie zależności pluginów, aby poznać
szczegóły katalogu głównego instalacji i własności zależności.Opublikuj
Zweryfikuj pakiet przed opublikowaniem:Kanoniczne fragmenty ClawHub znajdują się w
docs/snippets/plugin-publish/.Rejestrowanie narzędzi
Narzędzia mogą być wymagane albo opcjonalne. Wymagane narzędzia są zawsze dostępne, gdy plugin jest włączony. Opcjonalne narzędzia wymagają zgody użytkownika.api.registerTool(...) musi być również zadeklarowane w
manifeście pluginu:
tools.allow:
parameters, są pomijane i
zgłaszane w ten sam sposób. Zarejestrowane narzędzia to typowane funkcje, które model może wywołać
po przejściu kontroli polityki i allowlisty.
Fabryki narzędzi otrzymują obiekt kontekstu dostarczony przez runtime. Użyj ctx.activeModel,
gdy narzędzie musi logować, wyświetlać albo dostosowywać się do aktywnego modelu dla bieżącej
tury. Obiekt może zawierać provider, modelId i modelRef. Traktuj go jako
informacyjne metadane runtime, a nie jako granicę bezpieczeństwa wobec lokalnego
operatora, kodu zainstalowanego pluginu albo zmodyfikowanego runtime OpenClaw. Wrażliwe narzędzia lokalne
nadal powinny wymagać jawnej zgody pluginu albo operatora i domyślnie odmawiać działania,
gdy metadane aktywnego modelu są brakujące albo nieodpowiednie.
Manifest deklaruje własność i wykrywanie; wykonanie nadal wywołuje działającą
zarejestrowaną implementację narzędzia. Utrzymuj toolMetadata.<tool>.optional: true
w zgodzie z api.registerTool(..., { optional: true }), aby OpenClaw mógł uniknąć
ładowania runtime tego pluginu, dopóki narzędzie nie zostanie jawnie dodane do allowlisty.
Konwencje importu
Importuj z ukierunkowanych podścieżek SDK:api.ts i
runtime-api.ts, do importów wewnętrznych. Nie importuj własnego pluginu przez
ścieżkę SDK. Helpery specyficzne dla dostawcy powinny pozostać w pakiecie dostawcy, chyba że
granica jest naprawdę generyczna.
Niestandardowe metody RPC Gateway to zaawansowany punkt wejścia. Utrzymuj je pod
prefiksem specyficznym dla pluginu; przestrzenie nazw administracji rdzenia, takie jak config.*,
exec.approvals.*, operator.admin.*, wizard.* i update.*, pozostają zarezerwowane
i rozwiązują się do operator.admin. Most
openclaw/plugin-sdk/gateway-method-runtime jest zarezerwowany dla tras HTTP pluginu,
które deklarują contracts.gatewayMethodDispatch: ["authenticated-request"].
Pełną mapę importów znajdziesz w omówieniu SDK pluginów.
Lista kontrolna przed przesłaniem
package.json ma poprawne metadane
openclawManifest openclaw.plugin.json jest obecny i poprawny
Punkt wejścia używa
defineChannelPluginEntry albo definePluginEntryWszystkie importy używają ukierunkowanych ścieżek
plugin-sdk/<subpath>Importy wewnętrzne używają modułów lokalnych, a nie samoimportów SDK
Testy przechodzą (
pnpm test -- <bundled-plugin-root>/my-plugin/)pnpm check przechodzi (pluginy w repozytorium)Testowanie względem wydań beta
- Obserwuj tagi wydań GitHub w openclaw/openclaw i zasubskrybuj je przez
Watch>Releases. Tagi beta wyglądają jakv2026.3.N-beta.1. Możesz też włączyć powiadomienia dla oficjalnego konta OpenClaw na X @openclaw, aby otrzymywać ogłoszenia o wydaniach. - Przetestuj swój plugin względem taga beta, gdy tylko się pojawi. Okno przed wydaniem stabilnym zwykle trwa tylko kilka godzin.
- Po testach napisz w wątku swojego pluginu na kanale Discord
plugin-forum:all goodalbo opisz, co się zepsuło. Jeśli nie masz jeszcze wątku, utwórz go. - Jeśli coś się zepsuje, otwórz lub zaktualizuj zgłoszenie zatytułowane
Beta blocker: <plugin-name> - <summary>i zastosuj etykietębeta-blocker. Umieść link do zgłoszenia w swoim wątku. - Otwórz PR do
mainzatytułowanyfix(<plugin-id>): beta blocker - <summary>i podlinkuj zgłoszenie zarówno w PR, jak i w swoim wątku na Discord. Współautorzy nie mogą nadawać PR etykiet, więc tytuł jest sygnałem po stronie PR dla maintainerów i automatyzacji. Blokery z PR są scalane; blokery bez PR mogą mimo to trafić do wydania. Maintainerzy obserwują te wątki podczas testów beta. - Cisza oznacza zielone światło. Jeśli przegapisz okno, poprawka prawdopodobnie trafi do następnego cyklu.
Następne kroki
Pluginy kanałów
Zbuduj plugin kanału wiadomości
Pluginy dostawców
Zbuduj plugin dostawcy modeli
Pluginy backendu CLI
Zarejestruj lokalny backend CLI AI
Omówienie SDK
Mapa importów i dokumentacja API rejestracji
Pomocniki środowiska uruchomieniowego
TTS, wyszukiwanie, subagent przez api.runtime
Testowanie
Narzędzia i wzorce testowe
Manifest pluginu
Pełna dokumentacja schematu manifestu