• 專欄 - 由零開始學AI
• 專欄 - 寫出神提示：小白都掌握到嘅提示詞魔法

Claude Code 推出 Agent Teams 實驗功能支援多實例協作開發。

簡單講，就係可以畀你做老細，請一批AI員工做嘢。

我試下。。。

我組咗1個最細團隊，1個產品，1個開發，1個測試。叫佢哋自己腦暴，跟住開發1個產品。

等咗一陣，有啲急，問下佢哋進度。（老細係咪都係咁。。？）

又行咗一陣。成日騷擾員工都唔好，應該同項目經理溝通。我就問下項目經理進度。

又等咗一陣。點解咁慢（老細係咪都係咁諗）。問下，使唔使加1個人？會唔會咁就快咗？

做咗半個幾鐘，搞掂。我試下。。。

上傳圖片

揀模板，填上你想要嘅字

最後㩒“本地下載”掣，完成

Claude Code 推出 Agent Teams 實驗功能支援多實例協作開發

讓多個 Claude Code 實例組成一個團隊協同工作，共享任務、彼此通訊，並由一個負責人統一協調。

Agent teams 係實驗性功能，預設關閉。需要喺 settings.json 或環境變量中加入 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 先至可以啟用。目前喺會話恢復、任務協調同關閉流程上仲有啲已知限制。

Agent teams 畀你同時執行多個 Claude Code 實例。一個會話擔任負責人，負責分配任務、協調流程、歸納結果；其他隊友各自獨立運作，喺自己嘅 context window 入面工作，而且可以直接互相溝通。

同 subagents 唔同，subagents 淨係喺一個會話入面運行，只向主代理匯報；而 agent teams 嘅隊友之間可以直接對話，你亦可以繞過負責人直接同某個隊友交流。

幾時用 agent teams

Agent teams 適合“並行探索確實有價值”嘅情況，例如：

• 研究同審查
  ：唔同隊友同時調查問題唔同方面，然後互相質疑、補充
• 開發新模塊或功能
  ：每人負責一個獨立部分，互不幹擾
• 用競爭假設除錯
  ：並行驗證唔同理論，更快收窄範圍
• 跨層協作
  ：前端、後端、測試分別由唔同隊友負責

留意：佢嘅協調成本同 token 消耗都比單會話高。如果係順序任務、成日改同一個檔案、依賴關係多嘅工作，用單會話或 subagents 會更合適。

同 subagents 嘅分別

簡單講：
要“專心做嘢匯報結果”——用 subagents。
要“多人討論、互相挑戰”——用 agent teams。

啟用 agent teams

在 settings.json 入面加入：

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

啟動第一個 agent team

啟用之後，用自然語言描述你想要嘅團隊結構同任務就得。

例如：

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

負責人會自動：

• 建立團隊
• 生成隊友
• 建立共享任務列表
• 協調討論
• 歸納結果
• 最後清理資源

喺 in-process 模式下，用 Shift + Down 可以輪流切換唔同隊友。

控制你嘅 agent team

顯示模式

支援兩種模式：

• In-process
  ：所有隊友喺同一個終端入面輪流顯示（預設）
• Split panes
  ：每個隊友單獨一個窗格（需要 tmux 或 iTerm2）

在 settings.json 入面設定：

{
  "teammateMode": "in-process"
}

或啟動時指定：

claude --teammate-mode in-process

指定隊友數量同模型

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

要求計劃審批

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

流程：

1. 隊友先提交計劃
2. 負責人審批或駁回
3. 通過之後先開始實施

你可以定義審批標準，例如：

• “必須包含測試覆蓋”
• “唔可以修改數據庫結構”

直接同隊友講嘢

• In-process：Shift + Down 切換隊友
• Split-pane：直接㩒對應窗格

每個隊友都係完整獨立會話。

任務分配方式

共享任務列表有三種狀態：

• 待處理
• 進行中
• 已完成

任務可以有依賴關係。

分配方式：

• 負責人手動分配
• 隊友自我認領

系統會用檔案鎖避免搶任務衝突。

關閉隊友

Ask the researcher teammate to shut down

清理團隊

Clean up the team

一定要由負責人執行清理。
唔好叫隊友自己清理。

架構組成

本地儲存位置：

• 團隊設定：~/.claude/teams/{team-name}/config.json
• 任務列表：~/.claude/tasks/{team-name}/

Context 與通訊

每個隊友：

• 有自己嘅 context window
• 加載 CLAUDE.md、MCP servers、skills
• 唔繼承負責人嘅對話歷史

通訊方式：

• message：發畀某個隊友
• broadcast：發畀所有隊友（成本隨人數增加）

Token 使用

Agent teams 嘅 token 消耗遠高於單會話。
適合研究、審查、新功能探索。
日常簡單任務唔划算。

示例用例

並行代碼審查

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/...
Focus on token handling, session management..."

控制團隊規模

建議 3–5 個隊友。
超過呢個規模收益遞減。

每個隊友 5–6 個任務比較合適。

合理拆分任務

• 太細：協調成本高
• 太大：風險高
• 理想：獨立可交付單元（函數、測試檔案、審查報告）

等隊友完成

如果負責人搶住自己做：

Wait for your teammates to complete their tasks before proceeding

從研究類任務開始

建議先用嚟：

• 審查 PR
• 研究庫
• 調查 bug

避免一開始就並行寫代碼。

避免檔案衝突

唔好畀兩個隊友編輯同一個檔案。

故障排除

隊友冇出現

• Shift + Down
   查看
• 檢查任務係咪夠複雜
• 檢查 tmux 係咪安裝咗

which tmux

權限提示太多

提前喺權限設定裏面預批准常見操作。

隊友遇到錯誤停咗

• 直接畀指示
• 或生成替代隊友

負責人提早結束

叫佢繼續或等隊友完成。

孤立 tmux 會話

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

目前限制

• in-process 隊友唔支援會話恢復
• 任務狀態可能唔同步
• 關閉可能較慢
• 每次只能一個團隊
• 唔支援嵌套團隊
• 負責人唔可以轉移
• 權限喺生成時統一設定
• Split-pane 需要 tmux 或 iTerm2

CLAUDE.md 檔案對所有隊友都生效。

• 專欄 - 從零開始學AI
• 專欄 - 寫出神提示：小白也能掌握的提示詞魔法

Claude Code 推出 Agent Teams 實驗功能支持多實例協作開發。

簡單來說，就是可以讓你當老闆，招一批AI員工幹活。

我來試試。。。

我組了1個最小化團隊，1個產品，1個開發，1個測試。讓他們自己腦暴，然後開發1個產品。

等了一會，有點急了，問問他們進度。（老闆是不是都這樣。。？）

又跑了一會。老是打擾員工也不好，應該和項目經理交流。我就問問項目經理進度。

又等了一會。怎麼那麼慢（老闆是不是都這想法）。問問看，要不要加1個人？會不會這樣就快了？

幹了半個多小時，完成了。我試試。。。

上傳圖片

選模板，填上你想要的字

最後點擊“本地下載”按鈕，完成

Claude Code 推出 Agent Teams 實驗功能支持多實例協作開發

讓多個 Claude Code 實例組成一個團隊協同工作，共享任務、彼此通信，並由一個負責人統一協調。

Agent teams 是實驗性功能，默認關閉。需要在 settings.json 或環境變量中添加 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 才能啓用。當前在會話恢復、任務協調和關閉流程上仍有一些已知限制。

Agent teams 允許你同時運行多個 Claude Code 實例。一個會話擔任負責人，負責分配任務、協調流程、彙總結果；其他隊友各自獨立運行，在自己的 context window 中工作，並且可以直接互相交流。

和 subagents 不同，subagents 只在一個會話裏運行，只向主代理彙報；而 agent teams 中的隊友之間可以直接對話，你也可以繞過負責人直接和某個隊友交流。

何時使用 agent teams

Agent teams 適合“並行探索確實有價值”的場景，比如：

• 研究和審查
  ：不同隊友同時調查問題不同方面，然後互相質疑、補充
• 開發新模塊或功能
  ：每人負責一個獨立部分，互不干擾
• 用競爭假設調試
  ：並行驗證不同理論，更快收斂
• 跨層協作
  ：前端、後端、測試分別由不同隊友負責

注意：它的協調成本和 token 消耗都比單會話高。如果是順序任務、頻繁改同一個文件、依賴關係多的工作，用單會話或 subagents 更合適。

與 subagents 的區別

簡單說：
要“專心幹活彙報結果”——用 subagents。
要“多人討論、互相挑戰”——用 agent teams。

啓用 agent teams

在 settings.json 中加入：

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

啓動第一個 agent team

啓用後，用自然語言描述你想要的團隊結構和任務即可。

例如：

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

負責人會自動：

• 創建團隊
• 生成隊友
• 建立共享任務列表
• 協調討論
• 彙總結果
• 最後清理資源

在 in-process 模式下，使用 Shift + Down 可以輪流切換不同隊友。

控制你的 agent team

顯示模式

支持兩種模式：

• In-process
  ：所有隊友在同一個終端裏輪流顯示（默認）
• Split panes
  ：每個隊友單獨一個窗格（需要 tmux 或 iTerm2）

在 settings.json 裏設置：

{
  "teammateMode": "in-process"
}

或啓動時指定：

claude --teammate-mode in-process

指定隊友數量和模型

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

要求計劃審批

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

流程：

1. 隊友先提交計劃
2. 負責人審批或駁回
3. 通過後才開始實施

你可以定義審批標準，例如：

• “必須包含測試覆蓋”
• “不能修改數據庫結構”

直接和隊友說話

• In-process：Shift + Down 切換隊友
• Split-pane：直接點擊對應窗格

每個隊友都是完整獨立會話。

任務分配方式

共享任務列表有三種狀態：

• 待處理
• 進行中
• 已完成

任務可有依賴關係。

分配方式：

• 負責人手動分配
• 隊友自我認領

系統會用文件鎖避免搶任務衝突。

關閉隊友

Ask the researcher teammate to shut down

清理團隊

Clean up the team

必須由負責人執行清理。
不要讓隊友自己清理。

架構組成

本地存儲位置：

• 團隊配置：~/.claude/teams/{team-name}/config.json
• 任務列表：~/.claude/tasks/{team-name}/

Context 與通信

每個隊友：

• 有自己的 context window
• 加載 CLAUDE.md、MCP servers、skills
• 不繼承負責人的對話歷史

通信方式：

• message：發給某個隊友
• broadcast：發給所有隊友（成本隨人數增加）

Token 使用

Agent teams 的 token 消耗遠高於單會話。
適合研究、審查、新功能探索。
日常簡單任務不划算。

示例用例

並行代碼審查

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/...
Focus on token handling, session management..."

控制團隊規模

建議 3–5 個隊友。
超過這個規模收益遞減。

每個隊友 5–6 個任務比較合適。

合理拆分任務

• 太小：協調成本高
• 太大：風險高
• 理想：獨立可交付單元（函數、測試文件、審查報告）

等待隊友完成

如果負責人搶着自己做：

Wait for your teammates to complete their tasks before proceeding

從研究類任務開始

建議先用來：

• 審查 PR
• 研究庫
• 調查 bug

避免一開始就並行寫代碼。

避免文件衝突

不要讓兩個隊友編輯同一個文件。

故障排除

隊友沒出現

• Shift + Down
   查看
• 檢查任務是否足夠複雜
• 檢查 tmux 是否安裝

which tmux

權限提示太多

提前在權限設置裏預批准常見操作。

隊友遇錯停止

• 直接給指示
• 或生成替代隊友

負責人提前結束

告訴它繼續或等待隊友完成。

孤立 tmux 會話

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

當前限制

• in-process 隊友不支持會話恢復
• 任務狀態可能不同步
• 關閉可能較慢
• 每次只能一個團隊
• 不支持嵌套團隊
• 負責人不可轉移
• 權限在生成時統一設置
• Split-pane 需要 tmux 或 iTerm2

CLAUDE.md 文件對所有隊友都生效。