Dify 開源 AI 應用平台 — 不寫後端做出自己的 AI 工作流
Dify 讓不會寫後端程式的人,用拖拉節點的方式建出可上線的 AI 應用,而且產出的每個工作流都自帶 API 端點。它的核心價值不是「省下寫程式的時間」,而是把 prompt 管理、RAG 檢索、模型切換、日誌追蹤這四件原本要各自架設的事,收進同一個介面裡。 Dify 到底解決了什麼問題 沒有 Dify 之前,做一個「
Dify 讓不會寫後端程式的人,用拖拉節點的方式建出可上線的 AI 應用,而且產出的每個工作流都自帶 API 端點。它的核心價值不是「省下寫程式的時間」,而是把 prompt 管理、RAG 檢索、模型切換、日誌追蹤這四件原本要各自架設的事,收進同一個介面裡。 Dify 到底解決了什麼問題 沒有 Dify 之前,做一個「能查公司文件的客服機器人」需要組合至少五個元件:向量資料庫、embedding 服務、檢索邏輯、prompt 模板管理、對話歷史儲存。每個都要寫程式碼串接,任何一環改動都要重新部署。Dify 把這五件事變成畫布上的節點,改完按「發布」就生效。 Dify 是由 LangGenius 團隊開發的開源 LLMOps 平台,採用 Apache 2.0 為基礎的修改授權(附加商標與多租戶限制條款)。 「GitHub 星數超過 11 萬顆、貢獻者超過 900 人(2026 年)」(來源:langgenius/dify GitHub Repository) ,是同類開源 AI 應用平台中社群規模最大的專案之一。 它的定位介於兩個極端之間。一端是 n8n、Zapier 這類通用自動化工具,AI 只是眾多節點之一,缺乏 prompt 版本控制與 RAG 深度整合;另一端是 LangChain、LlamaIndex 這類程式框架,彈性極高但必須寫 Python。Dify 補的是中間地帶:視覺化操作,但保留 API 與程式碼節點作為逃生出口。 四種應用型態的差別 Dify 建立應用時要先選型態,選錯會導致後續整個結構重做。四種型態的適用情境如下。 聊天助手(Chatbot) 適合單一角色、單輪 prompt 就能處理的對話場景。設定一段系統提示詞、掛上知識庫、選模型,五分鐘可上線。限制是流程固定,無法依使用者輸入分支到不同處理路徑。 Agent 讓模型自行決定要呼叫哪些工具,適合任務邊界模糊的情境,例如「幫我查這家公司的最新財報並算出本益比」。Dify 內建 Google 搜尋、DALL-E、WolframAlpha 等工具,也支援自訂 OpenAPI 規格的外部工具。代價是每次執行的 token 消耗與延遲不可預測,因為模型可能反覆呼叫工具。 工作流(Workflow) 單次執行、無對話上下文的批次任務,例如「把這份會議記錄轉成三種格式的摘要」。這是最適合放進自動化排程的型態。 對話流(Chatflow) 結合對話記憶與流程分支,適合需要多輪釐清的客服或表單填寫。跟 Chatbot 的差別在於可以用「問題分類器」節點把不同意圖導向不同處理分支。 RAG 知識庫的實際設定要點 知識庫的檢索品質有八成取決於分段設定,而不是模型選擇。Dify 提供兩種分段模式,實務上的差異很大。 通用分段 :依固定字元數切割,適合結構鬆散的長文。中文文件建議 chunk size 設 500-800 字元、overlap 設 50-100,切太細會讓一個完整概念被拆成兩段,檢索時只撈到半截。 父子分段 :檢索時比對子段落(精確),送給模型時給父段落(完整上下文)。適合有明確章節結構的規章、手冊。這個模式的檢索命中率通常明顯高於通用分段,代價是索引時間較長。 檢索設定的另一個關鍵是混合檢索(Hybrid Search)。純向量檢索對「專有名詞、產品型號、人名」這類需要精確比對的查詢表現不佳,因為語意相近的詞會被判定為相關。開啟關鍵字檢索並搭配 Rerank 模型,能明顯改善這類查詢。 RAG 架構的原始論文 Lewis et al. (2020) 即指出檢索元件的品質直接決定生成品質上限。 Dify 支援接入多種向量資料庫,包含 Weaviate、Qdrant、Milvus、pgvector 等。 「Dify 官方文件列出支援超過 15 種向量資料庫與數十家模型供應商」(來源:Dify 官方文件) ,自架時預設使用 Weaviate,多數個人與小團隊用量不需更換。 自架 vs 雲端版的成本結構 自架 Dify 的門檻比想像中低,但長期成本不在伺服器而在維運。官方提供 Docker Compose 部署,一台 2 核 4GB 記憶體的機器即可跑起完整堆疊(API server、worker、web、資料庫、向量庫、Redis)。以常見 VPS 定價計算,這規格月費約在 10-20 美元區間。 雲端版的免費方案有明確配額限制。 「Dify Cloud 沙盒方案提供 200 次 OpenAI 呼叫額度與 5 個應用上限」(來源:Dify 官方定價頁) ,適合評估與原型驗證,不適合正式流量。 真正該計算的是模型 API 成本,而非平台成本。一個每天處理 500 次查詢的 RAG 客服,若每次消耗 3000 input tokens 加 500 output tok
相關工具書
由 FeiYueh 親自審稿驗證 · 最後更新於 2026-09-18. Independently maintained — not AI-generated boilerplate.
← Back to Blog