Mensajes

Esta página conecta cómo OpenClaw maneja mensajes entrantes, sesiones, colas, streaming y visibilidad de razonamiento.

Mensaje entrante
  -> enrutamiento/bindings -> clave de sesión
  -> cola (si una ejecución está activa)
  -> ejecución de agente (streaming + herramientas)
  -> respuestas salientes (límites de canal + fragmentación)

Las perillas clave están principalmente en la configuración:

- ''messages.*'': prefijos, colas y comportamiento de chat grupal.

- ''agents.defaults.*'': valores predeterminados de bloqueo de streaming y fragmentación.

- Anulaciones de canal (''channels.whatsapp.*'', ''channels.telegram.*'', etc.): límites e interruptores de streaming.

Esquema completo en ''Configuración''.

Los canales pueden reenviar el mismo mensaje después de reconectar. OpenClaw mantiene un caché de corta duración (claveado por canal/cuenta/par/sesión/id de mensaje) para evitar que la entrega duplicada active una segunda ejecución del agente.

Cuando el mismo remitente envía múltiples mensajes en rápida sucesión, ''messages.inbound'' puede fusionarlos en un solo turno de agente. El debouncing tiene alcance por canal + sesión y usa el "mensaje más reciente" como fuente para hilos/IDs de respuesta.

Configuración (predeterminado global + anulaciones por canal):

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

Notas:

- El debouncing solo aplica a texto plano; medios/adjuntos se envían inmediatamente.

- Los comandos de control omiten el debouncing y permanecen como mensajes separados.

Las sesiones son mantenidas por el gateway, no por el cliente.

- Los mensajes privados por defecto se pliegan en la clave de sesión principal del agente.

- Los chats grupales/canales usan claves de sesión independientes.

- El almacén de sesiones y transcripciones vive en el host del gateway.

Múltiples dispositivos/canales pueden mapear a la misma sesión, pero el historial no se sincroniza 100% de vuelta a todos los clientes. Recomendación: usa un dispositivo principal para conversaciones largas para evitar bifurcación de contexto. La UI de control y TUI siempre muestran transcripciones respaldadas por gateway, así que son la fuente de verdad.

Detalles: ''/concepts/session''.

ReferenceConceptsMessagesPage step 04: P7

OpenClaw distingue entre cuerpo del prompt y cuerpo del comando:

- ''Body'': texto del prompt enviado al agente, posiblemente conteniendo envelope del canal y wrappers de historial opcionales.

- ''CommandBody'': texto crudo del usuario usado para análisis de directivas/comandos.

- ''RawBody'': alias legacy para ''CommandBody'' (mantenido por compatibilidad).

Cuando los canales proporcionan contexto de historial, se usa un wrapper unificado:

- ''[Mensajes de chat desde tu última respuesta - para contexto]''

- ''[Mensaje actual - responde a este]''

Para chats no directos (grupos/canales/salas), el cuerpo del mensaje actual incluye una etiqueta de remitente (mismo estilo que entradas de historial) para hacer los mensajes en tiempo real más consistentes con los mensajes en cola/historial en el prompt.

El búfer de historial es solo pendiente: incluye mensajes grupales que no activaron una ejecución debido a gateo por mención, y excluye mensajes ya escritos en la transcripción de sesión.

El stripping de directivas solo aplica al bloque del ''mensaje actual'', asegurando que el contenido del historial permanezca sin cambios. Los canales que envuelven historial deben establecer ''CommandBody'' (o ''RawBody'') al texto crudo del mensaje y ''Body'' al prompt combinado. El búfer de historial puede configurarse via ''messages.groupChat.historyLimit'' (predeterminado global) y anulaciones de canal (ej., ''channels.slack.historyLimit'', ''channels.telegram.accounts.<id>.historyLimit''); establecer en ''0'' para deshabilitar.

ReferenceConceptsMessagesPage step 05: P11

Cuando una ejecución está activa, nuevos mensajes entrantes pueden encolarse, inyectarse en la ejecución actual para steering, o recopilarse para turnos subsiguientes:

- Configurado via ''messages.queue'' (y ''messages.queue.byChannel'').

- Modos: ''interrupt'', ''steer'', ''followup'', ''collect'', y variantes de backlog.

Detalles: ''/concepts/queue''.

ReferenceConceptsMessagesPage step 06: P5

ReferenceConceptsMessagesPage step 06: P6

El streaming de bloques envía respuestas parciales mientras el modelo produce bloques de texto. La fragmentación respeta los límites de texto del canal e intenta evitar romper código cercado.

Configuraciones clave:

- ''agents.defaults.blockStreamingDefault'' (''on|off'', predeterminado off)

- ''agents.defaults.blockStreamingBreak'' (''text_end|message_end'')

- ''agents.defaults.blockStreamingChunk'' (''minChars|maxChars|breakPreference'')

- ''agents.defaults.blockStreamingCoalesce'' (coalescencia basada en inactividad)

- ''agents.defaults.humanDelay'' (pausas tipo humano)

- Anulaciones de canal: ''*.blockStreaming'' y ''*.blockStreamingCoalesce'' (canales no-Telegram necesitan ''*.blockStreaming: true'' explícito)

OpenClaw puede mostrar u ocultar el razonamiento del modelo:

- ''/reasoning on|off|stream'' controla la visibilidad.

- El contenido de razonamiento cuenta hacia el uso de tokens cuando es producido por el modelo.

- Telegram soporta streaming de razonamiento en burbujas de borrador.

Detalles: ''/tools/thinking'', ''/token-use''.

El formato saliente está centralizado en ''messages'':

- ''messages.responsePrefix'' (prefijo saliente) y ''channels.whatsapp.messagePrefix'' (prefijo entrante de WhatsApp)

- Hilos de respuesta controlados via ''replyToMode'' y predeterminados por canal

Detalles: ''/gateway/configuration#messages'' y documentación por canal.