Skip to main content
Zbuduj Plugin dostawcy, aby dodać dostawcę modeli (LLM) do OpenClaw: katalog modeli, uwierzytelnianie kluczem API i dynamiczne rozpoznawanie modeli.
Nie znasz jeszcze pluginów OpenClaw? Najpierw przeczytaj Pierwsze kroki, aby poznać strukturę pakietu i konfigurację manifestu.
Pluginy dostawców dodają modele do standardowej pętli wnioskowania OpenClaw. Jeśli model musi działać za pośrednictwem natywnego demona agenta, który zarządza wątkami, Compaction lub zdarzeniami narzędzi, połącz dostawcę z uprzężą agenta, zamiast umieszczać szczegóły protokołu demona w rdzeniu.

Instrukcja

1

Pakiet i manifest

Krok 1: Pakiet i manifest

setup.providers[].envVars umożliwia OpenClaw wykrywanie danych uwierzytelniających bez ładowania środowiska uruchomieniowego pluginu. Dodaj providerAuthAliases, gdy wariant dostawcy powinien ponownie używać uwierzytelniania identyfikatora innego dostawcy. modelSupport jest opcjonalne i umożliwia OpenClaw automatyczne ładowanie pluginu dostawcy na podstawie skróconych identyfikatorów modeli, takich jak acme-large, zanim będą dostępne haki środowiska uruchomieniowego. Pola openclaw.compat i openclaw.build w pliku package.json są wymagane do publikowania w ClawHub (openclaw.compat.pluginApi i openclaw.build.openclawVersion to dwa wymagane pola; w przypadku pominięcia minGatewayVersion używana jest wartość openclaw.install.minHostVersion).
2

Zarejestruj dostawcę

Minimalny dostawca tekstowy wymaga pól id, label, auth i catalog. catalog jest należącym do dostawcy hakiem środowiska uruchomieniowego/konfiguracji; może wywoływać działające interfejsy API dostawcy i zwraca wpisy models.providers.
index.ts
registerModelCatalogProvider to nowszy interfejs katalogu płaszczyzny sterowania dla list, pomocy i interfejsu wyboru, obejmujący wiersze text, voice, image_generation, video_generation i music_generation. Wywołania punktów końcowych dostawcy i mapowanie odpowiedzi pozostaw w pluginie; OpenClaw odpowiada za wspólny kształt wierszy, etykiety źródeł i renderowanie pomocy.To jest działający dostawca. Użytkownicy mogą teraz uruchomić openclaw onboard --acme-ai-api-key <key> i wybrać acme-ai/acme-large jako swój model.

Wykrywanie modeli na żywo

Jeśli dostawca udostępnia interfejs API w stylu /models, zachowaj specyficzny dla dostawcy punkt końcowy i projekcję wierszy w pluginie, a do wspólnego cyklu pobierania użyj openclaw/plugin-sdk/provider-catalog-live-runtime. Ten pomocnik zapewnia chronione żądania HTTP, nagłówki uwierzytelniania dostawcy, ustrukturyzowane błędy HTTP, buforowanie TTL i statyczne zachowanie awaryjne bez umieszczania polityki dostawcy w rdzeniu OpenClaw.Użyj buildLiveModelProviderConfig, gdy aktywny interfejs API informuje tylko, które należące do dostawcy wiersze katalogu statycznego są obecnie dostępne:
index.ts
Użyj getCachedLiveProviderModelRows, gdy interfejs API dostawcy zwraca bogatsze metadane, a plugin musi samodzielnie przekształcać wiersze w definicje modeli OpenClaw:
index.ts
run powinien pozostać chroniony uwierzytelnianiem i zwracać null, gdy żadne użyteczne dane uwierzytelniające nie są dostępne. Zachowaj działający offline staticRun lub statyczny mechanizm awaryjny, aby konfiguracja, dokumentacja, testy i interfejsy wyboru nie zależały od dostępu do sieci na żywo. Użyj TTL odpowiedniego dla aktualności listy modeli, unikaj odpytywania systemu plików podczas obsługi żądań i przekazuj specyficzne dla dostawcy readRows / readModelId tylko wtedy, gdy odpowiedź systemu nadrzędnego nie ma zgodnego z OpenAI kształtu { data: [{ id, object }] }.Jeśli dostawca nadrzędny używa innych tokenów sterujących niż OpenClaw, dodaj niewielką dwukierunkową transformację tekstu, zamiast zastępować ścieżkę strumienia:
input przekształca końcową treść monitu systemowego i wiadomości tekstowych przed transportem. output przekształca fragmenty tekstu asystenta i tekst końcowy, zanim OpenClaw przeanalizuje własne znaczniki sterujące lub przekaże treść do kanału.W przypadku dostawców dołączonych do pakietu, którzy rejestrują tylko jednego dostawcę tekstowego z uwierzytelnianiem kluczem API oraz pojedynczym środowiskiem uruchomieniowym opartym na katalogu, preferuj węższy pomocnik defineSingleProviderPluginEntry(...):
buildProvider to ścieżka katalogu działająca na żywo, używana, gdy OpenClaw może ustalić rzeczywiste dane uwierzytelniające dostawcy. Może wykonywać wykrywanie specyficzne dla dostawcy. Używaj buildStaticProvider wyłącznie dla pozycji offline, które można bezpiecznie wyświetlić przed skonfigurowaniem uwierzytelniania; nie może wymagać danych uwierzytelniających ani wykonywać żądań sieciowych. Wyświetlanie przez models list --all w OpenClaw wykonuje obecnie katalogi statyczne tylko dla dołączonych pluginów dostawców, z pustą konfiguracją, pustymi zmiennymi środowiskowymi i bez ścieżek agenta ani obszaru roboczego.Jeśli przepływ uwierzytelniania musi również modyfikować models.providers.*, aliasy i domyślny model agenta podczas wdrażania, użyj pomocników ustawień wstępnych z openclaw/plugin-sdk/provider-onboard. Najbardziej wyspecjalizowane pomocniki to createDefaultModelPresetAppliers(...), createDefaultModelsPresetAppliers(...) oraz createModelCatalogPresetAppliers(...).Gdy natywny punkt końcowy dostawcy obsługuje strumieniowe bloki użycia w standardowym transporcie openai-completions, preferuj współdzielone pomocniki katalogu z openclaw/plugin-sdk/provider-catalog-shared zamiast kodowania na stałe kontroli identyfikatora dostawcy. supportsNativeStreamingUsageCompat(...) oraz applyProviderNativeStreamingUsageCompat(...) wykrywają obsługę na podstawie mapy możliwości punktu końcowego, dzięki czemu natywne punkty końcowe w stylu Moonshot/DashScope nadal mogą włączyć tę funkcję, nawet gdy plugin używa niestandardowego identyfikatora dostawcy.Powyższe przykłady wykrywania na żywo obejmują interfejsy API dostawców w stylu /models. Zachowaj to wykrywanie wewnątrz catalog.run, uzależniając je od dostępnego uwierzytelniania, a staticRun pozostaw bez dostępu do sieci na potrzeby generowania katalogu offline.
3

Add dynamic model resolution

Jeśli dostawca akceptuje dowolne identyfikatory modeli (jak serwer proxy lub router), dodaj resolveDynamicModel:
Jeśli ustalenie modelu wymaga wywołania sieciowego, użyj prepareDynamicModel do asynchronicznego przygotowania — po jego zakończeniu resolveDynamicModel zostanie uruchomione ponownie.
4

Add runtime hooks (as needed)

Większość dostawców potrzebuje tylko catalog i resolveDynamicModel. Dodawaj hooki stopniowo, zgodnie z wymaganiami dostawcy.Współdzielone konstruktory pomocnicze obsługują teraz najczęstsze rodziny zgodności odtwarzania i narzędzi, dlatego pluginy zwykle nie muszą ręcznie podłączać każdego hooka osobno:
Obecnie dostępne rodziny odtwarzania:Obecnie dostępne rodziny strumieni:
Każdy konstruktor rodziny składa się z publicznych pomocników niższego poziomu eksportowanych z tego samego pakietu, których można użyć, gdy dostawca musi wyjść poza typowy schemat:
  • openclaw/plugin-sdk/provider-model-sharedProviderReplayFamily, buildProviderReplayFamilyHooks(...) oraz podstawowe konstruktory odtwarzania (buildOpenAICompatibleReplayPolicy, buildAnthropicReplayPolicyForModel, buildGoogleGeminiReplayPolicy, buildHybridAnthropicOrOpenAIReplayPolicy). Eksportuje również pomocniki odtwarzania Gemini (sanitizeGoogleGeminiReplayHistory, resolveTaggedReasoningOutputMode) oraz pomocniki punktów końcowych i modeli (resolveProviderEndpoint, normalizeProviderId, normalizeGooglePreviewModelId).
  • openclaw/plugin-sdk/provider-streamProviderStreamFamily, buildProviderStreamFamilyHooks(...), composeProviderStreamWrappers(...), a także współdzielone opakowania OpenAI/Codex (createOpenAIAttributionHeadersWrapper, createOpenAIFastModeWrapper, createOpenAIServiceTierWrapper, createOpenAIResponsesContextManagementWrapper, createCodexNativeWebSearchWrapper), opakowanie DeepSeek V4 zgodne z OpenAI (createDeepSeekV4OpenAICompatibleThinkingWrapper), czyszczenie wstępnie wypełnionego rozumowania Anthropic Messages (createAnthropicThinkingPrefillPayloadWrapper), zgodność wywołań narzędzi w postaci zwykłego tekstu (createPlainTextToolCallCompatWrapper) oraz współdzielone opakowania proxy i dostawców (createOpenRouterWrapper, createToolStreamWrapper, createMinimaxFastModeWrapper).
  • openclaw/plugin-sdk/provider-stream-shared — lekkie opakowania ładunków i zdarzeń dla intensywnie używanych ścieżek dostawców, w tym createOpenAICompatibleCompletionsThinkingOffWrapper, createPayloadPatchStreamWrapper, createPlainTextToolCallCompatWrapper, normalizeOpenAICompatibleReasoningPayload(...) oraz setQwenChatTemplateThinking(...).
  • openclaw/plugin-sdk/provider-toolsProviderToolCompatFamily, buildProviderToolCompatFamilyHooks("deepseek" | "gemini" | "openai") oraz bazowe pomocniki schematów dostawców.
W przypadku dostawców z rodziny Gemini zachowaj zgodność trybu wyjścia rozumowania z transportem. Bezpośredni dostawcy Google Gemini API powinni używać wyjścia rozumowania native, aby OpenClaw przetwarzał natywne części myśli bez dodawania dyrektyw promptu <think> / <final>. Backendy tekstowe w stylu Gemini CLI, które analizują końcową odpowiedź JSON lub tekstową, mogą zachować współdzielony oznaczony kontrakt google-gemini.Niektóre pomocniki strumieni celowo pozostają lokalne dla dostawcy. @openclaw/anthropic-provider przechowuje wrapAnthropicProviderStream, resolveAnthropicBetas, resolveAnthropicFastMode, resolveAnthropicServiceTier oraz konstruktory opakowań Anthropic niższego poziomu we własnym publicznym interfejsie api.ts / contract-api.ts, ponieważ kodują obsługę funkcji beta OAuth Claude i ograniczenie context1m. Plugin xAI podobnie zachowuje natywne kształtowanie Responses xAI we własnym wrapStreamFn (aliasy /fast, domyślne tool_stream, czyszczenie nieobsługiwanych ścisłych narzędzi oraz usuwanie ładunku rozumowania specyficzne dla xAI).Ten sam wzorzec katalogu głównego pakietu obsługuje również @openclaw/openai-provider (konstruktory dostawców, pomocniki modeli domyślnych i konstruktory dostawców czasu rzeczywistego) oraz @openclaw/openrouter-provider (konstruktor dostawcy wraz z pomocnikami wdrażania i konfiguracji).
Dla dostawców wymagających wymiany tokenu przed każdym wywołaniem inferencji:
OpenClaw wywołuje hooki pluginów modeli i dostawców mniej więcej w tej kolejności. Większość dostawców używa tylko 2–3 z nich. Nie jest to pełny kontrakt ProviderPlugin — pełną, aktualną listę hooków i uwagi dotyczące mechanizmów rezerwowych zawiera sekcja Szczegóły wewnętrzne: hooki środowiska wykonawczego dostawcy. Pola dostawcy służące wyłącznie do zgodności, których OpenClaw już nie wywołuje, takie jak ProviderPlugin.capabilities i suppressBuiltInModel, nie są tutaj wymienione.Uwagi dotyczące mechanizmów rezerwowych środowiska wykonawczego:
  • normalizeConfig rozpoznaje jeden plugin będący właścicielem danego identyfikatora dostawcy (najpierw dostawcy wbudowani, następnie dopasowany plugin środowiska wykonawczego) i wywołuje wyłącznie ten hook — nie skanuje innych dostawców. Własny hook normalizeConfig firmy Google normalizuje wpisy konfiguracji google / google-vertex / google-antigravity; nie jest to osobny mechanizm rezerwowy rdzenia.
  • resolveConfigApiKey używa hooka dostawcy, gdy jest on udostępniony. Amazon Bedrock zachowuje rozpoznawanie znaczników środowiskowych AWS w swoim pluginie dostawcy; samo uwierzytelnianie środowiska wykonawczego nadal używa domyślnego łańcucha AWS SDK, gdy skonfigurowano auth: "aws-sdk".
  • resolveThinkingProfile(ctx) otrzymuje wybranego dostawcę provider, identyfikator modelId, opcjonalną scaloną wskazówkę katalogu reasoning oraz opcjonalne scalone informacje compat modelu. Używaj compat wyłącznie do wyboru interfejsu lub profilu myślenia dostawcy.
  • resolveSystemPromptContribution umożliwia dostawcy wstrzyknięcie wskazówek promptu systemowego uwzględniających pamięć podręczną dla rodziny modeli. Preferuj go zamiast starszego hooka before_prompt_build obejmującego cały plugin, gdy zachowanie należy do jednej rodziny dostawcy lub modeli i powinno zachować stabilny oraz dynamiczny podział pamięci podręcznej.
5

Dodaj dodatkowe możliwości (opcjonalnie)

Krok 5: Dodaj dodatkowe możliwości

Plugin dostawcy może rejestrować osadzanie, syntezę mowy, transkrypcję w czasie rzeczywistym, głos w czasie rzeczywistym, rozumienie multimediów, generowanie obrazów, generowanie filmów, pobieranie z sieci i wyszukiwanie w sieci obok wnioskowania tekstowego. OpenClaw klasyfikuje go jako plugin możliwości hybrydowych — jest to zalecany wzorzec dla pluginów firmowych (jeden plugin na dostawcę). Zobacz Szczegóły wewnętrzne: własność możliwości.Zarejestruj każdą możliwość wewnątrz register(api) obok istniejącego wywołania api.registerProvider(...). Wybierz tylko potrzebne karty:
W przypadku błędów HTTP dostawcy używaj assertOkOrThrowProviderError(...), aby pluginy współdzieliły odczyty treści błędów z ograniczeniem rozmiaru, analizowanie błędów JSON oraz sufiksy identyfikatorów żądań.
6

Testowanie

Krok 6: Testowanie

src/provider.test.ts

Publikowanie w ClawHub

Pluginy dostawców publikuje się tak samo jak każdy inny zewnętrzny Plugin kodu:
clawhub skill publish <path> to inne polecenie, przeznaczone do publikowania folderu skill, a nie pakietu Pluginu — nie używaj go tutaj.

Struktura plików

Informacje o kolejności katalogu

catalog.order określa, kiedy katalog zostanie scalony względem wbudowanych dostawców:

Następne kroki

Powiązane