Orca on KnightLi的博客

Orca 怎麼並行運行 Codex 和 Claude Code：Worktree、任務比較與手機審批

Wed, 15 Jul 2026 22:05:00 +0800

同一個 bug 或功能，交給 Codex 和 Claude Code 各做一遍，常常比讓一個 Agent 無限重試更快發現盲點。但真正難的是控制過程：兩份改動不能互相覆蓋，結果要能比較，人在離開電腦時也要能知道任務何時完成、該不該繼續。Orca 把多個終端 Agent 放在獨立 Git worktree 中運行，並在同一處追蹤會話、diff 和任務狀態。Orca 官方倉庫

本文把重點放在“比較後再審批”：並行運行不是自動合併；手機端也不是替代代碼審查，而是讓你及時查看進度、發送追問並決定哪些結果值得回到電腦前仔細審閱。

先建立正確邊界：並行執行，不等於自動採納

Orca 可以將 Codex、Claude Code 以及其他終端 Agent 並排運行，每個 Agent 使用自己的 Git worktree。官方 README 的工作方式是把同一提示分給多個 Agent，在隔離工作樹中完成後比較結果，再合併勝出的方案。

因此整個流程應分成三層：

階段	由誰完成	產物
執行	Codex / Claude Code	獨立分支、diff、測試輸出、說明
比較	Orca + 人工審閱	方案差異、風險點、候選結論
審批與合併	人工	被採納的提交、必要的補充修改

不要把“兩個 Agent 都說完成”當成審批通過。尤其是權限、數據庫遷移、依賴升級和刪除文件，必須在合併前審查實際 diff。

任務怎麼拆，比較纔有意義

如果兩個 Agent 收到完全模糊的“修復登錄問題”，最終往往得到了兩份無法橫向比較的大改動。應給每個任務統一驗收基線，再讓策略不同：

共同條件：復現登錄 token 過期後的重試失敗；必須通過現有登錄測試；不改 API 協議。

Codex：從請求重試鏈路定位根因，提交最小修復，並說明爲何不會影響刷新邏輯。
Claude Code：先寫失敗復現與迴歸測試，再提出最小修復；不改無關認證模塊。

比較時只看四個問題：

哪個方案真正復現並覆蓋了問題？
哪個 diff 更小、邊界更清楚？
哪個測試命令實際運行過，輸出是否可重現？
哪個方案引入的依賴、權限或迴歸風險更低？

這樣 Codex 和 Claude Code 的差異成爲可衡量的工程選擇，而不是比較誰寫的說明更有說服力。

Worktree 讓兩份候選改動不互相污染

Git worktree 讓同一倉庫的不同分支擁有不同工作目錄。Orca 在每個隔離工作樹中運行 Agent，因此 A 的格式化、依賴安裝或文件刪除不會直接改到 B 的目錄，也不會直接污染你的主目錄。

開始前仍建議把主工作區整理乾淨：

git status
git fetch --all --prune
git switch main
git pull --ff-only

再爲候選方案使用可讀的分支名：

1
2
3

agent/login-fix-codex
agent/login-fix-claude
agent/login-tests

隔離並不能消除合併衝突：如果兩個方案最終都修改同一個認證文件，合併仍需選擇一個主方案，或從另一個方案挑選獨立測試提交。不要把多個候選分支一次性 merge 到 main。

在 Orca 中啓動兩個 Agent 的實用順序

具體按鈕隨版本變化，但下面的順序不會變：

在 Orca 中打開 Git 倉庫，確認基線分支和當前未提交改動。
爲 Codex 與 Claude Code 分別創建/選擇獨立 worktree。
複製共同驗收條件，再寫出各自不同的子任務與禁止範圍。
要求 Agent 在結束時列出修改文件、執行的測試、未驗證假設和建議的提交說明。
完成後先讀 diff 和測試輸出，再決定是否讓其中一個繼續修正。

Orca 還支持從 GitHub、Linear 的任務打開 worktree，以及在 diff 行上留下評論回傳給 Agent。把評論寫成可執行反饋，例如“只保留測試，撤回依賴升級”或“解釋此處緩存失效順序”，比籠統說“再改好一點”有效。

如何在手機上做“審批”

Orca 的 Mobile Companion 用於在手機上監控和引導 Agent：完成時接收通知，並可從任意位置發送 follow-up。它支持 iOS 和 Android 配套應用，需與桌面端配對。

這裏的“手機審批”應該理解爲任務級決策，不是在手機上盲目完成 Git 合併：

通知到達
  → 查看 Agent 的完成摘要、測試狀態和風險提示
  → 決定：追問 / 讓它補測試 / 停止另一個候選 / 標記爲待電腦審閱
  → 回到桌面端查看完整 diff、運行關鍵測試、再合併

適合在手機上做的操作包括：讓 Agent 解釋失敗測試、要求縮小改動範圍、補一個迴歸用例、或停止明顯偏題的任務。不適合只憑通知摘要批准數據庫遷移、生產配置、權限修改或大範圍重構。

一份可複用的比較與審批清單

當兩個 Agent 都完成時，按此順序處理：

[ ] 兩個方案是否都基於同一基線分支？
[ ] 是否都列出了修改文件和運行過的測試？
[ ] 是否有一個方案引入了無關依賴或大範圍格式化？
[ ] 是否存在同一文件的競爭修改？
[ ] 主方案能否獨立通過測試？
[ ] 次方案中是否有可單獨挑選的測試、註釋或修復？
[ ] 是否已在桌面端審查完整 diff，再執行 merge？

合併前可以在主工作樹比較候選：

1
2
3

git diff main...agent/login-fix-codex
git diff main...agent/login-fix-claude
git log --oneline main..agent/login-fix-codex

確認後只合並被採納的分支，或用 git cherry-pick 選擇單獨提交。保留未採納 worktree 到驗證結束，再清理，方便在迴歸時找回另一份思路。

常見問題

Codex 和 Claude Code 可以同時修改同一個文件嗎？

可以，因爲它們在不同 worktree。但這只是避免運行時互相覆蓋，不會自動解決合併時的邏輯衝突。最好指定一個主實現 Agent，另一個負責測試、審閱或備選方案。

手機上看到“完成”就能合併嗎？

不應如此。手機適合接收通知和發送追問；完整 diff、實際測試、敏感配置和合並決策仍應在可信的桌面環境完成。

爲什麼兩個 Agent 的結果都不滿意？

通常是任務邊界或驗收條件不夠具體。先讓其中一個 Agent 只做代碼閱讀，列出根因假設與最小影響文件；確認方向後再啓動並行實現，成本會更低。

小結

Orca 讓 Codex 和 Claude Code 在隔離 worktree 中並行執行，真正的收益來自隨後可比較的 diff、測試和風險說明。手機伴侶應用適合把“收到通知—追問—決定下一步”提前完成，但不替代人工的完整審查與 Git 合併。把執行、比較、審批分開，纔不會因爲多 Agent 並行而放大代碼風險。

Orca 並行 Agent 工作流教程：用 Git Worktree 同時運行 Codex 和 Claude Code

Wed, 15 Jul 2026 21:58:00 +0800

多個 Agent 同時改一個倉庫，最怕的不是速度不夠，而是它們相互覆蓋文件、污染未提交改動，最後很難判斷哪一份結果可合併。Orca 的做法是爲每個 Agent 分配獨立的 Git worktree：同一個倉庫可以並行運行 Codex、Claude Code 或其他終端 Agent，完成後再比較 diff、選擇併合並結果。Orca 官方倉庫

它不是另一個模型，也不會替代 Codex 或 Claude Code；更準確地說，它是給多個 CLI Agent 加上一層工作區、任務和結果管理界面。適合需要並行探索方案、但又希望保留 Git 隔離邊界的開發者。

Orca 適合什麼任務

Orca 最適合“目標相同、實現路徑可比較”的任務，例如：

讓兩個 Agent 分別實現同一個接口，再比較測試、可讀性和改動範圍。
一邊排查 bug，另一邊補測試或閱讀相關模塊。
同時嘗試保守修復與重構方案，最後只合並其中一個。
把前端、後端、文檔拆成互不重疊的子任務並行推進。

不適合直接拆開的情況也很常見：多個 Agent 同時改同一個核心文件、需要共享未提交狀態的調試過程，或需求本身還沒有明確。這時先用一個 Agent 梳理計劃，通常比並行啓動五個窗口更省時間。

工作原理：每個 Agent 一棵獨立工作樹

Git worktree 允許一個倉庫同時檢出多個分支到不同目錄。Orca 在此基礎上爲 Agent 創建和管理這些獨立目錄：每個 Agent 都有自己的文件改動、終端會話和分支上下文，不會直接覆蓋主工作目錄。

官方 README 描述的典型流程是：把同一個提示分發給多個 Agent，每個 Agent 在隔離 worktree 中完成任務，然後比較結果併合並勝出的實現。Parallel Worktrees 說明

可以把關係理解爲：

層級	負責什麼
Codex / Claude Code	理解任務、修改代碼、執行測試
Git worktree	隔離每個方案的文件和分支改動
Orca	創建工作樹、啓動 Agent、集中查看會話與 diff
你	拆分任務、審查結果、決定合併哪個方案

開始前的倉庫準備

並行之前先把主目錄收拾乾淨。worktree 能隔離新分支的文件改動，卻不能替你判斷主目錄裏哪些未提交變更應該保留。

git status
git fetch --all --prune
git switch main
git pull --ff-only

如果 git status 不是乾淨狀態，先提交、暫存或明確保留當前改動。隨後爲不同方案建立清晰的分支命名，例如：

1
2
3

agent/fix-login-codex
agent/fix-login-claude
agent/add-login-tests

Orca 支持 Windows、macOS 和 Linux 桌面端；安裝包和當前版本以官方發佈頁爲準。它可以運行任何能在終端執行的 Agent，因此還要確認本機已經完成 Codex、Claude Code 或你計劃使用的 CLI 的登錄和基礎配置。

一個可複用的並行拆分方式

以“登錄偶發失敗”爲例，不要給三個 Agent 都發送“修復登錄 bug”。更好的拆分是把交付物寫清楚：

1
2
3

Agent A：定位請求重試與 token 刷新路徑；只提交最小修復，並補充復現步驟。
Agent B：不改業務邏輯；爲登錄失敗、過期 token、網絡超時補自動化測試。
Agent C：審查最近登錄相關改動，給出根因假設、風險文件和建議，不直接修改代碼。

這樣三條工作樹的輸出可以直接比較：A 提供候選修復，B 提供迴歸保護，C 提供獨立審查。即使最終只採用 A 的修改，B 和 C 的結果仍能幫助驗證方向。

對於同一個功能的多方案競賽，也應限制範圍：要求每個 Agent 只改指定模塊、運行相同測試命令、在最終說明中列出修改文件和未解決問題。沒有共同的驗收標準，多個 Agent 的“完成”很難橫向比較。

在 Orca 中啓動並行 worktree

具體界面會隨版本變化，但操作順序通常如下：

打開一個已初始化 Git 的倉庫，確認基線分支和主目錄沒有意外改動。
爲每個子任務創建獨立 worktree 或讓 Orca 從任務創建工作樹。
分別選擇 Codex、Claude Code 等本機可用 Agent，給出不重疊的任務說明和驗收命令。
讓 Agent 在自己的 worktree 中執行；不要在主目錄同時手動修改同一批文件。
完成後查看每棵工作樹的 diff、測試輸出和提交記錄，再決定保留、修改或丟棄。

Orca 還提供終端分屏、diff 行內評論、文件拖放給 Agent，以及通過 CLI 管理工作樹的能力；例如其文檔列出了 orca worktree create、snapshot 等工作流命令。功能入口以當前版本文檔爲準。Orca CLI 介紹

如何合併結果，避免把三個方案混在一起

最安全的順序是先審查、後合併：

# 在主工作樹中查看某個候選分支
git diff main...agent/fix-login-codex
git log --oneline main..agent/fix-login-codex

# 確認測試和改動範圍後再合併
git switch main
git merge --no-ff agent/fix-login-codex

如果測試工作樹和修復工作樹都值得保留，先合併測試，再合併修復，或用 git cherry-pick 挑選單獨提交。不要因爲它們都由 Agent 生成，就直接把全部 worktree 一次性 merge；重複的依賴升級、格式化改動和同文件重構最容易在這裏引入衝突。

合併前至少檢查四項：

改動是否只覆蓋了任務範圍內的文件。
測試命令是否實際運行且結果可復現。
是否包含密鑰、生成文件、大型鎖文件或無關格式化。
兩個候選方案是否改了同一段業務邏輯；若是，保留一個作爲主方案，另一個只作爲參考。

常見問題

Orca 會替我購買或共享 Codex、Claude Code 的額度嗎？

不會。Orca 的定位是編排終端 Agent；你仍使用自己已有的 Agent 訂閱、賬號和本機登錄狀態。多開 Agent 也可能更快消耗對應產品的用量額度。

多個 Agent 可以修改同一個文件嗎？

可以，因爲它們位於不同 worktree；但後續合併會產生競爭。若同一個文件不可避免地要改，最好指定一個主實現 Agent，其他 Agent 只做審查、測試或提出補丁建議。

沒有 Git 倉庫能用嗎？

Orca 能運行終端 Agent，但並行 worktree 的隔離和可控合併依賴 Git。對重要項目，先初始化倉庫並建立可回滾的基線，再開始並行任務。

Orca 與直接開多個終端有什麼區別？

手動開多個終端也能並行，但你需要自己創建工作樹、記住分支、追蹤會話和對比結果。Orca 把這些步驟放到同一界面，重點是降低並行 Agent 的管理成本，而不是改變 Agent 本身的能力。

小結

Orca 的實用之處在於把“並行試錯”變成可審查的 Git 工作流：每個 Agent 在獨立 worktree 中工作，結果用 diff、測試和分支提交來比較。先把任務拆到互不干擾，再只合並經過審查的候選分支，才能讓 Codex、Claude Code 的並行能力真正服務於交付，而不是製造更多衝突。