Wenn Sie noch kein OpenClaw-Plugin erstellt haben, lesen Sie zuerst
Erste Schritte für die grundlegende Paketstruktur
und die Manifest-Einrichtung.
Schritt-für-Schritt-Anleitung
Paket und Manifest
Schritt 1: Paket und Manifest
setup.providers[].envVars, damit OpenClaw
Anmeldedaten erkennen kann, ohne die Runtime Ihres Plugins zu laden. Fügen Sie providerAuthAliases
hinzu, wenn eine Provider-Variante die Authentifizierung einer anderen Provider-ID wiederverwenden soll. modelSupport
ist optional und ermöglicht OpenClaw, Ihr Provider-Plugin automatisch anhand von Kurzform-
Modell-IDs wie acme-large zu laden, bevor Runtime-Hooks existieren. Wenn Sie den
Provider auf ClawHub veröffentlichen, sind diese Felder openclaw.compat und openclaw.build
in package.json erforderlich.Provider registrieren
Ein minimaler Text-Provider benötigt Verwenden Sie
id, label, auth und catalog.
catalog ist der vom Provider besessene Runtime-/Config-Hook; er kann Live-
Vendor-APIs aufrufen und gibt models.providers-Einträge zurück.index.ts
registerModelCatalogProvider ist die neuere Control-Plane-Katalogoberfläche
für Listen-/Hilfe-/Picker-UI. Verwenden Sie sie für Text-, Bilderzeugungs-,
Videoerzeugungs- und Musikerzeugungszeilen. Belassen Sie Vendor-Endpunktaufrufe und
Response-Mapping im Plugin; OpenClaw besitzt die gemeinsame Zeilenform, Source-
Labels und Hilfe-Rendering.Das ist ein funktionsfähiger Provider. Benutzer können jetzt
openclaw onboard --acme-ai-api-key <key> ausführen und
acme-ai/acme-large als ihr Modell auswählen.Live-Modellerkennung
Wenn Ihr Provider eine API im Stil von/models bereitstellt, behalten Sie den Provider-spezifischen
Endpunkt und die Zeilenprojektion in Ihrem Plugin und verwenden Sie
openclaw/plugin-sdk/provider-catalog-live-runtime für den gemeinsamen Fetch-
Lebenszyklus. Der Helper bietet Ihnen abgesicherte HTTP-Fetches, Provider-Auth-Header,
strukturierte HTTP-Fehler, TTL-Caching und statisches Fallback-Verhalten, ohne
Provider-Policy in den OpenClaw-Core zu legen.Verwenden Sie buildLiveModelProviderConfig, wenn die Live-API Ihnen nur mitteilt, welche
vom Provider besessenen statischen Katalogzeilen derzeit verfügbar sind:index.ts
getCachedLiveProviderModelRows, wenn die Provider-API umfangreichere
Metadaten zurückgibt und das Plugin selbst Zeilen in OpenClaw-Modell-
Definitionen projizieren muss:index.ts
run sollte auth-gated bleiben und null zurückgeben, wenn keine nutzbaren Anmeldedaten
verfügbar sind. Behalten Sie ein Offline-staticRun oder einen statischen Fallback bei, damit Setup, Docs,
Tests und Picker-Oberflächen nicht von Live-Netzwerkzugriff abhängen. Verwenden Sie eine TTL,
die zur Aktualität der Modellliste passt, vermeiden Sie Filesystem-Polling zur Request-Zeit
und übergeben Sie provider-spezifisches readRows / readModelId nur dann, wenn die
Upstream-Antwort nicht der OpenAI-kompatiblen Form { data: [{ id, object }] }
entspricht.Wenn der Upstream-Provider andere Steuertokens als OpenClaw verwendet, fügen Sie eine
kleine bidirektionale Texttransformation hinzu, statt den Stream-Pfad zu ersetzen:input schreibt den finalen System-Prompt und den Inhalt von Textnachrichten vor
dem Transport um. output schreibt Assistant-Text-Deltas und finalen Text um, bevor
OpenClaw seine eigenen Steuermarker parst oder die Channel-Zustellung erfolgt.Für gebündelte Provider, die nur einen Text-Provider mit API-Schlüssel-
Auth plus einer einzelnen kataloggestützten Runtime registrieren, bevorzugen Sie den enger gefassten
Helper defineSingleProviderPluginEntry(...):buildProvider ist der Live-Katalogpfad, der verwendet wird, wenn OpenClaw echte
Provider-Authentifizierung auflösen kann. Er kann Provider-spezifische Erkennung ausführen. Verwenden Sie
buildStaticProvider nur für Offline-Zeilen, die vor der Konfiguration der Authentifizierung
sicher angezeigt werden können; es darf keine Zugangsdaten erfordern oder Netzwerkanfragen stellen.
Die Anzeige models list --all von OpenClaw führt statische Kataloge derzeit
nur für gebündelte Provider-Plugins aus, mit leerer Konfiguration, leerer Umgebung und ohne
Agent-/Arbeitsbereichspfade.Wenn Ihr Authentifizierungsablauf während des Onboardings auch models.providers.*, Aliasse und
das Standardmodell des Agents patchen muss, verwenden Sie die Preset-Helfer aus
openclaw/plugin-sdk/provider-onboard. Die engsten Helfer sind
createDefaultModelPresetAppliers(...),
createDefaultModelsPresetAppliers(...) und
createModelCatalogPresetAppliers(...).Wenn ein nativer Endpunkt eines Providers gestreamte Nutzungsblöcke über den
normalen openai-completions-Transport unterstützt, bevorzugen Sie die gemeinsamen Kataloghelfer in
openclaw/plugin-sdk/provider-catalog-shared statt fest codierter
Provider-ID-Prüfungen. supportsNativeStreamingUsageCompat(...) und
applyProviderNativeStreamingUsageCompat(...) erkennen Unterstützung aus der
Endpunkt-Capability-Map, sodass native Endpunkte im Moonshot-/DashScope-Stil weiterhin
opt-in verwenden, auch wenn ein Plugin eine benutzerdefinierte Provider-ID nutzt.Die obigen Beispiele für Live-Erkennung decken Provider-APIs im Stil von /models ab. Behalten Sie
diese Erkennung in catalog.run, abgesichert durch nutzbare Authentifizierung, und halten Sie
staticRun für die Offline-Kataloggenerierung netzwerkfrei.Add dynamic model resolution
Wenn Ihr Provider beliebige Modell-IDs akzeptiert (wie ein Proxy oder Router),
fügen Sie Wenn die Auflösung einen Netzwerkaufruf erfordert, verwenden Sie
resolveDynamicModel hinzu:prepareDynamicModel für das asynchrone
Aufwärmen - resolveDynamicModel wird nach Abschluss erneut ausgeführt.Add runtime hooks (as needed)
Die meisten Provider benötigen nur Heute verfügbare Replay-Familien:
Heute verfügbare Stream-Familien:
catalog + resolveDynamicModel. Fügen Sie Hooks
schrittweise hinzu, wenn Ihr Provider sie benötigt.Gemeinsame Helfer-Builder decken inzwischen die häufigsten Replay-/Tool-Kompatibilitäts-
Familien ab, sodass Plugins normalerweise nicht jeden Hook einzeln von Hand verdrahten müssen:| Familie | Was eingebunden wird | Gebündelte Beispiele |
|---|---|---|
openai-compatible | Gemeinsame Replay-Richtlinie im OpenAI-Stil für OpenAI-kompatible Transporte, einschließlich Bereinigung von Tool-Call-IDs, Korrekturen für Assistant-First-Reihenfolge und generischer Gemini-Turn-Validierung, wo der Transport sie benötigt | moonshot, ollama, xai, zai |
anthropic-by-model | Claude-bewusste Replay-Richtlinie, ausgewählt nach modelId, sodass Anthropic-Message-Transporte Claude-spezifische Thinking-Block-Bereinigung nur erhalten, wenn das aufgelöste Modell tatsächlich eine Claude-ID ist | amazon-bedrock, anthropic-vertex |
google-gemini | Native Gemini-Replay-Richtlinie plus Bootstrap-Replay-Bereinigung. Die gemeinsame Familie hält die Gemini CLI mit Textausgabe bei markiertem Reasoning; der direkte google-Provider überschreibt resolveReasoningOutputMode zu native, weil Gemini API Thinking als native Thought-Parts ankommt. | google, google-gemini-cli |
passthrough-gemini | Bereinigung von Gemini-Thought-Signaturen für Gemini-Modelle, die über OpenAI-kompatible Proxy-Transporte laufen; aktiviert keine native Gemini-Replay-Validierung oder Bootstrap-Umschreibungen | openrouter, kilocode, opencode, opencode-go |
hybrid-anthropic-openai | Hybride Richtlinie für Provider, die Anthropic-Message- und OpenAI-kompatible Modelloberflächen in einem Plugin mischen; optionales Entfernen von Claude-only-Thinking-Blocks bleibt auf die Anthropic-Seite beschränkt | minimax |
| Familie | Was eingebunden wird | Gebündelte Beispiele |
|---|---|---|
google-thinking | Gemini-Thinking-Payload-Normalisierung auf dem gemeinsamen Stream-Pfad | google, google-gemini-cli |
kilocode-thinking | Kilo-Reasoning-Wrapper auf dem gemeinsamen Proxy-Stream-Pfad, wobei kilo/auto und nicht unterstützte Proxy-Reasoning-IDs eingefügtes Thinking überspringen | kilocode |
moonshot-thinking | Moonshot-Binärmapping nativer Thinking-Payloads aus Konfiguration + /think-Level | moonshot |
minimax-fast-mode | MiniMax-Fast-Mode-Modellumschreibung auf dem gemeinsamen Stream-Pfad | minimax, minimax-portal |
openai-responses-defaults | Gemeinsame native OpenAI/Codex-Responses-Wrapper: Attribution-Header, /fast/serviceTier, Textausführlichkeit, native Codex-Websuche, Reasoning-Kompatibilitäts-Payload-Formung und Responses-Kontextverwaltung | openai |
openrouter-thinking | OpenRouter-Reasoning-Wrapper für Proxy-Routen, wobei nicht unterstützte Modelle/auto zentral übersprungen werden | openrouter |
tool-stream-default-on | Standardmäßig aktivierter tool_stream-Wrapper für Provider wie Z.AI, die Tool-Streaming wünschen, sofern es nicht explizit deaktiviert wurde | zai |
SDK seams powering the family builders
SDK seams powering the family builders
Jeder Familien-Builder setzt sich aus öffentlichen Helfern niedrigerer Ebene zusammen, die aus demselben Paket exportiert werden und die Sie verwenden können, wenn ein Provider vom gemeinsamen Muster abweichen muss:
openclaw/plugin-sdk/provider-model-shared-ProviderReplayFamily,buildProviderReplayFamilyHooks(...)und die rohen Replay-Builder (buildOpenAICompatibleReplayPolicy,buildAnthropicReplayPolicyForModel,buildGoogleGeminiReplayPolicy,buildHybridAnthropicOrOpenAIReplayPolicy). Exportiert außerdem Gemini-Replay-Helfer (sanitizeGoogleGeminiReplayHistory,resolveTaggedReasoningOutputMode) und Endpunkt-/Modellhelfer (resolveProviderEndpoint,normalizeProviderId,normalizeGooglePreviewModelId).openclaw/plugin-sdk/provider-stream-ProviderStreamFamily,buildProviderStreamFamilyHooks(...),composeProviderStreamWrappers(...)sowie die gemeinsamen OpenAI/Codex-Wrapper (createOpenAIAttributionHeadersWrapper,createOpenAIFastModeWrapper,createOpenAIServiceTierWrapper,createOpenAIResponsesContextManagementWrapper,createCodexNativeWebSearchWrapper), DeepSeek-V4-OpenAI-kompatibler Wrapper (createDeepSeekV4OpenAICompatibleThinkingWrapper), Anthropic-Messages-Thinking-Prefill-Bereinigung (createAnthropicThinkingPrefillPayloadWrapper), Plain-Text-Tool-Call-Kompatibilität (createPlainTextToolCallCompatWrapper) und gemeinsame Proxy-/Provider-Wrapper (createOpenRouterWrapper,createToolStreamWrapper,createMinimaxFastModeWrapper).openclaw/plugin-sdk/provider-stream-shared- leichtgewichtige Payload- und Event-Wrapper für heiße Provider-Pfade, einschließlichcreateOpenAICompatibleCompletionsThinkingOffWrapper,createPayloadPatchStreamWrapper,createPlainTextToolCallCompatWrapper,normalizeOpenAICompatibleReasoningPayload(...)undsetQwenChatTemplateThinking(...).openclaw/plugin-sdk/provider-tools-ProviderToolCompatFamily,buildProviderToolCompatFamilyHooks("deepseek" | "gemini" | "openai")und die zugrunde liegenden Provider-Schema-Helfer.
native
Reasoning-Ausgabe verwenden, damit OpenClaw native Thought-Parts konsumiert, ohne
<think>- / <final>-Prompt-Direktiven hinzuzufügen. Text-only-Backends im Stil der Gemini CLI,
die eine finale JSON-/Textantwort parsen, können den gemeinsamen
markierten google-gemini-Vertrag beibehalten.Einige Stream-Helfer bleiben absichtlich Provider-lokal. @openclaw/anthropic-provider behält wrapAnthropicProviderStream, resolveAnthropicBetas, resolveAnthropicFastMode, resolveAnthropicServiceTier und die Anthropic-Wrapper-Builder niedrigerer Ebene in seiner eigenen öffentlichen api.ts- / contract-api.ts-Naht, weil sie Claude-OAuth-Beta-Behandlung und context1m-Gating codieren. Das xAI-Plugin behält native xAI-Responses-Formung ähnlich in seinem eigenen wrapStreamFn (/fast-Aliasse, Standard-tool_stream, Bereinigung nicht unterstützter Strict-Tools, xAI-spezifische Entfernung von Reasoning-Payloads).Dasselbe Paket-Root-Muster unterstützt auch @openclaw/openai-provider (Provider-Builder, Standardmodell-Helfer, Realtime-Provider-Builder) und @openclaw/openrouter-provider (Provider-Builder plus Onboarding-/Konfigurationshelfer).- Token exchange
- Custom headers
- Native transport identity
- Nutzung und Abrechnung
Für Provider, die vor jedem Inferenzaufruf einen Token-Austausch benötigen:
Alle verfügbaren Provider-Hooks
Alle verfügbaren Provider-Hooks
OpenClaw ruft Hooks in dieser Reihenfolge auf. Die meisten Provider verwenden nur 2-3:
Provider-Felder, die nur noch der Kompatibilität dienen und von OpenClaw nicht
mehr aufgerufen werden, wie
Hinweise zum Runtime-Fallback:
ProviderPlugin.capabilities und
suppressBuiltInModel, sind hier nicht aufgeführt.| # | Hook | Wann verwenden |
|---|---|---|
| 1 | catalog | Modellkatalog oder Standardwerte für die Basis-URL |
| 2 | applyConfigDefaults | Provider-eigene globale Standardwerte während der Konfigurationsmaterialisierung |
| 3 | normalizeModelId | Bereinigung von Legacy-/Preview-Modell-ID-Aliasen vor dem Lookup |
| 4 | normalizeTransport | Bereinigung von api / baseUrl der Provider-Familie vor der generischen Modellzusammenstellung |
| 5 | normalizeConfig | models.providers.<id>-Konfiguration normalisieren |
| 6 | applyNativeStreamingUsageCompat | Native Streaming-Nutzungs-Kompatibilitätsumschreibungen für Konfigurations-Provider |
| 7 | resolveConfigApiKey | Provider-eigene Authentifizierungsauflösung für Env-Marker |
| 8 | resolveSyntheticAuth | Lokale/selbst gehostete oder konfigurationsgestützte synthetische Authentifizierung |
| 9 | shouldDeferSyntheticProfileAuth | Synthetische gespeicherte Profil-Platzhalter hinter Env-/Config-Authentifizierung zurückstellen |
| 10 | resolveDynamicModel | Beliebige Upstream-Modell-IDs akzeptieren |
| 11 | prepareDynamicModel | Asynchroner Metadatenabruf vor der Auflösung |
| 12 | normalizeResolvedModel | Transport-Umschreibungen vor dem Runner |
| 13 | normalizeToolSchemas | Provider-eigene Tool-Schema-Bereinigung vor der Registrierung |
| 14 | inspectToolSchemas | Provider-eigene Tool-Schema-Diagnose |
| 15 | resolveReasoningOutputMode | Vertrag für getaggte vs. native Reasoning-Ausgabe |
| 16 | prepareExtraParams | Standard-Anfrageparameter |
| 17 | createStreamFn | Vollständig benutzerdefinierter StreamFn-Transport |
| 19 | wrapStreamFn | Benutzerdefinierte Header-/Body-Wrapper auf dem normalen Stream-Pfad |
| 20 | resolveTransportTurnState | Native Header/Metadaten pro Turn |
| 21 | resolveWebSocketSessionPolicy | Native WS-Session-Header/Cool-down |
| 22 | formatApiKey | Benutzerdefinierte Runtime-Token-Form |
| 23 | refreshOAuth | Benutzerdefinierte OAuth-Aktualisierung |
| 24 | buildAuthDoctorHint | Anleitung zur Authentifizierungsreparatur |
| 25 | matchesContextOverflowError | Provider-eigene Overflow-Erkennung |
| 26 | classifyFailoverReason | Provider-eigene Klassifizierung von Rate-Limit/Überlastung |
| 27 | isCacheTtlEligible | TTL-Gating für Prompt-Cache |
| 28 | buildMissingAuthMessage | Benutzerdefinierter Hinweis bei fehlender Authentifizierung |
| 29 | augmentModelCatalog | Synthetische Forward-Compat-Zeilen |
| 30 | resolveThinkingProfile | Modellspezifischer /think-Optionssatz |
| 31 | isBinaryThinking | Kompatibilität für binäres Thinking ein/aus |
| 32 | supportsXHighThinking | Kompatibilität für xhigh-Reasoning-Unterstützung |
| 33 | resolveDefaultThinkingLevel | Kompatibilität der Standard-/think-Policy |
| 34 | isModernModelRef | Live-/Smoke-Modellabgleich |
| 35 | prepareRuntimeAuth | Token-Austausch vor der Inferenz |
| 36 | resolveUsageAuth | Benutzerdefiniertes Parsen von Nutzungs-Anmeldedaten |
| 37 | fetchUsageSnapshot | Benutzerdefinierter Nutzungs-Endpunkt |
| 38 | createEmbeddingProvider | Provider-eigener Embedding-Adapter für Memory/Suche |
| 39 | buildReplayPolicy | Benutzerdefinierte Richtlinie für Transcript-Replay/Compaction |
| 40 | sanitizeReplayHistory | Provider-spezifische Replay-Umschreibungen nach generischer Bereinigung |
| 41 | validateReplayTurns | Strikte Replay-Turn-Validierung vor dem eingebetteten Runner |
| 42 | onModelSelected | Callback nach der Auswahl (z. B. Telemetrie) |
normalizeConfigprüft zuerst den passenden Provider und danach andere hook-fähige Provider-Plugins, bis eines die Konfiguration tatsächlich ändert. Wenn kein Provider-Hook einen unterstützten Google-Familien-Konfigurationseintrag umschreibt, wird weiterhin der gebündelte Google-Konfigurationsnormalisierer angewendet.resolveConfigApiKeyverwendet den Provider-Hook, wenn er bereitgestellt wird. Amazon Bedrock behält die AWS-Env-Marker-Auflösung in seinem Provider-Plugin; die Runtime-Authentifizierung selbst verwendet weiterhin die Standardkette des AWS SDK, wenn sie mitauth: "aws-sdk"konfiguriert ist.resolveThinkingProfile(ctx)erhält den ausgewähltenprovider,modelId, einen optional zusammengeführtenreasoning-Kataloghinweis und optional zusammengeführtecompat-Fakten des Modells. Verwenden Siecompatnur, um die Thinking-UI/das Thinking-Profil des Providers auszuwählen.resolveSystemPromptContributionermöglicht es einem Provider, cache-bewusste System-Prompt-Hinweise für eine Modellfamilie einzufügen. Bevorzugen Sie dies gegenüberbefore_prompt_build, wenn das Verhalten zu einer Provider-/Modellfamilie gehört und die stabile/dynamische Cache-Trennung beibehalten soll.
Zusätzliche Fähigkeiten hinzufügen (optional)
Schritt 5: Zusätzliche Fähigkeiten hinzufügen
Ein Provider-Plugin kann Embeddings, Sprache, Echtzeit-Transkription, Echtzeit-Sprache, Medienverständnis, Bildgenerierung, Videogenerierung, Web Fetch und Websuche neben Textinferenz registrieren. OpenClaw klassifiziert dies als Hybrid-Capability-Plugin - das empfohlene Muster für Unternehmens-Plugins (ein Plugin pro Anbieter). Siehe Interna: Capability Ownership.Registrieren Sie jede Fähigkeit innerhalb vonregister(api) neben Ihrem vorhandenen
api.registerProvider(...)-Aufruf. Wählen Sie nur die Tabs aus, die Sie benötigen:- Sprache (TTS)
- Echtzeit-Transkription
- Echtzeit-Sprache
- Medienverständnis
- Embeddings
- Bild- und Videogenerierung
- Webabruf und Suche
assertOkOrThrowProviderError(...) für Provider-HTTP-Fehler, damit
Plugins begrenzte Error-Body-Lesevorgänge, JSON-Fehlerparsing und
Request-ID-Suffixe gemeinsam nutzen.Testen
Schritt 6: Testen
src/provider.test.ts
In ClawHub veröffentlichen
Provider-Plugins werden genauso veröffentlicht wie jedes andere externe Code- Plugin:clawhub package publish verwenden.
Dateistruktur
Referenz zur Katalogreihenfolge
catalog.order steuert, wann Ihr Katalog im Verhältnis zu integrierten
Providern zusammengeführt wird:
| Reihenfolge | Wann | Anwendungsfall |
|---|---|---|
simple | Erster Durchlauf | Einfache API-Key-Provider |
profile | Nach simple | Provider, die von Auth-Profilen abhängen |
paired | Nach profile | Mehrere zusammengehörige Einträge erzeugen |
late | Letzter Durchlauf | Bestehende Provider überschreiben (gewinnt bei Kollision) |
Nächste Schritte
- Channel-Plugins - wenn Ihr Plugin auch einen Channel bereitstellt
- SDK-Runtime -
api.runtime-Hilfsfunktionen (TTS, Suche, Subagent) - SDK-Übersicht - vollständige Referenz für Subpath-Imports
- Plugin-Interna - Hook-Details und gebündelte Beispiele