Points d’entrée de Plugin
Chaque plugin exporte un objet d’entrée par défaut. Le SDK fournit trois helpers pour les créer. Pour les plugins installés,package.json doit orienter le chargement à l’exécution vers le
JavaScript compilé lorsqu’il est disponible :
extensions et setupEntry restent des points d’entrée source valides pour le développement
en espace de travail et en checkout git. runtimeExtensions et runtimeSetupEntry sont préférés
lorsqu’OpenClaw charge un package installé et permettent aux packages npm d’éviter la compilation
TypeScript à l’exécution. Si un package installé ne déclare qu’un point d’entrée source TypeScript,
OpenClaw utilisera un homologue compilé dist/*.js correspondant lorsqu’il existe, puis reviendra au source TypeScript.
Tous les chemins de point d’entrée doivent rester à l’intérieur du répertoire du package plugin. Les points d’entrée à l’exécution
et les homologues JavaScript compilés inférés ne rendent pas valide un chemin source extensions ou
setupEntry qui s’échappe du package.
definePluginEntry
Import : openclaw/plugin-sdk/plugin-entry
Pour les plugins de fournisseur, plugins d’outils, plugins de hook, et tout ce qui n’est pas
un canal de messagerie.
| Champ | Type | Requis | Par défaut |
|---|---|---|---|
id | string | Oui | — |
name | string | Oui | — |
description | string | Oui | — |
kind | string | Non | — |
configSchema | OpenClawPluginConfigSchema | () => OpenClawPluginConfigSchema | Non | Schéma d’objet vide |
register | (api: OpenClawPluginApi) => void | Oui | — |
iddoit correspondre à votre manifesteopenclaw.plugin.json.kindest destiné aux emplacements exclusifs :"memory"ou"context-engine".configSchemapeut être une fonction pour une évaluation paresseuse.- OpenClaw résout et met en cache ce schéma au premier accès, de sorte que les constructeurs de schéma coûteux ne s’exécutent qu’une seule fois.
defineChannelPluginEntry
Import : openclaw/plugin-sdk/channel-core
Encapsule definePluginEntry avec un câblage spécifique aux canaux. Appelle automatiquement
api.registerChannel({ plugin }), expose une couture facultative de métadonnées CLI d’aide racine, et contrôle registerFull selon le mode d’enregistrement.
| Champ | Type | Requis | Par défaut |
|---|---|---|---|
id | string | Oui | — |
name | string | Oui | — |
description | string | Oui | — |
plugin | ChannelPlugin | Oui | — |
configSchema | OpenClawPluginConfigSchema | () => OpenClawPluginConfigSchema | Non | Schéma d’objet vide |
setRuntime | (runtime: PluginRuntime) => void | Non | — |
registerCliMetadata | (api: OpenClawPluginApi) => void | Non | — |
registerFull | (api: OpenClawPluginApi) => void | Non | — |
setRuntimeest appelé pendant l’enregistrement afin que vous puissiez stocker la référence d’exécution (généralement viacreatePluginRuntimeStore). Il est ignoré pendant la capture des métadonnées CLI.registerCliMetadatas’exécute à la fois pendantapi.registrationMode === "cli-metadata"etapi.registrationMode === "full". Utilisez-le comme emplacement canonique pour les descripteurs CLI appartenant au canal afin que l’aide racine reste non activante tout en conservant la compatibilité avec l’enregistrement normal des commandes CLI lors des chargements complets de plugin.registerFullne s’exécute que lorsqueapi.registrationMode === "full". Il est ignoré pendant le chargement configuration initiale uniquement.- Comme
definePluginEntry,configSchemapeut être une fabrique paresseuse et OpenClaw met en cache le schéma résolu au premier accès. - Pour les commandes CLI racine appartenant au plugin, préférez
api.registerCli(..., { descriptors: [...] })lorsque vous voulez que la commande reste chargée paresseusement sans disparaître de l’arbre d’analyse de la CLI racine. Pour les plugins de canal, préférez enregistrer ces descripteurs depuisregisterCliMetadata(...)et gardezregisterFull(...)centré sur le travail réservé à l’exécution. - Si
registerFull(...)enregistre aussi des méthodes RPC Gateway, gardez-les sur un préfixe propre au plugin. Les espaces de noms d’administration centraux réservés (config.*,exec.approvals.*,wizard.*,update.*) sont toujours forcés versoperator.admin.
defineSetupPluginEntry
Import : openclaw/plugin-sdk/channel-core
Pour le fichier léger setup-entry.ts. Renvoie uniquement { plugin } sans
câblage d’exécution ni CLI.
defineSetupPluginEntry(...) aux familles de helpers de configuration initiale étroites :
openclaw/plugin-sdk/setup-runtimepour les helpers de configuration initiale sûrs à l’exécution tels que les adaptateurs de patch de configuration initiale import-safe, la sortie de note de recherche,promptResolvedAllowFrom,splitSetupEntries, et les proxys de configuration initiale déléguésopenclaw/plugin-sdk/channel-setuppour les surfaces de configuration initiale à installation facultativeopenclaw/plugin-sdk/setup-toolspour les helpers CLI/archive/docs de configuration initiale et d’installation
defineBundledChannelSetupEntry(...) depuis
openclaw/plugin-sdk/channel-entry-contract à la place. Ce contrat permet au
point d’entrée de configuration initiale de conserver des exportations plugin/secrets sûres pour la configuration initiale tout en exposant un
setter d’exécution :
Mode d’enregistrement
api.registrationMode indique à votre plugin comment il a été chargé :
| Mode | Quand | Que faut-il enregistrer |
|---|---|---|
"full" | Démarrage normal du Gateway | Tout |
"setup-only" | Canal désactivé/non configuré | Enregistrement du canal uniquement |
"setup-runtime" | Flux de configuration initiale avec exécution disponible | Enregistrement du canal plus seulement l’exécution légère nécessaire avant le chargement du point d’entrée complet |
"cli-metadata" | Aide racine / capture de métadonnées CLI | Descripteurs CLI uniquement |
defineChannelPluginEntry gère automatiquement cette séparation. Si vous utilisez
definePluginEntry directement pour un canal, vérifiez vous-même le mode :
"setup-runtime" comme la fenêtre où les surfaces de démarrage configuration initiale uniquement doivent
exister sans réentrer dans l’exécution complète du canal intégré. Les bons cas d’usage sont
l’enregistrement du canal, les routes HTTP sûres pour la configuration initiale, les méthodes Gateway sûres pour la configuration initiale, et
les helpers de configuration initiale délégués. Les services lourds en arrière-plan, les enregistreurs CLI, et
les initialisations de SDK fournisseur/client doivent toujours rester dans "full".
Pour les enregistreurs CLI en particulier :
- utilisez
descriptorslorsque l’enregistreur possède une ou plusieurs commandes racine et que vous voulez qu’OpenClaw charge paresseusement le vrai module CLI à la première invocation - assurez-vous que ces descripteurs couvrent chaque racine de commande de premier niveau exposée par l’ enregistreur
- utilisez
commandsseul uniquement pour les chemins de compatibilité eager
Formes de plugin
OpenClaw classe les plugins chargés selon leur comportement d’enregistrement :| Forme | Description |
|---|---|
| plain-capability | Un type de capacité (par ex. fournisseur uniquement) |
| hybrid-capability | Plusieurs types de capacité (par ex. fournisseur + speech) |
| hook-only | Hooks uniquement, aucune capacité |
| non-capability | Outils/commandes/services mais aucune capacité |
openclaw plugins inspect <id> pour voir la forme d’un plugin.
Liens associés
- Vue d’ensemble du SDK — API d’enregistrement et référence des sous-chemins
- Helpers d’exécution —
api.runtimeetcreatePluginRuntimeStore - Configuration initiale et configuration — manifeste, point d’entrée de configuration initiale, chargement différé
- Plugins de canal — construction de l’objet
ChannelPlugin - Plugins de fournisseur — enregistrement des fournisseurs et hooks