Dify 社群回報語音工具用量歸類異常，生成器延後執行使來源資訊遺失

Dify 社群於 10 月 29 日提出用量追蹤缺陷：內建語音辨識（ASR）與語音合成（TTS）工具使用生成器函式，但負責標記用量來源的裝飾器，可能在工具真正執行前就結束作用範圍。回報針對當日主分支提交 e5acabc3d，翌日被加上「1.18.0 Bugs」標籤；截至查核時，議題仍未關閉。議題與重現說明

關鍵在於「取得生成器」與「執行生成器」發生於不同時間。Python 官方文件說明，呼叫生成器函式只會回傳迭代器，函式內容要等到 next() 等操作才開始執行。因此，若裝飾器只在 with 區塊內呼叫函式並立即回傳，區塊便會先退出，後續迭代無法取得原本設定的上下文。Python 生成器語義

依回報者提供的 ASR 測試輸出，模型管理器取得的用量中繼資料為 None；改為在迭代期間維持上下文後，才讀到 audio 來源。回報指出，這個快照差異會讓用量來源落入 UNKNOWN。目前公開證據主要來自作者的程式碼分析與測試輸出，仍缺少獨立重現，也未證明扣款金額錯誤。回報細節

對維運者而言，值得關注的是語音成本的可追溯性。若來源分類失準，依功能彙整的用量分析可能低估語音占比；這是由回報機制推導的風險，實際範圍仍須核對部署版本與用量紀錄。工程上，驗證也必須真正消費迭代器，僅建立生成器物件無法觸及模型呼叫。

作者建議讓裝飾器涵蓋迭代過程，或將上下文移入兩個工具的執行本體。後續修補應檢查正常結束、例外與提前關閉時是否正確還原上下文；Python 的生成器關閉機制會涉及待執行的 finally 區塊，這使清理路徑同樣需要驗證。修補建議、Python 關閉行為