Сообщения

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 может переопределять групповую/внутреннюю политику для каждой поверхности.

Отдельные тихие ответы отбрасываются на всех поверхностях, поэтому родительские сеансы остаются тихими вместо переписывания текста-сентинела в резервную болтовню.

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

• Рефакторинг жизненного цикла сообщений - целевой надежный дизайн отправки и получения
• Потоковая передача — доставка сообщений в реальном времени
• Повторная попытка — поведение повторной попытки доставки сообщений
• Очередь — очередь обработки сообщений
• Каналы — интеграции с платформами обмена сообщениями