From b6770c33feb8e68fdd5c746a2b1af87054fc682d Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Tue, 21 Apr 2026 19:02:34 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/automation/tasks.md | 213 +++++++++++------------ docs/uk/tools/subagents.md | 334 ++++++++++++++++++------------------ 2 files changed, 274 insertions(+), 273 deletions(-) diff --git a/docs/uk/automation/tasks.md b/docs/uk/automation/tasks.md index 3eb8f98b6..d4c8d3af6 100644 --- a/docs/uk/automation/tasks.md +++ b/docs/uk/automation/tasks.md @@ -1,41 +1,41 @@ --- read_when: - - Перевірка фонової роботи, що виконується або нещодавно завершилася + - Перевірка фонової роботи, яка виконується або нещодавно завершилася - Налагодження збоїв доставки для відокремлених запусків агентів - Розуміння того, як фонові запуски пов’язані із сеансами, Cron і Heartbeat summary: Відстеження фонових завдань для запусків ACP, субагентів, ізольованих завдань Cron і операцій CLI title: Фонові завдання x-i18n: - generated_at: "2026-04-20T18:25:02Z" + generated_at: "2026-04-21T19:01:28Z" model: gpt-5.4 provider: openai - source_hash: ba5511b1c421bdf505fc7d34f09e453ac44e85213fcb0f082078fa957aa91fe7 + source_hash: a4cd666b3eaffde8df0b5e1533eb337e44a0824824af6f8a240f18a89f71b402 source_path: automation/tasks.md workflow: 15 --- # Фонові завдання -> **Шукаєте планування?** Див. [Автоматизація й завдання](/uk/automation), щоб вибрати правильний механізм. Ця сторінка описує **відстеження** фонової роботи, а не її планування. +> **Шукаєте планування?** Дивіться [Автоматизація та завдання](/uk/automation), щоб вибрати правильний механізм. Ця сторінка описує **відстеження** фонової роботи, а не її планування. Фонові завдання відстежують роботу, яка виконується **поза межами вашого основного сеансу розмови**: -запуски ACP, створення субагентів, виконання ізольованих завдань Cron і операції, ініційовані через CLI. +запуски ACP, створення субагентів, ізольовані виконання завдань Cron і операції, ініційовані через CLI. -Завдання **не** замінюють сеанси, завдання Cron або Heartbeat — це **журнал активності**, який фіксує, яка відокремлена робота відбулася, коли саме та чи була вона успішною. +Завдання **не** замінюють сеанси, завдання Cron або Heartbeat — це **журнал активності**, який фіксує, яка відокремлена робота відбулася, коли саме, і чи була вона успішною. -Не кожен запуск агента створює завдання. Ходи Heartbeat і звичайний інтерактивний чат — ні. Усі виконання Cron, створення ACP, створення субагентів і команди агента CLI — так. +Не кожен запуск агента створює завдання. Ходи Heartbeat і звичайний інтерактивний чат — ні. Усі виконання Cron, створення ACP, створення субагентів і команди агента через CLI — так. ## Коротко -- Завдання — це **записи**, а не планувальники: Cron і Heartbeat вирішують, _коли_ запускається робота, а завдання відстежують, _що сталося_. +- Завдання — це **записи**, а не планувальники: Cron і Heartbeat вирішують, _коли_ запускати роботу, а завдання відстежують, _що сталося_. - ACP, субагенти, усі завдання Cron і операції CLI створюють завдання. Ходи Heartbeat — ні. - Кожне завдання проходить шлях `queued → running → terminal` (`succeeded`, `failed`, `timed_out`, `cancelled` або `lost`). -- Завдання Cron залишаються активними, поки середовище виконання Cron усе ще володіє цим завданням; чат-орієнтовані завдання CLI залишаються активними лише доти, доки їхній контекст запуску-власник усе ще активний. -- Завершення працює за push-моделлю: відокремлена робота може напряму сповістити або пробудити сеанс/Heartbeat запитувача після завершення, тому цикли опитування стану зазвичай є неправильною моделлю. -- Ізольовані запуски Cron і завершення субагентів у режимі best-effort очищають відстежувані вкладки браузера/процеси для свого дочірнього сеансу перед фінальним обліком очищення. -- Доставка ізольованого Cron пригнічує застарілі проміжні відповіді батьківського процесу, поки ще триває завершення нащадків-субагентів, і надає перевагу фінальному виводу нащадка, якщо він надходить до доставки. +- Завдання Cron залишаються активними, поки середовище виконання Cron усе ще володіє цим завданням; CLI-завдання на основі чату залишаються активними лише поки активний їхній контекст запуску-власника. +- Завершення керується подіями надсилання: відокремлена робота може напряму сповістити або пробудити сеанс запитувача/Heartbeat після завершення, тому цикли опитування статусу зазвичай є неправильною моделлю. +- Ізольовані запуски Cron і завершення субагентів у міру можливого очищають відстежувані вкладки браузера/процеси для свого дочірнього сеансу перед фінальним обліком очищення. +- Доставка ізольованого Cron пригнічує застарілі проміжні відповіді батьківського процесу, поки ще завершується робота дочірніх субагентів, і надає перевагу фінальному виводу дочірнього процесу, якщо він надходить до моменту доставки. - Сповіщення про завершення доставляються безпосередньо в канал або ставляться в чергу до наступного Heartbeat. - `openclaw tasks list` показує всі завдання; `openclaw tasks audit` виявляє проблеми. - Термінальні записи зберігаються 7 днів, після чого автоматично видаляються. @@ -43,23 +43,23 @@ x-i18n: ## Швидкий старт ```bash -# Перелічити всі завдання (спочатку найновіші) +# Показати всі завдання (найновіші спочатку) openclaw tasks list -# Відфільтрувати за середовищем виконання або статусом +# Фільтрувати за середовищем виконання або статусом openclaw tasks list --runtime acp openclaw tasks list --status running -# Показати подробиці для конкретного завдання (за ID, run ID або session key) +# Показати деталі конкретного завдання (за ID, ID запуску або ключем сеансу) openclaw tasks show -# Скасувати запущене завдання (завершує дочірній сеанс) +# Скасувати завдання, що виконується (завершує дочірній сеанс) openclaw tasks cancel # Змінити політику сповіщень для завдання openclaw tasks notify state_changes -# Виконати аудит працездатності +# Запустити перевірку стану openclaw tasks audit # Переглянути або застосувати обслуговування @@ -74,24 +74,24 @@ openclaw tasks flow cancel ## Що створює завдання -| Джерело | Тип середовища виконання | Коли створюється запис завдання | Політика сповіщень за замовчуванням | -| ---------------------- | ------------------------ | ------------------------------------------------------ | ----------------------------------- | -| Фонові запуски ACP | `acp` | Створення дочірнього сеансу ACP | `done_only` | -| Оркестрація субагентів | `subagent` | Створення субагента через `sessions_spawn` | `done_only` | -| Завдання Cron (усі типи) | `cron` | Кожне виконання Cron (основний сеанс та ізольований) | `silent` | -| Операції CLI | `cli` | Команди `openclaw agent`, що виконуються через Gateway | `silent` | -| Медіазавдання агента | `cli` | Запуски `video_generate`, прив’язані до сеансу | `silent` | +| Джерело | Тип середовища виконання | Коли створюється запис завдання | Типова політика сповіщень | +| ---------------------- | ------------------------ | ------------------------------------------------------ | ------------------------- | +| Фонові запуски ACP | `acp` | Під час створення дочірнього сеансу ACP | `done_only` | +| Оркестрація субагентів | `subagent` | Під час створення субагента через `sessions_spawn` | `done_only` | +| Завдання Cron (усі типи) | `cron` | Для кожного виконання Cron (основний сеанс та ізольовані) | `silent` | +| Операції CLI | `cli` | Команди `openclaw agent`, що виконуються через Gateway | `silent` | +| Медіазавдання агента | `cli` | Запуски `video_generate` на основі сеансу | `silent` | -Завдання Cron основного сеансу за замовчуванням використовують політику сповіщень `silent` — вони створюють записи для відстеження, але не генерують сповіщень. Ізольовані завдання Cron також за замовчуванням мають `silent`, але є помітнішими, оскільки виконуються у власному сеансі. +Завдання Cron основного сеансу типово використовують політику сповіщень `silent` — вони створюють записи для відстеження, але не генерують сповіщень. Ізольовані завдання Cron також типово використовують `silent`, але є помітнішими, оскільки виконуються у власному сеансі. -Запуски `video_generate`, прив’язані до сеансу, також використовують політику сповіщень `silent`. Вони все одно створюють записи завдань, але завершення повертається до початкового сеансу агента як внутрішнє пробудження, щоб агент міг сам написати наступне повідомлення й прикріпити готове відео. Якщо ви ввімкнете `tools.media.asyncCompletion.directSend`, асинхронні завершення `music_generate` і `video_generate` спочатку намагатимуться доставити результат безпосередньо в канал, а вже потім повертатимуться до шляху пробудження сеансу запитувача. +Запуски `video_generate` на основі сеансу також використовують політику сповіщень `silent`. Вони все одно створюють записи завдань, але завершення повертається до початкового сеансу агента як внутрішнє пробудження, щоб агент міг сам написати наступне повідомлення і прикріпити готове відео. Якщо ви вмикаєте `tools.media.asyncCompletion.directSend`, асинхронні завершення `music_generate` і `video_generate` спочатку намагаються доставити результат безпосередньо в канал, а вже потім переходять до шляху пробудження сеансу запитувача. -Поки завдання `video_generate`, прив’язане до сеансу, все ще активне, інструмент також діє як захисне обмеження: повторні виклики `video_generate` у цьому самому сеансі повертають статус активного завдання замість запуску другого паралельного генерування. Використовуйте `action: "status"`, якщо вам потрібен явний перегляд прогресу/статусу з боку агента. +Поки завдання `video_generate` на основі сеансу все ще активне, інструмент також працює як захисне обмеження: повторні виклики `video_generate` у тому самому сеансі повертають статус активного завдання замість запуску другої паралельної генерації. Використовуйте `action: "status"`, якщо хочете явний перегляд перебігу/статусу з боку агента. **Що не створює завдань:** - Ходи Heartbeat — основний сеанс; див. [Heartbeat](/uk/gateway/heartbeat) -- Звичайні ходи інтерактивного чату +- Звичайні інтерактивні ходи чату - Прямі відповіді `/command` ## Життєвий цикл завдання @@ -99,59 +99,59 @@ openclaw tasks flow cancel ```mermaid stateDiagram-v2 [*] --> queued - queued --> running : agent starts - running --> succeeded : completes ok - running --> failed : error - running --> timed_out : timeout exceeded - running --> cancelled : operator cancels - queued --> lost : session gone > 5 min - running --> lost : session gone > 5 min + queued --> running : запускається агент + running --> succeeded : успішне завершення + running --> failed : помилка + running --> timed_out : перевищено час очікування + running --> cancelled : оператор скасував + queued --> lost : сеанс відсутній > 5 хв + running --> lost : сеанс відсутній > 5 хв ``` -| Статус | Що це означає | -| ----------- | -------------------------------------------------------------------------- | -| `queued` | Створено, очікує на запуск агента | -| `running` | Хід агента активно виконується | -| `succeeded` | Успішно завершено | -| `failed` | Завершено з помилкою | -| `timed_out` | Перевищено налаштований час очікування | -| `cancelled` | Зупинено оператором через `openclaw tasks cancel` | -| `lost` | Середовище виконання втратило авторитетний стан-основу після 5-хвилинного пільгового періоду | +| Статус | Що це означає | +| ----------- | ------------------------------------------------------------------------- | +| `queued` | Створено, очікує запуску агента | +| `running` | Хід агента активно виконується | +| `succeeded` | Успішно завершено | +| `failed` | Завершено з помилкою | +| `timed_out` | Перевищено налаштований час очікування | +| `cancelled` | Зупинено оператором через `openclaw tasks cancel` | +| `lost` | Середовище виконання втратило авторитетний базовий стан після 5-хвилинного пільгового періоду | -Переходи відбуваються автоматично — коли пов’язаний запуск агента завершується, статус завдання оновлюється відповідно до результату. +Переходи відбуваються автоматично — коли пов’язаний запуск агента завершується, статус завдання оновлюється відповідно. -`lost` є залежним від середовища виконання: +`lost` залежить від середовища виконання: -- Завдання ACP: зникли метадані дочірнього сеансу ACP, на які спиралося завдання. -- Завдання субагента: дочірній сеанс-основа зник зі сховища цільового агента. +- Завдання ACP: зникли метадані дочірнього сеансу ACP. +- Завдання субагента: дочірній сеанс зник зі сховища цільового агента. - Завдання Cron: середовище виконання Cron більше не відстежує завдання як активне. -- Завдання CLI: ізольовані завдання дочірнього сеансу використовують дочірній сеанс; чат-орієнтовані завдання CLI натомість використовують живий контекст запуску, тому завислі рядки сеансів каналу/групи/прямих повідомлень не підтримують їх у живому стані. +- Завдання CLI: ізольовані завдання дочірнього сеансу використовують дочірній сеанс; CLI-завдання на основі чату натомість використовують активний контекст запуску, тому залишкові рядки сеансу каналу/групи/прямих повідомлень не підтримують їхню активність. ## Доставка і сповіщення -Коли завдання досягає термінального стану, OpenClaw надсилає вам сповіщення. Є два шляхи доставки: +Коли завдання досягає термінального стану, OpenClaw сповіщає вас. Є два шляхи доставки: -**Пряма доставка** — якщо завдання має ціль каналу (`requesterOrigin`), повідомлення про завершення надсилається прямо в цей канал (Telegram, Discord, Slack тощо). Для завершення субагента OpenClaw також зберігає прив’язане маршрутизування thread/topic, коли воно доступне, і може заповнити відсутні `to` / account із збереженого маршруту сеансу запитувача (`lastChannel` / `lastTo` / `lastAccountId`) перед тим, як відмовитися від прямої доставки. +**Пряма доставка** — якщо завдання має ціль каналу (`requesterOrigin`), повідомлення про завершення надсилається безпосередньо в цей канал (Telegram, Discord, Slack тощо). Для завершень субагентів OpenClaw також зберігає маршрутизацію прив’язаної гілки/теми, коли це можливо, і може заповнити відсутній `to` / обліковий запис зі збереженого маршруту сеансу запитувача (`lastChannel` / `lastTo` / `lastAccountId`) перед тим, як відмовитися від прямої доставки. -**Доставка через чергу сеансу** — якщо пряма доставка не вдалася або origin не задано, оновлення ставиться в чергу як системна подія в сеансі запитувача й з’являється під час наступного Heartbeat. +**Доставка через чергу сеансу** — якщо пряма доставка не вдається або origin не задано, оновлення ставиться в чергу як системна подія в сеансі запитувача і з’являється під час наступного Heartbeat. -Завершення завдання негайно запускає пробудження Heartbeat, щоб ви швидко побачили результат — вам не потрібно чекати наступного запланованого тіку Heartbeat. +Завершення завдання негайно пробуджує Heartbeat, тому ви швидко бачите результат — не потрібно чекати наступного запланованого тіку Heartbeat. -Це означає, що типовий робочий процес побудований на push-моделі: один раз запускаєте відокремлену роботу, а далі середовище виконання саме пробуджує або сповіщає вас після завершення. Опитуйте стан завдання лише тоді, коли вам потрібні налагодження, втручання або явний аудит. +Це означає, що типовий робочий процес базується на надсиланні подій: запустіть відокремлену роботу один раз, а потім дозвольте середовищу виконання пробудити або сповістити вас після завершення. Опитуйте стан завдання лише тоді, коли вам потрібне налагодження, втручання або явний аудит. ### Політики сповіщень Керуйте тим, скільки інформації ви отримуєте про кожне завдання: -| Політика | Що доставляється | -| --------------------- | ----------------------------------------------------------------------- | -| `done_only` (default) | Лише термінальний стан (`succeeded`, `failed` тощо) — **це значення за замовчуванням** | -| `state_changes` | Кожна зміна стану та оновлення прогресу | -| `silent` | Нічого | +| Політика | Що доставляється | +| --------------------- | ------------------------------------------------------------------------ | +| `done_only` (типово) | Лише термінальний стан (`succeeded`, `failed` тощо) — **це типове значення** | +| `state_changes` | Кожен перехід стану й оновлення прогресу | +| `silent` | Взагалі нічого | -Змінити політику під час виконання завдання: +Змініть політику, поки завдання виконується: ```bash openclaw tasks notify state_changes @@ -165,7 +165,7 @@ openclaw tasks notify state_changes openclaw tasks list [--runtime ] [--status ] [--json] ``` -Стовпці виводу: ID завдання, Тип, Статус, Доставка, Run ID, Дочірній сеанс, Підсумок. +Стовпці виводу: ID завдання, вид, статус, доставка, ID запуску, дочірній сеанс, зведення. ### `tasks show` @@ -173,7 +173,7 @@ openclaw tasks list [--runtime ] [--status ] [--j openclaw tasks show ``` -Токен lookup приймає ID завдання, run ID або ключ сеансу. Показує повний запис, включно з часом, станом доставки, помилкою та термінальним підсумком. +Токен пошуку приймає ID завдання, ID запуску або ключ сеансу. Показує повний запис, зокрема час, стан доставки, помилку й термінальне зведення. ### `tasks cancel` @@ -181,7 +181,7 @@ openclaw tasks show openclaw tasks cancel ``` -Для завдань ACP і субагентів це завершує дочірній сеанс. Для завдань, що відстежуються через CLI, скасування фіксується в реєстрі завдань (окремого дескриптора дочірнього середовища виконання немає). Статус переходить у `cancelled`, і, коли це доречно, надсилається сповіщення про доставку. +Для завдань ACP і субагентів це завершує дочірній сеанс. Для завдань, що відстежуються через CLI, скасування фіксується в реєстрі завдань (окремого дочірнього дескриптора середовища виконання немає). Статус переходить у `cancelled`, а за потреби надсилається сповіщення про доставку. ### `tasks notify` @@ -197,14 +197,14 @@ openclaw tasks audit [--json] Виявляє операційні проблеми. За наявності проблем результати також з’являються в `openclaw status`. -| Ознака проблеми | Серйозність | Тригер | -| -------------------------- | ----------- | ----------------------------------------------------- | -| `stale_queued` | warn | У черзі понад 10 хвилин | -| `stale_running` | error | Виконується понад 30 хвилин | -| `lost` | error | Зникла належність завдання до середовища виконання | -| `delivery_failed` | warn | Доставка не вдалася, а політика сповіщень не `silent` | -| `missing_cleanup` | warn | Термінальне завдання без часової позначки очищення | -| `inconsistent_timestamps` | warn | Порушення часової шкали (наприклад, завершено раніше, ніж розпочато) | +| Проблема | Серйозність | Тригер | +| ------------------------- | ----------- | ----------------------------------------------------- | +| `stale_queued` | warn | У стані queued понад 10 хвилин | +| `stale_running` | error | У стані running понад 30 хвилин | +| `lost` | error | Зникло володіння завданням на рівні середовища виконання | +| `delivery_failed` | warn | Доставка не вдалася, а політика сповіщень не `silent` | +| `missing_cleanup` | warn | Термінальне завдання без позначки часу очищення | +| `inconsistent_timestamps` | warn | Порушення часової шкали (наприклад, завершено раніше, ніж розпочато) | ### `tasks maintenance` @@ -213,21 +213,21 @@ openclaw tasks maintenance [--json] openclaw tasks maintenance --apply [--json] ``` -Використовуйте це, щоб переглянути або застосувати звіряння, проставлення позначок очищення та видалення застарілих даних для завдань і стану Task Flow. +Використовуйте це, щоб переглянути або застосувати узгодження, проставлення очищення та видалення для стану завдань і Task Flow. -Звіряння залежить від середовища виконання: +Узгодження залежить від середовища виконання: -- Завдання ACP/субагентів перевіряють свій дочірній сеанс-основу. -- Завдання Cron перевіряють, чи середовище виконання Cron усе ще володіє цим завданням. -- Чат-орієнтовані завдання CLI перевіряють контекст активного запуску-власника, а не лише рядок чат-сеансу. +- Завдання ACP/субагентів перевіряють свій базовий дочірній сеанс. +- Завдання Cron перевіряють, чи середовище виконання Cron усе ще володіє завданням. +- CLI-завдання на основі чату перевіряють базовий активний контекст запуску, а не лише рядок сеансу чату. Очищення після завершення також залежить від середовища виконання: -- Під час завершення субагента в режимі best-effort закриваються відстежувані вкладки браузера/процеси для дочірнього сеансу, перш ніж продовжиться очищення оголошення. -- Під час завершення ізольованого Cron у режимі best-effort закриваються відстежувані вкладки браузера/процеси для сеансу Cron, перш ніж виконання буде повністю згорнуто. -- Доставка ізольованого Cron за потреби очікує завершення подальших дій нащадків-субагентів і пригнічує застарілий текст підтвердження батьківського процесу замість його оголошення. -- Доставка завершення субагента надає перевагу найновішому видимому тексту асистента; якщо він порожній, використовується очищений найновіший текст `tool`/`toolResult`, а запуски лише з викликом інструмента, що завершилися через тайм-аут, можуть згортатися до короткого підсумку часткового прогресу. -- Помилки очищення не маскують реальний результат завдання. +- Завершення субагента в міру можливого закриває відстежувані вкладки браузера/процеси для дочірнього сеансу, перш ніж продовжиться оголошене очищення. +- Завершення ізольованого Cron у міру можливого закриває відстежувані вкладки браузера/процеси для сеансу Cron, перш ніж запуск повністю завершиться. +- Доставка ізольованого Cron за потреби очікує завершення дочірньої роботи субагентів і пригнічує застарілий текст підтвердження батьківського процесу замість його оголошення. +- Доставка завершення субагента надає перевагу найновішому видимому тексту асистента; якщо він порожній, використовується очищений найновіший текст tool/toolResult, а запуски лише з викликом інструменту, що завершилися тайм-аутом, можуть зводитися до короткого підсумку часткового прогресу. Термінальні невдалі запуски оголошують статус невдачі без повторного відтворення захопленого тексту відповіді. +- Збої очищення не повинні маскувати реальний результат завдання. ### `tasks flow list|show|cancel` @@ -237,35 +237,36 @@ openclaw tasks flow show [--json] openclaw tasks flow cancel ``` -Використовуйте ці команди, коли вас цікавить саме оркеструвальний Task Flow, а не окремий запис фонового завдання. +Використовуйте це, коли вас цікавить саме оркеструвальний Task Flow, а не окремий запис фонового завдання. ## Дошка завдань чату (`/tasks`) -Використовуйте `/tasks` у будь-якому чат-сеансі, щоб побачити фонові завдання, пов’язані з цим сеансом. Дошка показує -активні й нещодавно завершені завдання з інформацією про середовище виконання, статус, час, а також подробицями прогресу або помилки. +Використовуйте `/tasks` у будь-якому сеансі чату, щоб переглянути фонові завдання, пов’язані з цим сеансом. Дошка показує активні й нещодавно завершені завдання з середовищем виконання, статусом, часовими даними та деталями прогресу або помилки. -Якщо в поточному сеансі немає видимих пов’язаних завдань, `/tasks` переключається на локальні для агента підрахунки завдань, -щоб ви все одно бачили огляд без витоку подробиць з інших сеансів. +Коли поточний сеанс не має видимих пов’язаних завдань, `/tasks` повертається до локальних для агента підрахунків завдань, +щоб ви все одно отримували огляд без розкриття деталей інших сеансів. -Для повного журналу оператора використовуйте CLI: `openclaw tasks list`. +Для повного операторського журналу використовуйте CLI: `openclaw tasks list`. ## Інтеграція статусу (тиск завдань) -`openclaw status` містить стислий підсумок завдань: +`openclaw status` містить коротке зведення завдань: ``` Tasks: 3 queued · 2 running · 1 issues ``` -Підсумок показує: +Зведення повідомляє: - **active** — кількість `queued` + `running` - **failures** — кількість `failed` + `timed_out` + `lost` -- **byRuntime** — розбивка за `acp`, `subagent`, `cron`, `cli` +- **byRuntime** — розподіл за `acp`, `subagent`, `cron`, `cli` -І `/status`, і інструмент `session_status` використовують знімок завдань з урахуванням очищення: пріоритет надається активним завданням, застарілі завершені рядки приховуються, а нещодавні збої показуються лише тоді, коли активної роботи вже не залишилося. Це допомагає картці статусу зосереджуватися на тому, що важливо саме зараз. +І `/status`, і інструмент `session_status` використовують знімок завдань з урахуванням очищення: активні завдання +мають пріоритет, застарілі завершені рядки приховуються, а нещодавні збої показуються лише тоді, коли більше не +залишається активної роботи. Це допомагає картці статусу зосереджуватися на тому, що важливо саме зараз. -## Зберігання та обслуговування +## Зберігання й обслуговування ### Де зберігаються завдання @@ -275,50 +276,50 @@ Tasks: 3 queued · 2 running · 1 issues $OPENCLAW_STATE_DIR/tasks/runs.sqlite ``` -Реєстр завантажується в пам’ять під час запуску Gateway і синхронізує записи в SQLite для надійності між перезапусками. +Реєстр завантажується в пам’ять під час запуску Gateway і синхронізує записи в SQLite для стійкості між перезапусками. ### Автоматичне обслуговування Очищувач запускається кожні **60 секунд** і виконує три дії: -1. **Звіряння** — перевіряє, чи активні завдання все ще мають авторитетну основу в середовищі виконання. Завдання ACP/субагентів використовують стан дочірнього сеансу, завдання Cron — належність до активного завдання, а чат-орієнтовані завдання CLI — контекст запуску-власника. Якщо цей стан-основа відсутній понад 5 хвилин, завдання позначається як `lost`. -2. **Проставлення позначок очищення** — встановлює часову позначку `cleanupAfter` для термінальних завдань (`endedAt + 7 days`). -3. **Видалення застарілих даних** — видаляє записи після настання дати `cleanupAfter`. +1. **Узгодження** — перевіряє, чи активні завдання все ще мають авторитетне базове середовище виконання. Завдання ACP/субагентів використовують стан дочірнього сеансу, завдання Cron — володіння активним завданням, а CLI-завдання на основі чату — базовий контекст запуску. Якщо цей базовий стан відсутній понад 5 хвилин, завдання позначається як `lost`. +2. **Проставлення очищення** — встановлює часову позначку `cleanupAfter` для термінальних завдань (`endedAt + 7 days`). +3. **Видалення** — видаляє записи після настання дати `cleanupAfter`. -**Термін зберігання**: записи термінальних завдань зберігаються **7 днів**, після чого автоматично видаляються. Додаткового налаштування не потрібно. +**Термін зберігання**: термінальні записи завдань зберігаються **7 днів**, після чого автоматично видаляються. Налаштування не потрібне. ## Як завдання пов’язані з іншими системами -### Завдання і Task Flow +### Завдання і TaskFlow -[Task Flow](/uk/automation/taskflow) — це рівень оркестрації потоків над фоновими завданнями. Один потік може координувати кілька завдань протягом свого життєвого циклу, використовуючи керовані або дзеркальні режими синхронізації. Використовуйте `openclaw tasks` для перегляду окремих записів завдань і `openclaw tasks flow` для перегляду оркеструвального потоку. +[TaskFlow](/uk/automation/taskflow) — це рівень оркестрації потоків над фоновими завданнями. Протягом свого життєвого циклу один потік може координувати кілька завдань, використовуючи керовані або дзеркальні режими синхронізації. Використовуйте `openclaw tasks`, щоб переглядати окремі записи завдань, і `openclaw tasks flow`, щоб переглядати оркеструвальний потік. -Докладніше див. у [Task Flow](/uk/automation/taskflow). +Докладніше див. у [TaskFlow](/uk/automation/taskflow). ### Завдання і Cron -**Визначення** завдання Cron зберігається в `~/.openclaw/cron/jobs.json`; стан виконання під час роботи зберігається поруч у `~/.openclaw/cron/jobs-state.json`. **Кожне** виконання Cron створює запис завдання — і в основному сеансі, і в ізольованому. Завдання Cron основного сеансу за замовчуванням мають політику сповіщень `silent`, тому вони відстежуються без створення сповіщень. +**Визначення** завдання Cron зберігається в `~/.openclaw/cron/jobs.json`; стан виконання середовища зберігається поруч у `~/.openclaw/cron/jobs-state.json`. **Кожне** виконання Cron створює запис завдання — і в основному сеансі, і в ізольованому. Завдання Cron основного сеансу типово використовують політику сповіщень `silent`, тому вони відстежуються без створення сповіщень. Див. [Завдання Cron](/uk/automation/cron-jobs). ### Завдання і Heartbeat -Запуски Heartbeat — це ходи основного сеансу, вони не створюють записів завдань. Коли завдання завершується, воно може ініціювати пробудження Heartbeat, щоб ви швидше побачили результат. +Запуски Heartbeat — це ходи основного сеансу, вони не створюють записів завдань. Коли завдання завершується, воно може ініціювати пробудження Heartbeat, щоб ви швидко побачили результат. Див. [Heartbeat](/uk/gateway/heartbeat). ### Завдання і сеанси -Завдання може посилатися на `childSessionKey` (де виконується робота) і `requesterSessionKey` (хто її запустив). Сеанси — це контекст розмови; завдання — це відстеження активності поверх нього. +Завдання може посилатися на `childSessionKey` (де виконується робота) і `requesterSessionKey` (хто її запустив). Сеанси — це контекст розмови; завдання — це надбудова для відстеження активності. ### Завдання і запуски агентів -`runId` завдання пов’язує його із запуском агента, який виконує роботу. Події життєвого циклу агента (початок, завершення, помилка) автоматично оновлюють статус завдання — вам не потрібно керувати життєвим циклом вручну. +`runId` завдання пов’язує його із запуском агента, який виконує роботу. Події життєвого циклу агента (запуск, завершення, помилка) автоматично оновлюють статус завдання — вам не потрібно керувати життєвим циклом вручну. ## Пов’язане -- [Автоматизація й завдання](/uk/automation) — огляд усіх механізмів автоматизації -- [Task Flow](/uk/automation/taskflow) — оркестрація потоків над завданнями +- [Автоматизація та завдання](/uk/automation) — огляд усіх механізмів автоматизації +- [TaskFlow](/uk/automation/taskflow) — оркестрація потоків над завданнями - [Заплановані завдання](/uk/automation/cron-jobs) — планування фонової роботи - [Heartbeat](/uk/gateway/heartbeat) — періодичні ходи основного сеансу - [CLI: Tasks](/cli/index#tasks) — довідка з команд CLI diff --git a/docs/uk/tools/subagents.md b/docs/uk/tools/subagents.md index 78b20c58a..452abb6cc 100644 --- a/docs/uk/tools/subagents.md +++ b/docs/uk/tools/subagents.md @@ -1,26 +1,26 @@ --- read_when: - - Вам потрібна фонова/паралельна робота через агента - - Ви змінюєте політику sessions_spawn або інструментів субагентів - - Ви реалізуєте або усуваєте проблеми із сесіями субагентів, прив’язаними до тредів -summary: 'Субагенти: запуск ізольованих агентних виконань, які повідомляють про результати назад у чат запитувача' -title: Субагенти + - Ви хочете фонову/паралельну роботу через агента + - Ви змінюєте політику інструмента `sessions_spawn` або підагентів + - Ви впроваджуєте або усуваєте несправності сеансів підагентів, прив’язаних до потоку +summary: 'Підагенти: запуск ізольованих агентних виконань, які повідомляють про результати назад у чат запитувача' +title: Підагенти x-i18n: - generated_at: "2026-04-05T18:21:59Z" + generated_at: "2026-04-21T19:01:11Z" model: gpt-5.4 provider: openai - source_hash: 9df7cc35a3069ce4eb9c92a95df3ce5365a00a3fae92ff73def75461b58fec3f + source_hash: 218913f0db88d40e1b5fdb0201b8d23e7af23df572c86ff4be2637cb62498281 source_path: tools/subagents.md workflow: 15 --- -# Субагенти +# Підагенти -Субагенти — це фонові агентні виконання, запущені з наявного агентного виконання. Вони працюють у власній сесії (`agent::subagent:`) і після завершення **повідомляють** про свій результат назад у чат-канал запитувача. Кожне виконання субагента відстежується як [фонове завдання](/uk/automation/tasks). +Підагенти — це фонові агентні запуски, породжені з наявного агентного запуску. Вони працюють у власному сеансі (`agent::subagent:`) і після завершення **повідомляють** про свій результат назад у чат-канал запитувача. Кожен запуск підагента відстежується як [фонове завдання](/uk/automation/tasks). -## Слеш-команда +## Slash-команда -Використовуйте `/subagents`, щоб переглядати або керувати виконаннями субагентів для **поточної сесії**: +Використовуйте `/subagents`, щоб переглядати або керувати запусками підагентів для **поточного сеансу**: - `/subagents list` - `/subagents kill ` @@ -30,9 +30,9 @@ x-i18n: - `/subagents steer ` - `/subagents spawn [--model ] [--thinking ]` -Елементи керування прив’язкою до тредів: +Елементи керування прив’язкою до потоку: -Ці команди працюють у каналах, які підтримують постійні прив’язки тредів. Див. **Канали з підтримкою тредів** нижче. +Ці команди працюють у каналах, які підтримують постійні прив’язки до потоків. Див. **Канали з підтримкою потоків** нижче. - `/focus ` - `/unfocus` @@ -40,129 +40,129 @@ x-i18n: - `/session idle ` - `/session max-age ` -`/subagents info` показує метадані виконання (статус, часові мітки, id сесії, шлях до транскрипту, очищення). -Використовуйте `sessions_history` для обмеженого, відфільтрованого з погляду безпеки представлення для згадування; перевіряйте -шлях до транскрипту на диску, коли вам потрібен сирий повний транскрипт. +`/subagents info` показує метадані запуску (статус, часові мітки, id сеансу, шлях до транскрипту, очищення). +Використовуйте `sessions_history` для обмеженого, відфільтрованого з міркувань безпеки перегляду історії; переглядайте +шлях до транскрипту на диску, коли вам потрібен необроблений повний транскрипт. -### Поведінка spawn +### Поведінка запуску -`/subagents spawn` запускає фонового субагента як команду користувача, а не як внутрішню ретрансляцію, і надсилає одне фінальне оновлення про завершення назад у чат запитувача, коли виконання завершується. +`/subagents spawn` запускає фоновий підагент як команду користувача, а не як внутрішню ретрансляцію, і надсилає одне фінальне оновлення про завершення назад у чат запитувача, коли запуск завершується. -- Команда spawn є неблокувальною; вона одразу повертає id виконання. -- Після завершення субагент повідомляє зведення/результат назад у чат-канал запитувача. -- Доставка після завершення є push-орієнтованою. Після запуску не потрібно опитувати `/subagents list`, - `sessions_list` або `sessions_history` у циклі лише для очікування +- Команда spawn не блокує виконання; вона негайно повертає id запуску. +- Після завершення підагент повідомляє підсумкове повідомлення/результат назад у чат-канал запитувача. +- Доставка завершення є push-орієнтованою. Після запуску не опитуйте `/subagents list`, + `sessions_list` або `sessions_history` у циклі лише для того, щоб дочекатися завершення; перевіряйте статус тільки за потреби для налагодження або втручання. -- Після завершення OpenClaw за принципом best-effort закриває відстежувані вкладки/процеси браузера, відкриті цією сесією субагента, до продовження потоку очищення повідомлення. +- Після завершення OpenClaw у межах best-effort закриває відстежувані вкладки браузера/процеси, відкриті цим сеансом підагента, перш ніж потік очищення повідомлення про завершення продовжиться. - Для ручних запусків доставка є стійкою: - - OpenClaw спочатку намагається виконати пряму доставку `agent` зі стабільним ключем ідемпотентності. - - Якщо пряма доставка не вдається, він повертається до маршрутизації через чергу. - - Якщо маршрутизація через чергу все ще недоступна, спроба повідомлення повторюється з короткою експоненційною затримкою перед остаточною відмовою. -- Доставка після завершення зберігає визначений маршрут запитувача: - - маршрути завершення, прив’язані до треда або розмови, мають пріоритет, коли доступні - - якщо джерело завершення надає лише канал, OpenClaw заповнює відсутні target/account із визначеного маршруту сесії запитувача (`lastChannel` / `lastTo` / `lastAccountId`), щоб пряма доставка все одно працювала -- Передача завершення до сесії запитувача — це внутрішній контекст, згенерований runtime (а не текст, створений користувачем), і вона включає: - - `Result` (останній видимий текст відповіді `assistant`, інакше санітизований останній текст tool/toolResult) + - OpenClaw спочатку намагається пряму доставку `agent` зі стабільним ключем ідемпотентності. + - Якщо пряма доставка не вдається, система переходить до маршрутизації через чергу. + - Якщо маршрутизація через чергу все ще недоступна, спроба повідомлення повторюється з коротким експоненційним backoff перед остаточною відмовою. +- Доставка завершення зберігає визначений маршрут запитувача: + - маршрути завершення, прив’язані до потоку або до розмови, мають пріоритет, коли вони доступні + - якщо джерело завершення надає лише канал, OpenClaw заповнює відсутні target/account із визначеного маршруту сеансу запитувача (`lastChannel` / `lastTo` / `lastAccountId`), щоб пряма доставка все одно працювала +- Передача завершення до сеансу запитувача — це внутрішній контекст, згенерований під час виконання (а не текст, створений користувачем), і вона включає: + - `Result` (останній видимий текст відповіді `assistant`, або, якщо його немає, санітизований останній текст tool/toolResult; термінальні невдалі запуски не використовують повторно захоплений текст відповіді) - `Status` (`completed successfully` / `failed` / `timed out` / `unknown`) - - компактну статистику runtime/токенів - - інструкцію доставки, яка вказує агенту запитувача переписати це звичайним голосом помічника (а не пересилати сирі внутрішні метадані) + - компактну статистику виконання/токенів + - інструкцію з доставки, яка наказує агенту запитувача переписати повідомлення звичайним голосом помічника (а не пересилати необроблені внутрішні метадані) - `--model` і `--thinking` перевизначають типові значення для цього конкретного запуску. -- Використовуйте `info`/`log`, щоб перевіряти подробиці та вивід після завершення. -- `/subagents spawn` — це режим одноразового запуску (`mode: "run"`). Для постійних сесій, прив’язаних до тредів, використовуйте `sessions_spawn` із `thread: true` і `mode: "session"`. -- Для ACP harness-сесій (Codex, Claude Code, Gemini CLI) використовуйте `sessions_spawn` із `runtime: "acp"` і див. [ACP-агенти](/tools/acp-agents). +- Використовуйте `info`/`log`, щоб переглянути подробиці та вивід після завершення. +- `/subagents spawn` — це одноразовий режим (`mode: "run"`). Для постійних сеансів, прив’язаних до потоку, використовуйте `sessions_spawn` з `thread: true` і `mode: "session"`. +- Для сеансів harness ACP (Codex, Claude Code, Gemini CLI) використовуйте `sessions_spawn` з `runtime: "acp"` і див. [ACP Agents](/uk/tools/acp-agents). Основні цілі: -- Розпаралелювати роботу типу «дослідження / довге завдання / повільний інструмент» без блокування основного виконання. -- Ізолювати субагентів типово (розділення сесій + необов’язкова ізоляція). -- Зробити поверхню інструментів важкою для неправильного використання: субагенти типово **не** отримують інструменти сесій. +- Паралелізувати роботу типу «дослідження / довге завдання / повільний інструмент», не блокуючи основний запуск. +- За замовчуванням зберігати ізоляцію підагентів (розділення сеансів + необов’язковий sandboxing). +- Зберігати поверхню інструментів складною для неправильного використання: підагенти **не** отримують інструменти сеансу за замовчуванням. - Підтримувати налаштовувану глибину вкладеності для шаблонів оркестрації. -Примітка щодо вартості: кожен субагент має **власний** контекст і власне використання токенів. Для важких або повторюваних -завдань установіть для субагентів дешевшу модель, а основного агента залиште на якіснішій моделі. +Примітка щодо вартості: кожен підагент має **власний** контекст і власне використання токенів. Для важких або повторюваних +завдань установіть для підагентів дешевшу модель, а основного агента залиште на якіснішій моделі. Це можна налаштувати через `agents.defaults.subagents.model` або через перевизначення для окремих агентів. ## Інструмент Використовуйте `sessions_spawn`: -- Запускає виконання субагента (`deliver: false`, глобальна lane: `subagent`) -- Потім виконує крок повідомлення та публікує відповідь-повідомлення назад у чат-канал запитувача -- Типова модель: успадковується від виклику, якщо ви не встановите `agents.defaults.subagents.model` (або `agents.list[].subagents.model` для окремого агента); явне `sessions_spawn.model` усе одно має пріоритет. -- Типове thinking: успадковується від виклику, якщо ви не встановите `agents.defaults.subagents.thinking` (або `agents.list[].subagents.thinking` для окремого агента); явне `sessions_spawn.thinking` усе одно має пріоритет. -- Типовий timeout виконання: якщо `sessions_spawn.runTimeoutSeconds` не задано, OpenClaw використовує `agents.defaults.subagents.runTimeoutSeconds`, якщо його встановлено; інакше використовується `0` (без timeout). +- Запускає підагентний запуск (`deliver: false`, глобальна смуга: `subagent`) +- Потім виконує крок повідомлення та публікує відповідь-повідомлення в чат-канал запитувача +- Типова модель: успадковується від викликача, якщо ви не встановите `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` (без тайм-ауту). Параметри інструмента: -- `task` (обов’язково) -- `label?` (необов’язково) -- `agentId?` (необов’язково; запуск під іншим id агента, якщо дозволено) -- `model?` (необов’язково; перевизначає модель субагента; невалідні значення пропускаються, і субагент працює на типовій моделі з попередженням у результаті інструмента) -- `thinking?` (необов’язково; перевизначає рівень thinking для виконання субагента) -- `runTimeoutSeconds?` (типово береться з `agents.defaults.subagents.runTimeoutSeconds`, якщо задано, інакше `0`; якщо встановлено, виконання субагента переривається після N секунд) -- `thread?` (типово `false`; коли `true`, запитує прив’язку до треда каналу для цієї сесії субагента) +- `task` (обов’язковий) +- `label?` (необов’язковий) +- `agentId?` (необов’язковий; запуск під іншим id агента, якщо це дозволено) +- `model?` (необов’язковий; перевизначає модель підагента; недійсні значення пропускаються, і підагент запускається на типовій моделі з попередженням у результаті інструмента) +- `thinking?` (необов’язковий; перевизначає рівень thinking для запуску підагента) +- `runTimeoutSeconds?` (типово дорівнює `agents.defaults.subagents.runTimeoutSeconds`, якщо встановлено, інакше `0`; якщо встановлено, запуск підагента переривається через N секунд) +- `thread?` (типово `false`; якщо `true`, запитує прив’язку до потоку каналу для цього сеансу підагента) - `mode?` (`run|session`) - - типове значення — `run` - - якщо `thread: true` і `mode` не задано, типове значення стає `session` + - типовим є `run` + - якщо `thread: true` і `mode` пропущено, типовим стає `session` - `mode: "session"` вимагає `thread: true` - `cleanup?` (`delete|keep`, типово `keep`) -- `sandbox?` (`inherit|require`, типово `inherit`; `require` відхиляє запуск, якщо цільовий дочірній runtime не ізольований) -- `sessions_spawn` **не** приймає параметри доставки каналу (`target`, `channel`, `to`, `threadId`, `replyTo`, `transport`). Для доставки використовуйте `message`/`sessions_send` із запущеного виконання. +- `sandbox?` (`inherit|require`, типово `inherit`; `require` відхиляє запуск, якщо цільове дочірнє runtime не sandboxed) +- `sessions_spawn` **не** приймає параметри доставки каналу (`target`, `channel`, `to`, `threadId`, `replyTo`, `transport`). Для доставки використовуйте `message`/`sessions_send` із запущеного сеансу. -## Сесії, прив’язані до тредів +## Сеанси, прив’язані до потоку -Коли для каналу ввімкнено прив’язки тредів, субагент може залишатися прив’язаним до треда, щоб подальші повідомлення користувача в цьому треді й надалі маршрутизувалися до тієї самої сесії субагента. +Коли для каналу ввімкнено прив’язки до потоків, підагент може залишатися прив’язаним до потоку, щоб подальші повідомлення користувача в цьому потоці й надалі маршрутизувалися до того самого сеансу підагента. -### Канали з підтримкою тредів +### Канали з підтримкою потоків -- Discord (наразі єдиний підтримуваний канал): підтримує постійні сесії субагентів, прив’язані до тредів (`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.spawnSubagentSessions`. +- Discord (наразі єдиний підтримуваний канал): підтримує постійні сеанси підагентів, прив’язані до потоку (`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.spawnSubagentSessions`. -Швидкий сценарій: +Короткий потік роботи: -1. Запустіть через `sessions_spawn` із `thread: true` (і за потреби `mode: "session"`). -2. OpenClaw створює тред або прив’язує його до цільової сесії в активному каналі. -3. Відповіді та подальші повідомлення в цьому треді маршрутизуються до прив’язаної сесії. -4. Використовуйте `/session idle`, щоб переглядати/оновлювати автоматичне розфокусування за неактивністю, і `/session max-age`, щоб керувати жорстким лімітом. -5. Використовуйте `/unfocus`, щоб відв’язати вручну. +1. Запустіть через `sessions_spawn` із `thread: true` (і, за потреби, `mode: "session"`). +2. OpenClaw створює потік або прив’язує потік до цільового сеансу в активному каналі. +3. Відповіді та подальші повідомлення в цьому потоці маршрутизуються до прив’язаного сеансу. +4. Використовуйте `/session idle`, щоб переглянути/оновити автоматичне зняття фокуса через неактивність, і `/session max-age`, щоб керувати жорстким обмеженням. +5. Використовуйте `/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` -- Перевизначення каналу та ключі автоматичної прив’язки при запуску є специфічними для адаптера. Див. **Канали з підтримкою тредів** вище. +- Перевизначення для каналу та ключі автоматичної прив’язки під час запуску залежать від адаптера. Див. **Канали з підтримкою потоків** вище. -Див. [Довідник із конфігурації](/uk/gateway/configuration-reference) і [Слеш-команди](/tools/slash-commands) для актуальних подробиць щодо адаптерів. +Див. [Configuration Reference](/uk/gateway/configuration-reference) і [Slash commands](/uk/tools/slash-commands), щоб дізнатися актуальні подробиці щодо адаптерів. -Список дозволених: +Список дозволених значень: -- `agents.list[].subagents.allowAgents`: список id агентів, на які можна націлюватися через `agentId` (`["*"]` дозволяє будь-який). Типово: лише агент запитувача. -- `agents.defaults.subagents.allowAgents`: типовий список дозволених цільових агентів, який використовується, коли агент запитувача не задає власний `subagents.allowAgents`. -- Захист успадкування ізоляції: якщо сесія запитувача ізольована, `sessions_spawn` відхиляє цілі, які працювали б без ізоляції. -- `agents.defaults.subagents.requireAgentId` / `agents.list[].subagents.requireAgentId`: коли true, блокують виклики `sessions_spawn`, у яких пропущено `agentId` (примушує до явного вибору профілю). Типове значення: false. +- `agents.list[].subagents.allowAgents`: список id агентів, які можна вказувати через `agentId` (`["*"]` дозволяє будь-який). Типово: лише агент запитувача. +- `agents.defaults.subagents.allowAgents`: типовий список дозволених цільових агентів, який використовується, коли агент запитувача не встановлює власний `subagents.allowAgents`. +- Захист успадкування sandbox: якщо сеанс запитувача є sandboxed, `sessions_spawn` відхиляє цілі, які працювали б без sandbox. +- `agents.defaults.subagents.requireAgentId` / `agents.list[].subagents.requireAgentId`: якщо true, блокують виклики `sessions_spawn`, у яких пропущено `agentId` (примушує до явного вибору профілю). Типово: false. Виявлення: -- Використовуйте `agents_list`, щоб побачити, які id агентів зараз дозволені для `sessions_spawn`. +- Використовуйте `agents_list`, щоб побачити, які id агентів зараз дозволено для `sessions_spawn`. Автоархівація: -- Сесії субагентів автоматично архівуються після `agents.defaults.subagents.archiveAfterMinutes` (типове значення: 60). -- Архівація використовує `sessions.delete` і перейменовує транскрипт на `*.deleted.` (у тій самій папці). -- `cleanup: "delete"` архівує одразу після повідомлення (транскрипт усе одно зберігається через перейменування). -- Автоархівація працює за принципом best-effort; відкладені таймери втрачаються, якщо gateway перезапускається. -- `runTimeoutSeconds` **не** виконує автоархівацію; він лише зупиняє виконання. Сесія залишається до автоархівації. -- Автоархівація однаково застосовується до сесій глибини 1 і глибини 2. -- Очищення браузера відокремлене від очищення архіву: відстежувані вкладки/процеси браузера закриваються за принципом best-effort, коли виконання завершується, навіть якщо запис транскрипту/сесії зберігається. +- Сеанси підагентів автоматично архівуються після `agents.defaults.subagents.archiveAfterMinutes` (типово: 60). +- Архівування використовує `sessions.delete` і перейменовує транскрипт на `*.deleted.` (у тій самій папці). +- `cleanup: "delete"` архівує негайно після повідомлення (транскрипт усе одно зберігається через перейменування). +- Автоархівація виконується в режимі best-effort; заплановані таймери губляться, якщо Gateway перезапускається. +- `runTimeoutSeconds` **не** виконує автоархівацію; він лише зупиняє запуск. Сеанс залишається до автоархівації. +- Автоархівація однаково застосовується до сеансів глибини 1 і глибини 2. +- Очищення браузера є окремим від очищення архіву: відстежувані вкладки/процеси браузера закриваються в режимі best-effort, коли запуск завершується, навіть якщо запис транскрипту/сеансу зберігається. -## Вкладені субагенти +## Вкладені підагенти -Типово субагенти не можуть запускати власних субагентів (`maxSpawnDepth: 1`). Ви можете ввімкнути один рівень вкладеності, встановивши `maxSpawnDepth: 2`, що дозволяє **шаблон оркестратора**: main → субагент-оркестратор → робочі суб-субагенти. +За замовчуванням підагенти не можуть породжувати власних підагентів (`maxSpawnDepth: 1`). Ви можете ввімкнути один рівень вкладеності, встановивши `maxSpawnDepth: 2`, що дозволяє **шаблон оркестратора**: main → підагент-оркестратор → підагент-працівник нижчого рівня. ### Як увімкнути @@ -171,10 +171,10 @@ x-i18n: agents: { defaults: { subagents: { - maxSpawnDepth: 2, // дозволити субагентам запускати дочірні агенти (типово: 1) - maxChildrenPerAgent: 5, // максимальна кількість активних дочірніх агентів на одну сесію агента (типово: 5) - maxConcurrent: 8, // глобальне обмеження concurrency для lane (типово: 8) - runTimeoutSeconds: 900, // типовий timeout для sessions_spawn, коли його пропущено (0 = без timeout) + maxSpawnDepth: 2, // дозволити підагентам породжувати дочірні агенти (типово: 1) + maxChildrenPerAgent: 5, // максимальна кількість активних дочірніх агентів на сеанс агента (типово: 5) + maxConcurrent: 8, // глобальне обмеження паралельності для смуги (типово: 8) + runTimeoutSeconds: 900, // типовий тайм-аут для sessions_spawn, коли його пропущено (0 = без тайм-ауту) }, }, }, @@ -183,124 +183,124 @@ x-i18n: ### Рівні глибини -| Глибина | Форма ключа сесії | Роль | Може запускати? | -| ------- | ------------------------------------------- | -------------------------------------------- | ----------------------------- | -| 0 | `agent::main` | Основний агент | Завжди | -| 1 | `agent::subagent:` | Субагент (оркестратор, коли дозволено depth 2) | Лише якщо `maxSpawnDepth >= 2` | -| 2 | `agent::subagent::subagent:` | Суб-субагент (листовий worker) | Ніколи | +| Глибина | Форма ключа сеансу | Роль | Може породжувати? | +| ------- | -------------------------------------------- | --------------------------------------------- | ---------------------------- | +| 0 | `agent::main` | Основний агент | Завжди | +| 1 | `agent::subagent:` | Підагент (оркестратор, якщо дозволено глибину 2) | Лише якщо `maxSpawnDepth >= 2` | +| 2 | `agent::subagent::subagent:` | Підагент другого рівня (кінцевий виконавець) | Ніколи | ### Ланцюжок повідомлень -Результати рухаються вгору по ланцюжку: +Результати повертаються вгору по ланцюжку: -1. Worker глибини 2 завершується → повідомляє своєму батьківському оркестратору (глибина 1) +1. Працівник глибини 2 завершується → повідомляє своєму батьківському елементу (оркестратору глибини 1) 2. Оркестратор глибини 1 отримує повідомлення, синтезує результати, завершується → повідомляє main -3. Основний агент отримує повідомлення та доставляє його користувачу +3. Основний агент отримує повідомлення і доставляє його користувачу -Кожен рівень бачить повідомлення лише від своїх прямих дочірніх елементів. +Кожен рівень бачить лише повідомлення від своїх прямих дочірніх елементів. Операційні рекомендації: -- Запускайте дочірню роботу один раз і чекайте подій завершення замість побудови циклів опитування - навколо `sessions_list`, `sessions_history`, `/subagents list` або - `exec`-команд зі sleep. -- Якщо подія завершення дочірнього елемента надходить після того, як ви вже надіслали фінальну відповідь, - правильною подальшою дією є точний тихий токен `NO_REPLY` / `no_reply`. +- Запускайте дочірню роботу один раз і чекайте на події завершення замість побудови циклів + опитування навколо `sessions_list`, `sessions_history`, `/subagents list` або + команд `exec` із sleep. +- Якщо подія завершення дочірнього елемента приходить після того, як ви вже надіслали фінальну відповідь, + правильна подальша дія — це точний беззвучний токен `NO_REPLY` / `no_reply`. ### Політика інструментів за глибиною -- Роль і область керування записуються в метадані сесії під час spawn. Це не дає плоским або відновленим ключам сесії випадково знову отримати привілеї оркестратора. -- **Глибина 1 (оркестратор, коли `maxSpawnDepth >= 2`)**: отримує `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, щоб керувати своїми дочірніми елементами. Інші інструменти сесії/системи залишаються забороненими. -- **Глибина 1 (листовий елемент, коли `maxSpawnDepth == 1`)**: без інструментів сесії (поточна типова поведінка). -- **Глибина 2 (листовий worker)**: без інструментів сесії — `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: - `/stop` в основному чаті зупиняє всіх агентів глибини 1 і каскадно зупиняє їхніх дочірніх елементів глибини 2. -- `/subagents kill ` зупиняє конкретного субагента і каскадно зупиняє його дочірніх елементів. -- `/subagents kill all` зупиняє всіх субагентів для запитувача і виконує каскадну зупинку. +- `/subagents kill ` зупиняє конкретного підагента і каскадно зупиняє його дочірні елементи. +- `/subagents kill all` зупиняє всіх підагентів для запитувача і каскадно зупиняє їх. ## Автентифікація -Автентифікація субагента визначається за **id агента**, а не за типом сесії: +Автентифікація підагента визначається за **id агента**, а не за типом сеансу: -- Ключ сесії субагента — `agent::subagent:`. -- Сховище auth завантажується з `agentDir` цього агента. -- Профілі auth основного агента зливаються як **fallback**; профілі агента мають пріоритет у разі конфліктів. +- Ключ сеансу підагента — `agent::subagent:`. +- Сховище автентифікації завантажується з `agentDir` цього агента. +- Профілі автентифікації основного агента додаються як **резервний** варіант; профілі агента мають пріоритет над профілями основного агента в разі конфліктів. -Примітка: злиття є адитивним, тож профілі основного агента завжди доступні як fallback. Повністю ізольована auth для кожного агента поки що не підтримується. +Примітка: злиття є адитивним, тому профілі основного агента завжди доступні як резервні. Повністю ізольована автентифікація для кожного агента поки не підтримується. ## Повідомлення -Субагенти звітують назад через крок повідомлення: +Підагенти звітують назад через крок повідомлення: -- Крок повідомлення виконується всередині сесії субагента (а не сесії запитувача). -- Якщо субагент відповідає точно `ANNOUNCE_SKIP`, нічого не публікується. -- Якщо останній текст помічника — це точний тихий токен `NO_REPLY` / `no_reply`, +- Крок повідомлення виконується всередині сеансу підагента (а не сеансу запитувача). +- Якщо підагент відповідає рівно `ANNOUNCE_SKIP`, нічого не публікується. +- Якщо останній текст `assistant` — це точний беззвучний токен `NO_REPLY` / `no_reply`, вивід повідомлення пригнічується, навіть якщо раніше був видимий прогрес. - Інакше доставка залежить від глибини запитувача: - - сесії запитувача верхнього рівня використовують подальший виклик `agent` із зовнішньою доставкою (`deliver=true`) - - вкладені сесії субагентів-запитувачів отримують внутрішню ін’єкцію подальшої дії (`deliver=false`), щоб оркестратор міг синтезувати результати дочірніх елементів у межах сесії - - якщо вкладена сесія субагента-запитувача зникла, OpenClaw повертається до запитувача цієї сесії, коли це можливо -- Для сесій запитувача верхнього рівня пряма доставка в режимі завершення спочатку визначає будь-який маршрут прив’язаної розмови/треда та перевизначення hook, а потім заповнює відсутні поля channel-target із збереженого маршруту сесії запитувача. Це зберігає доставки завершення в правильному чаті/темі, навіть коли джерело завершення ідентифікує лише канал. -- Агрегація завершень дочірніх елементів обмежується поточним виконанням запитувача під час побудови вкладених результатів завершення, що запобігає витоку застарілих виводів дочірніх елементів із попередніх запусків у поточне повідомлення. -- Відповіді-повідомлення зберігають маршрутизацію треда/теми, коли вона доступна в адаптерах каналів. -- Контекст повідомлення нормалізується до стабільного внутрішнього блоку подій: + - сеанси запитувача верхнього рівня використовують подальший виклик `agent` із зовнішньою доставкою (`deliver=true`) + - вкладені сеанси підагентів запитувача отримують внутрішнє подальше впровадження (`deliver=false`), щоб оркестратор міг синтезувати результати дочірніх елементів у межах сеансу + - якщо вкладений сеанс підагента запитувача зник, OpenClaw, коли це можливо, повертається до запитувача цього сеансу +- Для сеансів запитувача верхнього рівня пряма доставка в режимі завершення спочатку визначає будь-який маршрут прив’язаної розмови/потоку та перевизначення hook, а потім заповнює відсутні поля цілі каналу зі збереженого маршруту сеансу запитувача. Це зберігає завершення в правильному чаті/темі, навіть коли джерело завершення вказує лише канал. +- Агрегація завершення дочірніх елементів обмежується поточним запуском запитувача під час побудови вкладених результатів завершення, що запобігає витоку застарілих виводів дочірніх елементів з попередніх запусків у поточне повідомлення. +- Відповіді повідомлення зберігають маршрутизацію потоку/теми, коли вона доступна в адаптерах каналів. +- Контекст повідомлення нормалізується до стабільного внутрішнього блоку події: - джерело (`subagent` або `cron`) - - ключ/id дочірньої сесії + - ключ/id дочірнього сеансу - тип повідомлення + мітка завдання - - рядок статусу, похідний від результату runtime (`success`, `error`, `timeout` або `unknown`) - - вміст результату, вибраний з останнього видимого тексту помічника, інакше санітизований останній текст tool/toolResult - - інструкція подальшої дії, яка описує, коли слід відповідати, а коли мовчати -- `Status` не виводиться з виводу моделі; він походить із сигналів результату runtime. -- У разі timeout, якщо дочірній елемент встиг лише до викликів інструментів, повідомлення може згорнути цю історію в коротке зведення часткового прогресу замість відтворення сирого виводу інструментів. + - рядок статусу, похідний від результату виконання (`success`, `error`, `timeout` або `unknown`) + - вміст результату, вибраний з останнього видимого тексту `assistant`, або, якщо його немає, санітизований останній текст tool/toolResult; термінальні невдалі запуски повідомляють про статус невдачі без повторення захопленого тексту відповіді + - подальша інструкція, яка описує, коли відповідати, а коли залишатися безмовним +- `Status` не виводиться з виводу моделі; він надходить із сигналів результату виконання. +- У разі тайм-ауту, якщо дочірній елемент встиг лише виконати виклики інструментів, повідомлення може згорнути цю історію до короткого підсумку часткового прогресу замість відтворення необробленого виводу інструментів. -Корисні навантаження повідомлень містять рядок статистики в кінці (навіть якщо вони обгорнуті): +Корисні навантаження повідомлень включають рядок статистики в кінці (навіть коли вони обгорнуті): - Runtime (наприклад, `runtime 5m12s`) - Використання токенів (input/output/total) -- Оцінена вартість, якщо налаштовано ціни моделей (`models.providers.*.models[].cost`) -- `sessionKey`, `sessionId` і шлях до транскрипту (щоб основний агент міг отримати історію через `sessions_history` або перевірити файл на диску) -- Внутрішні метадані призначені лише для оркестрації; відповіді, видимі користувачу, слід переписувати звичайним голосом помічника. +- Оцінена вартість, якщо для моделі налаштовано ціни (`models.providers.*.models[].cost`) +- `sessionKey`, `sessionId` і шлях до транскрипту (щоб основний агент міг отримати історію через `sessions_history` або переглянути файл на диску) +- Внутрішні метадані призначені лише для оркестрації; відповіді для користувача слід переписувати звичайним голосом помічника. `sessions_history` — безпечніший шлях оркестрації: -- згадування відповідей помічника спочатку нормалізується: - - thinking-теги видаляються +- історія `assistant` спочатку нормалізується: + - теги thinking видаляються - блоки каркаса `` / `` видаляються - - блоки XML-корисного навантаження викликів інструментів у звичайному тексті, як-от `...`, + - прості текстові XML-блоки корисного навантаження викликів інструментів, як-от `...`, `...`, `...` і - `...`, видаляються, включно з обрізаними - payload, які так і не закриваються коректно - - понижений каркас викликів/результатів інструментів та маркери історичного контексту видаляються - - витоки керівних токенів моделі, таких як `<|assistant|>`, інші ASCII + `...`, видаляються, включно з усіченими + корисними навантаженнями, які так і не закрилися належним чином + - знижені до нижчого рівня каркаси викликів/результатів інструментів і маркери історичного контексту видаляються + - витеклі керівні токени моделі, як-от `<|assistant|>`, інші ASCII токени `<|...|>` і повноширинні варіанти `<｜...｜>`, видаляються - некоректний XML викликів інструментів MiniMax видаляється - текст, схожий на облікові дані/токени, редагується -- довгі блоки можуть бути обрізані -- у дуже великих історіях старіші рядки можуть бути відкинуті або надто великий рядок може бути замінений на +- довгі блоки можуть бути усічені +- дуже великі історії можуть відкидати старіші рядки або замінювати надто великий рядок на `[sessions_history omitted: message too large]` -- перевірка сирого транскрипту на диску є fallback, коли вам потрібен повний побайтний транскрипт +- перегляд необробленого транскрипту на диску — резервний варіант, коли потрібен повний транскрипт байт-у-байт -## Політика інструментів (інструменти субагентів) +## Політика інструментів (інструменти підагента) -Типово субагенти отримують **усі інструменти, крім інструментів сесій** і системних інструментів: +За замовчуванням підагенти отримують **усі інструменти, крім інструментів сеансу** та системних інструментів: - `sessions_list` - `sessions_history` - `sessions_send` - `sessions_spawn` -`sessions_history` і тут залишається обмеженим, санітизованим представленням для згадування; це -не сирий дамп транскрипту. +`sessions_history` і тут залишається обмеженим, санітизованим переглядом історії; це не +необроблений дамп транскрипту. -Коли `maxSpawnDepth >= 2`, субагенти-оркестратори глибини 1 додатково отримують `sessions_spawn`, `subagents`, `sessions_list` і `sessions_history`, щоб керувати своїми дочірніми елементами. +Коли `maxSpawnDepth >= 2`, підагенти-оркестратори глибини 1 додатково отримують `sessions_spawn`, `subagents`, `sessions_list` і `sessions_history`, щоб керувати своїми дочірніми елементами. Перевизначення через конфігурацію: @@ -318,7 +318,7 @@ x-i18n: tools: { // deny має пріоритет deny: ["gateway", "cron"], - // якщо встановлено allow, політика стає лише allow-only (deny усе одно має пріоритет) + // якщо задано allow, діє режим лише allow (deny усе одно має пріоритет) // allow: ["read", "exec", "process"] }, }, @@ -326,23 +326,23 @@ x-i18n: } ``` -## Конкурентність +## Паралельність -Субагенти використовують окрему lane черги в межах процесу: +Підагенти використовують окрему вбудовану смугу черги: -- Назва lane: `subagent` -- Конкурентність: `agents.defaults.subagents.maxConcurrent` (типове значення `8`) +- Назва смуги: `subagent` +- Паралельність: `agents.defaults.subagents.maxConcurrent` (типово `8`) ## Зупинка -- Надсилання `/stop` у чаті запитувача перериває сесію запитувача та зупиняє всі активні виконання субагентів, запущені з неї, із каскадним поширенням на вкладених дочірніх елементів. -- `/subagents kill ` зупиняє конкретного субагента і каскадно зупиняє його дочірніх елементів. +- Надсилання `/stop` у чаті запитувача перериває сеанс запитувача і зупиняє всі активні запуски підагентів, породжені з нього, каскадно охоплюючи вкладених дочірніх елементів. +- `/subagents kill ` зупиняє конкретного підагента і каскадно зупиняє його дочірні елементи. ## Обмеження -- Повідомлення субагента працює за принципом **best-effort**. Якщо gateway перезапуститься, незавершена робота «повідомити назад» буде втрачена. -- Субагенти все ще спільно використовують ресурси того самого процесу gateway; розглядайте `maxConcurrent` як запобіжний клапан. -- `sessions_spawn` завжди є неблокувальним: він одразу повертає `{ status: "accepted", runId, childSessionKey }`. -- Контекст субагента ін’єктує лише `AGENTS.md` + `TOOLS.md` (без `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` або `BOOTSTRAP.md`). +- Повідомлення підагента — у режимі **best-effort**. Якщо Gateway перезапускається, незавершена робота з «повідомлення назад» втрачається. +- Підагенти все ще спільно використовують ресурси того самого процесу 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). +- `maxChildrenPerAgent` обмежує кількість активних дочірніх елементів на сеанс (типово: 5, діапазон: 1–20).