Mensajes

OpenClaw gestiona los mensajes entrantes mediante una canalización de resolución de sesiones, puesta en cola, streaming, ejecución de herramientas y visibilidad del razonamiento. Esta página mapea la ruta desde el mensaje entrante hasta la respuesta.

Flujo de mensajes (alto nivel)

Inbound message  -> routing/bindings -> session key  -> queue (if a run is active)  -> agent run (streaming + tools)  -> outbound replies (channel limits + chunking)

Los ajustes clave están en la configuración:

• messages.* para prefijos, puesta en cola y comportamiento de grupos.
• agents.defaults.* para valores predeterminados de streaming de bloques y segmentación.
• Sobrescrituras de canal (channels.whatsapp.*, channels.telegram.*, etc.) para límites y conmutadores de streaming.

Consulta Configuración para ver el esquema completo.

Desduplicación entrante

Los canales pueden volver a entregar el mismo mensaje después de reconexiones. OpenClaw mantiene una caché de corta duración con clave por canal/cuenta/par/sesión/id de mensaje para que las entregas duplicadas no activen otra ejecución del agente.

Debouncing entrante

Los mensajes consecutivos rápidos del mismo remitente pueden agruparse en un solo turno del agente mediante messages.inbound. El debouncing se delimita por canal + conversación y usa el mensaje más reciente para el encadenamiento/los IDs de respuesta.

Configuración (valor predeterminado global + sobrescrituras por canal):

{  messages: {    inbound: {      debounceMs: 2000,      byChannel: {        whatsapp: 5000,        slack: 1500,        discord: 1500,      },    },  },}

Notas:

• El debounce se aplica a mensajes solo de texto; los medios/adjuntos se vacían inmediatamente.
• Los comandos de control omiten el debouncing para mantenerse independientes. Los canales que optan explícitamente por fusionar mensajes directos del mismo remitente pueden mantener los comandos de DM dentro de la ventana de debounce para que una carga enviada en partes pueda unirse al mismo turno del agente.

Sesiones y dispositivos

Las sesiones pertenecen al Gateway, no a los clientes.

• Los chats directos se condensan en la clave de sesión principal del agente.
• Los grupos/canales obtienen sus propias claves de sesión.
• El almacén de sesiones y las transcripciones viven en el host del Gateway.

Varios dispositivos/canales pueden mapearse a la misma sesión, pero el historial no se sincroniza por completo de vuelta a cada cliente. Recomendación: usa un dispositivo principal para conversaciones largas a fin de evitar contexto divergente. La Control UI y la TUI siempre muestran la transcripción de sesión respaldada por el Gateway, por lo que son la fuente de verdad.

Detalles: Gestión de sesiones.

Metadatos de resultados de herramientas

El content del resultado de herramienta es el resultado visible para el modelo. details del resultado de herramienta son metadatos de runtime para renderizado de UI, diagnósticos, entrega de medios y plugins.

OpenClaw mantiene explícito ese límite:

• toolResult.details se elimina antes de la reproducción del proveedor y la entrada de Compaction.
• Las transcripciones de sesión persistidas conservan solo details acotados; los metadatos demasiado grandes se reemplazan por un resumen compacto marcado como persistedDetailsTruncated: true.
• Los plugins y las herramientas deben poner el texto que el modelo debe leer en content, no solo en details.

Cuerpos entrantes y contexto de historial

OpenClaw separa el cuerpo del prompt del cuerpo del comando:

• BodyForAgent: texto principal orientado al modelo para el mensaje actual. Los plugins de canal deben mantenerlo centrado en el texto actual del remitente que contiene el prompt.
• Body: fallback de prompt heredado. Puede incluir envoltorios de canal y wrappers opcionales de historial, pero los canales actuales no deben depender de él como entrada principal del modelo cuando BodyForAgent está disponible.
• CommandBody: texto sin procesar del usuario para el análisis de directivas/comandos.
• RawBody: alias heredado de CommandBody (conservado por compatibilidad).

Cuando un canal proporciona historial, usa un wrapper compartido:

• [Chat messages since your last reply - for context]
• [Current message - respond to this]

Para chats no directos (grupos/canales/salas), el cuerpo del mensaje actual lleva como prefijo la etiqueta del remitente (el mismo estilo usado para las entradas del historial). Esto mantiene coherentes los mensajes en tiempo real y en cola/historial dentro del prompt del agente.

Los búferes de historial son solo pendientes: incluyen mensajes de grupo que no activaron una ejecución (por ejemplo, mensajes filtrados por mención) y excluyen mensajes ya presentes en la transcripción de la sesión.

La eliminación de directivas solo se aplica a la sección del mensaje actual para que el historial permanezca intacto. Los canales que envuelven historial deben establecer CommandBody (o RawBody) en el texto original del mensaje y mantener Body como el prompt combinado. El historial estructurado, las respuestas, los mensajes reenviados y los metadatos de canal se renderizan como bloques de contexto no confiables de rol de usuario durante el ensamblado del prompt. Los búferes de historial se configuran mediante messages.groupChat.historyLimit (valor predeterminado global) y sobrescrituras por canal como channels.slack.historyLimit o channels.telegram.accounts.<id>.historyLimit (establece 0 para desactivar).

Puesta en cola y seguimientos

Si una ejecución ya está activa, los mensajes entrantes se dirigen a la ejecución actual de forma predeterminada. messages.queue selecciona si los mensajes durante una ejecución activa se dirigen, se ponen en cola para después, se recopilan en un turno posterior o interrumpen la ejecución activa.

• Configura mediante messages.queue (y messages.queue.byChannel).
• El modo predeterminado es steer, con un debounce de 500 ms para lotes de dirección de Codex y colas de followup/collect.
• Modos: steer, followup, collect e interrupt.

Detalles: Cola de comandos y Cola de dirección.

Propiedad de ejecución del canal

Los plugins de canal pueden preservar el orden, aplicar debounce a la entrada y aplicar contrapresión de transporte antes de que un mensaje entre en la cola de sesión. No deben imponer un tiempo de espera separado alrededor del propio turno del agente. Una vez que un mensaje se enruta a una sesión, el trabajo de larga duración se gobierna por el ciclo de vida de la sesión, la herramienta y el runtime para que todos los canales informen y se recuperen de turnos lentos de forma coherente.

Streaming, segmentación y agrupación

El streaming de bloques envía respuestas parciales a medida que el modelo produce bloques de texto. La segmentación respeta los límites de texto del canal y evita dividir código delimitado.

Ajustes clave:

• agents.defaults.blockStreamingDefault (on|off, desactivado de forma predeterminada)
• agents.defaults.blockStreamingBreak (text_end|message_end)
• agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
• agents.defaults.blockStreamingCoalesce (agrupación basada en inactividad)
• agents.defaults.humanDelay (pausa similar a la humana entre respuestas por bloques)
• Sobrescrituras de canal: *.blockStreaming y *.blockStreamingCoalesce (los canales que no son Telegram requieren *.blockStreaming: true explícito)

Detalles: Streaming + segmentación.

Visibilidad del razonamiento y tokens

OpenClaw puede mostrar u ocultar el razonamiento del modelo:

• /reasoning on|off|stream controla la visibilidad.
• El contenido de razonamiento sigue contando para el uso de tokens cuando lo produce el modelo.
• Telegram admite streaming de razonamiento en una burbuja de borrador transitoria que se elimina después de la entrega final; usa /reasoning on para salida de razonamiento persistente.

Detalles: Directivas de pensamiento + razonamiento y Uso de tokens.

Prefijos, encadenamiento y respuestas

El formato de mensajes salientes está centralizado en messages:

• messages.responsePrefix, channels.<channel>.responsePrefix y channels.<channel>.accounts.<id>.responsePrefix (cascada de prefijos salientes), además de channels.whatsapp.messagePrefix (prefijo entrante de WhatsApp)
• Encadenamiento de respuestas mediante replyToMode y valores predeterminados por canal

Detalles: Configuración y documentación de canales.

Respuestas silenciosas

El token silencioso exacto NO_REPLY / no_reply significa "no entregar una respuesta visible para el usuario". Cuando un turno también tiene medios de herramienta pendientes, como audio TTS generado, OpenClaw elimina el texto silencioso pero aun así entrega el adjunto multimedia. OpenClaw resuelve ese comportamiento por tipo de conversación:

• Las conversaciones directas nunca reciben guía de prompt NO_REPLY. Si una ejecución directa devuelve accidentalmente un token silencioso desnudo, OpenClaw lo suprime en lugar de reescribirlo o entregarlo.
• Los grupos/canales permiten silencio de forma predeterminada solo para respuestas automáticas de grupo. En modo de respuesta visible message_tool, el silencio significa que el modelo no llama a message(action=send).
• La orquestación interna permite silencio de forma predeterminada.

OpenClaw también usa respuestas silenciosas para fallos genéricos del ejecutor interno en chats no directos, de modo que los grupos/canales no vean texto repetitivo de error del Gateway. Los fallos clasificados con texto de recuperación orientado al usuario, como falta de autenticación, límite de tasa o avisos de sobrecarga, aún pueden entregarse. Los chats directos muestran texto compacto de fallo de forma predeterminada; los detalles sin procesar del ejecutor solo se muestran cuando /verbose full está activado.

Los valores predeterminados viven bajo agents.defaults.silentReply; surfaces.<id>.silentReply puede sobrescribir la política de grupo/interna por superficie.

Las respuestas silenciosas desnudas se descartan en todas las superficies, por lo que las sesiones padre permanecen en silencio en lugar de reescribir texto centinela como charla de fallback.

Relacionado

• Refactorización del ciclo de vida de mensajes - diseño objetivo duradero de envío y recepción
• Streaming — entrega de mensajes en tiempo real
• Reintento — comportamiento de reintento de entrega de mensajes
• Cola — cola de procesamiento de mensajes
• Canales — integraciones con plataformas de mensajería