子代理太多反而變笨？Anthropic 建議：把 AI 團隊「收編」回一個主腦！
以下為虛構對話，人物與情節為創作，科學內容來源標註於文末。
▌三個臭皮匠
雨從下午兩點開始下。
白板上畫滿方框。中間一個大框，四周拉出十二條線。
「三個臭皮匠，勝過一個諸葛亮。」Dg 拿著白板筆轉身，「所以客服 AI 要拆成十二個專家子代理。退貨一個，語氣一個，查訂單一個——」
「臭皮匠要開會。諸葛亮不用。」
K 沒抬頭。咖啡杯在手邊，已經不冒熱氣了。
「開會很有效率啊。」
「主代理把工作交出去，只能交摘要。」K 翻過一頁論文，「Berkeley 看了七個框架、一千六百多筆執行紀錄，整理出十四種失敗模式。其中一大類，是代理之間對不上。」
Dg 想了一下。
「……所以是傳話遊戲。傳到第十二個人，『退貨』變成『退休』。」
K 沒回應。
算是對。
▌十三碗
門被推開，雨聲跟著進來一截。
「外送。」Liy 把塑膠袋放上桌，「兩碗乾麵，一碗餛飩湯。」
Dg 立刻挺直背。「Liy，妳來得正好。我正在設計一個主代理，底下帶十二個小弟。」
Liy 看了看白板，又看了看袋子。
「那下次要叫十三碗嗎？」
「不是那種小弟……」
「他們不吃飯？」
「他們沒有嘴。」
「那小弟要怎麼跟主代理說話？」
Dg 張口，停住。
K 放下筆。「交一張紙條。紙條寫不下的，就掉了。」
「喔。」
▌科學怪人
Dg 不放棄。「一個好漢三個幫。每個部門都把自己的規則寫進系統提示，系統才完整。」
「每人塞一句，規則會互相打架。」K 說，「這有名字，叫 Frankenprompt。有家公司的客服代理掛了十幾個專家子代理，品牌語氣前後不一，回應越來越慢。」
「就是縫起來的科學怪人嘛。」Dg 轉向 Liy，「法蘭肯斯坦。」
「法蘭肯斯坦是做怪物的那個博士。」Liy 說，「怪物本人沒有名字。」
「……重點不是那個。」
「那這個 prompt，是博士還是怪物？」
K 的筆停在半空。
過了兩秒。
「被縫的那個。」
▌書目卡
「那十二個小弟的工作，誰做？」Dg 問。
「一個主代理，加技能。」K 說，「技能平常只放一句簡介，用到才載入全文。漸進式揭露。Claude Code 靠這個，系統提示砍掉超過八成。」
Dg 盯著天花板。
「就像圖書館不會把書全攤在桌上，只放書目卡。要看哪本，再去拿。」
「如果書目卡寫錯呢？」Liy 問。
K 停了一下。
「那本書就永遠不會被拿。」
「所以子代理沒用了？」
「三種情況還是拆。資料多到表現可以量測地變差；要同時查很多地方，查完中間過程可以丟；工具多到選不好——三、五十個以上就容易選錯。」
窗外一台機車騎過積水。
▌先考十題
Dg 看著白板很久。
「所以不是人越多越好。」他說，「是交接越少越好。要拆，得先證明拆了比較好。」
「嗯。」
「那怎麼證明？」
「先準備十題標準考題。一次只合併一個子代理，前後比。每題多跑幾次，看哪幾題翻盤。」
「平均分數變高，不就好了？」
「平均會蓋掉壞掉的那題。」
Liy 把空塑膠袋折成小方塊。
「我們店平均一碗麵八十元。」她說，「可是菜單上沒有一碗是八十元。」
Dg 拿起板擦，把十二個方框一個一個擦掉，只留中間那一個。他在旁邊寫下「先考十題」，想了想，又在底下補一行小字：一次只動一個。
你做過分組報告嗎？五個人分五段，最後拼起來，語氣不一樣、資料重複，結論還互相打架。AI 代理也有一樣的問題。Anthropic 應用 AI 團隊最近建議：別急著把工作拆給一堆「子代理」，很多時候一個帶著技能包的主代理，反而做得更好、更快、更省。不過，子代理沒有被淘汰，只是要用在對的地方。
關鍵亮點（Key Highlights）
- 一個主代理＋按需載入的技能，在 Anthropic 觀察的數個企業部署中，品質常常勝過「拆成很多子代理」的設計，成本和等待時間也常常更低。
- 拆越多層，越像傳話遊戲：每次交接都可能漏掉資訊，各子代理的規則也容易互相打架。
- 子代理還是有用：資料多到塞爆、需要同時平行處理、或工具多到選不好時，拆開仍是好選擇。
- 改架構要靠評測：先準備約 10 個標準考題，一次只合併一個子代理，前後比對分數，並留意哪些題目的結果翻盤。
一、先搞懂：AI 代理和子代理是什麼？
主代理像專案組長，子代理像各自負責一段的組員。
代理：會自己動手的 AI
一般聊天機器人是「你問、它答」。AI 代理（agent）則多了一步：它會自己決定要查什麼資料、呼叫什麼工具、下一步做什麼，直到把任務完成。你可以把它想成一位會自己跑流程的助理，不只是會回話的客服。
子代理：AI 的分組報告
當任務變複雜，工程師常會想：「那就分工吧！」於是主代理底下又生出好幾個子代理（subagent）。每個子代理都有自己的脈絡視窗（可以想成它的「短期記憶桌面」）、自己的工具和自己的指示，由主代理分派工作、收回結果。
聽起來很合理，對吧？就像分組報告，一人一段，效率應該更高。問題是，做過分組報告的人都知道，最難的從來不是分工，而是整合。
二、拆太細的代價：多代理常見的翻車現場
每多一次轉述，原意就可能被削掉一點。
傳話遊戲：交接時掉資訊
主代理把任務交給子代理時，只能交出一段摘要，不會把整張桌面搬過去。子代理不知道前面發生過什麼，做出來的東西就可能偏掉。這就是交接遺漏脈絡。
這不只是 Anthropic 的觀察。UC Berkeley 團隊分析了 7 個多代理框架、1642 筆執行紀錄，整理出 14 種失敗模式，其中一大類就是「代理之間對不上」，另外還有系統設計不良與驗證不足。
子代理氾濫與 Frankenprompt
原文舉了一個案例：某公司的客服代理底下有十幾個專家子代理，結果品牌語氣前後不一，回應時間也越拉越長。
另一個問題有個很生動的名字：Frankenprompt（科學怪人提示）。每個團隊都往系統提示裡塞一句「我們這邊的規則」，最後拼成一個縫縫補補的怪物，規則彼此衝突，AI 也不知道該聽誰的。
評測只看局部，延遲越疊越高
如果每個團隊只評自己負責的子代理，就會出現評測過度在地化：每一段都考一百分，串起來卻不及格。再加上每一層交接都要等，使用者看到答案的時間自然被拖長。
三、為什麼一個主代理就夠：三個理由
理由一：共享脈絡
單一主代理從頭到尾都看得到同一張桌面。前面使用者說過什麼、試過什麼、失敗過什麼，它都記得，不用靠摘要轉述。就像一個人自己寫完整份報告，雖然累，但前後一定一致。
理由二：漸進式揭露，桌面不會被塞爆
你可能會問：一個代理要記這麼多東西，不會爆掉嗎？這裡的關鍵是漸進式揭露（progressive disclosure）。
做法很像圖書館的書目卡：代理平常只看到每項技能（Skill）的一句簡介，真的需要時才把完整內容載入。技能封裝的是「團隊怎麼做事」的步驟與規則；MCP 工具則負責執行動作或讀取即時資料。原文提到，針對較新的模型，Claude Code 的系統提示因此縮減了超過 80%。
理由三：模型變強了
早期模型能力有限，拆成很多小角色是在「補能力」。原文指出，從 Opus 4.5 開始，單一迴圈能處理的工作量超出團隊原本預期。當主角自己就能扛，當初的輔助架構就可能變成累贅，就像學會游泳後還綁著浮板。
四、子代理沒有被判死刑：什麼時候還是該拆
兩種設計各有適用場合，關鍵在任務的性質。
兩種設計比一比
| 比較項目 | 單一主代理＋技能 | 多個子代理 |
|---|---|---|
| 資訊連貫性 | 高，全程共享同一份脈絡 | 交接時可能遺漏 |
| 語氣與規則一致性 | 易維持 | 易出現各說各話 |
| 回應速度 | 常較快（某客戶案例約快 2 倍） | 層層交接，延遲累積 |
| 平行處理 | 較弱 | 強，可同時跑多條線 |
| 適合任務 | 環環相扣、前後依賴的工作 | 可拆成獨立小塊的工作 |
| 主要風險 | 工具太多時選錯 | 交接失誤、Frankenprompt |
三種仍然該拆的情況
原文列出三種子代理依然適用的情境：
- 脈絡膨脹造成可以量測的退化：資料多到真的讓表現變差，而且有數據證明，不是憑感覺。
- 需要平行處理，而且中間脈絡可以丟掉：例如同時查十個來源，查完只留結論。
- 工具選擇困難或指令衝突：原文提到工具超過 30–50 個後，選工具的表現容易變差，建議依使用者意圖分組。
外部研究怎麼說
Anthropic 自家的多代理研究系統就是成功案例：在內部研究評測中勝過單一代理 90.2%，代價是大約耗用 15 倍 token，而且他們也說明，需要高度共享脈絡的領域並不適合這種做法。
Google Research 等團隊的研究方向一致：可以平行拆解的任務，多代理增益明顯；需要一步接一步推理的任務，多代理反而退步。該不該拆，看的是任務結構，不是潮流。
五、怎麼收回來：一次只合併一個
先建評測集
原文建議，動手前先準備評測集，大約 10 個標準範例就能起步。評法要用端到端評測：看整個任務有沒有完成，而不是只看某一段表現。各技能可以另外配小型評測。
一次只動一件事
優先合併那些「本來就需要共享脈絡」的子代理，而且一次只合併一個，比較合併前後的表現。這跟做實驗一樣，一次改兩個變因，就不知道是誰造成的差異。
小心分數騙人
這是最容易踩的坑：速度變快了，大家很開心，卻沒注意到某個關鍵流程默默壞掉。原文建議每題多跑幾次（AI 每次答案不完全相同），並且逐題檢查哪些題目的結果翻轉，不要只看平均分數。
組織也要跟著改
這裡出現一個有趣的概念：康威定律（Conway’s law），意思是系統架構往往會複製組織結構。十個團隊，就容易長出十個子代理。
原文的建議是：由一個小型中央團隊負責系統提示和整體品質；各團隊改為擁有自己的「技能與工具」，每項技能指定一位負責人（DRI）。分工還在，只是從「各自養一個 AI」變成「各自維護一本操作手冊」。
六、觀點平衡：這篇建議該怎麼讀
留意發文者的立場
這篇建議出自 Anthropic，技能、MCP、Claude Code 都是自家產品，讀的時候要記得有推廣成分。比較好的讀法是搭配外部資料：Cognition 的 Walden Yan 在 2025 年發表〈Don’t Build Multi-Agents〉，同樣強調共享脈絡；但他在 2026 年的更新文章裡修正立場，認為「只讓一條線負責寫入、其他代理只提供判斷」的窄類型多代理確實有效。同一個人十個月後改口，正好說明這個領域的結論會隨新證據更新。
證據範圍有限
原文是應用 AI 團隊在數個企業部署中的觀察，用詞是「常常」「經常」，不是「一定」。「快 2 倍」只來自單一客戶案例，不能當成通則。
常見問題（FAQ）
Q1：所以 Anthropic 叫大家不要再用子代理了嗎？ 不是。原文的意思是「收回過度拆分的子代理」，並列出三種子代理仍然適用的情況。網路上部分轉述用了「移除」這類比較強的字眼，以原文為準。
Q2：技能（Skill）和工具（MCP）有什麼不同？ 技能像操作手冊，告訴代理「這件事該怎麼做」；工具像手腳，讓代理真的去查資料或執行動作。兩者都是需要時才載入。
Q3：一個代理做全部，不會記憶塞爆嗎？ 這正是漸進式揭露要解決的事：平時只放簡介，用到才展開。若真的塞爆而且表現可以量測地變差，原文也承認那就是該拆子代理的時候。
Q4：我不是工程師，這跟我有什麼關係？ 這篇建議背後的道理，其實就是組織管理：轉述層級越多越容易失真、局部最佳化不等於整體最佳化、改制度一次動一項。分組報告、社團運作、公司部門都適用。
Q5：為什麼不能只看平均分數？ 平均分數可能因為很多簡單題變好而上升，同時掩蓋少數關鍵題壞掉。逐題看「哪些翻盤」才抓得到問題。
結論
這篇建議的核心不是「單一代理比較厲害」，而是架構要跟著模型能力和任務性質調整。模型弱的時候拆分是補救，模型變強之後，同樣的拆分可能變成交接成本。
更值得帶走的是那套方法：先量測、一次只改一件事、逐題檢查、留下真正有效的。隨著模型持續更新，今天合理的設計明天可能又要改，這篇文章本身也不會是最後的答案。
延伸搜尋
- multi-agent system failure modes
- progressive disclosure agent skills
- Conway’s law
- lost in the middle LLM long context
參考資料來源
- Building agents: When to fold subagents into your main agent loop（Anthropic，2026）
- How we built our multi-agent research system（Anthropic，2025）
- Equipping agents for the real world with Agent Skills（Anthropic，2025）
- Why Do Multi-Agent LLM Systems Fail?（Cemri et al.，arXiv 2503.13657）
- Towards a Science of Scaling Agent Systems（Kim et al.，arXiv 2512.08296）
- Lost in the Middle: How Language Models Use Long Contexts（Liu et al.，arXiv 2307.03172）
- Don’t Build Multi-Agents（Cognition，2025）
- Multi-Agents: What’s Actually Working（Cognition，2026）
