Plugin-Architektur-Interna

​

Lade-Pipeline

1. mögliche Plugin-Roots erkennen
2. native oder kompatible Bundle-Manifeste und Paketmetadaten lesen
3. unsichere Kandidaten ablehnen
4. Plugin-Konfiguration normalisieren (plugins.enabled, allow, deny, entries, slots, load.paths)
5. Aktivierung für jeden Kandidaten festlegen
6. aktivierte native Module laden: gebaute gebündelte Module verwenden einen nativen Loader; ungebaute native Plugins verwenden jiti
7. native register(api)-Hooks aufrufen und Registrierungen in der Plugin-Registry sammeln
8. die Registry für Befehle/Laufzeit-Oberflächen verfügbar machen

​

Manifest-first-Verhalten

• das Plugin zu identifizieren
• deklarierte Channels/Skills/Konfigurationsschema oder Bundle-Fähigkeiten zu erkennen
• plugins.entries.<id>.config zu validieren
• Labels/Platzhalter der Control UI anzureichern
• Installations-/Katalogmetadaten anzuzeigen
• günstige Aktivierungs- und Einrichtungsdeskriptoren zu bewahren, ohne die Plugin-Laufzeit zu laden

• Das CLI-Laden wird auf Plugins eingegrenzt, denen der angeforderte primäre Befehl gehört
• Channel-Setup/Plugin-Auflösung wird auf Plugins eingegrenzt, denen die angeforderte Channel-ID gehört
• explizite Provider-Setup-/Laufzeit-Auflösung wird auf Plugins eingegrenzt, denen die angeforderte Provider-ID gehört

​

Was der Loader zwischenspeichert

• Erkennungsergebnisse
• Manifest-Registry-Daten
• geladene Plugin-Registries

• Setzen Sie OPENCLAW_DISABLE_PLUGIN_DISCOVERY_CACHE=1 oder OPENCLAW_DISABLE_PLUGIN_MANIFEST_CACHE=1, um diese Caches zu deaktivieren.
• Passen Sie die Cache-Fenster mit OPENCLAW_PLUGIN_DISCOVERY_CACHE_MS und OPENCLAW_PLUGIN_MANIFEST_CACHE_MS an.

​

Registry-Modell

• Plugin-Datensätze (Identität, Quelle, Ursprung, Status, Diagnosen)
• Tools
• Legacy-Hooks und typisierte Hooks
• Channels
• Provider
• Gateway-RPC-Handler
• HTTP-Routen
• CLI-Registrare
• Hintergrunddienste
• Plugin-eigene Befehle

• Plugin-Modul -> Registry-Registrierung
• Core-Laufzeit -> Registry-Nutzung

​

Callbacks für Conversation-Bindings

export default {
  id: "my-plugin",
  register(api) {
    api.onConversationBindingResolved(async (event) => {
      if (event.status === "approved") {
        // Für dieses Plugin + diese Conversation existiert jetzt eine Bindung.
        console.log(event.binding?.conversationId);
        return;
      }

      // Die Anfrage wurde abgelehnt; lokalen Pending-Status bereinigen.
      console.log(event.request.conversation.conversationId);
    });
  },
};

• status: "approved" oder "denied"
• decision: "allow-once", "allow-always" oder "deny"
• binding: die aufgelöste Bindung für genehmigte Anfragen
• request: die ursprüngliche Anfragenzusammenfassung, Detach-Hinweis, Sender-ID und Conversation-Metadaten

​

Provider-Laufzeit-Hooks

• Manifest-Metadaten für günstige Lookup-Vorgänge vor der Laufzeit: providerAuthEnvVars, providerAuthAliases, providerAuthChoices und channelEnvVars.
• Hooks zur Konfigurationszeit: catalog (Legacy-discovery) plus applyConfigDefaults.
• Laufzeit-Hooks: mehr als 40 optionale Hooks für Auth, Modellauflösung, Stream-Wrapping, Thinking-Levels, Replay-Richtlinie und Usage-Endpunkte. Siehe die vollständige Liste unter Reihenfolge und Verwendung der Hooks.

​

Reihenfolge und Verwendung der Hooks

​

Provider-Beispiel

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);
  },
});

​

Integrierte Beispiele

​

Laufzeit-Helper

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 gibt die normale Core-TTS-Ausgabe-Payload für Datei-/Sprachnotiz-Oberflächen zurück.
• Verwendet die Core-Konfiguration messages.tts und die Provider-Auswahl.
• Gibt einen PCM-Audiopuffer + Sample-Rate zurück. Plugins müssen für Provider neu sampeln/kodieren.
• listVoices ist je nach Provider optional. Verwenden Sie es für provider-eigene Voice-Picker oder Setup-Flows.
• Voice-Listen können umfangreichere Metadaten wie Gebietsschema, Geschlecht und Personality-Tags für providerbewusste Picker enthalten.
• OpenAI und ElevenLabs unterstützen heute Telephony. Microsoft nicht.

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,
    };
  },
});

• Behalten Sie TTS-Richtlinie, Fallback und Antwortzustellung im Core.
• Verwenden Sie Speech-Provider für anbieterbezogenes Syntheseverhalten.
• Legacy-Microsoft-edge-Eingaben werden auf die Provider-ID microsoft normalisiert.
• Das bevorzugte Ownership-Modell ist unternehmensorientiert: Ein Vendor-Plugin kann Text-, Speech-, Bild- und künftige Medien-Provider besitzen, während OpenClaw diese Fähigkeitsverträge erweitert.

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

• Behalten Sie Orchestrierung, Fallback, Konfiguration und Channel-Verdrahtung im Core.
• Behalten Sie anbieterbezogenes Verhalten im Provider-Plugin.
• Additive Erweiterung sollte typisiert bleiben: neue optionale Methoden, neue optionale Ergebnisfelder, neue optionale Fähigkeiten.
• Die Videogenerierung folgt bereits demselben Muster:
  • der Core besitzt den Fähigkeitsvertrag und den Laufzeit-Helper
  • Vendor-Plugins registrieren api.registerVideoGenerationProvider(...)
  • Feature-/Channel-Plugins nutzen 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 { text } = await api.runtime.mediaUnderstanding.transcribeAudioFile({
  filePath: "/tmp/inbound-audio.ogg",
  cfg: api.config,
  // Optional, wenn der MIME-Typ nicht zuverlässig abgeleitet werden kann:
  mime: "audio/ogg",
});

• api.runtime.mediaUnderstanding.* ist die bevorzugte gemeinsame Oberfläche für Bild-/Audio-/Videoverständnis.
• Verwendet die Audio-Konfiguration des Core für Media-Understanding (tools.media.audio) und die Fallback-Reihenfolge der Provider.
• Gibt { text: undefined } zurück, wenn keine Transkriptionsausgabe erzeugt wird (zum Beispiel bei übersprungenen/nicht unterstützten Eingaben).
• api.runtime.stt.transcribeAudioFile(...) bleibt als Kompatibilitätsalias bestehen.

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 und model sind optionale Overrides pro Lauf, keine persistenten Session-Änderungen.
• OpenClaw berücksichtigt diese Override-Felder nur für vertrauenswürdige Aufrufer.
• Für Plugin-eigene Fallback-Läufe müssen Operatoren mit plugins.entries.<id>.subagent.allowModelOverride: true explizit zustimmen.
• Verwenden Sie plugins.entries.<id>.subagent.allowedModels, um vertrauenswürdige Plugins auf bestimmte kanonische Ziele provider/model zu beschränken, oder "*", um jedes Ziel explizit zuzulassen.
• Nicht vertrauenswürdige Plugin-Subagent-Läufe funktionieren weiterhin, aber Override-Anfragen werden abgelehnt, statt stillschweigend auf Fallback umzuschalten.

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,
  },
});

• Behalten Sie Provider-Auswahl, Auflösung der Zugangsdaten und gemeinsame Request-Semantik im Core.
• Verwenden Sie Websuche-Provider für anbieterspezifische Suchtransporte.
• api.runtime.webSearch.* ist die bevorzugte gemeinsame Oberfläche für Feature-/Channel-Plugins, die Suchverhalten benötigen, ohne vom Agent-Tool-Wrapper abzuhängen.

​

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(...): Ein Bild mit der konfigurierten Provider-Kette für Bildgenerierung erzeugen.
• listProviders(...): Verfügbare Provider für Bildgenerierung und deren Fähigkeiten auflisten.

​

Gateway-HTTP-Routen

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

• path: Routenpfad unter dem Gateway-HTTP-Server.
• auth: erforderlich. Verwenden Sie "gateway", um normale Gateway-Auth zu verlangen, oder "plugin" für Plugin-verwaltete Auth/Webhook-Verifizierung.
• match: optional. "exact" (Standard) oder "prefix".
• replaceExisting: optional. Erlaubt demselben Plugin, seine eigene vorhandene Routenregistrierung zu ersetzen.
• handler: gibt true zurück, wenn die Route die Anfrage verarbeitet hat.

• api.registerHttpHandler(...) wurde entfernt und verursacht einen Plugin-Ladefehler. Verwenden Sie stattdessen api.registerHttpRoute(...).
• Plugin-Routen müssen auth explizit deklarieren.
• Exakte Konflikte bei path + match werden abgelehnt, sofern nicht replaceExisting: true gesetzt ist, und ein Plugin kann keine Route eines anderen Plugins ersetzen.
• Überlappende Routen mit unterschiedlichen auth-Stufen werden abgelehnt. Halten Sie exact-/prefix-Fallthrough-Ketten nur auf derselben Auth-Stufe.
• Routen mit auth: "plugin" erhalten nicht automatisch Runtime-Scopes für Operatoren. Sie sind für Plugin-verwaltete Webhooks/Signaturverifizierung gedacht, nicht für privilegierte Gateway-Helper-Aufrufe.
• Routen mit auth: "gateway" laufen innerhalb eines Gateway-Request-Runtime-Scopes, aber dieser Scope ist absichtlich konservativ:
  • Shared-Secret-Bearer-Auth (gateway.auth.mode = "token" / "password") hält Runtime-Scopes für Plugin-Routen auf operator.write fest, selbst wenn der Aufrufer x-openclaw-scopes sendet
  • vertrauenswürdige HTTP-Modi mit Identitätsträgern (zum Beispiel trusted-proxy oder gateway.auth.mode = "none" bei privatem Ingress) berücksichtigen x-openclaw-scopes nur, wenn der Header explizit vorhanden ist
  • wenn x-openclaw-scopes bei solchen Plugin-Routenanfragen mit Identitätsträgern fehlt, fällt der Runtime-Scope auf operator.write zurück
• Praktische Regel: Gehen Sie nicht davon aus, dass eine per Gateway-auth geschützte Plugin-Route implizit eine Admin-Oberfläche ist. Wenn Ihre Route reines Admin-Verhalten benötigt, verlangen Sie einen HTTP-Modus mit Identitätsträgern und dokumentieren Sie den expliziten Header-Vertrag für x-openclaw-scopes.

​

Plugin-SDK-Importpfade

• index.js — Einstiegspunkt für gebündelte Plugins
• api.js — Barrel für Helper/Typen
• runtime-api.js — reines Laufzeit-Barrel
• setup-entry.js — Einstiegspunkt für Setup-Plugins

​

Message-Tool-Schemas

• presentation für semantische Darstellungsblöcke (text, context, divider, buttons, select)
• delivery-pin für Anfragen zur angehefteten Zustellung

​

Auflösung von Channel-Zielen

• messaging.inferTargetChatType({ to }) entscheidet, ob ein normalisiertes Ziel vor der Directory-Suche als direct, group oder channel behandelt werden soll.
• messaging.targetResolver.looksLikeId(raw, normalized) teilt dem Core mit, ob eine Eingabe direkt zur id-artigen Auflösung springen soll statt zur Directory-Suche.
• messaging.targetResolver.resolveTarget(...) ist der Plugin-Fallback, wenn der Core nach der Normalisierung oder nach einem Directory-Fehlschlag eine abschließende provider-eigene Auflösung benötigt.
• messaging.resolveOutboundSessionRoute(...) besitzt den Aufbau der provider-spezifischen Session- Route, sobald ein Ziel aufgelöst wurde.

• Verwenden Sie inferTargetChatType für Kategorieentscheidungen, die vor der Suche nach Peers/Gruppen erfolgen sollten.
• Verwenden Sie looksLikeId für Prüfungen im Stil „als explizite/native Ziel-ID behandeln“.
• Verwenden Sie resolveTarget als provider-spezifischen Normalisierungs-Fallback, nicht für breit angelegte Directory-Suche.
• Behalten Sie provider-native IDs wie Chat-IDs, Thread-IDs, JIDs, Handles und Raum- IDs in target-Werten oder provider-spezifischen Parametern, nicht in generischen SDK- Feldern.

​

Konfigurationsgestützte Directories

• durch Allowlist gesteuerte DM-Peers
• konfigurierte Channel-/Gruppenzuordnungen
• kontobezogene statische Directory-Fallbacks

• Query-Filterung
• Anwendung von Limits
• Deduping-/Normalisierungs-Helper
• Aufbau von ChannelDirectoryEntry[]

​

Provider-Kataloge

• { provider } für einen Provider-Eintrag
• { providers } für mehrere Provider-Einträge

• simple: einfache API-Key- oder env-gesteuerte Provider
• profile: Provider, die erscheinen, wenn Auth-Profile existieren
• paired: Provider, die mehrere zusammengehörige Provider-Einträge synthetisieren
• late: letzter Durchlauf, nach anderen impliziten Providern

• discovery funktioniert weiterhin als Legacy-Alias
• wenn sowohl catalog als auch discovery registriert sind, verwendet OpenClaw catalog

​

Schreibgeschützte Channel-Inspektion

• resolveAccount(...) ist der Laufzeitpfad. Er darf annehmen, dass Zugangsdaten vollständig materialisiert sind, und kann schnell fehlschlagen, wenn erforderliche Secrets fehlen.
• Schreibgeschützte Befehlswege wie openclaw status, openclaw status --all, openclaw channels status, openclaw channels resolve und Doctor-/Config- Repair-Flows sollten Laufzeit-Zugangsdaten nicht materialisieren müssen, nur um die Konfiguration zu beschreiben.

• Geben Sie nur beschreibenden Kontostatus zurück.
• Behalten Sie enabled und configured bei.
• Schließen Sie relevante Felder für Quelle/Status von Zugangsdaten ein, zum Beispiel:
  • tokenSource, tokenStatus
  • botTokenSource, botTokenStatus
  • appTokenSource, appTokenStatus
  • signingSecretSource, signingSecretStatus
• Sie müssen keine rohen Token-Werte zurückgeben, nur um schreibgeschützte Verfügbarkeit zu melden. Die Rückgabe von tokenStatus: "available" (und dem passenden Quellfeld) reicht für Befehle im Stil von Status aus.
• Verwenden Sie configured_unavailable, wenn Zugangsdaten über SecretRef konfiguriert, aber im aktuellen Befehlsweg nicht verfügbar sind.

​

Paket-Packs

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

• die Channel-Registrierung selbst
• alle HTTP-Routen, die verfügbar sein müssen, bevor das Gateway beginnt zuzuhören
• alle Gateway-Methoden, Tools oder Dienste, die in diesem selben Zeitraum vorhanden sein müssen

• singleAccountKeysToMove
• namedAccountPromotionKeys
• resolveSingleAccountPromotionTarget(...)

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

​

Channel-Katalogmetadaten

{
  "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 über Nextcloud-Talk-Webhook-Bots.",
      "order": 65,
      "aliases": ["nc-talk", "nc"]
    },
    "install": {
      "npmSpec": "@openclaw/nextcloud-talk",
      "localPath": "<bundled-plugin-local-path>",
      "defaultChoice": "npm"
    }
  }
}

• detailLabel: sekundäres Label für umfangreichere Katalog-/Statusoberflächen
• docsLabel: überschreibt den Linktext für den Docs-Link
• preferOver: Plugin-/Channel-IDs mit geringerer Priorität, die dieser Katalogeintrag übertreffen soll
• selectionDocsPrefix, selectionDocsOmitLabel, selectionExtras: Textsteuerungen für die Auswahloberfläche
• markdownCapable: markiert den Channel als Markdown-fähig für Entscheidungen zur ausgehenden Formatierung
• exposure.configured: blendet den Channel aus Oberflächen zur Auflistung konfigurierter Channels aus, wenn auf false gesetzt
• exposure.setup: blendet den Channel aus interaktiven Setup-/Configure-Auswahlfeldern aus, wenn auf false gesetzt
• exposure.docs: markiert den Channel für Docs-Navigationsoberflächen als intern/privat
• showConfigured / showInSetup: Legacy-Aliasse werden aus Kompatibilitätsgründen weiterhin akzeptiert; bevorzugen Sie exposure
• quickstartAllowFrom: aktiviert für den Channel den standardmäßigen Quickstart-Flow allowFrom
• forceAccountBinding: verlangt explizites Account-Binding, auch wenn nur ein Konto existiert
• preferSessionLookupForAnnounceTarget: bevorzugt Session-Lookup beim Auflösen von Ankündigungszielen

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

​

Context-Engine-Plugins

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

export default function (api) {
  api.registerContextEngine("lossless-claw", () => ({
    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", () => ({
    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);
    },
  }));
}

​

Hinzufügen einer neuen Fähigkeit

1. den Core-Vertrag definieren Entscheiden Sie, welches gemeinsame Verhalten der Core besitzen soll: Richtlinie, Fallback, Konfigurationszusammenführung, Lifecycle, channelseitige Semantik und Form des Laufzeit-Helpers.
2. typisierte Plugin-Registrierungs-/Laufzeitoberflächen hinzufügen Erweitern Sie OpenClawPluginApi und/oder api.runtime um die kleinste nützliche typisierte Fähigkeitsoberfläche.
3. Core + Verbraucher in Channels/Features verdrahten Channels und Feature-Plugins sollten die neue Fähigkeit über den Core nutzen, nicht indem sie direkt eine Vendor-Implementierung importieren.
4. Vendor-Implementierungen registrieren Vendor-Plugins registrieren dann ihre Backends für die Fähigkeit.
5. Vertragsabdeckung hinzufügen Fügen Sie Tests hinzu, damit Eigentümerschaft und Registrierungsform im Lauf der Zeit explizit bleiben.

​

Checkliste für Fähigkeiten

• Core-Vertragstypen in src/<capability>/types.ts
• Core-Runner/Laufzeit-Helper in src/<capability>/runtime.ts
• Plugin-API-Registrierungsoberfläche in src/plugins/types.ts
• Plugin-Registry-Verdrahtung in src/plugins/registry.ts
• Plugin-Laufzeit-Exponierung in src/plugins/runtime/*, wenn Feature-/Channel- Plugins sie nutzen müssen
• Capture-/Test-Helper in src/test-utils/plugin-registration.ts
• Assertions für Eigentümerschaft/Vertrag in src/plugins/contracts/registry.ts
• Operator-/Plugin-Dokumentation in docs/

​

Vorlage für Fähigkeiten

// Core-Vertrag
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);
  },
});

// gemeinsamer Laufzeit-Helper für Feature-/Channel-Plugins
const clip = await api.runtime.videoGeneration.generate({
  prompt: "Show the robot walking through the lab.",
  cfg,
});

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

• der Core besitzt den Fähigkeitsvertrag + die Orchestrierung
• Vendor-Plugins besitzen Vendor-Implementierungen
• Feature-/Channel-Plugins nutzen Laufzeit-Helper
• Vertragstests halten Eigentümerschaft explizit

​

Verwandt

• Plugin architecture — öffentliches Fähigkeitsmodell und Formen
• Plugin SDK subpaths
• Plugin SDK setup
• Building plugins