Interna der Plugin-Architektur

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.

​

Lade-Pipeline

1. Kandidaten für Plugin-Wurzeln entdecken
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 entscheiden
6. aktivierte native Module laden: gebaute gebündelte Module verwenden einen nativen Loader; lokaler TypeScript-Quellcode von Drittanbietern verwendet den Notfall-Jiti-Fallback
7. native register(api)-Hooks aufrufen und Registrierungen in der Plugin-Registry sammeln
8. die Registry für Befehle/Runtime-Oberflächen bereitstellen

​

Manifest-zuerst-Verhalten

• das Plugin zu identifizieren
• deklarierte Channels/Skills/Konfigurationsschemata oder Bundle-Capabilities zu entdecken
• plugins.entries.<id>.config zu validieren
• Beschriftungen/Platzhalter der Control UI zu ergänzen
• Installations-/Katalogmetadaten anzuzeigen
• günstige Aktivierungs- und Setup-Deskriptoren zu bewahren, ohne die Plugin-Runtime zu laden

• CLI-Ladevorgänge werden auf Plugins eingegrenzt, die den angeforderten primären Befehl besitzen
• Channel-Setup/Plugin-Auflösung wird auf Plugins eingegrenzt, die die angeforderte Channel-ID besitzen
• explizite Provider-Setup-/Runtime-Auflösung wird auf Plugins eingegrenzt, die die angeforderte Provider-ID besitzen
• Gateway-Startplanung verwendet activation.onStartup für explizite Start-Imports und Start-Opt-outs; Plugins ohne Startmetadaten laden nur über engere Aktivierungsauslöser

​

Plugin-Cache-Grenze

• PluginLoaderCacheState und kompatible aktive Runtime-Registries
• jiti-/Modul-Caches und Public-Surface-Loader-Caches, die verwendet werden, um wiederholtes Importieren derselben Runtime-Oberfläche zu vermeiden
• Dateisystem-Caches für installierte Plugin-Artefakte
• kurzlebige Maps pro Aufruf für Pfadnormalisierung oder Duplikatauflösung

• Erkennungsergebnisse
• direkte Manifest-Registries
• Manifest-Registries, die aus dem installierten Plugin-Index rekonstruiert wurden
• Provider-Owner-Lookup, Modellunterdrückung, Provider-Policy oder Public-Artifact- Metadaten
• jede andere aus dem Manifest abgeleitete Antwort, bei der ein geändertes Manifest, ein installierter Index oder Ladepfad beim nächsten Metadaten-Lesen sichtbar sein sollte

​

Registry-Modell

• Plugin-Einträge (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-Runtime -> Registry-Nutzung

​

Conversation-Binding-Callbacks

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" oder "denied"
• decision: "allow-once", "allow-always" oder "deny"
• binding: das aufgelöste Binding für genehmigte Anfragen
• request: die ursprüngliche Anfragezusammenfassung, Detach-Hinweis, Sender-ID und Konversationsmetadaten

​

Provider-Runtime-Hooks

• Manifest-Metadaten für günstige Pre-Runtime-Lookups: setup.providers[].envVars, veraltete Kompatibilität providerAuthEnvVars, providerAuthAliases, providerAuthChoices und channelEnvVars.
• Config-Time-Hooks: catalog (Legacy discovery) plus applyConfigDefaults.
• Runtime-Hooks: mehr als 40 optionale Hooks für Authentifizierung, Modellauflösung, Stream-Wrapping, Denkstufen, Replay-Policy und Nutzungsendpunkte. Siehe die vollständige Liste unter Hook-Reihenfolge und Verwendung.

​

Hook-Reihenfolge und Verwendung

​

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

​

Runtime-Helfer

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-Ausgabepayload für Datei-/Sprachnotiz-Oberflächen zurück.
• Verwendet die Core-Konfiguration messages.tts und die Provider-Auswahl.
• Gibt PCM-Audiopuffer + Abtastrate zurück. Plugins müssen für Provider resamplen/codieren.
• listVoices ist je Provider optional. Verwenden Sie es für anbieterverwaltete Stimmauswahlen oder Einrichtungsabläufe.
• Stimmlisten können reichere Metadaten wie Spracheinstellung, Geschlecht und Persönlichkeits-Tags für Provider-bewusste Auswahlen enthalten.
• OpenAI und ElevenLabs unterstützen heute Telefonie. 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,
    };
  },
});

• Belassen Sie TTS-Richtlinie, Fallback und Antwortzustellung im Core.
• Verwenden Sie Speech-Provider für anbieterverwaltetes Syntheseverhalten.
• Die ältere Microsoft-edge-Eingabe wird auf die Provider-ID microsoft normalisiert.
• Das bevorzugte Besitzmodell ist unternehmensorientiert: Ein Anbieter-Plugin kann Text-, Speech-, Bild- und zukünftige Medien-Provider besitzen, wenn OpenClaw diese Fähigkeitsverträge hinzufügt.

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

• Belassen Sie Orchestrierung, Fallback, Konfiguration und Channel-Verdrahtung im Core.
• Belassen Sie Anbieterverhalten im Provider-Plugin.
• Additive Erweiterung sollte typisiert bleiben: neue optionale Methoden, neue optionale Ergebnisfelder, neue optionale Fähigkeiten.
• Videogenerierung folgt bereits demselben Muster:
  • Core besitzt den Fähigkeitsvertrag und den Runtime-Helfer
  • Anbieter-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 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.* ist die bevorzugte gemeinsame Oberfläche für Bild-/Audio-/Videoverstehen.
• extractStructuredWithModel(...) ist die Plugin-seitige Schnittstelle für begrenzte, Provider-eigene, bildzentrierte Extraktion. Fügen Sie mindestens eine Bildeingabe hinzu; Texteingaben sind ergänzender Kontext. Produkt-Plugins besitzen ihre Routen und Schemas, während OpenClaw die Provider-/Runtime-Grenze besitzt.
• Verwendet die Core-Audiokonfiguration für Medienverständnis (tools.media.audio) und die Provider-Fallback-Reihenfolge.
• Gibt { text: undefined } zurück, wenn keine Transkriptionsausgabe erzeugt wird (zum Beispiel bei übersprungener/nicht unterstützter Eingabe).
• api.runtime.stt.transcribeAudioFile(...) bleibt als Kompatibilitätsalias erhalten.

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 dauerhaften Sitzungsä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 zustimmen.
• Verwenden Sie plugins.entries.<id>.subagent.allowedModels, um vertrauenswürdige Plugins auf bestimmte kanonische provider/model-Ziele zu beschränken, oder "*", um jedes Ziel ausdrücklich zu erlauben.
• Subagent-Läufe nicht vertrauenswürdiger Plugins funktionieren weiterhin, aber Override-Anforderungen werden abgelehnt, statt stillschweigend zurückzufallen.
• Von Plugins erstellte Subagent-Sitzungen werden mit der erstellenden Plugin-ID markiert. Der Fallback api.runtime.subagent.deleteSession(...) darf nur diese eigenen Sitzungen löschen; beliebiges Löschen von Sitzungen erfordert weiterhin eine administrativ begrenzte Gateway-Anforderung.

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

• Belassen Sie Provider-Auswahl, Auflösung von Zugangsdaten und gemeinsame Anfragesemantik 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(...): generiert ein Bild mithilfe der konfigurierten Bildgenerierungs-Provider-Kette.
• listProviders(...): listet verfügbare Bildgenerierungs-Provider und ihre Fähigkeiten auf.

​

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-Authentifizierung zu verlangen, oder "plugin" für Plugin-verwaltete Authentifizierung/Webhook-Verifizierung.
• match: optional. "exact" (Standard) oder "prefix".
• replaceExisting: optional. Ermöglicht 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 Fehler beim Laden des Plugins. Verwenden Sie stattdessen api.registerHttpRoute(...).
• Plugin-Routen müssen auth explizit deklarieren.
• Exakte path + match-Konflikte werden abgelehnt, sofern nicht replaceExisting: true gesetzt ist, und ein Plugin kann nicht die Route eines anderen Plugins ersetzen.
• Überlappende Routen mit unterschiedlichen auth-Stufen werden abgelehnt. Halten Sie exact-/prefix-Fallthrough-Ketten nur auf derselben Authentifizierungsstufe.
• auth: "plugin"-Routen erhalten Operator-Laufzeit-Scopes nicht automatisch. Sie sind für Plugin-verwaltete Webhooks/Signaturprüfung gedacht, nicht für privilegierte Gateway-Hilfsaufrufe.
• auth: "gateway"-Routen laufen innerhalb eines Gateway-Anforderungs-Laufzeit-Scopes, aber dieser Scope ist absichtlich konservativ:
  • Shared-Secret-Bearer-Authentifizierung (gateway.auth.mode = "token" / "password") fixiert die Laufzeit-Scopes von Plugin-Routen auf operator.write, selbst wenn der Aufrufer x-openclaw-scopes sendet
  • vertrauenswürdige identitätstragende HTTP-Modi (zum Beispiel trusted-proxy oder gateway.auth.mode = "none" an einem privaten Ingress) berücksichtigen x-openclaw-scopes nur, wenn der Header explizit vorhanden ist
  • wenn x-openclaw-scopes bei solchen identitätstragenden Plugin-Routen-Anforderungen fehlt, fällt der Laufzeit-Scope auf operator.write zurück
• Praktische Regel: Gehen Sie nicht davon aus, dass eine Gateway-authentifizierte Plugin-Route implizit eine Admin-Oberfläche ist. Wenn Ihre Route Admin-exklusives Verhalten benötigt, verlangen Sie einen identitätstragenden Authentifizierungsmodus und dokumentieren Sie den expliziten Header-Vertrag für x-openclaw-scopes.

​

Plugin-SDK-Importpfade

• index.js — Einstieg für gebündelte Plugins
• api.js — Barrel für Helfer/Typen
• runtime-api.js — nur Laufzeit-Barrel
• setup-entry.js — Einstieg für Setup-Plugin

​

Message-Tool-Schemas

• presentation für semantische Darstellungsblöcke (text, context, divider, buttons, select)
• delivery-pin für angepinnte Zustellungsanforderungen

​

Channel-Zielauflösung

• messaging.inferTargetChatType({ to }) entscheidet, ob ein normalisiertes Ziel vor der Verzeichnissuche 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 die Verzeichnissuche zu verwenden.
• messaging.targetResolver.resolveTarget(...) ist der Plugin-Fallback, wenn der Core nach der Normalisierung oder nach einem Verzeichnisfehlschlag eine abschließende Provider-eigene Auflösung benötigt.
• messaging.resolveOutboundSessionRoute(...) übernimmt die Provider-spezifische Session- Routenerstellung, sobald ein Ziel aufgelöst ist.

• Verwenden Sie inferTargetChatType für Kategorieentscheidungen, die vor dem Suchen von Peers/Gruppen stattfinden sollen.
• Verwenden Sie looksLikeId für Prüfungen vom Typ „dies als explizite/native Ziel-ID behandeln“.
• Verwenden Sie resolveTarget für Provider-spezifischen Normalisierungs-Fallback, nicht für breite Verzeichnissuche.
• Halten Sie Provider-native IDs wie Chat-IDs, Thread-IDs, JIDs, Handles und Room- IDs innerhalb von target-Werten oder Provider-spezifischen Parametern, nicht in generischen SDK- Feldern.

​

Konfigurationsgestützte Verzeichnisse

• durch Allowlist gesteuerte DM-Peers
• konfigurierte Channel-/Gruppen-Zuordnungen
• kontoabhängige statische Verzeichnis-Fallbacks

• Abfragefilterung
• Anwendung von Limits
• Deduplizierungs-/Normalisierungshelfer
• Erstellen von ChannelDirectoryEntry[]

​

Provider-Kataloge

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

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

• discovery funktioniert weiterhin als Legacy-Alias, gibt aber eine Veraltungswarnung aus
• wenn sowohl catalog als auch discovery registriert sind, verwendet OpenClaw catalog
• augmentModelCatalog ist veraltet; gebündelte Provider sollten zusätzliche Zeilen über registerModelCatalogProvider veröffentlichen

​

Schreibgeschützte Channel-Inspektion

• resolveAccount(...) ist der Laufzeitpfad. Er darf annehmen, dass Anmeldedaten vollständig materialisiert sind, und kann schnell fehlschlagen, wenn erforderliche Secrets fehlen.
• Schreibgeschützte Befehlspfade wie openclaw status, openclaw status --all, openclaw channels status, openclaw channels resolve sowie Doctor-/Konfigurations- Reparaturabläufe sollten keine Laufzeit-Anmeldedaten materialisieren müssen, nur um Konfiguration zu beschreiben.

• Geben Sie nur beschreibenden Kontostatus zurück.
• Bewahren Sie enabled und configured bei.
• Fügen Sie bei Relevanz Felder für Quelle/Status der Anmeldedaten ein, etwa:
  • 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. tokenStatus: "available" zurückzugeben (und das passende Quellfeld) reicht für Status-artige Befehle aus.
• Verwenden Sie configured_unavailable, wenn Anmeldedaten über SecretRef konfiguriert, aber im aktuellen Befehlspfad nicht verfügbar sind.

​

Paket-Packs

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

• die Kanalregistrierung selbst
• alle HTTP-Routen, die verfügbar sein müssen, bevor der Gateway zu lauschen beginnt
• alle Gateway-Methoden, Tools oder Dienste, die in demselben Zeitfenster vorhanden sein müssen

• singleAccountKeysToMove
• namedAccountPromotionKeys
• resolveSingleAccountPromotionTarget(...)

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

​

Kanalkatalog-Metadaten

{
  "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: sekundäres Label für reichhaltigere Katalog-/Statusoberflächen
• docsLabel: Linktext für den Docs-Link überschreiben
• preferOver: Plugin-/Kanal-IDs mit niedrigerer Priorität, die dieser Katalogeintrag übertreffen soll
• selectionDocsPrefix, selectionDocsOmitLabel, selectionExtras: Kopiesteuerungen für Auswahloberflächen
• markdownCapable: markiert den Kanal als Markdown-fähig für Entscheidungen zur ausgehenden Formatierung
• exposure.configured: blendet den Kanal auf Oberflächen für konfigurierte Kanallisten aus, wenn auf false gesetzt
• exposure.setup: blendet den Kanal in interaktiven Setup-/Konfigurationsauswahlen aus, wenn auf false gesetzt
• exposure.docs: markiert den Kanal für Docs-Navigationsoberflächen als intern/privat
• showConfigured / showInSetup: ältere Aliasse, die aus Kompatibilitätsgründen weiterhin akzeptiert werden; bevorzugen Sie exposure
• quickstartAllowFrom: nimmt den Kanal in den standardmäßigen Quickstart-allowFrom-Flow auf
• forceAccountBinding: erfordert eine explizite Kontobindung, auch wenn nur ein Konto vorhanden ist
• preferSessionLookupForAnnounceTarget: bevorzugt Session-Lookup beim Auflösen von Ankündigungszielen

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

​

Kontext-Engine-Plugins

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

​

Eine neue Fähigkeit hinzufügen

1. Core-Vertrag definieren Entscheiden Sie, welches gemeinsame Verhalten der Core besitzen soll: Policy, Fallback, Konfigurationszusammenführung, Lebenszyklus, kanalbezogene Semantik und Form des Laufzeithelfers.
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 und Kanal-/Feature-Verbraucher verdrahten Kanäle und Feature-Plugins sollten die neue Fähigkeit über den Core konsumieren, nicht durch direkten Import einer Herstellerimplementierung.
4. Herstellerimplementierungen registrieren Hersteller-Plugins registrieren ihre Backends dann gegen die Fähigkeit.
5. Vertragsabdeckung hinzufügen Fügen Sie Tests hinzu, damit Besitz und Registrierungsform im Laufe der Zeit explizit bleiben.

​

Fähigkeiten-Checkliste

• Core-Vertragstypen in src/<capability>/types.ts
• Core-Runner-/Laufzeithelfer in src/<capability>/runtime.ts
• Plugin-API-Registrierungsoberfläche in src/plugins/types.ts
• Plugin-Registry-Verdrahtung in src/plugins/registry.ts
• Plugin-Laufzeitfreigabe in src/plugins/runtime/*, wenn Feature-/Kanal- Plugins sie konsumieren müssen
• Capture-/Testhelfer in src/test-utils/plugin-registration.ts
• Besitz-/Vertragsassertionen in src/plugins/contracts/registry.ts
• Operator-/Plugin-Docs in docs/

​

Fähigkeiten-Vorlage

// 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"]);

• der Core besitzt den Fähigkeitsvertrag und die Orchestrierung
• Hersteller-Plugins besitzen Herstellerimplementierungen
• Feature-/Kanal-Plugins konsumieren Laufzeithelfer
• Vertragstests halten den Besitz explizit

​

Verwandte Themen

• Plugin-Architektur — öffentliches Fähigkeitsmodell und Formen
• Plugin-SDK-Unterpfade
• Plugin-SDK-Setup
• Plugins erstellen