> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Сообщения

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.*` и т. д.) для ограничений и переключателей потоковой передачи.

Полную схему см. в разделе [Конфигурация](/ru/gateway/configuration).

## Дедупликация входящих сообщений

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

## Устранение дребезга входящих сообщений

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

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

```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}}
{
  messages: {
    inbound: {
      debounceMs: 2000,
      byChannel: {
        whatsapp: 5000,
        slack: 1500,
        discord: 1500,
      },
    },
  },
}
```

Примечания:

* Устранение дребезга применяется к сообщениям **только с текстом**; медиа/вложения отправляются немедленно.
* Управляющие команды обходят устранение дребезга, чтобы оставаться самостоятельными. Каналы, которые явно включают объединение DM от одного отправителя, могут сохранять DM-команды внутри окна устранения дребезга, чтобы полезная нагрузка, отправленная частями, могла попасть в тот же ход агента.

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

Сеансами владеет Gateway, а не клиенты.

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

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

Подробности: [Управление сеансами](/ru/concepts/session).

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

`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`.

Подробности: [Очередь команд](/ru/concepts/queue) и [Очередь управления](/ru/concepts/queue-steering).

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

Канальные 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`)

Подробности: [Потоковая передача + разбиение на фрагменты](/ru/concepts/streaming).

## Видимость рассуждений и токены

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

* `/reasoning on|off|stream` управляет видимостью.
* Содержимое рассуждений по-прежнему учитывается в использовании токенов, когда его создает модель.
* Telegram поддерживает поток рассуждений во временный черновой пузырь, который удаляется после финальной доставки; используйте `/reasoning on` для постоянного вывода рассуждений.

Подробности: [Директивы мышления + рассуждений](/ru/tools/thinking) и [Использование токенов](/ru/reference/token-use).

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

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

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

Подробности: [Конфигурация](/ru/gateway/config-agents#messages) и документация каналов.

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

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

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

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

* [Рефакторинг жизненного цикла сообщений](/ru/concepts/message-lifecycle-refactor) - целевой надежный дизайн отправки и получения
* [Потоковая передача](/ru/concepts/streaming) — доставка сообщений в реальном времени
* [Повторная попытка](/ru/concepts/retry) — поведение повторной попытки доставки сообщений
* [Очередь](/ru/concepts/queue) — очередь обработки сообщений
* [Каналы](/ru/channels) — интеграции с платформами обмена сообщениями