chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
29dd8c371e
commit
b6770c33fe
@ -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 — це **журнал активності**, який фіксує, яка відокремлена робота відбулася, коли саме, і чи була вона успішною.
|
||||
|
||||
<Note>
|
||||
Не кожен запуск агента створює завдання. Ходи Heartbeat і звичайний інтерактивний чат — ні. Усі виконання Cron, створення ACP, створення субагентів і команди агента CLI — так.
|
||||
Не кожен запуск агента створює завдання. Ходи Heartbeat і звичайний інтерактивний чат — ні. Усі виконання Cron, створення ACP, створення субагентів і команди агента через CLI — так.
|
||||
</Note>
|
||||
|
||||
## Коротко
|
||||
|
||||
- Завдання — це **записи**, а не планувальники: 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 <lookup>
|
||||
|
||||
# Скасувати запущене завдання (завершує дочірній сеанс)
|
||||
# Скасувати завдання, що виконується (завершує дочірній сеанс)
|
||||
openclaw tasks cancel <lookup>
|
||||
|
||||
# Змінити політику сповіщень для завдання
|
||||
openclaw tasks notify <lookup> state_changes
|
||||
|
||||
# Виконати аудит працездатності
|
||||
# Запустити перевірку стану
|
||||
openclaw tasks audit
|
||||
|
||||
# Переглянути або застосувати обслуговування
|
||||
@ -74,24 +74,24 @@ openclaw tasks flow cancel <lookup>
|
||||
|
||||
## Що створює завдання
|
||||
|
||||
| Джерело | Тип середовища виконання | Коли створюється запис завдання | Політика сповіщень за замовчуванням |
|
||||
| ---------------------- | ------------------------ | ------------------------------------------------------ | ----------------------------------- |
|
||||
| Фонові запуски 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 <lookup>
|
||||
```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.
|
||||
|
||||
<Tip>
|
||||
Завершення завдання негайно запускає пробудження Heartbeat, щоб ви швидко побачили результат — вам не потрібно чекати наступного запланованого тіку Heartbeat.
|
||||
Завершення завдання негайно пробуджує Heartbeat, тому ви швидко бачите результат — не потрібно чекати наступного запланованого тіку Heartbeat.
|
||||
</Tip>
|
||||
|
||||
Це означає, що типовий робочий процес побудований на push-моделі: один раз запускаєте відокремлену роботу, а далі середовище виконання саме пробуджує або сповіщає вас після завершення. Опитуйте стан завдання лише тоді, коли вам потрібні налагодження, втручання або явний аудит.
|
||||
Це означає, що типовий робочий процес базується на надсиланні подій: запустіть відокремлену роботу один раз, а потім дозвольте середовищу виконання пробудити або сповістити вас після завершення. Опитуйте стан завдання лише тоді, коли вам потрібне налагодження, втручання або явний аудит.
|
||||
|
||||
### Політики сповіщень
|
||||
|
||||
Керуйте тим, скільки інформації ви отримуєте про кожне завдання:
|
||||
|
||||
| Політика | Що доставляється |
|
||||
| --------------------- | ----------------------------------------------------------------------- |
|
||||
| `done_only` (default) | Лише термінальний стан (`succeeded`, `failed` тощо) — **це значення за замовчуванням** |
|
||||
| `state_changes` | Кожна зміна стану та оновлення прогресу |
|
||||
| `silent` | Нічого |
|
||||
| Політика | Що доставляється |
|
||||
| --------------------- | ------------------------------------------------------------------------ |
|
||||
| `done_only` (типово) | Лише термінальний стан (`succeeded`, `failed` тощо) — **це типове значення** |
|
||||
| `state_changes` | Кожен перехід стану й оновлення прогресу |
|
||||
| `silent` | Взагалі нічого |
|
||||
|
||||
Змінити політику під час виконання завдання:
|
||||
Змініть політику, поки завдання виконується:
|
||||
|
||||
```bash
|
||||
openclaw tasks notify <lookup> state_changes
|
||||
@ -165,7 +165,7 @@ openclaw tasks notify <lookup> state_changes
|
||||
openclaw tasks list [--runtime <acp|subagent|cron|cli>] [--status <status>] [--json]
|
||||
```
|
||||
|
||||
Стовпці виводу: ID завдання, Тип, Статус, Доставка, Run ID, Дочірній сеанс, Підсумок.
|
||||
Стовпці виводу: ID завдання, вид, статус, доставка, ID запуску, дочірній сеанс, зведення.
|
||||
|
||||
### `tasks show`
|
||||
|
||||
@ -173,7 +173,7 @@ openclaw tasks list [--runtime <acp|subagent|cron|cli>] [--status <status>] [--j
|
||||
openclaw tasks show <lookup>
|
||||
```
|
||||
|
||||
Токен lookup приймає ID завдання, run ID або ключ сеансу. Показує повний запис, включно з часом, станом доставки, помилкою та термінальним підсумком.
|
||||
Токен пошуку приймає ID завдання, ID запуску або ключ сеансу. Показує повний запис, зокрема час, стан доставки, помилку й термінальне зведення.
|
||||
|
||||
### `tasks cancel`
|
||||
|
||||
@ -181,7 +181,7 @@ openclaw tasks show <lookup>
|
||||
openclaw tasks cancel <lookup>
|
||||
```
|
||||
|
||||
Для завдань 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 <lookup> [--json]
|
||||
openclaw tasks flow cancel <lookup>
|
||||
```
|
||||
|
||||
Використовуйте ці команди, коли вас цікавить саме оркеструвальний 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
|
||||
|
||||
@ -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:<agentId>:subagent:<uuid>`) і після завершення **повідомляють** про свій результат назад у чат-канал запитувача. Кожне виконання субагента відстежується як [фонове завдання](/uk/automation/tasks).
|
||||
Підагенти — це фонові агентні запуски, породжені з наявного агентного запуску. Вони працюють у власному сеансі (`agent:<agentId>:subagent:<uuid>`) і після завершення **повідомляють** про свій результат назад у чат-канал запитувача. Кожен запуск підагента відстежується як [фонове завдання](/uk/automation/tasks).
|
||||
|
||||
## Слеш-команда
|
||||
## Slash-команда
|
||||
|
||||
Використовуйте `/subagents`, щоб переглядати або керувати виконаннями субагентів для **поточної сесії**:
|
||||
Використовуйте `/subagents`, щоб переглядати або керувати запусками підагентів для **поточного сеансу**:
|
||||
|
||||
- `/subagents list`
|
||||
- `/subagents kill <id|#|all>`
|
||||
@ -30,9 +30,9 @@ x-i18n:
|
||||
- `/subagents steer <id|#> <message>`
|
||||
- `/subagents spawn <agentId> <task> [--model <model>] [--thinking <level>]`
|
||||
|
||||
Елементи керування прив’язкою до тредів:
|
||||
Елементи керування прив’язкою до потоку:
|
||||
|
||||
Ці команди працюють у каналах, які підтримують постійні прив’язки тредів. Див. **Канали з підтримкою тредів** нижче.
|
||||
Ці команди працюють у каналах, які підтримують постійні прив’язки до потоків. Див. **Канали з підтримкою потоків** нижче.
|
||||
|
||||
- `/focus <subagent-label|session-key|session-id|session-label>`
|
||||
- `/unfocus`
|
||||
@ -40,129 +40,129 @@ x-i18n:
|
||||
- `/session idle <duration|off>`
|
||||
- `/session max-age <duration|off>`
|
||||
|
||||
`/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 <target>` прив’язує поточний тред (або створює його) до цілі субагента/сесії.
|
||||
- `/unfocus` прибирає прив’язку для поточного прив’язаного треда.
|
||||
- `/agents` перелічує активні виконання та стан прив’язки (`thread:<id>` або `unbound`).
|
||||
- `/session idle` і `/session max-age` працюють лише для сфокусованих прив’язаних тредів.
|
||||
- `/focus <target>` прив’язує поточний потік (або створює його) до цільового підагента/сеансу.
|
||||
- `/unfocus` видаляє прив’язку для поточного прив’язаного потоку.
|
||||
- `/agents` перелічує активні запуски та стан прив’язки (`thread:<id>` або `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.<timestamp>` (у тій самій папці).
|
||||
- `cleanup: "delete"` архівує одразу після повідомлення (транскрипт усе одно зберігається через перейменування).
|
||||
- Автоархівація працює за принципом best-effort; відкладені таймери втрачаються, якщо gateway перезапускається.
|
||||
- `runTimeoutSeconds` **не** виконує автоархівацію; він лише зупиняє виконання. Сесія залишається до автоархівації.
|
||||
- Автоархівація однаково застосовується до сесій глибини 1 і глибини 2.
|
||||
- Очищення браузера відокремлене від очищення архіву: відстежувані вкладки/процеси браузера закриваються за принципом best-effort, коли виконання завершується, навіть якщо запис транскрипту/сесії зберігається.
|
||||
- Сеанси підагентів автоматично архівуються після `agents.defaults.subagents.archiveAfterMinutes` (типово: 60).
|
||||
- Архівування використовує `sessions.delete` і перейменовує транскрипт на `*.deleted.<timestamp>` (у тій самій папці).
|
||||
- `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:<id>:main` | Основний агент | Завжди |
|
||||
| 1 | `agent:<id>:subagent:<uuid>` | Субагент (оркестратор, коли дозволено depth 2) | Лише якщо `maxSpawnDepth >= 2` |
|
||||
| 2 | `agent:<id>:subagent:<uuid>:subagent:<uuid>` | Суб-субагент (листовий worker) | Ніколи |
|
||||
| Глибина | Форма ключа сеансу | Роль | Може породжувати? |
|
||||
| ------- | -------------------------------------------- | --------------------------------------------- | ---------------------------- |
|
||||
| 0 | `agent:<id>:main` | Основний агент | Завжди |
|
||||
| 1 | `agent:<id>:subagent:<uuid>` | Підагент (оркестратор, якщо дозволено глибину 2) | Лише якщо `maxSpawnDepth >= 2` |
|
||||
| 2 | `agent:<id>:subagent:<uuid>:subagent:<uuid>` | Підагент другого рівня (кінцевий виконавець) | Ніколи |
|
||||
|
||||
### Ланцюжок повідомлень
|
||||
|
||||
Результати рухаються вгору по ланцюжку:
|
||||
Результати повертаються вгору по ланцюжку:
|
||||
|
||||
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 <id>` зупиняє конкретного субагента і каскадно зупиняє його дочірніх елементів.
|
||||
- `/subagents kill all` зупиняє всіх субагентів для запитувача і виконує каскадну зупинку.
|
||||
- `/subagents kill <id>` зупиняє конкретного підагента і каскадно зупиняє його дочірні елементи.
|
||||
- `/subagents kill all` зупиняє всіх підагентів для запитувача і каскадно зупиняє їх.
|
||||
|
||||
## Автентифікація
|
||||
|
||||
Автентифікація субагента визначається за **id агента**, а не за типом сесії:
|
||||
Автентифікація підагента визначається за **id агента**, а не за типом сеансу:
|
||||
|
||||
- Ключ сесії субагента — `agent:<agentId>:subagent:<uuid>`.
|
||||
- Сховище auth завантажується з `agentDir` цього агента.
|
||||
- Профілі auth основного агента зливаються як **fallback**; профілі агента мають пріоритет у разі конфліктів.
|
||||
- Ключ сеансу підагента — `agent:<agentId>:subagent:<uuid>`.
|
||||
- Сховище автентифікації завантажується з `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 видаляються
|
||||
- блоки каркаса `<relevant-memories>` / `<relevant_memories>` видаляються
|
||||
- блоки XML-корисного навантаження викликів інструментів у звичайному тексті, як-от `<tool_call>...</tool_call>`,
|
||||
- прості текстові XML-блоки корисного навантаження викликів інструментів, як-от `<tool_call>...</tool_call>`,
|
||||
`<function_call>...</function_call>`, `<tool_calls>...</tool_calls>` і
|
||||
`<function_calls>...</function_calls>`, видаляються, включно з обрізаними
|
||||
payload, які так і не закриваються коректно
|
||||
- понижений каркас викликів/результатів інструментів та маркери історичного контексту видаляються
|
||||
- витоки керівних токенів моделі, таких як `<|assistant|>`, інші ASCII
|
||||
`<function_calls>...</function_calls>`, видаляються, включно з усіченими
|
||||
корисними навантаженнями, які так і не закрилися належним чином
|
||||
- знижені до нижчого рівня каркаси викликів/результатів інструментів і маркери історичного контексту видаляються
|
||||
- витеклі керівні токени моделі, як-от `<|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 <id>` зупиняє конкретного субагента і каскадно зупиняє його дочірніх елементів.
|
||||
- Надсилання `/stop` у чаті запитувача перериває сеанс запитувача і зупиняє всі активні запуски підагентів, породжені з нього, каскадно охоплюючи вкладених дочірніх елементів.
|
||||
- `/subagents kill <id>` зупиняє конкретного підагента і каскадно зупиняє його дочірні елементи.
|
||||
|
||||
## Обмеження
|
||||
|
||||
- Повідомлення субагента працює за принципом **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).
|
||||
|
||||
Loading…
Reference in New Issue
Block a user