Skip to main content
Créez un Plugin de fournisseur pour ajouter un fournisseur de modèles (LLM) à OpenClaw : un catalogue de modèles, une authentification par clé API et une résolution dynamique des modèles.
Vous découvrez les plugins OpenClaw ? Lisez d’abord Bien démarrer pour découvrir la structure des paquets et la configuration du manifeste.
Les plugins de fournisseur ajoutent des modèles à la boucle d’inférence normale d’OpenClaw. Si le modèle doit s’exécuter via un démon d’agent natif qui gère les fils de discussion, la Compaction ou les événements d’outils, associez le fournisseur à un environnement d’exécution d’agent plutôt que d’intégrer les détails du protocole du démon au cœur.

Procédure détaillée

1

Paquet et manifeste

Étape 1 : paquet et manifeste

setup.providers[].envVars permet à OpenClaw de détecter les identifiants sans charger l’environnement d’exécution de votre Plugin. Ajoutez providerAuthAliases lorsqu’une variante de fournisseur doit réutiliser l’identifiant d’authentification d’un autre fournisseur. modelSupport est facultatif et permet à OpenClaw de charger automatiquement votre Plugin de fournisseur à partir d’identifiants abrégés de modèles tels que acme-large, avant que les hooks d’exécution n’existent. openclaw.compat et openclaw.build dans package.json sont obligatoires pour la publication sur ClawHub (openclaw.compat.pluginApi et openclaw.build.openclawVersion sont les deux champs obligatoires ; minGatewayVersion utilise par défaut openclaw.install.minHostVersion lorsqu’il est omis).
2

Enregistrer le fournisseur

Un fournisseur de texte minimal nécessite un id, un label, une configuration auth et un catalog. catalog est le hook d’exécution et de configuration géré par le fournisseur ; il peut appeler les API actives du fournisseur et renvoie des entrées models.providers.
index.ts
registerModelCatalogProvider est la nouvelle surface de catalogue du plan de contrôle pour les interfaces de liste, d’aide et de sélection ; elle couvre les lignes text, voice, image_generation, video_generation et music_generation. Conservez les appels aux points de terminaison du fournisseur et la mise en correspondance des réponses dans le Plugin ; OpenClaw gère la structure partagée des lignes, les libellés de source et le rendu de l’aide.Vous disposez maintenant d’un fournisseur fonctionnel. Les utilisateurs peuvent exécuter openclaw onboard --acme-ai-api-key <key> et sélectionner acme-ai/acme-large comme modèle.

Découverte dynamique des modèles

Si votre fournisseur expose une API de type /models, conservez le point de terminaison propre au fournisseur et la projection des lignes dans votre Plugin, puis utilisez openclaw/plugin-sdk/provider-catalog-live-runtime pour le cycle de récupération partagé. Cet utilitaire fournit des requêtes HTTP protégées, des en-têtes d’authentification du fournisseur, des erreurs HTTP structurées, une mise en cache avec durée de vie et un comportement de repli statique, sans intégrer de règles propres au fournisseur dans le cœur d’OpenClaw.Utilisez buildLiveModelProviderConfig lorsque l’API dynamique vous indique uniquement quels éléments du catalogue statique géré par le fournisseur sont actuellement disponibles :
index.ts
Utilisez getCachedLiveProviderModelRows lorsque l’API du fournisseur renvoie des métadonnées plus riches et que le Plugin doit lui-même projeter les lignes dans les définitions de modèles OpenClaw :
index.ts
run doit rester conditionné à l’authentification et renvoyer null lorsqu’aucun identifiant utilisable n’est disponible. Conservez un staticRun hors ligne ou une solution de repli statique afin que la configuration, la documentation, les tests et les interfaces de sélection ne dépendent pas d’un accès réseau actif. Utilisez une durée de vie adaptée à la fraîcheur de la liste des modèles, évitez d’interroger le système de fichiers à chaque requête et transmettez des fonctions readRows / readModelId propres au fournisseur uniquement lorsque la réponse en amont n’adopte pas une structure compatible avec OpenAI de la forme { data: [{ id, object }] }.Si le fournisseur en amont utilise des jetons de contrôle différents de ceux d’OpenClaw, ajoutez une petite transformation de texte bidirectionnelle au lieu de remplacer le chemin de flux :
input réécrit l’invite système finale et le contenu textuel du message avant le transport. output réécrit les fragments de texte de l’assistant et le texte final avant qu’OpenClaw n’analyse ses propres marqueurs de contrôle ou n’effectue la remise au canal.Pour les fournisseurs intégrés qui n’enregistrent qu’un seul fournisseur de texte avec une authentification par clé API et un environnement d’exécution unique adossé à un catalogue, privilégiez l’utilitaire plus ciblé defineSingleProviderPluginEntry(...) :
buildProvider est le chemin du catalogue dynamique utilisé lorsqu’OpenClaw peut résoudre l’authentification réelle du fournisseur. Il peut effectuer une détection propre au fournisseur. Utilisez buildStaticProvider uniquement pour les entrées hors ligne qui peuvent être affichées sans risque avant que l’authentification soit configurée ; il ne doit pas nécessiter d’identifiants ni effectuer de requêtes réseau. L’affichage de models list --all d’OpenClaw n’exécute actuellement les catalogues statiques que pour les plugins de fournisseur intégrés, avec une configuration vide, un environnement vide et aucun chemin d’agent ou d’espace de travail.Si votre flux d’authentification doit également modifier models.providers.*, les alias et le modèle par défaut de l’agent pendant l’intégration, utilisez les assistants de préréglage de openclaw/plugin-sdk/provider-onboard. Les assistants les plus ciblés sont createDefaultModelPresetAppliers(...), createDefaultModelsPresetAppliers(...) et createModelCatalogPresetAppliers(...).Lorsque le point de terminaison natif d’un fournisseur prend en charge les blocs d’utilisation diffusés sur le transport openai-completions standard, préférez les assistants de catalogue partagés de openclaw/plugin-sdk/provider-catalog-shared plutôt que de coder en dur des vérifications d’identifiant de fournisseur. supportsNativeStreamingUsageCompat(...) et applyProviderNativeStreamingUsageCompat(...) détectent la prise en charge à partir de la carte des capacités du point de terminaison, de sorte que les points de terminaison natifs de type Moonshot/DashScope puissent toujours l’activer même lorsqu’un plugin utilise un identifiant de fournisseur personnalisé.Les exemples de détection dynamique ci-dessus couvrent les API de fournisseur de type /models. Conservez cette détection dans catalog.run, conditionnée par la présence d’une authentification utilisable, et veillez à ce que staticRun n’utilise pas le réseau pour la génération hors ligne du catalogue.
3

Add dynamic model resolution

Si votre fournisseur accepte des identifiants de modèle arbitraires (comme un proxy ou un routeur), ajoutez resolveDynamicModel :
Si la résolution nécessite un appel réseau, utilisez prepareDynamicModel pour le préchauffage asynchrone — resolveDynamicModel s’exécute à nouveau une fois celui-ci terminé.
4

Add runtime hooks (as needed)

La plupart des fournisseurs n’ont besoin que de catalog + resolveDynamicModel. Ajoutez des hooks progressivement, selon les besoins de votre fournisseur.Les générateurs d’assistants partagés couvrent désormais les familles les plus courantes de compatibilité de relecture et d’outils, de sorte que les plugins n’ont généralement pas besoin de connecter manuellement chaque hook :
Familles de relecture actuellement disponibles :Familles de flux actuellement disponibles :
Chaque générateur de famille est composé d’assistants publics de plus bas niveau exportés depuis le même paquet, que vous pouvez utiliser lorsqu’un fournisseur doit s’écarter du modèle commun :
  • openclaw/plugin-sdk/provider-model-sharedProviderReplayFamily, buildProviderReplayFamilyHooks(...) et les générateurs de relecture bruts (buildOpenAICompatibleReplayPolicy, buildAnthropicReplayPolicyForModel, buildGoogleGeminiReplayPolicy, buildHybridAnthropicOrOpenAIReplayPolicy). Exporte également les assistants de relecture Gemini (sanitizeGoogleGeminiReplayHistory, resolveTaggedReasoningOutputMode) ainsi que les assistants de point de terminaison et de modèle (resolveProviderEndpoint, normalizeProviderId, normalizeGooglePreviewModelId).
  • openclaw/plugin-sdk/provider-streamProviderStreamFamily, buildProviderStreamFamilyHooks(...), composeProviderStreamWrappers(...), ainsi que les enveloppes OpenAI/Codex partagées (createOpenAIAttributionHeadersWrapper, createOpenAIFastModeWrapper, createOpenAIServiceTierWrapper, createOpenAIResponsesContextManagementWrapper, createCodexNativeWebSearchWrapper), l’enveloppe DeepSeek V4 compatible avec OpenAI (createDeepSeekV4OpenAICompatibleThinkingWrapper), le nettoyage du préremplissage de réflexion des messages Anthropic (createAnthropicThinkingPrefillPayloadWrapper), la compatibilité des appels d’outils en texte brut (createPlainTextToolCallCompatWrapper) et les enveloppes partagées de proxy et de fournisseur (createOpenRouterWrapper, createToolStreamWrapper, createMinimaxFastModeWrapper).
  • openclaw/plugin-sdk/provider-stream-shared — enveloppes légères de charges utiles et d’événements pour les chemins critiques des fournisseurs, notamment createOpenAICompatibleCompletionsThinkingOffWrapper, createPayloadPatchStreamWrapper, createPlainTextToolCallCompatWrapper, normalizeOpenAICompatibleReasoningPayload(...) et setQwenChatTemplateThinking(...).
  • openclaw/plugin-sdk/provider-toolsProviderToolCompatFamily, buildProviderToolCompatFamilyHooks("deepseek" | "gemini" | "openai") et les assistants sous-jacents de schéma de fournisseur.
Pour les fournisseurs de la famille Gemini, veillez à ce que le mode de sortie du raisonnement corresponde au transport. Les fournisseurs directs de l’API Google Gemini doivent utiliser la sortie de raisonnement native afin qu’OpenClaw consomme les parties de pensée natives sans ajouter de directives d’invite <think> / <final>. Les moteurs de type CLI Gemini exclusivement textuels qui analysent une réponse finale JSON ou textuelle peuvent conserver le contrat balisé partagé google-gemini.Certains assistants de flux restent volontairement locaux au fournisseur. @openclaw/anthropic-provider conserve wrapAnthropicProviderStream, resolveAnthropicBetas, resolveAnthropicFastMode, resolveAnthropicServiceTier et les générateurs d’enveloppes Anthropic de plus bas niveau dans sa propre interface publique api.ts / contract-api.ts, car ils encodent la gestion des versions bêta OAuth de Claude et le contrôle de context1m. De même, le plugin xAI conserve la mise en forme native de Responses xAI dans sa propre fonction wrapStreamFn (alias /fast, tool_stream par défaut, nettoyage des outils stricts non pris en charge et suppression de la charge utile de raisonnement propre à xAI).Le même modèle à la racine du paquet sous-tend également @openclaw/openai-provider (générateurs de fournisseurs, assistants de modèle par défaut et générateurs de fournisseurs en temps réel) et @openclaw/openrouter-provider (générateur de fournisseur avec assistants d’intégration et de configuration).
Pour les fournisseurs qui nécessitent un échange de jeton avant chaque appel d’inférence :
OpenClaw appelle les hooks approximativement dans cet ordre pour les plugins de modèle ou de fournisseur. La plupart des fournisseurs n’en utilisent que 2 ou 3. Il ne s’agit pas du contrat ProviderPlugin complet : consultez Fonctionnement interne : hooks d’exécution des fournisseurs pour obtenir la liste complète et actuellement exacte des hooks ainsi que les remarques sur les mécanismes de repli. Les champs de fournisseur réservés à la compatibilité qu’OpenClaw n’appelle plus, tels que ProviderPlugin.capabilities et suppressBuiltInModel, ne sont pas répertoriés ici.Remarques sur les mécanismes de repli à l’exécution :
  • normalizeConfig résout un seul plugin propriétaire par identifiant de fournisseur (d’abord les fournisseurs intégrés, puis le plugin d’exécution correspondant) et n’appelle que ce hook : aucune analyse des autres fournisseurs n’est effectuée. Le hook normalizeConfig propre à Google est celui qui normalise les entrées de configuration google / google-vertex / google-antigravity ; il ne s’agit pas d’un mécanisme de repli distinct du cœur.
  • resolveConfigApiKey utilise le hook du fournisseur lorsqu’il est exposé. Amazon Bedrock conserve la résolution des marqueurs d’environnement AWS dans son plugin de fournisseur ; l’authentification à l’exécution continue toutefois d’utiliser la chaîne par défaut du SDK AWS lorsqu’elle est configurée avec auth: "aws-sdk".
  • resolveThinkingProfile(ctx) reçoit les valeurs sélectionnées provider et modelId, l’indication facultative reasoning issue du catalogue fusionné, ainsi que les informations facultatives compat du modèle fusionné. Utilisez compat uniquement pour sélectionner l’interface ou le profil de réflexion du fournisseur.
  • resolveSystemPromptContribution permet à un fournisseur d’injecter des instructions d’invite système tenant compte du cache pour une famille de modèles. Préférez-le à l’ancien hook global au plugin before_prompt_build lorsque le comportement appartient à une famille de fournisseurs ou de modèles et doit préserver la séparation stable/dynamique du cache.
5

Ajouter des capacités supplémentaires (facultatif)

Étape 5 : ajouter des capacités supplémentaires

Un plugin de fournisseur peut enregistrer les plongements, la synthèse vocale, la transcription en temps réel, la voix en temps réel, la compréhension des médias, la génération d’images, la génération de vidéos, la récupération web et la recherche web parallèlement à l’inférence de texte. OpenClaw classe cela comme un plugin à capacités hybrides : le modèle recommandé pour les plugins d’entreprise (un plugin par fournisseur). Consultez Fonctionnement interne : propriété des capacités.Enregistrez chaque capacité dans register(api) avec votre appel api.registerProvider(...) existant. Sélectionnez uniquement les onglets dont vous avez besoin :
Utilisez assertOkOrThrowProviderError(...) pour les échecs HTTP du fournisseur afin que les plugins partagent la lecture plafonnée du corps des erreurs, l’analyse des erreurs JSON et les suffixes d’identifiant de requête.
6

Tester

Étape 6 : Tester

src/provider.test.ts

Publier sur ClawHub

Les Plugins de fournisseurs se publient de la même manière que n’importe quel autre Plugin de code externe :
clawhub skill publish <path> est une autre commande, destinée à publier un dossier de skill et non un paquet de Plugin ; ne l’utilisez pas ici.

Structure des fichiers

Référence de l’ordre du catalogue

catalog.order détermine le moment où votre catalogue est fusionné par rapport aux fournisseurs intégrés :

Étapes suivantes

Ressources connexes