Firecrawl 提出零資料保留修補，補齊擷取設定在研究與開發者搜尋的傳遞

Firecrawl 的零資料保留設定出現跨服務傳遞缺口。專案成員 mogery 於 10 月 25 日提出 PR #5394，指出研究代理原先只依搜尋端模式判斷是否啟用零資料保留（ZDR）；若團隊僅設定 scrapeZDR: "forced"，研究、GitHub、開發者與政府搜尋仍會走完整資料保留流程。這是提案作者對既有行為的描述，目前尚無受影響客戶數或實際資料留存事件的公開證據。修補提案

這個問題涉及兩組不同的控制。官方搜尋文件說明，enterprise 參數控制搜尋部分，與擷取端的 zeroDataRetention 選項分開；端到端 ZDR 要求 Firecrawl 與上游搜尋供應商都不保存查詢或結果，匿名化模式則允許上游快取匿名查詢。對建置研究代理或 RAG 管線的團隊而言，確認每一段請求採用哪種模式，會直接影響資料處理邊界。搜尋與 ZDR 文件

提案改用既有設定解析函式，只要擷取或搜尋任一端被強制要求 ZDR，就對相關研究控制器套用保留限制。具體變更包括遮蔽 requests.target_hint、清空或遮蔽研究資料表的敏感欄位、排入清理工作，以及讓日誌攜帶 ZDR 標記供過濾器移除；送往研究、開發者與政府服務的標頭也會改為 firecrawl-zero-data-retention: true。實作說明

從工程角度看，這提醒團隊應沿著入口、資料庫、日誌與上游服務逐段驗證保留政策，不能只檢查客戶端旗標。作者已列出新增測試，但頁面同時顯示五筆深度研究測試失敗，尚不能判定是否與修補相關。截至查核，PR 仍開啟，沒有可確認的正式修復版本或部署證據；後續應追蹤合併與上線狀態，並以僅強制擷取 ZDR 的團隊設定驗證欄位遮蔽和上游標頭。測試與提案狀態