Dynamic Workflows 跟 Subagent 是同一件事嗎，複雜任務該用哪個？
不是同一件事，兩者的差別在於「誰掌握計畫」。用 Subagent 時，是 Claude 動態決定要不要派生、派生幾個、各自做什麼——這個決策過程本身是模型即時判斷的；Dynamic Workflows 則是先寫成一份固定的程式腳本，明確定義好整個協調流程，再由這份腳本去指揮一大批 Subagent 平行執行，控制流程本身是預先寫死、確定性的，不是每次臨場決定。
對日常任務而言，Subagent 已經足夠——它是新手最先會接觸、也最直覺的多任務處理方式。Dynamic Workflows 適合的是規模大到需要跑數十甚至上百個平行實例、且流程本身值得寫成可重複腳本的場景，這已經超出多數人日常會遇到的任務規模，不需要為了「聽起來比較先進」而優先選它。
為什麼「不確定任務範圍」時，反而不適合用多個 Subagent？
因為多個 Subagent 的運作前提是「你已經知道要拆成哪幾塊」——你得先決定角色、分工、每個 Subagent 該負責的範圍，這個切分本身需要對任務有足夠的理解。如果你連任務範圍都還沒摸清楚，切分本身就是在猜，猜錯了就要重新協調，這個重新協調的成本，往往比一開始就讓單一個 Agent 自己邊探索邊調整還要高。
單一 Agent 的優勢在這種情境下反而凸顯出來：它可以根據探索過程中發現的新資訊，動態調整接下來要做什麼，不需要先固定好一份分工表。這也是為什麼業界建議「任務範圍不確定時，優先用單一自適應 Agent，而不是急著切分成多個角色」——先把範圍摸清楚，真的需要平行處理時再考慮拆分,通常比一開始就假設好分工更穩妥。
巢狀 Subagent 的「二到三層甜蜜點」是絕對規則嗎？有沒有例外？
不是絕對規則，是一個實務上多數場景適用的經驗值。它的前提假設是「合併回傳結果的成本會隨深度疊加」，這在大多數任務裡確實成立，但如果你的任務本質上就是需要更深層次的獨立切分（例如真的有一個天然的四層架構，每一層都彼此獨立、回傳的摘要也很精簡），深度超過三層不一定就是錯的。
真正該檢查的不是「有沒有超過二到三層」這個數字本身，是「往下多切一層，換來的平行處理效益，有沒有超過多這一層要付出的合併成本」。如果每次往下切都在賠本，那就是深度過頭了；如果任務結構本身天生就需要更深的層次、而且每一層真的省下可觀的時間，數字本身不是重點,實際的效益才是判斷標準。
我是新手，剛開始接觸 Subagent，該怎麼避免一開始就走上「過度設計」的路？
最實用的起手式是先強迫自己走過文章裡那個自問流程，不要跳過：先問任務能不能拆成互不依賴的子任務，答不出來就先別拆；再問拆出來的過程雜訊,是不是你真的不想看到的東西，答案模糊的話,先試著讓單一 Agent 直接處理,觀察主對話有沒有真的被雜訊塞滿到難以閱讀,如果沒有,代表這個任務可能根本不需要 Subagent。
另一個實用習慣是,先用單一 Agent 跑過一次任務,親眼觀察它的中間過程量有多大、有沒有天然可以拆開的獨立段落,再決定要不要為下一次同類任務設計 Subagent 分工——用「先體驗問題,再設計解法」取代「先假設會複雜、預先武裝多個 Subagent」,能有效避免把簡單任務搞複雜的傾向。
Subagent 火起來之後，一個常見的新習慣是：遇到看起來複雜的任務，直覺反應就是「丟給 Subagent 處理」。這個直覺有一半是對的——Subagent 確實能帶來獨立上下文、平行處理的好處；但另一半是危險的，因為「看起來複雜」不等於「真的需要 Subagent」，把不該拆分的任務硬拆成多個 Subagent，換來的往往是協調成本超過效益，而不是效率提升。
Subagent 的核心價值是「獨立上下文」和「平行執行」。當一件工作會產生大量你不關心的中間過程（翻閱大量檔案、跑一堆探索性指令），或是一件工作可以拆成幾個彼此獨立、互不依賴的子任務，這時候 Subagent 才真正發揮作用——例如同時稽核四個不同模組的安全性，四個 Subagent 分頭進行，彼此的探索過程不會互相干擾，最後只把結論帶回主對話。
如果任務本身是線性的、每一步都依賴前一步的結果，拆成多個 Subagent 平行處理不但沒有幫助，反而會製造協調上的複雜度——你得想辦法讓後面的 Subagent 拿到前面 Subagent 的結果，這中間的溝通成本，很多時候比直接讓單一個 Claude 循序處理還要高。另一種常見的過度設計是任務範圍本身還不確定：如果你連這件事要拆成幾塊都還沒想清楚，硬性分派給多個固定角色的 Subagent，反而會讓 Claude 沒辦法根據探索過程中發現的新資訊動態調整方向，一個能持續學習、邊做邊調整的單一 Agent，這時候比預先切好角色的多 Subagent 更靈活。
Subagent 可以再往下派生自己的 Subagent，形成階層——一個負責模組的 Subagent，可以再往下拆給檔案層級的 Subagent。這在處理層次分明的大型任務時很有用，但深度每往下一層，token 成本就會顯著攀升，業界的實務經驗大致落在「二到三層是效益甜蜜點，超過這個深度，光是合併各層回傳的摘要所花的時間，就會蓋掉平行處理省下的時間」。深度不是越深越好，是要對應到任務本身真的有這麼多層次的獨立性，而不是為了展示「我用了很多 Subagent」而硬堆深度。
面對一個看起來複雜的任務，可以先問三個問題：這件事能不能拆成幾個彼此不依賴結果的子任務？如果答案是否定的（每一步都要等前一步的結果），那就該用單一 Agent 循序處理，不該拆 Subagent。如果答案是肯定的，再問：這些子任務各自的探索過程，是不是我完全不需要看到的雜訊？如果雜訊量不大、你其實也不介意它出現在主對話裡，那麼直接處理可能比啟動獨立實例更省事。只有當「可以獨立拆分」跟「過程雜訊確實需要隔離」兩個條件同時成立，才是 Subagent 真正該出場的時候。
每啟動一個 Subagent，都有一定的固定開銷——啟動獨立實例本身、以及最後把多個 Subagent 的回報整合起來的合併成本。如果任務本身不具備真正的並行性，這些開銷不會被平行處理省下的時間抵銷，反而是純粹的額外花費；巢狀深度也是同樣的邏輯，往下每多一層,合併回傳結果的成本就疊加一次。判斷該不該用 Subagent、該用到多深，本質上是在幫你的預算把關——用對地方，Subagent 能大幅縮短處理時間；用錯地方，你付出的是實質更高的 token 成本，換回的可能只是「看起來比較厲害」的執行方式，而不是真正的效率。