精選 Agent Teams CMS Architecture Knowledge Comic Claude Code

我們在 Agent Teams 存在之前就建好了它

CMS 多 Session 架構如何在 Claude Code 官方 Agent Teams 功能推出前 6 個月，就解決了 context 隔離、狀態持久化和團隊協調問題 — 以及這對「走在平台前面」意味著什麼。

2026年2月7日 • 8 min read • 作者：Claude World

Knowledge Comic 系列 — 最大技術深度，最少文字。

沒人談論的問題

每個 Claude Code 重度使用者都會撞上同一面牆：

Turn 1-20:   Claude 敏銳、專注、記得所有事
Turn 30-50:  開始忘記先前的決策
Turn 80+:    「我們在改哪個檔案來著？」

這就是 context 腐爛。單一 context window 容量有限。做越多，忘越多。

Sub-agents（Task tool）有幫助 — 但結果會流回主 context。越用越滿，腐爛更快。

真正的問題是：如何執行 50+ 輪開發迭代而不失憶？

CMS 的答案（2026 年 1 月）

我們打造了 CMS（Claude Multi-Session）— 一個將每輪開發迭代隔離在獨立 process 的多 Session 編排器。

┌─────────────────────────────────────────────┐
│              CMS Orchestrator                │
│                                              │
│   Iteration 1    Iteration 2    Iteration 3  │
│   ┌─────────┐   ┌─────────┐   ┌─────────┐  │
│   │ 全新     │   │ 全新     │   │ 全新     │  │
│   │ Context  │   │ Context  │   │ Context  │  │
│   │ Window   │   │ Window   │   │ Window   │  │
│   └────┬─────┘   └────┬────┘   └────┬─────┘  │
│        │              │              │         │
│        └──────┬───────┴──────┬───────┘         │
│               ▼              ▼                  │
│         checkpoint.json（共享狀態）              │
└─────────────────────────────────────────────────┘

每輪迭代：

  1. 啟動全新 Claude Code process — 完整 context window，零包袱
  2. 讀取 checkpoint.json — 接續上一輪的進度
  3. 執行任務 — 實作、測試、修復
  4. 寫入 checkpoint.json — 儲存進度給下一輪
  5. 結束 — process 退出，context 釋放

Orchestrator 持續循環。50 輪？100 輪？永遠不會 context 腐爛。

然後 Agent Teams 來了（2026 年 2 月）

Opus 4.6 帶來了 Agent Teams — Claude Code 官方的多 agent 協調系統。

我們看著功能清單，有種奇妙的既視感：

  • 共享 Task List → 我們有 checkpoint.json
  • 跨 agent 通訊 → 我們有 checkpoint 狀態傳遞
  • 獨立 context window → 我們有 CMS 每輪獨立 process
  • Team Lead 協調 → 我們有 6 階段編排循環

概念對應

┌─────────────────────┬──────────────────────────────────┐
│ Agent Teams (v2.1)   │         CMS（2026 年 1 月）       │
├─────────────────────┼──────────────────────────────────┤
│ TeamCreate           │ cms-iterate spawn                │
├─────────────────────┼──────────────────────────────────┤
│ TaskList / TaskGet   │ checkpoint.json                  │
├─────────────────────┼──────────────────────────────────┤
│ SendMessage          │ checkpoint 狀態傳遞               │
├─────────────────────┼──────────────────────────────────┤
│ Teammate（process）  │ CMS iteration（process）          │
├─────────────────────┼──────────────────────────────────┤
│ Team Lead            │ self-upgrade 6 階段循環           │
├─────────────────────┼──────────────────────────────────┤
│ Shutdown protocol    │ iteration exit + checkpoint      │
├─────────────────────┼──────────────────────────────────┤
│ Idle notification    │ iteration 完成信號                │
└─────────────────────┴──────────────────────────────────┘

同樣的問題。同樣的解法。不同的名字。

CMS 依然領先的地方

Agent Teams 很優雅。但 CMS 有經過實戰驗證的優勢，官方系統還沒追上。

0. 根本差異：誰擁有迭代循環？

這是最重要的架構差異：

Agent Teams:
  ┌──────────────────────────────┐
  │     Lead（主 context）        │  ← Lead 活在你的終端 session 裡
  │                              │
  │  spawn teammate A ──→ [A]    │  ← Teammate 拿到全新 context
  │  spawn teammate B ──→ [B]    │
  │  等待結果                     │  ← Lead 的 context 持續填滿
  │  綜合結果                     │
  │  spawn teammate C ──→ [C]    │
  │  ...                         │  ← 50 輪後，Lead 已經臃腫不堪
  └──────────────────────────────┘

CMS:
  ┌──────────────────────────────┐
  │     CMS Orchestrator         │  ← 薄薄的 shell script，不是 LLM
  │                              │
  │  spawn iteration 1 ──→ [I1]  │  ← 全新 context，執行所有事
  │  checkpoint.json ←── [I1]    │  ← 狀態外部化，I1 死亡
  │  spawn iteration 2 ──→ [I2]  │  ← 全新 context，讀取 checkpoint
  │  checkpoint.json ←── [I2]    │  ← I2 死亡
  │  ...                         │  ← 50 輪後，依然清新
  └──────────────────────────────┘

Agent Teams 隔離了 teammate，但沒有隔離 Lead。

Lead 累積每次 spawn 的結果、每則訊息、每次 task 更新。50 輪迭代後，Lead 的 context 跟單一 session 工作流一樣臃腫。

CMS 隔離了一切 — 包括迭代循環本身。

Orchestrator 是 shell script，不是 LLM。它不消耗 token。它不會忘記。它不會腐爛。每輪迭代是完全獨立的 Claude Code process，讀一個 JSON 檔、做完工作、然後死去。

這是「平行 agents 共用一個老闆」和「串行 processes 共用一個磁碟」的差別。

1. 平行但不共享大腦

當任務之間沒有依賴時，CMS 不會等待：

CMS（平行模式）:
  ┌──────────────────────────────────┐
  │       CMS Orchestrator           │
  │                                  │
  │  Task A（無依賴）──→ [Process 1]  │  ← 獨立 process
  │  Task B（無依賴）──→ [Process 2]  │  ← 獨立 process
  │  Task C（無依賴）──→ [Process 3]  │  ← 獨立 process
  │                                  │
  │  等待全部完成 ←─── checkpoint     │
  │                                  │
  │  Task D（依賴: A,B）──→ [Proc 4]  │  ← A & B 完成後才跑
  └──────────────────────────────────┘

Agent Teams（平行）:
  ┌──────────────────────────────────┐
  │       Lead（主 context）          │
  │                                  │
  │  spawn A ──→ [Teammate A]        │
  │  spawn B ──→ [Teammate B]        │  ← 全部平行，很好
  │  spawn C ──→ [Teammate C]        │
  │                                  │
  │  收到結果 A ← 填滿 Lead           │
  │  收到結果 B ← 填滿 Lead           │  ← Lead 累積所有東西
  │  收到結果 C ← 填滿 Lead           │
  └──────────────────────────────────┘

兩者都平行執行任務。但 CMS 的 orchestrator 不消耗 context。Agent Teams 的 Lead 會。

CMS 同時獲得平行性和 context 隔離。Agent Teams 讓你二選一。

2. 跨重啟恢復

CMS:
  Process 崩潰 → checkpoint.json 留在磁碟上
  執行 --resume → 精確接續上次的進度

Agent Teams:
  Leader 關閉終端 → 所有 teammate 死亡（Death #4）
  Mailbox 訊息 → 變成孤兒檔案
  恢復 → 從頭開始

CMS checkpoint 是設計上持久的。Agent Teams 的 in-memory 狀態是預設上短暫的。

3. 無限迭代

CMS:
  每輪迭代 = 新 process = 全新 200k context
  50 輪？200k × 50 = 10M tokens 累積容量
  第 50 輪零退化

Agent Teams:
  每個 teammate = 一個 process = 一個 context window
  長時間運行的 teammate = 同樣的 context 腐爛問題
  Max turns 限制 = 強制停止

CMS 不對抗 context 限制。它完全繞過它們。

4. 自進化循環

CMS + Self-Evolving:
  迭代失敗 → 萃取學習 → 進化 skills → 用更好的工具重試
  每次失敗讓下一輪迭代更聰明

Agent Teams:
  Teammate 失敗 → Lead 重試或重新 spawn
  失敗之間沒有內建學習機制

CMS 整合了學習循環。Agent Teams 提供協調，不提供進化。

Agent Teams 領先的地方

1. 即時對等通訊

Agent Teams:
  frontend-dev → SendMessage → backend-dev
  「你的 API schema 準備好了嗎？」
  即時、任意對任意、雙方同時運行

CMS:
  Iteration 5 寫入 checkpoint
  Iteration 6 讀取 checkpoint
  只有串行。沒有並行對話。

Agent Teams 支援平行對話。CMS 本質上是串行的。

2. 原生整合

Agent Teams:
  內建在 Claude Code runtime 中
  Shift+Up/Down 選擇 teammate
  Ctrl+T 檢視 task list
  零設定

CMS:
  自訂 skill + checkpoint 格式 + 編排邏輯
  需要設定和理解
  Claude Code 內部改動時可能壞掉

Agent Teams 是一等公民。CMS 是用戶端的 hack（很厲害的 hack，但還是 hack）。

3. 拓撲彈性

Agent Teams:
  Star、Mesh 或混合拓撲
  任何 teammate 可以訊息任何其他人
  Lead 可以委派後放手

CMS:
  嚴格的串行管線
  迭代之間沒有橫向通訊
  Orchestrator 始終掌控

遷移路徑

當 Agent Teams 穩定後，CMS 概念可以直接對應：

# CMS checkpoint.json → Agent Teams TaskList
checkpoint = read_checkpoint()
for task in checkpoint["remaining_tasks"]:
    TaskCreate(subject=task["name"], description=task["spec"])

# CMS iteration spawn → Agent Teams teammate
# 之前：
spawn_cms_iteration(task, checkpoint)
# 之後：
Task(subagent_type="general-purpose", team_name="dev-team", prompt=task)

# CMS 狀態傳遞 → Agent Teams 訊息
# 之前：
write_checkpoint({"api_schema": schema, "status": "ready"})
# 之後：
SendMessage(recipient="frontend-dev", content=f"API schema ready: {schema}")

# CMS resume → Agent Teams task list 恢復
# 之前：
cms_iterate --resume
# 之後：
TaskList()  # 找到 pending tasks，重新分配

商業邏輯不變。傳輸層改變。

更深的啟示

這不只是「我們先做出來」的故事。這是一個模式識別的啟示。

當你用第一性原理解決真實問題，你往往會收斂到平台廠商最終也會推出的同一套架構。

CMS 沒有抄 Agent Teams。Agent Teams 沒有抄 CMS。兩者獨立地得出：

  1. Context 隔離 — 不同工作用不同視窗
  2. 共享狀態 — 在任何單一 context 之外的協調層
  3. 生命週期管理 — 啟動、工作、回報、死亡
  4. 編排 — 總得有什麼來決定下一步

這些不是實作選擇。它們是多 agent 系統的架構必然。

下一步該建什麼

如果這個模式成立，以下是 Agent Teams 最終會需要的 — 也是你現在就能建的：

今天缺的為什麼需要現在就建
Heartbeat 協議偵測靜默死亡（Rate Limit Kill）Checkpoint 時間戳 + 超時偵測
送達確認確認訊息實際被讀取Checkpoint 狀態中的 ack 欄位
跨重啟恢復崩潰後恢復CMS 已有 — --resume
失敗間學習變聰明，不只是重試CMS 已有 — Self-Evolving Loop
每個 teammate 成本追蹤預算管理每輪迭代的 token 計數

今天建 userland 方案。明天換成原生 API。

這就是怎麼持續領先 6 個月。

延伸閱讀