前言：從「單一分流」走向「資訊聚合」
在Day16中，我們運用問題分類器建立了「各走各路」的基礎分流架構：問內部規範就走內部知識庫，問外部新技術就走網路搜尋。但在真實的軟體架構決策中，我們需要的往往不是單純查條文，而是具備判斷力的架構顧問（Dev-Advisor）。當工程師詢問：「我們能否將 Python 升級到最新版本？」時，系統不能只條列 Python 的新功能，也不能只丟出死板的公司手冊，而是要將「外部最新技術趨勢」與「內部既定架構約束」進行交叉比對（Synthesis / Cross-Reference），指出升級後的相容性與違規風險。

今天我們將全面升級工作流，挑戰讓多個資料來源匯流，實現真正的「多源資訊交叉審查」。

一、 架構演進：第16天 vs. 第17天
為什麼路線設計會發生改變？關鍵在於節點的職責升級：

二、 工作流拓撲與資料流設計
在Day17的進階架構中，資料流被劃分為三大階段：

1. 內部知識分支：透過「知識檢索」節點讀取企業內部規範手冊（《Dev Standards v2.0》），交由專屬LLM進行條文萃取
2. 外部網路分支：提煉使用者提問關鍵字，呼叫DuckDuckGo進行即時檢索，由LLM2彙整最新技術特點
3. 資訊匯流節點（LLM 4）：作為全域架構顧問，同時攝取內部規範與外部技術情報，執行條款對照與衝突分析
4. 聚合輸出節點：統一接收內部審查、外部技術與綜合比對三大觀點，提供多維度的決策依據

三、 今日實戰踩坑與關鍵除錯紀錄
在實作複雜的聚合型工作流時，往往會面臨快取、檢索門檻與模型負載等連環挑戰

1. 排除底層快取殘留與幽靈變數（Variable not found）

   • 問題現象：刪除或重建上游節點後，下游的 LLM 4 出現 Variable #...text# not found 報錯
   • 根本原因：節點Prompt中殘留了歷史節點的變數標籤引用，造成底層ID斷鏈
   • 解決方案：清除提示詞內失效的變數標籤，改以明確的文字指引，或重新綁定當前活躍節點的輸出變數

2. 突破 Google API 伺服器尖峰（503 UNAVAILABLE）

   • 問題現象：執行時節點亮紅燈，拋出 PluginInvokeError: 503 UNAVAILABLE - This model is currently experiencing high demand

   • 根本原因：免費層級（Free Tier）共用頻寬池在尖峰時段負載飽和，伺服器直接拒絕服務

   • 排查思路：

     • 此非工作流設計缺陷，無須重拉線路。
     • 在節點中將容易塞車的預覽模型（如 Flash-Lite）切換為資源池較穩定的版本（如 gemini-1.5-flash 或 gemini-2.5-flash），或配置第二家供應商（如 DeepSeek、Groq）作為分流備援

3. 優化向量檢索召回率（Top K 陷阱）

   • 問題現象：模型執行成功，但回覆「手冊中未包含具體API命名與規範細節，僅有標題」
   • 根本原因：知識檢索節點的 Top K 預設僅設為 1，檢索時僅帶入文件的首頁標題片段，正文規範條文全數被截斷
   • 解決方案：將 Top K 調升至 4～5，確保完整的章節條文與 PR 門檻要求能順利注入LLM上下文

四、 最終成果驗收
當全節點順利亮起綠燈後，顧問系統針對「評估升級 Python 最新版本」成功產出高水準的審查報告：

Dev-Advisor 審查意見摘要：

1. 內部規範相容性：Python 3.12+ 引入的泛型與 match-case 語法，在純語言層面與手冊中的「1. RESTful API 設計與路由規範」無直接衝突，可相容於後端實作

2. 合規紅線警示：

   • 禁止直接推送到主幹：環境升級與依賴庫變更必須嚴格建立獨立分支並發起 PR
   • PR 門檻（PR Gate）：必須至少獲得 1 位資深架構師的「Code Review Approved」方可合併

3. 安全與落地 SOP：需同步檢驗加密套件相容性，嚴禁使用 MD5/SHA1 等過時雜湊，維持密碼儲存的加鹽標準

總結
今天我們成功打通了Dify工作流中最具實用價值的「多源匯流」架構。透過解決快取幽靈變數、調優檢索 Top K，並釐清 503 伺服器端的尖峰特性，系統已經能具備企業級顧問的思考維度。