Потокове передавання та поділ на фрагменти

OpenClaw має два незалежні рівні потокового передавання, і наразі для повідомлень каналів немає справжнього потокового передавання дельт токенів:

• Потокове передавання блоків (канали): надсилає завершені блоки в міру того, як асистент пише. Це звичайні повідомлення каналу, а не дельти токенів.
• Потокове передавання попереднього перегляду (Telegram/Discord/Slack/Matrix/Mattermost/MS Teams): оновлює тимчасове повідомлення попереднього перегляду під час генерування (надсилання + редагування/додавання).

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

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

Вивід моделі  └─ text_delta/events       ├─ (blockStreamingBreak=text_end)       │    └─ роздільник створює блоки зі зростанням буфера       └─ (blockStreamingBreak=message_end)            └─ роздільник спорожнює буфер під час message_end                   └─ надсилання в канал (блокові відповіді)

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

Параметри керування (усі в agents.defaults, якщо не зазначено інше):

streaming.chunkMode: "newline" розділяє текст на порожніх рядках (межах абзаців), а не на кожному новому рядку, перш ніж перейти до поділу за довжиною, коли текст перевищить обмеження.

Вбудовані канали записують ці перевизначення як channels.<id>.streaming.{chunkMode,block.enabled,block.coalesce}. Плоскі форми *.chunkMode / *.blockStreaming / *.blockStreamingCoalesce є застарілими для кожного вбудованого каналу: openclaw doctor --fix переносить їх у вкладену форму, а схеми каналів їх відхиляють. Конфігурації зовнішніх SDK-плагінів, які досі використовують плоскі форми, продовжують працювати завдяки застарілому резервному механізму (з попередженням під час виконання) до наступного циклу випуску.

Семантика меж для blockStreamingBreak:

• text_end: передавати блоки потоком одразу після їх створення роздільником; спорожнювати буфер під час кожної text_end.
• message_end: чекати завершення повідомлення асистента, а потім спорожнити буферизований вивід. Роздільник усе одно використовується, якщо буферизований текст перевищує maxChars, тому наприкінці може бути надіслано кілька фрагментів.

Доставлення медіафайлів під час потокового передавання блоків

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

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

Алгоритм поділу на фрагменти (нижня/верхня межі)

Поділ блоків на фрагменти реалізовано в EmbeddedBlockChunker:

• Нижня межа: не надсилати, доки буфер не досягне >= minChars (якщо не застосовано примусове надсилання).
• Верхня межа: віддавати перевагу розділенню до maxChars; за примусового розділення — розділяти на maxChars.
• Послідовність бажаних місць розриву: paragraph -> newline -> sentence -> пробіл -> жорсткий розрив.
• Блоки коду: ніколи не розділяти всередині огорож; за примусового розділення на maxChars закрити й повторно відкрити огорожу, щоб зберегти коректність Markdown.

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

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

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

• Перед спорожненням об’єднання очікує на періоди бездіяльності (idleMs).
• Буфери обмежені значенням maxChars і спорожнюються в разі його перевищення.
• minChars не дає надсилати дрібні фрагменти, доки не накопичиться достатньо тексту (остаточне спорожнення завжди надсилає решту тексту).
• Роздільник обирається на основі blockStreamingChunk.breakPreference: paragraph -> \n\n, newline -> \n, sentence -> пробіл.
• Перевизначення каналів доступні через *.streaming.block.coalesce (включно з конфігураціями для окремих облікових записів).
• Для Discord, Signal і Slack типовим значенням об’єднання є { minChars: 1500, idleMs: 1000 }, якщо його не перевизначено.

Людиноподібні паузи між блоками

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

Перевизначається для кожного агента через agents.list[].humanDelay. Застосовується лише до блокових відповідей, а не до остаточних відповідей чи підсумків інструментів.

«Передавати фрагменти потоком або все разом»

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

Потокове передавання блоків вимкнено, якщо *.streaming.block.enabled явно не встановлено в true (виняток: QQ Bot не має ключів streaming.block і передає блокові відповіді потоком, якщо channels.qqbot.streaming.mode не має значення "off"). Канали можуть передавати потоком попередній перегляд наживо (channels.<channel>.streaming.mode) без блокових відповідей. Типові значення blockStreaming* містяться в agents.defaults, а не в корені конфігурації.

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

Канонічний ключ: channels.<channel>.streaming (вкладений { mode, ... }; застарілі булеві/рядкові форми верхнього рівня переписуються командою openclaw doctor --fix).

streaming.mode: "block" — це режим потокового передавання попереднього перегляду для каналів із можливістю редагування, як-от Discord і Telegram; сам по собі він не вмикає доставлення блоків каналу в них. Для звичайних блокових відповідей використовуйте streaming.block.enabled. Microsoft Teams є винятком: у ньому немає блокового транспорту чернеток попереднього перегляду, тому streaming.mode: "block" повністю вимикає власне потокове передавання, а відповідь надходить як звичайне блокове доставлення замість власного часткового потокового передавання або передавання поступу. Mattermost також відрізняється: у режимі block він чергує в попередньому перегляді завершений текст і блоки активності інструментів, тому попередні блоки залишаються видимими як окремі дописи, а не перезаписуються в одній редагованій чернетці.

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

Типові значення конфігурації фрагментів попереднього перегляду (streaming.preview.chunk.*, наприклад у channels.discord.streaming або channels.telegram.streaming): minChars: 200, maxChars: 800 (обмежується значенням каналу textChunkLimit) і breakPreference: "paragraph".

Лише для Slack:

• channels.slack.streaming.nativeTransport перемикає виклики власного API потокового передавання Slack (chat.startStream/chat.appendStream/chat.stopStream), коли channels.slack.streaming.mode="partial" (типове значення: true).
• Для власного потокового передавання Slack і стану потоку асистента Slack потрібна ціль потоку відповідей. Приватні повідомлення верхнього рівня не показують такий попередній перегляд у вигляді потоку, але все одно можуть використовувати дописи попереднього перегляду чернетки Slack та їх редагування.

Перенесення застарілих ключів

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

Telegram

• Використовує sendMessage + editMessageText для оновлення попереднього перегляду в приватних повідомленнях і групах/темах; фінальний текст редагує активний попередній перегляд на місці. Ефемерні 30-секундні чернетки «введення тексту» Telegram (sendMessageDraft) не використовуються для потокового передавання відповіді.
• Короткі початкові попередні перегляди й надалі мають затримку для зручності push-сповіщень, але з’являються після обмеженої затримки, щоб активні виконання не залишалися візуально непомітними.
• Довгі фінальні відповіді повторно використовують повідомлення попереднього перегляду для першого фрагмента й надсилають лише решту фрагментів.
• Режим block перетворює попередній перегляд на нове повідомлення при streaming.preview.chunk.maxChars (типово 800, з верхньою межею редагування Telegram у 4096 символів); в інших режимах один попередній перегляд збільшується до 4096 символів.
• Режим progress зберігає перебіг роботи інструментів у редагованій чернетці стану, показує мітку стану, коли потокове передавання відповіді активне, але рядок інструмента ще недоступний, очищає чернетку після завершення й надсилає фінальну відповідь через звичайний механізм доставки.
• Якщо фінальне редагування завершується помилкою до підтвердження завершеного тексту, OpenClaw використовує звичайну фінальну доставку й очищає застарілий попередній перегляд.
• Потокове передавання попереднього перегляду пропускається, коли явно ввімкнено блокове потокове передавання Telegram, щоб уникнути подвійного потокового передавання.
• /reasoning stream може записувати міркування до тимчасового попереднього перегляду, який видаляється після фінальної доставки.
• Відповіді на вибрану цитату в Telegram є винятком: коли replyToMode не має значення "off" і наявний текст вибраної цитати, OpenClaw пропускає потік попереднього перегляду відповіді для цього ходу (фінальна відповідь має пройти через нативний механізм відповіді на цитату), тому рядки попереднього перегляду перебігу роботи інструментів не можуть відображатися. Відповіді на поточне повідомлення без тексту вибраної цитати й надалі використовують потокове передавання попереднього перегляду. Докладніше див. у документації каналу Telegram.

Discord

• Використовує надсилання та редагування повідомлень попереднього перегляду.
• Режим block використовує поділ чернетки на фрагменти (draftChunk).
• Потокове передавання попереднього перегляду пропускається, коли явно ввімкнено блокове потокове передавання Discord.
• Режим progress додає до фінальної відповіді невелику квитанцію активності -# (кількість міркувань/викликів інструментів і витрачений час) та видаляє чернетку стану після доставки цієї відповіді, щоб у завантажених каналах над відповіддю не залишався осиротілий журнал інструментів. У разі фінальної помилки чернетка зберігається як запис невдалого ходу.
• Фінальні корисні навантаження з медіа, помилками та явними відповідями скасовують очікувані попередні перегляди, не виводячи нову чернетку, а потім використовують звичайну доставку.

Slack

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

Mattermost

• У режимі partial міркування та частковий текст відповіді потоково передаються в одну публікацію попереднього перегляду чернетки, яка фіналізується на місці, коли фінальну відповідь можна безпечно надіслати.
• У режимі progress міркування та активність інструментів потоково передаються в один попередній перегляд стану, який фіналізується на місці, коли фінальну відповідь можна безпечно надіслати.
• У режимі block відбувається чергування між публікаціями завершеного тексту та активності інструментів; паралельні й послідовні оновлення інструментів використовують спільну поточну публікацію активності інструментів.
• Якщо публікацію попереднього перегляду видалено або вона з іншої причини недоступна під час фіналізації, натомість надсилається нова фінальна публікація.
• Фінальні корисні навантаження з медіа/помилками скасовують очікувані оновлення попереднього перегляду перед звичайною доставкою замість виведення тимчасової публікації попереднього перегляду.

Matrix

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

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

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

Довготривалі інструменти можуть надсилати типізовані оновлення перебігу до свого завершення. Наприклад, web_fetch під час запуску встановлює п’ятисекундний таймер: якщо отримання даних усе ще триває, попередній перегляд показує Fetching page content...; якщо отримання завершується або скасовується раніше, рядок перебігу не надсилається. Подальший фінальний результат роботи інструмента все одно доставляється моделі звичайним способом.

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

• Discord, Slack, Telegram і Matrix типово потоково передають перебіг роботи інструментів і вступні оновлення Codex до активного редагованого попереднього перегляду, коли потокове передавання попереднього перегляду активне. Microsoft Teams використовує власний нативний потік перебігу в особистих чатах.
• Telegram постачається з увімкненими оновленнями попереднього перегляду перебігу роботи інструментів, починаючи з v2026.4.22; збереження їх увімкненими підтримує цю випущену поведінку.
• Mattermost об’єднує активність інструментів в одну публікацію попереднього перегляду в режимах partial і progress або в одну публікацію активності інструментів між текстовими блоками в режимі block (див. вище).
• Редагування перебігу роботи інструментів відповідають активному режиму потокового передавання попереднього перегляду; вони пропускаються, коли потокове передавання попереднього перегляду має значення off або коли блокове потокове передавання перебрало керування повідомленням. У Telegram streaming.mode: "off" призначено лише для фінальних повідомлень: загальні повідомлення про перебіг також пригнічуються, а не доставляються як окремі повідомлення стану, тоді як запити на схвалення, корисні навантаження з медіа та помилки й надалі спрямовуються звичайним способом.
• Щоб зберегти потокове передавання попереднього перегляду, але приховати рядки перебігу роботи інструментів, установіть streaming.preview.toolProgress у false для цього каналу (типове значення — true). Щоб залишити рядки перебігу роботи інструментів видимими, приховавши текст команд/виконання, установіть streaming.preview.commandText у "status" або streaming.progress.commandText у "status"; типове значення — "raw", щоб зберегти випущену поведінку. Ця політика є спільною для каналів чернеток/перебігу, які використовують компактний засіб відтворення перебігу OpenClaw, зокрема Discord, Matrix, Microsoft Teams, Mattermost, попередні перегляди чернеток Slack і Telegram. Щоб повністю вимкнути редагування попереднього перегляду, установіть streaming.mode у off.

Відтворення чернетки перебігу

Чернетки в режимі перебігу (streaming.progress.*) обмежені та налаштовуються окремо для кожного каналу:

Канал перебігу коментарів

Окрім перебігу роботи інструментів, компактний засіб відтворення перебігу може показувати в чернетці ще один канал:

• streaming.progress.commentary — відтворює передінструментальний коментар моделі (короткий опис на кшталт «Перевірю... потім...»), чергуючи його з рядками інструментів у чернетці перебігу. У Discord і Telegram у режимі перебігу той самий вступ формує заголовок стану, навіть коли цей необов’язковий канал вимкнено; інші канали зберігають наявну поведінку перебігу. Див. Чернетки перебігу.

{  "channels": {    "discord": {      "streaming": { "mode": "progress", "progress": { "commentary": true } }    }  }}

Залишити рядки перебігу видимими, але приховати необроблений текст команд/виконання:

{  "channels": {    "telegram": {      "streaming": {        "mode": "partial",        "preview": {          "toolProgress": true,          "commandText": "status"        }      }    }  }}

Використовуйте ту саму структуру під ключем іншого каналу компактного перебігу, наприклад channels.discord, channels.matrix, channels.msteams, channels.mattermost або попередніх переглядів чернеток Slack. Для режиму чернетки перебігу розмістіть ту саму політику в streaming.progress:

{  "channels": {    "telegram": {      "streaming": {        "mode": "progress",        "progress": {          "toolProgress": true,          "commandText": "status"        }      }    }  }}

Пов’язані матеріали

• Рефакторинг життєвого циклу повідомлень — цільова спільна архітектура попереднього перегляду, редагування, потокового передавання та фіналізації
• Чернетки перебігу — видимі повідомлення про незавершену роботу, що оновлюються під час тривалих ходів
• Повідомлення — життєвий цикл і доставка повідомлень
• Повторна спроба — поведінка повторних спроб у разі помилки доставки
• Канали — підтримка потокового передавання для окремих каналів