From 1049a310eb90fd803508016155770d05e150b04a Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Mon, 4 May 2026 06:14:51 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/channels/telegram.md | 425 +++++++++++++++++----------------- docs/uk/cli/sessions.md | 64 ++--- docs/uk/concepts/messages.md | 138 +++++------ docs/uk/concepts/streaming.md | 185 ++++++++------- 4 files changed, 415 insertions(+), 397 deletions(-) diff --git a/docs/uk/channels/telegram.md b/docs/uk/channels/telegram.md index 765c8f4bc..db311592f 100644 --- a/docs/uk/channels/telegram.md +++ b/docs/uk/channels/telegram.md @@ -1,25 +1,25 @@ --- read_when: - - Робота над функціями Telegram або Webhook -summary: Стан підтримки бота Telegram, можливості та конфігурація + - Робота з функціями Telegram або Webhook +summary: Статус підтримки, можливості та налаштування бота Telegram title: Telegram x-i18n: - generated_at: "2026-05-03T21:05:27Z" + generated_at: "2026-05-04T06:12:24Z" model: gpt-5.5 provider: openai - source_hash: 528ace9dae29eda22f98cc1436ec16146eb9d83edc73aa6db1ab8283f4f873c0 + source_hash: c7f49db5f3fe8fd724e53a2ae3d226446f248bf9d021fcc01c1cf816649381d2 source_path: channels/telegram.md workflow: 16 --- -Готово до продакшну для DM ботів і груп через grammY. Довге опитування є режимом за замовчуванням; режим Webhook необов’язковий. +Готово для продакшну для ботів у приватних повідомленнях і групах через grammY. Довге опитування є режимом за замовчуванням; режим Webhook необов’язковий. - Типова політика DM для Telegram — сполучення. + Типова політика особистих повідомлень для Telegram — сполучення. - - Міжканальна діагностика та плейбуки відновлення. + + Міжканальна діагностика та інструкції з відновлення. Повні шаблони й приклади конфігурації каналів. @@ -30,13 +30,13 @@ x-i18n: - Відкрийте Telegram і почніть чат із **@BotFather** (переконайтеся, що handle точно `@BotFather`). + Відкрийте Telegram і почніть чат із **@BotFather** (переконайтеся, що ім’я точно `@BotFather`). Виконайте `/newbot`, дотримуйтеся підказок і збережіть токен. - + ```json5 { @@ -51,12 +51,12 @@ x-i18n: } ``` - Резервне значення з env: `TELEGRAM_BOT_TOKEN=...` (лише типовий обліковий запис). - Telegram **не** використовує `openclaw channels login telegram`; налаштуйте токен у config/env, а потім запустіть gateway. + Резервний варіант через env: `TELEGRAM_BOT_TOKEN=...` (лише обліковий запис за замовчуванням). + Telegram **не** використовує `openclaw channels login telegram`; налаштуйте токен у config/env, потім запустіть gateway. - + ```bash openclaw gateway @@ -69,21 +69,21 @@ openclaw pairing approve telegram - Додайте бота до своєї групи, а потім налаштуйте `channels.telegram.groups` і `groupPolicy` відповідно до вашої моделі доступу. + Додайте бота до своєї групи, потім налаштуйте `channels.telegram.groups` і `groupPolicy` відповідно до вашої моделі доступу. -Порядок визначення токена враховує обліковий запис. На практиці значення config мають пріоритет над резервним значенням env, а `TELEGRAM_BOT_TOKEN` застосовується лише до типового облікового запису. +Порядок визначення токена враховує облікові записи. На практиці значення config мають пріоритет над резервним env, а `TELEGRAM_BOT_TOKEN` застосовується лише до облікового запису за замовчуванням. ## Налаштування на боці Telegram - Боти Telegram за замовчуванням використовують **режим приватності**, який обмежує, які групові повідомлення вони отримують. + Боти Telegram за замовчуванням використовують **Privacy Mode**, який обмежує групові повідомлення, що їх вони отримують. - Якщо бот має бачити всі групові повідомлення, зробіть одне з цього: + Якщо бот має бачити всі групові повідомлення, виконайте одне з наведеного: - вимкніть режим приватності через `/setprivacy`, або - зробіть бота адміністратором групи. @@ -92,7 +92,7 @@ openclaw pairing approve telegram - + Статус адміністратора керується в налаштуваннях групи Telegram. Боти-адміністратори отримують усі групові повідомлення, що корисно для постійно активної поведінки в групі. @@ -101,17 +101,17 @@ openclaw pairing approve telegram - - `/setjoingroups`, щоб дозволити/заборонити додавання до груп - - `/setprivacy` для поведінки видимості в групах + - `/setjoingroups`, щоб дозволити або заборонити додавання до груп + - `/setprivacy` для поведінки видимості в групі -## Керування доступом і активація +## Контроль доступу та активація - - `channels.telegram.dmPolicy` керує доступом до прямих повідомлень: + + `channels.telegram.dmPolicy` керує доступом до особистих повідомлень: - `pairing` (за замовчуванням) - `allowlist` (потребує принаймні одного ID відправника в `allowFrom`) @@ -121,24 +121,24 @@ openclaw pairing approve telegram `dmPolicy: "open"` з `allowFrom: ["*"]` дозволяє будь-якому обліковому запису Telegram, який знайде або вгадає ім’я користувача бота, керувати ботом. Використовуйте це лише для навмисно публічних ботів із жорстко обмеженими інструментами; боти з одним власником мають використовувати `allowlist` із числовими ID користувачів. `channels.telegram.allowFrom` приймає числові ID користувачів Telegram. Префікси `telegram:` / `tg:` приймаються та нормалізуються. - У конфігураціях із кількома обліковими записами обмежувальний `channels.telegram.allowFrom` верхнього рівня вважається межею безпеки: записи рівня облікового запису `allowFrom: ["*"]` не роблять цей обліковий запис публічним, якщо ефективний allowlist облікового запису після злиття не містить явний wildcard. - `dmPolicy: "allowlist"` із порожнім `allowFrom` блокує всі DM і відхиляється під час валідації конфігурації. + У конфігураціях із кількома обліковими записами обмежувальний верхньорівневий `channels.telegram.allowFrom` розглядається як межа безпеки: записи рівня облікового запису `allowFrom: ["*"]` не роблять цей обліковий запис публічним, якщо ефективний allowlist облікового запису після об’єднання все ще не містить явного wildcard. + `dmPolicy: "allowlist"` із порожнім `allowFrom` блокує всі особисті повідомлення та відхиляється перевіркою конфігурації. Налаштування запитує лише числові ID користувачів. - Якщо ви оновилися й ваша конфігурація містить записи allowlist `@username`, виконайте `openclaw doctor --fix`, щоб їх розв’язати (найкраща можлива спроба; потрібен токен бота Telegram). + Якщо ви оновилися і ваша конфігурація містить записи allowlist `@username`, виконайте `openclaw doctor --fix`, щоб розв’язати їх (за принципом best-effort; потрібен токен бота Telegram). Якщо раніше ви покладалися на файли allowlist зі сховища сполучень, `openclaw doctor --fix` може відновити записи в `channels.telegram.allowFrom` у потоках allowlist (наприклад, коли `dmPolicy: "allowlist"` ще не має явних ID). - Для ботів з одним власником віддавайте перевагу `dmPolicy: "allowlist"` з явними числовими ID `allowFrom`, щоб політика доступу була сталою в конфігурації (замість залежності від попередніх підтверджень сполучення). + Для ботів з одним власником віддавайте перевагу `dmPolicy: "allowlist"` із явними числовими ID `allowFrom`, щоб політика доступу була сталою в конфігурації (а не залежала від попередніх схвалень сполучення). - Типова плутанина: підтвердження сполучення DM не означає «цей відправник авторизований всюди». - Сполучення надає доступ до DM. Якщо власника команд ще не існує, перше підтверджене сполучення також встановлює `commands.ownerAllowFrom`, щоб команди лише для власника й підтвердження exec мали явний обліковий запис оператора. - Авторизація відправників у групах і далі надходить із явних allowlist у конфігурації. - Якщо ви хочете «я авторизований один раз, і працюють як DM, так і групові команди», додайте свій числовий ID користувача Telegram у `channels.telegram.allowFrom`; для команд лише для власника переконайтеся, що `commands.ownerAllowFrom` містить `telegram:`. + Поширена плутанина: схвалення сполучення в особистих повідомленнях не означає «цього відправника авторизовано всюди». + Сполучення надає доступ до особистих повідомлень. Якщо власника команд ще немає, перше схвалене сполучення також установлює `commands.ownerAllowFrom`, щоб команди лише для власника та схвалення exec мали явний обліковий запис оператора. + Авторизація відправників у групах усе ще походить із явних allowlist у конфігурації. + Якщо ви хочете «я авторизований один раз, і працюють і особисті повідомлення, і групові команди», додайте свій числовий ID користувача Telegram до `channels.telegram.allowFrom`; для команд лише для власника переконайтеся, що `commands.ownerAllowFrom` містить `telegram:`. ### Як знайти свій ID користувача Telegram Безпечніше (без стороннього бота): - 1. Надішліть DM своєму боту. + 1. Напишіть своєму боту в особисті повідомлення. 2. Виконайте `openclaw logs --follow`. 3. Прочитайте `from.id`. @@ -153,10 +153,10 @@ curl "https://api.telegram.org/bot/getUpdates" - Два засоби керування застосовуються разом: + Два елементи керування застосовуються разом: 1. **Які групи дозволені** (`channels.telegram.groups`) - - немає config `groups`: + - немає конфігурації `groups`: - з `groupPolicy: "open"`: будь-яка група може пройти перевірки ID групи - з `groupPolicy: "allowlist"` (за замовчуванням): групи заблоковані, доки ви не додасте записи `groups` (або `"*"`) - `groups` налаштовано: діє як allowlist (явні ID або `"*"`) @@ -168,13 +168,13 @@ curl "https://api.telegram.org/bot/getUpdates" `groupAllowFrom` використовується для фільтрації відправників у групах. Якщо не задано, Telegram повертається до `allowFrom`. Записи `groupAllowFrom` мають бути числовими ID користувачів Telegram (префікси `telegram:` / `tg:` нормалізуються). - Не додавайте ID чатів груп або супергруп Telegram у `groupAllowFrom`. Від’ємні ID чатів мають бути в `channels.telegram.groups`. - Нечислові записи ігноруються для авторизації відправників. - Межа безпеки (`2026.2.25+`): авторизація відправників у групах **не** успадковує підтвердження зі сховища сполучень DM. - Сполучення залишається лише для DM. Для груп задайте `groupAllowFrom` або `allowFrom` для групи/теми. - Якщо `groupAllowFrom` не задано, Telegram повертається до config `allowFrom`, а не до сховища сполучень. - Практичний шаблон для ботів з одним власником: задайте свій ID користувача в `channels.telegram.allowFrom`, залиште `groupAllowFrom` незаданим і дозвольте цільові групи в `channels.telegram.groups`. - Примітка щодо runtime: якщо `channels.telegram` повністю відсутній, runtime за замовчуванням fail-closed до `groupPolicy="allowlist"`, якщо `channels.defaults.groupPolicy` не задано явно. + Не додавайте ID чатів груп або супергруп Telegram у `groupAllowFrom`. Від’ємні ID чатів належать до `channels.telegram.groups`. + Нечислові записи ігноруються для авторизації відправника. + Межа безпеки (`2026.2.25+`): авторизація відправника в групі **не** успадковує схвалення зі сховища сполучень для особистих повідомлень. + Сполучення лишається лише для особистих повідомлень. Для груп задайте `groupAllowFrom` або `allowFrom` для окремої групи чи теми. + Якщо `groupAllowFrom` не встановлено, Telegram повертається до конфігураційного `allowFrom`, а не до сховища сполучень. + Практичний шаблон для ботів з одним власником: задайте свій ID користувача в `channels.telegram.allowFrom`, залиште `groupAllowFrom` невстановленим і дозвольте цільові групи в `channels.telegram.groups`. + Примітка щодо runtime: якщо `channels.telegram` повністю відсутній, runtime за замовчуванням відмовляє безпечно через `groupPolicy="allowlist"`, якщо `channels.defaults.groupPolicy` не задано явно. Приклад: дозволити будь-якого учасника в одній конкретній групі: @@ -211,20 +211,20 @@ curl "https://api.telegram.org/bot/getUpdates" ``` - Типова помилка: `groupAllowFrom` не є allowlist груп Telegram. + Поширена помилка: `groupAllowFrom` не є allowlist груп Telegram. - Додавайте від’ємні ID чатів груп або супергруп Telegram, як-от `-1001234567890`, у `channels.telegram.groups`. - - Додавайте ID користувачів Telegram, як-от `8734062810`, у `groupAllowFrom`, коли хочете обмежити, які люди в дозволеній групі можуть запускати бота. + - Додавайте ID користувачів Telegram, як-от `8734062810`, у `groupAllowFrom`, коли хочете обмежити, які люди всередині дозволеної групи можуть запускати бота. - Використовуйте `groupAllowFrom: ["*"]` лише тоді, коли хочете, щоб будь-який учасник дозволеної групи міг говорити з ботом. - + Відповіді в групах за замовчуванням потребують згадки. - Згадка може походити з: + Згадка може надходити з: - нативної згадки `@botusername`, або - шаблонів згадок у: @@ -236,7 +236,7 @@ curl "https://api.telegram.org/bot/getUpdates" - `/activation always` - `/activation mention` - Вони оновлюють лише стан сесії. Для збереження використовуйте конфігурацію. + Вони оновлюють лише стан сесії. Використовуйте конфігурацію для збереження. Приклад сталої конфігурації: @@ -265,12 +265,12 @@ curl "https://api.telegram.org/bot/getUpdates" - Telegram належить процесу gateway. - Маршрутизація детермінована: вхідні повідомлення Telegram отримують відповіді назад у Telegram (модель не вибирає канали). -- Вхідні повідомлення нормалізуються в спільний конверт каналу з метаданими відповіді та заповнювачами медіа. -- Групові сесії ізольовані за ID групи. Теми форуму додають `:topic:`, щоб теми залишалися ізольованими. -- DM-повідомлення можуть містити `message_thread_id`; OpenClaw зберігає ID треду для відповідей, але за замовчуванням залишає DM у плоскій сесії. Налаштуйте `channels.telegram.dm.threadReplies: "inbound"`, `channels.telegram.direct..threadReplies: "inbound"`, `requireTopic: true` або відповідну конфігурацію теми, коли ви навмисно хочете ізоляцію сесій тем DM. -- Довге опитування використовує grammY runner із послідовністю за чатами/тредами. Загальна конкурентність sink runner використовує `agents.defaults.maxConcurrent`. -- Довге опитування захищене всередині кожного процесу gateway, тож лише один активний poller може використовувати токен бота за раз. Якщо ви все ще бачите конфлікти `getUpdates` 409, імовірно, інший OpenClaw gateway, скрипт або зовнішній poller використовує той самий токен. -- Перезапуски watchdog для довгого опитування за замовчуванням спрацьовують після 120 секунд без завершеного liveness `getUpdates`. Збільшуйте `channels.telegram.pollingStallThresholdMs` лише якщо у вашому розгортанні все ще трапляються хибні перезапуски через polling-stall під час тривалої роботи. Значення вказується в мілісекундах і допускається від `30000` до `600000`; підтримуються перевизначення для окремих облікових записів. +- Вхідні повідомлення нормалізуються у спільний конверт каналу з метаданими відповіді та placeholders для медіа. +- Групові сесії ізольовані за ID групи. Теми форуму додають `:topic:`, щоб теми лишалися ізольованими. +- Особисті повідомлення можуть містити `message_thread_id`; OpenClaw зберігає ID треду для відповідей, але за замовчуванням тримає особисті повідомлення у плоскій сесії. Налаштуйте `channels.telegram.dm.threadReplies: "inbound"`, `channels.telegram.direct..threadReplies: "inbound"`, `requireTopic: true` або відповідну конфігурацію теми, коли ви навмисно хочете ізоляцію сесій за темами в особистих повідомленнях. +- Довге опитування використовує grammY runner із послідовністю для кожного чату й кожного треду. Загальна паралельність runner sink використовує `agents.defaults.maxConcurrent`. +- Довге опитування захищене всередині кожного процесу gateway, тому лише один активний poller може використовувати токен бота одночасно. Якщо ви все ще бачите конфлікти `getUpdates` 409, імовірно, інший gateway OpenClaw, скрипт або зовнішній poller використовує той самий токен. +- Перезапуски watchdog для довгого опитування за замовчуванням спрацьовують після 120 секунд без завершеної перевірки liveness `getUpdates`. Збільшуйте `channels.telegram.pollingStallThresholdMs` лише якщо ваше розгортання все ще бачить хибні перезапуски через зупинку опитування під час тривалої роботи. Значення вказується в мілісекундах і дозволене від `30000` до `600000`; підтримуються перевизначення для окремих облікових записів. - Telegram Bot API не підтримує сповіщення про прочитання (`sendReadReceipts` не застосовується). ## Довідник функцій @@ -284,12 +284,12 @@ curl "https://api.telegram.org/bot/getUpdates" Вимога: - - `channels.telegram.streaming` — `off | partial | block | progress` (за замовчуванням: `partial`) - - `progress` зберігає один редагований статусний чернетковий текст і оновлює його прогресом інструментів до фінальної доставки - - `streaming.preview.toolProgress` керує тим, чи оновлення інструментів/прогресу повторно використовують те саме відредаговане повідомлення попереднього перегляду (за замовчуванням: `true`, коли активне потокове передавання попереднього перегляду) + - `channels.telegram.streaming` має значення `off | partial | block | progress` (за замовчуванням: `partial`) + - `progress` зберігає одну редаговану чернетку статусу й оновлює її прогресом інструментів до фінальної доставки + - `streaming.preview.toolProgress` керує тим, чи оновлення інструментів/прогресу повторно використовують те саме відредаговане повідомлення попереднього перегляду (за замовчуванням: `true`, коли активний preview streaming) - застарілі `channels.telegram.streamMode` і булеві значення `streaming` виявляються; виконайте `openclaw doctor --fix`, щоб мігрувати їх до `channels.telegram.streaming.mode` - Оновлення попереднього перегляду прогресу інструментів — це короткі рядки статусу, що показуються під час роботи інструментів, наприклад виконання команд, читання файлів, оновлення планування або підсумки patch. Telegram залишає їх увімкненими за замовчуванням, щоб відповідати випущеній поведінці OpenClaw від `v2026.4.22` і пізніших версій. Щоб зберегти відредагований попередній перегляд для тексту відповіді, але приховати рядки прогресу інструментів, задайте: + Оновлення попереднього перегляду прогресу інструментів — це короткі рядки статусу, які показуються під час роботи інструментів, наприклад виконання команд, читання файлів, оновлення планування або підсумки patch. Telegram зберігає їх увімкненими за замовчуванням, щоб відповідати випущеній поведінці OpenClaw від `v2026.4.22` і пізніше. Щоб зберегти відредагований попередній перегляд для тексту відповіді, але приховати рядки прогресу інструментів, задайте: ```json { @@ -306,42 +306,43 @@ curl "https://api.telegram.org/bot/getUpdates" } ``` - Використовуйте `streaming.mode: "off"` лише тоді, коли потрібна доставка тільки фінальної відповіді: редагування попереднього перегляду в Telegram вимикається, а загальні повідомлення інструментів/прогресу приглушуються замість надсилання як окремих статусних повідомлень. Запити на підтвердження, медіавміст і помилки все одно проходять через звичайну фінальну доставку. Використовуйте `streaming.preview.toolProgress: false`, коли потрібно лише зберегти редагування попереднього перегляду відповіді, приховавши рядки статусу прогресу інструментів. + Використовуйте `streaming.mode: "off"` лише тоді, коли потрібна доставка тільки фінальної відповіді: редагування попереднього перегляду Telegram вимикаються, а загальні повідомлення про інструменти/прогрес приглушуються замість надсилання як окремі статусні повідомлення. Запити на схвалення, медіа-вміст і помилки все одно проходять через звичайну фінальну доставку. Використовуйте `streaming.preview.toolProgress: false`, коли потрібно лише зберегти редагування попереднього перегляду відповіді, приховавши статусні рядки прогресу інструментів. - Відповіді Telegram на вибрані цитати є винятком. Коли `replyToMode` має значення `"first"`, `"all"` або `"batched"` і вхідне повідомлення містить вибраний текст цитати, OpenClaw надсилає фінальну відповідь через нативний шлях відповіді з цитуванням Telegram замість редагування попереднього перегляду відповіді, тому `streaming.preview.toolProgress` не може показувати короткі рядки статусу для цього ходу. Відповіді на поточне повідомлення без вибраного тексту цитати й далі зберігають потоковий попередній перегляд. Установіть `replyToMode: "off"`, коли видимість прогресу інструментів важливіша за нативні відповіді з цитуванням, або встановіть `streaming.preview.toolProgress: false`, щоб явно прийняти цей компроміс. + Виняток — відповіді на вибрані цитати в Telegram. Коли `replyToMode` має значення `"first"`, `"all"` або `"batched"` і вхідне повідомлення містить текст вибраної цитати, OpenClaw надсилає фінальну відповідь через нативний шлях відповіді з цитатою Telegram замість редагування попереднього перегляду відповіді, тому `streaming.preview.toolProgress` не може показати короткі статусні рядки для цього ходу. Відповіді на поточне повідомлення без тексту вибраної цитати все ще зберігають потоковий попередній перегляд. Установіть `replyToMode: "off"`, коли видимість прогресу інструментів важливіша за нативні відповіді з цитатами, або встановіть `streaming.preview.toolProgress: false`, щоб явно прийняти цей компроміс. - Для текстових відповідей: + Для відповідей лише з текстом: - - короткі попередні перегляди в DM/групі/темі: OpenClaw зберігає те саме повідомлення попереднього перегляду й виконує фінальне редагування на місці, якщо після появи попереднього перегляду не було надіслано видиме повідомлення, що не є попереднім переглядом - - попередні перегляди, після яких іде видимий вивід, що не є попереднім переглядом: OpenClaw надсилає завершену відповідь як нове фінальне повідомлення й очищає старіший попередній перегляд, тому фінальна відповідь з'являється після проміжного виводу - - попередні перегляди старші приблизно за одну хвилину: OpenClaw надсилає завершену відповідь як нове фінальне повідомлення, а потім очищає попередній перегляд, тому видима часова позначка Telegram відображає час завершення, а не час створення попереднього перегляду + - короткі попередні перегляди в DM/групах/темах: OpenClaw зберігає те саме повідомлення попереднього перегляду й виконує фінальне редагування на місці, якщо після появи попереднього перегляду не було надіслано видиме повідомлення, що не є попереднім переглядом + - попередні перегляди, після яких іде видимий вивід, що не є попереднім переглядом: OpenClaw надсилає завершену відповідь як нове фінальне повідомлення та прибирає старіший попередній перегляд, тож фінальна відповідь з’являється після проміжного виводу + - попередні перегляди, старші приблизно за одну хвилину: OpenClaw надсилає завершену відповідь як нове фінальне повідомлення, а потім прибирає попередній перегляд, тож видима позначка часу Telegram відображає час завершення, а не час створення попереднього перегляду - Для складних відповідей (наприклад медіавмісту) OpenClaw повертається до звичайної фінальної доставки, а потім очищає повідомлення попереднього перегляду. + Для складних відповідей (наприклад, медіа-вмісту) OpenClaw повертається до звичайної фінальної доставки, а потім прибирає повідомлення попереднього перегляду. - Потоковий попередній перегляд відокремлений від потокової передачі блоків. Коли потокову передачу блоків явно ввімкнено для Telegram, OpenClaw пропускає потік попереднього перегляду, щоб уникнути подвійного потокового надсилання. + Потоковий попередній перегляд відокремлений від блокового потокового передавання. Коли блокове потокове передавання явно ввімкнено для Telegram, OpenClaw пропускає потік попереднього перегляду, щоб уникнути подвійного потокового передавання. - Потік reasoning тільки для Telegram: + Потік міркувань лише для Telegram: - - `/reasoning stream` надсилає reasoning у живий попередній перегляд під час генерації - - фінальна відповідь надсилається без тексту reasoning + - `/reasoning stream` надсилає міркування в живий попередній перегляд під час генерації + - попередній перегляд міркувань видаляється після фінальної доставки; використовуйте `/reasoning on`, коли міркування мають залишатися видимими + - фінальна відповідь надсилається без тексту міркувань Вихідний текст використовує Telegram `parse_mode: "HTML"`. - - Markdown-подібний текст рендериться у безпечний для Telegram HTML. - - Сирий HTML моделі екранується, щоб зменшити кількість помилок парсингу Telegram. - - Якщо Telegram відхиляє розібраний HTML, OpenClaw повторює спробу як звичайний текст. + - Текст у стилі Markdown перетворюється на безпечний для Telegram HTML. + - Сирий HTML моделі екранується, щоб зменшити кількість помилок розбору Telegram. + - Якщо Telegram відхиляє розібраний HTML, OpenClaw повторює надсилання як звичайний текст. - Попередні перегляди посилань увімкнені за замовчуванням і можуть бути вимкнені через `channels.telegram.linkPreview: false`. + Попередні перегляди посилань увімкнені за замовчуванням і можуть бути вимкнені за допомогою `channels.telegram.linkPreview: false`. - Реєстрація меню команд Telegram обробляється під час запуску через `setMyCommands`. + Реєстрація меню команд Telegram виконується під час запуску за допомогою `setMyCommands`. Типові значення нативних команд: @@ -364,47 +365,47 @@ curl "https://api.telegram.org/bot/getUpdates" Правила: - - імена нормалізуються (видаляється початковий `/`, переводяться в нижній регістр) + - імена нормалізуються (видаляється початковий `/`, нижній регістр) - допустимий шаблон: `a-z`, `0-9`, `_`, довжина `1..32` - користувацькі команди не можуть перевизначати нативні команди - - конфлікти/дублікати пропускаються й журналюються + - конфлікти/дублікати пропускаються та записуються в журнал Примітки: - користувацькі команди є лише записами меню; вони не реалізують поведінку автоматично - - команди plugin/skill усе одно можуть працювати під час введення, навіть якщо їх не показано в меню Telegram + - команди plugin/skill можуть працювати під час введення, навіть якщо їх не показано в меню Telegram - Якщо нативні команди вимкнено, вбудовані команди видаляються. Користувацькі/plugin-команди все ще можуть реєструватися, якщо налаштовані. + Якщо нативні команди вимкнено, вбудовані команди видаляються. Користувацькі команди/команди plugin усе ще можуть реєструватися, якщо їх налаштовано. - Поширені помилки налаштування: + Поширені збої налаштування: - - `setMyCommands failed` із `BOT_COMMANDS_TOO_MUCH` означає, що меню Telegram усе ще переповнювалося після обрізання; зменште кількість plugin/skill/користувацьких команд або вимкніть `channels.telegram.commands.native`. - - Збій `deleteWebhook`, `deleteMyCommands` або `setMyCommands` із `404: Not Found`, коли прямі команди curl до Bot API працюють, може означати, що `channels.telegram.apiRoot` було встановлено на повний endpoint `/bot`. `apiRoot` має бути лише коренем Bot API, а `openclaw doctor --fix` видаляє випадковий кінцевий `/bot`. - - `getMe returned 401` означає, що Telegram відхилив налаштований токен бота. Оновіть `botToken`, `tokenFile` або `TELEGRAM_BOT_TOKEN` поточним токеном BotFather; OpenClaw зупиняється перед polling, тому це не повідомляється як збій очищення webhook. - - `setMyCommands failed` із помилками мережі/fetch зазвичай означає, що вихідний DNS/HTTPS до `api.telegram.org` заблоковано. + - `setMyCommands failed` з `BOT_COMMANDS_TOO_MUCH` означає, що меню Telegram усе ще переповнене після обрізання; зменште кількість команд plugin/skill/користувацьких команд або вимкніть `channels.telegram.commands.native`. + - Помилка `deleteWebhook`, `deleteMyCommands` або `setMyCommands` з `404: Not Found`, коли прямі команди curl до Bot API працюють, може означати, що `channels.telegram.apiRoot` було встановлено на повну кінцеву точку `/bot`. `apiRoot` має бути лише коренем Bot API, а `openclaw doctor --fix` видаляє випадковий кінцевий `/bot`. + - `getMe returned 401` означає, що Telegram відхилив налаштований токен бота. Оновіть `botToken`, `tokenFile` або `TELEGRAM_BOT_TOKEN` поточним токеном BotFather; OpenClaw зупиняється до опитування, тому це не повідомляється як збій очищення webhook. + - `setMyCommands failed` з помилками мережі/fetch зазвичай означає, що вихідний DNS/HTTPS до `api.telegram.org` заблоковано. - ### Команди сполучення пристрою (`device-pair` plugin) + ### Команди сполучення пристрою (plugin `device-pair`) - Коли встановлено `device-pair` plugin: + Коли plugin `device-pair` установлено: 1. `/pair` генерує код налаштування 2. вставте код у застосунок iOS - 3. `/pair pending` перелічує запити в очікуванні (зокрема роль/scopes) - 4. підтвердьте запит: - - `/pair approve ` для явного підтвердження - - `/pair approve`, коли є лише один запит в очікуванні + 3. `/pair pending` показує список очікуваних запитів (включно з роллю/областями) + 4. схваліть запит: + - `/pair approve ` для явного схвалення + - `/pair approve`, коли є лише один очікуваний запит - `/pair approve latest` для найновішого - Код налаштування містить короткочасний bootstrap-токен. Вбудована передача bootstrap зберігає токен основного вузла на `scopes: []`; будь-який переданий операторський токен лишається обмеженим `operator.approvals`, `operator.read`, `operator.talk.secrets` і `operator.write`. Перевірки bootstrap-scope мають префікс ролі, тому цей allowlist оператора задовольняє лише операторські запити; неоператорським ролям усе ще потрібні scopes під власним префіксом ролі. + Код налаштування містить короткочасний bootstrap-токен. Вбудована передача bootstrap зберігає токен основного вузла на `scopes: []`; будь-який переданий токен оператора залишається обмеженим `operator.approvals`, `operator.read`, `operator.talk.secrets` і `operator.write`. Перевірки bootstrap-областей мають префікс ролі, тому цей allowlist оператора задовольняє лише запити оператора; ролям, що не є операторськими, усе ще потрібні області під їхнім власним префіксом ролі. - Якщо пристрій повторює спробу зі зміненими деталями автентифікації (наприклад роль/scopes/публічний ключ), попередній запит в очікуванні замінюється, а новий запит використовує інший `requestId`. Повторно виконайте `/pair pending` перед підтвердженням. + Якщо пристрій повторює спробу зі зміненими даними автентифікації (наприклад, роль/області/публічний ключ), попередній очікуваний запит замінюється, а новий запит використовує інший `requestId`. Повторно виконайте `/pair pending` перед схваленням. Докладніше: [Сполучення](/uk/channels/pairing#pair-via-telegram-recommended-for-ios). - Налаштуйте область дії inline-клавіатури: + Налаштуйте область дії вбудованої клавіатури: ```json5 { @@ -436,7 +437,7 @@ curl "https://api.telegram.org/bot/getUpdates" } ``` - Області дії: + Області: - `off` - `dm` @@ -444,7 +445,7 @@ curl "https://api.telegram.org/bot/getUpdates" - `all` - `allowlist` (за замовчуванням) - Застаріле `capabilities: ["inlineButtons"]` зіставляється з `inlineButtons: "all"`. + Застаріле `capabilities: ["inlineButtons"]` відображається на `inlineButtons: "all"`. Приклад дії повідомлення: @@ -472,13 +473,13 @@ curl "https://api.telegram.org/bot/getUpdates" Дії інструментів Telegram включають: - - `sendMessage` (`to`, `content`, необов'язкові `mediaUrl`, `replyToMessageId`, `messageThreadId`) + - `sendMessage` (`to`, `content`, необов’язкові `mediaUrl`, `replyToMessageId`, `messageThreadId`) - `react` (`chatId`, `messageId`, `emoji`) - `deleteMessage` (`chatId`, `messageId`) - `editMessage` (`chatId`, `messageId`, `content`) - - `createForumTopic` (`chatId`, `name`, необов'язкові `iconColor`, `iconCustomEmojiId`) + - `createForumTopic` (`chatId`, `name`, необов’язкові `iconColor`, `iconCustomEmojiId`) - Дії повідомлень каналу надають ергономічні псевдоніми (`send`, `react`, `delete`, `edit`, `sticker`, `sticker-search`, `topic-create`). + Дії повідомлень каналу надають зручні псевдоніми (`send`, `react`, `delete`, `edit`, `sticker`, `sticker-search`, `topic-create`). Елементи керування доступом: @@ -487,17 +488,17 @@ curl "https://api.telegram.org/bot/getUpdates" - `channels.telegram.actions.reactions` - `channels.telegram.actions.sticker` (за замовчуванням: вимкнено) - Примітка: `edit` і `topic-create` наразі ввімкнені за замовчуванням і не мають окремих перемикачів `channels.telegram.actions.*`. - Runtime-надсилання використовують активний знімок config/secrets (запуск/перезавантаження), тому шляхи дій не виконують ad-hoc повторне розв'язання SecretRef для кожного надсилання. + Примітка: `edit` і `topic-create` зараз увімкнені за замовчуванням і не мають окремих перемикачів `channels.telegram.actions.*`. + Надсилання під час виконання використовує активний знімок конфігурації/секретів (запуск/перезавантаження), тому шляхи дій не виконують спеціального повторного розв’язання SecretRef для кожного надсилання. Семантика видалення реакцій: [/tools/reactions](/uk/tools/reactions) - - Telegram підтримує явні теги reply threading у згенерованому виводі: + + Telegram підтримує явні теги гілок відповідей у згенерованому виводі: - - `[[reply_to_current]]` відповідає на повідомлення, яке спричинило запуск + - `[[reply_to_current]]` відповідає на повідомлення, що спричинило запуск - `[[reply_to:]]` відповідає на конкретний ID повідомлення Telegram `channels.telegram.replyToMode` керує обробкою: @@ -506,29 +507,29 @@ curl "https://api.telegram.org/bot/getUpdates" - `first` - `all` - Коли reply threading увімкнено й доступний оригінальний текст або підпис Telegram, OpenClaw автоматично включає нативний фрагмент цитати Telegram. Telegram обмежує нативний текст цитати 1024 кодовими одиницями UTF-16, тому довші повідомлення цитуються від початку й повертаються до звичайної відповіді, якщо Telegram відхиляє цитату. + Коли гілки відповідей увімкнено й оригінальний текст або підпис Telegram доступний, OpenClaw автоматично включає нативний уривок цитати Telegram. Telegram обмежує нативний текст цитати 1024 кодовими одиницями UTF-16, тому довші повідомлення цитуються від початку й повертаються до звичайної відповіді, якщо Telegram відхиляє цитату. - Примітка: `off` вимикає неявний reply threading. Явні теги `[[reply_to_*]]` усе одно враховуються. + Примітка: `off` вимикає неявні гілки відповідей. Явні теги `[[reply_to_*]]` усе ще враховуються. - - Форумні супергрупи: + + Супергрупи форуму: - - ключі сесій теми додають `:topic:` - - відповіді та typing спрямовуються в потік теми - - шлях config теми: + - ключі сесій тем додають `:topic:` + - відповіді та індикація набору спрямовуються в гілку теми + - шлях конфігурації теми: `channels.telegram.groups..topics.` - Спеціальний випадок загальної теми (`threadId=1`): + Особливий випадок загальної теми (`threadId=1`): - - надсилання повідомлень пропускає `message_thread_id` (Telegram відхиляє `sendMessage(...thread_id=1)`) - - дії typing усе ще включають `message_thread_id` + - надсилання повідомлень опускають `message_thread_id` (Telegram відхиляє `sendMessage(...thread_id=1)`) + - дії набору тексту все одно включають `message_thread_id` - Наслідування теми: записи теми наслідують налаштування групи, якщо їх не перевизначено (`requireMention`, `allowFrom`, `skills`, `systemPrompt`, `enabled`, `groupPolicy`). - `agentId` є лише тематичним і не наслідується з типових значень групи. + Успадкування тем: записи тем успадковують налаштування групи, якщо їх не перевизначено (`requireMention`, `allowFrom`, `skills`, `systemPrompt`, `enabled`, `groupPolicy`). + `agentId` є лише тематичним і не успадковується з типових значень групи. - **Маршрутизація агента за темою**: кожна тема може маршрутизуватися до іншого агента через установлення `agentId` у config теми. Це дає кожній темі власний ізольований workspace, пам'ять і сесію. Приклад: + **Маршрутизація агента за темою**: кожна тема може спрямовуватися до іншого агента через установлення `agentId` у конфігурації теми. Це дає кожній темі власну ізольовану робочу область, пам’ять і сесію. Приклад: ```json5 { @@ -550,24 +551,24 @@ curl "https://api.telegram.org/bot/getUpdates" Після цього кожна тема має власний ключ сесії: `agent:zu:telegram:group:-1001234567890:topic:3` - **Постійне прив'язування теми ACP**: форумні теми можуть закріплювати сесії ACP harness через типізовані прив'язки ACP верхнього рівня (`bindings[]` з `type: "acp"` і `match.channel: "telegram"`, `peer.kind: "group"` та кваліфікованим за темою id на кшталт `-1001234567890:topic:42`). Наразі обмежено форумними темами в групах/супергрупах. Див. [Агенти ACP](/uk/tools/acp-agents). + **Постійне прив’язування тем ACP**: теми форуму можуть закріплювати сесії ACP harness через типізовані ACP-прив’язки верхнього рівня (`bindings[]` з `type: "acp"` і `match.channel: "telegram"`, `peer.kind: "group"` та ідентифікатором з уточненням теми, наприклад `-1001234567890:topic:42`). Наразі область дії обмежена темами форуму в групах/супергрупах. Див. [Агенти ACP](/uk/tools/acp-agents). - **Прив'язаний до потоку ACP spawn із чату**: `/acp spawn --thread here|auto` прив'язує поточну тему до нової сесії ACP; подальші повідомлення маршрутизуються туди напряму. OpenClaw закріплює підтвердження spawn у темі. Потрібно, щоб `channels.telegram.threadBindings.spawnSessions` лишалося ввімкненим (за замовчуванням: `true`). + **Породження ACP, прив’язане до гілки, з чату**: `/acp spawn --thread here|auto` прив’язує поточну тему до нової сесії ACP; подальші повідомлення спрямовуються туди напряму. OpenClaw закріплює підтвердження породження в темі. Потрібно, щоб `channels.telegram.threadBindings.spawnSessions` залишалося ввімкненим (за замовчуванням: `true`). - Контекст шаблону надає `MessageThreadId` і `IsForum`. DM-чати з `message_thread_id` за замовчуванням зберігають DM-маршрутизацію та метадані відповіді у плоских сесіях; вони використовують ключі сесій з урахуванням потоків лише тоді, коли налаштовано `threadReplies: "inbound"`, `threadReplies: "always"`, `requireTopic: true` або відповідний config теми. Використовуйте верхньорівневий `channels.telegram.dm.threadReplies` для типового значення облікового запису або `direct..threadReplies` для одного DM. + Контекст шаблону надає `MessageThreadId` і `IsForum`. Чати DM з `message_thread_id` за замовчуванням зберігають маршрутизацію DM і метадані відповіді у пласких сесіях; вони використовують ключі сесій з урахуванням гілок лише тоді, коли налаштовано `threadReplies: "inbound"`, `threadReplies: "always"`, `requireTopic: true` або відповідну конфігурацію теми. Використовуйте `channels.telegram.dm.threadReplies` верхнього рівня для типового значення облікового запису або `direct..threadReplies` для одного DM. ### Аудіоповідомлення - Telegram розрізняє голосові повідомлення та аудіофайли. + Telegram розрізняє голосові нотатки та аудіофайли. - за замовчуванням: поведінка аудіофайлу - - тег `[[audio_as_voice]]` у відповіді агента, щоб примусово надіслати голосове повідомлення - - транскрипти вхідних голосових повідомлень оформлюються як машинно згенерований, - недовірений текст у контексті агента; виявлення згадок усе одно використовує сирий - транскрипт, тому голосові повідомлення з mention-gating продовжують працювати. + - тег `[[audio_as_voice]]` у відповіді агента, щоб примусово надіслати голосову нотатку + - транскрипти вхідних голосових нотаток оформлюються в контексті агента як машинно згенерований, + недовірений текст; виявлення згадок усе ще використовує сирий + транскрипт, тому голосові повідомлення з обмеженням за згадкою продовжують працювати. Приклад дії повідомлення: @@ -619,7 +620,7 @@ curl "https://api.telegram.org/bot/getUpdates" - `~/.openclaw/telegram/sticker-cache.json` - Стікери описуються один раз (коли це можливо) і кешуються, щоб зменшити повторні виклики розпізнавання зображень. + Стікери описуються один раз (коли можливо) і кешуються, щоб зменшити кількість повторних викликів зору. Увімкнути дії зі стікерами: @@ -660,7 +661,7 @@ curl "https://api.telegram.org/bot/getUpdates" - Реакції Telegram надходять як оновлення `message_reaction` (окремо від корисного навантаження повідомлень). + Реакції Telegram надходять як оновлення `message_reaction` (окремо від корисного навантаження повідомлення). Коли це ввімкнено, OpenClaw ставить у чергу системні події на кшталт: @@ -673,39 +674,39 @@ curl "https://api.telegram.org/bot/getUpdates" Примітки: - - `own` означає лише реакції користувачів на повідомлення, надіслані ботом (за найкращої спроби через кеш надісланих повідомлень). - - Події реакцій усе ще поважають засоби контролю доступу Telegram (`dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`); неавторизовані відправники відкидаються. - - Telegram не надає ідентифікатори гілок в оновленнях реакцій. - - групи не форумного типу спрямовуються до сесії групового чату - - форумні групи спрямовуються до сесії загальної теми групи (`:topic:1`), а не до точної початкової теми + - `own` означає лише реакції користувачів на повідомлення, надіслані ботом (за можливості через кеш надісланих повідомлень). + - Події реакцій усе ще дотримуються контролів доступу Telegram (`dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`); неавторизовані відправники відкидаються. + - Telegram не надає ідентифікатори ланцюжків в оновленнях реакцій. + - нефорумні групи спрямовуються до сеансу групового чату + - форумні групи спрямовуються до сеансу загальної теми групи (`:topic:1`), а не до точної початкової теми - `allowed_updates` для polling/webhook автоматично містить `message_reaction`. + `allowed_updates` для опитування/Webhook автоматично містять `message_reaction`. - - `ackReaction` надсилає емодзі підтвердження, поки OpenClaw обробляє вхідне повідомлення. + + `ackReaction` надсилає emoji-підтвердження, поки OpenClaw обробляє вхідне повідомлення. Порядок визначення: - `channels.telegram.accounts..ackReaction` - `channels.telegram.ackReaction` - `messages.ackReaction` - - резервний емодзі ідентичності агента (`agents.list[].identity.emoji`, інакше "👀") + - резервний emoji ідентичності агента (`agents.list[].identity.emoji`, інакше "👀") Примітки: - - Telegram очікує unicode-емодзі (наприклад, "👀"). + - Telegram очікує unicode emoji (наприклад "👀"). - Використовуйте `""`, щоб вимкнути реакцію для каналу або облікового запису. - Записи конфігурації каналу ввімкнено типово (`configWrites !== false`). + Записи конфігурації каналу ввімкнені типово (`configWrites !== false`). - Записи, ініційовані Telegram, охоплюють: + Записи, ініційовані Telegram, включають: - - події міграції груп (`migrate_to_chat_id`) для оновлення `channels.telegram.groups` + - події міграції групи (`migrate_to_chat_id`) для оновлення `channels.telegram.groups` - `/config set` і `/config unset` (потрібне ввімкнення команд) Вимкнути: @@ -722,30 +723,30 @@ curl "https://api.telegram.org/bot/getUpdates" - - Типово використовується long polling. Для режиму webhook задайте `channels.telegram.webhookUrl` і `channels.telegram.webhookSecret`; необов’язкові `webhookPath`, `webhookHost`, `webhookPort` (типово `/telegram-webhook`, `127.0.0.1`, `8787`). + + Типово використовується довге опитування. Для режиму Webhook задайте `channels.telegram.webhookUrl` і `channels.telegram.webhookSecret`; необов’язкові `webhookPath`, `webhookHost`, `webhookPort` (типові значення `/telegram-webhook`, `127.0.0.1`, `8787`). - Локальний слухач прив’язується до `127.0.0.1:8787`. Для публічного ingress або поставте зворотний проксі перед локальним портом, або навмисно задайте `webhookHost: "0.0.0.0"`. + Локальний слухач прив’язується до `127.0.0.1:8787`. Для публічного входу або поставте зворотний проксі перед локальним портом, або навмисно задайте `webhookHost: "0.0.0.0"`. - Режим webhook перевіряє захист запиту, секретний токен Telegram і JSON-тіло перед поверненням `200` до Telegram. - Потім OpenClaw обробляє оновлення асинхронно через ті самі доріжки бота для кожного чату/теми, що й long polling, тому повільні ходи агента не затримують ACK доставки Telegram. + Режим Webhook перевіряє захисти запиту, секретний токен Telegram і JSON-тіло, перш ніж повернути `200` до Telegram. + Потім OpenClaw асинхронно обробляє оновлення через ті самі лінії бота для кожного чату/теми, що використовуються довгим опитуванням, тому повільні ходи агента не затримують ACK доставки Telegram. - + - Типове значення `channels.telegram.textChunkLimit` — 4000. - - `channels.telegram.chunkMode="newline"` надає перевагу межам абзаців (порожнім рядкам) перед розбиттям за довжиною. + - `channels.telegram.chunkMode="newline"` надає перевагу межам абзаців (порожнім рядкам) перед поділом за довжиною. - `channels.telegram.mediaMaxMb` (типово 100) обмежує розмір вхідних і вихідних медіа Telegram. - - `channels.telegram.mediaGroupFlushMs` (типово 500) керує тим, як довго альбоми/медіагрупи Telegram буферизуються, перш ніж OpenClaw передасть їх як одне вхідне повідомлення. Збільште це значення, якщо частини альбому надходять із запізненням; зменште його, щоб скоротити затримку відповіді на альбом. - - `channels.telegram.timeoutSeconds` перевизначає тайм-аут клієнта Telegram API (якщо не задано, застосовується типове значення grammY). Клієнти ботів обмежують налаштовані значення нижче 60-секундного захисту вихідних запитів тексту/набору, щоб grammY не переривав доставку видимої відповіді до того, як спрацює транспортний захист і резервний механізм OpenClaw. Long polling усе ще використовує 45-секундний захист запиту `getUpdates`, щоб неактивні опитування не залишалися покинутими безкінечно. - - `channels.telegram.pollingStallThresholdMs` типово дорівнює `120000`; налаштовуйте в діапазоні від `30000` до `600000` лише для хибнопозитивних перезапусків через зависання polling. + - `channels.telegram.mediaGroupFlushMs` (типово 500) контролює, як довго альбоми/медіагрупи Telegram буферизуються, перш ніж OpenClaw відправить їх як одне вхідне повідомлення. Збільште значення, якщо частини альбому надходять пізно; зменште його, щоб скоротити затримку відповіді на альбом. + - `channels.telegram.timeoutSeconds` перевизначає тайм-аут клієнта Telegram API (якщо не задано, застосовується типове значення grammY). Клієнти ботів обмежують налаштовані значення нижче 60-секундного захисту вихідних текстових/typing-запитів, щоб grammY не переривала доставку видимої відповіді до того, як зможуть спрацювати транспортний захист і резервний механізм OpenClaw. Довге опитування все ще використовує 45-секундний захист запиту `getUpdates`, щоб неактивні опитування не залишалися покинутими безстроково. + - Типове значення `channels.telegram.pollingStallThresholdMs` — `120000`; налаштовуйте в діапазоні від `30000` до `600000` лише для хибнопозитивних перезапусків через зависання опитування. - історія контексту групи використовує `channels.telegram.historyLimit` або `messages.groupChat.historyLimit` (типово 50); `0` вимикає. - - додатковий контекст відповіді/цитати/пересилання наразі передається як отримано. - - allowlist Telegram передусім обмежують, хто може запускати агента, а не є повною межею редагування додаткового контексту. - - Елементи керування історією DM: + - додатковий контекст відповіді/цитати/пересилання наразі передається як отриманий. + - allowlist Telegram насамперед обмежують, хто може запускати агента, а не є повною межею редагування додаткового контексту. + - Контролі історії DM: - `channels.telegram.dmHistoryLimit` - `channels.telegram.dms[""].historyLimit` - - Конфігурація `channels.telegram.retry` застосовується до допоміжних засобів надсилання Telegram (CLI/інструменти/дії) для відновлюваних вихідних помилок API. Доставка фінальної відповіді для вхідних повідомлень також використовує обмежений повтор безпечного надсилання для збоїв Telegram до підключення, але не повторює неоднозначні мережеві оболонки після надсилання, які можуть дублювати видимі повідомлення. + - Конфігурація `channels.telegram.retry` застосовується до допоміжних засобів надсилання Telegram (CLI/інструменти/дії) для відновлюваних помилок вихідного API. Доставка фінальної вхідної відповіді також використовує обмежені безпечні повторні спроби надсилання для збоїв Telegram до підключення, але не повторює неоднозначні мережеві конверти після надсилання, які можуть дублювати видимі повідомлення. Ціль надсилання CLI може бути числовим ID чату або іменем користувача: @@ -764,7 +765,7 @@ openclaw message poll --channel telegram --target -1001234567890:topic:42 \ --poll-duration-seconds 300 --poll-public ``` - Прапорці опитувань лише для Telegram: + Прапорці опитування лише для Telegram: - `--poll-duration-seconds` (5-600) - `--poll-anonymous` @@ -773,8 +774,8 @@ openclaw message poll --channel telegram --target -1001234567890:topic:42 \ Надсилання Telegram також підтримує: - - `--presentation` з блоками `buttons` для inline-клавіатур, коли `channels.telegram.capabilities.inlineButtons` це дозволяє - - `--pin` або `--delivery '{"pin":true}'`, щоб запросити закріплену доставку, коли бот може закріплювати в цьому чаті + - `--presentation` з блоками `buttons` для вбудованих клавіатур, коли `channels.telegram.capabilities.inlineButtons` це дозволяє + - `--pin` або `--delivery '{"pin":true}'`, щоб запитати закріплену доставку, коли бот може закріплювати в цьому чаті - `--force-document`, щоб надсилати вихідні зображення та GIF як документи замість стиснених фото або завантажень анімованих медіа Обмеження дій: @@ -785,36 +786,36 @@ openclaw message poll --channel telegram --target -1001234567890:topic:42 \ - Telegram підтримує схвалення exec у DM схвалювачів і може необов’язково публікувати запити в початковому чаті або темі. Схвалювачі мають бути числовими ID користувачів Telegram. + Telegram підтримує схвалення exec у DM схвалювачів і може необов’язково публікувати підказки в початковому чаті або темі. Схвалювачі мають бути числовими ID користувачів Telegram. Шлях конфігурації: - `channels.telegram.execApprovals.enabled` (автоматично вмикається, коли можна визначити принаймні одного схвалювача) - - `channels.telegram.execApprovals.approvers` (повертається до числових ID власників із `commands.ownerAllowFrom`) + - `channels.telegram.execApprovals.approvers` (резервно використовує числові ID власників із `commands.ownerAllowFrom`) - `channels.telegram.execApprovals.target`: `dm` (типово) | `channel` | `both` - `agentFilter`, `sessionFilter` - `channels.telegram.allowFrom`, `groupAllowFrom` і `defaultTo` керують тим, хто може говорити з ботом і куди він надсилає звичайні відповіді. Вони не роблять когось схвалювачем exec. Перше схвалене сполучення DM початково заповнює `commands.ownerAllowFrom`, коли власника команд ще немає, тому налаштування з одним власником усе ще працює без дублювання ID у `execApprovals.approvers`. + `channels.telegram.allowFrom`, `groupAllowFrom` і `defaultTo` контролюють, хто може говорити з ботом і куди він надсилає звичайні відповіді. Вони не роблять когось схвалювачем exec. Перше схвалене парування DM ініціалізує `commands.ownerAllowFrom`, коли власника команд ще немає, тож налаштування з одним власником усе одно працює без дублювання ID у `execApprovals.approvers`. - Доставка в канал показує текст команди в чаті; вмикайте `channel` або `both` лише в довірених групах/темах. Коли запит потрапляє у форумну тему, OpenClaw зберігає тему для запиту схвалення та подальшого повідомлення. Схвалення exec типово спливають через 30 хвилин. + Доставка в канал показує текст команди в чаті; вмикайте `channel` або `both` лише в довірених групах/темах. Коли підказка потрапляє у форумну тему, OpenClaw зберігає тему для підказки схвалення та подальшого повідомлення. Схвалення exec типово закінчуються через 30 хвилин. - Inline-кнопки схвалення також потребують, щоб `channels.telegram.capabilities.inlineButtons` дозволяв цільову поверхню (`dm`, `group` або `all`). ID схвалення з префіксом `plugin:` визначаються через схвалення plugin; інші спершу визначаються через схвалення exec. + Вбудовані кнопки схвалення також потребують, щоб `channels.telegram.capabilities.inlineButtons` дозволяв цільову поверхню (`dm`, `group` або `all`). ID схвалень із префіксом `plugin:` визначаються через схвалення plugin; інші спочатку визначаються через схвалення exec. Див. [Схвалення exec](/uk/tools/exec-approvals). -## Елементи керування відповідями про помилки +## Контролі відповідей про помилки -Коли агент стикається з помилкою доставки або провайдера, Telegram може або відповісти текстом помилки, або придушити його. Цією поведінкою керують два ключі конфігурації: +Коли агент стикається з помилкою доставки або провайдера, Telegram може або відповісти текстом помилки, або придушити її. Цю поведінку контролюють два ключі конфігурації: -| Ключ | Значення | Типово | Опис | -| ----------------------------------- | ----------------- | ------- | ----------------------------------------------------------------------------------------------- | +| Ключ | Значення | Типово | Опис | +| ----------------------------------- | ----------------- | ------- | ---------------------------------------------------------------------------------------------- | | `channels.telegram.errorPolicy` | `reply`, `silent` | `reply` | `reply` надсилає дружнє повідомлення про помилку в чат. `silent` повністю придушує відповіді про помилки. | | `channels.telegram.errorCooldownMs` | number (ms) | `60000` | Мінімальний час між відповідями про помилки до того самого чату. Запобігає спаму помилками під час збоїв. | -Підтримуються перевизначення для кожного облікового запису, групи та теми (те саме успадкування, що й для інших ключів конфігурації Telegram). +Підтримуються перевизначення для облікового запису, групи й теми (така сама спадковість, як і для інших ключів конфігурації Telegram). ```json5 { @@ -840,51 +841,51 @@ openclaw message poll --channel telegram --target -1001234567890:topic:42 \ - Якщо `requireMention=false`, режим приватності Telegram має дозволяти повну видимість. - BotFather: `/setprivacy` -> Disable - потім видаліть і повторно додайте бота до групи - - `openclaw channels status` попереджає, коли конфігурація очікує групові повідомлення без згадки. + - `openclaw channels status` попереджає, коли конфігурація очікує групові повідомлення без згадок. - `openclaw channels status --probe` може перевіряти явні числові ID груп; wildcard `"*"` не можна перевірити на членство. - - швидка перевірка сесії: `/activation always`. + - швидкий тест сеансу: `/activation always`. - + - - коли існує `channels.telegram.groups`, група має бути в списку (або містити `"*"`) + - коли існує `channels.telegram.groups`, група має бути вказана (або має містити `"*"`) - перевірте членство бота в групі - перегляньте журнали: `openclaw logs --follow` для причин пропуску - + - - авторизуйте свою ідентичність відправника (сполучення та/або числовий `allowFrom`) - - авторизація команд усе ще застосовується, навіть коли політика групи — `open` - - `setMyCommands failed` з `BOT_COMMANDS_TOO_MUCH` означає, що нативне меню має забагато записів; зменште кількість команд plugin/skill/користувацьких команд або вимкніть нативні меню - - стартові виклики `deleteMyCommands` / `setMyCommands` і виклики набору `sendChatAction` обмежені й повторюються один раз через транспортний резерв Telegram у разі тайм-ауту запиту. Постійні мережеві/fetch-помилки зазвичай вказують на проблеми досяжності DNS/HTTPS до `api.telegram.org` + - авторизуйте ідентичність відправника (парування та/або числовий `allowFrom`) + - авторизація команд усе одно застосовується, навіть коли політика групи — `open` + - `setMyCommands failed` з `BOT_COMMANDS_TOO_MUCH` означає, що в нативному меню забагато записів; зменште кількість plugin/skill/користувацьких команд або вимкніть нативні меню + - стартові виклики `deleteMyCommands` / `setMyCommands` і typing-виклики `sendChatAction` обмежені та повторюються один раз через транспортний резервний механізм Telegram у разі тайм-ауту запиту. Постійні помилки мережі/fetch зазвичай вказують на проблеми з доступністю DNS/HTTPS до `api.telegram.org` - - `getMe returned 401` — це збій автентифікації Telegram для налаштованого токена бота. - - Повторно скопіюйте або згенеруйте заново токен бота в BotFather, а потім оновіть `channels.telegram.botToken`, `channels.telegram.tokenFile`, `channels.telegram.accounts..botToken` або `TELEGRAM_BOT_TOKEN` для стандартного облікового запису. - - `deleteWebhook 401 Unauthorized` під час запуску також є збоєм автентифікації; трактування цього як «Webhook не існує» лише відклало б той самий збій через поганий токен до пізніших викликів API. + - `getMe returned 401` — це помилка автентифікації Telegram для налаштованого токена бота. + - Повторно скопіюйте або згенеруйте токен бота в BotFather, потім оновіть `channels.telegram.botToken`, `channels.telegram.tokenFile`, `channels.telegram.accounts..botToken` або `TELEGRAM_BOT_TOKEN` для облікового запису за замовчуванням. + - `deleteWebhook 401 Unauthorized` під час запуску також є помилкою автентифікації; трактування цього як "webhook не існує" лише відкладе ту саму помилку неправильного токена до пізніших викликів API. - - Node 22+ і власний fetch/proxy можуть спричиняти негайне переривання, якщо типи AbortSignal не збігаються. - - Деякі хости спершу розв’язують `api.telegram.org` в IPv6; несправний вихідний IPv6-трафік може спричиняти періодичні збої Telegram API. + - Node 22+ + власний fetch/proxy може спричиняти негайне переривання, якщо типи AbortSignal не збігаються. + - Деякі хости спочатку розв'язують `api.telegram.org` в IPv6; несправний вихідний IPv6-трафік може спричиняти періодичні збої Telegram API. - Якщо журнали містять `TypeError: fetch failed` або `Network request for 'getUpdates' failed!`, OpenClaw тепер повторює ці операції як відновлювані мережеві помилки. - - Під час запуску опитування OpenClaw повторно використовує успішну стартову перевірку `getMe` для grammY, тож виконавцю не потрібен другий `getMe` перед першим `getUpdates`. - - Якщо `deleteWebhook` завершується збоєм через тимчасову мережеву помилку під час запуску опитування, OpenClaw переходить до long polling замість ще одного передопитувального виклику площини керування. Якщо Webhook усе ще активний, це проявляється як конфлікт `getUpdates`; OpenClaw тоді перебудовує транспорт Telegram і повторює очищення Webhook. - - Якщо сокети Telegram перестворюються з коротким фіксованим інтервалом, перевірте, чи не занизьке значення `channels.telegram.timeoutSeconds`; клієнти ботів обмежують налаштовані значення нижче захисних меж вихідних запитів і `getUpdates`, але старіші випуски могли переривати кожне опитування або відповідь, коли це значення було нижчим за ці межі. - - Якщо журнали містять `Polling stall detected`, OpenClaw типово перезапускає опитування й перебудовує транспорт Telegram після 120 секунд без завершеної перевірки життєздатності long-poll. - - `openclaw channels status --probe` і `openclaw doctor` попереджають, коли запущений обліковий запис опитування не завершив `getUpdates` після стартового пільгового періоду, коли запущений обліковий запис Webhook не завершив `setWebhook` після стартового пільгового періоду, або коли остання успішна активність транспорту опитування застаріла. - - Збільшуйте `channels.telegram.pollingStallThresholdMs` лише тоді, коли довготривалі виклики `getUpdates` працюють нормально, але ваш хост усе ще повідомляє про хибні перезапуски через зависання опитування. Постійні зависання зазвичай вказують на проблеми з proxy, DNS, IPv6 або вихідним TLS між хостом і `api.telegram.org`. - - Telegram також враховує змінні середовища proxy процесу для транспорту Bot API, зокрема `HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY` та їхні варіанти в нижньому регістрі. `NO_PROXY` / `no_proxy` усе ще можуть обходити `api.telegram.org`. - - Якщо керований proxy OpenClaw налаштовано через `OPENCLAW_PROXY_URL` для сервісного середовища й немає стандартних змінних середовища proxy, Telegram також використовує цей URL для транспорту Bot API. - - На VPS-хостах із нестабільним прямим виходом/TLS маршрутизуйте виклики Telegram API через `channels.telegram.proxy`: + - Під час запуску опитування OpenClaw повторно використовує успішну стартову перевірку `getMe` для grammY, щоб runner не потребував другого `getMe` перед першим `getUpdates`. + - Якщо `deleteWebhook` завершується тимчасовою мережевою помилкою під час запуску опитування, OpenClaw переходить до long polling замість виконання ще одного керівного виклику перед опитуванням. Webhook, який усе ще активний, проявляється як конфлікт `getUpdates`; тоді OpenClaw перебудовує транспорт Telegram і повторює очищення webhook. + - Якщо сокети Telegram перестворюються з коротким фіксованим інтервалом, перевірте, чи не занизьке значення `channels.telegram.timeoutSeconds`; клієнти ботів обмежують налаштовані значення нижче за захисні межі вихідних запитів і `getUpdates`, але старіші випуски могли переривати кожне опитування або відповідь, коли це значення було нижчим за ці межі. + - Якщо журнали містять `Polling stall detected`, OpenClaw перезапускає опитування та перебудовує транспорт Telegram після 120 секунд без завершеної перевірки життєздатності long-poll за замовчуванням. + - `openclaw channels status --probe` і `openclaw doctor` попереджають, коли запущений обліковий запис з опитуванням не завершив `getUpdates` після стартового пільгового періоду, коли запущений обліковий запис із webhook не завершив `setWebhook` після стартового пільгового періоду або коли остання успішна активність транспорту опитування застаріла. + - Збільшуйте `channels.telegram.pollingStallThresholdMs` лише тоді, коли довготривалі виклики `getUpdates` справні, але ваш хост усе одно повідомляє про хибні перезапуски через зависання опитування. Постійні зависання зазвичай вказують на проблеми proxy, DNS, IPv6 або вихідного TLS між хостом і `api.telegram.org`. + - Telegram також враховує env proxy процесу для транспорту Bot API, зокрема `HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY` та їхні варіанти в нижньому регістрі. `NO_PROXY` / `no_proxy` усе ще може обходити `api.telegram.org`. + - Якщо керований proxy OpenClaw налаштовано через `OPENCLAW_PROXY_URL` для сервісного середовища й стандартного env proxy немає, Telegram також використовує цю URL-адресу для транспорту Bot API. + - На VPS-хостах із нестабільним прямим вихідним трафіком/TLS маршрутизуйте виклики Telegram API через `channels.telegram.proxy`: ```yaml channels: @@ -892,8 +893,8 @@ channels: proxy: socks5://:@proxy-host:1080 ``` - - Node 22+ типово використовує `autoSelectFamily=true` (крім WSL2). Порядок результатів DNS для Telegram враховує `OPENCLAW_TELEGRAM_DNS_RESULT_ORDER`, потім `channels.telegram.network.dnsResultOrder`, потім стандарт процесу, як-от `NODE_OPTIONS=--dns-result-order=ipv4first`; якщо нічого не застосовується, Node 22+ повертається до `ipv4first`. - - Якщо ваш хост є WSL2 або явно краще працює в режимі лише IPv4, примусово задайте вибір сімейства: + - Node 22+ за замовчуванням використовує `autoSelectFamily=true` (крім WSL2). Порядок результатів DNS Telegram враховує `OPENCLAW_TELEGRAM_DNS_RESULT_ORDER`, потім `channels.telegram.network.dnsResultOrder`, потім значення процесу за замовчуванням, як-от `NODE_OPTIONS=--dns-result-order=ipv4first`; якщо нічого не застосовується, Node 22+ повертається до `ipv4first`. + - Якщо ваш хост є WSL2 або явно краще працює з поведінкою лише IPv4, примусово задайте вибір family: ```yaml channels: @@ -902,10 +903,10 @@ channels: autoSelectFamily: false ``` - - Відповіді діапазону RFC 2544 для бенчмаркінгу (`198.18.0.0/15`) уже дозволені - для завантажень медіа Telegram за замовчуванням. Якщо довірений fake-IP або + - Відповіді діапазону бенчмаркінгу RFC 2544 (`198.18.0.0/15`) уже дозволені + для завантаження медіа Telegram за замовчуванням. Якщо довірений fake-IP або прозорий proxy переписує `api.telegram.org` на якусь іншу - приватну/внутрішню/спеціального використання адресу під час завантажень медіа, ви можете + приватну/внутрішню/спеціальну адресу під час завантаження медіа, ви можете увімкнути обхід лише для Telegram: ```yaml @@ -915,25 +916,25 @@ channels: dangerouslyAllowPrivateNetwork: true ``` - - Така сама опція доступна для окремого облікового запису за адресою + - Такий самий opt-in доступний для кожного облікового запису за адресою `channels.telegram.accounts..network.dangerouslyAllowPrivateNetwork`. - - Якщо ваш proxy розв’язує хости медіа Telegram у `198.18.x.x`, спершу залиште + - Якщо ваш proxy розв'язує медіахости Telegram у `198.18.x.x`, спочатку залиште небезпечний прапорець вимкненим. Медіа Telegram уже дозволяє діапазон - RFC 2544 для бенчмаркінгу за замовчуванням. + бенчмаркінгу RFC 2544 за замовчуванням. `channels.telegram.network.dangerouslyAllowPrivateNetwork` послаблює захист Telegram - від SSRF для медіа. Використовуйте це лише для довірених середовищ proxy, - контрольованих оператором, як-от Clash, Mihomo або маршрутизація fake-IP у Surge, коли вони - синтезують приватні або спеціального використання відповіді поза діапазоном RFC 2544 для бенчмаркінгу. - Для звичайного публічного доступу Telegram через інтернет залишайте це вимкненим. + media SSRF. Використовуйте це лише для довірених, контрольованих оператором середовищ proxy, + як-от маршрутизація fake-IP у Clash, Mihomo або Surge, коли вони + синтезують приватні чи спеціальні відповіді поза діапазоном бенчмаркінгу + RFC 2544. Залишайте це вимкненим для звичайного публічного доступу Telegram через інтернет. - Перевизначення середовища (тимчасові): - `OPENCLAW_TELEGRAM_DISABLE_AUTO_SELECT_FAMILY=1` - `OPENCLAW_TELEGRAM_ENABLE_AUTO_SELECT_FAMILY=1` - `OPENCLAW_TELEGRAM_DNS_RESULT_ORDER=ipv4first` - - Перевірте відповіді DNS: + - Перевірте DNS-відповіді: ```bash dig +short api.telegram.org A @@ -943,24 +944,24 @@ dig +short api.telegram.org AAAA -Додаткова допомога: [Усунення несправностей каналів](/uk/channels/troubleshooting). +Додаткова допомога: [Усунення неполадок каналів](/uk/channels/troubleshooting). ## Довідник конфігурації Основний довідник: [Довідник конфігурації - Telegram](/uk/gateway/config-channels#telegram). - + -- запуск/автентифікація: `enabled`, `botToken`, `tokenFile`, `accounts.*` (`tokenFile` має вказувати на звичайний файл; символічні посилання відхиляються) -- контроль доступу: `dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`, `groups`, `groups.*.topics.*`, верхньорівневий `bindings[]` (`type: "acp"`) +- запуск/автентифікація: `enabled`, `botToken`, `tokenFile`, `accounts.*` (`tokenFile` має вказувати на звичайний файл; symlink відхиляються) +- керування доступом: `dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`, `groups`, `groups.*.topics.*`, `bindings[]` верхнього рівня (`type: "acp"`) - затвердження exec: `execApprovals`, `accounts.*.execApprovals` - команда/меню: `commands.native`, `commands.nativeSkills`, `customCommands` - потоки/відповіді: `replyToMode`, `dm.threadReplies`, `direct.*.threadReplies` -- потокове передавання: `streaming` (попередній перегляд), `streaming.preview.toolProgress`, `blockStreaming` +- streaming: `streaming` (попередній перегляд), `streaming.preview.toolProgress`, `blockStreaming` - форматування/доставка: `textChunkLimit`, `chunkMode`, `linkPreview`, `responsePrefix` - медіа/мережа: `mediaMaxMb`, `mediaGroupFlushMs`, `timeoutSeconds`, `pollingStallThresholdMs`, `retry`, `network.autoSelectFamily`, `network.dangerouslyAllowPrivateNetwork`, `proxy` -- власний корінь API: `apiRoot` (лише корінь Bot API; не включайте `/bot`) -- Webhook: `webhookUrl`, `webhookSecret`, `webhookPath`, `webhookHost` +- власний корінь API: `apiRoot` (лише корінь Bot API; не додавайте `/bot`) +- webhook: `webhookUrl`, `webhookSecret`, `webhookPath`, `webhookHost` - дії/можливості: `capabilities.inlineButtons`, `actions.sendMessage|editMessage|deleteMessage|reactions|sticker` - реакції: `reactionNotifications`, `reactionLevel` - помилки: `errorPolicy`, `errorCooldownMs` @@ -969,17 +970,17 @@ dig +short api.telegram.org AAAA -Пріоритетність кількох облікових записів: коли налаштовано два або більше ідентифікаторів облікових записів, задайте `channels.telegram.defaultAccount` (або включіть `channels.telegram.accounts.default`), щоб явно визначити стандартну маршрутизацію. Інакше OpenClaw повертається до першого нормалізованого ідентифікатора облікового запису, а `openclaw doctor` попереджає. Іменовані облікові записи успадковують `channels.telegram.allowFrom` / `groupAllowFrom`, але не значення `accounts.default.*`. +Пріоритетність кількох облікових записів: коли налаштовано два або більше ID облікових записів, задайте `channels.telegram.defaultAccount` (або додайте `channels.telegram.accounts.default`), щоб явно визначити маршрутизацію за замовчуванням. Інакше OpenClaw повертається до першого нормалізованого ID облікового запису, а `openclaw doctor` попереджає. Іменовані облікові записи успадковують `channels.telegram.allowFrom` / `groupAllowFrom`, але не значення `accounts.default.*`. ## Пов’язане - - Сполучіть користувача Telegram із Gateway. + + Спаруйте користувача Telegram із gateway. - Поведінка списку дозволених груп і тем. + Поведінка allowlist для груп і тем. Маршрутизуйте вхідні повідомлення до агентів. @@ -990,7 +991,7 @@ dig +short api.telegram.org AAAA Зіставляйте групи й теми з агентами. - - Міжканальна діагностика. + + Діагностика між каналами. diff --git a/docs/uk/cli/sessions.md b/docs/uk/cli/sessions.md index 2deda5853..1f64e9437 100644 --- a/docs/uk/cli/sessions.md +++ b/docs/uk/cli/sessions.md @@ -1,27 +1,33 @@ --- read_when: - Ви хочете вивести список збережених сеансів і переглянути нещодавню активність -summary: Довідка CLI для `openclaw sessions` (список збережених сеансів + використання) +summary: Довідник CLI для `openclaw sessions` (перелік збережених сеансів + використання) title: Сеанси x-i18n: - generated_at: "2026-05-02T12:44:55Z" + generated_at: "2026-05-04T06:12:22Z" model: gpt-5.5 provider: openai - source_hash: 5c9ec3ca55f7c5b6217b481e9da62f5416df73e69405a0dc15e77d2afeac723f + source_hash: 8dc90344f40c53513bd6db3696bc709279155f26e7c3b6ea27e81a07a2f9f15e source_path: cli/sessions.md workflow: 16 --- # `openclaw sessions` -Вивести список збережених сеансів розмов. +Показати список збережених сеансів розмов. -Списки сеансів не є перевірками працездатності каналів/провайдерів. Вони показують збережені +Списки сеансів не є перевірками доступності каналу/провайдера. Вони показують збережені рядки розмов зі сховищ сеансів. Тихий Discord, Slack, Telegram або -інший канал може успішно перепід’єднатися без створення нового рядка сеансу, +інший канал може успішно перепідключитися без створення нового рядка сеансу, доки не буде оброблено повідомлення. Використовуйте `openclaw channels status --probe`, -`openclaw status --deep` або `openclaw health --verbose`, коли потрібне живе -підключення каналу. +`openclaw status --deep` або `openclaw health --verbose`, коли потрібна жива +підключеність каналу. + +Відповіді Gateway `sessions.list` за замовчуванням обмежені, щоб великі довгоживучі +сховища не монополізували цикл подій Gateway. Передавайте явний додатний +`limit` із RPC-клієнтів, коли потрібне інше вікно результатів; відповіді +містять `totalCount`, `limitApplied` і `hasMore`, коли викликачам потрібно показати, +що існує більше рядків. ```bash openclaw sessions @@ -32,30 +38,30 @@ openclaw sessions --verbose openclaw sessions --json ``` -Вибір області дії: +Вибір області: -- за замовчуванням: налаштоване типове сховище агента +- default: налаштоване сховище агента за замовчуванням - `--verbose`: докладне журналювання - `--agent `: одне налаштоване сховище агента -- `--all-agents`: об’єднати всі налаштовані сховища агентів +- `--all-agents`: агрегувати всі налаштовані сховища агентів - `--store `: явний шлях до сховища (не можна поєднувати з `--agent` або `--all-agents`) -Експортуйте пакет траєкторії для збереженого сеансу: +Експортувати пакет траєкторії для збереженого сеансу: ```bash openclaw sessions export-trajectory --session-key "agent:main:telegram:direct:123" --workspace . openclaw sessions export-trajectory --session-key "agent:main:telegram:direct:123" --output bug-123 --json ``` -Це шлях команди, який використовується слеш-командою `/export-trajectory` після того, +Це шлях команди, який використовується slash-командою `/export-trajectory` після того, як власник схвалить запит на виконання. Вихідний каталог завжди розв’язується всередині `.openclaw/trajectory-exports/` у вибраному робочому просторі. `openclaw sessions --all-agents` читає налаштовані сховища агентів. Виявлення сеансів Gateway і ACP -ширше: воно також включає сховища лише на диску, знайдені в -типовому корені `agents/` або шаблонізованому корені `session.store`. Ці +ширше: воно також включає сховища лише на диску, знайдені під +коренем `agents/` за замовчуванням або шаблонізованим коренем `session.store`. Ці виявлені сховища мають розв’язуватися у звичайні файли `sessions.json` всередині -кореня агента; символьні посилання та шляхи поза коренем пропускаються. +кореня агента; симлінки та шляхи поза коренем пропускаються. Приклади JSON: @@ -80,7 +86,7 @@ openclaw sessions export-trajectory --session-key "agent:main:telegram:direct:12 ## Обслуговування очищення -Запустіть обслуговування зараз (замість очікування наступного циклу запису): +Запустити обслуговування зараз (замість очікування наступного циклу запису): ```bash openclaw sessions cleanup --dry-run @@ -91,23 +97,23 @@ openclaw sessions cleanup --enforce --active-key "agent:main:telegram:direct:123 openclaw sessions cleanup --json ``` -`openclaw sessions cleanup` використовує налаштування `session.maintenance` з конфігурації: +`openclaw sessions cleanup` використовує налаштування `session.maintenance` із конфігурації: -- Примітка щодо області дії: `openclaw sessions cleanup` обслуговує сховища сеансів, транскрипти та супровідні файли траєкторій. Вона не очищає журнали запусків cron (`cron/runs/.jsonl`), якими керують `cron.runLog.maxBytes` і `cron.runLog.keepLines` у [конфігурації Cron](/uk/automation/cron-jobs#configuration) та які пояснені в [обслуговуванні Cron](/uk/automation/cron-jobs#maintenance). +- Примітка щодо області: `openclaw sessions cleanup` обслуговує сховища сеансів, транскрипти та бічні файли траєкторій. Вона не обрізає журнали запусків Cron (`cron/runs/.jsonl`), які керуються `cron.runLog.maxBytes` і `cron.runLog.keepLines` у [конфігурації Cron](/uk/automation/cron-jobs#configuration) та пояснюються в [обслуговуванні Cron](/uk/automation/cron-jobs#maintenance). -- `--dry-run`: попередньо показати, скільки записів буде очищено/обмежено без запису. +- `--dry-run`: переглянути, скільки записів було б обрізано/обмежено без запису. - У текстовому режимі dry-run друкує таблицю дій для кожного сеансу (`Action`, `Key`, `Age`, `Model`, `Flags`), щоб ви могли бачити, що буде збережено, а що видалено. - `--enforce`: застосувати обслуговування, навіть коли `session.maintenance.mode` має значення `warn`. -- `--fix-missing`: видалити записи, файли транскриптів яких відсутні, навіть якщо зазвичай вони ще не були б вилучені через вік/кількість. -- `--active-key `: захистити конкретний активний ключ від витіснення через дисковий бюджет. Стійкі зовнішні вказівники розмов, як-от групові сеанси та сеанси чату в межах треду, також зберігаються під час обслуговування за віком/кількістю/дисковим бюджетом. +- `--fix-missing`: видалити записи, файли транскриптів яких відсутні, навіть якщо вони зазвичай ще не були б вилучені за віком/кількістю. +- `--active-key `: захистити певний активний ключ від витіснення через бюджет диска. Стійкі зовнішні вказівники розмов, як-от групові сеанси та сеанси чату в межах потоку, також зберігаються під час обслуговування за віком/кількістю/бюджетом диска. - `--agent `: запустити очищення для одного налаштованого сховища агента. - `--all-agents`: запустити очищення для всіх налаштованих сховищ агентів. -- `--store `: запустити для конкретного файлу `sessions.json`. -- `--json`: надрукувати підсумок JSON. З `--all-agents` вивід містить по одному підсумку для кожного сховища. +- `--store `: виконати для конкретного файлу `sessions.json`. +- `--json`: надрукувати зведення JSON. З `--all-agents` вивід містить одне зведення для кожного сховища. -Коли Gateway доступний, очищення не в режимі dry-run для налаштованих сховищ агентів -надсилається через Gateway, щоб воно використовувало той самий writer сховища сеансів, що й runtime -трафік. Використовуйте `--store ` для явного офлайн-відновлення файлу сховища. +Коли Gateway доступний, очищення без dry-run для налаштованих сховищ агентів +надсилається через Gateway, щоб воно використовувало той самий записувач сховища сеансів, що й runtime-трафік. +Використовуйте `--store ` для явного офлайн-відновлення файлу сховища. `openclaw sessions cleanup --all-agents --dry-run --json`: @@ -143,5 +149,5 @@ openclaw sessions cleanup --json ## Пов’язане -- [довідник CLI](/uk/cli) -- [керування сеансами](/uk/concepts/session) +- [Довідник CLI](/uk/cli) +- [Керування сеансами](/uk/concepts/session) diff --git a/docs/uk/concepts/messages.md b/docs/uk/concepts/messages.md index 54497156c..38b44125d 100644 --- a/docs/uk/concepts/messages.md +++ b/docs/uk/concepts/messages.md @@ -2,21 +2,21 @@ read_when: - Пояснення того, як вхідні повідомлення стають відповідями - Уточнення сеансів, режимів постановки в чергу або поведінки потокового передавання - - Документування видимості міркувань і наслідків для використання -summary: Потік повідомлень, сеанси, постановка в чергу та видимість міркувань + - Документування видимості міркувань і наслідків використання +summary: Потік повідомлень, сесії, постановка в чергу та видимість міркувань title: Повідомлення x-i18n: - generated_at: "2026-04-30T15:20:32Z" + generated_at: "2026-05-04T06:12:35Z" model: gpt-5.5 provider: openai - source_hash: fdeee014d92767a725501691fbe0c4ee6b631acc9a2ab5cbbcf321bfee9679b9 + source_hash: 15242e21fd17a9f2013561003e108d197204d834caf51bbcdc53ffb3f118b14f source_path: concepts/messages.md workflow: 16 --- -OpenClaw обробляє вхідні повідомлення через конвеєр визначення сеансу, постановки в чергу, потокового передавання, виконання інструментів і видимості міркувань. Ця сторінка показує шлях від вхідного повідомлення до відповіді. +OpenClaw обробляє вхідні повідомлення через конвеєр визначення сесії, постановки в чергу, streaming, виконання інструментів і видимості міркування. Ця сторінка показує шлях від вхідного повідомлення до відповіді. -## Потік повідомлень (загальний рівень) +## Потік повідомлень (високорівнево) ``` Inbound message @@ -29,20 +29,20 @@ Inbound message Ключові налаштування містяться в конфігурації: - `messages.*` для префіксів, постановки в чергу та поведінки груп. -- `agents.defaults.*` для типових значень блокового потокового передавання та розбиття на фрагменти. -- Перевизначення каналів (`channels.whatsapp.*`, `channels.telegram.*` тощо) для обмежень і перемикачів потокового передавання. +- `agents.defaults.*` для типових параметрів block streaming і chunking. +- Перевизначення каналів (`channels.whatsapp.*`, `channels.telegram.*` тощо) для лімітів і перемикачів streaming. -Повну схему див. у [Конфігурація](/uk/gateway/configuration). +Повну схему дивіться в [Конфігурація](/uk/gateway/configuration). ## Дедуплікація вхідних повідомлень -Канали можуть повторно доставляти те саме повідомлення після повторних підключень. OpenClaw зберігає короткоживучий кеш із ключем за каналом/обліковим записом/співрозмовником/сеансом/ідентифікатором повідомлення, щоб дублікати доставок не запускали ще один запуск агента. +Канали можуть повторно доставляти те саме повідомлення після перепідключень. OpenClaw зберігає короткочасний кеш із ключем за каналом/обліковим записом/співрозмовником/сесією/ідентифікатором повідомлення, щоб дублікати доставок не запускали ще один запуск агента. -## Дебаунс вхідних повідомлень +## Debouncing вхідних повідомлень -Швидкі послідовні повідомлення від **того самого відправника** можна об’єднати в один хід агента через `messages.inbound`. Дебаунс обмежується окремо для кожного каналу + розмови та використовує найновіше повідомлення для прив’язки відповіді до гілки/ідентифікаторів. +Швидкі послідовні повідомлення від **того самого відправника** можна об’єднати в один хід агента через `messages.inbound`. Debouncing обмежено каналом + розмовою і використовує найновіше повідомлення для потоків відповідей/ідентифікаторів. -Конфігурація (глобальне типове значення + перевизначення для каналів): +Конфігурація (глобальний типовий параметр + перевизначення для каналів): ```json5 { @@ -61,120 +61,120 @@ Inbound message Примітки: -- Дебаунс застосовується до **лише текстових** повідомлень; медіа/вкладення скидають буфер негайно. -- Команди керування обходять дебаунс, щоб залишатися окремими, **крім** випадків, коли канал явно вмикає об’єднання DM від того самого відправника (наприклад, [BlueBubbles `coalesceSameSenderDms`](/uk/channels/bluebubbles#coalescing-split-send-dms-command--url-in-one-composition)), де команди DM очікують у межах вікна дебаунсу, щоб розділене під час надсилання корисне навантаження могло потрапити в той самий хід агента. +- Debounce застосовується до повідомлень **лише з текстом**; медіа/вкладення скидають буфер негайно. +- Керівні команди обходять debouncing, щоб залишатися окремими — **окрім** випадків, коли канал явно вмикає об’єднання DM від того самого відправника (наприклад, [BlueBubbles `coalesceSameSenderDms`](/uk/channels/bluebubbles#coalescing-split-send-dms-command--url-in-one-composition)), де DM-команди чекають у межах debounce-вікна, щоб payload розділеного надсилання міг приєднатися до того самого ходу агента. -## Сеанси та пристрої +## Сесії та пристрої -Сеансами володіє Gateway, а не клієнти. +Сесіями володіє gateway, а не клієнти. -- Прямі чати згортаються в основний ключ сеансу агента. -- Групи/канали отримують власні ключі сеансів. -- Сховище сеансів і транскрипти розміщуються на хості Gateway. +- Прямі чати згортаються в основний ключ сесії агента. +- Групи/канали отримують власні ключі сесій. +- Сховище сесій і транскрипти зберігаються на хості gateway. -Кілька пристроїв/каналів можуть зіставлятися з тим самим сеансом, але історія не повністю синхронізується назад до кожного клієнта. Рекомендація: використовуйте один основний пристрій для довгих розмов, щоб уникнути розходження контексту. Control UI і TUI завжди показують транскрипт сеансу, підкріплений Gateway, тому вони є джерелом істини. +Кілька пристроїв/каналів можуть відповідати тій самій сесії, але історія не повністю синхронізується назад до кожного клієнта. Рекомендація: використовуйте один основний пристрій для довгих розмов, щоб уникнути розходження контексту. Control UI і TUI завжди показують транскрипт сесії, підтриманий gateway, тому вони є джерелом істини. -Докладніше: [Керування сеансами](/uk/concepts/session). +Докладніше: [Керування сесіями](/uk/concepts/session). -## Метадані результату інструмента +## Метадані результатів інструментів -`content` результату інструмента — це видимий для моделі результат. `details` результату інструмента — це метадані виконання для рендерингу UI, діагностики, доставки медіа та plugins. +`content` результату інструмента — це результат, видимий моделі. `details` результату інструмента — це runtime-метадані для відображення UI, діагностики, доставки медіа та plugins. OpenClaw зберігає цю межу явною: -- `toolResult.details` вилучається перед повторним відтворенням у провайдера та вхідними даними Compaction. -- Збережені транскрипти сеансів містять лише обмежені `details`; завеликі метадані замінюються компактним підсумком із позначкою `persistedDetailsTruncated: true`. +- `toolResult.details` вилучається перед повторним відтворенням у провайдера та введенням для compaction. +- Збережені транскрипти сесій залишають лише обмежені `details`; завеликі метадані замінюються компактним підсумком із позначкою `persistedDetailsTruncated: true`. - Plugins та інструменти мають розміщувати текст, який модель повинна прочитати, у `content`, а не лише в `details`. ## Тіла вхідних повідомлень і контекст історії -OpenClaw розділяє **тіло запиту** та **тіло команди**: +OpenClaw відокремлює **тіло prompt** від **тіла команди**: -- `BodyForAgent`: основний видимий для моделі текст поточного повідомлення. Plugins каналів мають тримати його зосередженим на поточному тексті відправника, що містить запит. -- `Body`: застарілий резервний варіант запиту. Він може містити оболонки каналу й необов’язкові обгортки історії, але поточні канали не повинні покладатися на нього як на основні вхідні дані моделі, коли доступний `BodyForAgent`. -- `CommandBody`: необроблений текст користувача для розбору директив/команд. -- `RawBody`: застарілий псевдонім для `CommandBody` (збережено для сумісності). +- `BodyForAgent`: основний текст для моделі для поточного повідомлення. Channel plugins мають тримати його зосередженим на поточному тексті відправника, який містить prompt. +- `Body`: застарілий резервний prompt. Він може містити оболонки каналу та необов’язкові обгортки історії, але поточні канали не мають покладатися на нього як на основне введення моделі, коли доступний `BodyForAgent`. +- `CommandBody`: сирий текст користувача для розбору директив/команд. +- `RawBody`: застарілий псевдонім для `CommandBody` (залишено для сумісності). Коли канал надає історію, він використовує спільну обгортку: -- `[Повідомлення чату з часу вашої останньої відповіді — для контексту]` -- `[Поточне повідомлення — відповідайте на нього]` +- `[Chat messages since your last reply - for context]` +- `[Current message - respond to this]` -Для **непрямих чатів** (груп/каналів/кімнат) **тіло поточного повідомлення** має префікс із міткою відправника (той самий стиль, що використовується для записів історії). Це зберігає узгодженість повідомлень у реальному часі та повідомлень із черги/історії в запиті агента. +Для **непрямих чатів** (груп/каналів/кімнат) **тіло поточного повідомлення** має префікс із міткою відправника (той самий стиль, що використовується для записів історії). Це зберігає узгодженість повідомлень реального часу та повідомлень із черги/історії в prompt агента. -Буфери історії є **лише очікуваними**: вони містять групові повідомлення, які _не_ запустили виконання (наприклад, повідомлення, обмежені згадками), і **виключають** повідомлення, які вже є в транскрипті сеансу. +Буфери історії є **лише pending-only**: вони включають групові повідомлення, які _не_ запустили run (наприклад, повідомлення, обмежені згадкою), і **виключають** повідомлення, які вже є в транскрипті сесії. -Вилучення директив застосовується лише до розділу **поточного повідомлення**, тому історія залишається неушкодженою. Канали, які обгортають історію, мають установлювати `CommandBody` (або `RawBody`) в оригінальний текст повідомлення та тримати `Body` як об’єднаний запит. Структурована історія, відповіді, переслані повідомлення та метадані каналу рендеряться як недовірені контекстні блоки з роллю користувача під час складання запиту. -Буфери історії налаштовуються через `messages.groupChat.historyLimit` (глобальне типове значення) і перевизначення для окремих каналів, як-от `channels.slack.historyLimit` або `channels.telegram.accounts..historyLimit` (установіть `0`, щоб вимкнути). +Вилучення директив застосовується лише до секції **поточного повідомлення**, щоб історія залишалася неушкодженою. Канали, які обгортають історію, мають встановлювати `CommandBody` (або `RawBody`) як оригінальний текст повідомлення і залишати `Body` як об’єднаний prompt. Структурована історія, відповідь, переслані повідомлення та метадані каналу відображаються як недовірені контекстні блоки з роллю користувача під час складання prompt. +Буфери історії налаштовуються через `messages.groupChat.historyLimit` (глобальний типовий параметр) і перевизначення для каналів, як-от `channels.slack.historyLimit` або `channels.telegram.accounts..historyLimit` (встановіть `0`, щоб вимкнути). -## Черги та подальші дії +## Постановка в чергу та followups -Якщо запуск уже активний, вхідні повідомлення можна поставити в чергу, спрямувати в поточний запуск або зібрати для наступного ходу. +Якщо run уже активний, вхідні повідомлення можна поставити в чергу, спрямувати в поточний run або зібрати для наступного ходу. -- Налаштовуйте через `messages.queue` (і `messages.queue.byChannel`). -- Типовий режим — `steer`, із дебаунсом подальшої дії 500 мс, коли спрямування відступає до доставки подальшої дії через чергу. -- Режими: `steer`, `followup`, `collect`, `steer-backlog`, `interrupt` і застарілий режим `queue` по одному елементу за раз. +- Налаштовується через `messages.queue` (і `messages.queue.byChannel`). +- Типовий режим — `steer`, із 500 мс followup debounce, коли steering повертається до доставки queued followup. +- Режими: `steer`, `followup`, `collect`, `steer-backlog`, `interrupt` і застарілий режим по одному `queue`. -Докладніше: [Черга команд](/uk/concepts/queue) і [Черга спрямування](/uk/concepts/queue-steering). +Докладніше: [Черга команд](/uk/concepts/queue) і [Steering-черга](/uk/concepts/queue-steering). ## Володіння запуском каналу -Plugins каналів можуть зберігати порядок, застосовувати дебаунс до введення та транспортний зворотний тиск до того, як повідомлення потрапить у чергу сеансу. Вони не повинні накладати окремий тайм-аут навколо самого ходу агента. Щойно повідомлення спрямовано до сеансу, довготривала робота керується життєвим циклом сеансу, інструмента та виконання, щоб усі канали послідовно повідомляли про повільні ходи й відновлювалися після них. +Channel plugins можуть зберігати порядок, виконувати debounce введення та застосовувати transport backpressure до того, як повідомлення потрапить у чергу сесії. Вони не мають накладати окремий timeout навколо самого ходу агента. Щойно повідомлення спрямовано до сесії, довготривала робота керується життєвим циклом сесії, інструмента та runtime, щоб усі канали однаково повідомляли про повільні ходи й відновлювалися після них. -## Потокове передавання, розбиття на фрагменти та пакетування +## Streaming, chunking і batching -Блокове потокове передавання надсилає часткові відповіді, коли модель створює текстові блоки. -Розбиття на фрагменти враховує текстові обмеження каналу та уникає розриву огородженого коду. +Block streaming надсилає часткові відповіді, коли модель створює текстові блоки. +Chunking дотримується текстових лімітів каналу й уникає розбиття fenced code. Ключові налаштування: -- `agents.defaults.blockStreamingDefault` (`on|off`, типово вимкнено) +- `agents.defaults.blockStreamingDefault` (`on|off`, типово off) - `agents.defaults.blockStreamingBreak` (`text_end|message_end`) - `agents.defaults.blockStreamingChunk` (`minChars|maxChars|breakPreference`) -- `agents.defaults.blockStreamingCoalesce` (пакетування на основі простою) -- `agents.defaults.humanDelay` (людиноподібна пауза між блоками відповідей) -- Перевизначення каналів: `*.blockStreaming` і `*.blockStreamingCoalesce` (канали, крім Telegram, потребують явного `*.blockStreaming: true`) +- `agents.defaults.blockStreamingCoalesce` (idle-based batching) +- `agents.defaults.humanDelay` (пауза, схожа на людську, між block-відповідями) +- Перевизначення каналів: `*.blockStreaming` і `*.blockStreamingCoalesce` (канали, що не є Telegram, потребують явного `*.blockStreaming: true`) -Докладніше: [Потокове передавання + розбиття на фрагменти](/uk/concepts/streaming). +Докладніше: [Streaming + chunking](/uk/concepts/streaming). -## Видимість міркувань і токени +## Видимість міркування та токени OpenClaw може показувати або приховувати міркування моделі: - `/reasoning on|off|stream` керує видимістю. -- Вміст міркувань усе одно враховується у використанні токенів, коли його створює модель. -- Telegram підтримує потік міркувань у бульбашку чернетки. +- Вміст міркування все одно враховується у використанні токенів, коли його створює модель. +- Telegram підтримує reasoning stream у тимчасову draft-бульбашку, яку видаляють після фінальної доставки; використовуйте `/reasoning on` для постійного виводу міркування. -Докладніше: [Директиви мислення + міркувань](/uk/tools/thinking) і [Використання токенів](/uk/reference/token-use). +Докладніше: [Директиви мислення + міркування](/uk/tools/thinking) і [Використання токенів](/uk/reference/token-use). -## Префікси, гілки та відповіді +## Префікси, threading і відповіді Форматування вихідних повідомлень централізовано в `messages`: - `messages.responsePrefix`, `channels..responsePrefix` і `channels..accounts..responsePrefix` (каскад вихідних префіксів), плюс `channels.whatsapp.messagePrefix` (вхідний префікс WhatsApp) -- Прив’язка відповідей до гілки через `replyToMode` і типові значення для окремих каналів +- Threading відповідей через `replyToMode` і типові параметри для каналів Докладніше: [Конфігурація](/uk/gateway/config-agents#messages) і документація каналів. ## Тихі відповіді -Точний тихий токен `NO_REPLY` / `no_reply` означає “не доставляти видиму для користувача відповідь”. -Коли хід також має очікувані медіа інструментів, наприклад згенероване TTS-аудіо, OpenClaw вилучає тихий текст, але все одно доставляє медіавкладення. +Точний silent token `NO_REPLY` / `no_reply` означає «не доставляти відповідь, видиму користувачу». +Коли хід також має pending tool media, як-от згенероване TTS-аудіо, OpenClaw вилучає silent-текст, але все одно доставляє медіавкладення. OpenClaw визначає цю поведінку за типом розмови: -- Прямі розмови типово забороняють мовчання та переписують голу тиху відповідь у короткий видимий резервний варіант. -- Групи/канали типово дозволяють мовчання. -- Внутрішня оркестрація типово дозволяє мовчання. +- Прямі розмови типово забороняють тишу й переписують голу silent-відповідь у короткий видимий fallback. +- Групи/канали типово дозволяють тишу. +- Внутрішня оркестрація типово дозволяє тишу. -OpenClaw також використовує тихі відповіді для внутрішніх помилок запуску, які трапляються до будь-якої відповіді асистента в непрямих чатах, щоб групи/канали не бачили шаблонного тексту помилки Gateway. Прямі чати типово показують стислий текст помилки; необроблені деталі запуску показуються лише тоді, коли `/verbose` має значення `on` або `full`. +OpenClaw також використовує silent-відповіді для внутрішніх збоїв runner, які трапляються до будь-якої відповіді assistant у непрямих чатах, щоб групи/канали не бачили шаблонний текст помилки gateway. Прямі чати типово показують компактний текст збою; сирі деталі runner показуються лише коли `/verbose` має значення `on` або `full`. -Типові значення містяться в `agents.defaults.silentReply` і `agents.defaults.silentReplyRewrite`; `surfaces..silentReply` і `surfaces..silentReplyRewrite` можуть перевизначати їх для кожної поверхні. +Типові параметри містяться в `agents.defaults.silentReply` і `agents.defaults.silentReplyRewrite`; `surfaces..silentReply` і `surfaces..silentReplyRewrite` можуть перевизначати їх для кожної surface. -Коли батьківський сеанс має один або кілька очікуваних породжених запусків підагента, голі тихі відповіді відкидаються на всіх поверхнях замість переписування, тому батьківський сеанс лишається тихим, доки подія завершення дочірнього запуску не доставить справжню відповідь. +Коли батьківська сесія має один або більше pending spawned subagent runs, голі silent-відповіді відкидаються на всіх surfaces замість переписування, тому батьківська сесія мовчить, доки подія завершення дочірнього агента не доставить справжню відповідь. ## Пов’язане -- [Потокове передавання](/uk/concepts/streaming) — доставка повідомлень у реальному часі -- [Повторна спроба](/uk/concepts/retry) — поведінка повторної спроби доставки повідомлення +- [Streaming](/uk/concepts/streaming) — доставка повідомлень у реальному часі +- [Повторна спроба](/uk/concepts/retry) — поведінка повторної спроби доставки повідомлень - [Черга](/uk/concepts/queue) — черга обробки повідомлень -- [Канали](/uk/channels) — інтеграції з платформами обміну повідомленнями +- [Канали](/uk/channels) — інтеграції платформ обміну повідомленнями diff --git a/docs/uk/concepts/streaming.md b/docs/uk/concepts/streaming.md index 298e19e36..096e20cbf 100644 --- a/docs/uk/concepts/streaming.md +++ b/docs/uk/concepts/streaming.md @@ -1,29 +1,29 @@ --- read_when: - - Пояснення роботи потокової передачі або розбиття на фрагменти в каналах - - Зміна поведінки блокового потокового передавання або фрагментації каналів - - Налагодження дубльованих/передчасних блокових відповідей або потокового попереднього перегляду каналу -summary: Поведінка потокового передавання + поділу на фрагменти (блокові відповіді, потокове передавання попереднього перегляду каналу, зіставлення режимів) -title: Потокове передавання та поділ на фрагменти + - Пояснення, як у каналах працює потокове передавання або розбиття на фрагменти + - Зміна поведінки потокового передавання блоків або фрагментації каналу + - Налагодження дубльованих або передчасних відповідей блоками чи потокового передавання попереднього перегляду каналу +summary: Поведінка потокового передавання + фрагментації (блокові відповіді, потокове передавання попереднього перегляду каналу, зіставлення режимів) +title: Потокове передавання та розбиття на фрагменти x-i18n: - generated_at: "2026-05-03T21:05:45Z" + generated_at: "2026-05-04T06:12:39Z" model: gpt-5.5 provider: openai - source_hash: 1335f4f5532060bd8bf839683a2b1fbab38f38887c5583135652b4753e0f6a50 + source_hash: fcb41ceb5602ab42c3fd41a59de62cc965ea61fdbc058c052fb93689a9c5299b source_path: concepts/streaming.md workflow: 16 --- -OpenClaw має два окремі шари потокового передавання: +OpenClaw має два окремі рівні потокового передавання: -- **Потокове передавання блоків (канали):** надсилає завершені **блоки** під час написання відповіді асистентом. Це звичайні повідомлення каналу (не дельти токенів). -- **Потокове передавання попереднього перегляду (Telegram/Discord/Slack):** оновлює тимчасове **повідомлення попереднього перегляду** під час генерації. +- **Блокове потокове передавання (канали):** надсилання завершених **блоків** під час написання відповіді асистентом. Це звичайні повідомлення каналу (не дельти токенів). +- **Потокове передавання попереднього перегляду (Telegram/Discord/Slack):** оновлення тимчасового **повідомлення попереднього перегляду** під час генерації. -Сьогодні **справжнього потокового передавання дельт токенів** у повідомлення каналів немає. Потокове передавання попереднього перегляду працює на основі повідомлень (надсилання + редагування/додавання). +Наразі **справжнього потокового передавання дельт токенів** у повідомлення каналу немає. Потокове передавання попереднього перегляду базується на повідомленнях (надсилання + редагування/додавання). -## Потокове передавання блоків (повідомлення каналу) +## Блокове потокове передавання (повідомлення каналу) -Потокове передавання блоків надсилає вивід асистента грубими фрагментами в міру його появи. +Блокове потокове передавання надсилає відповідь асистента великими фрагментами, щойно вони стають доступними. ``` Model output @@ -35,79 +35,85 @@ Model output └─ channel send (block replies) ``` -Позначення: +Легенда: -- `text_delta/events`: події потоку моделі (можуть бути розрідженими для моделей без потокового передавання). -- `chunker`: `EmbeddedBlockChunker`, що застосовує мінімальні/максимальні межі + бажану точку розбиття. +- `text_delta/events`: потокові події моделі (можуть бути рідкісними для непотокових моделей). +- `chunker`: `EmbeddedBlockChunker`, що застосовує мінімальні/максимальні межі + бажаний тип розриву. - `channel send`: фактичні вихідні повідомлення (блокові відповіді). **Елементи керування:** -- `agents.defaults.blockStreamingDefault`: `"on"`/`"off"` (типово вимкнено). +- `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. +- Режим фрагментації каналу: `*.chunkMode` (`length` за замовчуванням, `newline` розбиває за порожніми рядками (межами абзаців) перед фрагментацією за довжиною). +- М’яке обмеження Discord: `channels.discord.maxLinesPerMessage` (за замовчуванням 17) розбиває високі відповіді, щоб уникнути обрізання в UI. **Семантика меж:** -- `text_end`: передає блоки потоком щойно `chunker` їх видає; скидає буфер на кожному `text_end`. -- `message_end`: чекає завершення повідомлення асистента, потім скидає буферизований вивід. +- `text_end`: передавати блоки потоком, щойно `chunker` їх випускає; скидати буфер на кожному `text_end`. +- `message_end`: чекати завершення повідомлення асистента, потім скидати буферизований вивід. -`message_end` все одно використовує `chunker`, якщо буферизований текст перевищує `maxChars`, тому наприкінці може видати кілька фрагментів. +`message_end` усе одно використовує `chunker`, якщо буферизований текст перевищує `maxChars`, тому наприкінці може бути випущено кілька фрагментів. -### Доставлення медіа з потоковим передаванням блоків +### Доставка медіа з блоковим потоковим передаванням -Директиви `MEDIA:` є звичайними метаданими доставлення. Коли потокове передавання блоків рано надсилає медіаблок, OpenClaw запам’ятовує це доставлення для поточного ходу. Якщо фінальне корисне навантаження асистента повторює той самий URL медіа, фінальне доставлення вилучає дубльоване медіа замість повторного надсилання вкладення. +Директиви `MEDIA:` є звичайними метаданими доставки. Коли блокове потокове передавання рано надсилає медіаблок, OpenClaw запам’ятовує цю доставку для поточного ходу. Якщо фінальне навантаження асистента повторює той самий URL медіа, фінальна доставка прибирає дубльоване медіа замість повторного надсилання вкладення. -Точні дублікати фінальних корисних навантажень пригнічуються. Якщо фінальне корисне навантаження додає окремий текст навколо медіа, яке вже було передано потоком, OpenClaw все одно надсилає новий текст, зберігаючи медіа як одноразове доставлення. Це запобігає дублюванню голосових нотаток або файлів у таких каналах, як Telegram, коли агент видає `MEDIA:` під час потокового передавання, а провайдер також включає його в завершену відповідь. +Точні дублікати фінальних навантажень пригнічуються. Якщо фінальне навантаження додає окремий текст навколо медіа, яке вже було передано потоком, OpenClaw усе одно надсилає новий текст, зберігаючи одноразову доставку медіа. Це запобігає дублюванню голосових нотаток або файлів у каналах на кшталт Telegram, коли агент випускає `MEDIA:` під час потокового передавання, а провайдер також включає його в завершену відповідь. ## Алгоритм фрагментації (нижня/верхня межі) -Фрагментація блоків реалізована в `EmbeddedBlockChunker`: +Блокову фрагментацію реалізує `EmbeddedBlockChunker`: -- **Нижня межа:** не видавати, доки буфер >= `minChars` (якщо не примусово). -- **Верхня межа:** надавати перевагу розбиттю до `maxChars`; якщо примусово, розбивати на `maxChars`. -- **Бажана точка розбиття:** `paragraph` → `newline` → `sentence` → `whitespace` → жорсткий розрив. -- **Кодові блоки:** ніколи не розбивати всередині блоків; під час примусового розбиття на `maxChars` закрити + знову відкрити блок, щоб Markdown залишався коректним. +- **Нижня межа:** не випускати, доки буфер >= `minChars` (якщо не примусово). +- **Верхня межа:** віддавати перевагу розбиттю перед `maxChars`; якщо примусово, розбивати на `maxChars`. +- **Бажаний тип розриву:** `paragraph` → `newline` → `sentence` → `whitespace` → жорсткий розрив. +- **Кодові блоки:** ніколи не розбивати всередині блоків; під час примусового розбиття на `maxChars` закривати + повторно відкривати блок, щоб Markdown лишався коректним. -`maxChars` обмежується до `textChunkLimit` каналу, тому перевищити обмеження конкретного каналу неможливо. +`maxChars` обмежується значенням `textChunkLimit` каналу, тому перевищити обмеження конкретного каналу неможливо. -## Коалесценція (об’єднання потокових блоків) +## Об’єднання (злиття потокових блоків) -Коли потокове передавання блоків увімкнено, OpenClaw може **об’єднувати послідовні блокові фрагменти** перед їхнім надсиланням. Це зменшує «спам одним рядком», водночас забезпечуючи поступовий вивід. +Коли блокове потокове передавання ввімкнено, OpenClaw може **об’єднувати послідовні блокові фрагменти** +перед їх надсиланням. Це зменшує «спам одним рядком», але все ще забезпечує +поступовий вивід. -- Коалесценція чекає на **паузи бездіяльності** (`idleMs`) перед скиданням. -- Буфери обмежуються `maxChars` і будуть скинуті, якщо перевищать його. -- `minChars` запобігає надсиланню крихітних фрагментів, доки не накопичиться достатньо тексту (фінальне скидання завжди надсилає залишковий текст). -- З’єднувач визначається з `blockStreamingChunk.breakPreference` (`paragraph` → `\n\n`, `newline` → `\n`, `sentence` → пробіл). +- Об’єднання чекає на **паузи простою** (`idleMs`) перед скиданням. +- Буфери обмежуються `maxChars` і скидаються, якщо перевищують це значення. +- `minChars` не дає надсилати крихітні фрагменти, доки не накопичиться достатньо тексту + (фінальне скидання завжди надсилає залишковий текст). +- Розділювач виводиться з `blockStreamingChunk.breakPreference` + (`paragraph` → `\n\n`, `newline` → `\n`, `sentence` → пробіл). - Перевизначення каналів доступні через `*.blockStreamingCoalesce` (включно з конфігураціями для окремих облікових записів). -- Типове `minChars` для коалесценції підвищено до 1500 для Signal/Slack/Discord, якщо не перевизначено. +- Стандартне значення `minChars` для об’єднання підвищується до 1500 для Signal/Slack/Discord, якщо його не перевизначено. ## Людиноподібний темп між блоками -Коли потокове передавання блоків увімкнено, можна додати **рандомізовану паузу** між блоковими відповідями (після першого блока). Це робить відповіді з кількох бульбашок природнішими. +Коли блокове потокове передавання ввімкнено, можна додати **рандомізовану паузу** між +блоковими відповідями (після першого блоку). Це робить відповіді з кількох бульбашок +природнішими. -- Конфігурація: `agents.defaults.humanDelay` (перевизначається для кожного агента через `agents.list[].humanDelay`). -- Режими: `off` (типово), `natural` (800–2500 мс), `custom` (`minMs`/`maxMs`). -- Застосовується лише до **блокових відповідей**, не до фінальних відповідей чи підсумків інструментів. +- Конфігурація: `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"` (лише фінальна відповідь). +- **Передавати фрагменти потоком:** `blockStreamingDefault: "on"` + `blockStreamingBreak: "text_end"` (випускати поступово). Канали не-Telegram також потребують `*.blockStreaming: true`. +- **Передавати все потоком наприкінці:** `blockStreamingBreak: "message_end"` (скинути один раз, можливо кількома фрагментами, якщо дуже довго). +- **Без блокового потокового передавання:** `blockStreamingDefault: "off"` (лише фінальна відповідь). -**Примітка щодо каналів:** Потокове передавання блоків **вимкнено, якщо** +**Примітка щодо каналів:** Блокове потокове передавання **вимкнене, якщо** `*.blockStreaming` явно не встановлено в `true`. Канали можуть передавати живий попередній перегляд (`channels..streaming`) без блокових відповідей. -Нагадування про розташування конфігурації: типові значення `blockStreaming*` містяться в +Нагадування про розташування конфігурації: стандартні значення `blockStreaming*` містяться в `agents.defaults`, а не в кореневій конфігурації. ## Режими потокового передавання попереднього перегляду @@ -119,28 +125,33 @@ Model output - `off`: вимкнути потокове передавання попереднього перегляду. - `partial`: один попередній перегляд, який замінюється найновішим текстом. - `block`: попередній перегляд оновлюється фрагментованими/доданими кроками. -- `progress`: попередній перегляд прогресу/стану під час генерації, фінальна відповідь після завершення. +- `progress`: попередній перегляд прогресу/статусу під час генерації, фінальна відповідь після завершення. -`streaming.mode: "block"` — це режим потокового передавання попереднього перегляду для каналів із можливістю редагування, таких як Discord і Telegram. Він не вмикає доставлення блоків у каналі там. Використовуйте `streaming.block.enabled` або застарілий ключ каналу `blockStreaming`, коли потрібні звичайні блокові відповіді. Microsoft Teams є винятком: у нього немає транспорту блоків чорнового попереднього перегляду, тому `streaming.mode: "block"` відображається на блокове доставлення Teams замість нативного часткового/прогресивного потокового передавання. +`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 | ✅ | ✅ | ✅ | нативний потік прогресу | +| Канал | `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 і редагування. +- `channels.slack.streaming.nativeTransport` перемикає виклики нативного API потокового передавання Slack, коли `channels.slack.streaming.mode="partial"` (за замовчуванням: `true`). +- Нативне потокове передавання Slack і статус гілки асистента Slack потребують цільової гілки відповіді. DM верхнього рівня не показують такий попередній перегляд у стилі гілки, але все одно можуть використовувати дописи чернеток попереднього перегляду Slack і редагування. Міграція застарілих ключів: -- Telegram: застарілий `streamMode` і скалярні/булеві значення `streaming` виявляються й мігруються шляхами doctor/сумісності конфігурації до `streaming.mode`. +- Telegram: застарілі значення `streamMode` і скалярні/булеві значення `streaming` виявляються та мігруються шляхами сумісності doctor/config до `streaming.mode`. - Discord: `streamMode` + булевий `streaming` автоматично мігрують до enum `streaming`. - Slack: `streamMode` автоматично мігрує до `streaming.mode`; булевий `streaming` автоматично мігрує до `streaming.mode` плюс `streaming.nativeTransport`; застарілий `nativeStreaming` автоматично мігрує до `streaming.nativeTransport`. @@ -148,50 +159,50 @@ Model output Telegram: -- Використовує `sendMessage` + `editMessageText` для оновлень попереднього перегляду в DM і групах/темах. -- Надсилає нове фінальне повідомлення замість редагування на місці, коли попередній перегляд був видимий приблизно одну хвилину, а потім очищає попередній перегляд, щоб позначка часу Telegram відображала завершення відповіді. -- Потокове передавання попереднього перегляду пропускається, коли потокове передавання блоків Telegram явно ввімкнено (щоб уникнути подвійного потокового передавання). -- `/reasoning stream` може записувати міркування в попередній перегляд. +- Використовує `sendMessage` + `editMessageText` для оновлень попереднього перегляду в DM, групах і темах. +- Надсилає нове фінальне повідомлення замість редагування на місці, коли попередній перегляд був видимий приблизно одну хвилину, а потім прибирає попередній перегляд, щоб мітка часу Telegram відображала завершення відповіді. +- Потокове передавання попереднього перегляду пропускається, коли блокове потокове передавання Telegram явно ввімкнене (щоб уникнути подвійного потокового передавання). +- `/reasoning stream` може записувати міркування в тимчасовий попередній перегляд, який видаляється після фінальної доставки. Discord: - Використовує надсилання + редагування повідомлень попереднього перегляду. -- Режим `block` використовує чернеткову фрагментацію (`draftChunk`). -- Потокове передавання попереднього перегляду пропускається, коли потокове передавання блоків Discord явно ввімкнено. -- Фінальні медіа, помилки й корисні навантаження явної відповіді скасовують очікувані попередні перегляди без скидання нового чернеткового повідомлення, а потім використовують звичайне доставлення. +- Режим `block` використовує фрагментацію чернетки (`draftChunk`). +- Потокове передавання попереднього перегляду пропускається, коли блокове потокове передавання Discord явно ввімкнене. +- Фінальні медіа, помилки й навантаження явних відповідей скасовують очікувані попередні перегляди без скидання нової чернетки, а потім використовують звичайну доставку. Slack: -- `partial` може використовувати нативне потокове передавання Slack (`chat.startStream`/`append`/`stop`), коли доступно. -- `block` використовує чернеткові попередні перегляди в стилі додавання. -- `progress` використовує текст попереднього перегляду стану, а потім фінальну відповідь. -- DM верхнього рівня без потоку відповіді використовують чернеткові дописи попереднього перегляду та редагування замість нативного потокового передавання Slack. -- Нативне й чернеткове потокове передавання попереднього перегляду пригнічує блокові відповіді для цього ходу, тому відповідь Slack передається потоком лише одним шляхом доставлення. -- Фінальні корисні навантаження медіа/помилок і фінали прогресу не створюють одноразові чернеткові повідомлення; лише текстові/блокові фінали, які можуть редагувати попередній перегляд, скидають очікуваний чернетковий текст. +- `partial` може використовувати нативне потокове передавання Slack (`chat.startStream`/`append`/`stop`), коли воно доступне. +- `block` використовує чернетки попереднього перегляду в стилі додавання. +- `progress` використовує текст попереднього перегляду статусу, а потім фінальну відповідь. +- DM верхнього рівня без гілки відповіді використовують дописи чернеток попереднього перегляду та редагування замість нативного потокового передавання Slack. +- Нативне й чернеткове потокове передавання попереднього перегляду пригнічує блокові відповіді для цього ходу, тому відповідь Slack передається лише одним шляхом доставки. +- Фінальні навантаження медіа/помилок і фінали прогресу не створюють одноразових чернеток повідомлень; лише текстові/блокові фінали, які можуть редагувати попередній перегляд, скидають очікуваний текст чернетки. Mattermost: -- Передає мислення, активність інструментів і частковий текст відповіді в один чернетковий допис попереднього перегляду, який фіналізується на місці, коли фінальну відповідь безпечно надсилати. +- Передає думки, активність інструментів і частковий текст відповіді в один допис чернетки попереднього перегляду, який фіналізується на місці, коли фінальну відповідь безпечно надіслати. - Повертається до надсилання нового фінального допису, якщо допис попереднього перегляду було видалено або він інакше недоступний під час фіналізації. -- Фінальні корисні навантаження медіа/помилок скасовують очікувані оновлення попереднього перегляду перед звичайним доставленням замість скидання тимчасового допису попереднього перегляду. +- Фінальні навантаження медіа/помилок скасовують очікувані оновлення попереднього перегляду перед звичайною доставкою замість скидання тимчасового допису попереднього перегляду. Matrix: -- Чернеткові попередні перегляди фіналізуються на місці, коли фінальний текст може повторно використати подію попереднього перегляду. -- Фінали лише з медіа, помилками й невідповідністю цілі відповіді скасовують очікувані оновлення попереднього перегляду перед звичайним доставленням; уже видимий застарілий попередній перегляд редагується. +- Чернетки попереднього перегляду фіналізуються на місці, коли фінальний текст може повторно використати подію попереднього перегляду. +- Фінали лише з медіа, помилками та невідповідністю цілі відповіді скасовують очікувані оновлення попереднього перегляду перед звичайною доставкою; уже видимий застарілий попередній перегляд редагується. ### Оновлення попереднього перегляду прогресу інструментів -Потокове передавання попереднього перегляду також може містити оновлення **прогресу інструментів** — короткі рядки стану на кшталт "пошук в інтернеті", "читання файлу" або "виклик інструмента", — які з’являються в тому самому повідомленні попереднього перегляду, поки інструменти працюють, до фінальної відповіді. Це зберігає багатокрокові ходи з інструментами візуально активними, а не мовчазними між першим попереднім переглядом мислення та фінальною відповіддю. +Потокове передавання попереднього перегляду також може включати оновлення **прогресу інструментів** — короткі рядки статусу на кшталт "пошук в інтернеті", "читання файлу" або "виклик інструмента", — які з’являються в тому самому повідомленні попереднього перегляду, поки інструменти працюють, перед фінальною відповіддю. Це робить багатоетапні ходи з інструментами візуально активними, а не тихими між першим попереднім переглядом думок і фінальною відповіддю. Підтримувані поверхні: -- **Discord**, **Slack**, **Telegram** і **Matrix** типово передають прогрес інструментів у редагування живого попереднього перегляду, коли потокове передавання попереднього перегляду активне. Microsoft Teams використовує свій нативний потік прогресу в особистих чатах. +- **Discord**, **Slack**, **Telegram** і **Matrix** за замовчуванням передають прогрес інструментів у редагування живого попереднього перегляду, коли потокове передавання попереднього перегляду активне. Microsoft Teams використовує свій нативний потік прогресу в особистих чатах. - Telegram постачається з увімкненими оновленнями попереднього перегляду прогресу інструментів із `v2026.4.22`; збереження їх увімкненими підтримує цю випущену поведінку. -- **Mattermost** уже включає активність інструментів у свій єдиний чернетковий допис попереднього перегляду (див. вище). -- Редагування прогресу інструментів дотримуються активного режиму потокового передавання попереднього перегляду; вони пропускаються, коли потокове передавання попереднього перегляду `off` або коли потокове передавання блоків узяло повідомлення на себе. У Telegram `streaming.mode: "off"` означає лише фінал: загальні повідомлення про прогрес також пригнічуються замість доставлення як окремі повідомлення стану, тоді як запити на схвалення, медіакорисні навантаження й помилки все одно маршрутизуються звичайно. -- Щоб зберегти потокове передавання попереднього перегляду, але приховати рядки прогресу інструментів, встановіть `streaming.preview.toolProgress` у `false` для цього каналу. Щоб повністю вимкнути редагування попереднього перегляду, встановіть `streaming.mode` у `off`. -- Вибрані цитовані відповіді Telegram є винятком: коли `replyToMode` не `"off"` і присутній вибраний текст цитати, OpenClaw пропускає потік попереднього перегляду відповіді для цього ходу, тому рядки попереднього перегляду прогресу інструментів не можуть відобразитися. Відповіді на поточне повідомлення без вибраного тексту цитати все одно зберігають потокове передавання попереднього перегляду. Докладніше див. у [документації каналу Telegram](/uk/channels/telegram). +- **Mattermost** уже вкладає активність інструментів у свій єдиний допис чернетки попереднього перегляду (див. вище). +- Редагування прогресу інструментів дотримуються активного режиму потокового передавання попереднього перегляду; вони пропускаються, коли потокове передавання попереднього перегляду має значення `off` або коли блокове потокове передавання перебрало повідомлення. У Telegram `streaming.mode: "off"` означає лише фінал: загальні повідомлення про прогрес також пригнічуються замість доставки як окремі статусні повідомлення, тоді як запити на схвалення, медіанавантаження й помилки все одно маршрутизуються звичайно. +- Щоб зберегти потокове передавання попереднього перегляду, але приховати рядки прогресу інструментів, установіть `streaming.preview.toolProgress` у `false` для цього каналу. Щоб повністю вимкнути редагування попереднього перегляду, установіть `streaming.mode` у `off`. +- Відповіді Telegram із вибраною цитатою є винятком: коли `replyToMode` не дорівнює `"off"` і є текст вибраної цитати, OpenClaw пропускає потік попереднього перегляду відповіді для цього ходу, тому рядки попереднього перегляду прогресу інструментів не можуть відобразитися. Відповіді на поточне повідомлення без тексту вибраної цитати все ще зберігають потокове передавання попереднього перегляду. Докладніше див. у [документації каналу Telegram](/uk/channels/telegram). Приклад: @@ -212,7 +223,7 @@ Matrix: ## Пов’язане -- [Чернетки прогресу](/uk/concepts/progress-drafts) — видимі повідомлення про роботу в процесі, що оновлюються під час довгих ходів -- [Повідомлення](/uk/concepts/messages) — життєвий цикл і доставлення повідомлень -- [Повторна спроба](/uk/concepts/retry) — поведінка повторної спроби після помилки доставлення +- [Чернетки прогресу](/uk/concepts/progress-drafts) — видимі повідомлення про поточну роботу, які оновлюються під час тривалих ходів +- [Повідомлення](/uk/concepts/messages) — життєвий цикл повідомлень і доставка +- [Повторна спроба](/uk/concepts/retry) — поведінка повторних спроб у разі збою доставки - [Канали](/uk/channels) — підтримка потокового передавання для кожного каналу