在建立 n8n 的自動化工作流時，許多新手都會遇到一個核心痛點：畫面上同時有 LLM 節點和 AI Agent 節點，到底該拉哪一個？ 如果你習慣將所有任務都塞給 AI Agent 處理，你可能會面臨 Token 費用暴增、執行流程不穩定，甚至是難以 Debug 的地獄。這篇文章將帶你深度解析 LLM 與 AI Agent 的本質差異，並教你如何針對不同的戰場，選擇最適合的自動化武器。 💡 核心對決：LLM 與 AI Agent 的本質差異在哪裡？要理解兩者的差異，我們可以用最簡單的「積木（Function）」概念來看： LLM (大型語言模型)： 本質上它**只有一個大腦 (Model)**。它採取一問一答的線性模式（你問 → 他回），完全處於被動狀態。 AI Agent (智能體)： 除了大腦 (Model) 之外，它還具備了 記憶 (Memory) 與 **工具箱 (Tools)**。它能夠根據你的目標，自主啟動 ReAct（理解目標 ➔ 規劃步驟 ➔ 呼叫工具 ➔ 檢查結果）的多步推理解迴路，直到任務完成。 🧠 為什麼 90% 的場景你只需要 LLM？（省錢又穩定）許多新手在初學 n8n 時，容易陷入「凡事皆用 Agent」的誤區。事實上，在日常的自動化任務中，有高達 90% 的時間你只需要使用單純的 LLM 節點。 適合 LLM 處理的任務特徵： 流程固定： 擁有明確的輸入（Input）與輸出（Output）。 純文字處理： 例如資料摘要、語言翻譯、語意分類（客訴情緒判斷）。 生成結構化資料： 幫你打草稿、生成 Email 內容、或是轉換成特定格式（JSON、SQL）。 LLM 的絕對優勢： 超便宜： 只要 Prompt 寫好，一次呼叫就解決，Token 消耗極低。 超好 Debug： 流程固定，出錯時一眼就能看出是哪個環節的問題。 可控性極高： 嚴格遵循你的指令，不會有意外的自主決策。 🦸‍♀️ 何時才需要派 AI Agent 上場？（處理不確定任務）如果你今天的任務沒有固定的標準流程，且需要「動態決策」或「與外部系統互動」，這時才是 AI Agent 發揮價值的舞台。 適合 AI Agent 處理的任務特徵： 不確定的流程： 無法事先寫死所有的判斷條件。 需要多步驟決策： 遇到問題需要反覆思考並修正。 依賴外部工具： 例如自動查訂單資料庫、上網搜尋最新資訊、或是直接操作 API 發送郵件。 ⚠️ 新手防坑警告：拜託不要濫用 Agent！AI Agent 雖然聰明，但會帶來高昂的代價。它在思考與嘗試的過程中會消耗大量 Token（成本直接爆炸），且由於具備自主決策權，非常容易產生「幻覺 (Hallucination)」導致過度行動。如果出錯，因為思考邏輯成謎，Debug 的難度將會非常高。 鐵則：能用 LLM 解決的問題，就絕對不用 Agent！ 🏗️ 大師級實戰架構：如何打造「黃金混合生產線」？在實戰中，最強的架構不是全用 Agent，也不是全用 LLM，而是將兩者混搭，各司其職。我們以「智能客服工作流」為例： 讓 Agent 當「廠長」負責決策 (Decision)：接收到客戶訊息後，由 AI Agent 判斷「是否需要回覆？」。如果需要，Agent 會決定去 Database 調出這筆訂單資料。 讓 LLM 當「作業員」負責處理 (Process)：將訂單資訊與客訴內容交給純 LLM 節點，請它專心撰寫一封語氣誠懇的安撫 Email（生成內容）。 讓 Tools 當「輸送帶」確實執行 (Execute)：最後，將 LLM 寫好的信件交給常規的 HTTP / Gmail 節點（不需要 AI），單純負責把信件送出。 這樣一來，Agent 不需要浪費 Token 去寫信，LLM 也不需要負擔決策的壓力，整個 n8n 流程既聰明、穩定又省錢！ 常見問答 (FAQ)Q：為什麼我在 n8n 中使用 AI Agent 執行任務，費用會突然暴增？A：因為 AI Agent 具備「ReAct（推理與行動）」機制。為了解決一個問題，它會在背後不斷自我對話、反覆呼叫工具並驗證結果，每一次的內部迴圈都會消耗大量的 Token。如果沒有嚴格限制它的行動次數或提供精確的 Prompt，成本就會直線上升。 Q：我該如何決定一個新流程要用 LLM 還是 Agent？A：你可以問自己兩個問題：第一，「這個任務的流程是否固定不變？」第二，「任務需要自行判斷並呼叫外部工具來查資料嗎？」。如果流程固定且只需純文字轉換，請召喚 LLM；如果需要多重判斷與操作工具，再指派 Agent。 Q：如果我的 AI Agent 流程一直報錯，該如何優化？A：遇到 Agent 報錯或產生幻覺，首要之務是「把它牢牢限制住」。你可以在 System Prompt 中給予極度明確的目標與角色設定，限制其最大思考與行動次數，並確保給予的 Tools (工具箱) 只有它絕對需要的工具，避免它漫無目的地亂猜。若還是難以 Debug，建議將複雜流程拆解，改用「Agent 決策 + LLM 執行」的黃金混合架構。

使用 n8n 串接 LINE 官方帳號，最彈性且穩定的做法並非依賴專用的第三方節點，而是回歸本質，直接使用基礎的網路傳輸節點： 透過 Webhook 節點 接收來自 LINE 的 Webhook 事件。 透過 HTTP Request 節點 呼叫 LINE Messaging API 來回覆或推送訊息。 這種「不依賴特定模組」的架構，不僅能支援 LINE 最新的 API 功能，在未來擴充與維護上也最為自由。 n8n 串接 LINE 的核心運作架構為何？要建立流暢的自動化回覆，整個資訊流的方向如下： 使用者觸發： 使用者傳送訊息給 LINE 官方帳號。 事件推送： LINE 伺服器將該事件（Event）打包成 JSON，以 POST 方式傳送至你設定的 n8n Webhook URL。 資料解析： n8n 接收後，過濾並解析使用者的訊息內容。 執行回應： n8n 透過 HTTP Request 節點，帶著身分驗證（Token）呼叫 LINE Reply API 或 Push API，將回覆傳送給使用者。 💡 專家提示： LINE 官方文件明確指出，當使用者與官方帳號互動時，LINE 會發送 Webhook Event。而 n8n 的 Webhook 與 HTTP Request 節點完美對應了「接收」與「發送」這兩個必要動作。 開始前，你需要準備哪些開發環境？在建立工作流程前，請確保你已準備好以下兩端的設定： 1. LINE Developers 端請登入 LINE Developers Console，建立並設定你的 Messaging API Channel： 取得 Channel access token（用於 API 呼叫身分驗證）。 取得 Channel secret（用於後續的安全性簽章驗證）。 準備好填寫 Webhook URL 的位置（稍後從 n8n 取得）。 LINE 官方開發入口可參考：LINE Developers 2. n8n 端你需要一個 可從外網透過 HTTPS 存取 的 n8n 伺服器： LINE 的 Webhook 嚴格要求必須是公開的 HTTPS 網址。 請務必使用 n8n Webhook 節點提供的 Production URL（正式網址），Test URL 僅供編輯器內手動測試使用。 若你的 n8n 架設在 Reverse Proxy（如 Nginx、Cloudflare Tunnel）後方，請確保系統環境變數的 Webhook Base URL 設定正確。 實戰教學：3 步驟完成 n8n 與 LINE Webhook 設定步驟 1：建立 n8n Webhook 節點 (接收入口)在 n8n 中新增一個 Webhook 節點，這是整個自動化的起點： HTTP Method: POST Path: 自訂路徑，例如 line-webhook Respond: 設為 Immediately 或 Using Respond to Webhook Node（建議盡速回應 200 OK）。 設定完成後，複製節點上的 Production URL（例如：https://your-domain.com/webhook/line-webhook）。將此網址貼回 LINE Developers Console 的 Webhook URL 欄位並啟用，同時點擊 Verify 測試連線。 步驟 2：加入資料分流與判斷 (IF / Switch)LINE 送來的事件很多種（加入好友、封鎖、文字訊息、圖片等）。透過 IF 或 Switch 節點，過濾出你想處理的事件，例如僅處理文字訊息： 條件設定：{{ $json.body.events[0].type }} === "message" 條件設定：{{ $json.body.events[0].message.type }} === "text" 步驟 3：設定 HTTP Request 節點 (回覆訊息)過濾出文字後，使用 HTTP Request 節點呼叫 LINE Reply API： Method: POST URL: https://api.line.me/v2/bot/message/reply Authentication: 可使用 Header Auth 或直接在 Headers 手動加入。 Headers: Authorization: Bearer {{你的_CHANNEL_ACCESS_TOKEN}} Content-Type: application/json Body (JSON):123456789{ "replyToken": "={{$json.body.events[0].replyToken}}", "messages":[ { "type": "text", "text": "你剛剛說的是：{{$json.body.events[0].message.text}}" } ]} ⚠️ 絕對不能省的 Content-Type 設定：雖然你已經設定了 Bearer Auth 來驗證身分，但 **務必手動加上 Content-Type: application/json**。Authorization 管的是「你是誰」，而 Content-Type 是告訴 LINE「你送的資料格式」。如果漏掉這行，LINE API 非常容易直接回傳 400 Bad Request 錯誤。 資訊安全必備：如何在 n8n 實作 LINE 簽章驗證？為了防止惡意攻擊者偽造 LINE 的請求打爆你的 Webhook，LINE 官方強烈建議驗證請求標頭中的 x-line-signature。 簽章驗證官方文件可參考：Verify webhook signature 在 n8n 的實作步驟： 開啟原始內容： 在 Webhook 節點設定中開啟 Raw Body 選項，因為簽章驗證必須使用「完全未經解析的原始 Request Body」，若經過 JSON Parser 重整，計算出的雜湊值就會出錯。 加密運算： 加入 Crypto 節點，選擇 HMAC-SHA256 演算法。 設定密鑰： 將 LINE 的 Channel secret 作為加密 Key，對 Raw Body 進行加密。 編碼與比對： 將加密結果轉為 Base64 格式，並使用 IF 節點比對是否與 Header 中的 x-line-signature 完全一致。 進階實用情境：圖片處理與主動推播當你的基礎文字 echo bot 跑起來後，可以嘗試擴充以下業務邏輯： 1. 接收與處理圖片 (Image Handling) 事件觸發後取得 message.id。 透過 HTTP Request 發送 GET /v2/bot/message/{messageId}/content 取得圖片。 將下載的圖片串接後續節點（如上傳至 Google Drive、S3，或丟給 AI Vision 進行影像分析）。 2. 主動推播通知 (Push Messages)不需等待使用者講話，只要你有對方的 userId，就能利用 Push API 主動發送訊息。非常適合用於：電商訂單狀態更新、報名成功通知、定時提醒或 AI 每日摘要推播。 邁向企業級：如何規劃高擴充性的 n8n 自動化架構？如果你打算打造正式商業用的 LINE 自動化系統，建議將 n8n 工作流拆分為「兩層式架構」： 入口層 (Gateway Workflow)：專門負責 Webhook 接收、簽章驗證、回覆 HTTP 200 OK 給 LINE（避免超時），並將事件標準化後，透過子工作流 (Execute Workflow node) 傳遞下去。 業務層 (Business Workflows)：根據事件類型觸發不同的業務邏輯。例如：FAQ 智能客服 (串接 OpenAI)、會員資料寫入 (串接 Google Sheets / CRM)、預約系統建立 (串接 Notion / Airtable)。 這樣拆分的好處是：不僅能大幅降低 LINE Reply Token 逾時的風險，未來擴充任何 AI 工具或資料庫都會變得異常輕鬆。 常見問答 (FAQ)Q：HTTP Request 節點已經設定了 Bearer Auth，還需要手動加上 Content-Type 嗎？A：需要，強烈建議手動加上！ Authorization: Bearer xxx 僅負責身分驗證，而 Content-Type: application/json 是告訴 LINE 伺服器你傳送的資料格式。雖然某些 n8n 版本在 Body Type 選擇 JSON 時會自動補上，但為了避免難以除錯的 400 Bad Request 錯誤，手動在 Header 加上 Content-Type 是最穩妥的最佳實務。 Q：為什麼我在 LINE Developers 後台點擊 Verify Webhook，一直測試失敗？A：最常見的原因有兩個：第一，你在 n8n 提供的是 Test URL（僅限編輯模式有效），請務必改用 Production URL 並啟用 (Activate) 該工作流。第二，若你的 n8n 架設在反向代理伺服器（如 Nginx、Cloudflare）後方，請檢查 WEBHOOK_URL 系統環境變數是否有正確設定為對外公開的 HTTPS 網域名稱。 Q：LINE 的 Reply Token 有時效限制，如果我的流程需要很長的運算時間（例如呼叫 AI 整理資料）該怎麼辦？A：LINE 規定 Webhook 必須盡快給予 200 OK 回應，且 Reply Token 的有效時間非常短。實務上的做法是：Webhook 接收後立刻回傳「已收到您的訊息，處理中…」，接著將耗時任務（如 AI 分析）往後丟給非同步流程處理。當資料處理完畢後，改用 Push API 主動推播最終結果給該使用者的 userId。 官方文件延伸閱讀 LINE Developers Verify webhook signature Sending messages