本指南逐步說明如何建置一個為 OpenClaw 新增模型提供者 (LLM)的 provider Plugin。完成後,你將擁有一個包含模型目錄、 API 金鑰驗證,以及動態模型解析的 provider。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.
如果你先前尚未建置過任何 OpenClaw Plugin,請先閱讀
開始使用,了解基本套件
結構與 manifest 設定。
逐步指南
套件與 manifest
providerAuthEnvVars,讓 OpenClaw 不必載入你的 Plugin runtime
就能偵測憑證。當 provider 變體應重用另一個 provider id 的驗證時,請新增 providerAuthAliases。
modelSupport 是選用項,可讓 OpenClaw 在 runtime hook 存在前,先從像
acme-large 這類簡寫模型 id 自動載入你的 provider Plugin。如果你在
ClawHub 發佈 provider,package.json 中必須包含這些 openclaw.compat 和
openclaw.build 欄位。註冊 provider
最小 provider 需要 這就是可運作的 provider。使用者現在可以
id、label、auth 和 catalog:index.ts
openclaw onboard --acme-ai-api-key <key>,並選擇
acme-ai/acme-large 作為他們的模型。如果上游 provider 使用的控制 token 與 OpenClaw 不同,請新增一個
小型雙向文字轉換,而不是取代串流路徑:input 會在傳輸前改寫最終系統提示和文字訊息內容。output 會在
OpenClaw 解析自己的控制標記或通道投遞前,改寫助理文字 delta 和最終文字。對於只註冊一個使用 API 金鑰驗證、並具有單一 catalog-backed runtime 的文字 provider 的
內建 provider,請優先使用較窄的
defineSingleProviderPluginEntry(...) 輔助工具:buildProvider 是 OpenClaw 能解析真實 provider 驗證時使用的即時 catalog 路徑。
它可以執行 provider 特定的探索。buildStaticProvider 僅用於在驗證設定前
顯示仍安全的離線列;它不得要求憑證或發出網路請求。
OpenClaw 的 models list --all 顯示目前只會針對內建 provider Plugin 執行 static catalog,
且使用空 config、空 env,並且沒有代理/工作區路徑。如果你的驗證流程也需要在 onboarding 期間修補 models.providers.*、別名,以及
代理預設模型,請使用
openclaw/plugin-sdk/provider-onboard 中的 preset 輔助工具。最窄的輔助工具是
createDefaultModelPresetAppliers(...)、
createDefaultModelsPresetAppliers(...) 和
createModelCatalogPresetAppliers(...)。當 provider 的原生 endpoint 在一般 openai-completions 傳輸上支援 streamed usage blocks 時,
請優先使用 openclaw/plugin-sdk/provider-catalog-shared 中的共用 catalog 輔助工具,
而不是硬編碼 provider-id 檢查。supportsNativeStreamingUsageCompat(...) 和
applyProviderNativeStreamingUsageCompat(...) 會從 endpoint capability map 偵測支援狀態,
因此即使 Plugin 使用自訂 provider id,原生 Moonshot/DashScope 風格 endpoint 仍會選擇加入。新增動態模型解析
如果你的 provider 接受任意模型 ID(例如 proxy 或 router),
請新增 如果解析需要網路呼叫,請使用
resolveDynamicModel:prepareDynamicModel 進行 async
預熱,resolveDynamicModel 會在它完成後再次執行。視需要新增 runtime hook
多數 provider 只需要 目前可用的 replay 系列:
目前可用的 stream 系列:
catalog + resolveDynamicModel。請隨著 provider 需求
逐步新增 hook。共用輔助建構器現在涵蓋最常見的 replay/tool-compat
系列,因此 Plugin 通常不需要逐一手動接線每個 hook:| 系列 | 接入內容 | 內建範例 |
|---|---|---|
openai-compatible | OpenAI-compatible 傳輸的共用 OpenAI 風格 replay policy,包括 tool-call-id 清理、assistant-first ordering 修正,以及傳輸需要時的通用 Gemini-turn 驗證 | moonshot、ollama、xai、zai |
anthropic-by-model | 依 modelId 選擇的 Claude-aware replay policy,因此 Anthropic-message 傳輸只會在已解析模型實際上是 Claude id 時取得 Claude-specific thinking-block cleanup | amazon-bedrock、anthropic-vertex |
google-gemini | 原生 Gemini replay policy,加上 bootstrap replay sanitation 和 tagged reasoning-output mode | google、google-gemini-cli |
passthrough-gemini | 透過 OpenAI-compatible proxy 傳輸執行 Gemini 模型時的 Gemini thought-signature sanitation;不會啟用原生 Gemini replay validation 或 bootstrap rewrites | openrouter、kilocode、opencode、opencode-go |
hybrid-anthropic-openai | 針對在一個 Plugin 中混合 Anthropic-message 和 OpenAI-compatible 模型介面的 provider 的混合 policy;選用的 Claude-only thinking-block dropping 會保持限縮在 Anthropic 端 | minimax |
| 系列 | 接入內容 | 內建範例 |
|---|---|---|
google-thinking | 共用串流路徑上的 Gemini thinking 承載資料正規化 | google, google-gemini-cli |
kilocode-thinking | 共用代理串流路徑上的 Kilo reasoning 包裝器,並讓 kilo/auto 與不支援的代理 reasoning ID 略過注入的 thinking | kilocode |
moonshot-thinking | 從設定 + /think 等級對應 Moonshot binary native-thinking 承載資料 | moonshot |
minimax-fast-mode | 共用串流路徑上的 MiniMax fast-mode 模型改寫 | minimax, minimax-portal |
openai-responses-defaults | 共用原生 OpenAI/Codex Responses 包裝器:歸因標頭、/fast/serviceTier、文字詳略程度、原生 Codex 網頁搜尋、reasoning-compat 承載資料塑形,以及 Responses 上下文管理 | openai, openai-codex |
openrouter-thinking | 代理路由的 OpenRouter reasoning 包裝器,集中處理不支援模型/auto 略過 | openrouter |
tool-stream-default-on | 預設開啟的 tool_stream 包裝器,適用於 Z.AI 這類除非明確停用否則需要工具串流的提供者 | zai |
SDK seams powering the family builders
SDK seams powering the family builders
每個系列建構器都由同一套套件匯出的較低階公開輔助工具組成;當某個提供者需要偏離共用模式時,你可以使用這些工具:
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 Plugin 會搭配這些工具使用normalizeResolvedModel+contributeResolvedModelCompat,讓 xAI 規則由該提供者擁有。
@openclaw/anthropic-provider 會在自己的公開 api.ts / contract-api.ts seam 中保留 wrapAnthropicProviderStream、resolveAnthropicBetas、resolveAnthropicFastMode、resolveAnthropicServiceTier,以及較低階的 Anthropic 包裝器建構器,因為它們編碼了 Claude OAuth beta 處理和 context1m 閘控。xAI Plugin 同樣會在自己的 wrapStreamFn 中保留原生 xAI Responses 塑形(/fast 別名、預設 tool_stream、不支援的 strict-tool 清理、xAI 專屬 reasoning-payload 移除)。相同的套件根目錄模式也支援 @openclaw/openai-provider(提供者建構器、預設模型輔助工具、即時提供者建構器)和 @openclaw/openrouter-provider(提供者建構器加上上線導引/設定輔助工具)。- Token exchange
- Custom headers
- Native transport identity
- Usage and billing
對於每次推論呼叫前需要權杖交換的提供者:
All available provider hooks
All available provider hooks
OpenClaw 會依照以下順序呼叫 hook。大多數提供者只會使用 2 到 3 個:
OpenClaw 已不再呼叫的僅相容性提供者欄位,例如
執行階段備援注意事項:
ProviderPlugin.capabilities 和 suppressBuiltInModel,未列在此處。| # | Hook | 使用時機 |
|---|---|---|
| 1 | catalog | 模型目錄或 base URL 預設值 |
| 2 | applyConfigDefaults | 設定具體化期間,由提供者擁有的全域預設值 |
| 3 | normalizeModelId | 查找前清理舊版/預覽模型 ID 別名 |
| 4 | normalizeTransport | 通用模型組裝前,清理提供者系列的 api / baseUrl |
| 5 | normalizeConfig | 正規化 models.providers.<id> 設定 |
| 6 | applyNativeStreamingUsageCompat | 設定提供者的原生 streaming-usage 相容性改寫 |
| 7 | resolveConfigApiKey | 由提供者擁有的 env-marker 驗證解析 |
| 8 | resolveSyntheticAuth | 本機/自架或由設定支援的合成驗證 |
| 9 | shouldDeferSyntheticProfileAuth | 將合成的已儲存設定檔預留位置降到 env/config 驗證之後 |
| 10 | resolveDynamicModel | 接受任意上游模型 ID |
| 11 | prepareDynamicModel | 解析前非同步擷取中繼資料 |
| 12 | normalizeResolvedModel | runner 前的傳輸改寫 |
| 13 | contributeResolvedModelCompat | 另一個相容傳輸背後廠商模型的相容性旗標 |
| 14 | normalizeToolSchemas | 註冊前由提供者擁有的工具 schema 清理 |
| 15 | inspectToolSchemas | 由提供者擁有的工具 schema 診斷 |
| 16 | resolveReasoningOutputMode | 已標記與原生 reasoning-output 合約 |
| 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 | Binary thinking 開/關相容性 |
| 32 | supportsXHighThinking | xhigh reasoning 支援相容性 |
| 33 | resolveDefaultThinkingLevel | 預設 /think 政策相容性 |
| 34 | isModernModelRef | 即時/煙霧測試模型比對 |
| 35 | prepareRuntimeAuth | 推論前的權杖交換 |
| 36 | resolveUsageAuth | 自訂用量憑證剖析 |
| 37 | fetchUsageSnapshot | 自訂用量端點 |
| 38 | createEmbeddingProvider | 由提供者擁有、供記憶體/搜尋使用的 embedding 配接器 |
| 39 | buildReplayPolicy | 自訂轉錄 replay/compaction 政策 |
| 40 | sanitizeReplayHistory | 通用清理後,提供者專屬的 replay 改寫 |
| 41 | validateReplayTurns | 嵌入式 runner 前的嚴格 replay-turn 驗證 |
| 42 | onModelSelected | 選取後回呼(例如遙測) |
normalizeConfig會先檢查相符的提供者,接著檢查其他具備 hook 能力的提供者 Plugin,直到其中一個實際變更設定。如果沒有提供者 hook 改寫受支援的 Google 系列設定項目,內建 Google 設定正規化器仍會套用。resolveConfigApiKey會在公開時使用提供者 hook。內建的amazon-bedrock路徑在這裡也有內建 AWS env-marker 解析器,即使 Bedrock 執行階段驗證本身仍使用 AWS SDK 預設鏈。resolveSystemPromptContribution讓提供者可以為某個模型系列注入具快取感知的 system-prompt 指引。當行為屬於單一提供者/模型系列,且應保留穩定/動態快取分割時,請優先使用它,而不是before_prompt_build。
Add extra capabilities (optional)
提供者 Plugin 可以在文字推論之外,同時註冊語音、即時轉錄、即時語音、媒體理解、圖片生成、影片生成、網頁擷取和網頁搜尋。OpenClaw 將此分類為
混合能力 Plugin,也就是公司 Plugin 的建議模式(每個廠商一個 Plugin)。請參閱
內部:能力擁有權。在 對於提供者 HTTP 失敗,請使用
register(api) 內,於你現有的 api.registerProvider(...) 呼叫旁註冊每項能力。只選擇你需要的分頁:- 語音 (TTS)
- 即時轉錄
- 即時語音
- 媒體理解
- 圖片與影片生成
- 網頁擷取與搜尋
assertOkOrThrowProviderError(...),讓
plugins 共用受限的錯誤本文讀取、JSON 錯誤解析,以及
request-id 後綴。發布到 ClawHub
提供者 plugins 的發布方式與任何其他外部程式碼 plugin 相同:clawhub package publish。
檔案結構
目錄順序參考
catalog.order 控制你的目錄相對於內建提供者合併的時機:
| 順序 | 時機 | 使用情境 |
|---|---|---|
simple | 第一輪 | 一般 API key 提供者 |
profile | simple 之後 | 受 auth profiles 限制的提供者 |
paired | profile 之後 | 合成多個相關項目 |
late | 最後一輪 | 覆寫現有提供者(衝突時勝出) |
後續步驟
- Channel Plugins — 如果你的 plugin 也提供通道
- SDK Runtime —
api.runtime輔助工具(TTS、搜尋、subagent) - SDK Overview — 完整的子路徑匯入參考
- Plugin Internals — hook 詳細資料與 bundled 範例