Dify 於二零二六年十月二十三日發布 1.18.0，讓代理在流程中自行決定下一個分支，並把整份應用連同技能與檔案打包成單一 .ifpkg 套件。此版同時開放巢狀工作流的逐階追蹤與 Agent 知識庫 Beta，並以 difyctl 命令列工具取代舊有 OpenAPI 路徑，屬於架構層級的版本變動。
Dify 是什麼？
Dify 是開源 LLM 應用開發平台，以視覺化畫布建立工作流、RAG 管線與代理，支援數百種模型與 MCP 工具，採修改版 Apache 2.0 授權。
專案由 LangGenius 團隊於二零二三年四月建立，主要語言為 Python，前端為 Next.js，授權條款為修改版 Apache 2.0：商業使用與自架均開放，但不得以原始碼經營多租戶服務，亦不得移除主控台標誌。儲存庫主題標籤涵蓋 agent、agentic-workflow、low-code、mcp 與 rag，說明其定位介於低程式碼工具與代理執行環境之間。
平台的組成由七個部分構成：視覺化工作流、模型供應商管理、提示詞 IDE、RAG 管線、具備沙箱的自主代理、LLMOps 觀測，以及涵蓋所有功能的後端 API。最低部署需求為二核心 CPU 與 4 GiB 記憶體，以 Docker Compose 啟動，官方同時提供雲端版本與企業自架版本。
這種設計把「模型能力」與「流程編排」分開處理。使用者拉入節點定義資料流，再把模型、工具與知識庫接上，最後發布為聊天應用、API 或工作流中的一個步驟。1.18.0 的四項改動，正好分別對應這條路徑上的編排、搬移、觀測與知識四個環節。
Dify 1.18.0 帶來了哪些改動？
四個主軸為代理輸出路由、.ifpkg 可攜式應用套件、巢狀工作流逐階追蹤與 Agent 知識庫 Beta，另附 difyctl 命令列與 OpenAPI 目錄。
官方發布說明把 1.18.0 的改動歸為四類。第一類是讓代理決定下一步：啟用 Output Routes 之後，每個分支可設定選取條件，代理在執行期判斷要走哪一條，例如直接解決請求或轉交專門代理。第二類是可攜式應用，把工作流、聊天流程連同內嵌的代理、技能與檔案收進單一 .ifpkg 檔案。第三類是巢狀工作流的可觀測性，工具呼叫會以子圖形式執行，並可在執行紀錄中逐階展開。第四類是 Agent 知識庫，以 Beta 形式提供獨立的知識空間。
發布說明同時列出多項開發者層面的變更。OpenAPI 目錄擴大涵蓋範圍，新增的 difyctl 客戶端可從伺服器探索可用命令，支援工作流與聊天流程的建立、DSL 匯入匯出、環境變數管理、發布與版本還原，並以草稿雜湊處理並行編輯。原有的模式無關路徑 /openapi/v1/apps/{app_id}:run 已改為依模式分流的操作，硬編碼舊路徑的腳本需要更新。
伴隨功能而來的是一次協定層的調整。/runs 端點只接受 composition v2 請求，既有工作階段快照在讀取時轉換並以 v2 儲存，舊版執行環境無法讀取新格式。舊的代理專用 AskHuman 工具與延遲繼續路徑被移除，歷史表單不再恢復執行，共享工作流的人為輸入節點則維持支援。這意味著 1.18.0 是一次需要協調升級的版本，而非單純替換映像。
代理自行決定分支代表什麼？
代理可在 Output Routes 設定選取條件，執行期依內容判斷走向，選定的分支名稱由唯讀 switch 輸出公開，供後續節點與紀錄引用。
傳統工作流的條件分支由規則決定：比對關鍵字、檢查分類結果、判斷數值門檻。Output Routes 把這個判斷交給模型，開發者只需描述每個分支的適用情境，實際選取由代理在執行期完成。這樣的設計適合處理意圖不明確的請求，例如客服系統需要判斷應直接回覆、查詢知識庫，或轉交具備退款權限的專門代理。
可觀測性透過唯讀的 switch 輸出實現。下游節點與執行紀錄都能讀到代理選定的分支名稱，除錯時可確認代理是否按預期分流。同一版本也調整了串流行為：Plain Agent v2 節點會邊生成邊輸出文字，結構化結果、路由結果與使用預設值錯誤處理的節點則維持緩衝輸出。這項差異會直接影響前端呈現的即時感，遷移時需要一併檢查。
代價是結果的非確定性提高。規則分支的行為可預測，代理分支則受提示詞、上下文與模型版本影響。對需要稽核的流程而言，做法是把分支條件寫得足夠具體，並在每個路由之後保留記錄節點，讓選取理由與實際結果一併落庫。
可攜式應用套件解決什麼問題？
.ifpkg 把工作流、聊天流程、內嵌代理、技能與其檔案打包成單一檔案，匯入時在目標工作區重建資源並重映射引用，取代逐項手動搬移。
過去把一個應用從測試環境搬到生產環境，需要分別匯出工作流 DSL、代理設定、技能檔案與知識庫配置，任何一項漏掉都會在匯入後才發現。.ifpkg 把這些資源收進單一檔案，匯入時自動重建並重新對應引用關係。檔案與網址匯入同時支援套件與 YAML 兩種格式，明確的 YAML 匯出仍然保留，供版本控制與差異比對使用。
這項改動對兩類使用者影響最大。一類是把 Dify 應用作為交付物的顧問與外包團隊，套件讓交付變成單一附件，客戶在自己的工作區匯入即可執行。另一類是採用多環境流程的企業，測試與生產之間可以用同一份套件流轉，降低環境漂移。
需要注意的是套件內容包含檔案，體積會隨知識庫素材成長。官方文件建議把大型資料集留在外部儲存，套件只帶結構與必要檔案，避免每次匯入都重新上傳數百 MB 的內容。
巢狀工作流可視性為何重要？
工作流工具呼叫會以子圖形式執行，執行紀錄可展開檢視子流程每一步，並支援統一的暫停、繼續、停止與檔案輸出，存取檢查保護來源應用細節。
將工作流包裝成工具、再讓另一個工作流呼叫，是常見的模組化做法，但過去除錯時只能看到外層節點的成敗，失敗原因往往藏在子流程內部。1.18.0 讓 Workflow Tool 呼叫以子圖形式執行，並在執行紀錄提供逐階展開，外層的暫停、繼續與停止指令會傳遞到子圖，檔案輸出也統一管理。
官方同時標明兩項限制。巢狀用量的統計在暫停或停止之後可能仍為近似值，不能當作計費依據；主控台的下鑽檢視與外部追蹤匯出的範圍不同，需要完整鏈路時仍要接上外部觀測工具。存取檢查會確保子流程的細節不會越權暴露給沒有權限的成員。
對多團隊共用平台而言，這項改動的實際價值在於責任邊界。子流程的擁有者可以獨立維護與除錯，呼叫方只需關心輸入與輸出契約，平台則負責把兩邊的執行紀錄串起來。
Agent 知識庫目前有哪些限制？
Agent 知識庫為 Beta，需獨立服務與資料庫，預設 Compose 不安裝，映像目前僅支援 amd64，且尚未在雲端版本上線。
Agent 知識庫提供一個集中的知識空間，可加入檔案或連接外部來源，並在同一介面檢視文件處理進度、中繼資料、檢索軌跡與品質評估。新的知識檢索節點與代理整合共用受存取控制的 KnowledgeFS 空間，既有的傳統知識庫功能維持不變。
部署門檻寫得相當明確。這是可選整合，需要獨立資料庫與遷移、Capability v2 公開驗證器、Dify 簽署金鑰、模型設定（嵌入、推理與重排），以及工作區切換閘門。預設 Compose 安裝保持關閉，本機社群版開發需要明確開啟。健康檢查必須通過 /ready，而非只有 /health。官方發布的 KnowledgeFS API 映像目前僅提供 amd64 版本，標準 Dify API 映像則不含該引擎。
這些條件說明 Beta 標籤並非形式。對已在生產環境運行 Dify 的團隊而言，較穩妥的做法是先以獨立環境驗證知識庫流程，確認嵌入模型與重排模型的品質符合預期，再考慮切換工作區。急著在主要工作區啟用，會同時承擔資料遷移與服務穩定性的風險。
difyctl 與 OpenAPI 改變了什麼？
difyctl 從伺服器的操作目錄探索命令，支援建立工作流、DSL 匯入匯出、設定與版本還原，v2 客戶端不沿用 v1 登入狀態，需重新登入。
命令列工具的價值在於把重複操作變成腳本。difyctl 的設計並非硬編碼一組固定命令，而是從伺服器的操作目錄探索可用介面，因此不同版本的伺服器可以對應不同的命令集合，說明文件也隨之更新。草稿雜湊機制處理並行編輯，避免兩人同時修改同一份 DSL 時互相覆蓋。
舊有整合需要調整的地方有兩處。其一，模式無關的執行路徑已由依模式分流的操作取代，直接呼叫舊路徑的腳本會失效，應改為查詢目錄取得對應操作。其二，v2 客戶端不重用 v1 的登入狀態，升級後必須重新登入。工具本身也附帶代理技能，可用 difyctl install skills <目錄> 安裝，讓建構 Dify 應用的代理取得對應的操作知識。
對平台團隊而言，這代表自動化流程需要一次整理。把建立應用、匯出 DSL、發布與還原這幾步寫成腳本之後，環境複製與版本回溯都能進入 CI 流程，而不再依賴人工點擊。
Dify 的數據表現如何？
星標 159,353、分支 25,175、註冊貢獻者 456 位，最近七日提交 208 次，授權為修改版 Apache 2.0，後端以 Python 撰寫、前端為 Next.js。
專案自二零二三年四月建立，兩年半累積十五萬九千顆星標，分支數超過二萬五千，說明大量團隊把 Dify 當作起點而非終點：分支之後的修改多半圍繞自家模型、自家工具與自家合規要求。註冊貢獻者四百五十六位，最近七日提交二百零八次，活躍度維持在每天約三十次提交。
版本節奏同樣值得注意。1.17.1 於九月十日發布，1.18.0 於十月二十三日發布，相隔六週；在此之前，1.16.1 到 1.17.0 相隔約一個月。這種節奏對自架團隊意味著每季需要安排一次升級窗口，而 1.18.0 涉及執行協定變更，窗口內必須一次更新所有相關元件。
升級到 1.18.0 需要注意什麼？
API、worker、Agent Backend 與執行映像須同步升級，沙箱要設高熵權杖，來源安裝改用 Python 3.13，並保留 PASSWORD_PEPPER。
官方升級指南列出六項前置動作。第一，先備份資料庫、向量庫資料、上傳檔案、代理快照與所有部署密鑰。第二，代理相關元件必須一起升級，/runs 只接受 v2 請求，舊執行環境無法讀取新快照。第三，讓進行中的執行完成後再替換舊 worker，避免舊消費者處理共享佇列。第四，在重啟前設定 Local 沙箱的高熵權杖，並確認映像版本對應 1.18.0。第五，保留既有的 PASSWORD_PEPPER，升級時新設並非透明遷移，需要另行規劃密碼重設。第六，檢查代理邊界設定，內建 Nginx 會以解析出的用戶端位址取代 X-Forwarded-For，若前方另有負載平衡器或 CDN，需在該層設定真實 IP 處理，否則訪客會共用同一個限流桶。
資料層面有三項需要事後處理。已在升級前被移除的發布觸發器不會自動修復，需要重新綁定並重新發布；文件抽取的修正只對重新匯入或重建索引的內容生效；內建文件中繼資料的切換只改寫已啟用且索引完成的文件，其餘舊資料需要日後再處理。自架團隊若同時使用 Weaviate，仍停留在 1.27 的環境須先完成 1.17.1 的階段式升級。
這些條件構成一個明確結論：1.18.0 適合有維護窗口與備份流程的團隊，不適合在沒有測試環境的情況下直接對生產實例操作。Docker Compose 使用者至少要先在副本上驗證代理執行與知識檢索兩條路徑。
出處連結有哪些？
原始碼、版本發布說明與升級指南均位於 GitHub 的 langgenius/dify 儲存庫，1.18.0 頁面另列六項升級前置條件與資料修復說明。
專案位址為 https://github.com/langgenius/dify，1.18.0 的發布說明包含功能亮點、升級指南與部署指令三段，並附上相關拉取請求編號供追溯。官方文件站 docs.dify.ai 提供自架安裝、模型供應商與工作流節點的中文說明，繁簡中文版本均在儲存庫內同步維護。
總結：Dify 1.18.0 值得升級嗎？
值得升級，前提是先備份並安排協調窗口。輸出路由與可攜式套件直接改善交付與除錯流程，Beta 的知識庫則建議在獨立環境先行驗證。
1.18.0 的四項改動分別回應了平台使用者的四個實際痛點：分支判斷不够靈活、應用搬移容易漏件、巢狀流程難以除錯、知識管理散落各處。其中輸出路由與可攜式套件屬於完成度較高的功能，能立即投入使用；巢狀追蹤已可用但統計仍有近似值；Agent 知識庫則是明確的 Beta，需要獨立服務與額外設定。
升級判斷可以簡化為一個問題：團隊是否有能力在一個維護窗口內同步更新 API、worker、代理後端與執行環境，並在事前完成備份。答案是肯定的，1.18.0 帶來的工作流表達能力與交付便利值得投入；答案是否定的，先把測試環境建起來會比急著升級更有效率。
