Dify 社群提出排程身分修補，處理 Agent 檔案上傳成功卻無法取回

Dify 社群於 10 月 26 日回報，含有新版 Agent 節點的工作流程，在 Studio 手動執行可正常產生檔案，改由排程觸發卻出現 ToolFile not found。回報者使用自架 Kubernetes 環境，觀察到檔案上傳成功後，下載請求隨即失敗；Agent 節點雖被標為成功，下游仍因缺少 files 變數而中止。問題回報

這類故障會直接影響自動報表交付。Dify 官方文件將 Schedule Trigger 定位為定時執行工作流程的入口，可透過視覺介面或 cron 設定週期，用於每日報告與通知。依此使用情境推論，只確認編輯器內的手動測試通過，仍不足以證明背景排程能完成檔案交付。官方排程文件

候選修補指出，問題出在呼叫來源與使用者身分的推導不一致：排程以 SERVICE_API 來源執行，但實際發起者是工作區 Account；執行器卻依來源將其標為 end-user。上傳時，檔案歸屬映射後的終端使用者；下載時則拿原始帳號識別碼查詢，兩端因此找不到同一筆資料。PR #44799 提議在仍掌握真實使用者物件的入口記錄角色，讓執行器優先沿用。身分傳遞修補

另一份 PR #44796 進一步涵蓋暫停快照與恢復執行，並兼容未記錄角色的舊快照。作者表示，103 項相關測試通過，涵蓋檔案建立、下載重建，以及拒絕其他使用者與租戶存取；但未在本機測試外部 Agent 服務或已部署的排程工作流程。兩份提案截至查核時仍開放，不能視為正式版本已修復。工程團隊接下來應關注合併與發版狀態，並以實際排程驗證首次執行、暫停恢復及檔案權限是否一致。修補與驗證範圍