Skip to main content
Erstellen Sie ein Provider-Plugin, um OpenClaw einen Modell-Provider (LLM) hinzuzufügen: einen Modellkatalog, API-Schlüssel-Authentifizierung und dynamische Modellauflösung.
Noch nicht mit OpenClaw-Plugins vertraut? Lesen Sie zuerst Erste Schritte, um mehr über die Paketstruktur und die Einrichtung des Manifests zu erfahren.
Provider-Plugins fügen Modelle zur normalen Inferenzschleife von OpenClaw hinzu. Wenn das Modell über einen nativen Agent-Daemon ausgeführt werden muss, der Threads, Compaction oder Tool-Ereignisse verwaltet, kombinieren Sie den Provider mit einem Agent- Harness, anstatt Details des Daemon-Protokolls in den Core einzufügen.

Schritt-für-Schritt-Anleitung

1

Paket und Manifest

Schritt 1: Paket und Manifest

setup.providers[].envVars ermöglicht OpenClaw, Anmeldedaten zu erkennen, ohne die Laufzeit 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 anhand abgekürzter Modell-IDs wie acme-large automatisch zu laden, bevor Laufzeit-Hooks vorhanden sind. openclaw.compat und openclaw.build in package.json sind für die Veröffentlichung auf ClawHub erforderlich (openclaw.compat.pluginApi und openclaw.build.openclawVersion sind die beiden Pflichtfelder; minGatewayVersion greift auf openclaw.install.minHostVersion zurück, wenn es ausgelassen wird).
2

Provider registrieren

Ein minimaler Text-Provider benötigt id, label, auth und catalog. catalog ist der Provider-eigene Laufzeit-/Konfigurations-Hook; er kann Live- Hersteller-APIs aufrufen und gibt models.providers-Einträge zurück.
index.ts
registerModelCatalogProvider ist die neuere Katalogoberfläche der Steuerungsebene für Listen-, Hilfe- und Auswahloberflächen und deckt Zeilen vom Typ text, voice, image_generation, video_generation und music_generation ab. Belassen Sie Aufrufe von Herstellerendpunkten und die Zuordnung von Antworten im Plugin; OpenClaw verwaltet die gemeinsame Zeilenstruktur, Quellenbezeichnungen und die Darstellung der Hilfe.Damit ist der Provider funktionsfähig. Benutzer können jetzt openclaw onboard --acme-ai-api-key <key> ausführen und acme-ai/acme-large als Modell auswählen.

Live-Modellerkennung

Wenn Ihr Provider eine OpenAI-kompatible /models-API bereitstellt, aktivieren Sie für die Einzel-Provider-Hilfsfunktion die gemeinsame Erkennung:
liveModelDiscovery: true ist ein öffentlicher Vertrag des Plugin SDK mit folgenden Verhaltensweisen:Übergeben Sie für einen Endpunkt ohne Bearer-Authentifizierung oder einen nicht standardmäßigen Listenendpunkt Optionen anstelle von true:
Verwenden Sie endpointUrl nicht als uneingeschränkten alternativen Host. Die requireBaseUrl-Prüfung bildet die Grenze zur Isolation von Anmeldedaten für Provider, deren Host für die Modellliste sich von ihrem Inferenz-Host unterscheidet.Wenn der Provider eine benutzerdefinierte Modellsemantik anstelle der konservativen OpenAI-kompatiblen Projektion benötigt, belassen Sie diese Projektion im Plugin und verwenden Sie openclaw/plugin-sdk/provider-catalog-live-runtime für den gemeinsamen Abruf- Lebenszyklus. Die Hilfsfunktion stellt Ihnen geschützte HTTP-Abrufe, Provider-Authentifizierungsheader, strukturierte HTTP-Fehler, TTL-Caching und statisches Rückfallverhalten bereit, ohne Provider-Richtlinien in den OpenClaw-Core einzufügen.Verwenden Sie buildLiveModelProviderConfig, wenn die Live-API Ihnen nur mitteilt, welche Zeilen des Provider-eigenen statischen Katalogs derzeit verfügbar sind:
index.ts
Verwenden Sie getCachedLiveProviderModelRows, wenn die Provider-API umfangreichere Metadaten zurückgibt und das Plugin die Zeilen selbst in OpenClaw- Modelldefinitionen überführen muss:
index.ts
run sollte weiterhin durch die Authentifizierung geschützt sein und null zurückgeben, wenn keine verwendbaren Anmeldedaten verfügbar sind. Behalten Sie einen Offline-staticRun oder einen statischen Fallback bei, damit Einrichtung, Dokumentation, Tests und Auswahloberflächen nicht vom Live-Netzwerkzugriff abhängen. Verwenden Sie eine TTL, die für die Aktualität der Modellliste geeignet ist, vermeiden Sie Dateisystemabfragen zur Anfragezeit und übergeben Sie einen providerspezifischen readRows / readModelId nur, wenn die Upstream-Antwort keine OpenAI-kompatible { data: [{ id, object }] }- Struktur aufweist.Wenn der Upstream-Provider andere Steuerungstoken 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 der Übertragung um. output schreibt Assistenten-Text-Deltas und den endgültigen Text um, bevor OpenClaw seine eigenen Steuerungsmarkierungen parst oder die Kanalauslieferung erfolgt.Bevorzugen Sie für gebündelte Provider, die nur einen Text-Provider mit API-Schlüssel- Authentifizierung und einer einzelnen kataloggestützten Laufzeit registrieren, den enger gefassten Hilfsmechanismus defineSingleProviderPluginEntry(...):
buildProvider ist der Live-Katalogpfad, der verwendet wird, wenn OpenClaw echte Provider-Authentifizierungsdaten auflösen kann. Er kann eine providerspezifische Erkennung durchführen. Verwenden Sie buildStaticProvider nur für Offline-Zeilen, die sicher angezeigt werden können, bevor die Authentifizierung konfiguriert ist; er darf weder Anmeldedaten erfordern noch Netzwerkanfragen ausführen. Die models list --all-Anzeige von OpenClaw führt statische Kataloge derzeit nur für gebündelte Provider-Plugins aus, mit einer leeren Konfiguration, einer leeren Umgebung und ohne Agenten-/Arbeitsbereichspfade.Wenn Ihr Authentifizierungsablauf während des Onboardings außerdem models.providers.*, Aliasse und das Standardmodell des Agenten anpassen muss, verwenden Sie die Voreinstellungs-Hilfsmechanismen aus openclaw/plugin-sdk/provider-onboard. Die am engsten gefassten Hilfsmechanismen sind createDefaultModelPresetAppliers(...), createDefaultModelsPresetAppliers(...) und createModelCatalogPresetAppliers(...).Wenn der native Endpunkt eines Providers gestreamte Nutzungsblöcke über den normalen openai-completions-Transport unterstützt, bevorzugen Sie die gemeinsamen Katalog-Hilfsmechanismen in openclaw/plugin-sdk/provider-catalog-shared, anstatt Prüfungen auf Provider-IDs fest zu codieren. supportsNativeStreamingUsageCompat(...) und applyProviderNativeStreamingUsageCompat(...) erkennen die Unterstützung anhand der Endpunkt-Fähigkeitszuordnung, sodass native Endpunkte im Moonshot-/DashScope-Stil weiterhin aktiviert werden, selbst wenn ein Plugin eine benutzerdefinierte Provider-ID verwendet.Die obigen Beispiele zur Live-Erkennung decken Provider-APIs im Stil von /models ab. Belassen Sie diese Erkennung innerhalb von catalog.run, geschützt durch verwendbare Authentifizierungsdaten, und halten Sie staticRun für die Offline-Katalogerzeugung netzwerkfrei.
3

Dynamische Modellauflösung hinzufügen

Wenn Ihr Provider beliebige Modell-IDs akzeptiert (wie ein Proxy oder Router), fügen Sie resolveDynamicModel hinzu:
Wenn die Auflösung einen Netzwerkaufruf erfordert, verwenden Sie prepareDynamicModel für die asynchrone Vorabinitialisierung – resolveDynamicModel wird nach deren Abschluss erneut ausgeführt.
4

Laufzeit-Hooks hinzufügen (nach Bedarf)

Die meisten Provider benötigen nur catalog + resolveDynamicModel. Fügen Sie Hooks schrittweise hinzu, wenn Ihr Provider sie benötigt.Gemeinsame Hilfs-Builder decken jetzt die gängigsten Familien für Replay-/Tool-Kompatibilität ab, sodass Plugins normalerweise nicht jeden Hook einzeln manuell verdrahten müssen:
Derzeit verfügbare Replay-Familien:Derzeit verfügbare Stream-Familien:
Jeder Familien-Builder setzt sich aus öffentlichen Hilfsfunktionen niedrigerer Ebene zusammen, die aus demselben Paket exportiert werden und verwendet werden können, wenn ein Provider vom üblichen Muster abweichen muss:
  • openclaw/plugin-sdk/provider-model-shared - ProviderReplayFamily, buildProviderReplayFamilyHooks(...) und die unverarbeiteten Replay-Builder (buildOpenAICompatibleReplayPolicy, buildAnthropicReplayPolicyForModel, buildGoogleGeminiReplayPolicy, buildHybridAnthropicOrOpenAIReplayPolicy). Exportiert außerdem Gemini-Replay-Hilfsfunktionen (sanitizeGoogleGeminiReplayHistory, resolveTaggedReasoningOutputMode) sowie Endpunkt-/Modell-Hilfsfunktionen (resolveProviderEndpoint, normalizeProviderId, normalizeGooglePreviewModelId).
  • openclaw/plugin-sdk/provider-stream - ProviderStreamFamily, buildProviderStreamFamilyHooks(...), composeProviderStreamWrappers(...), außerdem die gemeinsamen OpenAI/Codex-Wrapper (createOpenAIAttributionHeadersWrapper, createOpenAIFastModeWrapper, createOpenAIServiceTierWrapper, createOpenAIResponsesContextManagementWrapper, createCodexNativeWebSearchWrapper), den OpenAI-kompatiblen DeepSeek-V4-Wrapper (createDeepSeekV4OpenAICompatibleThinkingWrapper), die Bereinigung vorausgefüllter Denkinhalte für Anthropic Messages (createAnthropicThinkingPrefillPayloadWrapper), die Kompatibilität für Tool-Aufrufe im Klartext (createPlainTextToolCallCompatWrapper) und gemeinsame Proxy-/Provider-Wrapper (createOpenRouterWrapper, createToolStreamWrapper, createMinimaxFastModeWrapper).
  • openclaw/plugin-sdk/provider-stream-shared - leichtgewichtige Nutzlast- und Ereignis-Wrapper für häufig durchlaufene Provider-Pfade, darunter createOpenAICompatibleCompletionsThinkingOffWrapper, createPayloadPatchStreamWrapper, createPlainTextToolCallCompatWrapper, normalizeOpenAICompatibleReasoningPayload(...) und setQwenChatTemplateThinking(...).
  • openclaw/plugin-sdk/provider-tools - ProviderToolCompatFamily, buildProviderToolCompatFamilyHooks("deepseek" | "gemini" | "openai") und zugrunde liegende Hilfsfunktionen für Provider-Schemas.
Halten Sie bei Providern der Gemini-Familie den Modus der Reasoning-Ausgabe mit dem Transport in Einklang. Provider der direkten Google Gemini API sollten die Reasoning-Ausgabe native verwenden, damit OpenClaw native Gedankenbestandteile verarbeitet, ohne die Prompt-Direktiven <think> / <final> hinzuzufügen. Reine Text-Backends im Stil der Gemini CLI, die eine abschließende JSON-/Textantwort parsen, können den gemeinsamen markierten Vertrag google-gemini beibehalten.Einige Stream-Hilfsfunktionen bleiben absichtlich providerspezifisch. @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-Schnittstelle, da sie die Handhabung der Claude-OAuth-Beta und die context1m-Steuerung abbilden. Das xAI-Plugin behält die native Gestaltung von xAI Responses ebenfalls in seinem eigenen wrapStreamFn (/fast-Aliasse, standardmäßiges tool_stream, Bereinigung nicht unterstützter strikter Tools, xAI-spezifische Entfernung der Reasoning-Nutzlast).Dasselbe Paketwurzelmuster bildet auch die Grundlage für @openclaw/openai-provider (Provider-Builder, Hilfsfunktionen für Standardmodelle, Echtzeit-Provider-Builder) und @openclaw/openrouter-provider (Provider-Builder sowie Hilfsfunktionen für Onboarding/Konfiguration).
Für Provider, die vor jedem Inferenzaufruf einen Token-Austausch benötigen:
OpenClaw ruft Hooks für Modell-/Provider-Plugins ungefähr in dieser Reihenfolge auf. Die meisten Provider verwenden nur 2-3. Dies ist nicht der vollständige Vertrag ProviderPlugin – die vollständige, derzeit aktuelle Hook-Liste und Hinweise zu Fallbacks finden Sie unter Interna: Provider-Laufzeit-Hooks. Ausschließlich der Kompatibilität dienende Provider-Felder, die OpenClaw nicht mehr aufruft, etwa ProviderPlugin.capabilities und suppressBuiltInModel, sind hier nicht aufgeführt.Hinweise zu Laufzeit-Fallbacks:
  • normalizeConfig ermittelt pro Provider-ID genau ein zuständiges Plugin (zuerst gebündelte Provider, dann das passende Laufzeit-Plugin) und ruft ausschließlich diesen Hook auf – andere Provider werden nicht durchsucht. Googles eigener normalizeConfig-Hook normalisiert die Konfigurationseinträge google / google-vertex / google-antigravity; er ist kein separater Core-Fallback.
  • resolveConfigApiKey verwendet den Provider-Hook, wenn dieser verfügbar ist. Amazon Bedrock behält die Auflösung von AWS-Umgebungsmarkierungen in seinem Provider-Plugin; die Laufzeitauthentifizierung selbst verwendet bei einer Konfiguration mit auth: "aws-sdk" weiterhin die Standardkette des AWS SDK.
  • resolveThinkingProfile(ctx) erhält die ausgewählten provider, modelId, den optional zusammengeführten reasoning-Kataloghinweis und die optional zusammengeführten compat-Modelldaten. Verwenden Sie compat ausschließlich zur Auswahl der Denkoberfläche bzw. des Denkprofils des Providers.
  • resolveSystemPromptContribution ermöglicht einem Provider, cachebewusste System-Prompt-Hinweise für eine Modellfamilie einzufügen. Ziehen Sie diesen Hook dem veralteten pluginweiten before_prompt_build-Hook vor, wenn das Verhalten zu einer einzelnen Provider-/Modellfamilie gehört und die Trennung zwischen stabilem und dynamischem Cache erhalten bleiben soll.
5

Zusätzliche Fähigkeiten hinzufügen (optional)

Schritt 5: Zusätzliche Fähigkeiten hinzufügen

Ein Provider-Plugin kann neben der Textinferenz auch Embeddings, Sprache, Echtzeittranskription, Echtzeitsprache, Medienverständnis, Bildgenerierung, Videogenerierung, Webabruf und Websuche registrieren. OpenClaw klassifiziert dies als ein Plugin mit Hybridfähigkeiten – das empfohlene Muster für Unternehmens-Plugins (ein Plugin pro Anbieter). Siehe Interna: Zuständigkeit für Fähigkeiten.Registrieren Sie jede Fähigkeit innerhalb von register(api) neben Ihrem vorhandenen api.registerProvider(...)-Aufruf. Wählen Sie nur die benötigten Tabs aus:
Verwenden Sie assertOkOrThrowProviderError(...) für HTTP-Fehler des Providers, damit Plugins begrenzte Fehlertext-Lesevorgänge, die Analyse von JSON-Fehlern und Anfrage-ID-Suffixe gemeinsam nutzen.
6

Testen

Schritt 6: Testen

src/provider.test.ts

Auf ClawHub veröffentlichen

Provider-Plugins werden genauso wie alle anderen externen Code-Plugins veröffentlicht:
clawhub skill publish <path> ist ein anderer Befehl zum Veröffentlichen eines Skills-Ordners und nicht eines Plugin-Pakets – verwenden Sie ihn hier nicht.

Dateistruktur

Referenz zur Katalogreihenfolge

catalog.order steuert, wann Ihr Katalog relativ zu den integrierten Providern zusammengeführt wird:

Nächste Schritte

Verwandte Themen