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

OpenClaw має два окремі рівні потокової передачі:

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

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

## Блокова потокова передача (повідомлення каналу)

Блокова потокова передача надсилає вихід асистента великими фрагментами в міру його доступності.

```
Model output
  └─ 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`, тому наприкінці може бути видано кілька фрагментів.

### Доставка медіа з блоковою потоковою передачею

Директиви `MEDIA:` є звичайними метаданими доставки. Коли блокова потокова передача надсилає медіаблок рано, OpenClaw запам’ятовує цю доставку для поточного ходу. Якщо фінальне корисне навантаження асистента повторює ту саму медіа-URL, фінальна доставка прибирає дубль медіа замість повторного надсилання вкладення.

Точні дублікати фінального корисного навантаження пригнічуються. Якщо фінальне корисне навантаження додає окремий текст навколо медіа, яке вже було передано потоково, OpenClaw усе одно надсилає новий текст, залишаючи доставку медіа одноразовою. Це запобігає дублюванню голосових повідомлень або файлів у таких каналах, як Telegram, коли агент надсилає `MEDIA:` під час потокової передачі, а провайдер також включає його в завершену відповідь.

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

Розбиття блоків реалізовано в `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` (зокрема в конфігураціях окремих акаунтів).
- Типове `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`: попередній перегляд прогресу/стану під час генерації, фінальна відповідь після завершення.

### Відповідність каналів

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

Лише для Slack:

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

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

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

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

Telegram:

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

Discord:

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

Slack:

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

Mattermost:

- Передає міркування, активність інструментів і частковий текст відповіді в один чернетковий допис попереднього перегляду, який фіналізується на місці, коли фінальну відповідь безпечно надсилати.
- Повертається до надсилання нового фінального допису, якщо допис попереднього перегляду було видалено або він інакше недоступний на момент фіналізації.
- Фінальні корисні навантаження медіа/помилок скасовують відкладені оновлення попереднього перегляду перед звичайною доставкою замість скидання тимчасового допису попереднього перегляду.

Matrix:

- Чернеткові попередні перегляди фіналізуються на місці, коли фінальний текст може повторно використати подію попереднього перегляду.
- Фінали лише з медіа, помилками та невідповідністю цільової відповіді скасовують відкладені оновлення попереднього перегляду перед звичайною доставкою; уже видимий застарілий попередній перегляд редагується.

### Оновлення попереднього перегляду прогресу інструментів

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

Підтримувані поверхні:

- **Discord**, **Slack**, **Telegram** і **Matrix** типово передають прогрес інструментів у живе редагування попереднього перегляду, коли активна потокова передача попереднього перегляду.
- У Telegram оновлення попереднього перегляду прогресу інструментів увімкнені з релізу `v2026.4.22`; збереження їх увімкненими підтримує цю випущену поведінку.
- **Mattermost** уже включає активність інструментів до свого єдиного чернеткового допису попереднього перегляду (див. вище).
- Редагування прогресу інструментів підкоряються активному режиму потокової передачі попереднього перегляду; вони пропускаються, коли потокову передачу попереднього перегляду встановлено в `off` або коли блокова потокова передача вже взяла на себе повідомлення.
- Щоб зберегти потокову передачу попереднього перегляду, але приховати рядки прогресу інструментів, установіть `streaming.preview.toolProgress` у `false` для цього каналу. Щоб повністю вимкнути редагування попереднього перегляду, установіть `streaming.mode` у `off`.

Приклад:

```json
{
  "channels": {
    "telegram": {
      "streaming": {
        "mode": "partial",
        "preview": {
          "toolProgress": false
        }
      }
    }
  }
}
```

## Пов’язане

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