什麼是 Claude Code Agent Teams？

如果你已經在用 Claude Code（Anthropic 的 CLI 開發工具），你大概已經體驗過讓 AI 幫你寫程式、Debug、重構的威力。但你有沒有想過：如果同時開好幾個 AI Agent，讓它們像真正的開發團隊一樣分工合作，會發生什麼事？

Claude Code Agent Teams 就是這個概念的實現。它允許你在一個專案中同時啟動多個 Claude Agent 實例，每個 Agent 可以被分配不同的角色和任務，然後在各自的 worktree（Git 工作樹）中平行開發。這不是什麼未來概念——在 Claude Opus 4.6 版本中，這已經是一個可用的功能了。

我個人從 2026 年初開始在實際專案中使用 Agent Teams，坦白講，第一次看到三個 AI 同時在幫我寫不同模組的程式碼時，那個感覺很超現實。但用了幾個月之後，我可以很確定地說：對於某些特定類型的開發任務，多 Agent 協作的效率提升是非常明顯的。

Agent Teams 的架構與運作原理

Agent Teams 的核心架構其實很直覺。你有一個主 Agent（Orchestrator），負責理解整體任務、拆分子任務、分配工作。然後你可以啟動多個子 Agent（Worker），每個 Worker 在自己的 Git worktree 分支中獨立工作。

具體的運作流程大概是這樣的：

任務拆分：你把一個大任務交給主 Agent，它會分析這個任務可以怎麼拆分成平行可執行的子任務。
分支建立：每個子 Agent 會在專案中建立一個獨立的 worktree 分支，避免程式碼衝突。
平行開發：各個 Agent 同時在各自的分支上工作，互不干擾。
整合與審查：所有子任務完成後，主 Agent 會協調合併，處理可能的衝突。

這個架構最大的好處是「真正的平行」——不是假的非同步，而是多個 Agent 同時在消耗 tokens、同時在產出程式碼。對於有明確分界的模組化任務，效率提升可以到 2-3 倍。

設定 Agent Teams：實戰步驟

讓我帶你走一遍實際設定 Agent Teams 的步驟。前提是你已經安裝了 Claude Code CLI。

首先，你需要確保你的 Claude 方案支援多 Agent。目前 Agent Teams 功能需要 Claude Max 方案或更高。接著在你的專案根目錄中，建立一個 .claude/ 設定資料夾（如果還沒有的話），裡面可以放一個 CLAUDE.md 檔案來定義專案上下文。

啟動 Agent Teams 最簡單的方式是使用 /agents 指令。在 Claude Code 的對話中，你可以這樣說：「幫我開三個 Agent，一個負責寫前端元件，一個負責寫 API endpoint，一個負責寫測試」。Claude 會自動幫你建立對應的 worktree 和 Agent 實例。

你也可以更精細地控制每個 Agent 的行為。比如：

指定每個 Agent 可以操作的檔案範圍
設定 Agent 之間的依賴關係（比如「等 API Agent 完成再開始前端整合」）
定義每個 Agent 的系統提示（System Prompt），讓它們扮演不同的專家角色

Agent 角色專業化：讓每個 Agent 各司其職

我在實際使用中發現，Agent Teams 效果最好的配置通常是 3-4 個 Agent，每個扮演不同角色：

1. 實作 Agent（Implementation Agent）：負責核心業務邏輯的實作。這個 Agent 的 prompt 會強調程式碼品質、遵循設計模式、使用正確的抽象。

2. 測試 Agent（Testing Agent）：專門負責寫單元測試和整合測試。這個 Agent 會等實作 Agent 產出程式碼後，針對每個功能寫對應的測試。

3. Code Review Agent：負責審查其他 Agent 產出的程式碼，檢查潛在的 Bug、效能問題、安全漏洞。這個角色特別有價值，因為它提供了一個獨立的「第二雙眼睛」。

4. 文件 Agent（Documentation Agent）：如果需要的話，可以開一個 Agent 專門負責更新文件、寫 JSDoc 註解、更新 README。

關鍵的經驗是：不要開超過 4 個 Agent。我試過開 5-6 個 Agent，結果整合的複雜度急遽上升，最後花在合併衝突上的時間反而比省下來的時間還多。3-4 個是甜蜜點。

實戰案例：用 Agent Teams 重構 API 層

讓我分享一個真實的使用案例。上個月我需要把一個 Express.js 的 REST API 遷移到 Hono 框架，同時加入 OpenAPI 規格定義和型別安全。這是一個典型的「大但可平行化」的任務。

我把任務拆成三個 Agent：

Agent A：負責把 Express 路由轉換成 Hono 路由，處理中介軟體的遷移
Agent B：負責為每個 endpoint 加入 Zod schema 驗證和 OpenAPI 裝飾器
Agent C：負責更新所有對應的整合測試

三個 Agent 同時開工，大約 25 分鐘後全部完成。如果是單一 Agent 依序處理，根據我的估算大概需要 50-60 分鐘。效率提升了大約一倍。而且因為每個 Agent 都在自己的 worktree 工作，程式碼衝突幾乎為零（唯一的衝突是 package.json，很容易手動解決）。

這跟使用 OpenAI Agents SDK 的多 Agent 模式有些不同。OpenAI 的 Agent SDK 主要是在同一個 runtime 中切換 Agent 角色，而 Claude Code Agent Teams 是真正的多實例平行執行，每個 Agent 有獨立的上下文和工作空間。

與單 Agent 工作流的比較

並不是所有任務都適合用 Agent Teams。以下是我的經驗總結：

適合 Agent Teams 的任務：

跨多個模組的重構
同時需要實作和測試的新功能
大量重複但略有差異的工作（比如為 20 個 API endpoint 加上驗證）
需要獨立審查的程式碼修改

不適合 Agent Teams 的任務：

高度耦合的程式碼修改（一個 Agent 的修改會影響其他 Agent 的工作）
探索性的開發（還不確定方向時）
小規模的 Bug 修復
需要大量互動討論的設計決策

我的經驗法則是：如果這個任務交給一個人類開發者，也可以合理地拆分給 2-3 個人同時做，那它就適合用 Agent Teams。如果拆分不了，就用單一 Agent 就好。

最佳實踐與踩坑經驗

用了幾個月 Agent Teams 之後，我整理了一些最佳實踐：

明確定義每個 Agent 的邊界：告訴每個 Agent 它只能動哪些檔案、哪些目錄。模糊的邊界是衝突的根源。
使用 CLAUDE.md 統一上下文：把專案的架構決策、coding style、命名規範都寫在 CLAUDE.md 裡，確保所有 Agent 遵循同一套規則。
先讓主 Agent 規劃，再啟動子 Agent：不要急著開工。讓主 Agent 先花時間理解程式碼庫、制定計劃，確認拆分方案合理後再啟動子 Agent。
定期 checkpoint：每個 Agent 完成一個里程碑就先 commit，不要等到全部做完才一次整合。
合併策略：建議用 rebase 而不是 merge，保持 git history 的整潔。

最大的坑是「Agent 之間的隱性依賴」。有一次我讓 Agent A 修改了一個共用的 utility function，但 Agent B 不知道，結果兩邊產出的程式碼邏輯不一致。解決方案是：把共用的程式碼層先鎖定，不允許任何 Agent 修改，或者指定只有一個 Agent 可以動共用層。

Agent Teams vs 其他多 Agent 框架

如果你有在關注 AI Agent 生態系，可能會好奇 Claude Code Agent Teams 跟 LangGraph、CrewAI、AutoGen 這些框架有什麼不同。

最大的差異在於抽象層次。LangGraph、CrewAI 這些框架是通用的 Agent 編排工具，你需要自己定義 Agent 的工具、記憶、通訊方式。而 Claude Code Agent Teams 是專為軟體開發場景設計的，它已經內建了 Git 操作、檔案系統存取、shell 指令執行等開發必需的工具。

另外，Claude Code Agent Teams 的 Agent 共享同一個 Claude 模型（Opus 4.6），而 CrewAI 或 AutoGen 允許你混搭不同的 LLM。如果你需要更靈活的模型配置，或者你的場景不限於軟體開發，那這些通用框架可能更適合。

但如果你的目標就是「讓 AI 更快地幫我寫程式」，Claude Code Agent Teams 的開箱體驗是目前最好的。結合 Claude MCP 協議提供的外部工具整合能力，你甚至可以讓 Agent 在開發過程中自動查詢資料庫、呼叫 API、讀取文件。