一句話：Multi-Agent 不是「很多個 AI」，而是一間設計得好的公司。
「Multi-Agent 是什麼意思？Agent 和一般的 AI 有什麼不一樣？」
我解釋過很多次。但有一次，我用錯了方式
——我開始列名詞：Orchestrator、Sub-agent、Skill、Command、Trigger、Tool、Memory……
對方的眼神告訴我，我把他搞糊塗了。
後來我換了一個方式。我說：「你可以把它想成一間小型顧問公司。」
他立刻說：「喔，這我懂。」
那間虛構的顧問公司長這樣：
當客戶提出需求，不是一個人包辦所有事。
是一位專案主管先聽懂需求，判斷要拆成幾個任務、交給哪些人做。
然後研究員去找資料
工程師去寫程式
內容編輯去整理報告。
每個人有自己的職務技能和工具——有人用 Google、有人用資料庫、有人用 Email。
最後，專案主管把所有成果整合，交回客戶。
這就是 Multi-Agent 在運作時，實際上長什麼樣子。
但這裡有個根本問題
大多數人理解 AI 工具的方式，是把它想成「一個超強的人」
——問它什麼，它給你什麼。
這在單一任務上沒問題。
但當任務變複雜、需要多種能力、需要長時間執行、需要不同角色互相制衡的時候，
這個模型就開始崩潰。
就像你不能只靠一個人既負責研究、又負責寫作、又負責品管——
不是因為能力不夠，而是上下文會被塞滿、責任界線會模糊、錯誤會難以追蹤。
Multi-Agent 解決的，不是「AI 能力不夠」的問題，
而是「複雜任務需要組織化分工」的問題。
所以真正的問題是什麼？
如果你覺得 Multi-Agent 很難懂，
我認為不是因為概念複雜，而是因為你在用「工具」的框架去理解「組織」。
工具只需要知道怎麼用。
組織需要知道：誰負責什麼、用什麼方法、在什麼時機啟動、出錯了誰負責。
真正的問題是：怎麼把一個複雜任務，設計成一個可以追蹤、可以重複、可以審核的工作系統？
我用三個問題來拆解整個系統。
Who = Agent（誰負責？）
Agent 是有角色、有責任、有工具權限的執行者。
不是「做很多事的人」，而是「以某個角色負責某一類任務的人」。
研究員就只負責研究；品管就只負責品管。角色邊界清楚，才不會互相干擾。
How = Skill（怎麼做？）
Skill 是可以重複使用的方法、SOP 或流程模板。
就像一份「把長文改成 FB 貼文」的標準操作手冊
——不管誰用，流程一樣。Skill 管的是「怎麼做」，不是「誰來做」。
What / When = Command / Trigger（做什麼、什麼時候啟動？）
Command 是明確的啟動指令，就像在介面輸入 `/weekly-report`；Trigger 是事件驅動，例如每週一自動啟動、收到 Email 自動處理。
這三個問題，幾乎可以拆解任何 Multi-Agent 系統的設計邏輯。
還有一個角色值得單獨說：Orchestrator，也就是任務協調中心。
它不一定是最會做事的角色——
它負責的是判斷：需求是什麼？要拆成哪些子任務？
應該交給誰？結果是否足夠？要不要補查或人工審核？
就像一位好的專案主管，不需要自己寫程式，但要知道什麼時候找誰做什麼事。
在 Claude Code 這類工具裡，你的主對話就是預設的 Orchestrator。
你不需要一開始就設計一套複雜的多代理架構
——先把 Skill 和 Command 建好，讓主對話做協調，就已經是一個有效的系統。
等任務複雜到「一個對話搞不定」的時候，才需要考慮啟動 Sub-agent。這個順序不要搞反。
Multi-Agent 的核心問題不是「要用幾個 AI」，而是：你有沒有把任務設計成一個可以被管理的系統？
設計得好，它是一個可以擴充的小型顧問團隊；
設計不好，它是一個更貴、更難除錯的混亂。
