n8n 進階實戰：用 Gemini 與 RAG 打造兩款企業級 AI 智慧助理

一、 前言：當 n8n 遇上 AI Agent

本文主旨將超越傳統的自動化流程，展示如何利用 n8n 作為靈活的後端，串接大型語言模型 (LLM) 與外部資料源，打造出兩款真正具備「思考」與「查詢」能力的 AI 智慧助理。

• 目標讀者：本文為熟悉 n8n 基本操作，並希望將其應用在 AI 領域的開發者與技術愛好者而設計。
• 成果預覽：我們將完成兩個專案：
  1. 自然語言資料庫助理：能將中文對話轉為 SQL 查詢。
  2. RAG 企業知識庫：能根據私有文件，提供精準回答的專家。

在深入探討技術細節之前，為了讓讀者能親手實作，本文中提到的兩個 AI 助理工作流，都已匯出成 JSON 檔案，可直接匯入您的 n8n 環境中使用。

• 智慧資料庫分析師 (Text-to-SQL) 工作流

  • 點此下載 Dual-AI-Agent-Workflow.json
  • 說明：此工作流包含將自然語言轉換為 SQL，並根據查詢結果生成分析報告的完整流程。

• 企業級 RAG 知識庫問答機器人工作流

  • 點此下載 Agent-RAG-Chatbot-Workflow.json
  • 說明：此工作流整合了 Agent、對話記憶與向量資料庫檢索，用於打造一個能回答專業領域問題的知識庫助理。

溫馨提醒：先確保n8n版本為v1.99.1以上，Node.js版本為v22(LTS)。匯入工作流後，請務必將其中的 Language Model API 金鑰、資料庫憑證、向量資料庫端點與 API Key 等節點，替換為您自己的資訊，才能順利運行。

二、 準備工作：打造 AI Agent 的軍火庫

在開始之前，請確保您已準備好以下環境與憑證：

• n8n 環境：一個運作中的 n8n 實例 (雲端版或自架設皆可)。
• 核心服務憑證 (Credentials)：
  • Google Gemini API Key：前往 Google AI Studio 取得並在 n8n 中設定。
  • Pinecone API Key：前往 Pinecone 官網註冊並取得 API 金鑰。
  • 資料庫連線資訊：準備一個用於測試的 SQL 資料庫 (本文以MSSQL Server為例) 的連線資訊。

三、 實作一：智慧資料庫分析師 (Text-to-RAG)

專案目標

讓任何人都能用口語中文從資料庫撈取資料，並直接獲得 AI 自動生成的摘要與結論，實現從「對話即查詢」到「對話即分析」的飛躍。

核心工作流程 (Workflow) 拆解

根據流程圖，這個強大的分析師是由兩個 AI Agent 協作完成的：

1. 指令接收 (When chat message received): 流程的起點，透過 Webhook 或聊天軟體接收使用者的自然語言提問。

    

2. AI Agent - 資料庫助理 (Gemini-生成SQL): 第一位 AI 助理登場。它接收到問題後，呼叫 Gemini 模型，將人類的語言轉換為精準的 SQL 查詢語句。
   

   • 關鍵 Prompt 1 (生成SQL)：
     

     你是一個專業的 MS SQL 資料庫助理。你的任務是嚴格按照範例，根據使用者的問題，生成一段精確且安全的 SQL 查詢語法。你的回答必須只有 SQL 語法，絕對不能包含任何其他文字。
     
     # 資料庫結構 (Schema)
     -- 看板列表 (boards)
     CREATE TABLE [dbo].[boards] ( [id] int NOT NULL, [name] nvarchar(255) NOT NULL );
     -- 文章列表 (posts)
     CREATE TABLE [dbo].[posts] ( [internal_id] int, [post_id] int, [board_id] int, [title] nvarchar(max), [author] nvarchar(255), [post_time] datetime2(7), [content] nvarchar(max), [url] nvarchar(max) );
     -- 回覆列表 (replies)
     CREATE TABLE [dbo].[replies] ( [id] int, [post_id] int, [author] nvarchar(255), [content] nvarchar(max), [post_time] datetime2(7) );
     -- **關聯提示**: replies.post_id 指向 posts.post_id
     
     # 可用看板資訊 (Available Boards)
     -- 你可以從以下看板中查詢資料：
     -- id: 1, name: 'Agentflow 發問區'
     -- id: 2, name: '技術分享'
     -- id: 3, name: '閒聊'
     
     # 查詢範例 (Examples)
     -- 使用者問題: 如何隱藏 table 欄位
     -- 你的回答:
     SELECT TOP 5 p.title, p.author, p.url, p.content, (SELECT r.author, r.content, r.post_time FROM dbo.replies r WHERE r.post_id = p.post_id ORDER BY r.post_time ASC FOR JSON PATH) AS replies FROM dbo.posts p WHERE (p.title LIKE N'%隱藏%' AND p.title LIKE N'%table%' AND p.title LIKE N'%欄位%') OR (p.content LIKE N'%隱藏%' AND p.content LIKE N'%table%' AND p.content LIKE N'%欄位%') ORDER BY CASE WHEN (p.title LIKE N'%隱藏%' AND p.title LIKE N'%table%' AND p.title LIKE N'%欄位%') THEN 1 ELSE 2 END, p.post_time DESC;
     
     # 嚴格規則 (Strict Rules)
     1.  **輸出格式 (極度重要)**：你的回答**只能也必須是純文字的 SQL 語法**。你的輸出將被直接傳給資料庫執行，任何多餘的字元，尤其是 ``` 或註解，都會導致整個系統錯誤。在輸出前請再三確認，你的回答中不包含任何非 SQL 的字元。
     2.  **整合回覆為 JSON 陣列 (極重要)**：當搜尋文章時，你必須使用子查詢 (subquery) 搭配 `FOR JSON PATH` 來抓取所有相關回覆，並將其格式化為一個 JSON 字串陣列。
         *   這個子查詢應該 SELECT `author`, `content`, `post_time` from `dbo.replies`。
         *   將這個子查詢的結果命名為 `replies`。
         *   這樣生成的 `replies` 欄位會是一個 JSON 格式的字串，例如 `[{"author":"user1","content":"reply1"},{"author":"user2","content":"reply2"}]`，n8n 可以輕易地將其解析為真正的陣列。
         *   **絕對不要再使用 `STRING_AGG` 或 `GROUP BY`**。
     3.  **搜尋精準度**：當使用者提出多關鍵字問題時，必須將其拆解成核心關鍵字，並使用多個 `AND` 連接的 `LIKE` 語句來確保所有關鍵字都被匹配。
     4.  **結果排序**：**必須優先顯示標題 (`title`) 包含所有關鍵字的文章**。使用 `ORDER BY CASE WHEN ... THEN 1 ELSE 2 END` 的語法來實現。
     5.  **回傳欄位**：搜尋結果中，必須包含 `title`, `author`, `url`, `content` (主文內容), 和 `replies` (JSON 格式的回覆串)。
     
     # 使用者問題:
     {{ $json.chatInput }}

     備註：這裡的 "{{ $json.chatInput }}" 是源自於Chat輸入參數，該Prompt最後還是要讓LLM知道使用者原始提問內容，避免回答太發散。
     
     

3. SQL 清理 (Code Node): AI 生成的 SQL 可能會包含 markdown 語法 (如 sql ... ) 或其他贅述。此節點使用一小段程式碼來清理字串，確保只有純淨的 SQL 語句進入下一步。
   
   

4. 執行查詢 (Execute Query): 將清理後的 SQL 語句傳遞給資料庫節點，實際執行查詢並從資料庫中獲取原始資料。
   
   

5. 資料解析 (Code Node): (可選，但建議) 資料庫回傳的通常是 JSON 格式的陣列。此節點可負責解析這些資料，並將其整理成適合下一個 AI 閱讀的格式。
   
   

6. AI Agent - 結論分析師 (Gemini-生成結論): 第二位 AI 助理上場。它接收到從資料庫撈取的結構化資料 (JSON)，並再次呼叫 Gemini，但這次的任務是分析這些資料並生成一段通順、易於理解的文字結論。

   • 關鍵 Prompt 2 (生成結論)：
     

     你是一位專業、友善的技術支援分析師。你的任務是根據我提供的 JSON 格式的搜尋結果，為使用者寫一份清晰、簡潔、有條理的摘要結論。
     
     # 任務目標
     1.  **直接回答**：首先，嘗試根據資料，直接回答使用者的原始問題。
     2.  **總結關鍵資訊**：從最相關的文章標題、內容以及回覆中，提煉出最重要的資訊或解決方案。
     3.  **引用來源**：在結論的最後，附上最相關的一篇文章的標題和 URL，方便使用者深入閱讀。
     4.  **友善提示**：如果找不到資料，就禮貌地告訴使用者目前找不到相關資訊。
     
     # 範例
     -- 使用者原始問題: "匯入EXCEL 元件有筆數問題"
     -- 我提供的 JSON 資料:
     [{"title":"匯入EXCEL 元件 筆數ISSUE","author":"P0126_mis","url":"https://forum.flowring.com/post/view?bid=34&id=43518","content":"想請問 匯入元件 跟資料筆數 及XLS ,XLSX 檔案有相關嗎...我資料筆數一大...後台就會跳出ERROR","replies":[{"author":"chen.yiwei","content":"可能是資料比數過大導致連線超時..."},{"author":"jimmy.liu","content":"可以參考此篇文章，確認執行時間是否有超過connectionTimeOut設置..."}]}]
     
     -- 你生成的摘要結論:
     關於「匯入 Excel 筆數過多」的問題，根據搜尋結果，這很可能是因為資料量太大，導致連線或執行超時。
     
     **關鍵摘要：**
     *   **問題原因**：有使用者回報，當匯入的資料筆數過大時，後台會出現錯誤，這通常與連線超時 (Timeout) 有關。
     *   **解決方向**：建議檢查伺服器的 `connectionTimeOut` 相關設定，可以參考相關的論壇文章來調整設定值。
     
     如果您想查看完整的討論串，可以參考這篇文章：
     **標題**：匯入EXCEL 元件 筆數ISSUE
     **連結**：https://forum.flowring.com/post/view?bid=34&id=43518
     
     ---
     # 嚴格規則
     *   你的回答必須使用繁體中文。
     *   語氣必須專業、友善且樂於助人。
     *   結論必須精簡，不要超過 200 字。
     
     # 使用者原始問題:
     {{ $('When chat message received').item.json.chatInput }}
     
     # JSON 搜尋結果:
     {{ JSON.stringify($input.all()) }}

      

7. 最終回覆: 將「結論分析師」生成的文字摘要作為最終結果，回傳給使用者，而不是冷冰冰的數據。

成果展示

下方是這個雙 AI 協作流程的示意圖。這種架構讓使用者體驗大幅提升，因為他們得到的不僅是資料，更是有洞見的分析。

四、 實作二：企業級 RAG 知識庫問答機器人 (Agent-based RAG)

專案目標

打造一個具備對話記憶、能理解上下文的專家問答系統。它能基於私有文件（如產品手冊、內部SOP）進行問答，不僅解決 LLM 的「幻覺」問題，更能實現流暢的多輪對話。

核心工作流程 (Workflow) 拆解

從流程圖中我們可以看到，這個實作採用了更先進的 AI Agent 架構，將所有能力整合在一個核心節點中，而非線性的步驟串連。

1. 指令接收 (When chat message received): 流程的起點，接收使用者的提問。
   
   
2. 核心大腦 (AI Agent-技術分析師): 這是整個工作流程的核心。它不是一個簡單的執行者，而是一個被賦予了模型、記憶和工具的「決策者」。
   • 思考模型 (Chat Model: Gemini-分析使用者問題): Agent 使用 Gemini 模型來理解使用者問題、決定是否使用工具，並根據工具回傳的資料生成最終的自然語言答案。
   • 對話記憶 (Memory: 內置記憶體-儲存當前 Chat Session): 這是實現多輪對話的關鍵。Agent 會記住當前的交談歷史，讓使用者可以提出「那第二點呢？」或「詳細說明一下」之類的追問，Agent 也能理解其意。
   • 知識工具 (Tool: Pinecone Vector Store-RAG): 這是 Agent 最重要的外部工具。當 Agent 判斷自身知識不足以回答問題時，它會主動調用此工具。
     • 工具內部運作: Pinecone 工具在被調用時，會自動使用 Gemini Embeddings-向量模型 將使用者的問題轉換為向量，然後到 Pinecone 向量資料庫中檢索最相關的知識片段，最後將這些片段回傳給 AI Agent。
       
       
3. 最終回覆: AI Agent 在拿到 RAG 工具回傳的資料後，會結合對話歷史，由 Gemini 模型生成最終的、有憑有據且符合上下文的答案，回傳給使用者。
   • 關鍵 Prompt 展示：這是指導 Gemini 如何根據上下文進行回答的核心。
     

     You are a helpful 你是一個專業、嚴謹的 Agentflow 技術支援分析師。
     你被賦予了一個強大的工具，可以讓你存取一個包含「主文章」和「回覆」的技術知識庫。
     
     # 你的思考與任務流程：
     1.  **分析問題**：當收到「使用者的問題」時，仔細分析其意圖。
     
     2.  **使用工具 (核心規則)**：
         *   對於**任何**關於 Agentflow 的技術問題、功能詢問、元件用法 (例如 Table 元件)、設定方式或錯誤排解，你都**必須**使用你被賦予的工具來檢索資料。
         *   只有當問題是閒聊 (例如「你好」、「你是誰」) 或與 Agentflow 技術完全無關時，才可不使用工具。
     
     3.  **理解資料**：工具會返回一個 JSON 陣列，其中每個物件代表一篇「主文章」或一則「回覆」。你需要理解它們的結構：
         *   `id`: 文件的唯一識別碼 (主文章ID如 "32190", 回覆ID如 "32190_001")。
         *   `content`: 文件內容。
         *   `url`: 原始網址。
         *   `metadata.reply_ids`: 主文章可能包含的所有回覆ID列表。
     
     4.  **生成回答**：
         *   你的回答**必須**完全基於工具檢索到的資料。**絕對禁止**使用外部知識或自行創造答案。
         *   **以「主文章」為主要上下文來組織你的回答**。如果答案在回覆中，請說明是哪篇文章下的回覆。
         *   使用**繁體中文**、**條列式**、**精簡專業**的風格。
     
     5.  **引用來源 (非常重要)**：
         *   在回答中**必須**清楚標示資訊來源，格式為：`(來源: [文件ID], [URL])`。
     
     6.  **處理失敗**：
         *   如果工具沒有找到相關資料，或資料與問題無關，你**必須**回答：「根據我目前的知識庫，我找不到關於您問題的具體資訊。」
     
     ---
     [使用者的問題]
     {{ $json.chatInput }}

     備註：這裡的 "{{ $json.chatInput }}" 是源自於Chat輸入參數，該Prompt最後還是要讓LLM知道使用者原始提問內容，避免回答太發散。
     
     

4. 回傳答案 (Webhook Response)：將精準、客製化的答案回傳。

成果展示

下方是 RAG 流程的示意圖，這種 Agent 架構讓 RAG 系統從一個「問答機」進化為一個可以對話的「專家助理」，極大地提升了互動的實用性與流暢度。

五、 【實戰對決】AI 助理能力邊界與場景分析

在本章節，我們將透過一系列的實際問題，對前面建立的兩個 AI 助理進行壓力測試。目標是直觀地展示它們在不同場景下的能力優劣，幫助讀者在未來選擇正確的技術方案。

場景一：結構化資料查詢

分析說明：
這個場景最能體現兩種 AI 助理在「資料來源」與「處理邏輯」上的根本不同。表面上兩者都成功回答，但細節卻揭示了截然不同的運作模式。

• 智慧資料庫分析師的回答分析： 它的回答精準、直接，且附加了有價值的「關鍵摘要」。它完美執行了「搜尋並列出最新的 5 篇文章」這個指令。然而，它回報的總數（5篇）很可能只是其搜尋工具一次性返回的結果數量上限，而非資料庫中的總數。它像一個精準的指令執行者，忠實地完成「給我看最新的 5 筆資料」這個任務，並對這 5 筆資料進行了深入分析。

• RAG 知識庫助理的回答分析： 它的回答在「總數」上更具宏觀視野和準確性（回報了 19 篇）。這得益於它對整個知識庫的全面索引。然而，它列出的「最新 5 篇」標題與分析師不同，這可能是因為它的排序依據或對「相關性」的定義是基於語意而非單純的關鍵字。它像一個博學的圖書管理員，知道館藏的總量，並能根據對問題的理解推薦相關書籍，但不保證推薦的順-序與資料庫的原始排序完全一致。

結論與啟示：
這次對決沒有絕對的贏家，而是展現了兩者的互補性：

• 若使用者需要對即時、精確的數據進行操作（例如：列出最新的 5 筆訂單），智慧資料庫分析師的「所見即所得」更為可靠。
• 若使用者需要對整個知識體系有全面的了解（例如：到底有多少相關文件），RAG 知識庫助理的「宏觀視角」則更勝一籌。

這個案例證明，即使在結構化查詢的場景中，RAG 助理也能提供有價值的補充資訊（如準確的總數），突顯了未來融合兩種架構的潛力。

場景二：非結構化知識問答

分析說明：
在這個場景中，企業級 RAG 知識庫問答機器人 的回答品質明顯勝出，完美體現了其架構優勢。

• 智慧資料庫分析師的回答分析： 它的回答雖然正確，但本質上只是對單一搜尋結果的摘要。它成功找到了相關性最高的論壇文章並提煉了重點，但這也成為了它的限制。它給出的答案是片面的，缺乏了更宏觀的視角，例如完全沒提到無需寫程式的「基本操作」以及潛在的「版本衝突」風險。它像一個「高效率的搜尋引擎」，能快速找到並摘要單點資訊。

• RAG 知識庫助理的回答分析： 它的成功在於其「檢索-綜合-生成」的核心能力。它並非只找一篇文章，而是從知識庫中檢索出所有相關的知識片段（來自不同文章的「基本操作」、「進階腳本」、「POI 套件」、「版本衝突警告」），再由大型語言模型將這些碎片化的資訊融會貫通，重新組織成一個有條理、有深度、且完整的教學。它不僅回答了「怎麼做」，還補充了「為什麼」和「要注意什麼」。

結論與啟示： RAG 知識庫助理 更像一位「領域專家」，能夠博覽群書，提供全面、結構化且包含重要細節的深度解答。在需要完整、可靠的知識傳遞時，RAG 架構是更理想的選擇，能提供遠超單純關鍵字搜尋的價值。

場景三：複合型問題 (挑戰極限)

分析說明：
這個複合型問題完美地展示了 RAG 知識庫助理 在處理「知識密集型任務」時的絕對優勢。使用者的問題不僅僅是「查詢」，而是包含了「查找」、「比較」與「總結」等多個認知步驟。

• 智慧資料庫分析師的失敗原因： 它的工作流是線性的「指令 -> SQL -> 數據 -> 分析」。它無法將「比較優缺點」這種抽象請求轉換為 SQL 查詢，導致工作流程在第一步就已失敗，因此沒有任何回應。這個 Agent 擅長處理結構化數據，但面對需要理解與推理非結構化文本的任務時，便無能為力。

• RAG 知識庫助理的成功之處： 它的核心是「檢索 + 生成」。它能理解問題的意圖，從向量資料庫中檢索出所有相關的知識片段（SQL 方法、API 方法、優缺點等），然後利用大型語言模型強大的綜合分析與推理能力，將這些碎片化的資訊整合成一篇結構完整、邏輯清晰的比較報告，並給出最終建議。

結論與啟示： 當任務超越了簡單的數據撈取，進入到需要對非結構化知識進行理解、比較、分析和總結的領域時，Agent-based RAG 架構是明顯更優越的選擇。它真正實現了從「數據查詢」到「知識助理」的躍升。

六、結論

經過上述的詳細實作與三場實戰對決，我們清楚地看到，「智慧資料庫分析師」與「企業級 RAG 知識庫」並非相互取代的關係，而是針對不同企業需求的最佳解。它們各自在擅長的領域中大放異彩，也突顯了其內在的架構限制。

以下是兩位 AI 助理的最終能力比較總表：

選擇指南

• 何時選擇「智慧資料庫分析師(Text-to-SQL)」？
  當您的核心任務是與結構化資料庫進行高頻互動，需要即時、精確的統計數字與數據摘要時。它就像一位不知疲倦的數據分析師，永遠忠實地執行您的查詢指令。

• 何時選擇「企業級 RAG 知識庫(Text-to-RAG)」？
  當您的核心任務是從大量非結構化文件（如 SOP、報告、手冊、法規）中尋找、理解、比較並總結知識時。它就像一位博學的領域專家，能為複雜問題提供全面且有條理的深度解答。

未來展望

本文展示的兩個 AI 助理是強大的概念驗證，而它們的潛力遠不止於此。以下是幾個具體的未來發展方向，能讓這套系統更貼近企業實際應用場景：

1. 整合前端交談介面 (如 LobeChat)
   目前我們是透過 n8n 的 Webhook 進行測試，但為了提供更友善的使用者體驗，下一步可以整合如 LobeChat 這類的開源聊天視窗套件。透過 LobeChat 的 Plugin 系統與 n8n 對接，即可打造出一個具備完整 UI、支援串流對話與歷史紀錄的企業級 AI 應用前端。

2. 自建地端 RAG 向量資料庫
   雖然 Pinecone 功能強大，但在資料量不大或有嚴格資安考量的場景下，採用線上付費服務可能成本較高。未來可以考慮使用如 ChromaDB 或 FAISS 等開源函式庫，在企業內部自建向量資料庫。這不僅能大幅降低建置成本，更能確保所有敏感知識都保留在企業內部，實現真正的資料私-有化。

3. 擴大知識庫的廣度與深度
   現階段的知識庫僅包含從論壇爬取的資料。為了讓 RAG 助理成為更權威的專家，下一步應將官方的 AgentFlow 技術手冊、API 文件、產品白皮書等結構化與非結構化文件一併納入。透過更全面的知識來源，將能顯著提升問答的準確性與工具的使用靈活度，使其能應對更複雜、更專業的技術問題。

透過這些改進，我們能將這套 n8n AI 系統從一個後端流程引擎，進化為一個完整、安全且高度客製化的企業級智慧解決方案。