---
read_when:
    - Пояснення того, як потокове передавання або розбиття на частини працює в каналах
    - Зміна поведінки потокового передавання блоків або розбиття на частини в каналах
    - Налагодження дубльованих/передчасних блокових відповідей або потокового передавання попереднього перегляду в каналах
summary: Поведінка потокового передавання та розбиття на частини (блокові відповіді, потокове передавання попереднього перегляду в каналах, зіставлення режимів)
title: Потокове передавання та розбиття на частини
x-i18n:
    generated_at: "2026-04-08T04:59:57Z"
    model: gpt-5.4
    provider: openai
    source_hash: a8e847bb7da890818cd79dec7777f6ae488e6d6c0468e948e56b6b6c598e0000
    source_path: concepts/streaming.md
    workflow: 15
---

# Потокове передавання та розбиття на частини

OpenClaw має два окремі шари потокового передавання:

- **Потокове передавання блоків (канали):** надсилає завершені **блоки**, поки помічник пише. Це звичайні повідомлення каналу (не дельти токенів).
- **Потокове передавання попереднього перегляду (Telegram/Discord/Slack):** оновлює тимчасове **повідомлення попереднього перегляду** під час генерації.

Справжнього **потокового передавання дельт токенів** у повідомлення каналів наразі **немає**. Потокове передавання попереднього перегляду є повідомлень-орієнтованим (надсилання + редагування/додавання).

## Потокове передавання блоків (повідомлення каналів)

Потокове передавання блоків надсилає вивід помічника великими частинами в міру його появи.

```
Вивід моделі
  └─ text_delta/events
       ├─ (blockStreamingBreak=text_end)
       │    └─ chunker emits blocks as buffer grows
       └─ (blockStreamingBreak=message_end)
            └─ chunker flushes at message_end
                   └─ channel send (block replies)
```

Легенда:

- `text_delta/events`: події потоку моделі (можуть бути рідкісними для моделей без потокового передавання).
- `chunker`: `EmbeddedBlockChunker`, що застосовує мінімальні/максимальні межі + пріоритет розриву.
- `channel send`: фактичні вихідні повідомлення (блокові відповіді).

**Керування:**

- `agents.defaults.blockStreamingDefault`: `"on"`/`"off"` (типово вимкнено).
- Перевизначення для каналів: `*.blockStreaming` (і варіанти для окремих облікових записів), щоб примусово встановити `"on"`/`"off"` для кожного каналу.
- `agents.defaults.blockStreamingBreak`: `"text_end"` або `"message_end"`.
- `agents.defaults.blockStreamingChunk`: `{ minChars, maxChars, breakPreference? }`.
- `agents.defaults.blockStreamingCoalesce`: `{ minChars?, maxChars?, idleMs? }` (об’єднання потокових блоків перед надсиланням).
- Жорстке обмеження каналу: `*.textChunkLimit` (наприклад, `channels.whatsapp.textChunkLimit`).
- Режим розбиття на частини для каналу: `*.chunkMode` (`length` типово, `newline` розбиває за порожніми рядками (межами абзаців) перед розбиттям за довжиною).
- М’яке обмеження Discord: `channels.discord.maxLinesPerMessage` (типово 17) розбиває високі відповіді, щоб уникнути обрізання в інтерфейсі.

**Семантика меж:**

- `text_end`: передавати блоки потоком щойно `chunker` їх видає; скидати буфер на кожному `text_end`.
- `message_end`: чекати, доки повідомлення помічника завершиться, а потім скидати буферизований вивід.

`message_end` усе одно використовує `chunker`, якщо буферизований текст перевищує `maxChars`, тому наприкінці він може видати кілька частин.

## Алгоритм розбиття на частини (нижня/верхня межа)

Розбиття блоків на частини реалізовано в `EmbeddedBlockChunker`:

- **Нижня межа:** не видавати нічого, доки буфер не стане >= `minChars` (якщо не примусово).
- **Верхня межа:** намагатися розбивати до `maxChars`; якщо примусово, розбивати на `maxChars`.
- **Пріоритет розриву:** `paragraph` → `newline` → `sentence` → `whitespace` → жорсткий розрив.
- **Огородження коду:** ніколи не розбивати всередині огороджень; у разі примусового розриву на `maxChars` огородження закривається й знову відкривається, щоб Markdown залишався коректним.

`maxChars` обмежується значенням `textChunkLimit` каналу, тому перевищити обмеження для конкретного каналу неможливо.

## Об’єднання (злиття потокових блоків)

Коли потокове передавання блоків увімкнене, OpenClaw може **об’єднувати послідовні блокові частини**
перед їх надсиланням. Це зменшує «спам з одного рядка», водночас зберігаючи
поступовий вивід.

- Об’єднання чекає на **паузи бездіяльності** (`idleMs`) перед скиданням.
- Буфери обмежуються значенням `maxChars` і буде виконано скидання, якщо їх перевищено.
- `minChars` не дає надсилати дрібні фрагменти, доки не накопичиться достатньо тексту
  (підсумкове скидання завжди надсилає решту тексту).
- Роздільник визначається з `blockStreamingChunk.breakPreference`
  (`paragraph` → `\n\n`, `newline` → `\n`, `sentence` → пробіл).
- Перевизначення для каналів доступні через `*.blockStreamingCoalesce` (зокрема в конфігураціях окремих облікових записів).
- Типове значення coalesce `minChars` підвищується до 1500 для Signal/Slack/Discord, якщо не перевизначено.

## Людиноподібний темп між блоками

Коли потокове передавання блоків увімкнене, можна додати **випадкову паузу** між
блоковими відповідями (після першого блоку). Це робить відповіді з кількох бульбашок
природнішими.

- Конфігурація: `agents.defaults.humanDelay` (перевизначення для агента через `agents.list[].humanDelay`).
- Режими: `off` (типово), `natural` (800–2500ms), `custom` (`minMs`/`maxMs`).
- Застосовується лише до **блокових відповідей**, а не до фінальних відповідей чи підсумків інструментів.

## «Передавати частинами чи все одразу»

Це зіставляється так:

- **Передавати частинами:** `blockStreamingDefault: "on"` + `blockStreamingBreak: "text_end"` (передавання в міру надходження). Для каналів, крім Telegram, також потрібно `*.blockStreaming: true`.
- **Передати все наприкінці:** `blockStreamingBreak: "message_end"` (одноразове скидання, можливо кількома частинами, якщо відповідь дуже довга).
- **Без потокового передавання блоків:** `blockStreamingDefault: "off"` (лише фінальна відповідь).

**Примітка щодо каналів:** Потокове передавання блоків **вимкнене, доки**
`*.blockStreaming` явно не встановлено в `true`. Канали можуть передавати живий попередній перегляд
(`channels.<channel>.streaming`) без блокових відповідей.

Нагадування про розташування конфігурації: типові параметри `blockStreaming*` знаходяться в
`agents.defaults`, а не в корені конфігурації.

## Режими потокового передавання попереднього перегляду

Канонічний ключ: `channels.<channel>.streaming`

Режими:

- `off`: вимкнути потокове передавання попереднього перегляду.
- `partial`: один попередній перегляд, який замінюється найновішим текстом.
- `block`: оновлення попереднього перегляду поетапно, частинами/додаванням.
- `progress`: попередній перегляд прогресу/стану під час генерації, фінальна відповідь після завершення.

### Зіставлення каналів

| Канал   | `off` | `partial` | `block` | `progress`        |
| ------- | ----- | --------- | ------- | ----------------- |
| Telegram | ✅    | ✅        | ✅      | зіставляється з `partial` |
| Discord  | ✅    | ✅        | ✅      | зіставляється з `partial` |
| Slack    | ✅    | ✅        | ✅      | ✅                |

Лише для Slack:

- `channels.slack.streaming.nativeTransport` перемикає виклики нативного API потокового передавання Slack, коли `channels.slack.streaming.mode="partial"` (типово: `true`).
- Нативне потокове передавання Slack і статус у потоці помічника Slack вимагають цільового потоку відповіді; DM верхнього рівня не показують такий попередній перегляд у стилі потоку.

Міграція застарілих ключів:

- Telegram: `streamMode` і булеве `streaming` автоматично мігрують у enum `streaming`.
- Discord: `streamMode` і булеве `streaming` автоматично мігрують у enum `streaming`.
- Slack: `streamMode` автоматично мігрує до `streaming.mode`; булеве `streaming` автоматично мігрує до `streaming.mode` плюс `streaming.nativeTransport`; застаріле `nativeStreaming` автоматично мігрує до `streaming.nativeTransport`.

### Поведінка під час виконання

Telegram:

- Використовує оновлення попереднього перегляду через `sendMessage` + `editMessageText` у DM та групах/темах.
- Потокове передавання попереднього перегляду пропускається, якщо для Telegram явно ввімкнено потокове передавання блоків (щоб уникнути подвійного потокового передавання).
- `/reasoning stream` може записувати міркування в попередній перегляд.

Discord:

- Використовує надсилання + редагування повідомлень попереднього перегляду.
- Режим `block` використовує чернеткове розбиття на частини (`draftChunk`).
- Потокове передавання попереднього перегляду пропускається, якщо для Discord явно ввімкнено потокове передавання блоків.

Slack:

- `partial` може використовувати нативне потокове передавання Slack (`chat.startStream`/`append`/`stop`), коли воно доступне.
- `block` використовує попередні перегляди чернеток у стилі додавання.
- `progress` використовує текст попереднього перегляду стану, а потім фінальну відповідь.

## Пов’язане

- [Повідомлення](/uk/concepts/messages) — життєвий цикл і доставка повідомлень
- [Повторна спроба](/uk/concepts/retry) — поведінка повторних спроб у разі помилки доставки
- [Канали](/uk/channels) — підтримка потокового передавання для кожного каналу
