Delegate noisy investigation to one or more subagents so the orchestrator's context stays clean, then work from the distilled answer. Use this skill whenever answering a question would require reading many files, long logs, large diffs, or wide codebase surveys — i.e. when producing the answer generates far more noise than the answer itself. Use it for "how does X work", "where is Y used", "what's the root cause of Z", "summarize this PR/log" style questions, and reach for it liberally before reading a pile of files inline.
Research
使用此技能來回答問題，方法是將「尋找答案的工作」委派給子代理，這樣該工作的副產物——檔案內容、日誌雜訊、無效的閱讀——永遠不會進入你自己的上下文。你只會得到精煉後的答案以及支持它的證據，並保持專注於實際任務。
為什麼這很重要
你的上下文視窗是你最寶貴且有限的資源。讀取二十個檔案才發現其中三個有用，這會讓十七個檔案的雜訊永久污染你的上下文，降低你後續每個決策的品質。子代理會替你吸收那些雜訊，只把有用的信號交給你。可以想像成請同事去翻閱檔案後回報，而不是把整個檔案庫堆在你的桌上。
何時使用
當「產生答案的成本遠大於答案本身」時，就該考慮使用研究委派。強烈信號包括：
- 你需要讀取許多檔案才能找到少數相關的檔案。
- 你需要瀏覽冗長的測試輸出、CI 日誌或堆疊追蹤來找出失敗原因。
- 你需要調查某個模式、API 或符號在整個程式碼庫中的使用情況。
- 你需要閱讀並總結一個大型差異或 PR。
- 問題包含幾個可以獨立調查的子部分。
範例——適合使用：
- 「這個測試失敗的根本原因是什麼？」（子代理讀取日誌並追蹤程式碼；你得到原因）
- 「
SessionManager在整個程式碼庫中如何使用？」（子代理進行 grep 並閱讀；你得到包含呼叫位置的摘要） - 「總結這個 4000 行的 PR 做了哪些變更以及原因。」（子代理讀取差異；你得到變更的輪廓）
範例——不要委派：
- 讀取你已經知道需要的 2-3 個檔案。直接讀取即可；委派只會增加延遲，卻沒有節省上下文。
- 單一的
grep或一行查詢。自己動手做。 - 任何你需要原始材料來進行下一步的情況。 如果你即將編輯那些你正在讀取的檔案，委派會適得其反——你還是得自己重新讀取才能進行修改。研究委派在輸出是「結論」時才有價值，而不是當它是「你將直接處理的材料」時。
子代理的成本是真實的（延遲和 token），所以判斷標準始終是：我避免的雜訊是否超過了這個成本？
如何執行
單一 vs. 平行
預設使用單一子代理。只有當問題確實可以分解成不需要共享中間發現的獨立子部分時，才平行啟動多個子代理——例如，「認證如何運作」AND「計費如何運作」AND「速率限制器如何運作」是三個可以同時進行的獨立調查。當各部分真正獨立時，平行處理是一項值得使用的能力，因為不同的子代理可以同時調查；但不要將一個連貫的問題強行拆成不自然的小塊。
充分告知子代理
子代理不知道你的意圖，所以請詳細說明。一個好的研究簡報包括：
- 要回答的具體問題。
- 去哪裡找（儲存庫路徑、分支、懷疑的檔案/符號，如果你知道的話）。
- 這是唯讀的——它應該調查並回報，不要修改檔案，除非任務明確要求變更。
- 你希望得到的輸出（見下方）。
要求信號，而非逐字稿
告訴子代理回傳精煉後的答案及其支持證據，而不是原始傾印。具體來說：
- 問題的直接答案。
- 關鍵證據：確切的檔案路徑和符號（例如
src/session.rs:142、fn reconnect），這樣你可以直接跳到重點。 - 任何令人驚訝的地方，或它遇到的注意事項/未知事項。
重點是雜訊留在子代理那邊。如果回報內容過於龐大，可以對同一個子代理發送一個聚焦的後續指令，要求它精簡答案——它保留了上下文，可以低成本地進行調整。
取得答案後
根據精煉後的結果進行工作。如果你後來發現需要底層檔案來進行編輯，那時再直接讀取——現在你已經確切知道哪些檔案重要，所以只需讀取三個檔案，而不是二十個。
