《筆記》Flowise Chatflow 簡化版示意圖

資料科學 自然語言處理
1

如果將 Flowise Chatflow 的圖直接截圖複製過來，字太小看不清楚。

後來用類似流程圖的方式來作示意圖，試了一個，效果不錯，就把六個範例全部套用。

線上討論時，發現講解的部分有些誤值，一併在此更新：

一、Open Router 界接各家 LLM model，compose IO 界接各式 API。

二、Open Router 界接各家 LLM model，不過 Tool Agent 也可以不透過 Open Router 界接，使用 Flowise 內建的幾個 LLM model（但選擇比 Open Router 少得多）。

三、Open Router 的收費，可預先儲值一定額度，使用它的 API Key 已涵蓋各家 LLM model 費用。也可以不用 Open Router，使用 Flowise 內建的幾個 LLM model，各自輸入該 LLM 廠商的 API Key，由各廠商分別扣款。

▌技術架構演進圖

講師一共介紹了六個 Chatflow 範例，其演進路徑大約如下（並非完全線性）。

  • 基礎層 (範例 1 & 2)：確立了 AI 讀取外部資料（RAG）的能力。範例 2 展示了橫向的部署遷移（雲端轉本地）。
  • 行動層 (範例 3 & 4)：AI 開始擁有「工具箱」。演進轉折點在於範例 4，它成功將 RAG 變成工具之一，讓 AI 決定何時該「讀書」何時該「做事」。
  • 管理層 (範例 5 & 6)：當工具與任務過於複雜，演進方向轉為「組織化」。範例 5 引入主管機制來調度團隊；範例 6 則引入審核機制確保安全。

這張演進地圖清晰地呈現了 AI 應用從「工具」轉變為「虛擬員工」，最後變成「自動化團隊」的完整旅程。

flowchart TD
    %% 第一階段：RAG 基礎
    subgraph Stage1 [階段一：RAG 知識庫問答]
        direction LR
        L1[<b>第1課：雲端 RAG</b><br/>Web 檢索問答] -->|橫向遷移| L2[<b>第2課：本地 RAG</b><br/>隱私與成本優化]
        style L1 fill:#e1f5fe,stroke:#01579b
        style L2 fill:#e1f5fe,stroke:#01579b
    end

    %% 第二階段：Agent 動能
    subgraph Stage2 [階段二：從對話到行動]
        direction LR
        L3[<b>第3課：工具代理人</b><br/>自主調用工具] -->|能力整合| L4[<b>第4課：RAG + Agent</b><br/>將知識庫化為工具]
        style L3 fill:#fff3e0,stroke:#ff6f00
        style L4 fill:#fff3e0,stroke:#ff6f00
    end

    %% 第三階段：團隊協作與管理
    subgraph Stage3 [階段三：組織化與流程管控]
        direction LR
        L5[<b>第5課：多代理人協作</b><br/>主管調度團隊]
        L6[<b>第6課：順序型與審核</b><br/>嚴謹產線與人類介入]
        style L5 fill:#f3e5f5,stroke:#7b1fa2
        style L6 fill:#f3e5f5,stroke:#7b1fa2
    end

    %% 演進流向
    Stage1 -->|從被動回答到主動執行| Stage2
    Stage2 -->|從單兵作戰到團隊協作| Stage3

    %% 演進特殊說明
    note1[演進轉折：AI 開始具備 Function Calling 能力]
    note1 -.-> L3
    
    note2[演進轉折：AI 進入組織管理與安全審核階段]
    note2 -.-> Stage3

▌1. 基本架構（雲端）

  1. Build a RAG Chatflow: Web Scraping, Embeddings, Vector Database & HTML Splitter

RAG (檢索增強生成) 基本架構。

Conversational Retrieval QA Chain

flowchart TD
    %% 節點定義
    A[HtmlToMarkdown Text Splitter]
    B[BraveSearch API Document Loader]
    C[OpenAI Embeddings]
    D[In-Memory Vector Store]
    E[ChatOpenAI]
    F[Buffer Window Memory]
    G[Conversational Retrieval QA Chain]

    %% 流向連接
    A -->|Text Splitter| B
    B -->|Document| D
    C -->|Embeddings| D
    D -->|Vector Store Retriever| G
    E -->|Chat Model| G
    F -->|Memory| G

流程節點解析

  • 數據處理層：

    • HtmlToMarkdown Text Splitter：負責將 HTML 轉換為 Markdown 並切割文字塊。
    • BraveSearch API Document Loader：根據關鍵字（預設為 Tesla）從網路上抓取資料。

  • 檢索儲存層：

    • OpenAI Embeddings：將文字轉換為向量數值。
    • In-Memory Vector Store：在記憶體中建立索引，接收來自 Loader 的文件與來自 OpenAI 的向量。

  • 核心邏輯層：

    • Conversational Retrieval QA Chain：此為最終整合點，負責結合以下三者來回答問題：
    • ChatOpenAI (模型：gpt-4o-mini)。
    • Vector Store Retriever (知識來源)。
    • Buffer Window Memory (儲存最近 20 輪的對話紀錄)。

▌2. 基本架構（本地端）

  1. Running a RAG Chatbot Locally with Ollama & LangChain (Data Security)

流程與上一個類似，最大的差別是所有的 AI 運算（模型與 Embedding）都更換成了 Ollama 本地端模型。

flowchart TD
    %% 節點定義
    A[Recursive Character Text Splitter]
    B[Folder with Files]
    C[Ollama Embeddings]
    D[In-Memory Vector Store]
    E[ChatOllama]
    F[Conversational Retrieval QA Chain]

    %% 流向連接
    A -->|Text Splitter| B
    B -->|Document| D
    C -->|Embeddings| D
    D -->|Vector Store Retriever| F
    E -->|Chat Model| F

流程節點解析

  • 數據加載與處理：

    • Recursive Character Text Splitter：將文檔遞迴地切割成較小的區塊。
    • Folder with Files：從指定的本地資料夾路徑（C:\Users\Arnold\Desktop\PDFs）讀取多個檔案。

  • 本地向量化：

    • Ollama Embeddings：使用本地運行的 nomic-embed-text 模型將文字轉為向量。
    • In-Memory Vector Store：接收來自資料夾的文件與來自 Ollama 的向量數據，暫存在記憶體中供查詢。

  • 核心對話邏輯：

    • ChatOllama：使用本地端的 llama3.2:3b-instruct-fp16 模型進行對話生成。
    • Conversational Retrieval QA Chain：最終的決策中心，負責整合本地模型（ChatOllama）與本地檢索器（Vector Store）來回答問題。

雲端／本地端比較

功能分類 網頁/雲端版 本地端版 差異說明
核心鏈接 (Chain) Conversational Retrieval QA Chain Conversational Retrieval QA Chain 邏輯框架相同，皆為具備檢索與對話能力的鏈結。
語言模型 (LLM) ChatOpenAI (gpt-4o-mini) ChatOllama (llama3.2:3b-instruct) 雲端 API vs. 本地運算。
嵌入模型 (Embeddings) OpenAI Embeddings (text-embedding-3-small) Ollama Embeddings (nomic-embed-text) 將文字轉向量的工具，分別由 OpenAI 與本地 Ollama 提供。
數據來源 (Loader) BraveSearch API (網路搜尋) Folder with Files (本地資料夾 PDF) 一個抓取即時網頁資料，一個讀取硬碟文件。
文字切割 (Splitter) HtmlToMarkdown (處理網頁格式) Recursive Character (處理一般文本) 針對不同數據源選用最適合的切割方式。
向量儲存 (Vector Store) In-Memory Vector Store In-Memory Vector Store 兩者皆將索引暫存在記憶體中。
對話記憶 (Memory) Buffer Window Memory (記住最近 20 輪) 無 (未連接) 本地版目前未配置記憶組件。

▌3. Tool Agent (工具代理人)

  1. Flowise Tool-Agent: One Workflow to Connect Any API & LLM (Openrouter & Claude)

與前兩個 RAG 流程不同，這個架構的核心在於 AgentExecutor，它可以根據使用者的需求，選擇多種工具來執行任務。

flowchart LR
    %% 核心代理人
    A[Tool Agent]

    %% 模型與記憶
    B[ChatOpenRouter]
    C[Buffer Window Memory]

    %% 工具集 (Tools)
    D1[Calculator]
    D2[BraveSearch API]
    D3[CurrentDateTime]
    D4[Write File]
    D5[Composio]
    D6[Custom Tool]

    %% 連接關係
    B -->|Tool Calling Chat Model| A
    C -->|Memory| A
    
    D1 -->|Tools| A
    D2 -->|Tools| A
    D3 -->|Tools| A
    D4 -->|Tools| A
    D5 -->|Tools| A
    D6 -->|Tools| A

1. 流程節點解析

這個工作流展示了一個功能強大的 AI 助手，具備以下特點：

  • 核心大腦 (Model)：

    • 使用 ChatOpenRouter，配置的模型是 anthropic/claude-3.7-sonnet。這是一個支援 Function Calling (函數調用) 的模型，能決定何時該使用哪種工具。

  • 記憶機制 (Memory)：

    • 使用 Buffer Window Memory，設定保留最近 20 輪的對話紀錄 (k: 20)，讓 Agent 能維持長期的對話上下文。

  • 多樣化工具箱 (Tools)：

    1. Calculator：執行數學運算。
    2. BraveSearch API：搜尋即時網路資訊。
    3. CurrentDateTime：獲取目前的日期與時間。
    4. Write File：將結果寫入本地磁碟（路徑設為：C:\Users\Arnold\Desktop\PDFs）。
    5. Composio：整合超過 250 種 App（此處串接了 Google Calendar 的創建與讀取功能）。
    6. Custom Tool：使用者自行定義的特殊工具。

2. 學習建議

本架構與 RAG 的最大差別在於，RAG 是被動檢索資料來回答問題；而 Agent 是主動判斷該用什麼工具（算數學、查行事曆、寫檔案等）來解決複雜的綜合性問題。

▌4. Retriever Tool：結合 RAG 能力的 Tool Agent

  1. Tool Agent with RAG: Pinecone, Function Calling & APIs (Postgres & Supabase)

這個 ChatFlow 展示了一個更為進階的架構：結合 RAG 能力的 Tool Agent。

本架構中，RAG 不再是整個流程的唯一中心，而是包裝成一個「Retriever Tool」，成為 Agent 工具箱中的其中一個選項。

AI 助理在需要特定知識時才去檢索文件，其餘時間則可以執行計算、寫入檔案或串接外部 App 等其他工作。

flowchart LR
    %% 核心代理人與支援組件
    A[Tool Agent]
    B[ChatOpenRouter]
    C[Buffer Window Memory]

    %% 一般工具集
    D1[Calculator]
    D2[BraveSearch API]
    D3[CurrentDateTime]
    D4[Write File]
    D5[Composio]

    %% RAG 工具鏈
    E1[Document Store Vector]
    E2[Retriever Tool]

    %% 連接關係
    B -->|Tool Calling Chat Model| A
    C -->|Memory| A
    
    D1 -->|Tools| A
    D2 -->|Tools| A
    D3 -->|Tools| A
    D4 -->|Tools| A
    D5 -->|Tools| A
    
    %% RAG 流程流向
    E1 -->|Retriever| E2
    E2 -->|Tools| A

1. 流程節點解析

這個架構實現了「大腦（Agent）+ 記憶（Memory）+ 技能（Tools）+ 知識庫（RAG）」的完全體：

  • 核心大腦與模型：

    • Tool Agent：作為決策中心，負責根據任務選擇工具。
    • ChatOpenRouter：使用 anthropic/claude-3.7-sonnet 模型，具備強大的邏輯推理與工具調用能力。

  • RAG 整合為工具：

    • Document Store (Vector)：從預先建立的向量儲存庫中進行檢索。
    • Retriever Tool：將檢索功能轉化為 Agent 可識別的工具，其描述為「用於詢問有關 Prompting 或程式碼的問題」。

  • 多功能技能組：

    • 除了檢索，Agent 還具備 Calculator (計算)、BraveSearch (即時搜索)、Write File (本地存檔) 以及 Composio (串接 Google Calendar) 等技能。

2. 學習建議

本範例最重要的地方是 Retriever Tool 節點。它將前兩堂課學到的「RAG 檢索能力」整合進了「Agent 執行架構」中。

這代表 AI 不僅能透過 RAG 獲得「知識」，還能透過其他工具產生「行動」。

▌ 5. Multi-Agent (多代理人協作)

  1. AI Agents (Multi-Agents) with Multiple LLM Experts and RAG

這個系統引入了一個 Supervisor (主管) 來調度多位具備不同專長的 Worker (員工)。

這種架構模擬了真實團隊的工作模式，能處理更大型且需要多種專業技能的專案。

flowchart TD
    %% 模型與主管
    A1[ChatOpenAI]
    A2[Supervisor]

    %% 員工與專屬工具/模型
    B1[Document Store Vector]
    B2[Retriever Tool]
    B3[Worker: Vector Database Researcher]

    C1[BraveSearch API]
    C2[Worker: Internet Research Specialist]

    D1[Write File]
    D2[ChatOpenRouter]
    D3[Worker: Blog Post Writer]

    %% 主管邏輯流
    A1 -->|Tool Calling Chat Model| A2
    A2 -->|Manage| B3
    A2 -->|Manage| C2
    A2 -->|Manage| D3

    %% 員工內部流向
    B1 -->|Retriever| B2
    B2 -->|Tools| B3

    C1 -->|Tools| C2

    D1 -->|Tools| D3
    D2 -->|Tool Calling Chat Model| D3

1. 流程節點（與團隊職掌）解析

  • 團隊主管 (Supervisor)：

    • 使用 ChatOpenAI (模型：o3-mini) 作為大腦。
    • 負責根據使用者需求分配任務，並決定由哪位員工接著執行。

  • 成員一：Vector Database Researcher (資料研究員)：

    • 專精於檢索內部知識庫（如 Prompt Engineering 相關資料）。
    • 配備 Retriever Tool 與 Document Store (Vector)。

  • 成員二：Internet Research Specialist (網路研究專員)：

    • 負責搜尋網路上的最新資訊、新聞與專家意見。
    • 配備 BraveSearch API。

  • 成員三：Blog Post Writer (部落格作家)：

    • 將研究員與專員提供的數據整合，撰寫成結構化的文章。
    • 配備 Write File 存檔工具，且為了處理複雜寫作，額外配備了 ChatOpenRouter (模型：claude-3.7-sonnet) 作為其專用的寫作大腦。

2. 學習建議

從「單打獨鬥的 AI」進化到「經營一個 AI 團隊」。

  • 重點在於權限分配：每個 Worker 只能使用主管分配給他們的工具，這能避免 AI 在處理大量工具時產生混亂。
  • 主管提示詞：在 Supervisor 的 Prompt 中，明確規定了工作順序：先研究內部資料 → 再查網路 → 最後寫作。

▌6. Sequential Agents (順序型代理人)

  1. Sequential Agents with Human‑in‑the‑Loop and self-improving Agentic RAG

這個架構中，代理人之間的協作是線性的。

關鍵設計在於 「分析師 (Analyst)」節點 開啟了 Require Approval 功能：

當 AI 想要調用工具（例如查詢 Apple 財務報表）時，必須先詢問使用者並獲得授權（ Human in the Loop 人類介入 ），才能繼續執行，以確保重要決策的安全性與準確性。

flowchart TD
    %% 全局配置
    subgraph Configuration
        M[ChatOpenAI]
        ST[State]
        MEM[Agent Memory]
    end

    %% 數據準備層
    subgraph Data_Ingestion
        TS[Recursive Character Text Splitter]
        PDF[Pdf File]
        EMB[OpenAI Embeddings]
        VS[In-Memory Vector Store]
        RT[Retriever Tool]
    end

    %% 順序執行代理人層
    subgraph Sequential_Workflow
        START[Start Node]
        A1[Agent: Analyst<br/>'Require Approval']
        A2[Agent: Researcher]
        END[End Node]
    end

    %% 外部工具
    B_SEA[BraveSearch API]

    %% 配置連接
    M --> START
    ST --> START
    MEM --> START

    %% 數據與工具連接
    TS --> PDF
    PDF --> VS
    EMB --> VS
    VS --> RT
    RT --> A1
    B_SEA --> A2

    %% 順序流向
    START --> A1
    A1 --> A2
    A2 --> END

上述圖中的 Sequential_Workflow，下圖將 Agent: Analyst ‘Require Approval’ 內部的 Human-in-the-Loop (人類介入) 細節列出。

flowchart TD
    %% 節點定義
    START[Start Node]
    RT[Retriever Tool: search_apple]
    
    subgraph Agent_Analyst [Analyst Agent 節點內部]
        A[AI 邏輯判斷: 需要查資料]
        HITL{{"⚠️ 人類審核按鈕 (Yes/No)"}}
    end

    A2[Researcher Agent]
    END[End Node]

    %% 流程流向
    START --> A
    A -->|觸發 Require Approval| HITL
    HITL -->|使用者點擊 Yes| RT
    RT -->|回傳資料| A2
    A2 --> END

    %% 樣式突出 HITL
    style HITL fill:#fff4dd,stroke:#d4a017,stroke-width:2px

本工作流是典型的財務研究流水線，並具備審核機制：

  • 基礎設施 (Configuration)：

    • 使用 ChatOpenAI (gpt-4o-mini) 作為核心模型。
    • 透過 State 管理全局變數，並由 Agent Memory (SQLite) 記錄對話狀態與檢查點。

  • 財務知識庫 (Data Ingestion)：

    • 將 Pdf File 經過切割與向量化後存入 Vector Store。
    • 封裝成名為 search_apple 的 Retriever Tool，專門提供 Apple 公司的文件查詢。

  • 關鍵機制：人類介入 (Human in the Loop)：

    • Analyst (分析師)：第一位員工，負責初步分析。其 Require Approval 設為 true。
    • 運作邏輯：當分析師需要使用 search_apple 工具時，流程會暫停並跳出「Yes/No」按鈕詢問使用者。使用者批准後，AI 才會讀取 PDF 內容。

  • 後續研究與輸出：

    • Researcher (研究員)：第二位員工，在分析師之後執行。
    • 配備 BraveSearch API 進行即時資訊補充，最後將結果彙整至 End 節點結束對話。

▌補充：應用情境

講師示範了一些常用的模組，那我們如何判斷在什麼時候使用哪種 Chatflow？

以下嘗試根據不同的業務需求、技術限制與應用場景，挑選最合適的設計模式。

檔案編號 架構名稱 核心能力 適合場景
1 雲端 RAG 基礎問答、網路搜尋 一般知識查詢、即時網頁資料擷取
2 本地 RAG 文件隱私、完全免費 處理私密 PDF 文件、低成本本地運行
3 工具代理人 自動執行、多功能工具箱 需要算數學、查時間或寫入本地檔案
4 RAG + Agent 知識檢索 + 動作執行 複雜任務處理，且需要參考特定知識庫
5 多代理人協作 團隊專業分工、主管調度 大規模專案，需要研究、寫作多環節配合
6 順序型與人類介入 嚴謹流程、人類審核機制 金融分析、高風險決策，需人類核准工具調用

▌其他

》Key Principles of Prompt Engineering 文件

》輔助 撰寫 System prompt 的網址

》優化 Retriever Tool 的「描述文字」

在 Flowise 的架構中，Agent 是透過閱讀工具的描述來決定是否調用該工具，而非直接讀取工具內部的內容。

針對 Retriever Tool 的「描述文字 (Description)」進行優化，是提升 Agent 判斷精準度的關鍵。

在 Multi-Agent 或 Sequential Agents 架構中，主管 (Supervisor) 或 Start 節點是根據這些描述文字來分派任務的。如果描述太模糊，主管可能會把問題丟給錯誤的 Worker，導致整個工作流失敗。

例如 Human-in-the-loop ，精準的描述能確保 Agent 只有在「真正需要」時才會觸發審核請求，避免頻繁打擾使用者。

以下是撰寫建議：

1. 明確界定知識範圍 (Boundary Setting)

不要只寫「這是一個關於公司的工具」，而要精確定義內容範圍。

  • 優化前：Use this tool to search about Apple.
  • 優化後：Use this tool ONLY when answering questions about Apple Inc (AAPL) financial reports, stock performance, or historical business data. Do not use for general technology news.

2. 加入觸發關鍵字 (Keyword Triggering)

引導 Agent 識別特定類型的問題。

  • 優化前：use this tool to search info about diffusion and llm prompting.
  • 優化後：Essential tool for queries containing keywords like 'stable diffusion', 'midjourney', 'negative prompt', or 'LLM context window'. Use this to retrieve technical methodologies for prompting.

3. 設定使用場景與限制 (Conditional Logic)

告訴 Agent 何時「不該」使用這個工具，這能有效節省 Token 並避免 AI 產生幻覺。

  • 範例描述：Use this tool to retrieve internal coding standards. If the user asks about general Python syntax, rely on your internal knowledge instead of this tool.

4. 指令化描述 (Instructional Phrasing)

使用動詞開頭，強化 Agent 的執行動機。

  • 範例描述：Consult this knowledge base to verify exact specifications of our products before confirming any technical details to the user.

以範例 6 的 Retriever Tool 為例：

原本的描述是：

Search and return documents about Apple Inc (APPL)

如果我們想讓「分析師 (Analyst)」更精準地判斷，可以優化為：

Required tool for deep-dive financial analysis of Apple Inc. Use this when the user requests specific data from annual reports, balance sheets, or 10-K filings. This tool provides official documentation that must be reviewed before providing a final financial opinion.

Required tool for deep-dive financial analysis of Apple Inc. (1) Use this when the user requests specific data from annual reports, balance sheets, or 10-K filings. (2) This tool provides official documentation (3) that must be reviewed before providing a final financial opinion. (4)

  1. 明確界定知識範圍 (Boundary Setting)
  2. 加入觸發關鍵字 (Keyword Triggering)
  3. 設定使用場景與限制 (Conditional Logic)
  4. 指令化描述 (Instructional Phrasing)