Gary Talks Stuff：Claude Dynamic Workflow 介紹

開場閒聊

Gary 一開場就用了一個很生活化的比喻來介紹 Dynamic Workflow：「以前你叫 Claude 做事，是他一個人慢慢做。現在你一句話下去，它會自己拉幾十個，甚至上百個 agent 同時開工，每一個負責一小塊。」

他笑著說，本來可能要排上一整個季度的大工程，或者好好寫一份很長的提示詞，現在一句話，一天內就可以搞定。因為 Claude 會幫你組建這個專案小組，而不是你一個人從頭慢慢磨。

不過他也坦承，很多人其實搞不清楚 Dynamic Workflow 到底是什麼、什麼時候該用。所以這集他決定把一切講清楚——從背後怎麼運作，跟其他功能的差異，優勢劣勢，再到實際的 Use case。

懶人包速覽

核心痛點	解決方案 / 關鍵觀點
大任務讓 Claude 主對話卡死，context 越跑越腫	Workflow 把指揮和整理搬到背景獨立環境，主 session 永遠乾淨
分不清 Workflow、Subagent、Agent Team、Skill 的差別	關鍵在「下一步由誰決定」——寫死程式碼是 Workflow，臨場看狀況是其他功能
一次開幾十個 Agent 太燒 token，不敢嘗試	三招省成本：便宜模型跑廣度、旗艦模型做收束、預算上限、先拿小塊試水溫
不知道什麼任務適合 Workflow	任務能切成大量獨立小塊 → Workflow 主場；必須一步接一步 → 別用

這集 Gary 把 Anthropic 3.0 預備推出的 Dynamic Workflow 功能做了非常完整的拆解。

如果你是 AI Agent 的重度使用者，或者正在研究怎麼把大規模的開發任務交給 AI 去跑，這集提供的架構思維很有參考價值。

Dynamic Workflow 是什麼？一句話說清楚

Dynamic Workflow 的核心概念其實很單純：Claude 不是直接動手做，而是先幫你寫一段 JavaScript 腳本。

這段腳本才是真正去幹活的東西。它跑在背景一個獨立的環境裡，所以主對話完全不會卡住。以前你叫 Claude 跑一個大任務，那個對話就卡在那邊，你只能乾等。現在你在背景跑 workflow，還可以繼續跟同一個 session 的 Claude 對話，請它幫你做別的事。

等 workflow 跑完後，Claude 會帶著結論回來找你。

這段 JavaScript 做的事情是指揮——把你的大任務拆成一堆小任務，然後同時派發出去，一次拉幾十個甚至上百個 subagent 平行幹活。

Gary 舉了一個例子：第一階段先拉五個 agent 從五個不同角度收資料；第二階段再拉二三十個，把搜到的東西一篇一篇深度讀；第三階段又拉一批出來，專門互相挑錯、互相驗證。每個階段要拉幾個 agent、用什麼模型，都是完全不一樣的，而這些 Claude 都會在寫腳本時自己安排好。

最關鍵的設計是：這幾十、上百個 agent 跑出來的中間結果，全部留在腳本的變數裡面，不會塞進你的主對話。Claude 的主 context 最後只會收到一份整理好的最終答案。

Dynamic Workflow 的品質把關機制

Workflow 不只是叫很多人來跑這麼簡單，它還內建了一層品質把關。

Gary 解釋說，你可以讓好幾個 agent 各自從不同角度去切同一個問題，然後再派另外一批 agent 專門去反駁、去挑前面那批的毛病。一路吵到答案收斂，才回報給你。

一個人檢查自己的作業很容易有盲區，但找另外一批人專門來挑你毛病，能撐過這種攻擊還站得住的結論，當然比較可信。

而且你可以指定不同階段用不同的模型。前面那種大量平行撒網式的搜尋，可以用便宜的模型（像是 Haiku）去跑；最後收尾做總結收斂、需要更強推理能力時，再換上 Opus 3.5 這樣的旗艦模型。這樣又快又省。

Function Family：Workflow 跟其他功能的差別

Gary 花了一段時間解釋最常讓人搞混的部分——Skill、Subagent、Agent Team、Workflow、Go 指令到底差在哪。他給了一個非常清楚的判斷框架。

關鍵問題：「下一步由誰決定？」

如果下一步是寫死在程式碼裡、由腳本決定的，那就是 Workflow。如果下一步是 Claude 臨場看狀況自己決定的，那就是另外那幾個。控制權是在程式碼手裡，還是在模型手裡，就差在這。

Skill：一本食譜

Skill 本質上就是一份說明書，告訴 Claude 遇到什麼情況該用什麼工具、按什麼步驟做、有什麼限制。它不是一個 Agent，它就是一份寫給 Agent 看的指令。

Skill 跟 Workflow 根本不是同一個層級的東西。Skill 是事情要怎麼做，Workflow 是同時叫多少人去做。它們甚至可以疊在一起——你的 Workflow 拉出來的那些子 Agent 裡面，就可以去呼叫你寫好的 Skill。

Subagent：一個實習生

Subagent 是 Claude 臨時派出去的一個小弟，幫你跑一件事，跑完結果直接塞回你的主對話。

Gary 打了一個很好的比方：Sub-agent 就像你叫一個實習生去查個資料，他查完回來把整疊資料堆在你桌上。一兩個還好，但同時叫一百個實習生去查一百件事，那一點一點的資料全堆到你桌上，這張桌子馬上就飽了。

Workflow 就是那個先在外面把一百份資料整理好、只把結論端上桌的人。正因為指揮跟整理這些事全搬到桌子外面去做，主對話那張桌子永遠是乾淨的。

Agent Team：一個作戰室

Agent Team 像是一個工作群組，裡面好幾個 agent 彼此會互相講話、討論、辯論、共用同一張任務清單，每個人還有自己的角色跟分工。

Workflow 的 agent 不是這樣——他們各走各的車道，彼此完全不講話，誰也不知道別人在幹嘛。整個過程更像是一條工廠的流水線。

Go 指令：深度 vs 廣度

Go 指令的精神是深度——它是一個迴圈，會一直跑、一直回頭，確認達標沒？沒達標就繼續，直到達標才停。Workflow 的精神剛好相反，是廣度——它不是一直回頭檢查，而是把任務一次橫向鋪開，幾十個 agent 同時做，做完匯整就結束了。

Gary 用一個階梯來總結：最下面是你直接跟 Claude 對話，往上一階是 Sub-agent（把雜事丟出去平行做），再往上是 Agent Team（讓 agent 互相溝通補位），最上面才是 Workflow（用腳本指揮上百個 sub-agent）。越往上，火力越大，能做的越複雜。

Workflow 的優點與缺點

優點

第一，省主 session 的 context。傭兵軍團（workflow）在過程中把手弄得那麼髒，一大堆過程都不會影響到你的得力助手（主 session 的 Claude）。所以跑再大的任務，主對話也不會越跑越腫、越跑越頓。

第二，可以重跑、可以觀測、可以驗證。因為它是一份程式碼，不是你臨場講的一段話。你可以存起來下次再跑，可以一個階段一個階段看它跑到哪、燒了多少 token。舉例來說，如果你每個禮拜都要把新的分支做一次完整的 review，把跑順的 workflow 存起來，以後每個禮拜叫它出來跑一次就好。

第三，規模。它可以同時組織超級大量的 agent 一起跑。如果需要同時 10 個 agent 掃程式碼，掃完後再丟給 10 個 agent 做驗證，這種需要動用一個師的軍隊的任務就很適合 workflow。

第四，可信度。它會自己派 agent 互相挑錯，多角度收斂，產出通常比單純叫 Claude 跑一遍更不容易出包。

缺點

最大的缺點就是貴。它拉出來的每一個 Agent 都是一次完整的 co-call，每一個都要自己讀一輪 context、自己跑、自己花 token。一次拉幾十個、幾百個，這個帳對於個人用戶來說要特別注意。

第二個缺點是它根本不適合日常小事。如果只是改一兩行、問個小問題、查個普通資料，動用 workflow 叫殺雞用牛刀，純粹浪費錢。

第三個是它目前還處於 Research Preview 階段，使用時仍要小心。

省成本三招

針對最燒錢的問題，Gary 分享了三個實戰技巧：

第一招，便宜模型跑廣度，旗艦模型做收束。 前面大量撒網的工作丟給 Haiku 這種便宜的去跑，最後收斂總結才用 Opus 3.5。光這一招就能省掉一大筆錢。

第二招，直接設定預算上限。 在下指令的時候就告訴 Claude 最多給你燒多少 token，它就不會超過。

第三招，先拿一小塊試水溫。 不要一上來就叫他燒整個 repo，先跑一個資料夾、一個比較窄的問題，看看大概花多少。如果覺得好用划算，再放大規模。

QA 精選

Q1：Dynamic Workflow 跟一般直接下 prompt 叫 Claude 做事，最大差別在哪？

最大的差別在於中間過程的管理方式。直接下 prompt 時，Claude 產生的所有中間結果都會留在主對話的 context 裡，任務越大 context 越腫。而 Dynamic Workflow 指揮的幾十、上百個 agent 的中間結果全部留在腳本變數中，不會進入主 session。Claude 的主 context 最後只會收到一份整理好的最終答案。這也讓 workflow 能夠執行超大型任務（如掃描整個 repo 的 bug）而不會卡死主對話。

Q2：Agent Team 跟 Workflow 都有多個 agent，什麼時候該用哪個？

關鍵在於 agent 之間需不需要溝通。Agent Team 的 agent 彼此會對話、辯論、共用任務清單——就像一個工作群組。如果你在設計產前後端，希望前端 agent 和後端 agent 能互相考量彼此的架構，那用 Agent Team 比較好。

Workflow 的 agent 則各走各的車道，彼此不講話，整個過程更像工廠流水線。如果你只需要大量平行處理（同時掃描多個檔案、多角度研究），不需要 agent 間互動，Workflow 更適合。

Q3：為什麼 Dynamic Workflow 產出的結果通常比較可靠？

因為它內建了多層驗證機制。Workflow 可以讓好幾個 agent 從不同角度切入同一個問題，然後再派另一批 agent 專門去反駁、挑毛病。能撐過這種交叉攻擊還站得住的結論，自然比單次 prompt 的結果更可信。Gary 比喻說：「一個人檢查自己的作業很容易有盲區，但找另外一批人專門來挑你毛病，能撐過這種攻擊的結論才比較可信。」

Q4：我是個人開發者，怎麼用最低成本體驗 Workflow？

Gary 推薦三種方式。第一，從 Claude Code 內建的 Deep Research 功能開始（輸入 /deep-research 即可）——這本身就是一個現成的 workflow，而且第一次跑之前會先停下來把整個計劃攤給你看，問你要不要跑，甚至可以先點開看原始腳本。第二，用便宜模型（Haiku）跑廣度，旗艦模型（Opus）做收束。第三，先拿小範圍測試——跑一個資料夾或一個窄問題看看 token 消耗，划算再放大。

Q5：Workflow 執行到一半能看進度嗎？

可以。執行時打 /workflows 就能看到完整進度——每個階段拉了幾個 agent、各自燒了多少 token、跑了多久，全部看得到。覺得不對勁隨時可以停。跑出滿意的 workflow 還可以存起來，下次直接呼叫同樣的流程，不需要重新寫 prompt。

主編隨筆

Gary 在這支影片中把 Dynamic Workflow 定位成「用腳本指揮 agent 的工廠流水線」，這個類比確實很精準。但我認為有一個沒被深入討論的面向值得補充——那就是「Workflow 的可組合性」。

影片中提到 Skill 可以跟 Workflow 疊加使用，但其實 Workflow 之間也能互相組合。想像一下：你可以先寫一個「程式碼審查」的 Workflow，再寫一個「專案結構分析」的 Workflow，然後在一個更大的 Workflow 中同時呼叫這兩個子流程，讓結果互相參照。這種多層嵌套的架構，其實就是軟體工程中的 Composition Pattern，搬到 AI Agent 的世界裡威力非常大。

以我自己的經驗來說，這種可組合的思維才是最值得早期建立的。現在大部分人還在適應「讓一個 Agent 做事」，但下一步的競爭力會在「設計 Agent 協作的架構」。就像當年從寫單執行緒程式進步到寫微服務架構一樣，越早建立這個思維習慣，在工具成熟的時候就越有優勢。

不過 Gary 說得很對：不要因為功能新就什麼都硬塞給它。任務不對，再強的工具也只是在幫你燒錢而已。

結語

Gary 最後回到他一直強調的觀念：AI 工具會不斷推陳出新，每次都聽起來很厲害，但重點從來都不是哪個功能最強，而是你手上這個任務到底適不適合它。

Dynamic Workflow 是 Anthropic 在 Agent 編排方向上的一大步——它把拆解、編排、寫腳本這三件事全部自動化了。你只要說出要做什麼，剩下的交給 Claude。但它的適用場景很明確：需要大量平行處理、且任務可以拆成獨立小塊的工作。日常小事、必須接續進行的流程，都不適合。

對於已經在用 Claude Code 的開發者來說，從 /deep-research 開始體驗是最快的入門方式。先感受一下什麼叫「一句話開上百個 agent 幫你幹活」，再決定這是不是你需要的火力。