Referenz für dasDocumentation 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-Objekt, das bei der Registrierung in jedes Plugin injiziert wird. Verwenden Sie diese Hilfsfunktionen, statt Host-Interna direkt zu importieren.
Kanal-Plugins
Schritt-für-Schritt-Anleitung, die diese Hilfsfunktionen im Kontext von Kanal-Plugins verwendet.
Provider-Plugins
Schritt-für-Schritt-Anleitung, die diese Hilfsfunktionen im Kontext von Provider-Plugins verwendet.
Laden und Schreiben der Konfiguration
Bevorzugen Sie Konfiguration, die bereits an den aktiven Aufrufpfad übergeben wurde, zum Beispielapi.config während der Registrierung oder ein cfg-Argument in Kanal-/Provider-Callbacks. Dadurch fließt ein Prozess-Snapshot durch die Arbeit, statt Konfiguration in heißen Pfaden erneut zu parsen.
Verwenden Sie api.runtime.config.current() nur, wenn ein langlebiger Handler den aktuellen Prozess-Snapshot benötigt und keine Konfiguration an diese Funktion übergeben wurde. Der zurückgegebene Wert ist schreibgeschützt; klonen Sie ihn oder verwenden Sie vor der Bearbeitung eine Mutations-Hilfsfunktion.
Tool-Fabriken erhalten ctx.runtimeConfig sowie ctx.getRuntimeConfig(). Verwenden Sie den Getter im execute-Callback eines langlebigen Tools, wenn sich die Konfiguration ändern kann, nachdem die Tool-Definition erstellt wurde.
Persistieren Sie Änderungen mit api.runtime.config.mutateConfigFile(...) oder api.runtime.config.replaceConfigFile(...). Jeder Schreibvorgang muss eine explizite afterWrite-Policy wählen:
afterWrite: { mode: "auto" }lässt den Reload-Planer des Gateway entscheiden.afterWrite: { mode: "restart", reason: "..." }erzwingt einen sauberen Neustart, wenn der schreibende Aufrufer weiß, dass Hot Reload unsicher ist.afterWrite: { mode: "none", reason: "..." }unterdrückt automatisches Reloaden/Neustarten nur, wenn der Aufrufer die Nachbearbeitung verantwortet.
afterWrite sowie eine typisierte followUp-Zusammenfassung zurück, damit Aufrufer protokollieren oder testen können, ob sie einen Neustart angefordert haben. Das Gateway entscheidet weiterhin, wann dieser Neustart tatsächlich erfolgt.
api.runtime.config.loadConfig() und api.runtime.config.writeConfigFile(...) sind veraltete Kompatibilitäts-Hilfsfunktionen unter runtime-config-load-write. Sie warnen einmal zur Laufzeit und bleiben während des Migrationsfensters für alte externe Plugins verfügbar. Gebündelte Plugins dürfen sie nicht verwenden; die Konfigurationsgrenzen-Prüfungen schlagen fehl, wenn Plugin-Code sie aufruft oder diese Hilfsfunktionen aus Unterpfaden des Plugin SDK importiert.
Verwenden Sie bei direkten SDK-Importen die fokussierten Konfigurations-Unterpfade statt des breiten
Kompatibilitäts-Barrels openclaw/plugin-sdk/config-runtime: config-contracts für
Typen, plugin-config-runtime für Assertions zu bereits geladener Konfiguration und die Plugin-
Eintragssuche, runtime-config-snapshot für aktuelle Prozess-Snapshots und
config-mutation für Schreibvorgänge. Tests gebündelter Plugins sollten diese fokussierten
Unterpfade direkt mocken, statt das breite Kompatibilitäts-Barrel zu mocken.
Interner OpenClaw-Laufzeitcode folgt derselben Richtung: Konfiguration einmal an der CLI-, Gateway- oder Prozessgrenze laden und diesen Wert dann weiterreichen. Erfolgreiche Mutationsschreibvorgänge aktualisieren den Prozess-Laufzeit-Snapshot und erhöhen seine interne Revision; langlebige Caches sollten den Laufzeit-eigenen Cache-Schlüssel verwenden, statt Konfiguration lokal zu serialisieren. Langlebige Laufzeitmodule haben einen Null-Toleranz-Scanner für umgebende loadConfig()-Aufrufe; verwenden Sie ein übergebenes cfg, ein Anfrage-context.getRuntimeConfig() oder getRuntimeConfig() an einer expliziten Prozessgrenze.
Provider- und Kanal-Ausführungspfade müssen den aktiven Laufzeit-Konfigurations-Snapshot verwenden, nicht einen Datei-Snapshot, der für Konfigurations-Rücklesen oder Bearbeitung zurückgegeben wurde. Datei-Snapshots erhalten Quellwerte wie SecretRef-Markierungen für UI und Schreibvorgänge; Provider-Callbacks benötigen die aufgelöste Laufzeitansicht. Wenn eine Hilfsfunktion entweder mit dem aktiven Quell-Snapshot oder dem aktiven Laufzeit-Snapshot aufgerufen werden kann, leiten Sie vor dem Lesen von Anmeldedaten über selectApplicableRuntimeConfig() weiter.
Laufzeit-Namespaces
api.runtime.agent
api.runtime.agent
Agent-Identität, Verzeichnisse und Sitzungsverwaltung.Bevorzugen Sie
runEmbeddedAgent(...) ist die neutrale Hilfsfunktion, um aus Plugin-Code eine normale OpenClaw-Agent-Runde zu starten. Sie verwendet dieselbe Provider-/Modellauflösung und Agent-Harness-Auswahl wie kanalgetriggerte Antworten.runEmbeddedPiAgent(...) bleibt als Kompatibilitätsalias erhalten.resolveThinkingPolicy(...) gibt die vom Provider/Modell unterstützten Thinking-Level und den optionalen Standardwert zurück. Provider-Plugins besitzen das modellspezifische Profil über ihre Thinking-Hooks, daher sollten Tool-Plugins diese Laufzeit-Hilfsfunktion aufrufen, statt Provider-Listen zu importieren oder zu duplizieren.normalizeThinkingLevel(...) konvertiert Benutzereingaben wie on, x-high oder extra high vor der Prüfung gegen die aufgelöste Policy in das kanonisch gespeicherte Level.Hilfsfunktionen für den Sitzungsspeicher befinden sich unter api.runtime.agent.session:updateSessionStore(...) oder updateSessionStoreEntry(...) für Laufzeit-Schreibvorgänge. Sie laufen über den Gateway-eigenen Sitzungsspeicher-Writer, erhalten parallele Aktualisierungen und verwenden den Hot Cache erneut. saveSessionStore(...) bleibt für Kompatibilität und Offline-Wartungs-Rewrites verfügbar.api.runtime.agent.defaults
api.runtime.agent.defaults
Standardmodell- und Provider-Konstanten:
api.runtime.llm
api.runtime.llm
Führen Sie eine Host-eigene Textvervollständigung aus, ohne Provider-Interna zu importieren oder
OpenClaw-Modell-/Auth-/Basis-URL-Vorbereitung zu duplizieren.Die Hilfsfunktion verwendet denselben Vorbereitungspfad für einfache Vervollständigungen wie die
integrierte OpenClaw-Laufzeit und den Host-eigenen Laufzeit-Konfigurations-Snapshot. Kontext-Engines
erhalten eine sitzungsgebundene
llm.complete-Fähigkeit, sodass Modellaufrufe den
Agent der aktiven Sitzung verwenden und nicht unbemerkt auf den Standard-Agent zurückfallen. Das
Ergebnis enthält Provider-/Modell-/Agent-Zuordnung sowie normalisierte Token-,
Cache- und geschätzte Kostennutzung, wenn verfügbar.api.runtime.subagent
api.runtime.subagent
Starten und verwalten Sie Subagent-Läufe im Hintergrund.
deleteSession(...) kann Sitzungen löschen, die dasselbe Plugin über api.runtime.subagent.run(...) erstellt hat. Das Löschen beliebiger Benutzer- oder Operator-Sitzungen erfordert weiterhin eine Gateway-Anfrage mit Admin-Scope.api.runtime.nodes
api.runtime.nodes
Listen Sie verbundene Nodes auf und rufen Sie einen Node-Host-Befehl aus Gateway-geladenem Plugin-Code oder aus Plugin-CLI-Befehlen auf. Verwenden Sie dies, wenn ein Plugin lokale Arbeit auf einem gekoppelten Gerät besitzt, zum Beispiel eine Browser- oder Audio-Bridge auf einem anderen Mac.Innerhalb des Gateway läuft diese Laufzeit im Prozess. In Plugin-CLI-Befehlen ruft sie das konfigurierte Gateway über RPC auf, sodass Befehle wie
openclaw googlemeet recover-tab gekoppelte Nodes vom Terminal aus prüfen können. Node-Befehle durchlaufen weiterhin normales Gateway-Node-Pairing, Befehls-Allowlists, Plugin-Node-Invoke-Policies und node-lokale Befehlsbehandlung.Plugins, die gefährliche Node-Host-Befehle bereitstellen, sollten eine Node-Invoke-Policy mit api.registerNodeInvokePolicy(...) registrieren. Die Policy läuft im Gateway nach den Befehls-Allowlist-Prüfungen und bevor der Befehl an die Node weitergeleitet wird, sodass direkte node.invoke-Aufrufe und höherstufige Plugin-Tools denselben Durchsetzungspfad teilen.api.runtime.tasks.managedFlows
api.runtime.tasks.managedFlows
Binden Sie eine Task-Flow-Laufzeit an einen vorhandenen OpenClaw-Sitzungsschlüssel oder einen vertrauenswürdigen Tool-Kontext und erstellen und verwalten Sie dann Task Flows, ohne bei jedem Aufruf einen Owner zu übergeben.Task Flow verfolgt dauerhaften Zustand mehrstufiger Workflows. Es ist kein Scheduler:
Verwenden Sie Cron oder Verwenden Sie
api.session.workflow.scheduleSessionTurn(...) für zukünftige
Wakeups und verwenden Sie dann managedFlows aus der geplanten Runde, wenn diese Arbeit
Flow-Zustand, Child-Tasks, Warteoperationen oder Abbruch benötigt.bindSession({ sessionKey, requesterOrigin }), wenn Sie bereits einen vertrauenswürdigen OpenClaw-Sitzungsschlüssel aus Ihrer eigenen Binding-Schicht haben. Binden Sie nicht aus rohen Benutzereingaben.api.runtime.tts
api.runtime.tts
Text-to-Speech-Synthese.Verwendet die Core-Konfiguration
messages.tts und die Provider-Auswahl. Gibt PCM-Audiopuffer + Abtastrate zurück.api.runtime.mediaUnderstanding
api.runtime.mediaUnderstanding
Bild-, Audio- und Videoanalyse.Gibt
{ text: undefined } zurück, wenn keine Ausgabe erzeugt wird (z. B. bei übersprungener Eingabe).api.runtime.stt.transcribeAudioFile(...) bleibt als Kompatibilitätsalias für api.runtime.mediaUnderstanding.transcribeAudioFile(...) erhalten.api.runtime.imageGeneration
api.runtime.imageGeneration
Bildgenerierung.
api.runtime.webSearch
api.runtime.webSearch
Websuche.
api.runtime.media
api.runtime.media
Low-Level-Medienwerkzeuge.
api.runtime.config
api.runtime.config
Aktueller Laufzeit-Konfigurationssnapshot und transaktionale Konfigurationsschreibvorgänge. Bevorzugen Sie
Konfiguration, die bereits in den aktiven Aufrufpfad übergeben wurde; verwenden Sie
current() nur, wenn der Handler den Prozesssnapshot direkt benötigt.mutateConfigFile(...) und replaceConfigFile(...) geben einen followUp-
Wert zurück, zum Beispiel { mode: "restart", requiresRestart: true, reason },
der die Absicht des Schreibers festhält, ohne dem
Gateway die Neustartkontrolle zu entziehen.api.runtime.system
api.runtime.system
Werkzeuge auf Systemebene.
api.runtime.events
api.runtime.events
Ereignisabonnements.
api.runtime.logging
api.runtime.logging
Protokollierung.
api.runtime.modelAuth
api.runtime.modelAuth
Auflösung der Modell- und Provider-Authentifizierung.
api.runtime.state
api.runtime.state
Auflösung des Zustandsverzeichnisses und SQLite-gestützter schlüsselbasierter Speicher.Schlüsselbasierte Speicher überstehen Neustarts und sind durch die laufzeitgebundene Plugin-ID isoliert. Verwenden Sie
registerIfAbsent(...) für atomare Deduplizierungs-Claims: Es gibt true zurück, wenn der Schlüssel fehlte oder abgelaufen war und registriert wurde, oder false, wenn bereits ein aktiver Wert vorhanden ist, ohne dessen Wert, Erstellungszeit oder TTL zu überschreiben. Grenzen: maxEntries pro Namespace, 1.000 aktive Zeilen pro Plugin, JSON-Werte unter 64 KB und optionaler TTL-Ablauf.api.runtime.tools
api.runtime.tools
Memory-Tool-Factories und CLI.
api.runtime.channel
api.runtime.channel
Channelspezifische Laufzeit-Hilfsfunktionen (verfügbar, wenn ein Channel-Plugin geladen ist).Verfügbare Erwähnungs-Hilfsfunktionen:
api.runtime.channel.mentions ist die gemeinsame Eingangs-Erwähnungsrichtlinienoberfläche für gebündelte Channel-Plugins, die Laufzeitinjektion verwenden:buildMentionRegexesmatchesMentionPatternsmatchesMentionWithExplicitimplicitMentionKindWhenresolveInboundMentionDecision
api.runtime.channel.mentions legt die älteren resolveMentionGating*-Kompatibilitäts-Hilfsfunktionen absichtlich nicht offen. Bevorzugen Sie den normalisierten { facts, policy }-Pfad.Laufzeitreferenzen speichern
Verwenden SiecreatePluginRuntimeStore, um die Laufzeitreferenz für die Verwendung außerhalb des register-Callbacks zu speichern:
Bevorzugen Sie
pluginId für die Runtime-Store-Identität. Die Low-Level-Form key ist für ungewöhnliche Fälle gedacht, in denen ein Plugin absichtlich mehr als einen Laufzeit-Slot benötigt.Weitere Top-Level-api-Felder
Über api.runtime hinaus stellt das API-Objekt außerdem Folgendes bereit:
Plugin-ID.
Anzeigename des Plugins.
Aktueller Konfigurations-Snapshot (aktiver In-Memory-Runtime-Snapshot, wenn verfügbar).
Plugin-spezifische Konfiguration aus
plugins.entries.<id>.config.Bereichsgebundener Logger (
debug, info, warn, error).Aktueller Lademodus;
"setup-runtime" ist das leichtgewichtige Start-/Setup-Fenster vor dem vollständigen Entry.Löst einen Pfad relativ zum Plugin-Root auf.
Verwandt
- Plugin-Interna — Capability-Modell und Registry
- SDK-Einstiegspunkte —
definePluginEntry-Optionen - SDK-Überblick — Subpath-Referenz