holaOS 評測：把 Claude Code 與 Codex 放進同一個桌面的代價與回報
Open-source agentic workspace enterprises can make their own. Connect the systems you already run — 100+ integrations, MCP, chat tools, apps, browser, local files — with shared memory. Any agent (Claude Code, Codex), any model, or BYOK. Set up in clicks, not months. Local-first: your data never leaves your machines.
秒懂
- 它是什麼？
- holaOS 是一個以 Electron 打造的開源 agentic workspace，宣稱能讓 Claude Code、Codex 與內建代理並排運作，共享記憶、工具與應用。本文檢視其架構、安裝流程、授權陷阱與真正的適用邊界。
- 適合誰用？
- holaOS 適合已經在跑 Claude Code 或 Codex、但受不了每次切換專案都要重建工具脈絡的工程團隊。它把「代理的桌面」這件事做成產品，用 Electron 換取跨平台，用本地優先換取資料主權，代價是記憶與整合都鎖在單一應用程式裡。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 25 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決什麼問題，誰需要它
holaOS 要解決的問題很具體：代理工具各自為政。Claude Code 在終端機裡跑，Codex 在另一個環境，Slack 的決策躺在聊天紀錄裡，Notion 的內容在瀏覽器分頁。工程師被迫把同一段脈絡重講三次，一次講給 Claude Code，一次講給 Codex，一次寫進文件。holaOS 把這些全部拉進一個 Electron 桌面視窗，讓應用與代理並排顯示，號稱「設定只要點幾下，不用幾個月」。目標對象是已經在用代理寫程式或處理業務的團隊，尤其是那些工作流程散落在 Slack、飛書、釘釘、微信，又不想把資料送上雲端的企業。它不追求取代你的代理，而是當代理的宿主。這個定位跟多數 agent 平台相反，多數平台綁定自家代理，holaOS 則宣稱讓 Claude Code、Codex 與內建代理共用同一套記憶、工具與技能。對已經投資特定代理生態的團隊，這是切入點；對還沒有代理工作流的團隊，它反而增加了一層要學的桌面環境。
架構拆解：Electron 外殼、MCP 中樞與共享記憶
從 README 與 repository 結構可以看出，holaOS 本質是一個 TypeScript 寫成的 Electron 桌面應用。Electron 意味著它同時有 Chromium 渲染層與 Node.js 主進程，這解釋了為什麼它能讓「應用與代理並排顯示」：HolaApp 實際上是嵌在視窗裡的 webview 或 iframe，代理則透過 MCP 協定驅動這些頁面。文件描述「把 HolaApp 指向任何 URL 與 MCP server」，這表示第三方應用不是原生整合，而是代理透過 MCP 工具去操作一個遠端或本機的網頁介面。共享記憶是核心賣點，但 README 在「One memory, every agent」處被截斷，只留下「Con」開頭，無法確認記憶是向量資料庫、SQLite 還是檔案系統。這是一個關鍵的未知數，因為「共享記憶」的實作方式直接影響效能與隱私。資料流大致是：使用者授權某個工具（如 Slack），代理經由 MCP server 讀取聊天內容，然後把結果寫回應用介面，整個過程都在本機執行。MCP 在這裡不是附屬功能，而是骨幹，它同時承載工具呼叫、應用驅動與記憶存取。架構上有一個明顯的權衡：所有整合都依賴 MCP server 的品質與隔離，如果一個 MCP server 寫得粗糙，代理可能拿到錯誤的脈絡，甚至誤觸本機檔案。
安裝與第一個工作區：命令、設定與真實路徑
README 的 Quick Start 段落被截斷，但從 badges 與描述可以推斷，holaOS 提供 macOS（Apple Silicon 與 Intel）、Windows 與 Linux 的安裝檔，因為它標明是 Electron desktop。沒有看到 `npm install` 或 `git clone` 的開發者安裝指令，這表示一般使用者預期下載編譯好的 binary，而不是從原始碼建置。啟動後，流程大概是：建立或登入帳號（網站有 signin 頁面），然後從 marketplace 安裝 HolaApp。設定模型時有兩條路，一是用平台內建模型（如 Kimi K3、GLM 5.2、GPT 5.6），二是 BYOK，文件寫明「bring your own keys for OpenAI, Anthropic, or any OpenAI- or Anthropic-compatible endpoint」，這些金鑰跑在使用者自己的帳號下。MCP 伺服器可以自帶或從社群安裝，Skills 則是把工作流程打包成可重複執行的單元，Combos 是技能與整合的捆綁。真正的設定成本不在安裝，而在授權範圍，文件強調「access is granted per tool and per scope, and the agent reads nothing until you approve it」，這表示每次代理要讀取新範圍都需要使用者點擊核准。這個設計安全，但也繁瑣，如果團隊每天有數百次代理請求，核准彈窗會成為瓶頸。
本地優先的界線：資料不出機器，但整合的盡頭仍是雲端
holaOS 最大的賣點是「local-first, your data never leaves your machines」。這句話需要拆開看。代理本身、記憶、HolaApp 的執行確實在本機，但當你連接 Slack、Gmail、Notion 這些服務時，資料本來就儲存在那些公司的雲端。holaOS 的本地優先指的是「不經過 holaOS 的雲端」，而不是「不經過任何雲端」。如果你用內建模型（GPT 5.6、Claude Opus 5），你的提示詞與檔案內容會送給那些模型供應商，這跟 BYOK 模式不同，BYOK 時請求直接打到你的 OpenAI 或 Anthropic 帳號，但資料仍然離開機器。真正的本地只有在接本機模型（如 Ollama 這類 OpenAI-compatible endpoint）時才成立，但 README 沒有提到任何本機模型支援。文件說「customizing it never means handing your work to someone else's cloud」，這句話在整合第三方服務時顯然不成立，因為那些服務本身就是雲端。這是行銷語與工程現實的落差，採用者必須自己想清楚：你要保護的資料是「holaOS 的對話紀錄」還是「Slack 的內容」？前者本地優先成立，後者取決於 Slack 的設定。
真正的限制：Electron 的重量、核准疲勞與記憶的黑箱
holaOS 有幾個沒有在 README 正面回應的限制。第一，Electron 應用天生吃記憶體，一個視窗同時跑 Chromium、Node.js、多個 webview（HolaApp）與代理程序，對 8GB RAM 的機器是負擔。文件完全沒提最低硬體需求，這對企業部署是麻煩，因為 IT 部門需要知道基準。第二，核准機制雖然安全，但沒有提到批次核准或規則式授權，如果代理需要讀取整個 Slack 頻道歷史，每次都要點核准會讓自動化形同虛設。第三，記憶的實作是黑箱，README 截斷在「Con」，我們無法知道記憶是長期向量儲存還是短期工作階段，也無法知道記憶如何被不同代理（Claude Code 與 Codex）一致地讀取。第四，MCP server 的安全性沒有被討論，任何 MCP server 都有權限執行工具與讀取檔案，holaOS 沒有提到 sandbox 或權限限制。最後，它宣稱「set up in clicks, not months」，但整合 100 多種工具背後的 OAuth 流程，每一種都可能需要管理員核准，實際設定時間可能遠超過 clicks。這些限制不必然是致命傷，但文件把它們包裝成「一切都很簡單」，這對企業評估是誤導。
替代方案：open-webui 與 Dify 的差異
holaOS 不是唯一一個想當「代理工作台」的開源專案。open-webui 是更輕量的選擇，它提供網頁介面，讓使用者連接 Ollama、OpenAI 相容 API，並有簡單的 RAG 與工具支援。差別在於 open-webui 沒有桌面外殼，也沒有「應用並排」的概念，它純粹是對話介面，代理無法驅動真實的 Notion 頁面或瀏覽器。Dify 則是另一個極端，它提供視覺化的工作流編排、知識庫與完整的應用生命週期管理，適合要建構面向使用者的 agent 服務，而不是個人工作台。holaOS 的獨特位置在於「代理與應用共享同一個螢幕」，open-webui 做不到，因為它沒有 webview 容器；Dify 做不到，因為它專注在後端編排，而不是前端整合。若你的需求只是「讓 Claude Code 有圖形介面」，open-webui 的對話介面可能就夠，而且它用 MIT 授權，沒有 hololaOS 的 Modified Apache 2.0 問題。若你的需求是「讓非工程師也能設定多步驟 agent 流程」，Dify 的拖曳介面更直覺。holaOS 的取捨是：它把所有東西綁在一個 Electron 程序裡，換來整合性，但失去模組性。
授權與維護成本：Modified Apache 2.0 不是 Apache 2.0
repository 的 license 欄位是 NOASSERTION，但 README badge 寫 Modified Apache 2.0。這是一個需要警惕的訊號，NOASSERTION 表示 GitHub 無法自動識別授權條款，因為它被修改過。Modified Apache 2.0 意味著原始 Apache 2.0 的條款被更動，常見的修改包括額外的限制（如禁止 SaaS 再散佈、或要求商標授權）。對企業來說，這不是可以忽略的細節。Apache 2.0 允許商業使用、修改與再散佈，但修改版可能加上「你不能用我們的名字促銷」或「你不能移除這個 notice」之類的條款。如果團隊想把 holaOS 整合進自家產品並再散佈，必須先取得授權全文並請法律顧問審閱。維護成本方面，專案最後一次 push 是 2026-08-21，最近一次 release 是 2026-08-06，顯示開發仍在進行，但沒有提供版本相容性政策或升級路徑。Electron 應用的升級通常需要重新下載整個 binary，不像套件管理器可以增量更新。另外，內建模型（如 GPT 5.6）的可用性依賴 holaOS 平台的合約，如果平台調整模型供應商，你的工作流可能受影響。BYOK 模式可以降低這個風險，但 BYOK 的設定文件沒有被提供，無法確認是否支援組織層級的金鑰管理。
編輯結論
holaOS 適合已經在跑 Claude Code 或 Codex、但受不了每次切換專案都要重建工具脈絡的工程團隊。它把「代理的桌面」這件事做成產品，用 Electron 換取跨平台，用本地優先換取資料主權，代價是記憶與整合都鎖在單一應用程式裡。不適合的人：需要 headless 自動化、要把代理嵌入自有 CI/CD 流程、或無法接受 Modified Apache 2.0 授權條款的團隊。採用前應驗證三件事：第一，確認 Modified Apache 2.0 的具體限制，因為它不等於 Apache 2.0，商業使用與再散佈的條件必須逐條讀；第二，測試 BYOK 模式是否真的繞過平台帳號，文件宣稱「你的金鑰、你的供應商、你的費率」，但沒有說明金鑰存放與傳輸的加密細節；第三，確認 MCP 伺服器的啟動隔離，因為每個 MCP server 都有本機檔案與網路存取權，holaOS 的文件沒有提到 sandbox 機制。若你只需要一個能接多模型的網頁介面，open-webui 更輕；若你要的是視覺化工作流編排，Dify 更成熟。holaOS 的賭注是「桌面即代理的歸宿」，這個方向有價值，但目前它的授權與安全文件都還不夠透明，這不是一個可以閉眼導入的專案。
社群筆記