Dify 提出串流輸出先審後送草案，揭示逐段內容審查的防護邊界

Dify 社群於 11 月 4 日提交串流輸出審查草案，嘗試縮小文字先抵達使用者、背景審查稍後才替換內容的時間差。截至查核時，PR #45536 仍為草案，設定名稱及應採整個部署或個別應用層級，均待維護者決定。提案說明

Dify 現有工具箱可審查輸入、輸出或兩者，支援審查模型、關鍵字與自訂端點。這次提案改變的是內容交付時機：設定 MODERATION_OUTPUT_MODE=blocking 後，適用應用會先緩衝文字，將累積答案交給審查服務，通過後才釋出該段；預設仍維持非同步模式。官方工具箱文件、草案

這項設計直接影響延遲與服務成本。首段文字須等待緩衝區達門檻或回答結束，再加上一次審查呼叫；後續各段也須等待檢查。由於每次送出累積答案，回答越長，審查輸入量越大。提案也明言，後文可能讓先前通過的文字變成違規內容，因此仍可能發生已送出文字遭替換，無法保證最終被判定有問題的答案完全未曝光。延遲與限制

防護範圍同樣有限：草案只攔截 message 文字事件，Agent 應用仍沿用既有行為；語音、推理片段、檔案及部分工作流程事件不在範圍內。停止回應串流也不會取消伺服器上的模型呼叫或工作流程。這使應用整合者必須逐一檢查實際輸出通道。草案限制

外部審查服務的轉接方式也值得驗證。阿里雲既有 Dify 整合範例，會將長輸出截取為最近兩千字元再送審；據此可推論，即使 Dify 傳送累積答案，端點也未必檢查完整上下文。工程團隊接下來應關注審查範圍、跨段命中與服務失敗時的行為，並等待維護者確認設計及發布版本。阿里雲整合文件