Цей посібник показує, як створити Plugin провайдера, який додає провайдера моделей (LLM) до OpenClaw. Наприкінці у вас буде провайдер із каталогом моделей, автентифікацією через API-ключ і динамічним визначенням моделей.Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Якщо ви ще не створювали жоден Plugin для OpenClaw, спершу прочитайте
Початок роботи, щоб ознайомитися з базовою
структурою пакета та налаштуванням маніфесту.
Покроковий посібник
Пакет і маніфест
Крок 1: Пакет і маніфест
providerAuthEnvVars, щоб OpenClaw міг виявляти
облікові дані без завантаження runtime вашого Plugin. Додайте
providerAuthAliases, коли варіант провайдера має повторно використовувати
автентифікацію ідентифікатора іншого провайдера. modelSupport
є необов’язковим і дає OpenClaw змогу автоматично завантажувати Plugin
вашого провайдера за скороченими ідентифікаторами моделей на кшталт
acme-large ще до появи runtime-хуків. Якщо ви публікуєте провайдера
на ClawHub, ці поля openclaw.compat і openclaw.build є обов’язковими
в package.json.Зареєструйте провайдера
Мінімальному текстовому провайдеру потрібні
id, label, auth і catalog.
catalog — це runtime/config-хук, яким володіє провайдер; він може викликати
live API постачальника та повертати записи models.providers.index.ts
registerModelCatalogProvider — це новіша поверхня каталогу рівня керування
для інтерфейсу списків, довідки та вибору. Використовуйте її для рядків
text, image-generation, video-generation і music-generation. Залишайте
виклики endpoint постачальника та мапінг відповідей у Plugin; OpenClaw
володіє спільною формою рядків, мітками джерел і рендерингом довідки.Це вже робочий провайдер. Тепер користувачі можуть виконати
openclaw onboard --acme-ai-api-key <key> і вибрати
acme-ai/acme-large як свою модель.Якщо upstream-провайдер використовує інші керівні токени, ніж OpenClaw,
додайте невелике двонапрямне текстове перетворення замість заміни
шляху стримінгу:input переписує фінальний системний prompt і вміст текстових повідомлень
перед передаванням. output переписує текстові дельти асистента та фінальний
текст до того, як OpenClaw розбере власні керівні маркери або доставку
каналом.Для вбудованих провайдерів, які реєструють лише одного текстового провайдера
з автентифікацією через API-ключ і одним runtime на базі каталогу, віддавайте
перевагу вужчому допоміжному методу defineSingleProviderPluginEntry(...):buildProvider — це шлях live-каталогу, який використовується, коли OpenClaw
може визначити реальну автентифікацію провайдера. Він може виконувати
специфічне для провайдера виявлення. Використовуйте buildStaticProvider
лише для офлайн-рядків, які безпечно показувати до налаштування
автентифікації; він не повинен вимагати облікових даних або виконувати
мережеві запити. Відображення OpenClaw models list --all наразі виконує
статичні каталоги лише для вбудованих Plugin-ів провайдерів, із порожньою
конфігурацією, порожнім env і без шляхів агента/робочого простору.Якщо вашому потоку автентифікації також потрібно змінювати
models.providers.*, псевдоніми та модель агента за замовчуванням під час
onboarding, використовуйте preset-допоміжні методи з
openclaw/plugin-sdk/provider-onboard. Найвужчі допоміжні методи:
createDefaultModelPresetAppliers(...),
createDefaultModelsPresetAppliers(...) і
createModelCatalogPresetAppliers(...).Коли нативний endpoint провайдера підтримує блоки використання у стримінгу
на звичайному транспорті openai-completions, віддавайте перевагу спільним
допоміжним методам каталогу в
openclaw/plugin-sdk/provider-catalog-shared замість жорстко закодованих
перевірок ідентифікатора провайдера. supportsNativeStreamingUsageCompat(...)
і applyProviderNativeStreamingUsageCompat(...) визначають підтримку з мапи
можливостей endpoint, тож нативні endpoint-и у стилі Moonshot/DashScope усе
ще вмикаються, навіть коли Plugin використовує власний ідентифікатор
провайдера.Додайте динамічне визначення моделей
Якщо ваш провайдер приймає довільні ідентифікатори моделей (як proxy або
router), додайте Якщо для визначення потрібен мережевий виклик, використовуйте
resolveDynamicModel:prepareDynamicModel для асинхронного прогрівання — resolveDynamicModel
запускається знову після його завершення.Додайте runtime-хуки (за потреби)
Більшості провайдерів потрібні лише Доступні сьогодні сімейства replay:
Доступні сьогодні сімейства потоків:
catalog + resolveDynamicModel.
Додавайте хуки поступово, коли вони потрібні вашому провайдеру.Спільні допоміжні builder-и тепер покривають найпоширеніші сімейства
replay/tool-compat, тож Plugin-ам зазвичай не потрібно вручну під’єднувати
кожен хук окремо:| Сімейство | Що підключає | Вбудовані приклади |
|---|---|---|
openai-compatible | Спільна політика повторного відтворення у стилі OpenAI для OpenAI-сумісних транспортів, зокрема очищення tool-call-id, виправлення порядку assistant-first і загальна валідація ходів Gemini там, де вона потрібна транспорту | moonshot, ollama, xai, zai |
anthropic-by-model | Політика повторного відтворення з урахуванням Claude, вибрана за modelId, щоб транспорти Anthropic-message отримували очищення блоків мислення, специфічне для Claude, лише коли розв’язана модель справді має ідентифікатор Claude | amazon-bedrock, anthropic-vertex |
google-gemini | Нативна політика повторного відтворення Gemini, а також очищення початкового повторного відтворення і режим позначеного виводу reasoning | google, google-gemini-cli |
passthrough-gemini | Очищення thought-signature Gemini для моделей Gemini, що працюють через OpenAI-сумісні проксі-транспорти; не вмикає нативну валідацію повторного відтворення Gemini або переписування початкового завантаження | openrouter, kilocode, opencode, opencode-go |
hybrid-anthropic-openai | Гібридна політика для провайдерів, які поєднують поверхні моделей Anthropic-message і OpenAI-сумісні поверхні моделей в одному plugin; необов’язкове скидання блоків мислення лише для Claude залишається обмеженим стороною Anthropic | minimax |
| Сімейство | Що підключає | Вбудовані приклади |
|---|---|---|
google-thinking | Нормалізація payload мислення Gemini на спільному шляху потоку | google, google-gemini-cli |
kilocode-thinking | Обгортка reasoning Kilo на спільному шляху проксі-потоку, де kilo/auto і непідтримувані ідентифікатори proxy reasoning пропускають ін’єктоване мислення | kilocode |
moonshot-thinking | Відображення бінарного нативного payload мислення Moonshot з конфігурації + рівня /think | moonshot |
minimax-fast-mode | Переписування моделі fast-mode MiniMax на спільному шляху потоку | minimax, minimax-portal |
openai-responses-defaults | Спільні нативні обгортки OpenAI/Codex Responses: заголовки атрибуції, /fast/serviceTier, докладність тексту, нативний вебпошук Codex, формування payload сумісності reasoning і керування контекстом Responses | openai, openai-codex |
openrouter-thinking | Обгортка reasoning OpenRouter для проксі-маршрутів, із централізованою обробкою пропусків для непідтримуваних моделей/auto | openrouter |
tool-stream-default-on | Обгортка tool_stream, увімкнена за замовчуванням, для провайдерів на кшталт Z.AI, які хочуть потокове передавання інструментів, якщо його явно не вимкнено | zai |
Шви SDK, що забезпечують роботу побудовників сімейств
Шви SDK, що забезпечують роботу побудовників сімейств
Кожен побудовник сімейства складений із нижчорівневих публічних допоміжних функцій, експортованих із того самого пакета, до яких можна звернутися, коли провайдеру потрібно відійти від спільного шаблону:
openclaw/plugin-sdk/provider-model-shared-ProviderReplayFamily,buildProviderReplayFamilyHooks(...), і сирі побудовники повторного відтворення (buildOpenAICompatibleReplayPolicy,buildAnthropicReplayPolicyForModel,buildGoogleGeminiReplayPolicy,buildHybridAnthropicOrOpenAIReplayPolicy). Також експортує допоміжні функції повторного відтворення Gemini (sanitizeGoogleGeminiReplayHistory,resolveTaggedReasoningOutputMode) і допоміжні функції endpoint/model (resolveProviderEndpoint,normalizeProviderId,normalizeGooglePreviewModelId).openclaw/plugin-sdk/provider-stream-ProviderStreamFamily,buildProviderStreamFamilyHooks(...),composeProviderStreamWrappers(...), а також спільні обгортки OpenAI/Codex (createOpenAIAttributionHeadersWrapper,createOpenAIFastModeWrapper,createOpenAIServiceTierWrapper,createOpenAIResponsesContextManagementWrapper,createCodexNativeWebSearchWrapper), OpenAI-сумісна обгортка DeepSeek V4 (createDeepSeekV4OpenAICompatibleThinkingWrapper), очищення префілу мислення Anthropic Messages (createAnthropicThinkingPrefillPayloadWrapper) і спільні проксі/провайдерські обгортки (createOpenRouterWrapper,createToolStreamWrapper,createMinimaxFastModeWrapper).openclaw/plugin-sdk/provider-tools-ProviderToolCompatFamily,buildProviderToolCompatFamilyHooks("gemini")і базові допоміжні функції схем Gemini (normalizeGeminiToolSchemas,inspectGeminiToolSchemas).
@openclaw/anthropic-provider тримає wrapAnthropicProviderStream, resolveAnthropicBetas, resolveAnthropicFastMode, resolveAnthropicServiceTier і нижчорівневі побудовники обгорток Anthropic у власному публічному шві api.ts / contract-api.ts, тому що вони кодують обробку Claude OAuth beta і gating context1m. Plugin xAI так само тримає нативне формування xAI Responses у власному wrapStreamFn (аліаси /fast, стандартний tool_stream, очищення непідтримуваного strict-tool, вилучення reasoning-payload, специфічне для xAI).Такий самий шаблон package-root також підтримує @openclaw/openai-provider (побудовники провайдера, допоміжні функції моделі за замовчуванням, побудовники realtime-провайдера) і @openclaw/openrouter-provider (побудовник провайдера плюс допоміжні функції onboarding/config).- Обмін токенів
- Власні заголовки
- Нативна ідентичність транспорту
- Використання та білінг
Для провайдерів, яким потрібен обмін токена перед кожним викликом inference:
Усі доступні hooks провайдера
Усі доступні hooks провайдера
OpenClaw викликає hooks у такому порядку. Більшість провайдерів використовують лише 2-3:
Поля провайдера лише для сумісності, які OpenClaw більше не викликає, як-от
Примітки щодо runtime fallback:
ProviderPlugin.capabilities і suppressBuiltInModel, тут не перелічені.| # | Hook | Коли використовувати |
|---|---|---|
| 1 | catalog | Каталог моделей або стандартні значення базового URL |
| 2 | applyConfigDefaults | Глобальні стандартні значення, якими володіє провайдер, під час матеріалізації конфігурації |
| 3 | normalizeModelId | Очищення застарілих/preview псевдонімів model-id перед пошуком |
| 4 | normalizeTransport | Очищення api / baseUrl сімейства провайдера перед загальною збіркою моделі |
| 5 | normalizeConfig | Нормалізація конфігурації models.providers.<id> |
| 6 | applyNativeStreamingUsageCompat | Переписування сумісності нативного streaming-usage для конфігураційних провайдерів |
| 7 | resolveConfigApiKey | Розв’язання auth env-marker, яким володіє провайдер |
| 8 | resolveSyntheticAuth | Синтетичний auth для локальних/self-hosted або config-backed випадків |
| 9 | shouldDeferSyntheticProfileAuth | Пониження synthetic stored-profile placeholders після env/config auth |
| 10 | resolveDynamicModel | Приймати довільні ідентифікатори upstream моделей |
| 11 | prepareDynamicModel | Асинхронне отримання метаданих перед розв’язанням |
| 12 | normalizeResolvedModel | Переписування транспорту перед runner |
| 13 | contributeResolvedModelCompat | Прапорці сумісності для vendor моделей за іншим сумісним транспортом |
| 14 | normalizeToolSchemas | Очищення tool-schema, яким володіє провайдер, перед реєстрацією |
| 15 | inspectToolSchemas | Діагностика tool-schema, якою володіє провайдер |
| 16 | resolveReasoningOutputMode | Контракт tagged vs native reasoning-output |
| 17 | prepareExtraParams | Стандартні параметри запиту |
| 18 | createStreamFn | Повністю власний транспорт StreamFn |
| 19 | wrapStreamFn | Власні обгортки заголовків/тіла на звичайному шляху потоку |
| 20 | resolveTransportTurnState | Нативні заголовки/метадані для кожного ходу |
| 21 | resolveWebSocketSessionPolicy | Нативні заголовки сеансу WS/cool-down |
| 22 | formatApiKey | Власна форма runtime-токена |
| 23 | refreshOAuth | Власне оновлення OAuth |
| 24 | buildAuthDoctorHint | Підказки щодо відновлення auth |
| 25 | matchesContextOverflowError | Виявлення overflow, яким володіє провайдер |
| 26 | classifyFailoverReason | Класифікація rate-limit/overload, якою володіє провайдер |
| 27 | isCacheTtlEligible | Gating TTL кешу prompt |
| 28 | buildMissingAuthMessage | Власна підказка щодо відсутнього auth |
| 29 | augmentModelCatalog | Синтетичні рядки forward-compat |
| 30 | resolveThinkingProfile | Набір опцій /think, специфічний для моделі |
| 31 | isBinaryThinking | Сумісність двійкового увімкнення/вимкнення мислення |
| 32 | supportsXHighThinking | Сумісність підтримки reasoning xhigh |
| 33 | resolveDefaultThinkingLevel | Сумісність стандартної політики /think |
| 34 | isModernModelRef | Зіставлення моделей live/smoke |
| 35 | prepareRuntimeAuth | Обмін токена перед inference |
| 36 | resolveUsageAuth | Власний розбір облікових даних usage |
| 37 | fetchUsageSnapshot | Власний endpoint usage |
| 38 | createEmbeddingProvider | Адаптер embeddings для memory/search, яким володіє провайдер |
| 39 | buildReplayPolicy | Власна політика повторного відтворення/Compaction transcript |
| 40 | sanitizeReplayHistory | Специфічні для провайдера переписування replay після загального очищення |
| 41 | validateReplayTurns | Сувора валідація replay-turn перед вбудованим runner |
| 42 | onModelSelected | Callback після вибору (наприклад, telemetry) |
normalizeConfigспершу перевіряє зіставленого провайдера, а потім інші provider plugins із підтримкою hooks, доки один із них справді не змінить конфігурацію. Якщо жоден hook провайдера не переписує підтримуваний запис конфігурації сімейства Google, вбудований нормалізатор конфігурації Google усе одно застосовується.resolveConfigApiKeyвикористовує hook провайдера, коли його надано. Вбудований шляхamazon-bedrockтакож має тут вбудований resolver AWS env-marker, хоча сам runtime auth Bedrock усе ще використовує стандартний ланцюг AWS SDK.resolveSystemPromptContributionдає провайдеру змогу вставити cache-aware підказки system-prompt для сімейства моделей. Віддавайте йому перевагу надbefore_prompt_build, коли поведінка належить одному провайдеру/сімейству моделей і має зберегти стабільне/динамічне розділення кешу.
Додайте додаткові можливості (необов’язково)
Крок 5: Додайте додаткові можливості
Плагін провайдера може реєструвати мовлення, транскрипцію в реальному часі, голос у реальному часі, розуміння медіа, генерацію зображень, генерацію відео, веботримання та вебпошук разом із текстовим інференсом. OpenClaw класифікує це як плагін із гібридними можливостями — рекомендований патерн для плагінів компаній (один плагін на постачальника). Див. Внутрішнє: володіння можливостями.Реєструйте кожну можливість уregister(api) поруч із наявним викликом
api.registerProvider(...). Виберіть лише потрібні вкладки:- Мовлення (TTS)
- Транскрипція в реальному часі
- Голос у реальному часі
- Розуміння медіа
- Генерація зображень і відео
- Веботримання та пошук
assertOkOrThrowProviderError(...) для HTTP-збоїв провайдера, щоб
плагіни спільно використовували обмежене читання тіла помилки, парсинг помилок JSON і
суфікси ідентифікаторів запитів.Тест
Крок 6: Тест
src/provider.test.ts
Публікація в ClawHub
Плагіни провайдерів публікуються так само, як і будь-який інший зовнішній кодовий плагін:clawhub package publish.
Структура файлів
Довідник порядку каталогу
catalog.order контролює, коли ваш каталог об’єднується відносно вбудованих
провайдерів:
| Порядок | Коли | Випадок використання |
|---|---|---|
simple | Перший прохід | Звичайні провайдери API-ключів |
profile | Після simple | Провайдери, обмежені профілями автентифікації |
paired | Після profile | Синтез кількох пов’язаних записів |
late | Останній прохід | Перевизначення наявних провайдерів (перемагає в разі конфлікту) |
Наступні кроки
- Плагіни каналів — якщо ваш плагін також надає канал
- SDK Runtime — помічники
api.runtime(TTS, пошук, субагент) - Огляд SDK — повний довідник імпорту підшляхів
- Внутрішнє Plugin — подробиці хуків і вбудовані приклади