Plugin-SDK-Migration

OpenClaw hat eine umfassende Abwärtskompatibilitätsschicht durch eine moderne Plugin- Architektur ersetzt, die aus kleinen, fokussierten Imports aufgebaut ist. Wenn Ihr Plugin vor dieser Änderung entstand, führt dieser Leitfaden es zu den aktuellen Verträgen über.

Was sich geändert hat

Mehrere sehr weit gefasste Import-Oberflächen ermöglichten Plugins früher den Zugriff auf fast alles über einen einzigen Einstiegspunkt:

• openclaw/plugin-sdk und openclaw/plugin-sdk/compat – exportierten Dutzende Hilfsfunktionen erneut, während das fokussierte SDK entwickelt wurde. Beide Wurzeln wurden inzwischen entfernt; importieren Sie stattdessen einen dokumentierten Unterpfad.
• openclaw/plugin-sdk/infra-runtime – ein umfassendes Barrel, das System- ereignisse, Heartbeat-Zustand, Zustellwarteschlangen, Fetch-/Proxy-Hilfsfunktionen, Dateihilfen, Genehmigungstypen und nicht zusammengehörige Dienstprogramme vermischte.
• openclaw/plugin-sdk/config-runtime – ein umfassendes Konfigurations-Barrel, das nur für sein späteres Kompatibilitätsfenster beibehalten wurde; direkte Hilfsfunktionen zum Laden und Schreiben zur Laufzeit wurden entfernt.
• openclaw/extension-api – eine entfernte Brücke, die Plugins direkten Zugriff auf hostseitige Hilfsfunktionen wie den eingebetteten Agent-Runner gewährte.
• api.registerEmbeddedExtensionFactory(...) – ein entfernter, ausschließlich für den eingebetteten Runner bestimmter Hook, der Ereignisse des eingebetteten Runners wie tool_result beobachtete. Verwenden Sie stattdessen Middleware für Agent- Werkzeugergebnisse (siehe Erweiterungen für eingebettete Werkzeugergebnisse zu Middleware migrieren).

Das SDK-Stammverzeichnis, das Kompatibilitäts-Barrel, die Erweiterungsbrücke und die Factory für eingebettete Erweiterungen wurden entfernt. infra-runtime und config-runtime bleiben nur für ihre separat dokumentierten späteren Zeitfenster bestehen; neue Plugins sollten fokussierte Unterpfade verwenden.

OpenClaw entfernt oder interpretiert dokumentiertes Plugin-Verhalten nicht in derselben Änderung neu, die einen Ersatz einführt. Inkompatible Vertragsänderungen durchlaufen zunächst einen Kompatibilitätsadapter, Diagnosen, Dokumentation und ein Veraltungszeitfenster. Das gilt für SDK-Imports, Manifestfelder, Einrichtungs-APIs, Hooks und das Registrierungsverhalten zur Laufzeit.

Warum

• Langsamer Start – der Import einer Hilfsfunktion lud Dutzende nicht zusammengehöriger Module.
• Zirkuläre Abhängigkeiten – umfassende Re-Exporte erleichterten das Erzeugen von Importzyklen.
• Unklare API-Oberfläche – stabile Exporte ließen sich nicht von internen unterscheiden.

Jedes openclaw/plugin-sdk/<subpath> ist jetzt ein kleines, eigenständiges Modul mit einem dokumentierten Vertrag.

Auch ältere Provider-Komfortschnittstellen für gebündelte Kanäle wurden entfernt – kanalspezifische Hilfsabkürzungen waren private Annehmlichkeiten des Mono-Repos und keine stabilen Plugin-Verträge. Verwenden Sie stattdessen schmale, generische SDK-Unterpfade. Behalten Sie innerhalb des Arbeitsbereichs gebündelter Plugins Provider-eigene Hilfsfunktionen im jeweiligen api.ts oder runtime-api.ts dieses Plugins:

• Anthropic behält Claude-spezifische Stream-Hilfsfunktionen in seiner eigenen api.ts- / contract-api.ts-Schnittstelle.
• OpenAI behält Provider-Builder, Hilfsfunktionen für Standardmodelle und Builder für Echtzeit-Provider in seinem eigenen api.ts.
• OpenRouter behält den Provider-Builder und Hilfsfunktionen für Onboarding und Konfiguration in seinem eigenen api.ts.

Kompatibilitätsrichtlinie

Kompatibilitätsarbeiten für externe Plugins erfolgen in dieser Reihenfolge:

1. Fügen Sie den neuen Vertrag hinzu.
2. Erhalten Sie das alte Verhalten über einen Kompatibilitätsadapter.
3. Geben Sie eine Diagnose oder Warnung aus, die den alten Pfad und seinen Ersatz nennt.
4. Decken Sie beide Pfade mit Tests ab.
5. Dokumentieren Sie die Veraltung und den Migrationspfad.
6. Entfernen Sie den alten Pfad erst nach dem angekündigten Migrationszeitraum, üblicherweise in einem Major- Release.

Wenn ein Manifestfeld weiterhin akzeptiert wird, verwenden Sie es weiter, bis Dokumentation und Diagnosen etwas anderes angeben. Neuer Code sollte den dokumentierten Ersatz bevorzugen; bestehende Plugins dürfen bei gewöhnlichen Minor-Releases nicht ausfallen.

Kompatibilität der Einrichtung veröffentlichter Kanäle

Über 2026.7.1 veröffentlichte Pakete für Slack, Discord, Signal und Microsoft Teams importieren kanalspezifische Konfigurationsschemas aus openclaw/plugin-sdk/bundled-channel-config-schema. Die veröffentlichten Pakete für Slack und Discord importieren außerdem createLegacyCompatChannelDmPolicy und promptLegacyChannelAllowFromForAccount aus openclaw/plugin-sdk/setup-runtime.

Diese Exporte bleiben als veraltete Kompatibilitätsadapter zur Laufzeit verfügbar. Neue und erneut veröffentlichte Plugins sollten ihre Konfigurationsschemas und Einrichtungsrichtlinien lokal verwalten und dafür generische Primitive aus channel-config-schema und setup-runtime verwenden. Die Kompatibilitätsexporte dürfen erst entfernt werden, wenn die unterstützten Mindestversionen der veröffentlichten Pakete sie nicht mehr importieren.

Kompatibilität der Eingabefelder für die Kanaleinrichtung

ChannelSetupInput behält jetzt dauerhaft nur noch den kanalübergreifenden Einrichtungsrahmen typisiert. Kanalspezifische Felder bleiben in einer veralteten Kompatibilitäts- ebene typisiert, damit vorhandene externe Plugins weiterhin kompiliert werden, während Plugin-Autoren diese Felder in Plugin-lokale Eingabetypen für die Einrichtung verschieben.

OpenClaw veröffentlicht keine Major-Releases. Eine Registry-Prüfung vom 2026-07-22 untersuchte 426 veröffentlichte, außerhalb des Repositorys verwaltete Kanal-Plugins und entfernte 21 Felder ohne Leser. Die 22 beibehaltenen Felder haben jeweils einen bekannten veröffentlichten Leser. Jedes weitere Feld wird gelöscht, sobald es von keinem veröffentlichten Plugin mehr gelesen wird; die beibehaltene Menge schrumpft, während Plugin-Autoren zu Plugin-lokalen Eingabetypen für die Einrichtung migrieren.

Dieselbe Prüfung entfernte 23 ältere, nicht deklarierte Schlüssel für die Adapter-Hochstufung ohne veröffentlichte Abhängige. Sechs gebräuchliche Schlüssel und der nur für die Einrichtung bestimmte Schlüssel rooms bleiben bestehen. Auch diese Menge schrumpft, während veröffentlichte Plugins singleAccountKeysToMove deklarieren.

Der gemeinsame Typ besitzt keine Indexsignatur. Plugin-eigene Schlüssel können weiterhin in Eingabeobjekten zur Laufzeit vorhanden sein; deklarieren Sie sie in einer Plugin-lokalen Schnittmenge oder grenzen Sie sie über das Einrichtungsschema des zuständigen Plugins ein.

Die ältere Ebene zur Hochstufung nicht deklarierter Adapter folgt derselben lesergesteuerten Richtlinie. Deklarieren Sie singleAccountKeysToMove, einschließlich eines leeren Arrays, wenn das Plugin keine zusätzlichen Hochstufungsschlüssel benötigt, damit der gemeinsame Fallback Schlüssel für Schlüssel außer Betrieb genommen werden kann.

Leser überprüfen

1. Blättern Sie mit jedem nextCursor durch https://clawhub.ai/api/v1/packages?family=code-plugin&limit=100 und behalten Sie Pakete bei, deren categories channels enthalten.
2. Fügen Sie npm-Kandidaten aus npm search --json --searchlimit=1000 "openclaw channel plugin" hinzu. Fügen Sie reine Quellcode-Kandidaten aus GitHub-Codesuchen nach openclaw/plugin-sdk/channel-setup, openclaw/plugin-sdk/setup und openclaw/plugin-sdk/core hinzu.
3. Ermitteln Sie für jeden Kandidaten die neueste veröffentlichte Version. Führen Sie npm pack <package>@<version> --json --pack-destination <temp-dir> aus, entpacken Sie sie und untersuchen Sie den ausgelieferten dist-JavaScript-Code und die Deklarationen auf direkte oder destrukturierte Feldzugriffe. Laden Sie das ClawHub-Artefakt herunter, wenn ein Paket keine npm-Veröffentlichung besitzt.
4. Erfassen Sie Paket, Version, Feld oder Hochstufungsschlüssel und die übereinstimmende Datei. Ein Feld oder Schlüssel darf nur gelöscht werden, wenn kein veröffentlichtes Plugin-Artefakt darauf zugreift. Halten Sie die Lesernamen in den Codekommentaren neben den Listen der beibehaltenen Felder und Schlüssel mit der Prüfung synchron.

Dies ist ausschließlich ein Kompatibilitätsdatensatz für Quellcode und Typen. Er besitzt keinen Adapter zur Laufzeit und keinen Eintrag in der Kompatibilitäts-Registry, da Eingabeobjekte für die Einrichtung und das Einrichtungs- verhalten zur Laufzeit unverändert bleiben.

Prüfen Sie die aktuelle Migrationswarteschlange mit pnpm plugins:boundary-report:

pnpm plugins:boundary-report:ci wird mit allen drei Fehler-Flags ausgeführt. Veraltete Datensätze besitzen normalerweise ein ausdrückliches Datum removeAfter statt eines vagen „nächsten Major-Releases“. Bei einem Datensatz, dessen Verantwortlicher noch kein Datum genehmigt hat, fehlt removeAfter; er erscheint als no-date und kann niemals entfernt werden. Der Bericht gruppiert veraltete Datensätze nach Datum, zählt lokale Code-/Dokumentationsreferenzen, zeigt reservierte SDK-Imports über Verantwortlichkeitsgrenzen hinweg an und fasst die private SDK-Brücke des Speicher-Hosts zusammen. Reservierte SDK-Unterpfade müssen eine nachverfolgte Nutzung durch den Verantwortlichen aufweisen; ungenutzte reservierte Exporte sollten aus dem öffentlichen SDK entfernt werden.

Veraltete Medienprojektion

Der Kompatibilitätsdatensatz media-legacy-projection deckt die alten parallelen Medienfelder, Payload-Builder, Metadatenaliase für Hooks und Namen von Medienvorlagen ab. Das genehmigte Datum removeAfter ist 2026-10-01 (zwei Release-Zyklen, nachdem die Facts-First-Ersatzlösungen ausgeliefert wurden). Die Entfernung erfordert zu diesem Zeitpunkt zusätzlich eine saubere Prüfung veröffentlichter Plugin-Artefakte; migrieren Sie vor diesem Datum.

Ersetzen Sie für den Kanaleingang die Singular-/Pluralformen MediaPath, MediaUrl, MediaType, MediaPaths, MediaUrls, MediaTypes, MediaTranscribedIndexes, MediaWorkspaceDir und MediaStaged durch geordnete Fakten:

 const media = toInboundMediaFacts([  { path: saved.path, url: nativeUrl, contentType: saved.contentType, messageId },]); const ctx = finalizeInboundContext({ Body: caption, media });

Verwenden Sie event.media in den Hooks inbound_claim und message_received. Wenn entfernte Medien nicht lokal bereitgestellt wurden, verwenden Sie event.originalMedia für Identität und Diagnosen und warten Sie auf event.media; event.mediaStagingPending kennzeichnet diesen Zustand. Lesen Sie die veralteten Singular-/Plural-Eigenschaften nicht aus event.metadata.

Ersetzen Sie für CLI-Medienmodelle {{MediaPath}}, {{MediaUrl}}, {{MediaType}} und {{MediaDir}} durch {{AttachmentPath}}, {{AttachmentUrl}}, {{AttachmentContentType}} und {{AttachmentDir}}. Verwenden Sie {{AttachmentIndex}}, wenn die Position des Anhangs relevant ist.

Importieren Sie für die Richtlinie zum Lesen lokaler Medien getAgentScopedMediaLocalRoots(...) oder getAgentScopedMediaLocalRootsForSources(...) aus openclaw/plugin-sdk/media-local-roots. Die openclaw/plugin-sdk/agent-media-payload-Fassade und ihre buildAgentMediaPayload(...)-Projektion sind veraltet.

Migration

await api.runtime.config.mutateConfigFile({  afterWrite: { mode: "auto" },  mutate(draft) {    draft.plugins ??= {};  },});

// OpenClaw-Laufzeitwerkzeuge und dynamische Werkzeuge der Codex-Laufzeit (das Ergebnis kann// transformiert werden). Ergebnisse nativer Codex-Werkzeuge werden zur Beobachtung ebenfalls weitergeleitet,// ihre transformierte Ausgabe erreicht das Modell jedoch nie: Der Vertrag des Codex-// PostToolUse-Hooks kann die Antwort eines nativen Werkzeugs nicht ersetzen.api.registerAgentToolResultMiddleware(async (event) => {  return compactToolResult(event);}, {  runtimes: ["openclaw", "codex"],});

{  "contracts": {    "agentToolResultMiddleware": ["openclaw", "codex"]  }}

// Vorherconst program = applyWindowsSpawnProgramPolicy({ candidate }); // Nachherconst program = applyWindowsSpawnProgramPolicy({  candidate,  // Legen Sie dies nur für vertrauenswürdige Kompatibilitätsaufrufer fest, die einen  // über die Shell vermittelten Fallback bewusst akzeptieren.  allowShellFallback: true,});

grep -r "plugin-sdk/compat" my-plugin/grep -r "plugin-sdk/infra-runtime" my-plugin/grep -r "plugin-sdk/config-runtime" my-plugin/grep -r "openclaw/extension-api" my-plugin/

// Vorher (veraltete Abwärtskompatibilitätsschicht)import {  createChannelReplyPipeline,  createPluginRuntimeStore,  resolveControlCommandGate,} from "openclaw/plugin-sdk/compat"; // Nachher (moderne gezielte Importe)import { createChannelReplyPipeline } from "openclaw/plugin-sdk/channel-reply-pipeline";import { createPluginRuntimeStore } from "openclaw/plugin-sdk/runtime-store";import { resolveControlCommandGate } from "openclaw/plugin-sdk/command-auth";

// Vorher (veraltete extension-api-Brücke)import { runEmbeddedAgent } from "openclaw/extension-api";const result = await runEmbeddedAgent({ sessionId, prompt }); // Nachher (injizierte Laufzeit)const result = await api.runtime.agent.runEmbeddedAgent({ sessionId, prompt });

pnpm buildpnpm test my-plugin/

Referenz für Importpfade

Die öffentliche Exportzuordnung des Pakets ist die maßgebliche Quelle für importierbare SDK- Unterpfade. Verwenden Sie die thematischen SDK-Leitfäden, die in der SDK-Übersicht verlinkt sind, und bevorzugen Sie den spezifischsten dokumentierten öffentlichen Unterpfad. Das Compiler-Inventar in scripts/lib/plugin-sdk-entrypoints.json enthält außerdem private lokale Einträge, die zum Erstellen gebündelter Plugins verwendet werden; ihre dortige Präsenz macht sie nicht zu öffentlichen Paketexporten.

Diese Tabelle zeigt die übliche Teilmenge für Migrationen, nicht die vollständige SDK-Oberfläche. Das Inventar der Compiler-Einstiegspunkte befindet sich in scripts/lib/plugin-sdk-entrypoints.json; Paketexporte werden aus der öffentlichen Teilmenge generiert.

Reservierte Hilfsschnittstellen für gebündelte Plugins wurden aus der öffentlichen SDK- Exportzuordnung entfernt, mit Ausnahme ausdrücklich dokumentierter Kompatibilitätsfassaden wie dem veralteten Shim plugin-sdk/discord, das für externe Plugins beibehalten wird, die weiterhin das veröffentlichte Paket @openclaw/discord direkt importieren. Eigentümerspezifische Hilfsfunktionen befinden sich innerhalb des jeweils zuständigen Plugin-Pakets; gemeinsames Hostverhalten wird über generische SDK-Verträge wie plugin-sdk/gateway-runtime, plugin-sdk/security-runtime und die injizierte Plugin-API bereitgestellt.

Verwenden Sie den spezifischsten Import, der zur Aufgabe passt. Wenn Sie einen Export nicht finden können, prüfen Sie den Quellcode unter src/plugin-sdk/ oder fragen Sie die Maintainer, welcher generische Vertrag dafür zuständig sein sollte.

Entfernte Kompatibilitätsoberflächen

Bei der Bereinigung im Juli 2026 wurden das Stamm-SDK und die Compat-Barrels, die Extension-API- Brücke, die abgelaufenen SDK-Unterpfadaliase, ungenutzte SDK-Unterpfade und die öffentlichen Exporte für ausschließlich gebündelte SDK-Module entfernt. Ausschließlich gebündelte Module bleiben ihren Repository-Eigentümern über private lokale Build-Zuordnungen verfügbar; sie können nicht aus dem veröffentlichten Paket importiert werden.

Prozessglobale Veröffentlichung von API-Providern

registerApiProvider(...) und unregisterApiProviders(...) wurden aus openclaw/plugin-sdk/llm entfernt. Sie veröffentlichten API-Transporte im prozessglobalen Zustand, den lebenszyklusverwaltete Modelllaufzeiten anschließend in jede vorbereitete Registry kopieren mussten.

Provider-Plugins sollten Textinferenz-Provider über api.registerProvider(...) registrieren. Hosteigener Code und Tests, die eine ApiRegistry erstellen, sollten direkt in dieser Registry registrieren, damit die Zuständigkeit für den Provider und dessen Abbau auf die vorbereitete Laufzeit beschränkt bleiben.

Privates Testing-Barrel

openclaw/plugin-sdk/testing war Repository-lokal und von ausgelieferten Paketartefakten ausgeschlossen, daher wurde es vor seinem removeAfter-Datum am 2026-07-28 entfernt. Repository- Tests verwenden spezifische Unterpfade wie plugin-sdk/plugin-test-runtime, plugin-sdk/channel-test-helpers, plugin-sdk/channel-target-testing, plugin-sdk/test-env und plugin-sdk/test-fixtures.

Migrationsreferenz

Diese Zuordnungen decken sowohl die im Juli 2026 entfernten Oberflächen als auch die in späteren Zeitfenstern aktiven Veraltungen ab. Eine Zuordnung ist eine Migrationsanleitung und kein Nachweis dafür, dass die alte Oberfläche weiterhin verfügbar ist; den aktuellen Status finden Sie im Kompatibilitätsregister und im Zeitplan für Entfernungen.

// Vorherimport { buildHelpMessage } from "openclaw/plugin-sdk/command-auth"; // Nachherimport { buildHelpMessage } from "openclaw/plugin-sdk/command-status";

// Vorherapi.on("deactivate", async (event, ctx) => {  await stopPluginService(ctx);}); // Nachherapi.on("gateway_stop", async (event, ctx) => {  await stopPluginService(ctx);});

// Vorherapi.on("subagent_spawning", async () => ({  status: "ok",  threadBindingReady: true,  deliveryOrigin: { channel: "discord", to: "channel:123", threadId: "456" },})); // Nachherapi.on("subagent_spawned", async (event) => {  await observeSubagentLaunch(event);});

{  "contracts": {    "externalAuthProviders": ["anthropic", "openai"]  }}

// Vorherconst flow = api.runtime.tasks.flow.fromToolContext(ctx);// Nachherconst flow = api.runtime.tasks.managedFlows.fromToolContext(ctx);

// Vorherimport type { OpenClawSchemaType } from "openclaw/plugin-sdk";// Nachherimport type { OpenClawConfig } from "openclaw/plugin-sdk/config-contracts";

Migration von Talk und Echtzeit-Sprachkommunikation

Code für Echtzeit-Sprachkommunikation, Telefonie, Meetings und Browser-Talk verwendet gemeinsam einen Talk-Sitzungscontroller, der von openclaw/plugin-sdk/realtime-voice exportiert wird. Der Controller verwaltet den gemeinsamen Talk-Ereignisumschlag, den Zustand des aktiven Gesprächsbeitrags, den Erfassungszustand, den Zustand der Audioausgabe, den jüngsten Ereignisverlauf und die Ablehnung veralteter Gesprächsbeiträge. Provider-Plugins verwalten anbieterspezifische Echtzeitsitzungen. Browser-Meeting-Plugins verwenden openclaw/plugin-sdk/meeting-runtime für Sitzungs-, Browser-, Audio-, Node-Host-, Agent-Consult- und Sprachanrufmechanismen und implementieren anschließend MeetingPlatformAdapter für URL-Regeln, DOM-Skripte, die Zuordnung manueller Aktionen, Untertitel, Erstellung und Einwahlpläne. Plattform-REST-APIs, OAuth, Artefakte, Selektoren und Wire-Namen verbleiben im Plugin. Browser-Berechtigungspläne erhalten die angeforderte Meeting-URL, damit jede Plattform ausschließlich ihre genau unterstützten Ursprünge freigeben kann. Sitzungs-Runtimes müssen außerdem die plattformspezifische Live-Funktionsfähigkeit nach dem bestätigten Verlassen des Browsers normalisieren; historische Transkriptfelder dürfen erhalten bleiben, aber die Bereitschaft von Untertiteln und Audio darf nach dem Verlassen nicht aktiv bleiben.

Alle gebündelten Oberflächen werden mit dem gemeinsamen Controller ausgeführt: Browser-Relay, Übergabe verwalteter Räume, Echtzeit-Sprachanrufe, Streaming-STT für Sprachanrufe, Google Meet-Echtzeitkommunikation und natives Push-to-Talk. Der Gateway kündigt in hello-ok.features.events einen Live-Talk-Ereigniskanal an: talk.event.

Neuer Code sollte createTalkEventSequencer(...) nicht direkt aufrufen, außer wenn ein Low-Level-Adapter oder eine Test-Fixture implementiert wird. Verwenden Sie den gemeinsamen Controller, damit auf einen Gesprächsbeitrag begrenzte Ereignisse nicht ohne Gesprächsbeitrags-ID ausgegeben werden können, veraltete Aufrufe von turnEnd / turnCancel keinen neueren aktiven Gesprächsbeitrag löschen können und Ereignisse im Lebenszyklus der Audioausgabe über Telefonie, Meetings, Browser-Relay, die Übergabe verwalteter Räume und native Talk-Clients hinweg konsistent bleiben.

Die Form der öffentlichen API:

// Vom Gateway verwaltete Talk-Sitzungs-API.await gateway.request("talk.session.create", {  mode: "realtime",  transport: "gateway-relay",  brain: "agent-consult",  sessionKey: "main",});await gateway.request("talk.session.appendAudio", { sessionId, audioBase64 });await gateway.request("talk.session.cancelOutput", { sessionId, reason: "barge-in" });await gateway.request("talk.session.submitToolResult", {  sessionId,  callId,  result: { status: "working" },  options: { willContinue: true },});await gateway.request("talk.session.submitToolResult", {  sessionId,  callId,  result: { status: "already_delivered" },  options: { suppressResponse: true },});await gateway.request("talk.session.submitToolResult", { sessionId, callId, result });await gateway.request("talk.session.close", { sessionId }); // Vom Client verwaltete Provider-Sitzungs-API.await gateway.request("talk.client.create", {  mode: "realtime",  transport: "webrtc",  brain: "agent-consult",  sessionKey: "main",});await gateway.request("talk.client.toolCall", { sessionKey, callId, name, args });await gateway.request("talk.client.steer", { sessionKey, text, mode: "steer" });

Browsereigene WebRTC-/Provider-WebSocket-Sitzungen verwenden talk.client.create, da der Browser die Provider-Aushandlung und den Medientransport verwaltet, während der Gateway Anmeldedaten, Anweisungen und Tool-Richtlinien verwaltet. talk.session.* ist die gemeinsame, vom Gateway verwaltete Oberfläche für Gateway-Relay-Echtzeitkommunikation, Gateway-Relay-Transkription und native STT-/TTS-Sitzungen in verwalteten Räumen.

Veraltete Konfigurationen, die Echtzeitselektoren neben talk.provider / talk.providers platzieren, sollten mit openclaw doctor --fix repariert werden; die Talk-Runtime interpretiert die Sprach-/TTS-Provider-Konfiguration nicht als Echtzeit-Provider-Konfiguration neu.

Die unterstützten Kombinationen von talk.session.create sind bewusst begrenzt:

Methodenzuordnung für Leser, die von den älteren Familien talk.realtime.* / talk.transcription.* / talk.handoff.* migrieren (alle entfernt):

Das einheitliche Steuerungsvokabular ist ebenfalls bewusst begrenzt:

Führen Sie keine Provider- oder Plattformsonderfälle im Kern ein, damit dies funktioniert. Der Kern verwaltet die Semantik von Talk-Sitzungen. Provider-Plugins verwalten die Einrichtung anbieterspezifischer Sitzungen. Voice-Call und Google Meet verwalten Telefonie-/Meeting-Adapter. Browser- und native Apps verwalten die Geräteerfassungs-/Wiedergabe-UX.

Zeitplan für die Entfernung

Für die nachfolgend verbleibenden öffentlichen SDK-Unterpfade gelten registrierungsgestützte Entfernungszeiträume. Die Zeilen vom 30. Juli wurden nach ihrer frühzeitigen, von den Maintainern genehmigten Bereinigung entfernt: Nicht verwendete Unterpfade wurden gelöscht, frühere Kompatibilitätsaliase wurden gelöscht und ausschließlich für gebündelte Plugins bestimmte Module wurden zu privaten lokalen Build-Zuordnungen herabgestuft.

Alle Kern-Plugins wurden bereits migriert. Externe Plugins sollten vor der nächsten Hauptversion migriert werden. Führen Sie pnpm plugins:boundary-report aus, um zu sehen, welche Kompatibilitätseinträge für die von Ihrem Plugin verwendeten Oberflächen am frühesten fällig sind.

Warnungen vorübergehend unterdrücken

OPENCLAW_SUPPRESS_PLUGIN_SDK_COMPAT_WARNING=1 openclaw gateway runOPENCLAW_SUPPRESS_EXTENSION_API_WARNING=1 openclaw gateway run

Dies ist ein vorübergehender Ausweg, keine dauerhafte Lösung.

Verwandte Themen

• Erste Schritte - Erstellen Sie Ihr erstes Plugin
• SDK-Übersicht - vollständige Importreferenz für Unterpfade
• Kanal-Plugins - Kanal-Plugins erstellen
• Provider-Plugins - Provider-Plugins erstellen
• Plugin-Interna - ausführlicher Einblick in die Architektur
• Plugin-Manifest - Referenz zum Manifest-Schema