既然 Subagent 沒有比較懂某個領域，那我在委派任務時，還需要特別描述它的「角色」嗎？
角色描述不是完全沒用，但它的作用被普遍高估了。角色描述真正發揮效果的地方，是幫助 Claude 在那個隔離的上下文裡，用比較一致的語氣或視角處理任務（例如要求用「安全稽核」的角度去檢視程式碼，會讓輸出更聚焦在漏洞而非風格問題），這比較接近「設定濾鏡」，而不是「賦予額外知識」。
更值得花心力琢磨的，反而是委派時附上的任務描述本身要夠具體——因為 Subagent 沒有主對話的背景，任務描述含糊，Subagent 只能憑猜測補上缺失的脈絡，容易做出偏離預期的結果。與其在角色設定上堆砌形容詞，不如把時間花在把任務範圍、預期輸出格式寫清楚。
如果一個任務其實不複雜，但過程中會讀很多檔案，也算是該用 Subagent 的訊號嗎？
是的，而且這正好點出「任務難不難」跟「該不該隔離」是兩條不同的判斷軸線。一個任務可以很簡單（例如「找出這個專案裡所有用到某個已棄用函式的地方」），但過程中需要搜尋大量檔案、產生大量中間結果，這種情況下即使任務本身不需要「專業判斷」，依然是委派給 Subagent 的好時機——因為真正要隔離的是搜尋過程中產生的雜訊，不是任務的難度。
反過來說，一個困難的任務（例如設計一套複雜的資料庫遷移策略）如果整個思考過程都需要跟主對話已知的專案脈絡緊密互動、來回討論，委派給一個看不到主對話歷史的 Subagent 反而不合適，因為它會缺乏太多必要的背景資訊。判斷依據永遠是「雜訊會不會累積」，不是「任務聽起來難不難」。
Subagent 回傳的結果摘要，如果漏掉了主對話後續需要的細節，有辦法補救嗎？
這是委派設計時最容易踩到的陷阱：因為主 Agent 只會收到 Subagent 最終的結果摘要，任何沒有被摘要涵蓋的中間細節，一旦 Subagent 結束執行就等於遺失了，沒有辦法事後回頭「補問」細節——因為那個上下文已經不存在了。
實務上的補救方式，是把「這次任務結束後，主對話後續可能還需要哪些資訊」在委派任務描述裡就先想清楚，明確要求 Subagent 在回傳摘要時涵蓋這些項目，而不是等結果回來才發現漏了什麼。如果真的漏掉了關鍵細節，通常只能重新啟動一個新的 Subagent、把任務範圍調整成包含那個缺漏的部分，再執行一次——這也是為什麼任務描述寫得夠完整，比事後補救重要得多。
我平常用 claude.ai 網頁版聊天，不是用 Claude Code，Subagent 這套機制跟我有關係嗎？
Subagent 目前主要出現在 Claude Code 這類具備檔案系統與多輪工具呼叫能力的агент式環境裡，網頁版聊天介面本身沒有這個功能。但理解這個機制背後的判斷邏輯，對任何情境下跟 Claude 協作都有幫助——尤其是「隔離雜訊」跟「增加能力」是兩件不同的事這個原則，同樣適用在你自己怎麼組織一次對話上。
舉例來說，如果你在同一個對話串裡先做了大量探索性質的資料蒐集，又想接著做一個需要專注、不希望被那些雜訊干擾的分析任務，開一個新的對話視窗、只把提煉過的重點貼過去，其實就是在人工複製 Subagent 想做的事——用乾淨的上下文換取品質，而不是硬把所有東西塞進同一個視窗，指望 Claude 自己去蕪存菁。
第一次接觸 Subagent 的人，很容易在腦中建立一個直覺但錯誤的模型：主 Agent 是「通才」，Subagent 是各自專精某個領域的「專家」，遇到程式碼審查就叫「程式碼審查專家」出馬、遇到研究任務就叫「研究專家」出馬，彷彿每個 Subagent 內部裝的是不同版本、能力各異的 Claude。
這個直覺完全可以理解——畢竟大部分 Subagent 的命名和 description 都長得像是在描述一種專業角色。但這個模型從機制上來說是錯的。Claude 在每一個上下文視窗裡本來就具備完整的知識，不會因為被指派成「Subagent」就變得更懂某個領域。Subagent 真正做的事，不是增加能力，是增加隔離。
當主 Agent 判斷某個任務適合委派出去，它會啟動一個 Subagent——這個 Subagent 擁有自己完全獨立、全新的上下文視窗，不會繼承主對話的歷史紀錄，也看不到主 Agent 之前讀過哪些檔案、呼叫過哪些工具、已經用過哪些 Skill。主 Agent 唯一能把資訊傳遞給 Subagent 的管道，是委派時附上的那段任務描述文字。
Subagent 在自己這個乾淨的上下文裡獨立完成任務——讀檔案、搜尋程式碼、執行指令，過程中產生的所有中間資訊都留在 Subagent 自己的上下文裡，主 Agent 完全看不到這些過程，只會收到 Subagent 最後回傳的結果摘要。這個特性也代表 Subagent 之間、以及 Subagent 跟主對話之間，資訊傳遞只有「委派時的任務描述」和「完成後的結果摘要」這兩個窄窗口，中間探索過程中累積的雜訊完全不會外流。
要理解 Subagent 為什麼重要，得先理解它解決的原始問題：一個標準的 Claude Code 對話有固定大小的上下文視窗，在一個進行數小時的專案裡，光是探索性質的檔案讀取、程式碼搜尋、網路查詢累積的輸出，就可能佔掉相當可觀的比例。如果一次探索讀了五十個檔案才找到真正需要的那一個，另外四十九個檔案的內容依然留在上下文裡，持續稀釋後續每一次生成回覆時模型能真正專注的資訊密度。
這個現象常被稱為「上下文腐化」（Context Rot）——不是模型變笨了，而是模型必須同等地關注上下文裡的所有內容，當雜訊比例升高，真正重要的訊號自然被稀釋。Subagent 解決的正是這個問題：把探索過程中會產生大量雜訊的工作，隔離到一個用完即丟的獨立上下文裡，讓雜訊完全不會流入主對話，主 Agent 只接收提煉過的結果。
如果把 Subagent 誤解成「更懂某個領域的專家」，設計 Subagent 的 description 和委派任務時，很容易寫成強調身分與專業背景的描述（例如「你是資深安全稽核專家」），卻忽略了真正該琢磨的重點：這個任務會不會產生大量主對話不需要看到的中間過程？如果答案是否定的——任務本身輸出精簡、不涉及大量探索——委派給 Subagent 反而可能只是徒增一次啟動新上下文、重新蒐集背景資訊的延遲成本，沒有實質好處。
正確的設計思路應該反過來問：這個任務會不會累積大量我不需要留在主上下文的雜訊？是不是需要限制某個工具的使用權限？工作本身是不是自成一體、能被總結成一段簡短摘要回傳？這三個問題答案越是肯定，委派給 Subagent 的價值就越高——重點始終落在「該不該隔離」，不是「誰比較懂」。
釐清 Subagent 不是「專家」之後，跟 Skill 的分工界線也會變得清楚：Skill 是把可重複使用的知識或工作流程，直接載入到主對話的既有上下文裡，屬於「增強」；Subagent 則是啟動一個獨立上下文去執行任務、再把結果收斂回主對話，屬於「隔離」。當你想要的是讓 Claude 在目前對話裡多一項本領，該找的是 Skill；當你想要的是把一個會產生大量雜訊的任務挪到看不見的地方去做，該找的是 Subagent。兩者也可以搭配使用，例如替 Subagent 預先載入特定 Skill，讓它在自己的隔離上下文裡運用那項能力。
Subagent 之間也不能互相巢狀啟動——如果一個 Subagent 執行過程中遇到原本會觸發委派的情境，它會在自己的上下文裡直接處理掉，而不是再生出下一層 Subagent，這也是為了避免隔離機制本身變成新的複雜度來源。
下次考慮要不要用 Subagent 之前，先把「這個任務需要專家」的念頭放下，換成問自己：這個任務做完之後，過程中產生的細節有多少是主對話真的需要留著的？如果答案接近於零，那才是委派給 Subagent 的訊號，跟任務難不難、要不要「專業知識」完全無關。設計委派任務時，把重點放在「回傳什麼樣的摘要對主對話最有用」，會比堆砌角色設定更能發揮 Subagent 真正的價值。