一個月前發了篇文章介紹了基于 MiniO 存儲的 RAGFlow+Dfiy 圖片處理方案，之后有幾個知識星球內的星友提問，如何優化上一版方案中不能流式輸出的問題。

這篇試圖說清楚，三種 RAG 圖片問答的方案迭代過程，油猴腳本 (Tampermonkey)的具體實現方式，以及項目架構梳理。

以下，enjoy:

1、多階段方案演進

在現有開源框架基礎上，不改動核心代碼，又要達到較好的流式圖文體驗，這自然會引入一些“變通方案”。本著“規避 LLM 弱點”、“模塊化處理”、“逐步優化體驗”的工程實踐思路，我前后進行了以下三種方案的探索，其中前兩個歷史文章已經詳細介紹過，這篇先大致回顧下前兩種的核心理念，后續主要就第三種方案展開。

1.1直接嵌入 HTML 的局限性

為了能在 RAGFlow、Dify 這類封裝度較高的框架中，回答顯示原文相關圖片，富文本處理 (圖片轉 URL)是基礎，也是讓圖片有被瀏覽器渲染的可能。我在最開始的工程化嘗試里，采用了最簡單直接的方式，就是通過圖片服務器容器化方案，把圖片直接使用 <img> 標簽和其公開的 HTTP URL 放處理后的富文本中，這樣只要在回答中輸出圖片 URL，瀏覽器就可以直接渲染。

但 LLM 在處理包含復雜 HTML 結構或 URL 的文本時，可能會“創造性地”修改它們。尤其明顯的就是 LLM 會想當然的按照 Next token prediction 的套路修改 URL 中的圖片名稱，從而導致加載失敗。

1.2后端占位符替換

為了解決“LLM 可能會改動富文本中的 URL”這個問題，把不穩定的 URL 替換為 LLM 更難篡改的、有特定格式的占位符，并把替換邏輯后置，這樣可以盡可能的確保數據在經過 LLM 后的完整性和可解析性。

具體來說，本地 python 腳本針對原文檔進行預處理后，提取圖片和 map.json 存入 MinIO，文本中插入占位符上傳至 RAGFlow 的知識庫。緊接著 Dify 工作流中，通過 HTTP 節點獲取 map.json，Code 節點進行后端替換。

這個迭代方案的優點是最大限度的解決了 LLM 修改圖片鏈接的問題，保證了圖片引用的準確性。但也帶來了新的痛點，就是 Dify Code 節點的批處理特性，導致圖片無法隨 LLM 的流式回答實時顯示，用戶體驗有明顯的延遲，尤其是針對選擇了帶顯示思維鏈的 LLM 而言，提問后的等待就變得更加反人性。

1.3前端實時渲染

先做下定義掃盲，簡單來說油猴腳本就是個瀏覽器擴展插件，在授權前提下允許用戶運行自定義 JavaScript 腳本來修改網頁。通俗解釋就是給網頁打“補丁”，增強或改變其功能。選擇這種做法的核心原因是可以非侵入式的修改 Dify 前端行為，免去了改動 Dify/RAGFlow 源碼的風險。（直接增強后端流式處理能力或前端渲染邏輯。成本高，且影響框架升級。）

經過了前兩個階段的試錯之后，就很自然的過渡到這個前端實時渲染的方案。引入油猴腳本后，就是把圖片占位符的替換工作從 Dify 后端轉移到用戶瀏覽器前端，從而實現圖片隨 LLM 文本流式輸出同步顯示，優化用戶的使用體驗。

總結來說，目前主流的、主要基于文本處理的 LLM（即使是某些聲稱支持多模態的，在處理嵌入式 HTML 時也不完美），都不擅長精確保持和輸出復雜的結構化數據如 HTML。上述后兩種方案討論的“占位符+映射替換”策略，本質上是將“結構化內容渲染”這個任務從 LLM 的職責中剝離出來，交給了后續更可控的程序（Code 節點或前端腳本），這是一種有效的規避 LLM 短板的思路。

如果使用 Langchain、LlamaIndex 這些自主開發 RAG 系統，在回答中顯示圖片的效果會簡化很多，但圖片提取、存儲和 URL 管理的復雜性依然存在，而且需要編寫更多的代碼來搭建整個應用。

2、項目架構圖

為了讓大家看的清楚些，整了張流程圖再還原下整個數據流和處理環節：從 PDF 到 MinIO，再到 RAGFlow 知識庫，Dify 調用，LLM 處理，最終油猴腳本渲染。

3、油猴腳本的具體實現

3.1@match 指令

這個指令位于油猴腳本的元數據頭部（// ==UserScript== 塊內），它告訴 Tampermonkey 擴展只有當用戶訪問的網址符合我列出的這些模式時，才需要激活并運行我這個腳本。

在這個本項目中， 需要將 @match 指令精確配置為 Dify 應用的聊天頁面 URL 模式，例如 http://localhost/chat/* 或 ://<你的 Dify 域名>/app//chat/*。這樣，只有當用戶進入 Dify 聊天界面時，圖片替換腳本才會被激活。

3.2map.json 的 URL 配置

我們的腳本需要知道哪個圖片占位符（如 [IMG::image1.png]）對應哪張真實的圖片（如 http://minio-server/bucket/image1.png）。 這個對應關系存儲在由 process_pdf.py 腳本生成并上傳到 MinIO 的 map.json 文件中。腳本內部通常會有一個變量（例如 mappingFileUrl）來存儲這個 map.json 文件的完整 HTTP URL。腳本在初始化時，會通過這個 URL 異步下載并解析 map.json 的內容。

在這個本項目中： 這個 URL（例如 http://localhost:9000/ragflow-public-assets/mappings/demo_map.json） 是在腳本首次運行時通過提示框讓用戶輸入，或者直接在腳本中配置一個默認值。正確配置此 URL 是腳本能否找到正確圖片鏈接的關鍵。它是連接占位符與實際圖片的橋梁。]

3.3CSS 選擇器

為了在網頁上準確地找到需要處理的內容（即機器人回復的聊天氣泡，以及包含這些氣泡的總容器），需要使用 CSS 選擇器幫助腳本在復雜的 HTML 結構中定位到目標元素。

注：通過瀏覽器開發者工具（F12）仔細檢查 Dify 聊天頁面的 HTML 代碼，找到能夠穩定標識機器人消息（例如，通過特定的 class 名如 div.markdown-body 或更復雜的組合選擇器）和聊天總容器的 CSS 選擇器，并將其配置在腳本中。

BOT_MESSAGE_SELECTOR：用于定位每一條由機器人發出的消息的 HTML 元素。腳本將在這個元素內部查找并替換圖片占位符。CHAT_MESSAGE_CONTAINER_SELECTOR：用于定位包裹所有聊天消息（用戶和機器人的）的父容器。MutationObserver 會監控這個容器的內容變化。

這是腳本能否正確工作的核心中的核心。如果這些選擇器不正確或不夠精確，腳本可能根本找不到機器人回復，或者錯誤地修改了頁面的其他部分。由于 Dify（或其他任何 Web 應用）的前端 HTML 結構可能更新，這些選擇器是最需要根據實際情況進行細致調試和配置的部分。

3.4油猴腳本的局限性

首先是用戶端依賴問題，因為不向后端服務是面向所有用戶修改的，油猴腳本的使用需要每個用戶在自己的瀏覽器上安裝 Tampermonkey 擴展并安裝該特定腳本，這個雖然也不復雜，但確實增加了一定的用戶側操作成本。

其次是前端結構依賴問題，因為腳本強依賴于 Dify 前端頁面的 HTML 結構（CSS 選擇器），如果 Dify 前端更新導致結構變化，腳本可能失效，所以可能需要不定期維護。

4、寫在最后

4.1RAGFlow+Dify 組合的必要性

在當前這個方案中，RAGFlow 負責知識庫處理，Dify 負責應用層和交互，油猴腳本負責前端體驗增強，三者協同工作。即使圖片渲染由油猴腳本在前端完成，Dify 作為應用編排和用戶交互界面的價值依然存在，尤其是在面對更復雜工作流編排的需求時。

4.2油猴腳本的一些其他玩法

對于沒有接觸過油猴腳本的盆友，這里再列舉兩個經典的用法，感興趣的可以試試看：

API 接口調試與 Mock 數據注入

在前端開發或與后端進行接口聯調時，經常會遇到后端接口尚未開發完成、接口不穩定、或者需要特定返回數據才能觸發某些前端邏輯的情況。油猴腳本可以用來攔截前端發起的 API 請求（通常是 XMLHttpRequest 或 fetch），并對其進行修改或直接返回一個預設的（Mock）響應。

網頁自動化測試與表單填充

對于一些需要頻繁進行回歸測試的 Web 應用，或者需要重復填寫大量表單的場景，油猴腳本可以編寫自動化腳本來模擬用戶操作，如點擊按鈕、輸入文本、選擇下拉框、提交表單等。

4.3“雕花”的階段性選擇

從步驟數量和涉及的組件來看，這個項目流程顯得有些復雜。但這種復雜性也往往源于我們試圖在現有框架（Dify/RAGFlow等）的限制下，實現一個它們并未原生完美支持的流式圖文混合輸出。

隨著多模態 LLM 能力的增強，也許能更直接地處理和引用上下文中的圖片，減少對占位符的依賴，或者輸出更結構化的指令來顯示圖片。 引導 LLM 輸出更結構化的數據（如 JSON 對象列表，明確指示文本和圖片），而不是自由文本中夾雜占位符，能讓后續處理更簡單。

Anyway，圖片回答更多是錦上添花，文檔預處理和分塊等基礎環節的優先級依然是最高的。