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-sdkundopenclaw/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 wietool_resultbeobachtete. Verwenden Sie stattdessen Middleware für Agent- Werkzeugergebnisse (siehe Erweiterungen für eingebettete Werkzeugergebnisse zu Middleware migrieren).
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.
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:- Fügen Sie den neuen Vertrag hinzu.
- Erhalten Sie das alte Verhalten über einen Kompatibilitätsadapter.
- Geben Sie eine Diagnose oder Warnung aus, die den alten Pfad und seinen Ersatz nennt.
- Decken Sie beide Pfade mit Tests ab.
- Dokumentieren Sie die Veraltung und den Migrationspfad.
- Entfernen Sie den alten Pfad erst nach dem angekündigten Migrationszeitraum, üblicherweise in einem Major- Release.
Kompatibilität der Einrichtung veröffentlichter Kanäle
Über2026.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.
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
- Blättern Sie mit jedem
nextCursordurchhttps://clawhub.ai/api/v1/packages?family=code-plugin&limit=100und behalten Sie Pakete bei, derencategorieschannelsenthalten. - Fügen Sie npm-Kandidaten aus
npm search --json --searchlimit=1000 "openclaw channel plugin"hinzu. Fügen Sie reine Quellcode-Kandidaten aus GitHub-Codesuchen nachopenclaw/plugin-sdk/channel-setup,openclaw/plugin-sdk/setupundopenclaw/plugin-sdk/corehinzu. - 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 ausgeliefertendist-JavaScript-Code und die Deklarationen auf direkte oder destrukturierte Feldzugriffe. Laden Sie das ClawHub-Artefakt herunter, wenn ein Paket keine npm-Veröffentlichung besitzt. - 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.
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ätsdatensatzmedia-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:
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
Hilfsfunktionen zum Laden/Schreiben der Laufzeitkonfiguration migrieren
api.runtime.config.loadConfig() und
api.runtime.config.writeConfigFile(...) nicht mehr direkt aufrufen. Bevorzugen Sie die Konfiguration, die bereits
an den aktiven Aufrufpfad übergeben wurde. Langlebige Handler, die den
aktuellen Prozess-Snapshot benötigen, können api.runtime.config.current() verwenden. Langlebige
Agent-Werkzeuge sollten ctx.getRuntimeConfig() innerhalb von execute lesen, damit ein Werkzeug,
das vor dem Schreiben einer Konfiguration erstellt wurde, dennoch die aktualisierte Konfiguration sieht.Konfigurationsschreibvorgänge erfolgen über die transaktionale Hilfsfunktion mit einer ausdrücklichen
Richtlinie für die Zeit nach dem Schreiben:afterWrite: { mode: "restart", reason: "..." }, wenn die Änderung
einen sauberen Neustart des Gateways erfordert, und afterWrite: { mode: "none", reason: "..." }
nur, wenn der Aufrufer für die Nachbereitung verantwortlich ist und den
Neuladungsplaner bewusst unterdrückt. Mutationsergebnisse enthalten eine typisierte Zusammenfassung followUp für
Tests und Protokollierung; das Gateway bleibt für die Durchführung oder
Planung des Neustarts verantwortlich.loadConfig und writeConfigFile wurden aus der Plugin-
Laufzeit entfernt. Gebündelte Plugins und Laufzeitcode des Repositorys werden durch
pnpm check:deprecated-api-usage und
pnpm check:no-runtime-action-load-config geschützt: Neue Verwendung in
produktivem Plugin-Code schlägt sofort fehl, direkte Konfigurationsschreibvorgänge schlagen fehl, Gateway-Servermethoden müssen
den Laufzeit-Snapshot der Anfrage verwenden, Laufzeit-Hilfsfunktionen für das Senden, Aktionen und Clients von Kanälen
müssen die Konfiguration von ihrer Schnittstellengrenze erhalten, und langlebige Laufzeitmodule
erlauben keine umgebungsbezogenen Aufrufe von loadConfig().Neuer Plugin-Code sollte das allgemeine Barrel openclaw/plugin-sdk/config-runtime
vermeiden. Verwenden Sie den spezifischen Unterpfad für die jeweilige Aufgabe:Eingebettete Erweiterungen für Werkzeugergebnisse auf Middleware migrieren
api.registerEmbeddedExtensionFactory(...) durch
laufzeitneutrale Middleware ersetzen:contracts.agentToolResultMiddleware deklariert ist. Nicht deklarierte Middleware-
Registrierungen installierter Plugins werden abgelehnt.Native Genehmigungshandler auf Fähigkeitsfakten migrieren
approvalCapability.nativeRuntime sowie die gemeinsame Registry für den Laufzeitkontext
bereit:- Ersetzen Sie
approvalCapability.handler.loadRuntime(...)durchapprovalCapability.nativeRuntime. - Verlagern Sie genehmigungsspezifische Authentifizierung/Zustellung von der veralteten Verkabelung
plugin.auth/plugin.approvalszuapprovalCapability. ChannelPlugin.approvalswurde aus dem öffentlichen Vertrag für Kanal-Plugins entfernt; verschieben Sie Felder für Zustellung, native Funktionen und Rendering nachapprovalCapability.plugin.authbleibt ausschließlich für Anmelde-/Abmeldeabläufe von Kanälen bestehen; der Kern liest dort keine Genehmigungs-Authentifizierungs-Hooks mehr.- Registrieren Sie kanaleigene Laufzeitobjekte (Clients, Tokens, Bolt-Apps)
über
openclaw/plugin-sdk/channel-runtime-context. - Senden Sie aus nativen Genehmigungshandlern keine Plugin-eigenen Hinweise zur Umleitung; der Kern ist anhand der tatsächlichen Zustellungsergebnisse für Hinweise über anderweitige Weiterleitung verantwortlich.
- Wenn Sie
channelRuntimeancreateChannelManager(...)übergeben, stellen Sie eine echte OberflächecreatePluginRuntime().channelbereit – partielle Stubs werden abgelehnt.
Fallback-Verhalten von Windows-Wrappern prüfen
openclaw/plugin-sdk/windows-spawn verwendet, schlagen nicht aufgelöste Windows-
Wrapper .cmd/.bat nun geschlossen fehl, sofern Sie nicht ausdrücklich
allowShellFallback: true übergeben:allowShellFallback nicht und behandeln Sie stattdessen den ausgelösten Fehler.Veraltete Importe finden
Durch gezielte Importe ersetzen
Allgemeine infra-runtime-Importe ersetzen
openclaw/plugin-sdk/infra-runtime besteht für externe
Kompatibilität weiterhin, neuer Code sollte jedoch die tatsächlich benötigte spezifische Oberfläche
importieren:infra-runtime geschützt, damit Repository-Code
nicht auf das allgemeine Barrel zurückfällt.Hilfsfunktionen für Kanalrouten migrieren
openclaw/plugin-sdk/channel-route. Die älteren
Namen der Routenschlüssel bleiben als Kompatibilitätsaliase erhalten:{ channel, to, accountId, threadId }
konsistent für native Genehmigungen, Antwortunterdrückung, Deduplizierung eingehender Nachrichten,
Cron-Zustellung und Sitzungsrouting.Fügen Sie keine neuen Verwendungen von ChannelMessagingAdapter.parseExplicitTarget oder
resolveChannelRouteTargetWithParser(...) aus
plugin-sdk/channel-route hinzu – diese sind veraltet und bleiben nur für ältere
Plugins erhalten. Neue Kanal-Plugins sollten
messaging.targetResolver.resolveTarget(...) für die Normalisierung von Ziel-IDs
und den Fallback bei fehlendem Verzeichniseintrag,
messaging.inferTargetChatType(...), wenn der Kern frühzeitig einen Peer-Typ benötigt,
und messaging.resolveOutboundSessionRoute(...) für Provider-native
Sitzungs- und Thread-Identitäten verwenden.Erstellen und testen
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 inscripts/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.Hilfsfunktionen für command-auth-Hilfe -> command-status
Hilfsfunktionen für command-auth-Hilfe -> command-status
openclaw/plugin-sdk/command-auth): buildCommandsMessage,
buildCommandsMessagePaginated, buildHelpMessage.Neu (openclaw/plugin-sdk/command-status): dieselben Signaturen, importiert
aus dem enger gefassten Unterpfad. Die Kompatibilitäts-Re-Exporte von command-auth
wurden entfernt.Hilfsfunktionen für Mention-Gating -> resolveInboundMentionDecision
Hilfsfunktionen für Mention-Gating -> resolveInboundMentionDecision
resolveMentionGating(params) und
resolveMentionGatingWithBypass(params) aus
openclaw/plugin-sdk/channel-inbound oder
openclaw/plugin-sdk/channel-mention-gating.Neu: resolveInboundMentionDecision({ facts, policy }) – ein Entscheidungsobjekt
anstelle zweier getrennter Aufrufformen.Übernommen für Discord, iMessage, Matrix, MS Teams, QQBot, Signal,
Telegram, WhatsApp und Zalo. Slacks eigenes app_mention-Ereignismodell
verwendet diese Hilfsfunktion nicht.Channel-Runtime-Shim und Hilfsfunktionen für Channel-Aktionen
Channel-Runtime-Shim und Hilfsfunktionen für Channel-Aktionen
openclaw/plugin-sdk/channel-runtime wurde entfernt. Verwenden Sie
openclaw/plugin-sdk/channel-runtime-context, um Runtime-Objekte zu registrieren.Die nativen Hilfsfunktionen für Nachrichtenschemas in openclaw/plugin-sdk/channel-actions
wurden zusammen mit den unstrukturierten „actions“-Channel-Exporten entfernt. Stellen Sie Fähigkeiten
stattdessen über die semantische Oberfläche presentation bereit – Channel-Plugins
deklarieren, was sie darstellen (Karten, Schaltflächen, Auswahlelemente), statt welche unstrukturierten
Aktionsnamen sie akzeptieren.Websuch-Provider-Hilfsfunktion tool() -> createTool() im Plugin
Websuch-Provider-Hilfsfunktion tool() -> createTool() im Plugin
tool()-Factory aus openclaw/plugin-sdk/provider-web-search.Neu: Implementieren Sie createTool(...) direkt im Provider-Plugin.
OpenClaw benötigt die SDK-Hilfsfunktion nicht mehr, um den Tool-Wrapper zu registrieren.Channel-Umschläge im Klartext -> BodyForAgent
Channel-Umschläge im Klartext -> BodyForAgent
api.runtime.channel.reply.formatInboundEnvelope(...) (und das
Feld channelEnvelope bei eingehenden Nachrichtenobjekten), um aus eingehenden
Channel-Nachrichten einen flachen Prompt-Umschlag im Klartext zu erstellen.Neu: BodyForAgent plus strukturierte Benutzerkontextblöcke. Channel-
Plugins fügen Routing-Metadaten (Thread, Thema, Antwortbezug, Reaktionen) als
typisierte Felder hinzu, statt sie zu einer Prompt-Zeichenfolge zusammenzufügen. Die
Hilfsfunktion formatAgentEnvelope(...) wird für synthetisch erzeugte,
an den Assistenten gerichtete Umschläge weiterhin unterstützt, eingehende Klartextumschläge werden jedoch
abgeschafft.Betroffene Bereiche: inbound_claim, message_received und jedes benutzerdefinierte
Channel-Plugin, das den alten Umschlagtext nachverarbeitet hat.deactivate-Hook -> gateway_stop
deactivate-Hook -> gateway_stop
api.on("deactivate", handler).Neu: api.on("gateway_stop", handler). Derselbe Vertrag für die Bereinigung beim Herunterfahren;
nur der Hook-Name ändert sich.deactivate bleibt als veralteter Kompatibilitätsalias eingebunden, bis er
nach dem 2026-08-16 entfernt wird.subagent_spawning-Hook -> Thread-Bindung im Kern
subagent_spawning-Hook -> Thread-Bindung im Kern
api.on("subagent_spawning", handler), das
threadBindingReady oder deliveryOrigin zurückgibt.Neu: Lassen Sie den Kern thread: true-Subagent-Bindungen über den
Adapter für Channel-Sitzungsbindungen vorbereiten. Verwenden Sie api.on("subagent_spawned", handler)
nur zur Beobachtung nach dem Start.subagent_spawning, PluginHookSubagentSpawningEvent,
PluginHookSubagentSpawningResult und
SubagentLifecycleHookRunner.runSubagentSpawning(...) bleiben nur als
veraltete Kompatibilitätsoberflächen bestehen, während externe Plugins migrieren, und werden
nach dem 2026-08-30 entfernt.Provider-Ermittlungstypen -> Provider-Katalogtypen
Provider-Ermittlungstypen -> Provider-Katalogtypen
ProviderCapabilities wurden
entfernt. Provider-Plugins
sollten explizite Provider-Hooks wie buildReplayPolicy,
normalizeToolSchemas und wrapStreamFn statt eines statischen Objekts verwenden.Hooks für Denk-Richtlinien -> resolveThinkingProfile
Hooks für Denk-Richtlinien -> resolveThinkingProfile
ProviderThinkingPolicy):
isBinaryThinking(ctx), supportsXHighThinking(ctx) und
resolveDefaultThinkingLevel(ctx).Neu: ein einzelnes resolveThinkingProfile(ctx), das ein
ProviderThinkingProfile mit dem kanonischen id, optionalem label und einer
nach Rang geordneten Stufenliste zurückgibt. OpenClaw stuft veraltete gespeicherte Werte automatisch
anhand des Profilrangs herunter.Der Kontext enthält provider, modelId, optional zusammengeführte reasoning-
sowie optional zusammengeführte Modellfakten aus compat. Provider-Plugins können diese
Katalogfakten verwenden, um ein modellspezifisches Profil nur dann bereitzustellen, wenn der konfigurierte
Anfragevertrag dies unterstützt.Implementieren Sie einen statt drei Hooks. Die alten Hooks wurden entfernt.Externe Authentifizierungs-Provider -> contracts.externalAuthProviders
Externe Authentifizierungs-Provider -> contracts.externalAuthProviders
contracts.externalAuthProviders im Plugin-Manifest
und implementieren Sie resolveExternalAuthProfiles(...).Nachschlagen von Provider-Umgebungsvariablen -> setup.providers[].envVars
Nachschlagen von Provider-Umgebungsvariablen -> setup.providers[].envVars
providerAuthEnvVars: { anthropic: ["ANTHROPIC_API_KEY"] }.Neu: Spiegeln Sie dieselbe Suche nach Umgebungsvariablen in setup.providers[].envVars
im Manifest. Dadurch werden Umgebungsmetadaten für Einrichtung und Status an einer Stelle zusammengeführt
und es wird vermieden, die Plugin-Runtime nur zum Beantworten von Abfragen nach Umgebungsvariablen zu starten.providerAuthEnvVars wird nicht mehr akzeptiert.Registrierung des Memory-Plugins -> registerMemoryCapability
Registrierung des Memory-Plugins -> registerMemoryCapability
api.registerMemoryPromptSection(...),
api.registerMemoryFlushPlan(...), api.registerMemoryRuntime(...).Neu: ein Aufruf in der Memory-State-API –
registerMemoryCapability(pluginId, { promptBuilder, flushPlanResolver, runtime }).Dieselben Slots, ein einzelner Registrierungsaufruf. Additive Hilfsfunktionen für Prompts und Korpora
(registerMemoryPromptSupplement, registerMemoryCorpusSupplement) sind
nicht betroffen.API für Memory-Embedding-Provider
API für Memory-Embedding-Provider
api.registerMemoryEmbeddingProvider(...) plus
contracts.memoryEmbeddingProviders.Neu: api.registerEmbeddingProvider(...) plus
contracts.embeddingProviders.Der generische Vertrag für Embedding-Provider ist außerhalb von Memory wiederverwendbar und stellt
den unterstützten Pfad für neue Provider dar. Die Memory-spezifische Registrierungs-API
bleibt als veraltete Kompatibilitätsoberfläche eingebunden, während bestehende Provider
migrieren. Die Plugin-Prüfung meldet die Verwendung durch nicht gebündelte Plugins als
Kompatibilitätsschuld.Unstrukturierte Channel-Sendeergebnisse -> OutboundDeliveryResult
Unstrukturierte Channel-Sendeergebnisse -> OutboundDeliveryResult
{ ok, messageId, error } über
ChannelSendRawResult zurückgeben und mit
createRawChannelSendResultAdapter(...) normalisieren.Neu: Geben Sie OutboundDeliveryResult-Felder zurück und fügen Sie den Channel mit
createAttachedChannelResultAdapter(...) hinzu. Fehlgeschlagene Sendevorgänge sollten eine Ausnahme auslösen,
statt eine Fehlerzeichenfolge zurückzugeben. Der unstrukturierte Ergebnistyp bleibt bis
zur nächsten Hauptversion des Plugin-SDK verfügbar.Typen für Subagent-Sitzungsnachrichten umbenannt
Typen für Subagent-Sitzungsnachrichten umbenannt
src/plugins/runtime/types.ts exportiert:readSession ist zugunsten von
getSessionMessages veraltet. Dieselbe Signatur; die alte Methode leitet den Aufruf an die
neue weiter.Entfernte APIs für Sitzungs- und Transkriptdateien
Entfernte APIs für Sitzungs- und Transkriptdateien
sessions.json-Speicher, JSONL-Transkriptpfade oder Listen
von Sitzungsdateien offengelegt haben. Runtime-Plugins sollten Sitzungsidentitäten und SDK-Runtime-
Hilfsfunktionen verwenden, statt aktive Dateien aufzulösen oder zu verändern.v2026.7.1-beta.5 veröffentlicht wurden, importierten die vier
oben genannten veralteten Hilfsfunktionen. openclaw/plugin-sdk/session-store-runtime erhält
genau diese Brücke bis zum 2026-10-12; neue Plugins müssen die Ersatzlösungen verwenden.
resolveStorePath(...) bleibt eine unterstützte SDK-Hilfsfunktion und ist nicht Teil
dieser Veraltung.openclaw plugins inspect --all --runtime meldet nicht gebündelte Plugins, deren
Ladefehler oder Diagnosen weiterhin auf diese entfernten Datei-APIs verweisen. Der
Beratungsdurchlauf @openclaw/plugin-inspector muss Version 0.3.17 oder
neuer verwenden, damit Scans externer Pakete vor der Veröffentlichung auch Sitzungs-Hilfsfunktionen
für den gesamten Speicher, Hilfsfunktionen für Sitzungsdateipfade, alte Transkriptdateiziele und
Low-Level-Transkripthilfsfunktionen kennzeichnen.runtime.tasks.flow -> runtime.tasks.managedFlows
runtime.tasks.flow -> runtime.tasks.managedFlows
runtime.tasks.flow (Singular) gab einen aktiven TaskFlow-
Zugriff zurück.Neu: runtime.tasks.managedFlows behält die verwaltete TaskFlow-Mutations-
Runtime für Plugins bei, die untergeordnete Aufgaben aus einem Ablauf erstellen, aktualisieren, abbrechen oder
ausführen. Verwenden Sie runtime.tasks.flows, wenn das Plugin nur DTO-basierte
Lesezugriffe benötigt.Eingebettete Erweiterungs-Factorys -> Middleware für Agent-Tool-Ergebnisse
Eingebettete Erweiterungs-Factorys -> Middleware für Agent-Tool-Ergebnisse
api.registerEmbeddedExtensionFactory(...) wird durch
api.registerAgentToolResultMiddleware(...) mit einer expliziten Runtime-Liste
in contracts.agentToolResultMiddleware ersetzt.Alias OpenClawSchemaType -> OpenClawConfig
Alias OpenClawSchemaType -> OpenClawConfig
OpenClawSchemaType wurde entfernt. Verwenden Sie den
kanonischen Namen OpenClawConfig.extensions/) werden in ihren eigenen Barrels api.ts und
runtime-api.ts nachverfolgt. Sie wirken sich nicht auf die Verträge von Drittanbieter-Plugins
aus und werden hier nicht aufgeführt. Wenn Sie das lokale Barrel eines gebündelten Plugins
direkt verwenden, lesen Sie vor dem Upgrade die Hinweise zu veralteten Funktionen in diesem Barrel.Migration von Talk und Echtzeit-Sprachkommunikation
Code für Echtzeit-Sprachkommunikation, Telefonie, Meetings und Browser-Talk verwendet gemeinsam einen Talk-Sitzungscontroller, der vonopenclaw/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:
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:
talk.realtime.* /
talk.transcription.* / talk.handoff.* migrieren (alle entfernt):
Zeitplan für die Entfernung
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
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