派子代理之前，先想清楚要換回甚麼

今年五月底，我跑了一次 workflow，燒掉約 410 萬 token、至少吃掉五小時額度的 30% 到 40%，最後產出一份 290KB 的文件，裡面一堆誤判，幾乎沒有作用。當時我把 Claude Code 的 effort 開到 ultracode，workflow 每個環節都派好幾個 Agent，我看到一路都在跑 Haiku 4.5；Opus 4.8 讀完文件後，又自己把 codebase 讀一次確認成果。

我又測了一個清理 codebase 的任務，同樣讓 workflow 派一堆小 Agent 去做，結果還是沒清乾淨，最後是 Opus 自己下場做完。

前幾天看到有人在討論 Anthropic 的一篇文章〈Building agents: When to fold subagents into your main agent loop〉，談甚麼時候該把子代理收回主流程。他們寫的是企業 Agent 產品，但我自己用 Claude Code 派子代理，踩到的坑方向一樣。

下次 AI 說「我派幾個子代理分頭做」，你可以怎麼判斷這次派得划不划算？這篇就回答這個問題。

開了一堆 Agent，為甚麼最後還是主模型自己重做？

因為子代理通常是從白紙開始讀，交回來的又只有摘要；摘要不夠做決定，主模型就得自己重查，前面省下的力氣就在讀回和驗收時吐了回去。

Claude Code 的官方文件寫得很直接，一般的子代理開在自己的 context 裡，看不到你的對話紀錄、你已經用過的 Skill，也看不到主對話讀過的檔案；它花的 token 和主對話算在同一份用量裡。所以一派出去，它就得把需要的資料重讀一遍。

做完之後，它交回一份摘要。我在 2025 年就寫過這個問題，長文會讓模型變笨，但太短太精簡也會讓模型跟白癡一樣，因為「總結」本身是一種去脈絡化的產物。摘要只留結論，卻把前因後果和排除過的可能全砍了，主模型拿著它常常做不了決定。

我把 workflow 這條路攤開來看，每一步都在燒：

Opus 燒 token 規劃 workflow。
workflow 開一堆子代理，各自燒一大堆 token。
子代理吐出一包超大的結果文件。
Opus 再燒 token 讀完這包文件。
Opus 親自下場驗證，把 workflow 做過的事重做一部分。

Anthropic 自己的數據也說明了這筆帳。他們做多 Agent 研究系統時量到，一般 Agent 用的 token 大約是聊天的 4 倍，多 Agent 系統大約是 15 倍；他們也寫明，大部分寫程式的工作能真正平行的部分比研究少，Agent 之間也還不擅長即時協調與委派。

那子代理到底該拿來做甚麼？

子代理的定位很多元，我自己分成四種用法：防污染、職責分工、外包、第三者，每一種換回來的東西不一樣，要檢查的地方也不一樣。

用法	派出去要換回甚麼	派之前要答得出來	我踩過的賠法
防污染	主對話保持乾淨，核心任務不被一大包資料蓋掉	這件事會不會佔掉主對話大量篇幅	摘要漏了重要細節，主模型又自己重讀
職責分工	幾塊工作同時推進	各塊要讀的資料重疊多少、要不要互等	按規劃、開發、QA 切，每個都重讀同一批程式碼
外包	一份交出去就能驗收的成果	做到甚麼程度算完成、驗收要花多少力氣	一路跑小模型，產出一堆誤判，Opus 重讀重做
第三者	一雙沒看過前面討論的眼睛	你要它找的是判斷上的盲點，還是格式和數字對不對	每個檢查點都開子代理，慢、會飄，還是漏查

最近我最常用的是外包和第三者分析。下面一種一種講。

防污染：派之前先看範圍，不看任務類型

當一件事本身會佔掉主對話大量篇幅，或主對話為了處理它反而稀釋了原本的核心任務，交給子代理就比較恰當。

我在技術班上特別講過，子代理要用工作範圍來評估，不能只看任務類型。同樣叫「查資料」，翻一個你知道位置的檔案，跟掃二十個目錄找某個功能散在哪裡，對主對話的影響完全不同。前者自己讀最快，後者才值得隔出去。

隔出去之後，要提防的是摘要。派工時直接講明要帶回甚麼，例如每個發現附上檔案和行號、沒讀到的部分另外列出。主模型拿到能回頭核對的線索，就不必為了確認一句摘要而重讀整包檔案。

職責分工：先算重疊，不要照組織圖切

同時派好幾個子代理前，先看它們要讀的資料重疊多少；按職稱切，往往付了好幾倍的閱讀成本，卻只換到一點點差異。

我重構一個舊專案時，大量用了 subagent、agent team 和 workflow 這些平行委派功能，看到各家主力模型通常都按任務、模組或角色切，卻很少考慮不同 Agent 是不是在重複讀同一批架構文件和程式碼。表面上各自負責規劃、開發、QA，實際上可能有 90% 的 context 重疊，只為了最後 10% 的差異。

很多「公司部門」型的 Agent 設計都有這個問題，直接把人類組織分工搬給 AI，卻忽略每個 Agent 都要重建 context、協調、驗證和整合。開頭提到的 Anthropic 那篇也提醒，最容易出問題的是 Agent 架構變成公司組織圖的翻版；他們建議按 context 切，讓每個子代理拿到一塊不太需要系統其他部分的工作。

想在派工前看出重疊，可以先叫 AI 列出每個子代理打算讀哪些目錄和檔案再動手。幾份清單大半相同，就合成一個，或乾脆留給主對話做。

這不代表平行就沒用。我把一個沒有框架、沒有模組概念的舊專案重構成 Vue 架構，總共約 34 萬行變更，有子代理輔助確實比較快。但就算各種平行委派全開，洗一包 Vibe Coding 出來的舊程式碼還是花了一個多禮拜。平行能加速的，只有本來就能分開做、讀的東西又不太重疊的那幾塊。

後來我讓 AI 讀了那幾天的執行對話，做了一個叫 Baton 的 Skill，要求 AI 派工前先判斷三件事：是不是真的需要委派、誰負責哪一塊、還是主 Agent 直接做完。用下來，小事也派、又重複讀同一批檔案的委派少了非常多。你不必裝這個 Skill，派工前先讓 AI 回答這三個問題就能當作檢查。

外包：便宜模型不一定便宜

外包換回的是一份能驗收的成果，所以要先講得出做到甚麼程度算完成；換成便宜模型之前，還要算進重讀和驗收的成本。

我最近外包時會試著讓子代理跑便宜的模型，例如透過 model-relay 串 GLM、DeepSeek，嘗試用更低的成本達到一些目的。model-relay 是我自己寫的 Claude Code mod，能把別家模型註冊成可以指派的子代理。用開源的 AI 資安檢測工具 Strix 時，我把主模型設成 GPT 6 Sol、子代理設成 GPT 6 Luna，整次測試大約花了 110 美金的額度，以資安檢測來說很便宜。

但小模型子代理不一定比較省。今年五月我把自己的 Claude 工具改到能看清楚每次對話的 token 用量，才發現分工範圍不明確時，好幾個小模型會讀進高度重疊的內容，這些都會計入建立快取的費用，開了五個可能就等於沒省到。

為甚麼讀同一批程式碼，快取還接不起來？快取要從開頭一字不差才會命中，只要子代理的任務說明或讀檔順序不同，快取前綴就可能不一致而無法共用。依 Anthropic 現行的定價，寫入 5 分鐘快取的價格是一般輸入的 1.25 倍；接不上的每一個子代理，都要各付一次寫入費。

開頭那次 workflow 就是最貴的版本。我當時判斷，它派 Agent 時應該全用了 Haiku。小模型省下的單價，被一堆誤判、290KB 的結果文件和 Opus 重讀重做吃掉了。

挑外包工作時可以先看驗收成本。像整理會議紀錄、找出某個功能散在哪些檔案，結果比較好核對，便宜模型做錯也看得出來。但要做取捨、判斷架構的工作，驗收本身就得靠主模型重讀，交給便宜模型可能反而更貴。

第三者：要的是沒看過過程的那雙眼睛

當你跟主對話已經討論很久，覺得可能有盲點卻說不出在哪，就派一個子代理做獨立復盤，從不同角度檢查既有的決策、假設和推論，再把結果完整帶回主對話。

怕主對話球員兼裁判，也可以直接在指令裡要它另開一個 Agent 做 Review。

第三者的價值在於沒看過前面的討論，所以給的東西要少。先給要檢查的成品和當初的需求就好，別把「我覺得這樣沒問題」的推論一起塞過去，免得它的意見先被帶向你的結論。手上有不同家的模型時，換一家當第三者，看事情的角度會更不一樣。

不過第三者不適合拿來顧每一個檢查點。我以前每個檢查點不是主對話自己檢查，就是再開一個子代理檢查，速度慢、效果不一定好，分析維度一多更難調整，還很容易飄移；最煩的是明明有問題，它就是沒檢查出來。格式、數字、連結這種有標準答案的項目，交給測試或固定程式去跑；第三者留給需要判斷的盲點。

甚麼時候根本不用派？

工作小、要順著前面的討論一步步做，或是後一步得等前一步做完，都留在主對話自己做。

只動一到三個你已經知道位置的檔案，自己讀自己改最快。
正在來回微調一段文字、一個介面，每一步都依賴上一輪剛講的細節，拆出去光寫說明就比做完還累。
先規劃、再實作、最後測試這種順序工作，硬拆成三個子代理，後面的還是在等前面的。

如果你做的是給客戶用的 Agent 產品，Anthropic 那篇的做法更適合：先建一套評測，把子代理一個一個收回主流程，每收一個就比一次分數，留下表現比較好的那版。

派之前問自己一句

下次 AI 說要派子代理，或你自己想多開幾個時，先問：

這次派出去，是要換回乾淨的主對話、一份能驗收的外包成果、一雙沒看過過程的眼睛，還是同時推進的幾塊工作？

說得出是哪一種，再對照上面那張表檢查一次。說不出來，就讓主對話自己做。