Перейти к основному содержанию
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,
      },
    },
  },
}
Примечания:
  • Устранение дребезга применяется к сообщениям только с текстом; медиа/вложения отправляются немедленно.
  • Управляющие команды обходят устранение дребезга, чтобы оставаться самостоятельными. Каналы, которые явно включают объединение DM от одного отправителя, могут сохранять DM-команды внутри окна устранения дребезга, чтобы полезная нагрузка, отправленная частями, могла попасть в тот же ход агента.

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

Сеансами владеет Gateway, а не клиенты.
  • Прямые чаты сворачиваются в ключ основного сеанса агента.
  • Группы/каналы получают собственные ключи сеансов.
  • Хранилище сеансов и стенограммы находятся на хосте Gateway.
Несколько устройств/каналов могут сопоставляться с одним и тем же сеансом, но история не полностью синхронизируется обратно во все клиенты. Рекомендация: используйте одно основное устройство для длинных бесед, чтобы избежать расходящегося контекста. Control UI и TUI всегда показывают стенограмму сеанса, поддерживаемую Gateway, поэтому они являются источником истины. Подробности: Управление сеансами.

​
Метаданные результата инструмента

content результата инструмента — это видимый модели результат. details результата инструмента — это метаданные среды выполнения для отрисовки UI, диагностики, доставки медиа и Plugins. OpenClaw сохраняет эту границу явной:
  • toolResult.details удаляется перед повторным воспроизведением у провайдера и входом Compaction.
  • Сохраненные стенограммы сеансов оставляют только ограниченные details; слишком большие метаданные заменяются компактной сводкой с пометкой persistedDetailsTruncated: true.
  • Plugins и инструменты должны помещать текст, который должна прочитать модель, в content, а не только в details.

​
Тела входящих сообщений и контекст истории

OpenClaw отделяет тело промпта от тела команды:
  • BodyForAgent: основной текст для модели в текущем сообщении. Канальные Plugins должны удерживать его сфокусированным на текущем тексте отправителя, несущем промпт.
  • Body: устаревший резервный вариант промпта. Он может включать оболочки канала и необязательные обертки истории, но текущие каналы не должны полагаться на него как на основной ввод модели, когда доступен BodyForAgent.
  • CommandBody: исходный пользовательский текст для разбора директив/команд.
  • RawBody: устаревший псевдоним для CommandBody (сохранен для совместимости).
Когда канал передает историю, он использует общую обертку:
  • [Сообщения чата с момента вашего последнего ответа — для контекста]
  • [Текущее сообщение — ответьте на него]
Для непрямых чатов (групп/каналов/комнат) тело текущего сообщения получает префикс с меткой отправителя (в том же стиле, что и записи истории). Это сохраняет согласованность сообщений реального времени и сообщений из очереди/истории в промпте агента. Буферы истории являются только ожидающими: они включают групповые сообщения, которые не запустили прогон (например, сообщения, пропущенные через фильтр упоминаний), и исключают сообщения, уже находящиеся в стенограмме сеанса. Удаление директив применяется только к разделу текущего сообщения, чтобы история оставалась нетронутой. Каналы, которые оборачивают историю, должны устанавливать CommandBody (или RawBody) в исходный текст сообщения и оставлять Body объединенным промптом. Структурированная история, ответы, пересланные сообщения и метаданные канала отрисовываются как ненадежные контекстные блоки с ролью пользователя во время сборки промпта. Буферы истории настраиваются через messages.groupChat.historyLimit (глобальное значение по умолчанию) и переопределения для каналов, такие как channels.slack.historyLimit или channels.telegram.accounts.<id>.historyLimit (установите 0, чтобы отключить).

​
Очередь и последующие сообщения

Если прогон уже активен, входящие сообщения по умолчанию направляются в текущий прогон. messages.queue выбирает, будут ли сообщения при активном прогоне направляться, ставиться в очередь на потом, собираться в один последующий ход или прерывать активный прогон.
  • Настраивается через messages.queue (и messages.queue.byChannel).
  • Режим по умолчанию — steer, с устранением дребезга 500 мс для пакетов управления Codex и очередей followup/collect.
  • Режимы: steer, followup, collect и interrupt.
Подробности: Очередь команд и Очередь управления.

​
Владение прогоном каналом

Канальные Plugins могут сохранять порядок, устранять дребезг ввода и применять транспортное обратное давление до того, как сообщение попадет в очередь сеанса. Они не должны накладывать отдельный тайм-аут вокруг самого хода агента. После маршрутизации сообщения в сеанс длительная работа регулируется жизненным циклом сеанса, инструмента и среды выполнения, чтобы все каналы единообразно сообщали о медленных ходах и восстанавливались после них.

​
Потоковая передача, разбиение на фрагменты и пакетная обработка

Потоковая передача блоков отправляет частичные ответы по мере того, как модель создает текстовые блоки. Разбиение на фрагменты учитывает текстовые ограничения канала и избегает разделения огражденного кода. Ключевые настройки:
  • 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 поддерживает поток рассуждений во временный черновой пузырь, который удаляется после финальной доставки; используйте /reasoning on для постоянного вывода рассуждений.
Подробности: Директивы мышления + рассуждений и Использование токенов.

​
Префиксы, ветвление и ответы

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

​
Тихие ответы

Точный тихий токен NO_REPLY / no_reply означает «не доставлять видимый пользователю ответ». Когда в ходе также есть ожидающие медиа от инструмента, например сгенерированное TTS-аудио, OpenClaw удаляет тихий текст, но все равно доставляет медиа-вложение. OpenClaw разрешает это поведение по типу беседы:
  • Прямые беседы никогда не получают инструкции промпта NO_REPLY. Если прямой прогон случайно возвращает отдельный тихий токен, OpenClaw подавляет его вместо переписывания или доставки.
  • Группы/каналы по умолчанию допускают тишину только для автоматических групповых ответов. В режиме видимого ответа message_tool тишина означает, что модель не вызывает message(action=send).
  • Внутренняя оркестрация по умолчанию допускает тишину.
OpenClaw также использует тихие ответы для общих внутренних сбоев раннера в непрямых чатах, поэтому группы/каналы не видят шаблонный текст ошибки Gateway. Классифицированные сбои с пользовательским текстом восстановления, такие как отсутствие авторизации, уведомления об ограничении частоты или перегрузке, все еще могут доставляться. Прямые чаты по умолчанию показывают компактный текст сбоя; сырые детали раннера показываются только при включенном /verbose full. Значения по умолчанию находятся в agents.defaults.silentReply; surfaces.<id>.silentReply может переопределять групповую/внутреннюю политику для каждой поверхности. Отдельные тихие ответы отбрасываются на всех поверхностях, поэтому родительские сеансы остаются тихими вместо переписывания текста-сентинела в резервную болтовню.

​
Связанные разделы