Dify 於二零二六年十一月四日發布 1.19.0，把巢狀工作流工具的執行步驟接進外部追蹤工具，並讓應用套件帶同工作流工具一併搬移。此版同時開放以 difyctl 管理技能、支援代理檔案批次上傳與即時預覽，資料庫遷移增至六個版本，追蹤佇列改為雙軌過渡。
上一版 1.18.0 於十月二十三日發布，兩次版本相隔十二日。專案目前累積十六萬顆星標、二萬五千個分支與一千六百零五位貢獻者，最近七日提交二百九十四次，屬於長週期專案中節奏偏快的一段。
Dify 1.19.0 帶來了哪些改動？
四項主軸為巢狀工作流追蹤、可攜式工作流工具套件、difyctl 技能管理與代理檔案批次上傳，另附追蹤佇列與安全修補，屬需要協調升級的版本。
官方發布說明把 1.19.0 的改動歸為三組。第一組是觀測能力，外部追蹤匯出開始包含被呼叫工作流工具的持久化執行步驟，子步驟掛在呼叫它的工具區段之下，階層在巢狀與重複呼叫中都保留位置。第二組是交付能力，應用套件開始把工作流工具背後的工作流一併打包，匯入時重建缺失的工具並重新對應引用。第三組是操作介面，代理設定檔支援多選、拖放與並行上傳，PDF 可在預覽區直接渲染，被截斷的文字會明確標示。
開發者層面另有三項變化。技能可以透過 OpenAPI 與 difyctl 匯出草稿或已發布版本、匯入資料夾並發布新版本；操作目錄開始標示每個操作的性質，命令列說明會同步顯示讀取、寫入與破壞性三類；Gunicorn 的 keep-alive 改為可設定，預設十秒。
環境變數層面新增五個設定。OPS_TRACE_QUEUE 預設為 ops_trace_v2，OPS_TRACE_EXPORT_MAX_ATTEMPTS 預設六次，ENABLE_TRACE_PAYLOAD_SWEEP_TASK 預設啟用每日清理，APP_PACKAGE_MAX_WORKFLOW_TOOLS 預設二十個，GUNICORN_KEEP_ALIVE 預設十秒。舊有的四個追蹤相關設定同時移除，包括 OPS_TRACE_UNIFIED_ENABLED 與重試延遲參數。
巢狀工作流追蹤解決什麼問題？
工作流工具被另一工作流呼叫時，過去只看到外層節點成敗。此版把子流程的持久化執行步驟掛在工具區段之下，重複呼叫與失敗都保留位置，並保留提示詞與回應內容。
把工作流包裝成工具、再讓另一個工作流呼叫，是模組化的常見做法。這種結構的代價是除錯斷層：外層節點顯示成功或失敗，失敗原因卻埋在子流程內部，開發者只能逐層打開主控台核對。1.18.0 已經在主控台提供下鑽檢視，但外部追蹤匯出仍然只到工具層級。
1.19.0 補上這道缺口。被呼叫工具的持久化執行步驟會以子段落形式出現在外部追蹤，掛在呼叫它的工具區段之下，階層在嵌套與重複呼叫中保持一致。每段保留格式化的提示詞與回應、權杖用量，以及專案、追蹤與觀測三層連結，Langfuse、LangSmith、Opik、Weave、Arize、Phoenix、阿里雲、MLflow、Databricks 與騰訊雲都走同一條供應商介面。
三項限制需要留意。歷史追蹤不會回填，新階層只對升級後的執行生效；獨立嵌套的工作流執行仍然分開記錄，只以父識別碼關聯；暫停或停止之後的巢狀用量統計可能仍為近似值，不能當作計費依據。
可攜式應用套件如何搬移工作流工具？
匯出應用時，被呼叫的工作流工具會連同其傳遞依賴一併打包，預設上限二十個。匯入時重用目標工作區既有工具，缺失的會重建、發布並重新對應引用。
1.18.0 引入的 .ifpkg 套件把應用連同代理、技能與檔案收進單一檔案，但工作流工具背後的工作流仍需另行搬移。1.19.0 把這層依賴收進套件，並在匯入時處理引用重映射：目標工作區已有的工具直接重用，缺失的按綁定版本重建、發布與註冊，匯入失敗時已建立的應用會被清理。
套件格式同時統一為第二版，包括不含工作流工具的應用；第一版匯入與明確的 YAML 匯出仍然支援。這項改動帶來一個次序要求：舊版匯入器可能拒絕新格式套件，升級時應先更新接收端，再匯出新套件。官方亦提醒 YAML 匯出不攜帶工作流工具的依賴，需要完整交付時應改用套件。
建立缺失工具需要工具管理權限與足夠的應用額度。若套件內的工具需要確認 DSL 版本，此流程會直接拒絕，避免半完成的匯入留在工作區。
difyctl 如何管理技能？
六個命令涵蓋列出、檢視、版本查詢、匯出、匯入與發布。匯入只替換草稿不會自動發布，覆寫既有技能屬破壞性操作，需要相應工作區權限。
技能原本只能在主控台逐項操作，難以納入版本控制流程。1.19.0 開放六個帳號授權命令：get skill 支援關鍵字與標籤過濾，describe skill 讀取詳情與草稿雜湊，get skill version 列出已發布版本，export skill 匯出草稿或指定版本為壓縮檔，import skill --files 從本機資料夾建立或覆寫草稿，publish skill 把草稿發布為新版本。
匯入與發布分離是刻意的設計。匯入不觸發發布，管理員可以在匯入後先檢視差異再決定是否上線；覆寫既有技能歸類為破壞性操作，操作目錄與命令列說明都會標示。草稿雜湊提供樂觀鎖，避免兩人同時替換同一份草稿，但比對精度只到秒級，同一秒內的編輯無法偵測。
匯入流程另有多項防護。系統會過濾作業系統垃圾檔、拒絕不安全或重複路徑、限制檔案數量與大小、重用相同的二進位素材，並在匯入失敗時清除已寫入的素材。技能前置資料中的連字號會原樣保留，避免解析時被誤判為清單分隔。
升級到 1.19.0 需要注意什麼？
Docker Compose 需 2.35.0 以上，六個資料庫遷移終點為 53c10126d551，來源部署改用 Python 3.13 與 Node.js 24.22.1 以上。
升級指南列出多項前置動作。部署層面，Docker Compose 最低版本提升至 2.35.0，因為根目錄 .env 的覆寫需要先於服務預設值解析；內建插件守護進程同步升至 0.6.14-local；API、worker、web、代理後端與沙箱映像必須使用同一個 1.19.0 版本，並保留既有的沙箱權杖與 PASSWORD_PEPPER。
資料層面，從 1.18.0 升級會套用六個遷移版本，終點為 53c10126d551。其中三項需要事先評估：儲存清理索引會在 message_files、workflow_node_execution_offload 與 workflow_draft_variable_files 上建立參考索引，PostgreSQL 以並行方式建立，但仍然掃描資料並佔用 I/O；追蹤設定改為每個應用與供應商只保留一筆，重複資料以最近更新者為準，其餘刪除且降級不會還原；文件抽取修正只對重新匯入或重建索引的內容生效，既有重複的 PDF 素材不會自動清除。
來源部署的門檻亦提高。Python 版本改為 3.13，Node.js 需 24.22.1 以上的 24.x 版本，pnpm 為 12.16.1，且不再代為安裝 Node.js。這些條件令 1.19.0 更適合有測試環境與維護窗口的團隊。
追蹤佇列改動對滾動部署有何影響？
新任務預設投遞至 ops_trace_v2，API、worker 與排程器必須一致。自訂佇列清單要加入新名稱，舊消費者需待舊任務清空後才可下線。
追蹤匯出改由共用供應商介面統一投遞，可重試的匯出會以固定識別碼重送同一單位，避免重複寫入。這項改動連帶調整佇列名稱：新任務預設進入 ops_trace_v2，API、worker 與 Beat 三者的設定必須一致，自訂 CELERY_QUEUES、CELERY_WORKER_QUEUES 或命令列佇列清單的環境，需要把新名稱加入。
滾動部署的次序因此變得重要。舊的追蹤 worker 應繼續留在 ops_trace，直到舊生產者與其排隊中、執行中、預約中與重試中的工作全部完成；期間不應清空舊佇列，也不應要求已退役的處理器匯出舊訊息。若次序顛倒，追蹤資料會出現缺口而不會有錯誤提示。
憑證處理亦一併收緊。追蹤設定的讀取不再回傳已儲存的密鑰，改為回傳 configured_secrets 標記；變更目的地主機、端點或網址時必須重新輸入密鑰，留空或省略則保留原值。自訂客戶端若依賴舊欄位，需要同步修改。
Dify 的數據表現如何？
星標 160,397、分支 25,368、貢獻者 1,605 位，最近七日提交 294 次，未結議題 1,209 個，主要語言 Python，授權為修改版 Apache 2.0。
專案自二零二三年四月建立，兩年半累積十六萬顆星標。分支數維持在二萬五千左右，說明大量團隊把 Dify 當作出發點：分支之後的修改集中在自家模型供應商、自家工具與合規要求。未結議題一千二百零九個，對照一週二百九十四次提交，議題處理壓力仍然存在。
版本節奏值得注意。1.17.1 於九月十日發布，1.18.0 於十月二十三日發布，1.19.0 於十一月四日發布，最近兩次相隔十二日。這種節奏對自架團隊意味著每季至少要安排一次升級窗口，而 1.19.0 涉及資料庫遷移與佇列改名，窗口內必須一次完成。
安全修補涵蓋哪些範圍？
模型啟用與停用改由擁有者或管理員操作，匯出客戶端改為請求範圍的 Cookie，資料集權杖只能列出明確綁定的資料集，另升級 Authlib、LiteLLM 等依賴。
工作區權限方面，啟用或停用供應商模型需要擁有者或管理員身分，電子郵件可用性檢查需要帳號准入。這兩項把過去可由一般成員觸發的操作收回到管理層。
網路層面，共用 SSRF 客戶端改為請求範圍的 Cookie，回應 Cookie 只保留於當次外送請求及其重新導向，避免後續請求繼承前一請求的憑證。資料集層面，資源存取權杖只能列出明確綁定且有效的資料集，include_all=true 無法擴大範圍；舊有工作區層級的金鑰維持原有範圍，但不會繼承被注入擁有者的個人可見性過濾。
應用層面，以 DSL 覆寫既有應用時會保留原有的 Web App 存取模式，應用轉換亦繼承來源存取模式。依賴升級包括 Authlib 1.9.1、LiteLLM 1.100.4 以上、代理端 Pydantic AI 2.53.0、Pillow 13.0.0 與 pypdf 6.21.4，另更新 Werkzeug 與 GitPython 等項目。官方明確說明，這些原始碼層面的更新不宣稱修復外部或企業版基礎映像中的全部問題。
出處連結有哪些？
原始碼位於 GitHub 的 langgenius/dify 儲存庫，1.19.0 發布頁含亮點、升級指南、詳細變更與環境變數對照四段，並附拉取請求編號供追溯。
專案位址為 https://github.com/langgenius/dify，1.19.0 的發布頁分為亮點、升級指南、詳細變更三段，另附環境變數與端點相容性對照。官方文件站 docs.dify.ai 提供自架安裝、模型供應商與工作流節點的中文說明，繁簡中文版本均在儲存庫內同步維護。
端點相容性另有三項變更需要核對。帳號名稱、頭像、介面語言、介面主題與時區五個 POST 端點已由 PATCH /console/api/account/profile 取代；追蹤設定查詢改為讀取 configured_secrets；工作流與對話流程的停止改走 stop.run，訊息型應用維持以任務識別碼停止的舊路徑。
總結：Dify 1.19.0 值得升級嗎？
值得升級，前提是先更新接收端套件格式並安排協調窗口。巢狀追蹤與可攜式工具套件直接改善除錯與交付，佇列改名與六個遷移則要求一次完成。
1.19.0 的三組改動回應三個實際痛點：除錯時看不到子流程內部、應用搬移時漏掉工具依賴、技能管理無法納入版本控制。其中巢狀追蹤與可攜式套件的完成度較高，可以立即投入使用；技能管理命令需要開啟對應功能並具備工作區權限，屬於有條件可用。
升級判斷可以簡化為兩個問題：團隊能否在一個維護窗口內同步更新所有元件與六個資料庫遷移，以及是否已有測試環境驗證追蹤佇列的雙軌過渡。兩項都成立時，1.19.0 帶來的觀測深度與交付便利值得投入；任何一項不成立，先補齊環境會比急著升級更有效率。
