¿Eres nuevo en los Plugins de OpenClaw? Lee primero Primeros pasos
para conocer la estructura del paquete y la configuración del manifiesto.
Qué pertenece a tu Plugin
Los Plugins de canal no implementan herramientas para enviar/editar/reaccionar; el núcleo proporciona una herramientamessage compartida. A tu Plugin le corresponde:
- Configuración - resolución de cuentas y asistente de configuración
- Seguridad - política de DM y listas de permitidos
- Emparejamiento - flujo de aprobación por DM
- Gramática de sesión - cómo los ids de conversación específicos del proveedor se asignan a chats base, ids de hilo y alternativas de padres
- Saliente - envío de texto, medios y encuestas a la plataforma
- Hilos - cómo se organizan las respuestas en hilos
- Escritura de Heartbeat - señales opcionales de escritura/ocupado para destinos de entrega de Heartbeat
:thread: y el despacho.
Adaptador de mensajes
Expón un adaptadormessage con defineChannelMessageAdapter desde
openclaw/plugin-sdk/channel-outbound. Declara solo las capacidades duraderas de envío final
que tu transporte nativo admite realmente, respaldadas por una prueba de contrato
que demuestre el efecto secundario nativo y el recibo devuelto. Apunta los envíos de texto/medios
a las mismas funciones de transporte que usa el adaptador outbound heredado. Para
el contrato completo de la API, la matriz de capacidades, las reglas de recibos, la finalización
de vista previa en vivo, la política de acuse de recibo, las pruebas y la tabla de migración, consulta
API saliente de canales.
Si tu adaptador outbound existente ya tiene los métodos de envío y los metadatos
de capacidades adecuados, deriva el adaptador message con
createChannelMessageAdapterFromOutbound(...) en lugar de escribir otro puente a mano.
Los envíos del adaptador devuelven valores MessageReceipt. Para ids heredados, derívalos
con listMessageReceiptPlatformIds(...) o
resolveMessageReceiptPrimaryId(...) en lugar de mantener campos messageIds
paralelos.
Declara con precisión las capacidades en vivo y de finalizador; el núcleo las usa para decidir
qué puede hacer un canal, y la divergencia entre el comportamiento declarado y el real es un
fallo de prueba de contrato:
| Superficie | Valores |
|---|---|
message.live.capabilities | draftPreview, previewFinalization, progressUpdates, nativeStreaming, quietFinalization |
message.live.finalizer.capabilities | finalEdit, normalFallback, discardPending, previewReceipt, retainOnAmbiguousFailure |
defineFinalizableLivePreviewAdapter(...) más
deliverWithFinalizableLivePreviewAdapter(...), y mantener las capacidades declaradas
respaldadas por pruebas verifyChannelMessageLiveCapabilityAdapterProofs(...)
y verifyChannelMessageLiveFinalizerProofs(...) para que el comportamiento nativo de vista previa,
progreso, edición, alternativa/retención, limpieza y recibos no pueda desviarse
silenciosamente.
Los receptores entrantes que difieren los acuses de recibo de la plataforma deben declarar
message.receive.defaultAckPolicy y supportedAckPolicies en lugar de ocultar
el tiempo del acuse en estado local del monitor. Cubre cada política declarada con
verifyChannelMessageReceiveAckPolicyAdapterProofs(...).
Los helpers de respuesta heredados como createChannelTurnReplyPipeline,
dispatchInboundReplyWithBase y recordInboundSessionAndDispatchReply
siguen disponibles para despachadores de compatibilidad. No los uses para código nuevo
de canales; empieza con el adaptador message, recibos y helpers del ciclo de vida
de recepción/envío en openclaw/plugin-sdk/channel-outbound.
Ingreso entrante (experimental)
Los canales que migran la autorización entrante pueden usar el subpath experimentalopenclaw/plugin-sdk/channel-ingress-runtime desde rutas de recepción en runtime.
Acepta datos de plataforma, listas de permitidos sin procesar, descriptores de ruta, datos de comandos
y configuración de grupos de acceso, y luego devuelve proyecciones de remitente/ruta/comando/activación
más el grafo de ingreso ordenado, mientras que la búsqueda en plataforma y los efectos secundarios
permanecen en el Plugin. Mantén la normalización de identidad del Plugin en el
descriptor que pasas al resolvedor; no serialices valores de coincidencia sin procesar desde
el estado o la decisión resueltos. Consulta
API de ingreso de canales para ver el diseño de la API,
el límite de propiedad y las expectativas de prueba. El subpath anterior
openclaw/plugin-sdk/channel-ingress sigue exportado como fachada de compatibilidad obsoleta
para Plugins de terceros.
Indicadores de escritura
Si tu canal admite indicadores de escritura fuera de las respuestas entrantes, expónheartbeat.sendTyping(...) en el Plugin de canal. El núcleo lo llama con el
destino de entrega de Heartbeat resuelto antes de que empiece la ejecución del modelo de Heartbeat y
usa el ciclo de vida compartido de mantenimiento/limpieza de escritura. Añade
heartbeat.clearTyping(...) cuando la plataforma necesite una señal explícita de parada.
Parámetros de origen de medios
Si tu canal añade parámetros de herramienta de mensajes que llevan orígenes de medios, expón esos nombres de parámetros medianteplugin.actions.describeMessageTool(...).mediaSourceParams.
El núcleo usa esa lista explícita para la normalización de rutas de sandbox y la política
de acceso a medios salientes, por lo que los Plugins no necesitan casos especiales de núcleo compartido para
parámetros específicos del proveedor de avatar, adjunto o imagen de portada.
Prefiere un mapa por clave de acción como { "set-profile": ["avatarUrl", "avatarPath"] }
para que las acciones no relacionadas no hereden los argumentos de medios de otra acción. Un arreglo plano
sigue funcionando para parámetros compartidos intencionalmente por cada acción expuesta.
Los canales que deban exponer una URL pública temporal para una obtención de medios del lado de la plataforma
pueden usar createHostedOutboundMediaStore(...) desde
openclaw/plugin-sdk/outbound-media con almacenes de estado del Plugin. Mantén el análisis
de rutas de plataforma y la aplicación de tokens en el Plugin de canal; el helper compartido
solo posee la carga de medios, los metadatos de expiración, las filas de fragmentos y la limpieza.
Modelado de payload nativo
Si tu canal necesita modelado específico del proveedor paramessage(action="send"),
prefiere actions.prepareSendPayload(...). Coloca tarjetas nativas, bloques, embeds u
otros datos duraderos bajo payload.channelData.<channel> y deja que el núcleo envíe
mediante el adaptador saliente/de mensajes. Usa actions.handleAction(...) para enviar
solo como alternativa de compatibilidad para payloads que no pueden serializarse y
reintentarse.
Gramática de conversación de sesión
Si tu plataforma almacena alcance adicional dentro de los ids de conversación, mantén ese análisis en el Plugin conmessaging.resolveSessionConversation(...). Ese es el hook
canónico para asignar rawId al id de conversación base, id de hilo opcional,
baseConversationId explícito y cualquier
parentConversationCandidates. Cuando devuelvas parentConversationCandidates,
ordénalos desde el padre más estrecho hasta la conversación más amplia/base.
messaging.resolveParentConversationCandidates(...) es una alternativa de compatibilidad
obsoleta para Plugins que solo necesitan alternativas de padres encima del id genérico/sin procesar.
Si existen ambos hooks, el núcleo usa primero
resolveSessionConversation(...).parentConversationCandidates y solo recurre a
resolveParentConversationCandidates(...) cuando el hook canónico los omite.
Los Plugins incluidos que necesiten el mismo análisis antes de que arranque el registro de canales
pueden exponer un archivo de nivel superior session-key-api.ts con una exportación
resolveSessionConversation(...) coincidente (consulta los Plugins Feishu y Telegram).
El núcleo usa esa superficie segura para arranque solo cuando el registro de Plugins en runtime
todavía no está disponible.
Usa openclaw/plugin-sdk/channel-route cuando el código del Plugin necesite normalizar
campos similares a rutas, comparar un hilo hijo con su ruta padre o construir una
clave estable de deduplicación desde { channel, to, accountId, threadId }. El helper
normaliza ids de hilo numéricos de la misma forma que el núcleo, así que prefiérelo frente a comparaciones
ad hoc de String(threadId). Los Plugins con gramática de destino específica del proveedor
deben exponer messaging.resolveOutboundSessionRoute(...) para que el núcleo obtenga
identidad de sesión e hilo nativa del proveedor sin shims de parser.
Aprobaciones y capacidades de canal
La mayoría de los Plugins de canal no necesitan código específico de aprobación. El núcleo posee/approve en el mismo chat, los payloads compartidos de botones de aprobación y la entrega alternativa genérica.
ChannelPlugin.approvals se eliminó; coloca los datos de entrega/nativo/renderizado/autenticación
de aprobaciones en un único objeto approvalCapability. plugin.auth es solo inicio/cierre
de sesión; el núcleo ya no lee hooks de autenticación de aprobación desde ese objeto.
Usa approvalCapability.delivery solo para enrutamiento nativo de aprobaciones o supresión
de alternativas, y approvalCapability.render solo cuando un canal realmente necesita
payloads de aprobación personalizados en lugar del renderizador compartido.
Autenticación de aprobación
approvalCapability.authorizeActorActionyapprovalCapability.getActionAvailabilityStateson la vía canónica de autenticación de aprobación.- Usa
getActionAvailabilityStatepara la disponibilidad de autenticación de aprobación en el mismo chat. Mantén disponibles a los aprobadores configurados para/approveincluso cuando la entrega nativa esté deshabilitada; usa en cambio el estado de la superficie de inicio nativa para orientación de entrega/configuración. - Si tu canal expone aprobaciones de exec nativas, usa
approvalCapability.getExecInitiatingSurfaceStatepara el estado de superficie de inicio/cliente nativo cuando difiera de la autenticación de aprobación en el mismo chat. El núcleo usa ese hook específico de exec para distinguirenableddedisabled, decidir si el canal iniciador admite aprobaciones de exec nativas e incluir el canal en la orientación de alternativa del cliente nativo.createApproverRestrictedNativeApprovalCapability(...)completa esto para el caso común. - Si un canal puede inferir identidades de DM estables similares a propietario a partir de la configuración existente,
usa
createResolvedApproverActionAuthAdapterdesdeopenclaw/plugin-sdk/approval-runtimepara restringir/approveen el mismo chat sin añadir lógica de núcleo específica de aprobación. - Si la autenticación de aprobación personalizada permite intencionalmente solo la alternativa del mismo chat, devuelve
markImplicitSameChatApprovalAuthorization({ authorized: true })desdeopenclaw/plugin-sdk/approval-auth-runtime; de lo contrario, el núcleo trata el resultado como autorización explícita de aprobador. - Si una devolución de llamada nativa propiedad del canal resuelve aprobaciones directamente, usa
isImplicitSameChatApprovalAuthorization(...)antes de resolver para que la alternativa implícita siga pasando por la autorización normal de actor del canal.
Ciclo de vida del payload y orientación de configuración
- Usa
outbound.shouldSuppressLocalPayloadPromptooutbound.beforeDeliverPayloadpara comportamiento del ciclo de vida del payload específico del canal, como ocultar prompts locales de aprobación duplicados o enviar indicadores de escritura antes de la entrega. - Usa
approvalCapability.describeExecApprovalSetupcuando el canal quiera que la respuesta de ruta deshabilitada explique los controles exactos de configuración necesarios para habilitar aprobaciones de exec nativas. El hook recibe{ channel, channelLabel, accountId }; los canales con cuentas con nombre deben renderizar rutas con alcance de cuenta comochannels.<channel>.accounts.<id>.execApprovals.*en lugar de valores predeterminados de nivel superior. - Usa
approvalCapability.describePluginApprovalSetupcuando sea seguro mostrar la orientación de fallos de aprobación de Plugin para fallos sin ruta y de tiempo de espera de aprobación de Plugin.createApproverRestrictedNativeApprovalCapability(...)no infiere esto desdedescribeExecApprovalSetup; pasa el mismo helper explícitamente solo cuando las aprobaciones de Plugin y exec usen realmente la misma configuración nativa.
Entrega de aprobación nativa
Si un canal necesita entrega de aprobación nativa, mantén el código del canal enfocado en la normalización del destino y en los datos de transporte/presentación. UsacreateChannelExecApprovalProfile, createChannelNativeOriginTargetResolver,
createChannelApproverDmTargetResolver y
createApproverRestrictedNativeApprovalCapability de
openclaw/plugin-sdk/approval-runtime. Coloca los datos específicos del canal detrás de
approvalCapability.nativeRuntime, idealmente mediante
createChannelApprovalNativeRuntimeAdapter(...) o
createLazyChannelApprovalNativeRuntimeAdapter(...), para que core pueda ensamblar el
manejador y hacerse cargo del filtrado de solicitudes, el enrutamiento, la deduplicación, la caducidad, la suscripción al Gateway
y los avisos de enrutamiento a otro lugar.
nativeRuntime se divide en algunos puntos de integración más pequeños:
availability- si la cuenta está configurada y si una solicitud debe manejarsepresentation- asigna el modelo de vista de aprobación compartido a cargas nativas pendientes/resueltas/caducadas o acciones finalestransport- prepara destinos y envía/actualiza/elimina mensajes de aprobación nativosinteractions- hooks opcionales bind/unbind/clear-action para botones o reacciones nativos, además de un hook opcionalcancelDelivered. ImplementacancelDeliveredcuandodeliverPendingregistra estado en proceso o persistente (como un almacén de destinos de reacción) para que ese estado pueda liberarse si una detención del manejador cancela la entrega antes de que se ejecutebindPending, o cuandobindPendingno devuelve ningún handleobserve- hooks opcionales de diagnóstico de entrega
- Usa
createNativeApprovalChannelRouteGatesdeopenclaw/plugin-sdk/approval-native-runtimecuando un canal admite tanto entrega nativa con origen de sesión como destinos explícitos de reenvío de aprobación. El helper centraliza la selección de configuración de aprobación, el manejo demode, los filtros de agente/sesión, la vinculación de cuentas, la coincidencia de destinos de sesión y la coincidencia de listas de destinos, mientras que los llamadores siguen siendo propietarios del id de canal, el modo predeterminado de reenvío, la búsqueda de cuenta, la comprobación de transporte habilitado, la normalización de destinos y la resolución de destinos de origen de turno. No lo uses para crear valores predeterminados de política de canal propiedad de core; pasa explícitamente el modo predeterminado documentado del canal. createChannelNativeOriginTargetResolverusa de forma predeterminada el matcher compartido de rutas de canal para destinos{ to, accountId, threadId }. PasatargetsMatchsolo cuando un canal tiene reglas de equivalencia específicas del proveedor, como la coincidencia de prefijo de timestamp de Slack. PasanormalizeTargetForMatchcuando el canal necesite canonicalizar ids de proveedor antes de que se ejecute el matcher de ruta predeterminado o un callback personalizadotargetsMatch, preservando al mismo tiempo el destino original para la entrega. UsanormalizeTargetsolo cuando el propio destino de entrega resuelto deba canonicalizarse.- Si el canal necesita objetos propiedad del runtime como un cliente, token, aplicación Bolt
o receptor de webhook, regístralos mediante
openclaw/plugin-sdk/channel-runtime-context. El registro genérico de contexto de runtime permite que core arranque manejadores impulsados por capacidades desde el estado de inicio del canal sin agregar pegamento de wrappers específico de aprobación. - Recurre a
createChannelApprovalHandlerocreateChannelNativeApprovalRuntimede nivel más bajo solo cuando el punto de integración impulsado por capacidades todavía no sea suficientemente expresivo. - Los canales de aprobación nativa deben enrutar tanto
accountIdcomoapprovalKindmediante esos helpers.accountIdmantiene la política de aprobación multi-cuenta acotada a la cuenta de bot correcta, yapprovalKindmantiene el comportamiento de aprobación exec vs plugin disponible para el canal sin ramas hardcodeadas en core. - Core también es propietario de los avisos de redireccionamiento de aprobación. Los plugins de canal no deben enviar
sus propios mensajes de seguimiento “la aprobación fue a DMs / otro canal” desde
createChannelNativeApprovalRuntime; en su lugar, expón un enrutamiento preciso de origen + DM del aprobador mediante los helpers compartidos de capacidad de aprobación y deja que core agregue las entregas reales antes de publicar cualquier aviso de vuelta al chat iniciador. - Preserva el tipo de id de aprobación entregado de extremo a extremo. Los clientes nativos no deben adivinar ni reescribir el enrutamiento de aprobación exec vs plugin desde estado local del canal.
- Distintos tipos de aprobación pueden exponer intencionalmente superficies nativas diferentes. Ejemplos empaquetados actuales: Matrix mantiene el mismo enrutamiento nativo de DM/canal y la UX de reacciones para aprobaciones exec y plugin, a la vez que permite que la autenticación difiera por tipo de aprobación; Slack mantiene el enrutamiento de aprobación nativa disponible tanto para ids exec como plugin.
createApproverRestrictedNativeApprovalAdaptertodavía existe como wrapper de compatibilidad, pero el código nuevo debe preferir el constructor de capacidades y exponerapprovalCapabilityen el plugin.
Subrutas más acotadas del runtime de aprobación
Para puntos de entrada críticos de canales, prefiere estas subrutas más acotadas sobre el barrel más amplioapproval-runtime cuando solo necesites una parte de esa familia:
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/reply-runtime,
openclaw/plugin-sdk/reply-dispatch-runtime,
openclaw/plugin-sdk/reply-reference y
openclaw/plugin-sdk/reply-chunking sobre superficies paraguas más amplias cuando
no las necesites todas.
Subrutas de configuración
openclaw/plugin-sdk/setup-runtimecubre los helpers de configuración seguros para runtime:createSetupTranslator, adaptadores de parches de configuración seguros para importación (createPatchedAccountSetupAdapter,createEnvPatchedAccountSetupAdapter,createSetupInputPresenceValidator), salida de notas de búsqueda,promptResolvedAllowFrom,splitSetupEntriesy los constructores delegados setup-proxy.openclaw/plugin-sdk/channel-setupcubre los constructores de configuración de instalación opcional además de algunas primitivas seguras para configuración:createOptionalChannelSetupSurface,createOptionalChannelSetupAdapter,createOptionalChannelSetupWizard,DEFAULT_ACCOUNT_ID,createTopLevelChannelDmPolicy,setSetupChannelEnabledysplitSetupEntries.- Usa el punto de integración más amplio
openclaw/plugin-sdk/setupsolo cuando también necesites los helpers compartidos más pesados de configuración/configuración, comomoveSingleAccountChannelSectionToDefaultAccount(...).
createOptionalChannelSetupSurface(...). El adaptador/asistente generado
falla de forma cerrada en escrituras de configuración y finalización, y reutiliza
el mismo mensaje de instalación requerida en validación, finalización y texto de enlace
a documentación.
Si tu canal admite configuración o autenticación impulsada por env y los flujos genéricos de inicio/configuración
deben conocer esos nombres de env antes de que se cargue el runtime, decláralos en el
manifiesto del plugin con channelEnvVars. Conserva envVars del runtime del canal o constantes locales
solo para texto orientado a operadores.
Si tu canal puede aparecer en status, channels list, channels status o
escaneos SecretRef antes de que arranque el runtime del plugin, agrega openclaw.setupEntry en
package.json. Ese punto de entrada debe ser seguro de importar en rutas de comandos
de solo lectura y debe devolver los metadatos del canal, el adaptador de configuración seguro para setup,
el adaptador de estado y los metadatos de destinos secretos del canal necesarios para esos
resúmenes. No inicies clientes, listeners ni runtimes de transporte desde la
entrada de configuración.
Mantén también acotada la ruta de importación de la entrada principal del canal. El descubrimiento puede evaluar
la entrada y el módulo del plugin de canal para registrar capacidades sin
activar el canal. Archivos como channel-plugin-api.ts deben exportar
el objeto del plugin de canal sin importar asistentes de configuración, clientes de transporte,
listeners de sockets, lanzadores de subprocesos ni módulos de inicio de servicios.
Coloca esas piezas de runtime en módulos cargados desde registerFull(...), setters
de runtime o adaptadores de capacidad lazy.
Otras subrutas acotadas de canal
Para otras rutas críticas de canal, prefiere los helpers acotados sobre superficies heredadas más amplias:openclaw/plugin-sdk/account-core,openclaw/plugin-sdk/account-id,openclaw/plugin-sdk/account-resolutionyopenclaw/plugin-sdk/account-helperspara configuración multi-cuenta y fallback de cuenta predeterminadaopenclaw/plugin-sdk/inbound-envelopeyopenclaw/plugin-sdk/channel-inboundpara rutas/sobres entrantes y cableado de registro y despachoopenclaw/plugin-sdk/channel-targetspara helpers de análisis de destinosopenclaw/plugin-sdk/outbound-mediapara carga de medios yopenclaw/plugin-sdk/channel-outboundpara delegados de identidad/envío salientes y planificación de payloadsbuildThreadAwareOutboundSessionRoute(...)deopenclaw/plugin-sdk/channel-corecuando una ruta saliente debe preservar unreplyToId/threadIdexplícito o recuperar la sesión:thread:actual después de que la clave de sesión base todavía coincida. Los plugins de proveedor pueden sobrescribir la precedencia, el comportamiento de sufijo y la normalización de id de hilo cuando su plataforma tenga semántica nativa de entrega en hilos.openclaw/plugin-sdk/thread-bindings-runtimepara el ciclo de vida de vinculaciones de hilos y el registro de adaptadoresopenclaw/plugin-sdk/agent-media-payloadsolo cuando todavía se requiera un diseño heredado de campos de payload de agente/medioopenclaw/plugin-sdk/telegram-command-config(obsoleto: ningún plugin empaquetado lo usa en producción) para la normalización de comandos personalizados de Telegram, validación de duplicados/conflictos y un contrato de configuración de comandos estable ante fallback; prefiere el manejo de configuración de comandos local al plugin para código de plugin nuevo
Política de menciones entrantes
Mantén el manejo de menciones entrantes dividido en dos capas:- recopilación de evidencia propiedad del plugin
- evaluación de política compartida
openclaw/plugin-sdk/channel-mention-gating para decisiones de política de menciones.
Usa openclaw/plugin-sdk/channel-inbound solo cuando necesites el barrel más amplio
de helpers entrantes.
Buen encaje para lógica local del plugin:
- detección de respuesta al bot
- detección de bot citado
- comprobaciones de participación en hilos
- exclusiones de mensajes de servicio/sistema
- cachés nativas de plataforma necesarias para demostrar participación del bot
requireMention- resultado de mención explícita
- lista de permisos de mención implícita
- omisión por comando
- decisión final de omisión
- Calcula los datos locales de mención.
- Pasa esos datos a
resolveInboundMentionDecision({ facts, policy }). - Usa
decision.effectiveWasMentioned,decision.shouldBypassMentionydecision.shouldSkipen tu puerta de entrada.
matchesMentionWithExplicit(...) devuelve un booleano. hasAnyMention,
isExplicitlyMentioned y canResolveExplicit provienen de los propios
metadatos nativos de mención del canal (entidades de mensaje, flags de respuesta al bot y similares);
proporciona valores false/undefined cuando tu plataforma no pueda detectarlos.
api.runtime.channel.mentions expone los mismos helpers de menciones compartidos para
plugins de canal incluidos que ya dependen de la inyección en runtime:
buildMentionRegexes, matchesMentionPatterns, matchesMentionWithExplicit,
implicitMentionKindWhen, resolveInboundMentionDecision.
Si solo necesitas implicitMentionKindWhen y resolveInboundMentionDecision,
importa desde openclaw/plugin-sdk/channel-mention-gating para evitar cargar
helpers de runtime entrante no relacionados.
Tutorial
Package and manifest
Crea los archivos estándar del Plugin. El campo
channels en
openclaw.plugin.json (no un campo kind) es lo que marca un manifiesto
como propietario de un canal. Para ver toda la superficie de metadatos del paquete, consulta
Configuración y setup de Plugin:configSchema valida plugins.entries.acme-chat.config. Úsalo para
ajustes propiedad del Plugin que no sean la configuración de la cuenta del canal.
channelConfigs.acme-chat.schema valida channels.acme-chat y es la
fuente de ruta fría que usan el esquema de configuración, el setup y las superficies de UI antes de que
se cargue el runtime del Plugin. Consulta Manifiesto de Plugin para ver la referencia completa
de campos de nivel superior.Build the channel plugin object
La interfaz Para canales que aceptan tanto claves DM canónicas de nivel superior como claves anidadas heredadas, usa los helpers de
ChannelPlugin tiene muchas superficies opcionales de adaptador. Empieza con
el mínimo: id, config y setup; y añade adaptadores a medida que los
necesites.Crea src/channel.ts:src/channel.ts
plugin-sdk/channel-config-helpers: resolveChannelDmAccess, resolveChannelDmPolicy, resolveChannelDmAllowFrom y normalizeChannelDmPolicy mantienen los valores locales de la cuenta por delante de los valores raíz heredados. Combina el mismo resolutor con la reparación de doctor mediante normalizeLegacyDmAliases para que el runtime y la migración lean el mismo contrato.What createChatChannelPlugin does for you
What createChatChannelPlugin does for you
En lugar de implementar manualmente interfaces de adaptador de bajo nivel, pasas
opciones declarativas y el constructor las compone:
También puedes pasar objetos de adaptador sin procesar en lugar de las opciones declarativas
si necesitas control total.Los adaptadores de salida sin procesar pueden definir una función
| Opción | Qué conecta |
|---|---|
security.dm | Resolutor de seguridad DM con alcance desde campos de configuración |
pairing.text | Flujo de emparejamiento DM basado en texto con intercambio de código |
threading | Resolutor de modo de respuesta (fijo, con alcance de cuenta o personalizado) |
outbound.attachedResults | Funciones de envío que devuelven metadatos de resultado (IDs de mensaje); requiere un id channel hermano para que core pueda sellar el resultado de entrega devuelto |
chunker(text, limit, ctx).
El ctx.formatting opcional lleva decisiones de formato en tiempo de entrega,
como maxLinesPerMessage; aplícalo antes de enviar para que el threading de respuestas
y los límites de fragmentos se resuelvan una sola vez mediante la entrega de salida compartida.
Los contextos de envío también incluyen replyToIdSource (implicit o explicit)
cuando se resolvió un destino de respuesta nativo, de modo que los helpers de payload puedan preservar
etiquetas de respuesta explícitas sin consumir un espacio de respuesta implícita de un solo uso.Wire the entry point
Crea Coloca los descriptores de CLI propiedad del canal en
index.ts:index.ts
registerCliMetadata(...) para que OpenClaw
pueda mostrarlos en la ayuda raíz sin activar todo el runtime del canal,
mientras que las cargas completas normales siguen recogiendo los mismos descriptores para el registro real de comandos.
Mantén registerFull(...) para trabajo exclusivo de runtime.
defineChannelPluginEntry gestiona automáticamente la división del modo de registro.
Si registerFull(...) registra métodos RPC de Gateway, usa un
prefijo específico del Plugin. Los espacios de nombres administrativos de core (config.*,
exec.approvals.*, wizard.*, update.*) permanecen reservados y siempre
se resuelven a operator.admin. Consulta
Puntos de entrada para ver todas las
opciones.Add a setup entry
Crea OpenClaw carga esto en lugar de la entrada completa cuando el canal está deshabilitado
o sin configurar. Evita traer código pesado de runtime durante los flujos de setup.
Consulta Setup y configuración para más detalles.Los canales de workspace incluidos que separan exportaciones seguras para setup en módulos
sidecar pueden usar
setup-entry.ts para una carga ligera durante el onboarding:setup-entry.ts
defineBundledChannelSetupEntry(...) desde
openclaw/plugin-sdk/channel-entry-contract cuando también necesitan un
setter explícito de runtime en tiempo de setup.Handle inbound messages
Tu Plugin necesita recibir mensajes de la plataforma y reenviarlos a
OpenClaw. El patrón típico es un Webhook que verifica la solicitud y
la despacha mediante el manejador entrante de tu canal:
El manejo de mensajes entrantes es específico de cada canal. Cada Plugin de canal posee
su propia canalización entrante. Examina los plugins de canal incluidos
(por ejemplo, el paquete de Plugin de Microsoft Teams o Google Chat) para ver patrones reales.
Test
Escribe pruebas colocadas junto al código en Para helpers de prueba compartidos, consulta Pruebas.
src/channel.test.ts:src/channel.test.ts
Estructura de archivos
Temas avanzados
Threading options
Modos de respuesta fijos, con alcance de cuenta o personalizados
Message tool integration
describeMessageTool y descubrimiento de acciones
Target resolution
inferTargetChatType, looksLikeId, reservedLiterals, resolveTarget
Runtime helpers
TTS, STT, medios, subagente mediante api.runtime
Channel inbound API
Ciclo de vida de eventos entrantes compartido: ingesta, resolución, registro, envío y finalización
Todavía existen algunos puntos de integración de helpers incluidos para el mantenimiento de Plugins incluidos y
la compatibilidad. No son el patrón recomendado para nuevos Plugins de canal;
prefiere las subrutas genéricas de canal/configuración/respuesta/runtime de la superficie común del SDK,
a menos que mantengas directamente esa familia de Plugins incluidos.
Siguientes pasos
- Plugins de proveedor - si tu Plugin también proporciona modelos
- Información general del SDK - referencia completa de importación por subrutas
- Pruebas del SDK - utilidades de prueba y pruebas de contrato
- Manifiesto de Plugin - esquema completo del manifiesto