Architecture interne des Plugin

​

Pipeline de chargement

1. découvrir les racines de plugins candidates
2. lire les manifestes de bundle natifs ou compatibles et les métadonnées de package
3. rejeter les candidats non sûrs
4. normaliser la configuration des plugins (plugins.enabled, allow, deny, entries, slots, load.paths)
5. décider de l’activation de chaque candidat
6. charger les modules natifs activés : les modules groupés compilés utilisent un chargeur natif ; le TypeScript source local tiers utilise le repli d’urgence Jiti
7. appeler les hooks natifs register(api) et collecter les enregistrements dans le registre des plugins
8. exposer le registre aux commandes/surfaces d’exécution

​

Comportement axé sur le manifeste

• identifier le plugin
• découvrir les canaux/Skills/schéma de configuration déclarés ou les capacités du bundle
• valider plugins.entries.<id>.config
• enrichir les libellés/espaces réservés de la Control UI
• afficher les métadonnées d’installation/catalogue
• préserver des descripteurs d’activation et de configuration peu coûteux sans charger le runtime du plugin

• le chargement CLI se limite aux plugins qui possèdent la commande principale demandée
• la configuration/résolution de plugin de canal se limite aux plugins qui possèdent l’identifiant de canal demandé
• la configuration/résolution runtime explicite de fournisseur se limite aux plugins qui possèdent l’identifiant de fournisseur demandé
• la planification du démarrage du Gateway utilise activation.onStartup pour les importations de démarrage explicites et les exclusions de démarrage ; les plugins sans métadonnées de démarrage ne se chargent que via des déclencheurs d’activation plus restreints

​

Frontière du cache de plugins

• PluginLoaderCacheState et les registres runtime actifs compatibles
• caches jiti/module et caches de chargeur de surface publique utilisés pour éviter d’importer plusieurs fois la même surface runtime
• caches du système de fichiers pour les artefacts de plugins installés
• maps de courte durée par appel pour la normalisation de chemins ou la résolution de doublons

• les résultats de découverte
• les registres de manifeste directs
• les registres de manifeste reconstruits depuis l’index des plugins installés
• la recherche de propriétaire de fournisseur, la suppression de modèle, la politique de fournisseur ou les métadonnées d’artefacts publics
• toute autre réponse dérivée du manifeste lorsqu’un manifeste modifié, un index installé ou un chemin de chargement devrait être visible à la prochaine lecture de métadonnées

​

Modèle de registre

• les enregistrements de plugins (identité, source, origine, statut, diagnostics)
• les outils
• les hooks hérités et les hooks typés
• les canaux
• les fournisseurs
• les gestionnaires RPC du Gateway
• les routes HTTP
• les registraires CLI
• les services en arrière-plan
• les commandes possédées par les plugins

• module de plugin -> enregistrement dans le registre
• runtime du cœur -> consommation du registre

​

Callbacks de liaison de conversation

export default {
  id: "my-plugin",
  register(api) {
    api.onConversationBindingResolved(async (event) => {
      if (event.status === "approved") {
        // A binding now exists for this plugin + conversation.
        console.log(event.binding?.conversationId);
        return;
      }

      // The request was denied; clear any local pending state.
      console.log(event.request.conversation.conversationId);
    });
  },
};

• status : "approved" ou "denied"
• decision : "allow-once", "allow-always" ou "deny"
• binding : la liaison résolue pour les demandes approuvées
• request : le résumé de la demande d’origine, l’indice de détachement, l’identifiant de l’expéditeur et les métadonnées de conversation

​

Hooks runtime des fournisseurs

• Métadonnées de manifeste pour une recherche peu coûteuse avant le runtime : setup.providers[].envVars, compatibilité obsolète providerAuthEnvVars, providerAuthAliases, providerAuthChoices et channelEnvVars.
• Hooks au moment de la configuration : catalog (discovery hérité) plus applyConfigDefaults.
• Hooks runtime : plus de 40 hooks facultatifs couvrant l’authentification, la résolution de modèle, l’encapsulation de flux, les niveaux de réflexion, la politique de relecture et les points de terminaison d’utilisation. Consultez la liste complète sous Ordre et utilisation des hooks.

​

Ordre et utilisation des hooks

​

Exemple de fournisseur

api.registerProvider({
  id: "example-proxy",
  label: "Example Proxy",
  auth: [],
  catalog: {
    order: "simple",
    run: async (ctx) => {
      const apiKey = ctx.resolveProviderApiKey("example-proxy").apiKey;
      if (!apiKey) {
        return null;
      }
      return {
        provider: {
          baseUrl: "https://proxy.example.com/v1",
          apiKey,
          api: "openai-completions",
          models: [{ id: "auto", name: "Auto" }],
        },
      };
    },
  },
  resolveDynamicModel: (ctx) => ({
    id: ctx.modelId,
    name: ctx.modelId,
    provider: "example-proxy",
    api: "openai-completions",
    baseUrl: "https://proxy.example.com/v1",
    reasoning: false,
    input: ["text"],
    cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
    contextWindow: 128000,
    maxTokens: 8192,
  }),
  prepareRuntimeAuth: async (ctx) => {
    const exchanged = await exchangeToken(ctx.apiKey);
    return {
      apiKey: exchanged.token,
      baseUrl: exchanged.baseUrl,
      expiresAt: exchanged.expiresAt,
    };
  },
  resolveUsageAuth: async (ctx) => {
    const auth = await ctx.resolveOAuthToken();
    return auth ? { token: auth.token } : null;
  },
  fetchUsageSnapshot: async (ctx) => {
    return await fetchExampleProxyUsage(ctx.token, ctx.timeoutMs, ctx.fetchFn);
  },
});

​

Exemples intégrés

​

Helpers d’exécution

const clip = await api.runtime.tts.textToSpeech({
  text: "Hello from OpenClaw",
  cfg: api.config,
});

const result = await api.runtime.tts.textToSpeechTelephony({
  text: "Hello from OpenClaw",
  cfg: api.config,
});

const voices = await api.runtime.tts.listVoices({
  provider: "elevenlabs",
  cfg: api.config,
});

• textToSpeech retourne la charge utile de sortie TTS normale du cœur pour les surfaces de fichier/note vocale.
• Utilise la configuration messages.tts du cœur et la sélection de fournisseur.
• Retourne un tampon audio PCM + le taux d’échantillonnage. Les plugins doivent rééchantillonner/encoder pour les fournisseurs.
• listVoices est facultatif par fournisseur. Utilisez-le pour les sélecteurs de voix ou les flux de configuration possédés par le fournisseur.
• Les listes de voix peuvent inclure des métadonnées plus riches comme la langue, le genre et des étiquettes de personnalité pour les sélecteurs conscients du fournisseur.
• OpenAI et ElevenLabs prennent en charge la téléphonie aujourd’hui. Microsoft ne la prend pas en charge.

api.registerSpeechProvider({
  id: "acme-speech",
  label: "Acme Speech",
  isConfigured: ({ config }) => Boolean(config.messages?.tts),
  synthesize: async (req) => {
    return {
      audioBuffer: Buffer.from([]),
      outputFormat: "mp3",
      fileExtension: ".mp3",
      voiceCompatible: false,
    };
  },
});

• Gardez la politique TTS, le repli et la livraison des réponses dans le cœur.
• Utilisez les fournisseurs de parole pour le comportement de synthèse possédé par le fournisseur.
• L’entrée Microsoft héritée edge est normalisée vers l’id de fournisseur microsoft.
• Le modèle de propriété préféré est orienté entreprise : un plugin fournisseur peut posséder les fournisseurs de texte, parole, image et médias futurs à mesure qu’OpenClaw ajoute ces contrats de capacité.

api.registerMediaUnderstandingProvider({
  id: "google",
  capabilities: ["image", "audio", "video"],
  describeImage: async (req) => ({ text: "..." }),
  transcribeAudio: async (req) => ({ text: "..." }),
  describeVideo: async (req) => ({ text: "..." }),
});

• Gardez l’orchestration, le repli, la configuration et le câblage des canaux dans le cœur.
• Gardez le comportement fournisseur dans le plugin de fournisseur.
• L’expansion additive doit rester typée : nouvelles méthodes facultatives, nouveaux champs de résultat facultatifs, nouvelles capacités facultatives.
• La génération vidéo suit déjà le même modèle :
  • le cœur possède le contrat de capacité et le helper d’exécution
  • les plugins fournisseurs enregistrent api.registerVideoGenerationProvider(...)
  • les plugins de fonctionnalité/canal consomment api.runtime.videoGeneration.*

const image = await api.runtime.mediaUnderstanding.describeImageFile({
  filePath: "/tmp/inbound-photo.jpg",
  cfg: api.config,
  agentDir: "/tmp/agent",
});

const video = await api.runtime.mediaUnderstanding.describeVideoFile({
  filePath: "/tmp/inbound-video.mp4",
  cfg: api.config,
});

const extraction = await api.runtime.mediaUnderstanding.extractStructuredWithModel({
  provider: "codex",
  model: "gpt-5.5",
  input: [
    {
      type: "image",
      buffer: receiptImageBuffer,
      fileName: "receipt.png",
      mime: "image/png",
    },
    { type: "text", text: "Use the printed fields as the source of truth." },
  ],
  instructions: "Return entities and searchable tags.",
  schemaName: "example.evidence",
  jsonSchema: {
    type: "object",
    properties: {
      entities: { type: "array", items: { type: "string" } },
      tags: { type: "array", items: { type: "string" } },
    },
  },
  cfg: api.config,
});

const { text } = await api.runtime.mediaUnderstanding.transcribeAudioFile({
  filePath: "/tmp/inbound-audio.ogg",
  cfg: api.config,
  // Optional when MIME cannot be inferred reliably:
  mime: "audio/ogg",
});

• api.runtime.mediaUnderstanding.* est la surface partagée préférée pour la compréhension d’image/audio/vidéo.
• extractStructuredWithModel(...) est la frontière destinée aux plugins pour l’extraction bornée, possédée par le fournisseur et centrée d’abord sur l’image. Incluez au moins une entrée image ; les entrées texte sont un contexte supplémentaire. les plugins produit possèdent leurs routes et schémas tandis qu’OpenClaw possède la frontière fournisseur/exécution.
• Utilise la configuration audio de compréhension multimédia du cœur (tools.media.audio) et l’ordre de repli des fournisseurs.
• Retourne { text: undefined } lorsqu’aucune sortie de transcription n’est produite (par exemple une entrée ignorée/non prise en charge).
• api.runtime.stt.transcribeAudioFile(...) reste un alias de compatibilité.

const result = await api.runtime.subagent.run({
  sessionKey: "agent:main:subagent:search-helper",
  message: "Expand this query into focused follow-up searches.",
  provider: "openai",
  model: "gpt-4.1-mini",
  deliver: false,
});

• provider et model sont des remplacements facultatifs par exécution, pas des changements persistants de session.
• OpenClaw n’honore ces champs de remplacement que pour les appelants de confiance.
• Pour les exécutions de repli possédées par un plugin, les opérateurs doivent accepter explicitement avec plugins.entries.<id>.subagent.allowModelOverride: true.
• Utilisez plugins.entries.<id>.subagent.allowedModels pour restreindre les plugins de confiance à des cibles canoniques provider/model spécifiques, ou "*" pour autoriser explicitement toute cible.
• Les exécutions de sous-agent de plugins non fiables fonctionnent toujours, mais les demandes de remplacement sont rejetées au lieu de se replier silencieusement.
• Les sessions de sous-agent créées par un plugin sont étiquetées avec l’id du plugin créateur. Le repli api.runtime.subagent.deleteSession(...) peut supprimer uniquement ces sessions possédées ; la suppression arbitraire de sessions exige toujours une requête Gateway à portée administrateur.

const providers = api.runtime.webSearch.listProviders({
  config: api.config,
});

const result = await api.runtime.webSearch.search({
  config: api.config,
  args: {
    query: "OpenClaw plugin runtime helpers",
    count: 5,
  },
});

• Gardez la sélection de fournisseur, la résolution des identifiants et la sémantique de requête partagée dans le cœur.
• Utilisez des fournisseurs de recherche web pour les transports de recherche propres aux fournisseurs.
• api.runtime.webSearch.* est la surface partagée préférée pour les plugins de fonctionnalité/canal qui ont besoin d’un comportement de recherche sans dépendre du wrapper de l’outil agent.

​

api.runtime.imageGeneration

const result = await api.runtime.imageGeneration.generate({
  config: api.config,
  args: { prompt: "A friendly lobster mascot", size: "1024x1024" },
});

const providers = api.runtime.imageGeneration.listProviders({
  config: api.config,
});

• generate(...) : générer une image en utilisant la chaîne de fournisseurs de génération d’images configurée.
• listProviders(...) : lister les fournisseurs de génération d’images disponibles et leurs capacités.

​

Routes HTTP Gateway

api.registerHttpRoute({
  path: "/acme/webhook",
  auth: "plugin",
  match: "exact",
  handler: async (_req, res) => {
    res.statusCode = 200;
    res.end("ok");
    return true;
  },
});

• path : chemin de route sous le serveur HTTP du Gateway.
• auth : requis. Utilisez "gateway" pour exiger l’authentification Gateway normale, ou "plugin" pour l’authentification/vérification de Webhook gérée par le plugin.
• match : facultatif. "exact" (par défaut) ou "prefix".
• replaceExisting : facultatif. Autorise le même plugin à remplacer son propre enregistrement de route existant.
• handler : renvoyez true lorsque la route a traité la requête.

• api.registerHttpHandler(...) a été supprimé et provoquera une erreur de chargement du plugin. Utilisez plutôt api.registerHttpRoute(...).
• Les routes de plugin doivent déclarer explicitement auth.
• Les conflits exacts path + match sont rejetés sauf si replaceExisting: true, et un plugin ne peut pas remplacer la route d’un autre plugin.
• Les routes qui se chevauchent avec différents niveaux auth sont rejetées. Gardez les chaînes de repli exact/prefix uniquement au même niveau d’authentification.
• Les routes auth: "plugin" ne reçoivent pas automatiquement les portées d’exécution opérateur. Elles servent aux Webhooks/vérifications de signature gérés par le plugin, pas aux appels d’aide Gateway privilégiés.
• Les routes auth: "gateway" s’exécutent dans une portée d’exécution de requête Gateway, mais cette portée est volontairement conservatrice :
  • l’authentification bearer par secret partagé (gateway.auth.mode = "token" / "password") garde les portées d’exécution des routes de plugin limitées à operator.write, même si l’appelant envoie x-openclaw-scopes
  • les modes HTTP avec identité de confiance (par exemple trusted-proxy ou gateway.auth.mode = "none" sur une entrée privée) honorent x-openclaw-scopes uniquement lorsque l’en-tête est explicitement présent
  • si x-openclaw-scopes est absent sur ces requêtes de route de plugin avec identité, la portée d’exécution revient à operator.write
• Règle pratique : ne supposez pas qu’une route de plugin authentifiée par Gateway est une surface d’administration implicite. Si votre route nécessite un comportement réservé aux administrateurs, exigez un mode d’authentification avec identité et documentez le contrat explicite de l’en-tête x-openclaw-scopes.

​

Chemins d’importation du SDK Plugin

• index.js — entrée de plugin intégré
• api.js — barrel d’aides/types
• runtime-api.js — barrel réservé à l’exécution
• setup-entry.js — entrée du plugin de configuration

​

Schémas des outils de message

• presentation pour les blocs de présentation sémantique (text, context, divider, buttons, select)
• delivery-pin pour les demandes de livraison épinglée

​

Résolution des cibles de canal

• messaging.inferTargetChatType({ to }) décide si une cible normalisée doit être traitée comme direct, group ou channel avant la recherche dans l’annuaire.
• messaging.targetResolver.looksLikeId(raw, normalized) indique au cœur si une entrée doit passer directement à une résolution de type identifiant au lieu d’une recherche dans l’annuaire.
• messaging.targetResolver.reservedLiterals liste les mots bruts qui sont des références de canal/session pour ce fournisseur. La résolution préserve les entrées d’annuaire configurées avant de rejeter les littéraux réservés, puis échoue fermement en cas d’absence dans l’annuaire.
• messaging.targetResolver.resolveTarget(...) est le repli du plugin lorsque le cœur a besoin d’une résolution finale possédée par le fournisseur après normalisation ou après une absence dans l’annuaire.
• messaging.resolveOutboundSessionRoute(...) possède la construction de route de session propre au fournisseur une fois une cible résolue.

• Utilisez inferTargetChatType pour les décisions de catégorie qui doivent se produire avant la recherche de pairs/groupes.
• Utilisez looksLikeId pour les vérifications « traiter ceci comme un identifiant de cible explicite/natif ».
• Utilisez resolveTarget pour le repli de normalisation propre au fournisseur, pas pour une recherche large dans l’annuaire.
• Gardez les identifiants natifs du fournisseur comme les identifiants de discussion, de fil, les JID, handles et identifiants de salon dans les valeurs target ou les paramètres propres au fournisseur, pas dans les champs SDK génériques.

​

Annuaires adossés à la configuration

• pairs DM pilotés par liste d’autorisation
• cartes de canaux/groupes configurées
• replis d’annuaire statiques limités à un compte

• filtrage des requêtes
• application des limites
• aides de déduplication/normalisation
• construction de ChannelDirectoryEntry[]

​

Catalogues de fournisseurs

• { provider } pour une entrée de fournisseur
• { providers } pour plusieurs entrées de fournisseur

• simple : fournisseurs simples pilotés par clé d’API ou variable d’environnement
• profile : fournisseurs qui apparaissent lorsque des profils d’authentification existent
• paired : fournisseurs qui synthétisent plusieurs entrées de fournisseur liées
• late : dernier passage, après les autres fournisseurs implicites

• discovery fonctionne encore comme alias hérité, mais émet un avertissement d’obsolescence
• si catalog et discovery sont tous deux enregistrés, OpenClaw utilise catalog
• augmentModelCatalog est obsolète ; les fournisseurs intégrés doivent publier les lignes supplémentaires via registerModelCatalogProvider

​

Inspection de canal en lecture seule

• resolveAccount(...) est le chemin d’exécution. Il est autorisé à supposer que les identifiants sont entièrement matérialisés et peut échouer rapidement lorsque des secrets requis sont manquants.
• Les chemins de commande en lecture seule tels que openclaw status, openclaw status --all, openclaw channels status, openclaw channels resolve, et les flux de réparation doctor/config ne doivent pas avoir besoin de matérialiser les identifiants d’exécution simplement pour décrire la configuration.

• Renvoyer uniquement un état de compte descriptif.
• Préserver enabled et configured.
• Inclure les champs de source/état des identifiants lorsque pertinent, comme :
  • tokenSource, tokenStatus
  • botTokenSource, botTokenStatus
  • appTokenSource, appTokenStatus
  • signingSecretSource, signingSecretStatus
• Vous n’avez pas besoin de renvoyer les valeurs brutes des jetons simplement pour signaler la disponibilité en lecture seule. Renvoyer tokenStatus: "available" (et le champ source correspondant) suffit pour les commandes de type statut.
• Utilisez configured_unavailable lorsqu’un identifiant est configuré via SecretRef mais indisponible dans le chemin de commande actuel.

​

Packs de packages

{
  "name": "my-pack",
  "openclaw": {
    "extensions": ["./src/safety.ts", "./src/tools.ts"],
    "setupEntry": "./src/setup-entry.ts"
  }
}

• l’enregistrement du canal lui-même
• toutes les routes HTTP qui doivent être disponibles avant que le Gateway commence à écouter
• toutes les méthodes, tous les outils ou services du Gateway qui doivent exister pendant cette même fenêtre

• singleAccountKeysToMove
• namedAccountPromotionKeys
• resolveSingleAccountPromotionTarget(...)

{
  "name": "@scope/my-channel",
  "openclaw": {
    "extensions": ["./index.ts"],
    "setupEntry": "./setup-entry.ts",
    "startup": {
      "deferConfiguredChannelFullLoadUntilAfterListen": true
    }
  }
}

​

Métadonnées du catalogue de canaux

{
  "name": "@openclaw/nextcloud-talk",
  "openclaw": {
    "extensions": ["./index.ts"],
    "channel": {
      "id": "nextcloud-talk",
      "label": "Nextcloud Talk",
      "selectionLabel": "Nextcloud Talk (self-hosted)",
      "docsPath": "/channels/nextcloud-talk",
      "docsLabel": "nextcloud-talk",
      "blurb": "Self-hosted chat via Nextcloud Talk webhook bots.",
      "order": 65,
      "aliases": ["nc-talk", "nc"]
    },
    "install": {
      "npmSpec": "@openclaw/nextcloud-talk",
      "localPath": "<bundled-plugin-local-path>",
      "defaultChoice": "npm"
    }
  }
}

• detailLabel : libellé secondaire pour des surfaces de catalogue/statut plus riches
• docsLabel : remplacer le texte du lien vers la documentation
• preferOver : ids de plugin/canal de priorité inférieure que cette entrée de catalogue doit dépasser
• selectionDocsPrefix, selectionDocsOmitLabel, selectionExtras : contrôles du texte de la surface de sélection
• markdownCapable : marque le canal comme compatible Markdown pour les décisions de formatage sortant
• exposure.configured : masquer le canal des surfaces de liste des canaux configurés lorsque défini sur false
• exposure.setup : masquer le canal des sélecteurs interactifs de configuration lorsque défini sur false
• exposure.docs : marquer le canal comme interne/privé pour les surfaces de navigation de la documentation
• showConfigured / showInSetup : alias hérités encore acceptés pour compatibilité ; préférez exposure
• quickstartAllowFrom : inscrire le canal au flux allowFrom de démarrage rapide standard
• forceAccountBinding : exiger une liaison explicite de compte même lorsqu’un seul compte existe
• preferSessionLookupForAnnounceTarget : préférer la recherche de session lors de la résolution des cibles d’annonce

• ~/.openclaw/mpm/plugins.json
• ~/.openclaw/mpm/catalog.json
• ~/.openclaw/plugins/catalog.json

​

Plugins de moteur de contexte

import { buildMemorySystemPromptAddition } from "openclaw/plugin-sdk/core";

export default function (api) {
  api.registerContextEngine("lossless-claw", (ctx) => ({
    info: { id: "lossless-claw", name: "Lossless Claw", ownsCompaction: true },
    async ingest() {
      return { ingested: true };
    },
    async assemble({ messages, availableTools, citationsMode }) {
      return {
        messages,
        estimatedTokens: 0,
        systemPromptAddition: buildMemorySystemPromptAddition({
          availableTools: availableTools ?? new Set(),
          citationsMode,
        }),
      };
    },
    async compact() {
      return { ok: true, compacted: false };
    },
  }));
}

import {
  buildMemorySystemPromptAddition,
  delegateCompactionToRuntime,
} from "openclaw/plugin-sdk/core";

export default function (api) {
  api.registerContextEngine("my-memory-engine", (ctx) => ({
    info: {
      id: "my-memory-engine",
      name: "My Memory Engine",
      ownsCompaction: false,
    },
    async ingest() {
      return { ingested: true };
    },
    async assemble({ messages, availableTools, citationsMode }) {
      return {
        messages,
        estimatedTokens: 0,
        systemPromptAddition: buildMemorySystemPromptAddition({
          availableTools: availableTools ?? new Set(),
          citationsMode,
        }),
      };
    },
    async compact(params) {
      return await delegateCompactionToRuntime(params);
    },
  }));
}

​

Ajouter une nouvelle capacité

1. définir le contrat du cœur Décidez quel comportement partagé le cœur doit posséder : politique, fallback, fusion de configuration, cycle de vie, sémantique visible par les canaux et forme du helper d’exécution.
2. ajouter des surfaces typées d’enregistrement/exécution de plugin Étendez OpenClawPluginApi et/ou api.runtime avec la plus petite surface typée utile de capacité.
3. câbler le cœur et les consommateurs de canal/fonctionnalité Les canaux et plugins de fonctionnalité doivent consommer la nouvelle capacité via le cœur, et non en important directement une implémentation fournisseur.
4. enregistrer les implémentations fournisseur Les plugins fournisseur enregistrent ensuite leurs backends auprès de la capacité.
5. ajouter une couverture de contrat Ajoutez des tests afin que la propriété et la forme d’enregistrement restent explicites au fil du temps.

​

Checklist des capacités

• types de contrat du cœur dans src/<capability>/types.ts
• helper d’exécution/runner du cœur dans src/<capability>/runtime.ts
• surface d’enregistrement de l’API de plugin dans src/plugins/types.ts
• câblage du registre de plugins dans src/plugins/registry.ts
• exposition d’exécution du plugin dans src/plugins/runtime/* lorsque des plugins de fonctionnalité/canal doivent la consommer
• helpers de capture/test dans src/test-utils/plugin-registration.ts
• assertions de propriété/contrat dans src/plugins/contracts/registry.ts
• documentation opérateur/plugin dans docs/

​

Modèle de capacité

// core contract
export type VideoGenerationProviderPlugin = {
  id: string;
  label: string;
  generateVideo: (req: VideoGenerationRequest) => Promise<VideoGenerationResult>;
};

// plugin API
api.registerVideoGenerationProvider({
  id: "openai",
  label: "OpenAI",
  async generateVideo(req) {
    return await generateOpenAiVideo(req);
  },
});

// shared runtime helper for feature/channel plugins
const clip = await api.runtime.videoGeneration.generate({
  prompt: "Show the robot walking through the lab.",
  cfg,
});

expect(findVideoGenerationProviderIdsForPlugin("openai")).toEqual(["openai"]);

• le noyau possède le contrat de capacité + l’orchestration
• les Plugins fournisseurs possèdent les implémentations fournisseur
• les Plugins de fonctionnalité/canal consomment les assistants d’exécution
• les tests de contrat gardent la propriété explicite

​

Associé

• Architecture des Plugins — modèle et formes de capacité publics
• Sous-chemins du SDK de Plugin
• Configuration du SDK de Plugin
• Création de Plugins