設計有效的子代理
現在您已經知道如何建立子代理，讓我們來看看讓它們真正發揮效用的模式。配置不佳的子代理會漫無目的地遊走、執行過久，或產生主代理無法使用的輸出。解決方法歸結為四件事：撰寫良好的描述、定義輸出格式、回報遇到的障礙，以及限制工具存取權限。
子代理配置資料如何被使用
當您向主上下文視窗代理發送訊息時，每個可用子代理的名稱和描述都會包含在系統提示中。這就是主代理決定要啟動哪個子代理以及何時啟動的方式。如果您想更好地控制子代理自動觸發的時機，名稱和描述就是您應該調整的地方。
描述還扮演第二個角色。當主代理啟動子代理時，它會撰寫一個輸入提示來啟動任務。它會使用描述作為撰寫該提示的指引。因此，描述不僅控制子代理「何時」執行——它還塑造了「子代理被告知要做什麼」。
撰寫能塑造輸入提示的描述
考慮一個程式碼審查子代理。使用通用的描述，主代理可能會撰寫像「使用 git diff 找出目前的變更」這樣的輸入提示。這很模糊。子代理必須自行判斷哪些檔案是重要的。
如果您將描述更新為包含類似「您必須精確告訴代理您希望它審查哪些檔案」的內容，主代理現在就會撰寫一個更具體的輸入提示，列出實際要審查的檔案。
這種技巧適用於不同類型的子代理。例如，在網路搜尋子代理的描述中加入「回傳可引用的來源」，會讓主代理在委派任務時包含該指示。
定義輸出格式
您能對子代理做出的最重要改進，就是在其系統提示中定義輸出格式。這會帶來兩個效果：
- 它建立了自然的停止點——子代理在填完格式的每個部分後，就知道自己已經完成了。
- 它防止子代理執行過久。如果沒有定義輸出，子代理很難判斷何時已經完成足夠的研究，往往會執行得比必要的時間長得多。
以下是程式碼審查子代理的結構化輸出格式範例：
請以結構化格式提供您的審查：
- 摘要：您審查內容的簡要概述和整體評估
- 嚴重問題：任何必須立即修復的安全漏洞、資料完整性風險或邏輯錯誤
- 主要問題：品質問題、架構不一致，或重大效能疑慮
- 次要問題：風格不一致、文件缺漏，或微小的最佳化空間
- 建議：改進建議、重構機會，或應套用的最佳實踐
- 核准狀態：明確說明程式碼是否可以合併/部署，或是否需要修改
這個格式為子代理提供了一份清晰的檢查清單。一旦每個部分都填完，子代理就知道可以停止了。
回報障礙
當子代理在工作過程中發現變通方法時——例如解決相依性問題，或發現某個指令需要特定旗標——這些細節需要出現在它回傳的摘要中。如果沒有，主執行緒就必須自行重新發現相同的解決方案，這會浪費時間和 token。
您希望被呈現出來的內容包括：
- 設定問題或環境特殊狀況
- 任務過程中發現的變通方法
- 需要特殊旗標或配置的指令
- 造成問題的相依性或匯入項目
取得這些資訊的方法，是在輸出格式中明確要求它。在您的輸出範本中加入「遇到的障礙」部分，可以可靠地呈現這些資訊。
- 遇到的障礙：回報審查過程中遇到的任何障礙。這可以是：設定問題、發現的變通方法或環境特殊狀況。回報需要特殊旗標或配置的指令。回報造成問題的相依性或匯入項目。
限制工具存取權限
並非每個子代理都需要存取每個工具。思考子代理實際需要做什麼，只給予該工作所需的工具。這會帶來兩個效果：它防止意外的副作用，並且在您有多個子代理時，讓每個子代理的角色更加清晰。
以下是思考常見子代理類型工具存取權限的方式：
- 研究／唯讀子代理——只需要
Glob、Grep和Read。無法意外修改檔案。 - 程式碼審查者——需要
Bash存取權限來執行git diff並查看變更內容，但仍然不需要Edit或Write。 - 樣式／程式碼修改代理——這是您給予
Edit和Write存取權限的地方，因為子代理的工作就是實際變更您的程式碼。
整合所有內容
有效的子代理具有四個共同特徵：
- 具體的描述——描述控制子代理何時被啟動，以及它收到什麼指示。撰寫時要同時引導這兩者。
- 結構化輸出——在系統提示中定義輸出格式，讓子代理知道何時完成，並回傳主執行緒可以使用的資訊。
- 障礙回報——在輸出格式中加入一個部分，用於記錄變通方法、特殊狀況和問題，讓主執行緒不必重新發現它們。
- 有限的工具存取權限——只給予子代理實際需要的工具。研究用唯讀、審查者用 bash、只有應該變更程式碼的代理才給予編輯／寫入權限。
這些模式每一個本身都很簡單，但結合在一起，它們能將子代理從一個模糊地試圖提供協助的東西，轉變為一個專注、可預測的工作者，能準時完成並清楚地回報結果。