AI 入門學習 ／ 資料更新至 2026 年 10 月
你請 ChatGPT 比較三台筆電，畫面右側突然出現「子智慧體：已使用 3 個」。三個小幫手各自去查規格、查售價、查效能，最後再由 ChatGPT 整理成一份比較。這就是現在 AI 工具越來越常見的「主代理＋子代理」分工。
它看起來很厲害，也帶來不少疑問：子代理到底是什麼？常聽到的「路由」跟它有什麼關係？交給子代理真的比較快嗎？會不會很燒用量？是不是讓主代理自己做比較划算？這篇用官方技術文件、研究數據和社群使用者的實際回報，一次說清楚。
30 秒看重點
90.2%
Anthropic 內部研究評測中，主代理＋子代理比單一代理高出的表現幅度
約 15 倍
多代理系統的 token 用量約是一般聊天的 15 倍，單一代理約 4 倍
最多約 90%
複雜研究問題因平行處理而縮短的完成時間
41%～86.7%
柏克萊大學研究測試 7 個開源多代理系統時觀察到的失敗率
3 個問題
能拆、量大、只要結論，三個都是「是」才值得派子代理
資料：Anthropic、UC Berkeley 等，詳見文末資料來源。
01主代理與子代理：一個專案經理，帶一群專員
主代理（orchestrator，也叫協調者）負責和你對話：理解需求、拆解任務、分派工作、收回結果、整合成最後的答案。子代理（subagent）則只接一項明確的小任務，在自己的工作空間裡完成，再把摘要交回主代理。
業界最常見的設計叫「協調者－工作者」模式。Anthropic 的 Research 研究功能就是典型例子：主代理先規劃研究方向，再同時派出 3 到 5 個子代理平行搜尋，最後統整結果並加上引用。ChatGPT 與 Codex 的子代理也是同樣的概念：由 ChatGPT 負責派出子代理、轉達後續指示、等待結果並收尾。
為什麼要這樣分工？主要有三個好處：
主對話保持乾淨
子代理可以讀幾十頁資料，只把結論帶回來，不會塞爆主對話
平行加速
彼此獨立的工作同時進行，不用一個做完才接著做下一個
權限可以收窄
例如只給子代理「讀取」權限，它就不可能誤改檔案
要記得
子代理看不到你和主代理之前的對話內容，它只拿到主代理寫給它的任務說明。所以主代理交辦得好不好，直接決定子代理做得對不對。Anthropic 早期就遇過子代理重複查同一件事，後來是靠把任務說明寫清楚才改善。
02路由：決定「這件事交給誰」
路由（routing）原本是網路名詞：路由器決定封包要走哪條路。放到 AI 代理上，意思是判斷一個請求該交給哪個代理、哪個模型，或哪一條處理流程。它和主代理、子代理有三層關係：
路由本身是一種基本模式
Anthropic 歸納的代理工作流程中，路由與協調者－工作者並列；Google ADK 也把路由代理視為最基本的多代理模式
交接通常是路由的結果
客服分流就是典型：第一位代理只判斷該轉給帳務、退款還是技術，轉過去後由專家接手
自動派工也是在做路由
Claude Code 會比對子代理的描述（description）決定要不要交辦，描述就是路由的依據
| 比較項目 | 路由器 | 主代理（協調者） |
|---|---|---|
| 做什麼 | 分類、轉送 | 拆解任務、分派、整合結果 |
| 一次派給幾個 | 通常一個 | 可以同時派好幾個 |
| 結果回到誰手上 | 不一定回來，專家直接接手 | 一定回來，由主代理彙整 |
| 比喻 | 總機 | 專案經理 |
整理：TempEDU，依 Anthropic、OpenAI、Google ADK 文件歸納。
簡單說，路由器只管「交給誰」，協調者除了交辦，還要「收回來、拼起來」。主代理在派工的那一刻其實也做了路由判斷，所以可以把路由看成協調者的基本動作之一。
各家框架的名稱不同，但幾乎都能歸成下面四種協作方式。判斷關鍵是「誰負責最後的答案」：OpenAI 的開發文件建議，主管要保有控制權、自己產出答案時，把專家當工具呼叫；要讓專家接手時，就用交接。
| 協作方式 | 怎麼運作 | 適合 |
|---|---|---|
| 代理當工具 主管制 | 主代理呼叫子代理，拿回結果自己整合 | 研究、比較、文件分析 |
| 交接 handoff | 把對話整個轉給專家代理接手 | 客服分流 |
| 固定工作流 依序、平行、迴圈 | 流程由程式決定，不靠 AI 判斷 | 審核流水線、草稿到修改 |
| 對等協作 團隊模式 | 代理之間直接溝通、共用任務清單 | 大型程式專案 |
資料：OpenAI Agents SDK、Google ADK、Claude Code 文件（2026 年 10 月）。
模型路由是什麼
你也可能看到「模型路由」：系統依問題難度，自動決定用反應快的小模型，還是深度推理的大模型。概念完全一樣，只是被分派的對象從「代理」換成「模型」。
03效能：平行讓它更快，也可能更好
多代理最有說服力的數據來自 Anthropic。以 Claude Opus 4 當主代理、Sonnet 4 當子代理的系統，在內部研究評測中比單一 Opus 4 高出 90.2%。他們舉的例子是找出標普 500 資訊科技類股所有公司的董事成員：多代理系統把題目拆給子代理分頭查而答對，單一代理一家一家慢慢查，最後沒有完成。
| 比較項目 | 單一代理 | 主代理＋子代理 |
|---|---|---|
| 研究評測表現 Anthropic 內部評測 | 基準 | 高出 90.2% |
| 複雜問題完成時間 | 基準 | 最多縮短約 90% |
| token 用量 和一般聊天相比 | 約 4 倍 | 約 15 倍 |
資料：Anthropic Engineering，How we built our multi-agent research system（2025 年 6 月）。
看懂這個數據
表現變好，很大一部分來自「花了更多 token」。Anthropic 分析後發現，光是 token 用量就能解釋約八成的表現差異。換句話說，子代理變強的代價，就是更耗用量。
多代理也不是每一種架構都一樣好。LangChain 比較過兩種常見設計：一律由主管代理轉述子代理答案的架構，表現略輸給讓子代理直接回答的架構。原因是主管在「翻譯」子代理的結果時會漏掉細節，就像傳話遊戲。
04用量：子代理不是省錢工具
派子代理會多花多少？
以一般聊天的 token 用量為 1 倍，數字為 Anthropic 的觀察
一般聊天
單一代理（會用工具、會多輪操作）
多代理系統（主代理＋子代理）
※ 實際倍數會因任務、模型與子代理數量而不同。
官方文件也講得很直接。OpenAI 的 Codex 文件寫明，子代理流程比同等的單一代理耗更多 token，因為每個子代理都要自己推理、自己操作工具。Claude Code 的文件則提醒，子代理自己發出的請求，跟主對話算在同一份用量額度裡。
社群論壇上的實際回報更讓人有感：
Hacker News
有人交給 Claude Code 一個大任務，它立刻派出 7 個子代理，還沒有一個做完，額度就用光了。
DEV 社群
有開發者用子代理重構數百個檔案，Pro 方案大約 15 分鐘就撞到用量上限。
Codex GitHub
有人同時開 8 個子代理，5 小時額度約 1 分鐘就見底。官方後來修正，屬於異常狀況。
為什麼這麼耗？社群歸納出三個原因：
子代理從零開始
它沒有主對話的脈絡，需要的資料得重新讀一次
預設沿用貴的模型
沒特別指定時，Codex 與 Claude Code 的子代理都會沿用主代理的模型
回報也會佔空間
派得越多，交回主對話的摘要越多，主代理要讀的也越多
例外：有時候反而省
AI 每回一則訊息，都會把整段對話歷史重新讀一遍。如果主代理自己讀了一萬行的紀錄檔，這些內容之後每一輪都要再讀一次。交給子代理去讀，原始資料留在子代理那邊，主對話只收到摘要。所以「資料量大、但你只需要結論」的工作，交給子代理可能反而省。
05什麼時候該用：先問三個問題
拆得開嗎？
能切成幾塊互不等待的工作，例如比較 5 家廠商、審 10 份合約
量夠大嗎？
3 項以內主代理自己做就好；5 項以上、或每項都要讀大量資料，優勢才明顯
只要結論嗎？
想看推理過程、想中途追問細節，就讓主代理自己做
能拆、量大、只要結論，才找子代理；其他情況，讓主代理自己來。
| 情況 | 建議 | 原因 |
|---|---|---|
| 小任務 幾個步驟就完成 | 主代理自己做 | 派工本身就有成本 |
| 環環相扣 寫一份文件、改一段程式 | 主代理自己做 | 子代理之間對不齊 |
| 多個獨立查詢 比較多家廠商、多份合約 | 派子代理 | 平行加速、主對話乾淨 |
| 資料量大 只需要結論 | 派子代理 | 避免主對話被塞爆 |
| 很趕 額度充足 | 派子代理 | 用額度換時間 |
| 額度吃緊 | 主代理自己做 | 依序做比較慢，但省 |
整理：TempEDU，依官方文件與社群討論歸納。
但，多代理不一定比較好
就在 Anthropic 發表多代理研究系統的前一天，開發 AI 工程師 Devin 的 Cognition 發表了一篇〈不要建多代理系統〉（Don’t Build Multi-Agents）。他們舉的例子很好懂：請 AI 做一個 Flappy Bird 小遊戲，拆給兩個子代理，一個做背景、一個做小鳥。結果一個做出瑪利歐風格的背景，另一個做出的鳥不像遊戲角色，動起來也不像 Flappy Bird，兩邊根本拼不起來。
學術研究也看到類似問題。加州大學柏克萊分校分析了 7 個熱門的開源多代理系統，失敗率落在 41% 到 86.7%，並歸納出 14 種失敗模式，大致分成三類：系統設計不良、代理之間對不齊，以及缺少驗證。這份研究測的是 2025 年的開源框架，不等於今天的商用產品，但點出的問題至今仍然存在。
兩派其實有共識。LangChain 的整理很中肯：多代理要做好，關鍵在於把正確的資訊交給正確的代理；而以「讀取」為主的工作，比以「寫入」為主的工作容易做好。這也是為什麼主流工具的子代理，多半負責搜尋、閱讀、整理，再把結果交回主代理做決定。
互相看不到
子代理不知道彼此做了什麼決定，風格、用詞、做法容易不一致。
平行寫入會衝突
多個代理同時修改同一份檔案，容易互相覆蓋。
傳話會失真
主代理轉述子代理的結果時，細節可能被省略或誤解。
額度燒得快
派得越多越耗用量，沒限制數量時尤其明顯。
怎麼開始用
不需要一開始就研究設定檔。先把握三個步驟，就能用得又快又省：
先判斷
用「能拆、量大、只要結論」三個問題，決定這次要不要派子代理。
講清楚
要派就指定數量、範圍和回傳長度；不派就直接說「請你自己依序完成」。
看用量
做完看一下用量變化，找出最耗的工作，下次調整做法。
不同角色可以這樣看待子代理：
一般使用者
不用刻意開子代理。比較多項產品、整理大量資料時，再要求它分頭進行。
企業主管
評估導入 AI 代理時，把用量當成預算項目。多代理適合研究、比較、文件審閱，不適合需要統一決策的工作。
老師與講師
用「專案經理帶專員」的比喻教學生理解分工，也是練習把任務拆清楚、交辦清楚的好題材。
子代理本質上就是「交辦」。會把事情拆清楚、說清楚的人，不論交給 AI 還是交給同事，都能事半功倍。實際在 ChatGPT、Claude 裡怎麼開、怎麼關、怎麼省，下一篇有完整的操作教學與可複製的提示詞。
延伸學習
想把交辦 AI 的能力練扎實，可以從這幾門課開始：
也可以搭配閱讀：子代理怎麼控制：ChatGPT、Codex、Claude、Claude Code 實務操作、AI 額度省著用：四大平台省額度攻略
本文重點
- 主代理負責拆解、分派、整合；子代理在自己的工作空間完成一項小任務後回傳摘要。
- 路由是「判斷交給誰」：路由器只轉送，協調者還要把結果收回來整合。
- 平行處理讓研究類任務更快、更完整，Anthropic 內部評測高出 90.2%。
- 代價是用量：多代理約是一般聊天 15 倍的 token，子代理不是省錢工具。
- 能拆、量大、只要結論，才派子代理；環環相扣的工作讓主代理自己做。
想一想
你手邊有哪一件工作，可以拆成三份互不相干的小任務？如果交給三個助理，你會怎麼寫交辦說明，才不會讓他們各做各的？
資料來源
- Anthropic Engineering（2025 年 6 月）。How we built our multi-agent research system
- OpenAI ChatGPT Learn。Subagents
- OpenAI API 文件。Multi-agent
- OpenAI Agents SDK 文件。Handoffs
- Claude Code 文件。Create custom subagents
- Claude Code 文件。Manage costs effectively
- Google Developers Blog。Agent Development Kit: Making it easy to build multi-agent applications
- LangChain（2025 年 6 月）。Benchmarking Multi-Agent Architectures
- LangChain。How and when to build multi-agent systems
- Cognition（2025 年 6 月）。Don’t Build Multi-Agents
- Cemri 等，NeurIPS 2025。Why Do Multi-Agent LLM Systems Fail?
- Hacker News 討論。子代理消耗 token 的使用者回報
- DEV Community。Claude Code Sub Agents – Burn Out Your Tokens
- openai/codex GitHub Issue #9748。Launching concurrent subagents instantly drains entire Pro plan usage quota
本文封面為 AI 生成的示意圖，內文圖解由程式繪製。社群案例為個別使用者回報，僅供參考。
Edit with Tr.Bug
Follow me on：LinkedIn ｜ 探教育TempEDU
3 Comments.
Comments are closed.