Diese Anleitung führt Sie durch das Erstellen eines Provider-Plugins, das OpenClaw einen Modell-Provider (LLM) hinzufügt. Am Ende verfügen Sie über einen Provider mit einem Modellkatalog, API-Schlüssel-Authentifizierung und dynamischer Modellauflösung.Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Wenn Sie noch kein OpenClaw-Plugin erstellt haben, lesen Sie zuerst
Erste Schritte für die grundlegende Paketstruktur
und Manifest-Einrichtung.
Exemplarische Anleitung
Paket und Manifest
Schritt 1: Paket und Manifest
providerAuthEnvVars, damit OpenClaw
Zugangsdaten 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 aus Kurzform-
Modell-IDs wie acme-large automatisch zu laden, bevor Runtime-Hooks vorhanden sind. 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 eine
id, ein label, auth und catalog.
catalog ist der providerseitige Runtime-/Konfigurations-Hook; er kann Live-
Hersteller-APIs aufrufen und gibt models.providers-Einträge zurück.index.ts
registerModelCatalogProvider ist die neuere Control-Plane-Katalogoberfläche
für Listen-, Hilfe- und Auswahl-UI. Verwenden Sie sie für Zeilen zu Text, Bilderzeugung,
Videoerzeugung und Musikerzeugung. Belassen Sie Hersteller-Endpunktaufrufe und
Antwortzuordnung im Plugin; OpenClaw besitzt die gemeinsame Zeilenform, Quell-
Labels und Hilfe-Rendering.Damit ist ein funktionsfähiger Provider vorhanden. Benutzer können nun
openclaw onboard --acme-ai-api-key <key> ausführen und
acme-ai/acme-large als Modell auswählen.Wenn der vorgelagerte Provider andere Steuerungstokens als OpenClaw verwendet, fügen Sie eine
kleine bidirektionale Texttransformation hinzu, anstatt den Stream-Pfad zu ersetzen:input schreibt den endgültigen System-Prompt und den Inhalt von Textnachrichten vor
dem Transport um. output schreibt Assistenten-Text-Deltas und den endgültigen Text um,
bevor OpenClaw seine eigenen Steuerungsmarker oder die Kanalauslieferung parst.Für gebündelte Provider, die nur einen Text-Provider mit API-Schlüssel-
Authentifizierung sowie einer einzelnen kataloggestützten Runtime registrieren, verwenden Sie bevorzugt den enger gefassten
Helper defineSingleProviderPluginEntry(...):buildProvider ist der Live-Katalogpfad, der verwendet wird, wenn OpenClaw echte
Provider-Authentifizierung auflösen kann. Er kann providerspezifische Erkennung durchführen. Verwenden Sie
buildStaticProvider nur für Offline-Zeilen, die vor der Konfiguration der Authentifizierung sicher angezeigt werden können;
er darf keine Zugangsdaten erfordern und keine 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-/Workspace-Pfade.Wenn Ihr Authentifizierungsablauf außerdem models.providers.*, Aliasse und
das Standardmodell des Agents während des Onboardings patchen muss, verwenden Sie die Preset-Helper aus
openclaw/plugin-sdk/provider-onboard. Die engsten Helper sind
createDefaultModelPresetAppliers(...),
createDefaultModelsPresetAppliers(...) und
createModelCatalogPresetAppliers(...).Wenn ein nativer Endpunkt eines Providers gestreamte Nutzungsblöcke über den
normalen openai-completions-Transport unterstützt, verwenden Sie bevorzugt die gemeinsamen Katalog-Helper in
openclaw/plugin-sdk/provider-catalog-shared, anstatt
Provider-ID-Prüfungen fest zu codieren. supportsNativeStreamingUsageCompat(...) und
applyProviderNativeStreamingUsageCompat(...) erkennen Unterstützung anhand der
Endpunkt-Capability-Map, sodass native Endpunkte im Moonshot-/DashScope-Stil weiterhin
opt-in verwenden, selbst wenn ein Plugin eine benutzerdefinierte Provider-ID nutzt.Dynamische Modellauflösung hinzufügen
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 asynchrone
Vorbereitung - resolveDynamicModel wird nach Abschluss erneut ausgeführt.Runtime-Hooks hinzufügen (bei Bedarf)
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 Helper-Builder decken inzwischen die häufigsten Replay-/Tool-Kompatibilitäts-
Familien ab, sodass Plugins normalerweise nicht jeden Hook einzeln verdrahten müssen:| Familie | Was sie einbindet | Mitgelieferte Beispiele |
|---|---|---|
openai-compatible | Gemeinsame OpenAI-artige Replay-Policy 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-Policy, ausgewählt per 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-Policy plus Bootstrap-Replay-Bereinigung und Modus für getaggte Reasoning-Ausgabe | google, google-gemini-cli |
passthrough-gemini | Gemini-Thought-Signature-Bereinigung für Gemini-Modelle, die über OpenAI-kompatible Proxy-Transporte laufen; aktiviert keine native Gemini-Replay-Validierung oder Bootstrap-Neuschreibungen | openrouter, kilocode, opencode, opencode-go |
hybrid-anthropic-openai | Hybride Policy für Provider, die Anthropic-Message- und OpenAI-kompatible Modelloberflächen in einem Plugin mischen; optionales Entfernen von Thinking-Blocks nur für Claude bleibt auf die Anthropic-Seite beschränkt | minimax |
| Familie | Was sie einbindet | Mitgelieferte Beispiele |
|---|---|---|
google-thinking | Normalisierung von Gemini-Thinking-Payloads im gemeinsamen Stream-Pfad | google, google-gemini-cli |
kilocode-thinking | Kilo-Reasoning-Wrapper im gemeinsamen Proxy-Stream-Pfad, wobei kilo/auto und nicht unterstützte Proxy-Reasoning-IDs injiziertes Thinking überspringen | kilocode |
moonshot-thinking | Zuordnung nativer Moonshot-Binary-Thinking-Payloads aus Konfiguration + /think-Stufe | moonshot |
minimax-fast-mode | MiniMax-Fast-Mode-Modellumschreibung im gemeinsamen Stream-Pfad | minimax, minimax-portal |
openai-responses-defaults | Gemeinsame native OpenAI/Codex-Responses-Wrapper: Attributions-Header, /fast/serviceTier, Text-Ausführlichkeit, native Codex-Websuche, Reasoning-kompatible Payload-Formung und Responses-Kontextverwaltung | openai, openai-codex |
openrouter-thinking | OpenRouter-Reasoning-Wrapper für Proxy-Routen, wobei Überspringen bei nicht unterstützten Modellen/auto zentral gehandhabt wird | 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 ist | zai |
SDK-Seams, die die Family Builder antreiben
SDK-Seams, die die Family Builder antreiben
Jeder Family Builder besteht aus öffentlichen Low-Level-Helfern, die aus demselben Paket exportiert werden und auf die Sie zurückgreifen 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-/Modell-Helfer (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) und gemeinsame Proxy-/Provider-Wrapper (createOpenRouterWrapper,createToolStreamWrapper,createMinimaxFastModeWrapper).openclaw/plugin-sdk/provider-tools-ProviderToolCompatFamily,buildProviderToolCompatFamilyHooks("gemini")und zugrunde liegende Gemini-Schema-Helfer (normalizeGeminiToolSchemas,inspectGeminiToolSchemas).
@openclaw/anthropic-provider behält wrapAnthropicProviderStream, resolveAnthropicBetas, resolveAnthropicFastMode, resolveAnthropicServiceTier und die Low-Level-Anthropic-Wrapper-Builder in seinem eigenen öffentlichen api.ts-/contract-api.ts-Seam, weil sie Claude-OAuth-Beta-Behandlung und context1m-Gating kodieren. Das xAI-Plugin behält ähnlich die native xAI-Responses-Formung in seinem eigenen wrapStreamFn (/fast-Aliasse, Standard-tool_stream, Bereinigung nicht unterstützter Strict-Tools, xAI-spezifisches Entfernen von Reasoning-Payloads).Dasselbe Package-Root-Muster stützt auch @openclaw/openai-provider (Provider-Builder, Default-Model-Helfer, Realtime-Provider-Builder) und @openclaw/openrouter-provider (Provider-Builder plus Onboarding-/Konfigurationshelfer).- Token-Austausch
- Benutzerdefinierte Header
- Native transport identity
- Usage and billing
Für Provider, die vor jedem Inferenzaufruf einen Token-Austausch benötigen:
All available provider hooks
All available provider hooks
OpenClaw ruft Hooks in dieser Reihenfolge auf. Die meisten Provider verwenden nur 2-3:
Nur der Kompatibilität dienende Provider-Felder, die OpenClaw nicht mehr aufruft, wie
Hinweise zu Runtime-Fallbacks:
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 Aliasen für Legacy-/Preview-Modell-IDs vor dem Lookup |
| 4 | normalizeTransport | Bereinigung von api / baseUrl der Provider-Familie vor der generischen Modellassemblierung |
| 5 | normalizeConfig | models.providers.<id>-Konfiguration normalisieren |
| 6 | applyNativeStreamingUsageCompat | Kompatibilitäts-Umschreibungen für native Streaming-Nutzung bei Konfigurations-Providern |
| 7 | resolveConfigApiKey | Provider-eigene Authentifizierungsauflösung für Env-Marker |
| 8 | resolveSyntheticAuth | Lokale/selbst gehostete oder konfigurationsgestützte synthetische Authentifizierung |
| 9 | shouldDeferSyntheticProfileAuth | Synthetische Platzhalter für gespeicherte Profile hinter Env-/Konfigurationsauthentifizierung zurückstufen |
| 10 | resolveDynamicModel | Beliebige Upstream-Modell-IDs akzeptieren |
| 11 | prepareDynamicModel | Asynchroner Metadatenabruf vor der Auflösung |
| 12 | normalizeResolvedModel | Transport-Umschreibungen vor dem Runner |
| 13 | contributeResolvedModelCompat | Kompatibilitäts-Flags für Vendor-Modelle hinter einem anderen kompatiblen Transport |
| 14 | normalizeToolSchemas | Provider-eigene Bereinigung von Tool-Schemata vor der Registrierung |
| 15 | inspectToolSchemas | Provider-eigene Diagnosen für Tool-Schemata |
| 16 | resolveReasoningOutputMode | Vertrag für getaggte vs. native Reasoning-Ausgabe |
| 17 | prepareExtraParams | Standard-Anfrageparameter |
| 18 | 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-Sitzungs-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-Limits/Überlastung |
| 27 | isCacheTtlEligible | Prompt-Cache-TTL-Gating |
| 28 | buildMissingAuthMessage | Benutzerdefinierter Hinweis bei fehlender Authentifizierung |
| 29 | augmentModelCatalog | Synthetische Forward-Compat-Zeilen |
| 30 | resolveThinkingProfile | Modellspezifisches /think-Optionsset |
| 31 | isBinaryThinking | Binäre Thinking-Ein/Aus-Kompatibilität |
| 32 | supportsXHighThinking | Kompatibilität für xhigh-Reasoning-Unterstützung |
| 33 | resolveDefaultThinkingLevel | Kompatibilität der Standard-/think-Richtlinie |
| 34 | isModernModelRef | Live-/Smoke-Modellabgleich |
| 35 | prepareRuntimeAuth | Token-Austausch vor der Inferenz |
| 36 | resolveUsageAuth | Benutzerdefiniertes Parsen von Nutzungsanmeldedaten |
| 37 | fetchUsageSnapshot | Benutzerdefinierter Nutzungs-Endpunkt |
| 38 | createEmbeddingProvider | Provider-eigener Embedding-Adapter für Speicher/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 dann andere hook-fähige Provider-Plugins, bis eines die Konfiguration tatsächlich ändert. Wenn kein Provider-Hook einen unterstützten Google-Family-Konfigurationseintrag umschreibt, greift weiterhin der gebündelte Google-Konfigurationsnormalisierer.resolveConfigApiKeyverwendet den Provider-Hook, wenn er bereitgestellt wird. Der gebündelteamazon-bedrock-Pfad hat hier außerdem einen integrierten AWS-Env-Marker-Resolver, obwohl die Bedrock-Runtime-Authentifizierung selbst weiterhin die Standardkette des AWS SDK verwendet.resolveSystemPromptContributionermöglicht einem Provider, cache-bewusste System-Prompt-Anleitung für eine Modellfamilie einzuschleusen. Bevorzugen Sie dies gegenüberbefore_prompt_build, wenn das Verhalten zu einem Provider/einer Modellfamilie gehört und die stabile/dynamische Cache-Aufteilung erhalten soll.
Add extra capabilities (optional)
Schritt 5: Zusätzliche Fähigkeiten hinzufügen
Ein Provider-Plugin kann Sprachausgabe, Echtzeittranskription, Echtzeit-Voice, Medienverständnis, Bildgenerierung, Videogenerierung, Web-Abruf 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-Zuständigkeit.Registrieren Sie jede Capability inregister(api) neben Ihrem bestehenden api.registerProvider(...)-Aufruf. Wählen Sie nur die Tabs aus, die Sie benötigen:- Sprachausgabe (TTS)
- Echtzeittranskription
- Echtzeit-Voice
- Medienverständnis
- Bild- und Videogenerierung
- Web-Abruf und Suche
assertOkOrThrowProviderError(...) für HTTP-Fehler von Providern, damit Plugins begrenzte Fehlertext-Lesevorgänge, JSON-Fehleranalyse 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 relativ zu integrierten Providern zusammengeführt wird:
| Reihenfolge | Zeitpunkt | Anwendungsfall |
|---|---|---|
simple | Erster Durchlauf | Einfache API-Key-Provider |
profile | Nach simple | Provider, die durch Auth-Profile gesteuert sind |
paired | Nach profile | Mehrere verwandte Einträge synthetisieren |
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-Helper (TTS, Suche, Subagent) - SDK-Überblick - vollständige Referenz für Subpath-Imports
- Plugin-Interna - Hook-Details und gebündelte Beispiele