clawhub: quando si desidera la risoluzione tramite ClawHub.
Requisiti
- Node 22.22.3+, Node 24.15+ o Node 25.9+ e
npmopnpm. - Moduli TypeScript ESM.
- Per lavorare sui Plugin inclusi nel repository, clonare il repository ed eseguire
pnpm install. Lo sviluppo dei Plugin dal checkout dei sorgenti supporta solo pnpm perché OpenClaw rileva i Plugin inclusi dai pacchetti dell’area di lavoroextensions/*.
Scegliere la struttura del Plugin
Plugin per canali
Connettere OpenClaw a una piattaforma di messaggistica.
Plugin provider
Aggiungere un provider di modelli, contenuti multimediali, ricerca, recupero, sintesi vocale o comunicazione in tempo reale.
Plugin backend CLI
Eseguire una CLI di IA locale tramite il fallback dei modelli OpenClaw.
Plugin per strumenti
Registrare gli strumenti dell’agente.
Avvio rapido
Creare un Plugin per strumenti minimale registrando un solo strumento obbligatorio dell’agente. Questa è la struttura di Plugin utile più semplice e comprende il pacchetto, il manifesto, il punto di ingresso e la verifica locale.1
Creare i metadati del pacchetto
contracts.tools affinché OpenClaw possa rilevarne la proprietà senza
caricare preventivamente ogni runtime dei Plugin. Impostare activation.onStartup
intenzionalmente; questo esempio viene caricato all’avvio del Gateway.Anche le superfici dei Plugin considerate attendibili dall’host sono controllate dal manifesto e richiedono una
dichiarazione esplicita per i Plugin installati: api.registerAgentToolResultMiddleware(...)
richiede che ogni runtime di destinazione sia elencato in contracts.agentToolResultMiddleware,
mentre api.registerTrustedToolPolicy(...) richiede ogni ID di criterio in
contracts.trustedToolPolicies. Queste dichiarazioni mantengono allineate
l’ispezione al momento dell’installazione e la registrazione in fase di runtime.Per tutti i campi del manifesto, consultare Manifesto del Plugin.2
Registrare lo strumento
index.ts
definePluginEntry per i Plugin non destinati ai canali. I Plugin per canali usano invece
defineChannelPluginEntry da openclaw/plugin-sdk/core.3
Testare il runtime
Per un Plugin installato o esterno, esaminare il runtime caricato:Se il Plugin registra un comando CLI, eseguire anche tale comando e verificarne
l’output, ad esempio
openclaw demo-plugin ping.Per un Plugin incluso in questo repository, OpenClaw rileva i pacchetti dei Plugin
dal checkout dei sorgenti nell’area di lavoro extensions/*. Eseguire il test mirato
più pertinente:4
Testare l'installazione del pacchetto
Prima di pubblicare un Plugin pronto per essere distribuito come pacchetto, testare la stessa modalità di installazione che
riceveranno gli utenti. Aggiungere innanzitutto un passaggio di compilazione, indirizzare le voci di runtime come
openclaw.extensions al JavaScript compilato, ad esempio ./dist/index.js, e assicurarsi
che npm pack includa tale output dist/. Le voci dei sorgenti TypeScript sono
destinate esclusivamente ai checkout dei sorgenti e ai percorsi di sviluppo locale.Quindi creare il pacchetto del Plugin e installare il tarball con npm-pack::npm-pack: usa il progetto npm per singolo Plugin gestito da OpenClaw, quindi rileva
gli errori nelle dipendenze di runtime che i test dal checkout dei sorgenti possono nascondere. Dimostra
la struttura del pacchetto e delle dipendenze, non l’attendibilità ufficiale collegata al catalogo.
Le importazioni di runtime devono trovarsi in dependencies o optionalDependencies;
le dipendenze presenti soltanto in devDependencies non verranno installate per il
progetto di runtime gestito.Non usare l’installazione diretta da archivio o percorso come verifica finale del comportamento
ufficiale o privilegiato di un Plugin. I sorgenti diretti sono utili per il debug locale, ma
non dimostrano lo stesso percorso delle dipendenze delle installazioni tramite npm o ClawHub. Se
il Plugin si basa sullo stato di Plugin ufficiale attendibile, aggiungere una seconda verifica
tramite un’installazione ufficiale supportata dal catalogo o un percorso di pacchetto pubblicato che
registri l’attendibilità ufficiale. Consultare
Risoluzione delle dipendenze dei Plugin per
i dettagli sulla radice di installazione e sulla proprietà delle dipendenze.5
Pubblicare
Convalidare il pacchetto prima della pubblicazione:I frammenti canonici dei pacchetti ClawHub si trovano in
docs/snippets/plugin-publish/.6
Installare
Installare il pacchetto pubblicato tramite ClawHub:
Registrazione degli strumenti
Gli strumenti possono essere obbligatori o facoltativi. Gli strumenti obbligatori sono sempre disponibili quando il Plugin è abilitato. Gli strumenti facoltativi richiedono il consenso esplicito dell’utente prima che OpenClaw carichi il runtime del Plugin proprietario. Le factory degli strumenti ricevono un contesto di runtime attendibile, che includedeliveryContext,
nativeChannelId per la conversazione attiva sulla piattaforma, quando disponibile, e
requesterSenderId.
api.registerTool(...) deve essere dichiarato anche nel
manifesto del Plugin:
tools.allow:
name non vuoto mancante,
un execute che non è una funzione o un descrittore di strumento privo di un oggetto parameters.
Le factory degli strumenti ricevono un oggetto di contesto fornito dal runtime. Usare ctx.activeModel
quando uno strumento deve registrare, mostrare o adattarsi al modello attivo per il turno
corrente; può includere provider, modelId e modelRef. Considerarlo
un metadato informativo di runtime, non un confine di sicurezza rispetto all’operatore
locale, al codice dei Plugin installati o a un runtime OpenClaw modificato. Gli strumenti
locali sensibili devono comunque richiedere il consenso esplicito del Plugin o dell’operatore e
interrompersi in sicurezza quando i metadati del modello attivo sono mancanti o inadeguati.
Il manifesto dichiara la proprietà e il rilevamento; l’esecuzione richiama comunque l’implementazione
dello strumento registrato e attivo. Mantenere toolMetadata.<tool>.optional: true
allineato con api.registerTool(..., { optional: true }) affinché OpenClaw possa evitare
di caricare il runtime di tale Plugin finché lo strumento non viene esplicitamente inserito nell’elenco consentito.
Convenzioni di importazione
Importare da sottopercorsi specifici dell’SDK:api.ts e
runtime-api.ts per le importazioni interne. Non importare il proprio Plugin tramite un
percorso dell’SDK. Gli helper specifici dei provider devono rimanere nel pacchetto del provider, a meno che
l’interfaccia non sia realmente generica.
I metodi RPC personalizzati del Gateway costituiscono un punto di ingresso avanzato. Mantenerli su un
prefisso specifico del Plugin; gli spazi dei nomi amministrativi del core come config.*,
exec.approvals.*, operator.admin.*, wizard.* e update.* rimangono riservati
e vengono risolti in operator.admin. Il bridge
openclaw/plugin-sdk/gateway-method-runtime è riservato alle route HTTP dei Plugin
che dichiarano contracts.gatewayMethodDispatch: ["authenticated-request"].
Per la mappa completa delle importazioni, consultare Panoramica dell’SDK per Plugin.
Elenco di controllo prima dell’invio
package.json contiene i metadati
openclaw correttiIl manifesto openclaw.plugin.json è presente e valido
Il punto di ingresso usa
defineChannelPluginEntry o definePluginEntryTutte le importazioni usano percorsi
plugin-sdk/<subpath> specificiLe importazioni interne usano moduli locali, non autoimportazioni dell’SDK
I test vengono superati (
pnpm test <bundled-plugin-root>/my-plugin/)pnpm check viene superato (Plugin nel repository)Test con le versioni beta
- Monitora le release di openclaw/openclaw (
Watch>Releases). I tag beta hanno un formato simile av2026.3.N-beta.1. È inoltre possibile seguire @openclaw su X per gli annunci delle release. - Testa il proprio Plugin con il tag beta non appena viene pubblicato. La finestra che precede la versione stabile è in genere di sole poche ore.
- Dopo il test, pubblica un messaggio nel thread del proprio Plugin nel canale Discord
plugin-forum(discord.gg/clawd), indicandoall goodoppure ciò che non ha funzionato. Se non esiste ancora un thread, creane uno. - Se qualcosa non funziona, apri o aggiorna una segnalazione intitolata
Beta blocker: <plugin-name> - <summary>e applica l’etichettabeta-blocker. Inserisci il link alla segnalazione nel proprio thread. - Apri una PR per
mainintitolatafix(<plugin-id>): beta blocker - <summary>e inserisci il link alla segnalazione sia nella PR sia nel proprio thread Discord. I contributori non possono applicare etichette alle PR, quindi il titolo costituisce il segnale lato PR per i maintainer e l’automazione. I problemi bloccanti con una PR vengono risolti tramite merge; quelli senza PR potrebbero comunque essere inclusi nella release. - Il silenzio indica che è tutto a posto. Se non si interviene entro questa finestra, in genere la correzione viene inclusa nel ciclo successivo.
Passaggi successivi
Plugin per canali
Crea un Plugin per un canale di messaggistica
Plugin per provider
Crea un Plugin per un provider di modelli
Plugin per backend CLI
Registra un backend CLI locale per l’IA
Panoramica dell'SDK
Riferimento per la mappa delle importazioni e l’API di registrazione
Helper di runtime
TTS, ricerca e sottoagente tramite api.runtime
Test
Utilità e modelli per i test
Manifest del Plugin
Riferimento completo dello schema del manifest