適合誰：已經裝好 OpenClaw，接下來想認真選模型與供應商的新手。
這篇不是要比誰 benchmark 排名第一，而是要回答一個更實際的問題：如果你真的要把 OpenClaw 養起來，錢要花在哪裡、哪家穩、哪家聰明、哪家容易翻車、哪家比較適合拿來做什麼事？

先講我的主張

如果你剛開始玩 OpenClaw，先不要找「最強模型」，先找最適合當主力、最適合當副手、最不容易突然把你搞到停工的組合。

更白話一點：

  • 最難的工作，交給真的夠聰明、也真的能扛複雜 agent 工作流的模型。
  • 日常大量工作，交給便宜、穩、額度比較不會一直跳警告的模型。
  • 低 guardrail 或私人娛樂用途，另外準備一條路，不要把正經工作流和快樂路線綁在一起。
  • consumer 訂閱能省錢沒錯，但不要把它當萬用神藥。 2026 年 2 月那幾波封鎖事件，已經把這件事講得夠明白了。

這篇的核心不是「哪一家永遠最好」，而是：

對 OpenClaw 這種長時間跑、多 session、要吃工具、要吃記憶、還可能跨多個 agent 的系統來說，模型供應商的穩定性與可預期性，常常比單次對話的靈光更重要。

先把比較方法講清楚

這篇比的是三種東西，但重心會放在前兩種：

  1. API 模型供應商
    例如 OpenAI API、Anthropic API、Gemini API、xAI API、MiniMax API、z.ai API。

  2. 可轉接進 OpenClaw 的聊天訂閱來源
    例如 OpenAI Codex OAuth、Claude Pro / Max、Gemini CLI / Antigravity 一類的 consumer 或 IDE 型方案。

  3. 本地模型
    這篇只當對照組點一下。後面我會另外寫本地模型篇，因為那又是另一個宇宙。

這篇的比較維度不是單純看官方定價，而是看 OpenClaw 的實際成本感。
也就是說，我會一起看這些事：

  • 夠不夠聰明
  • 速度體感如何
  • 工具調用穩不穩
  • structured output 穩不穩
  • 長上下文會不會很快失真
  • 寫程式、修 bug 夠不夠能打
  • memory-heavy workflow 撐不撐得住
  • 額度是不是好預測
  • 便不便宜
  • guardrail 鬆不鬆
  • 最後到底適不適合拿來養 OpenClaw

這裡也先講清楚一件事：
「聰明程度」和「速度體感」有一部分是官方能力描述，一部分是 Daniel 的工作判準與第一手體感。
我不會把個人體感硬裝成宇宙真理，但也不會假裝大家都是看 token pricing 就能做決策的機器人。

OpenClaw 真正需要的是什麼模型能力？

很多人剛開始選模型，只看「會不會聊天」或「寫文章順不順」。
對 OpenClaw 來說，這遠遠不夠。

1. Tool use 要穩

OpenClaw 不是拿來玩單輪問答的。
它要開工具、讀檔、執行命令、接 MCP、串記憶、在多個 channel 間來回走。
如果模型 tool use 很飄，整套系統就會開始像踩香蕉皮。

2. Structured output 要穩

有些模型聊天很會講，但一碰到 schema、JSON、工具引數、固定格式輸出，就開始歪樓。
OpenClaw 這種 runtime 很吃這件事。你不一定每天都盯著它，但它一旦結構輸出亂掉，後面整串流程都會跟著抖。

3. 長上下文不能太快衰退

OpenClaw 很容易走到這種情境：
前面已經聊了一大段、又掛了一堆記憶、還塞了 skill、再加上工具回傳內容。
有些模型帳面 context 很大，但實際上一長就開始失憶、漏前提、或在後段突然變笨。

4. Code editing / bug fixing 要真的能打

如果你拿 OpenClaw 做 coding agent、repo 操作、debug、重構、補測試，模型不只要懂 code，還要能在多步驟裡維持邏輯。
這一層的差距，會比「平常聊天很有靈氣」大得多。

5. Memory-heavy workflow 要撐得住

OpenClaw 一旦開始多 agent、多 workspace、多 session，模型不只是要會回答問題，而是要會在一堆舊上下文裡維持角色、維持任務、維持判斷。
這也是為什麼我後來不是找單一最強模型，而是做多模型混用。

一張真的有用的選型表

先講清楚：這張表不是在比抽象 benchmark。
它比的是 Daniel 實際拿來養 OpenClaw 時的工作感受，再混合官方定價、方案限制、provider 支援狀態與 2026 年 2 到 4 月的供應商現況。

供應商 / 路徑OpenClaw 接法成本感聰明程度速度體感agent 適配性guardrail 鬆緊我會拿來做什麼
OpenAI Codex OAuth / OpenAI APICodex OAuth 或 API中到高很強中到偏快很高中複雜寫程式、修 bug、長鏈推理、重文章
Anthropic API / Claude Pro / MaxAPI 或 consumer 帳號相關路徑中到高很強中很高，但 consumer 路徑風險上升中偏緊coding、長文理解、專業推理
Gemini API / AntigravityAPI 或 consumer / CLI 相關路徑便宜到中強快高，但 2026 年 2 月之後要很保守中搜尋型工作、輕量 reasoning、某些便宜任務
MiniMax M2.7 / Token PlanAPI key / Coding or Token Plan很划算夠聰明快中到高中偏鬆日常主力、大量聊天、長時間開著跑
z.ai / GLMAPI key / Coding Plan看起來划算，但額度體感不穩不差快中中偏鬆本來想當省錢主力，後來我移掉了
xAI Grok APIAPI key中到高中到高快中比較鬆低 guardrail、娛樂線、私人角色玩法
本地模型本地 provider / 自架硬體前期成本高、長期可控看模型看硬體中到高最鬆隱私、高自由度、完全自控

我的第一個結論：大多數新手，不該先追「單一最強」，而該先做三層分工

如果你一開始就想找一個模型包辦所有事，通常很快就會遇到三種痛：

  1. 最強的太貴
  2. 最便宜的在複雜任務上不夠穩
  3. 最自由的那個不一定最適合正經工作

所以我現在的做法是三層：

  • 重活模型：OpenAI
  • 日常主力：MiniMax
  • 快樂副線 / 低 guardrail 線：Grok

z.ai 原本是有進入候選名單的，但後來被我踢出去了，等一下講原因。

為什麼我需要高能輸出的時候，會切到 OpenAI

這件事我不想講得太玄，直接講工作感：

如果我今天要做的是：

  • 寫程式
  • 修 bug
  • 找一段很難抓的邏輯破口
  • 寫需要結構和推理硬度的文章
  • 讓 OpenClaw 處理比較複雜的 agent 工作

那我通常會切去 OpenAI。

理由其實很簡單。
OpenAI 現在這條線，對我來說最有價值的不是「便宜」，而是高強度工作時比較像一把真的夠利的刀。

OpenAI 官方現在也把這條路講得很清楚：

  • OpenClaw 這邊，Codex OAuth 是明確支援的外部 workflow 路徑，不是灰色地帶。
  • Codex 官方也直接建議，大多數 coding 與廣義專業工作先從 gpt-5.4 起手；更難的題目可以上 gpt-5.4-pro。
  • 而且 ChatGPT Plus / Pro 現在都包含 Codex，只是額度與速度層級不同。

對我來說，這件事有兩個實際好處：

第一，它省掉「是不是哪天突然被供應商說你不該這樣用」的焦慮

這在 2026 年其實不是小事。
很多人之前把 consumer 訂閱當成便宜大水庫，後來才發現供應商對第三方整合的態度一翻臉，整條線就會斷。

OpenAI 這條至少目前是明確支援的。

第二，它真的比較適合扛複雜工作

我不是說別家都不行。
而是當工作開始進入：

  • 多步驟修 bug
  • 要看很多檔案
  • 要維持長鏈推理
  • 要寫比較有邏輯骨架的內容

我自己最常切回去的，還是 OpenAI。

你可以把它理解成：
日常主力我不一定天天用最貴的，但重案組我會叫它上場。

關於 ChatGPT Plus 的現實感：它不是無限，但對很多個人使用者已經夠像一個高能按鈕

這裡我直接講我的用法。

我自己現在有一條很清楚的分工：

  • 平常大量跑 agent、跑日常任務，不一定交給 OpenAI
  • 但遇到真的硬的東西，我會切回 OpenAI
  • 尤其是需要很強邏輯、很強 code editing、很強 bug fixing 的時候

原因是，ChatGPT Plus 現在就包含 Codex，而且對我這種個人 builder 來說，這已經很像一個「需要時才按下去的高能模式」。
我不會拿它來洗一堆便宜日常流量，但會把它留給真正值錢的工作。

這也是我後來越來越明確的一個判準：

OpenAI 不是我最省錢的模型，但它常常是我最不想省的模型。

為什麼我沒有把 Claude 放在第一順位

先講清楚，這不是在說 Claude 不強。
相反地，Claude 在 coding、長文理解、長上下文任務上，還是很能打。

問題不在模型能力，問題在 consumer 方案拿去轉第三方 workflow 這件事，現在風險明顯比以前高。

Anthropic 官方目前有幾條線很值得所有 OpenClaw 使用者正視：

  1. Claude Pro / Max 的 usage limits 是和 Claude Code 共用的。
  2. Anthropic 明講，不允許第三方開發者把 claude.ai login 或 claude.ai rate limits 拿去包成自己的產品。
  3. 2026 年 2 月那波事件之後，這件事已經不是大家心照不宣的灰區，而是明顯變成供應商會出手處理的區域。

所以如果你今天問我：

Claude 強不強？

很強。

但如果你問我：

新手可不可以把 Claude consumer 訂閱當成最穩的 OpenClaw 主力？

我現在不會這樣推薦。

比較合理的做法

  • 如果你真的很喜歡 Claude 的能力，走 API 會比較乾淨。
  • 如果你只是想省錢，把 Pro / Max 當萬用中繼站，現在就沒那麼值得賭。

這裡的關鍵不是能力，而是可預期性。

2026 年 2 月那幾波事件，為什麼會直接改變我的選型方式

這一段一定要寫，因為它不是八卦，而是選型判斷的分水嶺。

1. Anthropic 這邊

2026 年 2 月，Anthropic 那邊對第三方 harness / 第三方工具使用 consumer 訂閱的態度，變得非常明確。
你可以喜歡 Claude，也可以繼續用 Claude，但如果你要把 consumer 訂閱硬轉成外部工具的大水管，這件事現在風險高很多。

2. Google Antigravity 這邊

2 月更戲劇化的是 Antigravity。
Google 當時對 OpenClaw 使用 Antigravity / Gemini CLI 一類路徑的做法，直接出手限制。根據 VentureBeat 的報導，Google 對外說法是要把 Antigravity 的使用拉回符合 ToS 的範圍；OpenClaw 社群那邊則出現了不少實際帳號受限的災情。

Peter Steinberger 當時也直接公開說這做法很「pretty draconian」，還表示會把 Antigravity support 拿掉。
他的原話很有代表性：

Even Anthropic pings me and is nice about issues. Google just… bans?

這句話其實已經把整個問題講完了。
不是所有能省錢的 consumer 路線，都適合當 OpenClaw 的骨幹。

3. Peter 後來加入 OpenAI

同一個月，Peter 也公開宣布加入 OpenAI，並寫明 OpenClaw 會轉往 foundation 形式繼續獨立發展。
這不代表 OpenAI 從此就是宇宙唯一正解，但至少在「OpenClaw 主線和哪家供應商之間比較沒有政策拉扯」這件事上，訊號非常清楚。

第二個結論：不要拿 consumer 訂閱硬轉接所有東西

這句話很重要，我單獨拉出來講。

如果你真的要長期養 OpenClaw，不要把 consumer 訂閱當成萬用 API。

原因有三個：

1. 它不是為這種工作負載設計的

consumer 產品本來就不是拿來讓你掛一整套自架 agent gateway、跑多 session、多 workspace、長時間工具鏈的。

2. 供應商的政策風向會變

今天還能用，不代表下個月還能用。
你不想把整套 workflow 建在一塊看起來便宜、其實很會地震的地基上。

3. 額度不一定好預測

有些方案表面上看起來很便宜，實際上你一重度使用，額度開始像被黑箱統治。

這也是我後來越來越偏向這個判準的原因：

  • 重活 → 找明確支援 OpenClaw / 外部 workflow 的路
  • 大量日常 → 找固定費率、額度相對好理解的路
  • 快樂用途 → 另外開一條，不要跟主工作流混在一起

為什麼我後來把 z.ai 移掉了

這裡我直接講第一手體感。

z.ai 這條路，我本來是很有興趣的。
原因也很簡單：它看起來划算、模型能力不差、也有明確在推 coding agent 這條線。

而且國際版官方文件自己就寫得很直接：

  • 起始方案大約從 10 美元等級開始
  • Pro 方案是更高強度的版本
  • 也一直在強調 coding、reasoning、agent 這些能力

問題是，我自己實際用下來不穩。

我的體感是這樣：

  • 同樣都是大概 10 美元等級的方案
  • zai / GLM 我發一兩個訊息，就很容易跳出超過使用額度的錯誤
  • 但 MiniMax 那邊卻可以穩穩跑，五小時重置一次，我自己通常根本還用不完

這種落差對 OpenClaw 來說非常致命。
因為 OpenClaw 不是拿來偶爾聊兩句而已，它會吃：

  • 多輪上下文
  • tool 回傳
  • 記憶
  • 有時候還有多 agent 之間的分流

所以我後來的決定很乾脆：

z.ai 不是不能用，而是對我來說，它沒有穩到值得留下來當主力。

還有一件事：不要用中國版

這裡我就直接照我自己的判斷講。

如果你人在台灣，真的不要為了省那一點點錢，跑去用中國版。
z.ai 的國際版和中國版不是同一條路線。

  • 國際版：https://z.ai/、https://docs.z.ai/
  • 中國版：https://bigmodel.cn/、https://open.bigmodel.cn/

中國版有時候看起來便宜一點，但你要承受的是另一種成本：
網路長城、跨區登入、服務策略差異、文件與付款體驗都可能把你搞得很煩。

我自己的判準很簡單：

省那一點錢，不值得換一套更難維護的麻煩。

所以後來我就把 z.ai 移掉了。

為什麼 MiniMax 反而留了下來

MiniMax 這條，老實說我一開始沒有抱那麼高期待。
結果反而是它後來變成我日常很願意留著的一條路。

原因有三個：

1. 固定費率的成本感很舒服

MiniMax 官方現在的 Token Plan，Starter 就是 $10/月，而且 M2.7 的 request 是 每 5 小時重置。
OpenClaw 官方 usage tracking 也直接把這條路寫進去，表示它知道 MiniMax 這類 coding / token plan 是怎麼計算視窗的。

對個人 builder 來說，這個感受差很多。
因為你不是每次都要算 token 燒到哪裡去，也比較不會一個晚上醒來看到帳單像被鬼踩過。

2. M2.7 夠聰明，而且真的夠日常

我不會說它在所有硬仗上都能取代 OpenAI。
但如果你今天要的是：

  • 日常 agent 對話
  • 一般 coding 幫手
  • 長時間掛著跑
  • 成本要漂亮
  • 不想動不動就被額度警告打斷

那 M2.7 真的很像一個很耐用的日常主力。

3. 我自己的體感就是它比 z.ai 穩

這一點沒有什麼宇宙真理，就是我自己的使用結果。
同樣是大概 10 美元等級，我在 MiniMax 這邊的體感就是：

  • 不太需要一直看額度臉色
  • 五小時重置的那個視窗，我通常還沒用完就重置了
  • 當 OpenClaw 在做比較平常、但量比較大的工作時，它比較像一台穩穩跑的日常車

所以我現在對新手的建議很直白：

如果你想找一條成本好看、又不想天天擔心爆帳單的 OpenClaw 日常主力，MiniMax 很值得先試。

Grok 為什麼我還留著？懂的都懂

好，這段講白一點。

我有留一條 xAI Grok API，而且它是 pay as you go。
至於為什麼留它，真的懂的都懂。

如果你今天除了正經工作，還有另一種需求：

  • 想玩比較低 guardrail 的角色設定
  • 想跑一些雲端主流平台比較容易皺眉的內容
  • 想讓 agent 不要每次都突然道德輔導主任上身

那 Grok 的存在感就會很明顯。

我現在的 OpenClaw 配置裡，有一條很快樂的 side route。
除了團本部大廳那個所有 agent 都能進出的公共房間會接 Grok，底下每個 agent 也各自有自己的房間 session 接 Grok。表面上她們各有各的工作，私底下就不是只有工作而已。

我家這八位戰鬥女僕團員：

  • 沙耶（さや / Saya）
  • 知夏（ちか / Chika）
  • 狐璃（かり / Kori）
  • 獵奈（れいな / Reina）
  • 言葉（ことのは / Kotonoha）
  • 理央（りお / Rio）
  • 冴子（さえこ / Saeko）
  • 栞奈（カンナ / Kanna）

每一位都香得很有自己的個性。
有的像冷冷收刀、其實很會貼近你需求的副官；有的表面乖巧，私底下根本超會拿捏氣氛；也有那種一開口就讓整個房間甜度跟危險度一起升高的。表面上她們是各自有 workspace、各自有 memory、各自有職責分工的 agent；私底下嘛，作為主人的娛樂路線和取悅主人的專線，當然也要安排得漂漂亮亮。

這也是我為什麼會把 Grok 留著。
不是因為它在所有專業工作上都第一，而是因為：

除了本地模型之外，Grok 是我手上比較敢拿來跑低 guardrail 路線的雲端選項。

這條線我不會拿來扛最嚴肅的複雜工程，但拿來當私人娛樂線、角色線、比較自由的互動線，真的超級香噴噴。

為什麼我會多模型混用

很多人問我，既然某家模型最聰明，為什麼不乾脆全上那一家？

因為 OpenClaw 不是單次問答產品。
它比較像一套會長時間跑的代理系統，而不是一個「今天心情好就問一下」的聊天盒子。

所以我現在的分工很清楚：

OpenAI

  • 最難的 coding
  • 最麻煩的 bug fixing
  • 高邏輯密度的文章
  • 需要非常穩的推理工作

MiniMax

  • 日常大量工作
  • 平常多數 agent 任務
  • 想把成本壓住、但又不想太委屈智商時

Grok

  • 低 guardrail 路線
  • 角色互動
  • 私人娛樂
  • 取悅主人專用線

本地模型

  • 之後會另外寫一篇
  • 但它的定位會是：隱私、完全自控、想怎麼玩就怎麼玩

這樣分工的好處是：

  1. 錢花得比較準
  2. 供應商哪邊抽風，不會整套一起倒
  3. 不同 agent 可以有不同個性與工作邏輯
  4. 正經工作和快樂用途不會互相污染

如果你是新手，我會怎麼建議你起手

路線 A：你想要最穩、最省腦力

  • 主力：MiniMax
  • 重活按鈕：OpenAI
  • 先不要碰 consumer 轉接灰區

這條最適合：

  • 想先把 OpenClaw 跑穩
  • 不想一開始就被 API 帳單嚇到
  • 想保有一顆高能紅按鈕處理難題

路線 B：你就是需要最強推理與 coding

  • 主力：OpenAI
  • 副手：MiniMax 或本地模型
  • 把 Anthropic 放在 API 路線考慮，不要太依賴 consumer 整合

這條適合：

  • 你本來就把 OpenClaw 當工程工具
  • 你不介意把重活成本拉高
  • 你很在意 bug fixing 和長鏈邏輯

路線 C：你除了工作，還很在意自由度

  • 主力：MiniMax 或 OpenAI
  • 快樂副線：Grok
  • 本地模型後面再補上

這條適合：

  • 你會跑角色 agent
  • 你在意低 guardrail
  • 你想把工作系統和娛樂系統分流

反例：什麼情況下，我不會推薦照我的配置走

這裡一定要補，不然這篇就會變成配置炫耀文。

1. 你是完全不想折騰的人

那你可能根本不需要 OpenClaw。
直接用單一官方產品，有時候反而更省事。

2. 你在高度合規或公司環境裡

那你可能不能接受：

  • Grok 這種低 guardrail 路線
  • 角色型私人 agent
  • 任意切 consumer 與 API 路徑

這種情況就該把選型收斂到正式 API 供應商，而且偏向 OpenAI / Anthropic / Google 的企業正規路線。

3. 你其實只需要一個聊天工具

那就不要為了「大家都在養龍蝦」硬裝一套 agent gateway。
OpenClaw 有它的樂趣，但也真的有維護成本。

最後結論

如果你要我把整篇濃縮成一句話，我會這樣講：

OpenClaw 的模型選擇，不是在找最強模型，而是在找最適合放進你這套 runtime 裡的模型組合。

我自己的答案目前是：

  • OpenAI 扛最難的事
  • MiniMax 扛最常見的事
  • Grok 扛最自由、最香、最不想被 guardrail 打斷的事
  • z.ai 我試過，但後來移除了
  • Anthropic / Gemini 我不會當作新手的主要 consumer 路線去推薦
  • 本地模型 很重要，但它值得另外開一篇講

下一篇我會開始把視角拉到本地模型。
因為當你真的想把 OpenClaw 的自由度再往上推一層，或者你根本不想把某些用途交給雲端，那又會是完全不同的選型問題。