Référence pour l’objetDocumentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
api.runtime injecté dans chaque plugin pendant l’enregistrement. Utilisez ces assistants au lieu d’importer directement les éléments internes de l’hôte.
Plugins de canal
Guide étape par étape qui utilise ces assistants en contexte pour les plugins de canal.
Plugins de fournisseur
Guide étape par étape qui utilise ces assistants en contexte pour les plugins de fournisseur.
Chargement et écritures de configuration
Préférez la configuration qui a déjà été transmise au chemin d’appel actif, par exempleapi.config pendant l’enregistrement ou un argument cfg dans les callbacks de canal/fournisseur. Cela garde un instantané de processus unique qui traverse le travail au lieu de réanalyser la configuration dans les chemins critiques.
Utilisez api.runtime.config.current() uniquement lorsqu’un gestionnaire de longue durée a besoin de l’instantané actuel du processus et qu’aucune configuration n’a été transmise à cette fonction. La valeur renvoyée est en lecture seule ; clonez-la ou utilisez un assistant de mutation avant de la modifier.
Les fabriques d’outils reçoivent ctx.runtimeConfig ainsi que ctx.getRuntimeConfig(). Utilisez le getter dans le callback execute d’un outil de longue durée lorsque la configuration peut changer après la création de la définition de l’outil.
Persistez les changements avec api.runtime.config.mutateConfigFile(...) ou api.runtime.config.replaceConfigFile(...). Chaque écriture doit choisir une stratégie afterWrite explicite :
afterWrite: { mode: "auto" }laisse la décision au rechargement du planificateur du Gateway.afterWrite: { mode: "restart", reason: "..." }force un redémarrage propre lorsque l’auteur de l’écriture sait que le rechargement à chaud n’est pas sûr.afterWrite: { mode: "none", reason: "..." }supprime le rechargement/redémarrage automatique uniquement lorsque l’appelant possède le suivi.
afterWrite ainsi qu’un résumé typé followUp, afin que les appelants puissent journaliser ou tester s’ils ont demandé un redémarrage. Le Gateway reste responsable du moment où ce redémarrage se produit effectivement.
api.runtime.config.loadConfig() et api.runtime.config.writeConfigFile(...) sont des assistants de compatibilité dépréciés sous runtime-config-load-write. Ils avertissent une fois à l’exécution et restent disponibles pour les anciens plugins externes pendant la fenêtre de migration. Les plugins intégrés ne doivent pas les utiliser ; les garde-fous de frontière de configuration échouent si le code d’un plugin les appelle ou importe ces assistants depuis des sous-chemins du SDK de plugin.
Pour les imports directs du SDK, utilisez les sous-chemins de configuration ciblés au lieu du barrel de compatibilité large
openclaw/plugin-sdk/config-runtime : config-contracts pour les types, plugin-config-runtime pour les assertions de configuration déjà chargée et la recherche d’entrée de plugin, runtime-config-snapshot pour les instantanés actuels du processus, et config-mutation pour les écritures. Les tests de plugins intégrés doivent simuler directement ces sous-chemins ciblés au lieu de simuler le barrel de compatibilité large.
Le code d’exécution interne d’OpenClaw suit la même direction : charger la configuration une seule fois à la frontière du CLI, du Gateway ou du processus, puis transmettre cette valeur. Les écritures de mutation réussies actualisent l’instantané d’exécution du processus et avancent sa révision interne ; les caches de longue durée doivent s’appuyer sur la clé de cache détenue par le runtime au lieu de sérialiser localement la configuration. Les modules d’exécution de longue durée ont un scanner à tolérance zéro pour les appels ambiants à loadConfig() ; utilisez un cfg transmis, un context.getRuntimeConfig() de requête, ou getRuntimeConfig() à une frontière de processus explicite.
Les chemins d’exécution de fournisseur et de canal doivent utiliser l’instantané actif de configuration d’exécution, et non un instantané de fichier renvoyé pour la relecture ou la modification de la configuration. Les instantanés de fichier préservent les valeurs source comme les marqueurs SecretRef pour l’interface utilisateur et les écritures ; les callbacks de fournisseur ont besoin de la vue d’exécution résolue. Lorsqu’un assistant peut être appelé avec l’instantané source actif ou l’instantané d’exécution actif, passez par selectApplicableRuntimeConfig() avant de lire les identifiants.
Espaces de noms du runtime
api.runtime.agent
api.runtime.agent
Identité de l’agent, répertoires et gestion de session.Préférez
runEmbeddedAgent(...) est l’assistant neutre pour démarrer un tour normal d’agent OpenClaw depuis le code d’un plugin. Il utilise la même résolution fournisseur/modèle et la même sélection de harnais d’agent que les réponses déclenchées par canal.runEmbeddedPiAgent(...) reste disponible comme alias de compatibilité.resolveThinkingPolicy(...) renvoie les niveaux de raisonnement pris en charge par le fournisseur/modèle et le niveau par défaut facultatif. Les plugins de fournisseur possèdent le profil propre au modèle via leurs hooks de raisonnement, donc les plugins d’outils doivent appeler cet assistant de runtime au lieu d’importer ou de dupliquer des listes de fournisseurs.normalizeThinkingLevel(...) convertit le texte utilisateur comme on, x-high ou extra high vers le niveau stocké canonique avant de le vérifier par rapport à la stratégie résolue.Les assistants de stockage de session se trouvent sous api.runtime.agent.session :updateSessionStore(...) ou updateSessionStoreEntry(...) pour les écritures à l’exécution. Ils passent par l’écrivain de stockage de session détenu par le Gateway, préservent les mises à jour concurrentes et réutilisent le cache chaud. saveSessionStore(...) reste disponible pour la compatibilité et les réécritures de type maintenance hors ligne.api.runtime.agent.defaults
api.runtime.agent.defaults
Constantes de fournisseur et de modèle par défaut :
api.runtime.llm
api.runtime.llm
Exécute une complétion de texte détenue par l’hôte sans importer les éléments internes du fournisseur ni
dupliquer la préparation OpenClaw du modèle, de l’authentification ou de l’URL de base.L’assistant utilise le même chemin de préparation de complétion simple que le
runtime intégré d’OpenClaw et l’instantané de configuration d’exécution détenu par l’hôte. Les moteurs de contexte
reçoivent une capacité
llm.complete liée à la session, afin que les appels de modèle utilisent
l’agent de la session active et ne se rabattent pas silencieusement sur l’agent par défaut. Le
résultat inclut l’attribution fournisseur/modèle/agent ainsi que l’utilisation normalisée des jetons,
du cache et du coût estimé lorsqu’elle est disponible.api.runtime.subagent
api.runtime.subagent
Lance et gère les exécutions de sous-agents en arrière-plan.
deleteSession(...) peut supprimer les sessions créées par le même plugin via api.runtime.subagent.run(...). La suppression de sessions arbitraires d’utilisateur ou d’opérateur nécessite toujours une requête Gateway avec portée administrateur.api.runtime.nodes
api.runtime.nodes
Liste les nœuds connectés et invoque une commande hébergée par un nœud depuis du code de plugin chargé par le Gateway ou depuis des commandes CLI de plugin. Utilisez cela lorsqu’un plugin possède du travail local sur un appareil appairé, par exemple un pont navigateur ou audio sur un autre Mac.Dans le Gateway, ce runtime est dans le processus. Dans les commandes CLI de plugin, il appelle le Gateway configuré via RPC, de sorte que des commandes comme
openclaw googlemeet recover-tab peuvent inspecter les nœuds appairés depuis le terminal. Les commandes de nœud passent toujours par l’appairage normal des nœuds du Gateway, les listes d’autorisation de commandes, les stratégies d’invocation de nœud des plugins et la gestion de commandes locale au nœud.Les plugins qui exposent des commandes dangereuses hébergées par un nœud doivent enregistrer une stratégie d’invocation de nœud avec api.registerNodeInvokePolicy(...). La stratégie s’exécute dans le Gateway après les vérifications de liste d’autorisation des commandes et avant que la commande soit transmise au nœud, afin que les appels directs à node.invoke et les outils de plugin de plus haut niveau partagent le même chemin d’application.api.runtime.tasks.managedFlows
api.runtime.tasks.managedFlows
Lie un runtime Task Flow à une clé de session OpenClaw existante ou à un contexte d’outil de confiance, puis crée et gère des Task Flows sans transmettre un propriétaire à chaque appel.Task Flow suit un état de workflow durable à plusieurs étapes. Ce n’est pas un planificateur :
utilisez Cron ou Utilisez
api.session.workflow.scheduleSessionTurn(...) pour les réveils
futurs, puis utilisez managedFlows depuis le tour planifié lorsque ce travail
a besoin d’un état de flux, de tâches enfants, d’attentes ou d’annulation.bindSession({ sessionKey, requesterOrigin }) lorsque vous disposez déjà d’une clé de session OpenClaw fiable issue de votre propre couche de liaison. N’effectuez pas de liaison à partir d’une entrée utilisateur brute.api.runtime.tts
api.runtime.tts
Synthèse vocale.Utilise la configuration principale
messages.tts et la sélection du fournisseur. Renvoie un tampon audio PCM + la fréquence d’échantillonnage.api.runtime.mediaUnderstanding
api.runtime.mediaUnderstanding
Analyse d’images, d’audio et de vidéo.Renvoie
{ text: undefined } lorsqu’aucune sortie n’est produite (par exemple, entrée ignorée).api.runtime.stt.transcribeAudioFile(...) reste un alias de compatibilité pour api.runtime.mediaUnderstanding.transcribeAudioFile(...).api.runtime.imageGeneration
api.runtime.imageGeneration
Génération d’images.
api.runtime.webSearch
api.runtime.webSearch
Recherche Web.
api.runtime.media
api.runtime.media
Utilitaires média de bas niveau.
api.runtime.config
api.runtime.config
Instantané de la configuration d’exécution actuelle et écritures de configuration transactionnelles. Préférez
la configuration qui a déjà été transmise au chemin d’appel actif ; utilisez
current() uniquement lorsque le gestionnaire a directement besoin de l’instantané du processus.mutateConfigFile(...) et replaceConfigFile(...) renvoient une valeur followUp,
par exemple { mode: "restart", requiresRestart: true, reason },
qui enregistre l’intention de l’auteur sans retirer au gateway le contrôle du redémarrage.api.runtime.system
api.runtime.system
Utilitaires au niveau système.
api.runtime.events
api.runtime.events
Abonnements aux événements.
api.runtime.logging
api.runtime.logging
Journalisation.
api.runtime.modelAuth
api.runtime.modelAuth
Résolution de l’authentification des modèles et des fournisseurs.
api.runtime.state
api.runtime.state
Résolution du répertoire d’état et stockage clé-valeur adossé à SQLite.Les stockages clé-valeur survivent aux redémarrages et sont isolés par l’id de Plugin lié à l’exécution. Utilisez
registerIfAbsent(...) pour les revendications de déduplication atomiques : la méthode renvoie true lorsque la clé était absente ou expirée et a été enregistrée, ou false lorsqu’une valeur active existe déjà sans écraser sa valeur, son heure de création ni son TTL. Limites : maxEntries par espace de noms, 1 000 lignes actives par Plugin, valeurs JSON inférieures à 64 Ko et expiration TTL facultative.api.runtime.tools
api.runtime.tools
Fabriques d’outils mémoire et CLI.
api.runtime.channel
api.runtime.channel
Assistants d’exécution propres aux canaux (disponibles lorsqu’un Plugin de canal est chargé).Assistants de mention disponibles :
api.runtime.channel.mentions est la surface partagée de politique de mention entrante pour les Plugins de canal groupés qui utilisent l’injection d’exécution :buildMentionRegexesmatchesMentionPatternsmatchesMentionWithExplicitimplicitMentionKindWhenresolveInboundMentionDecision
api.runtime.channel.mentions n’expose volontairement pas les anciens assistants de compatibilité resolveMentionGating*. Préférez le chemin normalisé { facts, policy }.Stockage des références d’exécution
UtilisezcreatePluginRuntimeStore pour stocker la référence d’exécution afin de l’utiliser en dehors du rappel register :
Préférez
pluginId pour l’identité du stockage d’exécution. La forme de plus bas niveau key est destinée aux cas peu courants où un Plugin a intentionnellement besoin de plusieurs emplacements d’exécution.Autres champs api de premier niveau
Au-delà de api.runtime, l’objet API fournit également :
Identifiant du Plugin.
Nom d’affichage du Plugin.
Instantané de la configuration actuelle (instantané actif du runtime en mémoire lorsqu’il est disponible).
Configuration propre au Plugin provenant de
plugins.entries.<id>.config.Journaliseur à portée limitée (
debug, info, warn, error).Mode de chargement actuel ;
"setup-runtime" est la fenêtre légère de démarrage/configuration avant l’entrée complète.Résout un chemin relatif à la racine du Plugin.
Associé
- Internes du Plugin — modèle de capacités et registre
- Points d’entrée du SDK — options de
definePluginEntry - Vue d’ensemble du SDK — référence des sous-chemins