chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
47e2924cb3
commit
69f7ea3964
@ -1,21 +1,21 @@
|
||||
---
|
||||
read_when:
|
||||
- Планування фонових завдань або пробуджень
|
||||
- Підключення зовнішніх тригерів (Webhook, Gmail) до OpenClaw
|
||||
- Підключення зовнішніх тригерів (Webhook-ів, Gmail) до OpenClaw
|
||||
- Вибір між Heartbeat і Cron для запланованих завдань
|
||||
sidebarTitle: Scheduled tasks
|
||||
summary: Заплановані завдання, Webhook і тригери Gmail PubSub для планувальника Gateway
|
||||
summary: Заплановані завдання, Webhook-и та тригери Gmail PubSub для планувальника Gateway
|
||||
title: Заплановані завдання
|
||||
x-i18n:
|
||||
generated_at: "2026-04-27T06:49:34Z"
|
||||
generated_at: "2026-04-27T08:37:00Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: eb1b9215b46599ebcacc3f7c594da7254db269778efd3a5e7ae6564108d1cbff
|
||||
source_hash: 52d48c5d6f19fe9bcaae63afd6a736d953de3f25a710faae9c1ac1df0c081354
|
||||
source_path: automation/cron-jobs.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
Cron — це вбудований планувальник Gateway. Він зберігає завдання, пробуджує агента в потрібний час і може повертати результат назад у канал чату або на endpoint Webhook.
|
||||
Cron — це вбудований планувальник Gateway. Він зберігає завдання, пробуджує агента в потрібний час і може повертати результат назад у канал чату або на кінцеву точку Webhook.
|
||||
|
||||
## Швидкий старт
|
||||
|
||||
@ -48,37 +48,37 @@ Cron — це вбудований планувальник Gateway. Він зб
|
||||
|
||||
- Cron працює **всередині процесу Gateway** (а не всередині моделі).
|
||||
- Визначення завдань зберігаються в `~/.openclaw/cron/jobs.json`, тож перезапуски не призводять до втрати розкладів.
|
||||
- Стан виконання під час роботи зберігається поруч, у `~/.openclaw/cron/jobs-state.json`. Якщо ви відстежуєте визначення cron у git, відстежуйте `jobs.json`, а `jobs-state.json` додайте в gitignore.
|
||||
- Після розділення старіші версії OpenClaw можуть читати `jobs.json`, але можуть сприймати завдання як нові, оскільки поля часу виконання тепер містяться в `jobs-state.json`.
|
||||
- Якщо `jobs.json` редагується, поки Gateway запущений або зупинений, OpenClaw порівнює змінені поля розкладу з метаданими очікуваного слота часу виконання і очищає застарілі значення `nextRunAtMs`. Перезапис лише з форматуванням або зміною порядку ключів зберігає очікуваний слот.
|
||||
- Усі виконання cron створюють записи [фонових завдань](/uk/automation/tasks).
|
||||
- Одноразові завдання (`--at`) за замовчуванням автоматично видаляються після успішного виконання.
|
||||
- Ізольовані запуски cron під час завершення виконання намагаються закрити відстежувані вкладки браузера/процеси для своєї сесії `cron:<jobId>`, щоб відокремлена автоматизація браузера не залишала сирітські процеси.
|
||||
- Ізольовані запуски cron також захищаються від застарілих відповідей-підтверджень. Якщо перший результат — лише проміжне оновлення стану (`on it`, `pulling everything together` та подібні підказки), і жоден дочірній запуск субагента більше не відповідає за фінальну відповідь, OpenClaw ще раз формує запит для отримання фактичного результату перед доставкою.
|
||||
- Ізольовані запуски cron надають перевагу структурованим метаданим відмови у виконанні з вбудованого запуску, а потім використовують відомі маркери підсумку/виводу, як-от `SYSTEM_RUN_DENIED` і `INVALID_REQUEST`, щоб заблокована команда не позначалася як успішний запуск.
|
||||
- Ізольовані запуски cron також трактують збої агента на рівні запуску як помилки завдання, навіть якщо корисне навантаження відповіді не було створено, тож помилки моделі/провайдера збільшують лічильники помилок і запускають сповіщення про збої замість позначення завдання як успішного.
|
||||
- Стан виконання під час роботи зберігається поруч у `~/.openclaw/cron/jobs-state.json`. Якщо ви відстежуєте визначення Cron у git, відстежуйте `jobs.json`, а `jobs-state.json` додайте в gitignore.
|
||||
- Після цього розділення старіші версії OpenClaw можуть читати `jobs.json`, але можуть сприймати завдання як нові, оскільки поля виконання тепер зберігаються в `jobs-state.json`.
|
||||
- Коли `jobs.json` редагується під час роботи або зупинки Gateway, OpenClaw порівнює змінені поля розкладу з метаданими очікуваного слота виконання й очищає застарілі значення `nextRunAtMs`. Переформатування або переписування лише зі зміною порядку ключів зберігає очікуваний слот.
|
||||
- Усі виконання Cron створюють записи [фонових завдань](/uk/automation/tasks).
|
||||
- Одноразові завдання (`--at`) типово автоматично видаляються після успішного виконання.
|
||||
- Для ізольованих запусків Cron виконує best-effort закриття відстежуваних вкладок/процесів браузера для їхньої сесії `cron:<jobId>` після завершення запуску, щоб відокремлена автоматизація браузера не залишала сирітські процеси.
|
||||
- Ізольовані запуски Cron також захищаються від застарілих відповідей-підтверджень. Якщо перший результат — це лише проміжне оновлення стану (`on it`, `pulling everything together` та подібні підказки), і жоден дочірній запуск субагента більше не відповідає за фінальну відповідь, OpenClaw один раз повторно надсилає запит на фактичний результат перед доставкою.
|
||||
- Ізольовані запуски Cron віддають перевагу структурованим метаданим відмови у виконанні з вбудованого запуску, а потім використовують відомі маркери підсумку/виводу, як-от `SYSTEM_RUN_DENIED` і `INVALID_REQUEST`, щоб заблокована команда не позначалася як успішний запуск.
|
||||
- Ізольовані запуски Cron також трактують збої агента на рівні запуску як помилки завдання, навіть коли корисне навантаження відповіді відсутнє, тож збої моделі/провайдера збільшують лічильники помилок і запускають сповіщення про збої замість позначення завдання як успішного.
|
||||
|
||||
<a id="maintenance"></a>
|
||||
|
||||
<Note>
|
||||
Узгодження завдань для cron насамперед належить часу виконання, а вже потім спирається на довговічну історію: активне cron-завдання залишається активним, доки середовище виконання cron усе ще відстежує це завдання як запущене, навіть якщо старий рядок дочірньої сесії все ще існує. Щойно середовище виконання перестає володіти завданням і минає 5-хвилинне вікно очікування, перевірки обслуговування аналізують збережені журнали запусків і стан завдання для відповідного запуску `cron:<jobId>:<startedAt>`. Якщо ця довговічна історія показує кінцевий результат, журнал завдань фіналізується на її основі; інакше обслуговування, яким керує Gateway, може позначити завдання як `lost`. Офлайновий аудит CLI може відновитися з довговічної історії, але він не вважає власний порожній набір активних завдань у процесі доказом того, що cron-запуск, яким володіє Gateway, зник.
|
||||
Узгодження завдань для Cron спочатку належить середовищу виконання, а вже потім спирається на стійку історію: активне завдання Cron лишається активним, доки середовище виконання Cron все ще відстежує це завдання як таке, що виконується, навіть якщо старий рядок дочірньої сесії все ще існує. Щойно середовище виконання перестає володіти завданням і минає 5-хвилинне вікно пільгового часу, перевірки обслуговування звіряють збережені журнали запусків і стан завдання для відповідного запуску `cron:<jobId>:<startedAt>`. Якщо ця стійка історія показує термінальний результат, журнал завдань фіналізується на її основі; інакше обслуговування, яким володіє Gateway, може позначити завдання як `lost`. Автономний аудит CLI може відновитися зі стійкої історії, але не трактує власний порожній набір активних завдань у процесі як доказ того, що запуск Cron, яким володіє Gateway, зник.
|
||||
</Note>
|
||||
|
||||
## Типи розкладу
|
||||
|
||||
| Вид | Прапорець CLI | Опис |
|
||||
| ------- | ------------- | ------------------------------------------------------- |
|
||||
| `at` | `--at` | Одноразова часова позначка (ISO 8601 або відносна, як-от `20m`) |
|
||||
| `at` | `--at` | Одноразова мітка часу (ISO 8601 або відносна, наприклад `20m`) |
|
||||
| `every` | `--every` | Фіксований інтервал |
|
||||
| `cron` | `--cron` | 5-польовий або 6-польовий cron-вираз з необов’язковим `--tz` |
|
||||
|
||||
Часові позначки без часового поясу трактуються як UTC. Додайте `--tz America/New_York` для планування за локальним настінним часом.
|
||||
Мітки часу без часового поясу трактуються як UTC. Додайте `--tz America/New_York` для планування за місцевим часом.
|
||||
|
||||
Періодичні вирази на початок години автоматично розподіляються зі зсувом до 5 хвилин, щоб зменшити піки навантаження. Використовуйте `--exact` для примусового точного часу або `--stagger 30s` для явного вікна.
|
||||
Періодичні вирази на початок години автоматично розподіляються зі зсувом до 5 хвилин, щоб зменшити пікове навантаження. Використовуйте `--exact`, щоб примусово встановити точний час, або `--stagger 30s` для явного вікна.
|
||||
|
||||
### День місяця і день тижня використовують логіку OR
|
||||
### День місяця та день тижня використовують логіку OR
|
||||
|
||||
Cron-вирази розбираються за допомогою [croner](https://github.com/Hexagon/croner). Коли і поле дня місяця, і поле дня тижня не є wildcard, croner знаходить збіг, якщо **збігається будь-яке** з полів, а не обидва. Це стандартна поведінка Vixie cron.
|
||||
Cron-вирази розбираються за допомогою [croner](https://github.com/Hexagon/croner). Коли і поле дня місяця, і поле дня тижня не є wildcard, croner знаходить збіг, коли **збігається будь-яке** з полів, а не обидва. Це стандартна поведінка Vixie cron.
|
||||
|
||||
```
|
||||
# Intended: "9 AM on the 15th, only if it's a Monday"
|
||||
@ -86,34 +86,34 @@ Cron-вирази розбираються за допомогою [croner](http
|
||||
0 9 15 * 1
|
||||
```
|
||||
|
||||
Це спрацьовує приблизно 5–6 разів на місяць замість 0–1 разу на місяць. OpenClaw тут використовує стандартну OR-поведінку Croner. Щоб вимагати виконання обох умов, використовуйте модифікатор дня тижня `+` у Croner (`0 9 15 * +1`) або плануйте за одним полем, а інше перевіряйте в prompt чи команді вашого завдання.
|
||||
Це спрацьовує приблизно 5–6 разів на місяць замість 0–1 разу на місяць. OpenClaw тут використовує стандартну OR-поведінку Croner. Щоб вимагати виконання обох умов, використайте модифікатор дня тижня `+` у Croner (`0 9 15 * +1`) або заплануйте за одним полем, а іншу умову перевіряйте в запиті чи команді вашого завдання.
|
||||
|
||||
## Стилі виконання
|
||||
|
||||
| Стиль | Значення `--session` | Виконується в | Найкраще підходить для |
|
||||
| --------------- | -------------------- | ------------------------- | ------------------------------ |
|
||||
| Основна сесія | `main` | Наступний цикл Heartbeat | Нагадувань, системних подій |
|
||||
| Ізольований | `isolated` | Виділений `cron:<jobId>` | Звітів, фонових завдань |
|
||||
| Стиль | Значення `--session` | Виконується в | Найкраще підходить для |
|
||||
| --------------- | -------------------- | ------------------------ | -------------------------------- |
|
||||
| Основна сесія | `main` | Наступного Heartbeat | Нагадувань, системних подій |
|
||||
| Ізольований | `isolated` | Окремій `cron:<jobId>` | Звітів, фонових задач |
|
||||
| Поточна сесія | `current` | Прив’язується під час створення | Періодичної роботи з контекстом |
|
||||
| Власна сесія | `session:custom-id` | Постійна іменована сесія | Робочих процесів, що спираються на історію |
|
||||
| Власна сесія | `session:custom-id` | Постійній іменованій сесії | Робочих процесів, що будуються на історії |
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Основна сесія vs ізольована vs власна">
|
||||
Завдання **основної сесії** ставлять системну подію в чергу та, за потреби, пробуджують Heartbeat (`--wake now` або `--wake next-heartbeat`). Ці системні події не подовжують актуальність щоденного/неактивного скидання для цільової сесії. **Ізольовані** завдання запускають окремий цикл агента з новою сесією. **Власні сесії** (`session:xxx`) зберігають контекст між запусками, що дає змогу реалізовувати робочі процеси на кшталт щоденних стендапів, які спираються на попередні зведення.
|
||||
Завдання **основної сесії** ставлять системну подію в чергу й за потреби пробуджують Heartbeat (`--wake now` або `--wake next-heartbeat`). Такі системні події не подовжують актуальність щоденного/idle скидання для цільової сесії. **Ізольовані** завдання запускають окремий хід агента зі свіжою сесією. **Власні сесії** (`session:xxx`) зберігають контекст між запусками, що дає змогу будувати робочі процеси на кшталт щоденних стендапів на основі попередніх підсумків.
|
||||
</Accordion>
|
||||
<Accordion title="Що означає 'нова сесія' для ізольованих завдань">
|
||||
Для ізольованих завдань «нова сесія» означає новий transcript/session id для кожного запуску. OpenClaw може переносити безпечні вподобання, як-от налаштування thinking/fast/verbose, мітки та явні перевизначення моделі/автентифікації, вибрані користувачем, але не успадковує фоновий контекст розмови зі старого рядка cron: маршрутизацію каналу/групи, політику надсилання чи черги, підвищення привілеїв, походження або прив’язку часу виконання ACP. Використовуйте `current` або `session:<id>`, коли періодичне завдання має навмисно спиратися на той самий контекст розмови.
|
||||
<Accordion title="Що означає 'свіжа сесія' для ізольованих завдань">
|
||||
Для ізольованих завдань «свіжа сесія» означає новий ідентифікатор транскрипту/сесії для кожного запуску. OpenClaw може переносити безпечні налаштування, як-от параметри thinking/fast/verbose, мітки та явно вибрані користувачем перевизначення моделі/автентифікації, але не успадковує фоновий контекст розмови зі старішого рядка cron: маршрутизацію каналу/групи, політику надсилання чи черги, підвищення прав, походження або прив’язку середовища виконання ACP. Використовуйте `current` або `session:<id>`, коли періодичне завдання має навмисно розвиватися в межах того самого контексту розмови.
|
||||
</Accordion>
|
||||
<Accordion title="Очищення середовища виконання">
|
||||
Для ізольованих завдань завершення виконання тепер включає best-effort очищення браузера для цієї cron-сесії. Помилки очищення ігноруються, тож фактичний результат cron усе одно має пріоритет.
|
||||
Для ізольованих завдань завершення середовища виконання тепер також включає best-effort очищення браузера для цієї cron-сесії. Помилки очищення ігноруються, щоб фактичний результат Cron усе одно залишався визначальним.
|
||||
|
||||
Ізольовані запуски cron також знищують усі вбудовані екземпляри середовища виконання MCP, створені для завдання, через спільний шлях очищення середовища виконання. Це відповідає тому, як завершуються клієнти MCP для основної та власних сесій, тож ізольовані cron-завдання не залишають після себе дочірні stdio-процеси або довгоживучі з’єднання MCP між запусками.
|
||||
Ізольовані запуски Cron також звільняють усі вбудовані екземпляри середовища виконання MCP, створені для завдання, через спільний шлях очищення середовища виконання. Це відповідає тому, як завершується робота клієнтів MCP для основної та власної сесій, тож ізольовані Cron-завдання не залишають процеси stdio child або довготривалі MCP-з’єднання між запусками.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Доставка через субагента і Discord">
|
||||
Коли ізольовані запуски cron оркеструють субагентів, під час доставки також надається перевага фінальному виводу дочірнього елемента, а не застарілому проміжному тексту батьківського. Якщо дочірні елементи все ще виконуються, OpenClaw пригнічує таке часткове батьківське оновлення замість його оголошення.
|
||||
<Accordion title="Доставка через субагента та Discord">
|
||||
Коли ізольовані запуски Cron оркеструють субагентів, під час доставки також надається перевага фінальному виводу дочірнього нащадка, а не застарілому проміжному тексту батьківського запуску. Якщо нащадки все ще виконуються, OpenClaw пригнічує це часткове оновлення батьківського запуску, замість того щоб оголошувати його.
|
||||
|
||||
Для цілей оголошення в Discord лише з текстом OpenClaw надсилає канонічний фінальний текст асистента один раз, замість повторного відтворення як потокових/проміжних текстових payload, так і фінальної відповіді. Медіа та структуровані payload Discord, як і раніше, доставляються окремими payload, щоб вкладення та компоненти не губилися.
|
||||
Для цілей оголошення в Discord, що підтримують лише текст, OpenClaw надсилає канонічний фінальний текст асистента один раз, замість повторного відтворення як потокових/проміжних текстових payload-ів, так і фінальної відповіді. Медіа та структуровані payload-и Discord, як і раніше, доставляються окремо, щоб не втрачалися вкладення та компоненти.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@ -121,7 +121,7 @@ Cron-вирази розбираються за допомогою [croner](http
|
||||
### Параметри payload для ізольованих завдань
|
||||
|
||||
<ParamField path="--message" type="string" required>
|
||||
Текст prompt (обов’язковий для isolated).
|
||||
Текст запиту (обов’язковий для ізольованих).
|
||||
</ParamField>
|
||||
<ParamField path="--model" type="string">
|
||||
Перевизначення моделі; використовує вибрану дозволену модель для завдання.
|
||||
@ -130,46 +130,46 @@ Cron-вирази розбираються за допомогою [croner](http
|
||||
Перевизначення рівня thinking.
|
||||
</ParamField>
|
||||
<ParamField path="--light-context" type="boolean">
|
||||
Пропустити ін’єкцію bootstrap-файлу робочого простору.
|
||||
Пропустити ін’єкцію файлів початкового налаштування робочого простору.
|
||||
</ParamField>
|
||||
<ParamField path="--tools" type="string">
|
||||
Обмежити, які інструменти може використовувати завдання, наприклад `--tools exec,read`.
|
||||
Обмежити інструменти, які може використовувати завдання, наприклад `--tools exec,read`.
|
||||
</ParamField>
|
||||
|
||||
`--model` використовує вибрану дозволену модель для цього завдання. Якщо запитана модель не дозволена, cron записує попередження в журнал і натомість використовує вибір моделі агента/моделі за замовчуванням для завдання. Налаштовані ланцюжки резервного переходу все ще застосовуються, але звичайне перевизначення моделі без явного списку резервних варіантів для конкретного завдання більше не додає основну модель агента як приховану додаткову ціль для повторної спроби.
|
||||
`--model` використовує вибрану дозволену модель для цього завдання. Якщо запитана модель не дозволена, Cron записує попередження в журнал і замість цього повертається до вибору моделі агента/типової моделі для завдання. Налаштовані ланцюжки резервних варіантів, як і раніше, застосовуються, але просте перевизначення моделі без явного списку резервних варіантів для завдання більше не додає основну модель агента як приховану додаткову ціль повторної спроби.
|
||||
|
||||
Пріоритет вибору моделі для ізольованих завдань такий:
|
||||
Пріоритет вибору моделі для ізольованих завдань:
|
||||
|
||||
1. Перевизначення моделі Gmail hook (коли запуск надійшов із Gmail і це перевизначення дозволене)
|
||||
2. `model` у payload конкретного завдання
|
||||
3. Збережене перевизначення моделі cron-сесії, вибране користувачем
|
||||
4. Вибір моделі агента/за замовчуванням
|
||||
1. Перевизначення моделі Gmail hook (коли запуск походить із Gmail і це перевизначення дозволене)
|
||||
2. `model` у payload завдання
|
||||
3. Збережене перевизначення моделі сесії Cron, вибране користувачем
|
||||
4. Вибір моделі агента/типової моделі
|
||||
|
||||
Режим fast також дотримується визначеного поточного вибору. Якщо конфігурація вибраної моделі має `params.fastMode`, ізольований cron використовує його за замовчуванням. Збережене перевизначення `fastMode` сесії все одно має пріоритет над конфігурацією в обох напрямках.
|
||||
Швидкий режим також дотримується визначеного активного вибору. Якщо в конфігурації вибраної моделі задано `params.fastMode`, ізольований Cron типово використовує це значення. Збережене перевизначення `fastMode` для сесії все одно має вищий пріоритет над конфігурацією в будь-якому напрямку.
|
||||
|
||||
Якщо ізольований запуск натрапляє на передачу керування через live-перемикання моделі, cron повторює спробу з перемкненим провайдером/моделлю та зберігає цей live-вибір для активного запуску перед повторною спробою. Якщо перемикання також містить новий профіль автентифікації, cron також зберігає це перевизначення профілю автентифікації для активного запуску. Повторні спроби обмежені: після початкової спроби плюс 2 повторних спроб через перемикання cron перериває виконання замість нескінченного циклу.
|
||||
Якщо ізольований запуск стикається з передачею на живе перемикання моделі, Cron повторює спробу з перемкненим провайдером/моделлю та зберігає цей активний вибір для поточного запуску перед повторною спробою. Коли перемикання також містить новий профіль автентифікації, Cron теж зберігає це перевизначення профілю автентифікації для поточного запуску. Повторні спроби обмежені: після початкової спроби плюс 2 повторних спроб перемикання Cron перериває роботу, замість того щоб зациклитися назавжди.
|
||||
|
||||
## Доставка і вивід
|
||||
## Доставка та вивід
|
||||
|
||||
| Режим | Що відбувається |
|
||||
| ---------- | ---------------------------------------------------------------- |
|
||||
| `announce` | Резервно доставляє фінальний текст у ціль, якщо агент не надіслав |
|
||||
| `webhook` | Надсилає payload події завершення методом POST на URL |
|
||||
| `none` | Немає резервної доставки з боку виконавця |
|
||||
| Режим | Що відбувається |
|
||||
| ---------- | ------------------------------------------------------------------ |
|
||||
| `announce` | Резервно доставляє фінальний текст до цілі, якщо агент його не надіслав |
|
||||
| `webhook` | Надсилає payload завершеної події методом POST на URL |
|
||||
| `none` | Без резервної доставки з боку виконавця |
|
||||
|
||||
Використовуйте `--announce --channel telegram --to "-1001234567890"` для доставки в канал. Для тем форуму Telegram використовуйте `-1001234567890:topic:123`. Цілі Slack/Discord/Mattermost мають використовувати явні префікси (`channel:<id>`, `user:<id>`). Ідентифікатори кімнат Matrix чутливі до регістру; використовуйте точний room ID або форму `room:!room:server` із Matrix.
|
||||
Використовуйте `--announce --channel telegram --to "-1001234567890"` для доставки в канал. Для тем форуму Telegram використовуйте `-1001234567890:topic:123`. Для цілей Slack/Discord/Mattermost слід використовувати явні префікси (`channel:<id>`, `user:<id>`). Ідентифікатори кімнат Matrix чутливі до регістру; використовуйте точний ідентифікатор кімнати або форму `room:!room:server` із Matrix.
|
||||
|
||||
Для ізольованих завдань доставка в чат є спільною. Якщо маршрут чату доступний, агент може використовувати інструмент `message`, навіть коли завдання використовує `--no-deliver`. Якщо агент надсилає повідомлення до налаштованої/поточної цілі, OpenClaw пропускає резервне оголошення. В іншому разі `announce`, `webhook` і `none` керують лише тим, що виконавець робить із фінальною відповіддю після циклу агента.
|
||||
Для ізольованих завдань доставка в чат є спільною. Якщо маршрут чату доступний, агент може використовувати інструмент `message`, навіть коли для завдання задано `--no-deliver`. Якщо агент надсилає повідомлення в налаштовану/поточну ціль, OpenClaw пропускає резервне оголошення. Інакше `announce`, `webhook` і `none` лише визначають, що виконавець робить із фінальною відповіддю після ходу агента.
|
||||
|
||||
Коли агент створює ізольоване нагадування з активного чату, OpenClaw зберігає збережену поточну ціль доставки для резервного маршруту оголошення. Внутрішні ключі сесії можуть бути в нижньому регістрі; цілі доставки провайдера не реконструюються з цих ключів, коли доступний поточний контекст чату.
|
||||
Коли агент створює ізольоване нагадування з активного чату, OpenClaw зберігає збережену активну ціль доставки для маршруту резервного оголошення. Внутрішні ключі сесії можуть бути в нижньому регістрі; цілі доставки провайдера не реконструюються з цих ключів, коли доступний контекст поточного чату.
|
||||
|
||||
Сповіщення про збої використовують окремий шлях призначення:
|
||||
Сповіщення про збої йдуть окремим маршрутом призначення:
|
||||
|
||||
- `cron.failureDestination` задає глобальне значення за замовчуванням для сповіщень про збої.
|
||||
- `job.delivery.failureDestination` перевизначає його для конкретного завдання.
|
||||
- Якщо жодне не задано і завдання вже доставляє результат через `announce`, сповіщення про збої тепер за замовчуванням надсилаються до тієї ж основної цілі оголошення.
|
||||
- `delivery.failureDestination` підтримується лише для завдань `sessionTarget="isolated"`, якщо основний режим доставки не є `webhook`.
|
||||
- `failureAlert.includeSkipped: true` дозволяє завданню або глобальній політиці сповіщень cron включити повторні сповіщення про пропущені запуски. Пропущені запуски ведуть окремий лічильник послідовних пропусків, тож не впливають на backoff помилок виконання.
|
||||
- `cron.failureDestination` задає глобове типове значення для сповіщень про збої.
|
||||
- `job.delivery.failureDestination` перевизначає його для окремого завдання.
|
||||
- Якщо не задано жодного з них, а завдання вже доставляється через `announce`, сповіщення про збої тепер резервно надсилаються до цієї основної цілі оголошення.
|
||||
- `delivery.failureDestination` підтримується лише для завдань із `sessionTarget="isolated"`, якщо основний режим доставки не є `webhook`.
|
||||
- `failureAlert.includeSkipped: true` дозволяє для завдання або глобальної політики сповіщень Cron повторювані сповіщення про пропущені запуски. Пропущені запуски ведуть окремий лічильник послідовних пропусків, тому не впливають на відкладення після помилок виконання.
|
||||
|
||||
## Приклади CLI
|
||||
|
||||
@ -212,9 +212,9 @@ Cron-вирази розбираються за допомогою [croner](http
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Webhook
|
||||
## Webhook-и
|
||||
|
||||
Gateway може відкривати HTTP endpoint Webhook для зовнішніх тригерів. Увімкніть у конфігурації:
|
||||
Gateway може відкривати HTTP-кінцеві точки Webhook для зовнішніх тригерів. Увімкніть це в конфігурації:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -233,11 +233,11 @@ Gateway може відкривати HTTP endpoint Webhook для зовніш
|
||||
- `Authorization: Bearer <token>` (рекомендовано)
|
||||
- `x-openclaw-token: <token>`
|
||||
|
||||
Токени в query string відхиляються.
|
||||
Токени в query-string відхиляються.
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="POST /hooks/wake">
|
||||
Додає системну подію до черги для основної сесії:
|
||||
Додає системну подію в чергу для основної сесії:
|
||||
|
||||
```bash
|
||||
curl -X POST http://127.0.0.1:18789/hooks/wake \
|
||||
@ -255,7 +255,7 @@ Gateway може відкривати HTTP endpoint Webhook для зовніш
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="POST /hooks/agent">
|
||||
Запускає ізольований цикл агента:
|
||||
Запускає ізольований хід агента:
|
||||
|
||||
```bash
|
||||
curl -X POST http://127.0.0.1:18789/hooks/agent \
|
||||
@ -264,23 +264,23 @@ Gateway може відкривати HTTP endpoint Webhook для зовніш
|
||||
-d '{"message":"Summarize inbox","name":"Email","model":"openai/gpt-5.4"}'
|
||||
```
|
||||
|
||||
Поля: `message` (обов’язково), `name`, `agentId`, `wakeMode`, `deliver`, `channel`, `to`, `model`, `thinking`, `timeoutSeconds`.
|
||||
Поля: `message` (обов’язкове), `name`, `agentId`, `wakeMode`, `deliver`, `channel`, `to`, `model`, `thinking`, `timeoutSeconds`.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Зіставлені hook (POST /hooks/<name>)">
|
||||
Користувацькі назви hook зіставляються через `hooks.mappings` у конфігурації. Зіставлення можуть перетворювати довільні payload на дії `wake` або `agent` за допомогою шаблонів або перетворень коду.
|
||||
<Accordion title="Зіставлені hook-и (POST /hooks/<name>)">
|
||||
Власні назви hook-ів зіставляються через `hooks.mappings` у конфігурації. Зіставлення можуть перетворювати довільні payload-и на дії `wake` або `agent` за допомогою шаблонів або перетворень коду.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
<Warning>
|
||||
Тримайте endpoint hook за loopback, tailnet або довіреним reverse proxy.
|
||||
Тримайте кінцеві точки hook за loopback, tailnet або довіреним reverse proxy.
|
||||
|
||||
- Використовуйте окремий токен hook; не використовуйте повторно токени автентифікації gateway.
|
||||
- Тримайте `hooks.path` на окремому підшляху; `/` відхиляється.
|
||||
- Установіть `hooks.allowedAgentIds`, щоб обмежити явну маршрутизацію `agentId`.
|
||||
- Залишайте `hooks.allowRequestSessionKey=false`, якщо вам не потрібні сесії, вибрані викликачем.
|
||||
- Якщо ви вмикаєте `hooks.allowRequestSessionKey`, також установіть `hooks.allowedSessionKeyPrefixes`, щоб обмежити допустимі форми ключів сесії.
|
||||
- Payload hook за замовчуванням обгортаються межами безпеки.
|
||||
- Встановіть `hooks.allowedAgentIds`, щоб обмежити явну маршрутизацію `agentId`.
|
||||
- Залишайте `hooks.allowRequestSessionKey=false`, якщо вам не потрібні сесії, які вибирає викликач.
|
||||
- Якщо ви вмикаєте `hooks.allowRequestSessionKey`, також встановіть `hooks.allowedSessionKeyPrefixes`, щоб обмежити допустимі форми ключів сесій.
|
||||
- Payload-и hook-ів типово обгортаються межами безпеки.
|
||||
</Warning>
|
||||
|
||||
## Інтеграція Gmail PubSub
|
||||
@ -288,20 +288,20 @@ Gateway може відкривати HTTP endpoint Webhook для зовніш
|
||||
Підключіть тригери вхідних Gmail до OpenClaw через Google PubSub.
|
||||
|
||||
<Note>
|
||||
**Передумови:** CLI `gcloud`, `gog` (gogcli), увімкнені hook OpenClaw, Tailscale для публічного HTTPS endpoint.
|
||||
**Передумови:** CLI `gcloud`, `gog` (gogcli), увімкнені hook-и OpenClaw, Tailscale для публічної HTTPS-кінцевої точки.
|
||||
</Note>
|
||||
|
||||
### Налаштування через майстер (рекомендовано)
|
||||
### Налаштування майстром (рекомендовано)
|
||||
|
||||
```bash
|
||||
openclaw webhooks gmail setup --account openclaw@gmail.com
|
||||
```
|
||||
|
||||
Це записує конфігурацію `hooks.gmail`, вмикає пресет Gmail і використовує Tailscale Funnel для push endpoint.
|
||||
Це записує конфігурацію `hooks.gmail`, вмикає Gmail preset і використовує Tailscale Funnel для push-кінцевої точки.
|
||||
|
||||
### Автозапуск Gateway
|
||||
|
||||
Коли `hooks.enabled=true` і задано `hooks.gmail.account`, Gateway під час завантаження запускає `gog gmail watch serve` і автоматично поновлює watch. Установіть `OPENCLAW_SKIP_GMAIL_WATCHER=1`, щоб відмовитися від цього.
|
||||
Коли `hooks.enabled=true` і задано `hooks.gmail.account`, Gateway під час завантаження запускає `gog gmail watch serve` і автоматично поновлює watch. Щоб відмовитися від цього, встановіть `OPENCLAW_SKIP_GMAIL_WATCHER=1`.
|
||||
|
||||
### Ручне одноразове налаштування
|
||||
|
||||
@ -350,39 +350,39 @@ openclaw webhooks gmail setup --account openclaw@gmail.com
|
||||
## Керування завданнями
|
||||
|
||||
```bash
|
||||
# List all jobs
|
||||
# Перелічити всі завдання
|
||||
openclaw cron list
|
||||
|
||||
# Show one job, including resolved delivery route
|
||||
# Показати одне завдання, включно з визначеним маршрутом доставки
|
||||
openclaw cron show <jobId>
|
||||
|
||||
# Edit a job
|
||||
# Редагувати завдання
|
||||
openclaw cron edit <jobId> --message "Updated prompt" --model "opus"
|
||||
|
||||
# Force run a job now
|
||||
# Примусово запустити завдання зараз
|
||||
openclaw cron run <jobId>
|
||||
|
||||
# Run only if due
|
||||
# Запустити лише якщо настав час
|
||||
openclaw cron run <jobId> --due
|
||||
|
||||
# View run history
|
||||
# Переглянути історію запусків
|
||||
openclaw cron runs --id <jobId> --limit 50
|
||||
|
||||
# Delete a job
|
||||
# Видалити завдання
|
||||
openclaw cron remove <jobId>
|
||||
|
||||
# Agent selection (multi-agent setups)
|
||||
# Вибір агента (у конфігураціях із кількома агентами)
|
||||
openclaw cron add --name "Ops sweep" --cron "0 6 * * *" --session isolated --message "Check ops queue" --agent ops
|
||||
openclaw cron edit <jobId> --clear-agent
|
||||
```
|
||||
|
||||
<Note>
|
||||
Примітка щодо перевизначення моделі:
|
||||
Примітка про перевизначення моделі:
|
||||
|
||||
- `openclaw cron add|edit --model ...` змінює вибрану модель завдання.
|
||||
- Якщо модель дозволена, саме ця пара провайдер/модель передається в ізольований запуск агента.
|
||||
- Якщо вона не дозволена, cron виводить попередження і повертається до вибору моделі агента/моделі за замовчуванням для завдання.
|
||||
- Налаштовані ланцюжки резервного переходу все ще застосовуються, але звичайне перевизначення `--model` без явного списку резервних варіантів для конкретного завдання більше не переходить до основної моделі агента як до тихої додаткової цілі повторної спроби.
|
||||
- Якщо модель дозволена, саме ця пара провайдер/модель потрапляє до ізольованого запуску агента.
|
||||
- Якщо вона не дозволена, cron попереджає й повертається до вибору моделі агента/типової моделі для завдання.
|
||||
- Налаштовані ланцюжки резервних варіантів, як і раніше, застосовуються, але просте перевизначення `--model` без явного списку резервних варіантів для завдання більше не переходить до основної моделі агента як до тихої додаткової цілі повторної спроби.
|
||||
</Note>
|
||||
|
||||
## Конфігурація
|
||||
@ -405,21 +405,23 @@ openclaw cron edit <jobId> --clear-agent
|
||||
}
|
||||
```
|
||||
|
||||
Побічний файл стану часу виконання виводиться з `cron.store`: сховище `.json`, наприклад `~/clawd/cron/jobs.json`, використовує `~/clawd/cron/jobs-state.json`, тоді як до шляху сховища без суфікса `.json` додається `-state.json`.
|
||||
`maxConcurrentRuns` обмежує як заплановане диспетчеризування cron, так і виконання ізольованих ходів агента. Ізольовані ходи агента cron внутрішньо використовують lane виконання `nested` у черзі, тому збільшення цього значення дає змогу незалежним запуском Cron LLM просуватися паралельно, а не лише запускати їхні зовнішні обгортки cron.
|
||||
|
||||
Якщо ви редагуєте `jobs.json` вручну, не включайте `jobs-state.json` до системи контролю версій. OpenClaw використовує цей побічний файл для очікуваних слотів, активних маркерів, метаданих останнього запуску та ідентичності розкладу, яка повідомляє планувальнику, коли завданню, відредагованому зовні, потрібен новий `nextRunAtMs`.
|
||||
Sidecar стану виконання виводиться з `cron.store`: сховище `.json`, таке як `~/clawd/cron/jobs.json`, використовує `~/clawd/cron/jobs-state.json`, тоді як до шляху сховища без суфікса `.json` додається `-state.json`.
|
||||
|
||||
Якщо ви редагуєте `jobs.json` вручну, не додавайте `jobs-state.json` до системи контролю версій. OpenClaw використовує цей sidecar для очікуваних слотів, активних маркерів, метаданих останнього запуску та ідентичності розкладу, яка підказує планувальнику, коли завданню, відредагованому зовні, потрібен свіжий `nextRunAtMs`.
|
||||
|
||||
Вимкнення cron: `cron.enabled: false` або `OPENCLAW_SKIP_CRON=1`.
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Поведінка повторних спроб">
|
||||
**Повтор одноразового завдання**: тимчасові помилки (обмеження швидкості, перевантаження, мережа, помилка сервера) повторюються до 3 разів з експоненційним backoff. Постійні помилки вимикають завдання негайно.
|
||||
**Повторна спроба для одноразового завдання**: тимчасові помилки (ліміт запитів, перевантаження, мережа, помилка сервера) повторюються до 3 разів з експоненційною затримкою. Постійні помилки вимикають завдання негайно.
|
||||
|
||||
**Повтор періодичного завдання**: експоненційний backoff (від 30 с до 60 хв) між повторними спробами. Після наступного успішного запуску backoff скидається.
|
||||
**Повторна спроба для періодичного завдання**: експоненційна затримка (від 30 с до 60 хв) між повторними спробами. Затримка скидається після наступного успішного запуску.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Обслуговування">
|
||||
`cron.sessionRetention` (типово `24h`) очищає записи сесій ізольованих запусків. `cron.runLog.maxBytes` / `cron.runLog.keepLines` автоматично очищають файли журналів запусків.
|
||||
`cron.sessionRetention` (типово `24h`) очищає записи сесій ізольованих запусків. `cron.runLog.maxBytes` / `cron.runLog.keepLines` автоматично очищають файли журналу запусків.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@ -443,31 +445,31 @@ openclaw doctor
|
||||
- Перевірте `cron.enabled` і змінну середовища `OPENCLAW_SKIP_CRON`.
|
||||
- Переконайтеся, що Gateway працює безперервно.
|
||||
- Для розкладів `cron` перевірте часовий пояс (`--tz`) відносно часового поясу хоста.
|
||||
- `reason: not-due` у виводі запуску означає, що ручний запуск було перевірено через `openclaw cron run <jobId> --due`, і час виконання завдання ще не настав.
|
||||
- `reason: not-due` у виводі запуску означає, що ручний запуск було перевірено через `openclaw cron run <jobId> --due`, але час для завдання ще не настав.
|
||||
</Accordion>
|
||||
<Accordion title="Cron спрацював, але доставки немає">
|
||||
- Режим доставки `none` означає, що резервне надсилання з боку виконавця не очікується. Агент усе одно може надсилати напряму через інструмент `message`, коли маршрут чату доступний.
|
||||
- Режим доставки `none` означає, що резервне надсилання з боку виконавця не очікується. Агент усе ще може надсилати напряму через інструмент `message`, коли маршрут чату доступний.
|
||||
- Відсутня/некоректна ціль доставки (`channel`/`to`) означає, що вихідне надсилання було пропущено.
|
||||
- Для Matrix скопійовані або застарілі завдання з room ID у `delivery.to`, перетвореним на нижній регістр, можуть завершитися невдачею, оскільки room ID у Matrix чутливі до регістру. Відредагуйте завдання, вказавши точне значення `!room:server` або `room:!room:server` із Matrix.
|
||||
- Для Matrix скопійовані або застарілі завдання з ідентифікаторами кімнат `delivery.to` у нижньому регістрі можуть не спрацювати, оскільки ідентифікатори кімнат Matrix чутливі до регістру. Відредагуйте завдання, вказавши точне значення `!room:server` або `room:!room:server` із Matrix.
|
||||
- Помилки автентифікації каналу (`unauthorized`, `Forbidden`) означають, що доставку було заблоковано обліковими даними.
|
||||
- Якщо ізольований запуск повертає лише тихий токен (`NO_REPLY` / `no_reply`), OpenClaw пригнічує пряме вихідне надсилання, а також резервний шлях зведення в черзі, тож назад у чат нічого не публікується.
|
||||
- Якщо агент має сам надсилати повідомлення користувачу, перевірте, що завдання має придатний маршрут (`channel: "last"` із попереднім чатом або явний канал/ціль).
|
||||
- Якщо ізольований запуск повертає лише тихий токен (`NO_REPLY` / `no_reply`), OpenClaw пригнічує пряме вихідне надсилання, а також резервний шлях підсумку через чергу, тож назад у чат нічого не публікується.
|
||||
- Якщо агент має сам написати користувачу, перевірте, що завдання має придатний маршрут (`channel: "last"` із попереднім чатом або явний канал/ціль).
|
||||
</Accordion>
|
||||
<Accordion title="Схоже, що Cron або Heartbeat заважає rollover у стилі /new">
|
||||
- Актуальність щоденного скидання й скидання через неактивність не базується на `updatedAt`; див. [Керування сесіями](/uk/concepts/session#session-lifecycle).
|
||||
- Пробудження cron, запуски Heartbeat, сповіщення exec і службові дії gateway можуть оновлювати рядок сесії для маршрутизації/стану, але вони не подовжують `sessionStartedAt` або `lastInteractionAt`.
|
||||
- Для застарілих рядків, створених до появи цих полів, OpenClaw може відновити `sessionStartedAt` із заголовка сесії в transcript JSONL, якщо файл усе ще доступний. Для застарілих рядків неактивності без `lastInteractionAt` це відновлене значення часу старту використовується як базова точка неактивності.
|
||||
- Актуальність щоденного та idle скидання не базується на `updatedAt`; див. [Керування сесіями](/uk/concepts/session#session-lifecycle).
|
||||
- Пробудження Cron, запуски Heartbeat, сповіщення exec і службові дії gateway можуть оновлювати рядок сесії для маршрутизації/стану, але не подовжують `sessionStartedAt` або `lastInteractionAt`.
|
||||
- Для застарілих рядків, створених до появи цих полів, OpenClaw може відновити `sessionStartedAt` із заголовка сесії transcript JSONL, якщо файл усе ще доступний. Для застарілих idle-рядків без `lastInteractionAt` як idle-базову мітку використовується цей відновлений час початку.
|
||||
</Accordion>
|
||||
<Accordion title="Підводні камені часових поясів">
|
||||
- Cron без `--tz` використовує часовий пояс хоста gateway.
|
||||
- Розклади `at` без часового поясу трактуються як UTC.
|
||||
- Heartbeat `activeHours` використовує налаштоване визначення часового поясу.
|
||||
- `activeHours` у Heartbeat використовує визначення часового поясу з конфігурації.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Автоматизація і завдання](/uk/automation) — огляд усіх механізмів автоматизації
|
||||
- [Автоматизація й завдання](/uk/automation) — усі механізми автоматизації з першого погляду
|
||||
- [Фонові завдання](/uk/automation/tasks) — журнал завдань для виконань cron
|
||||
- [Heartbeat](/uk/gateway/heartbeat) — періодичні цикли основної сесії
|
||||
- [Часовий пояс](/uk/concepts/timezone) — налаштування часового поясу
|
||||
- [Heartbeat](/uk/gateway/heartbeat) — періодичні ходи основної сесії
|
||||
- [Часовий пояс](/uk/concepts/timezone) — конфігурація часового поясу
|
||||
|
||||
@ -1,53 +1,52 @@
|
||||
---
|
||||
read_when:
|
||||
- Зміна виконання автовідповіді або конкурентності
|
||||
summary: Дизайн черги команд, що серіалізує вхідні запуски автовідповіді
|
||||
- Зміна виконання автоматичних відповідей або паралелізму
|
||||
summary: Проєктування черги команд, яка серіалізує вхідні запуски автоматичних відповідей
|
||||
title: черга команд
|
||||
x-i18n:
|
||||
generated_at: "2026-04-24T18:09:52Z"
|
||||
generated_at: "2026-04-27T08:36:59Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 0c027be3e9a67f91a49c5d4d69fa8191d3e7651265a152c4723b10062b339f2a
|
||||
source_hash: 90824e592379b46b568b9f7ab017c2d68bf9b741349fe88f63e358a4c8754751
|
||||
source_path: concepts/queue.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
Ми серіалізуємо вхідні запуски автовідповіді (усі канали) через невелику внутрішньопроцесну чергу, щоб запобігти конфліктам між кількома запусками агентів, водночас зберігаючи безпечний паралелізм між сесіями.
|
||||
Ми серіалізуємо вхідні запуски автоматичних відповідей (усі канали) через невелику внутрішньопроцесну чергу, щоб запобігти колізіям між кількома запусками агентів, водночас зберігаючи безпечний паралелізм між сесіями.
|
||||
|
||||
## Чому
|
||||
## Навіщо
|
||||
|
||||
- Запуски автовідповіді можуть бути дорогими (виклики LLM) і можуть конфліктувати, коли кілька вхідних повідомлень надходять майже одночасно.
|
||||
- Серіалізація запобігає конкуренції за спільні ресурси (файли сесій, журнали, CLI stdin) і зменшує ймовірність обмежень швидкості з боку зовнішніх сервісів.
|
||||
- Запуски автоматичних відповідей можуть бути дорогими (виклики LLM) і можуть конфліктувати, коли кілька вхідних повідомлень надходять майже одночасно.
|
||||
- Серіалізація допомагає уникнути конкуренції за спільні ресурси (файли сесій, журнали, stdin CLI) і зменшує ймовірність обмежень швидкості з боку зовнішніх сервісів.
|
||||
|
||||
## Як це працює
|
||||
|
||||
- FIFO-черга з урахуванням lane обробляє кожен lane з налаштованим обмеженням конкурентності (типово 1 для неналаштованих lane; `main` типово має 4, `subagent` — 8).
|
||||
- `runEmbeddedPiAgent` ставить у чергу за **ключем сесії** (lane `session:<key>`), щоб гарантувати лише один активний запуск на сесію.
|
||||
- Потім кожен запуск сесії ставиться в **глобальний lane** (`main` типово), тож загальний паралелізм обмежується через `agents.defaults.maxConcurrent`.
|
||||
- Коли ввімкнено докладне журналювання, запуски в черзі видають коротке повідомлення, якщо вони чекали понад ~2 с перед початком.
|
||||
- Індикатори набору тексту все одно спрацьовують одразу під час постановки в чергу (коли це підтримує канал), тож користувацький досвід не змінюється, поки ми чекаємо своєї черги.
|
||||
- Черга FIFO з урахуванням смуг обробляє кожну смугу з налаштовуваним лімітом паралелізму (типово 1 для неналаштованих смуг; `main` типово 4, `subagent` — 8).
|
||||
- `runEmbeddedPiAgent` ставить завдання в чергу за **ключем сесії** (смуга `session:<key>`), щоб гарантувати лише один активний запуск на сесію.
|
||||
- Потім кожен запуск сесії ставиться в **глобальну смугу** (`main` типово), щоб загальний паралелізм обмежувався `agents.defaults.maxConcurrent`.
|
||||
- Коли ввімкнено докладне логування, запуски в черзі виводять коротке повідомлення, якщо вони чекали понад ~2 с перед стартом.
|
||||
- Індикатори набору тексту, як і раніше, спрацьовують одразу під час додавання до черги (якщо це підтримує канал), тому користувацький досвід не змінюється, поки ми чекаємо своєї черги.
|
||||
|
||||
## Режими черги (для кожного каналу)
|
||||
|
||||
Вхідні повідомлення можуть спрямовувати поточний запуск, чекати наступного ходу або робити обидва варіанти:
|
||||
Вхідні повідомлення можуть спрямовувати поточний запуск, чекати наступного ходу, або робити і те, і інше:
|
||||
|
||||
- `steer`: негайно вбудовує повідомлення в поточний запуск (скасовує відкладені виклики інструментів після наступної межі інструмента). Якщо streaming вимкнено, повертається до followup.
|
||||
- `followup`: ставить у чергу на наступний хід агента після завершення поточного запуску.
|
||||
- `collect`: об’єднує всі повідомлення в черзі в **один** хід followup (типово). Якщо повідомлення націлені на різні канали/гілки, вони обробляються окремо, щоб зберегти маршрутизацію.
|
||||
- `steer-backlog` (також `steer+backlog`): спрямовує зараз **і** зберігає повідомлення для ходу followup.
|
||||
- `interrupt` (застаріле): перериває активний запуск для цієї сесії, а потім запускає найновіше повідомлення.
|
||||
- `steer`: негайно вбудувати в поточний запуск (скасовує відкладені виклики інструментів після наступної межі інструмента). Якщо потокове передавання не активне, повертається до `followup`.
|
||||
- `followup`: поставити в чергу на наступний хід агента після завершення поточного запуску.
|
||||
- `collect`: об’єднати всі повідомлення в черзі в **один** наступний хід (типово). Якщо повідомлення націлені на різні канали/гілки, вони обробляються окремо, щоб зберегти маршрутизацію.
|
||||
- `steer-backlog` (також `steer+backlog`): спрямувати зараз **і** зберегти повідомлення для наступного ходу.
|
||||
- `interrupt` (застаріле): перервати активний запуск для цієї сесії, а потім запустити найновіше повідомлення.
|
||||
- `queue` (застарілий псевдонім): те саме, що `steer`.
|
||||
|
||||
`steer-backlog` означає, що ви можете отримати відповідь followup після спрямованого запуску, тому
|
||||
поверхні зі streaming можуть виглядати як дублікати. Якщо ви хочете
|
||||
одну відповідь на кожне вхідне повідомлення, надайте перевагу `collect`/`steer`.
|
||||
Надішліть `/queue collect` як окрему команду (для сесії) або встановіть `messages.queue.byChannel.discord: "collect"`.
|
||||
`Steer-backlog` означає, що після спрямованого запуску ви можете отримати відповідь у наступному ході, тому на поверхнях із потоковим передаванням це може виглядати як дублікати. Віддавайте перевагу `collect`/`steer`, якщо хочете
|
||||
одну відповідь на кожне вхідне повідомлення.
|
||||
Надішліть `/queue collect` як окрему команду (для конкретної сесії) або встановіть `messages.queue.byChannel.discord: "collect"`.
|
||||
|
||||
Типові значення (якщо не задано в конфігурації):
|
||||
Типові значення (якщо в конфігурації не задано):
|
||||
|
||||
- Усі поверхні → `collect`
|
||||
|
||||
Налаштування глобально або для окремого каналу через `messages.queue`:
|
||||
Налаштовуйте глобально або для окремого каналу через `messages.queue`:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -65,33 +64,33 @@ x-i18n:
|
||||
|
||||
## Параметри черги
|
||||
|
||||
Параметри застосовуються до `followup`, `collect` і `steer-backlog` (а також до `steer`, коли він повертається до followup):
|
||||
Параметри застосовуються до `followup`, `collect` і `steer-backlog` (а також до `steer`, коли він повертається до `followup`):
|
||||
|
||||
- `debounceMs`: очікувати тиші перед запуском ходу followup (запобігає “continue, continue”).
|
||||
- `cap`: максимальна кількість повідомлень у черзі на сесію.
|
||||
- `debounceMs`: чекати тиші перед запуском наступного ходу (запобігає «continue, continue»).
|
||||
- `cap`: максимальна кількість повідомлень у черзі для однієї сесії.
|
||||
- `drop`: політика переповнення (`old`, `new`, `summarize`).
|
||||
|
||||
`Summarize` зберігає короткий маркірований список відкинутих повідомлень і вставляє його як синтетичний prompt followup.
|
||||
`Summarize` зберігає короткий список маркерів видалених повідомлень і додає його як синтетичний prompt наступного ходу.
|
||||
Типові значення: `debounceMs: 1000`, `cap: 20`, `drop: summarize`.
|
||||
|
||||
## Перевизначення для сесії
|
||||
## Перевизначення для конкретної сесії
|
||||
|
||||
- Надішліть `/queue <mode>` як окрему команду, щоб зберегти режим для поточної сесії.
|
||||
- Параметри можна комбінувати: `/queue collect debounce:2s cap:25 drop:summarize`
|
||||
- `/queue default` або `/queue reset` очищає перевизначення для сесії.
|
||||
- Параметри можна поєднувати: `/queue collect debounce:2s cap:25 drop:summarize`
|
||||
- `/queue default` або `/queue reset` очищує перевизначення для сесії.
|
||||
|
||||
## Область дії та гарантії
|
||||
|
||||
- Застосовується до запусків агентів автовідповіді в усіх вхідних каналах, що використовують конвеєр відповіді gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat тощо).
|
||||
- Типовий lane (`main`) є спільним для всього процесу для вхідних повідомлень і основних Heartbeat; установіть `agents.defaults.maxConcurrent`, щоб дозволити кілька паралельних сесій.
|
||||
- Можуть існувати додаткові lane (наприклад, `cron`, `subagent`), щоб фонові завдання могли виконуватися паралельно, не блокуючи вхідні відповіді. Ці відокремлені запуски відстежуються як [фонові завдання](/uk/automation/tasks).
|
||||
- Lane рівня сесії гарантують, що лише один запуск агента торкається певної сесії в один момент часу.
|
||||
- Без зовнішніх залежностей або фонових worker threads; чистий TypeScript + promises.
|
||||
- Застосовується до запусків агентів автоматичних відповідей в усіх вхідних каналах, які використовують конвеєр відповідей Gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat тощо).
|
||||
- Типова смуга (`main`) є загальнопроцесною для вхідних повідомлень + основних Heartbeat; установіть `agents.defaults.maxConcurrent`, щоб дозволити паралельну обробку кількох сесій.
|
||||
- Можуть існувати додаткові смуги (наприклад, `cron`, `nested`, `subagent`), щоб фонові завдання могли виконуватися паралельно й не блокували вхідні відповіді. Ізольовані ходи агентів Cron утримують слот `cron`, тоді як їхнє внутрішнє виконання агента використовує `nested`; обидва використовують `cron.maxConcurrentRuns`. Ці відокремлені запуски відстежуються як [фонові завдання](/uk/automation/tasks).
|
||||
- Смуги на рівні сесії гарантують, що лише один запуск агента одночасно працює з конкретною сесією.
|
||||
- Жодних зовнішніх залежностей або фонових робочих потоків; лише чистий TypeScript і promise.
|
||||
|
||||
## Усунення проблем
|
||||
## Усунення несправностей
|
||||
|
||||
- Якщо команди здаються завислими, увімкніть докладні журнали та шукайте рядки “queued for …ms”, щоб підтвердити, що черга обробляється.
|
||||
- Якщо вам потрібна глибина черги, увімкніть докладні журнали та стежте за рядками з часовими показниками черги.
|
||||
- Якщо команди виглядають завислими, увімкніть докладні журнали й шукайте рядки на кшталт «queued for …ms», щоб підтвердити, що черга обробляється.
|
||||
- Якщо вам потрібна глибина черги, увімкніть докладні журнали та стежте за рядками з часом черги.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user