chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
fef87fe905
commit
ddecb2d7be
@ -3,61 +3,61 @@ read_when:
|
||||
- Налаштування контролю доступу до особистих повідомлень
|
||||
- Сполучення нового iOS/Android Node
|
||||
- Огляд стану безпеки OpenClaw
|
||||
summary: 'Огляд сполучення: схвалюйте, хто може надсилати вам особисті повідомлення + які вузли можуть приєднуватися'
|
||||
summary: 'Огляд сполучення: схваліть, хто може писати вам у приватні повідомлення + які вузли можуть приєднуватися'
|
||||
title: Сполучення
|
||||
x-i18n:
|
||||
generated_at: "2026-05-01T23:10:05Z"
|
||||
generated_at: "2026-05-03T23:54:54Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: bb68d87c0e1dfe7c9a6a6d9415f4c63625755fb43a2e22a1d1374ff0a63e49c4
|
||||
source_hash: 4fb27840f7c9ef55e7270cc29f813e6db90b240aa2180f30952eb9485f0f8874
|
||||
source_path: channels/pairing.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
«Сполучення» — це явний крок затвердження доступу в OpenClaw.
|
||||
Воно використовується у двох місцях:
|
||||
«Створення пари» — це явний крок схвалення доступу в OpenClaw.
|
||||
Він використовується у двох місцях:
|
||||
|
||||
1. **Сполучення DM** (кому дозволено говорити з ботом)
|
||||
2. **Сполучення Node** (яким пристроям/вузлам дозволено приєднуватися до мережі Gateway)
|
||||
1. **Створення пари для DM** (кому дозволено спілкуватися з ботом)
|
||||
2. **Створення пари з Node** (яким пристроям/Node дозволено приєднуватися до мережі Gateway)
|
||||
|
||||
Контекст безпеки: [Безпека](/uk/gateway/security)
|
||||
|
||||
## 1) Сполучення DM (вхідний доступ до чату)
|
||||
## 1) Створення пари для DM (вхідний доступ до чату)
|
||||
|
||||
Коли канал налаштовано з політикою DM `pairing`, невідомі відправники отримують короткий код, а їхнє повідомлення **не обробляється**, доки ви його не затвердите.
|
||||
Коли канал налаштовано з політикою DM `pairing`, невідомі відправники отримують короткий код, а їхнє повідомлення **не обробляється**, доки ви не схвалите доступ.
|
||||
|
||||
Типові політики DM задокументовано тут: [Безпека](/uk/gateway/security)
|
||||
Стандартні політики DM задокументовано тут: [Безпека](/uk/gateway/security)
|
||||
|
||||
`dmPolicy: "open"` є публічним лише тоді, коли ефективний список дозволених DM містить `"*"`.
|
||||
Налаштування й перевірка вимагають цей wildcard для публічно відкритих конфігурацій. Якщо наявний
|
||||
стан містить `open` з конкретними записами `allowFrom`, runtime усе одно допускає
|
||||
лише цих відправників, а затвердження у сховищі сполучень не розширюють доступ `open`.
|
||||
`dmPolicy: "open"` є публічною лише тоді, коли ефективний список дозволених DM містить `"*"`.
|
||||
Налаштування й перевірка потребують цього wildcard для публічних відкритих конфігурацій. Якщо наявний
|
||||
стан містить `open` із конкретними записами `allowFrom`, середовище виконання все одно допускає
|
||||
лише цих відправників, а схвалення зі сховища створення пар не розширюють доступ `open`.
|
||||
|
||||
Коди сполучення:
|
||||
Коди створення пари:
|
||||
|
||||
- 8 символів, великі літери, без неоднозначних символів (`0O1I`).
|
||||
- **Спливають через 1 годину**. Бот надсилає повідомлення про сполучення лише тоді, коли створюється новий запит (приблизно раз на годину для кожного відправника).
|
||||
- Очікувані запити сполучення DM типово обмежено **3 на канал**; додаткові запити ігноруються, доки один не спливе або не буде затверджений.
|
||||
- **Спливають через 1 годину**. Бот надсилає повідомлення про створення пари лише тоді, коли створюється новий запит (приблизно раз на годину для кожного відправника).
|
||||
- Очікувані запити на створення пари для DM стандартно обмежено **3 на канал**; додаткові запити ігноруються, доки один із них не спливе або не буде схвалений.
|
||||
|
||||
### Затвердити відправника
|
||||
### Схвалити відправника
|
||||
|
||||
```bash
|
||||
openclaw pairing list telegram
|
||||
openclaw pairing approve telegram <CODE>
|
||||
```
|
||||
|
||||
Якщо власника команд ще не налаштовано, затвердження коду сполучення DM також початково налаштовує
|
||||
`commands.ownerAllowFrom` на затвердженого відправника, наприклад `telegram:123456789`.
|
||||
Це дає першим налаштуванням явного власника для привілейованих команд і запитів
|
||||
затвердження exec. Після появи власника подальші затвердження сполучення надають лише доступ
|
||||
DM; вони не додають більше власників.
|
||||
Якщо власника команд ще не налаштовано, схвалення коду створення пари для DM також ініціалізує
|
||||
`commands.ownerAllowFrom` для схваленого відправника, наприклад `telegram:123456789`.
|
||||
Це дає початковим налаштуванням явного власника для привілейованих команд і запитів
|
||||
схвалення виконання. Після появи власника подальші схвалення створення пари надають лише
|
||||
доступ до DM; вони не додають більше власників.
|
||||
|
||||
Підтримувані канали: `bluebubbles`, `discord`, `feishu`, `googlechat`, `imessage`, `irc`, `line`, `matrix`, `mattermost`, `msteams`, `nextcloud-talk`, `nostr`, `openclaw-weixin`, `signal`, `slack`, `synology-chat`, `telegram`, `twitch`, `whatsapp`, `zalo`, `zalouser`.
|
||||
|
||||
### Багаторазові групи відправників
|
||||
|
||||
Використовуйте верхньорівневі `accessGroups`, коли той самий набір довірених відправників має застосовуватися до
|
||||
кількох каналів повідомлень або і до списків дозволених DM, і до групових списків дозволених.
|
||||
Використовуйте верхньорівневі `accessGroups`, коли один і той самий набір довірених відправників має застосовуватися до
|
||||
кількох каналів повідомлень або до списків дозволених як для DM, так і для груп.
|
||||
|
||||
Статичні групи використовують `type: "message.senders"` і посилаються через
|
||||
`accessGroup:<name>` зі списків дозволених каналу:
|
||||
@ -88,60 +88,60 @@ DM; вони не додають більше власників.
|
||||
Зберігається в `~/.openclaw/credentials/`:
|
||||
|
||||
- Очікувані запити: `<channel>-pairing.json`
|
||||
- Сховище затвердженого списку дозволених:
|
||||
- Типовий обліковий запис: `<channel>-allowFrom.json`
|
||||
- Нетиповий обліковий запис: `<channel>-<accountId>-allowFrom.json`
|
||||
- Схвалене сховище списку дозволених:
|
||||
- Стандартний обліковий запис: `<channel>-allowFrom.json`
|
||||
- Нестандартний обліковий запис: `<channel>-<accountId>-allowFrom.json`
|
||||
|
||||
Поведінка області дії облікового запису:
|
||||
|
||||
- Нетипові облікові записи читають/записують лише свій файл списку дозволених з областю дії.
|
||||
- Типовий обліковий запис використовує каналовий файл списку дозволених без області дії.
|
||||
- Нестандартні облікові записи читають/записують лише свій файл списку дозволених з областю дії.
|
||||
- Стандартний обліковий запис використовує файл списку дозволених каналу без області дії.
|
||||
|
||||
Ставтеся до них як до конфіденційних (вони керують доступом до вашого асистента).
|
||||
Ставтеся до них як до чутливих даних (вони контролюють доступ до вашого асистента).
|
||||
|
||||
<Note>
|
||||
Сховище списку дозволених сполучення призначене для доступу DM. Авторизація груп є окремою.
|
||||
Затвердження коду сполучення DM автоматично не дозволяє цьому відправнику виконувати групові
|
||||
команди або керувати ботом у групах. Початкове налаштування першого власника є окремим станом конфігурації
|
||||
в `commands.ownerAllowFrom`, а доставка групового чату й далі дотримується
|
||||
Сховище списку дозволених для створення пар призначене для доступу до DM. Авторизація груп окрема.
|
||||
Схвалення коду створення пари для DM не дозволяє цьому відправнику автоматично виконувати групові
|
||||
команди або керувати ботом у групах. Початкова ініціалізація першого власника є окремим станом
|
||||
конфігурації в `commands.ownerAllowFrom`, а доставлення групових чатів і далі дотримується
|
||||
групових списків дозволених каналу (наприклад `groupAllowFrom`, `groups` або перевизначень для окремих груп
|
||||
чи тем залежно від каналу).
|
||||
</Note>
|
||||
|
||||
## 2) Сполучення пристрою Node (вузли iOS/Android/macOS/headless)
|
||||
## 2) Створення пари з Node-пристроєм (iOS/Android/macOS/headless Node)
|
||||
|
||||
Вузли підключаються до Gateway як **пристрої** з `role: node`. Gateway
|
||||
створює запит на сполучення пристрою, який потрібно затвердити.
|
||||
Node підключаються до Gateway як **пристрої** з `role: node`. Gateway
|
||||
створює запит на створення пари з пристроєм, який потрібно схвалити.
|
||||
|
||||
### Сполучення через Telegram (рекомендовано для iOS)
|
||||
### Створення пари через Telegram (рекомендовано для iOS)
|
||||
|
||||
Якщо ви використовуєте Plugin `device-pair`, перше сполучення пристрою можна виконати повністю з Telegram:
|
||||
Якщо ви використовуєте Plugin `device-pair`, ви можете виконати перше створення пари з пристроєм повністю з Telegram:
|
||||
|
||||
1. У Telegram напишіть своєму боту: `/pair`
|
||||
2. Бот відповідає двома повідомленнями: повідомленням з інструкціями та окремим повідомленням із **кодом налаштування** (його легко скопіювати/вставити в Telegram).
|
||||
1. У Telegram надішліть повідомлення своєму боту: `/pair`
|
||||
2. Бот відповість двома повідомленнями: повідомленням з інструкцією та окремим повідомленням із **кодом налаштування** (його легко копіювати/вставляти в Telegram).
|
||||
3. На телефоні відкрийте застосунок OpenClaw для iOS → Settings → Gateway.
|
||||
4. Вставте код налаштування й підключіться.
|
||||
5. Назад у Telegram: `/pair pending` (перегляньте ID запитів, роль і області дії), потім затвердьте.
|
||||
5. Поверніться в Telegram: `/pair pending` (перегляньте ідентифікатори запитів, роль і області дії), потім схваліть.
|
||||
|
||||
Код налаштування — це JSON-пейлоад, закодований у base64, який містить:
|
||||
Код налаштування — це JSON-навантаження, закодоване в base64, яке містить:
|
||||
|
||||
- `url`: URL WebSocket Gateway (`ws://...` або `wss://...`)
|
||||
- `bootstrapToken`: короткоживучий bootstrap-токен для одного пристрою, який використовується для початкового рукостискання сполучення
|
||||
- `bootstrapToken`: короткоживучий bootstrap-токен для одного пристрою, який використовується для початкового рукостискання створення пари
|
||||
|
||||
Цей bootstrap-токен має вбудований bootstrap-профіль сполучення:
|
||||
Цей bootstrap-токен має вбудований bootstrap-профіль створення пари:
|
||||
|
||||
- основний переданий токен `node` лишається `scopes: []`
|
||||
- будь-який переданий токен `operator` лишається обмеженим bootstrap-списком дозволених:
|
||||
- основний переданий токен `node` залишається з `scopes: []`
|
||||
- будь-який переданий токен `operator` залишається обмеженим bootstrap-списком дозволених:
|
||||
`operator.approvals`, `operator.read`, `operator.talk.secrets`, `operator.write`
|
||||
- перевірки bootstrap-областей дії мають префікс ролі, а не один плоский пул областей дії:
|
||||
записи областей дії operator задовольняють лише запити operator, а ролі не-operator
|
||||
усе одно мають запитувати області дії під власним префіксом ролі
|
||||
- подальша ротація/відкликання токенів лишається обмеженою і затвердженим
|
||||
контрактом ролі пристрою, і областями дії operator сесії виклику
|
||||
- перевірки bootstrap-областей дії мають префікс ролі, а не один плаский пул областей дії:
|
||||
записи області дії оператора задовольняють лише запити оператора, а ролі, що не є операторськими,
|
||||
все одно мають запитувати області дії під власним префіксом ролі
|
||||
- подальша ротація/відкликання токена залишається обмеженою як схваленим
|
||||
контрактом ролі пристрою, так і операторськими областями дії сесії викликача
|
||||
|
||||
Ставтеся до коду налаштування як до пароля, поки він чинний.
|
||||
|
||||
### Затвердити пристрій Node
|
||||
### Схвалити Node-пристрій
|
||||
|
||||
```bash
|
||||
openclaw devices list
|
||||
@ -149,18 +149,25 @@ openclaw devices approve <requestId>
|
||||
openclaw devices reject <requestId>
|
||||
```
|
||||
|
||||
Якщо той самий пристрій повторює спробу з іншими даними автентифікації (наприклад іншою
|
||||
роллю/областями дії/публічним ключем), попередній очікуваний запит замінюється і створюється новий
|
||||
Коли явне схвалення відхилено через те, що сесію схвалювального paired-пристрою
|
||||
було відкрито лише з областю дії для створення пари, CLI повторює той самий запит із
|
||||
`operator.admin`. Це дає наявному paired-пристрою з можливостями адміністратора відновити нове
|
||||
створення пари для Control UI/браузера без ручного редагування `devices/paired.json`.
|
||||
Gateway усе одно перевіряє повторне підключення; токени, які не можуть автентифікуватися
|
||||
з `operator.admin`, залишаються заблокованими.
|
||||
|
||||
Якщо той самий пристрій повторює спробу з іншими даними автентифікації (наприклад іншими
|
||||
роллю/областями дії/публічним ключем), попередній очікуваний запит замінюється, і створюється новий
|
||||
`requestId`.
|
||||
|
||||
<Note>
|
||||
Уже сполучений пристрій не отримує ширший доступ непомітно. Якщо він перепідключається й просить більше областей дії або ширшу роль, OpenClaw лишає наявне затвердження без змін і створює новий очікуваний запит на підвищення. Використовуйте `openclaw devices list`, щоб порівняти поточний затверджений доступ із новим запитаним доступом перед затвердженням.
|
||||
Уже paired-пристрій не отримує ширший доступ непомітно. Якщо він повторно підключається, запитуючи більше областей дії або ширшу роль, OpenClaw зберігає наявне схвалення без змін і створює новий очікуваний запит на підвищення доступу. Використовуйте `openclaw devices list`, щоб порівняти поточний схвалений доступ із новозапитаним доступом перед схваленням.
|
||||
</Note>
|
||||
|
||||
### Необов’язкове автоматичне затвердження Node за довіреним CIDR
|
||||
### Необов’язкове автоматичне схвалення Node з довірених CIDR
|
||||
|
||||
Сполучення пристроїв типово лишається ручним. Для суворо контрольованих мереж Node
|
||||
можна увімкнути автоматичне затвердження першого Node з явними CIDR або точними IP:
|
||||
Створення пари з пристроєм стандартно залишається ручним. Для суворо контрольованих Node-мереж
|
||||
ви можете ввімкнути автоматичне схвалення першого Node з явними CIDR або точними IP-адресами:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -174,25 +181,25 @@ openclaw devices reject <requestId>
|
||||
}
|
||||
```
|
||||
|
||||
Це застосовується лише до нових запитів сполучення `role: node` без запитаних
|
||||
областей дії. Клієнти operator, browser, Control UI і WebChat усе одно потребують ручного
|
||||
затвердження. Зміни ролі, області дії, метаданих і публічного ключа також потребують ручного
|
||||
затвердження.
|
||||
Це застосовується лише до нових запитів на створення пари `role: node` без запитаних
|
||||
областей дії. Операторські, браузерні, Control UI та WebChat клієнти все одно потребують ручного
|
||||
схвалення. Зміни ролі, області дії, метаданих і публічного ключа все одно потребують ручного
|
||||
схвалення.
|
||||
|
||||
### Зберігання стану сполучення Node
|
||||
### Зберігання стану створення пари з Node
|
||||
|
||||
Зберігається в `~/.openclaw/devices/`:
|
||||
|
||||
- `pending.json` (короткоживучий; очікувані запити спливають)
|
||||
- `paired.json` (сполучені пристрої + токени)
|
||||
- `paired.json` (paired-пристрої + токени)
|
||||
|
||||
### Примітки
|
||||
|
||||
- Застарілий API `node.pair.*` (CLI: `openclaw nodes pending|approve|reject|remove|rename`) є
|
||||
окремим сховищем сполучення, яким володіє gateway. WS-вузли все одно потребують сполучення пристрою.
|
||||
- Запис сполучення є тривалим джерелом істини для затверджених ролей. Активні
|
||||
токени пристрою лишаються обмеженими цим затвердженим набором ролей; випадковий запис токена
|
||||
поза затвердженими ролями не створює нового доступу.
|
||||
окремим сховищем створення пар, яким володіє gateway. WS Node усе одно потребують створення пари з пристроєм.
|
||||
- Запис створення пари є довготривалим джерелом істини для схвалених ролей. Активні
|
||||
токени пристроїв залишаються обмеженими цим схваленим набором ролей; випадковий запис токена
|
||||
поза схваленими ролями не створює нового доступу.
|
||||
|
||||
## Пов’язані документи
|
||||
|
||||
|
||||
@ -2,27 +2,27 @@
|
||||
read_when:
|
||||
- Налаштування видимих оновлень прогресу для тривалих ходів чату
|
||||
- Вибір між режимами потокового передавання partial, block і progress
|
||||
- Пояснення, як OpenClaw оновлює одне повідомлення в каналі під час виконання роботи
|
||||
- Усунення проблем із чернетками прогресу, окремими повідомленнями про прогрес або резервним механізмом фіналізації
|
||||
summary: 'Чернетки прогресу: одне видиме повідомлення про перебіг роботи, яке оновлюється під час роботи агента'
|
||||
title: Чернетки перебігу роботи
|
||||
- Пояснення того, як OpenClaw оновлює одне повідомлення в каналі під час виконання роботи
|
||||
- Усунення неполадок із чернетками прогресу, окремими повідомленнями про прогрес або резервним механізмом фіналізації
|
||||
summary: 'Чернетки прогресу: одне видиме проміжне повідомлення про хід роботи, яке оновлюється, поки агент працює'
|
||||
title: Чернетки прогресу
|
||||
x-i18n:
|
||||
generated_at: "2026-05-03T23:27:03Z"
|
||||
generated_at: "2026-05-03T23:55:07Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 04e87e81b5b256a3dcd52b70d46e85c80a5d05ecb32df00ccf59782ab47bde2c
|
||||
source_hash: 079d4b63554fee0fc968027195d2707f2f0a16fa527b0ec81f88baedfe809c1e
|
||||
source_path: concepts/progress-drafts.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
Чернетки прогресу оживляють довгі ходи агента в чаті, не перетворюючи
|
||||
розмову на стек тимчасових відповідей зі статусом.
|
||||
Чернетки прогресу роблять тривалі ходи агента живими в чаті, не перетворюючи
|
||||
розмову на стос тимчасових відповідей зі статусом.
|
||||
|
||||
Коли чернетки прогресу ввімкнені, OpenClaw створює одне видиме повідомлення
|
||||
про роботу в процесі лише після того, як хід доведе, що виконує реальну роботу,
|
||||
оновлює його, поки агент читає, планує, викликає інструменти або чекає на
|
||||
схвалення, а потім перетворює цю чернетку на фінальну відповідь, коли канал
|
||||
може зробити це безпечно.
|
||||
Коли чернетки прогресу ввімкнено, OpenClaw створює одне видиме повідомлення з
|
||||
роботою в процесі лише після того, як хід доводить, що справді виконує роботу,
|
||||
оновлює його, поки агент читає, планує, викликає інструменти або чекає
|
||||
схвалення, а потім перетворює цю чернетку на фінальну відповідь, коли канал може
|
||||
зробити це безпечно.
|
||||
|
||||
```text
|
||||
Shelling...
|
||||
@ -31,9 +31,9 @@ Shelling...
|
||||
- preparing reply
|
||||
```
|
||||
|
||||
Використовуйте чернетки прогресу, коли потрібне одне охайне повідомлення зі
|
||||
Використовуйте чернетки прогресу, коли вам потрібне одне охайне повідомлення зі
|
||||
статусом під час роботи з великою кількістю інструментів і фінальна відповідь,
|
||||
коли хід завершено.
|
||||
коли хід завершиться.
|
||||
|
||||
## Швидкий старт
|
||||
|
||||
@ -52,37 +52,38 @@ Shelling...
|
||||
```
|
||||
|
||||
Зазвичай цього достатньо. OpenClaw вибере автоматичну однослівну мітку,
|
||||
зачекає, доки робота триватиме щонайменше п’ять секунд або згенерує другу подію
|
||||
роботи, додаватиме стислі рядки прогресу, поки відбувається корисна робота, і
|
||||
пригнічуватиме дублікати окремого прогрес-чату для цього ходу.
|
||||
зачекає, доки робота триватиме щонайменше п'ять секунд або згенерує другу подію
|
||||
роботи, додаватиме компактні рядки прогресу, поки відбувається корисна робота, і
|
||||
приглушить дублікати окремих повідомлень про прогрес для цього ходу.
|
||||
|
||||
## Що бачать користувачі
|
||||
|
||||
Чернетка прогресу має дві частини:
|
||||
|
||||
| Частина | Призначення |
|
||||
| -------------- | ----------------------------------------------------------------- |
|
||||
| Мітка | Короткий заголовок, наприклад `Thinking...` або `Shelling...`. |
|
||||
| Рядки прогресу | Стислі оновлення виконання, як-от виклики інструментів, кроки завдань або схвалення. |
|
||||
| Частина | Призначення |
|
||||
| -------------- | -------------------------------------------------------------------------- |
|
||||
| Мітка | Короткий заголовок, як-от `Thinking...` або `Shelling...`. |
|
||||
| Рядки прогресу | Компактні оновлення запуску з тими самими мітками інструментів та іконками, що й у докладному виводі. |
|
||||
|
||||
Мітка з’являється після того, як агент починає змістовну роботу і або
|
||||
залишається зайнятим п’ять секунд, або генерує другу подію роботи. Відповіді
|
||||
лише звичайним текстом не показують чернетку прогресу. Рядки прогресу
|
||||
додаються лише тоді, коли агент генерує корисні оновлення роботи. Фінальна
|
||||
відповідь замінює чернетку, коли це можливо; інакше OpenClaw надсилає фінальну
|
||||
відповідь звичайним способом і очищає або припиняє оновлювати чернетку
|
||||
відповідно до транспорту каналу.
|
||||
Мітка з'являється після того, як агент починає змістовну роботу й або
|
||||
залишається зайнятим протягом п'яти секунд, або генерує другу подію роботи.
|
||||
Відповіді лише простим текстом не показують чернетку прогресу. Рядки прогресу
|
||||
додаються лише тоді, коли агент генерує корисні оновлення роботи, наприклад
|
||||
`🛠️ Exec`, `🔎 Web Search` або `✍️ Write: to /tmp/file`. Фінальна відповідь
|
||||
замінює чернетку, коли це можливо; інакше OpenClaw надсилає фінальну відповідь
|
||||
звичайним способом і очищає чернетку або припиняє її оновлювати відповідно до
|
||||
транспорту каналу.
|
||||
|
||||
## Вибір режиму
|
||||
|
||||
`channels.<channel>.streaming.mode` керує видимою поведінкою роботи в процесі:
|
||||
|
||||
| Режим | Найкраще для | Що з’являється в чаті |
|
||||
| ---------- | -------------------------------- | ------------------------------------------------- |
|
||||
| `off` | Тихі канали | Лише фінальна відповідь. |
|
||||
| `partial` | Спостереження за появою тексту відповіді | Одна чернетка, що редагується з найновішим текстом відповіді. |
|
||||
| `block` | Більші фрагменти попереднього перегляду відповіді | Один попередній перегляд, що оновлюється або доповнюється більшими фрагментами. |
|
||||
| `progress` | Ходи з великою кількістю інструментів або довгим виконанням | Одна чернетка статусу, потім фінальна відповідь. |
|
||||
| Режим | Найкраще для | Що з'являється в чаті |
|
||||
| ---------- | ------------------------------------ | -------------------------------------------------- |
|
||||
| `off` | Тихих каналів | Лише фінальна відповідь. |
|
||||
| `partial` | Спостереження за появою тексту відповіді | Одна чернетка, відредагована з найновішим текстом відповіді. |
|
||||
| `block` | Більших фрагментів попереднього перегляду відповіді | Один попередній перегляд, оновлений або доповнений більшими фрагментами. |
|
||||
| `progress` | Ходів із великою кількістю інструментів або тривалим виконанням | Одна чернетка статусу, потім фінальна відповідь. |
|
||||
|
||||
Вибирайте `progress`, коли користувачам важливіше "що відбувається", ніж
|
||||
спостерігати, як текст відповіді транслюється токен за токеном.
|
||||
@ -91,16 +92,16 @@ Shelling...
|
||||
|
||||
Вибирайте `block`, коли потрібні оновлення чернетки попереднього перегляду
|
||||
більшими текстовими фрагментами. У Discord і Telegram `streaming.mode: "block"`
|
||||
усе ще є потоковим попереднім переглядом, а не звичайною блоковою доставкою.
|
||||
Використовуйте `streaming.block.enabled` або застарілий `blockStreaming`, коли
|
||||
потрібні звичайні блокові відповіді.
|
||||
досі означає потокове передавання попереднього перегляду, а не звичайну доставку
|
||||
блоків. Використовуйте `streaming.block.enabled` або застарілий `blockStreaming`,
|
||||
коли потрібні звичайні блокові відповіді.
|
||||
|
||||
## Налаштування міток
|
||||
|
||||
Мітки прогресу розташовані в `channels.<channel>.streaming.progress`.
|
||||
|
||||
Типова мітка — `auto`, яка вибирає з вбудованого пулу OpenClaw
|
||||
однослівних міток із трьома крапками:
|
||||
Типова мітка — `auto`, яка вибирає з вбудованого в OpenClaw набору однослівних
|
||||
міток із трьома крапками:
|
||||
|
||||
```text
|
||||
Thinking...
|
||||
@ -142,7 +143,7 @@ Surfacing...
|
||||
}
|
||||
```
|
||||
|
||||
Використовуйте власний автоматичний пул міток:
|
||||
Використовуйте власний автоматичний набір міток:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -179,9 +180,9 @@ Surfacing...
|
||||
|
||||
## Керування рядками прогресу
|
||||
|
||||
Рядки прогресу ввімкнені типово в режимі progress. Вони походять із реальних
|
||||
подій виконання: запусків інструментів, оновлень елементів, планів завдань,
|
||||
схвалень, виводу команд, підсумків патчів і подібної активності агента.
|
||||
Рядки прогресу ввімкнено за замовчуванням у режимі прогресу. Вони походять із
|
||||
реальних подій запуску: запусків інструментів, оновлень елементів, планів
|
||||
завдань, схвалень, виводу команд, підсумків патчів і схожої активності агента.
|
||||
|
||||
Обмежте кількість рядків, які залишаються видимими:
|
||||
|
||||
@ -200,7 +201,7 @@ Surfacing...
|
||||
}
|
||||
```
|
||||
|
||||
Збережіть єдину чернетку прогресу, але приховайте рядки інструментів і завдань:
|
||||
Збережіть одну чернетку прогресу, але приховайте рядки інструментів і завдань:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -217,22 +218,22 @@ Surfacing...
|
||||
}
|
||||
```
|
||||
|
||||
З `toolProgress: false` OpenClaw усе ще пригнічує старіші окремі повідомлення
|
||||
про прогрес інструментів для цього ходу. Канал залишається візуально тихим до
|
||||
фінальної відповіді, крім мітки, якщо її налаштовано.
|
||||
З `toolProgress: false` OpenClaw усе одно приглушує старі окремі повідомлення про
|
||||
прогрес інструментів для цього ходу. Канал залишається візуально тихим до
|
||||
фінальної відповіді, за винятком мітки, якщо її налаштовано.
|
||||
|
||||
## Поведінка каналів
|
||||
|
||||
Кожен канал використовує найчистіший транспорт, який підтримує:
|
||||
Кожен канал використовує найчистіший транспорт, який він підтримує:
|
||||
|
||||
| Канал | Транспорт прогресу | Примітки |
|
||||
| --------------- | -------------------------------------- | --------------------------------------------------------------------- |
|
||||
| Discord | Надіслати одне повідомлення, потім редагувати його. | Фінальний текст редагується на місці, коли він уміщується в одне безпечне повідомлення попереднього перегляду. |
|
||||
| Matrix | Надіслати одну подію, потім редагувати її. | Конфігурація потокового передавання на рівні облікового запису керує чернетками на рівні облікового запису. |
|
||||
| Microsoft Teams | Нативний потік Teams в особистих чатах. | `streaming.mode: "block"` зіставляється з блоковою доставкою Teams. |
|
||||
| Slack | Нативний потік або редагований допис-чернетка. | Доступність треду впливає на те, чи можна використовувати нативне потокове передавання. |
|
||||
| Telegram | Надіслати одне повідомлення, потім редагувати його. | Старіші видимі чернетки можуть бути замінені, щоб фінальні часові позначки залишалися корисними. |
|
||||
| Mattermost | Редагований допис-чернетка. | Активність інструментів згортається в той самий допис у стилі чернетки. |
|
||||
| Канал | Транспорт прогресу | Примітки |
|
||||
| --------------- | ------------------------------------ | --------------------------------------------------------------------- |
|
||||
| Discord | Надіслати одне повідомлення, потім редагувати його. | Фінальний текст редагується на місці, коли вміщується в одне безпечне повідомлення попереднього перегляду. |
|
||||
| Matrix | Надіслати одну подію, потім редагувати її. | Налаштування потокового передавання на рівні акаунта керує чернетками на рівні акаунта. |
|
||||
| Microsoft Teams | Нативний потік Teams в особистих чатах. | `streaming.mode: "block"` зіставляється з блоковою доставкою Teams. |
|
||||
| Slack | Нативний потік або редагована чернетка допису. | Доступність гілки впливає на те, чи можна використовувати нативне потокове передавання. |
|
||||
| Telegram | Надіслати одне повідомлення, потім редагувати його. | Старіші видимі чернетки можуть бути замінені, щоб фінальні часові мітки залишалися корисними. |
|
||||
| Mattermost | Редагована чернетка допису. | Активність інструментів згортається в той самий допис у стилі чернетки. |
|
||||
|
||||
Канали без безпечної підтримки редагування зазвичай повертаються до індикаторів
|
||||
набору тексту або доставки лише фінальної відповіді.
|
||||
@ -243,10 +244,10 @@ Surfacing...
|
||||
|
||||
- Якщо чернетка може безпечно стати фінальною відповіддю, OpenClaw редагує її на місці.
|
||||
- Якщо канал використовує нативне потокове передавання прогресу, OpenClaw фіналізує цей потік, коли нативний транспорт приймає фінальний текст.
|
||||
- Якщо фінальна відповідь містить медіа, запит на схвалення, явну ціль відповіді, надто багато фрагментів або невдале редагування/надсилання, OpenClaw надсилає фінальну відповідь через звичайний шлях доставки каналу.
|
||||
- Якщо фінальна відповідь містить медіа, запит на схвалення, явну ціль відповіді, забагато фрагментів або невдале редагування/надсилання, OpenClaw надсилає фінальну відповідь через звичайний шлях доставки каналу.
|
||||
|
||||
Резервний шлях є навмисним. Краще надіслати нову фінальну відповідь, ніж
|
||||
втратити текст, неправильно прив’язати відповідь до треду або перезаписати
|
||||
втратити текст, неправильно прив'язати відповідь до гілки або перезаписати
|
||||
чернетку корисним навантаженням, яке канал не може безпечно представити.
|
||||
|
||||
## Усунення несправностей
|
||||
@ -254,42 +255,42 @@ Surfacing...
|
||||
**Я бачу лише фінальну відповідь.**
|
||||
|
||||
Перевірте, що `channels.<channel>.streaming.mode` встановлено на `progress` для
|
||||
облікового запису або каналу, який обробив повідомлення. Деякі групові шляхи
|
||||
або шляхи відповіді з цитатою можуть вимикати попередні перегляди чернеток для
|
||||
ходу, коли канал не може безпечно редагувати правильне повідомлення.
|
||||
акаунта або каналу, який обробив повідомлення. Деякі шляхи груп або відповідей із
|
||||
цитуванням можуть вимикати попередні перегляди чернеток для ходу, коли канал не
|
||||
може безпечно редагувати правильне повідомлення.
|
||||
|
||||
**Я бачу мітку, але не бачу рядків інструментів.**
|
||||
|
||||
Перевірте `streaming.progress.toolProgress`. Якщо це `false`, OpenClaw зберігає
|
||||
поведінку єдиної чернетки, але приховує рядки прогресу інструментів і завдань.
|
||||
поведінку з однією чернеткою, але приховує рядки прогресу інструментів і завдань.
|
||||
|
||||
**Я бачу нове фінальне повідомлення замість відредагованої чернетки.**
|
||||
|
||||
Це резервний механізм безпеки. Таке може статися для відповідей із медіа,
|
||||
довгих відповідей, явних цілей відповіді, старих чернеток Telegram, відсутніх
|
||||
цілей тредів Slack, видалених повідомлень попереднього перегляду або невдалої
|
||||
цілей гілок Slack, видалених повідомлень попереднього перегляду або невдалої
|
||||
фіналізації нативного потоку.
|
||||
|
||||
**Я все ще бачу окремі повідомлення про прогрес.**
|
||||
**Я досі бачу окремі повідомлення про прогрес.**
|
||||
|
||||
Режим progress пригнічує типові окремі повідомлення про прогрес інструментів,
|
||||
коли чернетка активна. Якщо окремі повідомлення все ще з’являються, перевірте,
|
||||
що хід справді використовує режим progress, а не `streaming.mode: "off"` або
|
||||
шлях каналу, який не може створити чернетку для цього повідомлення.
|
||||
Режим прогресу приглушує типові окремі повідомлення про прогрес інструментів,
|
||||
коли чернетка активна. Якщо окремі повідомлення все ще з'являються, перевірте,
|
||||
що хід справді використовує режим прогресу, а не `streaming.mode: "off"` або шлях
|
||||
каналу, який не може створити чернетку для цього повідомлення.
|
||||
|
||||
**Teams поводиться інакше, ніж Discord або Telegram.**
|
||||
|
||||
Microsoft Teams використовує нативний потік в особистих чатах замість
|
||||
універсального транспорту попереднього перегляду з надсиланням і редагуванням.
|
||||
Teams також трактує `streaming.mode: "block"` як блокову доставку Teams,
|
||||
оскільки він не має такого самого режиму блокового попереднього перегляду
|
||||
чернеток, який використовують Discord і Telegram.
|
||||
Teams також трактує `streaming.mode: "block"` як блокову доставку Teams, бо не
|
||||
має такого самого блокового режиму попереднього перегляду чернеток, який
|
||||
використовують Discord і Telegram.
|
||||
|
||||
## Пов’язане
|
||||
## Пов'язане
|
||||
|
||||
- [Потокове передавання та фрагментація](/uk/concepts/streaming)
|
||||
- [Потокове передавання та розбиття на фрагменти](/uk/concepts/streaming)
|
||||
- [Повідомлення](/uk/concepts/messages)
|
||||
- [Конфігурація каналів](/uk/gateway/config-channels)
|
||||
- [Налаштування каналів](/uk/gateway/config-channels)
|
||||
- [Discord](/uk/channels/discord)
|
||||
- [Matrix](/uk/channels/matrix)
|
||||
- [Microsoft Teams](/uk/channels/msteams)
|
||||
|
||||
@ -1,22 +1,22 @@
|
||||
---
|
||||
read_when:
|
||||
- Налагодження помилок через відсутню область дії оператора
|
||||
- Перегляд схвалень сполучення пристрою або Node
|
||||
- Налагодження помилок, пов’язаних із відсутньою областю дії оператора
|
||||
- Перегляд схвалень для сполучення пристрою або Node
|
||||
- Додавання або класифікація RPC-методів Gateway
|
||||
summary: Ролі операторів, області доступу та перевірки на етапі затвердження для клієнтів Gateway
|
||||
summary: Ролі операторів, області дії та перевірки під час затвердження для клієнтів Gateway
|
||||
title: Області дії оператора
|
||||
x-i18n:
|
||||
generated_at: "2026-05-03T00:43:11Z"
|
||||
generated_at: "2026-05-03T23:54:54Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 48f59f96b41333af9124ad4083ac5442eedb2d6cebdfff74e3ba256f06d36add
|
||||
source_hash: f05d6bdbf9bdad2aef1c9664bb7ebb4b6241334b8aefac7993104e9977e40450
|
||||
source_path: gateway/operator-scopes.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
Області дії оператора визначають, що клієнт Gateway може робити після автентифікації.
|
||||
Вони є захисним механізмом площини керування всередині одного довіреного домену оператора Gateway,
|
||||
а не ізоляцією від ворожого багатокористувацького середовища. Якщо вам потрібне сильне розділення між
|
||||
Вони є запобіжником площини керування всередині одного довіреного операторського домену Gateway,
|
||||
а не ізоляцією від ворожих багатьох орендарів. Якщо вам потрібне сильне розділення між
|
||||
людьми, командами або машинами, запускайте окремі Gateways під окремими користувачами ОС або
|
||||
на окремих хостах.
|
||||
|
||||
@ -27,41 +27,41 @@ x-i18n:
|
||||
|
||||
Клієнти Gateway WebSocket підключаються з однією роллю:
|
||||
|
||||
- `operator`: клієнти площини керування, як-от CLI, Control UI, автоматизація та
|
||||
- `operator`: клієнти площини керування, такі як CLI, Control UI, автоматизація та
|
||||
довірені допоміжні процеси.
|
||||
- `node`: хости можливостей, як-от macOS, iOS, Android або безголові вузли, які
|
||||
- `node`: хости можливостей, такі як macOS, iOS, Android або безголові вузли, які
|
||||
надають команди через `node.invoke`.
|
||||
|
||||
RPC-методи оператора потребують ролі `operator`. Методи, що походять від Node,
|
||||
Методи RPC оператора потребують ролі `operator`. Методи, що походять від Node,
|
||||
потребують ролі `node`.
|
||||
|
||||
## Рівні областей дії
|
||||
|
||||
| Область дії | Значення |
|
||||
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `operator.read` | Статус лише для читання, списки, каталог, журнали, читання сесій та інші виклики площини керування, які не змінюють стан. |
|
||||
| `operator.write` | Звичайні операторські дії, що змінюють стан, як-от надсилання повідомлень, виклик інструментів, оновлення налаштувань розмови/голосу та ретрансляція команд Node. Також задовольняє `operator.read`. |
|
||||
| `operator.admin` | Адміністративний доступ до площини керування. Задовольняє кожну область дії `operator.*`. Потрібна для зміни конфігурації, оновлень, нативних хуків, чутливих зарезервованих просторів імен та високоризикових схвалень. |
|
||||
| `operator.pairing` | Керування сполученням пристроїв і Node, зокрема перелік, схвалення, відхилення, видалення, ротація та відкликання записів сполучення або токенів пристроїв. |
|
||||
| `operator.approvals` | API схвалення exec і Plugin. |
|
||||
| `operator.talk.secrets` | Читання конфігурації Talk з включеними секретами. |
|
||||
| Область дії | Значення |
|
||||
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `operator.read` | Стан лише для читання, списки, каталог, журнали, читання сеансів та інші виклики площини керування без мутацій. |
|
||||
| `operator.write` | Звичайні мутаційні дії оператора, такі як надсилання повідомлень, виклик інструментів, оновлення налаштувань розмови/голосу та ретрансляція команд Node. Також задовольняє `operator.read`. |
|
||||
| `operator.admin` | Адміністративний доступ до площини керування. Задовольняє кожну область дії `operator.*`. Потрібна для мутації конфігурації, оновлень, нативних хуків, чутливих зарезервованих просторів імен та схвалень високого ризику. |
|
||||
| `operator.pairing` | Керування сполученням пристроїв і Node, зокрема перелік, схвалення, відхилення, видалення, ротація та відкликання записів сполучення або токенів пристроїв. |
|
||||
| `operator.approvals` | API схвалення виконання та plugin. |
|
||||
| `operator.talk.secrets` | Читання конфігурації Talk з включеними секретами. |
|
||||
|
||||
Невідомі майбутні області дії `operator.*` потребують точного збігу, якщо викликач не має
|
||||
`operator.admin`.
|
||||
|
||||
## Область дії методу — лише перший бар’єр
|
||||
|
||||
Кожен RPC Gateway має область дії методу з найменшими привілеями. Ця область дії методу визначає,
|
||||
Кожен RPC Gateway має область дії методу з мінімальними привілеями. Ця область дії методу визначає,
|
||||
чи може запит дійти до обробника. Деякі обробники потім застосовують суворіші
|
||||
перевірки під час схвалення на основі конкретної речі, яку схвалюють або змінюють.
|
||||
|
||||
Приклади:
|
||||
|
||||
- `device.pair.approve` доступний з `operator.pairing`, але схвалення
|
||||
операторського пристрою може створювати або зберігати лише ті області дії, які викликач уже має.
|
||||
- `node.pair.approve` доступний з `operator.pairing`, а потім виводить додаткові
|
||||
області дії для схвалення зі списку команд Node, що очікують.
|
||||
- `chat.send` зазвичай є методом з областю дії на запис, але постійні `/config set`
|
||||
- `device.pair.approve` доступний із `operator.pairing`, але схвалення
|
||||
операторського пристрою може лише створити або зберегти області дії, які викликач уже має.
|
||||
- `node.pair.approve` доступний із `operator.pairing`, а потім виводить додаткові
|
||||
області дії схвалення зі списку очікуваних команд Node.
|
||||
- `chat.send` зазвичай є методом з областю дії запису, але постійні `/config set`
|
||||
і `/config unset` потребують `operator.admin` на рівні команди.
|
||||
|
||||
Це дає операторам із нижчими областями дії виконувати низькоризикові дії сполучення, не роблячи
|
||||
@ -69,48 +69,50 @@ RPC-методи оператора потребують ролі `operator`. М
|
||||
|
||||
## Схвалення сполучення пристроїв
|
||||
|
||||
Записи сполучення пристроїв є довговічним джерелом схвалених ролей і областей дії.
|
||||
Записи сполучення пристроїв є надійним джерелом схвалених ролей і областей дії.
|
||||
Уже сполучені пристрої не отримують ширший доступ непомітно: повторні підключення, які запитують
|
||||
ширшу роль або ширші області дії, створюють новий запит на оновлення, що очікує.
|
||||
|
||||
Під час схвалення запиту пристрою:
|
||||
|
||||
- Запит без ролі оператора не потребує схвалення області дії операторського токена.
|
||||
- Запит без ролі оператора не потребує схвалення області дії токена оператора.
|
||||
- Запит на `operator.read`, `operator.write`, `operator.approvals`,
|
||||
`operator.pairing` або `operator.talk.secrets` потребує, щоб викликач мав
|
||||
ці області дії або `operator.admin`.
|
||||
- Запит на `operator.admin` потребує `operator.admin`.
|
||||
- Запит на відновлення без явних областей дії може успадкувати наявні області дії
|
||||
операторського токена. Якщо цей наявний токен має адміністративну область дії, схвалення все одно потребує
|
||||
- Запит на відновлення без явних областей дії може успадкувати наявні області дії токена
|
||||
оператора. Якщо цей наявний токен має область дії адміністратора, схвалення все одно потребує
|
||||
`operator.admin`.
|
||||
|
||||
Для токенних сесій сполучених пристроїв керування обмежене власним записом, якщо викликач
|
||||
також не має `operator.admin`: викликачі без прав адміністратора можуть ротувати, відкликати або видаляти лише
|
||||
власний запис пристрою.
|
||||
Для сеансів токенів сполучених пристроїв керування має власну область дії, якщо викликач
|
||||
також не має `operator.admin`: викликачі без прав адміністратора бачать лише власні записи сполучення,
|
||||
можуть схвалювати або відхиляти лише власний запит, що очікує, і можуть ротувати, відкликати або
|
||||
видаляти лише власний запис пристрою.
|
||||
|
||||
## Схвалення сполучення Node
|
||||
|
||||
Застарілі `node.pair.*` використовують окреме сховище сполучення Node, що належить Gateway. WS-вузли
|
||||
використовують сполучення пристрою з `role: node`, але застосовується той самий словник рівнів схвалення.
|
||||
Застарілий `node.pair.*` використовує окреме сховище сполучень Node, яким володіє Gateway. WS-вузли
|
||||
використовують сполучення пристроїв із `role: node`, але застосовується той самий словник
|
||||
рівнів схвалення.
|
||||
|
||||
`node.pair.approve` використовує список команд запиту, що очікує, щоб вивести додаткові
|
||||
потрібні області дії:
|
||||
|
||||
- Запит без команд: `operator.pairing`
|
||||
- Команди Node без exec: `operator.pairing` + `operator.write`
|
||||
- Команди Node без виконання: `operator.pairing` + `operator.write`
|
||||
- `system.run`, `system.run.prepare` або `system.which`:
|
||||
`operator.pairing` + `operator.admin`
|
||||
|
||||
Сполучення Node встановлює ідентичність і довіру. Воно не замінює власну
|
||||
політику схвалення exec `system.run` цього Node.
|
||||
Сполучення Node встановлює ідентичність і довіру. Воно не замінює власну політику
|
||||
схвалення виконання `system.run` цього Node.
|
||||
|
||||
## Автентифікація спільним секретом
|
||||
## Автентифікація зі спільним секретом
|
||||
|
||||
Автентифікація за спільним токеном/паролем Gateway розглядається як довірений операторський доступ для
|
||||
Автентифікація зі спільним токеном/паролем Gateway розглядається як довірений операторський доступ для
|
||||
цього Gateway. HTTP-поверхні, сумісні з OpenAI, і `/tools/invoke` відновлюють
|
||||
звичайний повний набір областей дії оператора за замовчуванням для bearer-автентифікації спільним секретом, навіть якщо
|
||||
звичайний повний стандартний набір областей дії оператора для bearer-автентифікації зі спільним секретом, навіть якщо
|
||||
викликач надсилає вужчі оголошені області дії.
|
||||
|
||||
Режими з ідентичністю, як-от автентифікація через довірений проксі або приватний вхід `none`,
|
||||
усе ще можуть враховувати явно оголошені області дії. Використовуйте окремі Gateways для справжнього
|
||||
Режими з ідентичністю, такі як автентифікація через довірений проксі або приватний вхід `none`,
|
||||
все ще можуть враховувати явно оголошені області дії. Використовуйте окремі Gateways для справжнього
|
||||
розділення меж довіри.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user