N8N x AI Agent 完全指南：串 Claude / OpenAI 的架構選擇與實戰心法

2024 年底開始，有一件事悄悄改變了很多非工程師用 N8N 的方式：他們不再只是「串 API」，而是開始讓 AI 在流程裡做決策。

這個轉變聽起來很酷，但實際操作的時候，大多數人遇到的第一道牆是：「我知道要串 OpenAI，但不知道要串在哪裡、怎麼給它任務、它怎麼告訴我結果。」

這篇文章就是要幫你把這道牆推倒。

我們會從架構選擇開始，一路講到 Claude 和 OpenAI 的節點設定差異、什麼時候用哪個、RAG 流程怎麼搭、Tool Use 怎麼讓 AI 主動去抓資料，最後給你一個可以直接套用的思路框架。

先搞清楚：什麼叫「AI Agent」

在 N8N 的語境裡，AI Agent 不是科幻小說裡的機器人，它是一個「會根據情況自己決定下一步的流程節點」。

普通的自動化流程是線性的：A 發生 → B 處理 → C 輸出。每個步驟都是預先定義好的。

AI Agent 流程是有分支判斷的：A 發生 → AI 看一下 A 的內容 → 決定要做 B1 還是 B2 還是 B3 → 執行對應的後續流程。

這個「AI 看一下內容、決定走哪條路」的能力，就是讓 N8N 流程從「機械式執行」變成「有邏輯的助手」的關鍵。

具體的場景舉例：

一封客服信件進來，AI 先讀一下這封信，判斷它屬於「退款申請」還是「使用問題」還是「合作詢問」，然後分別走三條不同的後續流程。退款申請自動轉進 CRM 建 ticket、使用問題自動查 FAQ 然後回覆、合作詢問轉給業務信箱並且抄送主管。

這整個過程不需要你手動分類，AI 幫你做了。

N8N 的 AI 節點生態：你有哪些工具

N8N 在 AI 支援這塊，目前主要有三類節點：

AI 語言模型節點

這是最基本的一層。你把文字丟進去，AI 回你一段文字。

N8N 原生支援的模型包括 OpenAI（GPT-4o、GPT-4 系列）、Anthropic（Claude 3.5 Sonnet、Claude 3 Opus）、Google（Gemini 系列）、還有 Ollama（本地模型）。詳細的節點文件可參考 N8N 官方文件。

每個模型節點的基本設定都差不多：給它一個 System Prompt（告訴它扮演什麼角色）、給它 User Message（告訴它這次的任務）、拿回它的回覆。

AI Agent 節點

這是更高一層的包裝。N8N 有一個專門的「AI Agent」節點，它讓你不只是「問 AI 一個問題」，而是讓 AI 去「完成一個任務」。

差別在哪？AI Agent 節點可以讓 AI 主動去呼叫「工具」（Tools）。你可以把「搜尋資料庫」「查天氣」「發送 Slack 訊息」這些操作包裝成工具，然後讓 AI 自己判斷什麼時候需要呼叫哪個工具。

這就是 Tool Use 的概念。

Memory 節點

對話記憶。讓 AI 記得這個使用者之前說過什麼，這樣它才能做到真正的「連續對話」，而不是每次都從頭開始。

N8N 目前支援 Simple Memory（存在 workflow 執行期間的暫時記憶）和 Window Buffer Memory（記住最近 N 輪對話），對接外部資料庫（如 Redis、Postgres）做永久記憶也是可以的。

Claude vs OpenAI：用 N8N 串的時候差在哪

很多人的第一個問題是：「我該用 Claude 還是 GPT？」

這個問題沒有標準答案，但有幾個判斷維度可以給你參考。

指令遵循精確度

如果你的流程對輸出格式要求很嚴格，比如「一定要回傳 JSON，而且欄位名稱必須是 xxx」，Claude 3.5 Sonnet 在這方面的表現通常比較穩定。它更「聽話」，比較不會自作主張在 JSON 外面加一段說明文字。

OpenAI 的 GPT-4o 同樣很好，但偶爾會在格式嚴格的場景下多加一些它認為「有幫助」但你不需要的內容。

長文本處理

Claude 目前支援 200K token 的 context window。如果你的任務是「讀一份很長的文件然後摘要」或「對照一大堆資料找出異常」，Claude 在這方面的優勢很明顯。

GPT-4o 的 context window 是 128K，大多數場景夠用，但遇到超長文件就會吃到限制。

速度與成本

GPT-4o-mini 是目前性價比最高的選項之一。如果你的任務不需要超強的推理能力，比如只是做個分類、改個格式、翻譯一段文字，GPT-4o-mini 速度快、便宜，很適合高頻觸發的流程。

Claude Haiku 同樣便宜且快，但在結構化輸出的穩定性上通常比 GPT-4o-mini 更可靠。

N8N 節點設定方式

在 N8N 裡串 OpenAI，走的是「OpenAI Chat Model」節點，設定 API Key 後可以在 Model 欄位選你要用的模型。

串 Claude，走的是「Anthropic Chat Model」節點，同樣設定 API Key，然後選模型。

這兩個節點的用法幾乎一樣，主要差異是：

OpenAI 節點支援 Function Calling（即 Tool Use），Claude 節點在 N8N 的 AI Agent 模式下也支援 Tool Use，但配置方式有細微差別。OpenAI 的 Tool 定義是 JSON Schema 格式，Claude 的也是，但 Anthropic 在處理多工具並行呼叫時的行為稍有不同，設計流程時要注意。

建議策略：先用 OpenAI 把流程邏輯跑通，因為社群資料多、debug 比較容易；流程穩定後再評估是否換 Claude，特別是在需要更精確格式控制或處理長文本的場景。

AI Agent 的四種常見架構

了解了工具之後，我們來看實際的架構設計。在 N8N 裡搭 AI Agent，主要有四種常見的架構模式。

架構一：單一 LLM 節點（最簡單）

流程：Trigger → LLM 節點 → 輸出

這是最基本的架構。你給 AI 一個任務，它回你一個結果，然後你用這個結果做後續動作。

適合場景：內容生成、文字轉換、簡單分類、翻譯。

限制：AI 無法主動抓資料，只能用你傳進來的資訊做事。

架構二：LLM + 路由（分類後分流）

流程：Trigger → LLM 分類 → Switch 節點 → 各分支流程

先讓 AI 判斷輸入屬於哪個類別，然後用 N8N 的 Switch 節點根據分類結果走不同的後續流程。

適合場景：客服分流、訂單類型判斷、內容標籤分類、多語言路由。

這個架構的關鍵在於 LLM 節點的 Prompt 設計：你要讓它輸出一個固定的分類值（比如「退款」「使用問題」「合作詢問」），而不是一段說明文字。這樣 Switch 節點才能正確識別。

建議的 Prompt 結構：「你是一個客服分類助手。根據以下信件內容，回覆一個詞：退款、使用問題、合作詢問。不要回覆其他內容。信件內容：{{ $json.email }}」

架構三：AI Agent + Tools（完整 Agent）

流程：Trigger → AI Agent 節點（綁定多個 Tools）→ 輸出

這是最強大也最複雜的架構。AI Agent 節點會根據任務需求，自動決定要不要呼叫哪個 Tool，呼叫幾次，然後整合結果給你。

適合場景：需要查詢外部資料才能回答的問題（查庫存、查日曆、查 CRM 記錄）、需要執行多步驟操作的任務（查詢 + 更新 + 發通知）。

在 N8N 裡設定這個架構的步驟：

一、建立 AI Agent 節點，選擇你要用的 LLM（Claude 或 OpenAI）

二、在 AI Agent 節點下方，新增「Tool」子節點。N8N 內建很多 Tool 類型，包括 HTTP Request Tool（可以呼叫任意 API）、Workflow Tool（可以呼叫另一條 N8N 流程）、Calculator、Code Tool 等

三、給每個 Tool 寫清楚「描述」，因為 AI 是根據描述來判斷什麼時候用哪個 Tool

Tool 描述的寫法很重要。如果你有一個查訂單的 Tool，描述應該是「Use this tool when you need to look up order information by order ID. Input: order ID (string).」描述越精確，AI 用錯 Tool 的機率越低。

架構四：Multi-Agent（多個 AI 協作）

流程：Orchestrator Agent → 根據任務分配給 Sub-agent A / Sub-agent B / Sub-agent C

這是最進階的架構，適合複雜的多步驟任務。一個主 AI 負責「規劃」，把大任務拆成小任務分配給多個子 AI 分別執行，最後再整合結果。

在 N8N 裡，Sub-agent 可以是 Workflow Tool（每個 Sub-agent 是獨立的 N8N 流程），或者是同一條流程裡的多個 LLM 節點串在一起。

適合場景：複雜的研究任務（搜尋 + 分析 + 撰寫報告）、需要專業分工的流程（一個 AI 負責技術分析、一個負責商業判斷、一個負責輸出整理）。

初學者建議從架構一或二開始，跑通了再考慮升級到架構三。

RAG 的基本架構：讓 AI 根據你的知識庫回答

RAG（Retrieval-Augmented Generation）是目前最實用的 AI Agent 應用場景之一。概念很簡單：讓 AI 在回答問題之前，先去你的知識庫裡找相關資料，然後根據找到的資料來回答，而不是靠它自己的訓練數據。

在 N8N 裡搭一個基本的 RAG 流程，分兩個部分：

知識庫建立部分（一次性執行）：

讀取你的 FAQ 文件或產品說明，用 Embeddings 節點（OpenAI Embeddings 或 Ollama Embeddings）把文字轉成向量，把向量存進 Vector Store（N8N 支援 Supabase、Pinecone、Qdrant 等）。

對話流程部分（每次對話觸發）：

接收使用者問題，把問題轉成向量，在 Vector Store 裡找最相近的幾筆資料，把找到的資料加上使用者問題一起丟給 LLM，LLM 根據找到的資料回答問題，最後回覆使用者。

這個架構的優勢是：AI 的回答有你自己的知識庫作為依據，不會亂說話。知識庫更新了，回答就自動跟著更新，不需要重新訓練模型。

RAG 客服機器人的完整 30 分鐘實作步驟，可以參考同主題的 Cluster 文章「第一個 AI Agent 工作流：RAG 客服機器人 30 分鐘搭好」，裡面有完整的節點設定流程。

設計 AI Agent 流程的五個實戰原則

光知道架構還不夠，實際設計流程的時候有幾個坑是大多數人都會踩到的。

原則一：輸出格式要嚴格規定

AI 的輸出如果不格式化，後續節點會很難處理。用 JSON Mode（OpenAI 支援）或在 Prompt 裡明確要求輸出 JSON，然後用 N8N 的 JSON Parse 節點解析。

範例 Prompt 結尾：「請用以下 JSON 格式回覆，不要加任何其他文字：{“category”: ”…”, “priority”: “high/medium/low”, “summary”: ”…”}」

原則二：加 Error Handling

AI 有時候會回傳格式不對的內容，特別是在 edge case 的情況下。在 LLM 節點後面加一個 IF 節點檢查輸出是否符合預期格式，不符合就走 fallback 路徑（比如轉給人工）。

原則三：控制 Token 用量

Token 用量直接影響成本。把 System Prompt 寫短，去掉所有廢話；傳給 AI 的資料只傳「相關欄位」，不要把整個資料物件丟進去；RAG 的召回數量控制在 3-5 筆，太多只是增加成本不增加品質。

原則四：加 Loop 機制但設上限

如果你的 AI Agent 需要多輪對話才能完成任務，N8N 的 Loop Over Items 或遞迴流程是可行的。但一定要設最大迴圈次數，防止 AI 陷入無限迴圈吃掉你的 API 額度。

原則五：先用低成本模型測試邏輯

流程邏輯測試階段，先用 GPT-4o-mini 或 Claude Haiku，確認流程走向正確之後，再換成更強的模型做品質調整。這樣測試成本可以降低 90%。

真實場景：一個電商客服 AI Agent 的完整設計

讓我用一個實際的場景把前面講的東西串起來。

背景：一個中小型電商，每天大概有 50-100 封客服信件，目前靠 1 個人工客服處理，他／她大部分時間都在回答重複問題：「我的訂單到哪了」「怎麼退換貨」「這個商品有沒有某某尺寸」。

設計目標：讓 AI 自動回覆其中 80% 的重複性問題，人工只需要處理剩下 20% 的複雜情況。

流程設計：

第一層：Email Trigger（Gmail 節點）接收新信件

第二層：AI 分類器（GPT-4o-mini）判斷問題類型，分為訂單查詢、退換貨、商品規格、其他四類

第三層：根據類型分流

訂單查詢走向：呼叫訂單查詢 API，取得訂單狀態，AI 整理成回覆格式，自動發信

退換貨走向：RAG 查詢退換貨政策，AI 根據政策說明回覆，自動發信

商品規格走向：RAG 查詢商品規格資料庫，AI 回覆，自動發信

其他走向：轉給人工客服，同時附上 AI 整理的「問題摘要」讓人工更快回覆

這個設計的重點是：分類用便宜的 mini 模型降低成本，Tool Use 只在真正需要的時候觸發，RAG 知識庫用你自己的退換貨政策不靠 AI 亂猜，無法判斷的情況不強行 AI 回覆，保留人工介入的彈性。

這個架構搭起來大概需要 2-3 小時，主要時間花在知識庫的整理和 Prompt 的調整上。

怎麼開始：新手的入門路徑

如果你還沒有動手過，這裡給你一個具體的學習路徑：

第一週：先跑通一個「最小可用流程」。Trigger 收 Email → GPT-4o-mini 分類 → 把分類結果寫進 Google Sheet。這個流程不需要 RAG，不需要 Tool Use，只是讓你熟悉 LLM 節點怎麼用、怎麼傳資料、怎麼讀結果。

第二週：加入 Tool Use。在現有流程裡加一個查詢功能，比如讓 AI 能夠查詢某個 API 或 Google Sheet，然後根據查到的資料做判斷。

第三週：建立你的第一個 Knowledge Base。用自己的文件做 Embeddings，建一個簡單的 RAG 流程，測試 AI 能不能根據你的資料回答問題。

第四週：把前三週學到的東西合在一起，搭一個真正有用的 AI Agent。

N8N 有 1700+ 現成模板，裡面有不少 AI Agent 相關的模板可以直接套用當起點。從模板開始改，比從空白畫布開始快很多。進一步了解如何選模板，可以閱讀「N8N 工作流模板 1700+ 怎麼選、怎麼改、怎麼套用」。

常見問題

AI 回答錯誤怎麼辦？加入 Human in the Loop 機制。AI 回覆後先送給你的 Slack 或 LINE 確認，你點「確認送出」才真的發出去。這樣能接住 AI 的錯誤，同時你也能觀察 AI 在哪些場景下容易出錯，再針對性地調整 Prompt。

成本怎麼控制？用 N8N 的 execution log 監控每次流程用了多少 token。定期審查哪些流程的 token 用量異常高，通常是 Prompt 太長或傳了太多不必要的資料。

怎麼知道 AI 有沒有幫到忙？設定一個「AI 處理率」指標：AI 成功處理的任務數除以總任務數。初期目標 50%，穩定後目標 80%。低於預期就回頭看分類準確率和回覆品質，找到問題點再調整。

開始行動

N8N 串 AI 這件事，最大的門檻不是技術，是「搞懂你自己的業務流程」。

AI 做什麼決策、依據什麼資料、什麼情況下轉人工——這些都需要你先想清楚，才能翻譯成 N8N 的節點設計。

技術層面的東西，有模板、有社群、有這篇文章，都可以解決。

真正值得你花時間想的問題是：你現在每天在重複做哪些「判斷加處理」的工作？

那就是你的第一個 AI Agent 應該解決的事。

留言告訴我你的場景，我來看能怎麼幫你設計。

想直接從現成模板開始？前往 N8Nstart 模板庫找 1700+ 個 AI Agent 與自動化模板。