Сообщения¶

Эта страница объединяет описание того, как OpenClaw обрабатывает входящие сообщения, сеансы, очереди, потоковую передачу и видимость рассуждений.

Поток сообщений (высокоуровнево)¶

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

Ключевые параметры находятся в конфигурации:

• messages.* — для префиксов, очередей и поведения в группах.
• agents.defaults.* — для потоковой передачи блоками и значений по умолчанию для разбиения на чанки.
• Переопределения на уровне канала (channels.whatsapp.*, channels.telegram.* и т. д.) — для лимитов и переключателей потоковой передачи.

Полная схема: см. Конфигурация.

Входящий выкуп¶

Каналы могут повторно доставлять одно и то же сообщение после переподключений. OpenClaw хранит краткоживущий кэш, индексируемый по каналу/аккаунту/собеседнику/сеансу/id сообщения, чтобы повторные доставки не запускали агента повторно.

Входящее обсуждение¶

Быстрые последовательные сообщения от одного и того же отправителя могут объединяться в один ход агента с помощью messages.inbound. Дебаунсинг применяется в рамках канала + диалога и использует самое последнее сообщение для трединга ответов/ID.

Конфиг (глобальное значение по умолчанию + переопределения на уровне канала):

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

Примечания:

• Дебаунсинг применяется только к текстовым сообщениям; медиа/вложения немедленно сбрасываются.
• Управляющие команды обходят дебаунсинг, чтобы оставаться самостоятельными.

Сеансы и устройства¶

Сеансы принадлежат Gateway (шлюзу), а не клиентам.

• Прямые чаты сворачиваются в основной ключ сеанса агента.
• Группы/каналы получают собственные ключи сеансов.
• Хранилище сеансов и транскрипты находятся на хосте шлюза Gateway.

Несколько устройств/каналов могут сопоставляться с одним и тем же сеансом, но история не полностью синхронизируется обратно на каждый клиент. Рекомендация: используйте одно основное устройство для длительных разговоров, чтобы избежать расхождения контекста. Control UI и TUI всегда показывают транскрипт сеанса, поддерживаемый Gateway (шлюзом), поэтому они являются источником истины.

Подробности: Управление сеансами.

Входящие тела и контекст истории¶

OpenClaw разделяет тело запроса (prompt) и тело команды:

• Body: текст prompt, отправляемый агенту. Может включать конверты канала и необязательные обёртки истории.
• CommandBody: исходный пользовательский текст для разбора директив/команд.
• RawBody: устаревший алиас для CommandBody (оставлен для совместимости).

Когда канал предоставляет историю, используется общая обёртка:

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

Для непрямых чатов (группы/каналы/комнаты) текущее тело сообщения дополняется префиксом с меткой отправителя (в том же стиле, что и для записей истории). Это обеспечивает согласованность между сообщениями в реальном времени и сообщениями из очереди/истории в prompt агента.

Буферы истории являются только ожидающими: они включают групповые сообщения, которые не запустили выполнение (например, сообщения с гейтом по упоминанию), и исключают сообщения, уже присутствующие в транскрипте сеанса.

Удаление директив применяется только к разделу текущего сообщения, поэтому история остаётся неизменной. Каналы, которые оборачивают историю, должны устанавливать CommandBody (или RawBody) в исходный текст сообщения и сохранять Body как объединённый prompt. Буферы истории настраиваются через messages.groupChat.historyLimit (глобальное значение по умолчанию) и переопределения на уровне канала, такие как channels.slack.historyLimit или channels.telegram.accounts.<id>.historyLimit (установите 0 для отключения).

Очередь и последующие действия¶

Если выполнение уже активно, входящие сообщения могут быть поставлены в очередь, направлены в текущее выполнение или собраны для последующего хода.

• Настройка через messages.queue (и messages.queue.byChannel).
• Режимы: interrupt, steer, followup, collect, а также варианты с backlog.

Подробности: Очереди.

Вещание, обручение и партия¶

Потоковая передача блоками отправляет частичные ответы по мере того, как модель производит текстовые блоки. Разбиение на чанки учитывает лимиты текста канала и избегает разрыва ограждённых блоков кода.

Ключевые настройки:

• agents.defaults.blockStreamingDefault (on|off, по умолчанию выключено)
• agents.defaults.blockStreamingBreak (text_end|message_end)
• agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
• agents.defaults.blockStreamingCoalesce (батчинг на основе простоя)
• agents.defaults.humanDelay (человеко‑подобная пауза между ответами блоков)
• Переопределения на уровне канала: *.blockStreaming и *.blockStreamingCoalesce (каналы, отличные от Telegram, требуют явного *.blockStreaming: true)

Подробности: Потоковая передача + разбиение на чанки.

Разумная видимость и токены¶

OpenClaw может показывать или скрывать рассуждения модели:

• /reasoning on|off|stream управляет видимостью.
• Контент рассуждений всё равно учитывается в использовании токенов, если он производится моделью.
• Telegram поддерживает потоковую передачу рассуждений в черновой «пузырь» сообщения.

Подробности: Директивы мышления + рассуждений и Использование токенов.

Префиксы, трединг и ответы¶

Форматирование исходящих сообщений централизовано в messages:

• messages.responsePrefix, channels.<channel>.responsePrefix и channels.<channel>.accounts.<id>.responsePrefix (каскад исходящих префиксов), а также channels.whatsapp.messagePrefix (входящий префикс WhatsApp)
• Трединг ответов через replyToMode и значения по умолчанию на уровне канала

Подробности: Конфигурация и документация по каналам.