---
read_when:
    - Пояснення того, як вхідні повідомлення перетворюються на відповіді
    - Уточнення сесій, режимів черги або поведінки streaming
    - Документування видимості reasoning і наслідків використання
summary: Потік повідомлень, сесії, постановка в чергу та видимість reasoning
title: Повідомлення
x-i18n:
    generated_at: "2026-04-05T18:01:26Z"
    model: gpt-5.4
    provider: openai
    source_hash: 475f892bd534fdb10a2ee5d3c57a3d4a7fb8e1ab68d695189ba186004713f6f3
    source_path: concepts/messages.md
    workflow: 15
---

# Повідомлення

Ця сторінка поєднує пояснення того, як OpenClaw обробляє вхідні повідомлення, сесії, постановку в чергу,
streaming і видимість reasoning.

## Потік повідомлень (високий рівень)

```
Вхідне повідомлення
  -> routing/bindings -> ключ сесії
  -> черга (якщо запуск уже активний)
  -> запуск агента (streaming + інструменти)
  -> вихідні відповіді (обмеження каналу + chunking)
```

Ключові параметри містяться в конфігурації:

- `messages.*` для префіксів, постановки в чергу та групової поведінки.
- `agents.defaults.*` для типових значень block streaming і chunking.
- Перевизначення на рівні каналу (`channels.whatsapp.*`, `channels.telegram.*` тощо) для лімітів і перемикачів streaming.

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

## Дедуплікація вхідних повідомлень

Канали можуть повторно доставляти те саме повідомлення після перепідключення. OpenClaw зберігає
короткоживучий кеш із ключем за channel/account/peer/session/message id, щоб дубльовані
доставки не запускали ще один запуск агента.

## Debouncing вхідних повідомлень

Швидкі послідовні повідомлення від **того самого відправника** можуть бути об’єднані в один
хід агента через `messages.inbound`. Debouncing виконується в межах channel + conversation
і використовує найновіше повідомлення для thread reply/ID.

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

```json5
{
  messages: {
    inbound: {
      debounceMs: 2000,
      byChannel: {
        whatsapp: 5000,
        slack: 1500,
        discord: 1500,
      },
    },
  },
}
```

Примітки:

- Debounce застосовується до повідомлень **лише з текстом**; медіа/вкладення скидаються негайно.
- Керувальні команди обходять debouncing, щоб залишатися окремими.

## Сесії та пристрої

Сесіями володіє gateway, а не клієнти.

- Прямі чати згортаються в ключ основної сесії агента.
- Групи/канали отримують власні ключі сесій.
- Сховище сесій і транскрипти знаходяться на хості gateway.

Кілька пристроїв/каналів можуть відображатися на ту саму сесію, але історія не
синхронізується повністю назад на кожен клієнт. Рекомендація: використовуйте один основний пристрій для довгих
розмов, щоб уникнути розходження контексту. Control UI і TUI завжди показують
транскрипт сесії, що зберігається в gateway, тому саме вони є джерелом істини.

Докладніше: [Керування сесіями](/concepts/session).

## Вхідні тіла та контекст історії

OpenClaw розділяє **тіло prompt** і **тіло команди**:

- `Body`: текст prompt, надісланий агенту. Він може включати envelope каналу та
  необов’язкові обгортки історії.
- `CommandBody`: сирий текст користувача для розбору directive/command.
- `RawBody`: застарілий псевдонім для `CommandBody` (збережено для сумісності).

Коли канал надає історію, він використовує спільну обгортку:

- `[Chat messages since your last reply - for context]`
- `[Current message - respond to this]`

Для **непрямих чатів** (груп/каналів/кімнат) **тіло поточного повідомлення** має префікс із
міткою відправника (у тому ж стилі, що використовується для записів історії). Це забезпечує узгодженість
між повідомленнями в реальному часі та повідомленнями з черги/історії в prompt агента.

Буфери історії є **лише pending**: вони включають групові повідомлення, які _не_
запустили виконання (наприклад, повідомлення, відфільтровані через gating згадувань), і **не включають** повідомлення,
які вже є в транскрипті сесії.

Видалення directive застосовується лише до секції **поточного повідомлення**, щоб історія
залишалася незмінною. Канали, які обгортають історію, мають задавати `CommandBody` (або
`RawBody`) як оригінальний текст повідомлення, а `Body` залишати як об’єднаний prompt.
Буфери історії налаштовуються через `messages.groupChat.historyLimit` (глобальне
типове значення) і перевизначення на рівні каналу, як-от `channels.slack.historyLimit` або
`channels.telegram.accounts.<id>.historyLimit` (задайте `0`, щоб вимкнути).

## Постановка в чергу та followup

Якщо запуск уже активний, вхідні повідомлення можна поставити в чергу, спрямувати в
поточний запуск або зібрати для наступного ходу followup.

- Налаштовується через `messages.queue` (і `messages.queue.byChannel`).
- Режими: `interrupt`, `steer`, `followup`, `collect`, а також варіанти backlog.

Докладніше: [Черга](/concepts/queue).

## Streaming, chunking і batching

Block streaming надсилає часткові відповіді в міру того, як модель продукує текстові блоки.
Chunking враховує текстові обмеження каналу й уникає розбиття fenced code.

Ключові параметри:

- `agents.defaults.blockStreamingDefault` (`on|off`, типово off)
- `agents.defaults.blockStreamingBreak` (`text_end|message_end`)
- `agents.defaults.blockStreamingChunk` (`minChars|maxChars|breakPreference`)
- `agents.defaults.blockStreamingCoalesce` (batching на основі idle)
- `agents.defaults.humanDelay` (людиноподібна пауза між block replies)
- Перевизначення на рівні каналу: `*.blockStreaming` і `*.blockStreamingCoalesce` (для каналів, окрім Telegram, потрібне явне `*.blockStreaming: true`)

Докладніше: [Streaming + chunking](/concepts/streaming).

## Видимість reasoning і токени

OpenClaw може показувати або приховувати reasoning моделі:

- `/reasoning on|off|stream` керує видимістю.
- Вміст reasoning все одно враховується у використанні токенів, якщо його продукує модель.
- Telegram підтримує потік reasoning у draft bubble.

Докладніше: [Директиви thinking + reasoning](/tools/thinking) і [Використання токенів](/reference/token-use).

## Префікси, thread і відповіді

Форматування вихідних повідомлень централізоване в `messages`:

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

Докладніше: [Довідник конфігурації](/gateway/configuration-reference#messages) і документацію каналів.

## Пов’язане

- [Streaming](/concepts/streaming) — доставка повідомлень у реальному часі
- [Retry](/concepts/retry) — поведінка повторних спроб доставки повідомлень
- [Queue](/concepts/queue) — черга обробки повідомлень
- [Channels](/channels) — інтеграції платформ обміну повідомленнями
