Dify 工作流編排教學：從單輪問答到多步驟流程
Chatbot 只能一問一答，遇到要先分類、再查資料、最後組合回覆的需求就不夠用。這篇說明 Workflow 的節點怎麼串、什麼時候該從 Chatbot 換過來。
🚀 想直接開始?60 秒部署你的 Dify
AI 應用開發平台 — No-Code 建構你的 AI。月付 NT$1,599 起,
Chatbot 的結構是固定的：收到問題、查知識庫、生成回答。
但真實需求常常不是一步到位。「先判斷這是售前還售後、售後再查訂單、售前才給型錄」——這種分支邏輯 Chatbot 做不了，要用 Workflow。
30 秒總覽
| Chatbot | Workflow | |
|---|---|---|
| 結構 | 固定，一問一答 | 自由，可分支可迴圈 |
| 適合 | 單一主題問答 | 多步驟、要分類、要串外部系統 |
| 上手難度 | 低 | 中 |
| 除錯 | 看引用來源 | 逐節點看輸入輸出 |
| 什麼時候換 | 當你發現 Prompt 裡開始寫「如果⋯就⋯否則⋯」 | |
最後一列是最實用的判斷法：當你在 Prompt 裡塞條件判斷的時候，就是該換成 Workflow 的訊號。模型不擅長穩定地執行分支邏輯，那應該交給流程結構。
常用節點在做什麼
開始與結束
開始節點定義這條流程接收什麼輸入。結束（或直接回覆）節點決定回傳什麼。
問題分類器
把使用者的問題分到你定義的類別，然後走不同的分支。這是多數實用流程的第一個節點。
分類的準確度取決於你怎麼描述每個類別。用具體例子描述會比用抽象定義準得多——「詢問運費、到貨時間、物流狀態」比「物流相關問題」有效。
知識檢索
從指定的知識庫撈相關段落。可以在不同分支接不同的知識庫，這是 Workflow 相對於 Chatbot 的一大優勢。
LLM
呼叫語言模型。一條流程裡可以有多個，各自負責不同的事——例如一個負責摘要、一個負責改寫語氣。
條件分支
依變數的值決定走哪條路。跟問題分類器的差別是：條件分支比的是明確的值，分類器是讓模型判斷語意。能用條件分支解決的就不要用分類器，前者穩定得多也不花模型費用。
HTTP 請求
呼叫外部 API。這是讓流程能查訂單、查庫存、寫入系統的關鍵節點。
不過如果你要串的東西多、又需要重試與錯誤處理，用 n8n 負責執行會比全部塞在 Workflow 裡好維護。
一條實際的流程長什麼樣
以客服為例：
- 開始——接收使用者問題
- 問題分類器——分成「產品諮詢」「訂單查詢」「其他」
- 產品諮詢 → 知識檢索（產品知識庫）→ LLM 生成回答
- 訂單查詢 → HTTP 請求（查訂單系統）→ LLM 把結果講成人話
- 其他 → 直接回覆固定的轉真人訊息
- 結束
注意第五條：不要讓每條路都經過模型。固定回覆用直接回覆節點就好，又快又不花錢，而且結果可預期。
除錯的方法
逐節點看輸入輸出
Workflow 的除錯體驗比 Chatbot 好很多——每個節點都看得到收到什麼、吐出什麼。流程結果不對時，從後往前找第一個輸出不符預期的節點。
先讓流程跑通，再調品質
常見的錯誤是一邊接節點一邊調 Prompt。建議先用最簡單的設定把整條路接通，確認資料流是對的，再回頭調每個 LLM 節點的品質。
變數名稱要看得懂
節點之間靠變數傳遞。流程一長，`text`、`result`、`output` 這種名字會讓你三天後看不懂自己寫了什麼。
變數：流程真正的骨架
節點之間靠變數傳遞資料，這是 Workflow 最容易出錯、也最少人講清楚的部分。
每個節點的輸出都要被接住
LLM 節點吐出的內容、知識檢索撈回的段落、HTTP 請求的回應，都會存成變數。下一個節點要用時再引用它。
常見的錯誤是在後面的節點裡引用了根本沒執行到的分支變數——流程走了 A 路，卻引用 B 路的輸出，結果是空值。有多個分支時要特別檢查這件事。
命名習慣會決定你三天後看不看得懂
`text`、`result`、`output` 這種預設名字在三個節點時還好，到十個節點就是災難。用途導向的命名（`classified_intent`、`order_status`）花不了多少時間，但省下的除錯時間差很多。
第二個案例：內容審核流程
不是所有 Workflow 都要對話。這條流程處理的是批次任務：
- 開始——接收一段使用者投稿的文字
- LLM——判斷有沒有違規內容，輸出「通過」或「需人工複審」
- 條件分支——依上一步的結果分流
- 通過 → HTTP 請求寫入資料庫
- 需複審 → HTTP 請求發通知給管理員
- 結束
這個案例說明兩件事：Workflow 不一定要有人在對話，它可以被系統呼叫；以及判斷交給模型、動作交給節點是比較穩的分工。
什麼時候不該用 Workflow
誠實講：如果你的需求就是「根據文件回答問題」，Chatbot 就夠了。用 Workflow 只是多一層維護成本。
另外，如果流程的重點是串接大量外部系統、需要排程、需要失敗重試——那核心應該放在自動化工具，Dify 只負責理解意圖的部分。分工方式在Dify 加 n8n。
常見問題
Q：Workflow 和 Chatflow 差在哪？
簡單說 Chatflow 是帶對話記憶的 Workflow，適合多輪對話；Workflow 比較像一次性的任務處理。要做客服機器人多半用 Chatflow，要做批次處理用 Workflow。
Q：一條流程可以多長？
技術上沒什麼限制，但實務上節點超過十幾個就該考慮拆開。太長的流程除錯困難，而且每個節點的失敗機率會累積。
Q：流程跑很慢怎麼辦？
先看是哪一個節點慢。多半是 LLM 節點——那是模型的回應時間，加資源沒用。可以考慮換更快的模型，或減少不必要的 LLM 節點。
Q：可以讓流程定時執行嗎？
Dify 的流程主要由請求觸發。需要排程的話，用外部工具定時呼叫它的 API 是比較常見的做法。
資料來源與延伸連結
- Dify 官方文件——節點類型與參數的完整說明
- Dify 版本更新紀錄——節點功能常隨版本增加
