From 3c74cb6f4344f734f0692b65a312da0a0f54bdaf Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Sun, 3 May 2026 22:57:26 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/plugins/memory-wiki.md | 286 +++++++++++++++++---------------- docs/uk/tools/llm-task.md | 85 +++++----- docs/uk/tools/lobster.md | 150 ++++++++--------- 3 files changed, 261 insertions(+), 260 deletions(-) diff --git a/docs/uk/plugins/memory-wiki.md b/docs/uk/plugins/memory-wiki.md index 9831faf7c..d64fb1a3e 100644 --- a/docs/uk/plugins/memory-wiki.md +++ b/docs/uk/plugins/memory-wiki.md @@ -1,15 +1,15 @@ --- read_when: - - Вам потрібні сталі знання, ширші за звичайні нотатки MEMORY.md + - Вам потрібні сталі знання за межами звичайних нотаток MEMORY.md - Ви налаштовуєте вбудований Plugin memory-wiki - Ви хочете зрозуміти wiki_search, wiki_get або режим мосту -summary: 'memory-wiki: скомпільоване сховище знань із походженням, твердженнями, панелями моніторингу та режимом моста' +summary: 'memory-wiki: скомпільоване сховище знань із походженням, твердженнями, панелями моніторингу та режимом мосту' title: Вікі пам’яті x-i18n: - generated_at: "2026-04-29T19:21:15Z" + generated_at: "2026-05-03T22:56:31Z" model: gpt-5.5 provider: openai - source_hash: 744d569f8b0c9b668ea54dc057f808544359eaae87d5557de2e6acd1b31acd89 + source_hash: b070177b7c1217e9102bc57680b4009265e3584ede7ad6dc3ba7b6393260fefe source_path: plugins/memory-wiki.md workflow: 16 --- @@ -17,65 +17,65 @@ x-i18n: `memory-wiki` — це вбудований Plugin, який перетворює довготривалу пам’ять на скомпільоване сховище знань. -Він **не** замінює Plugin Active Memory. Plugin Active Memory і далі -відповідає за пригадування, просування, індексування та Dreaming. `memory-wiki` працює поруч із ним -і компілює довготривалі знання в навігаційну вікі з детермінованими сторінками, -структурованими твердженнями, походженням, панелями моніторингу та машинозчитуваними дайджестами. +Він **не** замінює Plugin active memory. Plugin active memory і далі +відповідає за recall, promotion, indexing і dreaming. `memory-wiki` працює поруч із ним +і компілює довготривалі знання в навіговну вікі з детермінованими сторінками, +структурованими твердженнями, provenance, dashboards і machine-readable digests. -Використовуйте його, коли хочете, щоб пам’ять поводилася радше як підтримуваний шар знань, а -не як купа Markdown-файлів. +Використовуйте його, коли хочете, щоб пам’ять поводилася радше як підтримуваний шар знань, +а не як купа Markdown-файлів. ## Що він додає - Окреме вікі-сховище з детермінованим макетом сторінок - Метадані структурованих тверджень і доказів, а не лише прозу -- Походження, впевненість, суперечності та відкриті питання на рівні сторінки -- Скомпільовані дайджести для споживачів агентів/середовища виконання +- Provenance, confidence, contradictions і open questions на рівні сторінки +- Скомпільовані digests для agent/runtime-споживачів - Вікі-нативні інструменти search/get/apply/lint -- Необов’язковий режим bridge, який імпортує публічні артефакти з Plugin Active Memory -- Необов’язковий режим рендерингу, дружній до Obsidian, та інтеграція з CLI +- Необов’язковий bridge mode, який імпортує публічні artifacts з Plugin active memory +- Необов’язковий Obsidian-friendly режим рендерингу та інтеграція з CLI -## Як він поєднується з пам’яттю +## Як це поєднується з пам’яттю Уявляйте цей поділ так: -| Шар | Відповідає за | +| Шар | Відповідає за | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------ | -| Plugin Active Memory (`memory-core`, QMD, Honcho тощо) | Пригадування, семантичний пошук, просування, Dreaming, середовище виконання пам’яті | -| `memory-wiki` | Скомпільовані вікі-сторінки, синтези з багатим походженням, панелі, вікі-специфічні search/get/apply | +| Plugin active memory (`memory-core`, QMD, Honcho тощо) | Recall, semantic search, promotion, dreaming, memory runtime | +| `memory-wiki` | Скомпільовані вікі-сторінки, provenance-rich syntheses, dashboards, wiki-specific search/get/apply | -Якщо Plugin Active Memory відкриває спільні артефакти пригадування, OpenClaw може шукати -в обох шарах за один прохід за допомогою `memory_search corpus=all`. +Якщо Plugin active memory надає спільні recall artifacts, OpenClaw може шукати +в обох шарах за один прохід через `memory_search corpus=all`. -Коли потрібне вікі-специфічне ранжування, походження або прямий доступ до сторінок, використовуйте +Коли потрібні вікі-специфічне ранжування, provenance або прямий доступ до сторінок, використовуйте натомість вікі-нативні інструменти. ## Рекомендований гібридний шаблон -Надійний типовий варіант для локальних setup-first конфігурацій: +Сильний типовий варіант для local-first налаштувань: -- QMD як backend Active Memory для пригадування та широкого семантичного пошуку +- QMD як backend active memory для recall і широкого semantic search - `memory-wiki` у режимі `bridge` для довготривалих синтезованих сторінок знань -Такий поділ добре працює, бо кожен шар зберігає чіткий фокус: +Такий поділ добре працює, бо кожен шар лишається сфокусованим: -- QMD зберігає необроблені нотатки, експорти сесій і додаткові колекції доступними для пошуку -- `memory-wiki` компілює стабільні сутності, твердження, панелі та сторінки джерел +- QMD зберігає raw notes, session exports і додаткові collections доступними для пошуку +- `memory-wiki` компілює stable entities, claims, dashboards і source pages Практичне правило: -- використовуйте `memory_search`, коли потрібен один широкий прохід пригадування по пам’яті -- використовуйте `wiki_search` і `wiki_get`, коли потрібні вікі-результати з урахуванням походження +- використовуйте `memory_search`, коли потрібен один широкий recall-прохід пам’яттю +- використовуйте `wiki_search` і `wiki_get`, коли потрібні provenance-aware вікі-результати - використовуйте `memory_search corpus=all`, коли хочете, щоб спільний пошук охоплював обидва шари -Якщо режим bridge повідомляє про нуль експортованих артефактів, Plugin Active Memory -поки що не відкриває публічні вхідні дані bridge. Спершу запустіть `openclaw wiki doctor`, -а потім підтвердьте, що Plugin Active Memory підтримує публічні артефакти. +Якщо bridge mode повідомляє про нуль експортованих artifacts, Plugin active memory наразі +ще не надає публічні bridge inputs. Спершу запустіть `openclaw wiki doctor`, +а потім підтвердьте, що Plugin active memory підтримує публічні artifacts. -Коли режим bridge активний і `bridge.readMemoryArtifacts` увімкнено, +Коли bridge mode активний і `bridge.readMemoryArtifacts` увімкнено, `openclaw wiki status`, `openclaw wiki doctor` і `openclaw wiki bridge -import` читають через запущений Gateway. Це узгоджує CLI-перевірки bridge -з контекстом Plugin пам’яті в середовищі виконання. Якщо bridge вимкнено або читання артефактів +import` читають через запущений Gateway. Це тримає CLI bridge checks узгодженими +з runtime-контекстом Plugin memory. Якщо bridge вимкнено або читання artifacts вимкнене, ці команди зберігають свою локальну/offline поведінку. ## Режими сховища @@ -86,31 +86,31 @@ import` читають через запущений Gateway. Це узгодж Власне сховище, власні джерела, без залежності від `memory-core`. -Використовуйте це, коли хочете, щоб вікі була окремим кураторованим сховищем знань. +Використовуйте це, коли хочете, щоб вікі була власним куруваним сховищем знань. ### `bridge` -Читає публічні артефакти пам’яті та події пам’яті з Plugin Active Memory -через публічні шви plugin SDK. +Читає публічні memory artifacts і memory events з Plugin active memory +через публічні plugin SDK seams. Використовуйте це, коли хочете, щоб вікі компілювала й упорядковувала -експортовані артефакти Plugin пам’яті, не звертаючись до приватних внутрішніх частин Plugin. +експортовані artifacts Plugin memory без доступу до приватних внутрішніх частин Plugin. -Режим bridge може індексувати: +Bridge mode може індексувати: -- експортовані артефакти пам’яті -- звіти dream -- щоденні нотатки -- кореневі файли пам’яті -- журнали подій пам’яті +- експортовані memory artifacts +- dream reports +- daily notes +- memory root files +- memory event logs ### `unsafe-local` -Явний escape hatch для приватних локальних шляхів на тій самій машині. +Явний escape hatch для локальних приватних шляхів на тій самій машині. Цей режим навмисно експериментальний і непортативний. Використовуйте його лише тоді, коли -розумієте межу довіри та конкретно потребуєте доступу до локальної файлової системи, якого -режим bridge надати не може. +розумієте trust boundary і конкретно потребуєте доступу до локальної файлової системи, якого +bridge mode не може надати. ## Макет сховища @@ -132,17 +132,17 @@ Plugin ініціалізує сховище так: .openclaw-wiki/ ``` -Керований вміст залишається всередині згенерованих блоків. Блоки людських нотаток зберігаються. +Керований вміст лишається всередині generated blocks. Human note blocks зберігаються. Основні групи сторінок: -- `sources/` для імпортованих необроблених матеріалів і сторінок, підтриманих bridge +- `sources/` для імпортованого raw material і bridge-backed pages - `entities/` для довготривалих речей, людей, систем, проєктів і об’єктів - `concepts/` для ідей, абстракцій, шаблонів і політик -- `syntheses/` для скомпільованих підсумків і підтримуваних зведень -- `reports/` для згенерованих панелей +- `syntheses/` для скомпільованих підсумків і підтримуваних rollups +- `reports/` для згенерованих dashboards -## Структуровані твердження та докази +## Структуровані твердження й докази Сторінки можуть містити структурований frontmatter `claims`, а не лише довільний текст. @@ -167,31 +167,31 @@ Plugin ініціалізує сховище так: - `note` - `updatedAt` -Саме це робить вікі радше шаром переконань, ніж пасивним -dump нотаток. Твердження можна відстежувати, оцінювати, оскаржувати та пов’язувати назад із джерелами. +Саме це змушує вікі поводитися радше як belief layer, ніж як пасивний +dump нотаток. Claims можна відстежувати, оцінювати, оскаржувати та розв’язувати назад до джерел. ## Метадані сутностей для агентів -Сторінки сутностей також можуть містити маршрутні метадані для використання агентами. Це generic +Сторінки сутностей також можуть містити routing metadata для використання агентами. Це generic frontmatter, тому він працює для людей, команд, систем, проєктів або будь-якого іншого типу сутності. Поширені поля: - `entityType`: наприклад `person`, `team`, `system` або `project` -- `canonicalId`: стабільний ключ ідентичності, що використовується між aliases та імпортами -- `aliases`: імена, handles або labels, які мають резолвитися в ту саму сторінку +- `canonicalId`: стабільний identity key, що використовується між aliases та imports +- `aliases`: імена, handles або labels, які мають розв’язуватися в ту саму сторінку - `privacyTier`: `public`, `local-private`, `sensitive` або `confirm-before-use` -- `bestUsedFor` / `notEnoughFor`: компактні підказки маршрутизації -- `lastRefreshedAt`: позначка часу оновлення джерела, окрема від часу редагування сторінки -- `personCard`: необов’язкова маршрутна картка, специфічна для людини, з handles, socials, +- `bestUsedFor` / `notEnoughFor`: стислі routing hints +- `lastRefreshedAt`: timestamp оновлення джерела, окремий від часу редагування сторінки +- `personCard`: необов’язкова routing card для людей із handles, socials, emails, timezone, lane, ask-for, avoid-asking-for, confidence і privacy -- `relationships`: типізовані ребра до пов’язаних сторінок із target, kind, weight, +- `relationships`: typed edges до пов’язаних сторінок із target, kind, weight, confidence, evidence kind, privacy tier і note -Для вікі людей агент зазвичай має починати з -`reports/person-agent-directory.md`, потім відкривати сторінку людини через `wiki_get`, -перш ніж використовувати контактні дані або виведені факти. +Для people wiki агент зазвичай має починати з +`reports/person-agent-directory.md`, потім відкривати сторінку людини через `wiki_get` +перед використанням контактних даних або виведених фактів. Приклад: @@ -241,29 +241,30 @@ claims: privacyTier: local-private ``` -## Конвеєр компіляції +## Compile pipeline -Крок компіляції читає вікі-сторінки, нормалізує підсумки та видає стабільні -машинні артефакти в: +Compile-крок читає вікі-сторінки, нормалізує summaries і створює стабільні +machine-facing artifacts у: - `.openclaw-wiki/cache/agent-digest.json` - `.openclaw-wiki/cache/claims.jsonl` -Ці дайджести існують, щоб агентам і runtime-коду не потрібно було scrape Markdown-сторінки. +Ці digests існують, щоб agents і runtime code не мусили scrape Markdown +сторінки. -Скомпільований вивід також забезпечує: +Скомпільований output також живить: -- первинне вікі-індексування для потоків search/get -- lookup claim-id назад до сторінок-власників -- компактні доповнення до prompt -- генерацію звітів/панелей +- first-pass wiki indexing для search/get flows +- claim-id lookup назад до owning pages +- compact prompt supplements +- генерування reports/dashboards -## Панелі та звіти про стан +## Dashboards і звіти про стан -Коли `render.createDashboards` увімкнено, compile підтримує панелі в +Коли `render.createDashboards` увімкнено, compile підтримує dashboards у `reports/`. -Вбудовані звіти містять: +Вбудовані reports містять: - `reports/open-questions.md` - `reports/contradictions.md` @@ -275,25 +276,25 @@ claims: - `reports/provenance-coverage.md` - `reports/privacy-review.md` -Ці звіти відстежують такі речі, як: +Ці reports відстежують такі речі, як: -- кластери нотаток про суперечності -- конкуруючі кластери тверджень -- твердження без структурованих доказів -- сторінки й твердження з низькою впевненістю -- застарілу або невідому актуальність -- сторінки з нерозв’язаними питаннями -- маршрутні картки людей/сутностей -- структуровані ребра взаємозв’язків -- покриття класів доказів -- непублічні privacy tiers, які потребують перевірки перед використанням +- contradiction note clusters +- competing claim clusters +- claims без структурованих доказів +- сторінки й claims із низькою confidence +- stale або unknown freshness +- сторінки з unresolved questions +- person/entity routing cards +- structured relationship edges +- evidence class coverage +- non-public privacy tiers, які потребують review перед використанням ## Пошук і отримання -`memory-wiki` підтримує два backend пошуку: +`memory-wiki` підтримує два search backends: -- `shared`: використовувати спільний потік пошуку пам’яті, коли доступно -- `local`: шукати у вікі локально +- `shared`: використовувати shared memory search flow, коли доступно +- `local`: шукати вікі локально Він також підтримує три corpora: @@ -303,36 +304,36 @@ claims: Важлива поведінка: -- `wiki_search` і `wiki_get` за можливості використовують скомпільовані дайджести як перший прохід -- claim ids можуть резолвитися назад до сторінки-власника -- contested/stale/fresh claims впливають на ранжування -- labels походження можуть зберігатися в результатах -- режим пошуку може зміщувати ранжування для пошуку людей, маршрутизації питань, source +- `wiki_search` і `wiki_get` використовують compiled digests як перший прохід, коли можливо +- claim ids можуть розв’язуватися назад до owning page +- contested/stale/fresh claims впливають на ranking +- provenance labels можуть зберігатися в results +- search mode може зміщувати ranking для person lookup, question routing, source evidence або raw claims Практичне правило: -- використовуйте `memory_search corpus=all` для одного широкого проходу пригадування -- використовуйте `wiki_search` + `wiki_get`, коли вам важливі вікі-специфічне ранжування, - походження або структура переконань на рівні сторінки +- використовуйте `memory_search corpus=all` для одного широкого recall-проходу +- використовуйте `wiki_search` + `wiki_get`, коли важливі wiki-specific ranking, + provenance або page-level belief structure -Режими пошуку: +Search modes: -- `auto`: збалансоване типове значення +- `auto`: збалансований типовий режим - `find-person`: підсилює person-like entities, aliases, handles, socials і canonical IDs -- `route-question`: підсилює картки агентів, ask-for hints, best-used-for hints і - контекст взаємозв’язків -- `source-evidence`: підсилює сторінки джерел і метадані структурованих доказів -- `raw-claim`: підсилює відповідні структуровані твердження та повертає claim/evidence - metadata в результатах +- `route-question`: підсилює agent cards, ask-for hints, best-used-for hints і + relationship context +- `source-evidence`: підсилює source pages і structured evidence metadata +- `raw-claim`: підсилює matching structured claims і повертає claim/evidence + metadata в results -Коли результат відповідає структурованому твердженню, `wiki_search` може повертати +Коли result відповідає structured claim, `wiki_search` може повернути `matchedClaimId`, `matchedClaimStatus`, `matchedClaimConfidence`, -`evidenceKinds` і `evidenceSourceIds` у своєму details payload. Текстовий вивід -також містить компактні рядки `Claim:` і `Evidence:`, коли доступно. +`evidenceKinds` і `evidenceSourceIds` у своєму details payload. Text output +також містить компактні рядки `Claim:` і `Evidence:`, коли вони доступні. -## Інструменти для агентів +## Інструменти агента Plugin реєструє ці інструменти: @@ -344,33 +345,33 @@ Plugin реєструє ці інструменти: Що вони роблять: -- `wiki_status`: поточний режим сховища, стан, доступність Obsidian CLI -- `wiki_search`: шукає вікі-сторінки та, коли налаштовано, спільні corpora пам’яті; - приймає `mode` для пошуку людей, маршрутизації питань, source evidence або raw +- `wiki_status`: поточний vault mode, health, доступність Obsidian CLI +- `wiki_search`: шукає wiki pages і, коли налаштовано, shared memory corpora; + приймає `mode` для person lookup, question routing, source evidence або raw claim drilldown -- `wiki_get`: читає вікі-сторінку за id/path або повертається до спільного corpus пам’яті -- `wiki_apply`: вузькі мутації синтезу/метаданих без довільної хірургії сторінок -- `wiki_lint`: структурні перевірки, прогалини походження, суперечності, відкриті питання +- `wiki_get`: читає wiki page за id/path або fallback до shared memory corpus +- `wiki_apply`: вузькі synthesis/metadata mutations без freeform page surgery +- `wiki_lint`: structural checks, provenance gaps, contradictions, open questions -Plugin також реєструє неексклюзивне доповнення corpus пам’яті, щоб спільні -`memory_search` і `memory_get` могли досягати вікі, коли Plugin Active Memory -підтримує вибір corpus. +Plugin також реєструє non-exclusive memory corpus supplement, тому shared +`memory_search` і `memory_get` можуть діставатися до вікі, коли Plugin active memory +підтримує corpus selection. -## Поведінка prompt і контексту +## Поведінка prompt і context -Коли `context.includeCompiledDigestPrompt` увімкнено, розділи prompt пам’яті -додають компактний скомпільований snapshot з `agent-digest.json`. +Коли `context.includeCompiledDigestPrompt` увімкнено, memory prompt sections +додають compact compiled snapshot з `agent-digest.json`. -Цей snapshot навмисно малий і високосигнальний: +Цей snapshot навмисно малий і high-signal: - лише top pages - лише top claims -- кількість суперечностей -- кількість питань -- qualifiers впевненості/актуальності +- contradiction count +- question count +- confidence/freshness qualifiers -Це opt-in, бо змінює форму prompt і переважно корисне для context -engines або legacy prompt assembly, які явно споживають доповнення пам’яті. +Це opt-in, бо змінює prompt shape і переважно корисне для context +engines або legacy prompt assembly, які явно споживають memory supplements. ## Конфігурація @@ -430,23 +431,26 @@ engines або legacy prompt assembly, які явно споживають до - `vaultMode`: `isolated`, `bridge`, `unsafe-local` - `vault.renderMode`: `native` або `obsidian` -- `bridge.readMemoryArtifacts`: імпортувати публічні артефакти Plugin активної пам’яті +- `bridge.readMemoryArtifacts`: імпортувати публічні артефакти plugin Active Memory - `bridge.followMemoryEvents`: включати журнали подій у режимі bridge - `search.backend`: `shared` або `local` - `search.corpus`: `wiki`, `memory` або `all` -- `context.includeCompiledDigestPrompt`: додавати компактний знімок дайджесту до розділів підказки пам’яті +- `context.includeCompiledDigestPrompt`: додавати компактний знімок дайджесту до розділів memory prompt - `render.createBacklinks`: генерувати детерміновані пов’язані блоки -- `render.createDashboards`: генерувати сторінки панелей огляду +- `render.createDashboards`: генерувати сторінки панелей керування ### Приклад: QMD + режим bridge -Використовуйте це, коли вам потрібен QMD для пригадування та `memory-wiki` для підтримуваного +Використовуйте це, коли вам потрібен QMD для пригадування і `memory-wiki` для підтримуваного шару знань: ```json5 { memory: { backend: "qmd", + }, + plugins: { + entries: { "memory-wiki": { enabled: true, config: { @@ -475,9 +479,9 @@ engines або legacy prompt assembly, які явно споживають до Це зберігає: -- QMD відповідальним за пригадування активної пам’яті -- `memory-wiki` зосередженим на скомпільованих сторінках і панелях огляду -- форму підказки незмінною, доки ви навмисно не ввімкнете підказки скомпільованого дайджесту +- QMD керує пригадуванням Active Memory +- `memory-wiki` зосереджений на скомпільованих сторінках і панелях керування +- форма prompt лишається незмінною, доки ви навмисно не ввімкнете prompt скомпільованого дайджесту ## CLI @@ -497,11 +501,11 @@ openclaw wiki bridge import openclaw wiki obsidian status ``` -Див. [CLI: wiki](/uk/cli/wiki), щоб отримати повний довідник команд. +Див. [CLI: wiki](/uk/cli/wiki) для повного довідника команд. ## Підтримка Obsidian -Коли `vault.renderMode` дорівнює `obsidian`, Plugin записує дружній до Obsidian +Коли `vault.renderMode` має значення `obsidian`, plugin записує зручний для Obsidian Markdown і може додатково використовувати офіційний CLI `obsidian`. Підтримувані робочі процеси включають: @@ -512,21 +516,21 @@ Markdown і може додатково використовувати офіц - виклик команди Obsidian - перехід до щоденної нотатки -Це необов’язково. Вікі й далі працює в режимі native без Obsidian. +Це необов’язково. Wiki і надалі працює в native-режимі без Obsidian. ## Рекомендований робочий процес -1. Залиште ваш Plugin активної пам’яті для пригадування/просування/Dreaming. +1. Залиште свій plugin Active Memory для пригадування/просування/Dreaming. 2. Увімкніть `memory-wiki`. 3. Почніть із режиму `isolated`, якщо вам явно не потрібен режим bridge. 4. Використовуйте `wiki_search` / `wiki_get`, коли важливе походження. 5. Використовуйте `wiki_apply` для вузьких синтезів або оновлень метаданих. 6. Запускайте `wiki_lint` після суттєвих змін. -7. Увімкніть панелі огляду, якщо вам потрібна видимість застарілого або суперечностей. +7. Увімкніть панелі керування, якщо хочете бачити застарілість/суперечності. -## Пов’язана документація +## Пов’язані документи -- [Огляд пам’яті](/uk/concepts/memory) +- [Огляд Memory](/uk/concepts/memory) - [CLI: memory](/uk/cli/memory) - [CLI: wiki](/uk/cli/wiki) - [Огляд Plugin SDK](/uk/plugins/sdk-overview) diff --git a/docs/uk/tools/llm-task.md b/docs/uk/tools/llm-task.md index d0dd6c040..78f3a41d3 100644 --- a/docs/uk/tools/llm-task.md +++ b/docs/uk/tools/llm-task.md @@ -1,27 +1,27 @@ --- read_when: - - Ви хочете JSON-only крок LLM всередині workflows - - Вам потрібен вивід LLM, валідований схемою, для автоматизації -summary: Завдання LLM лише з JSON для workflows (необов’язковий інструмент plugin) + - Вам потрібен LLM-крок лише з JSON у робочих процесах + - Вам потрібен вивід LLM, перевірений за схемою, для автоматизації +summary: Завдання LLM лише з JSON для робочих процесів (необов’язковий інструмент Plugin) title: Завдання LLM x-i18n: - generated_at: "2026-04-23T23:07:51Z" - model: gpt-5.4 + generated_at: "2026-05-03T22:56:21Z" + model: gpt-5.5 provider: openai - source_hash: 613aefd1bac5b9675821a118c11130c8bfaefb1673d0266f14ff4e91b47fed8b + source_hash: 9cdc5d4feef17fb6d6d90d819d4c92d26a4ec43e4f5364c6acbaad1934a89269 source_path: tools/llm-task.md - workflow: 15 + workflow: 16 --- -`llm-task` — це **необов’язковий інструмент plugin**, який запускає JSON-only завдання LLM і -повертає структурований вивід (за бажанням валідований за JSON Schema). +`llm-task` — це **необов’язковий інструмент Plugin**, який запускає LLM-завдання лише з JSON і +повертає структурований вивід (за потреби перевірений за JSON Schema). -Це ідеально підходить для рушіїв workflow, таких як Lobster: ви можете додати один крок LLM -без написання користувацького коду OpenClaw для кожного workflow. +Це ідеально для рушіїв робочих процесів на кшталт Lobster: ви можете додати один LLM-крок +без написання власного коду OpenClaw для кожного робочого процесу. -## Увімкнення plugin +## Увімкнення Plugin -1. Увімкніть plugin: +1. Увімкніть Plugin: ```json { @@ -33,21 +33,18 @@ x-i18n: } ``` -2. Додайте інструмент до allowlist (він реєструється з `optional: true`): +2. Дозвольте необов’язковий інструмент: ```json { - "agents": { - "list": [ - { - "id": "main", - "tools": { "allow": ["llm-task"] } - } - ] + "tools": { + "alsoAllow": ["llm-task"] } } ``` +Використовуйте `tools.allow` лише тоді, коли потрібен обмежувальний режим списку дозволених. + ## Конфігурація (необов’язково) ```json @@ -70,30 +67,30 @@ x-i18n: } ``` -`allowedModels` — це allowlist рядків формату `provider/model`. Якщо його задано, будь-який запит -поза списком відхиляється. +`allowedModels` — це список дозволених рядків `provider/model`. Якщо його задано, будь-який запит +поза списком буде відхилено. ## Параметри інструмента -- `prompt` (string, обов’язково) -- `input` (any, необов’язково) -- `schema` (object, необов’язкова JSON Schema) -- `provider` (string, необов’язково) -- `model` (string, необов’язково) -- `thinking` (string, необов’язково) -- `authProfileId` (string, необов’язково) -- `temperature` (number, необов’язково) -- `maxTokens` (number, необов’язково) -- `timeoutMs` (number, необов’язково) +- `prompt` (рядок, обов’язково) +- `input` (будь-що, необов’язково) +- `schema` (об’єкт, необов’язкова JSON Schema) +- `provider` (рядок, необов’язково) +- `model` (рядок, необов’язково) +- `thinking` (рядок, необов’язково) +- `authProfileId` (рядок, необов’язково) +- `temperature` (число, необов’язково) +- `maxTokens` (число, необов’язково) +- `timeoutMs` (число, необов’язково) -`thinking` приймає стандартні пресети міркування OpenClaw, наприклад `low` або `medium`. +`thinking` приймає стандартні пресети міркування OpenClaw, як-от `low` або `medium`. ## Вивід -Повертає `details.json`, що містить розібраний JSON (і виконує валідацію за +Повертає `details.json`, що містить розібраний JSON (і перевіряє його за `schema`, якщо її надано). -## Приклад: крок workflow Lobster +## Приклад: крок робочого процесу Lobster ```lobster openclaw.invoke --tool llm-task --action json --args-json '{ @@ -117,14 +114,14 @@ openclaw.invoke --tool llm-task --action json --args-json '{ ## Примітки щодо безпеки -- Інструмент є **JSON-only** і наказує моделі виводити лише JSON (без - code fence, без коментарів). -- Для моделі під час цього запуску не відкриваються жодні інструменти. -- Вважайте вивід недовіреним, якщо ви не виконуєте валідацію через `schema`. -- Додавайте погодження перед будь-яким кроком із побічними ефектами (send, post, exec). +- Інструмент працює **лише з JSON** і вказує моделі виводити тільки JSON (без + code fences, без коментарів). +- Для цього запуску моделі не надаються жодні інструменти. +- Вважайте вивід ненадійним, якщо не перевіряєте його за допомогою `schema`. +- Розміщуйте затвердження перед будь-яким кроком із побічними ефектами (send, post, exec). -## Пов’язано +## Пов’язане -- [Рівні Thinking](/uk/tools/thinking) -- [Sub-agents](/uk/tools/subagents) +- [Рівні мислення](/uk/tools/thinking) +- [Субагенти](/uk/tools/subagents) - [Slash-команди](/uk/tools/slash-commands) diff --git a/docs/uk/tools/lobster.md b/docs/uk/tools/lobster.md index 3cc341c5e..abd4f7e3a 100644 --- a/docs/uk/tools/lobster.md +++ b/docs/uk/tools/lobster.md @@ -1,52 +1,52 @@ --- read_when: - - Вам потрібні детерміновані багатокрокові workflow з явними погодженнями - - Вам потрібно відновити workflow без повторного запуску попередніх кроків -summary: Типізоване середовище виконання workflow для OpenClaw із відновлюваними етапами погодження. -title: Lobster + - Вам потрібні детерміновані багатоетапні робочі процеси з явними затвердженнями + - Потрібно відновити робочий процес, не запускаючи попередні кроки повторно +summary: Типізоване середовище виконання робочих процесів для OpenClaw із відновлюваними шлюзами затвердження. +title: Омар x-i18n: - generated_at: "2026-04-27T06:28:56Z" - model: gpt-5.4 + generated_at: "2026-05-03T22:56:18Z" + model: gpt-5.5 provider: openai - source_hash: 1700bcfdbcf4558cb908935834e9059221d0d26ad78ed6f9e2158f7e0b83edbd + source_hash: e1a81fddd11fa36f4ce3b3f0bce35f5a7e90300e225027331965bdfdc8919532 source_path: tools/lobster.md - workflow: 15 + workflow: 16 --- -Lobster — це оболонка workflow, яка дозволяє OpenClaw виконувати багатокрокові послідовності інструментів як одну детерміновану операцію з явними контрольними точками погодження. +Lobster — це оболонка робочих процесів, яка дає OpenClaw змогу запускати багатоетапні послідовності інструментів як одну детерміновану операцію з явними контрольними точками затвердження. -Lobster — це рівень авторингу, що стоїть на один щабель вище за відокремлену фонову роботу. Для оркестрації потоків над окремими завданнями див. [TaskFlow](/uk/automation/taskflow) (`openclaw tasks flow`). Для журналу активності завдань див. [`openclaw tasks`](/uk/automation/tasks). +Lobster — це один авторський шар над від’єднаною фоновою роботою. Про оркестрацію потоків над окремими завданнями див. [TaskFlow](/uk/automation/taskflow) (`openclaw tasks flow`). Про журнал активності завдань див. [`openclaw tasks`](/uk/automation/tasks). ## Хук -Ваш помічник може створювати інструменти, які керують ним самим. Попросіть workflow — і за 30 хвилин у вас буде CLI плюс конвеєри, які виконуються як один виклик. Lobster — це відсутній елемент: детерміновані конвеєри, явні погодження та відновлюваний стан. +Ваш асистент може створювати інструменти, які керують ним самим. Попросіть робочий процес, і за 30 хвилин матимете CLI плюс конвеєри, що запускаються одним викликом. Lobster — це відсутня ланка: детерміновані конвеєри, явні затвердження та стан, який можна відновити. ## Навіщо -Сьогодні складні workflow вимагають багатьох викликів інструментів із поверненням назад і вперед. Кожен виклик коштує токенів, а LLM має оркеструвати кожен крок. Lobster переносить цю оркестрацію в типізоване середовище виконання: +Сьогодні складні робочі процеси потребують багатьох взаємних викликів інструментів. Кожен виклик витрачає токени, а LLM має оркеструвати кожен крок. Lobster переносить цю оркестрацію в типізоване середовище виконання: - **Один виклик замість багатьох**: OpenClaw виконує один виклик інструмента Lobster і отримує структурований результат. -- **Вбудовані погодження**: побічні дії (надіслати email, залишити коментар) зупиняють workflow, доки його явно не погодять. -- **Відновлюваність**: зупинені workflow повертають токен; погодьте й відновіть без повторного запуску всього. +- **Вбудовані затвердження**: побічні ефекти (надіслати email, опублікувати коментар) зупиняють робочий процес до явного затвердження. +- **Можливість відновлення**: зупинені робочі процеси повертають токен; затвердьте й відновіть без повторного виконання всього процесу. -## Чому DSL, а не звичайні програми? +## Навіщо DSL замість звичайних програм? -Lobster навмисно невеликий. Мета не в тому, щоб створити "нову мову", а в тому, щоб мати передбачувану, дружню до AI специфікацію конвеєра з першокласними погодженнями й токенами відновлення. +Lobster навмисно невеликий. Мета — не "нова мова", а передбачувана, зручна для AI специфікація конвеєра з повноцінними затвердженнями й токенами відновлення. -- **Погодження/відновлення вбудовано**: звичайна програма може попросити людину про підтвердження, але не може _зупинитися й відновитися_ за допомогою стійкого токена без того, щоб ви самі не вигадали таке середовище виконання. -- **Детермінізм + аудитованість**: конвеєри — це дані, тому їх легко журналювати, порівнювати, відтворювати й перевіряти. -- **Обмежена поверхня для AI**: маленька граматика + передавання JSON зменшують кількість “творчих” шляхів виконання коду й роблять валідацію реалістичною. -- **Політика безпеки вбудована**: тайм-аути, обмеження виводу, перевірки sandbox і allowlist примусово забезпечуються середовищем виконання, а не кожним окремим скриптом. -- **Усе ще програмований**: кожен крок може викликати будь-який CLI або скрипт. Якщо ви хочете JS/TS, генеруйте файли `.lobster` з коду. +- **Затвердження/відновлення вбудовано**: звичайна програма може попросити людину про підтвердження, але не може _призупинитися й відновитися_ зі сталим токеном, якщо ви самі не створите таке середовище виконання. +- **Детермінізм + аудитованість**: конвеєри — це дані, тому їх легко логувати, порівнювати, відтворювати й переглядати. +- **Обмежена поверхня для AI**: крихітна граматика + передавання JSON зменшують кількість “творчих” шляхів коду й роблять валідацію реалістичною. +- **Політика безпеки вбудована**: тайм-аути, обмеження виводу, перевірки пісочниці та allowlist-и застосовуються середовищем виконання, а не кожним скриптом. +- **Водночас програмований**: кожен крок може викликати будь-який CLI або скрипт. Якщо хочете JS/TS, генеруйте файли `.lobster` з коду. ## Як це працює -OpenClaw виконує workflow Lobster **у межах процесу** за допомогою вбудованого runner. Жоден зовнішній підпроцес CLI не запускається; рушій workflow виконується всередині процесу gateway і напряму повертає JSON-конверт. -Якщо конвеєр зупиняється для погодження, інструмент повертає `resumeToken`, щоб ви могли продовжити пізніше. +OpenClaw запускає робочі процеси Lobster **у межах процесу** за допомогою вбудованого раннера. Зовнішній підпроцес CLI не створюється; рушій робочих процесів виконується всередині процесу Gateway і повертає JSON-конверт напряму. +Якщо конвеєр призупиняється для затвердження, інструмент повертає `resumeToken`, щоб ви могли продовжити пізніше. -## Патерн: маленький CLI + конвеєри JSON + погодження +## Патерн: малий CLI + JSON-канали + затвердження -Створюйте маленькі команди, які працюють із JSON, а потім об’єднуйте їх в один виклик Lobster. (Нижче наведено лише приклади назв команд — замініть їх своїми.) +Створюйте невеликі команди, які спілкуються JSON, а потім об’єднуйте їх в один виклик Lobster. (Назви прикладних команд нижче — замініть їх на власні.) ```bash inbox list --json @@ -62,7 +62,7 @@ inbox apply --json } ``` -Якщо конвеєр запитує погодження, відновіть його за токеном: +Якщо конвеєр запитує затвердження, відновіть його з токеном: ```json { @@ -72,22 +72,22 @@ inbox apply --json } ``` -AI ініціює workflow; Lobster виконує кроки. Етапи погодження роблять побічні дії явними й аудитованими. +AI запускає робочий процес; Lobster виконує кроки. Шлюзи затвердження роблять побічні ефекти явними й аудитованими. -Приклад: зіставити вхідні елементи з викликами інструментів: +Приклад: зіставлення вхідних елементів із викликами інструментів: ```bash 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) -Для workflow, яким потрібен **структурований крок LLM**, увімкніть необов’язковий -інструмент plugin `llm-task` і викликайте його з Lobster. Це зберігає workflow -детермінованим, але водночас дозволяє класифікувати/узагальнювати/створювати чернетки за допомогою моделі. +Для робочих процесів, яким потрібен **структурований крок LLM**, увімкніть необов’язковий інструмент plugin +`llm-task` і викликайте його з Lobster. Це зберігає робочий процес +детермінованим, але дає змогу класифікувати, підсумовувати й готувати чернетки за допомогою моделі. -Увімкнення інструмента: +Увімкніть інструмент: ```json { @@ -107,7 +107,7 @@ gog.gmail.search --query 'newer_than:1d' \ } ``` -Використання в конвеєрі: +Використайте його в конвеєрі: ```lobster openclaw.invoke --tool llm-task --action json --args-json '{ @@ -126,11 +126,11 @@ openclaw.invoke --tool llm-task --action json --args-json '{ }' ``` -Докладніше про параметри й конфігурацію див. у [LLM Task](/uk/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 @@ -156,17 +156,17 @@ steps: Примітки: - `stdin: $step.stdout` і `stdin: $step.json` передають вивід попереднього кроку. -- `condition` (або `when`) може керувати виконанням кроків на основі `$step.approved`. +- `condition` (або `when`) може ставити кроки в залежність від `$step.approved`. -## Установлення Lobster +## Встановлення Lobster -Вбудовані workflow Lobster виконуються в межах процесу; окремий бінарний файл `lobster` не потрібен. Вбудований runner постачається разом із plugin Lobster. +Вбудовані робочі процеси Lobster виконуються в межах процесу; окремий бінарний файл `lobster` не потрібен. Вбудований раннер постачається з plugin Lobster. -Якщо вам потрібен окремий CLI Lobster для розробки або зовнішніх конвеєрів, установіть його з [репозиторію Lobster](https://github.com/openclaw/lobster) і переконайтеся, що `lobster` є в `PATH`. +Якщо вам потрібен автономний CLI Lobster для розробки або зовнішніх конвеєрів, установіть його з [репозиторію Lobster](https://github.com/openclaw/lobster) і переконайтеся, що `lobster` є в `PATH`. ## Увімкнення інструмента -Lobster — це **необов’язковий** інструмент plugin (типово не ввімкнений). +Lobster — це **необов’язковий** інструмент plugin (не ввімкнений за замовчуванням). Рекомендовано (адитивно, безпечно): @@ -195,10 +195,10 @@ Lobster — це **необов’язковий** інструмент plugin ( } ``` -Уникайте використання `tools.allow: ["lobster"]`, якщо тільки ви справді не хочете працювати в обмежувальному режимі allowlist. +Уникайте використання `tools.allow: ["lobster"]`, якщо не маєте наміру працювати в обмежувальному режимі allowlist. -Allowlist для необов’язкових plugin — це opt-in. Якщо ваш allowlist містить лише інструменти plugin (наприклад, `lobster`), OpenClaw залишає основні інструменти ввімкненими. Щоб обмежити основні інструменти, також включіть у allowlist потрібні основні інструменти або групи. +Allowlists вмикаються за бажанням для необов’язкових plugins. `alsoAllow` вмикає лише названі необов’язкові інструменти plugin, зберігаючи звичайний набір базових інструментів. Щоб обмежити базові інструменти, використовуйте `tools.allow` із потрібними базовими інструментами або групами. ## Приклад: сортування email @@ -226,7 +226,7 @@ User: "Check my email and draft replies" } ``` -Повертає JSON-конверт (усічено): +Повертає JSON-конверт (скорочено): ```json { @@ -242,7 +242,7 @@ User: "Check my email and draft replies" } ``` -Користувач погоджує → відновлення: +Користувач затверджує → відновлення: ```json { @@ -252,13 +252,13 @@ User: "Check my email and draft replies" } ``` -Один workflow. Детермінований. Безпечний. +Один робочий процес. Детермінований. Безпечний. ## Параметри інструмента ### `run` -Запустити конвеєр у режимі інструмента. +Запустіть конвеєр у режимі інструмента. ```json { @@ -270,7 +270,7 @@ User: "Check my email and draft replies" } ``` -Запуск файла workflow з аргументами: +Запустіть файл робочого процесу з аргументами: ```json { @@ -282,7 +282,7 @@ User: "Check my email and draft replies" ### `resume` -Продовжити зупинений workflow після погодження. +Продовжіть зупинений робочий процес після затвердження. ```json { @@ -294,62 +294,62 @@ User: "Check my email and draft replies" ### Необов’язкові вхідні дані -- `cwd`: Відносний робочий каталог для конвеєра (має залишатися в межах робочого каталогу gateway). -- `timeoutMs`: Перервати workflow, якщо він перевищує цю тривалість (типово: 20000). -- `maxStdoutBytes`: Перервати workflow, якщо вивід перевищує цей розмір (типово: 512000). -- `argsJson`: JSON-рядок, що передається в `lobster run --args-json` (лише для файлів workflow). +- `cwd`: відносний робочий каталог для конвеєра (має залишатися в межах робочого каталогу Gateway). +- `timeoutMs`: перервати робочий процес, якщо він перевищує цю тривалість (за замовчуванням: 20000). +- `maxStdoutBytes`: перервати робочий процес, якщо вивід перевищує цей розмір (за замовчуванням: 512000). +- `argsJson`: JSON-рядок, переданий до `lobster run --args-json` (лише файли робочих процесів). ## Конверт виводу Lobster повертає JSON-конверт з одним із трьох статусів: - `ok` → успішно завершено -- `needs_approval` → зупинено; для відновлення потрібен `requiresApproval.resumeToken` +- `needs_approval` → призупинено; для відновлення потрібен `requiresApproval.resumeToken` - `cancelled` → явно відхилено або скасовано -Інструмент показує конверт і в `content` (відформатований JSON), і в `details` (сирий об’єкт). +Інструмент показує конверт і в `content` (форматований JSON), і в `details` (сирий об’єкт). -## Погодження +## Затвердження -Якщо присутній `requiresApproval`, перегляньте prompt і вирішіть: +Якщо присутній `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-перегляд до запитів на затвердження без власного 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). ## Безпека -- **Лише локально в межах процесу** — workflow виконуються всередині процесу gateway; сам plugin не робить мережевих викликів. +- **Лише локально в межах процесу** — робочі процеси виконуються всередині процесу Gateway; сам plugin не виконує мережевих викликів. - **Без секретів** — Lobster не керує OAuth; він викликає інструменти OpenClaw, які це роблять. -- **З урахуванням sandbox** — вимикається, коли контекст інструмента перебуває в sandbox. -- **Посилений захист** — тайм-аути й обмеження виводу забезпечуються вбудованим runner. +- **З урахуванням пісочниці** — вимикається, коли контекст інструмента перебуває в пісочниці. +- **Зміцнений** — тайм-аути й обмеження виводу застосовуються вбудованим раннером. ## Усунення несправностей -- **`lobster timed out`** → збільште `timeoutMs` або розбийте довгий конвеєр. -- **`lobster output exceeded maxStdoutBytes`** → збільшіть `maxStdoutBytes` або зменште розмір виводу. -- **`lobster returned invalid JSON`** → переконайтеся, що конвеєр працює в режимі інструмента й виводить лише JSON. -- **`lobster failed`** → перевірте журнали gateway на наявність деталей помилки вбудованого runner. +- **`lobster timed out`** → збільште `timeoutMs` або розділіть довгий конвеєр. +- **`lobster output exceeded maxStdoutBytes`** → збільште `maxStdoutBytes` або зменште розмір виводу. +- **`lobster returned invalid JSON`** → переконайтеся, що конвеєр працює в режимі інструмента й друкує лише JSON. +- **`lobster failed`** → перевірте журнали Gateway, щоб знайти подробиці помилки вбудованого раннера. -## Дізнатися більше +## Докладніше - [Plugins](/uk/tools/plugin) -- [Авторинг інструментів plugin](/uk/plugins/building-plugins#registering-agent-tools) +- [Створення інструментів plugin](/uk/plugins/building-plugins#registering-agent-tools) -## Кейс: workflow спільноти +## Приклад із практики: спільнотні робочі процеси -Один публічний приклад: CLI “second brain” + конвеєри Lobster, які керують трьома сховищами Markdown (особистим, партнерським, спільним). CLI виводить JSON для статистики, списків inbox і сканування застарілих елементів; Lobster об’єднує ці команди у workflow на кшталт `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) — планування workflow Lobster +- [Автоматизація та завдання](/uk/automation) — планування робочих процесів Lobster - [Огляд автоматизації](/uk/automation) — усі механізми автоматизації - [Огляд інструментів](/uk/tools) — усі доступні інструменти агента