分代理（通常寫為 子代理 or 分代理) 是代理開發者工具中最明顯的實用進步之一：它們讓你在內部組建一個由專業 AI 助理組成的小團隊 克勞德·科德每個代理程式都有各自的角色、工具和上下文視窗。這個想法簡單卻強大——與其讓一個通用模型包攬所有工作，不如定義一些緊湊的、單一用途的代理，由主協調器將工作委託給它們（自動執行或在您明確請求時執行）。這改變了您管理上下文、工具以及複雜工作流程的成本/延遲權衡的方式。
什麼是子代理？
簡短的定義。 子代理程式是一種預先配置的、特定於任務的 AI“個性”，Claude Code 可以將任務委託給它。每個子代理都有自己的系統提示字元、獨立的上下文視窗、明確授予的工具以及可選的模型選擇。子代理程式可以在專案或使用者層級創建，並由 Claude 自動呼叫或由使用者明確調用。
子代理的關鍵屬性
- 專門用途和系統提示。 您可以在系統提示中描述子代理程式的角色、限制和方法，以便它在其狹窄的領域內表現出可預測的行為（例如， 程式碼審閱者, 調試器, 數據科學家).
- 隔離上下文視窗。 每個子代理程式都保存著各自的對話歷史記錄和上下文，防止主執行緒的上下文被底層細節所污染。這對於擴展工作流程至關重要，否則單一對話的上下文資訊就會被耗盡。
- 工具範圍和權限。 您可以授權或限制子代理程式可以使用哪些內部工具或外部模型上下文協定 (MCP) 工具。這是一項至關重要的安全和治理功能。
- 配置為代碼。 子代理定義為具有 YAML 前置內容（名稱、描述、工具、模型）的 Markdown 文件，並儲存在專案層級（
.claude/agents/) 或使用者等級 (~/.claude/agents/）。項目定義優先。
什麼是自動委託和顯式調用
克勞德·科德可以 自動 當您的提示或子代理 description 配對任務 — 或者你可以 明確地 請求代理（例如， > Use the code-reviewer subagent to check my recent changes)。使 description 行動導向（"Use PROACTIVELY", "MUST BE USED") 推動自動委派，在 Claude Code 中使用子代理程式的兩種互補方法：
- 自動委派 — Claude 檢查請求並主動將符合的工作委派給子代理程式。
- 顯式調用 — 您在提示/命令中按名稱呼叫子代理程式（例如，
Use the code-reviewer subagent to check my changes).
這兩種方法在使用者體驗和工程方面都有不同的權衡。下面我將分別進行分析。
自動委派
它在用戶眼中看起來如何。 您發出一個高級命令（例如，「為這個新圖書館準備安全審計」），Claude 會根據以下情況偵測到一個或多個子代理程式是適當的： description 字段。如果配置為主動使用，子代理程式將自動調度並以結構化輸出的形式傳回結果。
為什麼團隊要使用它。
- 它降低了認知負荷——您不需要記住或輸入每個子代理的名稱。
- 它為共享工作流程創造了更順暢的入職培訓，其中特定任務應始終由同一位專家處理。
警告。
- 你必須設計
description並故意提示系統，以便克勞德可靠地選擇正確的子代理。 - 如果許多子代理啟動執行類似的任務，過度熱切的委派可能會增加令牌的使用和噪音；請保守地設計您的描述。
顯式調用
它在用戶眼中看起來如何。 您明確調用子代理： > Use the test-runner subagent to run the project tests. 編排是確定性的：Claude 使用其預先配置的權限和提示來呼叫該命名子代理程式。
為什麼團隊要使用它。
- 完全控制：您可以準確決定要運行哪個專家，從而簡化調試和可重複性。
- 更容易推斷 CI 或自動化腳本中的成本和工具存取。
警告。
- 更多的打字和紀律：開發人員或自動化必須知道正確的子代理名稱。
- 機會主義程度較低：您會失去一些便利，因為主代理會自動偵測到好的子代理程式。
子代理的工作原理—技術概述
下面是一個實用的、面向實作的視圖，用於了解建立和使用子代理程式時發生的情況。
定義子代理程式（配置為程式碼）
子代理程式是一個有 YAML 前置內容的 Markdown 檔案。重要字段包括：
name— 唯一的小寫 ID（帶連字號）description— 用於自動委託配對的自然語言描述tools— 可選的允許工具逗號清單（或省略以繼承所有工具）model— 可選別名（sonnet,opus,haiku）或inherit使用主對話模型
一個小例子（概念性的，不是來自文件的逐字記錄）：
---
name: code-reviewer
description: Expert code reviewer. Proactively reviews code for quality, security, and maintainability.
tools: Read, Grep, Bash
model: inherit
---
You are a senior code reviewer. Focus on security, correctness, and maintainability.
這些文件位於 .claude/agents/ （項目範圍）或 ~/.claude/agents/ （用戶範圍）。專案文件優先，這使得共用和版本控制子代理變得簡單。
模型選擇和工具
- 模型欄位： 您可以為子代理程式選擇特定的模型別名，或讓它繼承主對話的模型。這樣您就可以在成本/品質之間進行權衡（例如，對於大型資料掃描子代理程式使用更便宜的模型，而對於最終的綜合使用更高品質的模型）。
- 工具範圍： 為每個子代理程式提供一套精簡的工具集，可以縮小影響範圍並簡化安全推理。工具包括標準的 Claude Code 原語（Read、Grep、Bash、Edit 等）以及 MCP 提供的整合。
運行時行為和上下文處理
當 Claude 委託子代理程式時，該子代理程式將會收到：
- 其係統提示（YAML/Markdown 內容）。
- 僅它需要的上下文（它自己的上下文視窗）。
- 工具存取在其配置中允許。
由於每個子代理都保留一個獨立的上下文，因此可以將長時間的調查或大型文件分析分解為許多小的上下文，而不是強制一個單一的上下文包含所有內容 - 這對於可靠性和可解釋性來說都是一個重大勝利。
子代理程式的架構模式
最常見的架構是 編排器 （主代理）分解高階任務，啟動多個子代理，然後合成或驗證它們的輸出。目前有兩種典型模式：
1）協調者+專家
一名代理人（ 編排器) 可以並行或序列地協調多個子代理程式。協調器決定調用哪個專家，匯總輸出，驗證一致性，並執行最終整合。這是常見的「經理委託給團隊成員」方法，並且與 Claude Code 資料中的許多範例和推薦設計相符。其優點包括並行性、更清晰的關注點分離以及更容易的錯誤控制（有缺陷的子代理僅影響其自身範圍）。
何時使用它： 具有獨立子問題的複雜任務（例如，“生成測試”，“運行靜態分析”，“重寫模組”，然後“整合並運行端到端測試”）。
權衡： 編排邏輯可能會變得複雜；額外的往返可能會稍微增加延遲。
2）管道/鍊式專家
在這裡，子代理按順序排列，其中一個子代理的輸出成為下一個子代理的輸入（例如，規範 → 腳手架 → 實現 → 測試 → 最佳化）。這本質上是以代理形式表達的函數組合——當你需要逐步轉換並嚴格確保資料在各個階段之間的流動方式時，這種方法非常方便。對於線性工作流程來說，它在概念上更簡單，有時也更容易除錯。
何時使用它： 確定性的多步驟轉換（例如，將設計文件轉換為腳手架程式碼，然後進行測試，然後進行最佳化）。
權衡： 對於需要廣泛探索（研究、腦力激盪）的任務來說，這不太自然，並且單一斷開的連結可能會阻礙整個流程。
子代理與單純基於角色的提示有何不同？
1）單獨的上下文視窗
每個子代理程式都有自己的上下文緩衝區，用於儲存與其角色相關的交換、檔案和元資料。這可以防止主會話的上下文被嘈雜的中間訊息污染，也意味著您可以保留（或限制）每個功能的歷史記錄。 Claude Code 就是這樣讓您為特定任務保留長期有效的高訊號上下文的，而無需支付令牌成本或將所有內容塞進一個提示的認知開銷。
2）系統提示和角色
子代理程式的建立需要係統級指令，這些指令定義了子代理程式的角色、語氣和約束（例如，「僅充當重構專家；不執行 Shell 命令」或「以 Pytest 風格產生單元測試；僅使用公共介面」）。這些指令類似於子代理的職責描述，並由 Claude Code 的運行時強制執行。
3）工具綁定和權限範圍
一個關鍵的實際區別是：子代理可以被授予或拒絕存取特定工具——檔案系統、進程執行、外部 API 或特權資料集。這使得子代理能夠 最低權限 設計：可以阻止文件產生器執行任意命令，同時為 CI 子代理程式授予隔離的沙盒。許多社群貼文建議將子代理與模型上下文協定 (MCP) 或基於鉤子的 MCP 伺服器配對，以管理對機密和 I/O 的安全存取。
4）模型選擇與性價比權衡
由於子代理程式是模組化的，您可以根據任務複雜度分配不同的底層模型。對於深度推理，可以使用高效能 Sonnet 模型；對於快速重複的任務，可以使用輕量級 Haiku 模型。這種異質部署有助於平衡延遲、令牌成本和效能。 Anthropic 的產品更新和社群文章強調並行部署小型模型，以實現經濟高效的擴展。
5）溝通模式
子代理程式透過結構化訊息或文件與協調器（或彼此）進行通訊。典型的模式包括：
- 傳回結構化的 JSON 負載（適合程式化編排），
- 寫入共享工作區中的作用域文件，
- 或將包含置信度分數和理由的最終格式化訊息傳回協調器。
社區實驗表明，團隊更喜歡明確的、機器可讀的交接，以避免歧義。
性能優勢
子代理不僅僅是一種設計上的巧妙——如果使用得當，它們還能帶來實際的性能和品質優勢。
1）透過並行減少時鐘時間
透過同時調度多個工作執行緒（例如，每個儲存庫資料夾、每個微服務或每個資料區塊一個工作執行緒），編排器可以減少完成大型複合任務所需的時間。分類錯誤報告、為多個模組產生文件或審核多個服務等用例非常適合。當工作負載真正可並行化時，開發人員工作流程的速度將會顯著提升。
透過為每個角色賦予各自的上下文，您可以避免快速膨脹，並降低不相關的歷史噪音引起的幻覺風險。這意味著更少的上下文相關故障，以及更一致的特定任務輸出。社群文章和 Anthropic 本身的研究表明，在廣度優先任務上，多智能體架構通常優於單體智能體。 Anthropic 的一項內部評估報告顯示，使用主智能體 + 子智能體架構，研究型任務的效能顯著提升。
警告：當子任務獨立時，並行效能帶來最佳效益。如果工作進程必須持續相互等待或共享繁重的狀態，則收益會遞減。
2）更好的上下文利用率和更低的令牌浪費
工作器不再將所有中間搜尋結果塞進單一全域上下文中，而是只保留自身視窗內的相關內容，並傳回精簡的輸出。這減少了協調器的令牌消耗，並降低了達到上下文限制的風險——當您處理大型程式碼庫、長日誌或大型文件儲存庫時，這非常實用。 SDK 的壓縮/匯總功能進一步擴展了長期運行代理的有效記憶體。
3）提高專家提示的準確性
建構為窄域專家的子代理程式可以透過其係統提示和工具集進行調整，以優化其領域內的精確度：安全檢查、程式碼風格或合規性提取。窄域提示往往會減少幻覺，因為代理的允許操作空間和預期輸出受到限制。組織報告稱，當使用特定領域的子代理程式而不是讓通才包辦所有事情時，自動程式碼審查等任務的輸出品質更高。
團隊實際如何使用子代理程式－範例工作流程
下面是具體的例子，以使其不那麼抽象。
範例 A — 重構管道（協調器 + 專家）
- Orchestrator 收到「重構元件 X」請求。
- Orchestrator 調用
analysis-subagent（無寫入權限）來識別複雜性熱點和風險依賴關係。 - Orchestrator 調用
refactor-subagent（將權限寫入類似分支的沙箱）以產生重構檔案。 - Orchestrator 調用
test-gen-subagent（程式碼唯讀）來產生單元測試。 - Orchestrator 運行 CI
ci-runner-subagent（沙盒執行）並彙總結果以供人工審核。
這種模式隔離了每個階段，控制了風險，並保持了審計追蹤的整潔。
範例 B — 研究 + 原型（管道）
literature-subagent抓取並總結參考文獻（無文件寫入，受監管的網路存取）。prototype-subagent從摘要中建構出最小的 PoC。benchmark-subagent在沙箱中執行微基準測試並報告結果。
此鏈條強化了研究任務的連續性，同時保持了明確的責任。
最佳實踐和模式
設計與配置
- 從小而狹窄的角色開始。 讓每個子代理負責一項明確的工作。職責明確會讓調試變得更容易。
- 版本控制你的
.claude/agents/文件夾中。 將子代理定義視為代碼—審查、測試和 PIN 版本。這可以減少偏差並簡化審計。 - 有意固定工具和模型。 使用
model: inherit當您希望與主對話保持一致的行為時，請為背景掃描指定一個成本較低的模型別名。鎖定工具以最小化攻擊面。
操作模式
- 使用顯式呼叫實現確定性自動化。 如果您正在執行 CI 作業或掛鉤，請呼叫特定的子代理程式以確保可預測的結果。
- 在互動式會話中使用自動委派。 對於探索性工作，讓 Claude 選擇子代理來降低摩擦——但要
description字段經過深思熟慮，因此自動化不會意外觸發。 - 設計用於合成的結構化輸出。 強制子代理寫入檔案或產生協調器可以讀取的 JSON；這簡化了減少步驟和稽核。
測試、監控和治理
- 建立代表性評估。 追蹤子代理程式的故障位置，並建立針對這些故障模式的測試。 Anthropic 建議使用代表性測試集並進行迭代改進。
- 監控令牌和工具的使用情況。 偵測每個子代理程式的使用情況並新增警報以偵測失控成本或速率限制條件。
何時不使用子代理
子代理功能強大，但並不總是合適的工具。
- 簡單任務： 對於簡短的、一次性的提示或簡單的轉換，子代理程式會增加不必要的複雜性。
- 嚴格的延遲限制： 編排往返會增加開銷；如果您需要單輪、極低延遲的反應，那麼單片方法可能更簡單。
- 小型團隊，基礎設施較少： 如果沒有用於機密、可觀察性和沙盒的工具，子代理商可能會增加營運風險。社群文章強調，應從小處著手，並在需要模組化時加入子代理程式。
哪些地方最推薦使用Claude Code CLI
很高興地宣布 CometAPI 現在完全支援強大的 Claude Code cli。 您只需安裝Claude Code並使用取得的Comet API金鑰和基底位址進行驗證，即可在Claude Code上使用Comet API模型。
為什麼要透過 CometAPI 使用 claude 程式碼？
頂級人工智慧功能：使用專為開發人員構建的模型輕鬆生成、調試和優化程式碼。
- 靈活的模型選擇：我們全面的模型系列使您能夠更無縫地進行開發。
- 無縫整合：API 始終可用。只需幾分鐘即可將 Claude Code 直接整合到您現有的工作流程中。
- 透過 CometAPI 使用 Claude 程式碼將節省更多成本CometAPI提供的Claude API比官方價格優惠20%，並由官方更新最新型號。
準備好使用 Claude Code cli 了嗎？請諮詢 API指南 有關詳細說明。
如果您想了解更多有關 AI 的提示、指南和新聞，請關注我們 VK, X 不和!
參見 如何透過 CometAPI 安裝和運行 Claude 程式碼？
結論—為什麼子代理現在很重要
子代理程式使代理式工作流程的承諾對團隊切實可行：它們讓您能夠明確地將角色、權限、上下文、成本和並行化視為一等公民物件。如果使用得當，子代理可以提高開發速度、提高多步驟任務的品質以及更可預測的治理。另一方面，您必須像生產軟體一樣設計、測試和監控這些子代理程式——但這項投資可以將快速的工程轉化為可靠的工程實踐。
