這項由浙江大學與騰訊合作完成的研究，於2026年4月以預印本形式發布在arXiv平台，論文編號為arXiv:2504.19667v1，有興趣深入了解的讀者可通過該編號查詢完整原文。研究的核心問題聽起來既簡單又雄心勃勃：能不能讓AI自動幫我們搭一套可以直接投入使用的工作流程？
在企業日常運營中，有一類東西叫做"工作流"——不是普通的文字流程圖，而是真正能在軟體平台上一鍵運行的自動化程序。打個比方，就像樂高積木的說明書，只不過這份說明書本身就是一台能自動拼裝的機器。現在，Dify和Coze這樣的平台讓越來越多的企業能夠通過拖拉節點的方式搭建這類流程，但問題在於，每一個節點的配置、每一條連線的邏輯，都需要專業工程師手動完成，耗時耗力，改一次需求就得重頭推敲一遍。
研究團隊因此提出了一個自然而然的問題：既然大語言模型（也就是ChatGPT這類AI）已經能寫代碼、能理解複雜指令，它能不能直接根據人類用自然語言描述的需求，幫我們把這套工作流原原本本地搭建出來，甚至在需求變化時隨時修改？為了系統地研究這個問題，他們創建了一個名為**Chat2Workflow**的測試基準，並設計了一套配套的智能框架來幫助AI減少反覆出錯。這是目前該領域首個專門針對"從自然語言生成可執行視覺工作流"這一任務的正式基準數據集，因此具有相當的開創性意義。
---
一、工作流到底是什麼，為什麼它如此難以自動生成
要理解這項研究，首先得弄清楚"可執行視覺工作流"究竟是什麼東西。在Dify或Coze這樣的平台上，工作流看起來就像一張由方塊和箭頭組成的地圖。每個方塊叫做"節點"，代表一個具體的操作——比如調用大語言模型生成文字、用代碼處理數據、發起網路請求、將文字轉換成圖片，等等。箭頭則代表數據從一個節點流向下一個節點的路徑。整張地圖在後台以YAML格式的文件儲存，平台讀取這個文件後就能自動執行對應的任務流程。
這套系統的核心價值在於它的可靠性和可控性。相比於讓AI自由發揮、每次給出不同答案，一個固定好的工作流就像一條裝配線——每次輸入原材料，輸出的產品都遵循同樣的質量標準。這正是現實企業更青睞工作流而非完全依賴AI隨機發揮的原因。一項針對真實企業部署情況的調查顯示，超過70%的真實AI部署案例中，開發者選擇的都是這種預先定義好流程的工作流方式，而不是讓模型自由生成。
然而，要讓AI從一句人類語言出發，自動生成一張正確且可運行的工作流地圖，難度遠超想像。研究團隊指出了兩大核心挑戰。其一，現實中的需求往往是複雜且隱式的——當用戶說"我需要一個能生成科普文章的工作流"時，AI必須自行推斷出這個任務需要哪些節點、這些節點應該如何連接、每個節點的參數應該怎麼填寫，任何一個環節出錯都會導致整個流程無法運行。其二，現實中的需求會不斷變化——用戶在第一輪說"我要一個總結書籍內容的工作流"，第二輪又說"在此基礎上再加一個生成人物傳記並導出為Word文檔的功能"，第三輪還要繼續追加"再加一個根據傳記內容生成配圖的模組"。AI必須在理解歷史對話的基礎上，準確地對已有工作流進行增刪改，既不能遺漏舊功能，也不能搞亂新舊邏輯之間的關係。
---
二、Chat2Workflow數據集是如何煉成的
為了評估AI在這個任務上的真實表現，研究團隊沒有憑空捏造測試題目，而是從真實的業務場景出發，踏踏實實地構建了一套高質量數據集。
他們的原材料來自Dify和Coze平台的官方資源庫以及GitHub上的開源工作流配置文件——這些都是真實用戶在真實場景中搭建並使用過的生產級工作流。團隊拿到這些工作流之後，並沒有直接把它們作為答案，而是反向操作：把工作流"翻譯"成自然語言的任務描述，就像把一道做好的菜拆解回菜譜。
更關鍵的是，這些任務描述被設計成多輪對話的形式。同一個大任務會被拆分成兩到四輪，每一輪都在前一輪的基礎上增加、修改或細化需求。以書籍處理任務為例，第一輪要求"根據書名和作者名生成三分鐘速讀摘要"，第二輪要求"在此基礎上再生成主角人物傳記並導出為DOCX文件"，第三輪要求"根據傳記內容生成一張插圖"。這種設計模擬了現實中用戶需求不斷演進的真實場景，遠比單輪測試更貼近實際使用情況。
經過嚴格的人工審核流程，團隊剔除了所有指令模糊、中間步驟無效、依賴時效性來源或行為邏輯前後矛盾的案例，最終保留了27個任務，共計79輪多輪對話指令。這27個任務涵蓋六大應用場景：AIGC內容生成（占22.2%）、學術研究（18.5%）、文檔處理（18.5%）、教育（14.8%）、企業（14.8%）以及開發者工具（11.1%）。
為了讓評估能夠真正落地，每一條指令都配備了三個真實可執行的測試用例。這些測試用例的輸入來自現有的公開數據集、網際網路上的零散素材以及AI合成數據，輸出則根據任務類型分為兩種：對於輸出結果比較明確的任務，測試用例會提供參考答案；對於更開放的任務，則只提供輸入，由執行結果來判斷是否符合要求。
---
三、AI如何生成工作流，背後有什麼講究
研究團隊沒有讓AI直接"一口氣"輸出完整的工作流文件，因為那樣太容易出錯。他們採用了一種叫做"思維鏈"（Chain-of-Thought）的方法，讓AI在給出最終答案之前，先把自己的推理過程分幾個步驟展示出來，就像讓一個人在解數學題之前先寫出解題思路。
具體來說，AI的輸出被分為三個部分，分別用特定標籤包裹。第一部分是"節點選擇"，AI需要列出這個工作流會用到哪些節點，比如"開始節點、大語言模型節點、文字轉圖片節點、結束節點"。第二部分是"設計原則"，AI需要用自然語言解釋它打算如何設計這個流程，相當於在動手之前先講清楚自己的思路。第三部分才是正式的"工作流"，以簡化的JSON格式描述所有節點的具體參數以及節點之間的連接關係。
這個JSON文件隨後會經過一個代碼轉換程序，自動變成Dify平台能夠直接導入運行的YAML格式文件。整個流程就像先畫草圖、再寫說明書、最後上機器實際製作——分步走比一蹴而就更不容易出差錯。
為了讓AI知道每種節點該怎麼用，團隊為20種最常用的節點類型專門整理了一份"節點知識庫"，作為AI系統提示詞的核心組成部分。這20種節點包括開始、結束、大語言模型、問題分類器、代碼執行、文檔提取器、HTTP請求、條件分支、列表處理、參數提取器、模板、變量聚合器、疊代、疊代開始、文字轉語音、文字轉圖片、Mermaid圖錶轉換、Markdown導出、谷歌搜索以及Echarts圖表。這個節點集合雖然相對精簡，但足以覆蓋數據集中的所有任務場景。
---
四、如何判斷AI生成的工作流到底好不好
這是這項研究最值得細說的地方。評價一段文字寫得好不好，人眼一看大概就能判斷；但評價一個工作流是否合格，光看它長什麼樣遠遠不夠，必須真的跑起來才算數。
研究團隊因此設計了一套兩階段遞進評估體系，用兩個指標來衡量：通過率和解決率。
通過率衡量的是第一階段——工作流的"格式合法性"。具體來說，AI生成的輸出必須經過四重檢驗：首先，輸出格式是否正確，三個標籤（節點選擇、設計原則、工作流）都得有，且JSON部分能正常解析；其次，JSON能否成功轉換為YAML文件；第三，工作流中聲明的變量是否與預先定義的參考變量完全一致；第四，節點選擇、設計原則和工作流三個部分在邏輯上是否互相一致，而且任務要求必須使用的關鍵節點是否都出現在了節點選擇中。這四步全部通過，才算"格式合格"，才有資格被導入平台運行。
解決率衡量的是第二階段——工作流真正運行後能不能完成任務。這一步又分兩個檢驗：先看工作流運行時有沒有報錯、有沒有產生實際輸出；再看輸出的內容是否滿足指令要求，如果有參考答案的話，還要對照參考答案做語義層面的比較。對於輸出中涉及文件的部分（比如生成的圖片、音頻、Word文檔），還會單獨檢查文件類型是否匹配。
整個評估過程藉助DeepSeek-V3
模型來完成自動化判斷。為了驗證這套自動化評估是否可靠，團隊還進行了人工抽樣對比：在通過率評估上抽取了500個樣本，人機一致率達到100%；在解決率評估上抽取了1282個樣本，人機一致率也高達98.83%。這說明這套評估體系的可信度相當高。
---
五、15個頂級AI模型的實戰成績，差距令人意外
研究團隊在Chat2Workflow基準上測試了15個代表性語言模型，每個模型獨立運行三次取平均，最終結果令人大開眼界。
先說閉源模型的情況。在四個閉源模型中，Gemini-3-Pro-Preview表現最為亮眼，在六個場景下的平均通過率達到80.17%，解決率達到71.59%，兩項指標均領跑所有模型。Claude-Sonnet-4.5的通過率為71.31%，解決率54.57%；GPT-5.2通過率67.51%，解決率54.71%；而GPT-5.1的表現相對遜色，通過率僅47.26%，解決率39.38%。
開源模型陣營則呈現出明顯的參數規模效應。以Qwen-3系列為例，8B參數版本的平均解決率僅6.89%，幾乎等同於隨機水平；14B版本提升到15.19%；32B版本達到23.35%；235B版本進一步升至27.71%。從8B到235B，隨著參數量的持續擴大，解決率穩步攀升，這條趨勢線相當清晰。
GLM-4.7和GLM-4.6之間的對比揭示了一個微妙但重要的現象。GLM-4.6經過了專門針對格式規範的後訓練，因此在某些場景下通過率確實高於GLM-4.7，比如在企業場景中GLM-4.6的通過率為63.89%，高於GLM-4.7的72.22%（筆誤，原文GLM-4.6企業通過率63.89，GLM-4.7為72.22%，按原數據：GLM-4.6企業通過率63.89%，GLM-4.7為72.22%）。然而，當看解決率時，結論完全反轉：GLM-4.7在企業場景的解決率為47.22%，而GLM-4.6僅有24.07%。這個現象說明，光靠訓練讓模型輸出更符合格式規範，並不等於讓工作流真正能解決問題——格式正確只是必要條件，不是充分條件。
思維型（Thinking）模型與指令型（Instruct）模型的對比同樣耐人尋味。Kimi-K2-Thinking在全部六個場景下的解決率均高於Kimi-K2-Instruct，平均解決率分別為43.46%和31.08%。類似地，Qwen-3-235B-A22B的平均解決率（27.71%）高於參數量更大但不具備推理機制的Qwen-3-Coder-480B-A35B-Instruct（26.44%）。也就是說，讓AI在給出答案之前多"想一想"，對工作流生成質量的幫助相當顯著。
通過率與解決率之間的差距是另一個值得關注的現象。幾乎所有模型的解決率都低於通過率，差距最大的是GLM-4.6，兩者之間的平均差距高達20.96%。在教育場景這個極端情況下，GLM-4.6的通過率達到72.73%，解決率卻只有29.29%，差距超過43個百分點。這說明，有相當比例的工作流在格式上完全合規，能成功導入平台，但運行之後根本無法完成實際任務——就像一輛外觀完好無損、發動機卻動不了的汽車。
---
六、隨著對話輪次增加，AI的狀態會怎樣變化
Chat2Workflow的另一個獨特設計是多輪對話。研究團隊追蹤了15個模型在前三輪對話中的表現變化趨勢，結果幾乎是一邊倒的：隨著輪次增加，絕大多數模型的通過率和解決率都在下降。
這個現象背後的邏輯並不複雜。每過一輪，模型需要處理的歷史資訊就多一份，需要理解的累積需求就複雜一層，需要在已有工作流基礎上做出的精準修改就多一處。就像在一棟樓上不斷加蓋新樓層，每加一層，地基和結構所承受的壓力就更大一點，稍有不慎就會出現裂縫。
不過，研究者也注意到一個稍顯樂觀的規律：隨著輪次推進，大多數模型的性能下降幅度也在逐漸收窄。換句話說，第一輪到第二輪之間的性能跌落，往往大於第二輪到第三輪之間的跌落。對此，研究者提出了一個合理的解釋：能熬過第一輪篩選、在第二輪仍然輸出合格工作流的那些"案例"，本身就已經經歷了一次自然淘汰，留下來的是質量較高的樣本；這些樣本在繼續演化時，天然具備更強的抗壓能力，因此性能衰減的速度放緩了。
---
七、一個典型失敗案例：教育場景的工作流競技場
為了讓抽象的數據變得具體，研究團隊選取了教育場景中的"學習規劃師"（StudyPlanner）任務作為案例分析，重點剖析了第二輪任務的執行情況。
第二輪任務要求AI在第一輪"生成自學計劃"的基礎上，進一步構建一個能自動生成完整教學的工作流：先生成課程大綱，再按章節疊代生成每個知識點的詳細內容，最後將所有內容整合成一份完整教學輸出。
三個模型的表現形成了鮮明對比。Kimi-K2-Instruct生成的工作流在格式上看起來沒什麼大問題，卻在邊連接關係上犯了一個根本性錯誤。它在"疊代節點"（相當於一個循環執行單元）和其內部的"疊代開始節點"之間設置了一條邊連接，而正確的做法是兩者之間只存在包含關係，不存在連接關係——這個區別在節點文檔中有明確說明，但模型沒能正確理解。結果，這個看起來格式完整的工作流根本無法運行。
GLM-4.6則犯了另一類錯誤：它在節點選擇部分沒有聲明"代碼節點"和"疊代開始節點"，但在實際的工作流JSON中卻用到了這兩個節點。這就像一個廚師在採購清單上沒有寫雞蛋，卻在烹飪時偷偷用了兩個雞蛋——前後不一致，邏輯上自相矛盾，最終導致評估判定為不合格。
GPT-5.2則是這一輪的優等生，它生成了格式正確、邏輯一致、能成功運行的工作流，並且在實際測試中成功解決了輸入的任務。研究者還展示了GPT-5.2在Dify和Coze兩個平台上生成的工作流截圖，從截圖中可以看到，整個流程圖包含了參數提取器、大語言模型、疊代、模板等多個節點，邏輯鏈條清晰，確實是一個可以真正部署使用的完整工作流。
---
八、加上"偵探模式"之後，AI能提升多少
面對上述種種失敗模式，研究團隊提出了一個"錯誤驅動的智能體框架"，試圖探索AI在這個任務上的性能上界。
這個框架的運作方式類似於給AI配備了一套專門針對這個任務的工具包和操作規程。框架基於OpenCode平台（版本1.3.17）實現，核心設計分幾個層面展開。
在基礎提示層面，框架從零樣本提示升級為結構化的"技能文檔"（SKILL.md）驅動模式，明確列出工作流生成中的關鍵規則，包括多輪對話的上下文繼承規則和變量引用規則，減少模型在這些細節上出錯的概率。
在上下文管理層面，為了防止隨著對話輪次增加、歷史資訊過多導致模型"記性變差"，框架會從前一輪的工作流中動態提取"變量摘要"，將最關鍵的上下文資訊壓縮提煉出來，作為補充輸入餵給下一輪的生成過程。
最關鍵的是錯誤修復機制。框架設計了一個最多嘗試5次的重試循環，每次生成後立刻進行結構和語義雙重驗證。一旦發現問題，框架不是簡單地重新生成，而是調用四個專門的"自動修復模組"分別對付四類最常見的錯誤：代碼圍欄格式問題（AI輸出的文本格式不對）、JSON解碼失敗（JSON格式語法錯誤）、拓撲排序違反（節點連接形成了環路，而工作流要求必須是有向無環圖）、節點選擇不一致（節點選擇與實際工作流JSON不匹配）。
結果顯示，這套框架對GPT-5.1的通過率提升從47.26%躍升至64.14%，解決率從39.38%提升至44.31%，絕對提升幅度約4.93個百分點；對GPT-5.2，通過率從67.51%提升至78.06%，解決率從54.71%提升至60.05%，絕對提升幅度約5.34個百分點。這些提升數字說明，專門針對這個任務設計的結構化方法確實有效，但即便如此，最好的結果也只是60%的解決率，離真正可靠的工業級水平還有相當距離。
---
九、這項研究的邊界在哪裡，未來還有多少路要走
研究團隊在論文中坦誠地說明了Chat2Workflow目前的幾個局限性，這種誠實恰恰讓整項研究更加可信。
首先是規模問題。27個任務、79輪指令，對於系統性研究來說已經相當紮實，但現實世界中業務流程的複雜度和多樣性幾乎是無窮無盡的，這套數據集無法窮舉所有情況。
其次是節點簡化問題。為了讓任務可執行，團隊對每個節點的輸入輸出接口進行了簡化，只保留了主要參數，次要參數設為默認值。但在真實部署中，很多複雜的業務場景需要精細調整那些"次要參數"，這部分複雜度目前還沒有被納入評估。
第三是節點種類有限的問題。20種節點類型能覆蓋大多數標準場景，但Dify這樣的平台實際上提供了數百種社區擴展節點，很多更複雜的真實業務需要用到那些目前不在測試範圍內的特殊節點。
儘管如此，這項研究的意義在於，它提供了第一個系統性的、可重複驗證的測試基準，讓研究者和開發者能夠客觀衡量"AI自動生成工作流"這項能力的真實水平和瓶頸所在。在此之前，這個問題更多停留在定性討論層面，現在終於有了量化數據可以依據。
---
說到底，Chat2Workflow做的這件事，是在問一個現實得不能再現實的問題：當你對AI說"幫我搭一個自動化工作流"，它能給你一個真正能用的答案，還是只是看起來像那麼回事的答案？
研究的結論坦率而清醒。即便是目前最頂級的大語言模型，也只能在大約七成的情況下給出"格式正確"的工作流，而真正"能運行、能解決問題"的比例更低。在開發者這個場景下，所有模型的表現都尤其糟糕——這裡涉及的邏輯最為複雜，對節點之間交互關係的理解要求最高。隨著用戶需求一輪輪演變，AI的性能還會進一步下滑，就像一個在嘈雜環境裡邊聽邊記、越記越亂的速記員。
加上專門設計的智能體框架之後，情況有所改善，但提升幅度仍然有限。這意味著，單純依靠更大模型或更複雜的提示詞，可能還不足以真正解決這個問題，未來可能需要在結構化推理、工具知識表示以及工作流專用訓練等方向上做出更深入的探索。
對於普通用戶來說，這項研究的直接意義是：在可預見的未來，讓AI全自動搭建生產級工作流還需要一段時間，但AI作為輔助工具、幫助工程師減少重複勞動、加速原型驗證，已經具備了相當的可行性。如果你對這個領域感興趣，可以通過arXiv編號2504.19667查閱完整論文，或訪問研究團隊開放的GitHub倉庫（github.com/zjunlp/Chat2Workflow）獲取數據集和代碼。
---
Q&A
Q1：Chat2Workflow基準測試中的"通過率"和"解決率"有什麼區別？
A：通過率衡量的是AI生成的工作流在"格式"上是否合格，包括JSON能否正確解析、能否轉換成YAML文件、節點聲明是否前後一致等；解決率則衡量工作流真正運行後能不能完成任務。研究發現，通過率總是高於解決率，最極端的情況下兩者差距超過43個百分點，說明格式合規只是工作流能用的必要條件，而非充分條件。
Q2：測試中哪個AI模型在自動生成工作流方面表現最好？
A：在Chat2Workflow基準上，Gemini-3-Pro-Preview綜合表現最優，平均通過率80.17%，平均解決率71.59%，是所有15個測試模型中最高的。開源模型中GLM-4.7解決率最高，達55.98%。但即便是最好的模型，解決率也沒有突破75%，距離真正可靠的工業級部署仍有明顯差距。
Q3：為什麼AI生成工作流的效果隨著對話輪次增加而變差？
A：每增加一輪對話，AI需要理解的歷史資訊就更多，需要在已有工作流基礎上做的精準修改也更複雜。簡單來說，AI需要同時記住舊需求、理解新需求、還要保證修改後的工作流整體邏輯不出錯，這三件事疊加在一起，出錯的概率自然上升。研究團隊觀察到，幾乎所有模型的性能都隨輪次穩步下滑，這被認為是該任務中長程指令跟隨能力的關鍵瓶頸。
