Configura el flujo de mensajes en OpenClaw: Guía técnica

¿Alguna vez has intentado gestionar mensajes que llegan de varias plataformas distintas al mismo tiempo? Es un caos. Entre los mensajes duplicados por problemas de red, las ráfagas de texto que deberían ser una sola idea y la pérdida de contexto, mantener una conversación coherente con un agente de IA puede ser frustrante.

OpenClaw está diseñado para resolver estos problemas de raíz, centralizando la lógica de los mensajes para que tú no tengas que preocuparte por la infraestructura de cada canal.

Mensajes

Esta página detalla cómo OpenClaw gestiona los mensajes entrantes, las sesiones, las colas, el streaming y la visibilidad del razonamiento.

Flujo de mensajes (nivel alto)

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

Los ajustes principales se encuentran en la configuración:

• messages.* para prefijos, colas y comportamiento de grupos.
• agents.defaults.* para los valores predeterminados de block streaming y fragmentación.
• Sobrescrituras por canal (channels.whatsapp.*, channels.telegram.*, etc.) para límites y activadores de streaming.

Consulta la Configuración para ver el esquema completo.

Deduplicación de entrada

Los canales pueden volver a enviar el mismo mensaje tras una reconexión. OpenClaw mantiene un caché de vida corta indexado por canal/cuenta/par/sesión/ID de mensaje para que las entregas duplicadas no activen otra ejecución del agente.

Debouncing de entrada

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

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

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

Notas:

• El debounce se aplica a mensajes de solo texto; los archivos multimedia o adjuntos se envían inmediatamente.
• Los comandos de control omiten el debouncing para que sigan siendo independientes.

Sesiones y dispositivos

Las sesiones pertenecen al Gateway, no a los clientes.

• Los chats directos se agrupan en la clave de sesión principal del agente.
• Los grupos o canales obtienen sus propias claves de sesión.
• El almacenamiento de sesiones y las transcripciones residen en el host del Gateway.

Varios dispositivos o canales pueden apuntar a la misma sesión, pero el historial no se sincroniza totalmente con cada cliente. Recomendación: usa un dispositivo principal para conversaciones largas para evitar contextos divergentes. La interfaz de control y la TUI siempre muestran la transcripción de la sesión respaldada por el Gateway, por lo que son la fuente de verdad.

Detalles: Gestión de sesiones.

Cuerpos de entrada y contexto del historial

OpenClaw separa el prompt body del command body:

• Body: texto del prompt enviado al agente. Puede incluir sobres de canal y envoltorios de historial opcionales.
• CommandBody: texto bruto del usuario para el análisis de directivas o comandos.
• RawBody: alias antiguo para CommandBody (mantenido por compatibilidad).

Cuando un canal proporciona historial, utiliza un envoltorio compartido:

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

Para chats que no son directos (grupos, canales o salas), el cuerpo del mensaje actual lleva el prefijo de la etiqueta del remitente (el mismo estilo usado para las entradas del historial). Esto mantiene la consistencia entre los mensajes en tiempo real y los mensajes en cola o del historial en el prompt del agente.

Los buffers de historial son solo para mensajes pendientes: incluyen mensajes de grupo que no activaron una ejecución (por ejemplo, mensajes filtrados por mención) y excluyen mensajes que ya están 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 el historial deben configurar CommandBody (o RawBody) con el texto del mensaje original y mantener Body como el prompt combinado. Los buffers de historial son configurables mediante messages.groupChat.historyLimit (predeterminado global) y sobrescrituras por canal como channels.slack.historyLimit o channels.telegram.accounts.<id>.historyLimit (establece 0 para desactivar).

Colas y seguimientos

Si una ejecución ya está activa, los mensajes entrantes pueden ponerse en cola, dirigirse a la ejecución actual o recopilarse para un turno de seguimiento.

• Configura esto mediante messages.queue (y messages.queue.byChannel).
• Modos: interrupt, steer, followup, collect, además de variantes de backlog.

Detalles: Colas.

Streaming, fragmentación y procesamiento por lotes

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

Ajustes clave:

• agents.defaults.blockStreamingDefault (on|off, por defecto off)
• agents.defaults.blockStreamingBreak (text_end|message_end)
• agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
• agents.defaults.blockStreamingCoalesce (procesamiento por lotes basado en inactividad)
• agents.defaults.humanDelay (pausa similar a la humana entre respuestas de bloques)
• Sobrescrituras de canal: *.blockStreaming y *.blockStreamingCoalesce (los canales que no son Telegram requieren explícitamente *.blockStreaming: true)

Detalles: Streaming + fragmentación.

Visibilidad del razonamiento y tokens

OpenClaw puede mostrar u ocultar el razonamiento del modelo:

• /reasoning on|off|stream controla la visibilidad.
• El contenido del razonamiento sigue contando para el uso de tokens cuando el modelo lo produce.
• Telegram admite el streaming de razonamiento en la burbuja de borrador.

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

Prefijos, hilos y respuestas

El formato de los mensajes de salida está centralizado en messages:

• messages.responsePrefix, channels.<channel>.responsePrefix, y channels.<channel>.accounts.<id>.responsePrefix (cascada de prefijos de salida), además de channels.whatsapp.messagePrefix (prefijo de entrada de WhatsApp).
• Hilos de respuesta mediante replyToMode y valores predeterminados por canal.

Detalles: Referencia de configuración y documentación de canales.

Relacionado

• Streaming — entrega de mensajes en tiempo real
• Retry — comportamiento de reintento en la entrega de mensajes
• Queue — cola de procesamiento de mensajes
• Channels — integraciones con plataformas de mensajería

Pasos siguientes

• Configura tu primer canal en la sección de Channels.
• Aprende a optimizar el gasto en la guía de Uso de tokens.

AI Setup Assistant