chore(i18n): refresh uk translations
This commit is contained in:
parent
3ae4181578
commit
d7adfcd042
@ -2,25 +2,25 @@
|
||||
read_when:
|
||||
- Запуск Gateway з CLI (розробка або сервери)
|
||||
- Налагодження автентифікації Gateway, режимів прив’язки та підключення
|
||||
- Виявлення шлюзів через Bonjour (local loopback + DNS-SD глобальної мережі)
|
||||
summary: CLI шлюзу OpenClaw (`openclaw gateway`) — запуск, запити та виявлення шлюзів
|
||||
- Виявлення шлюзів через Bonjour (local loopback + широкозонний DNS-SD)
|
||||
summary: OpenClaw Gateway CLI (`openclaw gateway`) — запуск, запити та виявлення шлюзів
|
||||
title: Gateway
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T07:25:02Z"
|
||||
generated_at: "2026-04-23T15:25:02Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: f9160017a4d1326819f6b4d067bd99aa02ee37689b96c185defedef6200c19cf
|
||||
source_hash: 6a398d61f9486319ecb7e1aa216cb59e4e8848a2bb11bdd2d29f6f55387a0ac1
|
||||
source_path: cli/gateway.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# CLI Gateway
|
||||
# Gateway CLI
|
||||
|
||||
Gateway — це WebSocket-сервер OpenClaw (канали, вузли, сесії, хуки).
|
||||
|
||||
Підкоманди на цій сторінці доступні через `openclaw gateway …`.
|
||||
|
||||
Пов’язана документація:
|
||||
Пов’язані документи:
|
||||
|
||||
- [/gateway/bonjour](/uk/gateway/bonjour)
|
||||
- [/gateway/discovery](/uk/gateway/discovery)
|
||||
@ -42,59 +42,59 @@ openclaw gateway run
|
||||
|
||||
Примітки:
|
||||
|
||||
- За замовчуванням Gateway відмовляється запускатися, якщо в `~/.openclaw/openclaw.json` не встановлено `gateway.mode=local`. Використовуйте `--allow-unconfigured` для разових/розробницьких запусків.
|
||||
- Очікується, що `openclaw onboard --mode local` і `openclaw setup` запишуть `gateway.mode=local`. Якщо файл існує, але `gateway.mode` відсутній, вважайте це пошкодженою або перезаписаною конфігурацією та виправте її, а не припускайте локальний режим неявно.
|
||||
- Якщо файл існує, а `gateway.mode` відсутній, Gateway вважає це підозрілим пошкодженням конфігурації й відмовляється «вгадувати local» за вас.
|
||||
- Прив’язка за межами loopback без автентифікації заблокована (захисне обмеження).
|
||||
- `SIGUSR1` запускає перезапуск у межах процесу, якщо це дозволено (`commands.restart` увімкнено за замовчуванням; установіть `commands.restart: false`, щоб заблокувати ручний перезапуск, тоді як застосування/оновлення інструмента й конфігурації gateway залишаться дозволеними).
|
||||
- Обробники `SIGINT`/`SIGTERM` зупиняють процес gateway, але не відновлюють жодний власний стан термінала. Якщо ви обгортаєте CLI у TUI або ввід у raw mode, відновіть термінал перед виходом.
|
||||
- За замовчуванням Gateway відмовляється запускатися, якщо в `~/.openclaw/openclaw.json` не встановлено `gateway.mode=local`. Використовуйте `--allow-unconfigured` для одноразових або dev-запусків.
|
||||
- Очікується, що `openclaw onboard --mode local` і `openclaw setup` запишуть `gateway.mode=local`. Якщо файл існує, але `gateway.mode` відсутній, вважайте це пошкодженою або перезаписаною конфігурацією та виправте її, а не припускайте неявно локальний режим.
|
||||
- Якщо файл існує, а `gateway.mode` відсутній, Gateway вважає це підозрілим пошкодженням конфігурації й відмовляється «вгадувати local» замість вас.
|
||||
- Прив’язка поза loopback без автентифікації блокується (запобіжний механізм безпеки).
|
||||
- `SIGUSR1` запускає перезапуск у межах процесу, якщо це дозволено (типово `commands.restart` увімкнено; встановіть `commands.restart: false`, щоб заборонити ручний перезапуск, водночас інструмент/конфігурація gateway apply/update залишаються дозволеними).
|
||||
- Обробники `SIGINT`/`SIGTERM` зупиняють процес gateway, але не відновлюють жодний користувацький стан термінала. Якщо ви обгортаєте CLI у TUI або raw-mode ввід, відновіть термінал перед виходом.
|
||||
|
||||
### Параметри
|
||||
|
||||
- `--port <port>`: порт WebSocket (типово береться з config/env; зазвичай `18789`).
|
||||
- `--port <port>`: порт WebSocket (типове значення надходить із config/env; зазвичай `18789`).
|
||||
- `--bind <loopback|lan|tailnet|auto|custom>`: режим прив’язки слухача.
|
||||
- `--auth <token|password>`: перевизначення режиму автентифікації.
|
||||
- `--token <token>`: перевизначення токена (також установлює `OPENCLAW_GATEWAY_TOKEN` для процесу).
|
||||
- `--password <password>`: перевизначення пароля. Попередження: паролі, вказані в рядку команди, можуть бути видимі в локальних списках процесів.
|
||||
- `--token <token>`: перевизначення токена (також встановлює `OPENCLAW_GATEWAY_TOKEN` для процесу).
|
||||
- `--password <password>`: перевизначення пароля. Попередження: паролі, вказані безпосередньо в команді, можуть бути видимі в локальних списках процесів.
|
||||
- `--password-file <path>`: зчитати пароль gateway з файлу.
|
||||
- `--tailscale <off|serve|funnel>`: відкрити Gateway через Tailscale.
|
||||
- `--tailscale <off|serve|funnel>`: опублікувати Gateway через Tailscale.
|
||||
- `--tailscale-reset-on-exit`: скинути конфігурацію Tailscale serve/funnel під час завершення роботи.
|
||||
- `--allow-unconfigured`: дозволити запуск gateway без `gateway.mode=local` у конфігурації. Це обходить стартовий захист лише для разового/розробницького початкового запуску; параметр не записує і не виправляє файл конфігурації.
|
||||
- `--dev`: створити dev config і робочий простір, якщо їх немає (пропускає BOOTSTRAP.md).
|
||||
- `--reset`: скинути dev config + облікові дані + сесії + робочий простір (потрібен `--dev`).
|
||||
- `--allow-unconfigured`: дозволити запуск gateway без `gateway.mode=local` у конфігурації. Це обходить стартовий запобіжник лише для одноразового/dev bootstrap; параметр не записує й не виправляє файл конфігурації.
|
||||
- `--dev`: створити dev-конфігурацію та workspace, якщо вони відсутні (пропускає BOOTSTRAP.md).
|
||||
- `--reset`: скинути dev-конфігурацію, облікові дані, сесії та workspace (потрібен `--dev`).
|
||||
- `--force`: завершити будь-який наявний слухач на вибраному порту перед запуском.
|
||||
- `--verbose`: докладні журнали.
|
||||
- `--cli-backend-logs`: показувати в консолі лише журнали бекенду CLI (і ввімкнути stdout/stderr).
|
||||
- `--ws-log <auto|full|compact>`: стиль журналів websocket (типово `auto`).
|
||||
- `--cli-backend-logs`: показувати в консолі лише журнали бекенду CLI (і вмикати stdout/stderr).
|
||||
- `--ws-log <auto|full|compact>`: стиль журналу websocket (типово `auto`).
|
||||
- `--compact`: псевдонім для `--ws-log compact`.
|
||||
- `--raw-stream`: журналювати необроблені події потоку моделі в jsonl.
|
||||
- `--raw-stream-path <path>`: шлях до jsonl необробленого потоку.
|
||||
- `--raw-stream`: журналювати сирі події потоку моделі у jsonl.
|
||||
- `--raw-stream-path <path>`: шлях до jsonl сирого потоку.
|
||||
|
||||
Профілювання запуску:
|
||||
|
||||
- Установіть `OPENCLAW_GATEWAY_STARTUP_TRACE=1`, щоб журналювати тривалість фаз під час запуску Gateway.
|
||||
- Запустіть `pnpm test:startup:gateway -- --runs 5 --warmup 1`, щоб виміряти швидкодію запуску Gateway. Бенчмарк фіксує перший вивід процесу, `/healthz`, `/readyz` і часові показники трасування запуску.
|
||||
- Встановіть `OPENCLAW_GATEWAY_STARTUP_TRACE=1`, щоб журналювати тривалість фаз під час запуску Gateway.
|
||||
- Запустіть `pnpm test:startup:gateway -- --runs 5 --warmup 1`, щоб виконати бенчмарк запуску Gateway. Бенчмарк фіксує перший вивід процесу, `/healthz`, `/readyz` і часові показники трасування запуску.
|
||||
|
||||
## Запит до запущеного Gateway
|
||||
|
||||
Усі команди запитів використовують WebSocket RPC.
|
||||
Усі команди запиту використовують WebSocket RPC.
|
||||
|
||||
Режими виводу:
|
||||
|
||||
- Типово: людинозрозумілий формат (з кольорами в TTY).
|
||||
- `--json`: машинозчитуваний JSON (без стилізації/спінера).
|
||||
- `--no-color` (або `NO_COLOR=1`): вимкнути ANSI, зберігши формат для людей.
|
||||
- Типово: людиночитаний формат (з кольорами в TTY).
|
||||
- `--json`: JSON для машинної обробки (без стилізації/спінера).
|
||||
- `--no-color` (або `NO_COLOR=1`): вимкнути ANSI, зберігши людиночитане компонування.
|
||||
|
||||
Спільні параметри (де підтримуються):
|
||||
|
||||
- `--url <url>`: URL WebSocket Gateway.
|
||||
- `--token <token>`: токен Gateway.
|
||||
- `--password <password>`: пароль Gateway.
|
||||
- `--timeout <ms>`: таймаут/бюджет часу (залежить від команди).
|
||||
- `--expect-final`: чекати «final» відповіді (виклики агентів).
|
||||
- `--timeout <ms>`: тайм-аут/бюджет часу (залежить від команди).
|
||||
- `--expect-final`: чекати на «final» відповідь (виклики агентів).
|
||||
|
||||
Примітка: коли ви задаєте `--url`, CLI не використовує резервні облікові дані з конфігурації або середовища.
|
||||
Передайте `--token` або `--password` явно. Відсутність явних облікових даних є помилкою.
|
||||
Примітка: коли ви встановлюєте `--url`, CLI не повертається до облікових даних із конфігурації чи змінних середовища.
|
||||
Передайте `--token` або `--password` явно. Відсутність явно переданих облікових даних є помилкою.
|
||||
|
||||
### `gateway health`
|
||||
|
||||
@ -102,7 +102,7 @@ openclaw gateway run
|
||||
openclaw gateway health --url ws://127.0.0.1:18789
|
||||
```
|
||||
|
||||
HTTP-ендпоінт `/healthz` — це перевірка живучості: він відповідає, щойно сервер може обслуговувати HTTP. HTTP-ендпоінт `/readyz` є суворішим і залишається червоним, поки побічні компоненти запуску, канали або налаштовані хуки ще стабілізуються.
|
||||
HTTP-ендпойнт `/healthz` — це перевірка працездатності: він повертає відповідь, щойно сервер може відповідати на HTTP. HTTP-ендпойнт `/readyz` суворіший і залишається в червоному стані, поки стартові sidecar-компоненти, канали або налаштовані хуки ще завершують ініціалізацію.
|
||||
|
||||
### `gateway usage-cost`
|
||||
|
||||
@ -120,7 +120,7 @@ openclaw gateway usage-cost --json
|
||||
|
||||
### `gateway stability`
|
||||
|
||||
Отримати нещодавній діагностичний записувач стабільності з запущеного Gateway.
|
||||
Отримати нещодавній засіб діагностичного запису стабільності із запущеного Gateway.
|
||||
|
||||
```bash
|
||||
openclaw gateway stability
|
||||
@ -134,19 +134,20 @@ openclaw gateway stability --json
|
||||
|
||||
- `--limit <limit>`: максимальна кількість нещодавніх подій для включення (типово `25`, максимум `1000`).
|
||||
- `--type <type>`: фільтр за типом діагностичної події, наприклад `payload.large` або `diagnostic.memory.pressure`.
|
||||
- `--since-seq <seq>`: включати лише події після номера діагностичної послідовності.
|
||||
- `--bundle [path]`: читати збережений пакет стабільності замість виклику запущеного Gateway. Використовуйте `--bundle latest` (або просто `--bundle`) для найновішого пакета в каталозі стану, або передайте шлях до JSON-пакета безпосередньо.
|
||||
- `--export`: записати zip із діагностикою для підтримки, яким можна поділитися, замість виведення подробиць стабільності.
|
||||
- `--since-seq <seq>`: включати лише події після номера послідовності діагностики.
|
||||
- `--bundle [path]`: зчитати збережений пакет стабільності замість виклику запущеного Gateway. Використовуйте `--bundle latest` (або просто `--bundle`) для найновішого пакета в каталозі стану або передайте шлях до JSON пакета безпосередньо.
|
||||
- `--export`: записати zip-файл діагностики підтримки для поширення замість виведення відомостей про стабільність.
|
||||
- `--output <path>`: шлях виводу для `--export`.
|
||||
|
||||
Примітки:
|
||||
|
||||
- Записи зберігають операційні метадані: назви подій, кількості, розміри в байтах, показники пам’яті, стан черги/сесій, назви каналів/плагінів і відредаговані зведення сесій. Вони не зберігають текст чату, тіла webhook, виводи інструментів, необроблені тіла запитів або відповідей, токени, cookie, секретні значення, імена хостів або необроблені id сесій. Установіть `diagnostics.enabled: false`, щоб повністю вимкнути записувач.
|
||||
- Під час фатальних завершень Gateway, таймаутів завершення роботи та збоїв запуску після перезапуску OpenClaw записує той самий діагностичний знімок у `~/.openclaw/logs/stability/openclaw-stability-*.json`, якщо в записувача є події. Перегляньте найновіший пакет за допомогою `openclaw gateway stability --bundle latest`; параметри `--limit`, `--type` і `--since-seq` також застосовуються до виводу пакета.
|
||||
- Записи зберігають операційні метадані: назви подій, лічильники, розміри в байтах, показники пам’яті, стан черги/сесії, назви каналів/плагінів і знеособлені зведення сесій. Вони не зберігають текст чату, тіла webhook, виводи інструментів, сирі тіла запитів або відповідей, токени, cookie, секретні значення, імена хостів або сирі ідентифікатори сесій. Встановіть `diagnostics.enabled: false`, щоб повністю вимкнути засіб запису.
|
||||
- У разі фатального завершення Gateway, тайм-аутів вимкнення та збоїв запуску під час перезапуску OpenClaw записує той самий діагностичний знімок у `~/.openclaw/logs/stability/openclaw-stability-*.json`, якщо засіб запису має події. Перегляньте найновіший пакет за допомогою `openclaw gateway stability --bundle latest`; параметри `--limit`, `--type` і `--since-seq` також застосовуються до виводу з пакета.
|
||||
|
||||
### `gateway diagnostics export`
|
||||
|
||||
Записати локальний zip із діагностикою, призначений для додавання до звітів про помилки.
|
||||
Записати локальний zip-файл діагностики, призначений для додавання до повідомлень про помилки.
|
||||
Модель конфіденційності та вміст пакета див. у [Diagnostics Export](/uk/gateway/diagnostics).
|
||||
|
||||
```bash
|
||||
openclaw gateway diagnostics export
|
||||
@ -156,19 +157,19 @@ openclaw gateway diagnostics export --json
|
||||
|
||||
Параметри:
|
||||
|
||||
- `--output <path>`: шлях до вихідного zip. Типово — експорт для підтримки в каталозі стану.
|
||||
- `--output <path>`: шлях до вихідного zip-файла. Типово використовується експорт підтримки в каталозі стану.
|
||||
- `--log-lines <count>`: максимальна кількість очищених рядків журналу для включення (типово `5000`).
|
||||
- `--log-bytes <bytes>`: максимальна кількість байтів журналу для аналізу (типово `1000000`).
|
||||
- `--url <url>`: URL WebSocket Gateway для знімка health.
|
||||
- `--token <token>`: токен Gateway для знімка health.
|
||||
- `--password <password>`: пароль Gateway для знімка health.
|
||||
- `--timeout <ms>`: таймаут знімка status/health (типово `3000`).
|
||||
- `--timeout <ms>`: тайм-аут знімка status/health (типово `3000`).
|
||||
- `--no-stability-bundle`: пропустити пошук збереженого пакета стабільності.
|
||||
- `--json`: вивести записаний шлях, розмір і маніфест у форматі JSON.
|
||||
|
||||
Експорт містить маніфест, Markdown-зведення, форму конфігурації, очищені деталі конфігурації, очищені зведення журналів, очищені знімки status/health Gateway і найновіший пакет стабільності, якщо він існує.
|
||||
Експорт містить маніфест, Markdown-зведення, форму конфігурації, очищені відомості конфігурації, очищені зведення журналів, очищені знімки status/health Gateway і найновіший пакет стабільності, якщо він існує.
|
||||
|
||||
Він призначений для спільного використання. Він зберігає операційні деталі, що допомагають у налагодженні, як-от безпечні поля журналів OpenClaw, назви підсистем, коди стану, тривалості, налаштовані режими, порти, id плагінів, id провайдерів, несекретні параметри функцій і відредаговані операційні повідомлення журналів. Він пропускає або редагує текст чату, тіла webhook, виводи інструментів, облікові дані, cookie, ідентифікатори облікових записів/повідомлень, текст підказок/інструкцій, імена хостів і секретні значення. Коли повідомлення у стилі LogTape схоже на текст корисного навантаження користувача/чату/інструмента, експорт зберігає лише факт пропуску повідомлення та його розмір у байтах.
|
||||
Він призначений для спільного використання. Він зберігає операційні відомості, що допомагають у налагодженні, як-от безпечні поля журналів OpenClaw, назви підсистем, коди стану, тривалості, налаштовані режими, порти, ідентифікатори плагінів, ідентифікатори провайдерів, несекретні налаштування функцій і знеособлені операційні повідомлення журналу. Він пропускає або редагує текст чату, тіла webhook, виводи інструментів, облікові дані, cookie, ідентифікатори облікових записів/повідомлень, текст prompt/інструкцій, імена хостів і секретні значення. Коли повідомлення у стилі LogTape виглядає як текст корисного навантаження користувача/чату/інструмента, експорт зберігає лише факт пропуску повідомлення та кількість його байтів.
|
||||
|
||||
### `gateway status`
|
||||
|
||||
@ -182,86 +183,86 @@ openclaw gateway status --require-rpc
|
||||
|
||||
Параметри:
|
||||
|
||||
- `--url <url>`: додати явну ціль перевірки. Налаштовані remote і localhost усе одно перевіряються.
|
||||
- `--url <url>`: додати явну ціль перевірки. Налаштований віддалений вузол і localhost однаково перевіряються.
|
||||
- `--token <token>`: автентифікація токеном для перевірки.
|
||||
- `--password <password>`: автентифікація паролем для перевірки.
|
||||
- `--timeout <ms>`: таймаут перевірки (типово `10000`).
|
||||
- `--no-probe`: пропустити перевірку підключення (лише перегляд служби).
|
||||
- `--deep`: також сканувати системні служби.
|
||||
- `--require-rpc`: підвищити стандартну перевірку підключення до перевірки читання і завершити роботу з ненульовим кодом, якщо ця перевірка читання не вдасться. Не можна поєднувати з `--no-probe`.
|
||||
- `--timeout <ms>`: тайм-аут перевірки (типово `10000`).
|
||||
- `--no-probe`: пропустити перевірку підключення (лише подання служби).
|
||||
- `--deep`: також сканувати служби системного рівня.
|
||||
- `--require-rpc`: підвищити типову перевірку підключення до перевірки читання та завершуватися з ненульовим кодом, якщо ця перевірка читання не вдалася. Не можна поєднувати з `--no-probe`.
|
||||
|
||||
Примітки:
|
||||
|
||||
- `gateway status` лишається доступною для діагностики, навіть якщо локальна конфігурація CLI відсутня або недійсна.
|
||||
- Стандартна `gateway status` підтверджує стан служби, WebSocket-з’єднання і можливість автентифікації, видиму під час рукостискання. Вона не підтверджує операції читання/запису/адміністрування.
|
||||
- `gateway status` за можливості розв’язує налаштовані SecretRef автентифікації для probe auth.
|
||||
- Якщо в цьому шляху команди не вдається розв’язати потрібний SecretRef автентифікації, `gateway status --json` повідомляє `rpc.authWarning`, коли probe auth/підключення не вдається; передайте `--token`/`--password` явно або спочатку розв’яжіть джерело секрету.
|
||||
- Якщо перевірка успішна, попередження про нерозв’язані auth-ref пригнічуються, щоб уникнути хибнопозитивних результатів.
|
||||
- Використовуйте `--require-rpc` у скриптах і автоматизації, коли недостатньо просто служби, що слухає, і потрібно, щоб також були справні RPC-виклики з областю читання.
|
||||
- `--deep` додає best-effort-сканування додаткових встановлень launchd/systemd/schtasks. Якщо виявлено кілька gateway-подібних служб, у людському виводі друкуються підказки з очищення та попередження, що в більшості конфігурацій має працювати один gateway на машину.
|
||||
- Людинозрозумілий вивід містить розв’язаний шлях до файлового журналу, а також знімок шляхів/дійсності конфігурації CLI і служби, щоб допомогти діагностувати розбіжності профілю або каталогу стану.
|
||||
- У встановленнях systemd на Linux перевірки розбіжностей автентифікації служби читають і значення `Environment=`, і `EnvironmentFile=` з unit-файлу (включно з `%h`, лапкованими шляхами, кількома файлами та необов’язковими файлами з `-`).
|
||||
- Перевірки розбіжностей розв’язують SecretRef `gateway.auth.token` з використанням об’єднаного runtime env (спочатку env команди служби, потім резервно env процесу).
|
||||
- Якщо автентифікація токеном фактично не активна (явний `gateway.auth.mode` зі значенням `password`/`none`/`trusted-proxy`, або mode не задано, де пароль може мати пріоритет і жоден кандидат токена не може перемогти), перевірки розбіжностей токена пропускають розв’язання токена з конфігурації.
|
||||
- `gateway status` залишається доступною для діагностики навіть тоді, коли локальна конфігурація CLI відсутня або недійсна.
|
||||
- Типова команда `gateway status` підтверджує стан служби, з’єднання WebSocket і можливість автентифікації, видиму під час handshake. Вона не підтверджує операції читання/запису/адміністрування.
|
||||
- `gateway status` за можливості розв’язує налаштовані auth SecretRef для автентифікації перевірки.
|
||||
- Якщо в цьому шляху команди не вдається розв’язати потрібний auth SecretRef, `gateway status --json` повідомляє `rpc.authWarning`, коли перевірка підключення/автентифікації не вдається; передайте `--token`/`--password` явно або спочатку розв’яжіть джерело секрету.
|
||||
- Якщо перевірка успішна, попередження про нерозв’язані auth-ref пригнічуються, щоб уникнути хибних спрацьовувань.
|
||||
- Використовуйте `--require-rpc` у скриптах та автоматизації, коли наявності служби, що слухає, недостатньо й потрібно, щоб RPC-виклики з областю читання також були справними.
|
||||
- `--deep` додає спробу сканування додаткових установок launchd/systemd/schtasks. Якщо виявлено кілька служб, подібних до gateway, людиночитаний вивід показує підказки щодо очищення й попереджає, що в більшості налаштувань має працювати один gateway на машину.
|
||||
- Людиночитаний вивід містить розв’язаний шлях до файлового журналу, а також знімок шляхів/дійсності конфігурацій CLI і служби, щоб допомогти діагностувати дрейф профілю або каталогу стану.
|
||||
- В установках systemd на Linux перевірки дрейфу автентифікації служби зчитують значення `Environment=` і `EnvironmentFile=` з юніта (включно з `%h`, шляхами в лапках, кількома файлами та необов’язковими файлами з `-`).
|
||||
- Перевірки дрейфу розв’язують SecretRef `gateway.auth.token`, використовуючи об’єднане середовище виконання (спочатку середовище команди служби, потім резервно середовище процесу).
|
||||
- Якщо автентифікація токеном фактично не активна (явне `gateway.auth.mode` зі значенням `password`/`none`/`trusted-proxy` або невстановлений режим, де може перемогти пароль і жоден кандидат токена не може перемогти), перевірки дрейфу токена пропускають розв’язання токена з конфігурації.
|
||||
|
||||
### `gateway probe`
|
||||
|
||||
`gateway probe` — це команда «налагодити все». Вона завжди перевіряє:
|
||||
|
||||
- ваш налаштований remote gateway (якщо задано), і
|
||||
- localhost (loopback) **навіть якщо remote налаштовано**.
|
||||
- ваш налаштований віддалений gateway (якщо задано), і
|
||||
- localhost (loopback) **навіть якщо віддалений вузол налаштовано**.
|
||||
|
||||
Якщо ви передасте `--url`, ця явна ціль буде додана перед обома. У людському виводі
|
||||
цілі позначаються так:
|
||||
Якщо ви передасте `--url`, ця явна ціль додається перед обома. Людиночитаний вивід позначає
|
||||
цілі так:
|
||||
|
||||
- `URL (explicit)`
|
||||
- `Remote (configured)` або `Remote (configured, inactive)`
|
||||
- `Local loopback`
|
||||
|
||||
Якщо доступно кілька gateway, команда виведе їх усі. Підтримується робота з кількома gateway, коли ви використовуєте ізольовані профілі/порти (наприклад, rescue bot), але більшість установок усе ще використовують один gateway.
|
||||
Якщо доступні кілька gateway, буде виведено всі з них. Підтримка кількох gateway є можливою, коли ви використовуєте ізольовані профілі/порти (наприклад, rescue bot), але більшість установок усе ще запускає один gateway.
|
||||
|
||||
```bash
|
||||
openclaw gateway probe
|
||||
openclaw gateway probe --json
|
||||
```
|
||||
|
||||
Тлумачення:
|
||||
Інтерпретація:
|
||||
|
||||
- `Reachable: yes` означає, що принаймні одна ціль прийняла WebSocket-з’єднання.
|
||||
- `Capability: read-only|write-capable|admin-capable|pairing-pending|connect-only` показує, що саме перевірка змогла підтвердити щодо автентифікації. Це окремо від доступності.
|
||||
- `Read probe: ok` означає, що RPC-виклики з областю читання (`health`/`status`/`system-presence`/`config.get`) також виконалися успішно.
|
||||
- `Read probe: limited - missing scope: operator.read` означає, що з’єднання встановлено, але RPC із областю читання обмежено. Це повідомляється як **погіршена** доступність, а не повна відмова.
|
||||
- Код виходу є ненульовим лише тоді, коли жодна з перевірених цілей недоступна.
|
||||
- `Capability: read-only|write-capable|admin-capable|pairing-pending|connect-only` повідомляє, що саме перевірка змогла довести щодо автентифікації. Це окремо від досяжності.
|
||||
- `Read probe: ok` означає, що RPC-виклики деталей з областю читання (`health`/`status`/`system-presence`/`config.get`) також успішні.
|
||||
- `Read probe: limited - missing scope: operator.read` означає, що з’єднання встановлено успішно, але RPC із областю читання обмежене. Це повідомляється як **погіршена** досяжність, а не повна помилка.
|
||||
- Код виходу є ненульовим лише тоді, коли жодна перевірена ціль не є досяжною.
|
||||
|
||||
Примітки щодо JSON (`--json`):
|
||||
|
||||
- Верхній рівень:
|
||||
- `ok`: принаймні одна ціль доступна.
|
||||
- `degraded`: принаймні для однієї цілі детальний RPC був обмежений областю доступу.
|
||||
- `capability`: найвища можливість, виявлена серед доступних цілей (`read_only`, `write_capable`, `admin_capable`, `pairing_pending`, `connected_no_operator_scope` або `unknown`).
|
||||
- `primaryTargetId`: найкраща ціль, яку слід вважати активним переможцем, у такому порядку: явний URL, SSH-тунель, налаштований remote, потім локальний loopback.
|
||||
- `warnings[]`: записи попереджень best-effort з `code`, `message` і необов’язковим `targetIds`.
|
||||
- `network`: підказки URL для локального loopback/tailnet, похідні від поточної конфігурації та мережі хоста.
|
||||
- `discovery.timeoutMs` і `discovery.count`: фактичний бюджет виявлення/кількість результатів, використані для цього проходу перевірки.
|
||||
- `ok`: принаймні одна ціль є досяжною.
|
||||
- `degraded`: принаймні для однієї цілі RPC деталей було обмежене через область доступу.
|
||||
- `capability`: найкраща можливість, виявлена серед досяжних цілей (`read_only`, `write_capable`, `admin_capable`, `pairing_pending`, `connected_no_operator_scope` або `unknown`).
|
||||
- `primaryTargetId`: найкраща ціль, яку слід вважати активним переможцем, у такому порядку: явний URL, SSH-тунель, налаштований віддалений вузол, потім локальний loopback.
|
||||
- `warnings[]`: записи попереджень за принципом best-effort з полями `code`, `message` та необов’язковим `targetIds`.
|
||||
- `network`: підказки URL локального loopback/tailnet, виведені з поточної конфігурації та мережі хоста.
|
||||
- `discovery.timeoutMs` і `discovery.count`: фактичний бюджет/кількість результатів виявлення, використані для цього проходу перевірки.
|
||||
- Для кожної цілі (`targets[].connect`):
|
||||
- `ok`: доступність після підключення + класифікація погіршеного стану.
|
||||
- `rpcOk`: успішне виконання повного детального RPC.
|
||||
- `scopeLimited`: детальний RPC не вдався через відсутню область operator.
|
||||
- `ok`: досяжність після підключення + класифікація погіршеного стану.
|
||||
- `rpcOk`: успішне повне RPC деталей.
|
||||
- `scopeLimited`: RPC деталей не вдалося через відсутню область `operator`.
|
||||
- Для кожної цілі (`targets[].auth`):
|
||||
- `role`: роль автентифікації, повідомлена в `hello-ok`, коли доступна.
|
||||
- `scopes`: надані області доступу, повідомлені в `hello-ok`, коли доступні.
|
||||
- `capability`: класифікація можливостей автентифікації, показана для цієї цілі.
|
||||
- `role`: роль автентифікації, повідомлена в `hello-ok`, якщо доступна.
|
||||
- `scopes`: надані області доступу, повідомлені в `hello-ok`, якщо доступні.
|
||||
- `capability`: представлена класифікація можливостей автентифікації для цієї цілі.
|
||||
|
||||
Поширені коди попереджень:
|
||||
|
||||
- `ssh_tunnel_failed`: не вдалося налаштувати SSH-тунель; команда переключилася на прямі перевірки.
|
||||
- `multiple_gateways`: доступною була більш ніж одна ціль; це нетипово, якщо тільки ви свідомо не запускаєте ізольовані профілі, наприклад rescue bot.
|
||||
- `auth_secretref_unresolved`: не вдалося розв’язати налаштований auth SecretRef для цілі, яка завершилася невдачею.
|
||||
- `probe_scope_limited`: WebSocket-з’єднання встановлено успішно, але перевірку читання було обмежено через відсутність `operator.read`.
|
||||
- `ssh_tunnel_failed`: не вдалося налаштувати SSH-тунель; команда повернулася до прямих перевірок.
|
||||
- `multiple_gateways`: досяжною виявилася більше ніж одна ціль; це незвично, якщо тільки ви навмисно не запускаєте ізольовані профілі, наприклад rescue bot.
|
||||
- `auth_secretref_unresolved`: для цілі, що не пройшла перевірку, не вдалося розв’язати налаштований auth SecretRef.
|
||||
- `probe_scope_limited`: WebSocket-з’єднання встановлено успішно, але перевірка читання була обмежена через відсутність `operator.read`.
|
||||
|
||||
#### Remote через SSH (паритет із застосунком Mac)
|
||||
#### Віддалено через SSH (паритет із Mac app)
|
||||
|
||||
Режим macOS-застосунку «Remote over SSH» використовує локальне переадресування порту, тож віддалений gateway (який може бути прив’язаний лише до loopback) стає доступним за адресою `ws://127.0.0.1:<port>`.
|
||||
Режим macOS app «Remote over SSH» використовує локальне переадресування порту, тому віддалений gateway (який може бути прив’язаний лише до loopback) стає доступним за адресою `ws://127.0.0.1:<port>`.
|
||||
|
||||
Еквівалент у CLI:
|
||||
|
||||
@ -271,13 +272,13 @@ openclaw gateway probe --ssh user@gateway-host
|
||||
|
||||
Параметри:
|
||||
|
||||
- `--ssh <target>`: `user@host` або `user@host:port` (порт типово `22`).
|
||||
- `--ssh-identity <path>`: файл ідентифікації.
|
||||
- `--ssh <target>`: `user@host` або `user@host:port` (типовий порт — `22`).
|
||||
- `--ssh-identity <path>`: файл ідентичності.
|
||||
- `--ssh-auto`: вибрати перший виявлений хост gateway як SSH-ціль із розв’язаного
|
||||
ендпоінта виявлення (`local.` плюс налаштований wide-area domain, якщо є). Підказки
|
||||
ендпойнта виявлення (`local.` плюс налаштований широкозонний домен, якщо він є). Підказки
|
||||
лише з TXT ігноруються.
|
||||
|
||||
Конфігурація (необов’язкова, використовується як значення за замовчуванням):
|
||||
Конфігурація (необов’язкова, використовується як типові значення):
|
||||
|
||||
- `gateway.remote.sshTarget`
|
||||
- `gateway.remote.sshIdentity`
|
||||
@ -293,7 +294,7 @@ openclaw gateway call logs.tail --params '{"sinceMs": 60000}'
|
||||
|
||||
Параметри:
|
||||
|
||||
- `--params <json>`: рядок JSON-об’єкта для params (типово `{}`)
|
||||
- `--params <json>`: рядок JSON-об’єкта для параметрів (типово `{}`)
|
||||
- `--url <url>`
|
||||
- `--token <token>`
|
||||
- `--password <password>`
|
||||
@ -304,7 +305,7 @@ openclaw gateway call logs.tail --params '{"sinceMs": 60000}'
|
||||
Примітки:
|
||||
|
||||
- `--params` має бути коректним JSON.
|
||||
- `--expect-final` переважно призначений для RPC у стилі агентів, які транслюють проміжні події перед фінальним payload.
|
||||
- `--expect-final` головним чином призначений для RPC у стилі агентів, які перед фінальним корисним навантаженням передають проміжні події потоку.
|
||||
|
||||
## Керування службою Gateway
|
||||
|
||||
@ -325,31 +326,31 @@ openclaw gateway uninstall
|
||||
Примітки:
|
||||
|
||||
- `gateway install` підтримує `--port`, `--runtime`, `--token`, `--force`, `--json`.
|
||||
- Коли для автентифікації токеном потрібен токен і `gateway.auth.token` керується через SecretRef, `gateway install` перевіряє, що SecretRef можна розв’язати, але не зберігає розв’язаний токен у метаданих середовища служби.
|
||||
- Якщо для автентифікації токеном потрібен токен, а налаштований токен SecretRef не розв’язується, встановлення завершується в закритому режимі, замість збереження резервного відкритого тексту.
|
||||
- Для автентифікації паролем у `gateway run` віддавайте перевагу `OPENCLAW_GATEWAY_PASSWORD`, `--password-file` або `gateway.auth.password` на основі SecretRef замість вбудованого `--password`.
|
||||
- У режимі автентифікації, що виводиться автоматично, лише shell-змінна `OPENCLAW_GATEWAY_PASSWORD` не послаблює вимоги до токена під час install; використовуйте сталі налаштування (`gateway.auth.password` або config `env`) під час встановлення керованої служби.
|
||||
- Якщо налаштовано і `gateway.auth.token`, і `gateway.auth.password`, а `gateway.auth.mode` не задано, install блокується, доки режим не буде встановлено явно.
|
||||
- Команди життєвого циклу приймають `--json` для сценаріїв.
|
||||
- Коли автентифікація токеном потребує токена і `gateway.auth.token` керується через SecretRef, `gateway install` перевіряє, що SecretRef можна розв’язати, але не зберігає розв’язаний токен у метаданих середовища служби.
|
||||
- Якщо автентифікація токеном потребує токена, а налаштований SecretRef токена не розв’язується, інсталяція завершується в закритому режимі замість збереження резервного відкритого тексту.
|
||||
- Для автентифікації паролем у `gateway run` надавайте перевагу `OPENCLAW_GATEWAY_PASSWORD`, `--password-file` або `gateway.auth.password` з опорою на SecretRef замість вбудованого `--password`.
|
||||
- У режимі виведеної автентифікації лише shell-змінна `OPENCLAW_GATEWAY_PASSWORD` не послаблює вимоги до токена для інсталяції; використовуйте стійку конфігурацію (`gateway.auth.password` або config `env`) під час інсталяції керованої служби.
|
||||
- Якщо одночасно налаштовано `gateway.auth.token` і `gateway.auth.password`, а `gateway.auth.mode` не встановлено, інсталяція блокується, доки режим не буде задано явно.
|
||||
- Команди життєвого циклу приймають `--json` для сценаріїв автоматизації.
|
||||
|
||||
## Виявлення gateway (Bonjour)
|
||||
|
||||
`gateway discover` сканує маяки Gateway (`_openclaw-gw._tcp`).
|
||||
|
||||
- Multicast DNS-SD: `local.`
|
||||
- Unicast DNS-SD (Wide-Area Bonjour): виберіть домен (наприклад: `openclaw.internal.`) і налаштуйте split DNS + DNS-сервер; див. [/gateway/bonjour](/uk/gateway/bonjour)
|
||||
- Unicast DNS-SD (Wide-Area Bonjour): виберіть домен (приклад: `openclaw.internal.`) і налаштуйте split DNS + DNS-сервер; див. [/gateway/bonjour](/uk/gateway/bonjour)
|
||||
|
||||
Лише gateway з увімкненим виявленням Bonjour (типово ввімкнено) рекламують маяк.
|
||||
Лише gateway з увімкненим виявленням Bonjour (типово увімкнено) рекламують маяк.
|
||||
|
||||
Записи виявлення Wide-Area містять (TXT):
|
||||
Записи широкозонного виявлення містять (TXT):
|
||||
|
||||
- `role` (підказка про роль gateway)
|
||||
- `transport` (підказка про транспорт, наприклад `gateway`)
|
||||
- `role` (підказка ролі gateway)
|
||||
- `transport` (підказка транспорту, наприклад `gateway`)
|
||||
- `gatewayPort` (порт WebSocket, зазвичай `18789`)
|
||||
- `sshPort` (необов’язково; клієнти типово використовують `22` для SSH-цілей, якщо він відсутній)
|
||||
- `tailnetDns` (ім’я хоста MagicDNS, коли доступне)
|
||||
- `sshPort` (необов’язково; за його відсутності клієнти використовують типовий SSH-порт `22`)
|
||||
- `tailnetDns` (ім’я хоста MagicDNS, якщо доступне)
|
||||
- `gatewayTls` / `gatewayTlsSha256` (TLS увімкнено + відбиток сертифіката)
|
||||
- `cliPath` (підказка віддаленого встановлення, записана в зону wide-area)
|
||||
- `cliPath` (підказка віддаленої інсталяції, записана в широкозонну зону)
|
||||
|
||||
### `gateway discover`
|
||||
|
||||
@ -359,8 +360,8 @@ openclaw gateway discover
|
||||
|
||||
Параметри:
|
||||
|
||||
- `--timeout <ms>`: таймаут для кожної команди (browse/resolve); типово `2000`.
|
||||
- `--json`: машинозчитуваний вивід (також вимикає стилізацію/спінер).
|
||||
- `--timeout <ms>`: тайм-аут для кожної команди (browse/resolve); типово `2000`.
|
||||
- `--json`: вивід для машинної обробки (також вимикає стилізацію/спінер).
|
||||
|
||||
Приклади:
|
||||
|
||||
@ -371,9 +372,9 @@ openclaw gateway discover --json | jq '.beacons[].wsUrl'
|
||||
|
||||
Примітки:
|
||||
|
||||
- CLI сканує `local.` плюс налаштований wide-area domain, якщо його ввімкнено.
|
||||
- `wsUrl` у JSON-виводі виводиться з розв’язаного ендпоінта служби, а не з підказок
|
||||
лише з TXT, таких як `lanHost` або `tailnetDns`.
|
||||
- Для `local.` mDNS, `sshPort` і `cliPath` транслюються лише тоді, коли
|
||||
`discovery.mdns.mode` має значення `full`. Wide-area DNS-SD усе одно записує `cliPath`; `sshPort`
|
||||
там також лишається необов’язковим.
|
||||
- CLI сканує `local.` плюс налаштований широкозонний домен, якщо його увімкнено.
|
||||
- `wsUrl` у JSON-виводі виводиться з розв’язаного ендпойнта служби, а не з підказок
|
||||
лише TXT, таких як `lanHost` або `tailnetDns`.
|
||||
- У `local.` mDNS `sshPort` і `cliPath` транслюються лише тоді, коли
|
||||
`discovery.mdns.mode` має значення `full`. Широкозонний DNS-SD все одно записує `cliPath`; `sshPort`
|
||||
там також залишається необов’язковим.
|
||||
|
||||
135
docs/uk/gateway/diagnostics.md
Normal file
135
docs/uk/gateway/diagnostics.md
Normal file
@ -0,0 +1,135 @@
|
||||
---
|
||||
read_when:
|
||||
- Підготовка звіту про помилку або запиту до служби підтримки
|
||||
- Налагодження збоїв Gateway, перезапусків, нестачі пам’яті або надмірно великих корисних навантажень
|
||||
- Перегляд того, які діагностичні дані записуються або редагуються
|
||||
summary: Створюйте спільні діагностичні пакети Gateway для звітів про помилки
|
||||
title: Експорт діагностики
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T15:24:58Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: b535e9e3f12ee3eb67b46604b00fdb15e883c40d6be359415b51c5e1e1980234
|
||||
source_path: gateway/diagnostics.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Експорт діагностики
|
||||
|
||||
OpenClaw може створити локальний zip-файл діагностики, який безпечно додавати до звітів про помилки. Він поєднує санітизовані статус, стан, журнали, структуру конфігурації Gateway і нещодавні події стабільності без корисного навантаження.
|
||||
|
||||
## Швидкий старт
|
||||
|
||||
```bash
|
||||
openclaw gateway diagnostics export
|
||||
```
|
||||
|
||||
Команда виводить шлях до записаного zip-файла. Щоб вибрати шлях:
|
||||
|
||||
```bash
|
||||
openclaw gateway diagnostics export --output openclaw-diagnostics.zip
|
||||
```
|
||||
|
||||
Для автоматизації:
|
||||
|
||||
```bash
|
||||
openclaw gateway diagnostics export --json
|
||||
```
|
||||
|
||||
## Що містить експорт
|
||||
|
||||
Zip-файл містить:
|
||||
|
||||
- `summary.md`: зручний для читання огляд для служби підтримки.
|
||||
- `diagnostics.json`: зручне для машинного читання зведення конфігурації, журналів, статусу, стану та даних стабільності.
|
||||
- `manifest.json`: метадані експорту та список файлів.
|
||||
- Санітизовану структуру конфігурації та несекретні деталі конфігурації.
|
||||
- Санітизовані зведення журналів і нещодавні відредаговані рядки журналу.
|
||||
- Знімки статусу та стану Gateway, отримані в міру можливості.
|
||||
- `stability/latest.json`: найновіший збережений пакет стабільності, якщо доступний.
|
||||
|
||||
Експорт корисний навіть тоді, коли Gateway працює нестабільно. Якщо Gateway не може відповісти на запити статусу чи стану, локальні журнали, структура конфігурації та найновіший пакет стабільності все одно збираються, якщо доступні.
|
||||
|
||||
## Модель конфіденційності
|
||||
|
||||
Діагностика призначена для спільного використання. Експорт зберігає операційні дані, які допомагають у налагодженні, зокрема:
|
||||
|
||||
- назви підсистем, ідентифікатори plugin, ідентифікатори провайдерів, ідентифікатори каналів і налаштовані режими
|
||||
- коди статусу, тривалості, кількість байтів, стан черги та показники пам’яті
|
||||
- санітизовані метадані журналів і відредаговані операційні повідомлення
|
||||
- структуру конфігурації та несекретні налаштування функцій
|
||||
|
||||
Експорт пропускає або редагує:
|
||||
|
||||
- текст чатів, промпти, інструкції, тіла Webhook і результати інструментів
|
||||
- облікові дані, API-ключі, токени, cookie та секретні значення
|
||||
- необроблені тіла запитів або відповідей
|
||||
- ідентифікатори облікових записів, ідентифікатори повідомлень, необроблені ідентифікатори сесій, імена хостів і локальні імена користувачів
|
||||
|
||||
Коли повідомлення журналу схоже на текст користувача, чату, промпту або корисного навантаження інструмента, експорт зберігає лише факт пропуску повідомлення та кількість байтів.
|
||||
|
||||
## Реєстратор стабільності
|
||||
|
||||
Gateway типово записує обмежений потік даних стабільності без корисного навантаження, коли діагностику ввімкнено. Він призначений для операційних фактів, а не для вмісту.
|
||||
|
||||
Перегляньте активний реєстратор:
|
||||
|
||||
```bash
|
||||
openclaw gateway stability
|
||||
openclaw gateway stability --type payload.large
|
||||
openclaw gateway stability --json
|
||||
```
|
||||
|
||||
Перегляньте найновіший збережений пакет стабільності після аварійного завершення, тайм-ауту вимкнення або помилки запуску під час перезапуску:
|
||||
|
||||
```bash
|
||||
openclaw gateway stability --bundle latest
|
||||
```
|
||||
|
||||
Створіть zip-файл діагностики з найновішого збереженого пакета:
|
||||
|
||||
```bash
|
||||
openclaw gateway stability --bundle latest --export
|
||||
```
|
||||
|
||||
Збережені пакети розташовуються в `~/.openclaw/logs/stability/`, коли події існують.
|
||||
|
||||
## Корисні параметри
|
||||
|
||||
```bash
|
||||
openclaw gateway diagnostics export \
|
||||
--output openclaw-diagnostics.zip \
|
||||
--log-lines 5000 \
|
||||
--log-bytes 1000000
|
||||
```
|
||||
|
||||
- `--output <path>`: записати до конкретного шляху zip-файла.
|
||||
- `--log-lines <count>`: максимальна кількість санітизованих рядків журналу для включення.
|
||||
- `--log-bytes <bytes>`: максимальна кількість байтів журналу для аналізу.
|
||||
- `--url <url>`: URL WebSocket Gateway для знімків статусу та стану.
|
||||
- `--token <token>`: токен Gateway для знімків статусу та стану.
|
||||
- `--password <password>`: пароль Gateway для знімків статусу та стану.
|
||||
- `--timeout <ms>`: тайм-аут знімків статусу та стану.
|
||||
- `--no-stability-bundle`: пропустити пошук збереженого пакета стабільності.
|
||||
- `--json`: вивести метадані експорту у форматі, зручному для машинного читання.
|
||||
|
||||
## Вимкнення діагностики
|
||||
|
||||
Діагностику ввімкнено типово. Щоб вимкнути реєстратор стабільності та збір діагностичних подій:
|
||||
|
||||
```json5
|
||||
{
|
||||
diagnostics: {
|
||||
enabled: false,
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
Вимкнення діагностики зменшує деталізацію звітів про помилки. Це не впливає на звичайне журналювання Gateway.
|
||||
|
||||
## Пов’язана документація
|
||||
|
||||
- [Перевірки стану](/uk/gateway/health)
|
||||
- [CLI Gateway](/uk/cli/gateway#gateway-diagnostics-export)
|
||||
- [Протокол Gateway](/uk/gateway/protocol#system-and-identity)
|
||||
- [Журналювання](/uk/logging)
|
||||
@ -1,70 +1,65 @@
|
||||
---
|
||||
read_when:
|
||||
- Діагностика підключення каналу або стану Gateway
|
||||
- Розуміння CLI-команд перевірки стану та їхніх параметрів
|
||||
- Розуміння команд CLI для перевірки стану та їхніх параметрів
|
||||
summary: Команди перевірки стану та моніторинг стану Gateway
|
||||
title: Перевірки стану
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T00:49:06Z"
|
||||
generated_at: "2026-04-23T15:24:56Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 5ddcbe6fa913c5ba889f78cb417124c96b562cf8939410b1d6f66042dfb51a9f
|
||||
source_hash: 8af5631a83fc0747a996687c5b399289815658b6bb929950a4aa915cc7d47a1a
|
||||
source_path: gateway/health.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Перевірки стану (CLI)
|
||||
|
||||
Короткий посібник, як перевірити підключення каналу без здогадок.
|
||||
Короткий посібник, щоб перевірити підключення каналу без здогадок.
|
||||
|
||||
## Швидкі перевірки
|
||||
|
||||
- `openclaw status` — локальне зведення: доступність/режим Gateway, підказка щодо оновлення, вік автентифікації пов’язаного каналу, сесії та нещодавня активність.
|
||||
- `openclaw status` — локальне зведення: доступність/режим gateway, підказка щодо оновлення, вік автентифікації прив’язаного каналу, сесії та нещодавня активність.
|
||||
- `openclaw status --all` — повна локальна діагностика (лише читання, кольоровий вивід, безпечно вставляти для налагодження).
|
||||
- `openclaw status --deep` — запитує у запущеного Gateway живу перевірку стану (`health` з `probe:true`), зокрема перевірки каналів для кожного облікового запису, якщо це підтримується.
|
||||
- `openclaw health` — запитує у запущеного Gateway знімок його стану (лише WS; без прямих сокетів каналів із CLI).
|
||||
- `openclaw health --verbose` — примусово запускає живу перевірку стану та виводить деталі підключення Gateway.
|
||||
- `openclaw status --deep` — запитує в запущеного gateway живу перевірку стану (`health` з `probe:true`), зокрема поканальні перевірки для кожного акаунта, якщо це підтримується.
|
||||
- `openclaw health` — запитує в запущеного gateway його знімок стану (лише WS; без прямих сокетів каналу з CLI).
|
||||
- `openclaw health --verbose` — примусово запускає живу перевірку стану та виводить дані про підключення gateway.
|
||||
- `openclaw health --json` — машинозчитуваний вивід знімка стану.
|
||||
- Надішліть `/status` як окреме повідомлення у WhatsApp/WebChat, щоб отримати відповідь зі станом без виклику агента.
|
||||
- Надішліть `/status` окремим повідомленням у WhatsApp/WebChat, щоб отримати відповідь зі статусом без виклику агента.
|
||||
- Логи: переглядайте `/tmp/openclaw/openclaw-*.log` і фільтруйте за `web-heartbeat`, `web-reconnect`, `web-auto-reply`, `web-inbound`.
|
||||
|
||||
## Поглиблена діагностика
|
||||
|
||||
- Облікові дані на диску: `ls -l ~/.openclaw/credentials/whatsapp/<accountId>/creds.json` (`mtime` має бути нещодавнім).
|
||||
- Сховище сесій: `ls -l ~/.openclaw/agents/<agentId>/sessions/sessions.json` (шлях можна перевизначити в конфігурації). Кількість і нещодавні одержувачі відображаються через `status`.
|
||||
- Повторне пов’язування: `openclaw channels logout && openclaw channels login --verbose`, якщо в логах з’являються коди стану 409–515 або `loggedOut`. (Примітка: після прив’язки потік входу через QR автоматично перезапускається один раз для статусу 515.)
|
||||
- Діагностика увімкнена за замовчуванням. Gateway записує операційні факти, якщо не встановлено `diagnostics.enabled: false`. Події пам’яті записують кількість байтів RSS/heap, тиск порога та тиск зростання. Події надто великих навантажень записують, що було відхилено, обрізано або розбито на частини, а також розміри й ліміти, якщо вони доступні. Вони не записують текст повідомлення, вміст вкладень, тіло Webhook, необроблене тіло запиту чи відповіді, токени, cookies або секретні значення. Той самий Heartbeat запускає обмежений засіб запису стабільності, доступний через `openclaw gateway stability` або Gateway RPC `diagnostics.stability`. Фатальні завершення Gateway, тайм-аути завершення роботи та збої запуску під час перезапуску зберігають останній знімок цього записувача в `~/.openclaw/logs/stability/`, якщо події існують; перегляньте найновіший збережений пакет за допомогою `openclaw gateway stability --bundle latest`.
|
||||
- Для звітів про помилки виконайте `openclaw gateway diagnostics export` і додайте згенерований zip-файл. Експорт об’єднує підсумок у Markdown, найновіший пакет стабільності, очищені метадані логів, очищені знімки стану/здоров’я Gateway і форму конфігурації. Він призначений для поширення: текст чату, тіла Webhook, виводи інструментів, облікові дані, cookies, ідентифікатори облікових записів/повідомлень і секретні значення пропускаються або редагуються.
|
||||
- Процес повторного прив’язування: `openclaw channels logout && openclaw channels login --verbose`, коли в логах з’являються коди стану 409–515 або `loggedOut`. (Примітка: після прив’язування потік входу через QR автоматично перезапускається один раз для статусу 515.)
|
||||
- Діагностику ввімкнено за замовчуванням. Gateway записує операційні факти, якщо не встановлено `diagnostics.enabled: false`. Події пам’яті записують кількість байтів RSS/heap, тиск порога та тиск зростання. Події надто великих payload записують, що було відхилено, обрізано або розбито на частини, а також розміри й ліміти, якщо доступні. Вони не записують текст повідомлень, вміст вкладень, тіло Webhook, сире тіло запиту або відповіді, токени, cookie чи секретні значення. Той самий Heartbeat запускає обмежений записувач стабільності, доступний через `openclaw gateway stability` або Gateway RPC `diagnostics.stability`. Фатальні завершення Gateway, тайм-аути вимкнення та збої запуску під час перезапуску зберігають останній знімок записувача в `~/.openclaw/logs/stability/`, якщо події існують; перевірте найновіший збережений пакет через `openclaw gateway stability --bundle latest`.
|
||||
- Для звітів про помилки запустіть `openclaw gateway diagnostics export` і додайте згенерований zip-архів. Експорт об’єднує підсумок у Markdown, найновіший пакет стабільності, очищені метадані логів, очищені знімки статусу/стану Gateway і форму конфігурації. Його призначено для спільного використання: текст чату, тіла Webhook, результати інструментів, облікові дані, cookie, ідентифікатори акаунтів/повідомлень і секретні значення пропускаються або редагуються. Див. [Експорт діагностики](/uk/gateway/diagnostics).
|
||||
|
||||
## Конфігурація монітора стану
|
||||
## Конфігурація моніторингу стану
|
||||
|
||||
- `gateway.channelHealthCheckMinutes`: як часто Gateway перевіряє стан каналу. Типове значення: `5`. Встановіть `0`, щоб глобально вимкнути перезапуски монітора стану.
|
||||
- `gateway.channelStaleEventThresholdMinutes`: як довго підключений канал може залишатися неактивним, перш ніж монітор стану вважатиме його застарілим і перезапустить. Типове значення: `30`. Тримайте це значення більшим або рівним `gateway.channelHealthCheckMinutes`.
|
||||
- `gateway.channelMaxRestartsPerHour`: ковзне обмеження на одну годину для перезапусків монітором стану на канал/обліковий запис. Типове значення: `10`.
|
||||
- `channels.<provider>.healthMonitor.enabled`: вимикає перезапуски монітора стану для конкретного каналу, залишаючи глобальний моніторинг увімкненим.
|
||||
- `channels.<provider>.accounts.<accountId>.healthMonitor.enabled`: перевизначення для кількох облікових записів, яке має пріоритет над налаштуванням на рівні каналу.
|
||||
- Ці перевизначення на рівні каналу застосовуються до вбудованих моніторів каналів, які наразі їх підтримують: Discord, Google Chat, iMessage, Microsoft Teams, Signal, Slack, Telegram і WhatsApp.
|
||||
- `gateway.channelHealthCheckMinutes`: як часто gateway перевіряє стан каналу. За замовчуванням: `5`. Установіть `0`, щоб глобально вимкнути перезапуски монітора стану.
|
||||
- `gateway.channelStaleEventThresholdMinutes`: як довго підключений канал може залишатися неактивним, перш ніж монітор стану вважатиме його застарілим і перезапустить. За замовчуванням: `30`. Це значення має бути більшим або дорівнювати `gateway.channelHealthCheckMinutes`.
|
||||
- `gateway.channelMaxRestartsPerHour`: ковзне обмеження на одну годину для перезапусків монітором стану на канал/акаунт. За замовчуванням: `10`.
|
||||
- `channels.<provider>.healthMonitor.enabled`: вимкнути перезапуски монітора стану для конкретного каналу, залишивши глобальний моніторинг увімкненим.
|
||||
- `channels.<provider>.accounts.<accountId>.healthMonitor.enabled`: перевизначення для кількох акаунтів, яке має пріоритет над налаштуванням на рівні каналу.
|
||||
- Ці перевизначення для окремих каналів застосовуються до вбудованих моніторів каналів, які зараз їх підтримують: Discord, Google Chat, iMessage, Microsoft Teams, Signal, Slack, Telegram і WhatsApp.
|
||||
|
||||
## Коли щось не працює
|
||||
|
||||
- `logged out` або статус 409–515 → виконайте повторне пов’язування через `openclaw channels logout`, а потім `openclaw channels login`.
|
||||
- Gateway недоступний → запустіть його: `openclaw gateway --port 18789` (використайте `--force`, якщо порт зайнятий).
|
||||
- Немає вхідних повідомлень → переконайтеся, що пов’язаний телефон онлайн і відправника дозволено (`channels.whatsapp.allowFrom`); для групових чатів переконайтеся, що правила allowlist і згадок збігаються (`channels.whatsapp.groups`, `agents.list[].groupChat.mentionPatterns`).
|
||||
- `logged out` або статус 409–515 → переприв’яжіть через `openclaw channels logout`, а потім `openclaw channels login`.
|
||||
- Gateway недоступний → запустіть його: `openclaw gateway --port 18789` (використайте `--force`, якщо порт зайнято).
|
||||
- Немає вхідних повідомлень → переконайтеся, що прив’язаний телефон онлайн і відправника дозволено (`channels.whatsapp.allowFrom`); для групових чатів переконайтеся, що allowlist і правила згадок збігаються (`channels.whatsapp.groups`, `agents.list[].groupChat.mentionPatterns`).
|
||||
|
||||
## Окрема команда "health"
|
||||
|
||||
`openclaw health` запитує у запущеного Gateway знімок його стану (без прямих сокетів
|
||||
каналів із CLI). За замовчуванням вона може повертати свіжий кешований знімок Gateway; після цього
|
||||
Gateway оновлює цей кеш у фоновому режимі. `openclaw health --verbose` натомість примусово виконує
|
||||
живу перевірку. Команда повідомляє про пов’язані облікові дані/вік автентифікації, якщо доступно,
|
||||
зведення перевірок для кожного каналу, зведення сховища сесій і тривалість перевірки. Вона завершується з ненульовим кодом,
|
||||
якщо Gateway недоступний або перевірка не вдалася/перевищила час очікування.
|
||||
`openclaw health` запитує в запущеного gateway його знімок стану (без прямих сокетів каналу з CLI). За замовчуванням команда може повертати нещодавній кешований знімок gateway; після цього gateway оновлює цей кеш у фоновому режимі. `openclaw health --verbose` натомість примусово запускає живу перевірку. Команда показує прив’язані creds/вік автентифікації, якщо доступно, зведення перевірок для кожного каналу, зведення сховища сесій і тривалість перевірки. Вона завершується з ненульовим кодом, якщо gateway недоступний або перевірка завершується помилкою/тайм-аутом.
|
||||
|
||||
Параметри:
|
||||
|
||||
- `--json`: машинозчитуваний JSON-вивід
|
||||
- `--timeout <ms>`: перевизначає типовий тайм-аут перевірки 10 с
|
||||
- `--verbose`: примусово запускає живу перевірку й виводить деталі підключення Gateway
|
||||
- `--timeout <ms>`: перевизначити стандартний тайм-аут перевірки 10 с
|
||||
- `--verbose`: примусово запустити живу перевірку та вивести дані про підключення gateway
|
||||
- `--debug`: псевдонім для `--verbose`
|
||||
|
||||
Знімок стану містить: `ok` (boolean), `ts` (часова позначка), `durationMs` (час перевірки), стан для кожного каналу, доступність агента та зведення сховища сесій.
|
||||
|
||||
@ -1,32 +1,29 @@
|
||||
---
|
||||
read_when:
|
||||
- Ви хочете використовувати вбудований app-server harness Codex
|
||||
- Ви хочете використовувати комплектний каркас app-server Codex
|
||||
- Вам потрібні посилання на моделі Codex і приклади конфігурації
|
||||
- Ви хочете вимкнути резервний перехід на Pi для розгортань лише з Codex
|
||||
summary: Запускати ходи вбудованого агента OpenClaw через вбудований app-server harness Codex
|
||||
title: Harness Codex
|
||||
- Ви хочете вимкнути резервний перехід до Pi для розгортань лише з Codex
|
||||
summary: Запускайте вбудовані ходи агента OpenClaw через комплектний каркас app-server Codex
|
||||
title: Каркас Codex
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T07:26:06Z"
|
||||
generated_at: "2026-04-23T15:25:02Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 8172af40edb7d1f7388a606df1c8f776622ffd82b46245fb9fbd184fbf829356
|
||||
source_hash: 4537cdc043768f19cd097b4542dfb3447bf3342c7c300832e160b795263c2a52
|
||||
source_path: plugins/codex-harness.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Harness Codex
|
||||
# Каркас Codex
|
||||
|
||||
Вбудований plugin `codex` дає змогу OpenClaw виконувати ходи вбудованого агента через
|
||||
app-server Codex замість вбудованого harness Pi.
|
||||
Комплектний Plugin `codex` дає змогу OpenClaw запускати вбудовані ходи агента через app-server Codex замість вбудованого каркаса PI.
|
||||
|
||||
Використовуйте це, коли хочете, щоб Codex керував низькорівневою сесією агента: виявленням
|
||||
моделей, нативним відновленням thread, нативним Compaction і виконанням через app-server.
|
||||
OpenClaw, як і раніше, керує каналами чату, файлами сесій, вибором моделей, інструментами,
|
||||
підтвердженнями, доставкою медіа та видимим дзеркалом стенограми.
|
||||
Використовуйте це, коли хочете, щоб Codex керував низькорівневою сесією агента: виявленням моделей, нативним відновленням потоку, нативним Compaction і виконанням app-server.
|
||||
OpenClaw і далі керує каналами чату, файлами сесій, вибором моделі, інструментами,
|
||||
погодженнями, доставкою медіа й видимим дзеркалом транскрипту.
|
||||
|
||||
Нативні ходи Codex також дотримуються спільних хуків plugin, тому shims prompt, автоматизація
|
||||
з урахуванням Compaction, middleware інструментів і спостерігачі життєвого циклу залишаються
|
||||
узгодженими з harness Pi:
|
||||
Нативні ходи Codex також враховують спільні хуки Plugin, тому шими промптів,
|
||||
автоматизація з урахуванням Compaction, middleware інструментів і спостерігачі життєвого циклу залишаються узгодженими з каркасом PI:
|
||||
|
||||
- `before_prompt_build`
|
||||
- `before_compaction`, `after_compaction`
|
||||
@ -35,45 +32,42 @@ OpenClaw, як і раніше, керує каналами чату, файла
|
||||
- `before_message_write`
|
||||
- `agent_end`
|
||||
|
||||
Вбудовані plugins також можуть реєструвати фабрику розширення app-server Codex, щоб додавати
|
||||
асинхронне middleware `tool_result`.
|
||||
Комплектні plugins також можуть реєструвати фабрику розширення app-server Codex, щоб додавати асинхронне middleware `tool_result`.
|
||||
|
||||
Цей harness вимкнено за замовчуванням. Він вибирається лише тоді, коли plugin `codex`
|
||||
увімкнено і визначена модель є моделлю `codex/*`, або коли ви явно примусово задаєте
|
||||
`embeddedHarness.runtime: "codex"` чи `OPENCLAW_AGENT_RUNTIME=codex`.
|
||||
Якщо ви ніколи не налаштовуєте `codex/*`, наявні запускі Pi, OpenAI, Anthropic, Gemini, local
|
||||
Каркас вимкнений за замовчуванням. Він вибирається лише тоді, коли Plugin `codex`
|
||||
увімкнено й визначена модель є моделлю `codex/*`, або коли ви явно примусово задаєте `embeddedHarness.runtime: "codex"` чи `OPENCLAW_AGENT_RUNTIME=codex`.
|
||||
Якщо ви ніколи не налаштовуєте `codex/*`, наявні запуски PI, OpenAI, Anthropic, Gemini, local
|
||||
і custom-provider зберігають свою поточну поведінку.
|
||||
|
||||
## Виберіть правильний префікс моделі
|
||||
|
||||
OpenClaw має окремі маршрути для доступу у стилі OpenAI і Codex:
|
||||
OpenClaw має окремі маршрути для доступу у формі OpenAI і Codex:
|
||||
|
||||
| Посилання на модель | Шлях runtime | Коли використовувати |
|
||||
| --------------------- | ------------------------------------------- | ------------------------------------------------------------------------- |
|
||||
| `openai/gpt-5.4` | Провайдер OpenAI через інфраструктуру OpenClaw/Pi | Вам потрібен прямий доступ до OpenAI Platform API через `OPENAI_API_KEY`. |
|
||||
| `openai-codex/gpt-5.4` | Провайдер OAuth OpenAI Codex через Pi | Вам потрібен ChatGPT/Codex OAuth без harness app-server Codex. |
|
||||
| `codex/gpt-5.4` | Вбудований провайдер Codex плюс harness Codex | Вам потрібне нативне виконання через app-server Codex для ходу вбудованого агента. |
|
||||
| Посилання на модель | Шлях runtime | Використовуйте, коли |
|
||||
| --------------------- | ------------------------------------------- | ------------------------------------------------------------------------ |
|
||||
| `openai/gpt-5.4` | Провайдер OpenAI через інфраструктуру OpenClaw/PI | Вам потрібен прямий доступ до API платформи OpenAI з `OPENAI_API_KEY`. |
|
||||
| `openai-codex/gpt-5.4` | Провайдер OAuth OpenAI Codex через PI | Вам потрібен OAuth ChatGPT/Codex без каркаса app-server Codex. |
|
||||
| `codex/gpt-5.4` | Комплектний провайдер Codex плюс каркас Codex | Вам потрібне нативне виконання app-server Codex для вбудованого ходу агента. |
|
||||
|
||||
Harness Codex обробляє лише посилання на моделі `codex/*`. Наявні посилання `openai/*`,
|
||||
Каркас Codex обробляє лише посилання на моделі `codex/*`. Наявні посилання `openai/*`,
|
||||
`openai-codex/*`, Anthropic, Gemini, xAI, local і custom provider зберігають
|
||||
свої звичайні шляхи.
|
||||
|
||||
## Вимоги
|
||||
|
||||
- OpenClaw із доступним вбудованим plugin `codex`.
|
||||
- OpenClaw із доступним комплектним Plugin `codex`.
|
||||
- app-server Codex версії `0.118.0` або новішої.
|
||||
- Доступна автентифікація Codex для процесу app-server.
|
||||
- Автентифікація Codex, доступна для процесу app-server.
|
||||
|
||||
Plugin блокує handshake app-server старіших версій або без версії. Це гарантує, що
|
||||
OpenClaw працює на поверхні протоколу, з якою його було протестовано.
|
||||
Plugin блокує старіші або неверсіоновані handshake app-server. Це утримує
|
||||
OpenClaw у межах поверхні протоколу, з якою його було протестовано.
|
||||
|
||||
Для live- і Docker smoke-тестів автентифікація зазвичай надходить через `OPENAI_API_KEY`, а також,
|
||||
за потреби, через файли CLI Codex, як-от `~/.codex/auth.json` і
|
||||
`~/.codex/config.toml`. Використовуйте ті самі матеріали автентифікації, що й ваш локальний app-server Codex.
|
||||
Для live і Docker smoke-тестів автентифікація зазвичай надходить із `OPENAI_API_KEY`, а також, за потреби, з файлів CLI Codex, таких як `~/.codex/auth.json` і
|
||||
`~/.codex/config.toml`. Використовуйте ті самі автентифікаційні дані, які використовує ваш локальний app-server Codex.
|
||||
|
||||
## Мінімальна конфігурація
|
||||
|
||||
Використовуйте `codex/gpt-5.4`, увімкніть вбудований plugin і примусово задайте harness `codex`:
|
||||
Використовуйте `codex/gpt-5.4`, увімкніть комплектний Plugin і примусово задайте каркас `codex`:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -96,7 +90,7 @@ OpenClaw працює на поверхні протоколу, з якою йо
|
||||
}
|
||||
```
|
||||
|
||||
Якщо ваша конфігурація використовує `plugins.allow`, додайте туди також `codex`:
|
||||
Якщо у вашій конфігурації використовується `plugins.allow`, додайте туди також `codex`:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -111,14 +105,13 @@ OpenClaw працює на поверхні протоколу, з якою йо
|
||||
}
|
||||
```
|
||||
|
||||
Установлення `agents.defaults.model` або моделі агента у `codex/<model>` також
|
||||
автоматично вмикає вбудований plugin `codex`. Явний запис plugin усе одно
|
||||
корисний у спільних конфігураціях, оскільки робить намір розгортання очевидним.
|
||||
Установлення `agents.defaults.model` або моделі агента в `codex/<model>` також
|
||||
автоматично вмикає комплектний Plugin `codex`. Явний запис Plugin усе ще
|
||||
корисний у спільних конфігураціях, бо він чітко показує намір розгортання.
|
||||
|
||||
## Додати Codex без заміни інших моделей
|
||||
## Додайте Codex без заміни інших моделей
|
||||
|
||||
Залиште `runtime: "auto"`, якщо хочете використовувати Codex для моделей `codex/*`, а Pi — для
|
||||
всього іншого:
|
||||
Залишайте `runtime: "auto"`, якщо хочете використовувати Codex для моделей `codex/*`, а PI — для всього іншого:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -150,17 +143,16 @@ OpenClaw працює на поверхні протоколу, з якою йо
|
||||
}
|
||||
```
|
||||
|
||||
За такої форми:
|
||||
У такій конфігурації:
|
||||
|
||||
- `/model codex` або `/model codex/gpt-5.4` використовує harness app-server Codex.
|
||||
- `/model codex` або `/model codex/gpt-5.4` використовує каркас app-server Codex.
|
||||
- `/model gpt` або `/model openai/gpt-5.4` використовує шлях провайдера OpenAI.
|
||||
- `/model opus` використовує шлях провайдера Anthropic.
|
||||
- Якщо вибрано модель не Codex, Pi залишається compatibility harness.
|
||||
- Якщо вибрано не-Codex модель, PI залишається каркасом сумісності.
|
||||
|
||||
## Розгортання лише з Codex
|
||||
|
||||
Вимкніть резервний перехід на Pi, якщо потрібно гарантувати, що кожен хід вбудованого агента використовує
|
||||
harness Codex:
|
||||
Вимкніть резервний перехід до PI, якщо вам потрібно довести, що кожен вбудований хід агента використовує каркас Codex:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -176,7 +168,7 @@ harness Codex:
|
||||
}
|
||||
```
|
||||
|
||||
Перевизначення через середовище:
|
||||
Перевизначення через змінні середовища:
|
||||
|
||||
```bash
|
||||
OPENCLAW_AGENT_RUNTIME=codex \
|
||||
@ -184,13 +176,13 @@ OPENCLAW_AGENT_HARNESS_FALLBACK=none \
|
||||
openclaw gateway run
|
||||
```
|
||||
|
||||
Якщо резервний перехід вимкнено, OpenClaw завершується з помилкою на ранньому етапі, якщо plugin Codex вимкнено,
|
||||
потрібна модель не є посиланням `codex/*`, app-server надто старий або
|
||||
app-server не вдається запустити.
|
||||
Коли fallback вимкнено, OpenClaw завершується з помилкою на ранньому етапі, якщо Plugin Codex вимкнений,
|
||||
запитана модель не є посиланням `codex/*`, app-server надто старий або
|
||||
app-server не може запуститися.
|
||||
|
||||
## Codex для окремого агента
|
||||
|
||||
Ви можете зробити один агент лише Codex, залишивши для типового агента звичайний
|
||||
Ви можете зробити одного агента лише Codex, тоді як агент за замовчуванням зберігатиме звичайний
|
||||
автовибір:
|
||||
|
||||
```json5
|
||||
@ -223,13 +215,13 @@ app-server не вдається запустити.
|
||||
```
|
||||
|
||||
Використовуйте звичайні команди сесії, щоб перемикати агентів і моделі. `/new` створює нову
|
||||
сесію OpenClaw, а harness Codex створює або відновлює свій sidecar thread app-server
|
||||
за потреби. `/reset` очищає прив’язку сесії OpenClaw для цього thread.
|
||||
сесію OpenClaw, а каркас Codex створює або відновлює свій sidecar-потік app-server
|
||||
за потреби. `/reset` очищає прив’язку сесії OpenClaw для цього потоку.
|
||||
|
||||
## Виявлення моделей
|
||||
|
||||
За замовчуванням plugin Codex запитує в app-server доступні моделі. Якщо
|
||||
виявлення не вдається або перевищує час очікування, використовується вбудований резервний каталог:
|
||||
За замовчуванням Plugin Codex запитує в app-server список доступних моделей. Якщо
|
||||
виявлення завершується помилкою або перевищує час очікування, він використовує комплектний резервний каталог:
|
||||
|
||||
- `codex/gpt-5.4`
|
||||
- `codex/gpt-5.4-mini`
|
||||
@ -255,8 +247,8 @@ app-server не вдається запустити.
|
||||
}
|
||||
```
|
||||
|
||||
Вимкніть виявлення, якщо хочете, щоб під час запуску не виконувалося зондування Codex і використовувався
|
||||
лише резервний каталог:
|
||||
Вимкніть виявлення, якщо хочете, щоб під час запуску не виконувалася перевірка Codex і використовувався лише
|
||||
резервний каталог:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -277,19 +269,19 @@ app-server не вдається запустити.
|
||||
|
||||
## Підключення app-server і політика
|
||||
|
||||
За замовчуванням plugin локально запускає Codex так:
|
||||
За замовчуванням Plugin запускає Codex локально так:
|
||||
|
||||
```bash
|
||||
codex app-server --listen stdio://
|
||||
```
|
||||
|
||||
За замовчуванням OpenClaw запускає локальні сесії harness Codex у режимі YOLO:
|
||||
За замовчуванням OpenClaw запускає локальні сесії каркаса Codex у режимі YOLO:
|
||||
`approvalPolicy: "never"`, `approvalsReviewer: "user"` і
|
||||
`sandbox: "danger-full-access"`. Це позиція довіреного локального оператора, що використовується
|
||||
`sandbox: "danger-full-access"`. Це поза довіри для локального оператора, який використовується
|
||||
для автономних Heartbeat: Codex може використовувати shell і мережеві інструменти без
|
||||
зупинки на нативних запитах підтвердження, на які нікому відповісти.
|
||||
зупинки на нативних запитах на погодження, коли поруч немає нікого, хто міг би відповісти.
|
||||
|
||||
Щоб увімкнути підтвердження Codex із перевіркою Guardian, задайте `appServer.mode:
|
||||
Щоб увімкнути погодження Codex, перевірювані Guardian, задайте `appServer.mode:
|
||||
"guardian"`:
|
||||
|
||||
```json5
|
||||
@ -310,45 +302,11 @@ codex app-server --listen stdio://
|
||||
}
|
||||
```
|
||||
|
||||
Режим Guardian розгортається в:
|
||||
Guardian — це нативний рецензент погоджень Codex. Коли Codex просить вийти із sandbox, записати поза межами workspace або додати дозволи, як-от доступ до мережі, Codex спрямовує цей запит на погодження до субагента-рецензента замість запиту людині. Рецензент застосовує модель ризиків Codex і схвалює або відхиляє конкретний запит. Використовуйте Guardian, якщо вам потрібно більше захисних обмежень, ніж у режимі YOLO, але водночас потрібно, щоб агенти без нагляду могли просуватися далі.
|
||||
|
||||
```json5
|
||||
{
|
||||
plugins: {
|
||||
entries: {
|
||||
codex: {
|
||||
enabled: true,
|
||||
config: {
|
||||
appServer: {
|
||||
mode: "guardian",
|
||||
approvalPolicy: "on-request",
|
||||
approvalsReviewer: "guardian_subagent",
|
||||
sandbox: "workspace-write",
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
Пресет `guardian` розгортається до `approvalPolicy: "on-request"`, `approvalsReviewer: "guardian_subagent"` і `sandbox: "workspace-write"`. Окремі поля політики все одно мають пріоритет над `mode`, тож у складніших розгортаннях можна поєднувати пресет із явними виборами.
|
||||
|
||||
Guardian — це нативний рецензент підтверджень Codex. Коли Codex просить вийти за межі
|
||||
sandbox, записати за межі workspace або додати дозволи, як-от доступ до мережі,
|
||||
Codex спрямовує цей запит на підтвердження рецензенту-підагенту замість людини. Рецензент
|
||||
збирає контекст і застосовує модель оцінки ризику Codex, а потім
|
||||
підтверджує або відхиляє конкретний запит. Guardian корисний, коли вам потрібно більше
|
||||
запобіжників, ніж у режимі YOLO, але водночас потрібні автономні агенти й Heartbeat, щоб просуватися далі.
|
||||
|
||||
Docker live harness включає перевірку Guardian, якщо
|
||||
`OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1`. Він запускає harness Codex у
|
||||
режимі Guardian, перевіряє, що безпечну shell-команду з підвищенням привілеїв підтверджено, і
|
||||
перевіряє, що надсилання фальшивого секрету до недовіреного зовнішнього призначення відхилено,
|
||||
щоб агент повторно попросив явне підтвердження.
|
||||
|
||||
Окремі поля політики, як і раніше, мають вищий пріоритет за `mode`, тому просунуті розгортання можуть
|
||||
поєднувати цей пресет із явними значеннями.
|
||||
|
||||
Для вже запущеного app-server використовуйте транспорт WebSocket:
|
||||
Для app-server, який уже запущено, використовуйте транспорт WebSocket:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -372,22 +330,22 @@ Docker live harness включає перевірку Guardian, якщо
|
||||
|
||||
Підтримувані поля `appServer`:
|
||||
|
||||
| Поле | За замовчуванням | Значення |
|
||||
| ------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
|
||||
| `transport` | `"stdio"` | `"stdio"` запускає Codex; `"websocket"` підключається до `url`. |
|
||||
| `command` | `"codex"` | Виконуваний файл для транспорту stdio. |
|
||||
| `args` | `["app-server", "--listen", "stdio://"]` | Аргументи для транспорту stdio. |
|
||||
| `url` | не задано | URL WebSocket app-server. |
|
||||
| `authToken` | не задано | Bearer-токен для транспорту WebSocket. |
|
||||
| `headers` | `{}` | Додаткові заголовки WebSocket. |
|
||||
| `requestTimeoutMs` | `60000` | Час очікування для викликів control-plane app-server. |
|
||||
| `mode` | `"yolo"` | Пресет для режиму YOLO або виконання з перевіркою Guardian. |
|
||||
| `approvalPolicy` | `"never"` | Нативна політика підтвердження Codex, що передається під час запуску/відновлення thread і ходу. |
|
||||
| `sandbox` | `"danger-full-access"` | Нативний режим sandbox Codex, що передається під час запуску/відновлення thread. |
|
||||
| `approvalsReviewer` | `"user"` | Використовуйте `"guardian_subagent"`, щоб підтвердження перевіряв Codex Guardian. |
|
||||
| Поле | Значення за замовчуванням | Значення |
|
||||
| ------------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------- |
|
||||
| `transport` | `"stdio"` | `"stdio"` запускає Codex; `"websocket"` підключається до `url`. |
|
||||
| `command` | `"codex"` | Виконуваний файл для транспорту stdio. |
|
||||
| `args` | `["app-server", "--listen", "stdio://"]` | Аргументи для транспорту stdio. |
|
||||
| `url` | не задано | URL app-server WebSocket. |
|
||||
| `authToken` | не задано | Bearer-токен для транспорту WebSocket. |
|
||||
| `headers` | `{}` | Додаткові заголовки WebSocket. |
|
||||
| `requestTimeoutMs` | `60000` | Тайм-аут для викликів control plane app-server. |
|
||||
| `mode` | `"yolo"` | Пресет для виконання в режимі YOLO або з погодженнями Guardian. |
|
||||
| `approvalPolicy` | `"never"` | Нативна політика погодження Codex, що передається під час старту/відновлення потоку/ходу. |
|
||||
| `sandbox` | `"danger-full-access"` | Нативний режим sandbox Codex, що передається під час старту/відновлення потоку. |
|
||||
| `approvalsReviewer` | `"user"` | Використовуйте `"guardian_subagent"`, щоб дозволити Guardian Codex перевіряти запити. |
|
||||
| `serviceTier` | не задано | Необов’язковий рівень сервісу app-server Codex: `"fast"`, `"flex"` або `null`. Некоректні застарілі значення ігноруються. |
|
||||
|
||||
Старіші змінні середовища все ще працюють як резервні значення для локального тестування, коли
|
||||
Старіші змінні середовища все ще працюють як fallback для локального тестування, коли
|
||||
відповідне поле конфігурації не задано:
|
||||
|
||||
- `OPENCLAW_CODEX_APP_SERVER_BIN`
|
||||
@ -396,15 +354,14 @@ Docker live harness включає перевірку Guardian, якщо
|
||||
- `OPENCLAW_CODEX_APP_SERVER_APPROVAL_POLICY`
|
||||
- `OPENCLAW_CODEX_APP_SERVER_SANDBOX`
|
||||
|
||||
`OPENCLAW_CODEX_APP_SERVER_GUARDIAN=1` було видалено. Натомість використовуйте
|
||||
`OPENCLAW_CODEX_APP_SERVER_GUARDIAN=1` вилучено. Натомість використовуйте
|
||||
`plugins.entries.codex.config.appServer.mode: "guardian"` або
|
||||
`OPENCLAW_CODEX_APP_SERVER_MODE=guardian` для разового локального тестування. Конфігурація
|
||||
є кращим варіантом для відтворюваних розгортань, оскільки зберігає поведінку plugin в тому
|
||||
самому перевіреному файлі, що й решту налаштувань harness Codex.
|
||||
`OPENCLAW_CODEX_APP_SERVER_MODE=guardian` для разового локального тестування. Для
|
||||
відтворюваних розгортань бажано використовувати конфігурацію, оскільки вона зберігає поведінку Plugin в тому самому перевіреному файлі, що й решта налаштування каркаса Codex.
|
||||
|
||||
## Поширені рецепти
|
||||
|
||||
Локальний Codex із типовим транспортом stdio:
|
||||
Локальний Codex із транспортом stdio за замовчуванням:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -418,7 +375,7 @@ Docker live harness включає перевірку Guardian, якщо
|
||||
}
|
||||
```
|
||||
|
||||
Перевірка harness лише з Codex, із вимкненим резервним переходом на Pi:
|
||||
Перевірка каркаса лише з Codex, з вимкненим fallback до PI:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -435,7 +392,7 @@ Docker live harness включає перевірку Guardian, якщо
|
||||
}
|
||||
```
|
||||
|
||||
Підтвердження Codex із перевіркою Guardian:
|
||||
Погодження Codex, перевірювані Guardian:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -480,73 +437,73 @@ Docker live harness включає перевірку Guardian, якщо
|
||||
}
|
||||
```
|
||||
|
||||
Перемикання моделей залишається під керуванням OpenClaw. Коли сесію OpenClaw приєднано
|
||||
до наявного thread Codex, наступний хід знову надсилає до
|
||||
app-server поточні вибрані `codex/*` модель, провайдера, політику підтвердження, sandbox і рівень сервісу.
|
||||
Перемикання з `codex/gpt-5.4` на `codex/gpt-5.2` зберігає прив’язку thread, але просить Codex
|
||||
продовжити роботу з новою вибраною моделлю.
|
||||
Перемикання моделей і далі контролюється OpenClaw. Коли сесію OpenClaw прив’язано
|
||||
до наявного потоку Codex, наступний хід знову надсилає до
|
||||
app-server поточну вибрану модель `codex/*`, провайдера, політику погодження, sandbox і рівень сервісу.
|
||||
Перемикання з `codex/gpt-5.4` на `codex/gpt-5.2` зберігає
|
||||
прив’язку до потоку, але просить Codex продовжити з нововибраною моделлю.
|
||||
|
||||
## Команда Codex
|
||||
|
||||
Вбудований plugin реєструє `/codex` як авторизовану slash-команду. Вона є
|
||||
загальною і працює в будь-якому каналі, який підтримує текстові команди OpenClaw.
|
||||
Комплектний Plugin реєструє `/codex` як авторизовану slash-команду. Вона є
|
||||
загальною і працює в будь-якому каналі, що підтримує текстові команди OpenClaw.
|
||||
|
||||
Поширені форми:
|
||||
|
||||
- `/codex status` показує активне підключення до app-server, моделі, обліковий запис, ліміти швидкості, MCP-сервери та skills.
|
||||
- `/codex models` показує активні моделі app-server Codex.
|
||||
- `/codex threads [filter]` показує нещодавні threads Codex.
|
||||
- `/codex resume <thread-id>` приєднує поточну сесію OpenClaw до наявного thread Codex.
|
||||
- `/codex compact` просить app-server Codex виконати Compaction для приєднаного thread.
|
||||
- `/codex review` запускає нативний review Codex для приєднаного thread.
|
||||
- `/codex account` показує обліковий запис і стан лімітів швидкості.
|
||||
- `/codex mcp` показує стан MCP-серверів app-server Codex.
|
||||
- `/codex status` показує стан підключення до live app-server, моделі, обліковий запис, ліміти швидкості, сервери MCP і skills.
|
||||
- `/codex models` показує список моделей live app-server Codex.
|
||||
- `/codex threads [filter]` показує список нещодавніх потоків Codex.
|
||||
- `/codex resume <thread-id>` прив’язує поточну сесію OpenClaw до наявного потоку Codex.
|
||||
- `/codex compact` просить app-server Codex виконати Compaction для прив’язаного потоку.
|
||||
- `/codex review` запускає нативну перевірку Codex для прив’язаного потоку.
|
||||
- `/codex account` показує стан облікового запису та лімітів швидкості.
|
||||
- `/codex mcp` показує стан серверів MCP app-server Codex.
|
||||
- `/codex skills` показує skills app-server Codex.
|
||||
|
||||
`/codex resume` записує той самий sidecar-файл прив’язки, який harness використовує для
|
||||
звичайних ходів. У наступному повідомленні OpenClaw відновлює цей thread Codex, передає
|
||||
поточну вибрану модель OpenClaw `codex/*` до app-server і залишає
|
||||
розширену історію ввімкненою.
|
||||
`/codex resume` записує той самий sidecar-файл прив’язки, який каркас використовує для
|
||||
звичайних ходів. У наступному повідомленні OpenClaw відновлює цей потік Codex, передає
|
||||
поточну вибрану в OpenClaw модель `codex/*` до app-server і зберігає
|
||||
увімкнену розширену історію.
|
||||
|
||||
Поверхня команд вимагає app-server Codex версії `0.118.0` або новішої. Окремі
|
||||
Поверхня команд потребує app-server Codex версії `0.118.0` або новішої. Окремі
|
||||
методи керування позначаються як `unsupported by this Codex app-server`, якщо
|
||||
майбутній або custom app-server не надає цього JSON-RPC-методу.
|
||||
майбутній або кастомний app-server не надає цей метод JSON-RPC.
|
||||
|
||||
## Інструменти, медіа та Compaction
|
||||
|
||||
Harness Codex змінює лише низькорівневий виконавець вбудованого агента.
|
||||
Каркас Codex змінює лише низькорівневий виконавець вбудованого агента.
|
||||
|
||||
OpenClaw, як і раніше, формує список інструментів і отримує динамічні результати інструментів від
|
||||
harness. Текст, зображення, відео, музика, TTS, підтвердження та вивід інструментів обміну повідомленнями
|
||||
і далі проходять звичайним шляхом доставки OpenClaw.
|
||||
OpenClaw і далі формує список інструментів і отримує динамічні результати інструментів від
|
||||
каркаса. Текст, зображення, відео, музика, TTS, погодження та вихід інструментів обміну повідомленнями
|
||||
і далі проходять через звичайний шлях доставки OpenClaw.
|
||||
|
||||
Запити на підтвердження інструментів Codex MCP маршрутизуються через потік
|
||||
підтвердження plugin OpenClaw, коли Codex позначає `_meta.codex_approval_kind` як
|
||||
`"mcp_tool_call"`; інші запити на elicitation і запити довільного введення, як і раніше, закриваються з відмовою.
|
||||
Запити на погодження інструментів MCP Codex спрямовуються через потік погоджень Plugin OpenClaw,
|
||||
коли Codex позначає `_meta.codex_approval_kind` як
|
||||
`"mcp_tool_call"`; інші запити на elicitation і вільне введення все ще завершуються
|
||||
із закритою відмовою.
|
||||
|
||||
Коли вибрана модель використовує harness Codex, нативний Compaction thread
|
||||
делегується app-server Codex. OpenClaw зберігає дзеркало стенограми для історії каналів,
|
||||
пошуку, `/new`, `/reset` і майбутнього перемикання моделі або harness. Дзеркало
|
||||
включає prompt користувача, фінальний текст асистента та полегшені записи міркувань або плану Codex, якщо app-server їх надсилає. Наразі OpenClaw лише записує сигнали початку й завершення нативного Compaction. Він ще не показує
|
||||
людинозрозуміле зведення Compaction або придатний до аудиту список того, які записи Codex
|
||||
Коли вибрана модель використовує каркас Codex, нативний Compaction потоку
|
||||
делегується app-server Codex. OpenClaw зберігає дзеркало транскрипту для історії каналу,
|
||||
пошуку, `/new`, `/reset` і майбутнього перемикання моделі або каркаса. Це
|
||||
дзеркало містить запит користувача, фінальний текст асистента та спрощені записи міркувань або плану Codex, коли app-server їх надсилає. Наразі OpenClaw лише
|
||||
записує нативні сигнали початку й завершення Compaction. Він поки що не показує
|
||||
людинозрозумілий підсумок Compaction або аудитний список того, які записи Codex
|
||||
зберіг після Compaction.
|
||||
|
||||
Генерація медіа не потребує Pi. Генерація зображень, відео, музики, PDF, TTS і
|
||||
Генерація медіа не потребує PI. Генерація зображень, відео, музики, PDF, TTS і
|
||||
розуміння медіа й далі використовують відповідні налаштування провайдера/моделі, як-от
|
||||
`agents.defaults.imageGenerationModel`, `videoGenerationModel`, `pdfModel` і
|
||||
`messages.tts`.
|
||||
|
||||
## Усунення несправностей
|
||||
## Усунення проблем
|
||||
|
||||
**Codex не з’являється в `/model`:** увімкніть `plugins.entries.codex.enabled`,
|
||||
задайте посилання на модель `codex/*` або перевірте, чи `plugins.allow` не виключає `codex`.
|
||||
|
||||
**OpenClaw використовує Pi замість Codex:** якщо жоден harness Codex не обробляє запуск,
|
||||
OpenClaw може використовувати Pi як сумісний бекенд. Задайте
|
||||
**OpenClaw використовує PI замість Codex:** якщо жоден каркас Codex не обробляє цей запуск,
|
||||
OpenClaw може використовувати PI як backend сумісності. Задайте
|
||||
`embeddedHarness.runtime: "codex"`, щоб примусово вибрати Codex під час тестування, або
|
||||
`embeddedHarness.fallback: "none"`, щоб отримувати помилку, коли жоден harness plugin не підходить. Щойно
|
||||
буде вибрано app-server Codex, його помилки відображатимуться безпосередньо без додаткової
|
||||
конфігурації резервного переходу.
|
||||
`embeddedHarness.fallback: "none"`, щоб завершуватися з помилкою, коли жоден каркас Plugin не підходить. Щойно буде вибрано app-server Codex, його збої відображатимуться безпосередньо без додаткової конфігурації fallback.
|
||||
|
||||
**app-server відхиляється:** оновіть Codex, щоб handshake app-server
|
||||
повідомляв версію `0.118.0` або новішу.
|
||||
@ -554,15 +511,15 @@ OpenClaw може використовувати Pi як сумісний бек
|
||||
**Виявлення моделей повільне:** зменште `plugins.entries.codex.config.discovery.timeoutMs`
|
||||
або вимкніть виявлення.
|
||||
|
||||
**Транспорт WebSocket одразу завершується з помилкою:** перевірте `appServer.url`, `authToken`
|
||||
**Транспорт WebSocket одразу завершується помилкою:** перевірте `appServer.url`, `authToken`
|
||||
і те, що віддалений app-server використовує ту саму версію протоколу app-server Codex.
|
||||
|
||||
**Модель не Codex використовує Pi:** це очікувана поведінка. Harness Codex обробляє лише
|
||||
**Модель не-Codex використовує PI:** це очікувано. Каркас Codex обробляє лише
|
||||
посилання на моделі `codex/*`.
|
||||
|
||||
## Пов’язане
|
||||
## Пов’язані матеріали
|
||||
|
||||
- [Plugins harness агента](/uk/plugins/sdk-agent-harness)
|
||||
- [Plugins каркаса агента](/uk/plugins/sdk-agent-harness)
|
||||
- [Провайдери моделей](/uk/concepts/model-providers)
|
||||
- [Довідник із конфігурації](/uk/gateway/configuration-reference)
|
||||
- [Довідник конфігурації](/uk/gateway/configuration-reference)
|
||||
- [Тестування](/uk/help/testing#live-codex-app-server-harness-smoke)
|
||||
|
||||
@ -1,30 +1,30 @@
|
||||
---
|
||||
read_when:
|
||||
- Ви хочете, щоб агенти перетворювали виправлення або багаторазово використовувані процедури на Skills робочого простору
|
||||
- Ви налаштовуєте пам’ять процедурних Skills
|
||||
- Ви хочете, щоб агенти перетворювали виправлення або повторно використовувані процедури на навички робочого простору
|
||||
- Ви налаштовуєте процедурну пам’ять навичок
|
||||
- Ви налагоджуєте поведінку інструмента skill_workshop
|
||||
- Ви вирішуєте, чи вмикати автоматичне створення Skills
|
||||
summary: Експериментальне фіксування багаторазово використовуваних процедур як навичок робочого простору з перевіркою, схваленням, карантином і гарячим оновленням Skills
|
||||
title: Plugin Skill Workshop
|
||||
- Ви вирішуєте, чи вмикати автоматичне створення навичок
|
||||
summary: Експериментальне збереження повторно використовуваних процедур як навичок робочого простору з перевіркою, затвердженням, карантином і гарячим оновленням навичок
|
||||
title: Plugin майстерні навичок
|
||||
x-i18n:
|
||||
generated_at: "2026-04-21T20:38:18Z"
|
||||
generated_at: "2026-04-23T15:25:00Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 62dcb3e1a71999bfc39a95dc3d0984d3446c8a58f7d91a914dfc7256b4e79601
|
||||
source_hash: 12036df53a7a34450f5b64819dd608d37e74a0e49d9fbeef431b9b2b53950f03
|
||||
source_path: plugins/skill-workshop.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Plugin Skill Workshop
|
||||
# Plugin майстерні навичок
|
||||
|
||||
Skill Workshop — **експериментальний**. Він вимкнений за замовчуванням, його
|
||||
евристики фіксування та запити для рецензента можуть змінюватися між випусками, а автоматичні
|
||||
записи слід використовувати лише в довірених робочих просторах після попереднього перегляду
|
||||
виводу в режимі очікування схвалення.
|
||||
Майстерня навичок є **експериментальною**. Вона вимкнена за замовчуванням, її
|
||||
евристики захоплення та запити для рецензента можуть змінюватися між релізами, а
|
||||
автоматичні записи слід використовувати лише в довірених робочих просторах після
|
||||
попереднього перегляду виводу в режимі очікування.
|
||||
|
||||
Skill Workshop — це процедурна пам’ять для Skills робочого простору. Він дає змогу агенту перетворювати
|
||||
багаторазово використовувані робочі процеси, виправлення від користувача, важко здобуті рішення та повторювані проблеми
|
||||
на файли `SKILL.md` у каталозі:
|
||||
Майстерня навичок — це процедурна пам’ять для навичок робочого простору. Вона дає змогу агенту перетворювати
|
||||
повторно використовувані робочі процеси, виправлення від користувача, важко здобуті виправлення та повторювані помилки
|
||||
на файли `SKILL.md` у:
|
||||
|
||||
```text
|
||||
<workspace>/skills/<skill-name>/SKILL.md
|
||||
@ -32,42 +32,43 @@ Skill Workshop — це процедурна пам’ять для Skills ро
|
||||
|
||||
Це відрізняється від довготривалої пам’яті:
|
||||
|
||||
- **Memory** зберігає факти, уподобання, сутності та минулий контекст.
|
||||
- **Skills** зберігають багаторазово використовувані процедури, яких агент має дотримуватися в майбутніх завданнях.
|
||||
- **Skill Workshop** — це міст від корисного ходу до довговічної навички робочого простору
|
||||
із перевірками безпеки та необов’язковим схваленням.
|
||||
- **Пам’ять** зберігає факти, уподобання, сутності та минулий контекст.
|
||||
- **Навички** зберігають повторно використовувані процедури, яких агент має дотримуватися в майбутніх завданнях.
|
||||
- **Майстерня навичок** — це міст від корисного ходу до довговічної навички робочого простору
|
||||
із перевірками безпеки та необов’язковим затвердженням.
|
||||
|
||||
Skill Workshop корисний, коли агент вивчає процедуру, таку як:
|
||||
Майстерня навичок корисна, коли агент вивчає процедуру, наприклад:
|
||||
|
||||
- як перевіряти анімовані GIF-ресурси із зовнішніх джерел
|
||||
- як замінювати ресурси зі знімками екрана та перевіряти розміри
|
||||
- як перевіряти анімовані GIF-ресурси, отримані із зовнішніх джерел
|
||||
- як замінювати ресурси скриншотів і перевіряти розміри
|
||||
- як запускати специфічний для репозиторію QA-сценарій
|
||||
- як налагоджувати повторюваний збій provider
|
||||
- як налагоджувати повторюваний збій провайдера
|
||||
- як виправляти застарілу локальну примітку робочого процесу
|
||||
|
||||
Він не призначений для:
|
||||
Вона не призначена для:
|
||||
|
||||
- фактів на кшталт «користувачеві подобається синій»
|
||||
- фактів на кшталт «користувачу подобається синій»
|
||||
- широкої автобіографічної пам’яті
|
||||
- архівування сирих транскриптів
|
||||
- секретів, облікових даних або прихованого тексту запитів
|
||||
- секретів, облікових даних або прихованого тексту запиту
|
||||
- одноразових інструкцій, які не повторюватимуться
|
||||
|
||||
## Стан за замовчуванням
|
||||
|
||||
Вбудований plugin є **експериментальним** і **вимкненим за замовчуванням**, якщо його
|
||||
Вбудований Plugin є **експериментальним** і **вимкненим за замовчуванням**, якщо його
|
||||
явно не ввімкнено в `plugins.entries.skill-workshop`.
|
||||
|
||||
Маніфест plugin не встановлює `enabledByDefault: true`. Значення `enabled: true`
|
||||
за замовчуванням усередині схеми конфігурації plugin застосовується лише після того, як запис plugin
|
||||
уже було вибрано та завантажено.
|
||||
Маніфест Plugin не встановлює `enabledByDefault: true`. Значення `enabled: true`
|
||||
за замовчуванням у схемі конфігурації Plugin застосовується лише після того, як запис Plugin вже
|
||||
було вибрано й завантажено.
|
||||
|
||||
Експериментальний статус означає:
|
||||
Експериментальний означає:
|
||||
|
||||
- plugin достатньо підтримується для добровільного тестування та внутрішнього використання
|
||||
- сховище пропозицій, пороги рецензування та евристики фіксування можуть розвиватися
|
||||
- режим очікування схвалення є рекомендованим початковим режимом
|
||||
- автоматичне застосування призначене для довірених персональних/робочих середовищ, а не для спільних або ворожих середовищ із великою кількістю вхідних даних
|
||||
- Plugin достатньо підтримується для тестування та внутрішнього використання за принципом opt-in
|
||||
- сховище пропозицій, пороги рецензента та евристики захоплення можуть розвиватися
|
||||
- початковим рекомендованим режимом є очікування затвердження
|
||||
- автоматичне застосування призначене для довірених особистих/робочих налаштувань, а не для спільних або ворожих
|
||||
середовищ з інтенсивним зовнішнім введенням
|
||||
|
||||
## Увімкнення
|
||||
|
||||
@ -90,14 +91,14 @@ Skill Workshop корисний, коли агент вивчає процеду
|
||||
}
|
||||
```
|
||||
|
||||
За такої конфігурації:
|
||||
З цією конфігурацією:
|
||||
|
||||
- інструмент `skill_workshop` доступний
|
||||
- явні багаторазово використовувані виправлення ставляться в чергу як пропозиції, що очікують схвалення
|
||||
- проходи рецензента на основі порогів можуть пропонувати оновлення Skills
|
||||
- жоден файл Skill не записується, доки пропозицію, що очікує схвалення, не буде застосовано
|
||||
- доступний інструмент `skill_workshop`
|
||||
- явні повторно використовувані виправлення ставляться в чергу як пропозиції в очікуванні
|
||||
- проходи рецензента на основі порогів можуть пропонувати оновлення навичок
|
||||
- жоден файл навички не записується, доки пропозицію в очікуванні не буде застосовано
|
||||
|
||||
Використовуйте автоматичний запис лише в довірених робочих просторах:
|
||||
Використовуйте автоматичні записи лише в довірених робочих просторах:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -116,27 +117,27 @@ Skill Workshop корисний, коли агент вивчає процеду
|
||||
}
|
||||
```
|
||||
|
||||
`approvalPolicy: "auto"` усе одно використовує той самий сканер і шлях карантину. Він
|
||||
не застосовує пропозиції з критичними результатами перевірки.
|
||||
`approvalPolicy: "auto"` усе ще використовує той самий сканер і шлях карантину. Він
|
||||
не застосовує пропозиції з критичними виявленнями.
|
||||
|
||||
## Конфігурація
|
||||
|
||||
| Ключ | За замовчуванням | Діапазон / значення | Значення |
|
||||
| -------------------- | ---------------- | -------------------------------------------- | -------------------------------------------------------------------- |
|
||||
| `enabled` | `true` | boolean | Вмикає plugin після завантаження запису plugin. |
|
||||
| `autoCapture` | `true` | boolean | Вмикає фіксування/рецензування після ходу на успішних ходах агента. |
|
||||
| `approvalPolicy` | `"pending"` | `"pending"`, `"auto"` | Ставити пропозиції в чергу або автоматично записувати безпечні. |
|
||||
| `reviewMode` | `"hybrid"` | `"off"`, `"heuristic"`, `"llm"`, `"hybrid"` | Вибирає явне фіксування виправлень, LLM-рецензента, обидва варіанти або жоден. |
|
||||
| `reviewInterval` | `15` | `1..200` | Запускати рецензента після такої кількості успішних ходів. |
|
||||
| `reviewMinToolCalls` | `8` | `1..500` | Запускати рецензента після такої кількості зафіксованих викликів інструментів. |
|
||||
| `reviewTimeoutMs` | `45000` | `5000..180000` | Тайм-аут для вбудованого запуску рецензента. |
|
||||
| `maxPending` | `50` | `1..200` | Максимум пропозицій у стані очікування/карантину на робочий простір. |
|
||||
| `maxSkillBytes` | `40000` | `1024..200000` | Максимальний розмір згенерованого файлу Skill/допоміжного файла. |
|
||||
| Ключ | За замовчуванням | Діапазон / значення | Значення |
|
||||
| -------------------- | ---------------- | ------------------------------------------- | -------------------------------------------------------------------- |
|
||||
| `enabled` | `true` | boolean | Увімкнути Plugin після завантаження запису Plugin. |
|
||||
| `autoCapture` | `true` | boolean | Увімкнути захоплення/рецензування після ходу для успішних ходів агента. |
|
||||
| `approvalPolicy` | `"pending"` | `"pending"`, `"auto"` | Ставити пропозиції в чергу або автоматично записувати безпечні пропозиції. |
|
||||
| `reviewMode` | `"hybrid"` | `"off"`, `"heuristic"`, `"llm"`, `"hybrid"` | Вибрати явне захоплення виправлень, LLM-рецензента, обидва варіанти або жоден. |
|
||||
| `reviewInterval` | `15` | `1..200` | Запускати рецензента після такої кількості успішних ходів. |
|
||||
| `reviewMinToolCalls` | `8` | `1..500` | Запускати рецензента після такої кількості зафіксованих викликів інструментів. |
|
||||
| `reviewTimeoutMs` | `45000` | `5000..180000` | Тайм-аут для вбудованого запуску рецензента. |
|
||||
| `maxPending` | `50` | `1..200` | Максимум пропозицій в очікуванні/карантині, що зберігаються для одного робочого простору. |
|
||||
| `maxSkillBytes` | `40000` | `1024..200000` | Максимальний розмір згенерованого файлу навички/допоміжного файлу. |
|
||||
|
||||
Рекомендовані профілі:
|
||||
|
||||
```json5
|
||||
// Консервативний: лише явне використання інструмента, без автоматичного фіксування.
|
||||
// Консервативний: лише явне використання інструмента, без автоматичного захоплення.
|
||||
{
|
||||
autoCapture: false,
|
||||
approvalPolicy: "pending",
|
||||
@ -145,7 +146,7 @@ Skill Workshop корисний, коли агент вивчає процеду
|
||||
```
|
||||
|
||||
```json5
|
||||
// Спочатку рецензування: фіксувати автоматично, але вимагати схвалення.
|
||||
// Спочатку рецензування: захоплювати автоматично, але вимагати затвердження.
|
||||
{
|
||||
autoCapture: true,
|
||||
approvalPolicy: "pending",
|
||||
@ -163,7 +164,7 @@ Skill Workshop корисний, коли агент вивчає процеду
|
||||
```
|
||||
|
||||
```json5
|
||||
// Низька вартість: без виклику LLM-рецензента, лише явні фрази виправлень.
|
||||
// Низька вартість: без виклику LLM-рецензента, лише явні фрази виправлення.
|
||||
{
|
||||
autoCapture: true,
|
||||
approvalPolicy: "pending",
|
||||
@ -171,21 +172,21 @@ Skill Workshop корисний, коли агент вивчає процеду
|
||||
}
|
||||
```
|
||||
|
||||
## Шляхи фіксування
|
||||
## Шляхи захоплення
|
||||
|
||||
Skill Workshop має три шляхи фіксування.
|
||||
Майстерня навичок має три шляхи захоплення.
|
||||
|
||||
### Пропозиції інструмента
|
||||
### Підказки інструмента
|
||||
|
||||
Модель може напряму викликати `skill_workshop`, коли бачить багаторазово використовувану процедуру
|
||||
або коли користувач просить її зберегти/оновити Skill.
|
||||
Модель може викликати `skill_workshop` безпосередньо, коли бачить повторно використовувану процедуру
|
||||
або коли користувач просить її зберегти/оновити навичку.
|
||||
|
||||
Це найбільш явний шлях, і він працює навіть із `autoCapture: false`.
|
||||
Це найявніший шлях, і він працює навіть із `autoCapture: false`.
|
||||
|
||||
### Евристичне фіксування
|
||||
### Евристичне захоплення
|
||||
|
||||
Коли `autoCapture` увімкнено, а `reviewMode` має значення `heuristic` або `hybrid`, plugin
|
||||
сканує успішні ходи на наявність явних фраз виправлення від користувача:
|
||||
Коли `autoCapture` увімкнено, а `reviewMode` має значення `heuristic` або `hybrid`,
|
||||
Plugin сканує успішні ходи на наявність явних фраз виправлення від користувача:
|
||||
|
||||
- `next time`
|
||||
- `from now on`
|
||||
@ -195,28 +196,28 @@ Skill Workshop має три шляхи фіксування.
|
||||
- `prefer ... when/for/instead/use`
|
||||
- `when asked`
|
||||
|
||||
Евристика створює пропозицію на основі останньої відповідної інструкції користувача. Вона
|
||||
використовує підказки теми для вибору назв Skills для поширених робочих процесів:
|
||||
Евристика створює пропозицію з останньої відповідної інструкції користувача. Вона
|
||||
використовує тематичні підказки, щоб вибирати назви навичок для поширених робочих процесів:
|
||||
|
||||
- завдання з анімованими GIF -> `animated-gif-workflow`
|
||||
- завдання зі знімками екрана або ресурсами -> `screenshot-asset-workflow`
|
||||
- завдання зі скриншотами або ресурсами -> `screenshot-asset-workflow`
|
||||
- завдання QA або сценаріїв -> `qa-scenario-workflow`
|
||||
- завдання з GitHub PR -> `github-pr-workflow`
|
||||
- резервний варіант -> `learned-workflows`
|
||||
- завдання GitHub PR -> `github-pr-workflow`
|
||||
- запасний варіант -> `learned-workflows`
|
||||
|
||||
Евристичне фіксування навмисно вузьке. Воно призначене для чітких виправлень і
|
||||
повторюваних приміток щодо процесу, а не для загального підсумовування транскриптів.
|
||||
Евристичне захоплення навмисно вузьке. Воно призначене для чітких виправлень і
|
||||
повторюваних нотаток про процес, а не для загального підсумовування транскриптів.
|
||||
|
||||
### LLM-рецензент
|
||||
|
||||
Коли `autoCapture` увімкнено, а `reviewMode` має значення `llm` або `hybrid`, plugin
|
||||
Коли `autoCapture` увімкнено, а `reviewMode` має значення `llm` або `hybrid`, Plugin
|
||||
запускає компактного вбудованого рецензента після досягнення порогів.
|
||||
|
||||
Рецензент отримує:
|
||||
|
||||
- текст нещодавнього транскрипту, обмежений останніми 12 000 символів
|
||||
- до 12 наявних Skills робочого простору
|
||||
- до 2 000 символів із кожного наявного Skill
|
||||
- текст недавнього транскрипту, обмежений останніми 12 000 символів
|
||||
- до 12 наявних навичок робочого простору
|
||||
- до 2 000 символів із кожної наявної навички
|
||||
- інструкції лише у форматі JSON
|
||||
|
||||
Рецензент не має інструментів:
|
||||
@ -225,13 +226,9 @@ Skill Workshop має три шляхи фіксування.
|
||||
- `toolsAllow: []`
|
||||
- `disableMessageTool: true`
|
||||
|
||||
Він може повернути:
|
||||
Рецензент повертає або `{ "action": "none" }`, або одну пропозицію. Поле `action` має значення `create`, `append` або `replace` — надавайте перевагу `append`/`replace`, коли відповідна навичка вже існує; використовуйте `create` лише тоді, коли жодна наявна навичка не підходить.
|
||||
|
||||
```json
|
||||
{ "action": "none" }
|
||||
```
|
||||
|
||||
або одну пропозицію Skill:
|
||||
Приклад `create`:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -244,35 +241,7 @@ Skill Workshop має три шляхи фіксування.
|
||||
}
|
||||
```
|
||||
|
||||
Він також може додати до наявного Skill:
|
||||
|
||||
```json
|
||||
{
|
||||
"action": "append",
|
||||
"skillName": "qa-scenario-workflow",
|
||||
"title": "QA Scenario Workflow",
|
||||
"reason": "Animated media QA needs reusable checks",
|
||||
"description": "QA scenario workflow.",
|
||||
"section": "Workflow",
|
||||
"body": "- For animated GIF tasks, verify frame count and attribution before passing."
|
||||
}
|
||||
```
|
||||
|
||||
Або замінити точний текст у наявному Skill:
|
||||
|
||||
```json
|
||||
{
|
||||
"action": "replace",
|
||||
"skillName": "screenshot-asset-workflow",
|
||||
"title": "Screenshot Asset Workflow",
|
||||
"reason": "Old validation missed image optimization",
|
||||
"oldText": "- Replace the screenshot asset.",
|
||||
"newText": "- Replace the screenshot asset, preserve dimensions, optimize the PNG, and run the relevant validation gate."
|
||||
}
|
||||
```
|
||||
|
||||
Надавайте перевагу `append` або `replace`, коли вже існує відповідний Skill. Використовуйте `create`
|
||||
лише тоді, коли жоден наявний Skill не підходить.
|
||||
`append` додає `section` + `body`. `replace` замінює `oldText` на `newText` у вказаній навичці.
|
||||
|
||||
## Життєвий цикл пропозиції
|
||||
|
||||
@ -290,24 +259,24 @@ Skill Workshop має три шляхи фіксування.
|
||||
- `source`: `tool`, `agent_end` або `reviewer`
|
||||
- `status`
|
||||
- `change`
|
||||
- необов’язкові `scanFindings`
|
||||
- необов’язкова `quarantineReason`
|
||||
- необов’язковий `scanFindings`
|
||||
- необов’язковий `quarantineReason`
|
||||
|
||||
Стани пропозиції:
|
||||
|
||||
- `pending` — очікує схвалення
|
||||
- `applied` — записана в `<workspace>/skills`
|
||||
- `rejected` — відхилена оператором/моделлю
|
||||
- `quarantined` — заблокована через критичні результати сканування
|
||||
- `pending` — очікує затвердження
|
||||
- `applied` — записано до `<workspace>/skills`
|
||||
- `rejected` — відхилено оператором/моделлю
|
||||
- `quarantined` — заблоковано через критичні результати сканера
|
||||
|
||||
Стан зберігається окремо для кожного робочого простору в каталозі стану Gateway:
|
||||
Стан зберігається для кожного робочого простору в каталозі стану Gateway:
|
||||
|
||||
```text
|
||||
<stateDir>/skill-workshop/<workspace-hash>.json
|
||||
```
|
||||
|
||||
Пропозиції в стані очікування та карантину дедуплікуються за назвою Skill і payload
|
||||
зміни. Сховище зберігає найновіші пропозиції в стані очікування/карантину в межах
|
||||
Пропозиції в очікуванні та в карантині дедуплікуються за назвою навички та
|
||||
вмістом зміни. Сховище зберігає найновіші пропозиції в очікуванні/карантині в межах
|
||||
`maxPending`.
|
||||
|
||||
## Довідка з інструмента
|
||||
@ -340,7 +309,7 @@ skill_workshop
|
||||
|
||||
### `list_pending`
|
||||
|
||||
Показати пропозиції, що очікують схвалення.
|
||||
Показати пропозиції в очікуванні.
|
||||
|
||||
```json
|
||||
{ "action": "list_pending" }
|
||||
@ -367,7 +336,7 @@ skill_workshop
|
||||
{ "action": "list_quarantine" }
|
||||
```
|
||||
|
||||
Використовуйте це, коли здається, що автоматичне фіксування нічого не робить, а в журналах згадується
|
||||
Використовуйте це, коли автоматичне захоплення начебто нічого не робить, а в журналах згадується
|
||||
`skill-workshop: quarantined <skill>`.
|
||||
|
||||
### `inspect`
|
||||
@ -383,7 +352,7 @@ skill_workshop
|
||||
|
||||
### `suggest`
|
||||
|
||||
Створити пропозицію. Із `approvalPolicy: "pending"` це за замовчуванням ставить її в чергу.
|
||||
Створити пропозицію. За `approvalPolicy: "pending"` (типове значення) вона ставиться в чергу, а не записується.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -396,7 +365,8 @@ skill_workshop
|
||||
}
|
||||
```
|
||||
|
||||
Примусово виконати безпечний запис:
|
||||
<AccordionGroup>
|
||||
<Accordion title="Примусово виконати безпечний запис (apply: true)">
|
||||
|
||||
```json
|
||||
{
|
||||
@ -408,7 +378,9 @@ skill_workshop
|
||||
}
|
||||
```
|
||||
|
||||
Примусово залишити в стані очікування навіть за `approvalPolicy: "auto"`:
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Примусово залишити в очікуванні за auto policy (apply: false)">
|
||||
|
||||
```json
|
||||
{
|
||||
@ -420,7 +392,9 @@ skill_workshop
|
||||
}
|
||||
```
|
||||
|
||||
Додати до розділу:
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Додати до іменованого розділу">
|
||||
|
||||
```json
|
||||
{
|
||||
@ -432,7 +406,9 @@ skill_workshop
|
||||
}
|
||||
```
|
||||
|
||||
Замінити точний текст:
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Замінити точний текст">
|
||||
|
||||
```json
|
||||
{
|
||||
@ -443,9 +419,12 @@ skill_workshop
|
||||
}
|
||||
```
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
### `apply`
|
||||
|
||||
Застосувати пропозицію, що очікує схвалення.
|
||||
Застосувати пропозицію в очікуванні.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -454,7 +433,7 @@ skill_workshop
|
||||
}
|
||||
```
|
||||
|
||||
`apply` відмовляється застосовувати пропозиції в карантині:
|
||||
`apply` відхиляє пропозиції в карантині:
|
||||
|
||||
```text
|
||||
quarantined proposal cannot be applied
|
||||
@ -473,9 +452,9 @@ quarantined proposal cannot be applied
|
||||
|
||||
### `write_support_file`
|
||||
|
||||
Записати допоміжний файл усередині каталогу наявного або запропонованого Skill.
|
||||
Записати допоміжний файл у межах наявного або запропонованого каталогу навички.
|
||||
|
||||
Дозволені каталоги підтримки верхнього рівня:
|
||||
Дозволені кореневі каталоги допоміжних файлів:
|
||||
|
||||
- `references/`
|
||||
- `templates/`
|
||||
@ -493,65 +472,65 @@ quarantined proposal cannot be applied
|
||||
}
|
||||
```
|
||||
|
||||
Файли підтримки мають область робочого простору, проходять перевірку шляху, обмежуються за розміром байтів через
|
||||
Допоміжні файли прив’язані до робочого простору, перевіряються за шляхом, обмежуються за розміром байтів через
|
||||
`maxSkillBytes`, скануються та записуються атомарно.
|
||||
|
||||
## Запис Skills
|
||||
## Запис навичок
|
||||
|
||||
Skill Workshop записує лише в:
|
||||
Майстерня навичок записує лише в:
|
||||
|
||||
```text
|
||||
<workspace>/skills/<normalized-skill-name>/
|
||||
```
|
||||
|
||||
Назви Skills нормалізуються:
|
||||
Назви навичок нормалізуються:
|
||||
|
||||
- переводяться в нижній регістр
|
||||
- послідовності символів, що не належать до `[a-z0-9_-]`, замінюються на `-`
|
||||
- послідовності символів, що не відповідають `[a-z0-9_-]`, замінюються на `-`
|
||||
- початкові/кінцеві неалфавітно-цифрові символи видаляються
|
||||
- максимальна довжина — 80 символів
|
||||
- остаточна назва має відповідати шаблону `[a-z0-9][a-z0-9_-]{1,79}`
|
||||
- підсумкова назва має відповідати `[a-z0-9][a-z0-9_-]{1,79}`
|
||||
|
||||
Для `create`:
|
||||
|
||||
- якщо Skill не існує, Skill Workshop записує новий `SKILL.md`
|
||||
- якщо він уже існує, Skill Workshop додає вміст до `## Workflow`
|
||||
- якщо навичка не існує, Майстерня навичок записує новий `SKILL.md`
|
||||
- якщо вона вже існує, Майстерня навичок додає вміст до `## Workflow`
|
||||
|
||||
Для `append`:
|
||||
|
||||
- якщо Skill існує, Skill Workshop додає вміст до запитаного розділу
|
||||
- якщо його не існує, Skill Workshop створює мінімальний Skill, а потім додає вміст
|
||||
- якщо навичка існує, Майстерня навичок додає вміст до запитаного розділу
|
||||
- якщо її не існує, Майстерня навичок створює мінімальну навичку, а потім додає вміст
|
||||
|
||||
Для `replace`:
|
||||
|
||||
- Skill уже має існувати
|
||||
- `oldText` має бути присутнім у точному вигляді
|
||||
- навичка вже має існувати
|
||||
- `oldText` має бути наявним у точному вигляді
|
||||
- замінюється лише перший точний збіг
|
||||
|
||||
Усі записи є атомарними та негайно оновлюють знімок Skills у пам’яті, тому
|
||||
новий або оновлений Skill може стати видимим без перезапуску Gateway.
|
||||
Усі записи є атомарними й негайно оновлюють знімок навичок у пам’яті, тож
|
||||
нова або оновлена навичка може стати видимою без перезапуску Gateway.
|
||||
|
||||
## Модель безпеки
|
||||
|
||||
Skill Workshop має сканер безпеки для згенерованого вмісту `SKILL.md` і файлів
|
||||
підтримки.
|
||||
Майстерня навичок має сканер безпеки для згенерованого вмісту `SKILL.md` і допоміжних
|
||||
файлів.
|
||||
|
||||
Критичні результати переводять пропозиції в карантин:
|
||||
Критичні виявлення переводять пропозиції в карантин:
|
||||
|
||||
| Ідентифікатор правила | Блокує вміст, який... |
|
||||
| Rule id | Блокує вміст, який... |
|
||||
| -------------------------------------- | -------------------------------------------------------------------- |
|
||||
| `prompt-injection-ignore-instructions` | наказує агенту ігнорувати попередні/вищі інструкції |
|
||||
| `prompt-injection-system` | посилається на системні запити, повідомлення розробника або приховані інструкції |
|
||||
| `prompt-injection-tool` | заохочує обходити дозвіл/схвалення інструмента |
|
||||
| `prompt-injection-tool` | заохочує обходити дозволи/затвердження для інструментів |
|
||||
| `shell-pipe-to-shell` | містить `curl`/`wget`, передані через pipe у `sh`, `bash` або `zsh` |
|
||||
| `secret-exfiltration` | виглядає як надсилання даних env/process env мережею |
|
||||
| `secret-exfiltration` | схоже на надсилання даних env/process env через мережу |
|
||||
|
||||
Попереджувальні результати зберігаються, але самі по собі не блокують:
|
||||
Попереджувальні виявлення зберігаються, але самі по собі не блокують:
|
||||
|
||||
| Ідентифікатор правила | Попереджає про... |
|
||||
| --------------------- | --------------------------------- |
|
||||
| `destructive-delete` | широкі команди у стилі `rm -rf` |
|
||||
| `unsafe-permissions` | використання дозволів у стилі `chmod 777` |
|
||||
| Rule id | Попереджає про... |
|
||||
| -------------------- | ------------------------------------ |
|
||||
| `destructive-delete` | широкі команди у стилі `rm -rf` |
|
||||
| `unsafe-permissions` | використання дозволів у стилі `chmod 777` |
|
||||
|
||||
Пропозиції в карантині:
|
||||
|
||||
@ -560,91 +539,91 @@ Skill Workshop має сканер безпеки для згенеровано
|
||||
- відображаються в `list_quarantine`
|
||||
- не можуть бути застосовані через `apply`
|
||||
|
||||
Щоб відновитися після пропозиції в карантині, створіть нову безпечну пропозицію без
|
||||
небезпечного вмісту. Не редагуйте JSON сховища вручну.
|
||||
Щоб відновитися після пропозиції в карантині, створіть нову безпечну пропозицію, з якої
|
||||
видалено небезпечний вміст. Не редагуйте JSON сховища вручну.
|
||||
|
||||
## Рекомендації щодо запитів
|
||||
|
||||
Коли ввімкнений, Skill Workshop додає короткий розділ запиту, який інструктує агента
|
||||
Коли Майстерню навичок увімкнено, вона додає короткий розділ запиту, який підказує агенту
|
||||
використовувати `skill_workshop` для довговічної процедурної пам’яті.
|
||||
|
||||
Рекомендації наголошують на:
|
||||
У рекомендаціях наголошується на такому:
|
||||
|
||||
- процедурах, а не фактах/уподобаннях
|
||||
- виправленнях від користувача
|
||||
- неочевидних успішних процедурах
|
||||
- повторюваних проблемах
|
||||
- виправленні застарілих/надто коротких/неправильних Skills через append/replace
|
||||
- збереженні багаторазово використовуваної процедури після довгих циклів інструментів або складних виправлень
|
||||
- короткому наказовому тексті Skill
|
||||
- відсутності дампів транскриптів
|
||||
- процедури, а не факти/уподобання
|
||||
- виправлення від користувача
|
||||
- неочевидні успішні процедури
|
||||
- повторювані помилки
|
||||
- виправлення застарілих/тонких/неправильних навичок через append/replace
|
||||
- збереження повторно використовуваної процедури після довгих циклів інструментів або складних виправлень
|
||||
- короткий наказовий текст навички
|
||||
- без вивантаження транскриптів
|
||||
|
||||
Текст режиму запису змінюється залежно від `approvalPolicy`:
|
||||
|
||||
- режим pending: ставити пропозиції в чергу; застосовувати лише після явного схвалення
|
||||
- режим auto: застосовувати безпечні оновлення Skills робочого простору, коли вони явно багаторазово використовувані
|
||||
- режим pending: ставити пропозиції в чергу; застосовувати лише після явного затвердження
|
||||
- режим auto: застосовувати безпечні оновлення навичок робочого простору, коли вони явно придатні для повторного використання
|
||||
|
||||
## Вартість і поведінка під час виконання
|
||||
|
||||
Евристичне фіксування не викликає модель.
|
||||
Евристичне захоплення не викликає модель.
|
||||
|
||||
LLM-рецензування використовує вбудований запуск на активній/стандартній моделі агента. Воно
|
||||
залежить від порогів, тому за замовчуванням не запускається на кожному ході.
|
||||
LLM-рецензування використовує вбудований запуск на активній/типовій моделі агента. Воно
|
||||
працює на основі порогів, тому за замовчуванням не запускається на кожному ході.
|
||||
|
||||
Рецензент:
|
||||
|
||||
- використовує той самий налаштований контекст provider/model, коли він доступний
|
||||
- інакше повертається до стандартних значень агента під час виконання
|
||||
- використовує той самий налаштований контекст провайдера/моделі, коли це доступно
|
||||
- інакше використовує типові значення агента під час виконання
|
||||
- має `reviewTimeoutMs`
|
||||
- використовує легкий bootstrap-контекст
|
||||
- використовує легкий початковий контекст
|
||||
- не має інструментів
|
||||
- нічого не записує напряму
|
||||
- може лише створити пропозицію, яка проходить звичайний сканер та
|
||||
шлях схвалення/карантину
|
||||
- нічого не записує безпосередньо
|
||||
- може лише створити пропозицію, яка проходить через звичайний сканер і
|
||||
шлях затвердження/карантину
|
||||
|
||||
Якщо рецензент завершується помилкою, перевищує час очікування або повертає недійсний JSON, plugin записує
|
||||
попереджувальне/налагоджувальне повідомлення в журнал і пропускає цей прохід рецензування.
|
||||
Якщо рецензент завершується з помилкою, перевищує час очікування або повертає невалідний JSON, Plugin записує
|
||||
попередження/повідомлення для налагодження та пропускає цей прохід рецензування.
|
||||
|
||||
## Типові шаблони використання
|
||||
## Робочі шаблони
|
||||
|
||||
Використовуйте Skill Workshop, коли користувач каже:
|
||||
Використовуйте Майстерню навичок, коли користувач каже:
|
||||
|
||||
- «наступного разу роби X»
|
||||
- «відтепер надавай перевагу Y»
|
||||
- «відтепер віддавай перевагу Y»
|
||||
- «обов’язково перевіряй Z»
|
||||
- «збережи це як робочий процес»
|
||||
- «це зайняло багато часу; запам’ятай процес»
|
||||
- «онови локальний Skill для цього»
|
||||
- «це зайняло певний час; запам’ятай процес»
|
||||
- «онови локальну навичку для цього»
|
||||
|
||||
Хороший текст Skill:
|
||||
Хороший текст навички:
|
||||
|
||||
```markdown
|
||||
## Workflow
|
||||
|
||||
- Перевірте, що URL GIF веде до `image/gif`.
|
||||
- Підтвердьте, що файл має кілька кадрів.
|
||||
- Зафіксуйте URL джерела, ліцензію та атрибуцію.
|
||||
- Переконайтеся, що URL GIF повертає `image/gif`.
|
||||
- Підтвердьте, що файл містить кілька кадрів.
|
||||
- Запишіть URL джерела, ліцензію та атрибуцію.
|
||||
- Збережіть локальну копію, якщо ресурс постачатиметься разом із продуктом.
|
||||
- Перевірте, що локальний ресурс відображається в цільовому UI, перш ніж давати остаточну відповідь.
|
||||
- Перед фінальною відповіддю переконайтеся, що локальний ресурс відображається в цільовому UI.
|
||||
```
|
||||
|
||||
Поганий текст Skill:
|
||||
Поганий текст навички:
|
||||
|
||||
```markdown
|
||||
The user asked about a GIF and I searched two websites. Then one was blocked by
|
||||
Cloudflare. The final answer said to check attribution.
|
||||
Користувач запитав про GIF, і я шукав на двох вебсайтах. Потім один був заблокований
|
||||
Cloudflare. У фінальній відповіді було сказано перевірити атрибуцію.
|
||||
```
|
||||
|
||||
Причини, чому погану версію не слід зберігати:
|
||||
|
||||
- має форму транскрипту
|
||||
- не є наказовою
|
||||
- містить шумні одноразові подробиці
|
||||
- не пояснює наступному агенту, що робити
|
||||
- містить шумні одноразові деталі
|
||||
- не підказує наступному агенту, що робити
|
||||
|
||||
## Налагодження
|
||||
|
||||
Перевірте, чи завантажено plugin:
|
||||
Перевірте, чи завантажено Plugin:
|
||||
|
||||
```bash
|
||||
openclaw plugins list --enabled
|
||||
@ -656,7 +635,7 @@ openclaw plugins list --enabled
|
||||
{ "action": "status" }
|
||||
```
|
||||
|
||||
Перегляньте пропозиції, що очікують схвалення:
|
||||
Перегляньте пропозиції в очікуванні:
|
||||
|
||||
```json
|
||||
{ "action": "list_pending" }
|
||||
@ -670,15 +649,15 @@ openclaw plugins list --enabled
|
||||
|
||||
Поширені симптоми:
|
||||
|
||||
| Симптом | Імовірна причина | Перевірка |
|
||||
| ------------------------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------- |
|
||||
| Інструмент недоступний | Запис plugin не ввімкнений | `plugins.entries.skill-workshop.enabled` і `openclaw plugins list` |
|
||||
| Автоматична пропозиція не з’являється | `autoCapture: false`, `reviewMode: "off"` або пороги не досягнуто | Конфігурація, стан пропозицій, журнали Gateway |
|
||||
| Евристика не зафіксувала | Формулювання користувача не відповідало шаблонам виправлень | Використайте явний `skill_workshop.suggest` або ввімкніть LLM-рецензента |
|
||||
| Рецензент не створив пропозицію | Рецензент повернув `none`, недійсний JSON або перевищив час очікування | Журнали Gateway, `reviewTimeoutMs`, пороги |
|
||||
| Пропозиція не застосовується | `approvalPolicy: "pending"` | `list_pending`, потім `apply` |
|
||||
| Пропозиція зникла з pending | Було повторно використано дублікат пропозиції, спрацювало обрізання max pending або її застосовано/відхилено/переведено в карантин | `status`, `list_pending` з фільтрами status, `list_quarantine` |
|
||||
| Файл Skill існує, але модель його пропускає | Знімок Skills не оновився або gating Skills виключає його | стан `openclaw skills` і придатність Skill робочого простору |
|
||||
| Симптом | Імовірна причина | Перевірка |
|
||||
| ------------------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------- |
|
||||
| Інструмент недоступний | Запис Plugin не ввімкнено | `plugins.entries.skill-workshop.enabled` і `openclaw plugins list` |
|
||||
| Автоматична пропозиція не з’являється | `autoCapture: false`, `reviewMode: "off"` або пороги не досягнуто | Конфігурація, стан пропозицій, журнали Gateway |
|
||||
| Евристика не спрацювала | Формулювання користувача не відповідало шаблонам виправлень | Використайте явний `skill_workshop.suggest` або ввімкніть LLM-рецензента |
|
||||
| Рецензент не створив пропозицію | Рецензент повернув `none`, невалідний JSON або перевищив час очікування | Журнали Gateway, `reviewTimeoutMs`, пороги |
|
||||
| Пропозиція не застосовується | `approvalPolicy: "pending"` | `list_pending`, потім `apply` |
|
||||
| Пропозиція зникла з очікування | Було повторно використано дублікат пропозиції, спрацювало обрізання за max pending або її було застосовано/відхилено/переведено в карантин | `status`, `list_pending` з фільтрами стану, `list_quarantine` |
|
||||
| Файл навички існує, але модель його пропускає | Знімок навичок не оновився або обмеження навичок його виключають | стан `openclaw skills` і придатність навички робочого простору |
|
||||
|
||||
Відповідні журнали:
|
||||
|
||||
@ -691,7 +670,7 @@ openclaw plugins list --enabled
|
||||
|
||||
## QA-сценарії
|
||||
|
||||
QA-сценарії з прив’язкою до репозиторію:
|
||||
QA-сценарії з підтримкою репозиторію:
|
||||
|
||||
- `qa/scenarios/plugins/skill-workshop-animated-gif-autocreate.md`
|
||||
- `qa/scenarios/plugins/skill-workshop-pending-approval.md`
|
||||
@ -714,24 +693,24 @@ pnpm openclaw qa suite \
|
||||
--concurrency 1
|
||||
```
|
||||
|
||||
Сценарій рецензента навмисно винесений окремо, оскільки він вмикає
|
||||
`reviewMode: "llm"` і перевіряє вбудований прохід рецензента.
|
||||
Сценарій рецензента навмисно винесено окремо, оскільки він вмикає
|
||||
`reviewMode: "llm"` і перевіряє прохід вбудованого рецензента.
|
||||
|
||||
## Коли не слід вмикати Auto Apply
|
||||
## Коли не слід вмикати auto apply
|
||||
|
||||
Уникайте `approvalPolicy: "auto"`, коли:
|
||||
|
||||
- робочий простір містить чутливі процедури
|
||||
- агент працює з недовіреним вхідним вмістом
|
||||
- Skills спільно використовуються широкою командою
|
||||
- агент працює з недовіреним введенням
|
||||
- навички використовує широка команда
|
||||
- ви все ще налаштовуєте запити або правила сканера
|
||||
- модель часто обробляє ворожий вміст із web/email
|
||||
- модель часто обробляє ворожий вміст із вебу/електронної пошти
|
||||
|
||||
Спочатку використовуйте режим pending. Перемикайтеся на режим auto лише після перегляду того, які
|
||||
Skills агент пропонує в цьому робочому просторі.
|
||||
Спочатку використовуйте режим pending. Перемикайтеся на режим auto лише після перегляду того,
|
||||
які навички агент пропонує в цьому робочому просторі.
|
||||
|
||||
## Пов’язана документація
|
||||
## Пов’язані документи
|
||||
|
||||
- [Skills](/uk/tools/skills)
|
||||
- [Plugins](/uk/tools/plugin)
|
||||
- [Testing](/uk/reference/test)
|
||||
- [Тестування](/uk/reference/test)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user