克勞德代碼子代理在生產中的作用：何時助力，何時致害

每隔幾週，r/ClaudeAI 版塊裡就會有人問同樣的問題：「你的 最好的 實際使用方法 克勞德代碼子代理人回覆總是千篇一律——複製貼上的設定資訊、Anthropic課程的連結、五個名字花俏的專業代理商的截圖。沒人給你看真正重要的部分：一個完整的、真正執行實際工作的子代理工作流程，以及能夠證明其成效的收據。.

這就是這篇文章的目的。我經營一系列基於 Claude Code 的自主業務——你現在閱讀的這個品牌就是其中之一——子代理已經接入整個流程中，在我睡覺的時候負責研究、撰寫和發佈內容。所以，我將以運營者的身份，坦誠地分享：什麼是子代理，哪些配置真正重要，如何調用它們，我自己的技術棧中一個真實的工作流程，以及——大家都忽略的部分—— 當次級代理人悄悄傷害你時 而不是伸出援手。.

不搞花俏的，沒有「效率提升十倍」之類的廢話。只告訴你哪些方法有效，哪些無效，以及如何區分它們。.

Claude Code 子代理程式的真正意義（而不僅僅是更嚴格地提示）

子代理程式是主會話可以產生的一個獨立的 Claude 實例，用於處理特定範圍的任務。可以把它想像成僱用一位專家來完成某項工作：它運行在主會話中。 它自己的上下文窗口, 它有自己的系統提示、自己的工具權限，並且只傳回結果，而不是傳回整個混亂的獲取過程。.

最後那部分才是重點，也是大多數指引都忽略的部分。當你的主代理將「去閱讀這十二個文件，告訴我哪些文件與身份驗證有關」的任務委派給子代理時，子代理就會… 它自己的 上下文讀取全部十二個檔案。你的主會話不會受到這些幹擾。它只會得到簡潔的兩句話回复，從而保持上下文視窗的精簡，以便處理真正需要連續性的工作。.

我找到的最清晰的思維模型：你的主程式就像一個專案經理，辦公桌空間有限。它讀取的所有內容——每個文件、每個搜尋結果、每個相關內容——都會留在桌面上，直到桌面被文件淹沒，專案經理開始忘記自己在做什麼。子程式就像你派去檔案室的同事。他們翻閱文件，只帶回一張便條，你的辦公桌就空了。你並沒有得到一個更聰明的專案經理；你得到的是一個不會被文件淹沒的專案經理。一旦你理解了這一點，你就不會再問“我能創建哪些很棒的子程序”，而是會問“我的辦公桌上有什麼可以派出去的雜物”。”

所以，誠實的說法不是「子代理讓克勞德更聰明」。事實並非如此。子代理和你正在對話的模型是同一個模型。它們改變的是… 代幣去哪了. 你用少量的協調工作量換取了大量的情境管理。對於某些任務來說，這是一筆划算的交易，而對於另一些任務來說，則非常糟糕——這正是我們稍後要重點討論的區別。.

如果你有讀過我的分析… 克勞德·科德真正帶給你的一切, 子代理與斜線命令、鉤子和 MCP 並列，是區分「使用 Claude Code」的人和「不使用 Claude Code」的人的四大關鍵因素之一。 操作 它。.

子代理剖析：真正重要的配置

子代理只是一個帶有 frontmatter 的 Markdown 文件，可以放入其中。 .claude/agents/ （專案級）或 ~/.claude/agents/ （全球範圍）。以下是一個簡化的真實範例：

--- 名稱：doc-scout 描述：唯讀研究員。主動搜尋程式碼庫中的程式碼、設定和命名規範。返回搜尋結果，絕不進行編輯。工具：讀取、Grep、Glob 模型：haiku --- 您是一個只讀搜尋代理。給定一個問題，掃描程式碼庫並返回：(1) 回答該問題的確切檔案和行範圍，(2) 兩句話的摘要。如果摘錄即可，請勿讀取整份文件。請勿提出編輯建議。.

四個欄位幾乎佔據了所有權重，如果這四個欄位出錯，人們就會覺得他們的下屬代理人毫無用處：

• 描述 — 這不是文檔，而是路由訊號。 Claude 會讀取它來決定何時自動委託。模糊的描述（例如“有助於程式碼”）永遠不會被呼叫。請放置觸發器。 在 描述：「在審查差異時，請積極主動地使用。」 「積極主動」一詞確實有助於授權。.
• 工具 ——嚴格篩選。一個只能…的研究子代理 讀, Grep, ， 和 全球 它不可能擅自離開並編輯文件。最小權限原則在這裡不僅僅是安全作秀；它使子代理的行為變得可預測。.
• 模型 — 你不需要 Opus 來搜尋倉庫。用低成本、高吞吐量的子代理處理較小的模型，把昂貴的代理人留給推理任務。這短短一行程式碼就能決定一個管線能否每天運行，以及它是否需要每天運行。.
• 系統提示 — 文件正文。務必明確說明它回傳什麼內容，以及絕對不能做什麼。一個能返回結構清晰、條理分明結果的子代理，勝過十個把一大段文本直接丟回主上下文的子代理。.

兩條組織方面的注意事項，可以避免日後出現麻煩。專案級代理 .claude/agents/ 與程式碼庫一起發布，這樣你的整個團隊（或你的整個容器集群）就會繼承同一份名單——這就是我如何確保十個品牌行為一致的秘訣。全球代理商 ~/.claude/agents/ 它們是你隨身攜帶的個人工具包。當名字衝突時，項目勝出。保持成員名單精簡，並以工作內容而非個人特質命名： doc-scout 和 去重檢測器 告訴 Claude（以及未來的你）何時該伸手去拿它們；「Alfred」和「Jarvis」什麼也不告訴它。.

我經常看到的一個錯誤是：人們編寫了一個功能齊全、提示訊息只有兩行的子代理，然後納悶為什麼它的表現比主會話略差一些。限制條件 是 數值。.

如何呼叫子代理：自動委託與明確調用

子代理程式有兩種使用方式，了解你想要使用哪一種方式會影響你寫設定的方式。.

自動委託 就是克勞德根據自身判斷，決定將任務交給下屬代理人的時候。 描述 字段。你只需正常工作——“審核此分支上的更改”——如果 代碼審查員 如果存在描述匹配的子代理，Claude 就會將其路由到該子代理程式。這在成功時非常神奇，失敗時則令人抓狂，而這完全取決於你的描述是否精準。.

顯式調用 當你給它命名時，例如：「使用 doc-scout 子代理程式尋找我們讀取設定檔的所有位置。」 無需猜測。這樣可以獲得確定性，但代價是需要記住你的成員清單。在實踐中，對於腳本化流程中的任何操作，我傾向於顯式地進行，而讓自動委派來處理互動式的探索性工作。.

沒人提及的細微差別：子代理始於 清晰的上下文 每次都一樣。除非你在呼叫時指定，否則它看不到你的對話記錄。這是為了隔離而做的設計，但如果你以為它“知道我們剛才在聊什麼”，那就成了陷阱。它不知道。就像一個對工作一無所知的承包商走進來一樣，你只需簡單介紹一下——因為它確實如此。.

我自己設定中的一個具體自動委派範例：我從不輸入「查看此內容」。我只需完成更改並說“檢查此分支上的差異”。因為我的 代碼審查員 子代理的描述字面意思是“使用 PROACTIVELY 來檢查當前差異的正確性和重用問題”，Claude 會在沒有被告知的情況下自動路由到它。我運行它的第一周，描述只寫著“檢查代碼”，結果一次都沒觸發過。同樣的子代理，僅僅改了一句話，行為就完全不同了。這就是描述的重要性。.

你也可以並行部署多個子代理程式——一次發送多個委託，它們就能同時運作。這才是真正節省時間的地方，但同時也是協調開銷開始顯現的地方。記住這一點。.

來自我的 JonOps 內容管道的真實 Claude Code 子代理工作流程

這就是搜尋結果頁面 (SERP) 所缺少的部分。所有指南都止步於「這裡列出了五個你可以創建的角色畫像」。沒有人展示一個子代理實際上是如何賺錢的。所以，這裡有一個來自 JonOps（經營該品牌的系統）的真實案例。.

當一篇部落格文章撰寫完成時，編排器（Claude Code 的主會話）並不會獨自完成所有工作。它會將部分工作委託出去：

1. 研究子代理人 （廉價型號，, 讀/Grep（僅限網頁工具）會掃描搜尋引擎結果頁面 (SERP) 和競爭對手頁面，尋找目標關鍵字，並傳回結構化的簡報：涵蓋了哪些內容、缺少哪些內容、平均字數。它會讀取大約 40KB 的競爭對手 Markdown 程式碼，因此主會話無需進行此類操作。.
2. 編曲家 拿到這份簡潔明了的簡報（幾百個字符，而不是 40KB）後，他自己撰寫草稿，因為寫作需要連貫性和聲音，而你不想把這些交給別人。.
3. 去重子代理 在發布任何內容之前，請檢查即時網站是否存在內容被篡改的情況，並傳回一個結果：安全，或這是衝突的 URL。.

證據如下：如果我直接在主會話中執行研究步驟，僅此一項就會消耗 3 萬到 5 萬個主上下文令牌。而將其推送給子代理程式後，主會話的資源佔用將控制在預算之內，並且可以在整個寫入過程中將整個文章結構保存在工作記憶體中。去重檢查在本季上線前就發現了兩篇幾乎重複的文章——每一篇都會分散排名訊號，悄悄地損失流量。這不是演示。這是子代理商在實際網站上防止真實、可衡量的錯誤發生的真實案例。.

注意我做了什麼 不是 委派：實際的寫作工作。這是有意為之，也是關鍵。子代理適用於範圍有限、上下文密集、連續性較低的工作—例如研究、搜尋和驗證。創意主線始終由統籌者掌控。如果您想了解其背後更廣泛的統籌理念，我將在[此處插入連結]中深入探討。 克勞德代碼代理團隊：當多個代理擊敗一個代理時.

如果你更希望建造這樣一條管道的話 為了 你不用自己組裝，這正是我實際做的工作—— 現成的自動化構建 向你的企業輸送子代理系統。.

子代理的弊端：上下文臃腫和協調開銷

這是其他所有指南都忽略的部分，也是最能幫助你避免痛苦的部分。.

子代理並非免費。任何委託都有成本，而教程中卻從未提及：

• 協調成本。. 編排器需要編寫任務簡報、啟動子代理程式、等待，然後解析結果。對於「重新命名這個變數」這樣簡單的任務，這種往返流程消耗的令牌和實際運行時間都比直接執行任務要多。委派一個五秒鐘就能完成的任務純粹是浪費。.
• 結果仍然符合你的實際情況。. 隔離可以保護你免受… 過程, 不是 輸出. 如果你的子代理回傳的是一份 5000 字的冗長文字而不是摘要，那麼你只是轉移了冗餘訊息，並沒有真正消除它。喋喋不休的子代理比沒有子代理更糟糕。.
• 失去了共同的脈絡。. 由於子智能體一開始是冷啟動的，因此緊密耦合的工作（即第二步依賴第一步的推理）會變得笨拙。最終，你需要在邊界上重新解釋狀態，導致許多細節遺漏。.
• 平行運動並不等於碰撞時速度較快。. 衍生十個子代理，每個子代理程式都想編輯相同的文件，你就建立了一個合併衝突產生器。只有當工作真正獨立時，並行處理才能帶來利益。.

給它量化一下，讓交易更具體。假設一個審查子代理程式讀取了一個包含 30 個檔案的差異——這很容易就消耗 4 萬個讀取令牌。如果直接在主上下文中完成，這 4 萬個令牌會一直佔用你的主上下文，直到會話結束，擠佔實際工作時間，並讓你不知不覺地進行你並不想要的壓縮。如果在子代理程式中完成，這 4 萬個令牌只會在子代理程式的視窗中運行；你的主會話只需為返回的約 300 個令牌的判定結果付費。現在反過來：委託「重新命名」操作。 福 到 酒吧”「這需要你花費一次簡報、一次生成、一次等待和一次解析——姑且算上幾百個代幣和幾秒鐘——才能完成一次原本可以瞬間完成的編輯。第一筆交易簡直是白菜價。第二筆交易則是你為擁有子代理這種美觀效果所付出的代價。學會其中的區別，你就已經感受瞭如何正確使用它們。」.

我每天運行這些任務後總結出的經驗法則是：當任務需要執行時，就應該使用子代理。 上下文密集、有界且低連續性 — 大量閱讀、廣泛搜尋、獨立驗證。在工作期間，請將其保留在主會話中。 體積小、耦合性強，或需要佔用線程內存. 當你發現自己把原本只需兩次工具呼叫就能完成的事情委託給了別人時，立刻停止。這顯示你只是盲目地複製了五個下屬，只因為一篇部落格文章建議你僱用五個。.

分代理 vs 代理團隊 vs 單一大代理

三種圖案不斷交織在一起，界線模糊。以下是清晰的劃分：

• 一個大經紀人。. 單一會話即可完成所有操作。最適合具有清晰創意或邏輯主線的緊密耦合工作——例如編寫程式碼、重構模組，以及任何一旦思路中斷就會造成損失的工作。這種模式最容易理解，是預設設置，通常也是正確的選擇。.
• 次級代理商。. 一個主要會議，由代表們主持 範圍限定，隔離 將任務分配給專家，並獲得結構化的結果。這在既要確保上下文一致性又不放棄中央控制時是最佳選擇。統籌者仍然是核心；子代理則是它處理繁瑣、需要高度關注上下文的任務的雙手。.
• 代理團隊。. 多個對等代理人並行處理更大的問題，彼此協調，而不是向單一主管報告。最適合真正可大規模並行化的工作——例如，大規模遷移、同時審查多個維度的重大差異。更高的處理能力，更多的代幣消耗，以及更多出錯的可能性。.

這種發展取決於你願意為多少協調付出代價。單一智能體：無需協調。子智能體：少量協調，但會犧牲一些情境隔離。智能體團隊：大量協調，但能實現真正的平行處理。大多數人應該選擇前兩種方案，只有當問題確實無法歸入單一上下文，也無法透過「老闆加助手」的模式解決時，才應該考慮使用智能體團隊。.

我詳細闡述了多支團隊何時能擊敗單一特工，以及何時只是昂貴的作秀。 代理團隊操作員指南. 如果你還在猶豫要用哪個編碼代理來建構這一切，我的 克勞德法典與法典比較分析 涵蓋平台選擇。一旦您的車隊開始運行，, 用手機運行它 這是順理成章的下一步。.

克勞德代碼子代理常見問題解答

什麼是 Claude Code 子代理程式？

在主會話中產生獨立的 Claude 實例來處理特定範圍的任務。每個實例都在其自身的上下文視窗中運行，擁有自己的提示符、工具和權限，並且只傳回結果——從而保持主會話上下文的整潔。.

如何建立子代理程式？

將包含 frontmatter 的 Markdown 文件拖放到 .claude/agents/ （投影儀 ~/.claude/agents/ （全域）設定 姓名, 一個對路由友好的 描述, 一個有範圍的 工具 列表，可選 模型, 以及體內特定的系統提示。.

次級代理商是免費的嗎？

不——它們像任何克勞德調用一樣消耗代幣。勝利是 在哪裡 這些令牌會被移除：上下文密集型工作會在子代理的視窗中進行，而不是污染你的主會話。對於高吞吐量的子代理，應使用較便宜的模型，以控製成本。.

我可以並行運行多個子代理程式嗎？

是的。一次發送多個委託，它們可以同時運行。但這只有在任務真正獨立的情況下才有效——並行子代理編輯同一文件只會製造衝突。.

次級代理人和代理人團隊有什麼不同？

子代理向一個統籌者匯報，該統籌者負責控制全局。代理團隊是由若干同級代理組成的，它們相互協作，共同解決一個更大的、可並行化的問題。子代理相當於領導和助手；代理團隊相當於一個團隊。先從子代理開始；只有當問題真正需要時，才升級到代理團隊。.

什麼情況下我不應該使用次級代理人？

對於瑣碎的任務（往返成本高於工作量）、需要共享上下文的緊密耦合步驟，以及任何令牌預算緊張且委託實際上無法保存上下文的會話，請跳過它們。.

最後總結：要像工頭一樣使用經銷商，而不是像粉絲一樣。

那些真正從中獲得優勢的人 克勞德代碼子代理人 不是擁有最多代理人的公司，而是那些將任務委託出去的公司。 正確的 把工作——那些規模龐大、界限分明、涉及大量背景資訊的任務——集中起來，把所有連結環節都放在一起。把你的統籌者當作工頭：它負責制定計劃，並派遣專家去完成繁重而獨立的工作。.

先從第一個開始。給一個研究或去重子代理程式寫一個精準的描述，鎖定它的工具，讓它使用一個低成本的模型，然後觀察你的主會話運行得多麼流暢。之後，只有在真正需要的時候才添加下一個子代。這樣，你最終就能得到一個在你睡覺時也能自動運行的流水線，而不是一堆永遠不會被調用的複雜配置。.