Messages and delivery

Потокова передача та розбиття на фрагменти

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:

Нижня межа: не видавати, доки buffer >= 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. Канали можуть передавати живий попередній перегляд (channels.<channel>.streaming) без блокових відповідей.

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

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

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

Режими:

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

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

Відображення каналів

Канал	`off`	`partial`	`block`	`progress`
Telegram	✅	✅	✅	редагована чернетка прогресу
Discord	✅	✅	✅	редагована чернетка прогресу
Slack	✅	✅	✅	✅
Mattermost	✅	✅	✅	✅
MS Teams	✅	✅	✅	нативний потік прогресу

Лише Slack:

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

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

Telegram: застарілий streamMode і скалярні/булеві значення streaming виявляються та мігруються шляхами сумісності doctor/config до streaming.mode.
Discord: streamMode + булевий streaming залишаються runtime-псевдонімами для enum streaming; запустіть openclaw doctor --fix, щоб переписати збережену конфігурацію.
Slack: streamMode залишається runtime-псевдонімом для streaming.mode; булевий streaming залишається runtime-псевдонімом для streaming.mode плюс streaming.nativeTransport; застарілий nativeStreaming залишається runtime-псевдонімом для streaming.nativeTransport. Запустіть openclaw doctor --fix, щоб переписати збережену конфігурацію.

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

Telegram:

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

Discord:

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

Slack:

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

Mattermost:

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

Matrix:

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

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

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

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

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

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

{
  "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"
        }
      }
    }
  }
}

Пов’язане

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

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

# Доставка медіа з потоковим передаванням блоків

# Алгоритм фрагментації (нижня/верхня межі)

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

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

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

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

# Відображення каналів

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

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

# Пов’язане