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
Kanal-Plugin
Verbinden Sie OpenClaw mit einer Messaging-Plattform.
Provider-Plugin
Fügen Sie einen Modell-, Medien-, Such-, Abruf-, Sprach- oder Echtzeit-Provider hinzu.
CLI-Backend-Plugin
Führen Sie eine lokale KI-CLI über den Modell-Fallback von OpenClaw aus.
Tool-Plugin
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.1
Paketmetadaten erstellen
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.2
Tool registrieren
index.ts
definePluginEntry für Plugins, die keine Kanal-Plugins sind. Kanal-Plugins verwenden
stattdessen defineChannelPluginEntry aus openclaw/plugin-sdk/core.3
Laufzeit testen
Prüfen Sie bei einem installierten oder externen Plugin die geladene Laufzeit:Wenn 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:4
Paketinstallation 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: 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.5
Veröffentlichen
Validieren Sie das Paket vor der Veröffentlichung:Kanonische ClawHub-Paketausschnitte befinden sich in
docs/snippets/plugin-publish/.6
Installieren
Installieren Sie das veröffentlichte Paket über ClawHub:
Tools 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ßlichdeliveryContext,
nativeChannelId für die aktive Plattformkonversation, sofern verfügbar, und
requesterSenderId.
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:
tools.allow zu:
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: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
package.json enthält korrekte
openclaw-MetadatenDas openclaw.plugin.json-Manifest ist vorhanden und gültig
Der Einstiegspunkt verwendet
defineChannelPluginEntry oder definePluginEntryAlle Importe verwenden spezifische
plugin-sdk/<subpath>-PfadeInterne Importe verwenden lokale Module, keine SDK-Selbstimporte
Tests sind erfolgreich (
pnpm test <bundled-plugin-root>/my-plugin/)pnpm check ist erfolgreich (repo-interne Plugins)Gegen Beta-Releases testen
- Beobachten Sie die Releases von openclaw/openclaw (
Watch>Releases). Beta-Tags sehen wiev2026.3.N-beta.1aus. Sie können außerdem @openclaw auf X folgen, um Release-Ankündigungen zu erhalten. - Testen Sie Ihr Plugin gegen den Beta-Tag, sobald er erscheint. Das Zeitfenster vor dem stabilen Release beträgt in der Regel nur wenige Stunden.
- Veröffentlichen Sie nach dem Testen im Thread Ihres Plugins im Discord-Kanal
plugin-forum(discord.gg/clawd) entwederall goododer eine Beschreibung dessen, was nicht funktioniert hat. Erstellen Sie einen Thread, falls Sie noch keinen haben. - Wenn etwas nicht funktioniert, öffnen oder aktualisieren Sie ein Issue mit dem Titel
Beta blocker: <plugin-name> - <summary>und weisen Sie ihm das Labelbeta-blockerzu. Verlinken Sie das Issue in Ihrem Thread. - Öffnen Sie einen PR für
mainmit dem Titelfix(<plugin-id>): beta blocker - <summary>und verlinken Sie das Issue sowohl im PR als auch in Ihrem Discord-Thread. Mitwirkende können PRs keine Labels zuweisen, daher dient der Titel als PR-seitiges Signal für Maintainer und Automatisierung. Blocker mit einem PR werden zusammengeführt; Blocker ohne PR werden möglicherweise trotzdem ausgeliefert. - Keine Rückmeldung bedeutet grünes Licht. Wenn Sie das Zeitfenster verpassen, wird Ihre Fehlerbehebung normalerweise erst im nächsten Zyklus aufgenommen.
Nächste Schritte
Kanal-Plugins
Ein Plugin für einen Nachrichtenkanal entwickeln
Provider-Plugins
Ein Plugin für einen Modell-Provider entwickeln
CLI-Backend-Plugins
Ein lokales KI-CLI-Backend registrieren
SDK-Übersicht
Referenz für Importzuordnung und Registrierungs-API
Runtime-Hilfsfunktionen
TTS, Suche und Subagent über api.runtime
Tests
Testhilfsprogramme und -muster
Plugin-Manifest
Vollständige Referenz zum Manifestschema