---
read_when:
    - Пояснення того, як потокове передавання або розбиття на фрагменти працює в каналах
    - Зміна поведінки потокового передавання блоків або розбиття каналу на фрагменти
    - Налагодження дубльованих/передчасних блокових відповідей або потокової передачі попереднього перегляду каналу
summary: Поведінка потокового передавання та розбиття на фрагменти (блокові відповіді, потокове передавання попереднього перегляду каналу, зіставлення режимів)
title: Потокове передавання та поділ на фрагменти
x-i18n:
    generated_at: "2026-05-03T01:35:00Z"
    model: gpt-5.5
    provider: openai
    source_hash: 85f6cb33031a6c818bb709e0ed14d8dd0f8c30a3dd90468a40396b3a515b5e65
    source_path: concepts/streaming.md
    workflow: 16
---

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–2500 мс), `custom` (`minMs`/`maxMs`).
- Застосовується лише до **блокових відповідей**, а не до фінальних відповідей чи підсумків інструментів.

## "Передавати фрагменти потоком або все"

Це відповідає:

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

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

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

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

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

Режими:

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

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

| Канал      | `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 потребують цільового треду відповіді. DM верхнього рівня не показують такий попередній перегляд у стилі треду, але все ще можуть використовувати чернетки дописів попереднього перегляду Slack і редагування.

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

- Telegram: застарілі значення `streamMode` і скалярні/булеві значення `streaming` виявляються й мігруються шляхами doctor/сумісності конфігурації до `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` використовує текст попереднього перегляду статусу, потім фінальну відповідь.
- DM верхнього рівня без треду відповіді використовують чернетки дописів попереднього перегляду та редагування замість нативної потокової передачі Slack.
- Нативний і чернетковий потоковий попередній перегляд пригнічують блокові відповіді для цього звернення, тому відповідь Slack передається лише одним шляхом доставки.
- Фінальні медіа/помилки та фінали прогресу не створюють одноразові повідомлення-чернетки; лише текстові/блокові фінали, які можуть редагувати попередній перегляд, очищують очікуваний текст чернетки.

Mattermost:

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

Matrix:

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

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

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

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

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

Приклад:

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

## Пов'язане

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