Building plugins
Plugins erstellen
Plugins erweitern OpenClaw, ohne den Kern zu verändern. Ein Plugin kann einen Messaging-Kanal, Modell-Provider, ein lokales CLI-Backend, Agenten-Tool, einen Hook, Medien-Provider oder eine andere Plugin-eigene Funktion hinzufügen.
Sie müssen dem OpenClaw-Repository kein externes Plugin hinzufügen. Veröffentlichen Sie das Paket auf ClawHub; Benutzer installieren es mit:
openclaw plugins install clawhub:<package-name>Reine Paketspezifikationen werden während der Einführungsumstellung weiterhin von npm installiert. Verwenden Sie das
Präfix clawhub:, wenn Sie die Auflösung über ClawHub wünschen.
Anforderungen
- Node 22.22.3+, Node 24.15+ oder Node 25.9+ sowie
npmoderpnpm. - TypeScript-ESM-Module.
- Klonen Sie für die Arbeit an gebündelten Plugins im Repository das Repository und führen Sie
pnpm installaus. Die Plugin-Entwicklung im Quellcode-Checkout erfolgt ausschließlich mit pnpm, da OpenClaw gebündelte Plugins ausextensions/*-Workspace-Paketen erkennt.
Plugin-Struktur auswählen
Verbinden Sie OpenClaw mit einer Messaging-Plattform.
Fügen Sie einen Modell-, Medien-, Such-, Abruf-, Sprach- oder Echtzeit-Provider hinzu.
Führen Sie eine lokale KI-CLI über den Modell-Fallback von OpenClaw aus.
Registrieren Sie Agenten-Tools.
Schnellstart
Erstellen Sie ein minimales Tool-Plugin, indem Sie ein erforderliches Agenten-Tool registrieren. Dies ist die kürzeste nützliche Plugin-Struktur und deckt Paket, Manifest, Einstiegspunkt und lokalen Nachweis ab.
Paketmetadaten erstellen
{"name": "@myorg/openclaw-my-plugin","version": "1.0.0","type": "module","dependencies": {"typebox": "1.1.39"},"peerDependencies": {"openclaw": ">=2026.3.24-beta.2"},"openclaw": {"extensions": ["./index.ts"],"compat": {"pluginApi": ">=2026.3.24-beta.2","minGatewayVersion": "2026.3.24-beta.2"},"build": {"openclawVersion": "2026.3.24-beta.2","pluginSdkVersion": "2026.3.24-beta.2"}}}{"id": "my-plugin","name": "My Plugin","description": "Adds a custom tool to OpenClaw","contracts": {"tools": ["my_tool"]},"activation": {"onStartup": true},"configSchema": {"type": "object","additionalProperties": false}}Veröffentlichte externe Plugins sollten Laufzeiteinträge auf erstellte JavaScript- Dateien verweisen lassen. Den vollständigen Einstiegspunktvertrag finden Sie unter SDK-Einstiegspunkte.
Jedes Plugin benötigt ein Manifest, auch ohne Konfiguration. Laufzeit-Tools müssen
in contracts.tools aufgeführt sein, damit OpenClaw die Zuständigkeit erkennen kann, ohne
jede Plugin-Laufzeit vorzeitig zu laden. Legen Sie activation.onStartup
bewusst fest; dieses Beispiel wird beim Start des Gateway geladen.
Auch vom Host als vertrauenswürdig eingestufte Plugin-Oberflächen sind durch das Manifest beschränkt und erfordern für
installierte Plugins eine ausdrückliche Deklaration: Für api.registerAgentToolResultMiddleware(...)
muss jede Ziellaufzeit in contracts.agentToolResultMiddleware aufgeführt sein,
und für api.registerTrustedToolPolicy(...) muss jede Richtlinien-ID in
contracts.trustedToolPolicies aufgeführt sein. Diese Deklarationen stimmen die Prüfung bei der Installation
mit der Laufzeitregistrierung ab.
Informationen zu allen Manifestfeldern finden Sie unter Plugin-Manifest.
Tool registrieren
import { Type } from "typebox";import { definePluginEntry } from "openclaw/plugin-sdk/plugin-entry"; export default definePluginEntry({ id: "my-plugin", name: "My Plugin", description: "Adds a custom tool to OpenClaw", register(api) { api.registerTool({ name: "my_tool", description: "Echo one input value", parameters: Type.Object({ input: Type.String() }), outputSchema: Type.Object( { input: Type.String() }, { additionalProperties: false }, ), async execute(_id, params) { const details = { input: params.input }; return { content: [{ type: "text", text: `Got: ${params.input}` }], details, }; }, }); },});Verwenden Sie definePluginEntry für Plugins, die keine Kanal-Plugins sind. Kanal-Plugins verwenden
stattdessen defineChannelPluginEntry aus openclaw/plugin-sdk/core.
Laufzeit testen
Prüfen Sie bei einem installierten oder externen Plugin die geladene Laufzeit:
openclaw plugins inspect my-plugin --runtime --jsonWenn das Plugin einen CLI-Befehl registriert, führen Sie auch diesen Befehl aus und überprüfen Sie
die Ausgabe, beispielsweise openclaw demo-plugin ping.
Bei einem gebündelten Plugin in diesem Repository erkennt OpenClaw Plugin-Pakete
aus dem Quellcode-Checkout im Workspace extensions/*. Führen Sie den am besten passenden gezielten
Test aus:
pnpm test extensions/my-plugin/pnpm checkPaketinstallation testen
Testen Sie vor der Veröffentlichung eines paketfertigen Plugins dieselbe Installationsform, die Benutzer
erhalten werden. Fügen Sie zunächst einen Build-Schritt hinzu, lassen Sie Laufzeiteinträge wie
openclaw.extensions auf erstelltes JavaScript wie ./dist/index.js verweisen und stellen Sie
sicher, dass npm pack diese dist/-Ausgabe enthält. TypeScript-Quellcodeeinträge sind
ausschließlich für Quellcode-Checkouts und lokale Entwicklungspfade vorgesehen.
Packen Sie dann das Plugin und installieren Sie das Tarball mit npm-pack::
npm pack --pack-destination /tmpopenclaw plugins install npm-pack:/tmp/<plugin-package>.tgz --forceopenclaw plugins inspect my-plugin --runtime --jsonnpm-pack: verwendet das von OpenClaw verwaltete npm-Projekt pro Plugin und erkennt daher
Fehler bei Laufzeitabhängigkeiten, die Tests im Quellcode-Checkout verbergen können. Dies weist
die Paket- und Abhängigkeitsstruktur nach, nicht jedoch den mit einem Katalog verknüpften offiziellen Vertrauensstatus.
Laufzeitimporte müssen in dependencies oder optionalDependencies enthalten sein;
Abhängigkeiten, die nur in devDependencies verbleiben, werden für das
verwaltete Laufzeitprojekt nicht installiert.
Verwenden Sie eine direkte Archiv-/Pfadinstallation nicht als abschließenden Nachweis für offizielles oder privilegiertes Plugin-Verhalten. Direkte Quellen sind für die lokale Fehlersuche nützlich, weisen jedoch nicht denselben Abhängigkeitspfad wie Installationen über npm oder ClawHub nach. Wenn Ihr Plugin auf dem Vertrauensstatus eines offiziellen Plugins beruht, ergänzen Sie einen zweiten Nachweis über eine kataloggestützte offizielle Installation oder einen veröffentlichten Paketpfad, der den offiziellen Vertrauensstatus aufzeichnet. Einzelheiten zu Installationsstamm und Zuständigkeit für Abhängigkeiten finden Sie unter Auflösung von Plugin-Abhängigkeiten.
Veröffentlichen
Validieren Sie das Paket vor der Veröffentlichung:
clawhub package publish your-org/your-plugin --dry-runclawhub package publish your-org/your-pluginKanonische ClawHub-Paketausschnitte befinden sich in docs/snippets/plugin-publish/.
Installieren
Installieren Sie das veröffentlichte Paket über ClawHub:
openclaw plugins install clawhub:your-org/your-pluginTools registrieren
Tools können erforderlich oder optional sein. Erforderliche Tools sind immer verfügbar, wenn das Plugin aktiviert ist. Optionale Tools erfordern die ausdrückliche Zustimmung des Benutzers, bevor OpenClaw die zugehörige Plugin-Laufzeit lädt.
Tool-Factories erhalten einen vertrauenswürdigen Laufzeitkontext, einschließlich deliveryContext,
nativeChannelId für die aktive Plattformkonversation, sofern verfügbar, und
requesterSenderId.
register(api) { api.registerTool( { name: "workflow_tool", description: "Run a workflow", parameters: Type.Object({ pipeline: Type.String() }), outputSchema: Type.Object( { pipeline: Type.String() }, { additionalProperties: false }, ), async execute(_id, params) { return { content: [{ type: "text", text: params.pipeline }], details: { pipeline: params.pipeline }, }; }, }, { optional: true }, );}outputSchema ist optional. Es beschreibt den strukturierten details-Wert, der von
Code Mode und Tool-Suche verwendet wird. Katalog-
Aufrufe lehnen ungültige Schemas vor der Ausführung ab und validieren den endgültigen Wert nach
Tool-Hooks. Lassen Sie es bei Tools ohne stabiles JSON-Ergebnis weg. Den vollständigen Vertrag finden Sie unter
Tool-Plugins.
Jedes mit api.registerTool(...) registrierte Tool muss außerdem im
Plugin-Manifest deklariert werden:
{ "contracts": { "tools": ["workflow_tool"] }, "toolMetadata": { "workflow_tool": { "optional": true } }}Benutzer stimmen mit tools.allow zu:
{ tools: { allow: ["workflow_tool"] }, // or ["my-plugin"] for every tool from one plugin}Optionale Tools steuern, ob ein Tool dem Modell bereitgestellt wird. Verwenden Sie Plugin-Berechtigungsanfragen, wenn ein Tool oder Hook nach der Auswahl durch das Modell und vor der Ausführung der Aktion eine Genehmigung anfordern soll.
Verwenden Sie optionale Tools für Nebeneffekte, ungewöhnliche Binärdateien oder Funktionen, die
standardmäßig nicht bereitgestellt werden sollten. Tool-Namen dürfen nicht mit Namen von Kern-Tools
kollidieren; Konflikte werden übersprungen und in der Plugin-Diagnose gemeldet. Fehlerhafte
Registrierungen werden übersprungen und auf dieselbe Weise gemeldet: ein fehlendes, nicht leeres
name, ein execute, das keine Funktion ist, oder ein Tool-Deskriptor ohne ein parameters-
Objekt.
Tool-Factories erhalten ein von der Laufzeit bereitgestelltes Kontextobjekt. Verwenden Sie ctx.activeModel,
wenn ein Tool das aktive Modell für den aktuellen
Durchlauf protokollieren, anzeigen oder sich daran anpassen muss; es kann provider, modelId und modelRef enthalten. Behandeln Sie es als
informative Laufzeitmetadaten und nicht als Sicherheitsgrenze gegenüber dem lokalen
Betreiber, installiertem Plugin-Code oder einer modifizierten OpenClaw-Laufzeit. Sensible
lokale Tools sollten weiterhin eine ausdrückliche Zustimmung für das Plugin oder durch den Betreiber erfordern und
geschlossen fehlschlagen, wenn Metadaten zum aktiven Modell fehlen oder ungeeignet sind.
Das Manifest deklariert Zuständigkeit und Erkennung; die Ausführung ruft weiterhin die aktive
registrierte Tool-Implementierung auf. Halten Sie toolMetadata.<tool>.optional: true
mit api.registerTool(..., { optional: true }) konsistent, damit OpenClaw das Laden
dieser Plugin-Laufzeit vermeiden kann, bis das Tool ausdrücklich in die Zulassungsliste aufgenommen wird.
Importkonventionen
Importieren Sie aus spezifischen SDK-Unterpfaden:
Verwenden Sie innerhalb Ihres Plugin-Pakets lokale Barrel-Dateien wie api.ts und
runtime-api.ts für interne Importe. Importieren Sie Ihr eigenes Plugin nicht über einen
SDK-Pfad. Provider-spezifische Hilfsfunktionen sollten im Provider-Paket verbleiben, sofern
die Schnittstelle nicht wirklich generisch ist.
Benutzerdefinierte Gateway-RPC-Methoden sind ein erweiterter Einstiegspunkt. Verwenden Sie dafür ein
Plugin-spezifisches Präfix; zentrale Admin-Namespaces wie config.*,
exec.approvals.*, operator.admin.*, wizard.* und update.* bleiben reserviert
und werden zu operator.admin aufgelöst. Die
openclaw/plugin-sdk/gateway-method-runtime-Bridge ist für Plugin-HTTP-
Routen reserviert, die contracts.gatewayMethodDispatch: ["authenticated-request"] deklarieren.
Die vollständige Importübersicht finden Sie unter Plugin-SDK-Übersicht.
Die OpenClaw-SDK-Kompatibilitätsfelder enthalten TypeScript-@deprecated-Annotationen,
die Editoren als Migrationswarnungen anzeigen. Um sie während des Builds durchzusetzen,
aktivieren Sie eine typbewusste Regel wie
@typescript-eslint/no-deprecated.
Oxlint ist nicht typbewusst und kann diese Annotationen daher nicht durchsetzen.
Checkliste vor der Einreichung
OPENCLAW_DOCS_MARKER:calloutOpen:Q2hlY2s
package.json enthält korrekte openclaw-Metadaten
OPENCLAW_DOCS_MARKER:calloutClose:
OPENCLAW_DOCS_MARKER:calloutOpen:Q2hlY2s Das openclaw.plugin.json-Manifest ist vorhanden und gültig OPENCLAW_DOCS_MARKER:calloutClose:
OPENCLAW_DOCS_MARKER:calloutOpen:Q2hlY2s
Der Einstiegspunkt verwendet defineChannelPluginEntry oder definePluginEntry
OPENCLAW_DOCS_MARKER:calloutClose:
OPENCLAW_DOCS_MARKER:calloutOpen:Q2hlY2s
Alle Importe verwenden spezifische plugin-sdk/<subpath>-Pfade
OPENCLAW_DOCS_MARKER:calloutClose: