by Rain Chu | 7 月 20, 2026 | AI, Tool
Orca 是 AI coding agent 的控制台，它把 Codex、Claude Code、OpenCode、Pi 這些 CLI agent 放進同一個開發環境，並且用 Git worktree 把每個任務隔離開來。這對已經開始同時使用多個 AI 編程工具的人很關鍵。
單一 Agent 的時代，問題通常是模型會不會寫，多 Agent 的時代，問題變成誰負責哪個分支、誰改了哪些檔案、怎麼比較成果、怎麼把最好的解法合回主線，Orca 想解的是後面這一段。
先講結論
Orca 是 stablyai 開源的 AI Development Environment，官方用法是把 Codex、Claude Code、OpenCode、Oh My Pi(OMP) 或其他 CLI agent 並排跑起來，每個 Agent 都在自己的 Git worktree 裡工作，最後由使用者比較差異、審查結果，再決定要合併哪一版。
我會把 Orca 看成 OpenWork 這類 OpenCode 工作台 的更完整版本，OpenWork 偏向把本地 Agent 工作桌面化，Orca 則更強調多 Agent orchestration、worktree 隔離、手機 companion、任務恢復和差異審查。
Orca 的核心不是多開終端，而是讓每個 Agent 有隔離環境，最後可以比較成果再合併。
Orca 解決的是多 Agent 失控問題
只跑一個 Codex 或 Claude Code 時，管理成本還可以接受，但當你同時讓三個 Agent 嘗試三種解法，麻煩就來了，檔案會互相覆蓋，終端輸出會混在一起，分支會弄亂，最後還要靠人回頭找哪一版比較好。
Orca 的做法是把每個 Agent 放進獨立 worktree。你可以把同一個 prompt 丟給多個 Agent，讓它們各自改一份程式碼，互不干擾。這很適合用在 bug 修復、重構、UI 改版、測試補齊和規格探索。
這和 用 Superpowers 建立 AI 開發紀律 的方向很接近。差別是 Superpowers 偏向規範和方法，Orca 偏向把這些工作流做進工具介面。
支援哪些 Agent
官方 README 的說法很直接：只要是能在 terminal 裡跑的 CLI agent，就可以放進 Orca。目前官方列出的包含 Claude Code、Codex、GitHub Copilot CLI、OpenCode、OpenClaude、OMP、Hermes Agent 等。這表示 Orca 不是綁定單一模型，而是把現有工具收進同一個 cockpit。
| Agent | Orca 裡的角色 | 適合任務 |
|---|
| Codex | 通用 coding agent | 改程式、跑測試、整理專案 |
| Claude Code | 強推理與長任務 | 重構、架構判斷、需求拆解 |
| OpenCode | 本地或自訂模型入口 | 低成本實驗、本地 agent 工作流 |
| OMP、Hermes 等 | 其他 CLI agent | 特定工具或特定模型路線 |
如果你已經在用 Codex 與 ChatGPT Work 的 AI 代理工作流，Orca 的價值會更明顯。它不是要取代 Codex，而是讓 Codex 可以和其他 Agent 同場協作。
Parallel Worktrees 是核心
Orca 最重要的功能是 Parallel Worktrees。你可以把同一個需求發給多個 Agent，讓它們各自在不同 Git worktree 裡完成任務。完成後再比較 diff、測試結果和實作品質。這比在同一個 working tree 裡輪流叫不同 Agent 改檔安全很多。
我會把它想成「平行探索」。不是每個 Agent 都要成功，而是讓不同模型或不同 prompt 策略同時試錯。最後人做判斷，挑一個最好的版本進主線。這比盲信單一 Agent 更符合真實工程工作。
Terminal Splits 和任務恢復
Orca 也把多面板和多終端做進介面。Terminal Splits 讓你可以把多個 Agent、測試、伺服器和 logs 並排放著看。對前端專案、後端 API、資料庫 migration 這類需要同時觀察多個輸出的任務，這會比一直切 tab 順很多。
任務恢復也很重要。AI coding agent 常常不是一次跑完，尤其遇到長時間編譯、測試失敗、rate limit 或你臨時離開電腦。Orca 把任務狀態集中管理，讓你能回到原本的 Agent session，而不是重新猜它剛剛做到哪裡。
手機遠端和語音輸入不是噱頭
Mobile Companion 乍看像附加功能，但對長時間 Agent 任務其實很實用，你可以在手機上看 Agent 是否完成，收到通知後補一句 follow-up，或遠端啟動下一個任務。這讓 AI coding 從坐在電腦前等待，變成可以非同步監看。
語音輸入也類似，很多時候我們不是缺鍵盤，而是缺一個快速把想法丟給 Agent 的入口，若搭配清楚的任務模板，語音輸入可以用來快速交代需求、補充限制或要求重跑測試。
GitHub Issue 和定時審查
Orca 官方也強調 GitHub 和 Linear 的原生整合。你可以在 app 裡看 issue、PR、project board，並從任務直接開 worktree。這讓「看任務 → 啟動 Agent → 產生改動 → review diff」變成一條線，而不是在瀏覽器、終端、IDE、Git UI 之間來回切。
定時審查 repository 是另一個有意思的方向，它適合拿來做每日或每週檢查，例如 dependency 更新、測試覆蓋率、錯誤 logs、未完成 issue、重複程式碼。這類任務不一定需要最強模型，但需要穩定排程和可追蹤結果。
和 Playwright CLI、OpenWork 怎麼搭
Orca 管的是多 Agent 和 worktree。Playwright CLI 管的是瀏覽器自動化。OpenWork 管的是 OpenCode 和本地 Agent 桌面工作台。這些工具其實不是互斥，而是分別解決 AI 開發流程中的不同層級。
我的理想組合會是：Orca 負責多 Agent 任務隔離，Codex 或 Claude Code 負責實作，Playwright CLI 負責跑 UI 驗證，Graphify 或 OpenWiki 負責專案知識。這樣 Agent 就不是聊天框，而是完整開發系統的一部分。
安裝與使用入口
Orca 官方下載入口在 onOrca.dev，支援 macOS、Windows、Linux。Windows 使用者官方 README 也提醒可以抓較新的 RC 版本，因為有 Windows fixes。手機 companion 則提供 iOS App Store、TestFlight 和 Android APK。
- 桌面版：到 onOrca.dev/download 下載
- 原始碼：stablyai/orca GitHub
- 手機 companion：官方 README 提供 iOS、TestFlight 和 Android APK 連結
- 支援 Agent：Codex、Claude Code、OpenCode、GitHub Copilot CLI、Pi、Hermes Agent 和其他 CLI agent
我的判斷
Orca 的價值，不是讓你同時叫五個 Agent 然後期待奇蹟發生。真正有用的是隔離、比較、恢復、審查和合併，多 Agent 不是數量遊戲，而是工程流程問題。
如果你只是偶爾用 Codex 改一兩個檔案，Orca 可能有點重，但如果你已經常常同時開 Claude Code、Codex、OpenCode，或想把 issue 修復、UI 測試、code review 分配給不同 Agent，Orca 就值得試，它比較像從單兵作戰進入小隊協作。
延伸資源
FAQ
Orca ADE 是什麼？
Orca 是 AI Development Environment，可以把 Codex、Claude Code、OpenCode、Pi 等 CLI agent 放在同一個介面裡並行工作。
Orca 為什麼要用 Git worktree？
Git worktree 可以讓每個 Agent 在獨立工作區修改程式碼，避免互相覆蓋檔案，也方便最後比較 diff 和測試結果。
Orca 適合所有開發者嗎？
如果只是偶爾用一個 Agent 改小檔案，Orca 可能太重。若你常用多個 Agent、需要任務隔離、差異比較、手機遠端和任務恢復，Orca 就很適合。
by Rain Chu | 7 月 8, 2026 | Agent, AI
OpenCode 和 OpenWork 這組工具，真正值得看的地方不是「又一個 Claude Code 替代品」而已，而是它把 AI Agent 從純命令列往桌面工作台推了一步, OpenCode 負責 agentic coding 的核心能力，OpenWork 則把工作目錄、Session、Skill、Plugin、MCP、權限確認和遠端 worker 包成比較容易操作的圖形介面。
這條路線剛好踩在很多人的痛點上：Claude Code 好用，但成本、封閉性和模型選擇會卡住；Codex 很適合開發工作，但一般辦公流程、跨工具流程、團隊共享設定，還需要另一層產品化介面, OpenWork 的企圖就是把 opencode 這套底層能力包成「可以給團隊重複使用的 Agent 工作流」。
如果你之前已經在看 OpenCode 如何使用本地端模型，這篇可以當成下一步：不只讓模型接進來，而是把 skills、plugins、MCP 和權限流程一起整理成可操作的工作台。
OpenWork 是 opencode 的桌面層，不是另一個單純聊天 App
OpenWork 官方把自己定位成 Claude Cowork 和 Codex 的開源替代方案，它是一個 local-first 的桌面 app，背後 powered by opencode 你可以在本機跑 host mode，也可以用 client mode 連到既有 OpenCode server, 之後透過 UI 管理 session、看 streaming event、處理 permission request、管理 templates、安裝 skills 和 plugins。
這個定位很重要。OpenWork 不是要取代 OpenCode，而是把 OpenCode 原本比較偏開發者的 CLI 體驗，變成更像工作台的產品。OpenCode 擅長讀檔、改檔、跑工具、處理任務；OpenWork 則負責讓這些能力變得可視化、可審核、可分享。
這也是我覺得它和 用 AI 組一家公司那篇可以放在一起看：真正有價值的不是單一模型多會回答，而是能不能把一套工作流程產品化，讓人、Agent、工具和權限一起運作。
OpenCode 和 OpenWork 的分工
這兩者的分工：
| 項目 | OpenCode | OpenWork |
|---|
| 核心角色 | AI coding agent 與 CLI/Server 核心 | 桌面工作台與協作介面 |
| 使用者體驗 | 偏工程師、命令列、設定檔 | 偏圖形介面、session、權限與模板 |
| 擴充方式 | plugins、agents、SDK、生態資源 | skills manager、plugins、MCP、templates |
| 適合場景 | 開發、專案自動化、終端機工作流 | 把 Agent 流程包成團隊可重複使用的工作台 |
OpenWork README 裡有一句很關鍵：它是 ejectable 意思是就算 UI 還沒包到某個能力，只要底層 OpenCode 能做，理論上還是可以回到底層去做。這是開源工具很重要的特性，因為你不會被單一 UI 的產品進度完全卡死。
安裝與模式：先分清楚桌面 App、Host mode、Client mode
OpenWork 有幾種使用方式。最直覺的是下載桌面 app；如果你想自己 build，就要準備 Node.js、pnpm、Bun、Rust/Tauri、OpenCode CLI 官方 source build 流程大致是：
git clone https://github.com/different-ai/openwork
cd openwork
git checkout dev
pnpm install --frozen-lockfile
pnpm dev
如果只想跑 CLI host，也可以用 OpenWork Orchestrator：
npm install -g openwork-orchestrator
openwork start --workspace /path/to/workspace --approval auto
這裡要注意一件事：OpenWork 的 Host mode 會在本機跑 host stack，預設綁在 127.0.0.1 Client mode 則是連到既有的 OpenCode server，如果你看到 ready 是灰色、New task 不能按，第一個方向不是懷疑模型，而是檢查工作目錄、host stack、OpenCode server、provider key 或本地模型連線是否真的準備好。
Skills、Plugins、MCP：OpenWork 真正有用的地方
OpenWork 的 Skills manager 可以列出 `.opencode/skills`，也能把本地 skill folder 匯入到 `.opencode/skills/<skill-name>` 這個方向很像 Claude Code / Codex 的 skills 概念：把常用工作流程寫成可重複使用的操作說明，讓 Agent 每次做事不用從零開始猜。
如果你站上看過 用 skill-creator 建立 Skill，OpenWork 這裡的邏輯也很接近：與其每次都寫一長串 prompt，不如把工作流程變成可安裝、可分享、可版本化的能力。
Plugin 則是 OpenCode 的原生擴充方式。OpenWork 會讀寫 `opencode.json`，Project scope 在工作目錄的 `opencode.json`，Global scope 通常在 `~/.config/opencode/opencode.json`。
awesome-opencode 這個 repo 則像是生態目錄，整理了 plugins、themes、agents、projects 和 resources 它不是核心工具，但很適合用來觀察 opencode 生態正在長出哪些周邊能力。
Build Mode 和 Plan Mode：不要一開始就讓 Agent 放手改
OpenCode 這類 agentic tool 最容易出問題的地方，是使用者還沒搞清楚任務邊界，就直接讓 Agent 進入執行狀態。比較穩的做法是先用 Plan Mode 讓它讀資料、拆任務、確認工具與風險，再進 Build Mode 讓它動手。
我會把它想成兩層：
- Plan Mode：先觀察、讀檔、列步驟、找不確定性、提出執行順序。
- Build Mode：開始改檔、跑命令、安裝依賴、呼叫工具、產出結果。
這和 Claude Code Workflow 裡的做法一致：先讓 Agent 把路線講清楚，再授權它動手。
AI Agent 的效率不是靠更衝，而是靠每一步都能回頭檢查。
本地模型與 Ollama：重點在 provider 設定，不是只裝好模型
很多人以為「Ollama 已經能跑模型」就等於 OpenWork 會自動看到它，但中間還差 provider 設定、base URL、模型名稱，以及 OpenCode / OpenWork 讀取設定檔的位置。
原則上，你要確認三件事：
- Ollama server 已經在跑，常見位置是 `http://localhost:11434`，遠端機器則要確定防火牆與 bind address。
- OpenCode 的 provider 設定有指到 Ollama 或 OpenAI-compatible endpoint。
- OpenWork 使用的 workspace / dev-mode / global config，和你實際編輯的設定檔是同一份。
這部分可以搭配 Ollama 遠端連線教學 和 LM Studio 與 Ollama 的零 API 成本環境一起看 OpenWork 不是魔法入口，它還是要靠底層 provider 設定把模型接起來。
Token 成本：免費模型不等於無限使用
免費通常代表某段時間、某個額度、某個服務條款下不用付費，不代表可以無限燒，也不代表 latency、rate limit、上下文長度和品質都沒有代價。
OpenCode / OpenWork 這種工具特別容易消耗 token，因為 Agent 會讀檔、反覆規劃、呼叫工具、看輸出、再修正你讓它處理一個大型 workspace，成本不是只有最後回答那幾百字，而是整個工作循環。
所以比較實際的策略是：
- 簡單查詢與短任務用便宜或本地模型。
- 高風險修改、跨檔案重構、複雜判斷再用強模型。
- 能寫成 skill / template 的流程就固化，減少每次重新解釋。
- 先 Plan 後 Build，避免 Agent 一路試錯燒成本。
Windows 使用者要先注意的幾個坑
Windows 問題不少，這也很符合這類 Tauri / Node / CLI 混合工具的現況。
OpenWork README 也有提到，Windows access 有一部分是透過 paid support plan；source build 則會牽涉 Node、pnpm、Bun、Rust、Tauri 和 OpenCode CLI。這不是一般雙擊安裝就結束的輕工具。
- Ready 灰色：先檢查 host stack 是否啟動、workspace 是否選對、provider 是否可用。
- New task 灰色：通常表示前置狀態未完成，例如沒有有效 session、工作目錄或 worker 尚未 ready。
- nul 檔案問題：Windows 下 `nul` 是特殊裝置名，如果工具誤產生同名檔，刪除會很麻煩。這種問題要優先回報 issue，並避免在重要目錄直接測不穩定版本。
- `.config` 目錄看起來不對：要確認你看的到底是 OpenCode global config、workspace config，還是 dev-mode 隔離狀態。
這裡我會建議用比較保守的方式測：先開一個乾淨測試資料夾，不要直接指到重要專案；先確認 session、provider、permission、簡單讀寫任務都正常，再把 OpenWork 放進真正的工作流程。
OpenWork 適合誰？
OpenWork 現階段比較適合三種人。
- 第一種是想把 OpenCode 圖形化的人。你已經接受 agentic coding，但希望有 session、permission、skills、plugins 的視覺工作台。
- 第二種是想把 Agent 工作流交給團隊的人。Templates、skills、remote sharing 這些能力，重點都是讓流程可以重複與分享。
- 第三種是正在比較 Claude Code、Codex、OpenCode 生態的人。OpenWork 讓 opencode 不只停留在 CLI，而是開始往產品化入口走。
但如果你現在只想要一個穩定、少設定、打開就能工作的辦公 AI，OpenWork 可能還會讓你覺得太工程化。它的價值在於可控與可擴充，不在於完全隱藏複雜度。
資源整理
截至我整理資料時，OpenWork GitHub repo 約 1.6 萬 stars，awesome-opencode 約 8 千多 stars 這代表生態正在被快速關注，但也代表文件、Windows 體驗、plugin 相容性和錯誤處理還會持續變動。用它之前要有「早期開源工具」的心理預期。
OpenWork 把 OpenCode 從工具變成工作台
OpenCode 已經回答了「AI Agent 能不能在 terminal 裡幫我做事」；OpenWork 想回答的是下一題：「這套能力能不能被包成一個可視化、可分享、可審核的工作台？」
現階段最好的用法，是先用 OpenCode 跑穩本地模型、provider、skills 和 plugins，再用 OpenWork 管理 session、權限、template 與團隊共享流程。
OpenWork 的重點不是多一個聊天視窗，而是讓 opencode 的 Agent 能力開始變成「可交付的工作流程」。這會是 2026 年 AI 工具很重要的一條線。
FAQ
OpenWork 是什麼？
OpenWork 是 powered by opencode 的開源桌面工作台，讓使用者在本機或遠端 server 上管理 AI Agent session、skills、plugins、MCP、templates 與權限確認。
OpenWork 和 OpenCode 有什麼差別？
OpenCode 是底層 AI coding agent 與 CLI/Server 核心；OpenWork 是圖形化桌面層，負責把 session、權限、skills、plugins、templates 與工作目錄變得更容易操作。
近期留言