多智能體不是把更多 AI 丟進同一個聊天室，而是把目標、責任、上下文、權限與驗收標準拆開管理。
本文從 CodeBuddy CLI 與 Git Worktree 的協作概念出發，說明企業如何避免「代理人越多、混亂越大」，建立可追蹤的 AI 團隊。
▋ Belief：多開幾個 AI 視窗，不等於擁有一支團隊
單一 AI 代理人處理小任務時很方便，但專案一旦同時包含研究、實作、測試、安全審查與文件整理，它就容易把不同目標塞進同一段上下文。前面討論的假設、後面新增的限制與中途產生的程式碼彼此干擾，最後形成所謂的上下文污染。
因此，多智能體架構的核心不是「數量」，而是職責分離。CodeBuddy CLI 的研調素材指出，子代理人可以擁有獨立的 Context Window、專用 System Prompt 與工具權限；主代理人則像技術主管，負責拆解任務、分派工作與整合結果。
一支 AI 團隊的成熟度，不看它同時啟動多少代理人，而看每一份產出能否找到負責者、證據與驗收標準。
Git Worktree 為什麼是關鍵機制？
想像兩位工程師同時在同一張桌面、同一份檔案上修改內容：一位重構核心程式，另一位新增測試。即使兩人能力都很好，只要彼此覆蓋檔案，成果就會互相破壞。Git Worktree 的作用，是讓不同代理人在各自的工作區與分支平行作業，最後再經過差異審查與合併。
這種設計帶來的不是神奇加速，而是清楚的隔離：代理人 A 的重構不會立即污染代理人 B 的測試環境；失敗的實驗可以被丟棄；每個變更都有獨立差異可供檢查。它把「大家一起亂改」轉化成「各自在可追蹤的邊界內交付」。
平行化不是萬靈丹
只有彼此依賴度低的任務，才適合平行執行。假如測試規格必須等資料模型確定後才能撰寫，硬把兩件事同時派出去，只會讓測試代理人根據錯誤假設工作。最後省下的執行時間，會在整合階段加倍付回。
- 適合平行：競品資料蒐集、安全檢查、文件盤點、彼此獨立的模組探索。
- 需要排序：需求確認後才能設計、設計確認後才能實作、介面穩定後才能完成整合測試。
- 不宜委派：最終商業決策、敏感權限核准、公開發布與無法回復的操作。
▋ Desire：你真正想要的是吞吐量，不是更多對話
企業採用多智能體，通常期待更快完成專案。然而速度只有在成果可整合時才有意義。若每個代理人使用不同定義、輸出不同格式，主控者將花更多時間閱讀、重寫與處理衝突，這就是看不見的協調稅。
理想狀態不是「AI 幫我做完所有事」，而是讓人類主管把注意力集中在高價值判斷：目標是否正確、風險是否可接受、證據是否足夠，以及成果是否值得發布。研究、草擬、測試與比對可以分派；責任與決策不能外包。
成本要看整條協作鏈
- 模型成本：每個代理人都會消耗推理資源，重複讀取大型上下文尤其昂貴。
- 協調成本：任務拆解、共享規格、狀態追蹤與衝突解決都需要時間。
- 整合成本：不同分支或不同報告必須經過合併、測試與一致性檢查。
- 失誤成本：權限過大、需求理解錯誤或未經審查的自動發布，可能造成遠高於模型費用的損失。
所以，最好的第一個多智能體專案，不是最複雜、最重要的任務，而是可以拆分、有明確交付物、失敗可回復的中等規模工作。先證明協作設計有效，再逐步擴大範圍。
▋ Intention：用「指揮官合約」建立可治理的 AI 團隊
步驟一：先寫共同任務書
1，定義結果：用一句話說清楚完成後要出現什麼可驗收成果，例如「產出已通過測試的登入修正與風險說明」，而不是「研究登入問題」。
2，固定共同詞彙：把客戶、訂單、草稿、發布等關鍵名詞寫成小型詞彙表，避免不同代理人對同一名詞各自解讀。
3，標示禁止事項：明確禁止接觸正式資料、修改憑證、跳過測試、直接合併或對外發布。權限要依任務最小化，不要因為方便就開放整個系統。
步驟二：依成果拆角色，不要依職稱演戲
每個子代理人都要有一份具體合約：輸入是什麼、要交付什麼、可用哪些工具、不能做什麼、何時算完成。安全審查者應交付威脅清單與證據；測試撰寫者應交付可執行測試；研究者應交付來源、結論與不確定性。
華麗的「CRO、CTO、CMO」名稱可以幫助理解，但如果角色沒有交付物與權限邊界，就只是在進行角色扮演。角色的價值來自責任可驗證，而不是名稱聽起來像高階主管。
步驟三：畫出依賴關係再決定平行度
把子任務放在一張簡單的依賴圖上：沒有前置條件的工作可以並行；需要共同介面的工作先由主控者定義契約；依賴上游決策的工作則排隊等待。這一步能避免代理人高速完成一批建立在錯誤假設上的成果。
步驟四：隔離工作區與上下文
程式專案可使用 Git Worktree 或獨立分支隔離變更；研究專案則可用獨立資料夾、來源清單與輸出格式隔離。每個代理人只拿到完成任務所需的最小上下文，既降低資訊噪音，也減少敏感資料暴露。
步驟五：設置雙層驗收
第一層由專職代理人檢查格式、測試與明顯風險；第二層由主控者或人類負責整合判斷。任何需要對外發布、寫入正式資料或變更權限的操作，都必須停在預覽狀態，等待明確核准。
步驟六：記錄協作效益
每次專案記錄總完成時間、人工介入時間、重做次數、合併衝突、模型消耗與錯誤類型。若平行代理人增加後，人工整合時間也同步暴增，問題不在模型不夠強，而在任務合約與依賴設計不夠清楚。
先建立責任，再增加代理人；先證明可整合，再追求平行速度。
▋ 從一個可回復的試點開始
選一個兩天內能完成、可以拆成研究、草擬與審查三部分的內部任務。為每個角色寫下輸入、輸出、權限與完成定義，最後比較單一代理人與多智能體流程的總工時與重做次數。你要測的不是誰比較聰明，而是哪一種組織設計更可靠。
如果你的團隊已經同時使用多種 AI，卻仍然遇到責任不清、資料分散與成果無法整合，與蔡教練聊聊您的數位轉型需求，把零散的 AI 對話重建成可治理、可追蹤、能持續交付的工作系統。
