Модели OpenClaw: выбор провайдера, настройка и проверка

Короткий ответ

В OpenClaw модель задаётся ссылкой вида provider/model. Она определяет провайдера и конкретную модель, но сама по себе не выдаёт доступ и не гарантирует, что runtime сможет выполнить запрос. По умолчанию OpenClaw использует основную модель (primary), затем настроенные резервные модели (fallbacks), а внутри провайдера может применять смену auth-профиля. Для выбора модели важно разделять четыре вещи: наличие модели в каталоге, разрешение политикой, действующую аутентификацию и фактическую совместимость с runtime.

Практически начинайте не с самой большой или самой новой модели, а с одного бизнес-сценария и контрольной выборки. Сравните качество, задержку, стоимость, требования к приватности и поведение при сбое. Значимые действия агента оставьте под подтверждением человека.

Как устроен выбор модели

Основной порядок выбора в конфигурации выглядит так:

1. agents.defaults.model.primary — исходная модель по умолчанию.
2. agents.defaults.model.fallbacks — резервные модели в заданном порядке.
3. Auth failover — смена профиля аутентификации внутри провайдера до перехода к следующей fallback-модели.

Модель можно выбирать и на уровне сессии через Control UI, /model, session_status(model=...) или sessions.patch. Важная оговорка: ручной выбор пользователя является строгим. Если явно выбранная модель недоступна, OpenClaw не обязан незаметно перейти на другую модель. Для автоматического восстановления используйте именно настроенный fallback-сценарий, а не рассчитывайте на ручной override.

Существующие сессии могут сохранять выбранную модель. Изменение primary не обязательно переписывает уже закреплённый выбор; при необходимости закрепление нужно снять через /model default.

Провайдер, доступ и политика разрешений

OpenClaw поддерживает hosted и local model providers. В onboarding можно настроить распространённые варианты доступа: существующий вход Claude Code или Codex CLI либо API key провайдера. README также описывает модели и agent harnesses как заменяемые компоненты, но это не означает, что любой провайдер или runtime совместим с любой моделью.

Проверяйте отдельно:

• есть ли у аккаунта право использовать выбранную модель;
• какой credential нужен: API key, OAuth или вход конкретного CLI;
• поддерживает ли выбранный runtime нужный тип запроса и инструменты;
• не ограничивает ли модель политика agents.defaults.modelPolicy.allow;
• соответствует ли точная ссылка формату provider/model.

Если allowlist задан, он может содержать точные ссылки или префиксы вроде provider/*. Для локальных вариантов документация приводит provider-prefixed refs, например ollama/gemma4:26b или lmstudio/Gemma4-26b-a4-it-gguf; это примеры формата, а не гарантия работы конкретной модели в вашей среде. Проверяйте точную строку через список моделей и тестовый запрос.

Как просматривать и настраивать модели

Начните с onboarding:

openclaw onboard

Он предназначен для настройки модели и авторизации без ручного редактирования конфигурации. После изменения credentials или конфигурации проверьте каталог моделей и состояние Gateway.

Для просмотра используйте предусмотренную команду:

openclaw models list
openclaw models list --all
openclaw models list --refresh

--all нужен, когда требуется просмотреть полный встроенный каталог, включая скрытые или устаревшие строки. --refresh запрашивает новое обнаружение моделей у провайдеров. В Control UI список моделей также можно обновить через явное действие Refresh.

В конфигурации можно задать основную и резервные модели. Пример структуры:

{
  agents: {
    defaults: {
      model: {
        primary: "provider/primary-model",
        fallbacks: ["provider/backup-model"],
      },
    },
  },
}

Перед применением замените refs на реальные значения из вашей среды. Не копируйте пример как готовый универсальный provider.

Allowlist и типичная ошибка «model is not allowed»

Каталог моделей и политика разрешений — разные механизмы. Модель может не отображаться в обычном picker, но быть доступной по точной ссылке, если политика не ограничивает выбор. И наоборот, модель из каталога будет отклонена, если она не разрешена modelPolicy.allow.

Пример ограничительной политики:

{
  agents: {
    defaults: {
      modelPolicy: {
        allow: ["openai/*", "vllm/*"],
      },
    },
  },
}

Точную политику можно задать CLI-командой:

openclaw config set agents.defaults.modelPolicy.allow '["openai/gpt-5.4","anthropic/*"]' --strict-json

Если появляется ошибка model is not allowed, сначала проверьте полное имя provider/model и allowlist. Добавьте точный ref, подходящий префикс или уберите ограничение, если политика действительно не нужна. Но разрешение в allowlist не заменяет credentials и не делает неподдерживаемый runtime рабочим.

Проверка после настройки

Проверку разделите на три уровня.

1. Технический доступ. Убедитесь, что CLI и Gateway работают:

openclaw --version
openclaw doctor
openclaw gateway status

После onboarding откройте Control UI и отправьте тестовое сообщение. Документация описывает проверку доступа к модели реальным completion во время onboarding; одного сохранённого ключа недостаточно.

2. Корректность выбора. Зафиксируйте точный provider/model, фактический auth-профиль, версию конфигурации и результат ответа. Убедитесь, что сессия не закреплена за старой моделью, а fallback настроен там, где он действительно нужен.

3. Поведение сценария. Прогоните обычные, неполные, неоднозначные и запрещённые входы. Проверьте, что модель извлекает обязательные поля, не выполняет неподтверждённое действие и передаёт спорный случай человеку. Для инструментоёмкого сценария отдельно проверяйте поддержку инструментов и формат ошибок.

Если каталог провайдера не обновился, команда просмотра и Settings > Models могут показать ошибку discovery и сохранить последний совместимый список. Не считайте старый список доказательством текущей доступности: выполните Refresh и тестовый запрос.

Алгоритм выбора модели для бизнеса

Используйте последовательность:

1. Опишите результат. Нужен свободный ответ, структурированное извлечение, работа с изображениями, вызов инструмента или подготовка черновика?
2. Определите риск ошибки. Для финансовых, юридических и клиентских действий задайте обязательную проверку человеком.
3. Соберите ограничения данных. Определите, какие сведения можно отправлять внешнему провайдеру, а какие требуют локального или отдельно согласованного контура.
4. Выберите кандидатов. Возьмите основную модель и одну-две резервные, которые действительно доступны аккаунту и совместимы с нужным runtime.
5. Проверьте качество. Используйте одинаковую контрольную выборку и заранее определённые правильные ответы или допустимые варианты.
6. Измерьте эксплуатацию. Сравните задержку, расход токенов или стоимость по данным провайдера, частоту ошибок и долю эскалаций.
7. Настройте отказоустойчивость. Укажите порядок fallback, проверьте отказ primary и определите, когда задача останавливается вместо автоматического продолжения.
8. Зафиксируйте решение. Запишите модель, provider, credentials, ограничения данных, дату проверки и условия пересмотра.

Для простого извлечения полей может оказаться достаточной менее дорогая модель, если она проходит тесты. Для задач с инструментами и недоверенными входами выбирайте вариант, который подтверждён для нужного runtime, и не расширяйте права только ради более самостоятельного поведения модели.

Что сравнивать: качество, стоимость, приватность и резерв

Качество. Считайте не общее впечатление от диалога, а точность обязательных полей, корректность классификации, следование формату и число критичных ошибок.

Стоимость. Учитывайте цену конкретного провайдера, объём входа и выхода, повторные запросы и fallback. В переданных материалах нет актуальной таблицы цен, поэтому стоимость нужно считать по выбранному аккаунту и тарифу.

Приватность. Hosted-модель отправляет запросы провайдеру, а локальный вариант меняет контур размещения, но не снимает требования к защите хоста, журналов и credentials. Подтвердите правила хранения и обработки данных у выбранного провайдера; не делайте вывод о приватности только из слова «локальная».

Задержка. Измеряйте время до первого ответа и полное время завершения типовой задачи. Для автоматизации с человеком в контуре это влияет на длительность проверки.

Резерв. Fallback должен быть не просто записан в конфигурации: проверьте отказ primary, сохранение контекста, различия результата и необходимость ручной остановки. Резервная модель может иметь другое качество, формат инструментов или ограничения контекста.

Как начать безопасный пилот

Для бизнеса достаточно начать с одного процесса: например, классифицировать обращения и подготовить черновик ответа без автоматической отправки. Зафиксируйте входные данные, ожидаемый формат, запрещённые действия и владельца проверки.

Проведите тесты на обезличенных примерах:

• обычное обращение;
• неполные или противоречивые данные;
• запрос вне области ответственности;
• повторная отправка одного входа;
• недоступность primary;
• ошибка авторизации;
• попытка выполнить действие без подтверждения.

Расширяйте доступ только если контрольная выборка проходит критерии приёмки, ошибки видны в журнале, а сотрудники понимают, когда результат нельзя принимать автоматически. Paramiko предлагает помочь описать один процесс, согласовать доступы, действия человека и обработку ошибок, а затем проверить ограниченный пилот на примерах заказчика. Это предложение подхода, а не утверждение о готовой совместимости, выполненном кейсе, цене или сроке.