為什麼Dynamic Workflows自動工作流如此重要?

作者:字節筆記本
日期:2026年5月31日 下午1:38
來源:WeChat 原文

整理版優先睇

速讀 5 個重點 高亮

Dynamic Workflows將編排邏輯代碼化,係解決大任務協調嘅關鍵

整理版摘要

呢篇文章係講Dynamic Workflows呢個Claude Code新功能點解咁重要。作者由Agent編程嘅演進講起,指出舊有subagent同Agent Teams都依賴Claude現場臨時調度,任務一多就會出現上下文膨脹問題。

然後作者用BunZig遷移到Rust嘅實際例子,說明Dynamic Workflows點樣將複雜工程拆成流水線:先分析結構、再分發並行遷移、然後交叉審查、最後進入fix loop。整個過程由一段JavaScript腳本控制,確保任務唔會跑偏。作者仲比較咗Dynamic Workflows同n8n等工具嘅異同,強調呢個功能嘅核心係「讓模型自己寫工作流」,將編排邏輯代碼化,帶嚟可讀、可審、可複用三個好處。

最後,作者指出Dynamic Workflows適合範圍大、步驟多、需要並行同反覆驗證嘅大工程,而一兩步嘅小任務就唔值得用。佢仲介紹咗Pi工具嘅插件實現方法,等非訂閲用戶都可以透過安裝pi-dynamic-workflows來體驗自動工作流,直接對Pi講指令就可以分析項目、做代碼審查等。

  • Dynamic Workflows將編排邏輯寫成JavaScript腳本,由代碼控制流程,唔再靠模型臨場判斷。
  • 同subagent最大分別係:subagent幫手做任務,Workflow負責任務分配同協調。
  • 實例Bun遷移Rust,11日完成75萬行Rust代碼,99.8%測試通過,證實大工程可以靠流水線高效完成。
  • 工作流代碼化帶嚟三個好處:可讀(睇到安排)、可審(運行前檢查)、可複用(沉澱為長期能力)。
  • 適用場合係範圍大、步驟多、需要並行驗證嘅工程,而小任務唔值得用;Pi工具嘅插件可以免費體驗。
值得記低
流程

pi-dynamic-workflows 安裝與啟用

在Pi中執行 `pi install npm:pi-dynamic-workflows` 安裝,然後執行 `/reload` 啟用。之後可直接對Pi講「運行一個工作流,分析當前項目結構」等指令。

整理重點

Agent編程嘅演進同侷限

以前講Agent編程,大多數時候係講一個模型喺Claude Code對話裏邊想邊做。佢讀代碼、改文件、跑命令、睇報錯,然後繼續下一步。

後嚟有咗子Agent,主Agent可以派幾個小弟出去查資料、讀文件、分析問題。再後嚟有咗Agent Teams,多個Claude Code實例可以並行協作。不過呢啲能力有個共同問題:編排者依然係Claude自己,即係下一步派邊個做、做完點合併、發現問題點回滾、點交叉驗證,都係靠Claude喺當前上下文裏臨時判斷。

上下文膨脹

臨時判斷

整理重點

Dynamic Workflows嘅核心原理

Dynamic Workflows換咗個思路:佢唔再讓Claude喺對話裏一輪一輪調度,而係讓Claude先將點樣調度寫成一段JavaScript腳本。呢個腳本可以有循環、分支、併發、校驗、彙總。

寫完之後,腳本交畀本地運行時執行。只有在腳本執行到需要模型幹活嘅地方,先臨時拉起一個子Agent。即係將編排邏輯代碼化,以前Claude係現場臨時指揮,而家Claude更似先畫出施工圖,然後讓一班Agent按圖施工。

確定性流程

代碼化編排

按圖施工

  1. 1 第一步:分析Zig代碼結構同生命週期
  2. 2 第二步:將唔同文件分發畀唔同Agent並行遷移
  3. 3 第三步Reviewer Agent對遷移結果做交叉審查
  4. 4 第四步:編譯測試Fix Loop:報錯、修復、再跑,直到收斂
整理重點

實例與工作流代碼化嘅好處

Claude Code官方例子為例,Bun作者Jarred SumnerDynamic Workflows將Bun運行時從Zig遷移到Rust。結果係11日、約75萬行Rust代碼、99.8%嘅原有測試通過。

11日

75萬行Rust代碼

99.8%測試通過

呢種跨語言遷移項目裏有大量文件、生命週期、內存所有權、編譯錯誤、測試迴歸,單個Agent就算能力再強都好難靠一輪對話協調曬。Workflow嘅做法更像流水線,保證任務唔跑偏。

工作流代碼化帶嚟嘅三個好處

  1. 1 可讀:你可以睇到Claude到底準備點樣安排件事。
  2. 2 可審:你可以在運行前檢查佢係咪要亂改文件、亂跑命令、亂燒token。
  3. 3 可複用:一個好嘅Workflow可以保存落嚟,變成項目裏嘅長期能力。

呢啲好處令Dynamic Workflows比普通subagent更重要:subagent似一次性幫手,Workflow似沉澱落嚟嘅生產流程。

整理重點

適用場景同Pi工具實作

Dynamic Workflows唔適用所有場景,一兩步就搞得掂嘅小任務完全冇必要起Workflow。佢適合範圍大、步驟多、需要並行同反覆循環嘅大工程,例如:

  • 全倉庫安全審計
  • 從舊框架遷移到新框架
  • 大規模API替換
  • 找性能瓶頸
  • 讓多個Agent從唔同角度審查一個方案,再派對抗性Agent去推翻

對於非訂閲用戶或者想結合Deepseek等開源模型嘅用戶,可以用Pi工具嘅插件pi-dynamic-workflows來體驗。安裝好簡單:

程式內容 bash
pi install npm:pi-dynamic-workflows
/reload

啟用之後唔使自己寫代碼,直接對Pi講指令就得,例如:

  • 運行一個工作流,分析當前項目結構,並總結主要模塊
  • 「運行一個工作流,從架構、安全、性能、可維護性幾個角度審查呢個項目,最後畀我一份改進建議」
  • 「運行一個工作流,揾出呢個項目裏最值得優先重構嘅文件、重複邏輯同潛在風險」
  • 「運行一個工作流,分別從技術實現、使用場景、優缺點同替代方案研究呢個主題,最後彙總」

Pi會自動生成工作流腳本

Esc取消

普通Pi係一個Agent從頭做到尾,pi-dynamic-workflows係讓Pi先寫一張任務拆解圖,再派多個子Agent並行幹活,最後彙總。

 

唔講抄襲先,告Anthropic!開源團隊爆Claude新功能Dynamic Workflows抄襲點解咁多間公司都將自己嘅功能拓展押注喺呢個自動工作流上面?

以前我哋講Agent編程,大多數情況係講一個模型喺Claude Code對話入面邊諗邊做。

佢讀code、改檔案、行指令、睇錯誤,然後繼續下一步。

之後有咗subagent,主Agent可以派幾個細佬出去查資料、讀檔案、分析問題。Claude Code Sub Agents嘅正確打開方式同案例演示

再之後有咗Agent Teams,多個Claude Code實例可以好似一個小團隊咁並行協作。一個人就係一間公司!Claude Code團隊組織化模式高效使用

呢啲能力當然有用,但佢哋有個共同問題:編排者仲係Claude自己

即係話,下一步派邊個去做、做完之後點樣合併、發現問題之後點樣回滾、點樣交叉驗證,都係靠Claude喺當前context入面臨時判斷。

任務細嘅時候冇問題,一旦任務變大,中間結果愈來愈多,Claude嘅context就開始俾過程信息塞滿。

佢唔係唔識做,而係協調成本愈來愈高。

Dynamic Workflows就換咗個諗法。

佢唔再俾Claude喺對話入面一輪一輪咁調度,而係俾Claude先將點樣調度寫成一段JavaScript腳本

呢個腳本入面可以有循環、分支、並行、校驗、彙總。寫完之後,腳本交俾本地運行時執行。只有喺腳本執行到需要模型做嘢嘅地方,先臨時拉起一個subagent。

即係話,將編排邏輯代碼化咗。

以前Claude係現場臨時指揮,睇到一個結果,再決定下一步。

而家Claude更加似係先畫好施工圖,然後俾一羣Agent按圖施工。中間過程唔再全部塞返主對話視窗,而係留喺腳本變數入面,最後只係將彙總結果交返嚟。

呢個就係Dynamic Workflows同subagent最大嘅分別。

subagent解決嘅係多任務,Workflow解決嘅係任務點樣分配同協調。

以Claude Code官方嘅例子,Bun嘅作者Jarred Sumner用Dynamic Workflows,將Bun運行時從Zig搬去Rust。結果係11日、大約75萬行Rust code、99.8%嘅原有測試通過。

圖片

喺呢種跨語言搬遷項目入面,有大量檔案、生命週期、記憶體所有權、編譯錯誤、測試回歸。單一個Agent就算能力再強,都好難靠一輪對話將成個任務協調好。

Workflow嘅做法更加似流水線。

第一步,先俾一批Agent分析Zig code入面嘅結構同生命週期。

第二步,將唔同檔案分派俾唔同Agent並行搬遷。

第三步,再俾reviewer Agent對搬遷結果做交叉審查。

第四步,進入編譯同測試嘅fix loop:報錯、修復、再執行,直到盡量收斂。

呢個就係佢真正勁嘅地方,Agent將複雜工程拆成可執行流程。

每個節點可以係一個Agent,但真正保證任務唔會走樣嘅,係嗰段Workflow腳本。

呢個都解釋咗點解佢同n8n、Dify、Coze呢啲工作流工具既似又唔似。

似,係因為佢哋本質上都係確定性流程 + 節點入面調用LLM流程本身唔係模型臨場決定,而係預先寫好嘅。

唔同嘅係,n8n入面嘅流程通常係人拖出嚟嘅圖,Dynamic Workflows入面嘅流程係Claude根據當前任務現場寫出嚟嘅一段code。

俾模型自己寫工作流。

真正大任務難嘅地方,往往唔係某一步點樣做,而係成套流程點樣組織。幾時並行,幾時彙總,幾時交叉驗證,幾時進入循環,幾時停止。

呢啲嘢如果都靠模型喺對話入面臨時諗,就好容易隨住context膨脹而失控。

但一旦佢變成code,就有三個好處。

第一,可讀。你可以睇到Claude到底準備點樣安排呢件事。

第二,可審。你可以喺執行之前檢查佢係咪會亂改檔案、亂行指令、亂燒token。

第三,可重用。一個好嘅Workflow可以保存落嚟,變成項目入面嘅長期能力。

呢個亦係我覺得佢比普通subagent更加重要嘅原因。subagent更加似一次過嘅幫手,Workflow更加似一套沉澱落嚟嘅生產流程。

當然,佢並唔係適用於所有情況。

一兩步就搞得掂嘅小任務,完全冇需要起Workflow。叫幾十個Agent並行做嘢,token成本一定更高,佢適合嘅係啲範圍大、步驟多、需要並行、需要驗證、需要反覆循環嘅大工程。

例如全倉庫安全審計、從舊框架搬去新框架、大規模API替換、揾性能瓶頸、讓多個Agent從唔同角度審查一個方案,再派對抗性嘅Agent去推翻佢。

過去我哋成日討論邊個寫code更勁,邊個修bug更穩,邊個context更大。

接下來可能仲要討論另一個問題:邊個更識得組織一支Agent隊伍。

單一個模型再勁,都只係一個大腦。真正嘅大工程,從來唔係靠一個人由頭寫到尾,而係靠一套流程、一套分工、一套檢查機制。

係會先判斷呢件事應該點樣拆,邊啲部分並行做,邊啲部分需要審查,邊啲地方需要循環驗證,然後自動生成一套可執行嘅工作流,令佢生成一套穩定推進嘅系統。

之前我哋都介紹過Goals,Codex & Claude Code嘅 /goal 指令高級進階使用技巧Goals更加似係將目標鎖定,讓模型持續向嗰個方向推進。

Dynamic Workflows就係將過程寫低,讓code保證流程唔會走樣。

呢個都解釋咗呢幾間公司點解會將呢種自動工作流作為關鍵性嘅功能組件。

不過目前呢個功能只係俾訂閲用戶使用,對於非訂閲,或者想結合Deepseek呢類開源模型嚟用嘅用戶,我哋可以用PiOpenClaw嘅心臟Pi Agent由入門到精通嘅插件嚟體驗Dynamic Workflows。

安裝步驟如下。


    
    
    
  pi install npm:pi-dynamic-workflows

安裝之後,喺Pi入面執行:


    
    
    
  /reload

咁就啟用咗,唔使自己寫code,直接對Pi講:


    
    
    
  運行一個工作流,分析當前項目結構,並總結主要模塊。

或者:


    
    
    
  運行一個工作流,從架構、安全、性能、可維護性幾個角度審查這個項目,最後給我一份改進建議。

Pi會自動生成工作流腳本,然後調用多個子Agent分頭處理。

以分析一個陌生code base嘅例子:


    
    
    
  運行一個工作流,掃描這個倉庫,告訴我入口文件、核心模塊、配置文件和整體運行邏輯。

做code審查:


    
    
    
  運行一個工作流,從架構、安全、性能、可維護性四個角度 review 當前項目。

重構前分析:


    
    
    
  運行一個工作流,找出這個項目裏最值得優先重構的文件、重複邏輯和潛在風險。

做資料研究:


    
    
    
  運行一個工作流,分別從技術實現、使用場景、優缺點和替代方案几個角度研究這個主題,最後彙總。

佢會顯示類似咁嘅進度:


    
    
    
  ◆ 工作流:inspect_project
  ✓ 掃描
  ✓ 分析
  ✓ 彙總

如果唔想繼續跑,可以㩒 Esc 取消。

普通Pi係一個Agent由頭做到尾,pi-dynamic-workflows 係俾Pi先寫一張任務拆解圖,再派多個子Agent並行做嘢,最後將結果彙總返嚟。

歌手胡彥斌Vibe Coding嘅APP上架咗!

告Anthropic!開源團隊爆Claude新功能Dynamic Workflows抄襲

Claude Opus 4.8發布,疑似蒸餾咗阿里Qwen!

分享我嘅微信公眾號發布工作流

                 

 

 

拋開抄襲不說,狀告Anthropic!開源團隊爆Claude新功能 Dynamic Workflows 抄襲,為啥各家都把自己的功能拓展押注在這個自動工作流上?

以前我們說 Agent 編程,大多數時候說的是一個模型在Claude Code對話裏邊想邊做。

它讀代碼、改文件、跑命令、看報錯,然後繼續下一步。

再後來有了 subagent,主 Agent 可以派幾個小弟出去查資料、讀文件、分析問題。Claude Code Sub Agents的正確打開方式和案例演示

再後來有了 Agent Teams,多個 Claude Code 實例可以像一個小團隊一樣並行協作。一個人就是一個公司!Claude Code 團隊組織化模式高效使用

這些能力當然有用,但它們有一個共同的問題:編排者還是 Claude 自己

也就是說,下一步派誰去做、做完以後怎麼合併、發現問題以後怎麼回滾、怎麼交叉驗證,還是靠 Claude 在當前上下文裏臨時判斷。

任務小的時候沒問題,一旦任務變大,中間結果越來越多,Claude 的上下文就開始被過程信息塞滿。

它不是不會幹,而是協調成本越來越高。

Dynamic Workflows 換了一個思路。

它不再讓 Claude 在對話裏一輪一輪地調度,而是讓 Claude 先把怎麼調度寫成一段 JavaScript 腳本

這個腳本里可以有循環、分支、併發、校驗、彙總。寫完之後,腳本交給本地運行時執行。只有在腳本執行到需要模型幹活的地方,才臨時拉起一個 subagent。

也就是說,把編排邏輯被代碼化了。

以前 Claude 是現場臨時指揮,看到一個結果,再決定下一步。

現在 Claude 更像是先畫出施工圖,然後讓一羣 Agent 按圖施工。中間過程不再全部塞回主對話窗口,而是留在腳本變量裏,最後只把彙總結果交回來。

這就是 Dynamic Workflows 和 subagent 最大的區別。

subagent 解決的多任務,Workflow 解決的是任務如何分配和協調。

以Claude Code官方的例子,Bun 作者 Jarred Sumner 用 Dynamic Workflows,把 Bun 運行時從 Zig 遷移到 Rust。結果是 11 天、約 75 萬行 Rust 代碼、99.8% 的原有測試通過。

圖片

在這種跨語言遷移項目裏面有大量文件、生命週期、內存所有權、編譯錯誤、測試迴歸。單個 Agent 就算能力再強,也很難靠一輪對話把整個任務協調完。

Workflow 的做法更像流水線。

第一步,先讓一批 Agent 分析 Zig 代碼裏的結構和生命週期。

第二步,把不同文件分發給不同 Agent 並行遷移。

第三步,再讓 reviewer Agent 對遷移結果做交叉審查。

第四步,進入編譯和測試的 fix loop:報錯、修復、再跑,直到儘量收斂。

這就是它真正厲害的地方,Agent把複雜工程拆成了可執行流程。

每個節點可以是一個 Agent,但真正保證任務不跑偏的,是那段 Workflow 腳本。

這也解釋了為什麼它和 n8n、Dify、Coze 這類工作流工具既像又不像。

像,是因為它們本質上都是確定性流程 + 節點裏調用 LLM。流程本身不是模型臨場決定的,而是提前寫好的。

不同的是,n8n 裏的流程通常是人拖出來的圖,Dynamic Workflows 裏的流程是 Claude 當前任務現場寫出來的一段代碼。

讓模型自己寫工作流。

真正大任務難的地方,往往不是某一步怎麼做,而是整套流程怎麼組織。什麼時候並行,什麼時候彙總,什麼時候交叉驗證,什麼時候進入循環,什麼時候停止。

這些東西如果都靠模型在對話裏臨場想,就很容易隨着上下文膨脹而失控。

但一旦它變成代碼,就有了三個好處。

第一,可讀。你可以看到 Claude 到底準備怎麼安排這件事。

第二,可審。你可以在運行前檢查它是不是要亂改文件、亂跑命令、亂燒 token。

第三,可複用。一個好的 Workflow 可以保存下來,變成項目裏的長期能力。

這也是我覺得它比普通 subagent 更重要的原因。subagent 更像一次性的幫手,Workflow 更像一套沉澱下來的生產流程。

當然,它並不適用於所有的場景。

一兩步就能搞定的小任務,完全沒必要起 Workflow。讓幾十個 Agent 並行幹活,token 成本一定更高,它適合的是那種範圍大、步驟多、需要並行、需要驗證、需要反覆循環的大工程。

比如全倉庫安全審計,從舊框架遷移到新框架,大規模 API 替換,找性能瓶頸,讓多個 Agent 從不同角度審查一個方案,再派對抗性的 Agent 去推翻它。

過去我們總是在討論誰寫代碼更強,誰修 bug 更穩,誰上下文更大。

接下來可能還要討論另一個問題:誰更會組織一支 Agent 隊伍。

單個模型再強,也還是一個大腦。真正的大工程,靠的從來不是一個人從頭寫到尾,而是一套流程、一套分工、一套檢查機制。

是會先判斷這件事該怎麼拆,哪些部分並行做,哪些部分需要審查,哪些地方需要循環驗證,然後自動生成一套可執行的工作流,讓它生成一套穩定推進的系統。

之前我們也介紹過Goals,Codex&Claude Code的 /goal 指令的高級進階使用技巧,Goals 更像是把目標釘住,讓模型持續朝那個方向推進。

Dynamic Workflows 則是把過程寫下來,讓代碼保證流程不跑偏。

這也解釋了這幾家為什麼會把這種自動工作流作為關鍵性的功能組件。

不過目前這個功能只能是訂閲用戶來使用的,對於非訂閲,或者想結合Deepseek這類開源模型來使用的用戶,我們可以使用PiOpenClaw的心臟 Pi Agent從入門到精通的插件來體驗Dynamic Workflows。

安裝步驟如下。


    
    
    
  pi install npm:pi-dynamic-workflows

安裝後,在 Pi 裏執行:


    
    
    
  /reload

這樣就啓用了,不用自己寫代碼,直接對 Pi 說:


    
    
    
  運行一個工作流,分析當前項目結構,並總結主要模塊。

或者:


    
    
    
  運行一個工作流,從架構、安全、性能、可維護性幾個角度審查這個項目,最後給我一份改進建議。

Pi 會自動生成工作流腳本,然後調用多個子 Agent 分頭處理。

以一個分析陌生代碼庫呢例子:


    
    
    
  運行一個工作流,掃描這個倉庫,告訴我入口文件、核心模塊、配置文件和整體運行邏輯。

做代碼審查:


    
    
    
  運行一個工作流,從架構、安全、性能、可維護性四個角度 review 當前項目。

重構前分析:


    
    
    
  運行一個工作流,找出這個項目裏最值得優先重構的文件、重複邏輯和潛在風險。

做資料研究:


    
    
    
  運行一個工作流,分別從技術實現、使用場景、優缺點和替代方案几個角度研究這個主題,最後彙總。

它會顯示類似這樣的進度:


    
    
    
  ◆ 工作流:inspect_project
  ✓ 掃描
  ✓ 分析
  ✓ 彙總

如果不想繼續跑,可以按 Esc 取消。

普通 Pi 是一個 Agent 從頭做到尾,pi-dynamic-workflows 是讓 Pi 先寫一張任務拆解圖,再派多個子 Agent 並行幹活,最後把結果彙總回來。

歌手胡彥斌Vibe Coding的APP上架了!

狀告Anthropic!開源團隊爆Claude新功能 Dynamic Workflows 抄襲

Claude Opus 4.8發佈,疑似蒸餾了阿里 Qwen!

分享我的微信公眾號發佈工作流