chore(i18n): refresh uk translations
This commit is contained in:
parent
ac65c9db37
commit
f7182d4142
@ -1,65 +1,65 @@
|
||||
---
|
||||
read_when:
|
||||
- Ви хочете, щоб просування пам’яті виконувалося автоматично
|
||||
- Ви хочете зрозуміти три фази Dreaming
|
||||
- Ви хочете налаштувати консолідацію без засмічення `MEMORY.md`
|
||||
summary: 'Фонове консолідування пам’яті з трьома кооперативними фазами: light, deep і REM'
|
||||
- Ви хочете зрозуміти три фази dreaming
|
||||
- Ви хочете налаштувати консолідацію, не засмічуючи `MEMORY.md`
|
||||
summary: 'Фонова консолідація пам’яті з трьома кооперативними фазами: light, deep і REM'
|
||||
title: Dreaming (експериментально)
|
||||
x-i18n:
|
||||
generated_at: "2026-04-05T22:59:56Z"
|
||||
generated_at: "2026-04-05T23:42:30Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: e6a82edf0b8630b48f458dacc270b0afc4032d5756baf39e28bf142e53cd8080
|
||||
source_hash: 9ba56b20013aa53f5f440fd79ea14dc67a61c4fb63ebe91b3fd183d09a842912
|
||||
source_path: concepts/dreaming.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Dreaming (експериментально)
|
||||
|
||||
Dreaming — це система фонового консолідування пам’яті в `memory-core`. Вона
|
||||
Dreaming — це система фонової консолідації пам’яті в `memory-core`. Вона
|
||||
повторно переглядає те, що з’являлося під час розмов, і вирішує, що варто
|
||||
зберегти як стійкий контекст.
|
||||
зберегти як довготривалий контекст.
|
||||
|
||||
Dreaming використовує три кооперативні **фази**, а не конкурувальні режими. Кожна фаза має
|
||||
окреме завдання, записує в окреме призначення і виконується за власним розкладом.
|
||||
Dreaming використовує три кооперативні **фази**, а не конкуруючі режими. Кожна фаза має
|
||||
окреме завдання, записує в окрему ціль і виконується за власним розкладом.
|
||||
|
||||
## Три фази
|
||||
|
||||
### Light
|
||||
|
||||
Фаза light dreaming впорядковує недавній безлад. Вона сканує недавні сліди пам’яті, видаляє дублікати
|
||||
за схожістю Жаккара, кластеризує пов’язані записи та готує кандидатів
|
||||
пам’яті у спільному файлі сліду dreaming (`DREAMS.md`), коли ввімкнено inline-зберігання.
|
||||
Light dreaming впорядковує недавній хаос. Вона сканує недавні сліди пам’яті, усуває дублікати
|
||||
за схожістю Жаккара, кластеризує пов’язані записи та готує кандидатні
|
||||
спогади у спільному файлі сліду dreaming (`DREAMS.md`), коли ввімкнено inline-зберігання.
|
||||
|
||||
Light **не** записує нічого в `MEMORY.md`. Вона лише організовує та
|
||||
готує. Простими словами: «що із сьогоднішнього може мати значення пізніше?»
|
||||
Light **не** записує нічого до `MEMORY.md`. Вона лише організовує та
|
||||
готує. Уявіть: «що із сьогоднішнього може бути важливим пізніше?»
|
||||
|
||||
### Deep
|
||||
|
||||
Фаза deep dreaming вирішує, що стає довготривалою пам’яттю. Вона виконує справжню логіку
|
||||
просування: зважене оцінювання за шістьма сигналами, порогові перевірки,
|
||||
кількість згадувань, різноманітність унікальних запитів, спадання за давністю та фільтрацію за максимальним віком.
|
||||
Deep dreaming вирішує, що стає довготривалою пам’яттю. Вона виконує справжню логіку
|
||||
просування: зважене оцінювання за шістьма сигналами, порогові перевірки, кількість
|
||||
згадувань, різноманітність унікальних запитів, згасання за давністю та фільтрацію за максимальним віком.
|
||||
|
||||
Deep — це **єдина** фаза, якій дозволено записувати стійкі факти в `MEMORY.md`.
|
||||
Вона також відповідає за відновлення, коли пам’ять збіднена (здоров’я падає нижче за
|
||||
налаштований поріг). Простими словами: «що є достатньо істинним, щоб це зберегти?»
|
||||
Deep — це **єдина** фаза, якій дозволено записувати довготривалі факти до `MEMORY.md`.
|
||||
Вона також відповідає за відновлення, коли пам’яті мало (рівень здоров’я падає нижче
|
||||
налаштованого порога). Уявіть: «що є достатньо правдивим, щоб це зберегти?»
|
||||
|
||||
### REM
|
||||
|
||||
Фаза REM dreaming шукає закономірності та рефлексію. Вона аналізує недавній матеріал,
|
||||
визначає повторювані теми через кластеризацію тегів концепцій і записує
|
||||
нотатки вищого рівня та рефлексії в `DREAMS.md`, коли ввімкнено inline-зберігання.
|
||||
REM dreaming шукає патерни та рефлексії. Вона аналізує недавні матеріали,
|
||||
визначає повторювані теми через кластеризацію тегів понять і записує
|
||||
нотатки вищого рівня та рефлексії до `DREAMS.md`, коли ввімкнено inline-зберігання.
|
||||
|
||||
REM записує в `DREAMS.md` в inline-режимі, **а не** в `MEMORY.md`.
|
||||
Її вивід є інтерпретативним, а не канонічним. Простими словами: «яку закономірність я помічаю?»
|
||||
REM записує до `DREAMS.md` в inline-режимі, **а не** до `MEMORY.md`.
|
||||
Її результат є інтерпретативним, а не канонічним. Уявіть: «який патерн я помічаю?»
|
||||
|
||||
## Жорсткі межі
|
||||
|
||||
| Фаза | Завдання | Записує в | НЕ записує в |
|
||||
| ----- | ----------- | ------------------------ | ---------------- |
|
||||
| Light | Організація | `DREAMS.md` (inline-режим) | MEMORY.md |
|
||||
| Deep | Збереження | MEMORY.md | -- |
|
||||
| REM | Інтерпретація | `DREAMS.md` (inline-режим) | MEMORY.md |
|
||||
| Фаза | Завдання | Записує до | НЕ записує до |
|
||||
| ----- | ----------- | ------------------------ | ------------- |
|
||||
| Light | Організація | `DREAMS.md` (inline-режим) | MEMORY.md |
|
||||
| Deep | Збереження | MEMORY.md | -- |
|
||||
| REM | Інтерпретація | `DREAMS.md` (inline-режим) | MEMORY.md |
|
||||
|
||||
## Швидкий старт
|
||||
|
||||
@ -106,30 +106,30 @@ REM записує в `DREAMS.md` в inline-режимі, **а не** в `MEMORY
|
||||
|
||||
## Конфігурація
|
||||
|
||||
Усі налаштування dreaming знаходяться в `plugins.entries.memory-core.config.dreaming`
|
||||
у `openclaw.json`. Повний список ключів див. у [довіднику конфігурації Memory](/uk/reference/memory-config#dreaming-experimental).
|
||||
Усі налаштування dreaming розташовані в `plugins.entries.memory-core.config.dreaming`
|
||||
у `openclaw.json`. Повний список ключів дивіться в [довіднику з конфігурації Memory](/uk/reference/memory-config#dreaming-experimental).
|
||||
|
||||
### Глобальні налаштування
|
||||
|
||||
| Ключ | Тип | Типово | Опис |
|
||||
| ---------------- | --------- | ---------- | ------------------------------------------------------------ |
|
||||
| `enabled` | `boolean` | `true` | Головний перемикач для всіх фаз |
|
||||
| `timezone` | `string` | не задано | Часовий пояс для оцінювання розкладу та групування дат dreaming |
|
||||
| `verboseLogging` | `boolean` | `false` | Виводити детальні логи dreaming для кожного запуску |
|
||||
| `timezone` | `string` | не задано | Часовий пояс для оцінки розкладу та групування дат dreaming |
|
||||
| `verboseLogging` | `boolean` | `false` | Виводити докладні журнали dreaming для кожного запуску |
|
||||
| `storage.mode` | `string` | `"inline"` | Inline `DREAMS.md`, окремі звіти або обидва варіанти |
|
||||
|
||||
### Конфігурація фази light
|
||||
### Конфігурація фази Light
|
||||
|
||||
| Ключ | Тип | Типово | Опис |
|
||||
| ------------------ | ---------- | ------------------------------- | ----------------------------------- |
|
||||
| `enabled` | `boolean` | `true` | Увімкнути фазу light |
|
||||
| `cron` | `string` | `0 */6 * * *` | Розклад (типово: кожні 6 годин) |
|
||||
| `lookbackDays` | `number` | `2` | Скільки днів слідів сканувати |
|
||||
| Ключ | Тип | Типово | Опис |
|
||||
| ------------------ | ---------- | ------------------------------- | --------------------------------- |
|
||||
| `enabled` | `boolean` | `true` | Увімкнути фазу light |
|
||||
| `cron` | `string` | `0 */6 * * *` | Розклад (типово: кожні 6 годин) |
|
||||
| `lookbackDays` | `number` | `2` | Скільки днів слідів сканувати |
|
||||
| `limit` | `number` | `100` | Макс. кількість кандидатів для підготовки за запуск |
|
||||
| `dedupeSimilarity` | `number` | `0.9` | Поріг Жаккара для дедуплікації |
|
||||
| `sources` | `string[]` | `["daily","sessions","recall"]` | Джерела даних для сканування |
|
||||
| `dedupeSimilarity` | `number` | `0.9` | Поріг Жаккара для дедуплікації |
|
||||
| `sources` | `string[]` | `["daily","sessions","recall"]` | Джерела даних для сканування |
|
||||
|
||||
### Конфігурація фази deep
|
||||
### Конфігурація фази Deep
|
||||
|
||||
| Ключ | Тип | Типово | Опис |
|
||||
| --------------------- | ---------- | ----------------------------------------------- | ------------------------------------ |
|
||||
@ -138,23 +138,23 @@ REM записує в `DREAMS.md` в inline-режимі, **а не** в `MEMORY
|
||||
| `limit` | `number` | `10` | Макс. кількість кандидатів для просування за цикл |
|
||||
| `minScore` | `number` | `0.8` | Мінімальний зважений бал для просування |
|
||||
| `minRecallCount` | `number` | `3` | Мінімальний поріг кількості згадувань |
|
||||
| `minUniqueQueries` | `number` | `3` | Мінімальна кількість різних запитів |
|
||||
| `minUniqueQueries` | `number` | `3` | Мінімальна кількість унікальних запитів |
|
||||
| `recencyHalfLifeDays` | `number` | `14` | Кількість днів, за яку бал давності зменшується вдвічі |
|
||||
| `maxAgeDays` | `number` | `30` | Максимальний вік щоденної нотатки для просування |
|
||||
| `sources` | `string[]` | `["daily","memory","sessions","logs","recall"]` | Джерела даних |
|
||||
|
||||
### Конфігурація відновлення deep
|
||||
### Конфігурація відновлення Deep
|
||||
|
||||
Відновлення запускається, коли здоров’я довготривалої пам’яті падає нижче порога.
|
||||
Відновлення запускається, коли рівень здоров’я довготривалої пам’яті падає нижче порога.
|
||||
|
||||
| Ключ | Тип | Типово | Опис |
|
||||
| --------------------------------- | --------- | ------- | ---------------------------------------- |
|
||||
| `recovery.enabled` | `boolean` | `true` | Увімкнути автоматичне відновлення |
|
||||
| `recovery.triggerBelowHealth` | `number` | `0.35` | Поріг бала здоров’я для запуску відновлення |
|
||||
| `recovery.lookbackDays` | `number` | `30` | Наскільки далеко назад шукати матеріал для відновлення |
|
||||
| Ключ | Тип | Типово | Опис |
|
||||
| --------------------------------- | --------- | ------- | ------------------------------------------ |
|
||||
| `recovery.enabled` | `boolean` | `true` | Увімкнути автоматичне відновлення |
|
||||
| `recovery.triggerBelowHealth` | `number` | `0.35` | Поріг оцінки здоров’я для запуску відновлення |
|
||||
| `recovery.lookbackDays` | `number` | `30` | Як далеко назад шукати матеріал для відновлення |
|
||||
| `recovery.maxRecoveredCandidates` | `number` | `20` | Макс. кількість кандидатів для відновлення за запуск |
|
||||
| `recovery.minRecoveryConfidence` | `number` | `0.9` | Мінімальна впевненість для кандидатів на відновлення |
|
||||
| `recovery.autoWriteMinConfidence` | `number` | `0.97` | Поріг автозапису (без ручної перевірки) |
|
||||
| `recovery.autoWriteMinConfidence` | `number` | `0.97` | Поріг автозапису (без ручної перевірки) |
|
||||
|
||||
### Конфігурація фази REM
|
||||
|
||||
@ -162,9 +162,9 @@ REM записує в `DREAMS.md` в inline-режимі, **а не** в `MEMORY
|
||||
| -------------------- | ---------- | --------------------------- | --------------------------------------- |
|
||||
| `enabled` | `boolean` | `true` | Увімкнути фазу REM |
|
||||
| `cron` | `string` | `0 5 * * 0` | Розклад (типово: щотижня, неділя 5:00) |
|
||||
| `lookbackDays` | `number` | `7` | Скільки днів матеріалу аналізувати |
|
||||
| `limit` | `number` | `10` | Макс. кількість закономірностей або тем для запису |
|
||||
| `minPatternStrength` | `number` | `0.75` | Мінімальна сила співзустрічальності тегів |
|
||||
| `lookbackDays` | `number` | `7` | Скільки днів матеріалів аналізувати |
|
||||
| `limit` | `number` | `10` | Макс. кількість патернів або тем для запису |
|
||||
| `minPatternStrength` | `number` | `0.75` | Мінімальна сила спільної появи тегів |
|
||||
| `sources` | `string[]` | `["memory","daily","deep"]` | Джерела даних для рефлексії |
|
||||
|
||||
### Перевизначення виконання
|
||||
@ -177,86 +177,100 @@ REM записує в `DREAMS.md` в inline-режимі, **а не** в `MEMORY
|
||||
| `thinking` | `string` | `"medium"` | `low`, `medium` або `high` |
|
||||
| `budget` | `string` | `"medium"` | `cheap`, `medium`, `expensive` |
|
||||
| `model` | `string` | не задано | Перевизначити модель для цієї фази |
|
||||
| `maxOutputTokens` | `number` | не задано | Обмежити вихідні токени |
|
||||
| `maxOutputTokens` | `number` | не задано | Обмежити кількість вихідних токенів |
|
||||
| `temperature` | `number` | не задано | Температура семплювання (0-2) |
|
||||
| `timeoutMs` | `number` | не задано | Тайм-аут фази в мілісекундах |
|
||||
|
||||
## Сигнали просування (фаза deep)
|
||||
|
||||
Фаза deep dreaming поєднує шість зважених сигналів. Просування вимагає, щоб усі налаштовані
|
||||
порогові перевірки проходили одночасно.
|
||||
Deep dreaming поєднує шість зважених сигналів. Для просування потрібно, щоб усі налаштовані
|
||||
порогові перевірки пройшли одночасно.
|
||||
|
||||
| Сигнал | Вага | Опис |
|
||||
| -------------------- | ---- | -------------------------------------------------- |
|
||||
| Частота | 0.24 | Наскільки часто згадувався той самий запис |
|
||||
| Релевантність | 0.30 | Середні бали згадування під час отримання |
|
||||
| Сигнал | Вага | Опис |
|
||||
| ------------------- | ---- | -------------------------------------------------- |
|
||||
| Частота | 0.24 | Як часто той самий запис згадувався |
|
||||
| Релевантність | 0.30 | Середні бали згадування під час витягування |
|
||||
| Різноманітність запитів | 0.15 | Кількість різних намірів запитів, у яких він з’являвся |
|
||||
| Давність | 0.15 | Часове спадання (`recencyHalfLifeDays`, типово 14) |
|
||||
| Консолідація | 0.10 | Винагороджує згадування, повторені впродовж кількох днів |
|
||||
| Концептуальна насиченість | 0.06 | Винагороджує записи з багатшими похідними тегами концепцій |
|
||||
| Давність | 0.15 | Часове згасання (`recencyHalfLifeDays`, типово 14) |
|
||||
| Консолідація | 0.10 | Винагорода за згадування, повторене в кілька днів |
|
||||
| Концептуальна насиченість | 0.06 | Винагорода записам із багатшими похідними тегами понять |
|
||||
|
||||
## Команди чату
|
||||
|
||||
```
|
||||
/dreaming status # Показати конфігурацію фаз і частоту
|
||||
/dreaming status # Показати конфігурацію фаз і частоту запуску
|
||||
/dreaming on # Увімкнути всі фази
|
||||
/dreaming off # Вимкнути всі фази
|
||||
/dreaming enable light|deep|rem # Увімкнути конкретну фазу
|
||||
/dreaming disable light|deep|rem # Вимкнути конкретну фазу
|
||||
/dreaming help # Показати довідник з використання
|
||||
/dreaming help # Показати довідку з використання
|
||||
```
|
||||
|
||||
## Команди CLI
|
||||
## CLI-команди
|
||||
|
||||
Попередній перегляд і застосування deep-просувань з командного рядка:
|
||||
Переглядайте та застосовуйте deep-просування з командного рядка:
|
||||
|
||||
```bash
|
||||
# Попередній перегляд кандидатів на просування
|
||||
# Preview promotion candidates
|
||||
openclaw memory promote
|
||||
|
||||
# Застосувати просування до MEMORY.md
|
||||
# Apply promotions to MEMORY.md
|
||||
openclaw memory promote --apply
|
||||
|
||||
# Обмежити кількість у попередньому перегляді
|
||||
# Limit preview count
|
||||
openclaw memory promote --limit 5
|
||||
|
||||
# Включити вже просунуті записи
|
||||
# Include already-promoted entries
|
||||
openclaw memory promote --include-promoted
|
||||
|
||||
# Перевірити статус dreaming
|
||||
# Check dreaming status
|
||||
openclaw memory status --deep
|
||||
```
|
||||
|
||||
Повну довідку з прапорців див. у [memory CLI](/cli/memory).
|
||||
Повний довідник щодо прапорців дивіться в [memory CLI](/cli/memory).
|
||||
|
||||
### Інструменти попереднього перегляду та пояснення
|
||||
|
||||
Ще дві підкоманди допомагають переглядати поведінку просування та REM без будь-якого запису:
|
||||
|
||||
```bash
|
||||
# Explain why a candidate would or would not promote
|
||||
openclaw memory promote-explain "meeting notes"
|
||||
|
||||
# Preview REM reflections, candidate truths, and deep promotions
|
||||
openclaw memory rem-harness --json
|
||||
```
|
||||
|
||||
Повний список параметрів дивіться в [memory CLI](/cli/memory).
|
||||
|
||||
## Як це працює
|
||||
|
||||
### Конвеєр фази light
|
||||
### Конвеєр фази Light
|
||||
|
||||
1. Прочитати записи короткочасного згадування з `memory/.dreams/short-term-recall.json`.
|
||||
1. Прочитати записи короткострокового згадування з `memory/.dreams/short-term-recall.json`.
|
||||
2. Відфільтрувати записи в межах `lookbackDays` від поточного часу.
|
||||
3. Видалити дублікати за схожістю Жаккара (налаштовуваний поріг).
|
||||
4. Відсортувати за середнім балом згадування, взяти до `limit` записів.
|
||||
5. Записати підготовлених кандидатів у `DREAMS.md` у блоці `## Light Sleep`, якщо
|
||||
3. Усунути дублікати за схожістю Жаккара (налаштовуваний поріг).
|
||||
4. Відсортувати за середнім балом згадування та взяти до `limit` записів.
|
||||
5. Записати підготовлених кандидатів до `DREAMS.md` у блоці `## Light Sleep`, якщо
|
||||
ввімкнено inline-зберігання.
|
||||
|
||||
### Конвеєр фази deep
|
||||
### Конвеєр фази Deep
|
||||
|
||||
1. Прочитати та ранжувати кандидатів короткочасного згадування за допомогою зважених сигналів.
|
||||
1. Прочитати та ранжувати кандидатів короткострокового згадування за зваженими сигналами.
|
||||
2. Застосувати порогові перевірки: `minScore`, `minRecallCount`, `minUniqueQueries`.
|
||||
3. Відфільтрувати за `maxAgeDays` і застосувати спадання за давністю.
|
||||
4. Розподілити по налаштованих робочих просторах пам’яті.
|
||||
5. Повторно прочитати актуальну щоденну нотатку перед записом (пропустити застарілі або видалені фрагменти).
|
||||
6. Додати придатні записи в `MEMORY.md` з мітками часу просування.
|
||||
3. Відфільтрувати за `maxAgeDays` та застосувати згасання за давністю.
|
||||
4. Виконати fan-out по налаштованих робочих просторах пам’яті.
|
||||
5. Перед записом повторно прочитати актуальну щоденну нотатку (пропустити застарілі або видалені фрагменти).
|
||||
6. Додати відповідні записи до `MEMORY.md` з часовими мітками просування.
|
||||
7. Позначити просунуті записи, щоб виключити їх із майбутніх циклів.
|
||||
8. Якщо здоров’я нижче `recovery.triggerBelowHealth`, запустити прохід відновлення.
|
||||
8. Якщо рівень здоров’я нижчий за `recovery.triggerBelowHealth`, запустити етап відновлення.
|
||||
|
||||
### Конвеєр фази REM
|
||||
|
||||
1. Прочитати недавні сліди пам’яті в межах `lookbackDays`.
|
||||
2. Кластеризувати теги концепцій за співзустрічальністю.
|
||||
3. Відфільтрувати закономірності за `minPatternStrength`.
|
||||
4. Записати теми та рефлексії в `DREAMS.md` у блоці `## REM Sleep`,
|
||||
2. Кластеризувати теги понять за спільною появою.
|
||||
3. Відфільтрувати патерни за `minPatternStrength`.
|
||||
4. Записати теми та рефлексії до `DREAMS.md` у блоці `## REM Sleep`,
|
||||
якщо ввімкнено inline-зберігання.
|
||||
|
||||
## Планування
|
||||
@ -265,28 +279,29 @@ openclaw memory status --deep
|
||||
`memory-core` узгоджує керовані cron-завдання під час запуску gateway. Вам не потрібно
|
||||
створювати записи cron вручну.
|
||||
|
||||
| Фаза | Типовий розклад | Опис |
|
||||
| ----- | --------------- | ------------------- |
|
||||
| Light | `0 */6 * * *` | Кожні 6 годин |
|
||||
| Deep | `0 3 * * *` | Щодня о 3:00 |
|
||||
| REM | `0 5 * * 0` | Щотижня, неділя 5:00 |
|
||||
| Фаза | Типовий розклад | Опис |
|
||||
| ----- | --------------- | --------------------- |
|
||||
| Light | `0 */6 * * *` | Кожні 6 годин |
|
||||
| Deep | `0 3 * * *` | Щодня о 3:00 |
|
||||
| REM | `0 5 * * 0` | Щотижня, неділя 5:00 |
|
||||
|
||||
Будь-який розклад можна перевизначити ключем `cron` фази. Усі розклади враховують глобальне
|
||||
Перевизначте будь-який розклад за допомогою ключа `cron` відповідної фази. Усі розклади враховують глобальне
|
||||
налаштування `timezone`.
|
||||
|
||||
## Інтерфейс Dreams
|
||||
|
||||
Коли dreaming увімкнено, на бічній панелі Gateway з’являється вкладка **Dreams** з
|
||||
показниками пам’яті (кількість короткочасних, довготривалих і просунутих записів) та часом
|
||||
Коли dreaming увімкнено, бічна панель Gateway показує вкладку **Dreams** зі
|
||||
статистикою пам’яті (кількість короткострокових записів, кількість довготривалих записів, кількість просунутих записів) і часом
|
||||
наступного запланованого циклу. Щоденні лічильники враховують `dreaming.timezone`, якщо його задано,
|
||||
інакше використовують налаштований часовий пояс користувача.
|
||||
і в іншому разі використовують налаштований часовий пояс користувача.
|
||||
|
||||
Ручні запуски `openclaw memory promote` типово використовують ті самі пороги фази deep,
|
||||
тому заплановане просування і просування на вимогу залишаються узгодженими, якщо ви не передасте перевизначення CLI.
|
||||
тому заплановане й виконуване на вимогу просування залишаються узгодженими, якщо ви не передаєте
|
||||
перевизначення CLI.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Memory](/uk/concepts/memory)
|
||||
- [Memory Search](/uk/concepts/memory-search)
|
||||
- [довідник конфігурації Memory](/uk/reference/memory-config)
|
||||
- [довідник з конфігурації Memory](/uk/reference/memory-config)
|
||||
- [memory CLI](/cli/memory)
|
||||
|
||||
@ -1,54 +1,54 @@
|
||||
---
|
||||
read_when:
|
||||
- Вам потрібні детерміновані багатокрокові workflows з явними погодженнями
|
||||
- Вам потрібно відновити workflow без повторного виконання попередніх кроків
|
||||
summary: Типізоване workflow runtime для OpenClaw із відновлюваними етапами погодження.
|
||||
- Вам потрібні детерміновані багатокрокові робочі процеси з явними затвердженнями
|
||||
- Вам потрібно відновити робочий процес без повторного виконання попередніх кроків
|
||||
summary: Типізоване середовище виконання робочих процесів для OpenClaw із відновлюваними етапами затвердження.
|
||||
title: Lobster
|
||||
x-i18n:
|
||||
generated_at: "2026-04-05T18:20:35Z"
|
||||
generated_at: "2026-04-05T23:42:21Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 82718c15d571406ad6f1507de22a528fdab873edfc6aafae10742e500f6a5eda
|
||||
source_hash: c1014945d104ef8fdca0d30be89e35136def1b274c6403b06de29e8502b8124b
|
||||
source_path: tools/lobster.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Lobster
|
||||
|
||||
Lobster — це workflow-оболонка, яка дозволяє OpenClaw виконувати багатокрокові послідовності інструментів як одну детерміновану операцію з явними контрольними точками погодження.
|
||||
Lobster — це оболонка робочих процесів, яка дає OpenClaw змогу виконувати багатокрокові послідовності інструментів як єдину детерміновану операцію з явними контрольними точками затвердження.
|
||||
|
||||
Lobster — це шар створення сценаріїв на один рівень вище за відокремлену фонову роботу. Для оркестрації потоків над окремими завданнями див. [Task Flow](/uk/automation/taskflow) (`openclaw tasks flow`). Для журналу активності завдань див. [`openclaw tasks`](/uk/automation/tasks).
|
||||
Lobster — це рівень створення сценаріїв, розташований над відокремленою фоновою роботою. Для оркестрації потоків вище за окремі завдання див. [Task Flow](/uk/automation/taskflow) (`openclaw tasks flow`). Для журналу активності завдань див. [`openclaw tasks`](/uk/automation/tasks).
|
||||
|
||||
## Хук
|
||||
## Hook
|
||||
|
||||
Ваш помічник може створювати інструменти, які керують ним самим. Попросіть workflow — і через 30 хвилин у вас буде CLI плюс конвеєри, які виконуються як один виклик. Lobster — це відсутній елемент: детерміновані конвеєри, явні погодження та відновлюваний стан.
|
||||
Ваш асистент може створювати інструменти, які керують ним самим. Попросіть робочий процес — і за 30 хвилин у вас буде CLI плюс конвеєри, які виконуються одним викликом. Lobster — це відсутній елемент: детерміновані конвеєри, явні затвердження та відновлюваний стан.
|
||||
|
||||
## Навіщо
|
||||
|
||||
Сьогодні складні workflows потребують багатьох викликів інструментів із поверненням назад і вперед. Кожен виклик коштує токенів, і LLM має оркеструвати кожен крок. Lobster переносить цю оркестрацію в типізоване runtime:
|
||||
Сьогодні складні робочі процеси вимагають багатьох викликів інструментів із постійною взаємодією туди-сюди. Кожен виклик коштує токенів, і LLM має оркеструвати кожен крок. Lobster переносить цю оркестрацію в типізоване середовище виконання:
|
||||
|
||||
- **Один виклик замість багатьох**: OpenClaw виконує один виклик інструмента Lobster і отримує структурований результат.
|
||||
- **Погодження вбудовано**: побічні ефекти (надсилання email, публікація коментаря) зупиняють workflow, доки їх явно не погодять.
|
||||
- **Можна відновити**: зупинені workflows повертають токен; погодьте й відновіть без повторного виконання всього.
|
||||
- **Затвердження вбудовані**: Побічні ефекти (надіслати email, опублікувати коментар) зупиняють робочий процес до явного затвердження.
|
||||
- **Відновлюваність**: Зупинені робочі процеси повертають токен; затвердіть і відновіть без повторного запуску всього.
|
||||
|
||||
## Чому DSL, а не звичайні програми?
|
||||
|
||||
Lobster навмисно невеликий. Мета не в тому, щоб створити «нову мову», а в тому, щоб мати передбачувану, дружню до AI специфікацію конвеєрів із погодженнями першого класу та токенами відновлення.
|
||||
Lobster навмисно зроблено невеликим. Мета не в тому, щоб створити «нову мову», а в тому, щоб мати передбачувану, дружню до AI специфікацію конвеєра з підтримкою затверджень і токенів відновлення як першокласних можливостей.
|
||||
|
||||
- **Погодження/відновлення вбудовані**: звичайна програма може запитати людину, але не може _призупинитися та відновитися_ з довговічним токеном, якщо ви самі не реалізуєте таке runtime.
|
||||
- **Детермінованість + аудитованість**: конвеєри — це дані, тому їх легко журналювати, порівнювати, повторювати та перевіряти.
|
||||
- **Обмежена поверхня для AI**: невелика граматика + JSON-конвеєри зменшують «креативні» шляхи коду й роблять валідацію реалістичною.
|
||||
- **Політика безпеки вбудована**: тайм-аути, обмеження виводу, перевірки sandbox і allowlists застосовуються runtime, а не кожним скриптом.
|
||||
- **Усе ще програмоване**: кожен крок може викликати будь-який CLI або скрипт. Якщо вам потрібен JS/TS, генеруйте файли `.lobster` з коду.
|
||||
- **Затвердити/відновити вбудовано**: Звичайна програма може запитати людину, але не може _призупинитися й відновитися_ з надійним токеном без того, щоб ви самі винайшли таке середовище виконання.
|
||||
- **Детермінованість + аудитованість**: Конвеєри — це дані, тому їх легко журналювати, порівнювати, відтворювати й перевіряти.
|
||||
- **Обмежена поверхня для AI**: Невелика граматика + JSON-передавання зменшують «творчі» шляхи виконання коду та роблять перевірку реалістичною.
|
||||
- **Політика безпеки вбудована**: Тайм-аути, обмеження виводу, перевірки sandbox і allowlist примусово забезпечуються середовищем виконання, а не кожним скриптом.
|
||||
- **Усе ще програмований**: Кожен крок може викликати будь-який CLI або скрипт. Якщо вам потрібен JS/TS, генеруйте файли `.lobster` з коду.
|
||||
|
||||
## Як це працює
|
||||
|
||||
OpenClaw запускає локальний CLI `lobster` у **режимі інструмента** і розбирає JSON-обгортку зі stdout.
|
||||
Якщо конвеєр призупиняється для погодження, інструмент повертає `resumeToken`, щоб ви могли продовжити пізніше.
|
||||
OpenClaw виконує робочі процеси Lobster **у процесі** за допомогою вбудованого раннера. Жоден зовнішній підпроцес CLI не запускається; рушій робочих процесів виконується всередині процесу gateway і напряму повертає JSON-конверт.
|
||||
Якщо конвеєр призупиняється для затвердження, інструмент повертає `resumeToken`, щоб ви могли продовжити пізніше.
|
||||
|
||||
## Шаблон: малий CLI + JSON-конвеєри + погодження
|
||||
## Шаблон: невеликий CLI + JSON-канали + затвердження
|
||||
|
||||
Створюйте маленькі команди, які працюють із JSON, а потім об’єднуйте їх в один виклик Lobster. (Нижче наведено приклади назв команд — замініть їх на власні.)
|
||||
Створюйте маленькі команди, які працюють із JSON, а потім об’єднуйте їх в один виклик Lobster. (Назви команд у прикладі нижче — лише приклад, замініть на свої.)
|
||||
|
||||
```bash
|
||||
inbox list --json
|
||||
@ -64,7 +64,7 @@ inbox apply --json
|
||||
}
|
||||
```
|
||||
|
||||
Якщо конвеєр запитує погодження, відновіть його за токеном:
|
||||
Якщо конвеєр запитує затвердження, відновіть його за допомогою токена:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -74,7 +74,7 @@ inbox apply --json
|
||||
}
|
||||
```
|
||||
|
||||
AI запускає workflow; Lobster виконує кроки. Етапи погодження зберігають побічні ефекти явними та придатними до аудиту.
|
||||
AI запускає робочий процес; Lobster виконує кроки. Етапи затвердження роблять побічні ефекти явними та придатними до аудиту.
|
||||
|
||||
Приклад: відображення вхідних елементів у виклики інструментів:
|
||||
|
||||
@ -83,11 +83,11 @@ gog.gmail.search --query 'newer_than:1d' \
|
||||
| openclaw.invoke --tool message --action send --each --item-key message --args-json '{"provider":"telegram","to":"..."}'
|
||||
```
|
||||
|
||||
## Кроки LLM лише з JSON (`llm-task`)
|
||||
## LLM-кроки лише з JSON (llm-task)
|
||||
|
||||
Для workflows, яким потрібен **структурований крок LLM**, увімкніть необов’язковий
|
||||
plugin tool `llm-task` і викликайте його з Lobster. Це зберігає workflow
|
||||
детермінованим, але водночас дає змогу класифікувати/узагальнювати/створювати чернетки за допомогою моделі.
|
||||
Для робочих процесів, яким потрібен **структурований крок LLM**, увімкніть необов’язковий інструмент плагіна
|
||||
`llm-task` і викликайте його з Lobster. Це зберігає
|
||||
детермінованість робочого процесу, водночас даючи змогу класифікувати, узагальнювати або створювати чернетки за допомогою моделі.
|
||||
|
||||
Увімкніть інструмент:
|
||||
|
||||
@ -109,7 +109,7 @@ plugin tool `llm-task` і викликайте його з Lobster. Це збе
|
||||
}
|
||||
```
|
||||
|
||||
Використайте його в конвеєрі:
|
||||
Використання в конвеєрі:
|
||||
|
||||
```lobster
|
||||
openclaw.invoke --tool llm-task --action json --args-json '{
|
||||
@ -128,11 +128,11 @@ openclaw.invoke --tool llm-task --action json --args-json '{
|
||||
}'
|
||||
```
|
||||
|
||||
Докладніше та про параметри конфігурації див. у [LLM Task](/tools/llm-task).
|
||||
Див. [LLM Task](/uk/tools/llm-task) для деталей і параметрів конфігурації.
|
||||
|
||||
## Файли workflow (.lobster)
|
||||
## Файли робочих процесів (.lobster)
|
||||
|
||||
Lobster може виконувати YAML/JSON-файли workflow з полями `name`, `args`, `steps`, `env`, `condition` і `approval`. У викликах інструментів OpenClaw задайте `pipeline` як шлях до файла.
|
||||
Lobster може виконувати файли робочих процесів YAML/JSON з полями `name`, `args`, `steps`, `env`, `condition` і `approval`. У викликах інструментів OpenClaw встановіть `pipeline` на шлях до файла.
|
||||
|
||||
```yaml
|
||||
name: inbox-triage
|
||||
@ -162,11 +162,13 @@ steps:
|
||||
|
||||
## Встановлення Lobster
|
||||
|
||||
Встановіть CLI Lobster на **тому самому хості**, де працює Gateway OpenClaw (див. [репозиторій Lobster](https://github.com/openclaw/lobster)), і переконайтеся, що `lobster` є в `PATH`.
|
||||
Вбудовані робочі процеси Lobster виконуються у процесі; окремий бінарний файл `lobster` не потрібен. Вбудований раннер постачається разом із плагіном Lobster.
|
||||
|
||||
Якщо вам потрібен автономний CLI Lobster для розробки або зовнішніх конвеєрів, установіть його з [репозиторію Lobster](https://github.com/openclaw/lobster) і переконайтеся, що `lobster` є в `PATH`.
|
||||
|
||||
## Увімкнення інструмента
|
||||
|
||||
Lobster — це **необов’язковий** plugin tool (не увімкнений типово).
|
||||
Lobster — це **необов’язковий** інструмент плагіна (типово не ввімкнений).
|
||||
|
||||
Рекомендовано (адитивно, безпечно):
|
||||
|
||||
@ -195,11 +197,12 @@ Lobster — це **необов’язковий** plugin tool (не увімк
|
||||
}
|
||||
```
|
||||
|
||||
Уникайте використання `tools.allow: ["lobster"]`, якщо ви не маєте наміру працювати в обмежувальному режимі allowlist.
|
||||
Уникайте використання `tools.allow: ["lobster"]`, якщо тільки ви справді не хочете працювати в режимі обмежувального allowlist.
|
||||
|
||||
Примітка: allowlists для необов’язкових plugins є опціональними. Якщо ваш allowlist називає лише
|
||||
plugin tools (наприклад, `lobster`), OpenClaw залишає core tools увімкненими. Щоб обмежити core
|
||||
tools, також включіть до allowlist ті core tools або групи, які вам потрібні.
|
||||
Примітка: allowlist для необов’язкових плагінів — це механізм із явним увімкненням.
|
||||
Якщо ваш allowlist містить лише
|
||||
інструменти плагінів (як-от `lobster`), OpenClaw залишає core tools увімкненими. Щоб обмежити core
|
||||
tools, також укажіть у allowlist потрібні core tools або групи.
|
||||
|
||||
## Приклад: сортування email
|
||||
|
||||
@ -207,13 +210,13 @@ tools, також включіть до allowlist ті core tools або гру
|
||||
|
||||
```
|
||||
User: "Check my email and draft replies"
|
||||
→ openclaw викликає gmail.list
|
||||
→ LLM узагальнює
|
||||
→ openclaw calls gmail.list
|
||||
→ LLM summarizes
|
||||
→ User: "draft replies to #2 and #5"
|
||||
→ LLM створює чернетки
|
||||
→ LLM drafts
|
||||
→ User: "send #2"
|
||||
→ openclaw викликає gmail.send
|
||||
(повторюється щодня, без пам’яті про те, що вже було розібрано)
|
||||
→ openclaw calls gmail.send
|
||||
(repeat daily, no memory of what was triaged)
|
||||
```
|
||||
|
||||
З Lobster:
|
||||
@ -226,7 +229,7 @@ User: "Check my email and draft replies"
|
||||
}
|
||||
```
|
||||
|
||||
Повертає JSON-обгортку (скорочено):
|
||||
Повертає JSON-конверт (усічено):
|
||||
|
||||
```json
|
||||
{
|
||||
@ -242,7 +245,7 @@ User: "Check my email and draft replies"
|
||||
}
|
||||
```
|
||||
|
||||
Користувач погоджується → відновлення:
|
||||
Користувач затверджує → відновлення:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -252,7 +255,7 @@ User: "Check my email and draft replies"
|
||||
}
|
||||
```
|
||||
|
||||
Один workflow. Детермінований. Безпечний.
|
||||
Один робочий процес. Детермінований. Безпечний.
|
||||
|
||||
## Параметри інструмента
|
||||
|
||||
@ -270,7 +273,7 @@ User: "Check my email and draft replies"
|
||||
}
|
||||
```
|
||||
|
||||
Запуск файла workflow з аргументами:
|
||||
Запуск файла робочого процесу з аргументами:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -282,7 +285,7 @@ User: "Check my email and draft replies"
|
||||
|
||||
### `resume`
|
||||
|
||||
Продовжує зупинений workflow після погодження.
|
||||
Продовжує зупинений робочий процес після затвердження.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -292,64 +295,64 @@ User: "Check my email and draft replies"
|
||||
}
|
||||
```
|
||||
|
||||
### Необов’язкові вхідні параметри
|
||||
### Необов’язкові входи
|
||||
|
||||
- `cwd`: Відносний робочий каталог для конвеєра (має залишатися в межах поточного робочого каталогу процесу).
|
||||
- `timeoutMs`: Завершити підпроцес, якщо він перевищує цю тривалість (типово: 20000).
|
||||
- `maxStdoutBytes`: Завершити підпроцес, якщо stdout перевищує цей розмір (типово: 512000).
|
||||
- `argsJson`: JSON-рядок, який передається в `lobster run --args-json` (лише для файлів workflow).
|
||||
- `cwd`: Відносний робочий каталог для конвеєра (має залишатися в межах робочого каталогу gateway).
|
||||
- `timeoutMs`: Перериває робочий процес, якщо він перевищує цю тривалість (типово: 20000).
|
||||
- `maxStdoutBytes`: Перериває робочий процес, якщо вивід перевищує цей розмір (типово: 512000).
|
||||
- `argsJson`: JSON-рядок, який передається в `lobster run --args-json` (лише для файлів робочих процесів).
|
||||
|
||||
## Обгортка виводу
|
||||
## Конверт виводу
|
||||
|
||||
Lobster повертає JSON-обгортку з одним із трьох статусів:
|
||||
Lobster повертає JSON-конверт з одним із трьох статусів:
|
||||
|
||||
- `ok` → успішно завершено
|
||||
- `needs_approval` → призупинено; для відновлення потрібен `requiresApproval.resumeToken`
|
||||
- `cancelled` → явно відхилено або скасовано
|
||||
|
||||
Інструмент віддає цю обгортку і в `content` (форматований JSON), і в `details` (сирий об’єкт).
|
||||
Інструмент відображає цей конверт і в `content` (форматований JSON), і в `details` (сирий об’єкт).
|
||||
|
||||
## Погодження
|
||||
## Затвердження
|
||||
|
||||
Якщо присутній `requiresApproval`, перегляньте запит і вирішіть:
|
||||
|
||||
- `approve: true` → відновити й продовжити побічні ефекти
|
||||
- `approve: false` → скасувати й завершити workflow
|
||||
- `approve: true` → відновити та продовжити побічні ефекти
|
||||
- `approve: false` → скасувати й завершити робочий процес
|
||||
|
||||
Використовуйте `approve --preview-from-stdin --limit N`, щоб додавати JSON-попередній перегляд до запитів на погодження без власного glue-коду на jq/heredoc. Тепер токени відновлення компактні: Lobster зберігає стан відновлення workflow у своєму каталозі стану й повертає невеликий ключ токена.
|
||||
Використовуйте `approve --preview-from-stdin --limit N`, щоб додати JSON-перегляд до запитів на затвердження без власних glue-скриптів на jq/heredoc. Тепер токени відновлення компактні: Lobster зберігає стан відновлення робочого процесу у своєму каталозі стану й повертає невеликий ключ токена.
|
||||
|
||||
## OpenProse
|
||||
|
||||
OpenProse добре поєднується з Lobster: використовуйте `/prose` для оркестрації підготовки кількох агентів, а потім запускайте конвеєр Lobster для детермінованих погоджень. Якщо програмі Prose потрібен Lobster, дозвольте інструмент `lobster` для субагентів через `tools.subagents.tools`. Див. [OpenProse](/uk/prose).
|
||||
OpenProse добре поєднується з Lobster: використовуйте `/prose` для оркестрації підготовки з кількома агентами, а потім запускайте конвеєр Lobster для детермінованих затверджень. Якщо програмі Prose потрібен Lobster, дозвольте інструмент `lobster` для субагентів через `tools.subagents.tools`. Див. [OpenProse](/uk/prose).
|
||||
|
||||
## Безпека
|
||||
|
||||
- **Лише локальний підпроцес** — сам plugin не виконує мережевих викликів.
|
||||
- **Лише локальне виконання у процесі** — робочі процеси виконуються всередині процесу gateway; сам плагін не робить мережевих викликів.
|
||||
- **Без секретів** — Lobster не керує OAuth; він викликає інструменти OpenClaw, які це роблять.
|
||||
- **З урахуванням sandbox** — вимкнено, коли контекст інструмента sandboxed.
|
||||
- **Захищено** — фіксована назва виконуваного файла (`lobster`) у `PATH`; застосовуються тайм-аути та обмеження виводу.
|
||||
- **Обізнаний про sandbox** — вимикається, коли контекст інструмента працює в sandbox.
|
||||
- **Посилений захист** — тайм-аути та обмеження виводу забезпечуються вбудованим раннером.
|
||||
|
||||
## Усунення несправностей
|
||||
|
||||
- **`lobster subprocess timed out`** → збільшіть `timeoutMs` або розбийте довгий конвеєр.
|
||||
- **`lobster output exceeded maxStdoutBytes`** → збільшіть `maxStdoutBytes` або зменште розмір виводу.
|
||||
- **`lobster returned invalid JSON`** → переконайтеся, що конвеєр працює в режимі інструмента і виводить лише JSON.
|
||||
- **`lobster failed (code …)`** → запустіть той самий конвеєр у терміналі, щоб перевірити stderr.
|
||||
- **`lobster timed out`** → збільште `timeoutMs` або розбийте довгий конвеєр.
|
||||
- **`lobster output exceeded maxStdoutBytes`** → збільште `maxStdoutBytes` або зменште розмір виводу.
|
||||
- **`lobster returned invalid JSON`** → переконайтеся, що конвеєр працює в режимі інструмента й виводить лише JSON.
|
||||
- **`lobster failed`** → перевірте журнали gateway для деталей помилки вбудованого раннера.
|
||||
|
||||
## Дізнатися більше
|
||||
|
||||
- [Plugins](/tools/plugin)
|
||||
- [Створення plugin tools](/uk/plugins/building-plugins#registering-agent-tools)
|
||||
- [Plugins](/uk/tools/plugin)
|
||||
- [Створення інструментів плагінів](/uk/plugins/building-plugins#registering-agent-tools)
|
||||
|
||||
## Приклад із практики: workflows спільноти
|
||||
## Кейс: робочі процеси спільноти
|
||||
|
||||
Один публічний приклад: CLI «другий мозок» + конвеєри Lobster, які керують трьома Markdown-сховищами (особистим, партнерським, спільним). CLI виводить JSON для статистики, списків inbox і перевірок застарілих елементів; Lobster об’єднує ці команди у workflows на кшталт `weekly-review`, `inbox-triage`, `memory-consolidation` і `shared-task-sync`, кожен із етапами погодження. AI виконує оцінювальну роботу (категоризацію), коли це доступно, і повертається до детермінованих правил, коли ні.
|
||||
Один публічний приклад: CLI «другий мозок» + конвеєри Lobster, які керують трьома сховищами Markdown (особистим, партнерським і спільним). CLI виводить JSON для статистики, списків inbox і перевірок застарілого вмісту; Lobster з’єднує ці команди в робочі процеси на кшталт `weekly-review`, `inbox-triage`, `memory-consolidation` і `shared-task-sync`, кожен із етапами затвердження. AI виконує оцінювальні дії (категоризацію), коли доступний, і повертається до детермінованих правил, коли недоступний.
|
||||
|
||||
- Гілка: [https://x.com/plattenschieber/status/2014508656335770033](https://x.com/plattenschieber/status/2014508656335770033)
|
||||
- Обговорення: [https://x.com/plattenschieber/status/2014508656335770033](https://x.com/plattenschieber/status/2014508656335770033)
|
||||
- Репозиторій: [https://github.com/bloomedai/brain-cli](https://github.com/bloomedai/brain-cli)
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Автоматизація та завдання](/uk/automation) — планування workflows Lobster
|
||||
- [Огляд автоматизації](/uk/automation) — усі механізми автоматизації
|
||||
- [Огляд інструментів](/tools) — усі доступні інструменти агента
|
||||
- [Automation & Tasks](/uk/automation) — планування робочих процесів Lobster
|
||||
- [Огляд Automation](/uk/automation) — усі механізми автоматизації
|
||||
- [Огляд Tools](/uk/tools) — усі доступні інструменти агента
|
||||
|
||||
Loading…
Reference in New Issue
Block a user