Multi-Agent 與模型調度 Part 03｜Codex Fan-out：從任務拆分到 Worker Ownership

同一個 repo 裡開三個 Agent 很容易。難的是第三個 Agent 開下去之前，能不能說清楚它為什麼需要存在。

假設一個功能同時牽涉 schema、API 和 frontend。三個 worktree 可以把 Git working state 隔開，卻不會把依賴一起切斷。API 還是在等 schema 的形狀，frontend 還是在等 API contract。這時候把三件事同時派出去，省下來的不是等待時間，而是把等待改造成三份猜測，最後再由某個人收拾。[2][3]

Codex 從早期就支援把 well-scoped tasks 分給多個 Agent；Codex App 把 parallel agents 和 isolated worktrees 做成日常工作流，Symphony 則進一步把 task dependency、bounded concurrency 和 orchestration state 放進同一套設計。[1][2][3] 能力成熟之後，派工本身反而變成需要設計的部分。

這篇使用一個 Baton 來做 dispatch 判斷：Outcome → Direct → Independence → Ownership → Closure。Baton 不是 Codex 的官方術語，也不是固定儀式；它只負責在新增 Worker 前，把幾個足以讓 topology 翻盤的問題攤開。

先證明這件事值得拆

Fan-out 有一筆很容易漏算的帳。

單一 Agent 的路徑通常是理解、修改、驗證、交付。多一個 Worker，就多一份 brief、多一個 scope、多一份結果要讀；再加上 shared assumptions、conflict handling、integration 和重跑測試，省下來的 execution time 很可能從另一頭被吃回去。

OpenAI 在 Symphony 的實務裡描述過類似的人類瓶頸：同時管理三到五個 Codex sessions 還算順手，再往上增加後，工程師開始花更多注意力記住每個 session 在做什麼、切 terminal、追進度和處理卡住的長任務。[3] Agent 可以平行，人腦沒有因此多長幾個分頁。

Outcome 和 Direct 應該連著看。

Outcome：最後到底要拿回什麼？

「幫我看看 auth」不是一個好 outcome。它沒有告訴 Worker 何時該停，也沒有告訴主 Agent 拿到什麼才算有用。換成「定位 token refresh 的 earliest failing boundary，read-only」或「建立目前 failing path 的 focused regression test，不改 production code」，輸出就有形狀，也比較容易被驗證。

Direct：如果不派 Worker，會真的慢很多嗎？

一個單檔 bug、局部 rename、明確的 test fix，就算理論上切得成三份，也未必值得多出三份上下文和一次整合。大型 repo 的多區 read-only investigation、互不相依 module 的 bounded change、獨立的 security / correctness review，才比較容易把平行時間換成實際收益。

OpenAI 2026 年 6 月公布的 Codex 使用研究顯示，重度使用者確實已經把大量 agent work 分散到多個 parallel agents 上。[5] 這證明「多 Agent 並行」是實際工作型態，沒有替任何單一任務回答「應不應該拆」。那一題仍然要回到工作本身。

Anthropic 公開的 multi-agent research 經驗也提供一個有用的反例。多 Agent 對高價值、可高度平行的 research 很有效，但 token 與協調成本會上升；需要大量共享 context、Agent 之間 dependency 很重的工作，適配度會變差。[6] 這不是 Codex 的產品規則，只是拿來檢查一個常見直覺：能拆，不代表值得拆。

先畫 dependency，再談平行

先畫 dependency：

Database schema
      ↓
API contract
      ↓
Frontend integration

這三塊可以由不同人負責，但不能因為 owner 不同，就當成三條平行線。API 的正確性依賴 schema，frontend 又依賴 API contract。三個 Agent 同時開工，會各自在自己的 worktree 裡建立一套暫時假設。等 contract 收斂時，重做的成本才一起浮出來。

一種做法是保留順序：

Schema owner
    ↓ verified contract
API owner
    ↓ verified contract
Frontend owner

另一種做法是先把 shared contract 凍結，再把已經脫離 dependency 的下游工作 fan-out。這時候平行化才是在消掉等待，不是在藏等待。

Codex App 的 worktree 很重要，但它解的是 workspace isolation：Agent 可以在同一個 repo 的隔離副本工作，不直接踩彼此的 local Git state。[2] Isolation 不會自動產生 independence。

Comparison showing valid Codex fan-out with independent worker ownership versus false parallelism caused by a hidden dependency chain or shared mutable state.

Figure 2｜Worktree 可以隔離 Git working state，但 dependency chain 與 shared mutable state 仍會破壞真正的 task independence。

判斷一塊工作能不能獨立出去，可以看幾個訊號：

它是否需要另一個 Worker 還沒產生的結果；
是否必須改到同一份 shared state；
正確性是否建立在別人的未驗證假設上；
任一 Worker 失敗後，其他人的成果是否會大幅失效。

前兩項就已經很危險。四項大多命中時，這比較像 pipeline 或 DAG，硬叫 fan-out 只是換名字。

Symphony 的處理方式很乾脆：先建立 task tree 和 dependencies，blocked task 不啟動；只有 dependency 已解除的工作才進 parallel execution。[3] 這個思路比「每個 Agent 一個 worktree，所以一起跑」可靠得多。

Ownership 要落到能執行、也能驗證的邊界

Part 02 已經講過主 Agent、Worker、Checker 的角色分工。這篇只往 dispatch 多走一步：兩個 Worker 不能同時覺得同一個 surface 歸自己。

「A 負責 backend，B 負責 frontend」太寬。派工至少要寫清楚可修改路徑、只讀輸入、禁止寫入範圍、驗收條件和 stop condition。這些不是為了把 brief 寫成小型 spec，而是讓 Worker 一碰到 boundary 就知道該停。

如果三個 Worker 都能修改 package-lock.json、shared schema、central config 或同一批 generated files，就應該指定單一 owner，或重切 scope。Git conflict 只是看得到的那一層；更麻煩的是 semantic interference，三個 patch 都能各自通過局部檢查，合起來卻建立在不同版本的 contract 上。OpenAI 的 Harness Engineering 也把 architecture、tests、docs、rules 和 feedback loops 視為 agent environment 的一部分。[4] Ownership 同樣需要落在可觀察、可執行的邊界上。

Write scope 和 authority 不能混成一件事：

Delegation divides work.
It does not expand authority.

派 Worker 重新分配的是 execution，不是既有 authority。主 Agent 沒被授權 push、deploy、publish、delete 或修改 live config，Worker 也不會因為拿到一份 brief 就自動取得這些權限。它可以準備 patch、proposal、檢查結果與 evidence；高權限動作仍由原本被授權的 actor 決定。

Baton 是一張 dispatch card

Part 02 已經談過 closure owner。放回 dispatch 問題，只需要保留一條：派工前如果還不知道誰會讀回所有輸出、處理 overlap、整合 candidate 並重新驗證，就先不要 fan-out。Symphony 也把 run success 和 workflow completion 分開；一個 agent run 可以抵達 Human Review 之類的 handoff state，orchestrator 仍保有 authoritative state，負責 dispatch、retry 和 reconciliation。[3]

Baton decision gates showing that fan-out happens only after Outcome, Direct, Independence, Ownership, and Closure pass, with worker results returning to one closure owner before integration and final verdict.

Figure 1｜Baton 在新增 Worker 前依序檢查 Outcome、Direct、Independence、Ownership 與 Closure；任一關未通過，就回到更簡單的 topology。

檢查	要回答的問題	沒通過時
Outcome	最後要拿回什麼可驗證輸出？	先把任務定義清楚
Direct	單一 Agent 直接做，是否其實更便宜、更快？	直接做
Independence	slice 之間是否真的可以各自前進？	保留 dependency，改成 sequential / DAG
Ownership	write surface、shared state 與 stop boundary 能否切乾淨？	指定單一 owner 或重切 scope
Closure	誰整合、重驗證並下最後 verdict？	先補 closure owner

Baton 不保證五個 checkbox 全綠就會成功。任何一格都可以把工作送回 direct path、DAG 或重新切 scope；它的用途是避免把 Agent count 誤當成進度。

幾個常見工作放進這張 card 後，通常會得到下面的結果：

工作	比較合理的起點	原因
單檔小 bug	Direct	integration cost 往往高於收益
三個互不相依 module 的 bounded change	Fan-out	dependency 與 write ownership 可分離
大型 repo 的多區 read-only diagnosis	Fan-out	適合平行探索，write collision 很低
schema → API → UI	Sequential / DAG	contract 有明確上下游
多個 reviewer 檢查不同風險	Parallel checkers	獨立觀點本身就是輸出的一部分
多個 Worker 同改 central config	Single owner / re-scope	shared mutable state 太強
scope 還不知道在哪	Scout first	先找到 boundary，再決定拆法
deploy / publish / destructive action	Authorised actor closes	execution ownership 不等於 decision authority

表格裡沒有「開幾個 Agent」這一欄。先知道有幾塊工作能獨立前進，Agent 數量才有意義。模型調度也應該更晚決定：mechanical slice 可以放到較快或較便宜的 lane，困難 reasoning、review 或 final synthesis 留給較強模型，但模型選得再好也救不了互相纏住的 scope。

什麼時候該把 fan-out 收回來

Fan-out 一開始合理，不代表後面不能縮。

如果 Worker 經常在等別人的輸出，同一批 shared files 一直出現在不同 scope，closure owner 花最多時間重新拼上下文，或 integrated candidate 才開始冒出 cross-slice regression，這些都代表 independence 比原先估得低。

另一個很好認的訊號是 brief 越寫越厚。當每份派工都要塞進大量「不要碰這裡、等那邊完成、如果看到某狀態先別做」才能勉強維持平行，topology 本身可能就切錯了。這時候減少 Worker、改成單一 owner，往往比再加 guardrail 更便宜。

OpenAI 6 月 22 日的 long-running work 指南把可驗證步驟、跨 workstream continuity，以及 delegation 與 human oversight 放在同一個長任務問題裡。[7] 每多一條平行線，都應該換回一塊能被單獨驗證、最後又能回到整體 candidate 的進度。

Fan-out 值得保留的條件很樸素：幾塊工作可以各自前進，最後還能回到同一個可驗證結果。做不到，就回到 direct path、DAG 或單一 owner。

參考資料

OpenAI, “Introducing Codex”, 2025-05-16.
OpenAI, “Introducing the Codex app”, 2026-02-02.
OpenAI, “An open-source spec for Codex orchestration: Symphony”, 2026-04-27.
OpenAI, “Harness engineering: leveraging Codex in an agent-first world”, 2026-02-11.
OpenAI, “How agents are transforming work”, 2026-06-25.
Anthropic, “How we built our multi-agent research system”, 2025-06-13.
OpenAI, “Codex-maxxing for long-running work”, 2026-06-22.