Orca：用 Git worktree 把平行 coding agents 變成可比較的開發流程

當 coding agent 從「一次只改一個工作目錄」進入同時執行多個任務的階段，真正困難的往往不是再接一個模型，而是管理並行工作的邊界：每個 agent 要在哪裡修改？如何避免互相覆蓋？結果要怎麼比較？完成後又如何合併回主線？

Orca 是一個以開發工作台為核心的開源 AI orchestrator。它把 Codex、Claude Code、OpenCode 或 Pi 等 CLI agent 放在同一個介面中，讓每個 agent 使用獨立的 Git worktree，再透過桌面、終端機、瀏覽器與行動端功能集中追蹤。這個設計的重點不是替開發者選模型，而是把「多個 agent 同時工作」變成一個可觀察、可比較、可收斂的工程流程。

本文根據 Orca 官方 README、repository metadata 與官方文件，拆解它如何處理平行 worktree、終端機、瀏覽器操作、遠端 SSH、差異審查與 CLI 自動化，也說明哪些能力適合導入既有團隊，哪些地方仍需要保留人工判斷。

先看清楚 Orca 解決的是哪一層問題

Orca 不是新的 LLM，也不是只包裝單一 coding agent 的聊天介面。它處理的是 agent runtime 之上的協作層：

工作隔離：每個 agent 在自己的 Git worktree 中執行，降低平行修改同一份檔案的衝突風險。
工作可見性：多個 agent 的終端機、狀態與結果集中在一個工作區，不必在多個視窗之間來回切換。
結果比較：同一個 prompt 可以分派給多個 agent，分別產生方案，再由開發者比較差異並選擇要合併的結果。
後續操作：除了文字輸入，也能從差異檔案加註、傳回 agent，或在瀏覽器介面中把元素資訊送進 prompt。
遠端執行：透過 SSH worktree 把 agent 放到較強的遠端機器上，仍保留檔案、Git 與終端機工作流。

因此，Orca 的價值比較接近「多 agent 開發控制面板」，而不是另一個模型入口。導入時應該先問團隊是否有平行探索、長時間執行、跨環境協作的需求，而不是只看它能否啟動某個特定模型。

核心設計：一個 prompt，五個隔離 worktree

Git worktree 是 Orca 工作模型的地基。官方 README 的示例是把一個 prompt 分派給最多五個 agent，每個 agent 使用獨立 worktree；開發者可以同時觀察結果，最後選擇要合併的版本。

這個流程和傳統「開一個分支、叫 agent 修改、等待結果」不同。它把探索階段拆成幾個互不干擾的候選解：

先從同一個 repository 建立多個 worktree。
將相同或略有差異的任務交給不同 agent。
讓每個 agent 在自己的目錄中讀取、修改與測試。
從集中介面檢查每個 agent 的輸出與 Git diff。
選擇一個方向，將它合併回主要分支，或淘汰其他 worktree。

隔離並不等於自動正確。測試仍可能漏掉需求，兩個方案也可能都不符合產品限制；但 worktree 將「同時探索」與「最後整合」分成明確階段，使審查者可以在合併前保留決策權。

為什麼 worktree 比複製多份 repository 更適合

複製多份 repository 也能讓 agent 平行工作，但會帶來額外的同步成本：分支關係不明、修改差異難以追蹤、最後合併容易變成手動搬檔。Git worktree 讓多個工作目錄共享同一個 Git repository 的物件資料，同時保留各自的工作樹與分支語意。

Orca 沒有因此消除 Git 的複雜度，卻把常見的建立、切換與觀察操作放到同一個工作台。這對需要同時比較重構方案、測試修復方案或 UI 實作方向的工作特別實用。

終端機不只是附屬視窗

Orca 的另一個重要組成是終端機工作區。官方 README 列出 WebGL rendering、無限分割，以及重新啟動後仍能保留 scrollback 等能力。對 coding agent 而言，終端機不是單純的輸入框，而是執行指令、查看測試、追蹤長任務與檢查環境狀態的主要介面。

集中終端機有三個工程上的好處：

降低上下文切換：agent 的工作目錄、終端輸出與 Git diff 可以放在相同的工作區中查看。
保留執行證據：長時間測試或建置的輸出不必依賴聊天訊息轉述，開發者可以直接回看 terminal scrollback。
支援人工接管：當 agent 卡在權限、依賴或測試失敗時，開發者可以直接進入相同環境處理，不必重建工作目錄。

這也提醒我們，好的 agent 介面不應只呈現「完成」或「失敗」兩種狀態。對實際開發而言，命令、輸出、變更與環境狀態都屬於可審查的工作上下文。

從瀏覽器取得更精準的 UI 上下文

在前端開發中，單靠自然語言描述「把這個按鈕往右移」通常不夠。Orca 的 Design Mode 讓使用者在真實 Chromium 視窗中點選 UI 元素，把該元素的 HTML、CSS 與裁切畫面直接送進 agent prompt。

這個功能的重點不是讓 agent 自動操控所有瀏覽器，而是縮短「人看到的畫面」與「agent 收到的上下文」之間的距離。它可以用在：

指定某個元件的實際 DOM 結構。
讓 agent 知道目前套用的 CSS 與版面層級。
以局部 screenshot 補充文字描述無法表達的視覺問題。
讓修正任務從「猜是哪個元素」變成「對這個元素提出變更」。

不過，HTML、CSS 與 screenshot 仍然是輸入資料，不是產品需求本身。設計規範、無障礙要求、瀏覽器相容性與測試結果仍需由團隊驗證。

GitHub、Linear 與 diff review 被放回同一個流程

Orca README 也列出 GitHub 與 Linear 的原生工作流：可以在應用程式內瀏覽 PR、issue 與 project board，從任務開啟 worktree，並在不離開工作區的情況下進行 review。

對團隊來說，這種整合的價值不只是少開幾個分頁，而是讓任務識別與程式碼修改有更清楚的對應關係：

Issue / Project task
        ↓
建立隔離 worktree
        ↓
分派一個或多個 coding agent
        ↓
查看測試、終端輸出與 diff
        ↓
加註、修正、重新執行
        ↓
人工審查後合併

其中「人工審查後合併」仍是必要節點。Orca 可以協助收集候選結果，不能替團隊決定需求是否完成、變更是否安全，或某個 diff 是否符合架構規範。

Remote SSH：把 agent 放到真正適合它的機器

本機環境不一定適合長時間或高資源的 agent 工作。Orca 的 SSH worktree 功能，讓 agent 可以在遠端機器上使用完整檔案編輯、Git 與終端機能力，並提供自動重新連線與 port forwarding。

這類設計適合以下情境：

本機是筆電，但建置或測試需要較多 CPU、RAM 或 GPU。
團隊有共用的 development box 或隔離執行環境。
需要讓多個 agent 在遠端分支上長時間執行任務。
服務只在遠端網路或內部環境可存取。

遠端執行同時提高了治理要求。SSH key、repository 權限、port forwarding、agent 可執行的命令範圍，以及工作完成後的清理策略，都應由團隊明確定義。便利的連線不等於可以省略隔離與審計。

Annotate AI Diffs：把 review 意見送回工作迴圈

Orca 支援在 diff 的行上加入註解，再把意見傳回 agent，讓 review 不必停留在「人看完之後另外寫一段 prompt」。這個設計將修改循環具體化：

agent 先產生變更。
開發者在 diff 上指出問題或補充限制。
agent 只針對這些上下文繼續修改。
重新執行測試並再次檢查 diff。

對大型變更來說，行級註解比一段籠統的「請再改善」更容易定位。不過，註解仍應描述可驗證的問題，例如行為、介面、測試或安全邊界，而不是只給主觀評語。

CLI 讓 Orca 不只服務互動操作

除了桌面介面，Orca 也提供 CLI，可以用 orca worktree create、snapshot、click 與 fill 等命令腳本化工作流程。這讓 Orca 可以被放進更自動化的開發流程中，例如：

為固定類型的 issue 建立標準化 worktree。
在 agent 執行前保存 snapshot，方便回溯。
以腳本操作介面，重現一組固定的人工流程。
在 CI 或內部工具中串接工作狀態，而不完全依賴滑鼠操作。

但「可腳本化」應該搭配明確的權限邊界。任何會修改 repository、執行部署、存取內部服務或傳送外部請求的流程，都應先設計 dry-run、審批與回滾機制。

如何在團隊中導入 Orca

建議不要一開始就把所有 coding agent 與所有 repository 都搬進去，可以採用三階段：

第一階段：只做隔離與觀察

選一個不涉及生產部署的 repository，讓兩個 agent 分別處理同一個小型任務。比較它們的 diff、測試輸出與人工審查時間，先確認 worktree 是否符合團隊現有 Git 流程。

第二階段：加入 review 迴圈

把需求拆成「agent 產生初稿、開發者逐行註解、agent 修正、測試驗證」的循環。這一階段應記錄哪些問題能透過精準上下文解決，哪些問題仍需要架構師或產品負責人決策。

第三階段：再接遠端與自動化

當隔離、審查與清理流程穩定後，再評估 SSH worktree、CLI 與任務系統整合。將可自動化的部分寫成腳本，並保留高風險操作的人工核准點。

限制與風險

Orca 的 README 展示了完整的 agent 工作台，但導入時仍有幾個限制需要實際驗證：

agent 品質不會因介面集中而自動提升：平行執行可能只是更快產生更多不正確的候選。
Git merge 仍然存在：worktree 降低互相覆蓋，並不保證不同方案可以無衝突合併。
資源成本會放大：五個 agent 同時執行，可能同時消耗模型額度、CPU、網路與建置資源。
遠端權限需要治理：SSH 與 port forwarding 讓能力更強，也讓錯誤設定的影響範圍更大。
產品功能變動快速：官方 README 明確表示功能持續更新，因此正式導入前應以當前 release 與官方文件再次確認行為。

這些限制不是 Orca 特有的缺陷，而是所有多 agent 開發系統都必須面對的工程問題。比較健康的評估方式，是以完成一項任務所需的總成本、審查時間、可回溯性與失敗恢復能力來衡量，而不是只計算 agent 產生程式碼的速度。

結語：把平行 agent 變成工程流程，而不是更多聊天視窗

Orca 最值得注意的地方，是它把 coding agent 的平行執行放回 Git、終端機、瀏覽器與 review 這些熟悉的工程概念中。Git worktree 提供隔離，集中工作區提供可見性，diff annotation 提供回饋迴圈，SSH 與 CLI 則讓流程延伸到遠端與自動化環境。

如果團隊目前最大的痛點是「agent 太多、結果難比、工作目錄難管」，Orca 值得用一個低風險任務做實驗。若問題其實是需求不清、測試不足或權限治理薄弱，那麼先補齊工程流程，通常比再增加一個 agent 介面更重要。

本文資料來源：

- GitHub repository：stablyai/orca

- Orca 官方網站：onorca.dev

- GitHub API repository metadata（星數、授權、最近更新時間）：截至 2026-09-19 查詢

本文未使用 repository README 中的圖片作為文章封面；封面僅保留可供後續產圖使用的英文 Prompt。