本指南介绍如何构建一个提供商插件,为 OpenClaw 添加模型提供商 (LLM)。完成后,你将拥有一个带有模型目录、API key 认证和动态模型解析的提供商。Documentation Index
Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
如果你之前没有构建过任何 OpenClaw 插件,请先阅读
入门指南,了解基本的包结构和清单设置。
演练
包和清单
第 1 步:包和清单
providerAuthEnvVars,因此 OpenClaw 可以在不加载你的插件运行时的情况下
检测凭证。当某个提供商变体应复用另一个提供商 ID 的认证时,请添加 providerAuthAliases。
modelSupport 是可选的,它让 OpenClaw 能够在运行时钩子存在之前,
根据 acme-large 这样的简写模型 ID 自动加载你的提供商插件。如果你在
ClawHub 上发布该提供商,则 package.json 中必须包含这些 openclaw.compat 和
openclaw.build 字段。注册提供商
一个最小文本提供商需要
id、label、auth 和 catalog。
catalog 是由提供商拥有的运行时/配置钩子;它可以调用实时
供应商 API,并返回 models.providers 条目。index.ts
registerModelCatalogProvider 是用于列表/帮助/选择器 UI 的较新控制平面目录接口。
请将它用于文本、图像生成、视频生成和音乐生成行。把供应商端点调用和
响应映射保留在插件中;OpenClaw 负责共享的行形状、来源标签和帮助渲染。这就是一个可工作的提供商。用户现在可以运行
openclaw onboard --acme-ai-api-key <key>,并选择
acme-ai/acme-large 作为他们的模型。如果上游提供商使用的控制标记与 OpenClaw 不同,请添加一个
小型双向文本转换,而不是替换流路径:input 会在传输前重写最终系统提示词和文本消息内容。
output 会在 OpenClaw 解析自己的控制标记或进行渠道投递前,
重写助手文本增量和最终文本。对于只注册一个带 API-key 认证且由单一目录支持运行时的内置提供商,
优先使用更窄的 defineSingleProviderPluginEntry(...) 辅助函数:buildProvider 是当 OpenClaw 能够解析真实提供商认证时使用的实时目录路径。
它可以执行提供商特定的发现。仅将 buildStaticProvider 用于在配置认证之前
可以安全显示的离线行;它不得要求凭证或发起网络请求。
OpenClaw 的 models list --all 显示目前只对内置提供商插件执行静态目录,
并使用空配置、空环境,以及无智能体/工作区路径。如果你的认证流程还需要在新手引导期间修补 models.providers.*、别名和
智能体默认模型,请使用 openclaw/plugin-sdk/provider-onboard 中的预设辅助函数。
最窄的辅助函数是 createDefaultModelPresetAppliers(...)、
createDefaultModelsPresetAppliers(...) 和
createModelCatalogPresetAppliers(...)。当提供商的原生端点在常规 openai-completions 传输上支持流式用量块时,
请优先使用 openclaw/plugin-sdk/provider-catalog-shared 中的共享目录辅助函数,
而不是硬编码提供商 ID 检查。supportsNativeStreamingUsageCompat(...) 和
applyProviderNativeStreamingUsageCompat(...) 会根据端点能力映射检测支持情况,
因此原生 Moonshot/DashScope 风格端点即使使用自定义提供商 ID 的插件,
仍然可以选择启用。添加动态模型解析
如果你的提供商接受任意模型 ID(例如代理或路由器),
请添加 如果解析需要网络调用,请使用
resolveDynamicModel:prepareDynamicModel 进行异步预热 -
它完成后会再次运行 resolveDynamicModel。添加运行时钩子(按需)
大多数提供商只需要 当前可用的重放系列:
当前可用的流系列:
catalog + resolveDynamicModel。请随着提供商需求
逐步添加钩子。共享辅助构建器现在覆盖了最常见的重放/工具兼容系列,
因此插件通常不需要逐个手动连接每个钩子:| 系列 | 接入内容 | 内置示例 |
|---|---|---|
openai-compatible | 面向 OpenAI 兼容传输协议的共享 OpenAI 风格重放策略,包括工具调用 ID 清理、assistant 优先顺序修复,以及在传输协议需要时进行通用 Gemini 轮次验证 | moonshot, ollama, xai, zai |
anthropic-by-model | 根据 modelId 选择的 Claude 感知重放策略,因此只有当解析出的模型确实是 Claude ID 时,Anthropic 消息传输协议才会获得 Claude 专属 thinking-block 清理 | amazon-bedrock, anthropic-vertex |
google-gemini | 原生 Gemini 重放策略,加上引导重放清理和带标签的推理输出模式 | google, google-gemini-cli |
passthrough-gemini | 通过 OpenAI 兼容代理传输协议运行的 Gemini 模型的 Gemini thought-signature 清理;不会启用原生 Gemini 重放验证或引导重写 | openrouter, kilocode, opencode, opencode-go |
hybrid-anthropic-openai | 适用于在一个插件中混合 Anthropic 消息和 OpenAI 兼容模型表面的提供商的混合策略;可选的仅限 Claude 的 thinking-block 丢弃仍限定在 Anthropic 侧 | minimax |
| 系列 | 接入内容 | 内置示例 |
|---|---|---|
google-thinking | 共享流路径上的 Gemini thinking 载荷规范化 | google, google-gemini-cli |
kilocode-thinking | 共享代理流路径上的 Kilo 推理包装器,kilo/auto 和不受支持的代理推理 ID 会跳过注入式 thinking | kilocode |
moonshot-thinking | 根据配置 + /think 级别映射 Moonshot 二进制原生 thinking 载荷 | moonshot |
minimax-fast-mode | 共享流路径上的 MiniMax fast-mode 模型重写 | minimax, minimax-portal |
openai-responses-defaults | 共享的原生 OpenAI/Codex Responses 包装器:归因标头、/fast/serviceTier、文本详细程度、原生 Codex Web 搜索、推理兼容载荷整形,以及 Responses 上下文管理 | openai, openai-codex |
openrouter-thinking | 面向代理路由的 OpenRouter 推理包装器,集中处理不受支持模型/auto 跳过 | openrouter |
tool-stream-default-on | 面向 Z.AI 等提供商的默认开启 tool_stream 包装器,除非显式禁用,否则启用工具流式传输 | zai |
为系列构建器提供支持的 SDK 接缝
为系列构建器提供支持的 SDK 接缝
每个系列构建器都由同一包导出的更低层级公共辅助函数组成。当提供商需要偏离通用模式时,你可以使用这些辅助函数:
openclaw/plugin-sdk/provider-model-shared-ProviderReplayFamily、buildProviderReplayFamilyHooks(...),以及原始重放构建器(buildOpenAICompatibleReplayPolicy、buildAnthropicReplayPolicyForModel、buildGoogleGeminiReplayPolicy、buildHybridAnthropicOrOpenAIReplayPolicy)。还导出 Gemini 重放辅助函数(sanitizeGoogleGeminiReplayHistory、resolveTaggedReasoningOutputMode)和端点/模型辅助函数(resolveProviderEndpoint、normalizeProviderId、normalizeGooglePreviewModelId)。openclaw/plugin-sdk/provider-stream-ProviderStreamFamily、buildProviderStreamFamilyHooks(...)、composeProviderStreamWrappers(...),以及共享 OpenAI/Codex 包装器(createOpenAIAttributionHeadersWrapper、createOpenAIFastModeWrapper、createOpenAIServiceTierWrapper、createOpenAIResponsesContextManagementWrapper、createCodexNativeWebSearchWrapper)、DeepSeek V4 OpenAI 兼容包装器(createDeepSeekV4OpenAICompatibleThinkingWrapper)、Anthropic Messages thinking 预填清理(createAnthropicThinkingPrefillPayloadWrapper),以及共享代理/提供商包装器(createOpenRouterWrapper、createToolStreamWrapper、createMinimaxFastModeWrapper)。openclaw/plugin-sdk/provider-tools-ProviderToolCompatFamily、buildProviderToolCompatFamilyHooks("gemini"),以及底层 Gemini schema 辅助函数(normalizeGeminiToolSchemas、inspectGeminiToolSchemas)。
@openclaw/anthropic-provider 将 wrapAnthropicProviderStream、resolveAnthropicBetas、resolveAnthropicFastMode、resolveAnthropicServiceTier,以及更低层级的 Anthropic 包装器构建器保留在自己的公共 api.ts / contract-api.ts 接缝中,因为它们编码了 Claude OAuth beta 处理和 context1m 门控。xAI 插件同样将原生 xAI Responses 整形保留在自己的 wrapStreamFn 中(/fast 别名、默认 tool_stream、不受支持的 strict-tool 清理、xAI 专属推理载荷移除)。同样的包根模式也支持 @openclaw/openai-provider(提供商构建器、默认模型辅助函数、实时提供商构建器)和 @openclaw/openrouter-provider(提供商构建器以及新手引导/配置辅助函数)。- 令牌交换
- 自定义标头
- 原生传输身份
- 用量和计费
对于需要在每次推理调用前进行令牌交换的提供商:
所有可用的提供商钩子
所有可用的提供商钩子
OpenClaw 按以下顺序调用钩子。大多数提供商只使用 2-3 个:
OpenClaw 不再调用的仅兼容提供商字段,例如
运行时回退说明:
ProviderPlugin.capabilities 和 suppressBuiltInModel,未在此列出。| # | 钩子 | 使用时机 |
|---|---|---|
| 1 | catalog | 模型目录或基础 URL 默认值 |
| 2 | applyConfigDefaults | 配置物化期间由提供商拥有的全局默认值 |
| 3 | normalizeModelId | 查找前清理旧版/预览模型 ID 别名 |
| 4 | normalizeTransport | 通用模型组装前清理提供商系列 api / baseUrl |
| 5 | normalizeConfig | 规范化 models.providers.<id> 配置 |
| 6 | applyNativeStreamingUsageCompat | 面向配置提供商的原生流式用量兼容重写 |
| 7 | resolveConfigApiKey | 提供商拥有的环境标记凭证解析 |
| 8 | resolveSyntheticAuth | 本地/自托管或配置支持的合成凭证 |
| 9 | shouldDeferSyntheticProfileAuth | 将合成的已存储配置文件占位符降低到环境/配置凭证之后 |
| 10 | resolveDynamicModel | 接受任意上游模型 ID |
| 11 | prepareDynamicModel | 解析前异步获取元数据 |
| 12 | normalizeResolvedModel | 运行器前的传输协议重写 |
| 13 | contributeResolvedModelCompat | 位于另一种兼容传输协议背后的供应商模型的兼容标志 |
| 14 | normalizeToolSchemas | 注册前由提供商拥有的工具 schema 清理 |
| 15 | inspectToolSchemas | 提供商拥有的工具 schema 诊断 |
| 16 | resolveReasoningOutputMode | 带标签与原生推理输出契约 |
| 17 | prepareExtraParams | 默认请求参数 |
| 18 | createStreamFn | 完全自定义的 StreamFn 传输协议 |
| 19 | wrapStreamFn | 正常流路径上的自定义标头/正文包装器 |
| 20 | resolveTransportTurnState | 原生逐轮标头/元数据 |
| 21 | resolveWebSocketSessionPolicy | 原生 WS 会话标头/冷却时间 |
| 22 | formatApiKey | 自定义运行时令牌形态 |
| 23 | refreshOAuth | 自定义 OAuth 刷新 |
| 24 | buildAuthDoctorHint | 凭证修复指引 |
| 25 | matchesContextOverflowError | 提供商拥有的溢出检测 |
| 26 | classifyFailoverReason | 提供商拥有的速率限制/过载分类 |
| 27 | isCacheTtlEligible | 提示缓存 TTL 门控 |
| 28 | buildMissingAuthMessage | 自定义缺失凭证提示 |
| 29 | augmentModelCatalog | 合成的前向兼容行 |
| 30 | resolveThinkingProfile | 模型专属 /think 选项集 |
| 31 | isBinaryThinking | 二进制 thinking 开/关兼容性 |
| 32 | supportsXHighThinking | xhigh 推理支持兼容性 |
| 33 | resolveDefaultThinkingLevel | 默认 /think 策略兼容性 |
| 34 | isModernModelRef | 实时/冒烟模型匹配 |
| 35 | prepareRuntimeAuth | 推理前的令牌交换 |
| 36 | resolveUsageAuth | 自定义用量凭证解析 |
| 37 | fetchUsageSnapshot | 自定义用量端点 |
| 38 | createEmbeddingProvider | 提供商拥有的记忆/搜索嵌入适配器 |
| 39 | buildReplayPolicy | 自定义转录重放/压缩策略 |
| 40 | sanitizeReplayHistory | 通用清理后的提供商特定重放重写 |
| 41 | validateReplayTurns | 嵌入式运行器前的严格重放轮次验证 |
| 42 | onModelSelected | 选择后的回调(例如 telemetry) |
normalizeConfig首先检查匹配的提供商,然后检查其他具备钩子能力的提供商插件,直到某个插件实际更改配置。如果没有提供商钩子重写受支持的 Google 系列配置条目,仍会应用内置的 Google 配置规范化器。resolveConfigApiKey在公开时使用提供商钩子。内置amazon-bedrock路径在这里也有内置的 AWS 环境标记解析器,尽管 Bedrock 运行时凭证本身仍使用 AWS SDK 默认链。resolveSystemPromptContribution允许提供商为一个模型系列注入缓存感知的系统提示指引。当行为属于某个提供商/模型系列并且应保留稳定/动态缓存拆分时,优先使用它而不是before_prompt_build。
添加额外能力(可选)
步骤 5:添加额外能力
提供商插件可以在文本推理之外,同时注册语音、实时转录、实时 语音、媒体理解、图像生成、视频生成、Web 获取 和 Web 搜索。OpenClaw 将其归类为 混合能力插件 - 这是公司插件的推荐模式 (每个厂商一个插件)。请参阅 内部机制:能力所有权。在register(api) 内与你现有的
api.registerProvider(...) 调用一起注册每项能力。只选择你需要的标签页:- Speech (TTS)
- Realtime transcription
- Realtime voice
- Media understanding
- Image and video generation
- Web fetch and search
assertOkOrThrowProviderError(...),这样
插件可以共享受限的错误正文读取、JSON 错误解析和
请求 ID 后缀。Test
步骤 6:测试
src/provider.test.ts
发布到 ClawHub
提供商插件的发布方式与任何其他外部代码插件相同:clawhub package publish。
文件结构
Catalog 顺序参考
catalog.order 控制你的 catalog 相对于内置
提供商的合并时机:
| 顺序 | 时机 | 使用场景 |
|---|---|---|
simple | 第一轮 | 普通 API key 提供商 |
profile | simple 之后 | 受 auth profile 限制的提供商 |
paired | profile 之后 | 合成多个相关条目 |
late | 最后一轮 | 覆盖现有提供商(冲突时胜出) |