Nanobot 與 OpenClaw：執行時期、供應商與營運成本

如果您想要一個小型、由自己託管且只有單一 JSON 設定檔的 Python 程序，請選擇 nanobot；如果您需要由基金會支持、具備更多聊天頻道、可選代理執行環境與第一方支出報告的閘道，請選擇 OpenClaw。 兩者都是 MIT 授權、可自行託管且免費下載，因此真正的決定因素是您要運作的執行環境、要手動撰寫的供應商區塊，以及您將為其背景頻率支付 token 的方式。

於 2026 年 9 月 21 日查核的版本：nanobot v0.3.5，發布於 2026 年 9 月 15 日；OpenClaw v2026.9.5，發布於 2026 年 9 月 19 日。OpenClaw 的 npm 記錄在本次查核前十天內有四次發布，涵蓋穩定版與延伸穩定版分支，因此請查看版本發布動態與 npm 記錄，不要依賴任何比較頁面（包括本頁）引用的版本。

首先，確認您安裝的是哪個 nanobot

本頁介紹的是HKUDS/nanobot，這是香港大學資料智能實驗室提供的 Python 個人助理框架，文件位於 nanobot.wiki。兩個近似名稱的專案會將買家導向錯誤的軟體：

• obot-platform/nanobot 位於 nanobot.ai，是另一個採 Apache-2.0 授權、用於建立 MCP 代理的獨立 Go 專案。它的功能宣稱並不是在描述 HKUDS 助理。
• 名為 nanobot 的 PyPI 套件是無關的機器人導航函式庫。正確的安裝方式是 pip install nanobot-ai，版本 0.3.5，採 MIT 授權，依據PyPI 記錄要求 Python 3.11 或更新版本。快速入門也提供會安裝或升級相同套件的安裝腳本。

也存在逐字複製描述與首頁的分支；nanobot 的部署指南也警告，第三方命名空間下的 Docker Hub 映像並非由專案維護或驗證，因此除非您信任發布者，否則不要將 API 金鑰或機器人 token 掛載到其中。對 OpenClaw 而言，官方入口是 docs.openclaw.ai、openclaw.ai、openclaw.org 與 GitHub 儲存庫；如果您在其他地方讀到下方的設定金鑰，請以這些來源進行核對，因為複製內容可能恰好在這些金鑰上過時。

誰應該選哪一個

當工作流程是一個人、一台機器、一個設定檔時，請選擇 nanobot。 它的完整設定是 ~/.nanobot/config.json，使用 camelCase 金鑰；其持久狀態位於代理工作區——預設為 ~/.nanobot/workspace/——以 SOUL.md、USER.md 與 memory/MEMORY.md 的形式存在，詳見其記憶參考。如果您想在將它託付給訊息帳戶之前了解每個運作元件，較小的介面確實是一項優勢。它自己的OpenAI 相容伺服器也使其成為其他工具的實用後端，預設繫結至 127.0.0.1，且沒有 API 金鑰時拒絕在 0.0.0.0 上啟動。

當工作流程是需要營運的部署時，請選擇 OpenClaw。 其頻道目錄列出 32 個頻道，其中少數隨核心安裝附帶，大多數則以官方或外部外掛形式安裝；它將代理工作區與狀態目錄分開，因此您可以重新定位任一者，並附帶 使用量追蹤，包括 /status、/usage cost 與 openclaw status --usage。它也將模型參照與代理執行環境分開，因此單一部署可以並行驅動 API 金鑰路由與供應商 CLI 帳戶。

在執行與權限模型方面，兩者都預期需要相同的工作。 兩者都維持一個負責背景傳遞的長時間執行閘道，且都將自訂端點視為明確的信任決策：OpenClaw 將自訂 baseUrl 視為針對該確切通訊協定、主機與連接埠範圍的網路信任授予；在沒有明確選擇加入的情況下，metadata、link-local 與本機使用 NAT64 來源仍會遭封鎖，其他私有或 CGNAT 範圍則需要 request.allowPrivateNetwork: true，其預設值為 false。

在成本路徑上，差異在於可見性，而不是價格。 兩個程式都是免費的。OpenClaw 會報告 API 金鑰工作階段的工作階段 token 與估算成本，並隱藏按方案計費工作階段的每 token 美元估算。nanobot 的 WebUI 顯示每輪 token 與快取圖表，並明確表示這些數字不是計費帳單；其 CLI 參考中沒有彙總支出指令。HKUDS/nanobot 中關於成本追蹤的公開請求，即 issue #1193（最後更新於 2026 年 2 月 25 日）與 #2020（最後更新於 2026 年 3 月 16 日），目前都仍未關閉——但不要將那些標題解讀為今天的功能集合，因為每輪顯示確實存在。缺少的是彙總功能。

在遷移成本方面，應規劃重寫，而不是匯入。 OpenClaw 的 記憶體匯入工具涵蓋 Codex、Claude Code 與 Hermes，而兩個專案都未記錄可雙向互相匯入的工具。供應商區塊、預設設定、頻道憑證、排程與記憶檔案都必須手動重新建立。

有一點是兩種選擇都不能據以判斷的：不存在共用基準測試，兩個專案也都未發布任務品質數據。nanobot 的 README 宣稱具備「小巧、易讀的核心」，但完全未發布行數，因此其他地方引用的任何具體行數都不是供應商聲明。程式碼大小無法預測任一方向的任務品質。

nanobot 與 OpenClaw 一覽比較

Star 數量衡量的是某一天的關注度，而不是成熟度或支援程度，且兩者每天都會變動——請直接從兩個儲存庫讀取，而不是從次級頁面讀取。在授權列上存在已記錄的歧異：GitHub API 中繼資料顯示 openclaw/openclaw 未聲明授權，但 LICENSE 檔案載有 MIT 文字，沒有商標或命名條款，後面只有指向 THIRD_PARTY_NOTICES.md 的指標。請閱讀該檔案，並在發布任何基於它的內容前自行確認。

供應商設定才是真正的差異

兩個用戶端都能呼叫 OpenAI 相容或 Anthropic 相容端點。它們選擇端點的方式不同，而這項單一事實正是可運作的設定無法在兩者之間直接轉換的原因。

nanobot 會依據你寫入的供應商索引鍵來決定。 根據其 供應商參考文件，你在 providers 下自行建立的任何索引鍵都會被視為直接的 OpenAI 相容供應商；由於 nanobot 無法知道端點 URL，因此必須設定 apiBase，而 apiKey 則為選用。對於 Anthropic 相容閘道，你必須改為保留供應商 anthropic，並覆寫其 apiBase：文件指出，任意自訂供應商名稱僅支援 OpenAI 相容格式，不會使用 Anthropic Messages 要求格式。這是本比較中最大的設定陷阱。

{
  "providers": {
    "kunavo": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com/v1"
    },
    "anthropic": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com"
    }
  },
  "modelPresets": {
    "openaiShaped": {
      "provider": "kunavo",
      "model": "claude-sonnet-5",
      "maxTokens": 1024
    },
    "anthropicShaped": {
      "provider": "anthropic",
      "model": "claude-sonnet-5",
      "maxTokens": 1024
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "openaiShaped"
    }
  }
}

這裡名稱會造成兩次影響。請避免與 openai、openai-codex、github-copilot 或 lm-studio 等內建名稱衝突，也不要在自訂索引鍵上設定 apiType——該欄位僅適用於 providers.openai。使用明確命名的自訂供應商時，模型 ID 會依原樣傳送，因此 model 必須完全符合端點預期的 ID；只有在 provider: "auto" 下才會去除相符的前綴。該覆寫會直接修改 anthropic 供應商區塊本身，因此所有指向該供應商的預設設定都會將閘道視為直接 Anthropic 的替代，而不是並列使用。另請注意，為相容性而接受 snake_case 索引鍵，但 nanobot 寫回磁碟時會使用 camelCase。

OpenClaw 透過欄位來決定。 其 自訂供應商參考文件將所有內容放在 models.providers 下的統一區塊中，其中 api 會選擇要求轉接器。該參考文件列出十一個值，包括 openai-completions、openai-responses、anthropic-messages、google-generative-ai、ollama 與 bedrock-converse-stream；OpenClaw 的 v2026.9.7 設定結構描述接受第十二個值 google-interactions，該值於 2026 年 9 月 25 日加入，目前僅在其 Google 供應商頁面上有文件說明。若 baseUrl 未設定 api，則預設為 openai-completions。

{
  "models": {
    "mode": "merge",
    "providers": {
      "kunavo": {
        "baseUrl": "https://api.kunavo.com",
        "apiKey": "${KUNAVO_API_KEY}",
        "api": "anthropic-messages",
        "authHeader": true,
        "models": [
          {
            "id": "claude-sonnet-5",
            "name": "Claude Sonnet 5",
            "input": [
              "text"
            ],
            "contextWindow": 1000000,
            "maxTokens": 1024
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "kunavo/claude-sonnet-5"
      }
    }
  }
}

僅在 agents.defaults 下新增模型參考並不會註冊模型：models.providers.<id>.models[] 中必須存在具有相同 id 的相符項目。上方的 1024 是首次試用時刻意設定的小型輸出上限，不是模型的最大值；請從與你路由的模型相對應的 模型頁面取得 contextWindow 與 maxTokens。Kunavo 尚未讓任一用戶端對其端點執行測試——這些設定區塊是於 2026 年 9 月 21 日從兩個專案各自的設定參考文件中查閱取得的，在採用這些設定執行排程工作前，仍需先自行進行範圍受限的試用。

第三方端點無法存取的內容

兩個專案都記錄了自訂端點會失去的特定功能。這些是價格比較通常略過的部分，卻會改變低價路由實際付出的代價。nanobot 列來自上方連結的供應商參考文件；OpenClaw 列則來自同一份設定參考文件，以及其 自訂供應商概念頁面，該頁面記錄了標頭遭捨棄的行為。

有兩項後果值得納入規劃。首先，在 OpenClaw 將 OpenAI 相容路由指向非原生主機時，設計上會捨棄用戶端的提示快取提示，以及 service_tier、store 與歸因標頭；而 anthropic-messages 路由則會捨棄隱含的 beta 標頭。這改變的是用戶端要求的內容，而不是端點本身是否快取——端點若在自身端進行快取，仍然可以快取，而 OpenClaw 文件並未表示相反情況。因此不要假設任一結果：在將週期性工作預算為已快取前，請確認回傳的使用量。提示快取指南說明快取運作時使用量欄位應呈現的樣子。

其次，在 OpenClaw 中，執行環境與供應商同樣重要。執行環境參考文件會在解析供應商與模型後解析執行環境，並允許使用 models.providers.<provider>.agentRuntime 為每個供應商固定一個執行環境：內建的 openclaw 執行環境會自行執行準備好的回合，而 codex、claude-cli 與 copilot 則透過攜帶自身訂閱憑證的供應商後端執行。文件同樣未說明這些後端是否遵守自訂的 baseUrl，因此請將 Kunavo 風格的金鑰視為應放在 openclaw 執行環境上，而不要假設可以重新導向 CLI 後端。在 nanobot 中，相應的界線是訂閱帳戶本身就是 OAuth 供應商，透過 nanobot provider login 登入；其供應商參考文件指出，OAuth 供應商不是有效的自動備援選項，而閘道金鑰不會繼承這些特性。OpenClaw 的 README 表示它沒有付費層級、託管服務或代幣，nanobot 的文件也未描述任何付費層級，因此兩者都未記錄軟體方案限制。

營運成本：軟體是 $0，但執行頻率不是

nanobot 依其 儲存庫授權採 MIT 授權，而 OpenClaw 的 README 表示它沒有付費層級、託管服務或代幣。兩者都未發布使用量基準測試，因此以下內容是根據所述假設進行的算術計算，不是實測結果，也不是帳單上限。

假設單一助理每天處理 30 個回合、持續 30 天，每回合假定有 6,000 個未快取輸入權杖與 400 個輸出權杖——每月共 5.4M 個輸入權杖與 360,000 個輸出權杖。依目前的 Kunavo 目錄費率，Claude Sonnet 5 每百萬個輸入權杖列為 $1.40，每百萬個輸出權杖列為 $7.00；Claude Haiku 4.5 則列為 $0.70 與 $3.50。

心跳列使用 OpenClaw 自己的數據：其 心跳參考文件指出，心跳會執行完整的代理程式回合；API 金鑰驗證的預設執行頻率為 30 分鐘，OAuth 則為一小時；而 isolatedSession 會將每次心跳的權杖成本從約 100K 降至約 2 至 5K 個權杖。這是整個比較中最大且可控制的項目，與你選擇哪個用戶端無關。這些是在所述假設下進行的權杖算術估算，不包括快取費用、心跳回合的輸出、外部工具與託管費用。

有兩項資訊缺口需要坦誠說明。目前尚未確認在沒有 agents.defaults.heartbeat 區塊的情況下，OpenClaw 是否會執行心跳機制——文件提供了執行間隔的預設值，卻未說明這項功能是否預設啟用——因此，請將上方各列視為您自行設定心跳機制後的成本。而 nanobot 的設定參考文件確實預設啟用閘道心跳，每 1800 秒執行一次，例行結果會「靜默略過」；同一份參考文件也將心跳評估列為會開啟模型串流的內部任務之一，因此，被略過的心跳不一定不產生費用。該文件未公布每次心跳的 token 用量，因此無法根據 nanobot 自身的文件確定其閒置成本。在確定執行排程之前，請先讓兩者在沒有其他活動的情況下各執行一天，測量實際用量。

OpenClaw 預設啟用的是記憶整合，每天 03:00 依 cron 執行，使用代理程式的預設模型，除非你設定 dreaming.model——將其指向較便宜的模型只需修改一行。nanobot 也有相同形式的工作：其 記憶參考文件指出，Dream 預設依 cron 排程執行，並接受指定較便宜預設設定的 modelOverride，因此兩邊都要將這項成本納入預算。其獨立的 idleCompactAfterMinutes 預設值為 15，是壓縮計時器，而不是排程模型呼叫；文件將該預設值與典型 KV 快取到期視窗相關聯。兩個專案都未發布每次整合程序的權杖數據，而且兩套系統彼此無關——不要將一個專案的數據套用到另一個專案。

除了權杖之外，還要預算維持閘道執行的機器，以及任何付費頻道或工具帳戶：OpenClaw 的 SMS 頻道需要設定 Twilio，而其 Signal 頻道透過 signal-cli 執行，可使用本機精靈或容器，並具有自己的號碼；nanobot 的轉錄選項以及任何影像或搜尋工具則是獨立帳戶。

如果您想以預付額度支付模型端的費用，而非採用訂閱制，Kunavo 的最低儲值金額為$10 的預付額度，且餘額不會到期。請先閱讀計費指南：目錄中的費用估算並非上限，因為當依上游成本計費的金額超過估算時，實際收費可能更高。當您準備好在所選的用戶端中進行這項有明確範圍限制的試用時，請建立 Kunavo 帳戶。

在兩者之間移轉，任一方向皆然

不要假設任何內容會自動轉移。供應商區塊必須手動改寫成另一種結構；nanobot 的 modelPresets 項目在 OpenClaw 中沒有直接對應的 models.providers.<id>.models[]，反之亦然。每個頻道的憑證都必須重新核發。排程會以定義而非狀態的形式移轉：nanobot 將 cron 狀態保存在 <workspace>/cron/jobs.json，而兩個產品都要求閘道程序持續執行，排程項目才會觸發。

記憶是值得刻意匯出的部分。nanobot 的持久知識位於工作區中的 SOUL.md、USER.md 與 memory/MEMORY.md，該工作區預設為 ~/.nanobot/workspace/。OpenClaw 預設將工作區保存在 ~/.openclaw/workspace，與存放設定、憑證及工作階段的 ~/.openclaw/ 分開；依其 代理程式工作區參考文件，可使用 OPENCLAW_WORKSPACE_DIR 覆寫預設工作區路徑。請複製檔案，然後在目的地讀取它們——帶過去一個檔案並不能證明下一個工作階段會取回正確的事實。

先移轉一項週期性工作，並保留舊安裝，直到替代方案完成該工作且能在重新啟動後正常運作。如果候選名單實際上是 OpenClaw 與 nanobot 以外的其他方案，請依工作流程比較替代方案；如果你已選定 OpenClaw、只需要模型路由，供應商比較與營運成本分析會比本頁深入。

常見問題

2026 年 9 月 21 日查核的來源文件：兩個儲存庫、其發布的文件、nanobot-ai 的 PyPI 紀錄，以及 openclaw 的 npm 紀錄。2026 年 10 月 1 日，OpenClaw 的 api 值與 openai-completions 預設值已根據其閘道設定參考文件、Google 供應商頁面及 v2026.9.7 的設定結構描述重新查核。Kunavo 尚未對任一用戶端進行執行時測試；設定區塊取自供應商文件。Kunavo 費率來自即時目錄，總額是在所述假設下進行的詞元算術計算，不是實測任務成本。