有效使用子代理

子代理大放異彩的時機

當探索工作與執行工作可以分開時，子代理的效果最好。如果任務中的每個步驟都取決於前一步驟的發現，您會希望這些工作留在主執行緒中。但如果您只需要一個答案，而不在乎過程，就把它委派出去。

子代理擅長以下任務：

• 您需要的是結果，而不是找出結果的逐步過程
• 探索性工作會使您主執行緒的上下文變得雜亂
• 該任務能從全新的視角或自訂的系統提示中受益

研究任務

研究是典型的子代理使用案例。試想調查一個不熟悉的程式碼庫中身份驗證是如何運作的。您的主執行緒需要知道 JWT 是在哪裡被驗證的，但不需要看到過程中搜尋過的每一個檔案。

研究型子代理可以讀取數十個檔案、追蹤函式呼叫，並探索不同的程式碼路徑。所有這些探索都留在子代理的上下文中。您的主執行緒會收到一份簡潔的摘要，例如：

JWT validation happens in middleware/auth.js line 42,
called from the Express router in route/api.js

子代理完成了繁重的工作。您的主執行緒得到的正是繼續前進所需的內容。

程式碼審查

當程式碼被呈現為由他人撰寫時，Claude 能更有效地審查程式碼。如果您與主執行緒經過多輪對話建立了一項功能，再要求同一個執行緒去審查它，往往會產生薄弱的回饋。因為 Claude 參與了建立過程，所以很難以全新的眼光來看待它。

審查型子代理會在一個獨立的上下文中查看變更。它會執行 git diff、讀取修改過的檔案，並套用其專門的審查標準，而不受程式碼撰寫過程歷史的影響。這種分離也讓您能在子代理的系統提示中編碼特定於專案的審查標準，確保整個團隊的審查標準一致。

自訂系統提示

Claude Code 的預設系統提示強調簡潔、聚焦於程式碼的回應。這對於編寫程式碼來說效果很好，但並非適用於所有情況。

以下是兩種自訂系統提示能讓子代理真正優於主執行緒的情況：

• 文案撰寫子代理——給它關於語氣、受眾和風格的指示。Claude Code 的預設提示傾向於簡潔的技術寫作，而這通常不是您在撰寫登陸頁面或電子郵件行銷活動時想要的。文案撰寫子代理可以擁有關於語調和結構完全不同的指示。
• 樣式設計子代理——在其系統提示中告訴它先讀取您的設計系統檔案，這樣它在開始撰寫任何 CSS 之前，就能了解您的顏色變數、間距慣例和元件模式。

子代理何時會造成傷害

啟動子代理的開銷——將其工作對主執行緒隱藏，並將其發現壓縮成摘要——只有在子代理能做到主執行緒做不到的事情時才有意義。有三種常見的反模式需要留意。

專家宣稱

宣稱自己是專家的子代理很少有幫助。像「你是 Python 專家」或「你是 Kubernetes 專家」這樣的提示沒有增加任何價值，因為 Claude 本來就具備這些知識。所謂的專家子代理能做的事，您的主執行緒沒有一件做不到。

循序管線

循序的子代理管線會產生問題。試想一個三代理流程：一個用來重現錯誤，一個用來除錯，一個用來修復。當任務真正獨立時，管線才能運作。但當每個步驟都依賴於前一步驟的發現時——而修復錯誤幾乎總是如此——管線就會失敗。資訊會在代理之間的交接過程中遺失。

測試執行器

測試執行器子代理往往會隱藏您需要的資訊。當測試失敗時，您需要完整的輸出來診斷問題。一個只回傳「測試失敗」的子代理，會迫使您建立額外的除錯腳本，才能取得原本在直接輸出中就能看到的細節。測試結果顯示，測試執行器模式在所有配置中表現最差。

決策準則

當您在決定是否要使用子代理時，請問自己一個問題：中間過程的工作重要嗎？

如果答案是否定的——您只需要最終結果——就把它委派給子代理。如果答案是肯定的——您需要看到並對過程中發生的事情做出反應——就把它留在主執行緒中。

在以下情況使用子代理：

• 研究與探索
• 程式碼審查
• 需要自訂系統提示的任務

在以下情況避免使用子代理：

• 沒有增加真正能力的「專家」人設
• 每個步驟都依賴上一步驟的多步驟管線
• 需要完整輸出以進行除錯的測試執行