Claude Code Task System：Agent Swarms 的實現¶

核心論述¶

CJ Hess 主張 Claude Code 的 task system 不只是 to-do list，而是協調層（coordination layer）— 實現了多年來一直被談論但從未真正運作的 agent swarms。他在大型 auth 重構中實測，發現系統首次「真的成功了」。關鍵轉變是：每個 task 可 spawn 獨立 sub-agent（200k context window），透過依賴圖（dependency graph）協調，實現 7-10 個 agents 並行工作。他預測這將上移開發者角色抽象層次 — 從「寫代碼」到「定義問題清晰到讓 agent swarm 能解決」。

WHY（為什麼重要）： 單一 context window 的 Claude 處理複雜專案會忘記步驟、context 滿後降級。
WHAT（核心機制）： Task system = 協調層，隔離 context、強制依賴順序、自動並行、跨 session 持久化。
SO WHAT（影響）： 開發者槓桿從「寫代碼」上移到「定義問題」，3 年內可能一人用一下午做出現在需要團隊 6 個月的應用。

大家誤解的地方¶

大多數人看到的： "哦，新的 to-do list。"

實際上是什麼： 協調層（coordination layer）。

關鍵差異： - Tasks 跨 /clear 存活 - Tasks 跨 session restart 存活 - 設定 CLAUDE_CODE_TASK_LIST_ID 後跨 terminal 關閉存活

但這些都不是重點。

真正的重點：
Task system 是協調層。它讓多個 agents 並行工作、追蹤依賴關係、共享跨越任何單一對話的狀態。

舊模式 vs 新模式： - 舊： Claude = 單一大腦，試圖同時把整個複雜專案放在腦中 - 新： Claude 將工作拆解，交給獨立的 sub-agents（各自有獨立 context window），透過共享依賴圖協調

這是完全不同的能力。

核心機制：實際運作方式¶

1. 隔離的 Context Windows（關鍵創新）¶

每個 task 可以 spawn 自己的 sub-agent，每個 sub-agent 獲得獨立的 200k token context window，完全隔離於主對話。

這是整個系統運作的關鍵。

隔離給你什麼： - Agent 1 深入 authentication 代碼，建立 session 處理的心智模型 - Agent 2 重構資料庫查詢，保持 schema 細節 - Agent 3 處理測試，追蹤哪些斷言需要改變 - 關鍵： 它們不會污染彼此的 context，也不會被彼此搞混，因為它們字面上看不到對方

與舊方法的對比： - 舊方法： Claude 試圖在單一對話中保持一切。小專案可以，但複雜專案會撞牆 — Claude 要同時記住早期決策、實作新東西、追蹤哪些檔案被修改過。Context 管理、context 管理、context 管理。東西會遺漏。 - 新方法： 每個 agent 專注一件事。Task 完成時，被它阻塞的任務自動解鎖，下一波工作啟動。協調被烘焙進結構中，而非 Claude 需要主動管理的事情。

2. Dependencies（真正的功能）：blockedBy¶

未被歌頌的英雄：blockedBy

{
  "subject": "Implement JWT authentication",
  "addBlockedBy": ["1", "2"]
}

這不是建議。 Task #3 字面上無法啟動，直到 tasks #1 和 #2 都完成。系統不會讓它進行，這意味著 Claude 無法意外跳過或忘記前置步驟，因為結構本身強制執行順序。

沒有依賴的情況： - Claude 必須把整個計劃保持在工作記憶中 - 小任務還好，複雜任務時計劃會在 context 填滿或 /clear 後降級 - 你必須重新解釋想要什麼、完成了什麼、剩下什麼、什麼依賴什麼 - 計劃只存在 Claude 腦中，這讓它很脆弱

有依賴的情況： - 你把計劃外部化成結構，跨越 context compaction、session restart、3 天後回來專案都能存活 - 圖不會忘記，也不會漂移 - 永遠不需要重新解釋，因為它從一開始就沒有儲存在記憶中

這就是為什麼 Ralph（reanchoring 工具）曾經很火。Anthropic 剛剛殺死 Ralph。

3. Free Parallelism（免費並行）¶

花了我一段時間才完全理解：你可以同時運行 7-10 個 sub-agents。

想想這意味著什麼：

舊方法（10 個任務）： - Claude 按順序執行：task 1 → task 2 → task 3 → ... - 即使其中一半完全獨立、可以任意順序完成 - Claude 仍會一次一個，因為一切都在單一對話線程中

新方法（task system）： - Claude 檢視依賴圖，spawn 所有可並行的任務 - Tasks 2、3、4 彼此不依賴？三個 agents 同時 spin up，各自獨立 context window，各自獨立工作 - 你剛剛快了 3 倍，什麼都沒做不同的事

自動資源分配： - Haiku — 快速搜尋 - Sonnet — 實作工作 - Opus — 需要重度推理時

你不用考慮資源分配或成本管理，只要定義依賴，系統自動處理所有編排。

4. Persistence（持久化）¶

設定一個環境變數：

export CLAUDE_CODE_TASK_LIST_ID="my-project"

現在你的 tasks 活在 ~/.claude/tasks/my-project/。

• 明天開新 session → 還在
• 不同 terminal → 同一個 task list
• 多個 Claude sessions 在同一專案上 → 都能看到和更新同樣的 tasks

這對長期工作來說很有趣： - 跨幾天的重構 - 一直回來繼續的功能 - Task graph 成為專案的持久狀態，獨立於任何對話

CJ 的實踐：

「我開始把 task list 當作大型專案的 source of truth。不是回來時重新解釋一切，而是讓 Claude 檢查 task list 看我們上次停在哪裡。結構把 context 往前帶。」

工作流的改變¶

舊方法（task system 之前）：¶

1. 要求 Claude 做複雜的事
2. 看它完成大概 60%
3. 注意到它在做 step 5 時忘記 step 2
4. /clear 重新開始
5. 重複直到挫折

新方法（task system）：¶

1. 要求 Claude 拆解工作
2. 審查 task graph
3. 讓它跑
4. Tasks 按順序完成，因為那是它們唯一能完成的順序

結構強制正確性。 依賴圖存在於 Claude 的 context window 之外，所以沒有東西會被忘記。

開始使用¶

非常簡單：

1. 要求 Claude 做複雜的事
2. 如果它自動建立 tasks → 讓它跑
3. 如果沒有 → 告訴它「把這個拆解成有依賴的 tasks」
4. 按 Ctrl+T 看 task view
5. 看它工作

持久化設定（加到 shell profile）：

export CLAUDE_CODE_TASK_LIST_ID="your-project-name"

就這樣。 系統處理編排、並行化、依賴追蹤。

Multi-Layer Swarms（未來方向）¶

目前狀況（Layer 2）¶

你現在是這樣工作： - 你 → Claude（main agent） → Sub-agents - 你給 Claude 複雜任務 - 它拆解工作、建立依賴圖、spawn sub-agents 處理片段

未來可能（Layer 3, 4, ...）¶

但這些 sub-agents 只是有獨立 context window 的 Claude instances。沒有理由它們不能自己使用同樣的 task system。

跟著這個思路：

1. 你要求 Claude 重構整個 codebase
2. 它拆解成子系統 — auth、database、API routes、frontend、tests

3. Spawn 5 個 sub-agents

4. Auth agent 看著自己的部分，決定還是太複雜

5. 它進一步拆解 auth 工作 — login、logout、sessions、password reset、token refresh
6. 建立自己的依賴圖，spawn 自己的 sub-agents

你現在是三層深。

沒有東西阻止 layer 3 spawn layer 4。架構沒有內建上限 — 唯一的約束是管理 context 和成本，而非能力。

目前我們在 layer 2。但走得更深的腳手架已經在那裡了。

開發者角色的上移（抽象層次）¶

幾十年來的演變： - 以前： 核心技能是寫代碼 - 然後： 轉移到架構系統 - 再來： 編排團隊 - 每一層都意味著更高抽象層次思考，但基礎始終相同 — 有人在寫實際代碼

那個基礎正在改變。

未來（幾年內，可能更短）： - 主要技能不會是寫代碼，甚至不是架構系統 - 會是定義問題清晰到足以讓 agent swarm 能解決 - 你的工作變成：知道要建什麼、為什麼重要、成功是什麼樣子 - 實作 — 重構、測試、除錯、跨服務協調 — 透過 agent 層次委派

這不是「AI 取代開發者」 — 那個框架錯過了正在發生的事。
角色只是上移了另一層抽象，就像每十年左右發生的那樣。

你變成協調階層的頂端，能以不久前需要 20 人的規模執行。

槓桿的崩塌（為什麼這改變一切）¶

過去：
如果你想建造雄心勃勃的東西 → 需要資金、團隊、幾個月 runway

未來：
你只需要信用卡和能力，清楚描述你在建造什麼，agents 就能執行。

建造軟體的障礙正在崩塌 — 不是「每個人都能寫代碼」那種方式（人們多年來一直這麼說，那總是有點扯淡，因為大多數人不想寫代碼）。

這是不同的。這是對知道自己想建造什麼但不想花 6 個月自己建造的人來說，障礙正在崩塌。

那是個不同的世界。

CJ 的預測¶

「我不知道這確切如何展開。但我賭 3 年後有人會在一個下午 ship 一個今天需要團隊 6 個月的 production application。可能有我沒看到的瓶頸，但方向很清楚。」

誰早期搞清楚這個，將有難以誇大的槓桿。

關鍵洞察（CJ 的金句）¶

「Task system 看起來像 to-do list，但底下運行的是階層式多 agent 系統的協調層。Checklist 只是 UI。」

「你不再管理 tasks。你在指揮一個 swarm。」

「結構強制正確性。依賴圖存在於 Claude 的 context window 之外，所以沒有東西會被忘記。」

「這就是為什麼 Ralph（reanchoring）很火。Anthropic 剛剛殺死 Ralph。」

「我們談論 agent swarms 已經好幾年了。這是我第一次看到架構在實踐中真正運作。」

「我們只在 layer 2。」

技術細節總結¶

Task System 核心特性¶

環境變數設定¶

# 加到 ~/.zshrc 或 ~/.bashrc
export CLAUDE_CODE_TASK_LIST_ID="your-project-name"

Tasks 儲存位置： ~/.claude/tasks/your-project-name/

快捷鍵¶

• Ctrl+T — 開啟 task view
• 審查依賴圖
• 追蹤進度

應用場景¶

適合的專案類型¶

✅ 大型重構（跨多個子系統）
✅ 功能開發（有清楚前置步驟）
✅ 測試套件建立（可並行的測試案例）
✅ API 整合（多個端點、各自獨立）
✅ 資料庫遷移（依賴順序明確）

可能不適合¶

❌ 簡單單一檔案修改（不需要協調層）
❌ 探索性重構（還不確定依賴）
❌ 原型開發（快速迭代，結構會變）

與其他概念的連結¶

呼應 MapReduce 模式¶

• Map： 拆解成獨立 tasks，spawn sub-agents
• Reduce： 依賴完成後，結果合併

呼應 Kubernetes 的 Pod 隔離¶

• 每個 sub-agent = 獨立 pod（context window）
• 不會互相干擾
• 透過協調層（dependency graph）通訊

呼應 Git 的 DAG（Directed Acyclic Graph）¶

• Task dependencies = commit graph
• blockedBy = parent commits
• 結構確保順序正確

限制與注意事項¶

目前限制¶

• Layer 2 上限（目前實作）— sub-agents 還不會再 spawn sub-agents
• 7-10 agents 並行上限（資源約束）
• 需要清楚定義依賴（垃圾進 = 垃圾出）

成本考量¶

• 多個 agents 並行 → token 使用量倍增
• 但時間縮短 → 總成本可能相當或更低
• 自動選擇 Haiku/Sonnet/Opus → 成本優化

學習曲線¶

• 需要學會「思考依賴」而非「思考步驟」
• 初期可能過度拆解或欠缺拆解
• 但一旦習慣，效率大幅提升

為什麼這篇值得收藏¶

1. 實戰驗證 — CJ 在真實大型專案中測試，不是理論或 demo
2. 核心洞察 — 「不是 to-do list，是協調層」框架很清楚
3. 未來預測 — Multi-layer swarms 的架構已存在
4. 具體可行 — 環境變數設定、快捷鍵、工作流改變
5. 時代意義 — 開發者角色正在上移一層抽象

延伸閱讀¶

• 如何應用到 Clawdbot 工作流： 參見 Claude Code Task System 工作流分析
• 宝玉的 Context 管理經驗： Claude Code 上下文管理