Dify 社群提出結構化輸出修補，推理區塊 JSON 可能被誤選為正式答案

Dify 的結構化輸出流程出現一項值得工作流開發者注意的解析問題。10 月 13 日，一名使用者回報，自架 Dify 1.11.2 Enterprise 經 LiteLLM、vLLM 呼叫推理模型時，正式答案已包含要求的 type、content 欄位，節點卻將推理文字內的 {"think":"start"} 回傳為 structured_output。回報附有設定、串流欄位與輸出對照；啟用推理標籤分離後仍觀察到問題。原始回報

技術焦點在於解析順序。回報分析指出，供應商外掛可能先把推理內容包進 <think> 標籤，再與答案合併。結構化解析器接收到整段文字，直接解析失敗後交由 json_repair 修復；若結果包含多個物件，既有路徑會選取第一個字典，因此可能拿到推理中的暫存物件。另一位參與者針對當時主分支的函式進行局部測試，在阻塞與串流路徑均得到相同結果，但測試使用模擬模型輸入輸出，並非完整部署驗證。技術討論

同日提出的修補 PR #44005，會在特定修復路徑中略過開頭的推理區塊，再解析後方答案。提案保留原始訊息與串流片段，避免改寫答案字串內合法的 <think> 文字；作者也列出跨片段標籤、大小寫變體及純 JSON 等測試。不過，截斷或僅有推理內容時仍保留原行為，完整 Schema 驗證亦未納入，這些邊界仍須審查。修補提案

官方文件將結構化輸出定位為供程式使用的資料，並說明推理分離可將思考內容移至獨立變數。這使本案具有實務意義：依上述案例推論，若下游直接採用解析結果，分類、欄位擷取或條件分支可能接收到錯誤物件。工程團隊宜加入「推理與答案各含不同 JSON」的驗證案例，並檢查必要欄位；截至查核，提案仍開放，尚不能視為正式修復，也不能推定所有模型與版本均受影響。官方 LLM 節點文件