OpenClaw 多代理程式與多模型：路由、隔離與成本

OpenClaw 多 agent 和多模型是同一個設定檔中的兩個不同層級：多個 agent 是 agents.entries 下具金鑰的項目，每個項目擁有自己的 workspace、狀態目錄和工作階段儲存，而多個模型則是這些項目中的逐 agent model 值。 另外還有兩個並列層級——bindings決定由哪個 agent 回應，而 fallback chain 決定某個 agent 的模型失敗時該如何處理。編輯錯誤的層級，是變更看似毫無作用的最常見原因。

執行更多代理不會增加軟體費用。OpenClaw 的文件概覽指出，該專案由「OpenClaw Foundation，一個獨立的 501(c)(3) 組織」以開放方式開發，並且「沒有付費方案，預設不會收集遙測資料，僅有可關閉的版本檢查，也不隸屬於任何實驗室」；openclaw.ai則補充「沒有訂閱。沒有託管方案。沒有代幣。」npm 套件 openclaw 採用 MIT 授權，latest 為 2026.9.5，另有版本為 2026.7.35 的 extended-stable 頻道，以及值為 >=24.16.0 <25 || >=26.1.0 的 engines.node（npm 套件登錄庫，已於 2026 年 9 月 21 日查核）。第二個代理增加到帳單上的，是 token 用量。

OpenClaw 多 agent：四個層級，以及編輯錯誤層級時的症狀

這四個層面都是於 2026 年 9 月 21 日從 OpenClaw 自己的文件中查閱得知：項目與多代理、代理繫結以及模型容錯移轉。較舊教學中的兩種形式已過時：agents.list 陣列形式的代理名單是由 Doctor 遷移的舊格式，而項目上的 default: true 標記已停用——項目頁面明確指出「default 已停用」，且多代理操作需要繫結或明確指定的目標。OpenClaw 之前也使用過另外兩個名稱，因此您找到的任何 Moltbot 或 Clawdbot 時期設定，都早於目前這個結構定義。

OpenClaw 多 agent 設定：最小化的雙 agent、雙模型設定

此片段假設您已經有可運作的 models.providers 區塊——OpenClaw 最佳 API包含 Kunavo 的設定，包括 api: "anthropic-messages" 以及發布於 Anthropic base URL 的基礎 URL。以下內容僅涵蓋 agent 和路由層。

{
  "agents": {
    "defaults": {
      "modelSelectionScope": "session",
      "model": {
        "primary": "kunavo/claude-haiku-4-5",
        "fallbacks": [
          "kunavo/claude-sonnet-5"
        ]
      }
    },
    "entries": {
      "ops": {
        "name": "Ops",
        "workspace": "~/.openclaw/workspace-ops",
        "agentDir": "~/.openclaw/agents/ops/agent",
        "model": "kunavo/claude-haiku-4-5",
        "modelPolicy": {
          "allow": [
            "kunavo/claude-haiku-4-5"
          ]
        }
      },
      "build": {
        "name": "Build",
        "workspace": "~/.openclaw/workspace-build",
        "agentDir": "~/.openclaw/agents/build/agent",
        "model": {
          "primary": "kunavo/claude-opus-5",
          "fallbacks": [
            "kunavo/claude-sonnet-5"
          ]
        },
        "utilityModel": "kunavo/claude-haiku-4-5"
      }
    }
  },
  "bindings": [
    {
      "agentId": "build",
      "match": {
        "channel": "discord",
        "accountId": "build"
      }
    },
    {
      "agentId": "ops",
      "match": {
        "channel": "discord",
        "accountId": "*"
      }
    }
  ]
}

該區塊中有四項內容至關重要。每個 agent 都有自己的 agentDir，因為多 agent 頁面警告：「Never reuse agentDir across agents — it causes auth/session state collisions.」ops agent 使用 string 形式的 model；entries 頁面將其定義為「a strict per-agent primary with no model fallback」，因此故障會直接顯示，而不會靜默地將例行工作移至更昂貴的層級。build agent 使用帶有明確 fallbacks 清單的物件形式，這就是讓 agent 啟用 fallback 的方式；failover 頁面補充說，agent 可以單獨設定 model: { fallbacks: [...] }，並繼續繼承共用的 primary。狹窄 binding 位於萬用字元之上，因為在同一個比對層級內，「the first matching bindings entry wins」。

預設代理與其他代理的工作區預設值不同，值得明確設定：預設代理的工作區是 <stateDir>/workspace，其他代理的預設值是 <stateDir>/workspace-<agentId>。記憶隨工作區而定，因為 OpenClaw 內建引擎「透過在代理的工作區中寫入純 Markdown 檔案來記住資訊」——因此，隔離工作區就能隔離記憶。工作階段權限模式又是另一個獨立面向：read-only、guarded、workspace 和 full，其中「full 需要 operator.admin。其他模式需要 operator.write」（權限模式，2026 年 9 月 21 日）。在具寬鬆權限的代理上使用便宜模型，該代理仍然具有寬鬆權限。

獨立 agent 會分開什麼——以及不會分開什麼

這是價格表忽略的界線。獨立項目會提供獨立的檔案、記憶體、歷史記錄、工具政策和儲存的 auth profile。但這些項目本身不會為每個 agent 提供環境設定自訂提供者專屬的 API 金鑰——文件記載的逐 agent schema 完全沒有 baseUrl、apiKey 或 providers 欄位。文件未提及不等於程式碼禁止，因此請將此解讀為未記載；如果需要按租戶嚴格隔離金鑰，請執行不同的 Gateway。身份也有相關限制：OpenClaw 的 WhatsApp DM 分流範例指出，「Replies still come from the same WhatsApp number — there is no per-agent sender identity」，並且「Direct chats collapse to the agent's main session key by default, so true isolation requires one agent per person.」這段話是針對 WhatsApp 所述；在泛化之前，請先查閱您所使用頻道的頁面。

在拆分角色時，還有一項能力界線值得注意：Kunavo 不提供文字轉語音、語音轉文字或 embedding 模型，因此需要語音輸出或向量索引的 agent，必須在該步驟呼叫外部提供者。

OpenClaw 多模型：嚴格模式、fallback、政策與 utility 路徑

逐 agent 模型選擇有四項值得刻意設定的控制項。model 使用字串時是嚴格模式。{ primary, fallbacks: [...] }會讓該 agent 啟用 failover。modelPolicy.allow 是一個 allowlist，會「replaces the default policy for that agent」——接受別名、精確參照和尾端萬用字元；透過它可以阻止例行 agent 觸及昂貴模型。而 utilityModel 是另一個通常較便宜的模型，用於「short internal tasks such as generated session and thread titles」，並可逐 agent 覆寫。

文件記載的觸發條件清單非常具體。OpenClaw 會在「auth failures, rate limits and cooldown exhaustion, overloaded/provider-busy errors, timeout-shaped failover errors, billing disables, model_not_found」時切換，在仍有候選模型時也會因其他未辨識錯誤而切換——但不會因上下文溢位錯誤而切換，這類錯誤會留在壓縮與重試邏輯中；也不會因「explicit aborts that are not timeout/failover-shaped」而切換。在群組和頻道對話之外，這項行為是可見的：這些介面會發布形式為 Model Fallback: <fallback> (selected <primary>; <reason>) 的狀態通知，以及相符的清除通知；而群組和頻道對話則「suppress the visible notices while retaining the same fallback state」，因此不要依賴在共用聊天室中看到通知。明確的工作階段選擇——/model、模型選擇器、session_status(model=...) 或 sessions.patch——是嚴格的：如果該模型在產生回覆前失敗，OpenClaw 會回報失敗，而不是使用已設定的 fallback 回答。Cron 工作的 --model 不屬於這些情況；文件稱其為仍會使用已設定 fallback 的工作 primary，除非工作設定了 payload.fallbacks: []。

另外兩項機制會決定您的意圖是否能保留。請求參數會透過四個層級合併，從 agents.defaults.params 到 agents.entries.*.params，後面的層級會依鍵覆寫前面的層級。平行處理也有計算出的上限：agents.defaults.maxConcurrent 預設為 max(8, available CPU parallelism * 4)，跨工作階段套用，而每個工作階段仍保持序列化——同一個 agent 的兩則訊息不會同時執行。若要選擇哪個模型適合哪種角色，Opus vs Sonnet vs Haiku涵蓋能力層面。

按路由而非 agent 歸因成本

由於沒有任何已記載的命令會回報逐 agent 支出，因此請按路由歸因。以下算術是示意性估算，不是實測帳單，也不是上限。假設一個 30 天月份、文件記載的 30m Heartbeat 預設值（1,440 次執行）、每次 Heartbeat 300 個輸出 tokens、沒有快取命中，以及主要對話路徑包含 8M 個輸入 tokens 和 500K 個輸出 tokens。每次執行約 100K 和約 2–5K 的上下文數據，是 OpenClaw 自己用來說明 isolatedSession 移除內容的範例，並非本文實測；3,000 是其中點。費率是即時的Kunavo 目錄價格，單位為每百萬 tokens。

Claude Haiku 4.5 在即時目錄中列出每百萬輸入／輸出 tokens 的 $0.70 / $3.50，而 Claude Opus 5 列出 $3.50 / $17.50。需要注意的解讀是：在這些假設下，排程路徑占主導地位。使用強模型的共用工作階段 Heartbeat 每月約為 $511.56，相同頻率但在便宜模型上使用 isolatedSession: true 則為 $4.54。OpenClaw 自己也如此說明——「Heartbeats run full agent turns. Shorter intervals burn more tokens」——並列出 isolatedSession、lightContext、較便宜的 model 和 target: "none" 作為可調整因素。

便宜的心跳方案有一種已記錄的失效模式，這也是為什麼單獨使用 isolatedSession 比只替換模型更有效。心跳會「在執行完成後保留共用工作階段現有的執行階段模型」，因此，將工作階段切換至較小模型的心跳，可能會讓該模型留到下一次主要工作階段回合，接著可能回報內容超出限制——OpenClaw 的復原訊息稱之為 心跳模型滲漏。文件中的實作範例是具有 32k 視窗的本機模型，因此風險大小取決於心跳模型的內容視窗比共用工作階段需求小多少。有一項排程注意事項：文件記載的預設間隔為 30m，只有在解析後的驗證模式為 Anthropic OAuth/token 時才會提升為 1h，因此純 API 金鑰路由會維持 30m，除非您自行設定 heartbeat.every。在編列預算前，請先確認您自己的值。

關於美元數字有兩項注意事項。Kunavo 的目錄金額是計費下限，而不是上限：上游回報其費用時，帳單金額取目錄成本與上游成本乘以適用加成之中的較高者。此外，若自訂提供者宣告時未提供每個模型的 cost 物件，OpenClaw 自己的讀數就沒有用——它會預設為 cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }，顯示 $0，而供應商仍會正常計費。請在您新增的每個模型上宣告 cost、contextWindow 和 maxTokens，並與提供者帳本核對。Kunavo 預付額度的最低加值金額為 $10 ——這是資金最低門檻，不是任務費用或訂閱費。請參閱 計費詳細資訊 和 AI 成本最佳化。

哪種購買路徑適合多代理程式 Gateway

關於 API 方言有一項注意事項，因為快取是節省成本的關鍵。相關指南中的 Kunavo 區塊宣告 api: "anthropic-messages"，OpenClaw 會將其視為非直接連接 Anthropic 的端點。由此會產生兩項文件記載的後果。這類端點不會自動附加 Anthropic beta 標頭，因此交錯思考等功能必須透過明確的 headers["anthropic-beta"] 選擇啟用，而不是自動啟用。此外，必須主動要求快取：OpenClaw 只會為直接的 anthropic 和 anthropic-vertex 提供者預先設定 cacheRetention: "short"，而「自訂的 anthropic-messages 相容端點」只有「在明確設定 cacheRetention 時」才支援快取——因此請自行設定 params.cacheRetention，不要假設有預設值（提示快取，2026 年 9 月 21 日）。另一項規則涵蓋另一種 API 方言：指向非原生端點的 openai-completions 路由「不會傳送提示快取提示」。在將重複使用的上下文按快取命中編列預算前，請先確認您自己路由回報的快取使用量。提示快取涵蓋費率部分。

確認它已套用到您指定的位置

openclaw config validate
openclaw gateway restart
openclaw agents list --bindings
openclaw models status --agent ops --json --check
openclaw models list --agent build

設定驗證會檢查結構，而 Gateway 重新啟動會重新載入設定；兩者都無法證明已成功完成計費請求。openclaw agents list --bindings會顯示實際載入的路由——請優先使用它，而不是 --tree；後者出現在概念頁面中，但不在 CLI 指令表中。openclaw models status --agent <id>會說明該代理程式設定的預設值，而 models list --agent <id>會顯示其清單。如果 models set在遇到未知提供者時以非零狀態結束，那就是模型層問題：提供者必須是已安裝的外掛程式，或宣告於 models.providers下。如果訊息沒有到達任何代理程式，那就是路由層問題。如果多個代理程式共用一個頻道後出現重複執行，OpenClaw 文件將 機器人迴圈防護金鑰列為防護機制——文件描述的是預防，而不是根本原因，因此請先診斷，再假設原因。

接著為每個代理程式執行一項有界任務，並讀取您的提供者帳戶為其記錄的費用。Kunavo 尚未對 OpenClaw（單代理程式或多代理程式）進行執行階段測試：以上內容全部來自 OpenClaw 已發布的文件，而已發布的設定並不等於相容性測試。在嘗試期間，請保留一條可運作的路由。請從提供者設定開始，在OpenClaw 定價中比較完整的運作帳單，準備為金鑰提供資金時再建立 Kunavo 帳戶。

常見問題

已於 2026 年 9 月 21 日檢查 OpenClaw 文件、CLI 參考資料和 npm 登錄項目，套件版本為 2026.9.5；此處未實際執行 Gateway、代理程式、繫結或付費請求。Kunavo 權杖費率取自即時目錄，本頁所有美元數字都是示意性的權杖算術，而非實測帳單。