Orca CLI 怎麼管理多個 AI agent？先看 worktree 與 review queue

Orca 主要管理哪三件事#

官方架構把 Orca 放在使用者與 coding agent 之間：

Pod 的概念是把一個較大的目標拆成有依賴關係的多個 run。上游完成後，下游才進入可執行狀態；這比單純開更多 terminal 多了一層順序控制，但 DAG 是否切得合理，仍是使用者要負責的設計。

這和既有的 Git worktree 多 agent 工作流 不同：那篇聚焦 Git 原生隔離與清理；Orca 則是在 worktree 之上增加 run state、pod 排程與 review 入口。兩者不能互相取代。

先熟悉 command surface，再照版本寫腳本#

README 列出的核心命令可以先按生命週期理解：

這張表是概念索引，不是固定的腳本 API。實際參數和旗標要以安裝版本的 orca --help、完整文件與 release 為準；不要把 active development 專案的 README 範例直接放進 production automation。

用單一 run 做第一輪試驗#

第一次試用時，把完成條件寫成可以由人檢查的順序：

1. 在乾淨的測試 repository 執行 git status --short，確認沒有未交接的工作。
2. 用 orca run 建立只修改一個小範圍的任務，禁止 agent 觸碰部署設定、production secrets 和無關目錄。
3. 用 orca watch 或 orca logs 觀察狀態，記錄 run id、branch、worktree 路徑和失敗時間。
4. run 進入 ready 後，用 orca review 和 orca diff 檢查實際變更，再獨立執行專案自己的 test、lint 或 build。
5. 只有在 diff、測試與檔案清單都通過 review 後，才考慮 orca ship；不需要交付的 run 先清理，不要留下孤兒 worktree。

如果第一次 run 就需要完整 repository、任意 shell、瀏覽器登入或 production API，代表測試範圍太大。先縮小任務，比遇到問題後才猜是哪一層造成外部副作用容易得多。

MCP 設定位置是另一個安全決策#

Orca 可以透過 orca mcp serve 提供 MCP server，但「agent 能驅動 Orca」和「Orca 能啟動某個 agent」是兩種不同的連線方向。官方 README 的設定示例把 Orca server 放進各 agent 的 MCP 設定；設定時先決定要全域使用，還是只對單一 repository 開放：

若要讓 Orca 讀取 repo-level AGENTS.md、skills、policies 或 templates，先 review 這些檔案是否含有會擴大權限的規則。設定檔是能力入口，不是安全證明；真正的 shell、檔案、網路與外部服務權限仍由 agent host 和作業系統決定。

worktree 之外要自己隔離的資源#

Orca 的 worktree 只解決 Git checkout 和檔案變更互相覆蓋的問題。多個 run 同時執行時，仍要為下面資源設計隔離：

• Secrets：.env、SSH agent、cloud credential 與 shell environment 可能在不同 worktree 共用。測試用 secret 要與 production 分開，且不要把它放入 run log。
• Port：兩個 agent 都啟動 localhost:3000 時，失敗可能被誤認成程式 bug。用 run-specific port 或由測試 runner 分配。
• 資料庫與 volume：Docker Compose project name、named volume、測試資料庫和 queue 可能仍指向同一份資料。先建立隔離的 namespace 或明確禁止寫入。
• 外部服務：瀏覽器 session、第三方 API、部署平台和通知頻道不會因為 Git branch 改變。將 agent 的外部寫入權限設成 default deny。

在這些邊界沒有定義前，不要把「每個 run 有自己的 worktree」寫成「多 agent 已經安全隔離」。

Active development 的採用條件#

Orca 目前的吸引力在於本機、agent-agnostic、worktree 和 review queue 的組合；但官方 repository 只有很早期的版本歷史，README 也說介面在 v1.0 前可能變動。採用前至少確認：

1. 是否能固定 binary 版本並保存 checksum。
2. ~/.orca/orca.db 的備份、權限與清理政策是否清楚。
3. run state 損壞或 worktree 遺失時，是否仍能用 Git 原生命令取回 diff。
4. pod 失敗、retry、kill 和 ship 是否都有人工 review gate。
5. 團隊的 agent config、MCP server 與 policy 是否能在 CI 或新工作站重建。

只要其中一項沒有答案，就先把 Orca 用在可丟棄的試驗 repo，不要直接接入重要 monorepo 或 production deploy pipeline。

常見問題#