Transmisión y fragmentación

OpenClaw tiene dos capas de transmisión independientes y, actualmente, no hay una verdadera transmisión de deltas de tokens a los mensajes de los canales:

• Transmisión por bloques (canales): emite bloques completados a medida que el asistente escribe. Son mensajes normales del canal, no deltas de tokens.
• Transmisión de vista previa (Telegram/Discord/Slack/Matrix/Mattermost/MS Teams): actualiza un mensaje de vista previa temporal durante la generación (envío + ediciones/adiciones).

Estado de inicio de la interfaz de control

Después de que chat.send confirme una ejecución activa, el Gateway puede enviar un estado de inicio general y tipado antes de que el texto del asistente o la actividad de las herramientas sean visibles. La interfaz de control muestra este estado junto al indicador de actividad, con etapas para la preparación del espacio de trabajo, el aprovisionamiento del entorno, la preparación del contexto y el inicio del modelo.

El primer delta del asistente o el inicio de una herramienta sustituye permanentemente el estado de inicio de esa ejecución. El estado de aprobación tiene prioridad mientras una herramienta espera una acción del operador. La creación del árbol de trabajo y el envío inicial a la nube se producen antes de que exista una ejecución de chat, por lo que el progreso de su RPC previo a la ejecución no se presenta como estado de inicio de la ejecución; el aprovisionamiento del entorno solo aparece aquí cuando una ejecución activa vuelve a aprovisionar un trabajador recuperado.

Transmisión por bloques (mensajes de canal)

La transmisión por bloques envía la salida del asistente en fragmentos grandes a medida que está disponible.

Salida del modelo  └─ text_delta/events       ├─ (blockStreamingBreak=text_end)       │    └─ el fragmentador emite bloques a medida que crece el búfer       └─ (blockStreamingBreak=message_end)            └─ el fragmentador vacía el búfer en message_end                   └─ envío al canal (respuestas por bloques)

• text_delta/events: eventos de transmisión del modelo (pueden ser escasos en modelos sin transmisión).
• chunker: EmbeddedBlockChunker que aplica límites mínimos/máximos y la preferencia de corte.
• channel send: mensajes salientes reales (respuestas por bloques).

Controles (todos bajo agents.defaults, salvo que se indique lo contrario):

streaming.chunkMode: "newline" divide por líneas en blanco (límites de párrafo), no por cada salto de línea, antes de recurrir a la división por longitud cuando el texto supera el límite.

Los canales incluidos expresan estas anulaciones como channels.<id>.streaming.{chunkMode,block.enabled,block.coalesce}. Las formas planas *.chunkMode / *.blockStreaming / *.blockStreamingCoalesce son heredadas en todos los canales incluidos: openclaw doctor --fix las migra a la estructura anidada y los esquemas de los canales las rechazan. Las configuraciones de plugins del SDK externos que todavía usan las formas planas siguen funcionando mediante un mecanismo alternativo obsoleto (con una advertencia en tiempo de ejecución) hasta el próximo ciclo de versiones.

Semántica de límites para blockStreamingBreak:

• text_end: transmite los bloques en cuanto el fragmentador los emite; vacía el búfer en cada text_end.
• message_end: espera hasta que termine el mensaje del asistente y después vacía la salida almacenada en el búfer. Sigue usando el fragmentador si el texto almacenado supera maxChars, por lo que puede emitir varios fragmentos al final.

Entrega de contenido multimedia con transmisión por bloques

El contenido multimedia transmitido debe usar campos de carga estructurados como mediaUrl o mediaUrls; el texto transmitido no se interpreta como un comando de adjunto. Cuando la transmisión por bloques envía contenido multimedia anticipadamente, OpenClaw recuerda esa entrega durante el turno. Si la carga final del asistente repite la misma URL del contenido multimedia, la entrega final elimina el contenido duplicado en lugar de volver a enviar el adjunto.

Las cargas finales exactamente duplicadas se suprimen. Si la carga final añade texto distinto alrededor del contenido multimedia que ya se transmitió, OpenClaw sigue enviando el texto nuevo y mantiene una única entrega del contenido multimedia. Esto evita la duplicación de notas de voz o archivos en canales como Telegram.

Algoritmo de fragmentación (límites inferior/superior)

La fragmentación por bloques se implementa mediante EmbeddedBlockChunker:

• Límite inferior: no emite hasta que el búfer >= minChars (salvo que se fuerce).
• Límite superior: da preferencia a las divisiones antes de maxChars; si se fuerza, divide en maxChars.
• Cadena de preferencia de corte: paragraph -> newline -> sentence -> espacio en blanco -> corte forzado.
• Bloques de código: nunca divide dentro de los bloques; cuando se fuerza en maxChars, cierra y vuelve a abrir el bloque para mantener válido el Markdown.

maxChars se restringe al textChunkLimit del canal, por lo que no se pueden superar los límites de cada canal.

Combinación (fusión de bloques transmitidos)

Cuando la transmisión por bloques está habilitada, OpenClaw puede fusionar fragmentos de bloques consecutivos antes de enviarlos, lo que reduce la proliferación de mensajes de una sola línea sin dejar de proporcionar una salida progresiva.

• La combinación espera a que haya intervalos de inactividad (idleMs) antes de vaciar el búfer.
• Los búferes están limitados por maxChars y se vacían si lo superan.
• minChars evita el envío de fragmentos pequeños hasta que se acumula suficiente texto (el vaciado final siempre envía el texto restante).
• El separador se deriva de blockStreamingChunk.breakPreference: paragraph -> \n\n, newline -> \n, sentence -> espacio.
• Las anulaciones de canal están disponibles mediante *.streaming.block.coalesce (incluidas las configuraciones por cuenta).
• Discord, Signal y Slack utilizan de forma predeterminada la combinación { minChars: 1500, idleMs: 1000 }, salvo que se anule.

Ritmo similar al humano entre bloques

Cuando la transmisión por bloques está habilitada, se añade una pausa aleatoria entre las respuestas por bloques después del primer bloque, para que las respuestas con varias burbujas resulten más naturales.

Se anula por agente mediante agents.entries.*.humanDelay. Solo se aplica a las respuestas por bloques, no a las respuestas finales ni a los resúmenes de herramientas.

«Transmitir fragmentos o todo»

• Transmitir fragmentos: blockStreamingDefault: "on" + blockStreamingBreak: "text_end" (emite sobre la marcha). Los canales distintos de Telegram también necesitan *.streaming.block.enabled: true.
• Transmitir todo al final: blockStreamingBreak: "message_end" (vacía el búfer una vez; pueden ser varios fragmentos si es muy largo).
• Sin transmisión por bloques: blockStreamingDefault: "off" (solo la respuesta final).

La transmisión por bloques está desactivada a menos que *.streaming.block.enabled se establezca explícitamente en true (excepción: QQ Bot no tiene claves streaming.block y transmite respuestas por bloques salvo que channels.qqbot.streaming.mode sea "off"). Los canales pueden transmitir una vista previa en directo (channels.<channel>.streaming.mode) sin respuestas por bloques. Los valores predeterminados de blockStreaming* se encuentran bajo agents.defaults, no en la raíz de la configuración.

Modos de transmisión de vista previa

Clave canónica: channels.<channel>.streaming ({ mode, ... } anidado; las formas booleanas/de cadena heredadas de nivel superior se reescriben mediante openclaw doctor --fix).

streaming.mode: "block" es un modo de transmisión de vista previa para canales que admiten ediciones, como Discord y Telegram; por sí solo, no habilita la entrega de bloques del canal en ellos. Use streaming.block.enabled para las respuestas por bloques normales. Microsoft Teams es la excepción: no dispone de transporte de bloques para borradores de vista previa, por lo que streaming.mode: "block" deshabilita por completo la transmisión nativa y la respuesta se entrega como una entrega normal por bloques en lugar de una transmisión nativa parcial/de progreso. Mattermost también es diferente: en el modo block, alterna la vista previa entre el texto completado y los bloques de actividad de las herramientas, de modo que los bloques anteriores permanecen visibles como publicaciones separadas en lugar de sobrescribirse en un único borrador editable.

Correspondencia de canales

La configuración de fragmentos de vista previa (streaming.preview.chunk.*, p. ej., bajo channels.discord.streaming o channels.telegram.streaming) tiene como valores predeterminados minChars: 200, maxChars: 800 (restringido al textChunkLimit del canal) y breakPreference: "paragraph".

Solo para Slack:

• channels.slack.streaming.nativeTransport activa o desactiva las llamadas a la API de transmisión nativa de Slack (chat.startStream/chat.appendStream/chat.stopStream) cuando channels.slack.streaming.mode="partial" (valor predeterminado: true).
• La transmisión nativa de Slack y el estado del hilo del asistente de Slack requieren un destino de hilo de respuesta. Los mensajes directos de nivel superior no muestran esa vista previa con estilo de hilo, pero pueden seguir usando publicaciones de vista previa de borrador de Slack y sus ediciones.

Migración de claves heredadas

Comportamiento en tiempo de ejecución

Telegram

• Utiliza actualizaciones de vista previa sendMessage + editMessageText en mensajes directos y grupos/temas; el texto final edita la vista previa activa en el mismo lugar. Los borradores efímeros de «escribiendo» durante 30 segundos de Telegram (sendMessageDraft) no se utilizan para la transmisión de respuestas.
• Las vistas previas iniciales breves aún se someten a una espera para mejorar la experiencia de las notificaciones push, pero se materializan tras un retraso acotado para que las ejecuciones activas no permanezcan visualmente silenciosas.
• Las respuestas finales largas reutilizan el mensaje de vista previa para el primer fragmento y envían solo los fragmentos restantes.
• El modo block convierte la vista previa en un mensaje nuevo al alcanzar streaming.preview.chunk.maxChars (valor predeterminado: 800, limitado al límite de edición de Telegram de 4096); los demás modos amplían una única vista previa hasta 4096 caracteres.
• El modo progress mantiene el progreso de las herramientas en un borrador de estado editable, materializa la etiqueta de estado cuando la transmisión de la respuesta está activa pero todavía no hay ninguna línea de herramienta disponible, borra el borrador al finalizar y envía la respuesta final mediante la entrega normal.
• Si la edición final falla antes de confirmar el texto completo, OpenClaw utiliza la entrega final normal y elimina la vista previa obsoleta.
• La transmisión de la vista previa se omite cuando la transmisión por bloques de Telegram está habilitada explícitamente, para evitar una transmisión duplicada.
• /reasoning stream puede escribir el razonamiento en una vista previa transitoria que se elimina después de la entrega final.
• Las respuestas a citas seleccionadas de Telegram son una excepción: cuando replyToMode no es "off" y hay texto de cita seleccionado, OpenClaw omite la transmisión de la vista previa de la respuesta para ese turno (la respuesta final debe pasar por la ruta nativa de respuesta a citas), por lo que no se pueden representar las líneas de vista previa del progreso de las herramientas. Las respuestas al mensaje actual sin texto de cita seleccionado siguen manteniendo la transmisión de la vista previa. Consulte la documentación del canal Telegram para obtener más información.

Discord

• Utiliza mensajes de vista previa enviados y editados.
• El modo block utiliza la fragmentación de borradores (draftChunk).
• La transmisión de la vista previa se omite cuando la transmisión por bloques de Discord está habilitada explícitamente.
• El modo progress añade un pequeño recibo de actividad -# (recuentos de pensamientos/llamadas a herramientas y tiempo transcurrido) a la respuesta final y elimina el borrador de estado una vez entregada dicha respuesta, para que los canales con mucha actividad no conserven ningún registro huérfano de herramientas encima de la respuesta. Las respuestas finales de error conservan el borrador como registro del turno fallido.
• Las cargas finales de contenido multimedia, errores y respuestas explícitas cancelan las vistas previas pendientes sin publicar un borrador nuevo y, después, utilizan la entrega normal.

Slack

• partial puede utilizar la transmisión nativa de Slack (chat.startStream/append/stop) cuando esté disponible.
• block utiliza vistas previas de borrador de tipo anexado.
• progress utiliza texto de vista previa de estado y, después, la respuesta final.
• Los mensajes directos de nivel superior sin un hilo de respuesta utilizan publicaciones y ediciones de vistas previas de borrador en lugar de la transmisión nativa de Slack.
• La transmisión de vistas previas nativas y de borrador suprime las respuestas por bloques durante ese turno, por lo que una respuesta de Slack se transmite mediante una única ruta de entrega.
• Las cargas finales de contenido multimedia/errores y las respuestas finales de progreso no crean mensajes de borrador desechables; solo el texto o los bloques finales que pueden editar la vista previa publican el texto de borrador pendiente.

Mattermost

• En el modo partial, transmite el razonamiento y el texto parcial de la respuesta en una única publicación de vista previa de borrador que se finaliza en el mismo lugar cuando es seguro enviar la respuesta final.
• En el modo progress, transmite el razonamiento y la actividad de las herramientas en una única vista previa de estado que se finaliza en el mismo lugar cuando es seguro enviar la respuesta final.
• En el modo block, alterna entre publicaciones de texto completado y de actividad de herramientas; las actualizaciones paralelas y consecutivas de herramientas comparten la publicación actual de actividad de herramientas.
• Recurre al envío de una publicación final nueva si la publicación de vista previa se eliminó o no está disponible por algún otro motivo en el momento de la finalización.
• Las cargas finales de contenido multimedia/errores cancelan las actualizaciones de vista previa pendientes antes de la entrega normal, en lugar de publicar una vista previa temporal.

Matrix

• Las vistas previas de borrador se finalizan en el mismo lugar cuando el texto final puede reutilizar el evento de vista previa.
• Las respuestas finales que solo contienen contenido multimedia, que contienen errores o cuyo destino de respuesta no coincide cancelan las actualizaciones de vista previa pendientes antes de la entrega normal; las vistas previas obsoletas que ya sean visibles se eliminan.

Actualizaciones de vista previa del progreso de herramientas

La transmisión de vistas previas también puede incluir actualizaciones del progreso de herramientas: líneas breves de estado como «buscando en la web», «leyendo un archivo» o «llamando a una herramienta» que aparecen en el mismo mensaje de vista previa mientras se ejecutan las herramientas, antes de la respuesta final. En el modo de servidor de aplicaciones de Codex, los mensajes de preámbulo/comentario de Codex utilizan esta misma ruta de vista previa, por lo que las notas breves de progreso como «Estoy comprobando...» pueden transmitirse al borrador editable sin convertirse en parte de la respuesta final. Esto mantiene visualmente activos los turnos de herramientas de varios pasos, en lugar de dejarlos silenciosos entre la primera vista previa de razonamiento y la respuesta final.

Las herramientas de larga duración pueden emitir progreso tipado antes de devolver un resultado. Por ejemplo, web_fetch activa un temporizador de cinco segundos al iniciarse: si la obtención aún está pendiente, la vista previa muestra Fetching page content...; si la obtención finaliza o se cancela antes, no se emite ninguna línea de progreso. El resultado final posterior de la herramienta se sigue entregando al modelo con normalidad.

Superficies compatibles:

• Discord, Slack, Telegram y Matrix transmiten de forma predeterminada el progreso de las herramientas y las actualizaciones de preámbulo de Codex a la edición de la vista previa activa cuando la transmisión de la vista previa está activa. Microsoft Teams utiliza su transmisión nativa de progreso en los chats personales.
• Telegram incluye las actualizaciones de vista previa del progreso de las herramientas habilitadas desde v2026.4.22; mantenerlas habilitadas preserva ese comportamiento publicado.
• Mattermost integra la actividad de las herramientas en una única publicación de vista previa en los modos partial y progress, o en una única publicación de actividad de herramientas entre bloques de texto en el modo block (véase más arriba).
• Las ediciones del progreso de las herramientas siguen el modo activo de transmisión de la vista previa; se omiten cuando la transmisión de la vista previa es off o cuando la transmisión por bloques ha asumido el control del mensaje. En Telegram, streaming.mode: "off" es solo para respuestas finales: la comunicación genérica de progreso también se suprime en lugar de entregarse como mensajes de estado independientes, mientras que las solicitudes de aprobación, las cargas de contenido multimedia y los errores se siguen procesando con normalidad.
• Para mantener la transmisión de la vista previa pero ocultar las líneas de progreso de las herramientas, establezca streaming.preview.toolProgress en false para ese canal (valor predeterminado: true). Para mantener visibles las líneas de progreso de las herramientas mientras se oculta el texto de comandos/ejecución, establezca streaming.preview.commandText en "status" o streaming.progress.commandText en "status"; el valor predeterminado es "raw" para preservar el comportamiento publicado. Esta política se comparte entre los canales de borrador/progreso que utilizan el procesador compacto de progreso de OpenClaw, incluidos Discord, Matrix, Microsoft Teams, Mattermost, las vistas previas de borrador de Slack y Telegram. Para deshabilitar por completo las ediciones de la vista previa, establezca streaming.mode en off.

Representación de borradores de progreso

Los borradores del modo de progreso (streaming.progress.*) están limitados y pueden configurarse por canal:

Canal de progreso de comentarios

Además del progreso de las herramientas, el procesador compacto de progreso puede mostrar un canal adicional en el borrador:

• streaming.progress.commentary: representa el comentario del modelo previo a las herramientas (una narración breve del tipo «Comprobaré... y después...»), intercalado con las líneas de las herramientas en el borrador de progreso. En Discord y Telegram, en el modo de progreso, el mismo preámbulo proporciona el encabezado de estado incluso cuando este canal opcional está desactivado; los demás canales mantienen su comportamiento de progreso existente. Consulte Borradores de progreso.

{  "channels": {    "discord": {      "streaming": { "mode": "progress", "progress": { "commentary": true } }    }  }}

Mantenga visibles las líneas de progreso, pero oculte el texto sin procesar de comandos/ejecución:

{  "channels": {    "telegram": {      "streaming": {        "mode": "partial",        "preview": {          "toolProgress": true,          "commandText": "status"        }      }    }  }}

Utilice la misma estructura bajo la clave de otro canal de progreso compacto, por ejemplo, channels.discord, channels.matrix, channels.msteams, channels.mattermost o las vistas previas de borrador de Slack. Para el modo de borrador de progreso, coloque la misma política bajo streaming.progress:

{  "channels": {    "telegram": {      "streaming": {        "mode": "progress",        "progress": {          "toolProgress": true,          "commandText": "status"        }      }    }  }}

Contenido relacionado

• Refactorización del ciclo de vida de los mensajes: diseño compartido de destino para vistas previas, edición, transmisión y finalización
• Borradores de progreso: mensajes visibles de trabajo en curso que se actualizan durante turnos largos
• Mensajes: ciclo de vida y entrega de los mensajes
• Reintentos: comportamiento de los reintentos ante fallos de entrega
• Canales: compatibilidad de transmisión por canal