Fonctionnement interne de l’architecture Plugin

Documentation Index

Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

​

Pipeline de chargement

1. découvrir les racines candidates de Plugins
2. lire les manifests de bundles 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 construits utilisent un chargeur natif ; le code source TypeScript local tiers utilise le repli d’urgence Jiti
7. appeler les hooks natifs register(api) et collecter les enregistrements dans le registre de Plugins
8. exposer le registre aux commandes/surfaces d’exécution

​

Comportement centré sur le manifest

• identifier le Plugin
• découvrir les canaux/Skills/schémas 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 l’interface de contrôle
• afficher les métadonnées d’installation/catalogue
• préserver 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 résolution de configuration/plugin de canal se limite aux Plugins qui possèdent l’identifiant de canal demandé
• la résolution explicite de configuration/runtime 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 explicites au démarrage et les exclusions de démarrage ; les Plugins sans métadonnées de démarrage ne se chargent que par des déclencheurs d’activation plus ciblés

​

Limite du cache des Plugins

• PluginLoaderCacheState et les registres runtime actifs compatibles
• caches jiti/module et caches de chargeur de surface publique utilisés pour éviter d’importer la même surface runtime à répétition
• caches de système de fichiers pour les artefacts de Plugins installés
• maps éphémères par appel pour la normalisation de chemins ou la résolution de doublons

• les résultats de découverte
• les registres de manifests directs
• les registres de manifests reconstruits à partir de l’index des Plugins installés
• la recherche de propriétaire de fournisseur, la suppression de modèles, la politique de fournisseur ou les métadonnées d’artefact public
• toute autre réponse dérivée d’un manifest lorsqu’un manifest 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 bureaux d’enregistrement CLI
• les services d’arrière-plan
• les commandes possédées par des 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’indication de détachement, l’identifiant de l’expéditeur et les métadonnées de conversation

​

Hooks runtime de fournisseur

• Métadonnées de manifest pour une recherche peu coûteuse avant runtime : setup.providers[].envVars, compatibilité obsolète providerAuthEnvVars, providerAuthAliases, providerAuthChoices et channelEnvVars.
• Hooks au moment de la configuration : catalog (hérité discovery) plus applyConfigDefaults.
• Hooks runtime : plus de 40 hooks facultatifs couvrant l’authentification, la résolution de modèles, l’enveloppement de flux, les niveaux de réflexion, la politique de relecture et les endpoints 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

​

Assistants 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 renvoie la charge utile TTS principale normale pour les surfaces fichier/note vocale.
• Utilise la configuration principale messages.tts et la sélection de fournisseur.
• Renvoie un tampon audio PCM + une fréquence d’échantillonnage. Les Plugins doivent rééchantillonner/encoder pour les fournisseurs.
• listVoices est optionnel selon le 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 telles que la locale, le genre et les tags 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 stratégie TTS, le repli et la livraison des réponses dans le cœur.
• Utilisez les fournisseurs de synthèse vocale 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, de synthèse vocale, d’image et de futurs médias à 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 du fournisseur dans le Plugin fournisseur.
• L’expansion additive doit rester typée : nouvelles méthodes optionnelles, nouveaux champs de résultat optionnels, nouvelles capacités optionnelles.
• La génération vidéo suit déjà le même modèle :
  • le cœur possède le contrat de capacité et l’assistant 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’images/audio/vidéo.
• extractStructuredWithModel(...) est le seam exposé aux Plugins pour l’extraction bornée image-first possédée par le fournisseur. Incluez au moins une entrée image ; les entrées texte fournissent un contexte supplémentaire. les Plugins produit possèdent leurs routes et schémas, tandis qu’OpenClaw possède la frontière fournisseur/runtime.
• Utilise la configuration audio de compréhension média du cœur (tools.media.audio) et l’ordre de repli des fournisseurs.
• Renvoie { text: undefined } lorsqu’aucune sortie de transcription n’est produite (par exemple 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 optionnels propres à l’exécution, pas des changements de session persistants.
• 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 explicitement l’autoriser 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 n’importe quelle cible.
• Les exécutions de sous-agent de Plugin non approuvé fonctionnent toujours, mais les demandes de remplacement sont rejetées au lieu de revenir silencieusement en arrière.
• Les sessions de sous-agent créées par un Plugin sont taguées avec l’id du Plugin créateur. Le repli api.runtime.subagent.deleteSession(...) ne peut supprimer que ces sessions possédées ; la suppression arbitraire de session nécessite toujours une requête Gateway avec 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 au fournisseur.
• 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 de l’enveloppe d’outil d’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ère une image en utilisant la chaîne de fournisseurs de génération d’images configurée.
• listProviders(...) : liste 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 Webhook gérée par le Plugin.
• match : optionnel. "exact" (par défaut) ou "prefix".
• replaceExisting : optionnel. Permet au même Plugin de remplacer son propre enregistrement de route existant.
• handler : renvoie true lorsque la route a traité la requête.

• api.registerHttpHandler(...) a été supprimé et provoquera une erreur de chargement de plugin. Utilisez api.registerHttpRoute(...) à la place.
• 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 des niveaux auth différents sont rejetées. Conservez 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 de l’opérateur. Elles sont destinées aux webhooks gérés par le plugin et à la vérification de signature, pas aux appels privilégiés aux assistants Gateway.
• 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") maintient 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 de confiance portant une identité (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 routes de plugin portant une identité, la portée d’exécution revient à operator.write
• Règle pratique : ne supposez pas qu’une route de plugin avec authentification Gateway constitue une surface d’administration implicite. Si votre route nécessite un comportement réservé à l’administration, exigez un mode d’authentification portant une identité et documentez le contrat explicite de l’en-tête x-openclaw-scopes.

​

Chemins d’importation du SDK de Plugin

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

​

Schémas des outils de message

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

​

Résolution de la cible 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.resolveTarget(...) est le repli du plugin lorsque le cœur a besoin d’une résolution finale détenue par le fournisseur après normalisation ou après un échec dans l’annuaire.
• messaging.resolveOutboundSessionRoute(...) possède la construction des routes de session propre au fournisseur une fois qu’une cible est résolue.

• Utilisez inferTargetChatType pour les décisions de catégorie qui doivent avoir lieu avant la recherche de pairs/groupes.
• Utilisez looksLikeId pour les vérifications « traiter ceci comme un identifiant 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 au fournisseur comme les identifiants de chat, les identifiants de fil, les JID, les handles et les identifiants de salle dans les valeurs target ou les paramètres propres au fournisseur, pas dans les champs SDK génériques.

​

Annuaires appuyés par la configuration

• des pairs DM pilotés par allowlist
• des correspondances de canaux/groupes configurées
• des replis d’annuaire statiques limités au compte

• filtrage des requêtes
• application des limites
• assistants 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é API ou env
• 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 groupé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 les secrets requis sont manquants.
• Les chemins de commande en lecture seule comme openclaw status, openclaw status --all, openclaw channels status, openclaw channels resolve, et les flux doctor/config repair ne doivent pas avoir à matérialiser les identifiants d’exécution simplement pour décrire la configuration.

• Renvoie uniquement un état descriptif du compte.
• Préserve enabled et configured.
• Inclut les champs de source/statut des identifiants lorsque cela est pertinent, comme :
  • tokenSource, tokenStatus
  • botTokenSource, botTokenStatus
  • appTokenSource, appTokenStatus
  • signingSecretSource, signingSecretStatus
• Vous n’avez pas besoin de renvoyer les valeurs brutes de jeton simplement pour signaler la disponibilité en lecture seule. Renvoyer tokenStatus: "available" (et le champ de 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, 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 de documentation
• preferOver : ids de plugins/canaux de priorité inférieure que cette entrée de catalogue doit devancer
• selectionDocsPrefix, selectionDocsOmitLabel, selectionExtras : contrôles de texte de la surface de sélection
• markdownCapable : marque le canal comme compatible Markdown pour les décisions de mise en forme sortante
• exposure.configured : masquer le canal des surfaces de liste des canaux configurés lorsque défini à false
• exposure.setup : masquer le canal des sélecteurs interactifs de configuration lorsque défini à false
• exposure.docs : marquer le canal comme interne/privé pour les surfaces de navigation de documentation
• showConfigured / showInSetup : alias hérités encore acceptés pour la compatibilité ; préférez exposure
• quickstartAllowFrom : inscrire le canal au flux standard de démarrage rapide allowFrom
• 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, repli, fusion de configuration, cycle de vie, sémantique côté canal et forme de l’assistant de runtime.
2. ajouter des surfaces typées d’enregistrement/runtime de plugin Étendez OpenClawPluginApi et/ou api.runtime avec la plus petite surface de capacité typée utile.
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 pour que la propriété et la forme d’enregistrement restent explicites au fil du temps.

​

Liste de vérification des capacités

• types de contrat du cœur dans src/<capability>/types.ts
• assistant d’exécution/runtime du cœur dans src/<capability>/runtime.ts
• surface d’enregistrement de l’API plugin dans src/plugins/types.ts
• câblage du registre de plugins dans src/plugins/registry.ts
• exposition au runtime des plugins dans src/plugins/runtime/* lorsque des plugins de fonctionnalité/canal doivent la consommer
• assistants 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 cœur possède le contrat de capacité + l’orchestration
• les plugins fournisseur possèdent les implémentations fournisseur
• les plugins de fonctionnalité/canal consomment les assistants de runtime
• les tests de contrat gardent la propriété explicite

​

Associé

• Architecture des plugins — modèle et formes publics des capacités
• Sous-chemins du SDK de plugin
• Configuration du SDK de plugin
• Créer des plugins