Agent Teams(多 Agent 協作)
在 Claude Code 中同時跑多個 agent,各自獨立但共享專案上下文,組成「團隊」分工完成複雜任務。
上線時間
2026/02/05。最多 10 個成員同時運作。
為什麼要有 Teams?
單一 Claude 主執行緒:
- 上下文擠 → 重要規則被擠掉
- 注意力分散 → 同時做設計 + coding + testing → 三件都不專業
- 難以平行 → 等 A 跑完才能跑 B
→ Teams 把工作拆給專職 agent,每個只看相關上下文。
典型團隊組成
Coordinator(你 / 主 Claude)
├── Researcher Agent ← 查資料、讀 code
├── Implementer Agent ← 寫 code
├── Tester Agent ← 跑測試、debug
├── Reviewer Agent ← code review
└── Documenter Agent ← 寫文件
每個 agent 看到的「世界」不同:
- Researcher 看 spec + 既有 code
- Implementer 看 spec + 已有架構
- Tester 看 implementer 寫的 code + 測試框架
跟 Sub-agents 的關係
| Sub-agent | Agent Team | |
|---|---|---|
| 規模 | 1 個任務 1 隻 | 持續運作的「團隊」 |
| 生命週期 | 單次執行完即丟 | 跨多輪對話保留 |
| 共享 | 不共享 | 共享專案根目錄 |
| 協同 | 主 Claude 一一派 | 可以互相溝通 |
比喻:sub-agent 是「外包打工」,team 是「正職員工」。
範例:PAM 大重構團隊
Coordinator:你
Task:「拆出 GradingService」
→ Researcher
「列出所有 CalcGrade / GradeRank 出現位置 + 上下文」
→ Implementer
「依 Researcher 結果,新建 Services/GradingService.cs」
「逐一改 HrController / ReviewController 呼叫」
→ Tester
「跑 ExamSystem.Tests,確認 223 筆全綠」
「跑壓測,確認效能未退化」
→ Documenter
「更新 CLAUDE.md 等第計算章節」
「更新 Docs/dev/ 相關文件」
→ Reviewer(最後一關)
「review 整體變更,確認無 regression」
跟 Tasks 的搭配
TaskList:6 個任務
↓ Coordinator 分派
Researcher 接 Task #1, #2
Implementer 接 Task #3, #4
Tester 接 Task #5
Documenter 接 Task #6
↓ 平行執行
Coordinator 收尾
限制
- 10 成員上限 — 避免協調成本爆炸
- 跨 agent 通訊需明確協議(不是自動的)
- 單機效能瓶頸(10 隻同時跑記憶體吃緊)
該不該用 Teams?
| 情境 | 建議 |
|---|---|
| 改一個 bug | ❌ 主 Claude 自己處理 |
| 加一個小功能 | ❌ Sub-agent 即可 |
| 大重構 / 多模組改動 | ✅ Teams |
| 研究 + 實作 + 文件並行 | ✅ Teams |
| 規律性工作(測試 + 部署) | ✅ Teams + Hooks |
對 Vincent 工作場景
Use Case:PAM 模組大改
任務:把面談流程從 PDF 改 docx + 線上簽核
- Researcher:查現行 PDF 流程 + DocuSign 整合需求
- Implementer:改 InterviewPdfService → 改成 docx + 接 DocuSign
- Tester:跑 18 筆相關測試 + 加新測試
- Documenter:更新 INTERVIEW.md
→ 平行運作 → 1 天完成過去要 1 週的工作。
Use Case:年度結算重構
- Researcher:審視 SettlementService 現有邏輯
- Implementer:拆出年度等第檢查站 + 平衡邏輯
- Tester:跑 36 筆 GradingService 測試
相關概念
強連結(原文明確提及)
- Sub-agent — Teams 的單一成員形態
- Tasks 任務管理 — Team 任務分派
- Channels — 跨 Team 溝通
- Hooks — Team 工作流自動化
← 回到 wiki