Orkas：把多代理協作搬進桌面聊天視窗
Open-source multi-agent AI desktop client — build and command your AI agent team through conversation. A commander LLM dispatches sub-agents in parallel or in series; agents self-evolve via reflection and skill crystallization. Local-first, BYO LLM keys (Claude · OpenAI · Gemini · DeepSeek · Kimi · GLM · Qwen). macOS / Windows / Linux.
秒懂
- 它是什麼？
- Orkas 是一個本地優先的 Electron 桌面應用，用一個 Commander 模型把目標拆解成步驟，再分派給內建或市集代理執行。它解決的是「不想寫 orchestration 程式碼、又不想把檔案與金鑰交給 SaaS」這個夾縫需求。
- 適合誰用？
- 如果你要的是「用聊天視窗指揮一組代理、檔案與 API key 都留在自己磁碟上」，而且團隊願意接受 Electron 桌面應用與自帶金鑰的成本，Orkas 值得裝起來試一輪。如果你需要的是可版本控制、可寫進 CI 的確定性流程，它的聊天式編排在這裡就是錯的工具，該回去用 CrewAI 或 LangChain 這類程式庫。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Commander 不是聊天機器人，是派工層
README 開頭那句話講得很直白：Command a team of AI agents from one desktop chat, not one chatbot。多數桌面 AI 客戶端的模型是「你問、它答」，上下文只有一條對話串。Orkas 的模型是「你描述目標、Commander 拆解、專職代理執行」。README 給的例子是：使用者說「研究前五大競爭者、寫成報告、再做成簡報」，Commander 把目標拆成步驟，交給 DeepResearcher 蒐集並驗證來源、ContentWriter 撰寫、PptMaker 產出投影片，最後成品落在本機磁碟。
這裡的關鍵差異在於排程權。一般聊天客戶端裡，模型要不要呼叫工具、呼叫幾次，是單輪對話內的決定。Orkas 把這個決定提升到計畫層級，由 Commander 決定用哪個代理、用什麼技能與連接器、平行跑還是序列跑。README 也明講 Commander 會自己處理「沒有專職代理更適合」的分析、寫作、研究與檔案工作，所以它同時是協調者與執行者。
這個設計換來的是可讀的計畫，代價是多一層模型呼叫與狀態管理。目標拆得不對，後面所有代理都會照著錯的計畫跑完，而使用者看到的是一份看起來很完整的成品。
九個內建代理與市集的三十個
README 列出九個隨應用出廠、第一次啟動就能用的專職代理：DeepResearcher、ContentWriter、PptMaker、ProductDeveloper、OfficeWorker、VideoStudio、ImageStudio、UIDesigner、SeoGeoAgent。每個都有自己的技能、記憶與工具。市集裡另有三十個代理可瀏覽，README 也提到可以直接描述需求，讓 Commander 幫你建一個自訂代理。
從描述看，這批代理的產出型態偏向「檔案」而非「對話」：PPTX、Word、Excel、PDF、影片、HTML 優先的 UI 交付物、帶引用的研究報告。ImageStudio 與 UIDesigner 都寫明 HTML/CSS/SVG first，需要特定畫面時才動用圖像模型。這是一個務實的取捨，向量或點陣圖模型每次生成都有變異，HTML 交付物可以進版控、可以人工改。
SeoGeoAgent 的定位比較特別：給它一個 URL，它做技術審核、內容品質、Core Web Vitals、GEO citability，輸出健康分數與排序過的修正清單。這是把一個原本散在各種 SaaS 的檢查流程收進桌面應用。
需要留意的是，README 沒有交代這九個代理各自預設綁哪個模型、需要哪些權限、會不會呼叫外部 API。這些得在裝好之後從應用內確認。
本地優先的邊界劃在哪裡
README 對 local-first 的定義相當具體：對話、檔案、API key、知識庫、自訂代理都存在你的磁碟上，模型呼叫從你的機器直接送到供應商，不經過 Orkas 伺服器。這句話同時界定了隱私邊界與責任邊界。
隱私上，這比雲端 SaaS orchestrator 明確得多。雲端平台的對話、檔案與金鑰都放在供應商基礎設施上，Orkas 的比較表把這一點列為主要差異。但本地優先不等於離線可用，模型推理仍然要送到 Claude、OpenAI、Gemini、DeepSeek、Kimi、GLM、Qwen、MiniMax、Doubao 其中一家，或是你自己架的本機端點。你的提示與檔案內容會離開機器，只是接收方是模型供應商而不是 Orkas。
責任上，BYO key 意味著配額、費率、地區可用性、內容政策全部由你和供應商之間的關係決定。README 支援混搭：一個代理用 Claude、另一個用 DeepSeek、第三個接本機端點。這對成本控制有用，但也讓「這個任務為什麼花這麼多」變成需要自己追的問題。
從原始碼啟動，以及安裝檔的落差
官方對外只提供三個打包安裝檔：macOS Apple Silicon 的 Orkas-mac-arm64.dmg、macOS Intel 的 Orkas-mac-x64.dmg、Windows x64 的 Orkas-Setup.exe。Linux 沒有對應的安裝檔，README 明講 glibc-based Linux x64/arm64 目前要從原始碼執行，並指向 Quick start 一節。
這裡有一個必須說清楚的限制：本次取得的 README 內容在 Quick start 之前就被截斷，所以實際的建置指令、Node 版本需求、套件管理器、環境變數名稱我都無法從材料中確認。專案主要語言是 TypeScript、桌面框架是 Electron，這是從 repository 描述與 topics 可以讀到的，但具體的 npm 或 pnpm 指令、以及金鑰要用哪個 config key 寫入，必須回到 repo 的 Quick start 與設定文件。任何在此處補上指令的寫法都是編造。
版本節奏可以觀察：近期釋出為 v2026.8.29、v2026.8.25、v2026.8.11，大致是每兩週上下的節奏，日期型版本號。這對桌面應用來說算頻繁，升級時要預期代理記憶與自訂代理的相容性問題。
接上外部 CLI 代理與本機工具
README 有一段容易被忽略但影響採用決策的設計：Orkas 可以接入外部的 CLI coding agent，點名的是 Claude Code、Codex、OpenCode、Cline，也可以把開源專案如 HyperFrames 註冊成本機工具，全部由同一個 Commander 協調。
這代表 Orkas 不必自己重造所有能力。程式碼相關的工作可以交給已經在你機器上、已經有自己設定與授權的 CLI 代理；影片相關的工作可以交給 HyperFrames 這類本機工具。Commander 的角色因此更像調度台而不是萬能執行者。
反面推論是：這些外部依賴的安裝、版本與授權狀態不在 Orkas 的控制範圍內。CLI 代理升級後行為改變、HyperFrames 依賴缺失，症狀會出現在 Orkas 的對話裡，但根因在別處。採用前值得先確認你的環境裡這些工具是否已經穩定運作。
self-evolve 與 reflection 的代價
README 描述每個代理有自己私有的技能與記憶，並在每次任務後透過 reflection 改進，技能會結晶化（skill crystallization）下來。這是 Orkas 相對框架類方案最明顯的差異點：CrewAI 這類 Python 框架要你自己定義 crew 與 agent，行為寫在程式碼裡；Orkas 把改進迴圈內建進應用。
但這也帶來幾個沒被文件回答的問題。reflection 產生的記憶存在哪裡、格式是什麼、能不能匯出、能不能審查？技能結晶化之後，同一個代理在不同時間對同一個任務給出不同結果，要怎麼重現？版本號是日期式的，兩週一次釋出，升級時舊記憶與新技能格式是否相容？
這些不是吹毛求疵。當一個代理的產出要進到正式流程，可重現性與可審計性就是門檻。README 對 DeepResearcher 特別強調 auditable report with citations，顯示團隊在意可審計，但那是單次任務層級的審計，不是代理自身演化歷史的審計。這是我在材料裡看到最明顯的文件缺口。
和 CrewAI、LangChain 的實際差別
README 的比較表把三個對象講得算清楚。LangChain 是開發者框架與程式庫，用來在你自己寫的 Python 或 JS 應用裡建 LLM 應用與代理，是 code-first 的。Orkas 則是你用聊天指揮的桌面應用，不寫 orchestration 程式碼，資料與金鑰預設留在本機。
CrewAI 是 Python 框架，用程式碼定義 crew 與 agent 來編排角色扮演式的自主代理。Orkas 把同樣的編排概念搬進桌面應用，加上本地優先儲存與每個代理的自演化。
真正的分水嶺不是功能多寡，而是流程住在哪裡。CrewAI 與 LangChain 的流程住在版本控制裡，可以 code review、可以寫測試、可以進 CI、可以在 staging 跑。Orkas 的流程住在一個 Electron 應用與它的對話歷史裡，可以重跑，但不容易 diff 與自動驗證。
如果你的任務是人類在迴圈裡、產出是文件或簡報，Orkas 的形態是優勢。如果任務要每天定時跑、失敗要告警、輸出要進資料庫，那聊天式編排會變成阻礙，該選框架。這兩者不是替代關係，是可以並存的。
至於雲端 SaaS orchestrator，差異寫在架構上：那些平台的對話、檔案與 API key 放在供應商基礎設施，Orkas 全部留在本機。對處理敏感文件的人，這一條就足以決定。
OpenClaw 的比較在取得的 README 中被截斷，只看到它被描述為單一常駐的個人助理、跨訊息通道觸達使用者，Orkas 那一欄的內容缺失，所以我不對這個對比下判斷。
授權、升級成本與誰該先按兵不動
授權是 MIT，這是採用門檻最低的一類。實務上要留意的是：MIT 涵蓋的是 Orkas 這個應用的程式碼，不涵蓋你接入的模型供應商服務條款，也不涵蓋 Claude Code、Codex、OpenCode、Cline 這些外部 CLI 工具各自的授權。市集裡三十個代理的授權狀態，README 沒有交代。這些是採用前要自己確認的，不是法律意見。
升級成本主要來自兩處。一是日期式版本號加上約兩週一次的釋出節奏，桌面應用要跟著更新才能拿到修補。二是代理的私有記憶與結晶化技能，這些是使用者產生的狀態，升級時如何遷移決定了你要不要重新訓練代理。README 沒有描述遷移機制。
該先按兵不動的情況有幾個。你的流程需要確定性重現與自動化驗證，Orkas 幫不上。你的環境是 Linux 且不接受從原始碼建置，目前沒有安裝檔。你的合規要求是「提示內容不得離開受控環境」，那 BYO key 仍然會把內容送到外部模型，只有接本機端點才成立。
反過來，如果你做的是研究、內容、簡報、文件處理這類人類在迴圈裡的知識工作，而且已經有各家模型的金鑰，Orkas 的 Commander 加九個內建代理可以省下不少接線工作。裝完第一件事是打開一個代理的設定，確認它綁的是哪個模型、記憶寫到哪個路徑，再決定要不要讓它碰正式資料。
編輯結論
如果你要的是「用聊天視窗指揮一組代理、檔案與 API key 都留在自己磁碟上」，而且團隊願意接受 Electron 桌面應用與自帶金鑰的成本，Orkas 值得裝起來試一輪。如果你需要的是可版本控制、可寫進 CI 的確定性流程，它的聊天式編排在這裡就是錯的工具，該回去用 CrewAI 或 LangChain 這類程式庫。動手前先確認三件事：你的供應商金鑰是否支援該代理指定的模型；Linux 目前官方只提供原始碼執行路徑，沒有打包安裝檔；以及 reflection 與 skill crystallization 寫入的代理記憶實際落在哪個目錄、升級時會不會被覆蓋。
社群筆記