多 Agent 協作不該用版本控制來救
多 Agent 協作的衝突不該靠版本控制合併來救，應該用工作區隔離來避免。
問題不在合併，在隔離
看到 Up AI 那則貼文時，我第一反應是：這解決的其實不是技術問題，而是架構問題。
多個 Agent 同時改動同一份代碼，用 Git 的自動合併機制應該能協調。但實際發生的是無限循環——Agent A 改了某段邏輯，Agent B 看到結果不對，改回去，Agent A 又改，陷入僵局。這不是因為合併演算法爛，而是因為參與者是 AI，它們的「判斷」可能相悖，版本控制工具根本無法理解這種衝突的根源。
Up AI 的答案很直接：別讓衝突發生。用 worktree 物理隔離工作區，讓不同 Agent 在不同分支上獨立作業。這改變了整個思路——從「事後用工具協調」轉向「事前用架構避免」。
worktree 的隱藏陷阱
Claude Code 的 claude -w 命令有個容易踩的坑：新 worktree 預設基於 remote default branch，而不是你當前的 HEAD。
如果你在本地分支上做了改動但還沒 push，啟動新 worktree 時，那些改動會被遺漏。你以為新工作區會包含最新進度，實際上卻可能丟失未提交的內容。
解決方法是改變操作流程：先手動執行 git worktree add，明確指定分支或 commit，再啟動 Claude。不能依賴工具的「便利」預設，因為那個預設在多 Agent 場景下其實很危險。
並行不等於加速
有人會想，既然一個 Agent 能做，那三個 Agent 應該快三倍。但 Up AI 的經驗和後續討論都指向同一個結論：無限繞圈，效率反而下降。
原因在於多 Agent 加速有個前置條件——事前的任務分割。不同檔案、不同分支、明確的 ownership。如果沒有這個設計，增加 Agent 數量只會增加衝突面積，遞減而非遞增效率。
你必須在啟動並行之前，就把任務分割清楚。否則多 Agent 就像多個廚師擠在一個廚房，互相踩腳。
實踐上的選擇
如果你現在在用 AI 做代碼改動，這裡有幾個具體的決策點：
- 單 Agent 單分支：最安全，但慢。適合小改動或探索性工作。
- 多 Agent 多分支：需要事前設計任務分割。每個 Agent 負責不同的檔案或功能模組，定期合併。
- 避免 worktree 預設：手動建立，明確指定基點。
用多 Agent 就必須付出架構設計的成本。如果沒有這個成本意識，加 Agent 只會加亂。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。