把多工變協作：Claude Agent Teams 是怎麼把開發節奏救回來的

我最怕的不是 bug 多，而是節奏被多工打碎。Agent Teams 的做法，是把「多工」變成「可協調的協作」：多個 Claude Code 實例作為團隊一起工作，具備共享任務清單、代理間訊息傳遞與集中管理；一個工作階段擔任主管，隊友各自獨立運作並可直接互相溝通。這是實驗性功能、預設停用，需要在設定或環境變數中啟用。

何時值得開團隊

官方的判斷標準很清楚：當「並行探索能增加真實價值」時，Agent Teams 才值得上場。典型情境包括研究與審查、新模組或新功能、競爭假設式除錯，以及跨前端/後端/測試的協作變更。

相對地，順序任務、同檔案密集修改或高度相依的工作，單一工作階段或 subagents 反而更有效率。原因很現實：Agent Teams 增加協調開銷，每個隊友都是獨立的 context window，token 使用成本會顯著提高。

和 subagents 的本質差異

兩者都能並行，但協作模型不同。Subagents 在單一工作階段內運行，只能向主代理回報結果；Agent Teams 則是多個獨立會話，隊友之間能直接溝通，並透過共享任務清單自我協調。簡單說：

只要結果、需要快速回報 → subagents
需要討論、互相質疑、協作收斂 → Agent Teams

協作機制：我最在意的細節

每個隊友都有自己的 context window，啟動時會載入和一般工作階段相同的專案 context（例如 CLAUDE.md 與專案設定），但不會繼承主管的對話歷史。資訊共享靠任務清單與代理間訊息。這也是為什麼「提供足夠 context」是最重要的最佳實踐之一。

權限也有明確規則：隊友一開始繼承主管的權限模式，生成時無法為每位隊友設定不同權限，只能在生成後再調整。

啟用與啟動

Agent Teams 預設停用，需要在 settings.json 或環境中啟用 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

啟用後，用自然語言告訴 Claude 建立團隊並描述任務與角色。這種「角色互補」提示是最常用的啟動方式：

I'm designing a CLI tool that helps developers track TODO comments across
there codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

如果你想指定隊友數量與模型，指令可以更直接：

Create a team with 4 teammates to refactor these modules in parallel.
Use Sonnet for each teammate.

顯示模式：讓「多人協作」真的可用

支援兩種顯示模式：

In-process：所有隊友在同一終端內運行，可用 Shift+Up/Down 切換並直接互動
Split panes：每位隊友一個窗格，可同時看到輸出並直接點擊互動，需要 tmux 或 iTerm2

預設是 auto，可在 settings.json 用 teammateMode 覆寫：

{
  "teammateMode": "in-process"
}

若要強制單次工作階段使用 in-process，可用 CLI 旗標：

claude --teammate-mode in-process

治理：計畫批准與委派模式

對於複雜或高風險任務，你可以要求隊友先提出計畫並由主管批准。隊友在計畫獲批前只會進行設計思考，不會實作：

Spawn an architect teammate to refactor the authentication module.
Require plan approval before they make any changes.

若你希望主管只負責協調，可啟用委派模式，讓主管僅能使用協調工具而不直接寫碼。

團隊管理：關閉、清理、等待

要優雅關閉隊友：

Ask the researcher teammate to shut down

完成後要求主管清理團隊：

Clean up the team

如果你發現主管開始自己動手而沒有等隊友完成，可以直接提醒：

Wait for your teammates to complete their tasks before proceeding

任務協調：避免多人同時改同一件事

共享任務清單提供待處理/進行中/已完成狀態，也能設定依賴關係。主管可明確分派任務，或讓隊友自我認領下一個可做的任務。為避免衝突，系統使用檔案鎖，避免多人同時搶同一個任務。

使用案例：我最常用的三種提示

並行程式碼審查：

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

競爭假設除錯：

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
 each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

安全審查給足 context：

Spawn a security reviewer teammate with the prompt: "Review the authentication module
at src/auth/ for security vulnerabilities. Focus on token handling, session
management, and input validation. The app uses JWT tokens stored in
httpOnly cookies. Report any issues with severity ratings."

最佳實踐（我會照做）

給隊友足夠的 context
任務大小要適中
先從研究與審查開始
避免檔案衝突
監控與引導，避免放置過久
必要時要求主管等待隊友完成再整合

疑難排解：tmux 與分割窗格

如果你明確要求分割窗格，務必確認 tmux 可用：

which tmux

當團隊結束後 tmux 工作階段仍存在，可列出並關閉：

tmux ls
tmux kill-session -t <session-name>

目前你必須接受的限制

Agent Teams 仍是實驗功能，有已知限制：in-process 隊友無法 /resume 或 /rewind；任務狀態可能延遲更新；關閉可能很慢；一個工作階段只能管理一個團隊；無法在隊友下再生成團隊；主管角色固定不可轉移；權限模式只能生成後調整。這些限制需要納入流程設計。

我的結論

Agent Teams 不是「更快寫完」，而是「更快收斂方向」。我會先用它做並行程式碼審查，把安全、效能、測試三個視角拆給隊友，再由主管統整結果。當你需要多視角並行探索，而不只是多工堆疊，它才真正值得上場。

參考資料

Claude Code Docs：協調 Claude Code 工作階段團隊