---
read_when:
    - Пояснення того, як вхідні повідомлення перетворюються на відповіді
    - Уточнення щодо сесій, режимів черги або поведінки потокового виведення
    - Документування видимості міркувань і наслідків для використання
summary: Потік повідомлень, сесії, постановка в чергу та видимість міркувань
title: Повідомлення
x-i18n:
    generated_at: "2026-04-27T06:24:36Z"
    model: gpt-5.4
    provider: openai
    source_hash: 0fcfadebb41a96e8e50a818081adf63487234541cf7805f502dae914a39983c0
    source_path: concepts/messages.md
    workflow: 15
---

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.*` для типових значень потокового виведення блоками та chunking.
- Перевизначення для каналів (`channels.whatsapp.*`, `channels.telegram.*` тощо) для обмежень і перемикачів потокового виведення.

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

## Усунення дублікатів вхідних повідомлень

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

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

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

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

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

Примітки:

- Debounce застосовується до повідомлень **лише з текстом**; медіа/вкладення скидаються негайно.
- Керувальні команди оминають debouncing, щоб залишатися окремими, — **крім** випадків, коли канал явно вмикає об’єднання особистих повідомлень від того самого відправника (наприклад, [BlueBubbles `coalesceSameSenderDms`](/uk/channels/bluebubbles#coalescing-split-send-dms-command--url-in-one-composition)), де команди в особистих повідомленнях чекають у межах debounce-вікна, щоб payload розділеного надсилання міг приєднатися до того самого циклу агента.

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

Сесії належать gateway, а не клієнтам.

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

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

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

## Метадані результатів інструментів

`content` результату інструмента — це видимий моделі результат. `details` результату інструмента —
це метадані runtime для відображення в UI, діагностики, доставлення медіа та plugin.

OpenClaw чітко зберігає цю межу:

- `toolResult.details` вилучається перед повторним відтворенням провайдером і входом Compaction.
- У збережених transcripts сесій зберігаються лише обмежені `details`; надто великі метадані
  замінюються компактним підсумком із позначкою `persistedDetailsTruncated: true`.
- Plugin та інструменти повинні розміщувати текст, який модель має прочитати, у `content`, а не лише
  в `details`.

## Тіла вхідних повідомлень та контекст історії

OpenClaw розділяє **prompt body** і **command body**:

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

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

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

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

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

Вилучення директив застосовується лише до секції **поточного повідомлення**, щоб історія
залишалася недоторканою. Канали, які обгортають історію, повинні встановлювати `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.

Докладніше: [Постановка в чергу](/uk/concepts/queue).

## Потокове виведення, chunking і batching

Потокове виведення блоками надсилає часткові відповіді в міру того, як модель створює текстові блоки.
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 на основі простою)
- `agents.defaults.humanDelay` (людиноподібна пауза між блоками відповіді)
- Перевизначення для каналів: `*.blockStreaming` і `*.blockStreamingCoalesce` (для не-Telegram каналів потрібно явно вказати `*.blockStreaming: true`)

Докладніше: [Потокове виведення + chunking](/uk/concepts/streaming).

## Видимість міркувань і токени

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

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

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

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

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

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

Докладніше: [Конфігурація](/uk/gateway/config-agents#messages) і документація каналів.

## Тихі відповіді

Точний тихий токен `NO_REPLY` / `no_reply` означає «не доставляти видиму для користувача відповідь».
Коли цикл також має очікувальні медіа від інструментів, наприклад згенероване аудіо TTS, OpenClaw
вилучає тихий текст, але все одно доставляє вкладення з медіа.
OpenClaw визначає цю поведінку за типом розмови:

- Прямі розмови типово не дозволяють тишу та переписують чисто тиху
  відповідь на короткий видимий fallback.
- Групи/канали типово дозволяють тишу.
- Внутрішня оркестрація типово дозволяє тишу.

OpenClaw також використовує тихі відповіді для внутрішніх збоїв виконавця, які стаються
до будь-якої відповіді асистента в непрямих чатах, щоб групи/канали не бачили
службовий текст помилки gateway. Прямі чати типово показують компактний текст про збій;
сирі деталі виконавця показуються лише коли `/verbose` має значення `on` або `full`.

Типові значення знаходяться в `agents.defaults.silentReply` і
`agents.defaults.silentReplyRewrite`; `surfaces.<id>.silentReply` і
`surfaces.<id>.silentReplyRewrite` можуть перевизначати їх для кожної поверхні.

Коли батьківська сесія має один або більше очікувальних породжених запусків subagent,
чисто тихі відповіді відкидаються на всіх поверхнях замість переписування, щоб
батьківський процес залишався тихим, доки подія завершення дочірнього процесу не доставить справжню відповідь.

## Пов’язане

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