面對複雜、跨領域的工作流程，仰賴單一 AI session 本質上就很慢。Claude agent teams 透過並行執行專門化 agents 來解決這點，以更高速度交付更深入的成果。本指南涵蓋 Claude Code agent teams 的運作方式、設定方法，以及最大化其價值的最佳實務。
什麼是 Claude agent teams
Claude Code agent teams 是一套多實例協調系統，讓多個 Claude sessions 在同一個 codebase 上並行工作。其中一個 session 會被指定為 lead agent，接收整體任務、拆解成子任務，並彙整最終輸出。其他 sub-agents 則是 teammates，各自在隔離的 context window 中執行，負責一塊明確的工作，並可直接與其他 teammates 溝通。
agent teams 的優勢
Agent teams 與一般 AI assistants 不同；一般 AI assistants 會一次一項、依序處理任務。Agent teams 打破這項限制：當工作確實能並行化時，實際耗時就會相應下降。
同時，agent teams 不只是多個 sessions；協調層加入了手動多 session 工作所欠缺的三項能力：
點對點訊息： Teammates 可直接互傳訊息，不必經由你或 lead 轉送。例如，包含安全審查者的 agent team 可在執行中途將發現標記給效能審查者，而不會讓整個 team 停滯。
File locking： 當某位 teammate 寫入檔案時，會取得一把鎖，防止其他 agents 同時寫入。這能阻擋無聲覆寫這類 merge conflicts。
相依追蹤： lead 會在任務拆解時編碼 task dependencies。協調層會強制執行這些相依關係，因此在前置條件滿足前，任何 agent 都不會開始，且不需要人工輪詢。
agent teams 實際如何運作
agent team 由以下元件組成，各自扮演特定角色：
team lead 是主要的 Claude Code session。它建立 team、產生 teammates、協調彼此的工作，並彙整最終結果。這也是你會直接互動的 session。
Teammates 是彼此分離的 Claude Code instances，各自在自己的 context window 內獨立處理被指派的任務。他們不會與 lead 或彼此共享 context；溝通必須明確進行，透過 task list 與 mailbox 完成。
共享 task list 與 mailbox 用於協調**。** 共享 task list 是 agent group 可讀寫的即時 queue。lead 會在拆解時填入任務，teammates 會領取任務、逐項完成並標記完成。相依關係會自動強制執行；當某位 teammate 完成任務，任何被該任務阻擋的任務都會自動解除阻塞，不需人工介入。mailbox 則是 agent-to-agent 直接溝通的訊息系統。訊息會在 teammates 與 lead 之間自動流動。
team config 與 task list 都會儲存在本機（~/.claude/teams/ 與 ~/.claude/tasks/）。Claude Code 會自動產生並維護這些檔案。請勿手動編輯，因為任何變更都會在下一次狀態更新時被覆寫。
如何設定 Claude Code agent teams
Claude Code 預設停用 Claude agent teams。它們被標示為實驗性功能，必須明確選擇啟用。以下是完整設定流程。啟用 agent teams 前，請先確認你的 Claude Code 版本為 v2.1.32 或更新版本**。** 你可以在終端機執行 claude --version 進行檢查。
步驟 1：啟用 feature flag
將 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 環境變數設為 1。可用以下三種方式：
選項 A：~/.claude/settings.json（建議）
選項 B：Shell profile（~/.bashrc 或 ~/.zshrc）
選項 C：Inline，僅用於單一 session
如果你修改了 settings.json 或 shell profile，請重新啟動 Claude Code，讓 flag 生效。
步驟 2：安裝 tmux（建議，但非必需）
Agent teams 有兩種顯示模式：In-process（所有 teammates 都在主終端機內執行）與分割 panes（每位 teammate 都有自己的 pane，需使用 tmux 或 iTerm2）。讓每位 teammate 在自己的 terminal pane 中執行，會更容易即時監看整個 team。
若要確保維持 split panes mode，請在 ~/.claude/settings.json 中設定 teammateMode：
若要覆寫預設的 "auto" 設定，請在 ~/.claude/settings.json 中將 teammateMode 設為 in-process。若要針對單一 session 強制使用 in-process mode，請以 flag 傳入：claude --teammate-mode in-process。
步驟 3：用提示詞啟動你的 agent team
啟用 agent team 後，只要用自然語言告訴 Claude 你希望 agent team 執行哪些任務、交付成果與 team structure。你可以在提示詞中指定每個角色，Claude 會據此建立 team、產生 teammates，並安排任務。
提示詞範例：
你可以指定 agent teams 使用哪個模型，例如「Use Sonnet for every teammate」。Teammates 不會繼承 lead agent 的模型。使用者必須在 role file frontmatter 中指定模型，或透過 /config 設定預設 teammate model。
步驟 4：針對複雜任務要求計畫核准（選用）
對於高風險且複雜的任務，你可以要求 team 在執行前先擬定計畫。agent group 中的 teammates 會以 read-only mode 工作，由 lead 審閱、修訂並最終通過計畫。只有當計畫獲 lead 核准後，teammates 才會開始實作。
請注意，lead agent 會負責做決策，因此你也可以提供一些決策準則。
提示詞範例：
步驟 5：設定 git worktrees 以隔離檔案（選用，建議）
若任何 teammate 會寫入檔案，強烈建議使用 Claude Code worktrees。git worktree 是位於自己 branch 上的獨立 working directory，並與你的 main checkout 共用同一份 .git 歷史。每個 agent 都能獲得隔離的檔案存取；某個 worktree 中的編輯，永遠不會碰到另一個 agent 進行中的工作。
若要針對每個 agent 啟用，只要在 agent 的 YAML frontmatter 加入 isolation: worktree。Claude Code 會為每次 parallel agent invocation 佈建全新的 worktree，並在 agent 完成後自動清理。
CLI 用法：claude --worktree 或 claude -w 會在自己的 worktree 中啟動 session。desktop app 會自動為每個 session 建立一個 Claude Code worktree。
步驟 6：定期監看
Agent teams 不能放著不管；長時間執行的 teams 可能會偏離方向。Agents 可能卡在權限提示、過早將任務標記完成，或失去對範圍的掌握。你可以每 10–15 分鐘查看一次，並檢視共享 task list 是否有卡住或未被領取的任務。若某個任務 20–30 分鐘都沒有進展，可能是權限阻擋或角色設定不當，需要人工介入。
並排比較：subagents vs agent teams
Subagents 是委派模式；agent teams 是協作模式。這項差異會影響一切，從 context 管理方式到每次執行的成本。
| Subagents | Agent teams | |
|---|---|---|
| 溝通 | 單向：lead 派發，subagents 回報 | 點對點 + lead 協調 |
| 共享狀態 | 無 | 具相依追蹤的共享 task list |
| Context windows | 各自擁有 context window；結果回傳給 lead | 每位 teammate 各自擁有（最多 1M tokens） |
| 檔案衝突防護 | 未內建 | 包含檔案鎖定 |
| Token 成本 | 較低 | 較高（每位 teammate 都是一個獨立 instance） |
| Session 恢復 | 支援 | /resume and /rewind don't restore in-process teammates |
| 巢狀 agents | 支援 | 不支援；只有 lead 可以產生 teammates |
| 最適合 | 聚焦委派、可重複 workflows | 可並行、彼此相依、跨領域的工作 |
Subagents 是單向委派模式：lead 送出任務，subagent 在自己的 context window 內執行，並回傳結果。它沒有共享狀態，sibling agents 之間也不能直接溝通，沒有協調層，只有乾淨的派發與回傳迴圈。
Agent teams 會在共享 task list 上工作，自動強制執行相依關係，並透過 mailbox 讓 teammates 之間進行點對點訊息溝通。
簡言之，當工作能拆分成真正獨立的並行路線，且需要彼此分享發現、相互協調時，agent teams 才能發揮價值。若追求快速結果、處理循序任務、單檔編輯，或任何成本可預測性比速度更重要的情境，subagents 會是更好的選擇。
何時選擇 agent teams，何時選擇 subagents
適合使用 agent teams 的情境：
Teammates 需要彼此直接溝通
工作需要一份共享 task list，並在多條並行 workstreams 之間追蹤相依關係
任務大到單一 session 難以承擔，且每位 worker 都需要完全獨立的 context
適合使用 subagents 的情境：
你只需要最終摘要，不需要完整的中間輸出
工作足夠自成一體，可以回傳乾淨明確的結果
你想限制工具，或導向成本較低的模型
你需要彼此不相依的並行研究路徑
如果你找不出至少三條真正獨立的並行 workstreams，單一 session 或 subagents 很可能會以更低成本勝過 agent team。
Agent teams 的實際使用情境
當工作能自然拆分成範圍清楚、邊界明確的 workstreams，且這些 workstreams 可以不必彼此等待就推進（或其相依關係能明確編碼），而協調成本又遠低於並行節省的時間時，agent teams 就很有價值。以下五個使用情境中，agent teams 會優於單一 session。
並行 code review
同時指派三位 reviewers 審查一個 pull request，包括 security agent、performance agent 與 test coverage agent。lead 會把三份並行報告整合成一份按優先順序排列的 action list。這種模式也適用於 architecture review（scalability agent、security agent、maintainability agent），或跨不同監管框架的 compliance checks。
競爭假設式除錯
產生五個 agents，每個 agent 各持一項假設，針對特定檔案或 logs 測試並檢查 production bug。第一個確認假設的 agent 會提出修正，其餘 agents 則可停止。相較於逐一調查每個理論、花數小時沿著一條路徑除錯、回頭再開始下一條，這種方式更有效率。
跨層 refactors
跨層 refactor 任務同時包含循序與並行步驟。例如，一項 breaking API change 需要更新 backend endpoints、使用這些 endpoints 的 frontend components，以及涵蓋兩者的 test suite。backend 工作必須先完成，frontend 才能開始。一旦 backend 任務展開，test suite agent 就能並行開始搭建新的測試結構。在 agent team 中，lead 會利用共享 task list 的 dependency tracking 來編碼這個順序。
避免 context 污染的研究掃描
一項技術決策可能需要調查多組彼此獨立的證據，例如選擇資料庫引擎、評估三個 third-party APIs，以及評估 build tooling。將互不重疊的 domain 分配給各個 agent，並由每個 agent 發布結構化摘要。lead 會彙整成比較文件。這種隔離能保留獨立視角，提升結果品質。
大型 codebase migration
在大型 codebase 中升級主要 dependency，通常會牽涉多個 modules。若這些 modules 邊界清楚且能同步遷移，agent teams 就能派上用場。為每個獨立 module 指派一個 agent；各 agent 負責遷移自己的 module、執行自己的 test suite，並回報包含任何 interface 變更的 migration summary。lead 會在宣告 migration 完成前審查 interface 變更，並協調 merge sequence。
設計 agent team 的 Dos and don'ts
使用 Claude Code 建置並行 agent 系統，設定起來很直接，但也很容易做錯。以下設計原則會決定你的 agent team 是真正提升效率，還是在浪費時間。
建置並行 agent 系統的專業建議
預先核准權限： Teammates 會從 lead 的權限設定開始。如果 lead 以 --dangerously-skip-permissions 執行，所有 teammates 也會繼承這項設定。產生後你可以調整個別 teammate 模式，但無法在產生時設定單一 teammate 的模式。啟動 team 前，請先透過 lead 規劃好權限策略。
寫出精準的角色提示詞： 每個角色提示詞都應說清楚四件事：要做什麼、要在哪些檔案或 domain 內工作、該聚焦與排除什麼，以及交付成果應長什麼樣子。產生 teammates 時，你可以引用任何 subagent scope 中的 subagent 類型：project、user、plugin 或 CLI-defined。如此一來，你只需定義一次角色，例如 security reviewer 或 test runner，就能同時把它作為委派的 subagent，以及 agent team 中的 teammate 重複使用。
強制檔案隔離： 任何會寫入磁碟的 agent 都應使用 isolation。兩個 agents 同時修改同一個檔案，是最容易產生損壞輸出的情況之一。
定期查看進度： 對於運作中的 agent teams，每 10–15 分鐘檢查一次。查看共享 task list 中有哪些 tasks 沒有推進。若某項 task 卡住超過 20–30 分鐘，可能是權限問題、角色定義不當，或 circular dependency，通常需要手動處理。
明確編碼相依關係： 如果 Task B 在邏輯上接續 Task A，請在拆解時把這項相依關係寫進 task list，而不是寫在角色提示詞裡。協調層會自動強制執行相依關係；提示詞中的指令可能被誤讀或忽略。
在 md 檔中定義 ownership 邊界： 對於 multi-session projects，請寫明每個 module 或 directory 都只能有一個負責的 agent。這能在 team 啟動前就避免工作重疊。
一律透過 lead 清理，而不是透過 teammate： lead 會在清理資源前檢查是否仍有 active teammates。Teammates 缺乏完整的 team context，無法安全清理；若由它們執行，可能讓 session 留在不一致狀態。
你的 agent team 可以避免的常見錯誤
不要為單一 session 就能妥善處理的任務產生 team： 在撰寫任何角色檔，或送出任何 swarm 提示詞前，先畫出 task graph。哪些 subtasks 真正獨立？哪些有相依關係？它是否是循序相依的工作？如果你無法清楚說明三條邊界明確的並行路線，單一 session 會比 team 表現更好。
不要把兩個 agents 指派到同一個檔案。 這是 merge conflicts 和 silent overwrites 最常見的來源。如果你的任務拆解產生兩個都需要碰同一個 component 的 agents，該 component 的工作就應該循序進行——等前一個 agent 完成後，再指派給下一個。
不要略過 Claude Code 的權限預先核准。 執行途中跳出的權限提示會讓並行執行停擺，並需要人工介入。這項額外成本會抵消大部分好處。啟動前，先為工作目錄預先核准檔案寫入與 shell commands。
不要期待能還原你的 Claude Code team。 如果 session 已清理，/resume 和 /rewind 不會還原執行中的 teammates。長時間執行前，請先儲存重要的中間輸出。
沒有明確理由，不要讓 team 超過五人。 Token 成本會線性增加，但協調成本成長更快。三個角色精準的 agents，通常穩定勝過五個角色模糊的 agents。只有在確實有一條明確的並行 workstream 等待處理時，才新增 teammates——不要因為覺得更多就等於更好。
另一種範式：在 Kimi Agent Swarm 建立你的 multi-agent team
Claude Code agent teams 擅長開發者原生情境，能深度整合 terminal workflows 與 Git 生態系。不過，multi-agent 協作的範式遠不只限於 command line。Kimi Agent Swarm 讓每個人都能使用這套範式。
Kimi Agent Swarm 是 Kimi 為複雜、大規模任務打造的 multi-agent 協作系統。它會將宏觀目標拆解為離散 subtasks，並調度不同 agents 與 skills，同步處理搜尋、閱讀、分析、寫作、coding、試算表產生、投影片製作與網頁建置。不需要 env flags，也不需要 git config。
Kimi Agent Swarm 的主要功能
最多 300 個 sub-agents 並行協作： Kimi Agent Swarm 會拆解複雜任務，並調度多個 sub-agents 同步處理 subtasks。系統可在單次執行中協調最多 300 個 sub-agents，完成超過 4,000 次 tool calls。
多技能複合執行：Swarm 可在單次執行中結合多項專業 skills，包括深度研究、pptx、報告撰寫、vibe-coding、網站建置、論文寫作，並在輸出深度與格式覆蓋上超越單一 agent。
大規模文件處理：Agent Swarm 可批次處理 20+ 種格式的檔案（PDF、Word、Excel、PPT、images 等），在完整文件集上並行閱讀、擷取資訊並摘要內容，也能引用 libraries、competitive intelligence files，或進行 multi-source data ingestion。
主動式廣域研究： 對於需要跨大範圍蒐集資訊的任務，Agent Swarm 會派出 sub-agents 並行搜尋 web、定位來源、下載內容、分類發現並產生結構化摘要。
多視角推理： Agent Swarm 可同時針對同一問題運行多個專家觀點。相較於單一觀點的一輪分析，這能產出更完整的分析，也能揭露循序審查容易漏掉的盲點。
深度內容交付： Agent Swarm 的並行架構專為持續深入的輸出而設計，例如數百頁研究報告、長篇產業分析、學術文獻回顧、結構化學習指南，以及延展型敘事內容。
單次執行輸出多種格式： Agent Swarm 可在同一任務中同時產生多種交付成果，例如 PDF 報告、PPT 簡報、網頁、Excel 資料集與 code project。
如何在 Kimi Agent Swarm 中運行 agent team
步驟 1：開啟 Kimi Agent Swarm 並輸入你的提示詞
開啟 Agent Swarm 頁面，並在輸入框中描述你的任務。為了獲得最佳結果，請具體說明範圍、你期望的交付成果，以及任何限制，例如時間區間、來源或格式要求。
範例提示詞：
步驟 2：讓 Kimi Agent Swarm 開始工作
送出提示詞後，Agent Swarm 會將任務拆解成 subtasks，並派出 subagents 並行工作。你可以查看即時進度，包括任務規劃、sub-agent 產生與並行執行。
步驟 3：接收、預覽、下載或分享結果
執行完成後，你的交付成果就能直接在介面中預覽。依任務而定，輸出可能包含研究報告、資料分析、PPT 簡報、網頁、code projects，或這些成果的組合。你可以下載檔案並直接分享。
Kimi Agent Swarm 大放異彩的使用情境
標案與提案撰寫： 同時指派並行 agents 處理技術規格、法規遵循要求、定價模型與案例研究；orchestrator 會將它們整合成一份連貫的提案。
財務分析： 指派並行 agents 處理市場資料、競爭者申報文件、總體指標與內部模型；orchestrator 會將其綜合為統一分析。
商業研究： 指派並行 agents 從不同來源研究競爭格局、客戶訪談、產業報告與監管脈絡；orchestrator 會產出結構化成果。
安全測試： 運行並行 agents 進行偵察、漏洞掃描、dependency auditing 與權限提升檢查；orchestrator 會彙整發現並形成最終報告。
全端開發： 建立並行 agents 分別處理 frontend components、backend endpoints、database schema 與 test suites；orchestrator 會協調整個 full stack 的整合。
結論
Claude Code agent teams 專為工程 workflows 打造，能直接從 terminal 將並行執行帶入複雜 codebases。若你的工作不只限於 code，Kimi Agent Swarm 會把同樣的 multi-agent 範式帶到研究、分析、內容等更多領域。只要描述你的任務，其餘就交給 swarm 處理。