ClaraVerse 評測：把 ChatGPT、Claude 與 n8n 換成自架方案的代價與回報
Claraverse is a opesource privacy focused ecosystem to replace ChatGPT, Claude, N8N, ImageGen with your own hosted llm, keys and compute. With desktop, IOS, Android Apps.
秒懂
- 它是什麼？
- ClaraVerse 是一個以隱私為核心的開源 AI 工作區，整合聊天、多代理團隊、視覺化流程編輯器與 RAG。本文從安裝、架構、記憶系統到授權爭議，檢視它是否真的能取代你現有的 AI 工具鏈。
- 適合誰用？
- ClaraVerse 適合已經熟悉 Docker、Ollama 或 LM Studio，且無法接受對話紀錄存在第三方伺服器的開發者與小型團隊。它不適合需要完整企業支援、不願意自行維護多容器服務、或對授權合規敏感的使用者。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 43 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
一個想取代四種工具的野心
ClaraVerse 的定位很直接：它要取代的不只是 ChatGPT 或 Claude 這種對話介面，還包含 n8n 這種流程自動化工具，以及圖像生成服務。README 開頭就寫著「Your Private AI Workspace」，強調三個一般聊天 UI 忽略的重點：能像團隊一樣協作的代理、真正有層次的記憶系統，以及不會在你專案受歡迎後突然開始收費的授權。目標使用者很清楚，是已經有 Ollama 或 LM Studio 本機模型、不想把對話資料送出自己機器的開發者或小型團隊。它的賣點不是單一功能，而是把聊天、多代理協作、視覺化流程編輯器、Telegram 整合全部裝進同一個容器。這個野心聽起來很大，但實際要付出的代價是部署複雜度與資源需求，這些會在後續章節一一檢視。
從一行指令到多容器架構的落差
安裝有兩條路徑，但兩者能力不對等。README 提供的一行指令是 curl 腳本加 claraverse init，適合快速試用。Docker Compose 則使用 docker-compose.production.yml，這才是完整功能的正確啟動方式。單一容器模式可以跑，但 Knowledge 分頁與 search_knowledge 工具會回報「embeddings service unreachable」，因為缺少 Qdrant 與 embeddings sidecar。換句話說，如果你要的是 RAG 知識庫，你必須部署 MySQL、MongoDB、Redis、SearXNG、Qdrant 加 sidecar 的完整堆疊。這代表安裝不只是拉一個映像檔，而是要管理多個服務的狀態。硬體需求也寫得很清楚：4 GB RAM 是最低，8 GB 才建議。對比 Open WebUI 的單容器部署，ClaraVerse 的架構複雜度明顯更高，這是採用前必須接受的現實。
Crew 與視覺化流程：代理不是黑盒子
Crew 是 ClaraVerse 的多代理團隊功能。使用者給一個專案 brief，然後「雇用」一群代理，透過卡片管道（card pipeline）來管理工作。每一張卡片在送出前都會回到人類面前審查，這設計是為了避免代理在沒有監督下做出不可逆的動作。README 強調「No black box」，意思是每個代理的決策過程都可追溯。視覺化流程編輯器則讓使用者用圖形方式串接不同步驟，類似 n8n 的概念，但深度整合在同一個應用程式內。這裡的關鍵差異是，ClaraVerse 的流程編輯器與聊天、記憶系統共享同一個模型與帳號，所以流程可以呼叫 search_memory 或 add_memory 這些工具。這與 n8n 的通用節點設計不同，n8n 需要自己串接各種 API，而 ClaraVerse 的流程天生就能存取內部的記憶與代理能力。但缺點是，它的生態系封閉，無法像 n8n 那樣連接數百種外部服務。
記憶系統的實際運作：分層、加密與衰退
記憶是 ClaraVerse 最特別的設計。它不是把對話歷史當成筆記，而是分成兩個層級：Pinned 與 Recall。Pinned 記憶永遠注入，例如過敏資訊或使用者的硬性限制，這些不會被相關性評分過濾，也不會衰退。Recall 層則透過 embedding 相似度比對目前對話，只取出相關的記憶。此外，記憶有衰退機制，不常用的記憶會隨時間失去相關性，最後自動封存。重點是，記憶的提取與寫入是由模型自己呼叫工具，就像呼叫其他工具一樣。這表示 Clara 會在對話中途決定何時需要搜尋記憶，而非每次對話都注入所有內容。加密部分使用 AES-256-GCM，金鑰由每個使用者透過 HKDF 推導，README 宣稱連管理員都無法讀取。這個設計比多數聊天 UI 的「全量上下文」做法更精緻，但代價是運算資源，每次對話都要計算 embedding 相似度，而且需要 embeddings sidecar 正常運作。如果 sidecar 掛掉，整個記憶功能就會失效。
本機 AI 自動偵測：方便但可能造成資源浪費
ClaraVerse 會自動偵測本機的 Ollama 與 LM Studio。偵測每兩分鐘執行一次，當提供者離線時自動停用，回來時重新匯入模型。這對使用者來說很方便，不需要手動設定 API 位址。但這裡有幾個需要注意的點。第一，Ollama 預設只監聽 127.0.0.1，Docker 容器無法存取，所以你必須手動設定 OLLAMA_HOST=0.0.0.0，README 甚至提供了 systemd 的編輯範例。第二，每兩分鐘的輪詢會持續對本機服務發出請求，即使你沒有使用任何模型。對於筆電或低功耗裝置，這可能造成不必要的喚醒與耗電。第三，自動匯入所有模型可能不是你想要的，如果你有數十個實驗性模型，介面會被塞滿。這個功能是雙面刃，它降低了入門門檻，但同時也隱含了持續的背景活動，在資源有限的環境中需要特別留意。
授權爭議：AGPL-3.0 的雙面刃
README 的徽章顯示 AGPL-3.0，但 GitHub 的 license 欄位卻標示 NOASSERTION。這是個明顯的矛盾。AGPL-3.0 是一個強 copyleft 授權，如果你修改程式碼並提供網路服務，你必須開放原始碼。這對個人使用者沒有影響，但對企業或新創公司來說，如果他們想基於 ClaraVerse 建立商業服務，可能會遇到障礙。README 中「a license that does not start charging you once people notice your project」這句話暗示作者有意避免商業收費，但 AGPL-3.0 實際上是要求任何衍生服務都必須以相同授權釋出，這對某些商業模式是致命的。此外，license 欄位的 NOASSERTION 表示作者沒有明確宣告授權，這在開源專案中是一個風險，因為使用者無法確定授權條款是否有效。如果你打算在商業產品中使用 ClaraVerse，你必須先與作者確認授權狀態，或者諮詢法律專業人士。這不是一個可以忽略的細節。
替代方案比較：Open WebUI 與 n8n 的差異
README 自己有一個「vs Open WebUI」的章節，顯示作者知道主要競爭者。Open WebUI 是一個成熟的自架聊天介面，支援 Ollama 與 OpenAI 相容 API，但它的核心就是聊天，沒有內建多代理團隊或流程編輯器。ClaraVerse 的優勢在於整合，你把代理、記憶、流程全部放在同一個地方，不需要像 Open WebUI 那樣另外搭配 n8n 來做自動化。但 Open WebUI 的部署簡單得多，單一容器即可，而且授權是 BSD-3-Clause，商業使用幾乎沒有障礙。n8n 則是完全不同的取向，它是一個通用自動化平台，有數百個節點可以連接各種服務，但沒有內建的記憶系統或代理團隊。ClaraVerse 的流程編輯器比較像 n8n 的簡化版，只能操作自己內部的工具。如果你需要對外服務的深度整合，n8n 仍是較佳選擇；如果你要的是純聊天介面，Open WebUI 更輕量。ClaraVerse 的定位是兩者之間的縫隙，但這也意味著它在兩個領域都不夠深入。
編輯結論
ClaraVerse 適合已經熟悉 Docker、Ollama 或 LM Studio，且無法接受對話紀錄存在第三方伺服器的開發者與小型團隊。它不適合需要完整企業支援、不願意自行維護多容器服務、或對授權合規敏感的使用者。在採用前，你必須先確認三件事：其一，你能否接受 AGPL-3.0 授權對衍生服務的開源要求；其二，你的硬體是否足夠運行 Qdrant 與 embeddings sidecar，否則 Knowledge 功能形同虛設；其三，你是否願意承擔每兩分鐘一次的本機 AI 偵測可能帶來的資源消耗。若這些條件都滿足，ClaraVerse 提供了一個罕見的組合：單一介面同時涵蓋聊天、代理團隊與流程編排，而且記憶系統的設計比多數商業產品更透明。若無法滿足，請繼續使用 Open WebUI 搭配 n8n，直到 ClaraVerse 的授權與部署複雜度改善為止。
社群筆記