diff --git a/docs/uk/concepts/qa-e2e-automation.md b/docs/uk/concepts/qa-e2e-automation.md index 95d8e14b4..233c8b067 100644 --- a/docs/uk/concepts/qa-e2e-automation.md +++ b/docs/uk/concepts/qa-e2e-automation.md @@ -1,67 +1,67 @@ --- read_when: - - Розуміння того, як взаємодіє QA-стек + - Розуміння того, як компоненти QA-стека працюють разом - Розширення qa-lab, qa-channel або транспортного адаптера - Додавання QA-сценаріїв на основі репозиторію - - Створення реалістичнішої автоматизації QA навколо панелі керування Gateway -summary: 'Огляд стека QA: qa-lab, qa-channel, сценарії на основі репозиторію, live-лінії транспорту, транспортні адаптери та звітування.' -title: Огляд QA + - Створення QA-автоматизації з вищим рівнем реалістичності навколо панелі керування Gateway +summary: 'Огляд стеку QA: qa-lab, qa-channel, сценарії на основі репозиторію, лінії реального транспорту, транспортні адаптери та звітування.' +title: Огляд забезпечення якості x-i18n: - generated_at: "2026-05-03T20:32:15Z" + generated_at: "2026-05-03T22:25:51Z" model: gpt-5.5 provider: openai - source_hash: 6a1446fddb00855634d34662a0a47be1e5054a9e7bfed5bc9ae21185d87094d8 + source_hash: 7553094890e20eb760df149ac8bd598048c023dc072743ffe2a8dd60d17382de source_path: concepts/qa-e2e-automation.md workflow: 16 --- -Приватний стек QA призначений для перевірки OpenClaw реалістичнішим, -канально-орієнтованим способом, ніж це може зробити один модульний тест. +Приватний QA-стек призначений для перевірки OpenClaw у реалістичніший, +канально-орієнтований спосіб, ніж це може зробити один unit-тест. Поточні складові: -- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, гілки, +- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, треду, реакції, редагування та видалення. -- `extensions/qa-lab`: UI відлагоджувача та шина QA для спостереження за транскриптом, - ін'єкції вхідних повідомлень і експорту Markdown-звіту. -- `extensions/qa-matrix`, майбутні runner-плагіни: адаптери live-транспортів, які - керують реальним каналом усередині дочірнього QA gateway. -- `qa/`: seed-ресурси з репозиторію для стартового завдання та базових QA - сценаріїв. -- [Mantis](/uk/concepts/mantis): перевірка до і після наживо для помилок, яким - потрібні реальні транспорти, знімки екрана браузера, стан VM і докази PR. +- `extensions/qa-lab`: UI відлагоджувача й QA-шина для спостереження за транскриптом, + ін’єкції вхідних повідомлень і експорту Markdown-звіту. +- `extensions/qa-matrix`, майбутні плагіни-ранери: адаптери live-транспорту, які + керують реальним каналом усередині дочірнього QA Gateway. +- `qa/`: seed-активи з репозиторію для стартового завдання й базових QA-сценаріїв. +- [Mantis](/uk/concepts/mantis): перевірка до та після live-верифікації для помилок, яким + потрібні реальні транспорти, скриншоти браузера, стан VM і докази для PR. ## Поверхня команд -Кожен QA-потік виконується через `pnpm openclaw qa `. Багато з них мають псевдоніми скриптів `pnpm qa:*`; -підтримуються обидві форми. +Кожен QA-потік виконується через `pnpm openclaw qa `. Багато з них мають +аліаси скриптів `pnpm qa:*`; підтримуються обидві форми. -| Команда | Призначення | -| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `qa run` | Вбудована самоперевірка QA; записує Markdown-звіт. | -| `qa suite` | Запустити сценарії з репозиторію проти lane QA gateway. Псевдоніми: `pnpm openclaw qa suite --runner multipass` для одноразової Linux VM. | -| `qa coverage` | Надрукувати Markdown-інвентар покриття сценаріїв (`--json` для машинного виводу). | -| `qa parity-report` | Порівняти два файли `qa-suite-summary.json` і записати агентний звіт про паритет. | -| `qa character-eval` | Запустити character QA scenario на кількох live-моделях зі звітом із судженням. Див. [Звітування](#reporting). | -| `qa manual` | Запустити одноразовий prompt проти вибраного lane провайдера/моделі. | -| `qa ui` | Запустити UI відлагоджувача QA та локальну шину QA (псевдонім: `pnpm qa:lab:ui`). | -| `qa docker-build-image` | Зібрати попередньо підготовлений Docker-образ QA. | -| `qa docker-scaffold` | Записати docker-compose scaffold для QA dashboard + gateway lane. | -| `qa up` | Зібрати QA site, запустити стек на Docker і надрукувати URL (псевдонім: `pnpm qa:lab:up`; варіант `:fast` додає `--use-prebuilt-image --bind-ui-dist --skip-ui-build`). | -| `qa aimock` | Запустити лише сервер AIMock provider. | -| `qa mock-openai` | Запустити лише сервер scenario-aware `mock-openai` provider. | -| `qa credentials doctor` / `add` / `list` / `remove` | Керувати спільним пулом облікових даних Convex. | -| `qa matrix` | Live transport lane проти одноразового Tuwunel homeserver. Див. [Matrix QA](/uk/concepts/qa-matrix). | -| `qa telegram` | Live transport lane проти реальної приватної групи Telegram. | -| `qa discord` | Live transport lane проти реального приватного каналу guild Discord. | -| `qa mantis` | Runner для перевірки до і після для помилок live-транспорту, з першим сценарієм Discord status-reactions. Див. [Mantis](/uk/concepts/mantis). | +| Команда | Призначення | +| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `qa run` | Вбудована самоперевірка QA; записує Markdown-звіт. | +| `qa suite` | Запустити сценарії з репозиторію проти лінії QA Gateway. Аліаси: `pnpm openclaw qa suite --runner multipass` для одноразової Linux VM. | +| `qa coverage` | Вивести markdown-інвентар покриття сценаріїв (`--json` для машинного виводу). | +| `qa parity-report` | Порівняти два файли `qa-suite-summary.json` і записати агентський звіт про паритет. | +| `qa character-eval` | Запустити character QA-сценарій на кількох live-моделях зі звітом, оціненим суддею. Див. [Звітування](#reporting). | +| `qa manual` | Запустити одноразовий prompt проти вибраної лінії провайдера/моделі. | +| `qa ui` | Запустити UI відлагоджувача QA та локальну QA-шину (аліас: `pnpm qa:lab:ui`). | +| `qa docker-build-image` | Зібрати попередньо підготовлений Docker-образ QA. | +| `qa docker-scaffold` | Записати docker-compose scaffold для QA-панелі + лінії Gateway. | +| `qa up` | Зібрати QA-сайт, запустити Docker-стек і вивести URL (аліас: `pnpm qa:lab:up`; варіант `:fast` додає `--use-prebuilt-image --bind-ui-dist --skip-ui-build`). | +| `qa aimock` | Запустити лише сервер провайдера AIMock. | +| `qa mock-openai` | Запустити лише сценарно-обізнаний сервер провайдера `mock-openai`. | +| `qa credentials doctor` / `add` / `list` / `remove` | Керувати спільним пулом облікових даних Convex. | +| `qa matrix` | Лінія live-транспорту проти одноразового homeserver Tuwunel. Див. [Matrix QA](/uk/concepts/qa-matrix). | +| `qa telegram` | Лінія live-транспорту проти реальної приватної групи Telegram. | +| `qa discord` | Лінія live-транспорту проти реального приватного каналу guild Discord. | +| `qa slack` | Лінія live-транспорту проти реального приватного каналу Slack. | +| `qa mantis` | Ранер перевірки до та після для помилок live-транспорту з першим сценарієм статусних реакцій Discord. Див. [Mantis](/uk/concepts/mantis). | ## Потік оператора -Поточний операторський потік QA — це двопанельний QA site: +Поточний QA-потік оператора — це QA-сайт із двома панелями: - Ліворуч: панель Gateway (Control UI) з агентом. -- Праворуч: QA Lab, що показує транскрипт у стилі Slack і план сценарію. +- Праворуч: QA Lab, що показує Slack-подібний транскрипт і план сценарію. Запустіть його так: @@ -69,13 +69,13 @@ x-i18n: pnpm qa:lab:up ``` -Це збирає QA site, запускає gateway lane на Docker і відкриває сторінку -QA Lab, де оператор або automation loop може дати агенту QA-місію, -спостерігати реальну поведінку каналу та записати, що спрацювало, не спрацювало або -залишилося заблокованим. +Це збирає QA-сайт, запускає Docker-лінію Gateway і відкриває сторінку +QA Lab, де оператор або цикл автоматизації може дати агенту QA-місію, +спостерігати реальну поведінку каналу й записати, що спрацювало, що +зламалося або що лишилося заблокованим. -Для швидшої ітерації UI QA Lab без перезбирання Docker-образу щоразу -запустіть стек із bind-mounted QA Lab bundle: +Для швидшої ітерації UI QA Lab без перебудови Docker-образу щоразу +запустіть стек із bind-mounted bundle QA Lab: ```bash pnpm openclaw qa docker-build-image @@ -84,10 +84,10 @@ pnpm qa:lab:up:fast pnpm qa:lab:watch ``` -`qa:lab:up:fast` тримає Docker-сервіси на попередньо зібраному образі та bind-mounts +`qa:lab:up:fast` тримає Docker-сервіси на попередньо зібраному образі та bind-mount-ить `extensions/qa-lab/web/dist` у контейнер `qa-lab`. `qa:lab:watch` -перезбирає цей bundle при змінах, а браузер автоматично перезавантажується, коли змінюється -хеш ресурсів QA Lab. +перезбирає цей bundle за змін, а браузер автоматично перезавантажується, коли змінюється +asset hash QA Lab. Для локального smoke OpenTelemetry trace запустіть: @@ -96,35 +96,36 @@ pnpm qa:otel:smoke ``` Цей скрипт запускає локальний OTLP/HTTP trace receiver, виконує -QA-сценарій `otel-trace-smoke` з увімкненим Plugin `diagnostics-otel`, потім +QA-сценарій `otel-trace-smoke` з увімкненим плагіном `diagnostics-otel`, потім декодує експортовані protobuf spans і перевіряє release-critical форму: `openclaw.run`, `openclaw.harness.run`, `openclaw.model.call`, `openclaw.context.assembled` і `openclaw.message.delivery` мають бути присутні; -model calls не мають експортувати `StreamAbandoned` на успішних ходах; raw diagnostic IDs і -атрибути `openclaw.content.*` мають залишатися поза trace. Він записує +виклики моделі не мають експортувати `StreamAbandoned` на успішних turns; сирі діагностичні ID та +атрибути `openclaw.content.*` мають лишатися поза trace. Він записує `otel-smoke-summary.json` поруч з артефактами QA suite. -Observability QA залишається лише для source checkout. npm tarball навмисно не містить -QA Lab, тому package Docker release lanes не виконують команди `qa`. Використовуйте +Observability QA лишається доступним лише з source-checkout. npm tarball навмисно не містить +QA Lab, тому package Docker release lanes не запускають команди `qa`. Використовуйте `pnpm qa:otel:smoke` із зібраного source checkout, коли змінюєте diagnostics instrumentation. -Для lane transport-real Matrix smoke запустіть: +Для транспортно-реальної smoke-лінії Matrix запустіть: ```bash pnpm openclaw qa matrix --profile fast --fail-fast ``` -Повний довідник CLI, каталог профілів/сценаріїв, env vars і структура артефактів для цього lane містяться в [Matrix QA](/uk/concepts/qa-matrix). Коротко: він provision одноразовий Tuwunel homeserver у Docker, реєструє тимчасових користувачів driver/SUT/observer, запускає реальний Matrix Plugin усередині дочірнього QA gateway, обмеженого цим transport (без `qa-channel`), а потім записує Markdown-звіт, JSON summary, артефакт observed-events і комбінований output log у `.artifacts/qa-e2e/matrix-/`. +Повний довідник CLI, каталог профілів/сценаріїв, env vars і layout артефактів для цієї лінії описані в [Matrix QA](/uk/concepts/qa-matrix). Коротко: вона provision-ить одноразовий homeserver Tuwunel у Docker, реєструє тимчасових користувачів driver/SUT/observer, запускає реальний плагін Matrix усередині дочірнього QA Gateway, обмеженого цим транспортом (без `qa-channel`), а потім записує Markdown-звіт, JSON summary, артефакт observed-events і комбінований output log у `.artifacts/qa-e2e/matrix-/`. -Для transport-real Telegram і Discord smoke lanes: +Для транспортно-реальних smoke-ліній Telegram, Discord і Slack: ```bash pnpm openclaw qa telegram pnpm openclaw qa discord +pnpm openclaw qa slack ``` -Обидва націлені на вже наявний реальний канал із двома ботами (driver + SUT). Обов'язкові env vars, списки сценаріїв, вихідні артефакти та пул облікових даних Convex задокументовані в [довіднику QA для Telegram і Discord](#telegram-and-discord-qa-reference) нижче. +Вони націлені на вже наявний реальний канал із двома ботами (driver + SUT). Обов’язкові env vars, списки сценаріїв, output artifacts і пул облікових даних Convex задокументовані нижче в [Довіднику QA для Telegram, Discord і Slack](#telegram-discord-and-slack-qa-reference). Перед використанням pooled live credentials запустіть: @@ -132,81 +133,83 @@ pnpm openclaw qa discord pnpm openclaw qa credentials doctor ``` -Doctor перевіряє env брокера Convex, валідовує endpoint settings і перевіряє доступність admin/list, коли maintainer secret присутній. Для secrets він повідомляє лише статус set/missing. +Doctor перевіряє env брокера Convex, валідовує налаштування endpoint і перевіряє доступність admin/list, коли присутній maintainer secret. Для secrets він повідомляє лише статус set/missing. -## Покриття live transport +## Покриття live-транспорту -Live transport lanes мають один спільний контракт замість того, щоб кожен вигадував власну форму списку сценаріїв. `qa-channel` — це широка синтетична suite поведінки продукту й не є частиною матриці покриття live transport. +Лінії live-транспорту мають один спільний контракт, а не кожна винаходить власну форму списку сценаріїв. `qa-channel` — це ширший синтетичний suite поведінки продукту, і він не є частиною матриці покриття live-транспорту. -| Lane | Canary | Mention gating | Bot-to-bot | Allowlist block | Top-level reply | Restart resume | Thread follow-up | Thread isolation | Reaction observation | Help command | Native command registration | +| Лінія | Canary | Mention gating | Bot-to-bot | Allowlist block | Top-level reply | Restart resume | Thread follow-up | Thread isolation | Reaction observation | Help command | Native command registration | | -------- | ------ | -------------- | ---------- | --------------- | --------------- | -------------- | ---------------- | ---------------- | -------------------- | ------------ | --------------------------- | | Matrix | x | x | x | x | x | x | x | x | x | | | | Telegram | x | x | x | | | | | | | x | | | Discord | x | x | x | | | | | | | | x | +| Slack | x | x | x | | | | | | | | | -Це зберігає `qa-channel` як широку suite поведінки продукту, тоді як Matrix, -Telegram і майбутні live transports мають один явний checklist транспортного контракту. +Це зберігає `qa-channel` як широкий suite поведінки продукту, тоді як Matrix, +Telegram і майбутні live-транспорти мають спільний явний checklist +транспортного контракту. -Для одноразового lane Linux VM без внесення Docker у шлях QA запустіть: +Для одноразової Linux VM-лінії без залучення Docker у QA-шлях запустіть: ```bash pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline ``` Це завантажує свіжий гостьовий Multipass, встановлює залежності, збирає OpenClaw -усередині guest, запускає `qa suite`, а потім копіює звичайний QA report і +усередині гостя, запускає `qa suite`, а потім копіює звичайний QA-звіт і summary назад у `.artifacts/qa-e2e/...` на host. Він повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на host. -Host і Multipass suite runs за замовчуванням виконують кілька вибраних сценаріїв паралельно +Host- і Multipass-запуски suite за замовчуванням виконують кілька вибраних сценаріїв паралельно з ізольованими gateway workers. `qa-channel` за замовчуванням має concurrency -4, обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency `, щоб налаштувати -кількість workers, або `--concurrency 1` для послідовного виконання. -Команда завершується з ненульовим кодом, коли будь-який сценарій не вдається. Використовуйте `--allow-failures`, коли -потрібні артефакти без коду завершення з помилкою. -Live runs передають підтримувані QA auth inputs, практичні для -guest: provider keys на основі env, шлях до QA live provider config і -`CODEX_HOME`, коли він присутній. Тримайте `--output-dir` під коренем репозиторію, щоб guest -міг записувати назад через mounted workspace. +4, обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency ` для налаштування +кількості workers або `--concurrency 1` для послідовного виконання. +Команда завершується з ненульовим кодом, коли будь-який сценарій падає. Використовуйте `--allow-failures`, коли +потрібні артефакти без failing exit code. +Live-запуски передають підтримувані QA auth inputs, практичні для +гостя: env-based provider keys, шлях до QA live provider config і +`CODEX_HOME`, коли він присутній. Тримайте `--output-dir` під коренем репозиторію, щоб гість +міг записувати назад через змонтований workspace. -## Довідник QA для Telegram і Discord +## Довідник QA для Telegram, Discord і Slack -Matrix має [окрему сторінку](/uk/concepts/qa-matrix) через кількість сценаріїв і provisioning homeserver на Docker. Telegram і Discord менші — кілька сценаріїв кожен, без системи профілів, проти вже наявних реальних каналів — тому їхній довідник міститься тут. +Matrix має [окрему сторінку](/uk/concepts/qa-matrix) через кількість сценаріїв і Docker-backed homeserver provisioning. Telegram, Discord і Slack менші — по кілька сценаріїв кожен, без системи профілів, проти вже наявних реальних каналів — тому їхній довідник наведено тут. ### Спільні CLI flags -Обидва lanes реєструються через `extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts` і приймають однакові flags: +Ці лінії реєструються через `extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts` і приймають ті самі flags: -| Прапор | Типове значення | Опис | -| ------------------------------------- | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | -| `--scenario ` | — | Запустити лише цей сценарій. Можна повторювати. | -| `--output-dir ` | `/.artifacts/qa-e2e/{telegram,discord}-` | Куди записуються звіти/підсумок/спостережені повідомлення та вихідний журнал. Відносні шляхи розв'язуються відносно `--repo-root`. | -| `--repo-root ` | `process.cwd()` | Корінь репозиторію під час виклику з нейтрального cwd. | -| `--sut-account ` | `sut` | Тимчасовий id облікового запису всередині конфігурації QA gateway. | -| `--provider-mode ` | `live-frontier` | `mock-openai` або `live-frontier` (застарілий `live-openai` досі працює). | -| `--model ` / `--alt-model ` | типове значення провайдера | Посилання на основну/альтернативну модель. | -| `--fast` | вимкнено | Швидкий режим провайдера там, де підтримується. | -| `--credential-source ` | `env` | Див. [пул облікових даних Convex](#convex-credential-pool). | -| `--credential-role ` | `ci` у CI, інакше `maintainer` | Роль, що використовується, коли `--credential-source convex`. | +| Прапор | Типово | Опис | +| ------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | +| `--scenario ` | — | Запустити лише цей сценарій. Можна повторювати. | +| `--output-dir ` | `/.artifacts/qa-e2e/{telegram,discord,slack}-` | Куди записуються звіти/підсумок/спостережені повідомлення та журнал виводу. Відносні шляхи обчислюються відносно `--repo-root`. | +| `--repo-root ` | `process.cwd()` | Корінь репозиторію під час виклику з нейтрального cwd. | +| `--sut-account ` | `sut` | Тимчасовий ідентифікатор облікового запису в конфігурації QA gateway. | +| `--provider-mode ` | `live-frontier` | `mock-openai` або `live-frontier` (застарілий `live-openai` досі працює). | +| `--model ` / `--alt-model ` | типове значення провайдера | Посилання на основну/альтернативну модель. | +| `--fast` | вимкнено | Швидкий режим провайдера там, де він підтримується. | +| `--credential-source ` | `env` | Див. [пул облікових даних Convex](#convex-credential-pool). | +| `--credential-role ` | `ci` у CI, інакше `maintainer` | Роль, що використовується, коли `--credential-source convex`. | -Обидва завершуються з ненульовим кодом виходу за будь-якого невдалого сценарію. `--allow-failures` записує артефакти без встановлення коду виходу як помилкового. +Кожна смуга завершується з ненульовим кодом за будь-якого невдалого сценарію. `--allow-failures` записує артефакти без встановлення коду виходу, що означає помилку. -### QA Telegram +### Telegram QA ```bash pnpm openclaw qa telegram ``` -Націлено на одну реальну приватну групу Telegram із двома окремими ботами (драйвер + SUT). SUT-бот повинен мати ім'я користувача Telegram; спостереження bot-to-bot працює найкраще, коли в обох ботів увімкнено **Bot-to-Bot Communication Mode** у `@BotFather`. +Націлюється на одну реальну приватну групу Telegram із двома різними ботами (драйвер + SUT). SUT-бот повинен мати імʼя користувача Telegram; спостереження бот-бот найкраще працює, коли в обох ботів увімкнено **Bot-to-Bot Communication Mode** у `@BotFather`. -Обов'язкові env, коли `--credential-source env`: +Обовʼязкові env, коли `--credential-source env`: -- `OPENCLAW_QA_TELEGRAM_GROUP_ID` — числовий id чату (рядок). +- `OPENCLAW_QA_TELEGRAM_GROUP_ID` — числовий ідентифікатор чату (рядок). - `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` - `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN` -Необов'язково: +Необовʼязково: -- `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1` зберігає тіла повідомлень в артефактах спостережених повідомлень (типово редагує). +- `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1` зберігає тіла повідомлень в артефактах спостережених повідомлень (типово редагуються). Сценарії (`extensions/qa-lab/src/live-transports/telegram/telegram-live.runtime.ts:44`): @@ -219,29 +222,29 @@ pnpm openclaw qa telegram - `telegram-whoami-command` - `telegram-context-command` -Вихідні артефакти: +Артефакти виводу: - `telegram-qa-report.md` -- `telegram-qa-summary.json` — включає RTT для кожної відповіді (надсилання драйвером → спостережена відповідь SUT), починаючи з canary. -- `telegram-qa-observed-messages.json` — тіла редагуються, якщо не задано `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1`. +- `telegram-qa-summary.json` — містить RTT для кожної відповіді (надсилання драйвером → спостережена відповідь SUT), починаючи з canary. +- `telegram-qa-observed-messages.json` — тіла редагуються, якщо не встановлено `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1`. -### QA Discord +### Discord QA ```bash pnpm openclaw qa discord ``` -Націлено на один реальний приватний канал guild Discord із двома ботами: бот-драйвер, керований harness, і SUT-бот, запущений дочірнім OpenClaw gateway через вбудований Discord plugin. Перевіряє обробку згадок каналу, те, що SUT-бот зареєстрував нативну команду `/help` у Discord, і opt-in сценарії доказів Mantis. +Націлюється на один реальний приватний канал гільдії Discord із двома ботами: ботом-драйвером, яким керує harness, і SUT-ботом, запущеним дочірнім OpenClaw gateway через вбудований Discord plugin. Перевіряє обробку згадок у каналі, що SUT-бот зареєстрував нативну команду `/help` у Discord, а також opt-in сценарії доказів Mantis. -Обов'язкові env, коли `--credential-source env`: +Обовʼязкові env, коли `--credential-source env`: - `OPENCLAW_QA_DISCORD_GUILD_ID` - `OPENCLAW_QA_DISCORD_CHANNEL_ID` - `OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN` - `OPENCLAW_QA_DISCORD_SUT_BOT_TOKEN` -- `OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID` — має збігатися з id користувача SUT-бота, який повертає Discord (інакше lane швидко завершується з помилкою). +- `OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID` — має збігатися з ідентифікатором користувача SUT-бота, який повертає Discord (інакше смуга швидко завершується помилкою). -Необов'язково: +Необовʼязково: - `OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1` зберігає тіла повідомлень в артефактах спостережених повідомлень. @@ -250,9 +253,9 @@ pnpm openclaw qa discord - `discord-canary` - `discord-mention-gating` - `discord-native-help-command-registration` -- `discord-status-reactions-tool-only` — opt-in сценарій Mantis. Запускається самостійно, бо перемикає SUT на завжди ввімкнені відповіді guild лише через tools із `messages.statusReactions.enabled=true`, а потім захоплює часову шкалу реакцій REST плюс візуальний артефакт HTML/PNG. +- `discord-status-reactions-tool-only` — opt-in сценарій Mantis. Виконується самостійно, бо перемикає SUT на завжди ввімкнені відповіді гільдії лише через інструменти з `messages.statusReactions.enabled=true`, а потім захоплює часову шкалу REST-реакцій і візуальний артефакт HTML/PNG. -Запустити сценарій реакцій статусу Mantis явно: +Запустіть сценарій status-reaction Mantis явно: ```bash pnpm openclaw qa discord \ @@ -263,141 +266,171 @@ pnpm openclaw qa discord \ --fast ``` -Вихідні артефакти: +Артефакти виводу: - `discord-qa-report.md` - `discord-qa-summary.json` -- `discord-qa-observed-messages.json` — тіла редагуються, якщо не задано `OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1`. -- `discord-qa-reaction-timelines.json` і `discord-status-reactions-tool-only-timeline.png`, коли запускається сценарій реакцій статусу. +- `discord-qa-observed-messages.json` — тіла редагуються, якщо не встановлено `OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1`. +- `discord-qa-reaction-timelines.json` і `discord-status-reactions-tool-only-timeline.png`, коли виконується сценарій status-reaction. + +### Slack QA + +```bash +pnpm openclaw qa slack +``` + +Націлюється на один реальний приватний канал Slack із двома різними ботами: ботом-драйвером, яким керує harness, і SUT-ботом, запущеним дочірнім OpenClaw gateway через вбудований Slack plugin. + +Обовʼязкові env, коли `--credential-source env`: + +- `OPENCLAW_QA_SLACK_CHANNEL_ID` +- `OPENCLAW_QA_SLACK_DRIVER_BOT_TOKEN` +- `OPENCLAW_QA_SLACK_SUT_BOT_TOKEN` +- `OPENCLAW_QA_SLACK_SUT_APP_TOKEN` + +Необовʼязково: + +- `OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1` зберігає тіла повідомлень в артефактах спостережених повідомлень. + +Сценарії (`extensions/qa-lab/src/live-transports/slack/slack-live.runtime.ts:39`): + +- `slack-canary` +- `slack-mention-gating` + +Артефакти виводу: + +- `slack-qa-report.md` +- `slack-qa-summary.json` +- `slack-qa-observed-messages.json` — тіла редагуються, якщо не встановлено `OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1`. ### Пул облікових даних Convex -Lane Telegram і Discord можуть орендувати облікові дані зі спільного пулу Convex замість читання env vars вище. Передайте `--credential-source convex` (або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`); QA Lab отримує ексклюзивну оренду, надсилає для неї Heartbeat протягом виконання та звільняє її під час завершення. Типи пулу — `"telegram"` і `"discord"`. +Смуги Telegram, Discord і Slack можуть орендувати облікові дані зі спільного пулу Convex замість читання env vars вище. Передайте `--credential-source convex` (або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`); QA Lab отримує ексклюзивну оренду, надсилає heartbeat протягом виконання й звільняє її під час завершення роботи. Типи пулу: `"telegram"`, `"discord"` і `"slack"`. Форми payload, які брокер перевіряє на `admin/add`: -- Telegram (`kind: "telegram"`): `{ groupId: string, driverToken: string, sutToken: string }` — `groupId` має бути числовим рядком chat-id. +- Telegram (`kind: "telegram"`): `{ groupId: string, driverToken: string, sutToken: string }` — `groupId` має бути рядком числового chat-id. - Discord (`kind: "discord"`): `{ guildId: string, channelId: string, driverBotToken: string, sutBotToken: string, sutApplicationId: string }`. -Операційні env vars і контракт endpoint брокера Convex описані в [Тестування → Спільні облікові дані Telegram через Convex](/uk/help/testing#shared-telegram-credentials-via-convex-v1) (назва розділу передує підтримці Discord; семантика брокера однакова для обох типів). +Операційні env vars і контракт endpoint брокера Convex описані в [Тестування → Спільні облікові дані Telegram через Convex](/uk/help/testing#shared-telegram-credentials-via-convex-v1) (назва розділу зʼявилася до підтримки Discord; семантика брокера ідентична для обох типів). -## Seeds на основі репозиторію +## Seeds, підкріплені репозиторієм -Seed-активи розміщені в `qa/`: +Seed-ресурси розташовані в `qa/`: - `qa/scenarios/index.md` - `qa/scenarios//*.md` -Вони навмисно зберігаються в git, щоб план QA був видимим і для людей, і для -агента. +Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і +агенту. -`qa-lab` має залишатися універсальним runner для markdown. Кожен markdown-файл сценарію є +`qa-lab` має залишатися універсальним markdown runner. Кожен markdown-файл сценарію є джерелом істини для одного тестового запуску й має визначати: - метадані сценарію -- необов'язкові метадані категорії, capability, lane і ризику +- необовʼязкові метадані категорії, можливості, смуги та ризику - посилання на docs і code -- необов'язкові вимоги до plugin -- необов'язковий patch конфігурації gateway +- необовʼязкові вимоги до plugin +- необовʼязковий patch конфігурації gateway - виконуваний `qa-flow` -Повторно використовувана runtime-поверхня, що підтримує `qa-flow`, може залишатися універсальною -та наскрізною. Наприклад, markdown-сценарії можуть поєднувати helpers транспортної сторони -з helpers браузерної сторони, які керують вбудованим Control UI через -Gateway `browser.request` seam без додавання runner для спеціального випадку. +Багаторазово використовувана runtime-поверхня, що підтримує `qa-flow`, може залишатися універсальною +та наскрізною. Наприклад, markdown-сценарії можуть поєднувати transport-side +помічники з browser-side помічниками, які керують вбудованим Control UI через +шов Gateway `browser.request` без додавання runner для спеціального випадку. -Файли сценаріїв слід групувати за capability продукту, а не за папкою дерева -джерел. Зберігайте ID сценаріїв стабільними, коли файли переміщуються; використовуйте `docsRefs` і `codeRefs` -для простежуваності реалізації. +Файли сценаріїв слід групувати за продуктовою можливістю, а не за папкою +дерева джерел. Зберігайте ідентифікатори сценаріїв стабільними під час переміщення файлів; використовуйте `docsRefs` і `codeRefs` +для трасованості реалізації. Базовий список має залишатися достатньо широким, щоб покривати: - DM і чат каналу - поведінку thread -- життєвий цикл дій із повідомленнями -- callbacks Cron -- пригадування пам'яті +- життєвий цикл message action +- callbacks cron +- пригадування памʼяті - перемикання моделей - передавання subagent - читання репозиторію та читання docs -- одне невелике завдання збірки, як-от Lobster Invaders +- одне невелике build-завдання, наприклад Lobster Invaders -## Mock lanes провайдера +## Mock-смуги провайдерів -`qa suite` має дві локальні mock lanes провайдера: +`qa suite` має дві локальні mock-смуги провайдерів: -- `mock-openai` — сценарно-обізнаний mock OpenClaw. Він залишається типовою - детермінованою mock lane для QA на основі репозиторію та parity gates. -- `aimock` запускає сервер провайдера на базі AIMock для експериментального protocol, +- `mock-openai` — це scenario-aware OpenClaw mock. Він залишається типовою + детермінованою mock-смугою для repo-backed QA і parity gates. +- `aimock` запускає AIMock-backed сервер провайдера для експериментального protocol, fixture, record/replay і chaos coverage. Він є додатковим і не замінює диспетчер сценаріїв `mock-openai`. -Реалізація provider-lane розміщена в `extensions/qa-lab/src/providers/`. +Реалізація provider-lane розташована в `extensions/qa-lab/src/providers/`. Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера, конфігурацією моделі gateway, -потребами staged auth-profile і прапорами capability live/mock. Спільний код suite і -gateway має маршрутизувати через registry провайдера замість розгалуження за +потребами staged auth-profile, а також live/mock capability flags. Спільний suite і +код gateway мають маршрутизуватися через registry провайдерів замість розгалуження за іменами провайдерів. -## Транспортні адаптери +## Transport adapters -`qa-lab` володіє універсальним transport seam для markdown QA-сценаріїв. `qa-channel` — перший адаптер на цьому seam, але ціль дизайну ширша: майбутні реальні або синтетичні канали мають підключатися до того самого suite runner замість додавання транспортно-специфічного QA runner. +`qa-lab` володіє універсальним transport seam для markdown QA сценаріїв. `qa-channel` є першим adapter на цьому seam, але ціль дизайну ширша: майбутні реальні або synthetic channels мають підключатися до того самого suite runner замість додавання transport-specific QA runner. -На рівні архітектури поділ такий: +На рівні архітектури розподіл такий: -- `qa-lab` володіє універсальним виконанням сценаріїв, concurrency worker, записом артефактів і звітністю. -- Транспортний адаптер володіє конфігурацією gateway, готовністю, inbound і outbound спостереженням, транспортними діями та нормалізованим транспортним станом. -- Markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає повторно використовувану runtime-поверхню, яка їх виконує. +- `qa-lab` володіє універсальним виконанням сценаріїв, паралельністю worker, записом артефактів і звітністю. +- Transport adapter володіє конфігурацією gateway, readiness, inbound and outbound observation, transport actions і normalized transport state. +- Markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає багаторазово використовувану runtime-поверхню, яка їх виконує. ### Додавання каналу -Додавання каналу до markdown-системи QA потребує рівно двох речей: +Додавання каналу до markdown QA system вимагає рівно двох речей: -1. Транспортного адаптера для каналу. -2. Пакета сценаріїв, який перевіряє контракт каналу. +1. Transport adapter для каналу. +2. Scenario pack, який перевіряє контракт каналу. -Не додавайте новий кореневий QA command верхнього рівня, коли спільний хост `qa-lab` може володіти flow. +Не додавайте новий top-level QA command root, коли спільний хост `qa-lab` може володіти потоком. `qa-lab` володіє спільною механікою хоста: -- корінь команди `openclaw qa` +- command root `openclaw qa` - запуск і teardown suite -- concurrency worker +- паралельність worker - запис артефактів -- генерація звіту +- генерування звіту - виконання сценаріїв -- compatibility aliases для старіших сценаріїв `qa-channel` +- aliases сумісності для старіших сценаріїв `qa-channel` -Runner plugins володіють транспортним контрактом: +Runner plugins володіють transport contract: -- як `openclaw qa ` монтується під спільним коренем `qa` -- як gateway конфігурується для цього транспорту -- як перевіряється готовність -- як вводяться inbound-події -- як спостерігаються outbound-повідомлення -- як transcripts і нормалізований транспортний стан надаються назовні -- як виконуються дії, підтримувані транспортом -- як обробляється транспортно-специфічне скидання або очищення +- як `openclaw qa ` монтується під спільним root `qa` +- як gateway налаштовується для цього transport +- як перевіряється readiness +- як injected inbound events +- як спостерігаються outbound messages +- як transcripts і normalized transport state доступні назовні +- як виконуються transport-backed actions +- як обробляється transport-specific reset або cleanup -Мінімальна планка adoption для нового каналу: +Мінімальна планка впровадження для нового каналу: -1. Зберігайте `qa-lab` власником спільного кореня `qa`. -2. Реалізуйте transport runner на спільному host seam `qa-lab`. -3. Тримайте транспортно-специфічну механіку всередині runner plugin або channel harness. -4. Монтуйте runner як `openclaw qa ` замість реєстрації конкуруючої root command. Runner plugins мають оголошувати `qaRunners` в `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` із `runtime-api.ts`. Тримайте `runtime-api.ts` легким; lazy CLI і виконання runner мають залишатися за окремими entrypoints. -5. Створіть або адаптуйте markdown-сценарії в тематичних директоріях `qa/scenarios/`. -6. Використовуйте універсальні helpers сценаріїв для нових сценаріїв. -7. Зберігайте наявні compatibility aliases робочими, якщо репозиторій не виконує навмисну міграцію. +1. Залиште `qa-lab` власником спільного кореня `qa`. +2. Реалізуйте виконавець транспорту на спільному стику хоста `qa-lab`. +3. Тримайте механіку, специфічну для транспорту, всередині Plugin виконавця або обв’язки каналу. +4. Змонтуйте виконавець як `openclaw qa ` замість реєстрації конкуруючої кореневої команди. Plugin-и виконавців мають оголошувати `qaRunners` в `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` з `runtime-api.ts`. Тримайте `runtime-api.ts` легким; ліниве виконання CLI і виконавця має лишатися за окремими точками входу. +5. Створіть або адаптуйте markdown-сценарії у тематичних каталогах `qa/scenarios/`. +6. Використовуйте загальні допоміжні функції сценаріїв для нових сценаріїв. +7. Зберігайте роботу наявних псевдонімів сумісності, якщо репозиторій не виконує навмисну міграцію. -Правило ухвалення рішень суворе: +Правило ухвалення рішення суворе: - Якщо поведінку можна виразити один раз у `qa-lab`, помістіть її в `qa-lab`. -- Якщо поведінка залежить від транспорту одного каналу, тримайте її в цьому runner plugin або plugin harness. -- Якщо сценарію потрібна нова capability, яку може використовувати більше ніж один канал, додайте універсальний helper замість гілки, специфічної для каналу, у `suite.ts`. -- Якщо поведінка має сенс лише для одного транспорту, залиште сценарій транспортно-специфічним і зробіть це явним у контракті сценарію. +- Якщо поведінка залежить від одного транспорту каналу, тримайте її в цьому Plugin виконавця або обв’язці Plugin. +- Якщо сценарію потрібна нова можливість, яку може використовувати більш ніж один канал, додайте загальну допоміжну функцію замість гілки, специфічної для каналу, у `suite.ts`. +- Якщо поведінка має сенс лише для одного транспорту, залиште сценарій специфічним для транспорту й явно вкажіть це в контракті сценарію. -### Назви helpers сценаріїв +### Назви допоміжних функцій сценаріїв -Бажані універсальні helpers для нових сценаріїв: +Бажані загальні допоміжні функції для нових сценаріїв: - `waitForTransportReady` - `waitForChannelReady` @@ -412,11 +445,11 @@ Runner plugins володіють транспортним контрактом: - `formatTransportTranscript` - `resetTransport` -Сумісні псевдоніми залишаються доступними для наявних сценаріїв — `waitForQaChannelReady`, `waitForOutboundMessage`, `waitForNoOutbound`, `formatConversationTranscript`, `resetBus` — але для написання нових сценаріїв слід використовувати загальні назви. Псевдоніми існують, щоб уникнути міграції в один день, а не як модель на майбутнє. +Псевдоніми сумісності лишаються доступними для наявних сценаріїв — `waitForQaChannelReady`, `waitForOutboundMessage`, `waitForNoOutbound`, `formatConversationTranscript`, `resetBus` — але для створення нових сценаріїв слід використовувати загальні назви. Псевдоніми існують, щоб уникнути одночасної міграції всього коду, а не як модель на майбутнє. ## Звітування -`qa-lab` експортує протокольний Markdown-звіт зі спостережуваної часової шкали шини. +`qa-lab` експортує Markdown-звіт протоколу зі спостережуваної часової шкали шини. Звіт має відповідати на такі питання: - Що спрацювало @@ -424,10 +457,10 @@ Runner plugins володіють транспортним контрактом: - Що залишилося заблокованим - Які подальші сценарії варто додати -Щоб отримати інвентар доступних сценаріїв — корисний під час оцінювання обсягу подальшої роботи або підключення нового транспорту — виконайте `pnpm openclaw qa coverage` (додайте `--json` для машинозчитуваного виводу). +Для інвентаризації доступних сценаріїв — корисної під час оцінювання обсягу подальшої роботи або підключення нового транспорту — виконайте `pnpm openclaw qa coverage` (додайте `--json` для машинозчитуваного виводу). -Для перевірок характеру й стилю запустіть той самий сценарій для кількох живих -референсів моделей і запишіть оцінений Markdown-звіт: +Для перевірок характеру та стилю виконайте той самий сценарій на кількох live model +refs і запишіть оцінений Markdown-звіт: ```bash pnpm openclaw qa character-eval \ @@ -446,41 +479,42 @@ pnpm openclaw qa character-eval \ --judge-concurrency 16 ``` -Команда запускає локальні дочірні процеси QA Gateway, а не Docker. Сценарії оцінювання -характеру мають задавати персону через `SOUL.md`, а потім виконувати звичайні ходи -користувача, як-от чат, допомога з робочою областю та невеликі файлові завдання. Моделі-кандидату +Команда запускає дочірні процеси локального QA Gateway, а не Docker. Сценарії оцінювання характеру +мають задавати персону через `SOUL.md`, а потім виконувати звичайні ходи користувача, +як-от чат, допомогу з робочим простором і невеликі файлові завдання. Моделі-кандидату не слід повідомляти, що її оцінюють. Команда зберігає кожен повний -транскрипт, записує базову статистику запуску, а потім просить моделі-судді в швидкому режимі з +транскрипт, записує базову статистику запуску, а потім просить моделі-судді у швидкому режимі з міркуванням `xhigh`, де це підтримується, ранжувати запуски за природністю, вайбом і гумором. -Використовуйте `--blind-judge-models` під час порівняння провайдерів: промпт судді все одно отримує -кожен транскрипт і статус запуску, але референси кандидатів замінюються нейтральними -мітками, як-от `candidate-01`; після парсингу звіт зіставляє рейтинги назад із реальними референсами. +Використовуйте `--blind-judge-models` під час порівняння провайдерів: підказка судді все одно отримує +кожен транскрипт і статус запуску, але refs кандидатів замінюються нейтральними +мітками, як-от `candidate-01`; звіт зіставляє рейтинги назад із реальними refs після +розбору. Запуски кандидатів за замовчуванням використовують мислення `high`, з `medium` для GPT-5.5 і `xhigh` -для старіших оцінювальних референсів OpenAI, які це підтримують. Перевизначте конкретного кандидата вбудовано за допомогою -`--model provider/model,thinking=`. `--thinking ` досі задає -глобальний резервний варіант, а старіша форма `--model-thinking ` -збережена для сумісності. -Референси кандидатів OpenAI за замовчуванням використовують швидкий режим, щоб там, -де провайдер це підтримує, застосовувалася пріоритетна обробка. Додайте `,fast`, `,no-fast` або `,fast=false` вбудовано, коли -окремому кандидату чи судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете -примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалості кандидатів і суддів -записуються у звіт для бенчмарк-аналізу, але промпти суддів явно вказують +для старіших refs оцінювання OpenAI, які це підтримують. Перевизначте конкретного кандидата inline за допомогою +`--model provider/model,thinking=`. `--thinking ` все ще задає +глобальний fallback, а старіша форма `--model-thinking ` зберігається +для сумісності. +Refs кандидатів OpenAI за замовчуванням використовують швидкий режим, щоб пріоритетна обробка застосовувалась там, де +провайдер її підтримує. Додайте `,fast`, `,no-fast` або `,fast=false` inline, коли +окремий кандидат або суддя потребує перевизначення. Передавайте `--fast` лише тоді, коли хочете +примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалості для кандидатів і суддів +записуються у звіті для аналізу бенчмарків, але підказки суддів явно вказують не ранжувати за швидкістю. -Запуски моделей-кандидатів і моделей-суддів за замовчуванням мають concurrency 16. Зменште -`--concurrency` або `--judge-concurrency`, коли ліміти провайдера чи навантаження на локальний Gateway -роблять запуск надто шумним. -Коли не передано жодного кандидата `--model`, оцінювання характеру за замовчуванням використовує +Запуски моделей-кандидатів і суддів за замовчуванням обидва використовують concurrency 16. Зменште +`--concurrency` або `--judge-concurrency`, коли ліміти провайдера або навантаження на локальний Gateway +роблять запуск занадто шумним. +Коли кандидатський `--model` не передано, оцінювання характеру за замовчуванням використовує `openai/gpt-5.5`, `openai/gpt-5.2`, `openai/gpt-5`, `anthropic/claude-opus-4-6`, `anthropic/claude-sonnet-4-6`, `zai/glm-5.1`, `moonshot/kimi-k2.5` і -`google/gemini-3.1-pro-preview`, якщо `--model` не передано. -Коли не передано `--judge-model`, судді за замовчуванням такі: +`google/gemini-3.1-pro-preview`, коли `--model` не передано. +Коли `--judge-model` не передано, судді за замовчуванням: `openai/gpt-5.5,thinking=xhigh,fast` і `anthropic/claude-opus-4-6,thinking=high`. -## Пов’язана документація +## Пов’язані документи -- [Матричне QA](/uk/concepts/qa-matrix) +- [Матрична QA](/uk/concepts/qa-matrix) - [Канал QA](/uk/channels/qa-channel) - [Тестування](/uk/help/testing) - [Панель керування](/uk/web/dashboard) diff --git a/docs/uk/concepts/queue-steering.md b/docs/uk/concepts/queue-steering.md index c463d357f..50d38f790 100644 --- a/docs/uk/concepts/queue-steering.md +++ b/docs/uk/concepts/queue-steering.md @@ -1,60 +1,63 @@ --- read_when: - - Пояснення того, як працює керування, коли агент використовує інструменти - - Зміна поведінки черги активного запуску або інтеграції керування під час виконання - - Порівняння режимів керування, черги, збирання та подальших дій -summary: Як керування активним запуском ставить повідомлення в чергу на межах середовища виконання + - Пояснення того, як steer поводиться, поки агент використовує інструменти + - Зміна поведінки черги активних запусків або інтеграції керування під час виконання + - Порівняння режимів steer, queue, collect і followup +summary: Як керування активним виконанням ставить повідомлення в чергу на межах середовища виконання title: Черга керування x-i18n: - generated_at: "2026-04-30T00:29:59Z" + generated_at: "2026-05-03T22:25:48Z" model: gpt-5.5 provider: openai - source_hash: 560390c8c26bcce95e0137f4336ad6e62bc3e2344cb15fd12ca3cfe4a85a8acc + source_hash: c8df35b127ae0c1e1b3b684a1f63ce33874eb3d0b7bf9d0df7cb9dfce093090a source_path: concepts/queue-steering.md workflow: 16 --- -Коли повідомлення надходить, поки запуск сеансу вже транслюється, OpenClaw може -надіслати це повідомлення в активне середовище виконання замість запуску ще одного -запуску для того самого сеансу. Публічні режими нейтральні до середовища виконання; Pi і нативний каркас сервера застосунку Codex +Коли повідомлення надходить під час потокового виконання запуску сеансу, OpenClaw може +надіслати це повідомлення в активне середовище виконання замість запуску ще одного виконання для +того самого сеансу. Публічні режими не залежать від середовища виконання; Pi і нативна обв’язка app-server Codex реалізують деталі доставки по-різному. ## Межа середовища виконання -Скерування не перериває виклик інструмента, який уже виконується. Pi перевіряє -наявність поставлених у чергу повідомлень скерування на межах моделі: +Керування не перериває виклик інструмента, який уже виконується. Pi перевіряє +поставлені в чергу повідомлення керування на межах моделі: 1. Асистент запитує виклики інструментів. 2. Pi виконує пакет викликів інструментів поточного повідомлення асистента. -3. Pi генерує подію завершення ходу. -4. Pi вичерпує поставлені в чергу повідомлення скерування. +3. Pi надсилає подію завершення ходу. +4. Pi обробляє поставлені в чергу повідомлення керування. 5. Pi додає ці повідомлення як повідомлення користувача перед наступним викликом LLM. -Це зберігає результати інструментів у парі з повідомленням асистента, яке їх запитало, -а потім дає наступному виклику моделі побачити найновіший ввід користувача. +Це зберігає результати інструментів пов’язаними з повідомленням асистента, яке їх +запитало, а потім дає наступному виклику моделі побачити найновіші введені дані користувача. -Нативний каркас сервера застосунку Codex надає `turn/steer` замість -внутрішньої черги скерування Pi. OpenClaw адаптує там ті самі режими: +Нативна обв’язка app-server Codex надає `turn/steer` замість внутрішньої +черги керування Pi. OpenClaw адаптує ті самі режими там: - `steer` групує поставлені в чергу повідомлення протягом налаштованого тихого вікна, а потім надсилає - один запит `turn/steer` з усім зібраним вводом користувача в порядку надходження. + один запит `turn/steer` з усіма зібраними введеними даними користувача в порядку надходження. - `queue` зберігає застарілу серіалізовану форму, надсилаючи окремі запити `turn/steer`. -- `followup`, `collect`, `steer-backlog` і `interrupt` залишаються поведінкою черги, якою володіє OpenClaw, +- `followup`, `collect`, `steer-backlog` і `interrupt` залишаються поведінкою черги, якою володіє OpenClaw навколо активного ходу Codex. -Ходи перегляду Codex і ручної Compaction відхиляють скерування в межах того самого ходу. Коли -середовище виконання не може прийняти скерування, OpenClaw повертається до черги подальших дій там, де +Ходи рецензування Codex і ручної Compaction відхиляють керування в межах того самого ходу. Коли +середовище виконання не може прийняти керування, OpenClaw повертається до черги подальших дій там, де цей режим це дозволяє. +Ця сторінка пояснює керування в режимі черги для звичайних вхідних повідомлень. Для +явної команди `/steer ` див. [Керування](/uk/tools/steer). + ## Режими -| Режим | Поведінка під час активного запуску | Поведінка подальшої дії пізніше | +| Режим | Поведінка активного запуску | Поведінка подальших дій пізніше | | --------------- | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | -| `steer` | Вставляє всі поставлені в чергу повідомлення скерування разом на наступній межі середовища виконання. Це стандартний режим. | Повертається до подальшої дії лише тоді, коли скерування недоступне. | -| `queue` | Застаріле почергове скерування. Pi вставляє по одному поставленому в чергу повідомленню на межу моделі; Codex надсилає окремі запити `turn/steer`. | Повертається до подальшої дії лише тоді, коли скерування недоступне. | -| `steer-backlog` | Та сама поведінка скерування активного запуску, що й у `steer`. | Також зберігає те саме повідомлення для пізнішого ходу подальшої дії. | -| `followup` | Не скеровує поточний запуск. | Запускає поставлені в чергу повідомлення пізніше. | -| `collect` | Не скеровує поточний запуск. | Об'єднує сумісні поставлені в чергу повідомлення в один пізніший хід після вікна debounce. | +| `steer` | Вставляє всі поставлені в чергу повідомлення керування разом на наступній межі середовища виконання. Це значення за замовчуванням. | Повертається до подальших дій лише тоді, коли керування недоступне. | +| `queue` | Застаріле покрокове керування. Pi вставляє одне повідомлення з черги на кожній межі моделі; Codex надсилає окремі запити `turn/steer`. | Повертається до подальших дій лише тоді, коли керування недоступне. | +| `steer-backlog` | Та сама поведінка керування активним запуском, що й у `steer`. | Також зберігає те саме повідомлення для пізнішого ходу подальших дій. | +| `followup` | Не керує поточним запуском. | Запускає поставлені в чергу повідомлення пізніше. | +| `collect` | Не керує поточним запуском. | Об’єднує сумісні поставлені в чергу повідомлення в один пізніший хід після вікна debounce. | | `interrupt` | Перериває активний запуск, а потім запускає найновіше повідомлення. | Немає. | ## Приклад сплеску @@ -62,35 +65,36 @@ x-i18n: Якщо четверо користувачів надсилають повідомлення, поки агент виконує виклик інструмента: - `steer`: активне середовище виконання отримує всі чотири повідомлення в порядку надходження перед - своїм наступним рішенням моделі. Pi вичерпує їх на наступній межі моделі; Codex + своїм наступним рішенням моделі. Pi обробляє їх на наступній межі моделі; Codex отримує їх як один пакетний `turn/steer`. -- `queue`: застаріле серіалізоване скерування. Pi вставляє по одному поставленому в чергу повідомленню за раз; +- `queue`: застаріле серіалізоване керування. Pi вставляє по одному повідомленню з черги; Codex отримує окремі запити `turn/steer`. -- `collect`: OpenClaw чекає, доки активний запуск завершиться, а потім створює хід подальшої дії - із сумісними поставленими в чергу повідомленнями після вікна debounce. +- `collect`: OpenClaw чекає, доки активний запуск завершиться, а потім створює хід подальших дій + із сумісними повідомленнями з черги після вікна debounce. ## Область дії -Скерування завжди націлене на поточний активний запуск сеансу. Воно не створює новий +Керування завжди націлене на поточний активний запуск сеансу. Воно не створює новий сеанс, не змінює політику інструментів активного запуску й не розділяє повідомлення за відправником. У -багатокористувацьких каналах вхідні промпти вже містять контекст відправника й маршруту, тож +багатокористувацьких каналах вхідні підказки вже містять контекст відправника й маршруту, тож наступний виклик моделі може бачити, хто надіслав кожне повідомлення. -Використовуйте `collect`, коли потрібно, щоб OpenClaw побудував пізніший хід подальшої дії, який може -об'єднувати сумісні повідомлення та зберігати політику відкидання черги подальших дій. Використовуйте -`queue` лише тоді, коли вам потрібна старіша поведінка почергового скерування. +Використовуйте `collect`, коли хочете, щоб OpenClaw побудував пізніший хід подальших дій, який може +об’єднувати сумісні повідомлення й зберігати політику відкидання черги подальших дій. Використовуйте +`queue` лише тоді, коли вам потрібна старіша поведінка покрокового керування. ## Debounce -`messages.queue.debounceMs` застосовується до доставки подальших дій, включно з `collect`, -`followup`, `steer-backlog` і резервним варіантом `steer`, коли скерування активного запуску +`messages.queue.debounceMs` застосовується до доставки подальших дій, зокрема `collect`, +`followup`, `steer-backlog` і резервного варіанта `steer`, коли керування активним запуском недоступне. Для Pi активний `steer` сам не використовує таймер debounce, тому що -Pi природно групує повідомлення до наступної межі моделі. Для нативного -каркаса Codex OpenClaw використовує те саме значення debounce як тихе вікно перед +Pi природно групує повідомлення до наступної межі моделі. Для нативної +обв’язки Codex OpenClaw використовує те саме значення debounce як тихе вікно перед надсиланням пакетного `turn/steer`. -## Пов'язане +## Пов’язане - [Черга команд](/uk/concepts/queue) +- [Керування](/uk/tools/steer) - [Повідомлення](/uk/concepts/messages) - [Цикл агента](/uk/concepts/agent-loop) diff --git a/docs/uk/concepts/queue.md b/docs/uk/concepts/queue.md index 2368ca06e..2288ab2ed 100644 --- a/docs/uk/concepts/queue.md +++ b/docs/uk/concepts/queue.md @@ -1,32 +1,32 @@ --- read_when: - Зміна виконання автоматичних відповідей або паралельності - - Пояснення режимів /queue або поведінки скерування повідомлень + - Пояснення режимів /queue або поведінки спрямування повідомлень summary: Режими черги автовідповідей, значення за замовчуванням і перевизначення для окремих сеансів title: Черга команд x-i18n: - generated_at: "2026-05-01T23:48:20Z" + generated_at: "2026-05-03T22:25:36Z" model: gpt-5.5 provider: openai - source_hash: c59ea6802d8bf526f4005db3b1baa87d96a23d561c916f91520e8e641fbaf74f + source_hash: 085aebe7059020f027eb08bb382cce2d253ea117eed0ca77d6ffd208f295acb1 source_path: concepts/queue.md workflow: 16 --- -Ми серіалізуємо вхідні запуски автовідповідей (усі канали) через невелику внутрішньопроцесну чергу, щоб запобігти зіткненню кількох запусків агента, водночас зберігаючи безпечний паралелізм між сесіями. +Ми серіалізуємо вхідні запуски автовідповідей (усі канали) через невелику внутрішньопроцесну чергу, щоб запобігти зіткненню кількох запусків агентів, водночас зберігаючи безпечний паралелізм між сесіями. ## Навіщо -- Запуски автовідповідей можуть бути витратними (виклики LLM) і можуть конфліктувати, коли кілька вхідних повідомлень надходять майже одночасно. -- Серіалізація запобігає конкуренції за спільні ресурси (файли сесій, журнали, stdin CLI) і зменшує ймовірність обмежень швидкості на боці вищого рівня. +- Запуски автовідповідей можуть бути дорогими (виклики LLM) і можуть конфліктувати, коли кілька вхідних повідомлень надходять майже одночасно. +- Серіалізація запобігає конкуренції за спільні ресурси (файли сесій, журнали, CLI stdin) і зменшує ймовірність лімітів частоти від зовнішніх сервісів. ## Як це працює -- FIFO-черга з урахуванням смуг обробляє кожну смугу з налаштовуваним лімітом паралельності (типово 1 для неналаштованих смуг; `main` типово 4, `subagent` — 8). -- `runEmbeddedPiAgent` ставить у чергу за **ключем сесії** (смуга `session:`), щоб гарантувати лише один активний запуск на сесію. -- Кожен запуск сесії потім ставиться в **глобальну смугу** (типово `main`), тож загальний паралелізм обмежується `agents.defaults.maxConcurrent`. -- Коли ввімкнено докладне журналювання, запуски в черзі виводять коротке повідомлення, якщо вони чекали понад ~2 с перед стартом. -- Індикатори набору все одно спрацьовують негайно під час додавання до черги (якщо канал це підтримує), тож користувацький досвід не змінюється, поки ми чекаємо своєї черги. +- FIFO-черга з урахуванням смуг обробляє кожну смугу з налаштовуваним лімітом конкурентності (типово 1 для неналаштованих смуг; для main типово 4, для subagent — 8). +- `runEmbeddedPiAgent` додає до черги за **ключем сесії** (смуга `session:`), щоб гарантувати лише один активний запуск на сесію. +- Потім кожен запуск сесії додається до **глобальної смуги** (`main` типово), щоб загальний паралелізм обмежувався `agents.defaults.maxConcurrent`. +- Коли ввімкнено докладне журналювання, запуски в черзі виводять коротке повідомлення, якщо чекали понад ~2 с перед стартом. +- Індикатори набору все одно спрацьовують одразу під час додавання до черги (якщо канал це підтримує), тому користувацький досвід не змінюється, поки ми чекаємо своєї черги. ## Типові значення @@ -37,30 +37,31 @@ x-i18n: - `cap: 20` - `drop: "summarize"` -`steer` є типовим, бо зберігає активний хід моделі чутливим без -запуску другого виконання сесії. Він обробляє всі керівні повідомлення, що надійшли -до наступної межі моделі. Якщо поточний запуск не може приймати керування, -OpenClaw повертається до запису черги для подальшого ходу. +`steer` є типовим, бо він зберігає активний хід моделі швидким без +запуску другої сесії. Він обробляє всі steering-повідомлення, що надійшли +до наступної межі моделі. Якщо поточний запуск не може приймати steering, +OpenClaw повертається до запису в черзі followup. ## Режими черги -Вхідні повідомлення можуть керувати поточним запуском, чекати наступного ходу або робити і те, і інше: +Вхідні повідомлення можуть скеровувати поточний запуск, чекати наступного ходу followup або робити обидва: -- `steer`: ставить керівні повідомлення в чергу активного середовища виконання. Pi доставляє всі очікувані керівні повідомлення **після завершення виконання викликів інструментів поточного ходу асистента**, перед наступним викликом LLM; app-server Codex отримує один пакетний `turn/steer`. Якщо запуск не транслюється активно або керування недоступне, OpenClaw повертається до запису черги для подальшого ходу. -- `queue` (застарілий): старе керування по одному повідомленню за раз. Pi доставляє одне керівне повідомлення з черги на кожній межі моделі; app-server Codex отримує окремі запити `turn/steer`. Віддавайте перевагу `steer`, якщо вам не потрібна попередня серіалізована поведінка. -- `followup`: ставить кожне повідомлення в чергу для пізнішого ходу агента після завершення поточного запуску. -- `collect`: об’єднує повідомлення з черги в **один** подальший хід після вікна тиші. Якщо повідомлення націлені на різні канали/треди, вони обробляються окремо, щоб зберегти маршрутизацію. -- `steer-backlog` (також `steer+backlog`): керує зараз **і** зберігає те саме повідомлення для подальшого ходу. +- `steer`: додає steering-повідомлення до активного середовища виконання. Pi доставляє всі pending steering-повідомлення **після завершення виконання викликів інструментів поточним ходом асистента**, перед наступним викликом LLM; Codex app-server отримує один пакетний `turn/steer`. Якщо запуск не транслюється активно або steering недоступний, OpenClaw повертається до запису в черзі followup. +- `queue` (застарілий): старий steering по одному повідомленню. Pi доставляє одне повідомлення steering з черги на кожній межі моделі; Codex app-server отримує окремі запити `turn/steer`. Надавайте перевагу `steer`, якщо вам не потрібна попередня серіалізована поведінка. +- `followup`: додає кожне повідомлення до черги для пізнішого ходу агента після завершення поточного запуску. +- `collect`: об’єднує повідомлення з черги в **один** хід followup після періоду тиші. Якщо повідомлення націлені на різні канали/треди, вони обробляються окремо, щоб зберегти маршрутизацію. +- `steer-backlog` (також `steer+backlog`): скеровує зараз **і** зберігає те саме повідомлення для ходу followup. - `interrupt` (застарілий): перериває активний запуск для цієї сесії, а потім запускає найновіше повідомлення. -Steer-backlog означає, що ви можете отримати подальшу відповідь після керованого запуску, тому -поверхні потокової передачі можуть виглядати як дублікати. Віддавайте перевагу `collect`/`steer`, якщо хочете -одну відповідь на вхідне повідомлення. +Steer-backlog означає, що ви можете отримати відповідь followup після скерованого запуску, тому +поверхні потокового передавання можуть виглядати як дублікати. Надавайте перевагу `collect`/`steer`, якщо хочете +одну відповідь на кожне вхідне повідомлення. -Про специфічну для середовища виконання синхронізацію та поведінку залежностей див. -[Черга керування](/uk/concepts/queue-steering). +Про поведінку таймінгу й залежностей для конкретних середовищ виконання див. +[Черга steering](/uk/concepts/queue-steering). Про явну команду `/steer ` +див. [Steer](/uk/tools/steer). -Налаштовуйте глобально або для кожного каналу через `messages.queue`: +Налаштуйте глобально або для кожного каналу через `messages.queue`: ```json5 { @@ -78,53 +79,53 @@ Steer-backlog означає, що ви можете отримати подал ## Параметри черги -Параметри застосовуються до `followup`, `collect` і `steer-backlog` (а також до `steer` або застарілого `queue`, коли керування повертається до подальшого ходу): +Параметри застосовуються до `followup`, `collect` і `steer-backlog` (а також до `steer` або застарілого `queue`, коли steering повертається до followup): -- `debounceMs`: вікно тиші перед обробкою подальших ходів із черги. Голі числа — це мілісекунди; одиниці `ms`, `s`, `m`, `h` і `d` приймаються параметрами `/queue`. -- `cap`: максимальна кількість повідомлень у черзі на сесію. Значення нижче `1` ігноруються. -- `drop: "summarize"`: типово. Викидає найстаріші записи черги за потреби, зберігає компактні підсумки та вставляє їх як синтетичний подальший запит. -- `drop: "old"`: викидає найстаріші записи черги за потреби без збереження підсумків. +- `debounceMs`: період тиші перед обробкою queued followups. Числа без одиниць — це мілісекунди; одиниці `ms`, `s`, `m`, `h` і `d` приймаються параметрами `/queue`. +- `cap`: максимальна кількість повідомлень у черзі на сесію. Значення менші за `1` ігноруються. +- `drop: "summarize"`: типово. Видаляє найстаріші записи черги за потреби, зберігає компактні підсумки й вставляє їх як синтетичний prompt followup. +- `drop: "old"`: видаляє найстаріші записи черги за потреби, без збереження підсумків. - `drop: "new"`: відхиляє найновіше повідомлення, коли черга вже заповнена. Типові значення: `debounceMs: 500`, `cap: 20`, `drop: summarize`. -## Пріоритетність +## Пріоритет Для вибору режиму OpenClaw визначає: -1. Вбудоване або збережене перевизначення `/queue` для сесії. +1. Inline або збережене перевизначення `/queue` для сесії. 2. `messages.queue.byChannel.`. 3. `messages.queue.mode`. 4. Типовий `steer`. -Для параметрів вбудовані або збережені параметри `/queue` мають перевагу над конфігурацією. Потім -застосовуються специфічне для каналу згладжування (`messages.queue.debounceMsByChannel`), типові значення згладжування Plugin, -глобальні параметри `messages.queue` і вбудовані типові значення. `cap` і `drop` є глобальними/сесійними параметрами, а не ключами конфігурації -для окремих каналів. +Для параметрів inline або збережені параметри `/queue` мають пріоритет над конфігурацією. Потім +застосовуються специфічний для каналу debounce (`messages.queue.debounceMsByChannel`), типові значення debounce для Plugin, +глобальні параметри `messages.queue` і вбудовані типові значення. `cap` і `drop` — це глобальні/сесійні параметри, а не ключі конфігурації для кожного каналу. ## Перевизначення для сесії - Надішліть `/queue ` як окрему команду, щоб зберегти режим для поточної сесії. -- Параметри можна комбінувати: `/queue collect debounce:0.5s cap:25 drop:summarize` +- Параметри можна поєднувати: `/queue collect debounce:0.5s cap:25 drop:summarize` - `/queue default` або `/queue reset` очищає перевизначення сесії. ## Область дії та гарантії -- Застосовується до запусків агентів автовідповідей у всіх вхідних каналах, що використовують конвеєр відповідей Gateway (веб WhatsApp, Telegram, Slack, Discord, Signal, iMessage, вебчат тощо). -- Типова смуга (`main`) є загальною для процесу для вхідних повідомлень + основних Heartbeat; задайте `agents.defaults.maxConcurrent`, щоб дозволити кілька сесій паралельно. -- Можуть існувати додаткові смуги (наприклад, `cron`, `cron-nested`, `nested`, `subagent`), щоб фонові завдання могли виконуватися паралельно, не блокуючи вхідні відповіді. Ізольовані ходи cron-агента утримують слот `cron`, доки їхнє внутрішнє виконання агента використовує `cron-nested`; обидва використовують `cron.maxConcurrentRuns`. Спільні не-cron потоки `nested` зберігають власну поведінку смуг. Ці відокремлені запуски відстежуються як [фонові завдання](/uk/automation/tasks). -- Смуги для сесії гарантують, що лише один запуск агента торкається певної сесії одночасно. -- Без зовнішніх залежностей або фонових робочих потоків; чистий TypeScript + promises. +- Застосовується до запусків агентів автовідповідей в усіх вхідних каналах, які використовують конвеєр відповідей Gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat тощо). +- Типова смуга (`main`) є процесно-глобальною для вхідних повідомлень + основних heartbeats; задайте `agents.defaults.maxConcurrent`, щоб дозволити кілька сесій паралельно. +- Можуть існувати додаткові смуги (наприклад, `cron`, `cron-nested`, `nested`, `subagent`), щоб фонові завдання могли виконуватися паралельно, не блокуючи вхідні відповіді. Ізольовані ходи cron-агента утримують слот `cron`, тоді як їхнє внутрішнє виконання агента використовує `cron-nested`; обидва використовують `cron.maxConcurrentRuns`. Спільні non-cron потоки `nested` зберігають власну поведінку смуги. Ці відокремлені запуски відстежуються як [фонові завдання](/uk/automation/tasks). +- Смуги для сесій гарантують, що лише один запуск агента одночасно працює з певною сесією. +- Без зовнішніх залежностей або фонових worker threads; лише TypeScript + promises. ## Усунення несправностей -- Якщо команди здаються завислими, увімкніть докладні журнали та шукайте рядки “queued for …ms”, щоб підтвердити, що черга обробляється. -- Якщо вам потрібна глибина черги, увімкніть докладні журнали та стежте за рядками часу черги. -- Запуски app-server Codex, які приймають хід, а потім припиняють виводити прогрес, перериваються адаптером Codex, щоб активна смуга сесії могла звільнитися замість очікування тайм-ауту зовнішнього запуску. -- Коли діагностику ввімкнено, сесії, які залишаються в `processing` довше за `diagnostics.stuckSessionWarnMs` без спостережуваної відповіді, інструмента, статусу, блока або прогресу ACP, класифікуються за поточною активністю. Активна робота журналюється як `session.long_running`; активна робота без нещодавнього прогресу журналюється як `session.stalled`; `session.stuck` зарезервовано для застарілого обліку сесій без активної роботи, і лише цей шлях може звільнити відповідну смугу сесії, щоб робота в черзі оброблялася. Повторні діагностичні повідомлення `session.stuck` відступають, поки сесія залишається незмінною. +- Якщо команди здаються завислими, увімкніть докладні журнали й шукайте рядки “queued for …ms”, щоб підтвердити, що черга обробляється. +- Якщо потрібна глибина черги, увімкніть докладні журнали й стежте за рядками таймінгу черги. +- Запуски Codex app-server, які приймають хід, а потім перестають видавати прогрес, перериваються адаптером Codex, щоб активна смуга сесії могла звільнитися замість очікування тайм-ауту зовнішнього запуску. +- Коли діагностику ввімкнено, сесії, що залишаються в `processing` довше за `diagnostics.stuckSessionWarnMs` без спостереженої відповіді, інструмента, статусу, блока або прогресу ACP, класифікуються за поточною активністю. Активна робота журналюється як `session.long_running`; активна робота без нещодавнього прогресу журналюється як `session.stalled`; `session.stuck` зарезервовано для застарілого обліку сесій без активної роботи, і лише цей шлях може звільнити відповідну смугу сесії, щоб робота в черзі оброблялася. Повторні діагностичні записи `session.stuck` застосовують backoff, доки сесія не змінюється. ## Пов’язане - [Керування сесіями](/uk/concepts/session) -- [Черга керування](/uk/concepts/queue-steering) +- [Черга steering](/uk/concepts/queue-steering) +- [Steer](/uk/tools/steer) - [Політика повторних спроб](/uk/concepts/retry) diff --git a/docs/uk/tools/slash-commands.md b/docs/uk/tools/slash-commands.md index 8a50e39d5..879c8ac3e 100644 --- a/docs/uk/tools/slash-commands.md +++ b/docs/uk/tools/slash-commands.md @@ -6,19 +6,19 @@ sidebarTitle: Slash commands summary: 'Слеш-команди: текстові й нативні, конфігурація та підтримувані команди' title: Слеш-команди x-i18n: - generated_at: "2026-05-03T21:42:02Z" + generated_at: "2026-05-03T22:25:42Z" model: gpt-5.5 provider: openai - source_hash: b95b98f84fd26b706cc38d93935be509033e5df30e00b2f581e326e68b256043 + source_hash: 49eb41674c8d0a01dbd28a2df783eb9aba3dde18d8425951a266cede825e9a84 source_path: tools/slash-commands.md workflow: 16 --- -Команди обробляються Gateway. Більшість команд потрібно надсилати як **окреме** повідомлення, що починається з `/`. Команда bash-чату лише для хоста використовує `! ` (з `/bash ` як псевдонімом). +Команди обробляє Gateway. Більшість команд потрібно надсилати як **окреме** повідомлення, що починається з `/`. Команда bash-чату лише для хоста використовує `! ` (з `/bash ` як псевдонімом). -Коли розмову або потік прив’язано до сесії ACP, звичайний текст подальших відповідей маршрутизується до цієї ACP-обв’язки. Команди керування Gateway усе одно залишаються локальними: `/acp ...` завжди потрапляє до обробника команд OpenClaw ACP, а `/status` і `/unfocus` залишаються локальними, коли для цієї поверхні ввімкнено обробку команд. +Коли розмова або гілка прив'язана до сесії ACP, звичайний подальший текст спрямовується до цього ACP-інструментарію. Команди керування Gateway усе одно залишаються локальними: `/acp ...` завжди потрапляє до обробника команд OpenClaw ACP, а `/status` і `/unfocus` залишаються локальними щоразу, коли для цієї поверхні ввімкнено обробку команд. -Є дві пов’язані системи: +Є дві пов'язані системи: @@ -27,16 +27,16 @@ x-i18n: `/think`, `/fast`, `/verbose`, `/trace`, `/reasoning`, `/elevated`, `/exec`, `/model`, `/queue`. - - Директиви вилучаються з повідомлення до того, як його побачить модель. + - Директиви вилучаються з повідомлення до того, як модель його побачить. - У звичайних повідомленнях чату (не лише з директивами) вони трактуються як "вбудовані підказки" і **не** зберігають налаштування сесії. - - У повідомленнях лише з директивами (повідомлення містить тільки директиви) вони зберігаються в сесії та повертають підтвердження. - - Директиви застосовуються лише для **авторизованих відправників**. Якщо задано `commands.allowFrom`, це єдиний список дозволених; інакше авторизація надходить зі списків дозволених/спарювання каналу плюс `commands.useAccessGroups`. Неавторизовані відправники бачать директиви як звичайний текст. + - У повідомленнях лише з директивами (повідомлення містить тільки директиви) вони зберігаються в сесії та відповідають підтвердженням. + - Директиви застосовуються лише для **авторизованих відправників**. Якщо встановлено `commands.allowFrom`, використовується лише цей список дозволених; інакше авторизація надходить зі списків дозволених каналів/парування плюс `commands.useAccessGroups`. Неавторизовані відправники бачать директиви як звичайний текст. - Лише відправники зі списку дозволених/авторизовані відправники: `/help`, `/commands`, `/status`, `/whoami` (`/id`). + Лише відправники зі списку дозволених/авторизовані: `/help`, `/commands`, `/status`, `/whoami` (`/id`). - Вони виконуються негайно, вилучаються до того, як модель побачить повідомлення, а решта тексту продовжує проходити звичайним потоком. + Вони виконуються негайно, вилучаються до того, як модель побачить повідомлення, а решта тексту продовжує оброблятися звичайним потоком. @@ -69,170 +69,170 @@ x-i18n: ``` - Вмикає розбір `/...` у повідомленнях чату. На поверхнях без нативних команд (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams) текстові команди й далі працюють, навіть якщо встановити це значення в `false`. + Вмикає розбір `/...` у повідомленнях чату. На поверхнях без нативних команд (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams) текстові команди все одно працюють, навіть якщо встановити це значення як `false`. - Реєструє нативні команди. Авто: увімкнено для Discord/Telegram; вимкнено для Slack (доки ви не додасте slash-команди); ігнорується для провайдерів без нативної підтримки. Встановіть `channels.discord.commands.native`, `channels.telegram.commands.native` або `channels.slack.commands.native`, щоб перевизначити для окремого провайдера (bool або `"auto"`). У Discord `false` пропускає реєстрацію та очищення slash-команд під час запуску; раніше зареєстровані команди можуть залишатися видимими, доки ви не видалите їх із застосунку Discord. Команди Slack керуються в застосунку Slack і не видаляються автоматично. + Реєструє нативні команди. Автоматично: увімкнено для Discord/Telegram; вимкнено для Slack (доки ви не додасте slash-команди); ігнорується для провайдерів без нативної підтримки. Установіть `channels.discord.commands.native`, `channels.telegram.commands.native` або `channels.slack.commands.native`, щоб перевизначити для окремого провайдера (bool або `"auto"`). У Discord `false` пропускає реєстрацію та очищення slash-команд під час запуску; раніше зареєстровані команди можуть залишатися видимими, доки ви не видалите їх із застосунку Discord. Командами Slack керують у застосунку Slack, і вони не видаляються автоматично. У Discord специфікації нативних команд можуть містити `descriptionLocalizations`, які OpenClaw публікує як Discord `description_localizations` і включає в порівняння узгодження. - Реєструє команди **Skills** нативно, коли це підтримується. Авто: увімкнено для Discord/Telegram; вимкнено для Slack (Slack вимагає створення slash-команди для кожної Skills). Встановіть `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` або `channels.slack.commands.nativeSkills`, щоб перевизначити для окремого провайдера (bool або `"auto"`). + Реєструє команди **skill** нативно, коли це підтримується. Автоматично: увімкнено для Discord/Telegram; вимкнено для Slack (Slack вимагає створення slash-команди для кожної навички). Установіть `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` або `channels.slack.commands.nativeSkills`, щоб перевизначити для окремого провайдера (bool або `"auto"`). Вмикає `! ` для запуску команд оболонки хоста (`/bash ` є псевдонімом; потребує списків дозволених `tools.elevated`). - Керує тим, як довго bash очікує перед перемиканням у фоновий режим (`0` одразу переводить у фон). + Керує тим, як довго bash чекає перед переходом у фоновий режим (`0` одразу переводить у фон). Вмикає `/config` (читає/записує `openclaw.json`). - Вмикає `/mcp` (читає/записує керовану OpenClaw конфігурацію MCP у `mcp.servers`). + Вмикає `/mcp` (читає/записує MCP-конфігурацію, керовану OpenClaw, у `mcp.servers`). - Вмикає `/plugins` (виявлення/стан plugin плюс елементи керування встановленням і ввімкненням/вимкненням). + Вмикає `/plugins` (виявлення/стан плагінів, а також встановлення та елементи керування ввімкненням/вимкненням). Вмикає `/debug` (перевизначення лише під час виконання). - Вмикає `/restart` плюс дії інструментів перезапуску gateway. + Вмикає `/restart` плюс дії інструментів перезапуску Gateway. - Задає явний список дозволених власників для поверхонь команд/інструментів лише для власника. Це обліковий запис оператора-людини, який може схвалювати небезпечні дії та виконувати команди на кшталт `/diagnostics`, `/export-trajectory` і `/config`. Він відокремлений від `commands.allowFrom` і від доступу через спарювання DM. + Задає явний список дозволених власників для командних/інструментальних поверхонь лише для власника. Це обліковий запис оператора-людини, який може схвалювати небезпечні дії та запускати команди на кшталт `/diagnostics`, `/export-trajectory` і `/config`. Він окремий від `commands.allowFrom` і доступу через парування DM. - Для кожного каналу: змушує команди лише для власника вимагати **ідентичність власника** для запуску на цій поверхні. Коли `true`, відправник має або відповідати розв’язаному кандидату-власнику (наприклад, запису в `commands.ownerAllowFrom` або нативним метаданим власника провайдера), або мати внутрішню область `operator.admin` у внутрішньому каналі повідомлень. Запис із wildcard у `allowFrom` каналу або порожній/нерозв’язаний список кандидатів-власників **не** є достатнім — команди лише для власника на цьому каналі закриваються за замовчуванням. Залиште це вимкненим, якщо хочете, щоб команди лише для власника обмежувалися тільки `ownerAllowFrom` і стандартними списками дозволених команд. + Для кожного каналу: змушує команди лише для власника вимагати **ідентичність власника** для запуску на цій поверхні. Коли `true`, відправник має або збігатися з визначеним кандидатом-власником (наприклад, записом у `commands.ownerAllowFrom` або нативними метаданими власника від провайдера), або мати внутрішній scope `operator.admin` у внутрішньому каналі повідомлень. Запис із wildcard у `allowFrom` каналу або порожній/невизначений список кандидатів-власників **не** достатній — команди лише для власника на цьому каналі завершуються закритою відмовою. Залиште це вимкненим, якщо хочете, щоб команди лише для власника обмежувалися тільки `ownerAllowFrom` і стандартними списками дозволених команд. - Керує тим, як ідентифікатори власників з’являються в системному промпті. + Керує тим, як ідентифікатори власника відображаються в системному prompt. - Необов’язково задає секрет HMAC, що використовується, коли `commands.ownerDisplay="hash"`. + За потреби задає секрет HMAC, що використовується, коли `commands.ownerDisplay="hash"`. - Список дозволених для авторизації команд за провайдерами. Коли налаштовано, це єдине джерело авторизації для команд і директив (списки дозволених/спарювання каналів і `commands.useAccessGroups` ігноруються). Використовуйте `"*"` для глобального типового значення; ключі конкретних провайдерів перевизначають його. + Список дозволених для авторизації команд за провайдерами. Коли налаштовано, це єдине джерело авторизації для команд і директив (списки дозволених каналів/парування та `commands.useAccessGroups` ігноруються). Використовуйте `"*"` для глобального типового значення; ключі конкретних провайдерів його перевизначають. - Застосовує списки дозволених/політики для команд, коли `commands.allowFrom` не задано. + Застосовує списки дозволених/політики для команд, коли `commands.allowFrom` не встановлено. ## Список команд Поточне джерело істини: -- вбудовані команди ядра надходять із `src/auto-reply/commands-registry.shared.ts` +- базові вбудовані команди надходять із `src/auto-reply/commands-registry.shared.ts` - згенеровані dock-команди надходять із `src/auto-reply/commands-registry.data.ts` -- команди plugin надходять із викликів plugin `registerCommand()` -- фактична доступність на вашому gateway усе одно залежить від прапорців конфігурації, поверхні каналу та встановлених/увімкнених plugin +- команди плагінів надходять із викликів `registerCommand()` плагінів +- фактична доступність на вашому gateway усе одно залежить від прапорців конфігурації, поверхні каналу та встановлених/увімкнених плагінів -### Вбудовані команди ядра +### Базові вбудовані команди - `/new [model]` запускає нову сесію; `/reset` є псевдонімом скидання. - - Control UI перехоплює введене `/new`, щоб створити й перемкнутися на свіжу сесію dashboard; введене `/reset` і далі виконує скидання Gateway на місці. - - `/reset soft [message]` зберігає поточний transcript, відкидає повторно використані ідентифікатори сесій backend CLI і повторно запускає завантаження startup/system-prompt на місці. + - Control UI перехоплює введене `/new`, щоб створити й перемкнутися на свіжу сесію dashboard; введене `/reset` усе ще виконує скидання Gateway на місці. + - `/reset soft [message]` зберігає поточну стенограму, відкидає повторно використані ідентифікатори сесій бекенду CLI та повторно виконує завантаження запуску/системного prompt на місці. - `/compact [instructions]` стискає контекст сесії. Див. [Compaction](/uk/concepts/compaction). - `/stop` перериває поточний запуск. - - `/session idle ` і `/session max-age ` керують завершенням терміну дії прив’язки потоку. + - `/session idle ` і `/session max-age ` керують завершенням прив'язки гілки. - `/export-session [path]` експортує поточну сесію в HTML. Псевдонім: `/export`. - - `/export-trajectory [path]` запитує схвалення exec, а потім експортує JSONL [пакет траєкторії](/uk/tools/trajectory) для поточної сесії. Використовуйте це, коли потрібна хронологія prompt, інструментів і transcript для однієї сесії OpenClaw. У групових чатах prompt схвалення та результат експорту надсилаються власнику приватно. Псевдонім: `/trajectory`. + - `/export-trajectory [path]` запитує схвалення exec, а потім експортує JSONL [пакет trajectory](/uk/tools/trajectory) для поточної сесії. Використовуйте це, коли потрібна часова шкала prompt, інструментів і стенограми для однієї сесії OpenClaw. У групових чатах запит на схвалення та результат експорту надсилаються власнику приватно. Псевдонім: `/trajectory`. - - - `/think ` задає рівень thinking. Варіанти надходять із профілю провайдера активної моделі; поширені рівні: `off`, `minimal`, `low`, `medium` і `high`, із власними рівнями на кшталт `xhigh`, `adaptive`, `max` або бінарним `on` лише там, де підтримується. Псевдоніми: `/thinking`, `/t`. + + - `/think ` задає рівень мислення. Варіанти надходять із профілю провайдера активної моделі; поширені рівні: `off`, `minimal`, `low`, `medium` і `high`, а користувацькі рівні, як-от `xhigh`, `adaptive`, `max`, або бінарне `on`, доступні лише там, де підтримуються. Псевдоніми: `/thinking`, `/t`. - `/verbose on|off|full` перемикає докладний вивід. Псевдонім: `/v`. - - `/trace on|off` перемикає вивід trace plugin для поточної сесії. + - `/trace on|off` перемикає trace-вивід плагінів для поточної сесії. - `/fast [status|on|off]` показує або задає швидкий режим. - `/reasoning [on|off|stream]` перемикає видимість reasoning. Псевдонім: `/reason`. - - `/elevated [on|off|ask|full]` перемикає elevated-режим. Псевдонім: `/elev`. + - `/elevated [on|off|ask|full]` перемикає elevated mode. Псевдонім: `/elev`. - `/exec host= security= ask= node=` показує або задає типові значення exec. - `/model [name|#|status]` показує або задає модель. - - `/models [provider] [page] [limit=|size=|all]` перелічує налаштованих/доступних через auth провайдерів або моделі для провайдера; додайте `all`, щоб переглянути повний catalog цього провайдера. - - `/queue ` керує поведінкою черги (`steer`, legacy `queue`, `followup`, `collect`, `steer-backlog`, `interrupt`) плюс параметри на кшталт `debounce:0.5s cap:25 drop:summarize`; `/queue default` або `/queue reset` очищає перевизначення сесії. Див. [Черга команд](/uk/concepts/queue) і [Steering-черга](/uk/concepts/queue-steering). - - `/steer ` вводить guidance в активний запуск для поточної сесії, незалежно від режиму `/queue`. Вона не запускає новий запуск, коли сесія idle. Псевдонім: `/tell`. + - `/models [provider] [page] [limit=|size=|all]` перелічує налаштованих/доступних за автентифікацією провайдерів або моделі для провайдера; додайте `all`, щоб переглянути повний каталог цього провайдера. + - `/queue ` керує поведінкою черги (`steer`, застаріле `queue`, `followup`, `collect`, `steer-backlog`, `interrupt`) плюс параметрами на кшталт `debounce:0.5s cap:25 drop:summarize`; `/queue default` або `/queue reset` очищає перевизначення сесії. Див. [Черга команд](/uk/concepts/queue) і [Черга steering](/uk/concepts/queue-steering). + - `/steer ` вставляє вказівки в активний запуск для поточної сесії незалежно від режиму `/queue`. Це не запускає новий запуск, коли сесія неактивна. Псевдонім: `/tell`. Див. [Steer](/uk/tools/steer). - - `/help` показує короткий підсумок довідки. - - `/commands` показує згенерований catalog команд. - - `/tools [compact|verbose]` показує, що поточний агент може використовувати саме зараз. - - `/status` показує стан виконання/середовища виконання, включно з мітками `Execution`/`Runtime` і використанням/квотою провайдера, коли доступно. - - `/diagnostics [note]` — це потік звіту підтримки лише для власника для помилок Gateway і запусків обв’язки Codex. Він щоразу запитує явне схвалення exec перед запуском `openclaw gateway diagnostics export --json`; не схвалюйте diagnostics правилом allow-all. Після схвалення він надсилає звіт, який можна вставити, з локальним шляхом bundle, підсумком manifest, примітками щодо приватності та відповідними ідентифікаторами сесій. У групових чатах prompt схвалення та звіт надсилаються власнику приватно. Коли активна сесія використовує обв’язку OpenAI Codex, те саме схвалення також надсилає релевантний відгук Codex на сервери OpenAI, а завершена відповідь перелічує ідентифікатори сесій OpenClaw, ідентифікатори потоків Codex і команди `codex resume `. Див. [Експорт diagnostics](/uk/gateway/diagnostics). - - `/crestodian ` запускає помічник налаштування й ремонту Crestodian з DM власника. + - `/help` показує коротке довідкове зведення. + - `/commands` показує згенерований каталог команд. + - `/tools [compact|verbose]` показує, що поточний агент може використовувати просто зараз. + - `/status` показує стан виконання/середовища виконання, зокрема мітки `Execution`/`Runtime` і використання/квоту провайдера, коли доступно. + - `/diagnostics [note]` — це потік звіту підтримки лише для власника для помилок Gateway і запусків Codex harness. Він щоразу запитує явне схвалення exec перед запуском `openclaw gateway diagnostics export --json`; не схвалюйте діагностику правилом allow-all. Після схвалення він надсилає звіт, придатний для вставлення, з локальним шляхом пакета, зведенням маніфесту, примітками щодо приватності та відповідними ідентифікаторами сесій. У групових чатах запит на схвалення та звіт надсилаються власнику приватно. Коли активна сесія використовує OpenAI Codex harness, те саме схвалення також надсилає релевантний відгук Codex на сервери OpenAI, а завершена відповідь перелічує ідентифікатори сесій OpenClaw, ідентифікатори гілок Codex і команди `codex resume `. Див. [Експорт діагностики](/uk/gateway/diagnostics). + - `/crestodian ` запускає помічник налаштування та ремонту Crestodian із DM власника. - `/tasks` перелічує активні/нещодавні фонові завдання для поточної сесії. - `/context [list|detail|json]` пояснює, як збирається контекст. - - `/whoami` показує ваш sender id. Псевдонім: `/id`. - - `/usage off|tokens|full|cost` керує footer використання для кожної відповіді або друкує локальний підсумок cost. + - `/whoami` показує ваш ідентифікатор відправника. Псевдонім: `/id`. + - `/usage off|tokens|full|cost` керує нижнім колонтитулом використання для кожної відповіді або друкує локальне зведення вартості. - - `/skill [input]` запускає Skills за назвою. + - `/skill [input]` запускає skill за назвою. - `/allowlist [list|add|remove] ...` керує записами списку дозволених. Лише текст. - - `/approve ` вирішує prompts схвалення exec. + - `/approve ` вирішує запити на схвалення exec. - `/btw ` ставить побічне запитання без зміни майбутнього контексту сесії. Псевдонім: `/side`. Див. [BTW](/uk/tools/btw). - `/subagents list|kill|log|info|send|steer|spawn` керує запусками субагентів для поточного сеансу. - `/acp spawn|cancel|steer|close|sessions|status|set-mode|set|cwd|permissions|timeout|model|reset-options|doctor|install|help` керує сеансами ACP і параметрами середовища виконання. - - `/focus ` прив’язує поточний потік Discord або тему/розмову Telegram до цілі сеансу. + - `/focus ` прив’язує поточний потік Discord або тему/розмову Telegram до цільового сеансу. - `/unfocus` видаляє поточну прив’язку. - - `/agents` виводить агентів, прив’язаних до потоку, для поточного сеансу. - - `/kill ` перериває одного або всіх запущених субагентів. - - `/subagents steer ` надсилає керування запущеному субагенту. + - `/agents` показує агентів, прив’язаних до потоку, для поточного сеансу. + - `/kill ` перериває один або всі запущені субагенти. + - `/subagents steer ` надсилає керування запущеному субагенту. Див. [Керування](/uk/tools/steer). - - - `/config show|get|set|unset` читає або записує `openclaw.json`. Лише для власника. Потрібно `commands.config: true`. - - `/mcp show|get|set|unset` читає або записує конфігурацію сервера MCP, якою керує OpenClaw, у `mcp.servers`. Лише для власника. Потрібно `commands.mcp: true`. - - `/plugins list|inspect|show|get|install|enable|disable` перевіряє або змінює стан plugin. `/plugin` є псевдонімом. Запис лише для власника. Потрібно `commands.plugins: true`. - - `/debug show|set|unset|reset` керує перевизначеннями конфігурації лише для середовища виконання. Лише для власника. Потрібно `commands.debug: true`. - - `/restart` перезапускає OpenClaw, коли ввімкнено. Типово: ввімкнено; задайте `commands.restart: false`, щоб вимкнути. + + - `/config show|get|set|unset` читає або записує `openclaw.json`. Лише для власника. Потребує `commands.config: true`. + - `/mcp show|get|set|unset` читає або записує конфігурацію MCP-сервера, керовану OpenClaw, у `mcp.servers`. Лише для власника. Потребує `commands.mcp: true`. + - `/plugins list|inspect|show|get|install|enable|disable` перевіряє або змінює стан plugin. `/plugin` є псевдонімом. Запис лише для власника. Потребує `commands.plugins: true`. + - `/debug show|set|unset|reset` керує перевизначеннями конфігурації лише для середовища виконання. Лише для власника. Потребує `commands.debug: true`. + - `/restart` перезапускає OpenClaw, коли це ввімкнено. Типово: увімкнено; задайте `commands.restart: false`, щоб вимкнути. - `/send on|off|inherit` задає політику надсилання. Лише для власника. - `/tts on|off|status|chat|latest|provider|limit|summary|audio|help` керує TTS. Див. [TTS](/uk/tools/tts). - `/activation mention|always` задає режим активації групи. - - `/bash ` запускає команду оболонки хоста. Лише текст. Псевдонім: `! `. Потрібно `commands.bash: true` плюс allowlists `tools.elevated`. + - `/bash ` виконує команду оболонки хоста. Лише текст. Псевдонім: `! `. Потребує `commands.bash: true` плюс списки дозволів `tools.elevated`. - `!poll [sessionId]` перевіряє фонове завдання bash. - `!stop [sessionId]` зупиняє фонове завдання bash. -### Згенеровані команди закріплення +### Згенеровані команди стикування -Команди закріплення перемикають маршрут відповіді поточного сеансу на інший пов’язаний -канал. Див. [Закріплення каналів](/uk/concepts/channel-docking) для налаштування, -прикладів і усунення несправностей. +Команди стикування перемикають маршрут відповіді поточного сеансу на інший пов’язаний +канал. Див. [Стикування каналів](/uk/concepts/channel-docking), щоб дізнатися про налаштування, +приклади та усунення несправностей. -Команди закріплення генеруються з plugin каналів із підтримкою нативних команд. Поточний вбудований набір: +Команди стикування генеруються з plugin каналів із підтримкою нативних команд. Поточний вбудований набір: - `/dock-discord` (псевдонім: `/dock_discord`) - `/dock-mattermost` (псевдонім: `/dock_mattermost`) - `/dock-slack` (псевдонім: `/dock_slack`) - `/dock-telegram` (псевдонім: `/dock_telegram`) -Використовуйте команди закріплення з прямого чату, щоб перемкнути маршрут відповіді поточного сеансу на інший пов’язаний канал. Агент зберігає той самий контекст сеансу, але майбутні відповіді для цього сеансу доставляються вибраному учаснику каналу. +Використовуйте команди стикування з прямого чату, щоб перемкнути маршрут відповіді поточного сеансу на інший пов’язаний канал. Агент зберігає той самий контекст сеансу, але майбутні відповіді для цього сеансу доставляються вибраному учаснику каналу. -Команди закріплення потребують `session.identityLinks`. Відправник-джерело та цільовий учасник мають бути в одній групі ідентичностей, наприклад `["telegram:123", "discord:456"]`. Якщо користувач Telegram з id `123` надсилає `/dock_discord`, OpenClaw зберігає `lastChannel: "discord"` і `lastTo: "456"` в активному сеансі. Якщо відправника не пов’язано з учасником Discord, команда відповідає підказкою з налаштування замість переходу до звичайного чату. +Команди стикування потребують `session.identityLinks`. Відправник джерела і цільовий учасник мають бути в одній групі ідентичностей, наприклад `["telegram:123", "discord:456"]`. Якщо користувач Telegram з id `123` надсилає `/dock_discord`, OpenClaw зберігає `lastChannel: "discord"` і `lastTo: "456"` в активному сеансі. Якщо відправника не пов’язано з учасником Discord, команда відповідає підказкою щодо налаштування замість переходу до звичайного чату. -Закріплення змінює лише маршрут активного сеансу. Воно не створює облікові записи каналів, не надає доступ, не обходить allowlists каналів і не переносить історію транскрипту до іншого сеансу. Використовуйте `/dock-telegram`, `/dock-slack`, `/dock-mattermost` або іншу згенеровану команду закріплення, щоб знову перемкнути маршрут. +Стикування змінює лише маршрут активного сеансу. Воно не створює облікові записи каналів, не надає доступ, не обходить списки дозволів каналів і не переносить історію транскрипту в інший сеанс. Використовуйте `/dock-telegram`, `/dock-slack`, `/dock-mattermost` або іншу згенеровану команду стикування, щоб знову перемкнути маршрут. ### Команди вбудованих plugin Вбудовані plugins можуть додавати більше slash-команд. Поточні вбудовані команди в цьому репозиторії: -- `/dreaming [on|off|status|help]` перемикає dreaming пам’яті. Див. [Dreaming](/uk/concepts/dreaming). +- `/dreaming [on|off|status|help]` вмикає або вимикає Dreaming пам’яті. Див. [Dreaming](/uk/concepts/dreaming). - `/pair [qr|status|pending|approve|cleanup|notify]` керує потоком сполучення/налаштування пристрою. Див. [Сполучення](/uk/channels/pairing). - `/phone status|arm [duration]|disarm` тимчасово активує високоризикові команди телефонного вузла. -- `/voice status|list [limit]|set ` керує конфігурацією голосу Talk. У Discord назва нативної команди — `/talkvoice`. -- `/card ...` надсилає пресети насичених карток LINE. Див. [LINE](/uk/channels/line). -- `/codex status|models|threads|resume|compact|review|diagnostics|account|mcp|skills` перевіряє та керує вбудованим app-server harness Codex. Див. [Harness Codex](/uk/plugins/codex-harness). +- `/voice status|list [limit]|set ` керує конфігурацією голосу Talk. У Discord нативна назва команди — `/talkvoice`. +- `/card ...` надсилає пресети розширених карток LINE. Див. [LINE](/uk/channels/line). +- `/codex status|models|threads|resume|compact|review|diagnostics|account|mcp|skills` перевіряє та керує вбудованим серверним каркасом застосунку Codex. Див. [Каркас Codex](/uk/plugins/codex-harness). - Команди лише для QQBot: - `/bot-ping` - `/bot-version` @@ -246,88 +246,88 @@ Skills, які може викликати користувач, також до - `/skill [input]` завжди працює як універсальна точка входу. - skills також можуть з’являтися як прямі команди, наприклад `/prose`, коли skill/plugin їх реєструє. -- реєстрація нативних команд skills керується `commands.nativeSkills` і `channels..commands.nativeSkills`. -- специфікації команд можуть надавати `descriptionLocalizations` для нативних поверхонь, які підтримують локалізовані описи, зокрема Discord. +- реєстрація нативних команд skills контролюється `commands.nativeSkills` і `channels..commands.nativeSkills`. +- специфікації команд можуть надавати `descriptionLocalizations` для нативних поверхонь, що підтримують локалізовані описи, зокрема Discord. - + - Команди приймають необов’язковий `:` між командою та аргументами (наприклад, `/think: high`, `/send: on`, `/help:`). - `/new ` приймає псевдонім моделі, `provider/model` або назву провайдера (нечіткий збіг); якщо збігу немає, текст обробляється як тіло повідомлення. - - Для повного розподілу використання провайдера застосовуйте `openclaw status --usage`. + - Для повного розбору використання провайдера використовуйте `openclaw status --usage`. - `/allowlist add|remove` потребує `commands.config=true` і враховує `configWrites` каналу. - - У багатооблікових каналах `/allowlist --account `, націлений на конфігурацію, і `/config set channels..accounts....` також враховують `configWrites` цільового облікового запису. - - `/usage` керує нижнім колонтитулом використання для кожної відповіді; `/usage cost` друкує локальний підсумок вартості з журналів сеансів OpenClaw. + - У багатооблікових каналах `/allowlist --account ` для цільової конфігурації та `/config set channels..accounts....` також враховують `configWrites` цільового облікового запису. + - `/usage` керує футером використання для кожної відповіді; `/usage cost` друкує локальний підсумок витрат із журналів сеансів OpenClaw. - `/restart` увімкнено типово; задайте `commands.restart: false`, щоб вимкнути. - `/plugins install ` приймає ті самі специфікації plugin, що й `openclaw plugins install`: локальний шлях/архів, npm-пакет, `git:` або `clawhub:`, а потім запитує перезапуск Gateway, оскільки вихідні модулі plugin змінилися. - `/plugins enable|disable` оновлює конфігурацію plugin і запускає перезавантаження plugin Gateway для нових ходів агента. - - - Нативна команда лише для Discord: `/vc join|leave|status` керує голосовими каналами (недоступна як текст). `join` потребує guild і вибраного voice/stage channel. Потрібні `channels.discord.voice` і нативні команди. + + - Нативна команда лише для Discord: `/vc join|leave|status` керує голосовими каналами (недоступна як текст). `join` потребує гільдії та вибраного голосового/сценічного каналу. Потребує `channels.discord.voice` і нативних команд. - Команди прив’язки потоків Discord (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) потребують увімкнених ефективних прив’язок потоків (`session.threadBindings.enabled` та/або `channels.discord.threadBindings.enabled`). - - Довідник команд ACP і поведінка середовища виконання: [Агенти ACP](/uk/tools/acp-agents). + - Довідник команд ACP і поведінка середовища виконання: [агенти ACP](/uk/tools/acp-agents). - - `/verbose` призначено для налагодження та додаткової видимості; у звичайному використанні тримайте його **вимкненим**. - - `/trace` вужчий за `/verbose`: він показує лише рядки trace/debug, що належать plugin, і залишає звичайний verbose-шум інструментів вимкненим. - - `/fast on|off` зберігає перевизначення сеансу. Використовуйте опцію `inherit` в UI Sessions, щоб очистити його й повернутися до типових значень конфігурації. - - `/fast` залежить від провайдера: OpenAI/OpenAI Codex зіставляють його з `service_tier=priority` на нативних Responses endpoints, тоді як прямі публічні запити Anthropic, зокрема трафік, автентифікований через OAuth і надісланий до `api.anthropic.com`, зіставляють його з `service_tier=auto` або `standard_only`. Див. [OpenAI](/uk/providers/openai) і [Anthropic](/uk/providers/anthropic). - - Підсумки збоїв інструментів усе ще показуються, коли це доречно, але детальний текст збою включається лише коли `/verbose` має значення `on` або `full`. - - `/reasoning`, `/verbose` і `/trace` ризиковані в групових налаштуваннях: вони можуть розкрити внутрішні міркування, вивід інструментів або діагностику plugin, які ви не мали наміру показувати. Краще залишати їх вимкненими, особливо в групових чатах. + - `/verbose` призначено для налагодження та додаткової видимості; тримайте його **вимкненим** під час звичайного використання. + - `/trace` вужчий за `/verbose`: він показує лише рядки трасування/налагодження, що належать plugin, і залишає звичайний докладний шум інструментів вимкненим. + - `/fast on|off` зберігає перевизначення сеансу. Використовуйте опцію `inherit` в UI сеансів, щоб очистити її та повернутися до типових значень конфігурації. + - `/fast` залежить від провайдера: OpenAI/OpenAI Codex відображають його на `service_tier=priority` у нативних кінцевих точках Responses, тоді як прямі публічні запити Anthropic, зокрема трафік, автентифікований через OAuth і надісланий до `api.anthropic.com`, відображають його на `service_tier=auto` або `standard_only`. Див. [OpenAI](/uk/providers/openai) і [Anthropic](/uk/providers/anthropic). + - Підсумки збоїв інструментів усе ще показуються, коли це доречно, але докладний текст збою включається лише коли `/verbose` має значення `on` або `full`. + - `/reasoning`, `/verbose` і `/trace` ризиковані в групових налаштуваннях: вони можуть розкрити внутрішнє міркування, вивід інструментів або діагностику plugin, які ви не мали наміру показувати. Краще залишати їх вимкненими, особливо в групових чатах. - - `/model` негайно зберігає нову модель сеансу. - - Якщо агент простоює, наступний запуск використовує її відразу. - - Якщо запуск уже активний, OpenClaw позначає live-перемикання як очікуване й перезапускає нову модель лише в чистій точці повторної спроби. - - Якщо активність інструментів або вивід відповіді вже почалися, очікуване перемикання може залишатися в черзі до пізнішої можливості повторної спроби або наступного ходу користувача. - - У локальному TUI `/crestodian [request]` повертає зі звичайного TUI агента до Crestodian. Це окремо від режиму порятунку каналу повідомлень і не надає віддалених повноважень конфігурації. + - `/model` одразу зберігає нову модель сеансу. + - Якщо агент бездіяльний, наступний запуск використовує її відразу. + - Якщо запуск уже активний, OpenClaw позначає живе перемикання як очікуване й перезапускає в новій моделі лише в чистій точці повторної спроби. + - Якщо активність інструментів або вивід відповіді вже почалися, очікуване перемикання може залишатися в черзі до пізнішої можливості повторної спроби або до наступного ходу користувача. + - У локальному TUI `/crestodian [request]` повертає зі звичайного TUI агента до Crestodian. Це окремо від режиму порятунку каналу повідомлень і не надає віддалені повноваження конфігурації. - - **Швидкий шлях:** повідомлення лише з командами від відправників з allowlist обробляються негайно (обхід черги + моделі). - - **Фільтрація згадок у групах:** повідомлення лише з командами від відправників з allowlist обходять вимоги щодо згадок. - - **Вбудовані скорочення (лише відправники з allowlist):** певні команди також працюють, коли вбудовані у звичайне повідомлення, і вилучаються до того, як модель побачить решту тексту. - - Приклад: `hey /status` запускає відповідь зі статусом, а решта тексту продовжує звичайний потік. + - **Швидкий шлях:** повідомлення лише з командами від відправників зі списку дозволів обробляються негайно (обхід черги + моделі). + - **Обмеження згадками в групі:** повідомлення лише з командами від відправників зі списку дозволів обходять вимоги згадування. + - **Вбудовані скорочення (лише відправники зі списку дозволів):** деякі команди також працюють, коли вбудовані у звичайне повідомлення, і видаляються перед тим, як модель побачить решту тексту. + - Приклад: `hey /status` запускає відповідь зі статусом, а решта тексту продовжує проходити звичайним потоком. - Наразі: `/help`, `/commands`, `/status`, `/whoami` (`/id`). - Несанкціоновані повідомлення лише з командами мовчки ігноруються, а вбудовані токени `/...` обробляються як звичайний текст. - - **Команди Skills:** skills `user-invocable` доступні як slash-команди. Назви санітизуються до `a-z0-9_` (макс. 32 символи); колізії отримують числові суфікси (наприклад, `_2`). + - **Команди Skills:** skills `user-invocable` доступні як slash-команди. Назви очищуються до `a-z0-9_` (макс. 32 символи); колізії отримують числові суфікси (наприклад, `_2`). - `/skill [input]` запускає skill за назвою (корисно, коли обмеження нативних команд не дозволяють окремі команди для кожного skill). - - Типово команди skills пересилаються до моделі як звичайний запит. - - Skills можуть необов’язково оголошувати `command-dispatch: tool`, щоб маршрутизувати команду безпосередньо до інструмента (детерміновано, без моделі). + - Типово команди skills переспрямовуються до моделі як звичайний запит. + - Skills можуть необов’язково оголошувати `command-dispatch: tool`, щоб маршрутизувати команду напряму до інструмента (детерміновано, без моделі). - Приклад: `/prose` (plugin OpenProse) — див. [OpenProse](/uk/prose). - - **Аргументи нативних команд:** Discord використовує автодоповнення для динамічних опцій (і меню кнопок, коли ви пропускаєте обов’язкові аргументи). Telegram і Slack показують меню кнопок, коли команда підтримує варіанти вибору, а ви пропускаєте аргумент. Динамічні варіанти обчислюються відносно цільової моделі сеансу, тому специфічні для моделі опції, як-от рівні `/think`, дотримуються перевизначення `/model` цього сеансу. + - **Аргументи нативних команд:** Discord використовує автодоповнення для динамічних опцій (і меню кнопок, коли ви пропускаєте обов’язкові аргументи). Telegram і Slack показують меню кнопок, коли команда підтримує варіанти вибору, а ви пропускаєте аргумент. Динамічні варіанти визначаються відносно цільової моделі сеансу, тому специфічні для моделі опції, як-от рівні `/think`, слідують перевизначенню `/model` цього сеансу. ## `/tools` -`/tools` відповідає на питання про середовище виконання, а не про конфігурацію: **що цей агент може використовувати прямо зараз у цій розмові**. +`/tools` відповідає на запитання про середовище виконання, а не про конфігурацію: **що цей агент може використовувати прямо зараз у цій розмові**. - Типовий `/tools` компактний і оптимізований для швидкого перегляду. - `/tools verbose` додає короткі описи. -- Поверхні нативних команд, що підтримують аргументи, надають той самий перемикач режиму `compact|verbose`. -- Результати прив’язані до сеансу, тому зміна агента, каналу, потоку, авторизації відправника або моделі може змінити вивід. -- `/tools` включає інструменти, які фактично доступні під час виконання, зокрема основні інструменти, підключені інструменти plugin та інструменти, що належать каналу. +- Поверхні нативних команд, які підтримують аргументи, надають той самий перемикач режиму `compact|verbose`. +- Результати обмежені сеансом, тому зміна агента, каналу, потоку, авторизації відправника або моделі може змінити вивід. +- `/tools` включає інструменти, які фактично доступні під час виконання, зокрема основні інструменти, підключені інструменти plugin та інструменти, що належать каналам. -Для редагування профілів і перевизначень використовуйте панель Tools у Control UI або поверхні конфігурації/каталогу, а не сприймайте `/tools` як статичний каталог. +Для редагування профілю й перевизначень використовуйте панель інструментів Control UI або поверхні конфігурації/каталогу замість того, щоб розглядати `/tools` як статичний каталог. ## Поверхні використання (що де показується) -- **Використання/квота провайдера** (приклад: "Claude 80% left") відображається в `/status` для поточного провайдера моделі, коли ввімкнено відстеження використання. OpenClaw нормалізує вікна провайдера до `% left`; для MiniMax поля відсотків лише із залишком інвертуються перед показом, а відповіді `model_remains` надають перевагу запису чат-моделі плюс позначці плану з тегом моделі. -- **Рядки токенів/кешу** в `/status` можуть відступати до останнього запису використання з транскрипта, коли live-знімок сесії неповний. Наявні ненульові live-значення все одно мають пріоритет, а відступ до транскрипта також може відновити мітку активної runtime-моделі плюс більший prompt-орієнтований підсумок, коли збережені підсумки відсутні або менші. -- **Виконання проти runtime:** `/status` повідомляє `Execution` для ефективного шляху пісочниці та `Runtime` для того, хто фактично запускає сесію: `OpenClaw Pi Default`, `OpenAI Codex`, CLI-бекенд або ACP-бекенд. -- **Токени/вартість на відповідь** керуються `/usage off|tokens|full` (додається до звичайних відповідей). -- `/model status` стосується **моделей/автентифікації/ендпоїнтів**, а не використання. +- **Використання/квота провайдера** (приклад: "Claude 80% left") відображається в `/status` для поточного провайдера моделі, коли ввімкнено відстеження використання. OpenClaw нормалізує вікна провайдера до `% left`; для MiniMax поля відсотків лише із залишком інвертуються перед показом, а відповіді `model_remains` надають перевагу запису chat-моделі плюс позначеній моделлю мітці плану. +- **Рядки токенів/кешу** в `/status` можуть повертатися до останнього запису використання з транскрипту, коли live-знімок сесії неповний. Наявні ненульові live-значення все одно мають пріоритет, а резерв із транскрипту також може відновити мітку активної runtime-моделі плюс більший prompt-орієнтований підсумок, коли збережені підсумки відсутні або менші. +- **Виконання проти runtime:** `/status` повідомляє `Execution` для ефективного шляху sandbox і `Runtime` для того, хто фактично запускає сесію: `OpenClaw Pi Default`, `OpenAI Codex`, CLI-бекенд або ACP-бекенд. +- **Токени/вартість на відповідь** керуються через `/usage off|tokens|full` (додається до звичайних відповідей). +- `/model status` стосується **моделей/автентифікації/endpoint-ів**, а не використання. ## Вибір моделі (`/model`) -`/model` реалізовано як директиву. +`/model` реалізовано як directive. Приклади: @@ -342,14 +342,14 @@ Skills, які може викликати користувач, також до Примітки: -- `/model` і `/model list` показують компактний нумерований вибір (сімейство моделей + доступні провайдери). -- У Discord `/model` і `/models` відкривають інтерактивний вибір зі спадними списками провайдера й моделі плюс кроком «Надіслати». -- `/model <#>` вибирає з цього списку (і за можливості надає перевагу поточному провайдеру). -- `/model status` показує детальний вигляд, зокрема налаштований ендпоїнт провайдера (`baseUrl`) і режим API (`api`), коли вони доступні. +- `/model` і `/model list` показують компактний нумерований picker (сімейство моделей + доступні провайдери). +- У Discord `/model` і `/models` відкривають інтерактивний picker із випадаючими списками провайдера й моделі та кроком Submit. +- `/model <#>` вибирає з цього picker (і надає перевагу поточному провайдеру, коли можливо). +- `/model status` показує детальний вигляд, зокрема налаштований endpoint провайдера (`baseUrl`) і режим API (`api`), коли вони доступні. ## Перевизначення для налагодження -`/debug` дає змогу задавати **лише runtime** перевизначення конфігурації (у памʼяті, не на диску). Тільки для власника. Вимкнено за замовчуванням; увімкніть через `commands.debug: true`. +`/debug` дає змогу задавати **лише runtime** перевизначення конфігурації (у памʼяті, не на диску). Лише для власника. Типово вимкнено; увімкніть за допомогою `commands.debug: true`. Приклади: @@ -367,7 +367,7 @@ Skills, які може викликати користувач, також до ## Вивід трасування Plugin -`/trace` дає змогу перемикати **привʼязані до сесії рядки трасування/налагодження plugin** без увімкнення повного докладного режиму. +`/trace` дає змогу перемикати **обмежені сесією рядки трасування/налагодження Plugin** без увімкнення повного докладного режиму. Приклади: @@ -380,15 +380,15 @@ Skills, які може викликати користувач, також до Примітки: - `/trace` без аргументу показує поточний стан трасування сесії. -- `/trace on` вмикає рядки трасування plugin для поточної сесії. +- `/trace on` вмикає рядки трасування Plugin для поточної сесії. - `/trace off` знову вимикає їх. -- Рядки трасування plugin можуть зʼявлятися в `/status` і як подальше діагностичне повідомлення після звичайної відповіді асистента. +- Рядки трасування Plugin можуть зʼявлятися в `/status` і як подальше діагностичне повідомлення після звичайної відповіді помічника. - `/trace` не замінює `/debug`; `/debug` і далі керує лише runtime перевизначеннями конфігурації. -- `/trace` не замінює `/verbose`; звичайний докладний вивід інструментів/стану все ще належить до `/verbose`. +- `/trace` не замінює `/verbose`; звичайний докладний вивід інструментів/статусу й далі належить до `/verbose`. ## Оновлення конфігурації -`/config` записує у вашу конфігурацію на диску (`openclaw.json`). Тільки для власника. Вимкнено за замовчуванням; увімкніть через `commands.config: true`. +`/config` записує у вашу конфігурацію на диску (`openclaw.json`). Лише для власника. Типово вимкнено; увімкніть за допомогою `commands.config: true`. Приклади: @@ -406,7 +406,7 @@ Skills, які може викликати користувач, також до ## Оновлення MCP -`/mcp` записує керовані OpenClaw визначення MCP-серверів у `mcp.servers`. Тільки для власника. Вимкнено за замовчуванням; увімкніть через `commands.mcp: true`. +`/mcp` записує керовані OpenClaw визначення серверів MCP у `mcp.servers`. Лише для власника. Типово вимкнено; увімкніть за допомогою `commands.mcp: true`. Приклади: @@ -423,7 +423,7 @@ Skills, які може викликати користувач, також до ## Оновлення Plugin -`/plugins` дає операторам змогу переглядати виявлені plugins і перемикати ввімкнення в конфігурації. Потоки лише для читання можуть використовувати `/plugin` як псевдонім. Вимкнено за замовчуванням; увімкніть через `commands.plugins: true`. +`/plugins` дає операторам змогу переглядати знайдені plugins і перемикати ввімкнення в конфігурації. Потоки лише для читання можуть використовувати `/plugin` як псевдонім. Типово вимкнено; увімкніть за допомогою `commands.plugins: true`. Приклади: @@ -436,10 +436,10 @@ Skills, які може викликати користувач, також до ``` -- `/plugins list` і `/plugins show` використовують справжнє виявлення plugin для поточного робочого простору плюс конфігурацію на диску. +- `/plugins list` і `/plugins show` використовують реальне виявлення Plugin у поточному workspace плюс конфігурацію на диску. - `/plugins install` встановлює з ClawHub, npm, git, локальних каталогів і архівів. -- `/plugins enable|disable` оновлює лише конфігурацію plugin; це не встановлює й не видаляє plugins. -- Зміни ввімкнення та вимкнення гаряче перезавантажують runtime-поверхні plugin Gateway для нових ходів агента; встановлення запитує перезапуск Gateway, бо вихідні модулі plugin змінилися. +- `/plugins enable|disable` оновлює лише конфігурацію Plugin; це не встановлює й не видаляє plugins. +- Зміни ввімкнення та вимкнення гаряче перезавантажують runtime-поверхні Plugin Gateway для нових ходів agent; install запитує перезапуск Gateway, тому що вихідні модулі Plugin змінилися. @@ -447,18 +447,18 @@ Skills, які може викликати користувач, також до - - **Текстові команди** виконуються у звичайній чат-сесії (приватні повідомлення спільно використовують `main`, групи мають власну сесію). - - **Нативні команди** використовують ізольовані сесії: + - **Текстові команди** виконуються у звичайній chat-сесії (DM спільно використовують `main`, групи мають власну сесію). + - **Native-команди** використовують ізольовані сесії: - Discord: `agent::discord:slash:` - Slack: `agent::slack:slash:` (префікс налаштовується через `channels.slack.slashCommand.sessionPrefix`) - - Telegram: `telegram:slash:` (цілить у чат-сесію через `CommandTargetSessionKey`) - - **`/stop`** цілить в активну чат-сесію, щоб вона могла перервати поточний запуск. + - Telegram: `telegram:slash:` (цілиться в chat-сесію через `CommandTargetSessionKey`) + - **`/stop`** цілиться в активну chat-сесію, щоб вона могла перервати поточний запуск. - `channels.slack.slashCommand` усе ще підтримується для однієї команди стилю `/openclaw`. Якщо ви вмикаєте `commands.native`, потрібно створити по одній slash-команді Slack для кожної вбудованої команди (ті самі назви, що й у `/help`). Меню аргументів команд для Slack доставляються як ефемерні кнопки Block Kit. + `channels.slack.slashCommand` і далі підтримується для однієї команди в стилі `/openclaw`. Якщо ви вмикаєте `commands.native`, потрібно створити по одній slash-команді Slack для кожної вбудованої команди (ті самі назви, що й у `/help`). Меню аргументів команд для Slack доставляються як ephemeral кнопки Block Kit. - Нативний виняток Slack: зареєструйте `/agentstatus` (не `/status`), бо Slack резервує `/status`. Текстова `/status` усе ще працює в повідомленнях Slack. + Виняток native у Slack: зареєструйте `/agentstatus` (не `/status`), тому що Slack резервує `/status`. Текстова `/status` і далі працює в повідомленнях Slack. @@ -467,15 +467,15 @@ Skills, які може викликати користувач, також до `/btw` — це швидке **побічне запитання** про поточну сесію. `/side` є псевдонімом. -На відміну від звичайного чату: +На відміну від звичайного chat: - воно використовує поточну сесію як фоновий контекст, - воно виконується як окремий одноразовий виклик **без інструментів**, - воно не змінює майбутній контекст сесії, -- воно не записується в історію транскрипта, -- воно доставляється як live-побічний результат замість звичайного повідомлення асистента. +- воно не записується в історію транскрипту, +- воно доставляється як live побічний результат замість звичайного повідомлення помічника. -Це робить `/btw` корисним, коли потрібне тимчасове уточнення, поки основне завдання триває. +Це робить `/btw` корисним, коли вам потрібне тимчасове уточнення, поки основне завдання триває. Приклад: @@ -484,10 +484,10 @@ Skills, які може викликати користувач, також до /side what changed while the main run continued? ``` -Див. [Побічні запитання BTW](/uk/tools/btw), щоб отримати повну поведінку та деталі UX клієнта. +Див. [Побічні запитання BTW](/uk/tools/btw), щоб переглянути повну поведінку й подробиці UX клієнта. ## Повʼязане -- [Створення skills](/uk/tools/creating-skills) +- [Створення Skills](/uk/tools/creating-skills) - [Skills](/uk/tools/skills) - [Конфігурація Skills](/uk/tools/skills-config) diff --git a/docs/uk/tools/steer.md b/docs/uk/tools/steer.md new file mode 100644 index 000000000..c7f6ef12f --- /dev/null +++ b/docs/uk/tools/steer.md @@ -0,0 +1,74 @@ +--- +read_when: + - Використання /steer або /tell, коли агент уже працює + - Порівняння /steer з /queue steer + - Вибір, чи скеровувати поточний запуск, субагента чи сеанс ACP +sidebarTitle: Steer +summary: Керуйте активним виконанням без зміни режиму черги +title: Спрямовуйте +x-i18n: + generated_at: "2026-05-03T22:25:45Z" + model: gpt-5.5 + provider: openai + source_hash: 71e1c80c0eea86d5c3c29513d3ed0675c04779fc9c6ee3b8a76c4bedaa264d22 + source_path: tools/steer.md + workflow: 16 +--- + +`/steer` надсилає вказівки до вже активного запуску. Це для моментів «скоригувати цей запуск, поки він ще виконується», а не для початку нового ходу. + +## Поточна сесія + +Використовуйте `/steer` верхнього рівня, щоб націлитися на активний запуск для поточної сесії: + +```text +/steer prefer the smaller patch and keep the tests focused +/tell summarize before making the next tool call +``` + +Поведінка: + +- Націлюється лише на активний запуск поточної сесії. +- Працює незалежно від режиму `/queue` сесії. +- Не запускає новий запуск, коли сесія неактивна. +- Відповідає попередженням, коли немає активного запуску, який можна спрямувати. +- Використовує шлях спрямування активного runtime, тож модель бачить вказівки на наступній підтримуваній межі runtime. + +## Спрямування проти черги + +`/queue steer` змінює поведінку звичайних вхідних повідомлень, коли вони надходять під час активного запуску. `/steer ` — це явна команда, яка намагається вставити повідомлення цієї команди в активний запуск на наступній підтримуваній межі runtime, незалежно від збереженого налаштування `/queue`. + +Використовуйте: + +- `/steer `, коли хочете спрямувати активний запуск просто зараз. +- `/queue steer`, коли хочете, щоб майбутні звичайні повідомлення типово спрямовували активні запуски. +- `/queue collect` або `/queue followup`, коли нові повідомлення мають чекати пізнішого ходу замість спрямування активного запуску. + +Про режими черги та резервну поведінку див. [Черга команд](/uk/concepts/queue) і [Черга спрямування](/uk/concepts/queue-steering). + +## Субагенти + +Використовуйте `/subagents steer`, коли ціль — дочірній запуск: + +```text +/subagents steer 2 focus only on the API surface +``` + +`/steer` верхнього рівня не вибирає субагента за id або індексом у списку. Він завжди націлюється на активний запуск поточної сесії. Див. [Субагенти](/uk/tools/subagents) для id субагентів, міток і команд керування. + +## Сесії ACP + +Використовуйте `/acp steer`, коли ціль — сесія середовища ACP: + +```text +/acp steer --session agent:main:acp:codex tighten the repro +``` + +Див. [Агенти ACP](/uk/tools/acp-agents) для вибору сесії ACP і поведінки runtime. + +## Пов’язане + +- [Slash-команди](/uk/tools/slash-commands) +- [Черга команд](/uk/concepts/queue) +- [Черга спрямування](/uk/concepts/queue-steering) +- [Субагенти](/uk/tools/subagents) diff --git a/docs/uk/tools/subagents.md b/docs/uk/tools/subagents.md index b44da55a4..d9037069c 100644 --- a/docs/uk/tools/subagents.md +++ b/docs/uk/tools/subagents.md @@ -1,40 +1,40 @@ --- read_when: - Вам потрібна фонова або паралельна робота через агента - - Ви змінюєте політику sessions_spawn або інструмента для субагентів - - Ви впроваджуєте або усуваєте несправності сеансів субагентів, прив’язаних до потоків + - Ви змінюєте політику інструмента sessions_spawn або під-агента + - Ви впроваджуєте або усуваєте несправності в сеансах субагентів, прив’язаних до потоку sidebarTitle: Sub-agents -summary: Запускайте ізольовані фонові запуски агентів, які повідомляють результати назад у чат запитувача +summary: Запускайте ізольовані фонові запуски агента, які повідомляють результати назад у чат запитувача title: Субагенти x-i18n: - generated_at: "2026-05-03T21:42:13Z" + generated_at: "2026-05-03T22:25:54Z" model: gpt-5.5 provider: openai - source_hash: e09370a96c3af4752a774aba5db62e38b0afd78bc5e105597d977cb130597daf + source_hash: d0df39e06b952def3eb0b296f36c7dc8c0b0a115785d865236a970c5d453fc37 source_path: tools/subagents.md workflow: 16 --- -Субагенти — це фонові запуски агентів, створені з наявного запуску агента. +Sub-agents — це фонові запуски агентів, породжені з наявного запуску агента. Вони працюють у власному сеансі (`agent::subagent:`) і, -коли завершуються, **оголошують** свій результат назад у канал чату -запитувача. Кожен запуск субагента відстежується як +після завершення, **оголошують** свій результат назад у канал чату +запитувача. Кожен запуск sub-agent відстежується як [фонове завдання](/uk/automation/tasks). Основні цілі: -- Паралелізувати роботу "дослідження / довге завдання / повільний інструмент" без блокування основного запуску. -- Типово ізолювати субагентів (розділення сеансів + необов'язкова пісочниця). -- Зробити поверхню інструментів стійкою до неправильного використання: субагенти типово **не** отримують інструменти сеансу. -- Підтримувати налаштовувану глибину вкладеності для шаблонів оркестраторів. +- Паралелізувати роботу з "дослідження / довге завдання / повільний інструмент", не блокуючи основний запуск. +- Ізолювати sub-agents за замовчуванням (розділення сеансів + необов’язкова пісочниця). +- Зробити поверхню інструментів складною для неправильного використання: sub-agents за замовчуванням **не** отримують інструменти сеансу. +- Підтримувати налаштовувану глибину вкладеності для патернів оркестратора. -**Примітка щодо вартості:** кожен субагент типово має власний контекст і використання токенів. Для важких або повторюваних завдань задайте дешевшу модель для субагентів і залиште основного агента на якіснішій моделі. Налаштуйте через `agents.defaults.subagents.model` або перевизначення для окремого агента. Коли дочірньому запуску справді потрібен поточний транскрипт запитувача, агент може запросити `context: "fork"` для цього одного створення. Сеанси субагентів, прив'язані до гілки, типово мають `context: "fork"`, бо вони відгалужують поточну розмову в подальшу гілку. +**Примітка щодо вартості:** кожен sub-agent за замовчуванням має власний контекст і використання токенів. Для важких або повторюваних завдань задайте дешевшу модель для sub-agents і залиште основного агента на якіснішій моделі. Налаштовуйте через `agents.defaults.subagents.model` або перевизначення для окремого агента. Коли дочірньому агенту справді потрібен поточний транскрипт запитувача, агент може запросити `context: "fork"` для цього одного породження. Сеанси subagent, прив’язані до треду, за замовчуванням використовують `context: "fork"`, бо вони відгалужують поточну розмову в подальший тред. -## Слеш-команда +## Slash-команда -Використовуйте `/subagents`, щоб переглядати або контролювати запуски субагентів для **поточного +Використовуйте `/subagents`, щоб переглядати або керувати запусками sub-agent для **поточного сеансу**: ```text @@ -47,16 +47,16 @@ x-i18n: /subagents spawn [--model ] [--thinking ] ``` -Використовуйте верхньорівневу `/steer `, щоб скеровувати активний запуск поточного сеансу запитувача. Використовуйте `/subagents steer `, коли ціль — дочірній запуск. +Використовуйте верхньорівневу [`/steer `](/uk/tools/steer), щоб спрямувати активний запуск поточного сеансу запитувача. Використовуйте `/subagents steer `, коли ціллю є дочірній запуск. -`/subagents info` показує метадані запуску (статус, часові позначки, ідентифікатор сеансу, +`/subagents info` показує метадані запуску (статус, часові позначки, id сеансу, шлях до транскрипту, очищення). Використовуйте `sessions_history` для обмеженого, -відфільтрованого з міркувань безпеки перегляду відтворення; переглядайте шлях до транскрипту на диску, коли вам потрібен сирий повний транскрипт. +відфільтрованого з міркувань безпеки перегляду пригадування; перевіряйте шлях до транскрипту на диску, коли потрібен сирий повний транскрипт. -### Елементи керування прив'язкою гілок +### Керування прив’язкою до треду -Ці команди працюють у каналах, які підтримують постійні прив'язки гілок. -Див. [Канали з підтримкою гілок](#thread-supporting-channels) нижче. +Ці команди працюють у каналах, які підтримують постійні прив’язки до тредів. +Див. [Канали з підтримкою тредів](#thread-supporting-channels) нижче. ```text /focus @@ -66,225 +66,225 @@ x-i18n: /session max-age ``` -### Поведінка створення +### Поведінка породження -`/subagents spawn` запускає фонового субагента як користувацьку команду (а не -внутрішню ретрансляцію) і надсилає одне фінальне оновлення про завершення назад у +`/subagents spawn` запускає фоновий sub-agent як команду користувача (а не внутрішню +ретрансляцію) і надсилає одне фінальне оновлення про завершення назад у чат запитувача, коли запуск завершується. - - - Команда створення не блокує виконання; вона одразу повертає ідентифікатор запуску. - - Після завершення субагент оголошує повідомлення з підсумком/результатом назад у канал чату запитувача. - - Завершення доставляється за ініціативою системи. Після створення **не** опитуйте `/subagents list`, `sessions_list` або `sessions_history` у циклі лише для очікування завершення; переглядайте статус тільки на вимогу для налагодження або втручання. - - Після завершення OpenClaw намагається закрити відстежувані вкладки браузера/процеси, відкриті цим сеансом субагента, перш ніж продовжиться потік очищення оголошення. + + - Команда породження не блокує виконання; вона одразу повертає id запуску. + - Після завершення sub-agent оголошує повідомлення з підсумком/результатом назад у канал чату запитувача. + - Завершення працює за push-моделлю. Після породження **не** опитуйте `/subagents list`, `sessions_list` або `sessions_history` у циклі лише для очікування завершення; перевіряйте статус лише на вимогу для налагодження або втручання. + - Після завершення OpenClaw у режимі best-effort закриває відстежувані вкладки браузера/процеси, відкриті цим сеансом sub-agent, перш ніж потік очищення оголошення продовжиться. - - - OpenClaw спершу пробує пряме доставлення `agent` зі стабільним ключем ідемпотентності. - - Якщо пряме доставлення не вдається, він повертається до маршрутизації через чергу. - - Якщо маршрутизація через чергу все ще недоступна, оголошення повторюється з коротким експоненційним відступом перед остаточною відмовою. - - Доставлення завершення зберігає визначений маршрут запитувача: маршрути завершення, прив'язані до гілки або розмови, мають пріоритет, коли доступні; якщо джерело завершення надає лише канал, OpenClaw заповнює відсутню ціль/обліковий запис із визначеного маршруту сеансу запитувача (`lastChannel` / `lastTo` / `lastAccountId`), тож пряме доставлення все одно працює. + + - OpenClaw спочатку пробує пряму доставку `agent` зі стабільним ключем ідемпотентності. + - Якщо пряма доставка не вдається, він переходить до маршрутизації через чергу. + - Якщо маршрутизація через чергу все ще недоступна, оголошення повторюється з коротким експоненційним backoff перед остаточною відмовою. + - Доставка завершення зберігає розв’язаний маршрут запитувача: маршрути завершення, прив’язані до треду або розмови, мають пріоритет, коли доступні; якщо джерело завершення надає лише канал, OpenClaw заповнює відсутню ціль/обліковий запис із розв’язаного маршруту сеансу запитувача (`lastChannel` / `lastTo` / `lastAccountId`), щоб пряма доставка все одно працювала. - - Передавання завершення до сеансу запитувача — це внутрішній контекст, згенерований середовищем виконання - (а не текст, написаний користувачем), і він містить: + + Передавання завершення до сеансу запитувача — це згенерований під час виконання + внутрішній контекст (не текст, створений користувачем), який містить: - - `Result` — найновіший видимий текст відповіді `assistant`, інакше очищений найновіший текст tool/toolResult. Запуски, що завершилися невдало в кінцевому стані, не використовують повторно захоплений текст відповіді. + - `Result` — найновіший видимий текст відповіді `assistant`, інакше очищений найновіший текст tool/toolResult. Термінально невдалі запуски не повторно використовують захоплений текст відповіді. - `Status` — `completed successfully` / `failed` / `timed out` / `unknown`. - - Стисла статистика середовища виконання/токенів. - - Інструкцію доставлення, яка наказує агенту-запитувачу переписати відповідь звичайним голосом асистента (а не пересилати сирі внутрішні метадані). + - Компактну статистику виконання/токенів. + - Інструкцію доставки, яка каже агенту-запитувачу переписати відповідь звичайним голосом асистента (а не пересилати сирі внутрішні метадані). - - - `--model` і `--thinking` перевизначають типові значення для цього конкретного запуску. - - Використовуйте `info`/`log`, щоб переглядати подробиці й вивід після завершення. - - `/subagents spawn` — це одноразовий режим (`mode: "run"`). Для постійних сеансів, прив'язаних до гілки, використовуйте `sessions_spawn` з `thread: true` і `mode: "session"`. - - Для сеансів обв'язки ACP (Claude Code, Gemini CLI, OpenCode або явно вказаний Codex ACP/acpx) використовуйте `sessions_spawn` з `runtime: "acp"`, коли інструмент оголошує це середовище виконання. Див. [модель доставлення ACP](/uk/tools/acp-agents#delivery-model) під час налагодження завершень або циклів агент-до-агента. Коли Plugin `codex` увімкнено, керування чатом/гілкою Codex має віддавати перевагу `/codex ...` над ACP, якщо користувач явно не просить ACP/acpx. - - OpenClaw приховує `runtime: "acp"`, доки ACP не ввімкнено, запитувач не перебуває в пісочниці, і не завантажено бекенд-Plugin, як-от `acpx`. `runtime: "acp"` очікує зовнішній ідентифікатор обв'язки ACP або запис `agents.list[]` з `runtime.type="acp"`; використовуйте типове середовище виконання субагента для звичайних агентів конфігурації OpenClaw з `agents_list`. + + - `--model` і `--thinking` перевизначають стандартні значення для цього конкретного запуску. + - Використовуйте `info`/`log`, щоб переглянути деталі та вивід після завершення. + - `/subagents spawn` — це одноразовий режим (`mode: "run"`). Для постійних сеансів, прив’язаних до треду, використовуйте `sessions_spawn` з `thread: true` і `mode: "session"`. + - Для сеансів ACP harness (Claude Code, Gemini CLI, OpenCode або явний Codex ACP/acpx) використовуйте `sessions_spawn` з `runtime: "acp"`, коли інструмент оголошує цю runtime. Див. [модель доставки ACP](/uk/tools/acp-agents#delivery-model) під час налагодження завершень або циклів agent-to-agent. Коли Plugin `codex` увімкнено, керування чатом/тредами Codex має віддавати перевагу `/codex ...` над ACP, якщо користувач явно не просить ACP/acpx. + - OpenClaw приховує `runtime: "acp"`, доки ACP не увімкнено, запитувач не перебуває в пісочниці, а backend Plugin, наприклад `acpx`, не завантажено. `runtime: "acp"` очікує зовнішній id ACP harness або запис `agents.list[]` з `runtime.type="acp"`; використовуйте стандартну runtime sub-agent для звичайних агентів конфігурації OpenClaw з `agents_list`. ## Режими контексту -Нативні субагенти запускаються ізольовано, якщо викликач явно не просить відгалузити +Нативні sub-agents стартують ізольовано, якщо викликач явно не просить відгалузити поточний транскрипт. -| Режим | Коли його використовувати | Поведінка | +| Режим | Коли використовувати | Поведінка | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | -| `isolated` | Свіже дослідження, незалежна реалізація, повільна робота інструмента або будь-що, що можна описати в тексті завдання | Створює чистий дочірній транскрипт. Це типове значення, яке зменшує використання токенів. | -| `fork` | Робота, що залежить від поточної розмови, попередніх результатів інструментів або нюансованих інструкцій, уже наявних у транскрипті запитувача | Відгалужує транскрипт запитувача в дочірній сеанс перед стартом дочірнього запуску. | +| `isolated` | Нове дослідження, незалежна реалізація, повільна інструментальна робота або будь-що, що можна коротко описати в тексті завдання | Створює чистий дочірній транскрипт. Це стандартний режим, який зменшує використання токенів. | +| `fork` | Робота, що залежить від поточної розмови, попередніх результатів інструментів або нюансованих інструкцій, уже наявних у транскрипті запитувача | Відгалужує транскрипт запитувача в дочірній сеанс перед запуском дочірнього агента. | -Використовуйте `fork` ощадливо. Він призначений для делегування, чутливого до контексту, а не як -заміна написанню чіткого промпта завдання. +Використовуйте `fork` помірковано. Він призначений для делегування, чутливого до контексту, а не як +заміна чіткому промпту завдання. ## Інструмент: `sessions_spawn` -Запускає запуск субагента з `deliver: false` на глобальній доріжці `subagent`, -потім виконує крок оголошення й публікує відповідь оголошення в канал чату +Запускає sub-agent з `deliver: false` на глобальній лінії `subagent`, +потім виконує крок оголошення та публікує відповідь оголошення в канал чату запитувача. Доступність залежить від ефективної політики інструментів викликача. Профілі `coding` і -`full` типово надають `sessions_spawn`. Профіль `messaging` -цього не робить; додайте `tools.alsoAllow: ["sessions_spawn", "sessions_yield", +`full` за замовчуванням відкривають `sessions_spawn`. Профіль `messaging` +не відкриває; додайте `tools.alsoAllow: ["sessions_spawn", "sessions_yield", "subagents"]` або використовуйте `tools.profile: "coding"` для агентів, які мають делегувати -роботу. Політики каналу/групи, провайдера, пісочниці та дозволів/заборон для окремого агента можуть +роботу. Політики каналу/групи, провайдера, пісочниці та allow/deny для окремого агента можуть усе ще прибрати інструмент після етапу профілю. Використовуйте `/tools` з того самого сеансу, щоб підтвердити ефективний список інструментів. -**Типові значення:** +**Стандартні значення:** -- **Модель:** успадковує викликача, якщо ви не задасте `agents.defaults.subagents.model` (або `agents.list[].subagents.model` для окремого агента); явне `sessions_spawn.model` усе одно має пріоритет. -- **Мислення:** успадковує викликача, якщо ви не задасте `agents.defaults.subagents.thinking` (або `agents.list[].subagents.thinking` для окремого агента); явне `sessions_spawn.thinking` усе одно має пріоритет. -- **Тайм-аут запуску:** якщо `sessions_spawn.runTimeoutSeconds` пропущено, OpenClaw використовує `agents.defaults.subagents.runTimeoutSeconds`, коли його задано; інакше повертається до `0` (без тайм-ауту). +- **Модель:** успадковує викликача, якщо не задано `agents.defaults.subagents.model` (або `agents.list[].subagents.model` для окремого агента); явне `sessions_spawn.model` усе одно має пріоритет. +- **Thinking:** успадковує викликача, якщо не задано `agents.defaults.subagents.thinking` (або `agents.list[].subagents.thinking` для окремого агента); явне `sessions_spawn.thinking` усе одно має пріоритет. +- **Таймаут запуску:** якщо `sessions_spawn.runTimeoutSeconds` пропущено, OpenClaw використовує `agents.defaults.subagents.runTimeoutSeconds`, коли задано; інакше повертається до `0` (без таймауту). ### Параметри інструмента - Опис завдання для субагента. + Опис завдання для sub-agent. - Необов'язкова зрозуміла для людини мітка. + Необов’язкова людиночитна мітка. - Створити під іншим ідентифікатором агента, коли це дозволено `subagents.allowAgents`. + Породжувати під іншим id агента, коли це дозволено `subagents.allowAgents`. - `acp` призначено лише для зовнішніх обв'язок ACP (`claude`, `droid`, `gemini`, `opencode` або явно запитаний Codex ACP/acpx) і для записів `agents.list[]`, у яких `runtime.type` є `acp`. + `acp` призначено лише для зовнішніх ACP harnesses (`claude`, `droid`, `gemini`, `opencode` або явно запитаного Codex ACP/acpx) і для записів `agents.list[]`, у яких `runtime.type` дорівнює `acp`. - Лише ACP. Відновлює наявний сеанс обв'язки ACP, коли `runtime: "acp"`; ігнорується для нативних створень субагентів. + Лише ACP. Відновлює наявний сеанс ACP harness, коли `runtime: "acp"`; ігнорується для нативних породжень sub-agent. - Лише ACP. Транслює вивід запуску ACP у батьківський сеанс, коли `runtime: "acp"`; пропустіть для нативних створень субагентів. + Лише ACP. Транслює вивід запуску ACP до батьківського сеансу, коли `runtime: "acp"`; пропускайте для нативних породжень sub-agent. - Перевизначає модель субагента. Недійсні значення пропускаються, і субагент запускається на типовій моделі з попередженням у результаті інструмента. + Перевизначає модель sub-agent. Некоректні значення пропускаються, а sub-agent запускається на стандартній моделі з попередженням у результаті інструмента. - Перевизначає рівень мислення для запуску субагента. + Перевизначає рівень thinking для запуску sub-agent. - Типово дорівнює `agents.defaults.subagents.runTimeoutSeconds`, коли задано, інакше `0`. Коли задано, запуск субагента переривається через N секунд. + За замовчуванням дорівнює `agents.defaults.subagents.runTimeoutSeconds`, коли задано, інакше `0`. Коли задано, запуск sub-agent переривається після N секунд. - Коли `true`, запитує прив'язку гілки каналу для цього сеансу субагента. + Коли `true`, запитує прив’язку треду каналу для цього сеансу sub-agent. - Якщо `thread: true` і `mode` пропущено, типовим стає `session`. `mode: "session"` вимагає `thread: true`. + Якщо `thread: true` і `mode` пропущено, стандартним стає `session`. `mode: "session"` потребує `thread: true`. - `"delete"` архівує одразу після оголошення (усе ще зберігає транскрипт через перейменування). + `"delete"` архівує одразу після оголошення (транскрипт усе одно зберігається через перейменування). - `require` відхиляє створення, якщо цільове дочірнє середовище виконання не в пісочниці. + `require` відхиляє породження, якщо цільова дочірня runtime не перебуває в пісочниці. - `fork` відгалужує поточний транскрипт запитувача в дочірній сеанс. Лише нативні субагенти. Створення, прив'язані до гілки, типово використовують `fork`; створення без гілки типово використовують `isolated`. + `fork` відгалужує поточний транскрипт запитувача в дочірній сеанс. Лише нативні sub-agents. Породження, прив’язані до треду, за замовчуванням використовують `fork`; породження без треду — `isolated`. -`sessions_spawn` **не** приймає параметри доставлення каналу (`target`, -`channel`, `to`, `threadId`, `replyTo`, `transport`). Для доставлення використовуйте -`message`/`sessions_send` зі створеного запуску. +`sessions_spawn` **не** приймає параметри доставки каналом (`target`, +`channel`, `to`, `threadId`, `replyTo`, `transport`). Для доставки використовуйте +`message`/`sessions_send` із породженого запуску. -## Сеанси, прив'язані до гілки +## Сеанси, прив’язані до треду -Коли для каналу ввімкнено прив'язки гілок, субагент може залишатися прив'язаним -до гілки, щоб подальші повідомлення користувача в цій гілці продовжували маршрутизуватися до -того самого сеансу субагента. +Коли для каналу ввімкнено прив’язки до тредів, sub-agent може залишатися прив’язаним +до треду, щоб подальші повідомлення користувача в цьому треді й надалі маршрутизувалися до +того самого сеансу sub-agent. -### Канали з підтримкою гілок +### Канали з підтримкою тредів **Discord** наразі є єдиним підтримуваним каналом. Він підтримує -постійні сеанси субагентів, прив'язані до гілки (`sessions_spawn` з -`thread: true`), ручні елементи керування гілками (`/focus`, `/unfocus`, `/agents`, -`/session idle`, `/session max-age`) та ключі адаптера +постійні сеанси subagent, прив’язані до тредів (`sessions_spawn` з +`thread: true`), ручне керування тредами (`/focus`, `/unfocus`, `/agents`, +`/session idle`, `/session max-age`) і ключі адаптера `channels.discord.threadBindings.enabled`, `channels.discord.threadBindings.idleHours`, -`channels.discord.threadBindings.maxAgeHours` і +`channels.discord.threadBindings.maxAgeHours` та `channels.discord.threadBindings.spawnSessions`. ### Швидкий потік - - `sessions_spawn` з `thread: true` (і необов'язково `mode: "session"`). + + `sessions_spawn` з `thread: true` (і необов’язково `mode: "session"`). - - OpenClaw створює або прив'язує гілку до цілі цього сеансу в активному каналі. + + OpenClaw створює або прив’язує тред до цільового сеансу в активному каналі. - - Відповіді й подальші повідомлення в цій гілці маршрутизуються до прив'язаного сеансу. + + Відповіді та подальші повідомлення в цьому треді маршрутизуються до прив’язаного сеансу. - - Використовуйте `/session idle`, щоб переглядати/оновлювати автоматичне зняття фокуса через неактивність, і - `/session max-age`, щоб контролювати жорстку верхню межу. + + Використовуйте `/session idle`, щоб переглянути/оновити автоматичне скасування фокуса через неактивність, і + `/session max-age`, щоб керувати жорстким лімітом. - - Використовуйте `/unfocus`, щоб від'єднати вручну. + + Використовуйте `/unfocus`, щоб від’єднати вручну. -### Ручні елементи керування +### Ручне керування | Команда | Дія | | ------------------ | --------------------------------------------------------------------- | -| `/focus ` | Прив'язати поточний потік (або створити його) до цілі субагента/сеансу | -| `/unfocus` | Прибрати прив'язку для поточного прив'язаного потоку | -| `/agents` | Показати активні запуски та стан прив'язки (`thread:` або `unbound`) | -| `/session idle` | Переглянути/оновити автоматичне скасування фокуса через бездіяльність (лише сфокусовані прив'язані потоки) | -| `/session max-age` | Переглянути/оновити жорстке обмеження (лише сфокусовані прив'язані потоки) | +| `/focus ` | Прив’язати поточний потік (або створити його) до цілі під-агента/сеансу | +| `/unfocus` | Видалити прив’язку для поточного прив’язаного потоку | +| `/agents` | Перелічити активні запуски та стан прив’язки (`thread:` або `unbound`) | +| `/session idle` | Переглянути/оновити автоматичне зняття фокуса через бездіяльність (лише сфокусовані прив’язані потоки) | +| `/session max-age` | Переглянути/оновити жорстке обмеження часу (лише сфокусовані прив’язані потоки) | ### Перемикачі конфігурації - **Глобальне значення за замовчуванням:** `session.threadBindings.enabled`, `session.threadBindings.idleHours`, `session.threadBindings.maxAgeHours`. -- **Перевизначення каналу та ключі автоматичної прив'язки під час створення** залежать від адаптера. Див. [Канали з підтримкою потоків](#thread-supporting-channels) вище. +- **Перевизначення каналу та ключі автоматичної прив’язки під час створення** залежать від адаптера. Див. [Канали з підтримкою потоків](#thread-supporting-channels) вище. Див. [Довідник конфігурації](/uk/gateway/configuration-reference) і -[Slash-команди](/uk/tools/slash-commands), щоб дізнатися поточні деталі адаптерів. +[Slash-команди](/uk/tools/slash-commands) для поточних деталей адаптерів. ### Список дозволених - Список ідентифікаторів агентів, на які можна націлюватися через явний `agentId` (`["*"]` дозволяє будь-який). За замовчуванням: лише агент-запитувач. Якщо ви задаєте список і все одно хочете, щоб запитувач створював себе з `agentId`, включіть ідентифікатор запитувача до списку. + Список ідентифікаторів агентів, на які можна націлюватися через явний `agentId` (`["*"]` дозволяє будь-який). За замовчуванням: лише агент-запитувач. Якщо ви задаєте список і все одно хочете, щоб запитувач міг створювати самого себе з `agentId`, додайте ідентифікатор запитувача до списку. Типовий список дозволених цільових агентів, який використовується, коли агент-запитувач не задає власний `subagents.allowAgents`. - Блокувати виклики `sessions_spawn`, які пропускають `agentId` (примусово вимагає явного вибору профілю). Перевизначення для окремого агента: `agents.list[].subagents.requireAgentId`. + Блокувати виклики `sessions_spawn`, які пропускають `agentId` (примушує явно вибирати профіль). Перевизначення для окремого агента: `agents.list[].subagents.requireAgentId`. -Якщо сеанс запитувача ізольований у пісочниці, `sessions_spawn` відхиляє цілі, +Якщо сеанс запитувача працює в пісочниці, `sessions_spawn` відхиляє цілі, які запускалися б без пісочниці. ### Виявлення -Використовуйте `agents_list`, щоб побачити, які ідентифікатори агентів зараз дозволені для -`sessions_spawn`. Відповідь містить ефективну -модель кожного переліченого агента та вбудовані метадані середовища виконання, щоб виклики могли відрізняти PI, сервер застосунку Codex +Використовуйте `agents_list`, щоб побачити, які ідентифікатори агентів наразі дозволені для +`sessions_spawn`. Відповідь містить ефективну модель кожного переліченого агента +та вбудовані метадані середовища виконання, щоб виклики могли відрізняти PI, сервер застосунку Codex та інші налаштовані нативні середовища виконання. ### Автоархівація -- Сеанси субагентів автоматично архівуються після `agents.defaults.subagents.archiveAfterMinutes` (за замовчуванням `60`). -- Архівування використовує `sessions.delete` і перейменовує транскрипт на `*.deleted.` (у тій самій папці). -- `cleanup: "delete"` архівує одразу після сповіщення (транскрипт усе одно зберігається через перейменування). -- Автоархівація виконується за принципом найкращих зусиль; очікувані таймери втрачаються, якщо Gateway перезапускається. -- `runTimeoutSeconds` **не** виконує автоархівацію; він лише зупиняє запуск. Сеанс лишається до автоархівації. +- Сеанси під-агентів автоматично архівуються після `agents.defaults.subagents.archiveAfterMinutes` (за замовчуванням `60`). +- Архівація використовує `sessions.delete` і перейменовує транскрипт на `*.deleted.` (у тій самій папці). +- `cleanup: "delete"` архівує одразу після оголошення (транскрипт усе одно зберігається через перейменування). +- Автоархівація виконується за принципом найкращого зусилля; очікувані таймери втрачаються, якщо Gateway перезапускається. +- `runTimeoutSeconds` **не** виконує автоархівацію; він лише зупиняє запуск. Сеанс залишається до автоархівації. - Автоархівація однаково застосовується до сеансів глибини 1 і глибини 2. -- Очищення браузера відокремлене від архівного очищення: відстежувані вкладки/процеси браузера за найкращими зусиллями закриваються після завершення запуску, навіть якщо запис транскрипта/сеансу зберігається. +- Очищення браузера відокремлене від очищення архіву: відстежувані вкладки/процеси браузера закриваються за принципом найкращого зусилля після завершення запуску, навіть якщо транскрипт/запис сеансу зберігається. -## Вкладені субагенти +## Вкладені під-агенти -За замовчуванням субагенти не можуть створювати власних субагентів +За замовчуванням під-агенти не можуть створювати власних під-агентів (`maxSpawnDepth: 1`). Задайте `maxSpawnDepth: 2`, щоб увімкнути один рівень -вкладеності — **патерн оркестратора**: основний → субагент-оркестратор → -робочі субсубагенти. +вкладеності — **шаблон оркестратора**: основний → під-агент-оркестратор → +робочі під-під-агенти. ```json5 { @@ -303,153 +303,153 @@ x-i18n: ### Рівні глибини -| Глибина | Форма ключа сеансу | Роль | Може створювати? | +| Глибина | Форма ключа сеансу | Роль | Може створювати? | | ----- | -------------------------------------------- | --------------------------------------------- | ---------------------------- | | 0 | `agent::main` | Основний агент | Завжди | -| 1 | `agent::subagent:` | Субагент (оркестратор, коли дозволено глибину 2) | Лише якщо `maxSpawnDepth >= 2` | -| 2 | `agent::subagent::subagent:` | Субсубагент (листовий робітник) | Ніколи | +| 1 | `agent::subagent:` | Під-агент (оркестратор, коли дозволена глибина 2) | Лише якщо `maxSpawnDepth >= 2` | +| 2 | `agent::subagent::subagent:` | Під-під-агент (листовий робітник) | Ніколи | -### Ланцюжок сповіщень +### Ланцюг оголошень -Результати передаються назад ланцюжком: +Результати передаються назад угору ланцюгом: -1. Робітник глибини 2 завершує роботу → сповіщає свого батька (оркестратора глибини 1). -2. Оркестратор глибини 1 отримує сповіщення, синтезує результати, завершує роботу → сповіщає основний сеанс. -3. Основний агент отримує сповіщення та доставляє його користувачу. +1. Робітник глибини 2 завершується → оголошує своєму батьківському сеансу (оркестратору глибини 1). +2. Оркестратор глибини 1 отримує оголошення, синтезує результати, завершується → оголошує основному. +3. Основний агент отримує оголошення та доставляє його користувачу. -Кожен рівень бачить лише сповіщення від своїх прямих дочірніх елементів. +Кожен рівень бачить лише оголошення від своїх безпосередніх дочірніх сеансів. -**Операційні вказівки:** запускайте дочірню роботу один раз і чекайте подій +**Операційні настанови:** запускайте дочірню роботу один раз і чекайте подій завершення замість побудови циклів опитування навколо `sessions_list`, -`sessions_history`, `/subagents list` або команд сну `exec`. -`sessions_list` і `/subagents list` утримують зв'язки дочірніх сеансів -сфокусованими на живій роботі — живі дочірні елементи залишаються приєднаними, завершені дочірні елементи -залишаються видимими в короткому недавньому вікні, а застарілі посилання лише зі сховища на дочірні елементи +`sessions_history`, `/subagents list` або команд `exec` зі сном. +`sessions_list` і `/subagents list` утримують зв’язки дочірніх сеансів +зосередженими на живій роботі — живі дочірні сеанси залишаються прикріпленими, завершені дочірні сеанси +залишаються видимими протягом короткого недавнього вікна, а застарілі посилання лише зі сховища ігноруються після завершення їхнього вікна свіжості. Це запобігає тому, щоб старі метадані `spawnedBy` / -`parentSessionKey` повторно відроджували примарні дочірні елементи після -перезапуску. Якщо подія завершення дочірнього елемента надходить після того, як ви вже надіслали +`parentSessionKey` воскресали примарні дочірні сеанси після +перезапуску. Якщо подія завершення дочірнього сеансу надходить після того, як ви вже надіслали фінальну відповідь, правильне подальше повідомлення — точний мовчазний токен `NO_REPLY` / `no_reply`. ### Політика інструментів за глибиною -- Роль і область керування записуються в метадані сеансу під час створення. Це запобігає випадковому повторному отриманню привілеїв оркестратора пласкими або відновленими ключами сеансу. -- **Глибина 1 (оркестратор, коли `maxSpawnDepth >= 2`):** отримує `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, щоб керувати своїми дочірніми елементами. Інші інструменти сеансів/системи лишаються забороненими. -- **Глибина 1 (лист, коли `maxSpawnDepth == 1`):** без інструментів сеансів (поточна поведінка за замовчуванням). -- **Глибина 2 (листовий робітник):** без інструментів сеансів — `sessions_spawn` завжди заборонено на глибині 2. Не може створювати подальші дочірні елементи. +- Роль і область керування записуються в метадані сеансу під час створення. Це не дає плоским або відновленим ключам сеансів випадково знову отримати привілеї оркестратора. +- **Глибина 1 (оркестратор, коли `maxSpawnDepth >= 2`):** отримує `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, щоб керувати своїми дочірніми сеансами. Інші інструменти сеансу/системи залишаються забороненими. +- **Глибина 1 (лист, коли `maxSpawnDepth == 1`):** без інструментів сеансу (поточна типова поведінка). +- **Глибина 2 (листовий робітник):** без інструментів сеансу — `sessions_spawn` завжди заборонено на глибині 2. Не може створювати подальших дочірніх сеансів. ### Ліміт створення для окремого агента -Кожен сеанс агента (на будь-якій глибині) може мати щонайбільше `maxChildrenPerAgent` -(за замовчуванням `5`) активних дочірніх елементів одночасно. Це запобігає неконтрольованому розгалуженню +Кожен сеанс агента (на будь-якій глибині) може мати не більше `maxChildrenPerAgent` +(за замовчуванням `5`) активних дочірніх сеансів одночасно. Це запобігає неконтрольованому розгортанню від одного оркестратора. ### Каскадна зупинка -Зупинка оркестратора глибини 1 автоматично зупиняє всі його дочірні елементи глибини 2: +Зупинка оркестратора глибини 1 автоматично зупиняє всі його дочірні сеанси глибини 2: -- `/stop` в основному чаті зупиняє всіх агентів глибини 1 і каскадно зупиняє їхні дочірні елементи глибини 2. -- `/subagents kill ` зупиняє конкретного субагента й каскадно зупиняє його дочірні елементи. -- `/subagents kill all` зупиняє всіх субагентів для запитувача та виконує каскадну зупинку. +- `/stop` в основному чаті зупиняє всіх агентів глибини 1 і каскадно зупиняє їхні дочірні сеанси глибини 2. +- `/subagents kill ` зупиняє конкретного під-агента і каскадно зупиняє його дочірні сеанси. +- `/subagents kill all` зупиняє всіх під-агентів для запитувача і виконує каскадну зупинку. ## Автентифікація -Автентифікація субагента визначається за **ідентифікатором агента**, а не за типом сеансу: +Автентифікація під-агента визначається за **ідентифікатором агента**, а не за типом сеансу: -- Ключ сеансу субагента — `agent::subagent:`. +- Ключ сеансу під-агента: `agent::subagent:`. - Сховище автентифікації завантажується з `agentDir` цього агента. -- Профілі автентифікації основного агента об'єднуються як **резервні**; профілі агента перевизначають основні профілі у разі конфліктів. +- Профілі автентифікації основного агента об’єднуються як **резервний варіант**; профілі агента перевизначають основні профілі у разі конфліктів. -Об'єднання є адитивним, тому основні профілі завжди доступні як -резервні. Повністю ізольована автентифікація для кожного агента поки не підтримується. +Об’єднання є додавальним, тому основні профілі завжди доступні як +резервні. Повністю ізольована автентифікація для кожного агента ще не підтримується. -## Сповіщення +## Оголошення -Субагенти звітують через крок сповіщення: +Під-агенти звітують назад через крок оголошення: -- Крок сповіщення виконується всередині сеансу субагента (не сеансу запитувача). -- Якщо субагент відповідає точно `ANNOUNCE_SKIP`, нічого не публікується. -- Якщо останній текст асистента є точним мовчазним токеном `NO_REPLY` / `no_reply`, вивід сповіщення пригнічується, навіть якщо раніше був видимий прогрес. +- Крок оголошення виконується всередині сеансу під-агента (не сеансу запитувача). +- Якщо під-агент відповідає точно `ANNOUNCE_SKIP`, нічого не публікується. +- Якщо останній текст асистента є точним мовчазним токеном `NO_REPLY` / `no_reply`, вивід оголошення пригнічується, навіть якщо раніше був видимий прогрес. Доставка залежить від глибини запитувача: - Сеанси запитувача верхнього рівня використовують подальший виклик `agent` із зовнішньою доставкою (`deliver=true`). -- Вкладені сеанси субагентів-запитувачів отримують внутрішню подальшу ін'єкцію (`deliver=false`), щоб оркестратор міг синтезувати дочірні результати в межах сеансу. -- Якщо вкладений сеанс субагента-запитувача зник, OpenClaw повертається до запитувача цього сеансу, коли він доступний. +- Вкладені сеанси під-агента-запитувача отримують внутрішнє подальше вставлення (`deliver=false`), щоб оркестратор міг синтезувати результати дочірніх сеансів у межах сеансу. +- Якщо вкладений сеанс під-агента-запитувача зник, OpenClaw повертається до запитувача цього сеансу, коли він доступний. Для сеансів запитувача верхнього рівня пряма доставка в режимі завершення спочатку -вирішує будь-який прив'язаний маршрут розмови/потоку та перевизначення hook, а потім заповнює +розв’язує будь-який маршрут прив’язаної розмови/потоку та перевизначення hook, а потім заповнює відсутні поля цілі каналу зі збереженого маршруту сеансу запитувача. -Це утримує завершення в правильному чаті/темі, навіть коли джерело завершення +Це утримує завершення у правильному чаті/темі, навіть коли джерело завершення ідентифікує лише канал. -Агрегація завершень дочірніх елементів обмежена поточним запуском запитувача під час -побудови вкладених результатів завершення, запобігаючи витоку застарілих дочірніх -виводів із попередніх запусків у поточне сповіщення. Відповіді сповіщень зберігають +Агрегація завершення дочірніх сеансів обмежена поточним запуском запитувача під час +побудови вкладених результатів завершення, запобігаючи просочуванню виводів дочірніх сеансів +із попередніх застарілих запусків у поточне оголошення. Відповіді оголошення зберігають маршрутизацію потоку/теми, коли вона доступна в адаптерах каналів. -### Контекст сповіщення +### Контекст оголошення -Контекст сповіщення нормалізується до стабільного внутрішнього блока події: +Контекст оголошення нормалізується до стабільного внутрішнього блока події: -| Поле | Джерело | +| Поле | Джерело | | -------------- | ------------------------------------------------------------------------------------------------------------- | | Джерело | `subagent` або `cron` | | Ідентифікатори сеансу | Ключ/ідентифікатор дочірнього сеансу | -| Тип | Тип сповіщення + мітка завдання | -| Статус | Виведено з результату середовища виконання (`success`, `error`, `timeout` або `unknown`) — **не** виводиться з тексту моделі | -| Вміст результату | Останній видимий текст асистента, інакше санітизований останній текст tool/toolResult | -| Подальша дія | Інструкція, що описує, коли відповідати, а коли лишатися мовчазним | +| Тип | Тип оголошення + мітка завдання | +| Стан | Виведено з результату середовища виконання (`success`, `error`, `timeout` або `unknown`) — **не** виводиться з тексту моделі | +| Вміст результату | Останній видимий текст асистента, інакше очищений останній текст інструмента/toolResult | +| Подальша дія | Інструкція, що описує, коли відповідати, а коли залишатися мовчазним | -Термінальні невдалі запуски повідомляють статус помилки без повторного відтворення захопленого -тексту відповіді. У разі тайм-ауту, якщо дочірній елемент устиг лише виконати виклики інструментів, сповіщення -може стиснути цю історію в короткий підсумок часткового прогресу замість -повторного відтворення сирого виводу інструментів. +Термінальні невдалі запуски повідомляють стан помилки без повторного відтворення захопленого +тексту відповіді. У разі тайм-ауту, якщо дочірній сеанс встиг лише виконати виклики інструментів, оголошення +може згорнути цю історію в короткий підсумок часткового прогресу замість +відтворення сирого виводу інструментів. ### Рядок статистики -Корисні навантаження сповіщень містять рядок статистики в кінці (навіть коли обгорнуті): +Корисні навантаження оголошень містять рядок статистики в кінці (навіть коли загорнуті): - Час виконання (наприклад, `runtime 5m12s`). - Використання токенів (вхідні/вихідні/усього). -- Орієнтовна вартість, коли налаштовано ціни моделі (`models.providers.*.models[].cost`). -- `sessionKey`, `sessionId` і шлях транскрипта, щоб основний агент міг отримати історію через `sessions_history` або переглянути файл на диску. +- Орієнтовна вартість, коли налаштовано ціни моделей (`models.providers.*.models[].cost`). +- `sessionKey`, `sessionId` і шлях транскрипту, щоб основний агент міг отримати історію через `sessions_history` або переглянути файл на диску. -Внутрішні метадані призначені лише для оркестрації; відповіді для користувачів +Внутрішні метадані призначені лише для оркестрації; відповіді для користувача слід переписувати звичайним голосом асистента. ### Чому варто надавати перевагу `sessions_history` `sessions_history` — безпечніший шлях оркестрації: -- Згадування асистента спочатку нормалізується: теги мислення видаляються; каркаси `` / `` видаляються; XML-блоки корисного навантаження викликів інструментів у простому тексті (``, ``, ``, ``) видаляються, включно з обрізаними корисними навантаженнями, які ніколи не закриваються коректно; понижені каркаси викликів/результатів інструментів і маркери історичного контексту видаляються; витеклі керівні токени моделі (`<|assistant|>`, інші ASCII `<|...|>`, повної ширини `<｜...｜>`) видаляються; некоректний XML викликів інструментів MiniMax видаляється. +- Спогади асистента спочатку нормалізуються: теги мислення видаляються; каркас `` / `` видаляється; XML-блоки корисного навантаження викликів інструментів у plain-text (``, ``, ``, ``) видаляються, включно з обрізаними корисними навантаженнями, які ніколи коректно не закриваються; знижений каркас викликів/результатів інструментів і маркери історичного контексту видаляються; витеклі керівні токени моделі (`<|assistant|>`, інші ASCII `<|...|>`, повноширинні `<｜...｜>`) видаляються; некоректний XML викликів інструментів MiniMax видаляється. - Текст, схожий на облікові дані/токени, редагується. - Довгі блоки можуть обрізатися. -- Дуже великі історії можуть відкидати старіші рядки або замінювати завеликий рядок на `[sessions_history omitted: message too large]`. -- Перегляд сирого транскрипта на диску є резервним варіантом, коли потрібен повний побайтово точний транскрипт. +- Дуже великі історії можуть відкидати старіші рядки або замінювати надмірно великий рядок на `[sessions_history omitted: message too large]`. +- Перегляд сирого транскрипту на диску є резервним варіантом, коли потрібен повний побайтово точний транскрипт. ## Політика інструментів -Субагенти спочатку використовують той самий профіль і конвеєр політики інструментів, що й батьківський +Під-агенти спочатку використовують той самий профіль і конвеєр політики інструментів, що й батьківський або цільовий агент. Після цього OpenClaw застосовує шар обмежень -субагента. +під-агента. -Без обмежувального `tools.profile` субагенти отримують **усі інструменти, крім -інструментів сеансів** і системних інструментів: +Без обмежувального `tools.profile` під-агенти отримують **усі інструменти, крім +інструментів сеансу** та системних інструментів: - `sessions_list` - `sessions_history` - `sessions_send` - `sessions_spawn` -`sessions_history` і тут лишається обмеженим, санітизованим поданням згадування — -це не сирий дамп транскрипта. +`sessions_history` тут також залишається обмеженим, очищеним поданням пригадування — це +не сирий дамп транскрипту. -Коли `maxSpawnDepth >= 2`, субагенти-оркестратори глибини 1 додатково +Коли `maxSpawnDepth >= 2`, під-агенти-оркестратори глибини 1 додатково отримують `sessions_spawn`, `subagents`, `sessions_list` і -`sessions_history`, щоб керувати своїми дочірніми елементами. +`sessions_history`, щоб керувати своїми дочірніми сеансами. ### Перевизначення через конфігурацію @@ -475,11 +475,11 @@ x-i18n: } ``` -`tools.subagents.tools.allow` — це остаточний фільтр лише дозволеного. Він може звузити -вже визначений набір інструментів, але не може **додати назад** інструмент, вилучений +`tools.subagents.tools.allow` — це фінальний фільтр лише для дозволеного. Він може звузити +вже визначений набір інструментів, але не може **повернути** інструмент, вилучений через `tools.profile`. Наприклад, `tools.profile: "coding"` включає `web_search`/`web_fetch`, але не інструмент `browser`. Щоб дозволити -під-агентам із профілем coding використовувати автоматизацію браузера, додайте browser на +субагентам із coding-профілем використовувати автоматизацію браузера, додайте browser на етапі профілю: ```json5 @@ -491,12 +491,12 @@ x-i18n: } ``` -Використовуйте `agents.list[].tools.alsoAllow: ["browser"]` для окремого агента, коли автоматизацію браузера має отримати лише один -агент. +Використовуйте `agents.list[].tools.alsoAllow: ["browser"]` для окремого агента, коли лише один +агент має отримати автоматизацію браузера. ## Паралельність -Під-агенти використовують окрему чергу виконання в межах процесу: +Субагенти використовують окрему внутрішньопроцесну чергу: - **Назва черги:** `subagent` - **Паралельність:** `agents.defaults.subagents.maxConcurrent` (за замовчуванням `8`) @@ -504,47 +504,47 @@ x-i18n: ## Живучість і відновлення OpenClaw не вважає відсутність `endedAt` постійним доказом того, що -під-агент досі активний. Незавершені запуски, старші за вікно застарілого запуску, -перестають враховуватися як активні/очікувані в `/subagents list`, зведеннях стану, -блокуванні завершення нащадків і перевірках паралельності для окремої сесії. +субагент досі активний. Незавершені запуски, старші за вікно застарілого запуску, +перестають враховуватися як активні/очікувані в `/subagents list`, зведеннях статусу, +блокуванні завершення нащадків і перевірках паралельності для сесії. -Після перезапуску Gateway застарілі незавершені відновлені запуски обрізаються, якщо +Після перезапуску Gateway застарілі незавершені відновлені запуски видаляються, якщо їхня дочірня сесія не позначена як `abortedLastRun: true`. Такі -перервані перезапуском дочірні сесії залишаються придатними для відновлення через потік -відновлення осиротілих під-агентів, який надсилає синтетичне повідомлення resume перед +дочірні сесії, перервані перезапуском, лишаються придатними до відновлення через потік +відновлення осиротілих субагентів, який надсилає синтетичне повідомлення відновлення перед очищенням маркера переривання. Автоматичне відновлення після перезапуску обмежене для кожної дочірньої сесії. Якщо той самий -дочірній під-агент неодноразово приймається для відновлення осиротілих у межах -швидкого вікна повторного зависання, OpenClaw зберігає tombstone відновлення в цій -сесії та припиняє автоматично відновлювати її під час наступних перезапусків. Запустіть +дочірній субагент неодноразово приймається для відновлення осиротілої сесії в межах +швидкого вікна повторного зависання, OpenClaw зберігає tombstone відновлення для цієї +сесії та припиняє автоматично відновлювати її під час наступних перезапусків. Виконайте `openclaw tasks maintenance --apply`, щоб узгодити запис завдання, або `openclaw doctor --fix`, щоб очистити застарілі прапорці перерваного відновлення в сесіях із tombstone. -Якщо створення під-агента завершується помилкою Gateway `PAIRING_REQUIRED` / -`scope-upgrade`, перевірте викликача RPC перед редагуванням стану спарювання. +Якщо створення субагента завершується помилкою Gateway `PAIRING_REQUIRED` / +`scope-upgrade`, перевірте викликача RPC перед редагуванням стану сполучення. Внутрішня координація `sessions_spawn` має підключатися як -`client.id: "gateway-client"` з `client.mode: "backend"` через прямий -local loopback з автентифікацією за спільним токеном/паролем; цей шлях не залежить від -базового рівня області paired-device для CLI. Віддалені викликачі, явні -`deviceIdentity`, явні шляхи device-token і клієнти browser/node -досі потребують звичайного схвалення пристрою для підвищення області. +`client.id: "gateway-client"` із `client.mode: "backend"` через пряму +автентифікацію спільним токеном/паролем через loopback; цей шлях не залежить від +базового рівня області дії сполученого пристрою CLI. Віддаленим викликачам, явним +`deviceIdentity`, явним шляхам device-token і клієнтам browser/node +усе ще потрібне звичайне схвалення пристрою для підвищення області дії. ## Зупинка -- Надсилання `/stop` у чаті запитувача перериває сесію запитувача й зупиняє всі активні запуски під-агентів, створені з неї, каскадно переходячи до вкладених дочірніх елементів. -- `/subagents kill ` зупиняє конкретного під-агента й каскадно зупиняє його дочірні елементи. +- Надсилання `/stop` у чаті запитувача перериває сесію запитувача та зупиняє всі активні запуски субагентів, створені з неї, каскадно поширюючись на вкладених нащадків. +- `/subagents kill ` зупиняє конкретного субагента та каскадно поширюється на його нащадків. ## Обмеження -- Оголошення під-агента виконується за принципом **best-effort**. Якщо gateway перезапускається, очікувана робота "announce back" втрачається. -- Під-агенти досі спільно використовують ресурси того самого процесу gateway; розглядайте `maxConcurrent` як запобіжний клапан. -- `sessions_spawn` завжди неблокувальний: він одразу повертає `{ status: "accepted", runId, childSessionKey }`. -- Контекст під-агента вставляє лише `AGENTS.md` + `TOOLS.md` (без `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` або `BOOTSTRAP.md`). -- Максимальна глибина вкладеності становить 5 (діапазон `maxSpawnDepth`: 1–5). Для більшості випадків використання рекомендовано глибину 2. +- Оголошення субагента виконується **за найкращих зусиль**. Якщо gateway перезапускається, очікувана робота "announce back" втрачається. +- Субагенти все ще спільно використовують ресурси того самого процесу gateway; розглядайте `maxConcurrent` як запобіжний клапан. +- `sessions_spawn` завжди неблокувальний: він негайно повертає `{ status: "accepted", runId, childSessionKey }`. +- Контекст субагента вставляє лише `AGENTS.md` + `TOOLS.md` (без `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` або `BOOTSTRAP.md`). +- Максимальна глибина вкладення становить 5 (діапазон `maxSpawnDepth`: 1–5). Для більшості випадків використання рекомендовано глибину 2. - `maxChildrenPerAgent` обмежує кількість активних дочірніх елементів на сесію (за замовчуванням `5`, діапазон `1–20`). ## Пов’язане