核心觀念與架構設計

在Day21中，我們成功打造了具備意圖分類與DuckDuckGo聯網搜尋雙軌路由的架構審查 Agent。然而，在導入實際對話場景測試時，我們遇到了兩個直接影響產品可用性與專業度的瓶頸：

• 介面交互冗餘（雙重輸入框問題）：在將工作流轉為 Chatflow 時，因啟動節點遺留了自訂欄位，導致使用者每次開啟新對話都必須在彈出表單填寫一次，又得在底層對話框輸入一次，嚴重破壞對話流暢度
• 多輪指代斷裂（Coreference Breakdown）：使用者在連續對話時習慣使用代名詞（如「那它效能如何？」、「這個功能上線了嗎？」）進行追問。若搜尋改寫器缺乏對話記憶，直接提取「它」作為關鍵字送進搜尋引擎，將導致檢索完全失焦，喪失作為AI顧問的精準度

核心設計理念

• 回歸標準對話語義（System Native Query）：徹底清理「開始」節點的手動輸入欄位，全面對齊Dify內建的 sys.query 系統標準變數，還原最直覺的單一輸入介面
• 多輪上下文記憶緩衝（Window Buffer Memory）：在關鍵的中介改寫節點與結果解讀節點開啟對話記憶視窗（Window Size = 5），確保模型在短多輪對話中保持上下文連貫性，同時避免過大Window造成的Token浪費與注意力漂移
• 指代消解改寫器（Coreference Resolution Agent）：升級LLM3為專業的指代消解代理人，任務不是單純精簡句子，而是優先比對前幾輪對話紀錄，將口語代名詞精確還原為實體名詞，確保交給外部搜尋引擎的關鍵字具備獨立性與精確度

實作流程與節點配置
步驟一：清除「開始」節點表單，切換系統標準變數

1. 進入畫布最左側的 「開始」節點，刪除原先手動配置的 {x} query 自訂欄位，解除新對話強制彈窗。

2. 全面檢查後續節點：

   • 問題分類器：輸入變數指向系統對齊的 開始 / query
   • LLM 3、LLM 2、LLM 4：提問輸入統一更新為對齊系統傳入的使用者訊息標籤

步驟二：配置 LLM3（指代消解查詢改寫器）將原本單純過濾贅字的改寫器，升級為具備上下文還原能力的 Agent：

• Model：gpt-4o-mini

• 輸入變數（USER）：{{#開始.query#}}

• 記憶配置：

  • 開啟「記憶（Memory）」
  • 開啟「記憶窗口（Memory Window）」，設定視窗大小為 5

• System Prompt 核心設定：

你是一位專業的對話脈絡分析與搜尋查詢改寫專家（Coreference Resolution Agent）。

【任務目標】
請分析使用者的最新提問與對話歷史紀錄：
1. 若使用者的提問包含代名詞（例如「它」、「這個技術」、「剛才那個版本」）或省略了主詞，請依據歷史對話內容將其補齊為完整的實體專有名詞。
2. 將補齊後的意圖提煉為 1~3 個最適合在 DuckDuckGo 搜尋引擎檢索的純關鍵字，關鍵字之間以空格分隔。
3. 若使用者的提問已經是完整具體的獨立查詢，直接提取該問題的核心搜尋關鍵字即可。

【輸出規則】
- 僅輸出搜尋關鍵字，嚴禁添加標點符號、問候語、前綴或任何解釋性文字。

步驟三：強化 DuckDuckGo 搜尋深度與 LLM 2 記憶

1. DUCKDUCKGO SEARCH 節點：

• 輸入變數：{{#LLM 3.text#}}
• 參數調優：將 MAX_RESULTS 從預設的5調整至10，擴增搜尋深度與內容覆蓋面

2. LLM 2（搜尋總結）節點：

• 變數關聯：【搜尋參考資料】 綁定 {{#DuckDuckGo Search.text#}}，【使用者提問】 綁定 {{#開始.query#}}
• 記憶配置：開啟「記憶」與「記憶窗口」，設定視窗大小為5

實測驗證與成果展示
測試場景：連續多輪追問與指代消解驗收
【第 1 輪提問：建立實體主題】
使用者輸入：*「請問 Vue 3 的最新穩定版本出到哪裡了？Vapor Mode 正式推出了嗎？」
*
執行路徑：開始 (0.094 ms) ➔ 問題分類器 (2.402 s) ➔ LLM 3 (1.260 s) ➔ DUCKDUCKGO SEARCH (4.019 s) ➔ LLM 2 (1.440 s) ➔ 直接回覆 (0.125 ms)

輸出結果：系統正確歸類至外部檢索線，回傳 Vue 3 目前最新狀態及 Vapor Mode 尚未正式推出的最新動態

【第 2 輪追問：省略主詞之指代消解測試】
使用者輸入：「那它不用 Virtual DOM 的話，到底是用什麼原理來提升渲染效能的？幫我查一下。」

執行歷程監控：

1. 問題分類器：耗時 1.495 s，順利識別為技術諮詢
2. LLM3：耗時 1.633 s，成功提取上一輪的對話歷史，將「它」精準補齊為「Vue 3」與相關渲染特性
3. DUCKDUCKGO SEARCH：耗時 2.473 s，攜帶補齊後的關鍵字完成外部檢索
4. LLM2：耗時 2.672 s，整合檢索資訊產出分析

實際產出報告：

根據搜尋參考資料，Vue 3 提升渲染效能的原理並未被明確提及。然而，Vue 3 通常使用了
一些改進的策略，例如更高效的響應系統和組件重新渲染的優化。具體來說，它可能包括優化
的數據響應性和更快的渲染機制。

若需更詳細的技術資訊，建議查閱官方文檔或相關的更新信息。

成果判定：
使用者在第二輪提問完全未提及「Vue 3」或「Vapor Mode」，但系統回覆開門見山以「根據搜尋參考資料，Vue 3 提升渲染效能的原理……」切入，證實多輪對話記憶與指代消解機制已完整串通且正確運作！

踩坑記錄與心得
自訂變數與系統原生對話變數的衝突：在 Chatflow 畫布中，若在「開始」節點額外宣告string變數，Dify會將其定義為開場表單，破壞標準對話體驗。Chatbot 應盡可能使用系統對齊的原生提問傳遞方式，保持乾淨簡潔的輸入視窗

記憶視窗（Window Size）的精準控制：記憶並非開得越大越好。若記憶視窗開到 50 輪，不僅會消耗極大Token 成本，還容易因歷史資訊雜訊過多，導致指代消解模型把幾輪之前的舊主題誤當成當前代名詞的主體。將 Window 限制在5輪以內，是平衡改寫精確度與資源消耗的最佳實踐。

搜尋深度對回答品質的直接影響：MAX_RESULTS 設為5時容易抓到廣泛但不夠聚焦的摘要；適度調整為10能讓 LLM取得更充足的長尾技術細節，有效降低「資料未提及」的盲區。