核心觀念與架構設計
在Day20，我們成功將純靜態工作流轉換為支援 Markdown 渲染的架構審查 Chatbot。然而，單一路線的架構在面對多元提問時顯得力不從心：當使用者提出與內部開發規範無關的外部動態問題時，大模型只能硬套內部規範模板作答。

為了讓架構顧問具備判斷問題性質並自主調用外部工具的能力，我們在 Day 21 正式重構畫布拓撲，導入 「意圖分類器（Question Classifier）」 與 「DuckDuckGo 外部聯網搜尋工具」。

架構設計的核心理念

• 互斥單選（OR）與條件分流：問題分類器扮演前額葉角色，根據提問意圖選擇單一最佳執行路徑，避免無差別調用外部工具造成延遲與資源浪費
• 檢索前置查詢改寫（Query Rewriter）：使用者的自然語言往往包含多餘贅字，透過前置的LLM3將提問提煉為乾淨的搜尋關鍵字，大幅提高搜尋引擎的回傳精準度
• 多路分支終端閉環（Multi-path Convergence）：各分支獨立完成計算後，直接收攏至同一個終端節點，並透過變數容錯機制確保無論走哪條路線都能正確印出成果

實作流程與節點配置
本次重構重點在於解開畫布上交錯的死鎖連線，並理順搜尋支線的資料流動。

步驟一：意圖分類器配置
在「開始」節點後方接入「問題分類器」，設定三種清晰的意圖類別：

1. 內部規範諮詢：涉及團隊內部的 RESTful API 設計命名規範、內部代碼檢查準則
2. 複合交叉比對：同時涉及內部規範與外部最新技術變更的架構評估
3. 一般技術與其他諮詢：包含通用程式語法、外部最新版本動態及聯網搜尋需求

步驟二：拆解死鎖拓撲，建立獨立搜尋支線
1.解除匯流死結：將原先從搜尋分支誤連至LLM4的多餘連線全數拔除，避免因等待未執行的平行分支而造成整個流程卡死

2.打通外部搜尋流程：分類器「一般技術與其他諮詢」出口連至LLM3查詢改寫器）

• LLM3輸出連至 DUCKDUCKGO SEARCH 工具節點
• DUCKDUCKGO SEARCH 輸出連至負責解讀結果的LLM2節點

3.修復變數引用盲點：在 LLM 2 節點中，移除錯誤的預設上下文 標籤，改為明確綁定 {{#DUCKDUCKGO SEARCH.text#}}，確保大模型能確實讀取搜尋爬回的即時文本

步驟三：終端回覆節點變數多重掛載
將LLM2的輸出連線直接接入終端「直接回覆」節點。在「直接回覆」的內容框中，同時宣告三個互斥變數：

{{#LLM 4.text#}}{{#LLM_BACKUP.text#}}{{#LLM 2.text#}}

由於分類器每次僅會執行一條路徑，未走的分支輸出為空字串，有產出結果的分支文字便能順利呈現在對話介面中。

實測驗證與成果展示
為了驗證分類器能否正確分流，我們進行了兩組對比測試：

測試一：內部架構規範審查

測試提問：「我們團隊計劃新增批次刪除 API：DELETE /users/clean-inactive，資料庫預計使用舊版 session.query().delete()，請評估架構衝突。」
執行歷程：開始 ➔ 問題分類器 ➔ 知識檢索 ➔ LLM ➔ LLM 4 ➔ 直接回覆
結果判定：系統正確辨識為內部規範議題，沒有盲目調用搜尋工具，而是精確比對本地知識庫產出審查報告

測試二：即時外部資訊檢索

測試提問：「請問今天台北的天氣與氣溫如何？」
執行歷程（實際監控數據）：

1. 開始（0.240 ms）
2. 問題分類器（2.158 s，精準判定走一般諮詢分支）
3. LLM 3（937.530 ms，將自然語言改寫為搜尋查詢）
4. DUCKDUCKGO SEARCH（3.776 s，成功連線外部引擎爬取網頁）
5. LLM 2（1.919 s，讀取搜尋結果並總結）
6. 直接回覆（0.135 ms）

今天台北的天氣是90°F（約32°C），天氣多雲。
請注意接下來幾天會有變化，建議關注即時天氣預報。

外部動態數據順利渲染至對話框，證實外部搜尋工具已被完整打通！

踩坑記錄與心得小結
在本次畫布重構過程中，我們解決了三個極具代表性的Dify工作流陷阱：

1. OR 分流與 AND 匯流造成的排程死鎖：問題分類器是單選條件跳轉（OR），若下游節點（如 LLM 4）同時接了多條不同分支的線（AND 等待），排程器會因永遠等不到未執行分支的變數而直接死鎖。解法是將各分支的生命週期獨立，最終直接匯入終端回覆節點
2. 工具輸出變數與 RAG 上下文混淆：在 LLM 節點設定時，容易誤填系統內建的上下文標籤，但該標籤專屬於知識庫檢索。外部工具（Tool）回傳的文字必須手動插入對應的 {x} text 變數，大模型才能真正取得搜尋內容
3. 大模型對搜尋結果的逼真幻覺：在測試版本查詢時，若路徑未正確走到搜尋節點，大模型可能會根據提示詞「假裝」自己執行了搜尋並捏造看似合理的版本號與Issue。檢查執行面板中的 Node Execution List 才是確認工具是否真正運行的唯一標準