Deze gids laat zien hoe je een kanaal-Plugin bouwt die OpenClaw verbindt met een berichtenplatform. Aan het einde heb je een werkend kanaal met DM-beveiliging, koppeling, antwoordthreading en uitgaande berichten.Documentation Index
Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Als je nog niet eerder een OpenClaw-Plugin hebt gebouwd, lees dan eerst
Aan de slag voor de basispakketstructuur
en manifestconfiguratie.
Hoe kanaal-Plugins werken
Kanaal-Plugins hebben geen eigen tools voor verzenden/bewerken/reageren nodig. OpenClaw houdt één gedeeldemessage-tool in core. Je Plugin is eigenaar van:
- Configuratie - accountresolutie en installatiewizard
- Beveiliging - DM-beleid en toelatingslijsten
- Koppeling - DM-goedkeuringsflow
- Sessiesyntaxis - hoe provider-specifieke gespreks-id’s worden gekoppeld aan basischats, thread-id’s en bovenliggende fallbacks
- Uitgaand - tekst, media en polls naar het platform verzenden
- Threading - hoe antwoorden worden gethread
- Heartbeat-typen - optionele typ-/bezig-signalen voor Heartbeat-bezorgdoelen
:thread:-boekhouding en dispatch.
Nieuwe kanaal-Plugins moeten ook een message-adapter beschikbaar maken met
defineChannelMessageAdapter uit openclaw/plugin-sdk/channel-message. De
adapter verklaart welke duurzame final-send-capabilities het native transport
daadwerkelijk ondersteunt en laat tekst-/mediaverzendingen wijzen naar dezelfde transportfuncties als
de legacy outbound-adapter. Declareer een capability alleen wanneer een contracttest
het native neveneffect en het geretourneerde ontvangstbewijs bewijst.
Zie voor het volledige API-contract, voorbeelden, capability-matrix, ontvangstbewijsregels, live
preview-finalisatie, receive-ack-beleid, tests en migratietabel
Channel message API.
Als de bestaande outbound-adapter al de juiste verzendmethoden en
capability-metadata heeft, gebruik dan createChannelMessageAdapterFromOutbound(...) om
de message-adapter af te leiden in plaats van handmatig nog een bridge te schrijven.
Adapterverzendingen moeten MessageReceipt-waarden retourneren. Wanneer compatibiliteitscode
nog legacy-id’s nodig heeft, leid die dan af met listMessageReceiptPlatformIds(...)
of resolveMessageReceiptPrimaryId(...) in plaats van parallelle
messageIds-velden in nieuwe lifecycle-code bij te houden.
Kanalen die previews ondersteunen, moeten ook message.live.capabilities declareren met
de exacte live-lifecycle waarvan zij eigenaar zijn, zoals draftPreview,
previewFinalization, progressUpdates, nativeStreaming of
quietFinalization. Kanalen die een conceptpreview op dezelfde plek finaliseren, moeten
ook message.live.finalizer.capabilities declareren, zoals finalEdit,
normalFallback, discardPending, previewReceipt en
retainOnAmbiguousFailure, en de runtimelogica routeren via
defineFinalizableLivePreviewAdapter(...) plus
deliverWithFinalizableLivePreviewAdapter(...). Houd die capabilities ondersteund
door verifyChannelMessageLiveCapabilityAdapterProofs(...)- en
verifyChannelMessageLiveFinalizerProofs(...)-tests, zodat native preview-,
voortgangs-, bewerkings-, fallback-/retentie-, opschonings- en ontvangstbewijsgedrag niet stil
kan afwijken.
Inkomende receivers die platformbevestigingen uitstellen, moeten
message.receive.defaultAckPolicy en supportedAckPolicies declareren in plaats van
ack-timing te verbergen in monitor-lokale state. Dek elk gedeclareerd beleid af met
verifyChannelMessageReceiveAckPolicyAdapterProofs(...).
Legacy helpers voor antwoorden/turns, zoals createChannelTurnReplyPipeline,
dispatchInboundReplyWithBase en recordInboundSessionAndDispatchReply,
blijven beschikbaar voor compatibiliteitsdispatchers. Gebruik die namen niet voor nieuwe
kanaalcode; nieuwe Plugins moeten beginnen met de message-adapter, ontvangstbewijzen en
receive/send-lifecyclehelpers op openclaw/plugin-sdk/channel-message.
Kanalen die inkomende autorisatie migreren, kunnen het experimentele
openclaw/plugin-sdk/channel-ingress-runtime-subpad gebruiken vanuit runtime-receivepaden.
Het subpad houdt platformlookup en neveneffecten in de Plugin, terwijl
allowlist-state-resolutie, route-/sender-/command-/event-/activation-
beslissingen, geredigeerde diagnostiek en turn-admission-mapping worden gedeeld. Houd
Plugin-identiteitsnormalisatie in de descriptor die je aan de resolver doorgeeft; serialiseer geen
ruwe matchwaarden uit de opgeloste state of beslissing. Zie
Channel ingress API voor het API-ontwerp,
de eigendomsgrens en testverwachtingen.
Als je kanaal typindicatoren buiten inkomende antwoorden ondersteunt, stel dan
heartbeat.sendTyping(...) beschikbaar op de kanaal-Plugin. Core roept dit aan met het
opgeloste Heartbeat-bezorgdoel voordat de Heartbeat-modelrun start en
gebruikt de gedeelde typing-keepalive-/cleanup-lifecycle. Voeg heartbeat.clearTyping(...)
toe wanneer het platform een expliciet stopsignaal nodig heeft.
Als je kanaal message-tool-parameters toevoegt die mediabronnen dragen, stel die
parameternamen dan beschikbaar via describeMessageTool(...).mediaSourceParams. Core gebruikt
die expliciete lijst voor sandboxpadnormalisatie en outbound media-access-
beleid, zodat Plugins geen gedeelde-core special cases nodig hebben voor provider-specifieke
avatar-, attachment- of cover-image-parameters.
Geef bij voorkeur een action-keyed map terug zoals
{ "set-profile": ["avatarUrl", "avatarPath"] }, zodat niet-gerelateerde acties niet
de media-argumenten van een andere actie erven. Een platte array werkt nog steeds voor parameters die
bewust worden gedeeld door elke beschikbare actie.
Als je kanaal provider-specifieke vormgeving nodig heeft voor message(action="send"),
gebruik dan bij voorkeur actions.prepareSendPayload(...). Zet native kaarten, blocks, embeds of
andere duurzame data onder payload.channelData.<channel> en laat core de daadwerkelijke
verzending uitvoeren via de outbound/message-adapter. Gebruik
actions.handleAction(...) voor verzending alleen als compatibiliteitsfallback voor
payloads die niet kunnen worden geserialiseerd en opnieuw geprobeerd.
Als je platform extra scope opslaat in gespreks-id’s, houd die parsing dan
in de Plugin met messaging.resolveSessionConversation(...). Dat is de
canonieke hook voor het mappen van rawId naar het basisgespreks-id, optioneel thread-
id, expliciete baseConversationId en eventuele parentConversationCandidates.
Wanneer je parentConversationCandidates retourneert, houd ze dan geordend van de
smalste parent naar het breedste/basisgesprek.
Gebruik openclaw/plugin-sdk/channel-route wanneer Plugin-code route-achtige velden moet normaliseren,
een child-thread moet vergelijken met de parent-route, of een
stabiele dedupe-sleutel moet bouwen uit { channel, to, accountId, threadId }. De helper
normaliseert numerieke thread-id’s op dezelfde manier als core, dus Plugins moeten
dit verkiezen boven ad-hoc String(threadId)-vergelijkingen.
Plugins met provider-specifieke doelsyntaxis kunnen hun parser injecteren in
resolveChannelRouteTargetWithParser(...) en toch dezelfde route target-
vorm en thread-fallbacksemantiek krijgen die core gebruikt.
Gebundelde Plugins die dezelfde parsing nodig hebben voordat de kanaalregistry opstart,
kunnen ook een top-level session-key-api.ts-bestand beschikbaar maken met een overeenkomende
resolveSessionConversation(...)-export. Core gebruikt dat bootstrap-veilige oppervlak
alleen wanneer de runtime-Pluginregistry nog niet beschikbaar is.
messaging.resolveParentConversationCandidates(...) blijft beschikbaar als een
legacy compatibiliteitsfallback wanneer een Plugin alleen parent-fallbacks nodig heeft bovenop
het generieke/ruwe id. Als beide hooks bestaan, gebruikt core eerst
resolveSessionConversation(...).parentConversationCandidates en valt alleen terug op
resolveParentConversationCandidates(...) wanneer de canonieke hook
ze weglaat.
Goedkeuringen en kanaal-capabilities
De meeste kanaal-Plugins hebben geen goedkeuringsspecifieke code nodig.- Core is eigenaar van same-chat
/approve, gedeelde approval-knoppayloads en generieke fallback-bezorging. - Geef de voorkeur aan één
approvalCapability-object op de channel-plugin wanneer het kanaal approval-specifiek gedrag nodig heeft. ChannelPlugin.approvalsis verwijderd. Zet approval-bezorging/native/render/auth-feiten opapprovalCapability.plugin.authis alleen login/logout; core leest niet langer approval-auth-hooks uit dat object.approvalCapability.authorizeActorActionenapprovalCapability.getActionAvailabilityStatezijn de canonieke approval-auth-naad.- Gebruik
approvalCapability.getActionAvailabilityStatevoor beschikbaarheid van same-chat approval-auth. - Als je kanaal native exec-approvals blootstelt, gebruik dan
approvalCapability.getExecInitiatingSurfaceStatevoor de initiating-surface/native-client-status wanneer die verschilt van same-chat approval-auth. Core gebruikt die exec-specifieke hook omenabledvandisabledte onderscheiden, te bepalen of het initiërende kanaal native exec-approvals ondersteunt, en het kanaal op te nemen in fallback-instructies voor native clients.createApproverRestrictedNativeApprovalCapability(...)vult dit in voor het gangbare geval. - Gebruik
outbound.shouldSuppressLocalPayloadPromptofoutbound.beforeDeliverPayloadvoor kanaalspecifiek payload-lifecycle-gedrag, zoals het verbergen van dubbele lokale approval-prompts of het verzenden van typindicatoren vóór bezorging. - Gebruik
approvalCapability.deliveryalleen voor native approval-routing of fallback-onderdrukking. - Gebruik
approvalCapability.nativeRuntimevoor native approval-feiten die eigendom zijn van het kanaal. Houd dit lazy op hete kanaal-entrypoints metcreateLazyChannelApprovalNativeRuntimeAdapter(...), dat je runtime-module op aanvraag kan importeren terwijl core nog steeds de approval-lifecycle kan samenstellen. - Gebruik
approvalCapability.renderalleen wanneer een kanaal echt aangepaste approval-payloads nodig heeft in plaats van de gedeelde renderer. - Gebruik
approvalCapability.describeExecApprovalSetupwanneer het kanaal wil dat het disabled-path-antwoord uitlegt welke exacte configuratieknoppen nodig zijn om native exec-approvals in te schakelen. De hook ontvangt{ channel, channelLabel, accountId }; named-account-kanalen moeten account-gescopete paden renderen, zoalschannels.<channel>.accounts.<id>.execApprovals.*, in plaats van defaults op topniveau. - Als een kanaal stabiele owner-achtige DM-identiteiten uit bestaande config kan afleiden, gebruik dan
createResolvedApproverActionAuthAdapteruitopenclaw/plugin-sdk/approval-runtimeom same-chat/approvete beperken zonder approval-specifieke core-logica toe te voegen. - Als een kanaal native approval-bezorging nodig heeft, houd de kanaalcode dan gericht op target-normalisatie plus transport-/presentatiefeiten. Gebruik
createChannelExecApprovalProfile,createChannelNativeOriginTargetResolver,createChannelApproverDmTargetResolverencreateApproverRestrictedNativeApprovalCapabilityuitopenclaw/plugin-sdk/approval-runtime. Zet de kanaalspecifieke feiten achterapprovalCapability.nativeRuntime, idealiter viacreateChannelApprovalNativeRuntimeAdapter(...)ofcreateLazyChannelApprovalNativeRuntimeAdapter(...), zodat core de handler kan samenstellen en request-filtering, routing, dedupe, expiry, Gateway-subscription en routed-elsewhere-meldingen kan beheren.nativeRuntimeis opgesplitst in een paar kleinere naden: createChannelNativeOriginTargetResolvergebruikt standaard de gedeelde channel-route-matcher voor{ to, accountId, threadId }-targets. GeeftargetsMatchalleen mee wanneer een kanaal providerspecifieke equivalentieregels heeft, zoals Slack-timestamp-prefixmatching.- Geef
normalizeTargetForMatchdoor aancreateChannelNativeOriginTargetResolverwanneer het kanaal provider-id’s moet canonicaliseren voordat de standaard route-matcher of een aangepastetargetsMatch-callback draait, terwijl het originele target voor bezorging behouden blijft. GebruiknormalizeTargetalleen wanneer het opgeloste bezorgtarget zelf moet worden gecanonicaliseerd. availability- of het account is geconfigureerd en of een request moet worden afgehandeldpresentation- map het gedeelde approval-viewmodel naar pending/resolved/expired native payloads of finale actiestransport- bereid targets voor en verzend/update/verwijder native approval-berichteninteractions- optionele bind/unbind/clear-action-hooks voor native knoppen of reactiesobserve- optionele hooks voor bezorgdiagnostiek- Als het kanaal runtime-owned objecten nodig heeft, zoals een client, token, Bolt-app of webhook receiver, registreer ze dan via
openclaw/plugin-sdk/channel-runtime-context. De generieke runtime-context-registry laat core capability-gedreven handlers bootstrappen vanuit de kanaal-startupstatus zonder approval-specifieke wrapperlijm toe te voegen. - Grijp alleen naar de lagere-level
createChannelApprovalHandlerofcreateChannelNativeApprovalRuntimewanneer de capability-gedreven naad nog niet expressief genoeg is. - Native approval-kanalen moeten zowel
accountIdalsapprovalKindvia die helpers routeren.accountIdhoudt multi-account-approvalbeleid gescopet op het juiste botaccount, enapprovalKindhoudt exec- versus plugin-approvalgedrag beschikbaar voor het kanaal zonder hardcoded branches in core. - Core is nu ook eigenaar van approval-reroute-meldingen. Channel-plugins moeten niet hun eigen vervolgberichten “approval went to DMs / another channel” verzenden vanuit
createChannelNativeApprovalRuntime; stel in plaats daarvan accurate origin- en approver-DM-routing beschikbaar via de gedeelde approval-capability-helpers en laat core daadwerkelijke bezorgingen aggregeren voordat er een melding terug naar de initiërende chat wordt geplaatst. - Behoud het soort van de bezorgde approval-id end-to-end. Native clients mogen exec- versus plugin-approval-routing niet raden of herschrijven vanuit kanaallokale status.
- Verschillende approval-soorten kunnen bewust verschillende native surfaces blootstellen.
Huidige gebundelde voorbeelden:
- Slack houdt native approval-routing beschikbaar voor zowel exec- als plugin-id’s.
- Matrix houdt dezelfde native DM-/kanaalrouting en reactie-UX voor exec- en plugin-approvals, terwijl auth nog steeds per approval-soort kan verschillen.
createApproverRestrictedNativeApprovalAdapterbestaat nog steeds als compatibiliteitswrapper, maar nieuwe code moet de voorkeur geven aan de capability-builder enapprovalCapabilityop de plugin blootstellen.
openclaw/plugin-sdk/approval-auth-runtimeopenclaw/plugin-sdk/approval-client-runtimeopenclaw/plugin-sdk/approval-delivery-runtimeopenclaw/plugin-sdk/approval-gateway-runtimeopenclaw/plugin-sdk/approval-handler-adapter-runtimeopenclaw/plugin-sdk/approval-handler-runtimeopenclaw/plugin-sdk/approval-native-runtimeopenclaw/plugin-sdk/approval-reply-runtimeopenclaw/plugin-sdk/channel-runtime-context
openclaw/plugin-sdk/setup-runtime,
openclaw/plugin-sdk/setup-runtime,
openclaw/plugin-sdk/reply-runtime,
openclaw/plugin-sdk/reply-dispatch-runtime,
openclaw/plugin-sdk/reply-reference en
openclaw/plugin-sdk/reply-chunking wanneer je de bredere overkoepelende
surface niet nodig hebt.
Specifiek voor setup:
openclaw/plugin-sdk/setup-runtimedekt de runtime-veilige setup-helpers: import-veilige setup-patchadapters (createPatchedAccountSetupAdapter,createEnvPatchedAccountSetupAdapter,createSetupInputPresenceValidator), lookup-note-output,promptResolvedAllowFrom,splitSetupEntriesen de gedelegeerde setup-proxy-buildersopenclaw/plugin-sdk/setup-runtimebevat de env-bewuste adapter-naad voorcreateEnvPatchedAccountSetupAdapteropenclaw/plugin-sdk/channel-setupdekt de optional-install setup- builders plus een paar setup-veilige primitives:createOptionalChannelSetupSurface,createOptionalChannelSetupAdapter,
channelEnvVars. Houd runtime-envVars van het kanaal of lokale
constanten alleen voor operatorgerichte tekst.
Als je kanaal in status, channels list, channels status of
SecretRef-scans kan verschijnen voordat de pluginruntime start, voeg dan openclaw.setupEntry toe in
package.json. Dat entrypoint moet veilig te importeren zijn in read-only command
paths en moet de kanaalmetadata, setup-veilige config-adapter, status-
adapter en kanaal-secret-target-metadata teruggeven die nodig zijn voor die samenvattingen. Start geen
clients, listeners of transportruntimes vanuit de setup-entry.
Houd ook het importpad van de hoofd-channel-entry smal. Discovery kan de
entry en de channel-plugin-module evalueren om capabilities te registreren zonder
het kanaal te activeren. Bestanden zoals channel-plugin-api.ts moeten het channel-
pluginobject exporteren zonder setup-wizards, transportclients, socket-
listeners, subprocess launchers of service-startupmodules te importeren. Zet die runtime-
onderdelen in modules die worden geladen vanuit registerFull(...), runtime-setters of lazy
capability-adapters.
createOptionalChannelSetupWizard, DEFAULT_ACCOUNT_ID,
createTopLevelChannelDmPolicy, setSetupChannelEnabled en
splitSetupEntries
- gebruik de bredere
openclaw/plugin-sdk/setup-naad alleen wanneer je ook de zwaardere gedeelde setup-/config-helpers nodig hebt, zoalsmoveSingleAccountChannelSectionToDefaultAccount(...)
createOptionalChannelSetupSurface(...). De gegenereerde
adapter/wizard falen gesloten bij config-writes en finalization, en ze hergebruiken
hetzelfde install-required-bericht in validatie, finalize en docs-link-
tekst.
Voor andere hete kanaalpaden geef je de voorkeur aan de smalle helpers boven bredere legacy-
surfaces:
openclaw/plugin-sdk/account-core,openclaw/plugin-sdk/account-id,openclaw/plugin-sdk/account-resolutionenopenclaw/plugin-sdk/account-helpersvoor multi-account-config en default-account-fallbackopenclaw/plugin-sdk/inbound-envelopeenopenclaw/plugin-sdk/inbound-reply-dispatchvoor inbound route/envelope en record-and-dispatch-bedradingopenclaw/plugin-sdk/messaging-targetsvoor target parsing/matchingopenclaw/plugin-sdk/outbound-mediaenopenclaw/plugin-sdk/outbound-runtimevoor medialading plus outbound identity/send-delegates en payloadplanningbuildThreadAwareOutboundSessionRoute(...)uitopenclaw/plugin-sdk/channel-corewanneer een outbound route een explicietereplyToId/threadIdmoet behouden of de huidige:thread:-sessie moet herstellen nadat de basissessiesleutel nog steeds matcht. Provider-plugins kunnen precedence, suffixgedrag en thread-id-normalisatie overschrijven wanneer hun platform native thread-bezorgsemantiek heeft.openclaw/plugin-sdk/thread-bindings-runtimevoor thread-binding-lifecycle en adapterregistratieopenclaw/plugin-sdk/agent-media-payloadalleen wanneer een legacy agent/media- payloadveldindeling nog vereist isopenclaw/plugin-sdk/telegram-command-configvoor Telegram custom-command- normalisatie, validatie van duplicaten/conflicten en een fallback-stabiel command- configcontract
Inbound mention-beleid
Houd inbound mention-afhandeling opgesplitst in twee lagen:- plugin-owned evidence gathering
- gedeelde beleidsevaluatie
openclaw/plugin-sdk/channel-mention-gating voor mention-policy-beslissingen.
Gebruik openclaw/plugin-sdk/channel-inbound alleen wanneer je de bredere inbound
helper-barrel nodig hebt.
Goede plek voor plugin-lokale logica:
- reply-to-bot-detectie
- quoted-bot-detectie
- controles op thread-deelname
- uitsluitingen voor service-/systeemberichten
- platform-native caches die nodig zijn om botdeelname te bewijzen
requireMention- expliciet vermeldingsresultaat
- impliciete vermeldings-allowlist
- commando-omzeiling
- uiteindelijke oversla-beslissing
- Bereken lokale vermeldingsfeiten.
- Geef die feiten door aan
resolveInboundMentionDecision({ facts, policy }). - Gebruik
decision.effectiveWasMentioned,decision.shouldBypassMentionendecision.shouldSkipin je inkomende gate.
api.runtime.channel.mentions stelt dezelfde gedeelde vermeldingshelpers beschikbaar voor
gebundelde kanaalplugins die al afhankelijk zijn van runtime-injectie:
buildMentionRegexesmatchesMentionPatternsmatchesMentionWithExplicitimplicitMentionKindWhenresolveInboundMentionDecision
implicitMentionKindWhen en
resolveInboundMentionDecision nodig hebt, importeer dan vanuit
openclaw/plugin-sdk/channel-mention-gating om te voorkomen dat niet-gerelateerde inkomende
runtimehelpers worden geladen.
De oudere resolveMentionGating*-helpers blijven alleen als compatibiliteitsexports beschikbaar op
openclaw/plugin-sdk/channel-inbound. Nieuwe code
moet resolveInboundMentionDecision({ facts, policy }) gebruiken.
Stapsgewijze uitleg
Pakket en manifest
Maak de standaard Plugin-bestanden. Het veld
channel in package.json is
wat dit een kanaalplugin maakt. Zie Plugin instellen en configureren
voor het volledige oppervlak voor pakketmetadata:configSchema valideert plugins.entries.acme-chat.config. Gebruik dit voor
instellingen in eigendom van de Plugin die geen kanaalaccountconfiguratie zijn. channelConfigs
valideert channels.acme-chat en is de cold-path-bron die door configuratieschema,
setup en UI-oppervlakken wordt gebruikt voordat de Plugin-runtime wordt geladen.Bouw het kanaalpluginobject
De interface Voor kanalen die zowel canonieke DM-sleutels op topniveau als verouderde geneste sleutels accepteren, gebruik je de helpers uit
ChannelPlugin heeft veel optionele adapteroppervlakken. Begin met
het minimum - id en setup - en voeg adapters toe wanneer je ze nodig hebt.Maak src/channel.ts:src/channel.ts
plugin-sdk/channel-config-helpers: resolveChannelDmAccess, resolveChannelDmPolicy, resolveChannelDmAllowFrom en normalizeChannelDmPolicy houden accountlokale waarden vóór overgeërfde rootwaarden. Koppel dezelfde resolver aan doctor-reparatie via normalizeLegacyDmAliases, zodat runtime en migratie hetzelfde contract lezen.Wat createChatChannelPlugin voor je doet
Wat createChatChannelPlugin voor je doet
In plaats van low-level adapterinterfaces handmatig te implementeren, geef je
declaratieve opties door en stelt de builder ze samen:
Je kunt ook ruwe adapterobjecten doorgeven in plaats van de declaratieve opties
als je volledige controle nodig hebt.Ruwe uitgaande adapters kunnen een functie
| Optie | Wat het koppelt |
|---|---|
security.dm | Scoped DM-beveiligingsresolver vanuit configuratievelden |
pairing.text | Tekstgebaseerde DM-koppelingsflow met code-uitwisseling |
threading | Reply-to-modusresolver (vast, account-scoped of aangepast) |
outbound.attachedResults | Verzendfuncties die resultaatmetadata retourneren (bericht-ID’s) |
chunker(text, limit, ctx) definiëren.
De optionele ctx.formatting bevat op bezorgtijd genomen opmaakbeslissingen,
zoals maxLinesPerMessage; pas die toe vóór het verzenden, zodat reply-threading
en chunkgrenzen één keer worden opgelost door gedeelde uitgaande bezorging.
Verzendcontexten bevatten ook replyToIdSource (implicit of explicit)
wanneer een native replydoel is opgelost, zodat payloadhelpers expliciete
reply-tags kunnen behouden zonder een impliciete eenmalige reply-slot te verbruiken.Koppel het entrypoint
Maak Plaats CLI-descriptors die eigendom zijn van het kanaal in
index.ts:index.ts
registerCliMetadata(...), zodat OpenClaw
ze in de root-help kan tonen zonder de volledige kanaalruntime te activeren,
terwijl normale volledige loads nog steeds dezelfde descriptors meenemen voor echte
commandoregistratie. Houd registerFull(...) voor werk dat alleen runtime betreft.
Als registerFull(...) Gateway-RPC-methoden registreert, gebruik dan een
Plugin-specifiek voorvoegsel. Core admin-namespaces (config.*,
exec.approvals.*, wizard.*, update.*) blijven gereserveerd en worden altijd
opgelost naar operator.admin.
defineChannelPluginEntry handelt de splitsing van registratiemodi automatisch af. Zie
Entrypoints voor alle
opties.Voeg een setup-entry toe
Maak OpenClaw laadt dit in plaats van de volledige entry wanneer het kanaal is uitgeschakeld
of niet is geconfigureerd. Het voorkomt dat zware runtimecode wordt geladen tijdens setupflows.
Zie Setup en configuratie voor details.Gebundelde workspace-kanalen die setup-veilige exports opsplitsen naar sidecar
modules kunnen
setup-entry.ts voor lichtgewicht laden tijdens onboarding:setup-entry.ts
defineBundledChannelSetupEntry(...) gebruiken vanuit
openclaw/plugin-sdk/channel-entry-contract wanneer ze ook een
expliciete runtime-setter voor setuptijd nodig hebben.Verwerk inkomende berichten
Je Plugin moet berichten van het platform ontvangen en doorsturen naar
OpenClaw. Het typische patroon is een Webhook die de aanvraag verifieert en
deze dispatcht via de inkomende handler van je kanaal:
Afhandeling van inkomende berichten is kanaalspecifiek. Elke channel plugin beheert
zijn eigen inkomende pipeline. Bekijk gebundelde channel plugins
(bijvoorbeeld het Microsoft Teams- of Google Chat-pluginpakket) voor echte patronen.
Testen
Schrijf gecolokeerde tests in Zie Testen voor gedeelde testhelpers.
src/channel.test.ts:src/channel.test.ts
Bestandsstructuur
Geavanceerde onderwerpen
Threading-opties
Vaste, accountgebonden of aangepaste antwoordmodi
Integratie met berichttool
describeMessageTool en actiedetectie
Doelresolutie
inferTargetChatType, looksLikeId, resolveTarget
Runtime-helpers
TTS, STT, media, subagent via api.runtime
Channel turn-kernel
Gedeelde lifecycle voor inkomende turns: ingest, resolve, record, dispatch, finalize
Sommige gebundelde helperseams bestaan nog steeds voor onderhoud van gebundelde plugins en
compatibiliteit. Ze zijn niet het aanbevolen patroon voor nieuwe channel plugins;
geef de voorkeur aan de generieke channel/setup/reply/runtime-subpaden uit het gemeenschappelijke SDK-
oppervlak, tenzij je die gebundelde pluginfamilie rechtstreeks onderhoudt.
Volgende stappen
- Provider-Plugins - als je plugin ook modellen levert
- SDK-overzicht - volledige referentie voor subpath-imports
- SDK-testen - testhulpmiddelen en contracttests
- Plugin-manifest - volledig manifestschema