chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
06b8645378
commit
ba5bf6c9b2
File diff suppressed because it is too large
Load Diff
102
docs/uk/ci.md
102
docs/uk/ci.md
@ -1,89 +1,89 @@
|
||||
---
|
||||
read_when:
|
||||
- Вам потрібно зрозуміти, чому завдання CI було або не було запущено.
|
||||
- Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося
|
||||
- Ви налагоджуєте збої перевірок GitHub Actions
|
||||
summary: Граф завдань CI, шлюзи області дії та локальні еквіваленти команд
|
||||
summary: Граф завдань CI, межі перевірок і локальні еквіваленти команд
|
||||
title: Конвеєр CI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-22T19:49:54Z"
|
||||
generated_at: "2026-04-22T19:55:18Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 8a3fd8d758be86be3b2845b8507d118b6dbe14d1e4886a7adc88d226d2817772
|
||||
source_hash: c8c90ba88b3b08f87407e3b1cd90c13b1a2b2b6cb3c0e23b4f4f367614c97cc2
|
||||
source_path: ci.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Конвеєр CI
|
||||
|
||||
CI запускається під час кожного push до `main` і для кожного pull request. Він використовує розумне визначення області дії, щоб пропускати дорогі завдання, коли змінено лише не пов’язані частини.
|
||||
CI запускається при кожному push до `main` і для кожного pull request. Він використовує розумне визначення меж, щоб пропускати дорогі завдання, коли змінювалися лише нерелевантні ділянки.
|
||||
|
||||
## Огляд завдань
|
||||
|
||||
| Завдання | Призначення | Коли запускається |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- |
|
||||
| `preflight` | Визначає зміни лише в документації, змінені області, змінені розширення та збирає маніфест CI | Завжди для push і PR, що не є draft |
|
||||
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для push і PR, що не є draft |
|
||||
| `security-dependency-audit` | Аудит production lockfile без залежностей щодо npm advisories | Завжди для push і PR, що не є draft |
|
||||
| `security-fast` | Обов’язковий агрегатор для швидких завдань безпеки | Завжди для push і PR, що не є draft |
|
||||
| `build-artifacts` | Один раз збирає `dist/` і Control UI, завантажує повторно використовувані артефакти для downstream-завдань | Зміни, релевантні для Node |
|
||||
| `checks-fast-core` | Швидкі Linux-етапи коректності, як-от перевірки bundled/plugin-contract/protocol | Зміни, релевантні для Node |
|
||||
| `checks-fast-contracts-channels` | Розподілені перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node |
|
||||
| `checks-node-extensions` | Повні шарди тестів bundled-plugin для всього набору розширень | Зміни, релевантні для Node |
|
||||
| `checks-node-core-test` | Шарди тестів core Node, без етапів каналів, bundled, контрактів і розширень | Зміни, релевантні для Node |
|
||||
| `extension-fast` | Цільові тести лише для змінених bundled plugins | Коли виявлено зміни розширень |
|
||||
| `check` | Розподілений еквівалент основного локального шлюзу: production types, lint, guards, test types і strict smoke | Зміни, релевантні для Node |
|
||||
| `check-additional` | Захисти архітектури, меж, surface розширень, package-boundary і шарди gateway-watch | Зміни, релевантні для Node |
|
||||
| `build-smoke` | Smoke-тести зібраного CLI та smoke стартової пам’яті | Зміни, релевантні для Node |
|
||||
| `checks` | Решта Linux Node-етапів: тести каналів і сумісність лише для push із Node 22 | Зміни, релевантні для Node |
|
||||
| `check-docs` | Форматування документації, lint і перевірки битих посилань | Коли змінено документацію |
|
||||
| `skills-python` | Ruff + pytest для Skills на базі Python | Зміни, релевантні для Python Skills |
|
||||
| `checks-windows` | Windows-специфічні тестові етапи | Зміни, релевантні для Windows |
|
||||
| `macos-node` | Етап тестів TypeScript на macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS |
|
||||
| `macos-swift` | Swift lint, build і tests для застосунку macOS | Зміни, релевантні для macOS |
|
||||
| `android` | Матриця збірки та тестів Android | Зміни, релевантні для Android |
|
||||
| Завдання | Призначення | Коли запускається |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------ | ----------------------------------- |
|
||||
| `preflight` | Визначає зміни лише в документації, змінені межі, змінені розширення та будує маніфест CI | Завжди для push і PR, що не є draft |
|
||||
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для push і PR, що не є draft |
|
||||
| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisory з npm | Завжди для push і PR, що не є draft |
|
||||
| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для push і PR, що не є draft |
|
||||
| `build-artifacts` | Збирає `dist/` і Control UI один раз, завантажує повторно використовувані артефакти для наступних завдань | Зміни, релевантні Node |
|
||||
| `checks-fast-core` | Швидкі Linux-етапи коректності, такі як перевірки bundled/plugin-contract/protocol | Зміни, релевантні Node |
|
||||
| `checks-fast-contracts-channels` | Шардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні Node |
|
||||
| `checks-node-extensions` | Повні тестові шарди bundled-plugin для всього набору розширень | Зміни, релевантні Node |
|
||||
| `checks-node-core-test` | Шарди основних тестів Node, за винятком каналів, bundled, контрактних і extension-етапів | Зміни, релевантні Node |
|
||||
| `extension-fast` | Сфокусовані тести лише для змінених bundled plugins | Коли виявлено зміни розширень |
|
||||
| `check` | Шардований еквівалент основної локальної перевірки: production types, lint, guards, test types і strict smoke | Зміни, релевантні Node |
|
||||
| `check-additional` | Архітектурні перевірки, перевірки меж, extension-surface guards, package-boundary і шарди gateway-watch | Зміни, релевантні Node |
|
||||
| `build-smoke` | Smoke-тести зібраного CLI та smoke-тест використання пам’яті під час запуску | Зміни, релевантні Node |
|
||||
| `checks` | Решта Linux Node-етапів: тести каналів і сумісність лише для push із Node 22 | Зміни, релевантні Node |
|
||||
| `check-docs` | Форматування документації, lint і перевірки битих посилань | Документацію змінено |
|
||||
| `skills-python` | Ruff + pytest для Skills на основі Python | Зміни, релевантні Python Skills |
|
||||
| `checks-windows` | Специфічні для Windows тестові етапи | Зміни, релевантні Windows |
|
||||
| `macos-node` | Етап тестів TypeScript на macOS із використанням спільних зібраних артефактів | Зміни, релевантні macOS |
|
||||
| `macos-swift` | Swift lint, збірка і тести для застосунку macOS | Зміни, релевантні macOS |
|
||||
| `android` | Матриця збірки й тестів Android | Зміни, релевантні Android |
|
||||
|
||||
## Порядок fail-fast
|
||||
## Порядок швидкого завершення з помилкою
|
||||
|
||||
Завдання впорядковані так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запустяться дорогі:
|
||||
Завдання впорядковані так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запускаються дорогі:
|
||||
|
||||
1. `preflight` вирішує, які етапи взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` завершуються швидко без очікування важчих завдань з артефактами та платформних матриць.
|
||||
3. `build-artifacts` виконується паралельно зі швидкими Linux-етапами, щоб downstream-споживачі могли почати роботу, щойно спільна збірка буде готова.
|
||||
4. Після цього розгалужуються важчі платформні та runtime-етапи: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою, не чекаючи важчих завдань зі збирання артефактів і платформених матриць.
|
||||
3. `build-artifacts` виконується паралельно зі швидкими Linux-етапами, щоб наступні споживачі могли стартувати, щойно спільна збірка буде готова.
|
||||
4. Після цього розгалужуються важчі платформені та runtime-етапи: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
|
||||
|
||||
Логіка області дії знаходиться в `scripts/ci-changed-scope.mjs` і покривається unit-тестами в `src/scripts/ci-changed-scope.test.ts`.
|
||||
Зміни у workflow CI перевіряють граф Node CI плюс lint workflow, але самі по собі не примушують запускати нативні збірки Windows, Android або macOS; ці платформні етапи й надалі обмежені змінами у вихідному коді відповідної платформи.
|
||||
Перевірки Windows Node обмежені Windows-специфічними обгортками для process/path, допоміжними засобами npm/pnpm/UI runner, конфігурацією package manager і поверхнями workflow CI, які запускають цей етап; не пов’язані зміни у вихідному коді, plugins, install-smoke і зміни лише в тестах залишаються на Linux Node-етапах, щоб не резервувати 16-vCPU Windows worker для покриття, яке вже виконується звичайними шардами тестів.
|
||||
Окремий workflow `install-smoke` повторно використовує той самий скрипт визначення області дії через власне завдання `preflight`. Він обчислює `run_install_smoke` із вужчого сигналу changed-smoke, тому Docker/install smoke запускається лише для змін, релевантних до встановлення, пакування та контейнерів. Його smoke QR package примушує Docker-шар `pnpm install` виконатися повторно, зберігаючи кеш BuildKit pnpm store, тож він усе одно перевіряє встановлення без повторного завантаження залежностей під час кожного запуску. Його gateway-network e2e повторно використовує runtime-образ, зібраний раніше в межах завдання, тому додає реальне WebSocket-покриття між контейнерами без додавання ще однієї Docker-збірки.
|
||||
Логіка меж знаходиться в `scripts/ci-changed-scope.mjs` і покривається unit-тестами в `src/scripts/ci-changed-scope.test.ts`.
|
||||
Зміни workflow CI перевіряють граф Node CI разом із linting workflow, але самі по собі не примушують запускати нативні збірки Windows, Android або macOS; ці платформені етапи залишаються прив’язаними до змін у вихідному коді відповідної платформи.
|
||||
Перевірки Windows Node обмежені специфічними для Windows обгортками process/path, допоміжними засобами npm/pnpm/UI runner, конфігурацією package manager і поверхнями workflow CI, які запускають цей етап; нерелевантні зміни вихідного коду, plugin, install-smoke і лише тестові зміни залишаються на Linux Node-етапах, щоб не резервувати Windows worker із 16 vCPU для покриття, яке вже виконується звичайними тестовими шардами.
|
||||
Окремий workflow `install-smoke` повторно використовує той самий скрипт меж через власне завдання `preflight`. Він обчислює `run_install_smoke` на основі вужчого сигналу changed-smoke, тому Docker/install smoke запускається лише для змін, релевантних встановленню, пакуванню та контейнерам. Його QR package smoke примушує Docker-шар `pnpm install` виконатися повторно, зберігаючи кеш BuildKit pnpm store, тож він усе ще перевіряє встановлення без повторного завантаження залежностей у кожному запуску. Його gateway-network e2e повторно використовує runtime-образ, зібраний раніше в межах цього завдання, тому додає реальне покриття WebSocket між контейнерами без додавання ще однієї Docker-збірки.
|
||||
|
||||
Локальна логіка changed-lane знаходиться в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний шлюз суворіший щодо архітектурних меж, ніж широка область дії платформ у CI: зміни core production запускають typecheck core prod плюс тести core, зміни лише в тестах core запускають лише typecheck/tests для core test, зміни production у розширеннях запускають typecheck extension prod плюс тести розширень, а зміни лише в тестах розширень запускають лише typecheck/tests для extension test. Зміни в публічному Plugin SDK або plugin-contract розширюють валідацію до розширень, оскільки розширення залежать від цих контрактів core. Підвищення версії лише в release metadata запускають цільові перевірки version/config/root-dependency. Невідомі зміни root/config для безпеки запускають усі етапи.
|
||||
Локальна логіка changed-lane знаходиться в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Ця локальна перевірка суворіша щодо архітектурних меж, ніж широкі платформені межі CI: зміни core production запускають core prod typecheck разом із core tests, зміни лише core test запускають тільки core test typecheck/tests, зміни extension production запускають extension prod typecheck разом із extension tests, а зміни лише extension test запускають тільки extension test typecheck/tests. Зміни публічного Plugin SDK або plugin-contract розширюють перевірку на extension, оскільки розширення залежать від цих контрактів core. Зміни лише в release metadata із підвищенням версії запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config безпечно призводять до запуску всіх етапів.
|
||||
|
||||
Для push матриця `checks` додає етап `compat-node22`, який запускається лише для push. Для pull request цей етап пропускається, і матриця залишається зосередженою на звичайних test/channel-етапах.
|
||||
|
||||
Найповільніші сімейства тестів Node розбиті або збалансовані так, щоб кожне завдання залишалося невеликим: контракти каналів розділяють покриття registry і core на вісім зважених шардів кожне, auto-reply працює як три збалансовані workers замість шести крихітних workers, а конфігурації agentic gateway/plugin розподілені по наявних agentic Node-завданнях лише для вихідного коду замість очікування зібраних артефактів. `check-additional` тримає разом compile/canary-роботи package-boundary і відокремлює їх від runtime topology gateway/architecture; шард boundary guard виконує свої невеликі незалежні guards паралельно в межах одного завдання, а регресія gateway watch використовує мінімальний профіль збірки `gatewayWatch` замість повторного збирання повного набору sidecar-артефактів CI.
|
||||
Найповільніші сімейства тестів Node розбиті або збалансовані так, щоб кожне завдання залишалося невеликим: контракти каналів розділяють покриття registry і core на вісім зважених шардів кожне, auto-reply працює у вигляді трьох збалансованих worker замість шести крихітних, а agentic gateway/plugin configs розподілені по наявних source-only agentic Node-завданнях замість очікування на зібрані артефакти. `check-additional` тримає package-boundary compile/canary роботу разом і відокремлює її від runtime topology gateway/architecture роботи; шард boundary guard запускає свої невеликі незалежні guards паралельно в межах одного завдання, а regression для gateway watch використовує мінімальний профіль збірки `gatewayWatch` замість повторного збирання повного набору sidecar-артефактів CI.
|
||||
|
||||
GitHub може позначати витіснені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо тільки найновіший запуск для того самого ref також не завершується з помилкою. Агреговані перевірки шардів використовують `!cancelled() && always()`, тому вони все одно повідомляють про звичайні збої шардів, але не стають у чергу після того, як увесь workflow уже був витіснений.
|
||||
Ключ конкурентності CI має версію (`CI-v4-*`), щоб zombie-процес на боці GitHub у старій групі черги не міг безстроково блокувати новіші запуски main.
|
||||
GitHub може позначати замінені новішими завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Сприймайте це як шум CI, якщо тільки найновіший запуск для того самого ref теж не завершується з помилкою. Агреговані перевірки шардів використовують `!cancelled() && always()`, тому вони все одно повідомляють про звичайні збої шардів, але не стають у чергу після того, як увесь workflow уже був замінений новішим.
|
||||
Ключ concurrency для CI має версію (`CI-v5-*`), щоб zombie-процес на боці GitHub у старій групі черги не міг безстроково блокувати новіші запуски main.
|
||||
|
||||
## Runners
|
||||
|
||||
| Runner | Завдання |
|
||||
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегатори (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, розподілені перевірки контрактів каналів, шарди `check`, окрім lint, шарди й агрегатори `check-additional`, агреговані верифікатори тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла стати в чергу раніше |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів bundled plugins, решта споживачів зібраних артефактів, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо чутливим до CPU, тому 8 vCPU коштували дорожче, ніж заощаджували; Docker-збірки install-smoke, де час очікування в черзі для 32 vCPU коштував дорожче, ніж давав вигоду |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` у `openclaw/openclaw`; для fork використовується резервний перехід на `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; для fork використовується резервний перехід на `macos-latest` |
|
||||
| Runner | Завдання |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки й агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки контрактів каналів, шарди `check`, окрім lint, шарди й агрегати `check-additional`, агреговані верифікатори тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла ставати в чергу раніше |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів bundled plugin, решта споживачів зібраних артефактів, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо чутливим до CPU, тому 8 vCPU коштували дорожче, ніж давали вигоди; Docker-збірки install-smoke, де час очікування в черзі для 32 vCPU коштував дорожче, ніж давав вигоди |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` у `openclaw/openclaw`; для форків використовується резервний `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; для форків використовується резервний `macos-latest` |
|
||||
|
||||
## Локальні еквіваленти
|
||||
|
||||
```bash
|
||||
pnpm changed:lanes # переглянути локальний класифікатор changed-lane для origin/main...HEAD
|
||||
pnpm check:changed # розумний локальний шлюз: changed typecheck/lint/tests за boundary-етапом
|
||||
pnpm check # швидкий локальний шлюз: production tsgo + sharded lint + parallel fast guards
|
||||
pnpm check:changed # розумна локальна перевірка: changed typecheck/lint/tests за boundary-етапом
|
||||
pnpm check # швидка локальна перевірка: production tsgo + шардований lint + паралельні швидкі guards
|
||||
pnpm check:test-types
|
||||
pnpm check:timed # той самий шлюз із таймінгами для кожного етапу
|
||||
pnpm check:timed # та сама перевірка з таймінгами для кожного етапу
|
||||
pnpm build:strict-smoke
|
||||
pnpm check:architecture
|
||||
pnpm test:gateway:watch-regression
|
||||
|
||||
@ -3,13 +3,13 @@ read_when:
|
||||
- Додавання або змінення CLI моделей (models list/set/scan/aliases/fallbacks)
|
||||
- Зміна поведінки резервних варіантів моделі або UX вибору
|
||||
- Оновлення перевірок сканування моделей (інструменти/зображення)
|
||||
summary: 'CLI моделей: список, встановлення, псевдоніми, резервні варіанти, сканування, стан'
|
||||
summary: 'CLI моделей: список, встановлення, псевдоніми, резервні варіанти, сканування, статус'
|
||||
title: CLI моделей
|
||||
x-i18n:
|
||||
generated_at: "2026-04-22T17:02:09Z"
|
||||
generated_at: "2026-04-22T19:55:24Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 94fe5b6012f12ab469305bcae95b2b7e9482f2d6868fc8a71a8c9ac2bd0e8604
|
||||
source_hash: 99174b625d265fe4743f4e0ca7ea3897bb446a485dde0841e101fe136a08558a
|
||||
source_path: concepts/models.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -24,35 +24,34 @@ x-i18n:
|
||||
OpenClaw вибирає моделі в такому порядку:
|
||||
|
||||
1. **Основна** модель (`agents.defaults.model.primary` або `agents.defaults.model`).
|
||||
2. **Резервні варіанти** в `agents.defaults.model.fallbacks` (у вказаному порядку).
|
||||
3. **Перемикання автентифікації провайдера при збої** відбувається всередині провайдера перед переходом до наступної моделі.
|
||||
2. **Резервні варіанти** в `agents.defaults.model.fallbacks` (за порядком).
|
||||
3. **Резервне перемикання автентифікації провайдера** відбувається всередині провайдера перед переходом до наступної моделі.
|
||||
|
||||
Пов’язано:
|
||||
Пов’язане:
|
||||
|
||||
- `agents.defaults.models` — це allowlist/каталог моделей, які OpenClaw може використовувати (разом із псевдонімами).
|
||||
- `agents.defaults.imageModel` використовується **лише тоді**, коли основна модель не може приймати зображення.
|
||||
- `agents.defaults.pdfModel` використовується інструментом `pdf`. Якщо його не вказано, інструмент повертається до `agents.defaults.imageModel`, а потім до визначеної моделі сеансу/типової моделі.
|
||||
- `agents.defaults.imageGenerationModel` використовується спільною можливістю генерації зображень. Якщо його не вказано, `image_generate` усе одно може вивести типовий провайдер на основі автентифікації. Спочатку він пробує поточного типового провайдера, потім решту зареєстрованих провайдерів генерації зображень у порядку provider-id. Якщо ви задаєте конкретний провайдер/модель, також налаштуйте автентифікацію/API key цього провайдера.
|
||||
- `agents.defaults.musicGenerationModel` використовується спільною можливістю генерації музики. Якщо його не вказано, `music_generate` усе одно може вивести типовий провайдер на основі автентифікації. Спочатку він пробує поточного типового провайдера, потім решту зареєстрованих провайдерів генерації музики в порядку provider-id. Якщо ви задаєте конкретний провайдер/модель, також налаштуйте автентифікацію/API key цього провайдера.
|
||||
- `agents.defaults.videoGenerationModel` використовується спільною можливістю генерації відео. Якщо його не вказано, `video_generate` усе одно може вивести типовий провайдер на основі автентифікації. Спочатку він пробує поточного типового провайдера, потім решту зареєстрованих провайдерів генерації відео в порядку provider-id. Якщо ви задаєте конкретний провайдер/модель, також налаштуйте автентифікацію/API key цього провайдера.
|
||||
- Типові значення для окремого агента можуть перевизначати `agents.defaults.model` через `agents.list[].model` разом із прив’язками (див. [/concepts/multi-agent](/uk/concepts/multi-agent)).
|
||||
- `agents.defaults.pdfModel` використовується інструментом `pdf`. Якщо його не вказано, інструмент повертається до `agents.defaults.imageModel`, а потім до визначеної для сесії/типової моделі.
|
||||
- `agents.defaults.imageGenerationModel` використовується спільною можливістю генерації зображень. Якщо його не вказано, `image_generate` усе одно може визначити типовий варіант провайдера з автентифікацією. Спочатку він пробує поточного типового провайдера, потім — решту зареєстрованих провайдерів генерації зображень у порядку `provider-id`. Якщо ви задаєте конкретний провайдер/модель, також налаштуйте автентифікацію/API key цього провайдера.
|
||||
- `agents.defaults.musicGenerationModel` використовується спільною можливістю генерації музики. Якщо його не вказано, `music_generate` усе одно може визначити типовий варіант провайдера з автентифікацією. Спочатку він пробує поточного типового провайдера, потім — решту зареєстрованих провайдерів генерації музики в порядку `provider-id`. Якщо ви задаєте конкретний провайдер/модель, також налаштуйте автентифікацію/API key цього провайдера.
|
||||
- `agents.defaults.videoGenerationModel` використовується спільною можливістю генерації відео. Якщо його не вказано, `video_generate` усе одно може визначити типовий варіант провайдера з автентифікацією. Спочатку він пробує поточного типового провайдера, потім — решту зареєстрованих провайдерів генерації відео в порядку `provider-id`. Якщо ви задаєте конкретний провайдер/модель, також налаштуйте автентифікацію/API key цього провайдера.
|
||||
- Типові значення для окремих агентів можуть перевизначати `agents.defaults.model` через `agents.list[].model` разом із прив’язками (див. [/concepts/multi-agent](/uk/concepts/multi-agent)).
|
||||
|
||||
## Швидка політика щодо моделей
|
||||
## Швидка політика моделей
|
||||
|
||||
- Встановіть основною найсильнішу модель останнього покоління, яка вам доступна.
|
||||
- Використовуйте резервні варіанти для завдань, чутливих до вартості/затримки, і менш критичного чату.
|
||||
- Для агентів з увімкненими інструментами або недовіреними вхідними даними уникайте старіших/слабших рівнів моделей.
|
||||
- Використовуйте резервні варіанти для завдань, чутливих до вартості/затримки, і для менш критичного чату.
|
||||
- Для агентів з увімкненими інструментами або для недовірених вхідних даних уникайте старіших/слабших рівнів моделей.
|
||||
|
||||
## Онбординг (рекомендовано)
|
||||
|
||||
Якщо ви не хочете редагувати конфігурацію вручну, запустіть онбординг:
|
||||
Якщо ви не хочете вручну редагувати конфігурацію, запустіть онбординг:
|
||||
|
||||
```bash
|
||||
openclaw onboard
|
||||
```
|
||||
|
||||
Він може налаштувати модель + автентифікацію для поширених провайдерів, зокрема **OpenAI Code (Codex)
|
||||
subscription** (OAuth) та **Anthropic** (API key або Claude CLI).
|
||||
Він може налаштувати модель + автентифікацію для поширених провайдерів, зокрема **OpenAI Code (Codex) subscription** (OAuth) та **Anthropic** (API key або Claude CLI).
|
||||
|
||||
## Ключі конфігурації (огляд)
|
||||
|
||||
@ -64,24 +63,20 @@ subscription** (OAuth) та **Anthropic** (API key або Claude CLI).
|
||||
- `agents.defaults.models` (allowlist + псевдоніми + параметри провайдера)
|
||||
- `models.providers` (власні провайдери, записані в `models.json`)
|
||||
|
||||
Посилання на моделі нормалізуються до нижнього регістру. Псевдоніми провайдерів, наприклад `z.ai/*`, нормалізуються
|
||||
до `zai/*`.
|
||||
Посилання на моделі нормалізуються до нижнього регістру. Псевдоніми провайдерів, як-от `z.ai/*`, нормалізуються до `zai/*`.
|
||||
|
||||
Приклади конфігурації провайдерів (зокрема OpenCode) наведені в
|
||||
Приклади конфігурації провайдерів (зокрема OpenCode) наведено в
|
||||
[/providers/opencode](/uk/providers/opencode).
|
||||
|
||||
## «Модель не дозволена» (і чому відповіді припиняються)
|
||||
## «Модель не дозволена» (і чому відповіді зупиняються)
|
||||
|
||||
Якщо задано `agents.defaults.models`, воно стає **allowlist** для `/model` і для
|
||||
перевизначень сеансу. Коли користувач вибирає модель, якої немає в цьому allowlist,
|
||||
OpenClaw повертає:
|
||||
Якщо задано `agents.defaults.models`, воно стає **allowlist** для `/model` і для перевизначень сесії. Коли користувач вибирає модель, якої немає в цьому allowlist, OpenClaw повертає:
|
||||
|
||||
```
|
||||
Model "provider/model" is not allowed. Use /model to list available models.
|
||||
```
|
||||
|
||||
Це відбувається **до** генерації звичайної відповіді, тому може здаватися,
|
||||
ніби повідомлення «не отримало відповіді». Щоб виправити це, потрібно:
|
||||
Це відбувається **до** генерації звичайної відповіді, тому може здаватися, що повідомлення «не отримало відповіді». Виправити це можна так:
|
||||
|
||||
- Додати модель до `agents.defaults.models`, або
|
||||
- Очистити allowlist (видалити `agents.defaults.models`), або
|
||||
@ -103,7 +98,7 @@ Model "provider/model" is not allowed. Use /model to list available models.
|
||||
|
||||
## Перемикання моделей у чаті (`/model`)
|
||||
|
||||
Ви можете перемикати моделі для поточного сеансу без перезапуску:
|
||||
Ви можете перемикати моделі для поточної сесії без перезапуску:
|
||||
|
||||
```
|
||||
/model
|
||||
@ -115,28 +110,28 @@ Model "provider/model" is not allowed. Use /model to list available models.
|
||||
|
||||
Примітки:
|
||||
|
||||
- `/model` (і `/model list`) — це компактний нумерований засіб вибору (сімейство моделей + доступні провайдери).
|
||||
- У Discord `/model` і `/models` відкривають інтерактивний засіб вибору зі списками провайдера та моделі, а також кроком Submit.
|
||||
- `/models add` дає змогу додати запис провайдер/модель із чату без ручного редагування конфігурації.
|
||||
- `/models add <provider> <modelId>` — найшвидший шлях; простий `/models add` запускає керований потік із вибором провайдера спочатку, де це підтримується.
|
||||
- `/model` (і `/model list`) — це компактний нумерований вибір (сімейство моделей + доступні провайдери).
|
||||
- У Discord `/model` і `/models` відкривають інтерактивний вибір із випадними списками провайдера та моделі, а також кроком Submit.
|
||||
- `/models add` доступна типово й може бути вимкнена через `commands.modelsWrite=false`.
|
||||
- Якщо ввімкнено, `/models add <provider> <modelId>` — це найшвидший шлях; просто `/models add` запускає керований процес із вибором провайдера спочатку, де це підтримується.
|
||||
- Після `/models add` нова модель стає доступною в `/models` і `/model` без перезапуску Gateway.
|
||||
- `/model <#>` вибирає зі списку цього засобу вибору.
|
||||
- `/model` одразу зберігає новий вибір для сеансу.
|
||||
- `/model <#>` вибирає модель із цього списку.
|
||||
- `/model` одразу зберігає новий вибір для сесії.
|
||||
- Якщо агент неактивний, наступний запуск одразу використовує нову модель.
|
||||
- Якщо запуск уже активний, OpenClaw позначає перемикання під час роботи як відкладене й перезапускається з новою моделлю лише в чистій точці повторної спроби.
|
||||
- Якщо активність інструментів або виведення відповіді вже почалися, відкладене перемикання може залишатися в черзі до пізнішої можливості повторної спроби або до наступного ходу користувача.
|
||||
- `/model status` — це докладне подання (кандидати автентифікації та, якщо налаштовано, `baseUrl` і режим `api` кінцевої точки провайдера).
|
||||
- Посилання на моделі розбираються шляхом поділу за **першим** `/`. Під час введення `/model <ref>` використовуйте `provider/model`.
|
||||
- Якщо запуск уже активний, OpenClaw позначає перемикання на льоту як очікуване й перезапускає в нову модель лише в чистій точці повторної спроби.
|
||||
- Якщо активність інструментів або виведення відповіді вже почалися, очікуване перемикання може залишатися в черзі до пізнішої можливості повторної спроби або до наступного ходу користувача.
|
||||
- `/model status` — це детальне подання (кандидати автентифікації та, коли налаштовано, `baseUrl` кінцевої точки провайдера + режим `api`).
|
||||
- Посилання на модель розбираються шляхом поділу за **першим** `/`. Під час введення `/model <ref>` використовуйте `provider/model`.
|
||||
- Якщо сам ID моделі містить `/` (у стилі OpenRouter), ви маєте вказати префікс провайдера (приклад: `/model openrouter/moonshotai/kimi-k2`).
|
||||
- Якщо ви не вказуєте провайдера, OpenClaw визначає введення в такому порядку:
|
||||
1. збіг псевдоніма
|
||||
2. унікальний збіг налаштованого провайдера для цього точного ID моделі без префікса
|
||||
3. застаріле повернення до налаштованого типового провайдера
|
||||
2. однозначний збіг налаштованого провайдера для цього точного ID моделі без префікса
|
||||
3. застарілий резервний перехід до налаштованого типового провайдера
|
||||
Якщо цей провайдер більше не надає налаштовану типову модель, OpenClaw
|
||||
натомість повертається до першого налаштованого провайдера/моделі, щоб не
|
||||
показувати застаріле типове значення видаленого провайдера.
|
||||
натомість переходить до першого налаштованого провайдера/моделі, щоб уникнути
|
||||
показу застарілого типового значення видаленого провайдера.
|
||||
|
||||
Повна поведінка/конфігурація команд: [Слеш-команди](/uk/tools/slash-commands).
|
||||
Повна поведінка команди/конфігурація: [Косі команди](/uk/tools/slash-commands).
|
||||
|
||||
Приклади:
|
||||
|
||||
@ -146,7 +141,7 @@ Model "provider/model" is not allowed. Use /model to list available models.
|
||||
/models add lmstudio qwen/qwen3.5-9b
|
||||
```
|
||||
|
||||
## Команди CLI
|
||||
## CLI команди
|
||||
|
||||
```bash
|
||||
openclaw models list
|
||||
@ -181,31 +176,22 @@ openclaw models image-fallbacks clear
|
||||
- `--plain`: одна модель на рядок
|
||||
- `--json`: машинозчитуваний вивід
|
||||
|
||||
`--all` включає зведені статичні рядки каталогу, якими володіють вбудовані провайдери, до
|
||||
налаштування автентифікації, тому подання лише для виявлення можуть показувати моделі, які недоступні, доки
|
||||
ви не додасте відповідні облікові дані провайдера.
|
||||
`--all` включає рядки статичного каталогу вбудованих провайдерів ще до налаштування автентифікації, тож подання лише для виявлення можуть показувати моделі, недоступні, доки ви не додасте відповідні облікові дані провайдера.
|
||||
|
||||
### `models status`
|
||||
|
||||
Показує визначену основну модель, резервні варіанти, модель зображень і огляд
|
||||
автентифікації налаштованих провайдерів. Також показує статус завершення дії OAuth для профілів, знайдених
|
||||
у сховищі автентифікації (типово попереджає за 24 год до завершення). `--plain` виводить лише
|
||||
визначену основну модель.
|
||||
Статус OAuth показується завжди (і входить у вивід `--json`). Якщо в налаштованого
|
||||
провайдера немає облікових даних, `models status` виводить розділ **Відсутня автентифікація**.
|
||||
JSON включає `auth.oauth` (вікно попередження + профілі) і `auth.providers`
|
||||
Показує визначені основну модель, резервні варіанти, модель для зображень і огляд автентифікації налаштованих провайдерів. Також показує стан завершення строку дії OAuth для профілів, знайдених у сховищі автентифікації (типово попереджає за 24 год). `--plain` виводить лише визначену основну модель.
|
||||
Стан OAuth показується завжди (і включається у вивід `--json`). Якщо налаштований провайдер не має облікових даних, `models status` виводить розділ **Відсутня автентифікація**.
|
||||
JSON містить `auth.oauth` (вікно попередження + профілі) та `auth.providers`
|
||||
(ефективна автентифікація для кожного провайдера, зокрема облікові дані з env). `auth.oauth`
|
||||
стосується лише стану профілів у сховищі автентифікації; провайдери лише з env там не відображаються.
|
||||
Використовуйте `--check` для автоматизації (код виходу `1` для відсутніх/прострочених, `2` для тих, що скоро завершаться).
|
||||
Використовуйте `--probe` для живих перевірок автентифікації; рядки перевірки можуть надходити з профілів автентифікації, облікових даних env
|
||||
або `models.json`.
|
||||
стосується лише стану профілів у сховищі автентифікації; провайдери лише з env там не з’являються.
|
||||
Використовуйте `--check` для автоматизації (код виходу `1` для відсутніх/прострочених, `2` для тих, що скоро спливають).
|
||||
Використовуйте `--probe` для живих перевірок автентифікації; рядки перевірок можуть надходити з профілів автентифікації, облікових даних env або `models.json`.
|
||||
Якщо явний `auth.order.<provider>` пропускає збережений профіль, перевірка повідомляє
|
||||
`excluded_by_auth_order` замість спроби його використати. Якщо автентифікація є, але не вдається визначити
|
||||
жодну модель для перевірки для цього провайдера, перевірка повідомляє `status: no_model`.
|
||||
`excluded_by_auth_order` замість спроби його використати. Якщо автентифікація є, але для цього провайдера неможливо визначити модель, придатну для перевірки, перевірка повідомляє `status: no_model`.
|
||||
|
||||
Вибір автентифікації залежить від провайдера/облікового запису. Для хостів Gateway, що працюють постійно,
|
||||
API key зазвичай є найпередбачуванішим варіантом; також підтримується повторне використання Claude CLI та наявних профілів
|
||||
OAuth/токенів Anthropic.
|
||||
Вибір автентифікації залежить від провайдера/облікового запису. Для постійно активних хостів Gateway
|
||||
API key зазвичай найпередбачуваніші; також підтримується повторне використання Claude CLI та наявних профілів OAuth/token Anthropic.
|
||||
|
||||
Приклад (Claude CLI):
|
||||
|
||||
@ -214,25 +200,25 @@ claude auth login
|
||||
openclaw models status
|
||||
```
|
||||
|
||||
## Сканування (безкоштовні моделі OpenRouter)
|
||||
## Сканування (безплатні моделі OpenRouter)
|
||||
|
||||
`openclaw models scan` перевіряє **каталог безкоштовних моделей** OpenRouter і може
|
||||
за потреби перевіряти моделі на підтримку інструментів і зображень.
|
||||
`openclaw models scan` перевіряє **каталог безплатних моделей** OpenRouter і може
|
||||
за бажанням виконувати перевірку моделей на підтримку інструментів і зображень.
|
||||
|
||||
Основні прапорці:
|
||||
|
||||
- `--no-probe`: пропустити живі перевірки (лише метадані)
|
||||
- `--min-params <b>`: мінімальний розмір параметрів (у мільярдах)
|
||||
- `--max-age-days <days>`: пропускати старіші моделі
|
||||
- `--max-age-days <days>`: пропустити старіші моделі
|
||||
- `--provider <name>`: фільтр за префіксом провайдера
|
||||
- `--max-candidates <n>`: розмір списку резервних варіантів
|
||||
- `--set-default`: встановити `agents.defaults.model.primary` на перший вибраний варіант
|
||||
- `--set-image`: встановити `agents.defaults.imageModel.primary` на перший вибраний варіант зображень
|
||||
- `--set-default`: встановити `agents.defaults.model.primary` на перший вибір
|
||||
- `--set-image`: встановити `agents.defaults.imageModel.primary` на перший вибір зображення
|
||||
|
||||
Для перевірок потрібен API key OpenRouter (із профілів автентифікації або
|
||||
Перевірка потребує API key OpenRouter (з профілів автентифікації або
|
||||
`OPENROUTER_API_KEY`). Без ключа використовуйте `--no-probe`, щоб лише перелічити кандидатів.
|
||||
|
||||
Результати сканування ранжуються за такими критеріями:
|
||||
Результати сканування ранжуються за:
|
||||
|
||||
1. Підтримка зображень
|
||||
2. Затримка інструментів
|
||||
@ -241,36 +227,36 @@ openclaw models status
|
||||
|
||||
Вхідні дані
|
||||
|
||||
- список OpenRouter `/models` (фільтр `:free`)
|
||||
- Потрібен API key OpenRouter із профілів автентифікації або `OPENROUTER_API_KEY` (див. [/environment](/uk/help/environment))
|
||||
- Список OpenRouter `/models` (фільтр `:free`)
|
||||
- Потребує API key OpenRouter із профілів автентифікації або `OPENROUTER_API_KEY` (див. [/environment](/uk/help/environment))
|
||||
- Необов’язкові фільтри: `--max-age-days`, `--min-params`, `--provider`, `--max-candidates`
|
||||
- Керування перевірками: `--timeout`, `--concurrency`
|
||||
- Керування перевіркою: `--timeout`, `--concurrency`
|
||||
|
||||
Під час запуску в TTY ви можете інтерактивно вибирати резервні варіанти. У неінтерактивному
|
||||
режимі передайте `--yes`, щоб прийняти типові значення.
|
||||
|
||||
## Реєстр моделей (`models.json`)
|
||||
|
||||
Власні провайдери в `models.providers` записуються до `models.json` у
|
||||
каталозі агента (типово `~/.openclaw/agents/<agentId>/agent/models.json`). Цей файл
|
||||
Власні провайдери в `models.providers` записуються в `models.json` у каталозі
|
||||
агента (типово `~/.openclaw/agents/<agentId>/agent/models.json`). Цей файл
|
||||
типово об’єднується, якщо тільки `models.mode` не встановлено в `replace`.
|
||||
|
||||
Пріоритет у режимі об’єднання для збіжних ID провайдерів:
|
||||
Пріоритет у режимі злиття для однакових ID провайдерів:
|
||||
|
||||
- Непорожній `baseUrl`, уже наявний у `models.json` агента, має перевагу.
|
||||
- Непорожній `apiKey` у `models.json` агента має перевагу лише тоді, коли цей провайдер не керується через SecretRef у поточному контексті конфігурації/профілю автентифікації.
|
||||
- Значення `apiKey` для провайдерів, керованих через SecretRef, оновлюються з маркерів джерела (`ENV_VAR_NAME` для посилань на env, `secretref-managed` для посилань file/exec) замість збереження визначених секретів.
|
||||
- Значення заголовків для провайдерів, керованих через SecretRef, оновлюються з маркерів джерела (`secretref-env:ENV_VAR_NAME` для посилань на env, `secretref-managed` для посилань file/exec).
|
||||
- Порожній або відсутній `apiKey`/`baseUrl` агента повертається до конфігурації `models.providers`.
|
||||
- Непорожній `baseUrl`, уже наявний в `models.json` агента, має пріоритет.
|
||||
- Непорожній `apiKey` у `models.json` агента має пріоритет лише тоді, коли цей провайдер не керується через SecretRef у поточному контексті конфігурації/профілю автентифікації.
|
||||
- Значення `apiKey` провайдера, якими керує SecretRef, оновлюються з маркерів джерела (`ENV_VAR_NAME` для env-посилань, `secretref-managed` для посилань file/exec) замість збереження розкритих секретів.
|
||||
- Значення заголовків провайдера, якими керує SecretRef, оновлюються з маркерів джерела (`secretref-env:ENV_VAR_NAME` для env-посилань, `secretref-managed` для посилань file/exec).
|
||||
- Порожні або відсутні `apiKey`/`baseUrl` агента переходять до конфігурації `models.providers`.
|
||||
- Інші поля провайдера оновлюються з конфігурації та нормалізованих даних каталогу.
|
||||
|
||||
Збереження маркерів є авторитетним щодо джерела: OpenClaw записує маркери з активного знімка конфігурації джерела (до визначення), а не з визначених значень секретів під час виконання.
|
||||
Це застосовується щоразу, коли OpenClaw повторно генерує `models.json`, зокрема в шляхах, ініційованих командами, таких як `openclaw agent`.
|
||||
Збереження маркерів є авторитетним щодо джерела: OpenClaw записує маркери з активного знімка конфігурації джерела (до розв’язання), а не з розв’язаних значень секретів часу виконання.
|
||||
Це застосовується щоразу, коли OpenClaw повторно генерує `models.json`, зокрема в шляхах, ініційованих командами, як-от `openclaw agent`.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Провайдери моделей](/uk/concepts/model-providers) — маршрутизація провайдерів і автентифікація
|
||||
- [Резервні варіанти моделей](/uk/concepts/model-failover) — ланцюжки резервних варіантів
|
||||
- [Резервне перемикання моделей](/uk/concepts/model-failover) — ланцюжки резервних варіантів
|
||||
- [Генерація зображень](/uk/tools/image-generation) — конфігурація моделі зображень
|
||||
- [Генерація музики](/uk/tools/music-generation) — конфігурація музичної моделі
|
||||
- [Генерація відео](/uk/tools/video-generation) — конфігурація відеомоделі
|
||||
|
||||
Loading…
Reference in New Issue
Block a user