這篇文章本身就是一個案例
寫這篇之前，我在 Claude Code 裡同時派了 Codex 跟 Gemini 兩個外部 LLM 各自去官方文件查 subagent 跟 Agent Teams 的差別，再加上 Claude 自己查的一份，三份結果交叉比對。三方都同意的當高信心，有分歧的我回官方文件定案。
這個動作本身剛好就是 subagent pattern 的示範：一個主 agent 派出三個下屬獨立工作、回報後綜合。而如果我改用 Agent Teams pattern，它們會彼此對話、互相糾錯，結果會完全不同。
多數人對 Claude Code 的平行化其實只認識一半。
一張表看完差別
面向 | Subagent | Agent Teams |
|---|---|---|
本質 | 主 session 內的分身 | 獨立的 Claude Code 實例，統稱 teammate |
Context | 自己一份 context，生命週期短 | 每個 teammate 各自滿 1M，持久 |
溝通 | 單向：收工回報一段文字 | 雙向： |
Sibling 對話 | ❌ | ✅ teammate 間可直接 ping |
巢狀 | ❌ 不能再 spawn subagent | ❌ teammate 不能再開 team |
生命週期 | 做完就收 | Session 活著都在；但 /resume、/rewind 不恢復 in-process teammate |
協調 | 主 agent 手動派活 | 共享任務清單，自動解依賴 |
Token 成本 | 基準 | 官方文件：plan mode 下約 7× |
穩定性 | 正式功能 | 實驗性，需 flag 開啟 |
架構差異的根本
Subagent 是主 session 派出去的一次性工作者。它有自己的 context，但跑完就消失，只有一段回報文字回來。主 agent 負責協調、綜合。這是星形拓撲。
Agent Teams 的每個 teammate 是另一個完整的 Claude Code，跟你同級。它會讀同一個 project 的 CLAUDE.md、skills、MCP server，但不繼承你的對話歷史——你給什麼 spawn prompt，它就知道什麼。teammate 之間透過一個檔案系統層的信箱互傳訊息。這是網狀拓撲。
拓撲決定能做什麼。星形下，三個審查者各給一份報告你自己整合；網狀下，安全審查者發現的 race condition 可以直接 ping 效能審查者：「你的 benchmark 可能失準」。
成本結構：為什麼是 7×
官方文件給的數字是「Agent Teams in plan mode ~7× tokens」。來源是兩個：
每個 teammate 各自燒 context：你 spawn 三個就是三份 1M 在跑
協調訊息本身要 token：信箱的訊息要寫進對方的 context window
這就是為什麼官方反覆強調「Agent Teams 適合協調本身就是問題的任務」。如果你的任務可以切乾淨、各做各的，subagent 永遠比較划算。
什麼時候用哪個
實用決策框架：
用 subagent，如果：
任務能一次講清楚，不需要中途對話
只要結果，不在乎過程
多個工作互相獨立（研究、翻譯、跑測試）
想省 context 或省錢
用 Agent Teams，如果：
多個 teammate 的發現會影響彼此（安全影響效能的案例）
要長時間互動（持續除錯、來回審查）
需要真平行且每個 teammate 都要完整 1M context
有複雜依賴想自動解
不確定時預設：先用 subagent。Agent Teams 的 7× 成本只有在「協調本身就是價值」時才值回票價。
在 Windows 上怎麼用
Agent Teams 支援兩種顯示模式：
In-process（預設）：所有 teammate 共用你的終端機，Shift+Down 切換。Windows Terminal / cmd / PowerShell / VS Code 終端都能跑。
Split panes：每個 teammate 一格。只支援 tmux 或 iTerm2。Windows Terminal 不在支援列表。
想在 Windows 用 split panes，唯一路徑是 WSL2 + tmux：
# WSL (Ubuntu)
sudo apt install tmux
npm install -g @anthropic-ai/claude-code
tmux
claude啟用 flag（~/.claude/settings.json）：
{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }建議：先別為了 split panes 搬 WSL。in-process 模式功能完整，只差畫面同時顯示這個 UX。等你實際用過一次確定需要再搬。
Resume 有個坑
Agent Teams 是實驗性功能，最顯著的限制在 session 恢復：
/resume 跟 /rewind 不會恢復 in-process 模式的 teammate——即使主 session 成功 resume，那些 teammate 實際上已經不存在
恢復後 lead 手上還拿著舊的 teammate 引用，可能對著不存在的 teammate 發
SendMessage如果發生，要明確告訴 lead「那個 teammate 已經不在了，重新 spawn 一個」
實務建議：重要的團隊工作做完就明確關閉，別依賴 resume 繼續。Split panes 模式靠 tmux 保留進程，限制少一點但還是建議手動重連。
三個常踩的雷
兩個 teammate 改同檔案：會互蓋。切任務時讓每個 teammate 擁有自己的檔案集合
Spawn prompt 給太少 context：teammate 不繼承主 session 對話歷史，你給什麼它只知道什麼
任務切太細：3 個 teammate 各跑 2 分鐘的工作，協調成本反而超過單 session 做完
下一篇
這篇文章的製作方式——在 Claude 裡呼叫 Codex 跟 Gemini 做獨立驗證——本身就是一個省 token 的 pattern。下一篇會講具體怎麼設定、什麼任務該用哪個外部 LLM、以及為什麼這比讓 Claude 自己跑 3 次便宜。