一個人也能有「團隊」

Claude Code 有一個能力：主對話裡的 agent 可以把工作拆出去，交給獨立的子 agent 執行——各自在乾淨的上下文裡工作,完成後回報結果。聽起來像是免費的平行處理，但用了幾個月後我的結論是：這個能力的價值取決於你會不會判斷「什麼該拆出去」——拆錯方向，反而更慢更差。

適合拆出去的工作形狀

判斷標準濃縮成一句：過程龐雜、結論精簡、不需要中途干預的工作。

最典型的是搜索盤點類任務：「找出專案裡所有還在用舊版某函式的地方」「盤點哪些 API 端點缺少某類測試」。這類工作的過程會產生大量中間結果——幾十次檔案搜尋、上百段程式碼片段——但我真正需要的只是最後那份清單。讓子 agent 在自己的上下文裡消化這些雜訊，主對話只接收濃縮後的結論，主線的上下文品質被保護住了。這很重要：主對話的上下文塞滿搜尋殘渣後，agent 對真正任務的注意力是肉眼可見地下降的。

平行化的甜蜜點也在這裡：幾個互不相依的盤點任務同時發出去，等於同時有幾個研究員在幫你翻資料——Day 22 那次「找出所有 LLM 呼叫點」的掃蕩，就是這種形狀。

不適合拆出去的工作形狀

反過來，三類工作我一定留在主對話：

需要持續判斷、方向會中途調整的。 設計討論、邊做邊發現問題的重構——這類工作的價值恰恰在互動的來回裡，拆給一個不能中途對話的子 agent，等於把方向盤交給一個看不到路的司機。

涉及商業判斷或風險決策的。 動到錢、動到使用者承諾、動到 Day 14-15 那些紅線區的改動——這些連主對話的 agent 都只有提案權，更不可能下放給子 agent。

依賴大量主對話脈絡的。 子 agent 是失憶的（Day 24 的機制它只有部分繼承），它不知道你們剛剛討論了什麼。如果一個任務需要那些脈絡才能做對,拆出去的溝通成本（把脈絡完整寫進任務描述）可能比自己做還高。

交辦的品質決定結果的品質

被坑過幾次後學到的：給子 agent 的任務描述，要當成給外包工程師的需求文件來寫。 具體差異：

• 壞的交辦：「檢查一下通知模組有沒有問題」——它會用自己的想像定義「問題」，回來一份不痛不癢的報告
• 好的交辦：「列出通知模組裡所有在迴圈內執行資料庫查詢的位置，每一處標注查詢的資料是否跨迭代不變」——範圍、判準、輸出格式都明確

差別的本質：子 agent 沒有你的隱含知識，你沒寫的它就用預設值填，而它的預設值來自「一般專案的常識」——恰恰不包含你這個專案的特殊性（還記得 Day 3 嗎？專案的特殊性正是地雷的來源）。

一人公司視角的總結

這套多 agent 機制對一人團隊的真正意義,是第一次擁有了「委派」這個管理動作。而它逼你學的,跟真人團隊的管理是同一課：清楚的任務定義、明確的驗收標準、對「什麼不能委派」的自覺。管理能力突然變成了一人公司的核心技能——這句話五年前聽起來是笑話，現在是日常。