Skip to main content
Crie um plugin de provedor para adicionar um provedor de modelos (LLM) ao OpenClaw: um catálogo de modelos, autenticação por chave de API e resolução dinâmica de modelos.
Ainda não conhece os plugins do OpenClaw? Leia primeiro Primeiros passos para entender a estrutura do pacote e a configuração do manifesto.
Os plugins de provedor adicionam modelos ao ciclo normal de inferência do OpenClaw. Se o modelo precisar ser executado por meio de um daemon de agente nativo que gerencie threads, Compaction ou eventos de ferramentas, combine o provedor com um harness de agente, em vez de colocar detalhes do protocolo do daemon no núcleo.

Passo a passo

1

Pacote e manifesto

Etapa 1: Pacote e manifesto

setup.providers[].envVars permite que o OpenClaw detecte credenciais sem carregar o runtime do seu plugin. Adicione providerAuthAliases quando uma variante do provedor precisar reutilizar a autenticação do id de outro provedor. modelSupport é opcional e permite que o OpenClaw carregue automaticamente seu plugin de provedor com base em ids abreviados de modelos, como acme-large, antes que os hooks de runtime existam. openclaw.compat e openclaw.build em package.json são obrigatórios para a publicação no ClawHub (openclaw.compat.pluginApi e openclaw.build.openclawVersion são os dois campos obrigatórios; minGatewayVersion usa openclaw.install.minHostVersion como alternativa quando omitido).
2

Registrar o provedor

Um provedor de texto mínimo precisa de id, label, auth e catalog. catalog é o hook de runtime/configuração pertencente ao provedor; ele pode chamar APIs ativas do fornecedor e retorna entradas de models.providers.
index.ts
registerModelCatalogProvider é a superfície mais recente do catálogo do plano de controle para interfaces de listagem, ajuda e seleção, abrangendo linhas de text, voice, image_generation, video_generation e music_generation. Mantenha as chamadas aos endpoints do fornecedor e o mapeamento das respostas no plugin; o OpenClaw gerencia o formato compartilhado das linhas, os rótulos de origem e a renderização da ajuda.Isso constitui um provedor funcional. Agora, os usuários podem executar openclaw onboard --acme-ai-api-key <key> e selecionar acme-ai/acme-large como modelo.

Descoberta de modelos em tempo real

Se o seu provedor expõe uma API no estilo /models, mantenha o endpoint específico do provedor e a projeção das linhas no seu plugin e use openclaw/plugin-sdk/provider-catalog-live-runtime para o ciclo de busca compartilhado. O auxiliar fornece buscas HTTP protegidas, cabeçalhos de autenticação do provedor, erros HTTP estruturados, cache com TTL e comportamento de fallback estático sem colocar políticas do provedor no núcleo do OpenClaw.Use buildLiveModelProviderConfig quando a API em tempo real informar apenas quais linhas do catálogo estático pertencentes ao provedor estão disponíveis no momento:
index.ts
Use getCachedLiveProviderModelRows quando a API do provedor retornar metadados mais detalhados e o plugin precisar projetar as linhas nas próprias definições de modelo do OpenClaw:
index.ts
run deve permanecer condicionado à autenticação e retornar null quando nenhuma credencial utilizável estiver disponível. Mantenha um staticRun offline ou um fallback estático para que a configuração, a documentação, os testes e as superfícies de seleção não dependam do acesso à rede em tempo real. Use um TTL adequado à atualização da lista de modelos, evite a sondagem do sistema de arquivos durante as solicitações e forneça readRows / readModelId específicos do provedor somente quando a resposta upstream não tiver um formato compatível com OpenAI { data: [{ id, object }] }.Se o provedor upstream usar tokens de controle diferentes dos do OpenClaw, adicione uma pequena transformação bidirecional de texto em vez de substituir o caminho de streaming:
input reescreve o prompt de sistema final e o conteúdo das mensagens de texto antes do transporte. output reescreve os deltas de texto do assistente e o texto final antes que o OpenClaw analise seus próprios marcadores de controle ou realize a entrega pelo canal.Para provedores integrados que registram apenas um provedor de texto com autenticação por chave de API e um único runtime baseado em catálogo, prefira o auxiliar mais específico defineSingleProviderPluginEntry(...):
buildProvider é o caminho do catálogo ativo usado quando o OpenClaw consegue resolver a autenticação real do provedor. Ele pode realizar uma descoberta específica do provedor. Use buildStaticProvider somente para linhas offline que possam ser exibidas com segurança antes que a autenticação seja configurada; ele não deve exigir credenciais nem fazer solicitações de rede. Atualmente, a exibição de models list --all do OpenClaw executa catálogos estáticos somente para plugins de provedor integrados, com configuração vazia, ambiente vazio e sem caminhos de agente/espaço de trabalho.Se o seu fluxo de autenticação também precisar modificar models.providers.*, aliases e o modelo padrão do agente durante a integração, use os auxiliares de predefinição de openclaw/plugin-sdk/provider-onboard. Os auxiliares mais específicos são createDefaultModelPresetAppliers(...), createDefaultModelsPresetAppliers(...) e createModelCatalogPresetAppliers(...).Quando o endpoint nativo de um provedor oferecer suporte a blocos de uso transmitidos no transporte openai-completions normal, prefira os auxiliares de catálogo compartilhados em openclaw/plugin-sdk/provider-catalog-shared em vez de codificar diretamente verificações de ID do provedor. supportsNativeStreamingUsageCompat(...) e applyProviderNativeStreamingUsageCompat(...) detectam o suporte pelo mapa de recursos do endpoint, portanto endpoints nativos no estilo Moonshot/DashScope ainda optam por esse comportamento mesmo quando um plugin usa um ID de provedor personalizado.Os exemplos de descoberta ativa acima abrangem APIs de provedores no estilo /models. Mantenha essa descoberta dentro de catalog.run, condicionada à disponibilidade de autenticação utilizável, e mantenha staticRun sem acesso à rede para a geração offline do catálogo.
3

Add dynamic model resolution

Se o seu provedor aceitar IDs de modelo arbitrários (como um proxy ou roteador), adicione resolveDynamicModel:
Se a resolução exigir uma chamada de rede, use prepareDynamicModel para o aquecimento assíncrono — resolveDynamicModel será executado novamente após a conclusão.
4

Add runtime hooks (as needed)

A maioria dos provedores precisa apenas de catalog + resolveDynamicModel. Adicione hooks gradualmente conforme as necessidades do seu provedor.Os construtores de auxiliares compartilhados agora abrangem as famílias mais comuns de compatibilidade de repetição/ferramentas, portanto os plugins geralmente não precisam conectar manualmente cada hook individualmente:
Famílias de repetição disponíveis atualmente:Famílias de transmissão disponíveis atualmente:
Cada construtor de família é composto por auxiliares públicos de nível inferior exportados pelo mesmo pacote, que você pode usar quando um provedor precisar sair do padrão comum:
  • openclaw/plugin-sdk/provider-model-sharedProviderReplayFamily, buildProviderReplayFamilyHooks(...) e os construtores de repetição brutos (buildOpenAICompatibleReplayPolicy, buildAnthropicReplayPolicyForModel, buildGoogleGeminiReplayPolicy, buildHybridAnthropicOrOpenAIReplayPolicy). Também exporta auxiliares de repetição do Gemini (sanitizeGoogleGeminiReplayHistory, resolveTaggedReasoningOutputMode) e auxiliares de endpoint/modelo (resolveProviderEndpoint, normalizeProviderId, normalizeGooglePreviewModelId).
  • openclaw/plugin-sdk/provider-streamProviderStreamFamily, buildProviderStreamFamilyHooks(...), composeProviderStreamWrappers(...), além dos wrappers compartilhados do OpenAI/Codex (createOpenAIAttributionHeadersWrapper, createOpenAIFastModeWrapper, createOpenAIServiceTierWrapper, createOpenAIResponsesContextManagementWrapper, createCodexNativeWebSearchWrapper), wrapper do DeepSeek V4 compatível com OpenAI (createDeepSeekV4OpenAICompatibleThinkingWrapper), limpeza do preenchimento prévio de raciocínio de mensagens da Anthropic (createAnthropicThinkingPrefillPayloadWrapper), compatibilidade de chamadas de ferramentas em texto simples (createPlainTextToolCallCompatWrapper) e wrappers compartilhados de proxy/provedor (createOpenRouterWrapper, createToolStreamWrapper, createMinimaxFastModeWrapper).
  • openclaw/plugin-sdk/provider-stream-shared — wrappers leves de carga útil e eventos para caminhos críticos de provedores, incluindo createOpenAICompatibleCompletionsThinkingOffWrapper, createPayloadPatchStreamWrapper, createPlainTextToolCallCompatWrapper, normalizeOpenAICompatibleReasoningPayload(...) e setQwenChatTemplateThinking(...).
  • openclaw/plugin-sdk/provider-toolsProviderToolCompatFamily, buildProviderToolCompatFamilyHooks("deepseek" | "gemini" | "openai") e os auxiliares subjacentes de esquema do provedor.
Para provedores da família Gemini, mantenha o modo de saída de raciocínio alinhado ao transporte. Provedores diretos da API Google Gemini devem usar a saída de raciocínio native para que o OpenClaw consuma partes nativas de pensamento sem adicionar diretivas de prompt <think> / <final>. Backends no estilo da CLI do Gemini, somente de texto, que analisam uma resposta final em JSON/texto podem manter o contrato marcado compartilhado google-gemini.Alguns auxiliares de transmissão permanecem locais ao provedor propositalmente. @openclaw/anthropic-provider mantém wrapAnthropicProviderStream, resolveAnthropicBetas, resolveAnthropicFastMode, resolveAnthropicServiceTier e os construtores de wrappers da Anthropic de nível inferior em sua própria interface pública api.ts / contract-api.ts, pois eles codificam o tratamento de betas do OAuth do Claude e a restrição de context1m. De forma semelhante, o plugin xAI mantém a formatação nativa de Responses da xAI em seu próprio wrapStreamFn (aliases de /fast, tool_stream padrão, limpeza de ferramentas estritas sem suporte e remoção de carga útil de raciocínio específica da xAI).O mesmo padrão de raiz de pacote também sustenta @openclaw/openai-provider (construtores de provedores, auxiliares de modelo padrão e construtores de provedores em tempo real) e @openclaw/openrouter-provider (construtor de provedor, além de auxiliares de integração/configuração).
Para provedores que precisam de uma troca de token antes de cada chamada de inferência:
O OpenClaw chama os hooks aproximadamente nesta ordem para plugins de modelo/provedor. A maioria dos provedores usa apenas 2 ou 3. Este não é o contrato completo de ProviderPlugin — consulte Aspectos internos: hooks de runtime do provedor para ver a lista completa e atualmente correta de hooks e as observações sobre fallback. Campos de provedor mantidos apenas para compatibilidade que o OpenClaw não chama mais, como ProviderPlugin.capabilities e suppressBuiltInModel, não estão listados aqui.Observações sobre fallback de runtime:
  • normalizeConfig resolve um plugin proprietário por ID de provedor (primeiro os provedores integrados e depois o plugin de runtime correspondente) e chama apenas esse hook — não há varredura entre outros provedores. O próprio hook normalizeConfig do Google é responsável por normalizar as entradas de configuração google / google-vertex / google-antigravity; ele não é um fallback separado do núcleo.
  • resolveConfigApiKey usa o hook do provedor quando ele é exposto. O Amazon Bedrock mantém a resolução de marcadores de variáveis de ambiente da AWS em seu plugin de provedor; a autenticação de runtime em si continua usando a cadeia padrão do AWS SDK quando configurada com auth: "aws-sdk".
  • resolveThinkingProfile(ctx) recebe o provider selecionado, o modelId, a dica opcional mesclada de catálogo reasoning e os fatos opcionais mesclados de compat do modelo. Use compat somente para selecionar a interface/perfil de pensamento do provedor.
  • resolveSystemPromptContribution permite que um provedor injete orientações de prompt do sistema sensíveis ao cache para uma família de modelos. Prefira-o ao hook legado before_prompt_build de todo o plugin quando o comportamento pertencer a uma família de provedor/modelo e precisar preservar a divisão estável/dinâmica do cache.
5

Adicionar recursos extras (opcional)

Etapa 5: adicionar recursos extras

Um plugin de provedor pode registrar embeddings, fala, transcrição em tempo real, voz em tempo real, compreensão de mídia, geração de imagens, geração de vídeos, busca de conteúdo web e pesquisa na web junto à inferência de texto. O OpenClaw classifica isso como um plugin de recursos híbridos — o padrão recomendado para plugins de empresas (um plugin por fornecedor). Consulte Aspectos internos: propriedade dos recursos.Registre cada recurso dentro de register(api) junto à chamada existente api.registerProvider(...). Escolha apenas as abas necessárias:
Use assertOkOrThrowProviderError(...) para falhas HTTP do provedor, de modo que os plugins compartilhem leituras limitadas do corpo do erro, análise de erros JSON e sufixos de ID da solicitação.
6

Testar

Etapa 6: Testar

src/provider.test.ts

Publicar no ClawHub

Plugins de provedor são publicados da mesma forma que qualquer outro Plugin externo de código:
clawhub skill publish <path> é um comando diferente para publicar uma pasta de skill, não um pacote de Plugin — não o use aqui.

Estrutura de arquivos

catalog.order controla quando seu catálogo é mesclado em relação aos provedores integrados:

Próximas etapas

Relacionado