多個 Agent 同時改程式碼卻不打架？Muse Code 靠 git worktree 實現平行開發零衝突

核心模式：一個父代理，多個能寫程式的子代理

Muse Code 的設計圍繞著一條簡單的規則：當一項工作可以拆成幾個獨立任務時，這些任務會自動分派（fan-out）給不同的 agent。父 agent 會為每個任務各生出一個具備寫入能力的子 agent。你不需要做任何設定，也不用啟動什麼特殊的平行模式——只要工作規模大到值得拆分，任務分解與派工就是預設行為。

顯而易見的問題馬上就來了：如果多個 agent 可以同時在同一個儲存庫裡寫程式碼，為什麼不會演變成滿地的合併衝突和互相覆蓋的檔案？

一場真實的 fan-out session：同一款遊戲拆成六項任務，四項已合併、兩項還在跑——每項任務都在 .muse/worktrees/ 底下各自的 worktree 裡進行，主要 checkout 完全不受影響。

Worktree：最符合 git 原生思維的隔離方式

每個子 agent 都會拿到自己專屬的 git worktree——一份與主副本共享歷史紀錄、卻擁有獨立工作目錄和獨立分支的儲存庫 checkout。兩個子 agent 可以在各自的 worktree 裡編輯同一個檔案，過程中完全看不到對方的變更。從結構上來說，衝突根本不可能發生。

同樣重要的是：你自己的工作副本始終保持乾淨。你在編輯器裡打開的那個目錄，永遠不會是 agent 正在動手改的那一個。不會有東西在你的游標底下憑空移動，不會有改到一半的 agent 變更混進你的 diff，而放棄某個 agent 的成果，也不過就是丟掉它的 worktree 那麼便宜。變更只有在完工並通過審查之後，才會進到你的分支。

為什麼不直接用分支？或是用容器？

一般的分支共用同一個工作目錄——任務進行到一半切換分支，等於直接把地毯從執行中的 agent 腳下抽走。完整的容器或整份儲存庫的 clone 當然行得通，但太過笨重：物件庫整份複製、啟動速度慢、合併起來也彆扭。Worktree 正好落在甜蜜點上：建立幾乎是瞬間完成、共享底層的 git 物件資料庫，而把子 agent 完工的分支合併回來，就是再普通不過的 git 操作——沒有需要你信任的自製同步層，也沒有需要除錯的專有狀態。

六個功能同時開發，有憑有據

官方發表時的示範就狠狠壓在這個機制上：在遊戲開發的範例裡，Muse Code 同時打造六項遊戲功能，每個 agent 各在自己的 worktree 裡工作，最後每條分支都乾淨合併。這就是實際的回報——一場多功能衝刺的實際耗時，會塌縮到接近其中最長那一項任務的時間，而不是所有任務時間的總和。

動手試試這道食譜

Agent fan-out 是 Meta 官方 cookbook 收錄的三大模式之一——把一件大工作拆給多個 subagent，讓任何環節都不會在半路互撞。可執行的版本收在 cookbook 裡。而且，分派出去的工作正是你事後最想稽核的那種東西——每個子 agent 的生成、工具呼叫與合併，全都記錄在事件日誌裡——不會因為事情是平行發生的，就有任何一筆逃出紀錄之外。