Ce qui a changé
Deux surfaces d’import très permissives permettaient auparavant aux plugins d’accéder à presque tout depuis un point d’entrée unique :openclaw/plugin-sdk/compat- réexportait des dizaines d’utilitaires pour maintenir le fonctionnement des anciens plugins fondés sur des hooks pendant la construction de la nouvelle architecture.openclaw/plugin-sdk/infra-runtime- un vaste module d’agrégation mêlant événements système, état Heartbeat, files d’attente de livraison, utilitaires de récupération/proxy, utilitaires de fichiers, types d’approbation et utilitaires sans rapport entre eux.openclaw/plugin-sdk/config-runtime- un vaste module d’agrégation de configuration qui contenait encore des utilitaires directs obsolètes de chargement/écriture pendant la période de migration.openclaw/extension-api- une passerelle donnant aux plugins un accès direct aux utilitaires côté hôte, comme l’exécuteur d’agent intégré.api.registerEmbeddedExtensionFactory(...)- un hook supprimé, propre à l’exécuteur intégré, qui observait ses événements tels quetool_result. Utilisez plutôt l’intergiciel de résultats d’outils d’agent (voir Migrer les extensions de résultats d’outils intégrées vers l’intergiciel).
registerEmbeddedExtensionFactory a déjà été supprimé ; les anciens
enregistrements ne sont plus chargés.
OpenClaw ne supprime ni ne réinterprète un comportement de plugin documenté dans
le même changement que celui qui introduit son remplacement. Les modifications
de contrat incompatibles passent d’abord par un adaptateur de compatibilité, des
diagnostics, de la documentation et une période d’obsolescence. Cela s’applique
aux imports du SDK, aux champs du manifeste, aux API de configuration, aux hooks
et au comportement d’enregistrement à l’exécution.
Pourquoi
- Démarrage lent - l’import d’un seul utilitaire chargeait des dizaines de modules sans rapport.
- Dépendances circulaires - les vastes réexportations facilitaient la création de cycles d’import.
- Surface d’API peu claire - rien ne permettait de distinguer les exports stables des exports internes.
openclaw/plugin-sdk/<subpath> est désormais un petit module autonome
doté d’un contrat documenté.
Les anciennes interfaces pratiques de fournisseurs pour les canaux intégrés ont
également disparu : les raccourcis d’utilitaires propres aux canaux étaient des
commodités privées du monorepo, et non des contrats de plugin stables. Utilisez
plutôt des sous-chemins génériques et ciblés du SDK. Dans l’espace de travail
des plugins intégrés, conservez les utilitaires appartenant au fournisseur dans
le fichier api.ts ou runtime-api.ts de ce plugin :
- Anthropic conserve les utilitaires de flux propres à Claude dans son
interface
api.ts/contract-api.ts. - OpenAI conserve les constructeurs de fournisseurs, les utilitaires de modèle
par défaut et les constructeurs de fournisseurs en temps réel dans son
fichier
api.ts. - OpenRouter conserve le constructeur de fournisseur et les utilitaires
d’intégration/configuration dans son fichier
api.ts.
Politique de compatibilité
Les travaux de compatibilité des plugins externes suivent cet ordre :- Ajouter le nouveau contrat.
- Maintenir l’ancien comportement au moyen d’un adaptateur de compatibilité.
- Émettre un diagnostic ou un avertissement indiquant l’ancien chemin et son remplacement.
- Couvrir les deux chemins dans les tests.
- Documenter l’obsolescence et la procédure de migration.
- Ne supprimer qu’après la période de migration annoncée, généralement dans une version majeure.
pnpm plugins:boundary-report :
pnpm plugins:boundary-report:ci s’exécute avec les trois options d’échec.
Chaque enregistrement de compatibilité possède une date removeAfter explicite
(et non une vague « prochaine version majeure ») : le rapport regroupe les
enregistrements obsolètes selon cette date, compte les références locales dans
le code et la documentation, signale les imports SDK réservés entre
propriétaires et résume la passerelle SDK privée de l’hôte de mémoire. Les
sous-chemins SDK réservés doivent être associés à un usage suivi par leur
propriétaire ; les exports réservés inutilisés doivent être supprimés du SDK
public.
Procédure de migration
Migrer les utilitaires de chargement/écriture de la configuration d’exécution
api.runtime.config.loadConfig() et
api.runtime.config.writeConfigFile(...). Privilégiez la configuration
déjà transmise au chemin d’appel actif. Les gestionnaires à longue durée de
vie qui ont besoin de l’instantané actuel du processus peuvent utiliser
api.runtime.config.current(). Les outils d’agent à longue durée de vie
doivent lire ctx.getRuntimeConfig() dans execute, afin qu’un outil créé
avant une écriture de configuration voie tout de même la configuration
actualisée.Les écritures de configuration passent par l’utilitaire transactionnel avec
une politique explicite après écriture :afterWrite: { mode: "restart", reason: "..." } lorsque le
changement nécessite un redémarrage propre du Gateway, et
afterWrite: { mode: "none", reason: "..." } uniquement lorsque l’appelant
prend en charge la suite et désactive délibérément le planificateur de
rechargement. Les résultats de mutation incluent un résumé followUp typé
pour les tests et la journalisation ; le Gateway reste responsable de
l’application ou de la planification du redémarrage.loadConfig et writeConfigFile restent disponibles comme utilitaires de
compatibilité obsolètes pour les plugins externes et émettent un
avertissement unique avec le code de compatibilité
runtime-config-load-write. Les plugins intégrés et le code d’exécution du
dépôt sont protégés par pnpm check:deprecated-api-usage et
pnpm check:no-runtime-action-load-config : toute nouvelle utilisation
dans le code de production d’un plugin échoue immédiatement, les écritures
directes de configuration échouent, les méthodes du serveur Gateway doivent
utiliser l’instantané d’exécution de la requête, les utilitaires d’envoi,
d’action et de client des canaux d’exécution doivent recevoir la
configuration depuis leur frontière, et les modules d’exécution à longue
durée de vie n’autorisent aucun appel ambiant à loadConfig().Le nouveau code de plugin doit éviter le vaste module d’agrégation
openclaw/plugin-sdk/config-runtime. Utilisez le sous-chemin ciblé
correspondant au besoin :Migrer les extensions de résultats d’outils intégrées vers l’intergiciel
api.registerEmbeddedExtensionFactory(...) par un intergiciel indépendant
de l’environnement d’exécution :contracts.agentToolResultMiddleware. Les enregistrements d’intergiciels
installés non déclarés sont rejetés.Migrer les gestionnaires d’approbation natifs vers les faits de capacité
approvalCapability.nativeRuntime et du registre partagé de contexte
d’exécution :- Remplacez
approvalCapability.handler.loadRuntime(...)parapprovalCapability.nativeRuntime. - Déplacez l’authentification et la livraison propres aux approbations hors
de l’ancien câblage
plugin.auth/plugin.approvalsversapprovalCapability. ChannelPlugin.approvalsa été supprimé du contrat public des plugins de canaux ; déplacez les champs de livraison, natifs et de rendu versapprovalCapability.plugin.authne sert plus qu’aux flux de connexion/déconnexion des canaux ; le cœur n’y lit plus les hooks d’authentification des approbations.- Enregistrez les objets d’exécution appartenant au canal (clients, jetons,
applications Bolt) au moyen de
openclaw/plugin-sdk/channel-runtime-context. - N’envoyez pas de notifications de réacheminement appartenant au plugin depuis les gestionnaires d’approbation natifs ; le cœur gère les notifications d’acheminement vers un autre emplacement à partir des résultats de livraison réels.
- Lorsque vous transmettez
channelRuntimeàcreateChannelManager(...), fournissez une véritable surfacecreatePluginRuntime().channel; les simulations partielles sont rejetées.
Auditer le comportement de repli des wrappers Windows
openclaw/plugin-sdk/windows-spawn, les wrappers
Windows .cmd/.bat non résolus échouent désormais de manière fermée, sauf
si vous transmettez explicitement allowShellFallback: true :allowShellFallback et gérez plutôt l’erreur levée.Rechercher les imports obsolètes
Les remplacer par des imports ciblés
Remplacer les importations générales d’infra-runtime
openclaw/plugin-sdk/infra-runtime existe toujours pour assurer la
compatibilité externe, mais le nouveau code doit importer la surface ciblée
dont il a réellement besoin :infra-runtime, afin
que le code du dépôt ne puisse pas revenir à ce barrel général.Migrer les fonctions auxiliaires de routage des canaux
openclaw/plugin-sdk/channel-route.
Les anciens noms de clés de routage et de cibles comparables restent disponibles
comme alias de compatibilité :{ channel, to, accountId, threadId } de manière cohérente pour les
approbations natives, la suppression des réponses, la déduplication des
messages entrants, la livraison Cron et le routage des sessions.N’ajoutez pas de nouvelles utilisations de
ChannelMessagingAdapter.parseExplicitTarget, des fonctions auxiliaires de
routage chargé reposant sur l’analyseur (parseExplicitTargetForLoadedChannel,
resolveRouteTargetForLoadedChannel) ni de
resolveChannelRouteTargetWithParser(...) provenant de
plugin-sdk/channel-route : elles sont obsolètes et ne subsistent que pour
les anciens plugins. Les nouveaux plugins de canal doivent utiliser
messaging.targetResolver.resolveTarget(...) pour normaliser l’identifiant
de cible et fournir une solution de repli en cas d’absence dans l’annuaire,
messaging.inferTargetChatType(...) lorsque le cœur a besoin de connaître
rapidement le type de pair, et messaging.resolveOutboundSessionRoute(...)
pour déterminer l’identité native du fournisseur pour la session et le fil
de discussion.Compiler et tester
Référence des chemins d’importation
Common import path table
Common import path table
scripts/lib/plugin-sdk-entrypoints.json ;
les exportations de paquet sont générées à partir du sous-ensemble public.
Les interfaces d’assistance réservées aux plugins intégrés ont été retirées de la
carte d’exportation du SDK public, à l’exception des façades de compatibilité explicitement documentées, telles que le
shim plugin-sdk/discord obsolète, conservé pour les plugins externes qui
importent encore directement le paquet publié @openclaw/discord. Les
assistants propres à un propriétaire résident dans le paquet du plugin concerné ; le comportement partagé de l’hôte passe
par des contrats SDK génériques tels que plugin-sdk/gateway-runtime,
plugin-sdk/security-runtime et plugin-sdk/plugin-config-runtime.
Utilisez l’importation la plus ciblée correspondant à la tâche. Si vous ne trouvez pas une exportation,
consultez le code source dans src/plugin-sdk/ ou demandez aux responsables quel contrat
générique doit en être propriétaire.
Dépréciations actives
Dépréciations plus ciblées dans le SDK des plugins, le contrat des fournisseurs, la surface d’exécution et le manifeste. Chacune fonctionne encore actuellement, mais sera supprimée dans une prochaine version majeure. Chaque entrée associe l’ancienne API à son remplacement canonique.Générateurs d’aide command-auth -> command-status
Générateurs d’aide command-auth -> command-status
openclaw/plugin-sdk/command-auth) : buildCommandsMessage,
buildCommandsMessagePaginated, buildHelpMessage.Nouveau (openclaw/plugin-sdk/command-status) : mêmes signatures, mêmes
exportations ; seule l’importation se fait depuis le sous-chemin plus ciblé. command-auth
les réexporte comme stubs de compatibilité.Assistants de filtrage des mentions -> resolveInboundMentionDecision
Assistants de filtrage des mentions -> resolveInboundMentionDecision
resolveMentionGating(params) et
resolveMentionGatingWithBypass(params) depuis
openclaw/plugin-sdk/channel-inbound ou
openclaw/plugin-sdk/channel-mention-gating.Nouveau : resolveInboundMentionDecision({ facts, policy }) — un seul objet de
décision au lieu de deux formes d’appel distinctes.Adopté dans Discord, iMessage, Matrix, MS Teams, QQBot, Signal,
Telegram, WhatsApp et Zalo. Le modèle d’événement app_mention propre à Slack
n’utilise pas cet assistant.Shim d’exécution des canaux et assistants d’actions de canal
Shim d’exécution des canaux et assistants d’actions de canal
openclaw/plugin-sdk/channel-runtime est un shim de compatibilité destiné aux anciens
plugins de canal. Ne l’importez pas dans du nouveau code ; utilisez
openclaw/plugin-sdk/channel-runtime-context pour enregistrer les objets
d’exécution.Les assistants channelActions* de openclaw/plugin-sdk/channel-actions sont
obsolètes, tout comme les exportations brutes d’« actions » de canal. Exposez plutôt les capacités
par l’intermédiaire de la surface sémantique presentation : les plugins de canal
déclarent ce qu’ils affichent (cartes, boutons, sélecteurs), plutôt que les noms
d’actions brutes qu’ils acceptent.Assistant tool() du fournisseur de recherche Web -> createTool() sur le plugin
Assistant tool() du fournisseur de recherche Web -> createTool() sur le plugin
tool() de openclaw/plugin-sdk/provider-web-search.Nouveau : implémentez createTool(...) directement sur le plugin fournisseur.
OpenClaw n’a plus besoin de l’assistant du SDK pour enregistrer l’enveloppe de l’outil.Enveloppes de canal en texte brut -> BodyForAgent
Enveloppes de canal en texte brut -> BodyForAgent
api.runtime.channel.reply.formatInboundEnvelope(...) (ainsi que le
champ channelEnvelope des objets de message entrants) pour construire une enveloppe
d’invite plate en texte brut à partir des messages entrants du canal.Nouveau : BodyForAgent accompagné de blocs structurés de contexte utilisateur. Les plugins de
canal joignent les métadonnées de routage (fil, sujet, réponse à, réactions) sous forme de
champs typés, au lieu de les concaténer dans une chaîne d’invite. L’assistant
formatAgentEnvelope(...) reste pris en charge pour les enveloppes synthétisées
destinées à l’assistant, mais les enveloppes entrantes en texte brut sont en voie
de suppression.Zones concernées : inbound_claim, message_received et tout plugin de
canal personnalisé qui post-traitait l’ancien texte de l’enveloppe.Hook deactivate -> gateway_stop
Hook deactivate -> gateway_stop
api.on("deactivate", handler).Nouveau : api.on("gateway_stop", handler). Même contrat de nettoyage lors de
l’arrêt ; seul le nom du hook change.deactivate reste connecté comme alias de compatibilité obsolète jusqu’à sa
suppression après le 2026-08-16.Hook subagent_spawning -> liaison de fil par le cœur
Hook subagent_spawning -> liaison de fil par le cœur
api.on("subagent_spawning", handler) renvoyant
threadBindingReady ou deliveryOrigin.Nouveau : laissez le cœur préparer les liaisons de sous-agent thread: true via
l’adaptateur de liaison de session du canal. Utilisez api.on("subagent_spawned", handler)
uniquement pour l’observation après le lancement.subagent_spawning, PluginHookSubagentSpawningEvent,
PluginHookSubagentSpawningResult et
SubagentLifecycleHookRunner.runSubagentSpawning(...) ne subsistent que comme
surfaces de compatibilité obsolètes pendant la migration des plugins externes, et seront supprimés
après le 2026-08-30.Types de découverte des fournisseurs -> types du catalogue des fournisseurs
Types de découverte des fournisseurs -> types du catalogue des fournisseurs
ProviderCapabilities : les plugins fournisseurs
doivent utiliser des hooks de fournisseur explicites tels que buildReplayPolicy,
normalizeToolSchemas et wrapStreamFn, plutôt qu’un objet statique.Hooks de politique de réflexion -> resolveThinkingProfile
Hooks de politique de réflexion -> resolveThinkingProfile
ProviderThinkingPolicy) :
isBinaryThinking(ctx), supportsXHighThinking(ctx) et
resolveDefaultThinkingLevel(ctx).Nouveau : un unique resolveThinkingProfile(ctx) qui renvoie un
ProviderThinkingProfile avec l’id canonique, un label facultatif et une
liste ordonnée de niveaux. OpenClaw rétrograde automatiquement les anciennes valeurs
enregistrées selon le rang du profil.Le contexte comprend provider, modelId, un reasoning fusionné facultatif
et des informations compat facultatives fusionnées concernant le modèle. Les plugins fournisseurs peuvent utiliser ces
informations du catalogue pour exposer un profil propre au modèle uniquement lorsque le contrat de
requête configuré le prend en charge.Implémentez un seul hook au lieu de trois. Les anciens hooks continuent de fonctionner pendant
la période de dépréciation, mais ne sont pas composés avec le résultat du profil.Fournisseurs d’authentification externes -> contracts.externalAuthProviders
Fournisseurs d’authentification externes -> contracts.externalAuthProviders
contracts.externalAuthProviders dans le manifeste du plugin
et implémentez resolveExternalAuthProfiles(...).Recherche des variables d’environnement du fournisseur -> setup.providers[].envVars
Recherche des variables d’environnement du fournisseur -> setup.providers[].envVars
providerAuthEnvVars: { anthropic: ["ANTHROPIC_API_KEY"] }.Nouveau : reproduisez la même recherche de variables d’environnement dans setup.providers[].envVars
au sein du manifeste. Cela regroupe au même endroit les métadonnées d’environnement de configuration et d’état
et évite de démarrer l’environnement d’exécution du plugin uniquement pour répondre aux recherches de variables d’environnement.providerAuthEnvVars reste pris en charge par un adaptateur de compatibilité
jusqu’à la fin de la période de dépréciation.Enregistrement du plugin de mémoire -> registerMemoryCapability
Enregistrement du plugin de mémoire -> registerMemoryCapability
api.registerMemoryPromptSection(...),
api.registerMemoryFlushPlan(...), api.registerMemoryRuntime(...).Nouveau : un seul appel sur l’API d’état de la mémoire —
registerMemoryCapability(pluginId, { promptBuilder, flushPlanResolver, runtime }).Mêmes emplacements, un seul appel d’enregistrement. Les assistants additifs d’invite et de corpus
(registerMemoryPromptSupplement, registerMemoryCorpusSupplement) ne sont
pas concernés.API du fournisseur de plongements pour la mémoire
API du fournisseur de plongements pour la mémoire
api.registerMemoryEmbeddingProvider(...) et
contracts.memoryEmbeddingProviders.Nouveau : api.registerEmbeddingProvider(...) et
contracts.embeddingProviders.Le contrat générique du fournisseur de plongements est réutilisable en dehors de la mémoire et constitue
la voie prise en charge pour les nouveaux fournisseurs. L’API d’enregistrement propre à la mémoire
reste connectée comme compatibilité obsolète pendant la migration des fournisseurs
existants. L’inspection des plugins signale l’utilisation par des plugins non intégrés comme une dette de
compatibilité.Types de messages de session de sous-agent renommés
Types de messages de session de sous-agent renommés
src/plugins/runtime/types.ts :readSession est obsolète au profit de
getSessionMessages. Même signature ; l’ancienne méthode appelle la
nouvelle.API de fichiers de session et de transcription supprimées
API de fichiers de session et de transcription supprimées
sessions.json actifs, des chemins de transcription
JSONL ou des listes de fichiers de session. Les plugins d’exécution doivent utiliser l’identité de session et les assistants
d’exécution du SDK au lieu de résoudre ou de modifier les fichiers actifs.v2026.7.1-beta.5 importaient les quatre
assistants obsolètes ci-dessus. openclaw/plugin-sdk/session-store-runtime
conserve exactement cette passerelle jusqu’au 2026-10-12 ; les nouveaux
plugins doivent utiliser les remplacements. resolveStorePath(...) reste
un assistant SDK pris en charge et ne fait pas partie de cette dépréciation.openclaw plugins inspect --all --runtime signale les plugins non intégrés
dont les erreurs de chargement ou les diagnostics font encore référence à
ces API de fichiers supprimées. L’analyse consultative
@openclaw/plugin-inspector doit utiliser la version 0.3.17 ou une version
ultérieure afin que les analyses de paquets externes signalent également,
avant la publication, les assistants de session portant sur l’ensemble du
stockage, les assistants de chemin de fichier de session, les anciennes
cibles de fichier de transcription et les assistants de transcription de
bas niveau.runtime.tasks.flow -> runtime.tasks.managedFlows
runtime.tasks.flow -> runtime.tasks.managedFlows
runtime.tasks.flow (au singulier) renvoyait un accesseur
TaskFlow actif.Nouveau : runtime.tasks.managedFlows conserve l’environnement
d’exécution de mutation TaskFlow géré pour les plugins qui créent, mettent
à jour, annulent ou exécutent des tâches enfants à partir d’un flux.
Utilisez runtime.tasks.flows lorsque le plugin nécessite uniquement des
lectures fondées sur des DTO.Fabriques d’extensions intégrées -> intergiciel de résultats d’outil d’agent
Fabriques d’extensions intégrées -> intergiciel de résultats d’outil d’agent
api.registerEmbeddedExtensionFactory(...), réservé à l’ancien exécuteur
intégré, est remplacé par api.registerAgentToolResultMiddleware(...) avec
une liste explicite d’environnements d’exécution dans
contracts.agentToolResultMiddleware.Alias OpenClawSchemaType -> OpenClawConfig
Alias OpenClawSchemaType -> OpenClawConfig
OpenClawSchemaType, réexporté depuis openclaw/plugin-sdk, est désormais
un alias d’une ligne pour OpenClawConfig. Préférez le nom canonique.extensions/) sont suivies dans leurs propres fichiers
d’exportation api.ts et runtime-api.ts. Elles n’affectent pas les contrats
des plugins tiers et ne sont pas répertoriées ici. Si vous utilisez directement
le fichier d’exportation local d’un plugin intégré, lisez ses commentaires de
dépréciation avant d’effectuer la mise à niveau.Migration de Talk et de la voix en temps réel
Le code de voix en temps réel, de téléphonie, de réunion et de Talk dans le navigateur partage un contrôleur de session Talk exporté paropenclaw/plugin-sdk/realtime-voice. Le contrôleur possède l’enveloppe commune
des événements Talk, l’état du tour actif, l’état de capture, l’état de la
sortie audio, l’historique récent des événements et le rejet des tours
obsolètes. Les plugins fournisseurs possèdent les sessions en temps réel
propres à chaque fournisseur ; les plugins de surface possèdent les
particularités de la capture, de la lecture, de la téléphonie et des réunions.
Toutes les surfaces intégrées s’exécutent sur le contrôleur partagé : relais
du navigateur, transfert vers une salle gérée, appel vocal en temps réel,
reconnaissance vocale en continu pour les appels vocaux, Google Meet en temps
réel et mode natif « appuyer pour parler ». Le Gateway annonce un seul canal
d’événements Talk en direct dans hello-ok.features.events : talk.event.
Le nouveau code ne doit pas appeler directement
createTalkEventSequencer(...), sauf pour implémenter un adaptateur de bas
niveau ou un dispositif de test. Utilisez le contrôleur partagé afin que les
événements limités à un tour ne puissent pas être émis sans identifiant de
tour, que les appels turnEnd / turnCancel obsolètes ne puissent pas effacer
un tour actif plus récent et que les événements du cycle de vie de la sortie
audio restent cohérents entre la téléphonie, les réunions, le relais du
navigateur, le transfert vers une salle gérée et les clients Talk natifs.
Forme de l’API publique :
talk.client.create, car le navigateur prend en charge la négociation avec le
fournisseur et le transport des médias, tandis que le Gateway possède les
identifiants, les instructions et la politique des outils. talk.session.*
est la surface commune gérée par le Gateway pour le temps réel via relais du
Gateway, la transcription via relais du Gateway et les sessions STT/TTS
natives en salle gérée.
Les anciennes configurations qui placent les sélecteurs en temps réel à côté
de talk.provider / talk.providers doivent être réparées avec
openclaw doctor --fix ; l’environnement d’exécution Talk ne réinterprète pas
la configuration du fournisseur de parole/TTS comme une configuration de
fournisseur en temps réel.
Les combinaisons prises en charge par talk.session.create sont
intentionnellement peu nombreuses :
talk.realtime.* / talk.transcription.* / talk.handoff.* (toutes
supprimées) :
Calendrier de suppression
pnpm plugins:boundary-report pour savoir quelles
entrées de compatibilité arriveront le plus tôt à échéance pour les surfaces utilisées par votre plugin.
Suppression temporaire des avertissements
Ressources connexes
- Bien démarrer - créez votre premier plugin
- Présentation du SDK - référence complète des importations de sous-chemins
- Plugins de canal - création de plugins de canal
- Plugins de fournisseur - création de plugins de fournisseur
- Fonctionnement interne des plugins - présentation approfondie de l’architecture
- Manifeste de plugin - référence du schéma du manifeste