Claude Code 嘅 Task 系統揭示咗 AI 原生工程師嘅核心能力

上個禮拜，Claude Code 靜靜雞將 Todo 改名做 Task。睇落只係術語上嘅調整，但其實標誌住一個全新系統嘅開始。

Todo 係 Claude 自己一個維護嘅記憶清單 - 單一代理嘅個人備忘錄。Task 係多個代理共享嘅工作單位。呢個分別改變咗 AI 編程工具嘅範式。

即係話，AI Swarm 所需嘅新抽象單位已經出現咗。

核心係「委派」，唔係「自動化」

以前嘅 Claude Code 係單一大腦。將複雜項目交俾佢，佢會喺中途唔記得之前做過嘅嘢，最後喺完成大約 60% 嗰陣被迫重新嚟過，不斷重複。

新嘅 Task 系統喺架構上完全唔同：

• 你同團隊負責人傾偈。 負責人唔會直接寫 code。佢負責規劃、委派同綜合。
• 你批准計劃之後，專業代理會被建立出嚟，並行工作。

呢個唔係自動化 - 係委派。兩者嘅分別好關鍵。自動化係為已知流程寫腳本。委派係定義目標，信任結構化嘅團隊自己搵到執行路徑。

依賴關係圖先係真正嘅武器

Task 系統嘅核心特性係任務間嘅依賴關係（blockedBy）。任務 3 喺任務 1 同 2 完成之前根本開始唔到。

點解呢樣咁重要？

以前，Claude 需要喺腦入面保持成個計劃。隨住上下文變長，佢自然會唔記得計劃嘅部分內容。Session 越長，偏差累積越多。

而家，計劃本身已經被外部化同結構化。就算上下文被壓縮或者代理被替換，計劃都仲喺度。依賴關係圖充當咗超越單一代理記憶嘅持久化協調層。

並行處理係免費附送嘅

分配七到十個任務，系統唔會再順序執行。冇依賴關係嘅任務會同時運行。快速搜尋交俾 Haiku，實作交俾 Sonnet，複雜判斷交俾 Opus - 模型分配根據任務特性自動完成。

呢個係結構化任務設計嘅直接結果。工作分解越乾淨、依賴定義越準確，系統就能提取越多嘅並行性。你唔使明確優化並行 - 好嘅任務架構自然會帶嚟並行性。

工作變成咗編排

Swarm 文件揭示咗清晰嘅模式：

• Parallel Specialists：多位專家同時審查 - 安全、效能、型別檢查同步進行。
• Pipeline：研究 → 規劃 → 實作 → 測試 - 每個階段依賴於上一個階段嘅順序流。
• Self-Organizing Swarm：代理從共享任務池入面自己攞未阻塞、未分配嘅任務。

工作唔再係寫 code。工作係設計邊啲代理做咩、按咩順序、佢哋之間有咩依賴關係。

Swarm 效率嘅關鍵在於任務設計

優化 Swarm 效能有三個槓桿：

• 任務粒度：任務越細，並行率越高，但代理間通訊開銷都越大。
• 角色分離：專業化提升質素，但可能喺負載唔均嘅代理上產生瓶頸。
• 依賴設計：結構化咩嘢必須先完成先可以令下一步無阻塞噉運行 - 呢個就係工作流嘅拓撲結構。

根據我親身實驗，第三個槓桿嘅影響最為顯著。任務粒度同角色分離相對直覺。依賴設計需要諗工作本身嘅形態 - 我叫呢個做依賴拓撲設計。

呢個先係 Swarm 時代真正嘅核心能力。唔係寫更快嘅 code，亦唔係揀更好嘅模型。而係建構工作流嘅結構，令最多數量嘅代理能夠零等待噉運行。

從寫 code 到設計工作方式

方向好清楚：

最初，我哋寫 code。然後，我哋設計系統。而家，我哋設計工作本身嘅運作方式。

你唔係喺用 AI 工具。你係喺指揮一支 AI 團隊。最先明白呢個分別嘅人，將會主導未來一年嘅軟件開發。

從 Todo 到 Task 嘅改動表面上好細。但喺下面，佢鋪好咗一個新世界嘅基礎 - 喺呢個世界入面，工程師嘅核心產出唔再係 code，而係機器之間嘅協作架構。