實測狀態 本文記錄已觀察到的派單偏離現象，提出待驗證的改善策略；尚未提供 Orca Task／Dispatch／worker_done 的修正前後實測資料。請勿將方案視為已驗證成功。

我明明啟用了 Orca，為什麼 Codex 還是自己開 Subagent？

AI 多代理協作踩坑記：從派單失控，到建立可追蹤的 Worker 工作流

最近在整理自己的 AI 開發工作流，希望透過 Orca 把 Codex、Claude Code 和 Git Worktree 串起來。

我的想法很簡單：讓 AI 不只是各自寫程式，而是能像一個開發團隊一樣分工協作。

理想中的流程是：

Coordinator 分析需求 → 建立 Task DAG → 派發 Worker → 回報 worker_done → 整合驗收。

每個 Worker 在獨立的工作環境中執行任務，由 Coordinator 統一掌握進度。

結果實際使用時，卻發現一個奇怪的現象。

Orca Orchestration 明明已經啟用了，但 AI 有時還是直接開自己的 Subagent，而不是透過 Orca 呼叫 Worker。

任務可能照樣完成，但原本設計好的任務追蹤與協作流程，卻不一定會留下對應紀錄。

這讓我發現：

AI 會自己分工，不代表它會按照你設計的流程分工。

01. 原來我同時用了兩套代理系統

一開始，我以為啟用 Orca Orchestration，AI 就會優先透過 Orca 派單。

後來才發現，Codex 和 Claude Code 本身就具備自己的子代理機制。

當 AI 認為某項任務適合平行處理時，可能直接使用原生 Subagent。

但這與 Orca Worker 是不同的機制。

原生 Subagent 並不是不好。

如果只是讓 AI 同時閱讀幾個檔案，或者進行一次性的分析，它可能更直接、更有效率。

但當我需要的是跨模型協作、任務相依關係與可追蹤的執行狀態，就需要使用 Orca Orchestration。

問題不是哪一種代理比較強，而是我原本需要受監督的任務，卻可能走上另一條執行路徑。

02. 為什麼啟用 Orchestration，AI 還是會繞過？

查閱 Orca 官方文件後，我發現一個很重要的區別。

Orca 並不是把所有 Agent 交接都視為 Orchestration。

它區分了幾種情境：

• Ordinary Agent：一般工作，不需要正式協作生命週期。
• Handoff Owner：將工作所有權交給另一個 Agent，不一定需要持續監督。
• Coordinator：負責受監督的任務、Task DAG、Worker 派單與完成追蹤。
• Dispatched Worker：接收具備 Task ID、Dispatch ID 的正式任務，並回報執行結果。

所以，「幫我叫另一個 Agent 做」與「建立兩個受監督 Worker，完成後回報 Coordinator」，並不是相同的指令。

而且 Orca 的 Orchestration Skill 主要是指導 AI 如何使用這套機制，並不會因為設定已開啟，就自動禁止模型使用原生 Subagent。

如果沒有清楚定義派單方式，AI 就可能選擇自己熟悉的工具。

這也讓我理解，單純提醒 AI「記得使用 Orca」，不是可靠的解決方式。

03. 我的解法：建立 Orca-First 派單規則

我希望 Coordinator 保有判斷能力，但正式的多代理監督任務必須經過 Orca。

因此打算在自己的 AI 大腦中，增加一組 Orca-First Delegation Policy。

核心原則只有三個。

簡單任務，不要硬開 Worker

例如修改 CSS、調整文案、修正單一函式。

一個 Agent 能完成就直接做，不需要為了多代理而多代理。

正式多代理協作，必須走 Orca

只要需要追蹤任務狀態、管理 DAG、等待 Worker 回報，Coordinator 就必須使用 Orca Orchestration。

不得以原生 spawn_agent 或其他子代理工具取代正式 Worker。

派單必須能被驗證

每次正式派單，都應該能找到對應的 Task ID、Dispatch ID，以及最後的 Worker 完成狀態。

如果 Orca 啟動失敗，不應該偷偷改用原生 Subagent，最後卻宣稱完成了 Orca 協作。

這套規則會放進 AGENTS.md，並讓 Claude Code 讀取等效的協作規範。

但我也不認為寫好一份 Markdown，就能保證所有模型永遠遵守。

所以還需要工具層級的控制。

04. 不只靠 Prompt，還要限制 Coordinator 的工具

我目前考慮的方式，是建立專用 Coordinator 配置。

Claude Code 可以透過工具權限設定，限制 Coordinator 使用原生 Agent 工具。

Codex 則需要確認實際版本提供的 Multi-Agent 設定，以及是否能有效禁止 Coordinator 自行建立子代理。

這裡有個重要原則：

我只想限制 Coordinator 繞過正式調度，不想把所有 Worker 的代理能力全部關閉。

畢竟某些 Worker 可能只是在自己的授權範圍內，使用原生子代理協助分析。

真正需要避免的是：原本應該由 Orca 追蹤的正式任務，最後變成無法對應 Orca Task 的外部執行。

因此，理想中的控制方式是：

Coordinator 規則約束 + 工具權限限制 + 執行紀錄驗證。

不過，工具限制是否真的生效，仍需要按照安裝版本進行測試。

05. 最關鍵的一步：不要只相信 AI 說自己派單了

這次問題讓我最有感的地方，是 AI 的執行描述與實際系統狀態可能不同。

AI 可能回覆：

「我已經派出兩個 Agent 進行分析。」

但如果要確認這是不是一次真正的 Orca 協作，不能只看 AI 的文字回報。

我需要檢查 Orca Runtime。

例如先查詢：

orca orchestration task-list --json

確認是否真的建立了 Task。

再使用：

orca orchestration dispatch-show --task <task_id> --json

確認對應的 Dispatch。

在正式受監督的流程中，Worker 應透過 worker-start 啟動，完成後從自己的執行環境送出具備有效任務身分的 worker_done。

Coordinator 收到回報後，還需要驗證結果、處理訊息，並依照後續任務狀態繼續派單。

另外，收到 worker_done 不代表程式碼品質已通過驗收。它代表該次 Dispatch 的生命週期已回報完成；測試結果與程式碼變更仍然需要獨立確認。

這是我希望建立的標準：

不是 AI 說有派單就算成功，而是 Orca 能提供對應的執行證據。

06. 修正前後，我打算如何驗證？

目前已觀察到的問題是：Orchestration 已啟用，但模型偶爾仍會使用原生 Subagent。

接下來，我打算用三個情境驗證 Orca-First 規則。

我也會記錄修正前後的差異，特別是：

• 原生 Subagent 是否仍然被誤用？
• Coordinator 是否真的建立了 Orca Dispatch？
• Worker 是否能正常回報與釋放？
• DAG 相依任務是否能正確接續？
• 新增規則後，Token 成本與執行時間有多少變化？

這些目前仍是待驗證項目，還不能宣稱 Orca-First 已經完全解決問題。

尤其我想測試失敗的情境。

因為正常情況下大家都能順利執行，真正考驗協作機制的，是 Worker 逾時、無法啟動、回報失敗，甚至執行狀態無法確認時，Coordinator 能不能做出正確判斷。

07. 多代理真正困難的，不是啟動更多 Agent

回頭看這次問題，我發現自己對 AI 工作流的期待已經慢慢改變。

一開始，我希望透過 Orca、Codex、Claude Code 和 Git Worktree，讓更多任務可以平行執行。

但當多個 Agent 開始參與同一個專案，新的問題也跟著出現。

誰負責拆解任務？

誰決定使用哪個模型？

哪些工作能夠平行？

不同 Worker 修改相同檔案怎麼辦？

執行失敗時，誰負責重新派單？

最後由誰判斷結果可以交付？

這些其實都不是單純的 Prompt 問題，而是專案管理、軟體工程與工作流程設計的問題。

對我來說，Orca-First 不代表所有工作都必須經過複雜的管理。

它只是替 AI 建立一個明確的決策邊界：

簡單任務維持簡單，正式協作遵循統一流程，重要結果必須能夠驗證。

我希望 AI 能持續保有自主執行的能力，但不應該因為自主性越來越高，就讓整個開發流程變得不可追蹤。

這也是我正在打造 AI 大腦與多代理工作流的原因。

讓 AI 自己做事並不困難，困難的是讓一群 AI 按照同一套規則合作。

參考資料

• Orca Orchestration 官方文件
• Orca Orchestration Skill
• Git Worktree
• Claude Code Permissions
• OpenAI Codex 文件