N8N x LLM 打造 AI Agent 工作流：從零開始的實戰教學

N8N AI Agent 是 N8N 內建的一種節點，讓大型語言模型（LLM）不只是回答問題，而是能自己判斷該呼叫哪些工具、依結果決定下一步，把整段任務跑完。這篇從零開始，帶你理解 AI Agent 的運作原理、實際搭一個會做事的 Agent，並裝上避免它失控的安全護欄。

如果你之前用 N8N 串過 OpenAI，多半是「丟一段 prompt、拿一段回覆」的單向呼叫。AI Agent 是另一個層次：你給它一個目標和一組工具，它會像一個初級助理那樣，自己決定先查資料、再算數字、最後寫結論。理解這個差別，是整篇教學的起點。

先搞懂：Chain 與 Agent 的本質差別

很多人混用這兩個詞，但它們在 N8N 裡是兩種不同的東西。

Chain（鏈） 是固定流程：輸入 → prompt → 模型 → 輸出。每一步你都寫死了，模型只負責「填空」。適合翻譯、摘要、分類這種步驟明確的任務。

Agent（代理） 是動態流程：你給目標 + 工具清單，模型自己決定呼叫順序。它可能先呼叫搜尋工具、看結果不夠再呼叫第二個、最後才生成回覆。適合「需要視情況決定下一步」的任務。

面向	Chain	Agent
流程	固定	模型動態決定
工具呼叫	無或單一	多工具、可迭代
適用	翻譯/摘要/分類	客服處理/研究/多步任務
風險	低、可預測	高、需設護欄
成本	穩定	可能爆量

一句話判斷：任務步驟你能事先寫死，就用 Chain；要模型臨場判斷，才用 Agent。 不要因為 Agent 聽起來厲害就什麼都用 Agent——它更貴、更難除錯、更容易失控。

動手前的三個準備

一個 LLM 憑證：本教學用 OpenAI（GPT-4o），但 Anthropic Claude、Google Gemini 在 N8N 裡的接法幾乎一樣。把 API key 存進 N8N 的 Credentials，別寫死在節點裡。
N8N 版本確認：AI Agent 相關節點在較新版本才穩定，自架的話先把版本更到近期穩定版。
一個明確的小目標：第一個 Agent 別貪心。我們就做一個「客服分流助理」：讀一封進線信，判斷它屬於哪一類，需要時查 FAQ，最後產出建議回覆。

實戰：搭一個客服分流 AI Agent

Step 1：放下 AI Agent 節點

新建工作流，加一個觸發節點（先用 Manual Trigger 測試，上線再換成信箱或 webhook 觸發）。接著加入 AI Agent 節點。這個節點本身是「大腦」，但它需要你掛三樣東西上去：Chat Model、Tools、Memory。

Step 2：掛 Chat Model

在 AI Agent 節點下方的 Chat Model 連接點，接一個 OpenAI Chat Model 節點，選 gpt-4o。GPT-4o 在「判斷該呼叫哪個工具」這種推理任務上表現穩定，又比頂規模型便宜，是 Agent 的甜蜜點。

設定建議：

temperature 設低一點（0.2–0.4），Agent 任務要的是穩定判斷，不是創意發揮。
開啟 function calling / tools 支援（GPT-4o 原生支援）。

Step 3：寫 System Prompt（最關鍵的一步）

Agent 的成敗八成在 System Prompt。它要說清楚三件事：角色、可用工具、輸出格式。

你是一個客服分流助理。你的任務是讀取一封客戶來信，判斷它屬於
[帳務問題 / 技術問題 / 一般諮詢] 三類之一。

判斷規則：
- 涉及付款、發票、退款 → 帳務問題
- 涉及登入失敗、功能錯誤、bug → 技術問題
- 其他 → 一般諮詢

若需要產品資訊才能回覆，呼叫 FAQ 查詢工具，不要自己編造答案。

輸出必須是 JSON：
{ "category": "...", "suggested_reply": "...", "need_human": true/false }
複雜或情緒激動的客訴，把 need_human 設為 true。

注意最後一句——明確告訴 Agent什麼時候該舉手求救，是避免它硬答錯答的關鍵。

Step 4：掛 Tool（FAQ 查詢）

在 Tools 連接點接一個工具。最簡單的做法是接一個 Workflow Tool，指向另一個查 FAQ 資料庫（或向量資料庫）的子工作流。Agent 會在 System Prompt 允許的情況下，自己決定要不要呼叫它。

工具的 description 一定要寫清楚「這個工具在什麼情況該用、輸入什麼、回傳什麼」——Agent 是靠這段描述決定要不要呼叫它的，描述含糊它就會亂用或不用。

Step 5：掛 Memory（選用）

單封信分流其實不需要記憶。但若你要做多輪對話的客服機器人，就在 Memory 連接點接 Window Buffer Memory，讓 Agent 記得前幾輪講過什麼。記住：記憶會把歷史塞進每次的 prompt，直接推高 token 成本，按需使用。

Step 6：接後續動作

AI Agent 輸出 JSON 後，接一個 Switch 節點依 category 分流，依 need_human 決定是直接回覆還是轉真人。到這裡，一個會自己判斷、會查資料、會在拿不準時舉手的 Agent 就成形了。

上線前必裝的安全護欄

這段是大多數教學略過、卻最會出事的地方。Agent 之所以強，是因為它有自主性；而自主性沒有護欄，就是災難。

護欄一：迭代上限

Agent 會「想完再做、做完再想」地迭代。若任務卡住，它可能陷入無限自我呼叫，把 API 額度一路燒乾。在 AI Agent 節點設定 Max Iterations（建議 5–10），超過就強制停止。

護欄二：輸出結構化驗證

模型「大致」會照你要的 JSON 格式輸出，但偶爾會脫稿。在 Agent 後面接一個驗證節點（或用 Structured Output Parser），格式不對就走錯誤分支，絕不要讓沒驗證的 LLM 輸出直接流進下游系統。

護欄三：成本監控與告警

設一個每日 token / 費用上限的監控工作流。Agent 失控時，你要在帳單寄到之前就知道。這本身就是「通知與告警」類工作流的好應用。

護欄四：人在迴路（Human-in-the-loop）

對外發送、寫入資料庫、執行付款這類不可逆動作，務必走「Agent 產出建議 → 人工確認 → 執行」。讓 Agent 提案、由人按下最後那顆按鈕。

護欄五：工具權限最小化

Agent 能呼叫的工具，就是它能造成的破壞範圍。只給它完成任務必要的工具，別圖方便把一個萬能的「執行任意 SQL」工具掛上去。

常見卡關與排查

Agent 不呼叫工具：八成是工具的 description 寫太模糊，或 System Prompt 沒說清楚何時該用。把描述寫得像給新人的操作說明。
輸出格式飄移：降 temperature、加 Structured Output Parser、在 prompt 裡放一個明確的 JSON 範例。
成本爆掉：檢查是不是開了 Memory 又設太大的 window、或迭代上限沒設。
回答在亂編：System Prompt 要明寫「不確定就呼叫工具或設 need_human，禁止編造」。

結語：從會聊天到會做事

AI Agent 把 LLM 從「一個很會講話的對話框」變成「一個會做事的同事」。但同事需要管理——清楚的職責（System Prompt）、明確的工具、以及不會讓它闖大禍的權限邊界。

先從這個客服分流 Agent 練起，跑順之後再加工具、加場景。等你想更深入單一模型的串接細節，可以接著看 N8N 串接 OpenAI GPT-4o 的完整設定，把 Agent 背後那顆「大腦」調到最佳狀態。

記住一句話：Agent 的能力上限是模型給的，但 Agent 的安全下限是你給的。護欄裝好，再放它上線。