Riferimento per l’oggettoDocumentation 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 iniettato in ogni Plugin durante la registrazione. Usa questi helper invece di importare direttamente gli internals dell’host.
Plugin di canale
Guida dettagliata che usa questi helper nel contesto dei Plugin di canale.
Plugin provider
Guida dettagliata che usa questi helper nel contesto dei Plugin provider.
Caricamento e scritture della configurazione
Preferisci la configurazione già passata al percorso di chiamata attivo, per esempioapi.config durante la registrazione o un argomento cfg nei callback di canale/provider. Questo mantiene un unico snapshot del processo attraverso il lavoro invece di rieseguire il parsing della configurazione nei percorsi critici.
Usa api.runtime.config.current() solo quando un handler di lunga durata ha bisogno dello snapshot corrente del processo e a quella funzione non è stata passata alcuna configurazione. Il valore restituito è readonly; clonalo o usa un helper di mutazione prima di modificarlo.
Le factory degli strumenti ricevono ctx.runtimeConfig più ctx.getRuntimeConfig(). Usa il getter dentro il callback execute di uno strumento di lunga durata quando la configurazione può cambiare dopo la creazione della definizione dello strumento.
Rendi persistenti le modifiche con api.runtime.config.mutateConfigFile(...) o api.runtime.config.replaceConfigFile(...). Ogni scrittura deve scegliere una policy afterWrite esplicita:
afterWrite: { mode: "auto" }lascia decidere al ricaricamento planner del Gateway.afterWrite: { mode: "restart", reason: "..." }forza un riavvio pulito quando chi scrive sa che l’hot reload non è sicuro.afterWrite: { mode: "none", reason: "..." }sopprime ricaricamento/riavvio automatici solo quando il chiamante possiede il follow-up.
afterWrite più un riepilogo followUp tipizzato, così i chiamanti possono registrare nei log o testare se hanno richiesto un riavvio. Il Gateway resta comunque responsabile di quando quel riavvio avviene effettivamente.
api.runtime.config.loadConfig() e api.runtime.config.writeConfigFile(...) sono helper di compatibilità deprecati sotto runtime-config-load-write. Emettono un avviso una sola volta a runtime e restano disponibili per i vecchi Plugin esterni durante la finestra di migrazione. I Plugin in bundle non devono usarli; le guardie del confine di configurazione falliscono se il codice del Plugin li chiama o importa quegli helper dai sottopercorsi del Plugin SDK.
Per import diretti dell’SDK, usa i sottopercorsi di configurazione mirati invece del barrel di compatibilità ampio
openclaw/plugin-sdk/config-runtime: config-contracts per i
tipi, plugin-config-runtime per le asserzioni sulla configurazione già caricata e la ricerca
delle entry dei Plugin, runtime-config-snapshot per gli snapshot correnti del processo, e
config-mutation per le scritture. I test dei Plugin in bundle dovrebbero fare mock direttamente di questi
sottopercorsi mirati invece di fare mock del barrel di compatibilità ampio.
Il codice runtime interno di OpenClaw segue la stessa direzione: carica la configurazione una volta al confine della CLI, del Gateway o del processo, poi passa quel valore attraverso il flusso. Le scritture di mutazione riuscite aggiornano lo snapshot runtime del processo e avanzano la sua revisione interna; le cache di lunga durata dovrebbero usare come chiave la chiave cache posseduta dal runtime invece di serializzare localmente la configurazione. I moduli runtime di lunga durata hanno uno scanner a tolleranza zero per le chiamate ambientali a loadConfig(); usa un cfg passato, un context.getRuntimeConfig() della richiesta o getRuntimeConfig() a un confine esplicito del processo.
I percorsi di esecuzione di provider e canali devono usare lo snapshot di configurazione runtime attivo, non uno snapshot di file restituito per rilettura o modifica della configurazione. Gli snapshot di file preservano valori sorgente come i marker SecretRef per UI e scritture; i callback provider hanno bisogno della vista runtime risolta. Quando un helper può essere chiamato sia con lo snapshot sorgente attivo sia con lo snapshot runtime attivo, passa attraverso selectApplicableRuntimeConfig() prima di leggere le credenziali.
Namespace runtime
api.runtime.agent
api.runtime.agent
Identità dell’agente, directory e gestione delle sessioni.Preferisci
runEmbeddedAgent(...) è l’helper neutrale per avviare un normale turno di agente OpenClaw dal codice del Plugin. Usa la stessa risoluzione provider/model e la stessa selezione dell’agent harness delle risposte attivate dal canale.runEmbeddedPiAgent(...) rimane come alias di compatibilità.resolveThinkingPolicy(...) restituisce i livelli di ragionamento supportati dal provider/model e l’eventuale predefinito. I Plugin provider possiedono il profilo specifico del modello tramite i propri hook di ragionamento, quindi i Plugin di strumenti dovrebbero chiamare questo helper runtime invece di importare o duplicare gli elenchi dei provider.normalizeThinkingLevel(...) converte testo utente come on, x-high o extra high nel livello canonico memorizzato prima di verificarlo rispetto alla policy risolta.Gli helper dello store delle sessioni sono sotto api.runtime.agent.session:updateSessionStore(...) o updateSessionStoreEntry(...) per le scritture runtime. Passano attraverso il writer dello store delle sessioni posseduto dal Gateway, preservano gli aggiornamenti concorrenti e riutilizzano la cache hot. saveSessionStore(...) resta disponibile per compatibilità e riscritture in stile manutenzione offline.api.runtime.agent.defaults
api.runtime.agent.defaults
Costanti predefinite di modello e provider:
api.runtime.llm
api.runtime.llm
Esegui un completamento testuale posseduto dall’host senza importare internals del provider o
duplicare la preparazione di modello/autenticazione/base URL di OpenClaw.L’helper usa lo stesso percorso di preparazione dei completamenti semplici del
runtime integrato di OpenClaw e lo snapshot di configurazione runtime posseduto dall’host. I motori di contesto
ricevono una capability
llm.complete vincolata alla sessione, quindi le chiamate al modello usano
l’agente della sessione attiva e non ricadono silenziosamente sull’agente predefinito. Il
risultato include attribuzione provider/model/agente più uso normalizzato di token,
cache e costo stimato quando disponibile.api.runtime.subagent
api.runtime.subagent
Avvia e gestisci esecuzioni subagent in background.
deleteSession(...) può eliminare sessioni create dallo stesso Plugin tramite api.runtime.subagent.run(...). L’eliminazione di sessioni arbitrarie di utenti o operatori richiede comunque una richiesta Gateway con ambito admin.api.runtime.nodes
api.runtime.nodes
Elenca i nodi connessi e invoca un comando ospitato dal nodo dal codice del Plugin caricato dal Gateway o dai comandi CLI del Plugin. Usalo quando un Plugin possiede lavoro locale su un dispositivo associato, per esempio un bridge browser o audio su un altro Mac.Dentro il Gateway questo runtime è in-process. Nei comandi CLI del Plugin chiama il Gateway configurato tramite RPC, quindi comandi come
openclaw googlemeet recover-tab possono ispezionare i nodi associati dal terminale. I comandi Node passano comunque attraverso il normale pairing dei nodi del Gateway, le allowlist dei comandi, le policy node-invoke dei Plugin e la gestione dei comandi locale al nodo.I Plugin che espongono comandi per host Node pericolosi dovrebbero registrare una policy node-invoke con api.registerNodeInvokePolicy(...). La policy viene eseguita nel Gateway dopo i controlli della allowlist dei comandi e prima che il comando venga inoltrato al nodo, quindi le chiamate dirette a node.invoke e gli strumenti Plugin di livello superiore condividono lo stesso percorso di enforcement.api.runtime.tasks.managedFlows
api.runtime.tasks.managedFlows
Associa un runtime Task Flow a una chiave di sessione OpenClaw esistente o a un contesto strumento attendibile, poi crea e gestisci Task Flow senza passare un owner a ogni chiamata.Task Flow traccia lo stato durevole dei workflow multi-step. Non è uno scheduler:
usa Cron o Usa
api.session.workflow.scheduleSessionTurn(...) per i risvegli
futuri, poi usa managedFlows dal turno pianificato quando quel lavoro
richiede stato del flow, attività figlie, attese o annullamento.bindSession({ sessionKey, requesterOrigin }) quando hai già una chiave di sessione OpenClaw attendibile dal tuo livello di binding. Non effettuare il binding da input utente grezzo.api.runtime.tts
api.runtime.tts
Sintesi vocale da testo.Usa la configurazione core
messages.tts e la selezione del provider. Restituisce un buffer audio PCM + frequenza di campionamento.api.runtime.mediaUnderstanding
api.runtime.mediaUnderstanding
Analisi di immagini, audio e video.Restituisce
{ text: undefined } quando non viene prodotto alcun output (ad esempio input saltato).api.runtime.stt.transcribeAudioFile(...) rimane un alias di compatibilità per api.runtime.mediaUnderstanding.transcribeAudioFile(...).api.runtime.imageGeneration
api.runtime.imageGeneration
Generazione di immagini.
api.runtime.webSearch
api.runtime.webSearch
Ricerca web.
api.runtime.media
api.runtime.media
Utilità multimediali di basso livello.
api.runtime.config
api.runtime.config
Snapshot della configurazione runtime corrente e scritture di configurazione transazionali. Preferisci
la configurazione già passata nel percorso di chiamata attivo; usa
current() solo quando il gestore ha bisogno direttamente dello snapshot del processo.mutateConfigFile(...) e replaceConfigFile(...) restituiscono un valore
followUp, per esempio { mode: "restart", requiresRestart: true, reason },
che registra l’intento dello scrivente senza sottrarre al
Gateway il controllo del riavvio.api.runtime.system
api.runtime.system
Utilità a livello di sistema.
api.runtime.events
api.runtime.events
Sottoscrizioni agli eventi.
api.runtime.logging
api.runtime.logging
Logging.
api.runtime.modelAuth
api.runtime.modelAuth
Risoluzione dell’autenticazione di modello e provider.
api.runtime.state
api.runtime.state
Risoluzione della directory di stato e archiviazione con chiavi basata su SQLite.Gli store con chiavi sopravvivono ai riavvii e sono isolati dall’id del Plugin associato al runtime. Usa
registerIfAbsent(...) per rivendicazioni atomiche di deduplicazione: restituisce true quando la chiave era assente o scaduta ed è stata registrata, oppure false quando esiste già un valore attivo senza sovrascriverne valore, ora di creazione o TTL. Limiti: maxEntries per namespace, 1.000 righe attive per Plugin, valori JSON inferiori a 64 KB e scadenza TTL facoltativa.api.runtime.tools
api.runtime.tools
Factory di strumenti di memoria e CLI.
api.runtime.channel
api.runtime.channel
Helper runtime specifici del canale (disponibili quando viene caricato un Plugin di canale).Helper di menzione disponibili:
api.runtime.channel.mentions è la superficie condivisa delle policy di menzione in ingresso per i Plugin di canale in bundle che usano l’iniezione runtime:buildMentionRegexesmatchesMentionPatternsmatchesMentionWithExplicitimplicitMentionKindWhenresolveInboundMentionDecision
api.runtime.channel.mentions intenzionalmente non espone i vecchi helper di compatibilità resolveMentionGating*. Preferisci il percorso normalizzato { facts, policy }.Archiviazione dei riferimenti runtime
UsacreatePluginRuntimeStore per archiviare il riferimento runtime da usare fuori dalla callback register:
Preferisci
pluginId per l’identità del runtime store. La forma di livello inferiore key è per casi non comuni in cui un Plugin necessita intenzionalmente di più di uno slot runtime.Altri campi api di primo livello
Oltre a api.runtime, l’oggetto API fornisce anche:
ID del Plugin.
Nome visualizzato del Plugin.
Snapshot della configurazione corrente (snapshot runtime attivo in memoria quando disponibile).
Configurazione specifica del Plugin da
plugins.entries.<id>.config.Logger con ambito (
debug, info, warn, error).Modalità di caricamento corrente;
"setup-runtime" è la finestra leggera di avvio/configurazione precedente all’entry completa.Risolve un percorso relativo alla radice del Plugin.
Correlati
- Interni del Plugin — modello di capability e registro
- Punti di ingresso SDK — opzioni di
definePluginEntry - Panoramica dell’SDK — riferimento ai sottopercorsi