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

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

1
2
3
4


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

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

比較時只看四個問題：

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

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

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

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

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

1
2
3
4


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 合併：

1
2
3
4


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

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

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

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

1
2
3
4
5
6
7


[ ] 兩個方案是否都基於同一基線分支？
[ ] 是否都列出了修改文件和運行過的測試？
[ ] 是否有一個方案引入了無關依賴或大範圍格式化？
[ ] 是否存在同一文件的競爭修改？
[ ] 主方案能否獨立通過測試？
[ ] 次方案中是否有可單獨挑選的測試、註釋或修復？
[ ] 是否已在桌面端審查完整 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 並行而放大代碼風險。