這陣子 Claude Code 紅了後，YT 上很流行一種教學：打造一整套 Agent Team。
行銷 Agent、設計 Agent、文案 Agent、PM Agent、HR Agent。有任務時，先決定派給對應的角色，再由「主管 Agent」彙整。然後再搭配一個視覺化的遊戲介面，看起來猛的操作，像一間小型公司在你電腦裡上班。
不過玩了 Claude Code 這三個月，我不會向小白建議這樣用，我自己也不是這樣用的。
我幾乎沒主動建過任何特定的 Agent 角色，只是寫好 Skill 和 Workflow，把個人知識、風格判斷、工作流程寫好，專心打造一個「全能的 AI 代理人助理」，任務、派工都由它自己判斷。
看到大人學的張國洋老師寫了類似的觀察，他用簡單幾句話，完全點出了我的想法：
一般人的使用情境不應該嘗試多 Agent，除非是稽核、平行測試。
人類之所以要分部門，是因為一個人窮其一生只能搞懂一兩個專業，所以才需要行銷、工程、會計、HR……，但代價是溝通成本、跨部門協作、流程斷點、資訊不透明。結果現在你有一個全能的 AI，還自己去蓋部門壁壘，讓它溝通效率降低，這不是哪裡搞錯了嗎？
簡單幾句話，太有共鳴。（於是我就用語音講了 10 幾分鐘我的想法，寫了這篇長文 XD）
這也讓我想起，為什麼當初要離開大公司，用一人公司的模式經營著，就是希望能降低溝通成本、資訊透明，能一個人做完的事，幹嘛拆成一群人？
現在，AI Agent 的成熟，讓這理想更能被實踐了！
公司的存在，並不是因為「分工很美好」
經濟學家寇斯（Ronald Coase）有一個很經典的問題：「如果市場那麼有效率，為什麼會有公司存在？」
為什麼大家不全部直接向市場交易？
他的答案是：因為交易有成本。每筆交易都要找人、議價、簽約、驗收、追進度、處理糾紛。
當這些「交易成本」高過內部管理成本時，公司就會出現，把這些活動圈進一個組織裡，用權威而不是市場來協調。
白話來說，公司會分部門，本質上不是「美好的設計」，是「人類受限於自身能力，迫不得已的權衡」。
人類之所以要切出行銷部、設計部、工程部，不是因為這樣產出最好，而是因為一個人沒辦法同時是頂尖行銷、頂尖設計、頂尖工程。專業學習有極限，時間有極限，記憶有極限。我們只好把工作切碎，分給不同的人，再用會議、制度、規範把他們重新黏起來（恰恰也是大多數人最討厭上班的因素）。
現在問題來了：AI 沒有這個極限。
一個 Claude 或 GPT，理論上可以同時讀過行銷、設計、文案、工程、財務、法律的所有公開知識。
它的「專業頻寬」遠大於任何一個人類。它沒有時間極限，可以 24 小時持續工作；它沒有技能極限，你把所有 SOP 都餵進去，它一次就能調用。
換句話說：當初人類發明「分部門」這件事的根本原因，在 AI 身上根本不存在，而我們還擅自主張，還幫它蓋一座部門牆？
多 Agent 的隱形成本：溝通成本以平方增長
軟體業有一條很有名的法則，來自《人月神話1》的布魯克斯法則（Brooks’s Law）：專案已經延遲了，如果再塞更多人進來，只會延遲的更厲害。
Fred Brooks 的核心論點是：n 個人之間的溝通連線是 n(n-1)/2，也就是隨著人數平方增長。3 個人要協調 3 條線，10 個人要協調 45 條線，30 個人要協調 435 條線。當你加新人時，產出的增量永遠不可能線性增長，因為新增的溝通成本會把它吃掉。
這條法則放在 Agent Team 上完全適用。
每多一個 Agent，你就多了一個介面、一個 prompt、一份角色定義、一條交接協議。看似只是「多一個分工」，實際上是多了一條條需要被維護、被測試、被翻譯的溝通邊界。
雖然我沒開過百人公司，但身邊有不少管理 50+ 或百人公司的朋友，他們常說開公司最怕的就是：你以為你在做精細化分工，其實卻是在替自己累積管理債。
Conway’s Law：你怎麼切 Agent，產出就會長那個樣子
電腦科學裡有另一條被反覆驗證的觀察，叫康威定律（Conway’s Law）：「組織設計出來的系統，會反映該組織的溝通結構。2」
白話文說明：組織的形狀，會偷偷塑造產品的形狀。
如果你的公司有三個團隊，你做出來的軟體就會自然分成三個模組，模組之間的接縫就長在團隊與團隊之間。
當你預設「行銷文案歸行銷 Agent，視覺設計歸設計 Agent」，你就在 AI 的產出裡硬切出一條本來不需要存在的邊界。文案會少了視覺感，設計會少了文字節奏，整合的時候每個 Agent 只能看到自己被分配到的那塊，然後花更多 token 來彼此給回饋修正。
最後你會發現一個奇怪的現象：AI 在「單一任務」裡表現驚人，但在「多 Agent 協作」裡反而出現各種斷點、誤解、重工。
這不是 AI 變笨了，是你把它變回了人類組織的樣子。
真正的問題，是你「把解法寫進了提問」
講了好多理論觀察，最後來結論講講我的評估點。
我覺得多 Agent 設計裡最危險的一件事，來自「認知層面」。
當你說「派給行銷 Agent 寫貼文」的那一刻，你其實已經幫 AI 做完三個決定：
- 這是個行銷任務
- 要寫成貼文
- 要用行銷的視角切入
AI 接到的不是一個開放問題，是一條被預先鋪好的軌道（封閉）。
這就掉進了 AI 提問跟任務交付的最大誤區：你在提需求或問題的文字裡，已經預設了答案，後續無論誰來執行，人也好、AI 也好，都只能在你劃定的框框裡找局部最佳解。
但很多時候，最好的方案，根本不在那個框裡。
你以為這是行銷任務，但 AI 可能讀完你過去三年的內容後，覺得這次該走「個人故事 + 觀點長文」而不是「行銷文案」。你以為這要先做設計再寫文案，但 AI 可能判斷這個主題應該先寫稿、再讓視覺跟著文字節奏長出來。
所以我在我的 CLAUDE.md 文檔裡，有一條是寫：
當我提出需求，不盲目執行，你會挑戰假設、提出更好方案。
我發現這樣 AI 反而常常產出比我自己預想更好的方案。它會盤點我過去寫過的內容、我手上有的工具、我寫過的知識、規則和流程，然後給我一條我沒想過的路徑。
這需要一點「放手」的勇氣。但如果你不放手，你只會得到「你認知中的那個天花板」的產出，善用 AI，它能帶你看見另一個天花板。
這也是為什麼我覺得很多 2024-2025 年被大眾瘋傳的「提示詞模版」，現在來看反而是一種「詛咒」。
因為你的 AI 能力，會被限制在「提示詞提供者」的認知。
以前要分工，是因為人有極限；現在要合一，是因為 AI 沒有
經濟學裡有一條叫比較優勢（Comparative Advantage）的法則：即使一個人在所有事情上都比別人做得好，他還是應該專注在「相對最強」的那件事，把其他事讓給別人做，這樣整體產出最大。
這是分工合作的理論基礎，也是過去兩百年人類組織的底層邏輯。
但比較優勢有一個前提：個體能力是有限的，時間是稀缺的，所以「機會成本」存在。你做 A 就不能做 B，所以一定要分工。
在 AI 時代，當「同時做 A 和 B」的成本趨近於零，「同時掌握五個領域」不再需要五輩子，或是「在不同視角間切換」不需要任何啟動時間，分工合作的模式就改變了。
對於個體工作者來說，把自己手上唯一一個 AI 切成五個 Agent，再讓它們互相協調，這個動作的「合作收益」可能根本抵不上「協調成本」。
還要加上一個更深層的代價：你切 Agent 的同時，也在切自己的學習迴路。
當所有任務都被一個全能的 AI 處理，你會被迫看到「行銷、設計、工程、財務」是怎麼在同一個腦袋裡互相影響的。這個整合視角，本身就是這個時代最稀缺的能力。
不是說分工從此沒意義，但當你切成 Agent Team，你看到的就只是各部門的產出疊在一起，看不到中間的化學作用。久而久之，你也只會用「分部門」的方式思考，而不是用「整體」思考。
這才是最大的損失。
Anthropic 和 Cognition 的官方立場：multi-agent 不是預設選項
如果上面這些經濟學和軟體業的類比還不夠說服你，那我們直接看兩家 frontier AI lab 自己怎麼說。
Anthropic 和 Cognition 都有能力做 multi-agent，但兩家公司都公開講過：這個概念被濫用了。
Anthropic 在工程部落格的 Building Effective Agents 講得很直接：
多數場景下，一個結構簡單的 workflow 加上單一 agent 就夠了，不需要動用複雜的多 agent 架構。
後來他們又發表 How we built our multi-agent research system，分享自家多 agent 系統的經驗，但那個系統處理的是「研究型、需要並行探索」的任務，不是日常的內容產出或工作流。換句話說，連 Anthropic 自己都把 multi-agent 留給特定場景，沒有當成預設答案。
Cognition（開發 AI 工程師 Devin 的那家公司）講得更白，他們有一篇文章標題直接就叫 Don’t Build Multi-Agents。
核心警告是 context fragmentation：多個 agent 各自有自己的對話脈絡，彼此看不到對方知道什麼。
他們的建議是先窮盡單一 agent 加上 long-context 的可能性，真的不行了，才考慮 multi-agent。
context fragmentation 翻成白話，就是 A agent 已經處理過的事，B agent 不知道，又重新做一遍；或者更慘，A agent 跟你討論過「這個方案不要用」，B agent 接手後又把那個方案拿出來用。
這就是 multi-agent 真正的隱形稅。
什麼時候才需要 Agent Team？
當然，Agent Team 並非一無是處，在特定一種情境，我也會主動去提出要派 AI Agent，那就是讓 Codex 來稽核 Claude Code 的任務。
當你需要一個獨立的視角來檢查另一個 AI 的產出，不被原本的脈絡污染。這時候多 Agent 的「資訊隔離」變成優點。
但就不是在同一個 LLM 底下，而是讓不同的模型來獨立評估，很像寫論文的 peer review，這時候的分工是「動態」的，不是「結構性」的。
Agent 是被當下的任務需求叫出來的，不是被你預先固定在那裡等任務上門。
把知識給滿，讓它自行派工，我們不要干預
如果不用 Agent Team，怎麼讓 AI Agent 真的好用？
這三個多月，我的答案還是一樣：把你的知識、技能、SOP、工具、品味，全部寫成它能讀的東西，然後信任它的分配能力。
我自己用 Claude Code 的方式是：把每個領域的知識和風格寫成 Skill，把固定步驟寫成 Workflow，把跨領域的鐵則寫進 CLAUDE.md。剩下的，我幾乎不太去下指導棋。
任務進來，它自己讀規則、判斷流程、決定要不要叫 subagent、什麼時候該停下來問我。
- 我管的是「成果＆品味」：它交付出來的成果像不像我、有沒有抓到我想表達的核心、有沒有符合我對品質的標準。
- 我不管「流程＆分工」：什麼任務該誰做、要不要拆部門、流程要怎麼走。
我發現：當我管得越少，產出越好。當我管得越細，AI 的判斷力反而會被我限制。
這可能也是為什麼我會覺得玩 AI 很興奮，因為，這就是見證「重塑組織」的重要轉折點。
習慣管得太多的公司，不相信自己員工的老闆，可能 AI 也用不太好 XDD
我現在都跟我的讀者會員說，我覺得我的 AI 比我聰明百倍。我能給它的最大幫助，是把我自己會的東西全部交給它，不用擅自替它決定該怎麼用這些東西。
結語：部門牆是迫不得已，不是值得搬進 AI 的東西
我們從小被教的協作和管理觀念，是建立在「人有極限」這個前提上的。
因為一個人學不完所有專業，所以要分工；因為分工有摩擦，所以要組織；因為組織有規模，所以要部門。這一整套邏輯鏈，是人類為了克服自身極限，演化出來的妥協。
它，是「不得不的折衷」。
可是當我們手上突然多了一個沒有這些極限的 AI，我們第一反應竟然不是慶祝終於可以「合而為一」，而是急著把人類組織裡那些痛苦的部門牆，原封不動搬過去。
（當然也是因為 Agent Team 的視覺化介面很吸引人，好像自己擁有了一個團隊跑在自己電腦，像是打遊戲一樣）
如果你管理過 50 人以上的團隊，你應該很清楚：分工到一定規模後，效率減少，內耗增加，最後大部分力氣都拿去處理跨部門的溝通。
當模型會越來越強，越來越聰明，它將能掌握越多上下文、多領域知識，產出越好的成果，硬把它切成 Agent Team，等於是把它從「不會內耗的超人」，硬退化回「會內耗的小公司」。
也許在團隊協作、在企業導入、在需要多人共用同一套 AI 規範的場景，Agent Team 有它的位置，它讓角色可審查、可重複、新人 onboard 比較快，這些是組織治理的需求。
但如果你是一位超級個體，想用 AI 把自己的生產力發揮 10 倍，你的時間應該不是去煩惱怎麼替 AI Agent 分工劃部門，是交給它你的知識脈絡、工具權限、流程 SOP，然後信任 AI 的判斷與建議，讓它好好發揮。
🔥 五星好評優惠價倒數中｜24 小時開始活用 Claude Code
為什麼大多數人用不好？因為你的 AI Agent 一開始太空白、你也不知道從何訓練。
以我們 8 年教學，超過 10,000 名學員在數位工作術的經驗，這次特別設計課程機制：
這堂迷你課，設計為可以直接餵給 Claude Code，它會快速學會這些「武功秘笈」！
- 【基礎設定引導檔】讓你直接丟給你 AI Agent，讓它快速升級的
- 【實戰應用 Skill 組合】，幫你省下 10+ 小時的迷惘摸索期，讓你的 AI Agent 快速好用
👉 已超過 4,400 人購買：前往觀看課程
（記得收藏持續更新的 Claude Code 學習資源）
- 《人月神話：軟體專案管理之道》（The Mythical Man-Month: Essays on Software Engineering），作者 Fred Brooks，是 IBM System/360 作業系統的專案經理，這本書被譽為軟體領域的經典著作。 ↩︎
- 康威定律原文：”Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” ↩︎
