--- read_when: - Объяснение того, как потоковая передача или разбиение на фрагменты работают в каналах - Изменение поведения потоковой передачи блоков или разбиения канала на фрагменты - Отладка дублирующихся или преждевременных ответов блоками либо потоковой передачи предпросмотра канала summary: Поведение потоковой передачи и разбиения на фрагменты (блочные ответы, потоковая передача предпросмотра канала, сопоставление режимов) title: Потоковая передача и разбиение на фрагменты x-i18n: generated_at: "2026-06-28T22:53:42Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: 6667e95a1ed89e6bd8990a1b8784edb73885c59c7a3905eabc14184270efcfe1 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) делит высокие ответы, чтобы избежать обрезки в UI. **Семантика границ:** - `text_end`: отправлять блоки сразу после того, как `chunker` их выдает; сбрасывать буфер на каждом `text_end`. - `message_end`: ждать завершения сообщения ассистента, затем сбрасывать буферизованный вывод. `message_end` все равно использует `chunker`, если буферизованный текст превышает `maxChars`, поэтому в конце он может выдать несколько фрагментов. ### Доставка медиа при потоковой передаче блоков Потоковые медиа должны использовать структурированные поля полезной нагрузки, такие как `mediaUrl` или `mediaUrls`; потоковый текст не разбирается как команда вложения. Когда потоковая передача блоков отправляет медиа раньше, OpenClaw запоминает эту доставку для текущего хода. Если финальная полезная нагрузка ассистента повторяет тот же URL медиа, финальная доставка удаляет дублирующее медиа вместо повторной отправки вложения. Точные дубликаты финальной полезной нагрузки подавляются. Если финальная полезная нагрузка добавляет отдельный текст вокруг медиа, которое уже было отправлено потоком, OpenClaw все равно отправляет новый текст, сохраняя однократную доставку медиа. Это предотвращает дублирование голосовых заметок или файлов в таких каналах, как Telegram. ## Алгоритм разбиения (нижняя/верхняя границы) Разбиение блоков реализовано в `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`. Каналы могут транслировать живой предпросмотр (`channels..streaming`) без ответов блоками. Напоминание о расположении конфигурации: значения по умолчанию `blockStreaming*` находятся в `agents.defaults`, а не в корневой конфигурации. ## Режимы потокового предпросмотра Канонический ключ: `channels..streaming` Режимы: - `off`: отключить потоковый предпросмотр. - `partial`: единый предпросмотр, заменяемый последним текстом. - `block`: предпросмотр обновляется фрагментами/добавлениями. - `progress`: предпросмотр прогресса/статуса во время генерации, финальный ответ по завершении. `streaming.mode: "block"` — это режим потокового предпросмотра для каналов с возможностью редактирования, таких как Discord и Telegram. Он не включает там доставку блоков канала. Используйте `streaming.block.enabled` или устаревший ключ канала `blockStreaming`, когда нужны обычные ответы блоками. Microsoft Teams — исключение: у него нет транспорта чернового предпросмотра блоков, поэтому `streaming.mode: "block"` сопоставляется с доставкой блоков Teams вместо нативной потоковой передачи partial/progress. ### Сопоставление каналов | Канал | `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/совместимости конфигурации в `streaming.mode`. - Discord: `streamMode` + булево `streaming` остаются runtime-алиасами для перечисления `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 и группах/топиках. - Короткие начальные предпросмотры все еще дебаунсятся для UX push-уведомлений, но Telegram теперь материализует их после ограниченной задержки, чтобы активные запуски не оставались визуально безмолвными. - Финальный текст редактирует активный предпросмотр на месте; длинные финальные ответы повторно используют это сообщение для первого фрагмента и отправляют только оставшиеся фрагменты. - Режим `block` переводит предпросмотр в новое сообщение на `streaming.preview.chunk.maxChars` (по умолчанию 800, ограничено лимитом редактирования Telegram в 4096); другие режимы увеличивают один предпросмотр до 4096 символов. - Режим `progress` держит прогресс инструмента в редактируемом черновике статуса, материализует метку статуса, когда потоковая передача ответа активна, но строка инструмента еще недоступна, очищает этот черновик по завершении и отправляет финальный ответ через обычную доставку. - Если финальная правка завершается с ошибкой до подтверждения завершенного текста, OpenClaw использует обычную финальную доставку и очищает устаревший предпросмотр. - Потоковый предпросмотр пропускается, когда потоковая передача блоков Telegram явно включена (чтобы избежать двойной потоковой передачи). - `/reasoning stream` может записывать рассуждение во временный предпросмотр, который удаляется после финальной доставки. Discord: - Использует отправку + редактирование сообщений предпросмотра. - Режим `block` использует разбиение черновика (`draftChunk`). - Потоковый предпросмотр пропускается, когда потоковая передача блоков Discord явно включена. - Финальные медиа, ошибки и полезные нагрузки явного ответа отменяют ожидающие предпросмотры без сброса нового черновика, затем используют обычную доставку. Slack: - `partial` может использовать нативную потоковую передачу Slack (`chat.startStream`/`append`/`stop`), когда она доступна. - `block` использует черновые предпросмотры в стиле добавления. - `progress` использует текст предпросмотра статуса, затем финальный ответ. - DM верхнего уровня без треда ответа используют черновые публикации предпросмотра и правки вместо нативной потоковой передачи Slack. - Нативная и черновая потоковая передача предпросмотра подавляют ответы блоками для этого хода, поэтому ответ Slack транслируется только одним путем доставки. - Финальные полезные нагрузки медиа/ошибок и финалы прогресса не создают одноразовые черновые сообщения; только текстовые/блочные финалы, которые могут редактировать предпросмотр, сбрасывают ожидающий текст черновика. Mattermost: - Транслирует размышление, активность инструментов и частичный текст ответа в единую черновую публикацию предпросмотра, которая финализируется на месте, когда финальный ответ можно безопасно отправить. - Возвращается к отправке новой финальной публикации, если публикация предпросмотра была удалена или иначе недоступна во время финализации. - Финальные полезные нагрузки медиа/ошибок отменяют ожидающие обновления предпросмотра перед обычной доставкой вместо сброса временной публикации предпросмотра. Matrix: - Черновые предпросмотры финализируются на месте, когда финальный текст может повторно использовать событие предпросмотра. - Финалы только с медиа, ошибками и несовпадением целевого ответа отменяют ожидающие обновления предпросмотра перед обычной доставкой; уже видимый устаревший предпросмотр редактируется. ### Обновления предпросмотра прогресса инструментов Потоковый предпросмотр также может включать обновления **прогресса инструментов** — короткие строки статуса вроде «поиск в интернете», «чтение файла» или «вызов инструмента», которые появляются в том же сообщении предпросмотра, пока инструменты работают, до финального ответа. В режиме app-server Codex сообщения преамбулы/комментариев Codex используют тот же путь предпросмотра, поэтому короткие заметки прогресса «Я проверяю...» могут транслироваться в редактируемый черновик, не становясь частью финального ответа. Это сохраняет визуальную активность многошаговых ходов с инструментами, а не тишину между первым предпросмотром размышления и финальным ответом. Долго работающие инструменты могут выдавать типизированный прогресс до возврата результата. Например, `web_fetch` запускает пятисекундный таймер при старте: если загрузка все еще ожидает, предпросмотр может показать `Fetching page content...`; если загрузка завершается или отменяется до этого, строка прогресса не выдается. Последующий финальный результат инструмента все равно обычно доставляется модели. Поддерживаемые поверхности: - **Discord**, **Slack**, **Telegram** и **Matrix** по умолчанию передают ход выполнения инструментов и обновления преамбулы Codex в редактируемый предпросмотр в реальном времени, когда активна потоковая передача предпросмотра. 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](/ru/channels/telegram). Оставить строки хода выполнения видимыми, но скрыть необработанный текст команд/выполнения: ```json { "channels": { "telegram": { "streaming": { "mode": "partial", "preview": { "toolProgress": true, "commandText": "status" } } } } } ``` Используйте ту же форму под ключом другого канала с компактным ходом выполнения, например `channels.discord`, `channels.matrix`, `channels.msteams`, `channels.mattermost` или черновыми предпросмотрами Slack. Для режима черновика хода выполнения поместите ту же политику в `streaming.progress`: ```json { "channels": { "telegram": { "streaming": { "mode": "progress", "progress": { "toolProgress": true, "commandText": "status" } } } } } ``` ## Связанные материалы - [Рефакторинг жизненного цикла сообщений](/ru/concepts/message-lifecycle-refactor) - целевой общий дизайн предпросмотра, редактирования, потоковой передачи и финализации - [Черновики хода выполнения](/ru/concepts/progress-drafts) - видимые сообщения о незавершенной работе, которые обновляются во время долгих ходов - [Сообщения](/ru/concepts/messages) - жизненный цикл и доставка сообщений - [Повтор](/ru/concepts/retry) - поведение повтора при сбое доставки - [Каналы](/ru/channels) - поддержка потоковой передачи для каждого канала