Dify 社群回報代理歷史載入重複提示，長對話可能推高 API 記憶體用量

Dify 一則於 10 月 22 日提出的技術回報，將長對話的效能瓶頸指向 API 端的歷史資料載入。回報者表示，自架版 1.17.1 與當日檢查的主分支仍有此行為，並提供可對 PostgreSQL 執行的重現程式；目前證據屬於社群測試，尚不能推定所有部署都會出現相同結果。問題回報

依回報分析，organize_agent_history 會讀取整段對話的完整訊息資料列，其中 Message.message 保存了各輪生成時使用的提示。當每輪提示都包含先前對話，第 n 輪的資料便再次收錄前 n−1 輪內容；一次載入所有資料列，讀取的文字量因此可能接近平方成長。然而，歷史重建實際使用的是問題、回答及代理思考紀錄，並不需要這個大型提示欄位。技術說明與程式

回報者在合成的 700 輪對話測試中，量得單次歷史建立增加約 1.36 GB 的 RSS，耗時約 4.2 秒；改以 load_only 選取必要欄位後，降至 10.3 MB 與 0.80 秒。這是隔離測試，不能直接當作正式環境的改善保證，也未證明程序會永久保留全部記憶體。量測結果

修補方向具有明確的 ORM 依據：SQLAlchemy 文件說明，load_only 可讓查詢略過未指定的大型欄位，但後續存取仍可能觸發延遲查詢；raiseload 則能在意外存取時拋錯。這表示驗證重點除了記憶體下降，也應確認後續路徑沒有重新載入提示欄位。SQLAlchemy 文件

對維運團隊而言，值得把對話輪數納入容量測試，並分別觀察歷史建立耗時、程序記憶體與 SQL 查詢。工程上還應檢查裁減欄位前後的歷史內容是否一致，以及工具紀錄較大的對話是否仍有瓶頸；這些是由回報推導的驗證建議。目前仍須等待維護者確認、修補合併及版本交付，才能判定實際受影響範圍。