Claude Code Agent Teams 實測：9 個 Opus Agent 同時跑，16GB 記憶體瞬間炸裂

Claude Code 的 Agent Teams 功能可以讓多個 AI 同時協作，但你的電腦記憶體撐得住嗎？

我用 9 個 Opus agent 同時審查一個電商系統的程式碼，結果 16GB 記憶體瞬間吃光，系統直接當機。這篇文章記錄完整的事件經過、當機原因分析，以及給想嘗試 Agent Teams 的開發者的建議。

一、事件時間線

時間	事件
08:36	開始研究 Agent Teams 功能，發現 settings.json 需要設定
08:41	找到啟用方式：`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`
10:51	確認 settings.json 的 env 區塊設定方式
11:18	建立 simpleec-review 團隊 — 9 位 Opus agent 同時啟動
11:19-11:21	18 個任務建立完成，9 位 agent 全部進入 in_progress
11:56	再建立 whale-51w 團隊 — 再加 1 位 agent
11:57-12:24	whale-51w 的爬蟲 agent 也進入工作狀態
~12:00	系統凍結 / 當機

二、當機原因：記憶體耗盡 (OOM)

硬體規格

RAM：16GB
CPU：8 核心
Swap：512MB

同時在跑的東西

類別	數量	預估記憶體
simpleec-review agents (Opus)	9 個 in-process	~4.5-9 GB
whale-51w agents	2 個 in-process	~1-2 GB
Team Lead (主 session)	1 個 Opus 1M context	~1-2 GB
SimpleEC OMS Docker 容器	26 個	~3-5 GB
系統 + 桌面 + 其他	–	~1-2 GB
總計	–	>16 GB

結果：

16GB RAM 全部吃光
512MB Swap 也 100% 用盡
Linux kernel 的 OOM Killer 介入，系統凍結

三、為什麼這麼吃記憶體？

關鍵問題：backendType: “in-process”

從團隊配置可以看到，所有 9 位 agent 都設定為：

"backendType": "in-process"

這表示每位 agent 都作為主進程內的子執行緒運行，每個都要維護：

完整的 Node.js runtime
Claude API 連線和 streaming buffer
工具執行環境（Bash、Read、Grep 等）
各自的 context window

9 個 agent 同時在做什麼？

DBA：掃描所有 Entity + SQL DDL
Docker 專家：讀 docker-compose.yml + 所有 Dockerfile
前端工程師：讀 admin-app/ + user-app/ 所有 Vue 檔案
後端工程師：讀所有 Controller + Service + VO
事件流工程師：讀所有 Kafka Consumer + Handler
…全部同時進行

每個 agent 的 context buffer 可能佔 500MB-1GB，9 個就是 4.5-9GB。

四、任務執行狀態（凍結時的快照）

simpleec-review（18 個任務）

任務	角色	狀態	說明
#1	Leader	in_progress	等待其他 agent 完成
#2	DBA	in_progress	正在掃描 Entity + DDL
#3	Docker Expert	in_progress	正在讀 docker-compose
#4	Frontend Eng	in_progress	正在讀 Vue 組件
#5	Backend Eng	in_progress	正在讀 Controller
#6	Event Flow Eng	in_progress	正在追蹤 Kafka topics
#7	System PM	in_progress	等待 #5, #6 完成
#8	UI/UX Expert	in_progress	正在分析使用者旅程
#9	Doc PM	pending	等待 #1 完成（還沒開始）

所有任務都卡在 in_progress，沒有一個完成。系統在 agent 們工作的中途就凍結了。

五、殘留影響

當機後，這些團隊的殘留資料還在系統中：

~/.claude/teams/simpleec-review/    ← 團隊配置
~/.claude/teams/whale-51w/          ← 團隊配置
~/.claude/tasks/simpleec-review/    ← 18 個任務 JSON
~/.claude/tasks/whale-51w/          ← 11 個任務 JSON

系統記憶體依然緊張：14GB used / 755MB available，Swap 100%。可能還有殘留的 Node.js 進程。

六、給想嘗試 Agent Teams 的建議

建議	說明
限制並行 agent 數	16GB 機器建議最多 2-3 個 Opus agent 同時跑
混用模型	簡單任務（文件盤點、Docker 配置檢查）用 Haiku，深度分析才用 Opus
分批執行	9 個審查拆成 3 批（每批 3 個 agent），逐批完成
增加 Swap	目前只有 512MB，建議至少 4-8GB 作為緩衝
清理殘留	當機後記得刪除 teams/tasks 目錄 + 檢查殘留 Node.js 進程

七、後續調整：三層防護機制

經過這次教訓，我建立了三層防護機制，確保 Agent Teams 不會再拖垮整台機器。

層級 1：AI 自我限制（~/.claude/CLAUDE.md）

所有 Claude Code session 都會讀取這個檔案，在 AI 層面就先做限制：

限制同時最多 3 個 agent
禁止同時跑兩個 team
超過 3 個角色必須分批執行
建立 team 前先告知使用者確認

層級 2：系統硬限制（cgroup）

建立 claude-limited 啟動指令，透過 systemd slice 限制資源：

啟動方式	記憶體限制	適用場景
`claude`	無限制	一般使用、單 agent
`claude-limited`	10GB + 4GB swap	跑 Agent Team 時

用 claude-limited 啟動時，所有 Claude 進程被限在 10GB RAM + 4GB Swap 以內。超過就會被 cgroup 強制回收，不會拖垮整台機器。

層級 3：核心參數調整

swappiness 60→10：系統更傾向釋放 cache 而非 swap，減少磁碟 thrashing
Swap 512MB→8GB：就算吃到 swap 也不會馬上掛掉
重開機自動生效

八、如何指定 Agent 模型（關鍵！）

這次當機的根本原因之一：沒有指定模型，9 個 agent 全部繼承了 parent 的 Opus。

模型別名對照

別名	模型	用途	記憶體
`opus`	claude-opus-4-6	深度分析	~1GB
`sonnet`	claude-sonnet-4-6	平衡	~600MB
`haiku`	claude-haiku-4-5	快速輕量	~300MB

⚠️ 重要：不指定模型 → 繼承 parent session 的模型

如果你的主 session 是 Opus，spawn 出來的 agent 也會是 Opus！這就是為什麼 9 個 agent 全變成 Opus 的原因。

自然語言指定法

你不需要自己寫 JSON。只要在任務描述中指明即可：

幫我建一個審查團隊：
- DBA (haiku) — 掃描 Entity 和 DDL 對比
- Docker 專家 (haiku) — 檢查 port 和配置
- 後端工程師 (opus) — 深度分析 API 邏輯

Claude Code 會自動把指定的模型帶入 model 參數。

常見問題 FAQ

Q: Agent Teams 需要多少記憶體？

每個 Opus agent 大約需要 500MB-1GB 的記憶體。如果你有 16GB RAM，建議最多同時跑 2-3 個 Opus agent，其餘用 Haiku 或 Sonnet。

Q: 如何啟用 Claude Code 的 Agent Teams？

在 Claude Code 的 settings.json 中加入環境變數設定：

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

Q: Agent Teams 當機後如何清理？

刪除 ~/.claude/teams/ 和 ~/.claude/tasks/ 目錄下的殘留資料，並用 pkill -f node 清理可能殘留的 Node.js 進程。

Q: 16GB 記憶體可以跑幾個 agent？

扣除系統和其他應用的使用，建議：

純 Opus：2-3 個
混用模型（Opus + Haiku）：4-5 個
純 Haiku：6-8 個

Q: 如何避免 Agent Teams 導致系統當機？

三個關鍵做法：(1) 限制並行 agent 數量 (2) 增加 Swap 空間到 4-8GB (3) 分批執行任務而非一次全開。進階做法是用 cgroup 設定記憶體硬上限。

Q: 什麼是 claude-limited？

這是透過 systemd cgroup 建立的記憶體限制啟動方式。執行 claude-limited 會讓所有 Claude 相關進程被限制在 10GB RAM + 4GB Swap 以內，超過就會被系統強制回收，避免拖垮整台機器。

Q: 如何指定 Agent 使用的模型？

在任務描述中用自然語言指明即可，例如「DBA (haiku)」或「後端架構師 (opus)」。Claude Code 會自動把指定的模型帶入 model 參數。模型別名：opus、sonnet、haiku。

Q: 不指定模型會怎樣？

Agent 會繼承 parent session 的模型。如果你的主 session 是 Opus，所有 spawn 出來的 agent 都會是 Opus，這是記憶體爆掉的主因之一。

Q: 怎麼判斷一個角色該用什麼模型？

問自己：「這個角色需要說不嗎？」需要挑戰、否決、找漏洞 → opus。需要照做、實現 → sonnet。需要收集、整理 → haiku。

九、模型選擇口訣：這個角色需要「說不」嗎？

經過這次教訓，我整理出一套快速判斷模型的方法。

核心規則

這個角色會需要挑戰假設、否決方案、找出漏洞嗎？

特性	模型	說明
需要「說不」、「挑戰」	opus	對抗性思維
需要「照做」、「實現」	sonnet	遵循性執行
需要「收集」、「整理」	haiku	機械性收集

一句話口訣

問法	模型	需要的能力
「這樣做對不對？」	opus	判斷力
「這樣做出來」	sonnet	執行力
「這些東西找出來」	haiku	效率

角色對照表

角色	模型	判斷理由
架構師	opus	要說「這個方案不行，因為…」要能否決不好的設計
QA（測試設計）	opus	要故意找碴：「如果使用者輸入 null 呢？併發呢？斷線呢？」
QA（寫測試）	sonnet	測試案例已經設計好了，按 pattern 寫 code
QA（跑測試/回歸）	haiku	執行已有的測試、收集結果、分類 pass/fail
UI/UX 設計師	opus	要質疑：「使用者真的會這樣操作嗎？」需要同理心推理
UI/UX 切版實作	sonnet	按設計稿 + Design System 做出來
系統設計師	opus	要權衡：效能 vs 成本 vs 複雜度，做取捨
DBA（Schema 設計）	opus	正規化、索引策略、預判查詢模式
DBA（例行維護）	haiku	跑 backup、查慢 query log、整理
PM（需求分析）	opus	要追問：「你說的X到底是什麼意思？邊界在哪？」
PM（進度追蹤）	haiku	收集狀態、整理報告
Tech Writer	sonnet	按已有架構寫文件，結構化輸出
DevOps	sonnet	照 best practice 配 infra
安全審計	opus	對抗性思維：「攻擊者會怎麼繞過這個？」

實際 Agent Team 範例

拿 simpleec-review 來說，正確的配法應該是：

批次 1 — 收集階段 [haiku × 3, ~1.2GB]

文件PM (haiku) → 盤點所有文件，列清單
Docker 專家 (haiku) → 列出 26 個容器 port/config
DBA-掃描 (haiku) → 列出所有 Entity 和 DDL 欄位

批次 2 — 分析階段 [opus × 2 + sonnet × 1, ~2.6GB]

後端架構師 (opus) → 分析 API + Kafka 事件流一致性
前端 + UI/UX (opus) → 分析使用者旅程 + 前後端 contract
QA 寫測試 (sonnet) → 根據批次 1 的清單寫測試案例

批次 3 — 評審階段 [opus × 1, ~1GB]

Leader (opus) → 交叉比對所有報告，找不一致，寫總結

總共只要 3 批，每批不超過 3GB，安全不爆。

結論

Agent Teams 是個強大的功能，可以讓多個 AI 專家同時協作分析程式碼。但它對硬體資源的需求也是倍數成長。

想玩 Agent Teams 之前，先確認你的記憶體夠不夠。

16GB 記憶體想同時跑 9 個 Opus agent？結果就是這篇文章。

但經過三層防護的調整，現在可以安心使用 Agent Teams 了 — 就算 AI 失控，系統也會自動踩煞車。