---
read_when:
    - Объяснение того, как входящие сообщения становятся ответами
    - Уточнение сессий, режимов очередей или поведения потоковой передачи
    - Документирование видимости рассуждений и последствий использования
summary: Поток сообщений, сессии, постановка в очередь и видимость рассуждений
title: Сообщения
x-i18n:
    generated_at: "2026-06-28T22:50:52Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: d5585ae95fc65cb64240e4bf5d0bbe2eb54f55461b9fa4ee331d4d703d62e76f
    source_path: concepts/messages.md
    workflow: 16
---

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
{
  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) — интеграции с платформами обмена сообщениями