Claude Code 的多 Agent 編排，為什麼要從 Teams 開始想
Claude Code 的多 Agent 編排不該從「更聰明」開始想，而是從「如何分工協作」開始——oh-my-claudecode 用 Teams 模式解決的是複雜任務中的上下文和可控性問題。
問題的起點
Claude Code 這類 AI 編程助手最大的瓶頸，不在單個 Agent 的能力，而在協作的粒度。一個複雜的開發任務往往需要不同角色的配合——有人負責架構決策，有人負責實現細節，有人負責測試驗證。如果只有一個 Agent 在跑，它要在這些角色之間不斷切換上下文，效率會快速衰減。
yeachan-heo 的 oh-my-claudecode 就是在解決這個問題：把 Claude Code 的能力拆解成多個專門化的 Agent，用 Teams 的概念來編排它們。
架構的核心想法
這個項目不是讓一個超級 Agent 什麼都做，而是建立一個「Team」模式——每個 Agent 有明確的職責邊界，通過消息傳遞和狀態共享來協作。
這樣做的好處有幾個：
- 上下文管理更精準——每個 Agent 只維護它需要的上下文，不會因為全局信息過多而降速
- 失敗恢復更容易——一個 Agent 出錯，不需要重新跑整個流程，只需要重新執行那個任務
實現層面的取捨
Teams-first 的設計不是沒有代價的。多個 Agent 之間需要同步狀態、傳遞結果，這本身就是開銷。更關鍵的是決策複雜度——什麼時候該分發任務給哪個 Agent，誰來決定？這需要一個調度層，而調度層本身也可能成為瓶頸。
這個項目在做的其實是把「如何分工」這個問題從人類移到了代碼層。你不再需要手動寫「先做 A，再做 B」的流程，而是定義清楚每個 Agent 的職責，然後讓系統自己決定調度。
什麼時候值得用
不是所有的編程任務都需要多 Agent 編排。簡單的代碼生成、小範圍的重構，單個 Agent 就夠了。但如果任務跨越多個技術棧或層級（前端、後端、基礎設施），需要反覆驗證和迭代，或者團隊成員需要看到 AI 的推理過程而不只是最終結果，多 Agent 架構就開始有價值。
換句話說，這不是為了追求「更智能」，而是為了在複雜場景下保持可控和可追蹤。
未來的問題
當 Agent 數量增加時，協調的成本增長曲線是什麼樣的？是線性的，還是指數的？這決定了這個模式能擴展到多大規模。
另一個問題是 Agent 之間的「信任」。如果一個 Agent 的輸出有問題，下游 Agent 怎麼判斷？是盲目相信，還是要有驗證機制？驗證本身又會變成新的 Agent 嗎？
這些問題的答案會決定 Teams-first 這個思路在實際工程中能走多遠。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。