Vous découvrez les plugins OpenClaw ? Lisez d’abord Bien démarrer
pour découvrir la structure des paquets et la configuration du manifeste.
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 Utilisez
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
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 Si la résolution nécessite un appel réseau, utilisez
resolveDynamicModel :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 Familles de relecture actuellement disponibles :
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 flux actuellement disponibles :
SDK seams powering the family builders
SDK seams powering the family builders
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-shared—ProviderReplayFamily,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-stream—ProviderStreamFamily,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, notammentcreateOpenAICompatibleCompletionsThinkingOffWrapper,createPayloadPatchStreamWrapper,createPlainTextToolCallCompatWrapper,normalizeOpenAICompatibleReasoningPayload(...)etsetQwenChatTemplateThinking(...).openclaw/plugin-sdk/provider-tools—ProviderToolCompatFamily,buildProviderToolCompatFamilyHooks("deepseek" | "gemini" | "openai")et les assistants sous-jacents de schéma de fournisseur.
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).- Token exchange
- Custom headers
- Native transport identity
- Utilisation et facturation
Pour les fournisseurs qui nécessitent un échange de jeton avant chaque appel d’inférence :
Hooks courants des fournisseurs
Hooks courants des fournisseurs
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 :
normalizeConfigré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 hooknormalizeConfigpropre à Google est celui qui normalise les entrées de configurationgoogle/google-vertex/google-antigravity; il ne s’agit pas d’un mécanisme de repli distinct du cœur.resolveConfigApiKeyutilise 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 avecauth: "aws-sdk".resolveThinkingProfile(ctx)reçoit les valeurs sélectionnéesprovideretmodelId, l’indication facultativereasoningissue du catalogue fusionné, ainsi que les informations facultativescompatdu modèle fusionné. Utilisezcompatuniquement pour sélectionner l’interface ou le profil de réflexion du fournisseur.resolveSystemPromptContributionpermet à 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 pluginbefore_prompt_buildlorsque 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é dansregister(api) avec votre appel
api.registerProvider(...) existant. Sélectionnez uniquement les onglets dont
vous avez besoin :- Synthèse vocale (TTS)
- Transcription en temps réel
- Voix en temps réel
- Compréhension des médias
- Plongements vectoriels
- Génération d’images et de vidéos
- Récupération et recherche sur le Web
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
- Plugins de canal - si votre plugin fournit également un canal
- Environnement d’exécution du SDK - utilitaires
api.runtime(synthèse vocale, recherche, sous-agent) - Présentation du SDK - référence complète des importations par sous-chemin
- Fonctionnement interne des plugins - détails des hooks et exemples intégrés