跳至主要內容
蒼時弦也
蒼時弦也
資深軟體工程師
發表於

正確使用 Claude Code 的 Agent 功能

你是否看到 Claude Code 的 Sub-Agent 功能就想設計一堆來用？Backend Agent、Frontend Agent 等等，感覺得到更強的工具，但真的需要嗎？

WebConf 2025 期間跟朋友聊到這個話題，才發現大家對 Sub-Agent 的使用時機還是相對陌生。今年有兩場演講提供了不錯的切入點：ihower 大大的 AI Agents 開發 以及 91APP 首席架構師安德魯大大的 從 Service 到 Agent。

用不到是正常

今年 Anthropic 推出訂閱方案可以接近不受限制使用 Claude Code 後，當 Sub-Agent 功能一釋出，很多人瘋狂的設計 Sub-Agent 來使用，像是 Backend Agent、Frontend Agent 等等。但大部分情境真的需要 Sub-Agent 嗎？

實際上，大部分情境是不需要 Sub-Agent 的。在有 Sub-Agent 之前用 Claude Code 輔助開發並沒有什麼問題，不應該多了 Sub-Agent 後就能有極大的改善，這很可能是我們對這個功能的誤解。使用 Sub-Agent 的花費是成倍的，有兩個 Sub-Agent 大致上就會變成兩倍，因為每一個 Agent 都是獨立計算 Token 使用，這也是為什麼花費很容易快速增加的原因。如果額度是照真實方式計費會貴很多，那麼很可能不會選擇這個方式。

也因此，我們需要先搞清楚 Claude Code 的 Sub-Agent 能提供哪幾種類型的應用，因為實務上有非常多種，可以從 ihower 大大的演講中觀察到類型的變化。

WebConf 期間，剛好看到朋友分享 Towards a Science of Scaling Agent Systems 這篇論文，剛好就是測試使用多 Agent 的表現，在某些情境使用反而是會造成退步的

何時該用

一般來說，我只會在兩種情境會選擇使用 Sub-Agent 來處理，一種是蒐集資料的情況，另一種則是適合並行處理的任務，其他情況我都不會刻意去使用。

先從蒐集資料的情境來看，這種類型遇到的問題是 Context Window 上限，假設使用單一 Agent 來蒐集很容易獲得過多雜訊也會超過 Context Window 的限制，因此很適合用 Sub-Agent 來處理，像是 DeepResearch（深入研究）就是很經典的案例。

如果仔細觀察比較新版本的 Claude Code 設計，在「搜尋程式碼」的情況也有機會自動被切換成使用 Sub-Agent 來處理，很明顯的這也是一種蒐集資料的情境，但這類情境會發現 Claude Code 不是用「特定 Sub-Agent」而是使用 Task 這類工具處理。

也因此，另一種情境就是利用 Task 工具並行處理的模式，在 Agent 的運作中流程是線性的，也因此我們如果需要等待每一個動作完成，就會需要花很多時間等待。這個時候利用 Task 工具就可以拆到另一個 Agent 去「專心處理」再把結果回報回來，就能很大的加速過程。

如果仔細看 DeepResearch 的運作，基本上就是這兩個特性所組合而成，而且這種多 Agent 機制就是主從式（Master-Slave）的架構，這也是為什麼會用 Sub-Agent（子代理）來稱呼，因為它提供了主要的 Agent 去管理和總結。

基本上，我們在使用 Claude Code 並且會用到 Sub-Agent 大多是這樣的應用情境，那麼就會比較好判斷下一步該怎麼處理。

例如：想利用 Claude Code 蒐集資料，可以要求分解多個任務，用 Task 工具平行使用 WebSearch 工具蒐集資料，再一次統整，對需要快速查詢大量文件的情境就會很好用

實際應用

雖然我們已經區分出如何使用的情境，但還是有使用 Task 工具跟定義 Sub-Agent 兩種不同的應用方式需要區分，接下來我們可以從一些實際的使用方式來理解。

首先，不要馬上去定義 Sub-Agent 和撰寫 System Prompt 來嘗試解決特定問題，初期一定是先使用 Task 工具開始「觀察」使用狀況。

假設我們想要針對專案蒐集資訊，剛開始應該像這樣

1使用 Task 工具，平行的檢查 `src/modules/` 目錄內容，並且製作一份 `docs/modules.md` 的模組分析報告
2
3- 每一個 `src/modules/*` 下的目錄都是獨立模組，使用一個 Task 個別檢索
4- 文件中每一個模組都要有自己的段落
5- 說明每一個模組的特點，文件第一個段落是模組的通用設計
6  
7請先確認目錄結構，規劃任務後再開始細部的分析

大致上來說，我們可以預期 Claude Code 會先用 ls src/modules/ 之類的命令了解每個模組的大致狀況，在產生多個 Task(...) 來確認，在使用 Task 之前還可能會抽幾個檔案看過。

在這個時候，我們就可以利用 Ctrl + O 觀看細節，用 Ctrl + E 展開 Claude Code 對每個 Task 下的指示，這些就是未來 Sub-Agent 可能的 System Prompt。

下一個階段，就需要分析是否真的需要 Sub-Agent 來使用。

  • 動態產生 Task 已經做得很好，那基本上不用
  • 這個特定任務需要專門的指示

假設 Task 做不太好，而且 Claude Code 也寫不太出來好的指示，那我們才需要走向 Sub-Agent 去做更多細節的客製化。

簡單來說，當我們需要 Sub-Agent 的情境，更多是我們已經有一個需要特定要求、會需要大範圍蒐集資料、任務沒有依賴性的情境。

像是 Frontend Agent、Ruby Agent 這種設計，我認為是很糟的，在 Claude Code 官方的範例，大多是 Code Review Agent 這種形式（專精）而不是有點廣泛的任務定義

我在自己的 Claude Code 中，有一個不太常用的 Rubric Code Analyzer Agent 只在處理舊專案中會使用，這是因為 Rubric 是我對 Claude Code 實作程式碼約束的一種設計，但是舊專案要整理這些規則要找很多原始碼。

那麼，就會需要一個 Sub-Agent 幫我搜尋，而且這些搜尋是有特定規則的。

  • 慣例
  • 模式
  • 最佳實踐
  • 約定

這個 Sub-Agent 必須根據要求，篩選出這些資訊，以慣例來說他可能會發現變數命名都習慣用 snake_case 而不是 camelCase 那就會需要把大部分的原始碼看一遍，然後找出頻率最高的那種做法，其他規則也是類似的。

這個做法基本上就是大量搜尋搭配平行讀取的情境，在大多數時候將蒐集的資訊傳回來後歸納，通常可以整理出還不錯的規則。

在這種類型的情況外，大多不太需要特地使用 Sub-Agent 來處理。

前後端分離看似可以分兩個 Sub-Agent 但太廣泛，而且前後端能力基本上還是靠模型本身的能力，這種時候讓 Claude Code 自己用 Task 分配任務反而比較合理，但你很可能發現他是分解成兩個小功能同時做前後端，而不是一個做前端一個做後端