為什麼有了 Sub-Agent，Claude Code 還要做 Agent Teams？

大家好，我係子昕。

上個禮拜我用Claude Code分析一個舊 project，成十幾萬行 code 嗰種。

我叫佢揾支付模組相關嘅邏輯，佢翻咗幾十個 files，揾完之後我發現對話 context 已經塞爆咗。

再問問題嘅時候，回答質素直線下降，有用嘅資訊全部俾搜尋結果淹沒曬。

呢個問題其實一直都存在：AI 嘅 context window 就得咁大，塞太多中間過程入去，後面嘅對話質素一定會跌。

後來我醒起，Claude Code 有兩個專門解決呢個問題嘅功能：Subagent和Agent Teams。

好多人唔知，但用過之後真係返唔到轉頭。

簡單講：

• Subagent（子智能體）：叫Claude派一個「分身」去做嘢，做完攞結果返嚟，你個 main dialogue 保持乾淨
• Agent Teams（智能體團隊）：俾多個子智能體組成團隊，分工合作，適合複雜嘅多模組任務

今日就將呢兩個功能拆開嚟講。

一、Subagent：派個分身去做嘢

解決咩問題

你同Claude緊對話，遇到一個子任務——例如係搜尋 code、審查某個 module、調查一個 bug。

如果叫Claude直接喺而家呢個對話做，所有搜尋過程、中間 files 嘅內容全部堆咗喺 context 度，越講越臃腫。

Subagent 嘅諗法：唔喺 main dialogue 做，派一個獨立嘅子智能體去做。

佢有自己獨立嘅 context，做完嘢將結果俾返 main Claude，main Claude 睇完之後將關鍵資訊總結俾你。你個 main dialogue 由頭到尾都係乾淨嘅。

可以同時派幾個，互唔幹擾。

怎麼用

直接同Claude講就得：

幫我搜索項目中所有支付相關的代碼，不要污染當前對話

或者更直接：

用子智能體幫我做個代碼審查，看看 src/auth/ 目錄有沒有安全隱患

Claude會自動判斷需唔需要派子智能體，自動揀合適嘅類型，自動生成任務描述。你唔需要寫任何參數。

一個容易疑惑嘅地方：子智能體睇唔到你同main Claude之前嘅對話內容，但佢可以 access 你整個 project directory——可以讀 file、搜 code、執行 command。

佢只係唔知你哋傾過啲咩。

Main Claude 派佢出去嘅時候，會自動將必要嘅背景資訊寫入任務描述裏面，所以子智能體收到嘅指令係完整嘅。

如果你好奇Claude內部係點樣 call，係咁樣：

// 這是Claude內部的調用格式，你不需要自己寫
Agent({
  description: "搜索支付代碼",
  subagent_type: "Explore",
  prompt: "搜索項目中所有支付相關的代碼，包括接口定義、回調處理..."
})

段 code 係Claude自己生成同執行嘅。你只需要用自然語言講需求。

70 幾種專業類型

Claude提供咗 70 幾種子智能體類型，常用嘅有幾個：

注意：Explore同Plan唔可以編輯 file，但千祈唔好以為佢哋淨係識讀 code——佢哋可以執行 command、搜網頁、做各種查詢，只係唔可以改你啲 code。

前台同後台

默認前台執行：main Claude 等子智能體完成先繼續。

都可以後台執行：main Claude 唔等，繼續做其他嘢，子智能體完成後會自動通知。適合耗時嘅 codebase 探索。

二、Agent Teams：組團合作

Subagent 係單兵作戰，Agent Teams 係多個子智能體組隊合作。

幾時需要組團

一個子智能體搞得掂嘅任務，用Subagent就得。

但有啲任務自然需要分工。

例如幫 project 加一個功能，牽涉後端接口、前端 component、測試 cases，三個方向可以並行，但之間又有依賴關係（前端要等後端接口出咗先可以對接）。

呢種任務拆俾一個子智能體效率太低，組團先合理。

怎麼用

最簡單嘅方式，直接描述你嘅需求：

創建一個Agent團隊，扮演不同的角色來閲讀這篇文章，反饋閲讀後的感受，給到編輯者Agent，彙總反饋修改文章。調整後繼續通知其他人閲讀，反覆幾輪，給我最終結果。

Claude會自動處理所有協調工作：建立團隊、拆分任務、設定依賴關係、派出合適類型嘅子智能體、協調佢哋之間嘅配合。

全部完成之後，匯總結果話俾你知。

你都可以更仔細咁控制，手動指定點樣拆任務、用咩類型嘅子智能體。

但大多數情況下，叫Claude自動處理就夠。

背後發生咗啲咩

雖然你唔需要操心呢啲，但瞭解嚇有助於理解佢嘅工作方式：

1. Main Claude 建立團隊，設定任務列表同依賴關係
2. 每個子智能體睇任務列表，揾到冇被阻塞嘅任務，認領並開始工作
3. 完成後標記任務完成。Main Claude 作為「項目經理」收到通知，協調後續——例如發現前端任務嘅依賴已解除，就安排前端子智能體開始
4. 子智能體之間都可以直接通訊，例如後端完成後將接口細節傳俾前端
5. 全部任務完成後，main Claude 執行團隊關閉同資源清理

成個過程中，Main Claude 扮演項目經理嘅角色——分配任務、協調進度、傳遞資訊。你作為用戶，只需要描述需求，然後等結果。

如果中途遇到需要你做決定嘅問題，Claude會問你。

一個具體嘅例子

你話：「幫 project 加用戶頭像上載功能」

Claude可能會咁樣拆：

任務1：實現後端上傳接口（POST /api/upload）
任務2：實現前端上傳組件（依賴任務1完成）
任務3：編寫測試（依賴任務1和2完成）

然後派出三個子智能體：

• backend-dev（後端架構師類型）→ 認領任務1，開始做嘢
• frontend-dev（前端開發類型）→ 等任務1完成後，main Claude 協調佢開始任務2，同時將接口地址同參數格式傳過去
• tester（測試自動化類型）→ 等任務1同2都完成後認領任務3

全部完成後，main Claude 匯總所有改動話俾你知。

三、踩坑實錄

坑1：以為要自己寫子智能體嘅 prompt

啱啱接觸 Subagent 嘅時候，我見到文檔入面有 description、prompt、subagent_type 呢啲參數，以為要自己精心設計調用參數。

花咗半個鐘研究點樣寫好 prompt。

後來發現完全唔使。你就同Claude正常講嘢，「幫我揾嚇支付相關嘅 code」，Claude自動決定用咩類型嘅子智能體、自動生成詳細嘅 prompt。

嗰半個鐘白費咗。

當然，如果子智能體嘅 output 唔夠理想，你可以俾多啲背景資訊 Claude，等佢生成更精準嘅 prompt。

但你唔需要自己去寫Agent({...})呢種 call。

坑2：見到Idle以為死咗

第一次用 Agent Teams，見到子智能體狀態變咗「Idle」，心諗大鑊，係咪出 bug。查咗好耐。

結果 Idle 就係「做曬嘢，等緊新任務」。完全正常。

Main Claude 會喺需要嘅時候分配新任務或者 send message 叫醒佢。

坑3：叫唯讀嘅子智能體去改 code

有次我想叫子智能體重構一段 code，Claude自動揀咗 Explore 類型。結果佢分析得頭頭是道，就係唔改——因為 Explore 係唯讀，唔可以編輯 file。

後來搞清楚了：需要改 code 嘅任務，要用有寫入權限嘅類型，例如 debugger、frontend-developer 呢啲。

而家如果我明確需要子智能體改 code，會喺需求入面提一句，Claude就會揀啱類型。

四、幾時用，點樣揀

我嘅策略：

• 改一個 function、修一個明確嘅 bug → 直接叫Claude做，唔需要子智能體
• 搜尋 code、分析 module、code 審查 → Subagent，保持 main dialogue 乾淨
• 多模組協作嘅複雜任務 → Agent Teams

一個簡單嘅判斷標準：

如果任務會產生大量中間過程，而你只關心最終結果——用Subagent。

如果牽涉多個有依賴關係嘅子任務——用Agent Teams。

五、用咗一段時間嘅真實感受

Context 隔離係最大價值

呢個唔係錦上添花，係實實在在解決痛點。

以前叫Claude分析大 project，對話越講越亂，回答質素肉眼可見咁跌。

而家搜尋類嘅嘢全部掉曬俾 Subagent，main dialogue 永遠聚焦喺有用資訊度，體驗完全唔同。

Agent Teams 適合有一定規模嘅任務

幾個 files 嘅小 project 用唔著，但一旦牽涉多個 module 嘅改動，團隊合作確實可以幫你管理起複雜任務。

學習成本幾乎係零

你唔需要記 TaskCreate、SendMessage 呢啲——呢啲係底層機制，Claude自己用嘅。你只需要用自然語言講需求，Claude嚟決定要唔要組團、點樣分工。

角色喺變

用咗Agent之後，我發現自己更加似項目經理——描述需求、確認方案、驗收結果。

Code 係AI寫嘅，但方向係我控制嘅。呢種感覺幾得意。

六、底層原理（有興趣可以睇嚇）

如果你好奇 Agent Teams 底層係點樣運作，呢部分簡單講講。冇興趣可以直接 skip。

Agent Teams 嘅所有狀態管理，底層就係讀寫本地 JSON files。冇 database，冇 remote API。

~/.claude/
├── teams/
│   └── add-feature/
│       └── config.json        # 團隊配置：成員列表
│
└── tasks/
    └── add-feature/
        ├── 1.json             # 任務1
        ├── 2.json             # 任務2
        └── 3.json             # 任務3

一個 task file 係咁樣：

{
  "id": "1",
  "subject": "實現後端上傳接口",
  "status": "in_progress",
  "owner": "backend-dev",
  "blockedBy": []
}

Task 狀態得幾種：pending（等待）→ in_progress（進行中）→ completed（已完成）。

子智能體認領任務改狀態，完成咗再改狀態。

有依賴嘅任務會等前置任務完成咗先可以俾人認領。

你可以直接喺 terminal 睇進度：

cat ~/.claude/teams/add-feature/config.json   # 看團隊成員
cat ~/.claude/tasks/add-feature/1.json         # 看任務狀態

講真，第一次理解呢個設計時我呆咗一呆。

複雜嘅多智能體協作，底層就係讀寫幾個JSON files？

但諗深一層真係合理——透明、簡單、唔會斷線超時，出問題直接睇 file 甚至手改 JSON 就可以 fix。有時最簡單嘅方案就係最好嘅方案。

你平時叫AI幫你做嘢，最頭痛係咪 context 越講越亂？試嚇Subagent，可能會有驚喜。

畀個關注啦，我會繼續用我半桶水嘅水平為大家帶嚟更多AI編程工具嘅第一手體驗～

「讚好、轉發、睇緊」
同大家一齊睇

大家好，我是子昕。

上週我用Claude Code分析一個老項目，十幾萬行代碼那種。

我讓它搜支付模塊相關的邏輯，它翻了幾十個文件，搜完之後我發現對話上下文已經被撐滿了。

後面再問問題，回答質量直線下降，有效信息全被搜索結果淹沒了。

這個問題其實一直存在：AI的上下文窗口就那麼大，塞太多中間過程進去，後面的對話質量必然下降。

後來我反應過來，Claude Code有兩個專門解決這個問題的功能：Subagent和Agent Teams。

很多人不知道，但用過之後真的回不去了。

簡單說：

• Subagent（子智能體）：讓Claude派一個“分身”去幹活，幹完把結果帶回來，你的主對話保持乾淨
• Agent Teams（智能體團隊）：讓多個子智能體組成團隊，分工協作，適合複雜的多模塊任務

今天把這兩個功能掰開了講。

一、Subagent：派個分身去幹活

解決什麼問題

你在和Claude對話，遇到一個子任務——比如搜索代碼、審查某個模塊、調查一個bug。

如果讓Claude直接在當前對話裏做，所有搜索過程、中間文件內容全堆在上下文裏，越聊越臃腫。

Subagent的思路：不在主對話裏做，派一個獨立的子智能體去做。

它有自己獨立的上下文，幹完活把結果返回給主Claude，主Claude看完之後把關鍵信息總結給你。你的主對話從頭到尾是乾淨的。

可以同時派多個，互不干擾。

怎麼用

直接跟Claude說就行：

幫我搜索項目中所有支付相關的代碼，不要污染當前對話

或者更直接：

用子智能體幫我做個代碼審查，看看 src/auth/ 目錄有沒有安全隱患

Claude會自動判斷需不需要派子智能體，自動選擇合適的類型，自動生成任務描述。你不需要寫任何參數。

一個容易疑惑的點：子智能體看不到你和主Claude之前的對話內容，但它能訪問你的整個項目目錄——能讀文件、搜代碼、執行命令。

它只是不知道你們聊過什麼。

主Claude在派它出去的時候，會自動把必要的背景信息寫進任務描述裏，所以子智能體拿到的指令是完整的。

如果你好奇Claude內部是怎麼調用的，長這樣：

// 這是Claude內部的調用格式，你不需要自己寫
Agent({
  description: "搜索支付代碼",
  subagent_type: "Explore",
  prompt: "搜索項目中所有支付相關的代碼，包括接口定義、回調處理..."
})

這段代碼是Claude自己生成和執行的。你只管用自然語言說需求。

70多種專業類型

Claude提供了70多種子智能體類型，常用的幾個：

注意：Explore和Plan不能編輯文件，但別以為它們只會讀代碼——它們能執行命令、搜網頁、做各種查詢，只是不能改你的代碼。

前台和後台

默認前台運行：主Claude等子智能體完成後才繼續。

也可以後台運行：主Claude不等，繼續做別的事，子智能體完成後自動通知。適合耗時的代碼庫探索。

二、Agent Teams：組團協作

Subagent是單兵作戰，Agent Teams是多個子智能體組隊協作。

什麼時候需要組團

一個子智能體能搞定的事，用Subagent就行。

但有些任務天然需要分工。

比如給項目加一個功能，涉及後端接口、前端組件、測試用例，三個方向可以並行，但之間又有依賴關係（前端得等後端接口出來才能對接）。

這種任務拆給一個子智能體效率太低，組團才合理。

怎麼用

最簡單的方式，直接描述你的需求：

創建一個Agent團隊，扮演不同的角色來閲讀這篇文章，反饋閲讀後的感受，給到編輯者Agent，彙總反饋修改文章。調整後繼續通知其他人閲讀，反覆幾輪，給我最終結果。

Claude會自動處理所有協調工作：創建團隊、拆分任務、設置依賴關係、派出合適類型的子智能體、協調它們之間的配合。

全部完成後，彙總結果告訴你。

你也可以更細緻地控制，手動指定怎麼拆任務、用什麼類型的子智能體。

但大多數情況下，讓Claude自動處理就夠了。

背後發生了什麼

雖然你不需要操心這些，但瞭解一下有助於理解它的工作方式：

1. 主Claude創建團隊，設定任務列表和依賴關係
2. 每個子智能體查看任務列表，找到沒有被阻塞的任務，領取並開始工作
3. 完成後標記任務完成。主Claude作為“項目經理”收到通知，協調後續——比如發現前端任務的依賴已解除，就安排前端子智能體開始
4. 子智能體之間也可以直接通信，比如後端完成後把接口細節傳給前端
5. 全部任務完成後，主Claude執行團隊關閉和資源清理

整個過程中，主Claude扮演項目經理的角色——分配任務、協調進度、傳遞信息。你作為用戶，只需要描述需求，然後等結果。

如果中間遇到需要你決策的問題，Claude會來問你。

一個具體的例子

你說：「給項目添加用戶頭像上傳功能」

Claude可能會這樣拆：

任務1：實現後端上傳接口（POST /api/upload）
任務2：實現前端上傳組件（依賴任務1完成）
任務3：編寫測試（依賴任務1和2完成）

然後派出三個子智能體：

• backend-dev（後端架構師類型）→ 領取任務1，開始幹活
• frontend-dev（前端開發類型）→ 等任務1完成後，主Claude協調它開始任務2，同時把接口地址和參數格式傳過去
• tester（測試自動化類型）→ 等任務1和2都完成後領取任務3

全部完成後，主Claude彙總所有改動告訴你。

三、踩坑實錄

坑1：以為要自己寫子智能體的prompt

剛接觸Subagent的時候，我看到文檔裏有description、prompt、subagent_type這些參數，以為得自己精心設計調用參數。

花了半小時研究怎麼寫出好的prompt。

後來發現完全不用。你就跟Claude正常說話，“幫我搜一下支付相關的代碼”，Claude自動決定用什麼類型的子智能體、自動生成詳細的prompt。

那半小時白花了。

當然，如果子智能體的輸出不夠理想，你可以給Claude更多背景信息，讓它生成更精準的prompt。

但你不需要自己去寫Agent({...})這種調用。

坑2：看到Idle以為掛了

第一次用Agent Teams，看到子智能體狀態變成了“Idle”，心想壞了，是不是出bug了。查了半天。

結果Idle就是“活兒幹完了，在等新任務”。完全正常。

主Claude會在需要的時候給它分配新任務或者發消息喚醒它。

坑3：讓只讀的子智能體去改代碼

有一次我想讓子智能體重構一段代碼，Claude自動選了Explore類型。結果它分析得頭頭是道，就是不改——因為Explore是隻讀的，不能編輯文件。

後來弄明白了：需要改代碼的任務，得用有寫入權限的類型，比如debugger、frontend-developer這些。

現在我如果明確需要子智能體改代碼，會在需求裏提一嘴，Claude就會選對類型。

四、什麼時候用，怎麼選

我的策略：

• 改一個函數、修一個明確的bug → 直接讓Claude做，不需要子智能體
• 搜索代碼、分析模塊、代碼審查 → Subagent，保持主對話乾淨
• 多模塊協作的複雜任務 → Agent Teams

一個簡單的判斷標準：

如果任務會產生大量中間過程，而你只關心最終結果——用Subagent。

如果涉及多個有依賴關係的子任務——用Agent Teams。

五、用了一段時間的真實感受

上下文隔離是最大價值

這不是錦上添花，是實打實解決痛點。

以前讓Claude分析大項目，對話越聊越亂，回答質量肉眼可見地下降。

現在搜索類的活兒全扔給Subagent，主對話始終聚焦在有效信息上，體驗完全不一樣。

Agent Teams適合有一定規模的任務

幾個文件的小項目用不上，但一旦涉及多個模塊的改動，團隊協作確實能幫你把複雜任務管理起來。

學習成本幾乎為零

你不需要記什麼TaskCreate、SendMessage——這些是底層機制，Claude自己用的。你只管用自然語言說需求，Claude來決定要不要組團、怎麼分工。

角色在變

用了Agent之後，我發現自己更像項目經理了——描述需求、確認方案、驗收結果。

代碼是AI寫的，但方向是我把控的。這種感覺挺奇妙的。

六、底層原理（感興趣可以看看）

如果你好奇Agent Teams底層是怎麼運作的，這部分簡單聊聊。不感興趣的直接跳過。

Agent Teams的所有狀態管理，底層就是讀寫本地JSON文件。沒有數據庫，沒有遠程API。

~/.claude/
├── teams/
│   └── add-feature/
│       └── config.json        # 團隊配置：成員列表
│
└── tasks/
    └── add-feature/
        ├── 1.json             # 任務1
        ├── 2.json             # 任務2
        └── 3.json             # 任務3

一個任務文件長這樣：

{
  "id": "1",
  "subject": "實現後端上傳接口",
  "status": "in_progress",
  "owner": "backend-dev",
  "blockedBy": []
}

任務狀態就幾種：pending（等待）→ in_progress（進行中）→ completed（已完成）。

子智能體領取任務改狀態，完成了再改狀態。

有依賴的任務會等前置任務完成後才能被領取。

你可以直接在終端查看進度：

cat ~/.claude/teams/add-feature/config.json   # 看團隊成員
cat ~/.claude/tasks/add-feature/1.json         # 看任務狀態

說實話，第一次理解這個設計時我愣了一下。

複雜的多智能體協作，底層就是讀寫幾個JSON文件？

但仔細想想真的合理——透明、簡單、不會斷連超時，出問題直接看文件甚至手動改JSON就能修。有時候最簡單的方案就是最好的方案。

你平時讓AI幫你幹活，最頭疼的是不是上下文越聊越亂？試試Subagent，可能會有驚喜。

點個關注唄，我會繼續用我這半吊子水平為大家帶來更多AI編程工具的第一手體驗～

「點贊、轉發、在看」
和大家一起看