Sub-Agent

子代理是什麼，跟我平常說的「多步驟任務」有什麼不同？

子代理是主任務把某個獨立的子問題整個拆出去，交給另一個完全獨立運作的 Claude 實例處理，處理完再把結果送回主任務，主任務不需要知道子代理內部經歷了哪些推理過程。這跟一般的多步驟任務差別很大：一般多步驟任務是同一個 Claude 實例依序做完步驟一、步驟二、步驟三，所有步驟共用同一個上下文視窗，隨著步驟增加，早期的資訊會逐漸被擠出視窗或變得模糊。

子代理不同，每個子代理都有自己專屬、乾淨的上下文視窗，只裝著它被指派的那一小塊任務，完全不受主任務裡其他內容干擾。舉例來說，如果主任務是「幫我審查這 20 份供應商合約」，一般做法是同一個對話裡逐份看完，看到第 15 份時，第 1 份合約的細節可能已經模糊；用子代理的做法則是把 20 份合約分給多個子代理，每個子代理只專注在自己拿到的那幾份，不會被前面看過的內容干擾判斷。

子代理有哪些風險，哪個最容易被忽略？

最容易被忽略的風險是「協調成本」。子代理平行處理雖然快，但每個子代理只看得到自己那一小塊資訊，看不到其他子代理在做什麼。如果任務之間其實有隱藏的關聯——例如子代理 A 審查的合約條款，其實會影響子代理 B 該怎麼判斷另一份合約——拆成子代理反而會讓這層關聯被忽略，因為沒有人負責把兩邊的資訊串起來，除非主任務事後有做交叉檢查。

第二個常被忽略的風險是結果品質不一致。因為每個子代理是獨立運作，如果任務描述不夠精確，不同子代理對同一個模糊指令可能會有不同的理解方式，導致最後彙整回來的結果，風格或判斷標準不太一致。這在需要嚴格統一標準的工作（例如合規審查、法律文件比對）特別危險，因為表面上看起來每份都審查完了，但審查的嚴格程度可能因子代理而異。

什麼情況下應該用子代理，什麼情況下不應該？

適合用子代理的核心判斷標準是「任務彼此獨立、可以平行處理、結果之間不需要互相參照」。例如同時檢查一個專案裡三個不同模組的程式碼品質，或是同時研究三個競品各自的定價策略、同時整理三份不同客戶的會議紀錄——這些任務即使全部同時做，結果也不會互相影響，適合拆成子代理。

不適合的情況是任務彼此高度依賴，後面的步驟一定要等前面的結果才能決定怎麼做。例如先分析一份市場報告，再根據分析結果決定要不要深入研究某個特定議題——這種「先有結論才知道下一步要做什麼」的任務，拆成子代理反而會增加溝通成本，因為子代理之間沒辦法即時交換中間結果，不如維持單一流程循序處理，讓每一步都能看到前一步完整的推理過程。簡單判斷法：問自己「這些子任務可以同時丟出去做，還是一定要照順序做」，答案是同時，才適合用子代理。

進階使用者怎麼設計子代理任務，才能讓結果品質更穩定？

進階使用者的關鍵做法是「在分派前先統一標準」，而不是分派後才發現各子代理標準不一致再回頭修正。具體做法是先寫一份簡短但明確的共用指引，包含判斷標準、輸出格式、需要標注的關鍵欄位，讓每個子代理拿到的不只是「去審查這份合約」，而是「用以下五個標準審查這份合約，每個標準給出符合或不符合的判斷，並附上具體條款編號作為依據」。這樣即使子代理各自獨立運作，因為起點的指引一致，最後彙整回來的結果風格和嚴格程度也會比較一致。

另一個進階技巧是設計「彙整步驟」而不是單純把子代理結果拼在一起。主任務收到所有子代理的結果後，應該再做一次交叉檢查，特別留意子代理之間有沒有互相矛盾的判斷，或是有沒有原本應該互相參照卻各自獨立處理的隱藏關聯。這一步彙整檢查，正是彌補子代理「看不到彼此」這個結構性限制的關鍵動作，也是子代理任務品質穩不穩定的分水嶺。