本指南将带你构建一个为 OpenClaw 添加模型提供方(LLM)的插件。到最后,你将拥有一个带有模型目录、API 密钥认证和动态模型解析能力的提供方。Documentation Index
Fetch the complete documentation index at: https://openclaw.zhcndoc.com/llms.txt
Use this file to discover all available pages before exploring further.
如果你之前没有构建过任何 OpenClaw 插件,请先阅读
入门指南,了解基本的软件包
结构和清单配置。
操作流程
Package and manifest
Step 1: Package and manifest
providerAuthEnvVars,这样 OpenClaw 就可以在不加载你的插件运行时的情况下检测
凭据。当某个提供方变体应复用另一个提供方 id 的认证时,请添加 providerAuthAliases。
modelSupport 是可选项,它允许 OpenClaw 在运行时钩子出现之前,就通过诸如
acme-large 这样的简写模型 id 自动加载你的提供方插件。如果你把该
提供方发布到 ClawHub,则 package.json 中的这些 openclaw.compat 和 openclaw.build 字段
是必需的。注册提供方
一个最小的提供方需要 这就是一个可工作的提供方。现在用户可以运行
id、label、auth 和 catalog:index.ts
openclaw onboard --acme-ai-api-key <key> 并选择
acme-ai/acme-large 作为他们的模型。如果上游提供方使用的控制 token 与 OpenClaw 不同,不要替换流路径,而是添加一个
小的双向文本转换:input 会在传输前重写最终的系统提示词和文本消息内容。output 会在 OpenClaw 解析
自己的控制标记或通道投递之前,重写助手文本增量和最终文本。对于只注册一个文本提供方、使用 API 密钥认证并且只有一个基于目录的运行时的打包提供方,
优先使用更窄的 defineSingleProviderPluginEntry(...) 辅助函数:buildProvider 是动态目录路径,在 OpenClaw 能解析真实提供方认证时使用。它可以执行
提供方特定的发现逻辑。buildStaticProvider 仅用于离线行,这些内容在认证配置完成之前也应是安全可展示的;
它不能依赖凭据,也不能发起网络请求。OpenClaw 的 models list --all 当前只会为打包的提供方插件执行静态目录,
并且配置为空、环境变量为空,也没有 agent/workspace 路径。如果你的认证流程还需要在 onboarding 期间修补 models.providers.*、别名和 agent 默认模型,
请使用 openclaw/plugin-sdk/provider-onboard 中的预设辅助函数。最小粒度的辅助函数有
createDefaultModelPresetAppliers(...)、
createDefaultModelsPresetAppliers(...) 和
createModelCatalogPresetAppliers(...)。当某个提供方的原生端点在常规 openai-completions 传输上支持流式 usage 块时,
应优先使用 openclaw/plugin-sdk/provider-catalog-shared 中共享的目录辅助函数,而不是硬编码
提供方 id 判断。supportsNativeStreamingUsageCompat(...) 和
applyProviderNativeStreamingUsageCompat(...) 会根据端点能力映射检测支持情况,因此即使插件使用了自定义提供方 id,
原生 Moonshot/DashScope 风格端点也仍然可以接入。添加动态模型解析
如果你的提供方接受任意模型 ID(例如代理或路由器),请添加
如果解析需要网络请求,请使用
resolveDynamicModel:prepareDynamicModel 做异步预热 —— resolveDynamicModel
会在其完成后再次运行。添加运行时钩子(按需)
大多数提供方只需要 当前可用的 replay 家族:
当前可用的 stream 家族:
catalog + resolveDynamicModel。随着你的提供方需要,再逐步添加钩子。现在共享辅助构建器已经覆盖了最常见的 replay/tool-compat 家族,因此插件通常不需要逐个手工连接每个钩子:| Family | 作用 | 打包示例 |
|---|---|---|
openai-compatible | 面向 OpenAI 兼容传输的共享 OpenAI 风格 replay 策略,包括 tool-call-id 清理、assistant-first 顺序修复,以及在传输需要时进行通用的 Gemini turn 校验 | moonshot, ollama, xai, zai |
anthropic-by-model | 由 modelId 选择的 Claude 感知 replay 策略,因此只有在解析出的模型确实是 Claude id 时,Anthropic 消息传输才会获得 Claude 专属的 thinking-block 清理 | amazon-bedrock, anthropic-vertex |
google-gemini | 原生 Gemini replay 策略,加上 bootstrap replay 清理和标记的 reasoning 输出模式 | google, google-gemini-cli |
passthrough-gemini | 用于通过 OpenAI 兼容代理传输运行的 Gemini 模型的 Gemini thought-signature 清理;不会启用原生 Gemini replay 校验或 bootstrap 重写 | openrouter, kilocode, opencode, opencode-go |
hybrid-anthropic-openai | 适用于在一个插件中混合 Anthropic 消息和 OpenAI 兼容模型表面的混合策略;可选的仅 Claude thinking-block 删除仍然只作用于 Anthropic 一侧 | minimax |
| Family | 作用 | 打包示例 |
|---|---|---|
google-thinking | 共享流路径上的 Gemini thinking 负载规范化 | google, google-gemini-cli |
kilocode-thinking | 共享代理流路径上的 Kilo reasoning 包装器,对 kilo/auto 和不受支持的代理 reasoning ids 跳过注入的 thinking | kilocode |
moonshot-thinking | 基于配置 + /think 级别的 Moonshot 二进制原生 thinking 负载映射 | moonshot |
minimax-fast-mode | 共享流路径上的 MiniMax fast-mode 模型重写 | minimax, minimax-portal |
openai-responses-defaults | 共享的原生 OpenAI/Codex Responses 包装器:归因 headers、/fast/serviceTier、文本详细程度、原生 Codex web search、reasoning-compat 负载塑形,以及 Responses 上下文管理 | openai, openai-codex |
openrouter-thinking | 面向代理路由的 OpenRouter reasoning 包装器,不支持的模型/auto 跳过由中心处理 | openrouter |
tool-stream-default-on | 面向 Z.AI 等希望默认启用工具流的提供方的 tool_stream 包装器,除非显式禁用 | zai |
驱动这些家族构建器的 SDK 接口
驱动这些家族构建器的 SDK 接口
每个家族构建器都由同一软件包导出的更底层公共辅助函数组合而成;当某个提供方需要脱离通用模式时,
你可以直接使用这些函数:
openclaw/plugin-sdk/provider-model-shared—ProviderReplayFamily、buildProviderReplayFamilyHooks(...),以及原始 replay 构建器(buildOpenAICompatibleReplayPolicy、buildAnthropicReplayPolicyForModel、buildGoogleGeminiReplayPolicy、buildHybridAnthropicOrOpenAIReplayPolicy)。还导出 Gemini replay 辅助函数(sanitizeGoogleGeminiReplayHistory、resolveTaggedReasoningOutputMode)以及端点/模型辅助函数(resolveProviderEndpoint、normalizeProviderId、normalizeGooglePreviewModelId、normalizeNativeXaiModelId)。openclaw/plugin-sdk/provider-stream—ProviderStreamFamily、buildProviderStreamFamilyHooks(...)、composeProviderStreamWrappers(...),以及共享的 OpenAI/Codex 包装器(createOpenAIAttributionHeadersWrapper、createOpenAIFastModeWrapper、createOpenAIServiceTierWrapper、createOpenAIResponsesContextManagementWrapper、createCodexNativeWebSearchWrapper)、DeepSeek V4 OpenAI 兼容包装器(createDeepSeekV4OpenAICompatibleThinkingWrapper)、Anthropic Messages thinking prefill 清理(createAnthropicThinkingPrefillPayloadWrapper),以及共享代理/提供方包装器(createOpenRouterWrapper、createToolStreamWrapper、createMinimaxFastModeWrapper)。openclaw/plugin-sdk/provider-tools—ProviderToolCompatFamily、buildProviderToolCompatFamilyHooks("gemini")、底层 Gemini schema 辅助函数(normalizeGeminiToolSchemas、inspectGeminiToolSchemas),以及 xAI 兼容辅助函数(resolveXaiModelCompatPatch()、applyXaiModelCompat(model))。打包的 xAI 插件使用normalizeResolvedModel+contributeResolvedModelCompat来确保 xAI 规则由该提供方自身拥有。
@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 特定的 reasoning 负载移除)。同样的 package-root 模式也支撑着 @openclaw/openai-provider(提供方构建器、默认模型辅助函数、realtime 提供方构建器)以及 @openclaw/openrouter-provider(提供方构建器加 onboarding/config 辅助函数)。- Token 交换
- 自定义请求头
- 原生传输身份
- 用量和计费
对于需要在每次推理调用前进行 token 交换的提供方:
所有可用的提供方钩子
所有可用的提供方钩子
OpenClaw 会按以下顺序调用这些钩子。大多数提供方只会用到 2-3 个:
OpenClaw 不再调用的仅兼容字段,例如
运行时回退说明:
ProviderPlugin.capabilities 和 suppressBuiltInModel,不在此列出。| # | Hook | 适用场景 |
|---|---|---|
| 1 | catalog | 模型目录或 base URL 默认值 |
| 2 | applyConfigDefaults | 配置实例化期间由提供方拥有的全局默认值 |
| 3 | normalizeModelId | 查找前清理旧版/预览版 model-id 别名 |
| 4 | normalizeTransport | 生成通用模型前清理提供方家族 api / baseUrl |
| 5 | normalizeConfig | 规范化 models.providers.<id> 配置 |
| 6 | applyNativeStreamingUsageCompat | 配置提供方的原生流式 usage 兼容重写 |
| 7 | resolveConfigApiKey | 提供方拥有的 env-marker 认证解析 |
| 8 | resolveSyntheticAuth | 本地/自托管或由配置支持的合成认证 |
| 9 | shouldDeferSyntheticProfileAuth | 在 env/config 认证之下延后合成存储的 profile 占位符 |
| 10 | resolveDynamicModel | 接受任意上游模型 ID |
| 11 | prepareDynamicModel | 解析前的异步元数据获取 |
| 12 | normalizeResolvedModel | 运行器之前的传输重写 |
| 13 | contributeResolvedModelCompat | 位于另一个兼容传输之后的厂商模型兼容标志 |
| 14 | normalizeToolSchemas | 注册前由提供方拥有的 tool-schema 清理 |
| 15 | inspectToolSchemas | 由提供方拥有的 tool-schema 诊断 |
| 16 | resolveReasoningOutputMode | 标记式 vs 原生 reasoning-output 协议 |
| 17 | prepareExtraParams | 默认请求参数 |
| 18 | createStreamFn | 完全自定义的 StreamFn 传输 |
| 19 | wrapStreamFn | 常规流路径上的自定义请求头/请求体包装器 |
| 20 | resolveTransportTurnState | 原生的每轮请求头/元数据 |
| 21 | resolveWebSocketSessionPolicy | 原生 WS 会话头/冷却时间 |
| 22 | formatApiKey | 自定义运行时 token 形状 |
| 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 reasoning 支持兼容性 |
| 33 | resolveDefaultThinkingLevel | 默认 /think 策略兼容性 |
| 34 | isModernModelRef | 线上/冒烟测试模型匹配 |
| 35 | prepareRuntimeAuth | 推理前的 token 交换 |
| 36 | resolveUsageAuth | 自定义用量凭据解析 |
| 37 | fetchUsageSnapshot | 自定义用量端点 |
| 38 | createEmbeddingProvider | 面向 memory/search 的提供方拥有 embedding 适配器 |
| 39 | buildReplayPolicy | 自定义对话回放/压缩策略 |
| 40 | sanitizeReplayHistory | 通用清理之后的提供方特定回放重写 |
| 41 | validateReplayTurns | 嵌入式运行器之前的严格 replay-turn 校验 |
| 42 | onModelSelected | 选择后的回调(例如遥测) |
normalizeConfig会先检查匹配到的提供方,然后再检查其他支持钩子的提供方插件,直到有一个真正修改了配置。如果没有任何提供方钩子重写受支持的 Google 家族配置项,打包的 Google 配置规范化器仍会生效。resolveConfigApiKey会在暴露时使用提供方钩子。打包的amazon-bedrock路径在这里也有内置的 AWS env-marker 解析器,尽管 Bedrock 运行时认证本身仍然使用 AWS SDK 默认链。resolveSystemPromptContribution允许提供方为某个模型家族注入支持缓存感知的系统提示指导。若行为属于某个单独的提供方/模型家族,并且应保留稳定/动态缓存拆分,则应优先使用它,而不是before_prompt_build。
Add extra capabilities (optional)
Step 5: Add extra capabilities
一个提供方插件可以在文本推理之外,同时注册语音、实时转写、实时语音、 媒体理解、图像生成、视频生成、网页抓取和网页搜索。OpenClaw 将这类插件归类为 hybrid-capability 插件——这是公司插件的推荐模式(每个供应商一个插件)。 参见 内部机制:能力所有权。在register(api) 中与你现有的
api.registerProvider(...) 调用并列注册每种能力。只选择你需要的选项卡:- 语音(TTS)
- 实时转写
- 实时语音
- 媒体理解
- 图像和视频生成
- 网页抓取与搜索
assertOkOrThrowProviderError(...),这样插件可以共享
有上限的错误正文读取、JSON 错误解析和 request-id 后缀。Test
Step 6: Test
src/provider.test.ts
发布到 ClawHub
提供方插件与其他外部代码插件的发布方式相同:clawhub package publish。
文件结构
目录顺序参考
catalog.order 控制你的目录与内置提供者合并的相对时机:
| 顺序 | 时机 | 使用场景 |
|---|---|---|
simple | 第一轮 | 纯 API 密钥提供者 |
profile | simple 之后 | 由认证配置文件控制的提供者 |
paired | profile 之后 | 合成多个相关条目 |
late | 最后一轮 | 覆盖现有提供者(冲突时获胜) |