當工程師開始在終端機裡同時叫用兩、三個甚至十個 Coding Agent 時，最先崩潰的通常不是模型的 Context Window，而是本機檔案系統的 Working Directory。

在傳統的 IDE 工作流中，編輯器本質上是為「一個肉眼、雙手」的單一操作者設計的。當我們把同一個專案資料夾同時丟給 Claude Code、Codex CLI 與 Cursor，災難會以極快的速度發生：Agent A 正在修改使用者驗證模組並執行測試，Agent B 同時依據另一個 Prompt 進行資料庫 Migration，兩者立刻在同一份未 Commit 的暫存檔案上打架、編譯鎖檔互咬、Hot Reload 機制陷入死循環，終端裡的輸出記錄與記憶上下文徹底被污染。

2026 年初由 Stably AI 開源、截至 9 月在 GitHub 已累積超過 7.4 萬顆星的 Orca，標榜自己不是 IDE，而是 ADE（Agent Development Environment，智慧代理開發環境）。它提出的核心主張是：當軟體開發的生產主力轉向平行運行的 Agent 艦隊時，開發環境的首要任務不再是語法高亮或自動補齊，而是多 Agent 的隔離編排、資源調度與結果裁決。

社群近期的採用討論揭示了這個轉向的本質。本文從 Orca 的架構實踐出發，拆解 ADE 如何透過 Git Worktree 實現真正的平行隔離，以及工程團隊該如何建立多 Agent 協作的控制平面。

Orca ADE 與 Git Worktree 多 Agent 隔離控制平面 中央任務分發器將 Prompt 平行派發至三個獨立 Git Worktree，分別執行 Claude Code、Codex 與 Cursor CLI，最終匯整至單一 Diff 審查與合流閘門。GIT REPOSITORY單一 .git 核心共用 Commit 歷史worktree add獨立檢出無鎖衝突WORKTREE 1 · BRANCH-AUTH-CLAUDEClaude Code (Refactor)獨立目錄 · 獨立 Process · 私有 ContextWORKTREE 2 · BRANCH-AUTH-CODEXCodex (Best-of-N)獨立目錄 · 獨立 Process · 私有 ContextWORKTREE 3 · BRANCH-AUTH-CURSORCursor CLI (Alternative)獨立目錄 · 獨立 Process · 私有 ContextORCA CONTROL PLANEDiff 比較與合流閘門比對測試綠燈與變更半徑擇優 Merge，其餘 Prune 銷毀
GIT REPOSITORY單一 .git 核心

所有分支與歷史共用，避免完整 clone 的磁碟與時間開銷。

↓ 分派獨立工作樹（git worktree add）
WORKTREE 1Claude Code：實作與重構

獨立檔案目錄，終端歷史與暫存區互不污染。

WORKTREE 2Codex：平行競爭實作

獨立 Process，由本地直接呼叫模型 API（Zero-Proxy）。

WORKTREE 3Cursor CLI：替代方案實作

探索不同架構分支，不影響本機 main branch。

↓ 匯流至 Orca 控制台
ORCA CONTROL PLANEDiff 審查與合流閘門

以測試通過率與 Code Review 決定最佳解，一鍵 Merge 並自動清理其餘 Worktree。

圖 1：Orca ADE 核心架構。透過 Git Worktree 提供實體檔案與 Process 隔離，再由單一控制台完成多 Agent 並排評估與整併。

為什麼檔案隔離必須落到 Git Worktree？

許多人在嘗試讓多 Agent 平行作業時，第一個直覺往往是開多個終端分頁（如 tmux 或 Ghostty 分割視窗），或寫一段腳本呼叫 sub-agent。但只要所有 Agent 指向同一個磁碟路徑，就無法逃避三個硬性物理衝突：

  1. 檔案寫入踩踏（Write-Write Hazards）：兩個 Agent 同時修改同一檔案的不同行，若無交易鎖機制，後寫入者會靜默覆蓋前者的修改，導致測試結果無法歸因。
  2. 開發環境鎖檔與 Process 衝突：多數現代構建工具（如 Vite、Next.js、Cargo 或 Go compiler）會在 node_modules/.cache 或 target/ 產生 lock file，或預設綁定固定 Port（如 3000）。兩個 Agent 同時下達 pnpm test 或啟動 dev server 會直接引發 EADDRINUSE 或檔案被佔用的錯誤。
  3. 未提交狀態的 Context 污染：Coding Agent 通常會藉由 git status 與 git diff 觀察自己剛才的修改。若環境中有另一個 Agent 的半成品，兩者的推理鏈會互相解讀對方的垃圾代碼，導致自我除錯迴圈徹底發散。

有人試圖用「複製整個 Repository 目錄」來解決，但對於動輒數 GB、含大量 submodule 與歷史紀錄的龐大 monorepo 而言，複製目錄的時間與硬碟開銷巨大，後續將分支合併回主線時更是痛苦不堪。

Orca 選擇的解法是 Git Worktree。

Git Worktree 允許同一個 .git 核心歷史資料庫掛載多個獨立的 Working Tree。每個 Worktree 都是一個真實的獨立目錄，並且檢出（checkout）到不同的分支。

# 傳統目錄複製：慢、佔硬碟、.git 歷史脫鉤
cp -R my-project my-project-agent-2  # 昂貴且危險

# Git Worktree：秒級建立、共用 commit history、實體目錄隔離
git worktree add -b feat/passkey-auth .orca/worktrees/agent-claude origin/main
git worktree add -b feat/oauth-refresh .orca/worktrees/agent-codex origin/main

在 Orca 的生命週期管理中，每次使用者發派任務，Orca 就會透過低階 Git 指令派生一個暫存 Worktree。各 Agent 在獨立的目錄中跑 CLI、改 Code、跑測試。任務完成後，開發者在中央控制台檢視產出的 Diff；擇優 Merge 後，其餘 Worktree 會被自動清除（git worktree remove）。

我的工程判斷是：多 Agent 協作的最小可行隔離單位是檔案系統目錄，而非終端分頁；而 Git Worktree 是在成本與版本歷史連貫性之間唯一合適的原生支點。

Zero-Proxy 架構：為什麼開發者拒絕中間伺服器？

在 Orca 快速擴散的社群回饋中，另一個引發廣泛共鳴的架構決策是 Zero-Proxy（自帶金鑰與本機直連）。

許多宣稱支援多 Agent 的雲端 SaaS 平台，運作方式是要求使用者將 GitHub 授權給雲端後端，所有 Prompt 與程式碼會經過該平台的伺服器，再由平台代為呼叫 LLM API。這種架構在企業與資深工程師眼中存在巨大阻力：

  • 資安與合規風險：專有業務邏輯與未公開程式碼被轉發到第三方未知服務器，違反多數企業的安全政策。
  • 訂閱與額度浪費：開發者已經購買了 Claude Pro/Max、OpenAI 訂閱或企業專屬的 API Key，不願意為轉發平台再付一層溢價或中介訂閱費。
  • 網路延遲與中斷單點：中間代理層一旦掛掉，整個團隊的本機開發工作流立即停擺。

Orca 的架構則純粹在本地（或使用者自行掌控的遠端 VPS）執行。它原生支援 20 多種現成的 Agent CLI（包含 Claude Code、Codex、Cursor CLI、Devin CLI、Grok、OpenCode 等）。當你在 Orca 裡呼叫 Agent 時，本質上是 Orca 的 Process Supervisor 在對應的 Worktree 目錄下啟動本機 CLI 二進位檔。

API 憑證完全保留在開發者本地系統的環境變數或 Keyring 中，呼叫直接發往 Anthropic、OpenAI 等模型端點。這種「只做 Scaffolding 與控制面，不碰模型資料流」的設計，是它能在重視隱私的開源社群迅速取得信任的關鍵。

三種平行模式：從競爭採納到專業分工

把多個 Agent 丟進各自的 Worktree 後，下一步是如何組織工作。在社群實踐中，主要收斂出三種運作模式：

模式一：Best-of-N 錦標賽競爭（Tournament）

在重構複雜模組或解決隱晦 Bug 時，單一 Agent 很容易陷入某個錯誤的實作假設。過去工程師只能看著它越陷越深，再手動 git reset --hard。

在 Orca 中，你可以對同一個問題發起平行競爭：

  • Worktree A：由 Claude Code 實作，側重架構重組與型別約束。
  • Worktree B：由 Codex 實作，側重最少行數變更與回歸測試覆蓋。
  • Worktree C：由 Cursor CLI 實作另一種設計模式。
# 概念化操作：同一個 Prompt 平行分派多個 Harness
orca run \
  --prompt "Refactor PaymentProcessor to use Strategy Pattern and pass all tests" \
  --harness claude-code:branch-strategy-claude \
  --harness codex:branch-strategy-codex

開發者在中央控制台並排比較兩者的 Git Diff、測試通過狀態與 Token 消耗量。選出最優解後一鍵 Merge，淘汰的分支直接刪除。這把過去耗時的序列嘗試，壓縮成一次性的平行對決。

模式二：流水線分工（Divide & Conquer）

當需求明確但橫跨多個子系統時，流水線模式能大幅縮短交付週期：

  • Agent 1 專注於依據 OpenAPI Spec 產出後端路由與 Controller；
  • Agent 2 在另一棵 Worktree 撰寫對應的整合測試與 Mock 資料；
  • Agent 3 專注於前端 UI 元件更新。

因為 Worktree 各自獨立，Agent 2 在寫測試時不會被 Agent 1 尚未編譯成功的半成品擋住；兩者各自 Commit 後，再透過正常的 Pull Request 機制進行整合。

模式三：Headless 遠端持久執行

本機筆電有睡眠、斷線與硬體資源上限。Orca 支援 orca serve 模式，將 ADE runtime 部署於大算力伺服器或 VPS 上。開發者在本地桌面 GUI 或行動端 Companion App 連線至 Remote Server，即使本地網路斷線，遠端的多個 Agent 依然在各自的 Worktree 中持續執行長達數十分鐘的測試套件與編譯流程。

整合落地的四個工程限制與防禦措施

引進 ADE 不等於開發效能自然翻倍。多 Agent 平行編排如果不設防，會以驚人的速度消耗你的硬碟、記憶體與注意力。在正式引入現有專案前，必須建立四項防禦措施：

潛在陷阱失敗表徵工程防禦規則
磁碟容量耗盡10 個 Worktree 各自安裝 node_modules，硬碟被瞬間塞滿數十 GB強制使用 pnpm 或符號連結共用 store；配置定時 orca prune 清理已完成的 Worktree
Port 衝突多個 Agent 同時啟動 Dev Server，造成 Port 3000 互搶在環境變數中動態注入偏移量：PORT=3000 + $WORKTREE_INDEX
90/10 決策失控Agent 自行做主更動了 Production 資料庫 Schema 或破壞 Public API設定 Approval Gate：低風險變更允許自動 Commit，高風險檔案修改必須跳出確認中斷
審查注意力瓶頸同時產出 5 個 PR，人類 Reviewer 成為全隊最嚴重的延遲節點導入嚴格的自動化驗收指標：未附帶新增測試或覆蓋率下降的變更，直接拒絕審查

給工程團隊的導入建議

不要一開始就試圖用 ADE 管理十個 Agent。建議依循以下循序漸進的導入路徑：

  1. 第一步：建立 Worktree 邊界與 Ignore 規則。在 .gitignore 中加入 .orca/worktrees/，並確認專案的依賴管理工具（如 pnpm）具備全域快取能力，避免派生工作樹時重複下載。
  2. 第二步：只嘗試「雙 Agent 競爭驗證」。針對近期一個架構不確定性較高的 Issue，同時派發給兩個不同特性的 Agent（例如一個強調最少修改、一個嘗試結構重組），透過控制台實際體驗 Diff 比對與採納流程。
  3. 第三步：固化審核閘門。將專案的 npm test 或 pytest 指令設定為 Orca 的驗收前置條件。未通過本地測試的分支，不進入人類視線。

當開發工具的本質從「文字編輯器」演進為「智慧代理編排器」，開發者的核心競爭力也正從親自打字，轉向如何精準定義任務契約、建構安全的隔離沙盒，以及設定高效的驗收決策。

延伸閱讀