Перейти к основному содержанию

​
Сообщения

Эта страница объединяет описание того, как 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 и значения по умолчанию на уровне канала
Подробности: Конфигурация и документация по каналам.