前言

最近在研究 stablyai/orca。如果平常會同時開 Claude Code、Codex 或 OpenCode，應該很快就會遇到幾個問題：多個 agent 可能改到同一份檔案、terminal 越開越多、很難知道誰在工作或等待回覆，也不容易比較不同 agent 對同一題的成果。

Orca 想處理的就是這一層。它不提供新的 AI 模型，而是把既有 CLI agent、Git worktree、terminal、diff、browser 和遠端環境放進同一個操作介面。官方稱它為 ADE（Agentic Development Environment）；我會把它理解成「以 worktree 為核心的 AI coding agent 控制台」。

Orca 是什麼？

Orca 是一個開源桌面應用程式，可以在 macOS、Windows 與 Linux 執行。它會啟動你電腦上原本就能使用的 CLI agent，因此模型帳號、訂閱與用量仍屬於 Claude Code、Codex 等服務，Orca 本身不是另一個模型供應商。

它的主要工作是：

  • 為每個任務建立獨立 Git worktree 與 branch。
  • 在 worktree 中啟動一個或多個 agent terminal。
  • 集中顯示 agent 的工作、完成與等待輸入狀態。
  • 比較各 worktree 的 diff，選出要留下的成果。
  • 從同一介面 commit、push、建立 PR 或刪除未採用的分支。
  • 透過 SSH、remote server 或手機繼續查看與控制 session。

官方 README 把典型情境寫得很直接：將同一個 prompt 交給五個 agent，在五個隔離的 worktree 中實作，再比較並合併勝出的版本。

為什麼核心是 Git Worktree？

一般 Git branch 只代表不同版本線；如果所有 agent 共用同一個 checkout，切換 branch 或修改檔案時仍會互相影響。git worktree 則能讓同一個 repository 同時擁有多個實體工作目錄，每個目錄各自 checkout 不同 branch。

Orca 把一個任務的生命週期都綁在同一個 worktree：

  1. 從 origin/main、其他 branch 或指定 commit 建立 worktree。
  2. 在該目錄啟動 agent、terminal、editor 與 browser。
  3. 以起始 ref 為基準查看 diff 和註解修改。
  4. Commit、push 並建立 PR。
  5. 完成後 archive，或刪除 worktree 與 branch。

因此 agent A 修改登入流程時，不會直接覆蓋 agent B 正在嘗試的另一種寫法。這是檔案層面的隔離，也是 Orca 能平行執行多個 coding agent 的基礎。Worktrees 文件 也說明 Orca 建立的是標準 Git worktree，仍可直接使用 git status、rebase 或 cherry-pick，不是只有 Orca 能讀取的專有格式。

不過，worktree 並沒有解決所有衝突。兩個 branch 若都修改同一段邏輯，合併時仍可能發生 conflict；即使 Git 可以自動合併，產品行為互相矛盾時也還是需要 review。

平行 Agent 有兩種不同用法

把不同任務分開執行

例如一個 agent 修 API、一個補測試、另一個調整前端。每個任務有自己的 worktree，適合已經能清楚切分、彼此修改範圍較少重疊的工作。

讓多個 Agent 解同一題

Orca 的入門教學則示範「race」：把相同 prompt 分別交給 Claude Code、Codex 與 Cursor CLI，等三個 branch 都產生結果後，再比較 diff 並挑出最接近需求的版本。官方 3-agent session 將完整流程濃縮為 add、worktree、agent、split、diff、ship。

這兩種模式的成本不一樣：

模式 適合情境 主要代價
一個任務一個 agent 工作可以獨立切分 需要安排依賴與合併順序
同一題交給多個 agent 解法不明確、值得比較 重複消耗模型額度與 review 時間
SSH worktree Build、GPU 或環境在遠端 需要管理主機、金鑰與連線
Remote Orca Server 希望 VPS 長時間保留 session 需要自行維護服務與網路安全
Mobile companion 離開電腦後查看或簡短回覆 適合控制，不是完整手機 IDE

Orca 提供的是執行環境與操作介面，不會自動理解哪些任務應該拆開、誰依賴誰，也不保證多個 agent 會互相協作。把同一題送給多人競賽，和具備共同計畫、能交換發現的 multi-agent system，是兩件不同的事。

支援哪些 Coding Agent？

Orca 的基本相容方式很單純：agent picker 最後仍是在 terminal 啟動一個 process，所以任何能以 CLI 執行的 agent 理論上都能加入。官方已預先設定 Claude Code、Codex、Cursor CLI、OpenCode、Gemini、Aider、GitHub Copilot CLI 等多種工具，也允許加入自訂 command。

但「可以啟動」和「完整整合」並不相同。Claude Code、Codex、Cursor CLI 等部分 agent 有帳號切換、用量或狀態追蹤；其他工具可能只有自動 setup 或啟動 command。Supported agents 文件 有列出每個 agent 的整合深度。

實際導入前仍需確認：

  • 對應 CLI 已安裝在 agent 真正執行的主機。
  • 該主機已具備模型服務的登入資訊或 API key。
  • 使用量、rate limit 與費用仍依各家供應商計算。
  • 自訂 agent 的 TTY 輸出、resume 與狀態偵測不一定都有深度支援。

不只是多開 Terminal

如果 Orca 只是一個 terminal 分割工具，就很難說明這個 repository 為何會發展成大型 Electron 專案。它把 agent 開發的其他回饋迴圈也放進 worktree：

  • Diff 與標註：檢視變更，對特定行加入註解再送回 agent。
  • Browser preview：每個 worktree 可保留自己的預覽頁面。
  • Design Mode：點選畫面上的 DOM 元素，將 HTML、computed CSS、局部截圖與可能的 source location 傳給 agent。
  • GitHub、GitLab、Linear、Jira：從 issue 或 task 建立 workspace，並在介面內處理 source control。
  • Orca CLI：用 command 建立 worktree、terminal，或對 browser 執行 snapshot、click、fill。
  • Session restore：保留 terminal scrollback、tabs 與 agent 工作狀態。

Design Mode 文件 顯示它的價值不只是「讓 agent 看截圖」，而是把使用者點到的元素及其結構化前端資訊一起交給 agent，縮短從發現 UI 問題到定位原始碼的路徑。

桌面、SSH、Server 與手機怎麼分工？

Orca 的遠端功能容易混在一起，可以用「runtime 與檔案到底放在哪裡」來理解。

SSH Worktree

Orca runtime 主要仍由筆電上的桌面程式管理，但 worktree、terminal 與 agent process 放在 SSH 主機執行。斷線後可重新連接，遠端 PTY 在 grace period 內仍能保留，也支援 port forwarding。它適合只有自己的 Orca 要控制遠端 build box 或 GPU 主機。

Remote Orca Server

遠端主機直接執行 orca serve，由該主機擁有 repositories、worktrees、terminal 與 agent sessions；筆電、browser 或 mobile 只是 client。這比較適合 always-on VPS 或需要多種 client 連接的環境。

Remote server 文件 明確提醒 pairing URL 本身會授予 runtime 存取權，應當作 secret，優先使用 Tailscale、WireGuard、LAN、SSH forwarding 或有驗證的 tunnel，不應直接把 port 暴露在公網。Runtime RPC 原始碼 顯示 WebSocket 使用 per-device token 與 TweetNaCl application-layer encryption；但加密不能取代服務暴露範圍、主機權限與 pairing secret 的管理。

Headless Linux 目前仍是 Electron runtime：官方 AppImage 需要 Electron 相關系統 library，沒有 DISPLAY 時會啟動 Xvfb，但主機必須先安裝 Xvfb。orca serve 也不會自動更新，正式環境應固定 release，記錄版本並規劃手動升級與 rollback。Headless server 原始指南 有 systemd、服務帳號與版本管理範例。

Mobile Companion

iOS／Android app 會直接與已配對的桌面或 server 連接，可以查看 agent 狀態與 terminal scrollback、回覆等待中的 prompt、看檔案、做簡單 source control 或接收完成通知。官方把它定位為 read-mostly remote control，不是完整 editor；桌面配對模式也沒有 Orca cloud relay，桌面關閉後連線就會中斷。Mobile companion 文件 說明目前這項功能仍是 beta。

最需要注意：Worktree 不是安全 Sandbox

這是我認為評估 Orca 時最重要的一點。

官方文件指出，新啟動的內建 agent 預設會加入跳過權限確認的參數，例如 Claude Code 的 --dangerously-skip-permissions、Codex 的 --dangerously-bypass-approvals-and-sandbox，以及其他 CLI 的 --yolo。使用者可以在 Settings → Agents → Agent Permissions 改回 Manual，但預設方向是讓 agent 在 disposable worktree 中不中斷地執行。

Worktree 只能隔離不同 branch 的工作檔案，不是 OS、container 或 VM sandbox。Agent process 仍可能以目前使用者的權限讀取 home directory、環境變數、SSH key、雲端憑證、其他 repository，或執行影響 worktree 以外範圍的 command。丟棄 branch 只能復原 Git 追蹤的程式碼，無法復原外部 API、資料庫、部署環境或其他檔案的變更。

因此建議先做這些調整：

  1. 不需要全自動時，把全域 Agent Permissions 改成 Manual。
  2. 遠端環境使用專用的低權限帳號，不要以 root 執行 agent。
  3. 將 production token、個人 SSH key 與不相關資料隔離出執行環境。
  4. 對必須自動執行的工作，使用 container、VM 或獨立 VPS 建立真正的系統邊界。
  5. Pairing URL、SSH credential 與遠端 port 都當作敏感資訊管理。
  6. 合併前仍要 review diff、執行測試並檢查 repository 外的副作用。

Telemetry 與資料會去哪裡？

官方 Privacy & Telemetry 說明，packaged build 預設會傳送匿名產品使用事件到美國區域的 PostHog Cloud，內容包含版本、作業系統、CPU 架構、啟動、建立 workspace 與 agent 類型等固定欄位。

文件宣稱不傳送檔案內容、prompt、agent 或 terminal output、repository 與 branch 名稱、路徑、URL、commit message、raw error 和帳號資訊。可以在 Settings → Privacy 關閉，也能設定：

DO_NOT_TRACK=1

或：

ORCA_TELEMETRY_DISABLED=1

這只描述 Orca 自己的產品 telemetry。Agent CLI、模型供應商、Git hosting、Linear 等整合服務仍有各自的資料處理規則，不能因為關閉 Orca telemetry 就視為整條工具鏈都不會傳送資料。

技術架構與專案規模

從 package.json 與原始碼結構來看，Orca 不是薄薄一層 shell wrapper：

  • 桌面端以 Electron、React、TypeScript 與 Vite 為主。
  • node-pty 負責 terminal process，xterm.js 提供 terminal rendering。
  • ssh2、WebSocket 與 relay 處理遠端連線和 session。
  • Main process 包含 Git、GitHub、GitLab、Linear、Jira、browser、SQLite、provider account、telemetry 等模組。
  • src/cli 提供 automation command，src/preload 隔開 Electron renderer 與主程序能力。
  • Mobile app 是另一套 Expo／React Native 專案。

截至查核 commit 827cd49，repository 的 package version 已是 1.4.148-rc.1，研究當日最新穩定版則是 v1.4.148。頻繁的 release 與大量 provider integration 代表功能演進很快，也代表更新可能影響 agent 啟動參數、帳號處理、遠端 protocol 或 UI；正式工作環境不宜只追 latest 而不做驗證。

平行執行的隱性成本

「同時跑五個 agent」不等於工作會直接快五倍，實際成本至少包含：

  • 每個 worktree 都有一份 checkout，會增加磁碟使用量；未追蹤的大型 build output 不會像 Git object 一樣共享。
  • 多個 agent、dev server、browser 與 build 同時執行，會消耗 CPU、RAM 和 I/O。
  • 同題競賽會重複消耗 token、subscription quota 與 API 費用。
  • 產出越多，人工比較 diff、執行測試與確認語意的時間越長。
  • 多個正確的局部修改合併後，仍可能造成全域設計不一致。
  • 快速切換十個 session 容易把「有很多工作在跑」誤認為「正在交付最重要的工作」。

Orca 真正能降低的是環境切換與檔案互踩的成本，不能消除 task decomposition、技術決策與驗收成本。

適合誰使用？

Orca 比較適合：

  • 已經習慣使用 CLI coding agent，經常同時處理多個 branch。
  • 想比較 Claude Code、Codex 等不同 agent 的同題結果。
  • 需要長時間在遠端主機執行 build 或 agent session。
  • 希望把 terminal、preview、diff、issue 與 PR 集中管理。
  • 願意管理權限、用量與最終 code review。

如果只偶爾讓單一 agent 修改小型專案，原本的 terminal 加上 Git branch 可能已經足夠。若團隊需要嚴格的 sandbox、細緻 RBAC、集中 audit 或多人 production governance，也不應只靠 worktree isolation；Remote Orca Server 目前仍標示 beta，必須另行設計基礎設施與安全邊界。

安裝方式

桌面版可從 Orca 官網 或 GitHub Releases 下載。macOS 也提供 Homebrew cask：

brew install --cask stablyai/orca/orca

安裝 Orca 之後，還是要在實際執行的主機安裝並登入想使用的 agent CLI。第一次測試建議先選非敏感 repository、把 permissions 改成 Manual，只開一個 worktree 熟悉 create、diff、ship 與 delete 流程，再逐步增加平行 session。

專案成熟度與我的看法

Orca 採 MIT License，可自由使用、修改與商業利用，但散佈時需要保留授權聲明。

截至 2026 年 7 月 21 日，GitHub 顯示專案已有約 2.4 萬顆 stars，release 與 commit 更新相當頻繁；但 repository 建立於 2026 年 3 月，仍是歷史不到半年的年輕專案。這代表關注度與開發活動很高，stars 卻不是穩定性或安全審查的保證。桌面核心流程看起來已相當完整，mobile 與 remote server 等部分功能則仍由官方標示為 beta。

我認為 Orca 最有價值的設計，不是讓畫面同時塞進更多 agent，而是把「一個任務、一個工作目錄、一個 diff」變成明確單位。當平行工作的數量增加，這種結構比共用 checkout 安全、也更容易丟棄失敗方案。

但它的效率來自把 agent 的阻力降得很低，權限風險也恰好來自同一件事。若能先建立真正的執行環境隔離、調整預設 permission，並保留人的 review 與決策，Orca 會是一個很有意思的 agent orchestration layer；如果把 disposable worktree 誤認為安全 sandbox，就可能在享受到平行效率之前，先把風險一起放大。

參考資料