La presentación de mensajes es el contrato compartido de OpenClaw para una interfaz de chat saliente enriquecida. Permite que agentes, comandos de CLI, flujos de aprobación y plugins describan la intención del mensaje una sola vez, mientras cada Plugin de canal representa la mejor forma nativa que puede. Use la presentación para una interfaz de mensaje portátil: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.
- secciones de texto
- texto pequeño de contexto/pie de página
- divisores
- botones
- menús de selección
- título y tono de tarjeta
components de Discord, blocks de Slack, buttons de Telegram, card de Teams o card de Feishu, a la herramienta de mensajes compartida. Esas son salidas de renderizador propiedad del Plugin de canal.
Contrato
Los autores de plugins importan el contrato público desde:valuees un valor de acción de la aplicación que se enruta de vuelta por la ruta de interacción existente del canal cuando el canal admite controles clicables.urles un botón de enlace. Puede existir sinvalue.labeles obligatorio y también se usa en el respaldo de texto.stylees orientativo. Los renderizadores deben asignar los estilos no admitidos a un valor predeterminado seguro, no hacer fallar el envío.
options[].valuees el valor de aplicación seleccionado.placeholderes orientativo y puede ser ignorado por canales sin soporte nativo de selección.- Si un canal no admite selecciones, el texto de respaldo enumera las etiquetas.
Ejemplos de productores
Tarjeta simple:Contrato del renderizador
Los plugins de canal declaran el soporte de renderizado en su adaptador saliente:Flujo de renderizado central
Cuando unReplyPayload o una acción de mensaje incluye presentation, el núcleo:
- Normaliza la carga útil de presentación.
- Resuelve el adaptador saliente del canal de destino.
- Lee
presentationCapabilities. - Llama a
renderPresentationcuando el adaptador puede renderizar la carga útil. - Recurre a texto conservador cuando el adaptador no existe o no puede renderizar.
- Envía la carga útil resultante por la ruta normal de entrega del canal.
- Aplica metadatos de entrega, como
delivery.pin, después del primer mensaje enviado correctamente.
Reglas de degradación
La presentación debe ser segura de enviar en canales limitados. El texto de respaldo incluye:titlecomo primera línea- bloques
textcomo párrafos normales - bloques
contextcomo líneas de contexto compactas - bloques
dividercomo separador visual - etiquetas de botones, incluidas las URL para botones de enlace
- etiquetas de opciones de selección
- Telegram con botones en línea deshabilitados envía texto de respaldo.
- Un canal sin soporte de selección enumera las opciones de selección como texto.
- Un botón solo con URL se convierte en un botón de enlace nativo o en una línea de URL de respaldo.
- Los errores opcionales al fijar no hacen fallar el mensaje entregado.
delivery.pin.required: true; si se solicita fijar como obligatorio y el canal no puede fijar el mensaje enviado, la entrega informa un error.
Asignación de proveedores
Renderizadores integrados actuales:| Canal | Destino de renderizado nativo | Notas |
|---|---|---|
| Discord | Componentes y contenedores de componentes | Preserva channelData.discord.components heredado para los productores de cargas útiles nativas de proveedor existentes, pero los nuevos envíos compartidos deben usar presentation. |
| Slack | Block Kit | Preserva channelData.slack.blocks heredado para los productores de cargas útiles nativas de proveedor existentes, pero los nuevos envíos compartidos deben usar presentation. |
| Telegram | Texto más teclados en línea | Los botones/selecciones requieren capacidad de botones en línea para la superficie de destino; de lo contrario, se usa texto de respaldo. |
| Mattermost | Texto más props interactivas | Otros bloques se degradan a texto. |
| Microsoft Teams | Adaptive Cards | El texto message simple se incluye con la tarjeta cuando se proporcionan ambos. |
| Feishu | Tarjetas interactivas | El encabezado de la tarjeta puede usar title; el cuerpo evita duplicar ese título. |
| Canales simples | Respaldo de texto | Los canales sin renderizador siguen obteniendo una salida legible. |
Presentación frente a InteractiveReply
InteractiveReply es el subconjunto interno más antiguo usado por los ayudantes de aprobación e interacción. Admite:
- texto
- botones
- selecciones
MessagePresentation es el contrato canónico de envío compartido. Agrega:
- título
- tono
- contexto
- divisor
- botones solo con URL
- metadatos de entrega genéricos mediante
ReplyPayload.delivery
openclaw/plugin-sdk/interactive-runtime al adaptar código anterior:
MessagePresentation directamente.
presentationToInteractiveReply(...) preserva el texto visible de presentación al asignar el título, texto, contexto, botones y selecciones a la forma anterior de InteractiveReply. Los renderizadores de componentes que ya dibujan de forma nativa bloques de título, texto, contexto y divisor deben usar presentationToInteractiveControlsReply(...) en su lugar, y luego anexar solo los controles de botón y selección.
renderMessagePresentationFallbackText(...) devuelve una cadena vacía para bloques de presentación que no tienen respaldo de texto, como una presentación que solo contiene divisores. Los transportes que requieren un cuerpo de envío no vacío pueden pasar emptyFallback para optar por un cuerpo mínimo sin cambiar el contrato predeterminado de respaldo.
Fijación de entrega
Fijar es un comportamiento de entrega, no de presentación. Usedelivery.pin en lugar de campos nativos de proveedor como channelData.telegram.pin.
Semántica:
pin: truefija el primer mensaje entregado correctamente.pin.notifytomafalsecomo valor predeterminado.pin.requiredtomafalsecomo valor predeterminado.- Los errores opcionales al fijar se degradan y dejan intacto el mensaje enviado.
- Los errores obligatorios al fijar hacen fallar la entrega.
- Los mensajes fragmentados fijan el primer fragmento entregado, no el fragmento final.
pin, unpin y pins siguen existiendo para mensajes existentes cuando el proveedor admite esas operaciones.
Lista de comprobación para autores de plugins
- Declare
presentationdesdedescribeMessageTool(...)cuando el canal pueda renderizar o degradar de forma segura la presentación semántica. - Agregue
presentationCapabilitiesal adaptador saliente de tiempo de ejecución. - Implemente
renderPresentationen código de tiempo de ejecución, no en código de configuración de Plugin del plano de control. - Mantenga las bibliotecas de UI nativa fuera de las rutas calientes de configuración/catálogo.
- Preserve los límites de la plataforma en el renderizador y las pruebas.
- Agregue pruebas de respaldo para botones no admitidos, selecciones, botones de URL, duplicación de título/texto y envíos mixtos de
messagemáspresentation. - Agregue soporte para fijación de entrega mediante
deliveryCapabilities.pinypinDeliveredMessagesolo cuando el proveedor pueda fijar el id del mensaje enviado. - No exponga nuevos campos nativos de proveedor de tarjeta/bloque/componente/botón mediante el esquema de acción de mensaje compartido.